Vibe coding : quand la vitesse de l'IA coûte cher à votre PME

Le devis était moitié moins cher que les autres, l'application est en ligne en quelques semaines, et la démo est convaincante. Ce qui ne se voit pas : personne n'a relu le code, rien ne le teste, et le prestataire serait bien en peine d'expliquer comment il fonctionne. Huit mois plus tard, le tableau s'inverse : chaque évolution prend des semaines, un développeur consulté refuse de reprendre le code, et un audit révèle que des données clients étaient accessibles sans réelle protection depuis la mise en ligne.

Le délai n'a rien d'anormal dans cette histoire : livrer en quelques semaines, avec les bons outils et la bonne méthode, est devenu parfaitement tenable. Ce qui a manqué, c'est le contrôle : personne ne supervisait ce que l'IA produisait, aucune méthode n'encadrait le chantier. Cette pratique a un nom : le vibe coding. Si vous envisagez de faire développer un logiciel, ce terme mérite d'entrer dans votre vocabulaire de décision — non pas pour rejeter l'IA, mais pour poser les bonnes questions à ceux qui l'utilisent en votre nom.

Le vibe coding : d'où vient le terme, ce qu'il désigne

En février 2025, Andrej Karpathy (cofondateur d'OpenAI, ancien directeur de l'IA chez Tesla) décrit sur X « une nouvelle façon de coder, où l'on s'abandonne complètement à l'intuition, où l'on embrasse les exponentielles, et où l'on oublie jusqu'à l'existence du code ». Il baptise cela vibe coding : coder à l'instinct. On décrit à une IA ce qu'on veut, en langage courant ; elle produit le logiciel ; on regarde si ça a l'air de marcher ; on enchaîne.

Pour un prototype du week-end (le contexte dont parlait Karpathy), c'est une pratique réjouissante. Le problème commence quand elle produit, sans le dire, le logiciel qui gère vos clients, votre facturation ou vos données de santé.

La frontière utile a été posée un mois plus tard par Simon Willison, ingénieur reconnu de la communauté open source : « si un LLM a écrit chaque ligne de votre code, mais que vous l'avez relu, testé et compris, ce n'est pas du vibe coding — c'est du développement logiciel » (mars 2025, traduit). Le risque ne vient pas de la génération elle-même. Il commence là où le code n'est ni relu, ni testé, ni compris.

C'est cette distinction que les chiffres qui suivent mesurent.

La qualité : plus de code, moins de fondations

Chaque année, l'outil d'analyse GitClear mesure ce qui change réellement dans le code de milliers d'équipes. Son étude 2026, portant sur 623 millions de changements de code analysés entre 2023 et 2026, documente deux mouvements simultanés.

D'un côté, les blocs de code dupliqués ont augmenté de 81 % depuis 2023. La duplication, c'est le même passage copié-collé à plusieurs endroits du logiciel : le jour où une règle métier change, il faut penser à corriger chaque copie. En oublier une, c'est un bug qui dort.

De l'autre, le refactoring s'est effondré : de 21 % des lignes modifiées en 2022 à moins de 4 % début 2026. Le refactoring, c'est le travail de réorganisation du code existant pour qu'il reste simple à faire évoluer. Sur un chantier, ce serait consolider les fondations à mesure qu'on ajoute des étages. L'IA générative excelle à ajouter des étages ; elle ne consolide presque jamais d'elle-même.

Le résultat porte un nom en ingénierie : la dette technique. Chaque raccourci pris aujourd'hui devient un intérêt à payer sur chaque modification future. Et c'est le point aveugle du devis imbattable : la dette est invisible à la livraison. Elle se paie à la première évolution, au premier changement de prestataire, à la première panne. Chez vous, donc, après la fin du contrat.

Que pèse cette dette, à l'échelle ? Les ordres de grandeur disponibles sont des estimations, à prendre comme telles. Le consortium CISQ évaluait en 2022 le coût de la mauvaise qualité logicielle aux États-Unis à 2 410 milliards de dollars par an (estimation agrégée, pas une mesure). Et dès 2018, avant l'IA générative, l'enquête Developer Coefficient de Stripe indiquait que les développeurs passaient déjà 42 % de leur temps à gérer de la dette et du mauvais code. Le problème est antérieur à l'IA ; sans supervision, elle l'industrialise.

La sécurité : des failles, et l'excès de confiance en prime

Dès 2023, une équipe de Stanford (Perry et al., conférence ACM CCS) a comparé des développeurs travaillant avec et sans assistant IA (le modèle Codex d'OpenAI, testé à l'époque). Double constat : les participants assistés par l'IA ont produit un code moins sûr sur quatre des cinq exercices, et ils étaient plus convaincus d'avoir écrit un code sûr. La faille, plus la confiance : c'est la combinaison la plus coûteuse qui existe, parce que personne ne cherche un problème dont personne ne se doute.

Les modèles ont progressé depuis ? Sur ce point précis, non. En 2025, l'éditeur de sécurité Veracode a soumis plus de 100 modèles d'IA à 80 tâches de programmation : dans 45 % des cas, le code généré contenait une faille du top 10 OWASP, les dix familles de vulnérabilités les plus connues et les plus documentées du web, celles que tout professionnel apprend à éviter. L'étude note que les modèles les plus récents et les plus gros ne font pas mieux que les autres. Attendre la prochaine version n'y changera donc rien : le défaut est structurel à la génération de code sans relecture.

La fiabilité : on livre plus, on casse plus

