En 2018, j'ai fait mon premier stage chez IT-KAMER à Yaoundé. On m'a confié l'intégration et le développement de sites web : PHP, Bootstrap, WordPress, les bases. À l'époque, je pensais que savoir coder était suffisant pour construire un vrai système. Je me trompais sur presque tout ce qui compte.
Quelques années plus tard, je me retrouve sur deux projets clients simultanément : une application de transfert et monétisation de fichiers numériques, et un système de marketing réseau avec intégration d'un opérateur de paiement mobile. C'est là que j'ai appris ce que l'université et les formations ne m'avaient pas dit.
Leçon 1 : comprendre le métier avant de toucher au code
Sur mon premier projet applicatif sérieux, j'ai commencé par modéliser la base de données. Produits, commandes, utilisateurs, paiements. Ça semblait logique. Le problème : je modélisais des tables, pas un processus métier.
Qu'est-ce qui se passe exactement quand une commande est passée ? Qui peut l'annuler ? Jusqu'à quand ? Qu'est-ce qui déclenche la notification ? Ces questions n'avaient pas de réponse parce que je ne les avais jamais posées. J'avais codé une structure de données, pas un système.
Passer les deux premières heures à écrire en français simple, sans aucun code, le flux complet d'une transaction de bout en bout. Qui fait quoi, dans quel ordre, sous quelles conditions. Ce document de deux pages aurait évité trois semaines de refactoring.
Un système métier existe pour servir un processus humain. Si on ne comprend pas ce processus avant de coder, on construit une solution à un problème qu'on a inventé.
Leçon 2 : une API tierce n'est jamais fiable par défaut
Sur un projet intégrant un opérateur de paiement mobile, j'ai eu ma première vraie leçon sur les systèmes distribués. L'API fonctionnait. Puis elle ne fonctionnait plus. Puis elle fonctionnait à nouveau. Parfois elle répondait en deux secondes, parfois en trente.
Mon code d'origine supposait que chaque appel API allait réussir. Pas de timeout configuré. Pas de retry. Pas de gestion d'état intermédiaire. Résultat : des transactions en état indéterminé, ni confirmées, ni annulées. L'argent avait quitté le compte Mobile Money mais la commande n'était pas validée. Ou l'inverse.
Tout appel vers un service externe est traité comme une opération qui peut échouer à tout moment. Timeout explicite, retry avec backoff exponentiel, état de transaction persisté avant l'appel. Cette discipline est non négociable dès le départ, quelle que soit la passerelle.
Leçon 3 : le code qui marche et le code qui dure sont deux choses différentes
Sur un projet de distribution de contenu numérique avec plusieurs passerelles de paiement, la première version fonctionnait. Les fichiers s'uploadaient, les paiements passaient, les téléchargements marchaient.
Mais la logique de paiement était répartie entre le contrôleur, le modèle, et trois fonctions utilitaires sans rapport apparent. Ajouter une nouvelle passerelle aurait nécessité de comprendre et de modifier du code à cinq endroits différents. Tester une règle de commission isolément était impossible.
Le code marchait. Mais il était fragile. Un changement de règle chez l'un des prestataires de paiement, et c'était une journée de débogage pour retrouver tous les endroits concernés.
Si cette règle métier change demain, combien d'endroits dois-je modifier ? Si la réponse est supérieure à un, le code a un problème de conception, pas de fonctionnement.
Leçon 4 : la certification Google m'a appris à apprendre, pas à construire
En 2017, j'ai obtenu la certification Mobile Web Specialist financée par Google et Andela, via Udacity et PluralSight. Service Workers, Progressive Web Apps, optimisation des performances, stockage local. C'était une excellente formation technique.
Ce qu'elle ne m'a pas appris : comment prendre une décision d'architecture quand trois solutions sont toutes techniquement valides. Comment estimer la complexité d'une intégration avant de l'avoir commencée. Comment expliquer à un client pourquoi sa fonctionnalité "simple" prend une semaine.
Les certifications et formations enseignent des outils. Les projets réels enseignent le jugement. Il n'existe pas de raccourci entre les deux, mais on peut accélérer le deuxième en étant honnête sur ce qu'on ne sait pas encore.
Leçon 5 : écrire des tests n'est pas une perte de temps
Sur mes premiers projets, je ne testais pas. Je cliquais. Je soumettais des formulaires. Je regardais ce qui se passait dans la base de données. C'était lent, imprévisible, et ça ne couvrait que les cas que j'avais pensé à tester.
Le jour où j'ai écrit mon premier test unitaire qui a détecté une régression que je n'avais pas vue en cliquant, quelque chose a changé dans ma façon de travailler. Le test m'avait dit que le code était cassé avant que j'aie eu à le découvrir en production.
Le TDD n'est pas une contrainte méthodologique. C'est un outil de réflexion. Écrire le test en premier force à se demander : qu'est-ce que cette fonction est censée faire exactement ? Cette question, posée avant de coder, évite la moitié des bugs.
Ce que je dirais à celui que j'étais en 2018
La technique s'apprend. Les algorithmes, les frameworks, les APIs, tout ça s'apprend avec du temps et de la pratique. Ce qui s'apprend moins facilement, c'est la discipline de ralentir avant de commencer.
Comprendre le problème. Modéliser le domaine. Identifier les risques. Définir les contrats entre composants. Ces étapes semblent coûter du temps. En réalité elles en font gagner, mais le gain arrive plus tard, là où la douleur est invisible au départ.
Les meilleurs développeurs que j'ai rencontrés ne sont pas ceux qui codent le plus vite. Ce sont ceux qui posent les bonnes questions avant de commencer.
Je propose un accompagnement en amont : cadrage technique, choix d'architecture, identification des risques, avant que vous écriviez la première ligne de code.
Me contacter