Le paradoxe de l'architecture : un code rapide qui ralentit tout le système

Vous connaissez ça avec les assistants IA pour coder. Vendredi après-midi, une demande de feature arrive. Lundi matin, c'est implémenté, testé, PR prêt. Le business jubile, et c'est déployé avant le déjeuner.

Trois mois plus tard, vous traquez un bug monstre que personne n'avait vu venir.

Le piège de la vitesse

Ces dernières années, coder est devenu bon marché, pas l'architecture.

Avec GitHub Copilot, Claude ou des frameworks qui masquent le boilerplate, on produit du code fonctionnel à une allure folle. Les libs de composants, outils internes et approches "vibe coding" fluidifient tout : proto, ship, repeat.

C'est top. On expérimente plus vite, on apprend plus vite. Les équipes agiles gagnent un vrai avantage.

Mais ce rythme cache un coût sournois.

L'architecture a disparu où ?

Du code qui marche, ce n'est pas du code qui s'intègre bien. Une feature passe ses tests et reste une bombe :

• Logique dupliquée au lieu d'être partagée
• Responsabilités floues éparpillées dans les fichiers
• Patterns incohérents qui embrouillent le codebase
• Failles sécurité oubliées dans la course à la livraison
• Frontières foireuses OK au début, dramatiques à l'échelle
• Composants uniques qui méritaient un pattern réutilisable
• Features incrustées impossibles à virer sans casse

Pire : quand ça pète, le code est déjà mergé, shippé, et protégé par la business logic.

Le goulot pre-merge

Solution facile : durcir les code reviews. Architects et seniors valident tout PR. On stoppe les problèmes avant entrée.

Sur le papier, nickel. Dans les faits ? PRs en attente des jours. Débats post-code (plus durs à changer). Devs frustrés qui refont tout après un ship réussi. Et la file de PR qui tue les gains de vitesse.

La review devient flic, pas outil qualité.

Un modèle supérieur : l'architecture continue

Pas besoin de ralentir les reviews. Il faut décaler les décisions architecturales.

Les bonnes équipes misent sur des boucles de feedback post-merge explicites :

Review système : Après landing, zoom out. Ce changement crée-t-il des patterns à dupliquer ? Violemont-il nos frontières clés ?

Éval réutilisation : Duplication à consolider ? Pattern émergent à extraire ?

Checks sécurité et hypothèses : Code réel en main, nos assomptions tiennent-elles ? Edges cases manquants ?

Planif refactor : "Refactor plus tard" ne marche que si c'est calé. Traiter le refactor comme une tâche prioritaire garde le système sain.

Feature flags et reversibilité : Shipper derrière flags. Rendre désactivable facile. Anticiper un rewrite futur dès le départ.

Leçon clé : l'architecture est continue, pas un portillon.

Rendre "refactor later" concret

Ça ne vole que si c'est un vrai engagement.

Les équipes qui codent vite sans trash leur archi partagent ça :

• Budget temps dédié à l'architecture (pas en rab d'un sprint)
• Mesurent santé système + vitesse features
• Stoppent et réécrivent quand la dette explose
• Architects en post-merge, pas que pre-merge
• Déploys rapides pour que refactor ne soit pas risqué

La vraie question

Où placer l'architecture ?

Partout, mais au bon moment.

Elle se décide en discussions design (avant code). En code review (pour les évidences). Mais aussi post-merge, en refactors, redesigns système, et pauses stratégiques : "Ça marche, mais on peut mieux faire."

Les outils dev rapides ne sont pas le souci. Le défi : équipes et process qui suivent ce rythme sans flinguer la solidité.

Si vous chassez encore toute archi en comments PR, vous luttez contre la physique. Le moteur code va plus vite que la review.

Upgradez les deux.

Et chez vous ? Architecture pre-merge, post-merge, ou mix ? Ça dit beaucoup sur la durabilité de votre vitesse.