Le rapport DORA 2024 de Google (l'étude de référence sur la performance des équipes de développement, plus de 39 000 répondants) chiffre l'effet à l'échelle des organisations. Quand l'adoption de l'IA augmente de 25 %, la productivité individuelle des développeurs progresse et la documentation s'améliore ; l'étude le mesure et il faut le dire. Mais dans le même mouvement, la stabilité des livraisons chute de 7,2 %, et le débit de livraison recule légèrement (−1,5 %).

L'image est celle d'une usine qui produit plus vite, mais dont davantage de pièces reviennent au service après-vente. L'explication du rapport tient en une phrase : l'IA pousse à livrer des lots de changements plus gros, donc plus difficiles à vérifier. Sans les garde-fous d'ingénierie (petits lots, tests automatisés robustes), la vitesse se paie en pannes.

Un incident, un seul

En juillet 2025, les chercheurs en sécurité de Wiz ont publié leur analyse de Base44, l'une des plateformes de vibe coding les plus en vue, rachetée par Wix. Leur découverte : muni du seul identifiant public d'une application (une valeur visible dans son adresse web), n'importe qui pouvait se créer un compte vérifié sur les applications privées d'entreprises clientes, en contournant toute l'authentification, y compris le SSO, le système d'accès unique des entreprises. Étaient exposés des outils internes de ressources humaines, des bases de connaissances, des données personnelles. Wix a corrigé en 24 heures, et aucune exploitation malveillante n'a été constatée.

L'incident s'est bien terminé ; son intérêt est ailleurs. Il révèle que la promesse commerciale de tout cet écosystème est précisément de se passer d'ingénieurs. Or une faille d'authentification ne se voit dans aucune démo. Quand personne n'a pour mission de chercher ce qui ne se voit pas, personne ne le trouve — jusqu'au jour où quelqu'un d'extérieur le trouve à votre place.

Le renversement : l'IA amplifie la compétence, elle ne la remplace pas

Voici la donnée qui remet l'ensemble à l'endroit. En janvier 2026, la revue Science a publié la plus large mesure à ce jour de l'usage réel de l'IA dans le code : 30 millions de contributions Python, 160 000 développeurs. En France, environ un quart des nouvelles fonctions étaient déjà écrites avec assistance IA début 2025. Le gain de productivité mesuré est réel : +3,6 %.

Mais sa répartition est tout sauf uniforme : les gains sont portés par les développeurs expérimentés. Les débutants, qui utilisent pourtant l'IA davantage (37 % de leur code, contre 27 % chez les expérimentés), n'en tirent presque aucun bénéfice mesurable.

L'IA n'est donc pas une compétence de substitution : c'est un multiplicateur. Multipliée par une expertise senior, elle donne de la vélocité avec de la rigueur. Multipliée par l'absence d'expertise, elle donne du code plus vite — sans personne pour voir ce qui cloche.

Ne demandez pas à votre prestataire s'il utilise l'IA. Demandez-lui comment il encadre ce qu'elle produit.

Tout le monde utilise l'IA, et nous les premiers : c'est elle qui permet de livrer en semaines ce qui prenait des mois. Ce qui sépare les projets qui tiennent des projets qui coûtent, c'est la supervision d'ingénierie autour.

Les cinq questions à poser à votre prestataire

Vous n'avez pas besoin de devenir technique pour vous protéger. Cinq questions suffisent, et la précision des réponses est en soi une information.

• Qui relit le code généré ? La réponse attendue nomme une personne et une pratique : un ingénieur identifié relit chaque changement. « L'IA vérifie elle-même » ou « on regarde si ça marche » sont des drapeaux rouges.
• Comment le logiciel est-il testé ? Attendez des tests automatisés : des vérifications écrites une fois, rejouées à chaque modification, qui couvrent vos scénarios critiques (facturation, accès, données). « On a tout cliqué avant la livraison » n'est pas une réponse.
• Qui est responsable en cas de faille de sécurité ? La réponse doit exister dans le contrat, pas seulement dans la conversation. Un prestataire qui assume sa responsabilité organise sa relecture en conséquence.
• Que se passe-t-il dans deux ans ? Le code vous appartient-il entièrement ? Est-il documenté ? Un autre développeur pourrait-il le reprendre sans vous facturer une réécriture ? La réversibilité se décide au premier jour.
• Comment l'application est-elle surveillée en production ? Journalisation des erreurs, alertes, suivi des performances : un logiciel professionnel se surveille comme une installation électrique. Une panne qu'on découvre par un appel client est une panne découverte trop tard.

Un prestataire sérieux répond à ces cinq questions en quelques minutes, avec des réponses concrètes. Des réponses floues ne prouvent pas une faute — mais elles vous disent où vous mettez les pieds.

La vitesse ou la rigueur ? Les deux.

Le vibe coding ne condamne pas l'IA. Il rappelle ce que coûte la vitesse sans l'ingénierie qui l'encadre. La vélocité de l'IA et la rigueur de l'ingénieur ne s'opposent pas : l'une sans l'autre produit soit de la lenteur, soit de la dette. Si vous avez un projet en tête, ou un devis qui vous semble trop beau, un appel de cadrage suffit souvent à y voir clair : ce qui est faisable, à quel prix, et avec quels garde-fous.

Cet article a été produit avec assistance IA, selon la méthode qu'il décrit : chiffres vérifiés un à un à la source primaire, relecture et signature par un ingénieur. C'est exactement ce que nous recommandons pour votre code.