Mission menée en 2023 puis 2024 avec Cœur du Web, l'agence que j'ai fondée. Mon rôle portait sur le pilotage et l'architecture, en binôme avec un associé, aux côtés de trois développeurs camerounais recrutés pour le projet.
Deux composantes sans équivalent sur le marché
Une base d'adressage numérique ouverte, destinée à devenir la référence du pays pour localiser un lieu là où l'adressage classique ne couvre pas tout le territoire. Puis une plateforme urbaine construite sur cette base, pour outiller les agglomérations. Aucune des deux n'existait en logiciel prêt à l'emploi.
L'absence d'équivalent sur le marché n'était pas un argument de vente, c'était un constat vérifié avant de proposer quoi que ce soit. L'adressage numérique souverain d'un pays et la plateforme urbaine de ses agglomérations ne sont pas des besoins que couvre un abonnement logiciel, et prétendre le contraire aurait fait perdre au programme le temps qu'il n'avait pas.
Le sujet ressemble à celui de n'importe quel arbitrage entre un outil du marché et du sur-mesure, à l'échelle près : ici, le mauvais choix se serait payé en souveraineté, pas seulement en budget.
Trois contraintes qui excluaient la solution évidente
- Un réseau intermittent. Le terrain couvre l'urbain, le péri-urbain et le rural. Une application qui exige une connexion permanente n'y sert à rien.
- Pas d'adressage formel préexistant. Impossible de s'appuyer sur un référentiel de rues et de numéros, puisque c'était précisément ce qu'il fallait construire.
- La souveraineté, dès le premier jour. Code, données et hébergement devaient être pilotés par l'institution camerounaise, pas confiés à un prestataire français qui les restituerait plus tard.
S'ajoutait une fenêtre de calendrier courte. Il n'y avait ni le temps d'un cycle de spécification long, ni la marge pour livrer une démonstration qui ne tiendrait pas en production. Nous sommes donc entrés en construction avec un cadrage léger mené en parallèle, ce qui est l'inverse de ce que je recommande d'ordinaire et ce que j'assume ici parce que la contrainte de calendrier était réelle et connue de tous.
Ce compromis a un coût, et il est honnête de le nommer : une part de la conception s'est faite au contact du terrain plutôt que sur le papier, ce qui exige une capacité de décision rapide côté pilotage et une confiance que tous les commanditaires n'accordent pas.
Construire pour un réseau qui tombe
Le principe retenu tient en une phrase : l'utilisateur enregistre sa contribution localement et elle remonte quand la connexion revient. Le repérage s'appuie sur la position satellitaire et une description courte, plutôt que sur un standard d'adressage inexistant.
Ce choix a des conséquences en cascade sur toute la chaîne, jusqu'à la gestion des conflits entre deux contributions faites hors ligne sur le même lieu. C'est le genre de décision qui se prend une fois, tôt, et qu'on ne peut plus reprendre ensuite sans tout redéfaire : exactement le type d'arbitrage qui justifie qu'un pilote soit présent dès la conception plutôt qu'à la recette.
La pile a été choisie libre et hébergeable indépendamment, non par préférence technique mais parce que la contrainte de souveraineté l'imposait. Une dépendance à un service propriétaire aurait rendu la transmission illusoire.
Former ceux qui prendraient la suite
Trois développeurs camerounais ont été recrutés sur place et formés sur le projet, en binôme avec l'équipe. Ils ont écrit du code parti en production et sont passés par les mêmes revues que les autres. À la fin de la mission, ce sont eux qui ont maintenu et fait évoluer les deux composantes.
C'est la décision dont je suis le plus certain avec le recul, et c'est aussi celle qui coûte le plus cher à court terme : former pendant qu'on livre ralentit la livraison. La ligne de budget correspondante est toujours la première qu'un commanditaire pressé propose de couper.
La justification tient en une observation simple. Livrer les sources d'un logiciel à quelqu'un qui ne sait pas les faire évoluer ne transmet rien du tout : on lui remet une archive, pas un outil. La souveraineté du code n'a de sens que si la souveraineté des compétences suit.
Le socle, et sa trace publique
La base d'adressage et la plateforme urbaine reposent sur le socle technique de BougeMaville, une solution de signalement géolocalisé que j'ai conçue et qui était déjà déployée dans des villes et des agglomérations avant ce programme. Le socle n'était donc ni un prototype ni une promesse commerciale : il tournait ailleurs.
C'est un point qui compte au moment de choisir entre construire de zéro et partir d'une base existante. Reprendre un socle éprouvé ne dispense pas de l'adapter, et l'essentiel du travail au Cameroun a porté sur ce que le socle ne savait pas faire : le fonctionnement hors ligne durable et le repérage sans adressage formel. Mais cela évite de redécouvrir des problèmes déjà résolus, sur un programme dont le calendrier ne le permettait pas.
Ce que prouve une sortie de mission
Les sources ont été remises avec un guide d'auto-hébergement, les accès et l'hébergement sont au nom de l'institution, et la disponibilité de la plateforme a été totale sur la durée de l'opération. Le projet n'est pas resté un actif de l'agence.
La preuve qu'un projet a été bien construit ne se lit pas à la livraison, elle se lit le jour où le client décide de reprendre la main. Ici, elle s'est jouée deux fois : la base d'adressage a servi de socle à la plateforme urbaine sans nouveau cycle d'engagement, et l'équipe locale a pris la suite sans rupture.
Le même critère s'applique à des projets sans commune mesure avec celui-là. Sur une refonte de site comme sur une application métier, la question utile au moment de signer est de savoir ce qui reste chez vous quand le prestataire s'en va : les sources, les accès, la documentation, et quelqu'un capable de s'en servir. C'est ce que doit prévoir le choix du prestataire, bien avant la recette.
Questions fréquentes
À propos de l'auteur
Laurent Tulpan
Directeur de projet digital senior, ancien développeur et expert SEO depuis 2005. Il pilote des refontes, des applications métier et des plateformes pour le compte de ses clients, pour des grands comptes, des PME et des institutions publiques. Découvrir son approche.
À lire ensuite
Faire développer une application
Budget, cahier des charges, choix du prestataire et pilotage.
Choisir son prestataire
Les critères qui comptent, et ceux qui ne veulent rien dire.
Reprendre un projet existant
Ce qu'il faut récupérer avant de reprendre du code écrit ailleurs.
Les autres missions
Deux autres cas, racontés du côté du pilote.