Érosion architecturale due au codage rapide

1. Vue d'ensemble du concept et problème systémique

La vitesse du vibe coding crée une euphorie quasi addictive : en trois semaines, une startup livre un produit qui prenait auparavant un an de développement. Tout le monde est satisfait, les métriques sont au vert.

Mais dès le sixième mois, la gueule de bois s'installe — c'est l'Architectural Erosion (Érosion architecturale) :

• La modification d'un simple champ dans le profil utilisateur casse soudainement la génération des rapports PDF.
• On découvre que le projet contient trois méthodes distinctes de connexion à la base de données, quatre systèmes différents de validation des formulaires et cinq bibliothèques différentes pour la gestion des dates — chaque modèle, dans chaque session de chat, a utilisé ce qui lui passait par la tête.
• Le projet devient si fragile que même le modèle le plus puissant commence à se perdre dans les contradictions qu'il a lui-même créées.

2. Taxonomie architecturale et modèle mental

┌─────────────────────────────────────────────────────────────┐
│                 DYNAMIQUES D'ÉROSION ARCHITECTURALE         │
├─────────────────────────────────────────────────────────────┤
│ 1. JOUR 1 : ARCHITECTURE EN COUCHES PROPRE                  │
│    [ Couche UI ] ──► [ Service Métier ] ──► [ Repository ]  │
│    • Frontières claires, interfaces déterministes           │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ 100 Correctifs IA rapides sans   │
│                            spécifications                   │
├─────────────────────────────────────────────────────────────┤
│ 2. JOUR 180 : TOILE D'ARAGNÉE ENTROPIQUE                    │
│    • Composant UI exécutant directement des requêtes SQL    │
│    • Service métier modifiant les éléments DOM en contournant│
│      React                                                  │
│    • 14 dépendances circulaires (Circular Dependencies)     │
├─────────────────────────────────────────────────────────────┤
│                          │                                  │
│                          ▼ RÉSULTAT : GEL TOTAL DU          │
│                            DÉVELOPPEMENT                    │
│ 3. Le coût d'ajout de toute nouvelle fonctionnalité est     │
│    multiplié par 10                                         │
└─────────────────────────────────────────────────────────────┘

3. Scénarios d'ingénierie concrets en production

01. Intégration de Dependency-Cruiser dans le CI

L'équipe configure une règle automatique : "Il est interdit d'importer le module DB @/lib/db à l'intérieur des composants du dossier @/components/ui". Si l'agent tente d'écrire un "bricolage rapide", le build est immédiatement bloqué par le linter architectural.

02. Sessions hebdomadaires d'alignement architectural (Architecture Sync)

Le Tech Lead consacre deux heures chaque vendredi à inspecter le graphe global du repository via Graphify, isolant les modules qui commencent à devenir trop fortement couplés entre eux.

4. Pièges, erreurs courantes et sécurité

• L'illusion du "on réécrira proprement plus tard" : Les équipes pensent souvent : "On fait vite avec l'agent maintenant, et on fera le refactoring avant la release". Dans 99 % des cas, ce "plus tard" n'arrive jamais, et le projet meurt sous le poids de sa dette technique.
• Perte de leadership architectural : Si l'équipe ne désigne pas un propriétaire clair de l'architecture (Lead Architect), le projet devient une loterie de décisions aléatoires prises par différents modèles de langage.

5. Conclusion stratégique pour l'ingénieur de 2026

L'architecture est ce dont vous regretterez l'absence dans six mois si vous l'ignorez aujourd'hui. Les agents peuvent générer des milliers de lignes de code, mais la responsabilité de préserver l'intégrité et la simplicité du système incombe toujours à l'ingénieur.