Aller au contenu
FRENDécrivez votre besoin

Vibe coding en entreprise : du prototype au code qu’on peut mettre en production

Faire écrire un logiciel par une IA sans lire son code fonctionne pour un prototype, pas pour la production. Ce qui casse, ce que disent les études, et comment garder la vitesse avec des garde-fous.

Par Publié le 3 octobre 2026

Le vibe coding consiste à faire écrire un logiciel par une IA en lui décrivant ce qu’on veut, sans lire le code qu’elle produit. Le terme vient d’Andrej Karpathy, chercheur en IA, en février 2025, et le dictionnaire Collins en a fait son mot de l’année 2025. Pour un prototype ou un outil jetable, le gain est réel ; pour du code qui touche vos clients ou vos données, il faut remettre de la relecture, des tests et des contrôles.

Là où ça marche : prototypes et outils jetables

Karpathy le présentait lui-même comme adapté aux projets jetables du week-end. En entreprise, c’est la même chose : une maquette pour tester une idée auprès des utilisateurs, une démonstration, un script ponctuel, l’exploration d’une API. Le vibe coding permet aussi à des personnes qui ne développent pas de montrer précisément ce qu’elles veulent, ce qui fait gagner du temps à l’équipe qui construira la vraie version.

Ce qui casse en production

  • Des failles de sécurité. Dans son rapport de juillet 2025, Veracode a testé plus de cent modèles sur quatre-vingts tâches : 45 % des échantillons de code produits échouaient aux tests de sécurité et introduisaient des failles du Top 10 de l’OWASP. Son rapport de juillet 2026 relève un taux de réussite moyen de 56 %, à peine meilleur.
  • Des dépendances inventées. Une étude présentée à USENIX Security en août 2025 a mesuré qu’au moins 5,2 % des paquets proposés par les modèles commerciaux, et 21,7 % pour les modèles ouverts, n’existaient pas. Des attaquants publient des paquets malveillants sous ces noms : c’est le « slopsquatting », que le CERT-FR signalait comme utilisé dans sa synthèse de février 2026.
  • Des actions destructrices. En juillet 2025, lors d’un essai public, l’agent de la plateforme Replit a supprimé des données de production pendant un gel du code ; son dirigeant a reconnu que cela n’aurait jamais dû être possible.
  • Des secrets et des licences. Du code non relu peut embarquer une clé d’accès ou reprendre du code public sous licence ; GitHub indique que ces reprises concernent moins de 1 % des suggestions de Copilot, et affiche la licence quand cela arrive.

Les développeurs le savent : selon l’enquête Stack Overflow 2025, 46 % se méfient de l’exactitude des outils d’IA, contre 33 % qui leur font confiance.

Garder la vitesse avec des garde-fous

  • Une spécification d’abord : ce que le logiciel doit faire, ses cas limites, ce qu’il ne doit jamais faire. Le prototype en est souvent la meilleure base.
  • Des tests validés par une personne : l’IA peut les écrire, une personne vérifie qu’ils testent bien ce qui compte.
  • Une relecture humaine : l’ANSSI et le BSI recommandent depuis octobre 2024 que le code généré soit vérifié par les développeurs.
  • Des analyses automatiques dans la chaîne de livraison : analyse du code, vérification que chaque dépendance existe et vient d’une source connue, recherche de secrets. C’est le rôle de la sécurité intégrée à chaque livraison.
  • Des sources de paquets maîtrisées : des fichiers de versions figées et un registre interne ou une liste de sources autorisées.

Qui a le droit de mettre en production ?

Tout le monde peut prototyper, dans un environnement isolé et sans données de production. Ce qui part en production suit le même chemin que le reste du code : relecture, tests, analyses et validation. Côté responsabilité, la directive européenne sur les produits défectueux couvre désormais les logiciels, pour les produits mis sur le marché à partir du 9 décembre 2026, et le Cyber Resilience Act rend les fabricants responsables de la sécurité de leurs produits. Notre lecture de ces textes : l’entreprise qui livre le logiciel en répond, quelle que soit la façon dont le code a été écrit.

Du prototype au produit, étape par étape

  • Garder le prototype comme spécification vivante, montrée aux utilisateurs.
  • Faire relire et, si besoin, réécrire par un développeur ce qui part en production.
  • Ajouter les tests qui manquent, validés par une personne.
  • Passer la chaîne CI/CD complète, avec ses analyses de sécurité.
  • Mettre en production derrière une validation, avec un retour arrière prévu.

Notre page Automatisation du développement logiciel montre comment des agents IA prennent leur part du cycle avec une relecture humaine à chaque étape. Voir aussi nos articles sur le déploiement des agents de code et sur les serveurs MCP, et la page L’IA agentique sous votre contrôle.

Questions fréquentes

Peut-on mettre en production du code généré par une IA ?

Oui, s’il passe les mêmes contrôles qu’un code écrit à la main : relecture, tests, analyses de sécurité et validation avant la mise en production.

Qui est responsable de ce code ?

L’entreprise qui le livre, selon notre lecture des textes européens : ils visent le fabricant du logiciel, quelle que soit la façon dont il a été écrit. D’où l’importance de garder la trace de qui a relu et validé quoi.

Faut-il interdire le vibe coding aux non-développeurs ?

Non. Donnez-leur un environnement isolé, sans données de production ni identifiants réels. Leurs prototypes servent de base aux développeurs, mais ne partent pas en production sans eux.

Sources

Faits et chiffres vérifiés le 3 octobre 2026.