2026 : une odyssée de l’IA — Conséquences du vibe coding

En 2025, le « vibe coding » est devenu un véritable flux de travail, pour le meilleur comme pour le pire : je décrivais ce que je voulais, j’acceptais ce que le modèle produisait, je recopiais l’erreur suivante et je recommençais. Le code « fonctionnait », mais je ne l’avais souvent ni lu ni compris (surtout dans un langage que je maîtrise mal).

Le terme « vibe coding » a été forgé par Andrej Karpathy dans un billet viral décrivant un mode où l’on « oublie même que le code existe . Simon Willison a ensuite proposé la définition la plus utilisable par les équipes dans les règles internes et en revue de code : le vibe coding consiste à « générer du code avec l’IA sans se soucier du code produit ».

Cette attitude peut être rationnelle pour des prototypes et des outils ponctuels. Pensez à de petits modules en boîte noire qui exécutent des tâches simples et semblent le faire correctement - le « j’ai juste besoin que ça fasse ce truc », acceptable pour les makers et les amateurs.

Les problèmes apparaissent lorsque ces artefacts « jetables » deviennent des dépendances, des fonctions génératrices de revenus ou des firmwares embarqués à maintenir, auditer et sécuriser pendant des années. Si 2025 a été l’année où tout le monde a livré plus vite, 2026 est celle où beaucoup d’équipes découvrent ce qu’elles ont livré.
 

Ce que signifie le « vibe coding » (et ce que ce n’est pas)

Beaucoup d’ingénieurs ont utilisé l’IA en 2025 sans faire du vibe coding : génération de code standard, rédaction de tests, explication d’API nouvelles ou première version ensuite passée en revue. C’est simplement du développement assisté par l’IA.

Le vibe coding est le mode où personne n’est responsable du fonctionnement interne. On quitte alors l’outil à la démarche. Traite-t-on la sortie de l’IA comme du code non fiable devant passer revue, tests et contrôles de sécurité comme toute contribution externe ? Ou comme un raccourci qui s’en affranchit ?

En pratique, les équipes y glissent par petites décisions raisonnables : un script rapide ici, une couche d’intégration là, une automatisation « temporaire », une migration générée, un workflow CI généré, un module Terraform généré. Chaque élément est plausible isolément. Le résultat global est une base logicielle avec plus d’exposition, plus de dépendances et moins de personnes qui comprennent vraiment pourquoi ça fonctionne.

La vitesse a augmenté, la stabilité non

Le point de données public le plus frappant est la recherche DORA sur l’adoption de l’IA générative. Dans le résumé du rapport DORA 2024, Google a indiqué qu’à mesure que l’adoption de l’IA augmentait, elle s’accompagnait d’une baisse estimée de 7,2 % de la stabilité de livraison et de 1,5 % du débit de livraison.

Le rapport DORA 2025 a présenté ces chiffres comme une variation estimée pour chaque hausse de 25 % de l’adoption de l’IA et a souligné l’écart entre l'impression de rapidité des développeurs et la performance réelle de livraison.

Ce schéma correspond exactement à ce que le vibe coding optimise : la vitesse locale plutôt que la fiabilité globale. L’IA réduit le coût des changements, ce qui encourage des modifications plus importants et plus fréquents. Si le discipline de mise en production est déjà fragile, l’IA en amplifie les effets.

Il existe aussi une hypothèse moins confortable : l’IA ne fait pas toujours gagner du temps aux développeurs expérimentés sur des bases familières, même si l’impression est contraire. Un essai contrôlé randomisé de METR a montré que des développeurs open source expérimentés prenaient environ 19 % de temps en plus avec des outils d’IA début 2025, tout en se croyant plus rapides. La conclusion n’est pas que « l’IA est mauvaise », mais que « l’intuition n’est pas un indicateur fiable. ». Si un flux réduit la compréhension ou accroît le coût de vérification, la promesse de vitesse peut s’inverser.

Défaillances de qualité qui passent bien en démo

Le code produit en vibe coding passe souvent des tests superficiels car il est optimisé pour la plausibilité. Il échoue ensuite de façon difficile à diagnostiquer :

• Colle surajustée : code fragile supposant la forme exacte des entrées, API ou HTML du moment, sans contrats ni versionnement.
• Complexité cachée : scripts « en un fichier » qui accumulent reprises, cache, concurrence et cas limites jusqu’à devenir des systèmes complets.
• Dette de performance discrète : requêtes N+1, boucles quadratiques, files non bornées, préchargements ou schémas de cache qui masquent les causes profondes.
• Risques de configuration : workflows CI/CD, règles IAM cloud, manifestes Kubernetes et modules Terraform qui « fonctionnent » tout en intégrant des valeurs par défaut dangereuses.
• Théâtre de tests : tests générés qui valident le comportement actuel plutôt que l’intention, ou qui neutralisent le risque réel.

