J'ai commis des erreurs d'architecture. Plusieurs. Certaines coûteuses en temps, d'autres en réputation. En construisant Lydia-Edu, Séko, et les outils internes d'Omnitrade, j'ai appris des leçons que les tutoriels YouTube ne couvrent pas — parce qu'ils sont pensés pour des contextes très différents du nôtre.
Voici les trois erreurs qui m'ont le plus coûté, et comment les éviter.
Erreur 1 : Supposer une connexion stable
Ma première version de Lydia-Edu chargeait les données depuis l'API à chaque action utilisateur. Pas de cache, pas de gestion offline, pas de queue de synchronisation. Sur une connexion fibre parisienne, ça tourne. Sur une 3G béninoise un lundi matin, c'est une expérience catastrophique.
La correction : Architecture offline-first dès la conception. Service Workers pour le cache des assets critiques. IndexedDB pour la persistance locale. Une queue d'actions qui se synchronise quand la connexion revient. C'est plus de travail initial, mais c'est la différence entre un produit qui fonctionne et un produit qu'on abandonne après la deuxième utilisation.
Erreur 2 : Microservices trop tôt
Fasciné par les architectures que je lisais dans les articles de Netflix et Uber, j'ai commencé Séko avec une vision microservices : un service pour l'authentification, un pour les transactions, un pour les notifications, un pour la gestion des litiges. Sur le papier, c'est élégant. En pratique, avec une équipe de deux personnes et zéro utilisateurs payants, c'est une dette opérationnelle massive.
Déployer, monitorer, déboguer des appels inter-services sur une infrastructure cloud sans budget significatif : c'est plusieurs heures perdues par semaine pour des gains de scalabilité dont vous n'avez pas encore besoin.
La correction : Monolithe modulaire d'abord. Une base de code bien organisée avec des modules clairement séparés, déployée comme une seule application. Quand vous atteignez les limites réelles (problèmes de performance mesurés, équipes qui se marchent dessus), vous extrayez les services qui en ont besoin. Pas avant.
Erreur 3 : Ignorer le coût des requêtes N+1
Sur le tableau de bord administrateur de Lydia-Edu, j'avais une page qui listait les classes avec, pour chaque classe, le nombre d'élèves, la moyenne générale, et les absences du mois. Développée vite, sans attention particulière aux requêtes générées. Résultat : pour 20 classes, l'API faisait 61 requêtes SQL. Temps de réponse : 4 à 8 secondes.
La correction : Apprendre à lire les requêtes générées par son ORM. Utiliser des jointures et de l'agrégation SQL plutôt que de charger des entités et de calculer en mémoire. Ajouter du logging des requêtes en développement. Et surtout : tester avec des volumes de données réalistes, pas avec les 5 entrées de votre base de dev.
La méta-leçon
Ces trois erreurs ont un point commun : j'ai appliqué des solutions pensées pour des problèmes que je n'avais pas encore, dans un contexte que ces solutions ne prenaient pas en compte. L'ingénierie logicielle en Afrique de l'Ouest n'a pas besoin d'être inférieure — elle a besoin d'être différente, ancrée dans ses contraintes réelles et ses opportunités spécifiques.