Le code généré par IA n'a pas sa place en production sans garde-fous
Demandez à une IA générative (une intelligence artificielle capable de produire du texte ou du code à partir d'une simple consigne) de fabriquer une application, et vous obtenez en quelques heures quelque chose qui tourne. La pratique a un nom, le « vibe coding » : on décrit ce qu'on veut à l'IA, on garde ce qu'elle écrit, sans forcément relire ni comprendre le détail du code.
Cette vitesse est trompeuse. Un logiciel en production, c'est-à-dire utilisé pour de vrai par des clients ou des collaborateurs, n'est pas un prototype qu'on aurait prolongé. C'est un bien de l'entreprise, qui engage sa sécurité, la continuité de son service et, au bout du compte, sa crédibilité. Ce que la vitesse cache se paie presque toujours au même moment : le premier incident en production, rarement avant.
Ce qui arrive quand personne ne cadre le code généré
Quand du code écrit par une IA arrive en production sans relecture ni règles de construction, on retrouve régulièrement les mêmes symptômes.
L'architecture, c'est-à-dire la façon dont le logiciel est construit, s'est faite au fil de l'eau. Le code fonctionne, mais personne dans l'équipe ne sait dire pourquoi il est structuré ainsi plutôt qu'autrement. Toute évolution devient risquée.
La dette technique s'accumule sans se voir. Ce sont les raccourcis pris aujourd'hui qui coûteront demain, comme un entretien de voiture reporté. Elle reste invisible tant que le système n'est pas mis sous tension : pic de fréquentation, changement d'un composant, incident de sécurité.
Enfin, l'entreprise dépend d'un système que plus personne ne comprend vraiment. Le code généré à la volée est rarement documenté. La seule personne capable de l'expliquer est parfois celle qui a rédigé la consigne à l'IA (le « prompt »), pas celle qui devra le maintenir.
J'ai vu la question se poser lors d'une mission de « CIO fractionné » (directeur informatique à temps partiel) pour une startup SaaS en phase d'amorçage. Une startup SaaS vend un logiciel en ligne par abonnement, et l'amorçage désigne ses tout premiers mois de vie. On a proposé de recourir au vibe coding pour accélérer certains développements. J'ai mis mon veto, à cause du risque au moment de grandir : une architecture assemblée sans relecture devient un frein le jour où l'entreprise doit vraiment monter en charge, recruter une équipe technique, ouvrir son code à d'autres ou faire évoluer un produit que plus personne ne sait expliquer en détail. Refuser cette vitesse de façade au tout début, quand la tentation est la plus forte faute de moyens, est ce qui permet ensuite de grandir sans tout reconstruire.
L'IA accélère, elle ne remplace pas l'ingénieur
Le risque ne s'arrête pas au code. Recruter ou former des personnes dont la seule valeur est de bien formuler des demandes à une IA, sans compétence d'architecture derrière, fragilise l'organisation à moyen terme : elle dépend d'un outil sans avoir en interne de quoi juger ce qu'il produit. Accepter des livrables générés de façon opaque, sans règle du jeu explicite, expose à des risques que personne n'a mesurés.
L'IA générative garde toute sa place dans un cycle de développement bien encadré. Mais l'architecture, la sécurité et la durée de vie d'un système restent des responsabilités humaines. On peut déléguer la vitesse d'exécution à un outil, pas la maîtrise de ce qu'il produit.
Les garde-fous minimums
Pour qu'un code généré par une IA puisse raisonnablement partir en production, quelques garde-fous suffisent.
- Relire l'architecture avant chaque mise en production, quelle que soit la vitesse à laquelle le code a été écrit.
- Exiger une documentation qui explique pourquoi le système est construit ainsi, pas seulement ce qu'il fait.
- Avoir quelqu'un de compétent, en interne ou en renfort, capable d'auditer ce que l'outil a produit, au lieu de vérifier seulement que ça marche le jour du test.
Ces garde-fous ne ralentissent presque pas un projet bien mené. Ils évitent de découvrir la facture quand elle coûte le plus cher : en production, sous tension, sans personne pour expliquer pourquoi le système se comporte ainsi.
Un chantier similaire chez vous ?
Décrivez votre contexte, nous verrons ensemble par où commencer.
Parlons-en