Le fil conducteur est l’intention manquante. Les systèmes écrits par des humains gardent une trace du pourquoi. Les systèmes du vibe coding n’ont souvent que le quoi.

Sécurité : « ça compile » n’est pas une propriété de sécurité

Le vibe coding vise le fonctionnement local immédiat plutôt que la sûreté en environnement hostile. Ce n’est pas théorique. Une étude empirique de fragments générés par l’IA a constaté une forte probabilité de faiblesses de sécurité, notamment de nombreux fragments Python et JavaScript signalés avec des problèmes alignés sur la CWE dans de vrais projets GitHub.

Ces études ne condamnent pas un outil en particulier ; l’analyse statique produit des faux positifs et une faiblesse signalée n’est pas toujours exploitable. Mais la tendance est claire : un code plausible n’est pas forcément sûr, et la sécurité est précisément l’exigence non fonctionnelle ignorée par le vibe coding.
 

Les risques les plus fréquents dans les bases très orientées IA restent les classiques :

• Injection et constructions dangereuses : injection SQL, injection de commandes, désérialisation non sûre, templating fragile et validation d’entrées faible.
• Fuite de secrets : clés commises dans des scripts « temporaires », journaux contenant des jetons et endpoints de débogage qui passent en production.
• Erreurs d’authentification et de session : authentification artisanale, contrôles d’autorisation manquants et mauvaise compréhension des frontières d’identité entre services.
• Pièges cryptographiques : aléa DIY, mauvais modes, mauvaise gestion des clés et valeurs par défaut non sûres qui passent les tests.

Le vibe coding n’est pas intrinsèquement dangereux ; il l’est d’une manière précise : il facilite la production de beaucoup de code sans la compréhension nécessaire pour voir les hypothèses de sécurité implicites.

Risque de chaîne d’approvisionnement : hallucinations de paquets et attaques via les dépendances

Accepter la sortie de l’IA sans la lire fait des dépendances une surface d’attaque majeure. Un risque est l’« hallucination de paquets » : le modèle suggère une dépendance inexistante. Un attaquant peut publier un paquet de ce nom et attendre une installation. USENIX a analysé le phénomène comme une forme de confusion de paquets dans la chaîne d’approvisionnement logicielle.

Plus profondément, l’IA fait de « essaie cette bibliothèque » un réflexe. Dans une boucle de vibe coding, ajouter des dépendances paraît moins coûteux que comprendre l’existant. Cela augmente :

• le nombre de dépendances transitives implicitement approuvées,
• la vitesse d’entrée de paquets inconnus dans la compilation, et
• la difficulté d’audit et de correction lors d’un incident de chaîne d’approvisionnement.

Pour le code embarqué et industriel, les défaillances sont moins indulgentes

Les logiciels web peuvent souvent échouer « en douceur » : dégradation sans dommages physiques immédiats ou permanents. Les systèmes embarqués, eux, échouent plutôt par pannes intermittentes, bugs de temporisation, incidents de sécurité ou blocages irréversibles. Les firmwares issus du vibe coding sont particulièrement sujets à :

• Détails matériels plausibles mais faux : registres, champs de bits, temporisations et « nombres magiques » incorrects.
• Risques de concurrence et d’interruptions : conditions de course autour des ISR, DMA, primitives RTOS et tampons partagés, visibles surtout en charge.
• Mauvais usage des HAL : mélange d’appels HAL et d’écritures directes de registres violant des hypothèses et créant des bugs non reproductibles.
• Cas limites de protocoles : pilotes I2C/SPI/UART qui passent les tests de bon fonctionnement mais échouent avec l’étirement d’horloge, le bruit, la contention ou des câbles plus longs.
• Lacunes de watchdog et de reprise : code fonctionnel au labo sans gestion robuste des chutes de tension, du démarrage sûr ou des mécanismes de reprise.

Rien de nouveau ici. Ce qui change, c’est la facilité d’entrée du code peu compris et sa longévité tant qu’il « marche à peu près ».

Le facteur humain : défiance, surconfiance et dette de compétences

Même au pic du battage, la confiance dans la sortie de l’IA n’était pas uniforme. L’enquête Stack Overflow 2025 montrait que davantage de développeurs doutaient de son exactitude qu’ils ne lui faisaient confiance, avec peu de « très confiants » .

