5 raisons pour lesquelles votre app meurt à 18 mois (et 5 pratiques pour 10 ans)

En 2024, j'ai assisté en consultant externe à la décision de réécrire complètement une application chez un client dans le secteur bancaire. L'app avait 22 mois. 480 000 lignes de code. Toute l'équipe d'origine était partie. Le coût de modification d'une feature simple était devenu prohibitif. Le verdict du CTO : "on repart de zéro, c'est moins cher." Cette phrase, je l'ai entendue 7 fois en 25 ans. Et à chaque fois, ce n'est pas le temps qui a tué l'application. C'est 5 choix craft qui n'avaient pas été faits.

Cet article est le compagnon de fond de la série sur le code durable. Voici les 5 raisons systémiques de la mort à 18 mois, et les 5 pratiques craft qui changent radicalement la trajectoire.

Le mythe de l'appli qui meurt parce qu'elle vieillit

On parle de "code legacy" comme si c'était une fatalité du temps. Comme si toute application atteignait fatalement un point où elle devenait impossible à maintenir. C'est faux, et c'est démontré.

Sur les 11 codebases bancaires que j'ai auditées depuis 2024, j'ai trouvé une application de 19 ans encore activement développée, lisible, modifiable, avec un onboarding nouvel-arrivant de 3 semaines. À côté, j'ai vu 4 applications de moins de 24 mois où le CTO planifiait une réécriture parce que la modification coûtait trop cher.

Le facteur âge n'est pas la variable explicative. Le facteur discipline craft l'est. Selon la classification du niveau de maturité engineering que j'utilise en mission, une équipe de niveau 3+ peut maintenir une application 10 à 15 ans sans réécriture majeure. Une équipe de niveau 1-2 voit la fatigue de codebase apparaître à 12-18 mois.

Ce que j'ai observé : dans l'équipe bancaire dont je parle en intro, j'ai fait un audit post-mortem du repo en cours de mort. Les 5 mécanismes ci-dessous étaient tous présents. Aucun n'avait été identifié pendant la vie de l'application. Tous auraient pu être évités avec une discipline craft installée dès les 3 premiers mois, en s'inspirant des principes Clean Code et software craftsmanship que je rappelle systématiquement.

Cet article s'appuie aussi sur ce que je vois revenir dans les Reels storytelling que je publie sur mon profil Instagram kamangacode. Le cas n°1 du "projet que j'ai vu mourir à 18 mois" est celui-ci. Et il est rejouable autant de fois qu'on veut. Voici comment ne plus jamais le rejouer.

Raison #1 : aucun POURQUOI tracé (et la pratique ADR)

Symptôme : à 12 mois, plus personne dans l'équipe ne sait pourquoi on a choisi cette architecture, ce framework, ce pattern. Chaque refacto devient une redécouverte du métier. Le coût n'est pas dans le code, il est dans la fouille archéologique.

Mécanisme : pendant les 3 premiers mois d'une app, les décisions architecturales sont prises rapidement, oralement, en stand-up ou en pair. Personne ne les trace. Six mois plus tard, le développeur qui a pris la décision part. Douze mois plus tard, la décision est devenue une coutume non expliquée. À 18 mois, c'est une contrainte non négociée dont plus personne ne se souvient de la raison.

Pratique craft : ADR (Architecture Decision Records). Michael Nygard a écrit en 2011 l'article fondateur "Documenting Architecture Decisions" qui propose un format ultra-minimaliste : Contexte, Options envisagées, Décision, Conséquences. 15 lignes. 30 minutes à rédiger. Versionné dans le repo comme du code.

Sur le repo crmcoaching que je maintiens depuis 6 mois, je suis à 52 ADRs. Chaque décision structurante (choix de stack, pattern, dépendance, trade-off) a sa trace. Quand je revisite une décision 4 mois plus tard, je retrouve mon raisonnement en 30 secondes. Quand un nouveau dev arrive, il lit la collection d'ADRs comme une généalogie de l'application. C'est exactement ce que recommande la pratique des ADR pour les décisions structurantes.

Sur les missions où j'installe cette discipline, le ratio ADR / 100 commits passe de 0,3 à 2,5 en 6 mois. Et le temps d'onboarding d'un nouveau dev baisse de 35% en moyenne.

Raison #2 : pas de frontières métier (et la pratique Bounded Contexts)

Symptôme : modifier 1 module touche 3 autres. Le module "facturation" appelle directement le module "stock" qui touche au module "auth". Tout dépend de tout. Aucun refacto local n'est possible. Chaque feature devient une chirurgie sur l'ensemble du corps.

Mécanisme : les premières features sont écrites vite, dans le même répertoire, avec des appels directs entre modules. Au bout de 6 mois, la matrice de dépendances ressemble à un plat de spaghettis. Au bout de 12 mois, l'équipe n'ose plus toucher au module central par peur de casser ce qu'elle ne voit pas.

