Le vibe coding déclenche une épidémie de syndrome NIH

Longtemps cantonné aux équipes d’ingénierie, le Not Invented Here syndrome explose avec le vibe coding : produire du code devient si facile que réutiliser n’est plus un réflexe. Résultat, une prolifération de micro-outils et de solutions redondantes, plus rapides à créer qu’à maintenir et qui finissent par ralentir tout le monde.

À retenir

• Le vibe coding s’appuie sur une boucle see-say-run.
• Il peut amplifier le NIH via la facilité de création.
• Le code généré peut ignorer la sécurité : context amnesia.
• Le risque monte avec le shadow engineering.
• La réponse passe par la gouvernance IA.

En 2025, popularisé par Andrej Karpathy, le vibe coding bouscule la manière d’écrire du logiciel avec des LLM comme Cursor ou Replit Agent. Le sujet n’est pas seulement la vitesse, mais ce qui casse quand la réutilisation de code devient secondaire. Pour les équipes produit et d’ingénierie, cette bascule peut déclencher une prolifération de composants redondants et accroître les risques de sécurité, et créer l’illusion de la solution parfaite.

L’intention d’abord : le vibe coding et sa promesse opérationnelle

On passe d’un contrôle syntaxique à une logique d’objectif : l’utilisateur décrit, l’agent produit. Le clavier compte moins que la capacité à exprimer clairement le besoin métier.

Une “boucle” popularisée en 2025 par Andrej Karpathy

Le vibe coding s’articule, dans la formule d’Andrej Karpathy, autour de trois étapes : see stuff, say stuff, run stuff. Concrètement, le développeur montre ou décrit ce qu’il veut, formule l’intention, puis exécute. L’idée centrale est simple : la machine génère l’essentiel du code à partir de l’objectif.

Coder en langage naturel : une programmation par intention

Cette accessibilité repose sur un principe simple : la programmation par intention. L’anglais (ou un autre langage naturel) devient présenté comme “le langage de programmation le plus puissant” dans les discours autour du concept. On affronte moins la syntaxe au quotidien, et l’on délègue davantage la traduction de l’idée vers l’implémentation concrète.

Le NIH Syndrome 2.0

Le NIH ne relève plus seulement de l’orgueil technique. Il devient un effet de bord direct de la généralisation de la génération automatique.

Moins de recherche, plus de génération

Le NIH, au sens classique — Not Invented Here — consistait à refuser les solutions externes par posture technique. Avec le vibe coding, la dynamique change : l’équipe ne “refuse” plus, elle n’a simplement plus le temps de chercher. Réutiliser une bibliothèque suppose lecture, compréhension, intégration et tests. Générer une variante locale “sur mesure” semble plus rapide, même si c’est rarement vrai à long terme.

Une économie des dépendances remise en cause

La conséquence est très concrète. La facilité de création immédiate fragilise l’économie de la réutilisation de code. Les développeurs finissent par préférer des implémentations redondantes à des standards communs, ce qui peut mener à une prolifération de micro-outils orphelins. À moyen terme, maintenir dix variantes parallèles coûte plus cher, en effort et en risque, que d’intégrer une dépendance bien cadrée.

Shadow engineering et sécurité : l’autre face du code “jetable”

Le problème n’est pas que l’IA code, mais qu’elle code parfois sans votre contexte. Le résultat fonctionne, compile, passe quelques tests, mais ne respecte pas forcément vos contraintes réelles.

L’illusion de la solution parfaite pour chaque cas

En entreprise, le NIH se transforme en réflexe : chaque développeur préfère sa version générée à la demande, plutôt qu’une brique partagée dont l’intégration est plus “complexe socialement”. La personnalisation paraît plus juste parce qu’elle répond au cas présent. Mais l’assemblage de micro-variantes finit par fragmenter les pratiques. Les équipes construisent alors des solutions qui ressemblent à des réponses, sans toujours bien s’emboîter dans un cadre commun.

Dette technique invisible et “solution bloat”

Le vibe coding peut conduire à une dette technique très importante et invisible. Le code généré manque souvent d’architecture globale, de documentation et de tests unitaires rigoureux.
Le solution bloat : Concrètement, on obtient des pièces qui “fonctionnent”, mais le volume de code augmente sans cohérence d’ensemble. Personne ne sait pourquoi la logique profonde a été écrite ainsi et cela rend l’évolution future bien plus difficile.

Dette technique invisible : de la “preuve” vers la production

Une autre complication vient de la dette technique. Le code généré est souvent présenté comme temporaire, donc moins nettoyé, moins optimisé et moins documenté. Puis, pour des raisons métier, il finit en production et devient durable. C’est là que la facture arrive : moins par incapacité technique que par inertie organisationnelle. Le logiciel “jetable” devient un actif, donc un engagement d’entretien sur plusieurs années.

Passer du vibe coding à une vibe engineering gouvernée

Pour éviter que l’accélération ne se transforme en dette, il faut structurer ce qui alimente les prompts. Ce n’est plus seulement une affaire d’outillage, mais de règles partagées et appliquées.

Du mode individuel à la gouvernance collective

Les équipes doivent passer d’un vibe coding “single player” à une vibe engineering plus collective et structurée. L’objectif : aligner les sorties du LLM avec des standards organisationnels clairs. Autrement dit, on ne mesure plus seulement la vitesse de frappe, on mesure la capacité à maintenir la cohérence, d’un projet à l’autre.

Trust but verify : la vérification redevient le vrai travail

Le principe annoncé est clair : Trust but verify. Le rôle de l’humain ne disparaît pas avec l’IA ; il se déplace vers la validation. Tests, revue de code, conformité sécurité et intégration réelle deviennent la barrière de sécurité contre les réponses qui ont l’air justes mais ne respectent pas les contraintes réelles.

Réinjecter l’architecture dans le flux de prompts

La piste la plus concrète consiste à réinjecter l’architecture dans le contexte envoyé au LLM. Cela peut prendre la forme d’instructions personnalisées, de catalogues d’API internes ou de garde-fous documentés. Cette approche vise une gouvernance IA opérationnelle : encadrer la génération pour réduire les dépendances fantômes et limiter les écarts de patterns entre équipes.