La faible confiance ne produit pas forcément une revue attentive. Elle conduit souvent à « relancer la requête jusqu’à ce que les tests passent », une vérification de façade — surtout si les tests sont minces, absents ou générés à partir du comportement actuel.

Le coût à long terme va de la dette technique à la dette de compétences. Quand le code devient quelque chose que l’on pilote plutôt que l’on écrit, il reste moins de personnes capables de déboguer au plus bas niveau, de raisonner sur les cas limites et de construire des interfaces fiables. On s’en rend compte quand le système casse hors du périmètre couvert par les tests.

La gouvernance rattrape son retard : traiter l’IA comme un contributeur non fiable

La réponse pratique qui émerge de 2025 à 2026 est « politique + pipeline », pas « interdiction ». Le profil communautaire SSDF du NIST pour l’IA générative est explicite : tout code source doit être évalué avant usage, sans distinguer entre code humain et code généré .

C’est la seule posture qui passe à l’échelle. La question n’est pas « un modèle a-t-il écrit ceci ? » mais « l’accepterions-nous d’un contributeur externe ? ».

Un filet de sécurité minimal pour les équipes orientées IA

Pour bénéficier de la vitesse de l’IA sans en subir les dérives, il faut poser un cadre minimal. Les outils varient, les principes non.

Limiter la taille des modifications. L’IA facilite les gros changements ; la fiabilité les punit. Fixez des limites de PR, déployez par étapes et utilisez des feature flags.

Exiger des tests qui échouent utilement. Les tests unitaires ne suffisent pas si les frontières d’intégration sont critiques. Ajoutez des tests de contrat, du fuzzing quand pertinent et des tests de régression liés aux incidents.

Activer les scanners et les rendre bloquants. Analyse statique, détection de secrets, analyse des dépendances et scan de conteneurs/IaC doivent être par défaut ; le mode « avertissement » doit être transitoire.

Verrouiller les dépendances et tracer la provenance. Lockfiles, versions épinglées, compilations reproductibles, SBOM et artefacts signés sont requis. « Installer le paquet suggéré » n’est pas un processus.

Focaliser la revue sur l’intention, pas la syntaxe. Exigez une courte note expliquant la raison, les risques et les tests.

Instrumenter la production. L’IA déplace l’effort vers le débogage. L’observabilité est indispensable : journaux, métriques, traçage et SLO explicites.

Rien de tout cela n’est nouveau. L’IA accroît simplement la pression sur ces fondamentaux en réduisant le coût marginal du changement.

Juridique et conformité : la provenance ne disparaît pas

Le vibe coding heurte la conformité en brouillant la provenance : données sources, contraintes de licence et responsabilité. Les régulateurs avancent. La Commission européenne a publié le 10 juillet 2025 un Code de bonnes pratiques pour l’IA à usage général, outil volontaire pour démontrer la conformité aux obligations de l’AI Act applicables dès le 2 août 2025a>.

Au Royaume-Uni, une consultation gouvernementale a posé explicitement le droit d’auteur et l’entraînement de l’IA comme problème actif ; elle s’est tenue du 17 décembre 2024 au 25 février 2025.

Implication pratique : si votre organisation a des contraintes de licence ou de conformité, le code généré par l’IA ne les contourne pas. Traitez la provenance comme une exigence opérationnelle, pas comme un débat théorique à remettre à plus tard.

La vraie leçon de 2025

2025 a réduit le coût de création des logiciels. Pas celui de leur possession.

Les équipes qui ont cantonné le vibe coding au prototypage ont gagné en vitesse. Celles qui ont laissé le vibe coding entrer en production en ont subi les conséquences, sous trois formes.

• Plus d’instabilité, la vélocité dépassant la discipline de livraisona>.
• Plus d’exposition sécurité, un code plausible n’étant pas sûr et les erreurs de dépendances devenant plus faciles à introduirea>.
• Plus d’ambiguïté de responsabilité, les questions de provenance, de revue et de licence arrivant plus tard — souvent quand l’argent est en jeu.

Rien de tout cela n’implique d’abandonner l’IA. Cela appelle une position simple et juste : l’IA accélère l’ingénierie, elle ne la remplace pas.

Questions ou commentaires ?

Vous pouvez me contacter par courriel brian.williams@elektor.com ou me retrouver sur X : @briantw.

Note de la rédaction : cet article (230181-R-01) est paru dans le numéro de mars/avril 2026 du magazine Elektor.