Pratique craft : Bounded Contexts issus du Domain-Driven Design d'Eric Evans (2003). Chaque module a un sens métier précis et délimité. Les communications entre modules passent par des contrats explicites (events, APIs, requêtes), jamais par des appels internes croisés. C'est l'application directe de ce que le DDD décrit comme la condition de scalabilité humaine d'une codebase.

Sur le crmcoaching, j'ai défini 8 bounded contexts dès le démarrage : booking, lead, calendar, payment, notification, audit, auth, tenant. Chacun a sa frontière, son langage ubiquitaire, son équipe de fait (même si je suis seul à coder, je ne mélange jamais les responsabilités). Quand je modifie booking, je sais que payment ne sera pas affecté tant que je ne change pas le contrat d'événement entre les deux. La même logique structure l'architecture hexagonale appliquée en Java.

Cette discipline porte ses fruits à partir du 6ème mois. Avant, elle ressemble à de la sur-organisation. Après, elle ressemble à un investissement qui paie. Sur les missions où j'introduis les bounded contexts en refacto progressif, je vois le temps de modification des features baisser de 40% en moyenne sur 9 mois.

Raison #3 : tests qui testent des mocks (et la pratique AC-level coverage)

Symptôme : 87% de couverture technique affichée par le rapport SonarQube. Et pourtant, des bugs en prod toutes les semaines. Le filet de tests est dense mais inutile, parce qu'il teste des mocks plutôt que des comportements observables.

Mécanisme : Claude (et avant lui les juniors) génère des tests qui vérifient que la fonction A appelle la fonction B. Si vous changez l'implémentation pour appeler la fonction C avec le même résultat métier, le test casse, sans qu'aucun bug n'ait été introduit. C'est le pire des deux mondes : couplage fort à l'implémentation, zéro garantie de comportement, faux sentiment de sécurité.

Pratique craft : Acceptance Criteria + couverture AC-level. Dan North a posé les bases dans ses articles BDD fondateurs de 2006. Format Given/When/Then. Chaque comportement métier exprimé en langage naturel, puis instrumenté en test. L'implémentation peut changer 5 fois, le test reste valable tant que le comportement est respecté. C'est exactement la philosophie défendue dans l'adoption du Behaviour-Driven Development.

Sur le crmcoaching, j'ai 47 acceptance criteria explicites, chacun couvert par un test behavior-level. Mon ratio "tests utiles / tests totaux" est à 78%. La couverture brute est plus basse que sur un repo IA-heavy non audité (62% vs 87%), mais la couverture utile triple. Sur les missions où j'instaure cette transition, le change failure rate baisse de 50% en 4 mois. La Definition of Done bien établie est l'autre pilier de cette discipline, et elle se complète bien avec les pièges classiques des tests d'intégration sur du legacy.

Raison #4 : pas de discipline de refacto (et la pratique Strangler Fig)

Symptôme : la dette technique grossit en silence. "Plus tard" devient "jamais". Au bout de 18 mois, le module legacy fait peur à toute l'équipe. Personne ne veut le toucher. Le coût composé de la dette atteint 1,5x par an (chiffre que je vois revenir sur la majorité de mes audits).

Mécanisme : sans discipline explicite de refacto, le code se dégrade par accumulation de petits compromis. Chaque feature pressée ajoute son raccourci. Chaque deadline impose son TODO non traité. À 18 mois, la dette accumulée demanderait 3 mois de stop production pour être remboursée, ce qui est inacceptable, donc on continue, et elle continue de grossir.

Pratique craft : Strangler Fig Application (Martin Fowler, 2004). Au lieu de réécrire d'un coup, on encapsule le legacy derrière une interface, et on remplace progressivement module par module. Chaque refacto est documenté en ADR (raison #1 + raison #4 se renforcent), chaque module remplacé libère un peu d'air à l'équipe.

Sur les missions où j'installe cette discipline, je couple le Strangler Fig avec un programme de refacto approuvé business. 20% du temps équipe sur 6 mois consacré au remplacement progressif. Pas plus. Pas de "big bang refacto". Le résultat : à 12 mois, 40% du legacy est neutralisé, sans avoir mis en pause la livraison de features. C'est aussi ce que défend la Boy Scout Rule appliquée au quotidien : on laisse le code un peu plus propre que comment on l'a trouvé, à chaque PR. Ce travail s'appuie sur l'évaluation préalable du risque legacy pour prioriser correctement.

Raison #5 : tout est dans une seule tête (et la pratique Docs as code)

Symptôme : un développeur part, 30% du savoir métier part avec lui. Trois mois plus tard, l'équipe redécouvre des décisions qu'elle pensait actées. Six mois plus tard, des bugs réapparaissent parce que personne ne se souvient des contraintes initiales.

