Lectures: 3
Résumé – Les agents IA produisent en quelques secondes un scaffold par défaut qui fige l’architecture sous l’effet du vibe coding, menaçant scalabilité, résilience et intégrité de systèmes legacy. Le code généré accumule dettes techniques, monolithe sans séparation de responsabilités, décisions implicites hors contexte et absence de non-functional requirements, exposant à des régressions et incidents critiques. Solution : adopter le vibe speccing en exigeant d’abord une spécification d’architecture (couches, modules, NFR), utiliser des playbooks de prompt et des audits automatisés pour assurer cohérence, observabilité et gouvernance durable.
Les agents IA ne se contentent plus de proposer quelques lignes de code : ils tracent d’emblée une architecture implicite. En quelques secondes, un prompt minimal suffit pour générer un scaffold complet, mais sans intention ni vision systémique.
Cette rapidité apparentée au “vibe coding” risque de figer un design par défaut, qui devient la base de vos applications en production. La question n’est plus de savoir si le code fonctionne, mais si cette architecture tiendra face à la croissance des usages, aux exigences de résilience et aux contraintes d’un environnement legacy souvent complexe.
Architecture par défaut du vibe coding
Les agents IA génèrent un squelette d’architecture sans contexte explicite. Ce “scaffold” par défaut devient la fondation de votre application, même si elle n’a pas été pensée pour durer.
Décisions implicites de l’agent
Lorsqu’un agent IA reçoit une simple consigne, il ne se contente pas d’écrire du code : il choisit un framework, organise les dossiers, et définit des flux de données. Ces décisions se basent sur des patterns génériques plutôt que sur vos besoins spécifiques, car l’agent maximise la simplicité et la cohérence du code qu’il produit.
En l’absence d’instructions précises, il privilégie le chemin le plus direct, c’est-à-dire le “happy path”. Toute condition hors norme ou cas extrême est souvent omis, renforçant ainsi l’idée d’une architecture taillée pour un MVP plutôt que pour un service enterprise.
Résultat : vous disposez d’un projet initial qui “marche”, mais qui intègre déjà des choix d’organisation et de dépendances inadaptés à une évolution modulable ou à une gouvernance stricte.
Impact sur le code initial
Le code produit par “vibe coding” a tendance à concentrer la logique métier dans des routes ou des controlleurs, sans séparation claire des responsabilités. Cette approche favorise un monolithe brut, où chaque nouvelle fonctionnalité déborde naturellement dans le même fichier.
L’absence de couches dédiées aux services, à la persistence ou à la validation des données complique les tests unitaires et l’intégration continue. Chaque refactor devient alors un chantier coûteux, car il nécessite de démêler un maillage dense de dépendances et d’effets de bord.
En pratique, la vitesse initiale se paie cash lors des premières évolutions : chaque extension ou correction devient un risque de rupture pour l’ensemble du système.
Exemple concret d’une REST API blog minimaliste
Une PME suisse du secteur financier a testé un agent IA pour générer une REST API de gestion d’articles. Le code initial regroupait routes HTTP, requêtes SQL et logique de validation dans un seul fichier. Le projet était prêt en moins de cinq minutes, mais le client a vite constaté que l’ajout d’une simple fonctionnalité de tagging brisait toute la structure.
Sans couche de service distincte ni modules dédiés à la persistance, chaque développeur intervenant risquait d’écraser une partie critique du code en ajoutant sa logique métier. L’exemple montre que le scaffold généré par l’agent tenait sur un prototype, mais pas sur un projet en production avec plusieurs équipes.
Ce cas illustre comment le vibe coding “fige” l’architecture dans une forme par défaut, sans anticiper le cycle de vie long et la collaboration en délégation multipoints.
Danger du legacy sur l’architecture
Les systèmes historiques regorgent de règles métier implicites et de dettes non documentées. Un agent optimisant localement sans contexte complet risque de casser un flux critique.
Optimisation locale vs compréhension système
Les agents sont conçus pour exceller dans des “micro-tâches” : ils identifient un problème précis et proposent une solution ciblée. Dans un écosystème legacy, chaque module est imbriqué dans un maillage d’interactions non documentées qui ne transparaissent pas dans le prompt.
Lorsque l’agent modifie un composant, il se focalise sur la fonction appelée, sans effectuer l’analyse d’impact sur l’ensemble du système. Les tests unitaires manquent souvent de couverture suffisante pour détecter ces brèches, laissant passer des régressions systémiques.
Le vrai défi du legacy n’est pas la syntaxe ou la technologie : c’est le contexte et la dynamique historique qui justifient chaque contournement et chaque dépendance.
Risques de modifications dans le legacy
Dans un contexte legacy, l’agent peut “nettoyer” ce qui lui semble du code superflu, alors que ces fragments servaient de palliatifs à des limitations techniques ou réglementaires. La suppression d’un bout de validation peut engendrer une faille de sécurité critique ou briser l’intégrité des données.
De même, l’agent peut introduire une nouvelle dépendance sans en mesurer l’impact sur les processus de déploiement existants, créant un désalignement entre les pipelines CI/CD et les exigences de conformité.
Ces modifications locales peuvent déclencher des incidents en chaîne, car chaque micro-changement déstructure un réseau de règles implicites accumulées depuis des années.
Exemple concret d’une plateforme vieille de dix ans
Un grand acteur logistique suisse exploitait une plateforme développée il y a plus de dix ans. Un prompt mal cadré a conduit un agent à remplacer un module de validation de données démographiques par une version plus performante, sans prendre en compte un script batch qui s’appuyait sur ce module pour enrichir un entrepôt de données.
Le résultat : une interface restituait des champs vides et induisait des erreurs dans les rapports de facturation. Cette panne a immobilisé plusieurs services pendant deux jours, démontrant que l’optimisation locale sans vision globale pouvait casser un workflow critique.
Cette situation met en lumière le risque systémique lorsqu’on confie des modifications de legacy à des agents sans intégrer au préalable une phase d’analyse complète.
Edana : partenaire digital stratégique en Suisse
Nous accompagnons les entreprises et les organisations dans leur transformation digitale
3 critères d’une app vibe-coded non prête
Une application “vibe-coded” manque souvent de scalabilité, de résilience et de pratiques robustes. Ces déficits indiquent une dette architecturale significative avant même le premier utilisateur à l’échelle.
Scalabilité
Un projet vibe-coded ne sépare pas toujours clairement la couche compute de la couche storage. Les requêtes restent bloquantes, sans mécanismes de cache ni stratégie de distribution de charge.
En cas d’afflux de trafic, les traitements se concentrent sur un nœud unique, entraînant des goulots d’étranglement. L’agent n’a pas anticipé l’ajout de mécanismes de pagination, de throttling ou de partitionnement des données.
Le résultat est une application qui répond de manière satisfaisante pour quelques utilisateurs, mais qui s’effondre dès qu’un pic d’usage survient.
Résilience
Les mécanismes de retry, de timeout et de circuit breaker sont souvent absents, car l’agent se concentre sur le “happy path”. Les erreurs imprévues sont gérées au mieux par un bloc try/catch basique, sans plan de secours.
En production, un appel externe défaillant peut bloquer un thread entier, provoquant l’effet domino sur d’autres requêtes. L’agent n’a pas généré de fallback ni de système de reprise différée.
Sans stratégie de résilience, une simple interruption de service externe se transforme en crash total de votre application.
Meilleures pratiques manquantes
Une app vibe-coded limite la validation des données aux simples checks d’exemple, sans construire de DTO ni appliquer de schéma unifié. La sécurité est traitée en option plutôt qu’en prérequis.
Les logs se limitent souvent à des console.log, sans structuration ni corrélation avec un trace ID. Il devient impossible de diagnostiquer rapidement l’origine d’un incident ou de suivre un flux de bout en bout.
L’absence de tests automatisés et de pipelines CI/CD robustes empêche toute montée en charge rapide et sécurisée, laissant la porte ouverte à des régressions insidieuses.
Architecture-first et boucle de contrôle
Le “vibe speccing” consiste à générer une spécification avant de lancer la production de code. Coupler cette approche avec des audits automatisés permet de mesurer et corriger la dérive architecturale en continu.
Vibe speccing avant génération
Avant de demander du code, invitez l’agent à détailler les couches, les responsabilités et les non-functional requirements. Cette spec doit inclure les modules, les interfaces et les patterns à respecter.
En exigeant explicitement des controllers, services, repositories et un schéma de validation, vous transformez le prompt en un document d’architecture officiel, prêt à être validé par vos architectes.
Cette phase de speccing limite les choix implicites de l’agent et garantit une cohérence structurelle avant même la première ligne de code.
Playbook de prompting
Rédigez des templates de prompt qui imposent les NFR : timeouts, retries, logs structurés, validation systématique et réponses JSON standardisées. Ces instructions deviennent votre cookbook interne pour chaque agent IA.
Ajoutez des exigences sur la séparation de concerns, la modularité des fichiers et l’absence de dépendances circulaires. Encouragez l’agent à documenter chaque couche générée et à fournir une arborescence de projet.
Plus votre playbook est précis, plus l’agent est capable de produire un code aligné avec vos standards et votre gouvernance IT.
Observabilité et audits automatiques
Intégrez des outils d’analyse d’architecture qui extraient la structure real-time de vos applications et détectent le coupling, les hotspot et les drift par rapport à la spec initiale.
Ces audits doivent générer des TODOs directement exploitables, listant les points de non-conformité et proposant des correctifs pour remettre votre code dans la trajectoire architecturale prévue.
En bouclant changement → mesure → correction, vous limitez la dette et assurez une industrialisation maîtrisée de vos solutions IA.
Passez du vibe coding à une gouvernance architecturale efficiente
Les agents IA accélèrent la production, mais sans garde-fous architecturaux, ils figent une structure par défaut et industrialisent la dette technique. En remplaçant le “vibe coding” par un “vibe speccing” centré sur la définition des couches, des responsabilités et des NFR, vous transformez chaque prompt en document d’architecture validé. Ajoutez à cela des audits automatisés qui mesurent la dérive et déclenchent des actions correctives, et vous obtenez un workflow agile, maîtrisé et durable.
Nos experts accompagnent les CIO, CTO et responsables SI dans la mise en place de cette démarche “architecture-first”. Ils vous aident à rédiger les prompts, à déployer les outils d’observabilité et à établir une gouvernance qui garantit performance, sécurité et évolutivité.
