Le vibe coding ne peut pas servir d’excuse pour un travail de mauvaise qualité
(addyo.substack.com)- Le vibe coding basé sur l’IA est innovant, mais cet article avertit qu’aller vite sans qualité est dangereux
> « Avancez plus vite, cassez-en davantage »
> « le vibe coding, cette façon pour deux ingénieurs de créer la dette technique de 50 personnes » - Cette reformulation détournée d’un vieux slogan de la Silicon Valley circule récemment dans la communauté de l’ingénierie sous le concept de « vibe coding »
- Il est vrai que le développement assisté par l’IA révolutionne la manière de produire du logiciel, mais cela ne donne pas pour autant licence d’abandonner la rigueur, la revue et le savoir-faire
- Le « vibe coding » ne peut pas servir de prétexte pour justifier un travail de faible qualité
- Pour lui reconnaître ses avantages, le codage assisté par l’IA peut être un game changer
- Il abaisse la barrière d’entrée pour les nouveaux programmeurs et les non-spécialistes, en leur permettant de créer des logiciels fonctionnels simplement en décrivant leurs besoins
- Cela libère la créativité et permet à davantage de personnes de résoudre directement leurs problèmes avec des logiciels sur mesure
- Cette dynamique est considérée comme faisant partie de la tendance au dégroupage du logiciel personnel (utiliser de petits outils basés sur l’IA au lieu d’apps prêtes à l’emploi)
- Les ingénieurs expérimentés peuvent eux aussi en tirer profit
- Mais comme le dirait n’importe quel ingénieur chevronné, la vitesse ne vaut rien si les roues se détachent à l’arrivée
- Et c’est précisément là que les fissures commencent à apparaître — l’écart entre la vibe et la réalité, autrement dit la différence entre l’impression et les exigences réelles de la construction d’un logiciel maintenable et robuste
La vérité inconfortable : la qualité ne suit pas automatiquement
- Le hype est fort, mais le scepticisme des développeurs vétérans envers le vibe coding l’est tout autant
- La critique centrale est simple : ce n’est pas parce que l’IA produit du code rapidement que ce code est bon
- En réalité, faire confiance tel quel à du code généré par l’IA et l’utiliser peut être assez risqué
- La blague selon laquelle « deux ingénieurs produisent la dette technique de 50 personnes » n’est pas totalement une blague
- Du code IA non revu peut faire exploser la dette technique à grande échelle
→ Cette dette rend le code fragile et difficile à maintenir, et entraîne des coûts importants sur le long terme
- Les projets créés en vibe coding ont souvent l’air excellents en surface (« Ça marche bien, on déploie ! »)
- Mais en réalité, ils dissimulent souvent les risques suivants :
- absence de gestion des erreurs
- performances médiocres
- mécanismes de sécurité fragiles
- structure logique faible et cassante
- Ce genre de projet ressemble à une construction bâtie sur du sable,
- ou, comme je l’appelle, à du « house of cards code » —
cela semble fini en apparence, mais s’effondre facilement sous des contraintes réalistes - Si vous avez déjà vu la première grosse fonctionnalité d’un développeur junior presque fonctionner, avant de casser immédiatement sur une entrée imprévue, vous voyez l’idée
- L’IA peut produire rapidement de grandes quantités de code, mais la quantité ne signifie pas la qualité
- « L’IA, c’est comme un développeur junior extrêmement enthousiaste qui a rejoint l’équipe. »
- → Cette idée est bien illustrée par un dessin de Forrest Brazeal
- Ce risque n’est pas une simple hypothèse : du point de vue de la maintenance aussi, le problème est bien réel
- Si un module produit par l’IA est trop complexe ou difficile à comprendre, qui va en assurer la maintenance ?
- Si même le développeur qui l’a initialement produit ne comprend pas totalement le code généré par l’IA,
ce code peut devenir un cauchemar pour les futures modifications ou extensions
- La sécurité est un autre problème majeur
- L’IA peut générer du code qui semble bien fonctionner, tout en cachant des vulnérabilités critiques comme l’injection SQL
- Ou bien elle peut laisser une gestion des erreurs insuffisante
- Si ces problèmes sont déployés en production sans revue approfondie, ils peuvent conduire à de vrais incidents
- Un autre problème est le surapprentissage au prompt (overfitting to the prompt)
→ L’IA fait exactement ce que vous demandez, mais cela peut être différent de ce dont vous avez réellement besoin - Un développeur humain repère souvent des erreurs de conception ou des malentendus pendant l’implémentation et les corrige
- À l’inverse, l’IA ne perçoit pas du tout ces malentendus, et si personne ne les détecte et ne les corrige, le problème reste en place
- Bien sûr, tout cela ne signifie pas que l’IA est incapable d’écrire du bon code —
- L’IA produit parfois d’excellent code
- Mais pour juger si ce code peut réellement être utilisé, trois choses restent indispensables :
- le contexte (context)
- l’examen critique (scrutiny)
- l’expérience et l’expertise (expertise)
- En 2025, l’IA que nous utilisons ressemble à un assistant débordant d’enthousiasme mais manquant d’expérience
- De la même manière qu’on ne confierait pas l’architecture d’un système entier à un développeur débutant sans supervision,
le code de l’IA ne doit pas non plus être accepté sans revue - Les attentes autour de la « magie de l’IA » doivent désormais s’accorder avec la réalité de l’ingénierie logicielle
- Alors, comment trouver le bon équilibre ?
- L’important est qu’il n’est pas nécessaire de rejeter totalement le vibe coding
- Le vibe coding peut parfois être très utile
- Mais l’essentiel est de l’intégrer de manière disciplinée — autrement dit, considérer l’IA comme un outil aux limites bien définies
- Cela signifie que l’humain doit rester dans la boucle, et que nous devons utiliser l’IA d’une manière qui respecte nos standards de qualité et nos principes d’ingénierie
L’IA n’est pas un remplaçant, c’est un stagiaire (l’humain doit rester dans la boucle)
- Pour utiliser efficacement le vibe coding, il faut adopter un changement d’état d’esprit : traiter l’IA comme « le stagiaire développeur de l’équipe, très rapide mais encore immature »
- Autrement dit, vous — ingénieur senior ou lead d’équipe — restez le responsable final du résultat
- L’IA peut produire rapidement un premier jet, mais il faut le relire avec un regard critique, le corriger et vérifier qu’il respecte les standards de qualité
- Les développeurs expérimentés suivent ce processus presque instinctivement
- Quand l’IA propose du code, ils ne cliquent pas simplement sur « Accept » avant de passer à autre chose ; ils réagissent plutôt ainsi :
- lire et comprendre d’abord le code rédigé par l’IA — en le traitant comme du code écrit par un développeur junior
- modulariser et refactorer si le code est monolithique ou désordonné — en le découpant en unités plus petites et plus claires
- ajouter eux-mêmes les exceptions ou edge cases manquants — comme les vérifications de
null, la validation des entrées, etc., que l’IA oublie souvent - renforcer les types trop lâches ou les abstractions incomplètes — en transformant des hypothèses implicites en contrats explicites
- évaluer si l’architecture ou l’approche choisie par l’IA est inefficace — par exemple un traitement en force brute ou l’introduction d’un état global
- écrire des tests ou effectuer des tests manuels — si l’IA a généré des tests unitaires, il faut aussi vérifier qu’ils sont pertinents
-
À travers tout ce processus, on injecte dans le code produit par l’IA la sagesse de l’ingénierie (wisdom)
-
Cette combinaison peut être extrêmement puissante — l’IA apporte la vitesse, l’humain garantit la fiabilité
-
D’ailleurs, selon la recherche et l’expérience de terrain, les développeurs seniors tirent davantage de valeur des outils de coding IA que les juniors
-
La raison est simple : les seniors ont les connaissances et l’expérience pour bien guider la sortie de l’IA et corriger ses erreurs
-
À l’inverse, les juniors risquent davantage de prendre l’IA à tort pour une autorité absolue
- D’où une règle importante :
→ tout code écrit par l’IA doit impérativement être relu avant intégration - Comme pour la revue de la PR d’un développeur débutant, il faut lire chaque ligne et ne merger qu’une fois l’ensemble parfaitement compris
- Ne partez pas du principe que l’IA est plus intelligente — dans la plupart des cas, ce n’est pas le cas
- Si une partie n’est pas claire :
- il vaut mieux reformuler le prompt pour demander plus explicitement, ou
- réécrire soi-même le code concerné
- La sortie de l’IA n’est qu’un “brouillon” et doit toujours passer par une revue
- En environnement d’équipe :
- si quelqu’un a utilisé l’IA pour produire du code,
- cette personne doit être capable de l’expliquer et de le défendre elle-même en revue
- « Ça marche, c’est tout » ne suffit pas — un vrai code est un code que des humains comprennent et peuvent maintenir
- Un autre bon exemple : la conception pour l’humain, l’implémentation pour l’IA
- Autrement dit, l’IA sert à implémenter rapidement des tâches déjà bien définies comme une API CRUD
- En revanche, une demande du type « conçois-moi une architecture de microservices scalable » doit rester du ressort humain
- La conception de haut niveau et les décisions clés doivent rester entre les mains des humains
- En résumé : confions à l’IA le travail répétitif (grunt work), et aux humains la réflexion et le jugement (brain work)
- La communication et la documentation deviennent elles aussi cruciales
- Si vous avez demandé à l’IA de produire un algorithme complexe ou d’utiliser une bibliothèque peu familière,
- il faut absolument documenter les raisons et l’intention de ce choix
- les futurs mainteneurs — ou votre futur vous — doivent pouvoir comprendre pourquoi ce code a été écrit de cette façon
- Certaines équipes vont même jusqu’à consigner les prompts eux-mêmes utilisés pour générer du code important avec l’IA
→ utile en débogage, car cela permet de se référer à l’« historique de conversation » avec l’IA
- En conclusion, l’intervention humaine n’est pas une option, mais une nécessité
- Utiliser uniquement du code généré par l’IA sans intervention humaine, c’est jouer la qualité logicielle aux dés
- Nous ne sommes pas encore à une époque où l’IA peut remplacer la compréhension globale d’un ingénieur senior
- Le vibe coding doit être un partenariat —
→ l’IA peut donner de la vitesse, et l’humain joue le rôle de la ceinture de sécurité
Règles pratiques pour un vibe coding de haute qualité
- Résumons maintenant la discussion en règles concrètes et bonnes pratiques actionnables
- On peut y voir une sorte de manuel de la nouvelle époque : « avancer vite, sans tout casser »
- Ce sont des règles qui servent de garde-fous pour préserver la qualité tout en faisant du vibe coding
- Règle 1: Always Review AI-Generated Code / Toujours relire le code généré par l’IA
- Aucune exception. Tout code produit par l’IA doit être relu comme s’il avait été écrit par un développeur junior
- Qu’il s’agisse d’une relecture individuelle ou d’une peer review, elle doit toujours avoir lieu
- Cela vaut pour Copilot, ChatGPT, Cursor ou n’importe quelle autre IA
- Si vous n’avez pas le temps de relire ce code, vous n’avez pas non plus le temps de l’utiliser
- Fusionner du code IA sans relecture revient à accepter le risque tel quel
- Règle 2: Establish Coding Standards and Follow Them / Définir des standards de code et les respecter
- L’IA reflète les styles de code sur lesquels elle a appris ; sans standards d’équipe cohérents, la qualité devient irrégulière
- Il faut définir clairement le guide de style, les patterns d’architecture et les règles de codage de l’équipe
- Exemple : « toute fonction doit avoir du JSDoc et des tests unitaires » → cela s’applique aussi au code généré par l’IA
- Dans les projets avec hiérarchie stricte ou architecture en couches,
il faut refactorer pour éviter que l’IA n’insère des appels DB dans le code UI - Il est recommandé d’introduire des règles de lint ou d’analyse statique pour détecter les erreurs fréquentes de l’IA (ex. : fonctions trop complexes, usage d’API deprecated, etc.)
- Règle 3: Use AI for Acceleration, Not Autopilot / L’IA est un accélérateur, pas un pilote automatique
- Le vibe coding doit servir à traiter rapidement des tâches que l’on maîtrise déjà bien
- Bons cas d’usage :
- génération de boilerplate
- scaffolding de composants
- traduction entre langages
- rédaction de l’ossature d’un algorithme simple
- Cas d’usage risqués :
- lui faire concevoir un module entier à partir d’une description vague
- tenter de générer du code dans un domaine que l’on maîtrise mal
- Si le code est destiné à rester durablement, il faut absolument passer du mode vibe au mode engineering
- Règle 4: Test, Test, Test / Il faut tester, systématiquement
- Ce n’est pas parce que l’IA a généré du code qu’il est automatiquement correct
- Il faut écrire des tests pour tous les parcours principaux
- Si l’IA a aussi généré les tests, il faut vérifier qu’ils sont réellement pertinents
- En particulier pour les fonctionnalités UI ou les zones riches en saisies utilisateur, il faut cliquer soi-même et tester les entrées anormales
- Les applications vibe-coded fonctionnent souvent bien sur le happy path, mais sont fragiles face aux entrées exceptionnelles
- Règle 5: Iterate and Refine / Itérer et affiner
- Si le premier résultat fourni par l’IA n’est pas satisfaisant, ne passez pas simplement à autre chose : réessayez ou refactorez
- Le vibe coding est un processus itératif fondé sur le dialogue
- Par exemple :
- « rends ce code plus concis »
- « découpe-le en petites fonctions », etc., en ajustant le prompt
- Ou bien : refactorisation manuelle → identification des points à corriger → nouveau prompt → répétition
- Une stratégie fondée sur des cycles avec l’IA est efficace
- Règle 6: Know When to Say No / Il faut savoir dire non
- Le vibe coding n’est pas toujours la meilleure option
- Quand l’enjeu de conception ou de sécurité est important, mieux vaut écrire soi-même
- Exemple :
- concevoir soi-même un module lié à la sécurité, puis n’utiliser l’IA que partiellement
- si l’IA complique une question simple, coder directement est plus rapide
- Quand l’IA ne résout pas correctement le problème, il ne faut pas s’entêter et il faut repasser en mode manuel
- « Parce que c’est l’IA qui l’a fait » n’est pas une excuse pour ne pas comprendre son propre code
- Règle 7: Document and Share Knowledge / Documenter et partager les connaissances
- Le code généré par l’IA doit être documenté autant que du code écrit à la main (et parfois davantage)
- S’il y a des décisions peu intuitives ou des implémentations inhabituelles, il faut laisser des commentaires
- Il faut indiquer clairement à l’équipe quelles parties ont été générées par l’IA
- Certaines équipes conservent tels quels les prompts utilisés pour le code IA important → utile pour le débogage
- En suivant ces règles, les équipes peuvent tirer le meilleur de la productivité du vibe coding tout en réduisant les risques au minimum
- L’essentiel est que l’IA ne remplace pas l’humain, mais le complète
- L’IA accélère les tâches répétitives, tandis que l’humain apporte esprit critique et créativité
- Nous vivons à l’ère de la co-création de code avec l’IA
Quand le vibe coding fonctionne bien vs quand il s’effondre
- Il est aussi important de bien savoir où le vibe coding excelle, et où ce n’est pas le cas
- Tous les projets ou toutes les tâches ne se prêtent pas de la même manière à un workflow fondé sur l’IA
- Voici ci-dessous une distinction des cas d’usage, synthétisée à partir d’expériences et d’exemples du secteur
- 👍 Situations où cela fonctionne bien (Great Use Cases)
- Rapid prototyping (prototypage rapide)
→ le sweet spot du vibe coding. Quand il s’agit d’une petite app ou d’une idée de fonctionnalité
→ on peut utiliser un assistant IA pour créer rapidement une preuve de concept ou un prototype
→ peu importe si le code est un peu brouillon — l’essentiel, c’est la validation de l’idée
→ on voit déjà de nombreux cas où des apps sont créées uniquement avec de l’IA pour des projets de week-end afin de tester un concept - One-off scripts / Internal tools (scripts ponctuels, outils internes)
→ parsing de fichiers logs, automatisation de tâches personnelles, dashboards internes, etc.
→ dans des environnements où le risque reste limité en cas d’échec, le vibe coding permet effectivement de gagner du temps
→ quand une qualité de niveau production n’est pas nécessaire, on peut rapidement fabriquer « quelque chose qui marche tout de suite » - Learning and exploration (apprentissage et exploration)
→ quand on apprend un nouveau langage ou une nouvelle API, on peut demander à l’IA de générer des exemples
→ même si le code n’est pas parfait, il reste largement suffisant comme support d’apprentissage
→ c’est un peu comme avoir un TA virtuel qui montre différentes approches, que l’humain affine ensuite - Boilerplate-heavy tasks (tâches riches en boilerplate)
→ par exemple : générer 10 classes de données similaires, implémenter du CRUD
→ tant que la structure est claire, l’IA suit correctement les patterns répétitifs
→ cela permet d’expédier rapidement les tâches mécaniques, pendant que l’humain se concentre sur l’essentiel
- Rapid prototyping (prototypage rapide)
- 👎 Situations où cela pose problème (Not-So-Great Use Cases)
- Enterprise software / Complex systems (logiciels de niveau enterprise, systèmes complexes)
→ des systèmes avec logique métier complexe, concurrence, sécurité et exigences de conformité
→ l’IA ne connaît pas ces contraintes si on ne les lui explique pas explicitement, et même si elle les connaît, elle peut mal les intégrer
→ par exemple : des systèmes de paiement fintech, des logiciels de contrôle aérospatial, etc. ne doivent jamais être confiés à l’IA seule
→ dans ce type d’environnement, elle ne peut servir qu’en appui, et la qualité finale exige impérativement la QA et l’expertise humaines - Long-term maintainability (maintenabilité à long terme)
→ pour une codebase destinée à durer des années, la structure compte dès le départ
→ le code bricolé à coups d’IA tend à manquer de cohérence, ce qui alourdit fortement la maintenance par la suite
→ mieux vaut investir du temps dès le début pour définir un framework et une conception clairs
→ beaucoup d’utilisateurs précoces racontent que le temps gagné grâce au vibe coding
est ensuite entièrement reperdu en refactoring et en remise en ordre - Critical algorithms / Optimizations (algorithmes critiques ou travail d’optimisation)
→ par exemple : gestion mémoire personnalisée, algorithmes de tri ultra-rapides, etc.
→ l’IA peut s’en sortir sur de petites entrées, mais elle prend mal en compte les questions de passage à l’échelle
→ cela peut devenir lent ou se mettre à mal fonctionner sans avertissement
→ dans ces cas, la créativité et la profondeur de compréhension humaines restent indispensables - Explainability and clarity (clarté et explicabilité)
→ dans les situations où le code doit être clairement lisible pour d’autres développeurs ou des auditeurs
→ si l’IA sur-abstrait ou adopte une approche inutilement complexe, la lisibilité et la maintenabilité se dégradent fortement
→ aujourd’hui, l’IA ne vise pas toujours « un code court et concis » → elle devient parfois trop verbeuse ou abstrait inutilement
→ dans ces cas-là, un refactoring humain et une écriture de code plus claire sont nécessaires
- Enterprise software / Complex systems (logiciels de niveau enterprise, systèmes complexes)
- En résumé, le vibe coding est un puissant outil d’accélération, mais pas une solution miracle universelle
- il est très efficace quand la vitesse compte et que le résultat peut être retouché plusieurs fois
- en revanche, confier d’un seul coup un logiciel mission-critical à l’IA est une démarche risquée
- pour prendre une image : c’est comme confier un bus scolaire à un pilote de course — bon outil, mauvais usage
- Peut-être qu’un jour l’IA deviendra l’outil de base de tout développement, mais ce n’est pas le cas aujourd’hui
- Aujourd’hui, ce que nous devons faire, c’est utiliser l’IA sur les bons problèmes, de la bonne manière et avec le bon niveau de responsabilité
Conclusion : vibez avec prudence — profitez de la vitesse sans perdre le sens de l’artisanat
- le vibe coding et le développement logiciel piloté par l’IA représentent un bond immense dans l’évolution des outils
- ce mouvement n’est pas une mode passagère, mais une réalité désormais installée, qui va encore se raffiner
- une équipe d’ingénierie tournée vers l’avenir ne peut pas se permettre de l’ignorer
- tout comme les anciens outils d’automatisation ou les frameworks avancés ont dépassé les méthodes de développement précédentes,
les équipes qui savent bien exploiter l’IA ont de fortes chances de surpasser celles qui ne le font pas - le message de cet article n’est pas qu’il faut rejeter le vibe coding —
→ mais qu’il faut l’aborder les yeux ouverts, sans abandonner les fondamentaux de l’ingénierie
- La leçon la plus importante : la vitesse ne vaut rien sans la qualité
- Déployer rapidement un code plein de bugs et impossible à maintenir, c’est simplement foncer vers le précipice
- Les meilleurs développeurs sont ceux qui utilisent l’IA pour aller plus vite sans faire s’effondrer le système
- L’IA fait le gros du travail, et l’humain vérifie que tout tient correctement debout
- Trouver ce point d’équilibre (sweet spot) est l’essentiel
- Points d’action pour les responsables techniques et les managers :
→ il faut ancrer dans l’équipe une culture où l’IA est un outil à utiliser avec responsabilité- encourager le vibe coding, mais aussi définir des attentes et des règles claires pour protéger la codebase
- le code généré par l’IA doit lui aussi systématiquement passer en code review,
- et instaurer une culture où la question « tu comprends ce code ? » est naturelle
- investir dans la montée en compétence de toute l’équipe pour collaborer efficacement avec l’IA
- en introduisant de nouvelles compétences comme l’art d’écrire de bons prompts ou d’évaluer les suggestions de l’IA
- c’est un changement de paradigme comparable au passage aux langages de haut niveau ou à l’adoption de Git
→ les équipes qui s’adaptent vite en tireront un avantage
- Ce qui compte vraiment en ingénierie logicielle reste toujours le même :
- résoudre les problèmes des utilisateurs
- construire des systèmes fiables
- continuer à apprendre
- le vibe coding est un moyen, pas une fin
- si cela permet d’apporter plus vite une meilleure valeur aux utilisateurs, c’est un excellent outil
- mais si, au passage, cela nous pousse à sacrifier la qualité et la sécurité auxquelles nous devons croire, il faut s’en abstenir
- Le fond reste inchangé :
→ pensée claire, compréhension des exigences, conception préparée au changement, tests rigoureux
- Enfin, gardons cet état d’esprit :
→ « allez vite, mais ne cassez rien — et si vous cassez quelque chose, assurez-vous au moins de pouvoir le réparer. » - écrivons du code rapidement, mais sur une base d’ingénierie solide
- l’IA peut être un puissant ciseau dans les mains d’un artisan
→ mais c’est toujours la main humaine qui manie ce ciseau
- Alors, développeurs, vibez — mais vibez avec prudence
- accueillons l’avenir sans lâcher les principes fondamentaux qui nous ont menés jusqu’ici
- le vibe coding n’est pas une excuse pour justifier une mauvaise qualité,
→ mais une occasion de montrer tout ce que nous pouvons construire de plus grand lorsque le jugement humain et la capacité générative des machines se combinent
- les équipes qui intérioriseront ce principe ne feront pas que devenir plus rapides,
→ elles construiront des logiciels qui méritent de durer
Happy coding — et vibe élevé, qualité encore plus élevée.
3 commentaires
+1
Je suis d'accord.
Attention, très long.
Avis Hacker News
Redéfinition de ce que signifie « vibe coding »
Le battage autour du code généré par l’IA a tellement enflé qu’il semble impossible à satisfaire dans la réalité
Cela rappelle l’époque, au début des années 2000, où les grandes entreprises essayaient d’externaliser le développement vers des pays à bas revenus
Traiter l’IA comme un développeur junior de l’équipe peut faire perdre davantage de temps
Cela dépend des cas d’usage
Il existe différentes conceptions de la qualité logicielle
Une question se pose sur l’impact négatif éventuel du code assisté par IA sur la progression des développeurs
Le vibe coding permet d’évaluer la difficulté d’un travail
Les gens ont tendance à vouloir économiser leur énergie, et le vibe coding rend possible un développement à faible effort
L’article entier donne l’impression de broder autour de la phrase : « un humain doit relire du vibe code avant son déploiement en production »