Le vibe coding à l'épreuve de la qualité production
L'idée de laisser une IA écrire du code de qualité production suscite à la fois fascination et doutes. Certains y voient la promesse d'une productivité quasi instantanée, du code en un prompt, tandis que d'autres craignent de libérer des légions de scripts à peine lisibles et non maintenables dans leurs bases de code. En tant que praticiens ayant passé d'innombrables heures à affiner les normes du « bon » code, nous avons abordé ce débat avec un mélange de curiosité et de prudence, et une hypothèse simple à tester : une IA peut-elle construire une application non triviale à partir de zéro, sans aucune ligne écrite par nous, et produire quelque chose que des humains peuvent maintenir ?
Pour concrétiser le test, nous avons choisi de construire un System Update Planner : un outil de gestion des mises à jour logicielles et des déploiements de correctifs sur une flotte d'appareils. Il permet de définir quels paquets nécessitent une mise à jour, de planifier des déploiements progressifs par lots et de suivre l'état d'exécution jusqu'aux appareils individuels. Ni « Hello World » ni système d'entreprise massif : juste ce qu'il faut de versioning, de gestion d'états et de suivi temps réel pour évaluer de manière réaliste la qualité du code généré.
Nous avons mené trois expériences aux attentes très différentes. Dans la première, un style d'improvisation libre, ce qu'Andrej Karpathy a popularisé sous le nom de vibe coding, centré sur la fonctionnalité, sans rien exprimer de la structure attendue. Dans les autres, nous avons été bien plus délibérés : heuristiques de conception prescrites, exigences de modularité et de testabilité, qualité renforcée par une rétroaction continue. Ce contraste éclaire le rôle de l'intention humaine et de la discipline technique dans les systèmes créés par l'IA.
Définir la qualité production : critères et signaux mesurables
« Qualité production » n'est pas un terme universellement défini, et si une définition unique existait, bien des bases de code réelles peineraient à la respecter. En pratique, le terme reflète une combinaison de jugement technique, de contexte organisationnel et d'expérience concrète. Nous ne l'utilisons pas pour désigner la perfection, mais un logiciel robuste, maintenable, prêt à être déployé et à évoluer de manière responsable dans des conditions réelles.
Six critères, des signaux qualitatifs aux seuils quantitatifs
Notre grille combine six critères, chacun associé à des signaux observables et des repères chiffrés. Le comportement : les workflows clés sont vérifiés par des tests automatisés rapides, sans régression sur l'usage de base, taux de réussite proche de 100 %, score de mutation supérieur à 80 %. La testabilité : la conception supporte des tests unitaires, d'intégration et de bout en bout ciblés et isolés, couverture unitaire supérieure à 90 %, aucun test instable. La lisibilité : un code modulaire et idiomatique que d'autres peuvent modifier en sécurité, avec une complexité cognitive faible. Les exigences non fonctionnelles : performance, sécurité et robustesse opérationnelle anticipées, sans couplage excessif. La diagnosticabilité : journaux structurés et contextualisés, défaillances traçables, alertes sur les chemins critiques. Enfin, les pratiques d'ingénierie : contrôle de version, CI, analyse statique, commits fréquents et lint propre.
Ce n'est pas une liste de contrôle de la perfection, mais c'est à peu près le point de référence que nous avons en tête quand nous demandons : le vibe coding peut-il produire un logiciel de qualité production ?
Outils et configuration : IDE agentiques, modèles frontière et serveurs MCP
Nous avons principalement utilisé Cursor en mode agent, qui donne à l'IA la capacité d'exécuter des programmes en ligne de commande, d'interagir avec Git et d'exploiter des outils exposés via des serveurs Model Context Protocol (MCP), Sequential Thinking, Git, GitHub et Memory. Ce mode agentique, depuis généralisé à tout l'écosystème (agents cloud de Cursor, Claude Code d'Anthropic, et leurs équivalents chez JetBrains et Windsurf), permet à l'IA d'explorer la base de code, de lire la documentation, d'exécuter des commandes et de raisonner sur plusieurs étapes.
Côté modèles, nous avons commencé avec Claude Sonnet pour ses capacités de raisonnement, puis adopté Gemini Pro presque exclusivement, impressionnés par sa compréhension des exigences fonctionnelles et sa participation aux discussions architecturales. Les générations se succèdent vite, Claude Opus 4.8 et Sonnet 5 chez Anthropic, Gemini 3.1 Pro chez Google au moment où nous actualisons cet article, mais nos observations portent moins sur un modèle précis que sur la manière de le guider : les conclusions restent valables d'une génération à l'autre.
Trois expériences, trois niveaux de contrainte
Expérience 1 : un aperçu fonctionnel, puis liberté totale, l'IA a construit l'application de manière autonome, principalement en JavaScript. Expérience 2 : les mêmes exigences fonctionnelles, plus des règles d'implémentation strictes comme le développement piloté par les tests, l'IA a choisi TypeScript et Prisma comme ORM. Expérience 3 : serveurs MCP désactivés et style conversationnel proche d'une collaboration humaine, en encourageant l'IA à poser des questions clarifiantes, l'implémentation finale a été réalisée en Python. Pour simuler un contexte brownfield, nous démarrions de nouvelles sessions de chat : l'IA « oubliait » qu'elle avait créé la base de code, et le serveur MCP Memory n'a pas notablement atténué ce comportement.
Expérience 1 : le vibe coding pur, rapide mais fragile
Dans notre première expérience, l'approche fut entièrement mains libres : une description fonctionnelle de haut niveau, puis l'IA au volant. Le résultat initial fut impressionnant, une application presque fonctionnelle générée en une seule passe, démontrant la capacité des modèles à traduire rapidement des spécifications en code.
Les limites sont apparues dès les évolutions. Ajuster les formats de sortie, introduire un mode interactif à menus, intégrer un outil de migration de base de données, ajouter des tests : chaque changement incrémental a provoqué des régressions et exigé des interventions manuelles. C'est un constat largement documenté depuis : sans structure, le code généré vieillit mal, et la dette technique s'accumule à la vitesse de génération, les analyses de qualité de code à grande échelle mesurent d'ailleurs une hausse de la duplication et du code réécrit peu après sa création dans les dépôts fortement assistés par IA.
Il faut néanmoins reconnaître ce que cette approche change : elle abaisse radicalement les barrières à l'entrée. Des profils moins techniques prototypent des idées en autonomie, et les équipes accélèrent leurs preuves de concept. La capacité à produire rapidement un logiciel fonctionnel est une avancée réelle, à condition de ne pas la confondre avec la capacité à produire un logiciel durable.
Expérience 2 : discipline imposée, TDD, TypeScript et tests de mutation
Notre deuxième expérience a inversé la logique : discipline technique dès le départ. Attentes explicites, TDD, changements petits et incrémentaux, commits réguliers, modularité, et sécurité des types, ce qui a conduit l'IA vers TypeScript et Prisma. Les premiers résultats furent prometteurs : modèles de domaine propres, tests unitaires échafaudés, workflow trunk-based tenu avec une cohérence raisonnable. Nous avons ajouté des seuils de couverture et Stryker pour les tests de mutation ; certaines parties de la base ont atteint une couverture de mutation proche de 100 %.
Malgré des consignes répétées, l'IA régressait pourtant vers ses vieilles habitudes, écrire d'abord le code de production, adapter les tests ensuite. Ce comportement, toujours observable avec les modèles actuels, reflète vraisemblablement un biais d'entraînement : les bases de code rigoureusement test-first restent sous-représentées dans les données d'apprentissage. Le déséquilibre se lisait dans notre historique de commits, où la croissance des lignes de test traînait derrière la production jusqu'à ce que nous appliquions les vérifications de mutation.
L'incident Prisma : quand un petit changement dérape
Un incident résume le risque. Après une exécution de tests propre, nous avons demandé la suppression de quelques console.log résiduels. Un changement mineur, en théorie. S'en est suivie une cascade de modifications cassantes, de régressions de tests et, finalement, une rétrogradation spontanée et injustifiée de la dépendance Prisma de deux versions majeures. Que l'IA ait su retracer le problème jusqu'au décalage de version était impressionnant ; qu'elle l'ait introduit sans cause ni avertissement était préoccupant. La leçon tient en une phrase : plus le changement est complexe, plus les garde-fous, analyse statique, application des tests, seuils de mutation, revue humaine, sont essentiels à la fiabilité.
Expérience 3 : la collaboration conversationnelle, comme avec un pair humain
Pour la troisième expérience, nous avons changé de stratégie : plus de serveurs MCP, un seul modèle, et des conversations architecturales riches, exactement comme avec un collaborateur humain à qui l'on demande d'évaluer nos hypothèses de façon critique.
Quand l'IA pose les bonnes questions d'architecture
Le moment le plus marquant est survenu en discutant la conception des instantanés d'appareils. Plutôt que d'implémenter mécaniquement une API, l'IA a soulevé d'elle-même des questions judicieuses : les instantanés doivent-ils capturer l'état complet des paquets installés à un instant donné ? Comment traiter les divergences entre états signalés et états stockés ? La soumission d'un instantané doit-elle écraser l'état courant ou enregistrer une version historique à des fins d'audit ? Elle a proposé des conceptions d'API, débattu des compromis, chargement hâtif contre chargement paresseux, et exposé les lacunes de nos hypothèses initiales.
Ces échanges relèvent d'une véritable prévoyance architecturale, pas d'une génération mécanique. Malgré quelques incohérences résiduelles, le code produit, un système Python/FastAPI, fut le plus propre, le plus modulaire et le plus conforme aux principes REST des trois expériences. C'est aussi la préfiguration de ce que l'on appelle désormais le context engineering : la qualité de la conversation et du contexte fourni détermine directement la qualité du système produit.
Enseignements et recommandations pour les équipes en 2026
Évalués sur nos six critères, les trois exercices dessinent une hiérarchie nette : le vibe coding pur excelle en vitesse et échoue en maintenabilité ; la discipline imposée produit le code le plus vérifiable ; la collaboration conversationnelle produit la meilleure architecture. Trois enseignements transverses en ressortent. Le choix de l'outillage compte, mais la manière de le guider compte davantage. La conscience contextuelle reste limitée : même avec des serveurs MCP, chaque nouvelle session obligeait à tout réexpliquer. Et la qualité production nécessite une supervision délibérée, testabilité, maintenabilité et diagnosticabilité ne s'améliorent que lorsqu'elles sont explicitement exigées et vérifiées.
Ce que chaque rôle peut faire dès maintenant
Les développeurs doivent apprendre à guider ces outils : formuler les demandes avec des motifs architecturaux, des stratégies de test et des principes de codage, et traiter l'IA comme un binôme rapide mais inexpérimenté. Les tech leads et architectes doivent définir les garde-fous, modèles de démarrage, dépôts de référence, politiques de gouvernance du développement assisté. Les testeurs et analystes sécurité peuvent exploiter l'IA pour explorer scénarios de test, cas limites et surfaces d'attaque. Les leaders IT, enfin, doivent préparer l'organisation : nouvelles capacités, nouveaux risques, et nouveaux coûts, car les IDE agentiques fonctionnent désormais sur des systèmes de crédits mensuels que les modèles frontière épuisent rapidement à l'échelle d'une équipe.
Alors, la programmation assistée par IA peut-elle produire des logiciels de qualité production ? Pas systématiquement, pas encore. Mais l'écart se réduit à chaque génération de modèles. À mesure qu'ils progressent, un basculement se dessine : des systèmes plus petits et modulaires, tenant dans la fenêtre de contexte d'un modèle, que l'on régénère plutôt que l'on rafistole. Dans ce monde, la maintenabilité ne signifiera plus seulement écrire du code qui dure, mais écrire du code facile à remplacer. Les organisations qui investissent dès maintenant dans l'art de guider, gouverner et intégrer ces outils seront les leaders de demain. Avertissement : les déclarations et opinions exprimées dans cet article sont celles de l'auteur ou des auteurs et ne reflètent pas nécessairement les positions d'Adservio.
RÉCUPÉRER CET ARTICLE
Téléchargez l'article complet en PDF pour le lire hors ligne ou le partager.
RESTER INFORMÉ
Recevez nos prochaines analyses et retours d'expérience directement dans votre boîte mail.
