Vibe coding en prod : les 5 erreurs qui arrivent quand il n'y a pas de senior dans la boucle

Je vois ça toutes les semaines en mission. Une équipe pousse du code généré par IA en production, les features sortent vite, les bugs arrivent lentement. Puis un jour, un secret API se retrouve dans un repo public, un endpoint critique n'a pas d'authentification, ou une migration détruit la base en staging. Le vibe coding (coder « au ressenti » en laissant l'IA générer le code) a produit 74 CVEs confirmées entre janvier et mars 2026 selon le projet Vibe Security Radar de Georgia Tech. Le problème n'est pas l'IA. Le problème, c'est qu'il n'y a personne pour vérifier ce qu'elle produit.

Erreur 1 : le code IA part en prod sans audit de sécurité

Le premier réflexe du vibe coding, c'est la vitesse. L'IA génère une feature en dix minutes, le développeur la teste visuellement, elle fonctionne, il la pousse. Le problème : ce qui fonctionne visuellement peut être criblé de failles que personne ne lit.

Selon Veracode, 45 % du code généré par IA contient au moins une vulnérabilité exploitable. CodeRabbit mesure un facteur 2,74x sur les issues de sécurité dans le code assisté par IA par rapport au code écrit manuellement. Le rapport METR 2025 confirme que les développeurs assistés par IA corrigent moins de bugs qu'ils n'en introduisent, dès que la complexité dépasse le boilerplate.

Quels sont les risques concrets du vibe coding en production ?

Le projet Vibe Security Radar de Georgia Tech a tracé chaque CVE jusqu'au commit d'origine pour déterminer si un outil de coding IA avait introduit la faille. Résultat : 6 CVEs en janvier 2026, 15 en février, 35 en mars. Soit 74 vulnérabilités confirmées en trois mois, selon le blog de Pradeo. Les chercheurs estiment que le chiffre réel est 5 à 10 fois supérieur, car la majorité des commits IA ne portent pas de signature identifiable.

Les failles ne sont pas exotiques. Ce sont les classiques du Top 10 OWASP : injections SQL, XSS, secrets hardcodés, cryptographie faible, authentification insuffisante. Un dev senior les repère à la lecture. Sans cette lecture, elles passent en prod à la vitesse de l'IA.

J'ai staffé des missions où le premier audit de sécurité après trois mois de vibe coding a révélé plus de 40 failles critiques sur un seul projet Next.js. Le coût du correctif a dépassé le coût du développement initial. C'est le schéma classique : la vitesse initiale se paie en dette de sécurité.

Erreur 2 : l'architecture dérive sans que personne ne la contrôle

L'IA ne dit jamais « attention, cette décision architecturale est incohérente avec ce que j'ai fait hier ». Elle résout le problème du prompt, pas le problème du projet. Spencer Keglovitz, CTO fractionnel avec 25 ans d'expérience, le résume bien dans son analyse : « l'IA ne flag pas quand elle produit une architecture inconsistante. Elle avance. C'est vous qui devez surveiller le structural drift. »

Pourquoi l'IA ne peut pas décider de l'architecture à votre place ?

Un LLM est un pattern matcher. Il reproduit ce qu'il a vu dans ses données d'entraînement. Quand vous lui demandez de concevoir un système, il produit quelque chose qui ressemble à un design. Il le défend même. Mais il n'a pas pesé les trade-offs comme le ferait un ingénieur avec du contexte métier.

Sur une mission récente, j'ai repris un projet où l'IA avait migré silencieusement d'un schéma REST à des appels RPC custom au milieu du développement. Personne ne l'avait remarqué parce que chaque prompt produisait du code qui fonctionnait. C'est seulement quand un nouveau développeur a rejoint l'équipe qu'on a découvert deux patterns incompatibles dans la même codebase.

Le développeur augmenté n'est pas celui qui laisse l'IA décider du stack. C'est celui qui fixe l'architecture en amont (ARCHITECTURE.md, CONVENTIONS.md, DECISIONS.md) et qui vérifie que chaque commit IA respecte ces choix. L'IA exécute vite. Le senior garantit qu'elle exécute dans la bonne direction.

Erreur 3 : les données sensibles se retrouvent exposées

Red Access a analysé plus de 380 000 actifs web sur les plateformes de vibe coding (Lovable, Replit, Base44) et identifié 5 000 applications construites à des fins d'entreprise. Parmi elles, 40 % contenaient des données sensibles déployées sans contrôles de sécurité de base, selon le rapport publié en juin 2026 et repris par LeMagIT.

Ce n'est plus du shadow IT. C'est du shadow development. Des employés construisent des apps complètes, les connectent à des systèmes de production, et les déploient publiquement pendant que la DSI ne sait même pas qu'elles existent. 2 000 de ces 5 000 applications n'avaient ni authentification, ni contrôle d'accès, ni piste d'audit.

Comment des apps vibe-codées finissent avec des accès admin ouverts ?

Le cas documenté par Red Access inclut un tableau de bord financier en direct dans une banque d'Amérique latine, accessible à quiconque possédait l'URL. L'IA génère du code qui fonctionne, mais elle ne configure pas la sécurité par défaut. Les headers HTTP, la protection CSRF, le rate limiting, le chiffrement des secrets : rien de tout cela n'arrive « gratuitement » dans le code généré.

Un senior sait que chaque endpoint exposé doit être authentifié. Il sait que les clés API ne vont pas dans le code source. Il sait qu'un .env.example ne contient jamais de vraie valeur. Ce n'est pas du gatekeeping, c'est de la discipline de base, celle qui sépare un prototype d'un service en production. Quand vous recrutez un dev senior à 180 €/jour pour cette review, vous achetez exactement ce filtre.

Erreur 4 : personne ne distingue « ça tourne » de « c'est prod-ready »

Un code qui passe les tests visuels en local n'est pas un code prêt pour la production. La production, c'est le monitoring, les logs structurés, les backups, la gestion d'erreurs, les migrations réversibles, les health checks, le graceful shutdown. L'IA ne met aucune de ces briques en place spontanément. Elle les ajoute si vous les demandez, mais encore faut-il savoir quoi demander.

Le vibe coding crée une illusion de vélocité. Amazon a généralisé l'assistance IA à travers ses équipes d'engineering, et en 90 jours, ils ont enregistré 471 incidents de production, dont un outage de 6 heures ayant impacté 6,3 millions de commandes, rapporte Spencer Keglovitz. Amazon a des milliers d'ingénieurs pour surveiller ces systèmes. Une startup avec trois développeurs juniors n'a pas ce filet.

Comment un dev senior review du code IA ?

Le senior vérifie d'abord la cohérence architecturale (ce code suit-il les conventions du projet ?). Il cherche les patterns de sécurité manquants (validation d'input, sanitization, auth). Il teste les cas limites que l'IA n'a pas imaginés (timeout réseau, base indisponible, payload malformé).