Mécanisme : pendant les 12 premiers mois, l'équipe est stable. Les développeurs portent le contexte dans leur tête. Personne ne sent le besoin de tracer. À 12-18 mois, le premier départ révèle le trou. À 24 mois, les rotations cumulées ont fait disparaître la moitié du savoir non écrit.

Pratique craft : Docs as code, artifacts vivants versionnés. Pas une documentation Confluence séparée du repo (qui pourrit en 6 mois). Une documentation dans le repo, à côté du code, mise à jour dans les mêmes PR que le code. ADRs (raison #1), README de module (raison #2), Acceptance Criteria (raison #3), playbooks d'incident, journal de décisions, etc.

Sur le crmcoaching, j'ai 280 fichiers de documentation versionnés dans le repo. Pas des pages mortes, des artifacts vivants : 52 ADRs, 47 ACs, 22 playbooks d'incident, 8 README de bounded context, 18 schemas d'architecture, etc. Le ratio docs / code est à 18% en LOC. C'est ce qui permet à un nouveau dev d'être productif en 3 semaines au lieu de 7, et c'est ce qui fait survivre le contexte aux personnes.

Cette discipline est aussi ce qui permet à une équipe de tenir l'usage massif de l'IA : Claude lit les ADRs et les contrats de bounded context comme contexte, et propose des solutions cohérentes avec l'architecture, au lieu d'inventer des patterns inadaptés. C'est le sujet de fond traité dans l'usage de l'IA pour la documentation technique, où l'IA devient un amplificateur d'écriture craft plutôt qu'un raccourci.

Synthèse : le code qui tient à 10 ans

Voici la phrase signature que j'utilise en mission, en conférence, en stand-up :

"Le code qui tient à 10 ans n'est pas le code qui marche aujourd'hui. C'est le code dont les décisions sont tracées, les frontières sont nommées, les comportements sont testés, la dette est remboursée et le savoir est partagé."

Ces 5 conditions ne sont pas optionnelles. Ce sont les 5 piliers du craft durable. Une codebase peut survivre à l'absence d'un pilier pendant 6 à 12 mois. Au-delà, elle entre en pourrissement accéléré. Avec les 5 piliers en place, elle peut tenir 10 à 15 ans, traverser 3 ou 4 rotations d'équipe, et accueillir de nouvelles features sans réécriture majeure.

Cette grille tient sur un poster A4. Je la donne à chaque équipe en fin de mission. Elle se lit en 30 secondes. Elle structure 10 ans de discipline, et elle prolonge naturellement les pratiques décrites dans comment écrire du code évolutif en développement logiciel.

Ce que ça change concrètement

Sur les 4 dernières missions où j'ai installé les 5 piliers (audit + plan en 90 jours + accompagnement 6 mois), voici les chiffres avant/après.

Le gain économique est mesurable. Une équipe de 5 développeurs qui passe de 4,2 à 1,6 jours par feature livre 2,6 fois plus de valeur pour le même coût salarial. C'est aussi le sujet que je détaille dans l'ingénierie logicielle comme avantage concurrentiel. Le craft n'est pas une dépense engineering, c'est un levier business avec ROI mesurable.

Conclusion

Ce que je veux que vous reteniez de cet article, c'est que la mort d'une application à 18 mois n'est jamais accidentelle. C'est le résultat prévisible de 5 absences de discipline que j'ai vues se rejouer 7 fois en 25 ans. Et symétriquement, la durabilité d'une application à 10 ans n'est jamais miraculeuse. C'est le résultat prévisible de 5 disciplines installées dès les 3 premiers mois.

Le bon moment pour installer ces 5 disciplines, c'était au démarrage. Le deuxième meilleur moment, c'est maintenant. Chaque mois où vous tardez, vous payez en intérêts composés. Chaque ADR que vous écrivez aujourd'hui économise 5 heures de fouille archéologique dans 18 mois. Chaque bounded context que vous définissez aujourd'hui économise 3 jours de coordination dans 12 mois. Chaque test behavior-level aujourd'hui économise un incident en prod dans 6 mois.

Si en lisant ces lignes vous reconnaissez votre situation, vous avez deux choix. Vous pouvez continuer à laisser les 5 raisons s'installer un peu plus chaque sprint. Ou vous pouvez commencer lundi matin, par 1 ADR sur la décision la plus structurante des 3 derniers mois, et bâtir la suite. La discipline craft ne vient pas d'un coup. Elle vient pratique par pratique, ADR par ADR, test par test. Et au bout de 12 mois, vous regardez en arrière et vous ne reconnaissez plus votre codebase, dans le bon sens.

Pour la suite des patterns de durabilité que je documente chaque semaine en mission, retrouvez-moi sur mon profil Instagram kamangacode.

FAQ sur le code durable et les 5 piliers craft