Connectivité, coupures, cloud : les contraintes techniques d’un projet numérique à Djibouti

Un projet numérique conçu ailleurs et transposé tel quel à Djibouti se heurte vite au réel : coupures de courant, coût de la bande passante, latence vers les serveurs européens, disponibilité du matériel. Ces contraintes ne sont pas des obstacles insurmontables — mais elles doivent être des décisions d'architecture prises au départ, pas des découvertes après la mise en production.

La connectivité n'est pas continue

La question à se poser n'est pas « avons-nous internet ? » mais « que se passe-t-il pendant les vingt minutes où nous ne l'avons pas ? ». Pour un point de vente, une école ou un guichet, l'interruption est inacceptable : les clients sont là, les élèves aussi.

Trois réponses techniques, à combiner selon l'usage :

• Fonctionnement hors ligne pour les opérations critiques — encaisser, enregistrer une présence, imprimer un reçu — avec synchronisation dès le retour du réseau.
• Mise en cache locale des données consultées souvent, pour que l'application reste utilisable en lecture.
• Liaison de secours lorsque l'activité ne tolère aucune coupure, avec bascule automatique.

Le poids des pages compte

Quand la bande passante se paie au volume, une interface de 4 Mo par écran n'est pas seulement lente : elle coûte de l'argent à chaque consultation. Nous concevons les interfaces métiers en gardant cet arbitrage présent — images dimensionnées, chargement différé, pas de bibliothèque embarquée pour trois icônes.

Héberger localement ou dans le cloud ?

Il n'y a pas de réponse universelle. Le choix se décide sur quatre critères concrets :

1. La latence perçue : un serveur distant ajoute un délai à chaque action. Pour une saisie intensive, cela se sent.
2. La nature des données : certaines informations — dossiers d'usagers, données de santé, pièces d'état civil — ne devraient pas quitter le territoire.
3. Le coût récurrent : un abonnement en devises se renchérit avec le change ; un serveur local demande de l'électricité, de la climatisation et de la maintenance.
4. La capacité d'intervention : qui redémarre la machine à 22 h, et en combien de temps ?

Une architecture hybride — traitement local, sauvegarde chiffrée hors site — répond dans la majorité des cas que nous rencontrons.

L'électricité fait partie du système

Un serveur bien configuré derrière une alimentation instable reste un serveur fragile. Onduleurs correctement dimensionnés, arrêt propre en cas de coupure prolongée, redémarrage automatique des services : ces éléments coûtent une fraction du projet et évitent la corruption de base de données qui, elle, se paie en jours de travail perdus.

Sauvegardes : la règle des trois copies

Trois copies des données, sur deux supports différents, dont une hors du bâtiment. C'est un principe ancien, et il reste le seul qui résiste à la fois à la panne matérielle, à l'erreur humaine et au sinistre. Nous ajoutons systématiquement un quatrième point : tester la restauration. Une sauvegarde jamais restaurée n'est pas une sauvegarde, c'est une hypothèse.

Le matériel, maillon souvent négligé

Les délais d'approvisionnement locaux imposent d'anticiper. Choisir des équipements dont les pièces sont disponibles sur place, standardiser les modèles pour limiter les références à maintenir, prévoir un élément de rechange sur les points critiques du réseau : ce sont des décisions de conception, pas des détails logistiques.

C'est cette logique que nous appliquons sur les installations réseau et téléphoniques que nous livrons, comme celle réalisée pour l'Unité de Gestion du Projet du MAEPE-RH.

Concevoir pour le terrain, pas pour la démonstration

Une plateforme qui fonctionne parfaitement en salle de réunion et se bloque au guichet n'a pas rempli son objectif. Les contraintes djiboutiennes — réseau intermittent, énergie irrégulière, coût de la donnée — sont connues et adressables. Elles demandent simplement d'être traitées comme des exigences, au même titre qu'une fonctionnalité.

Si vous préparez un projet et que ces questions restent ouvertes, elles méritent d'être tranchées avant la première ligne de code.