La facture que personne n'a mise dans le business case
Il y a quelques mois, un ingénieur me racontait une API interne que son équipe avait livrée après qu'un assistant de code l'eut pondue en un après-midi. Ça marchait. Ça avait passé la revue. Puis un scan de routine a repéré que l'endpoint se fiait à un identifiant fourni par l'utilisateur pour décider quels enregistrements renvoyer : n'importe qui pouvait lire les données de n'importe qui d'autre en changeant un chiffre dans l'URL. L'assistant l'avait écrit avec un aplomb total, et trois ingénieurs l'avaient validé parce que ça avait l'air terminé.
C'est le motif, pas l'exception. Des tests indépendants menés en 2026 ont trouvé qu'une large part des échantillons de code généré par IA contenaient une vulnérabilité connue, et le nombre de CVE rattachées à du code écrit par IA grimpe mois après mois. « On relira plus tard » a discrètement cessé d'être une option sûre.
Quand les équipes montent le business case pour GitHub Copilot ou Cursor, elles comptent les heures gagnées. Elles ne comptent presque jamais le travail de sécurité que ces heures gagnées déclenchent en aval. C'est là que le vrai coût se planque : pas dans la licence par poste, mais dans les vulnérabilités qui partent en production quand la génération distance la revue.
Pourquoi l'IA écrit du code non sécurisé par défaut
Un assistant optimise pour du code qui fonctionne, pas pour du code sûr. Entraînez un modèle sur la surface publique de GitHub et il apprend les motifs les plus fréquents, et les plus fréquents sont truffés de mauvaises habitudes : validation des entrées absente, accès trop permissifs, secrets collés directement dans le source.
Résultat : un endpoint qui compile, renvoie les bonnes données pendant la démo, et fait silencieusement confiance à une entrée à laquelle il ne devrait jamais se fier. Les faiblesses que les chercheurs en sécurité recensent dans le Top 10 de l'OWASP(lien externe, nouvel onglet) reviennent encore et encore, reproduites avec un aplomb total par un outil qui n'a aucune notion de modélisation des menaces. C'est le nouveau visage de la dette technique, sauf que cette version-là a un attaquant à l'autre bout.
Un assistant répond à « est-ce que ça tourne », pas à « est-ce que ça peut être attaqué ». Une seule de ces questions apparaît dans une démo.
Et ce n'est pas la lubie d'un seul fournisseur. Ces mêmes tests de 2026 ont relevé des vulnérabilités confirmées dans un quart à près de la moitié des échantillons générés selon la tâche, et les catégories les plus risquées étaient justement celles qui passent une démo sans accroc : authentification, traitement des entrées, contrôle d'accès. Une fonctionnalité peut sembler complète, réussir son test du chemin heureux, et embarquer quand même un trou exploitable que personne dans la salle n'avait pensé à chercher.
Quand le volume distance la revue
Le danger n'a jamais été qu'un assistant écrive une ligne non sécurisée. C'est qu'il en écrit bien plus vite que quiconque ne les relit, et le volume sert de multiplicateur. Quand des agents ouvrent des pull requests à longueur de journée et que les relecteurs les survolent sous la pression du sprint, la densité de vulnérabilités s'accumule en silence jusqu'à ce que quelque chose lâche.
C'est précisément ici que le vibe coding ne sauvera pas votre produit. Livrer vite est grisant, jusqu'au moment où une faille d'authentification atterrit devant chaque client à la vitesse de la machine. La discipline de production que j'évoquais dans les leçons Kubernetes en production s'applique tout aussi bien ici : la vitesse n'est un atout que si, en aval, quelque chose rattrape ce qu'elle laisse passer.
À quoi ressemble un vrai garde-fou sécurité
Sécuriser le développement assisté par IA est un problème de processus, pas un slogan d'outillage, et quelques pratiques portent l'essentiel.
La règle non négociable : aucun code généré touchant l'authentification, le traitement des entrées ou l'accès aux données ne fusionne sans qu'un humain attentif à la sécurité l'ait lu d'abord. Autour de ça, mettez du scan automatisé dans le pipeline. Des outils comme Semgrep ou Snyk attrapent les failles évidentes pour qu'elles fassent échouer le build plutôt que le client, et un détecteur de secrets comme GitGuardian gagne sa place parce que les assistants adorent coder les identifiants en dur. Traitez permissions et secrets en deny par défaut, et partez du principe que le modèle s'est trompé tant qu'on n'a pas prouvé le contraire. Puis raccrochez le tout à un cadre reconnu comme le cadre de gestion des risques IA du NIST(lien externe, nouvel onglet), pour que le jour où quelque chose passe entre les mailles, la responsabilité soit écrite noir sur blanc plutôt que débattue après coup.
Pour une équipe qui relit déjà sérieusement, rien de tout ça n'ajoute beaucoup de friction. Cela déplace surtout le coût d'un incident de production à 2 h du matin vers un commentaire de pull request, où corriger le même bug coûte dix fois moins cher.
Qui porte le bug qui part en prod
La question que la plupart des équipes ne tranchent jamais, c'est la responsabilité. Quand l'assistant écrit le code et qu'un humain clique sur « merge », qui porte la vulnérabilité livrée ? La réponse honnête, c'est l'équipe, à chaque fois. L'outil, lui, ne reçoit pas d'astreinte à minuit.
Cela recadre toute la décision. Adopter Copilot ou Cursor n'est pas qu'un arbitrage de productivité ; c'est s'engager à financer la revue et le scan qui rendent la sortie sûre à livrer. Une équipe qui empoche la vitesse et saute le garde-fou n'a pas économisé d'argent. Elle l'a emprunté à son futur budget incident, à un taux fixé par celui qui trouvera le trou en premier.
Le takeaway
Ajoutez une règle avant votre prochaine fusion assistée par IA : rien de généré touchant l'authentification, les entrées ou l'accès aux données ne part sans revue de sécurité. Ce sera plus lent ce sprint. C'est bien moins cher que la fuite que vous êtes en train, sans le dire, de programmer.
