La question que tout développeur doit se poser avant d'écrire la première ligne

"Est-ce que ce code que j'écris aujourd'hui me facilitera ou me compliquera la vie dans 6 mois ?"

C'est la question que je me suis posée. Et la réponse m'a conduit vers une approche que j'avais déjà croisée dans mes lectures : l'architecture hexagonale.

C'est quoi l'architecture hexagonale ? (Sans le jargon)

Oublie le code une seconde.

Imagine que tu ouvres un restaurant. Tu as ta cuisine, c'est le cœur de ton activité, là où la vraie valeur est créée. Maintenant, tes clients peuvent commander de plusieurs façons : en salle, par téléphone, via une app de livraison, ou demain peut-être par WhatsApp.

Est-ce que tu reconfigurez toute ta cuisine à chaque nouveau canal de commande ? Non. Tu crées un protocole de commande standard, et n'importe quel nouveau canal qui respecte ce protocole peut interagir avec ta cuisine. La cuisine, elle, ne change pas.

C'est exactement l'idée derrière l'architecture hexagonale :

• Le cœur de ton application (ta logique métier) ne sait pas qui lui parle ni comment.
• Il définit des contrats (interfaces) : "voilà ce que j'attends de toi".
• Chaque outil externe base de données, API de paiement, service SMS implémente ce contrat à sa façon.
• Résultat : tu peux brancher ou débrancher n'importe quel outil sans toucher au cœur.

Comment ça se traduit dans le code

Dans notre système de paiement, le cœur ne connaît pas Orange Money. Il ne connaît pas MTN. Il ne connaît qu'un contrat :

Chaque intégration implémente ce contrat à sa façon :

Et une Factory se charge de donner le bon processeur selon le contexte :

Propre. Lisible. Et surtout extensible.

La semaine dernière : AfribaPAY entre dans le jeu

Nous avons conclu un partenariat avec AfribaPay, une solution de paiement qui élargit considérablement notre couverture.

J'ouvre le projet. Je crée AfribaPayProcessor.php qui implémente le même contrat que les autres. J'ajoute une ligne dans la Factory :

Et c'est tout.

Aucun code existant modifié. Aucun risque de régression sur Orange Money ou MoMo. Aucune nuit blanche. L'intégration complète, incluant les appels API, la gestion des erreurs et les tests bouclée en moins d'une heure.

Ce moment là, c'est ce que j'appelle le dividende de la bonne architecture. Tu paies un peu plus cher au départ en temps de réflexion, et tu encaisses des intérêts à chaque évolution du système.

Ce que cette expérience m'a confirmé

1. La complexité anticipée n'est pas de la sur ingénierie

Il y a un mythe dans notre métier : "ne construis pas ce dont tu n'as pas besoin maintenant". Ce principe est sain, mais mal interprété, il devient une excuse pour coder sans vision. Anticiper les points d'extension probables, ce n'est pas sur ingénier, c'est penser en architecte.

2. Un bon système grandit avec toi, pas contre toi

Beaucoup de développeurs ont vécu ce moment douloureux : reprendre un projet 6 mois plus tard et réaliser que la moindre modification risque de tout casser. C'est le signe d'un système couplé. L'architecture hexagonale découple les pièces. Chaque module peut évoluer indépendamment.

3. La lisibilité est une feature

Regarde la Factory ci-dessus. N'importe quel développeur, même junior, même qui rejoint l'équipe demain; comprend instantanément ce que fait ce code. Cette lisibilité a une valeur économique réelle : elle réduit le temps d'onboarding, diminue les bugs, et facilite la revue de code.

4. L'architecture, c'est aussi du respect

Respect pour ton équipe qui reprendra le code. Respect pour tes clients dont le système sera plus stable. Respect pour ton futur toi qui ne voudra pas pleurer en rouvrant le projet.

Pour les non développeurs qui lisent encore

Si vous travaillez avec des équipes techniques en tant que fondateur, product manager, investisseur ou client voici ce que vous devez retenir :

La qualité de l'architecture d'un système détermine le coût de son évolution.

Un système mal architecturé, c'est une dette qui s'accumule. Chaque nouvelle feature coûte plus cher. Chaque bug prend plus de temps. Chaque partenariat devient un chantier.

Quand vous évaluez une équipe technique, ne demandez pas seulement "combien de temps ?" demandez aussi "comment avez-vous prévu de le faire évoluer ?"

En conclusion

L'intégration d'AfribaPay en moins d'une heure n'était pas une performance extraordinaire. C'était juste le résultat logique d'une décision prise des mois en amont : prendre le temps de bien construire.

La pression du delivery est réelle. Les deadlines aussi. Mais si vous construisez quelque chose qui doit durer, ralentissez au moment de la conception. Votre futur vous remerciera et vos partenaires aussi.

Je suis Wilfried Okono, CTO chez We Tell Africa Group . Je construis des systèmes pensés pour durer dans des contextes africains exigeants; Mobile Money, connectivité variable, équipes en croissance.