Pour piloter cette review à distance, un rituel de 30 minutes par jour suffit. Le senior lit les PR du matin, commente les points bloquants, valide les merges. Ce n'est pas un goulot d'étranglement, c'est un checkpoint.

Mon approche : chaque bloc livré par l'agent IA passe par un cycle lecture, test navigateur, validation manuelle. L'agent lit le contexte (CLAUDE.md, ARCHITECTURE.md), exécute, teste, documente. Puis le senior valide.

Erreur 5 : le junior armé d'IA accumule de la dette sans le savoir

Stanford mesure une baisse de 20 % des embauches de développeurs juniors entre 2024 et 2026. Les entreprises pensent que l'IA comble le gap. La réalité : un junior qui utilise l'IA sans senior dans la boucle ne produit pas un code de senior. Il produit un code de LLM que personne ne relit.

L'écart entre « savoir utiliser l'IA » et « savoir vérifier sa production » est un écart d'expérience, pas d'intelligence. La confiance des devs expérimentés dans le code IA est passée de 40 % à 29 % en un an, selon l'enquête citée par Spencer Keglovitz. Les seniors doutent parce qu'ils savent ce qui casse.

Un junior armé d'IA sans senior, c'est vraiment un risque ?

Un développeur qui ne comprend pas les race conditions, l'access control ou la gestion de sessions ne repérera pas quand l'IA se trompe sur ces sujets. L'IA délivre le code vulnérable avec la même confiance que le code correct. Il n'y a pas de signal d'alerte, pas de changement de ton, pas de warning.

Le marché est en train de se restructurer autour de cette réalité. Les juniors interchangeables perdent du terrain. Les seniors qui orchestrent l'IA, posent les garde-fous et garantissent la qualité du livrable voient leur valeur monter. C'est pourquoi nos profils chez Extra Dev ont tous 8 ans d'expérience minimum : un agent IA dans les mains d'un senior avec du contexte métier, ça livre vite et propre. Le même agent dans les mains d'un junior seul, ça produit du code qui passe les tests unitaires et qui explose en production.

« Le senior n'est pas là pour ralentir. Il est là pour que le code tienne. »

Vincent Roye, juin 2026

Le vibe coding n'est pas une impasse. C'est un outil puissant quand le coût de l'échec est faible et que quelqu'un comprend le résultat. Pour un prototype interne, un script d'automatisation, un outil one-shot, c'est redoutable d'efficacité. Pour de la production client, avec des données sensibles, des utilisateurs réels et une obligation de disponibilité, le filtre d'un dev senior avec 8 ans d'expérience minimum n'est pas optionnel. Il est le seul barrage entre un code qui fonctionne et un code qui tient.