Pourquoi j'ai donné la recette d'une architecture incassable
Pourquoi j’ai donné la recette d’une architecture incassable
Six mois avant d’écrire cette page, j’ai passé une semaine à chasser un bug. Une correction avait créé deux autres. Un UseCase qui touchait à trop de choses. Un widget qui parlait directement à Firestore. Et puis un dépôt qui ne savait pas s’il devait retourner une entité brute ou un DTO.
À la fin, j’avais compris: je n’avais pas un problème de code. J’avais un problème de structure. Et mon agent IA n’y pouvait rien — c’était la maison qui était mal bâtie.
Le jour où j’ai dû refaire Studeat
Studeat avait échoué une première fois. Une agence l’avait montée. C’était brisé. J’ai eu 30 jours pour la refaire.
Le jour 1, j’ai dit non à la pression. Pas d’architecture pendant deux semaines, on va en improvisation. Ça avait marché sur BeeDone. Ça marche au début sur tout. C’est à partir du jour 15 qu’on paye.
Mais Studeat, c’était différent. Dix écoles attendaient. Pas de marge d’erreur. Zéro deadline extension.
Donc je me suis forcé. Je me suis assise la première semaine et j’ai écrit les couches. Domain pur (les règles métier qui n’ont aucune dépendance externe). Data (les DTOs, les mappers, Firestore). Presentation (les widgets, rien d’autre).
Les trois semaines suivantes, j’ai touché presque rien à cette structure. J’ai juste empilé des UseCase dans Domain. J’ai écrit des tests pour chacun. Et je ne me suis jamais inquiétée qu’ajouter une feature casse les autres.
Studeat est parti à la date. En production depuis.
C’est ce jour-là que j’ai compris: ce n’était pas un truc optionnel. C’était la différence entre une app que je pouvais livrer et une app dont j’aurais peur.
Ce que les cinq abribus ans d’Evolum m’ont appris
Evolum a démarré en 2018. À un moment il y a eu 12 personnes. Le coût de coordination était énorme. Vivien et moi, on a été à deux points de rupture: soit on hiérarchise tout (3 mois de réorg), soit on bricole une convention et on l’impose.
On a choisi le bricole.
Une personne posait une question: « on code ça où ? » La réponse était toujours la même: « dans Domain si c’est du métier, dans Data si c’est une source de données, dans Presentation si c’est l’UI, nulle part ailleurs ». Pas un débat. Une règle mécanique.
Et puis une année plus tard, on était à trois personnes. Et puis une personne. Et puis juste moi sur l’infra.
L’architecture avait tenu. Une personne seule peut maintenir cette app deux heures par semaine, toujours. Aucune agence ne fait ça. Aucun dev solo n’y arrive sans cette structure.
Voilà le moment où j’ai arrêté de voir l’architecture comme « un nice-to-have si on a du temps ». C’était la fondation. Tout ce qu’on construisait par dessus devait s’y appuyer.
Pourquoi tu vibe-codes avec Claude Code
Quand tu dis à une IA « ajoute cette feature », tu ne lui dis pas « crée une entité Domain, puis un UseCase, puis une DataSource, puis un Repository, puis un widget ». Tu dis « ajoute cette feature ».
L’IA va trouver le chemin le plus court. Elle va modifier où c’est le plus facile. Et si ton code est un gros bloc, ce chemin le plus court traverse trois couches d’un coup. Elle parle directement de la UI à Firestore.
Ça marche une fois. La deuxième correction, ça se croise. La troisième correction, ça casse.
C’est pour ça que j’ai écrit une architecture qui refuse de se laisser faire. Pas une bonne intention du dev. Un mur. L’import est noir sur blanc refusé par le compilateur.
Et à partir de là, mon agent IA ne peut plus faire n’importe quoi. Elle peut faire que ce qui est prévisible.
Ce que j’ai volontairement omis
J’aurais pu écrire une page sur Redux, sur Bloc, sur Riverpod. Sur la bonne pattern de state management pour chaque outil. Ça occupe 20% du travail et 80% des forums.
Je l’ai pas fait.
Ce qui tue une app, ce n’est jamais le choix du state manager. C’est qu’un jour tu veux swapper Firestore pour Supabase, et tu dois ouvrir 200 fichiers. C’est qu’un bug métier s’est propagé à l’UI et tu ne sais pas d’où ça vient.
Donc j’ai écrit la couche invisible qui empêche ces deux choses. Le reste, c’est de l’implémentation. Les outils changent tous les deux ans. L’architecture, non.
Pourquoi c’est gratuit
Pendant longtemps, j’ai livré de l’architecture comme un service. C’est 40% du coût d’une mission: poser les fondations juste. Les devs que j’ai formés, la majorité l’a jamais refait ailleurs. Ils connaissaient juste la recette que j’avais donnée.
Le coût n’était jamais vu. On voit qu’on a livré vite. On voit pas qu’on a pas livré de la dette.
Donc le calcul a changé quand j’ai compris: publier cette recette en entier — les cinq règles, les douze pièges, les cinq skills — c’est pas me cannibaliser. C’est prouver que je sais de quoi je parle. C’est investir dans une crédibilité qu’aucun pdf du marché peut acheter.
Quelqu’un lira cette page, essayera tout seul, arrivera à un piège que je décris, se demandera si ça vaut le coup de le fixer seul. C’est le moment où il m’appelle.
Et moi je peux dire: « j’ai déjà vu ce truc-là tuer trois apps. Veux que je la pose pour toi ? »
C’est pas une négociation. C’est une preuve.
Comment on la fabrique en mission
La première semaine, on découpe le code existant. On crée les trois dossiers. On déplace les imports. On configure le linter pour que tout ce qui casse compile d’erreur.
La deuxième semaine, on écrit un AGENTS.md qui dit: voilà les règles, voilà pourquoi, voilà comment ton agent IA les respecte.
La troisième semaine, l’agent code dedans. Et aucune ligne ne s’écrit hors des couches.
Et à partir de là, on la maintient. On code dedans, on la défend quand un dev junior veut faire un raccourci (ça arrive), on la change quand les outils changent (Firestore → Supabase, ça se fait), mais la structure reste.
Trois semaines au démarrage. Puis une pérennité.
C’est rare, une équipe qui vole là-dedans du premier coup. Mais c’est possible.
Ce que tu trouveras pas sur cette page
Comment la monter solo, avec un agent IA et rien que ça? Oui, c’est possible. Et c’est ce que j’ai écrit.
Mais si l’architecture tient pour une feature, elle tient pas pour dix. Les noms de fichiers se mélangent. L’ordre des couches se négocie mal. Un dev dit « ma règle c’est plus important que la vôtre ». Et c’est vrai, mais ça tue le système.
À trois devs ça devient un job. Quelqu’un doit defendre les couches. Quelqu’un doit relire les diff et dire « non, ça va pas ». Quelqu’un doit écrire le AGENTS.md et le mettre à jour.
C’est 15% du temps, chaque semaine. C’est moi. Je peux pas le déléguer à un agent IA.
Et pour ça, il faut m’appeler.
Le jour où tu auras besoin de cette page
Pas tout de suite. Aujourd’hui ça va. Ton app a trois fonctionnalités, un agent l’a montée d’un coup, c’est joli.
C’est dans six mois que c’est moche. Quelqu’un a changé un détail du métier dans un widget. Quelqu’un a ajouté une feature en touchant à trois couches à la fois. Un bug tu le fixes, deux autres cassent.
C’est là que tu t’arrêtes et tu relis cette page.
Et si ça résonne, tu sais ce qu’il faut faire.
Le résumé de marche
— Mon app se sent fragile. Un changement casse tout. Comment je sais si c’est une architecture qui manque?
Ouvre ton code. Peux-tu importer Firestore depuis ta UI sans passer par le métier? Oui. Là, c’est une architecture qui manque.
— J’ai quelques pièges. Est-ce que tout le guide me servira?
Peut-être pas. Si tu as déjà des couches et un linter, tu tiens probablement les quatre premières règles. Le reste, c’est du raffinement. Lis les pièges: tu en reconnaîtras qui te coûtent déjà.
— Et si je fais ça avec mon agent IA, ça suffit?
Ça suffit si tu es tout seul, une feature à la fois. Ça suffira cinq ans. Mais je t’aurai pas coûté cher, et tu auras besoin que de moi une fois pour que l’app respire pour de bon.
Donc lis la page. Essaie. Et si ça te sauve une nuit d’astreinte, tu sais où me trouver.
Une app qui cassait tout le temps → Une app qu’une personne maintient seule deux heures par semaine.
Voilà la matière.