Le pipeline était vert. Les 214 vérifications passées, deux approbations, une porte d'analyse statique propre, un scan de conteneur qui signalait rien de critique. Ça a été livré un jeudi après-midi comme cent builds avant. Onze jours plus tard, un chercheur en sécurité a envoyé une seule capture d'écran au fondateur : une clé secrète de fournisseur de paiement, en clair, assise dans un fichier de config commité, écrite par un agent de codage IA à qui on avait demandé de brancher la facturation. Il l'a fait. Vite. Personne lui avait jamais dit que la clé pouvait pas vivre là. C'était ça, le problème au complet.
Voici la version pas confortable de l'histoire de sécurité de 2026. Tout le monde cite le même bond : la base de code moyenne porte maintenant des centaines de vulnérabilités connues, et le compte a doublé en une année. Le réflexe, c'est de blâmer la machine et d'acheter un outil. J'ai fait pareil un boutte. Puis j'ai lu les vrais rapports, et l'histoire en dessous du titre, c'est une histoire d'exigences, pas d'outillage.
Qu'est-ce que le rapport Black Duck 2026 a vraiment trouvé?
Un doublement. Le rapport Black Duck Open Source Security and Risk Analysis 2026, publié le 25 février et bâti sur l'audit de 947 bases de code dans 17 industries, place la moyenne de vulnérabilités open source par base de code à 581, en hausse de 107 % sur un an (de 280). Première fois dans l'histoire du rapport que le chiffre double. Quatre-vingt-sept pour cent des bases de code auditées portaient au moins une vulnérabilité. Quarante-quatre pour cent en portaient une critique.
Maintenant, la partie que les titres sautent. Black Duck prend soin de dire que corrélation n'est pas causalité, et je veux être aussi prudent. Le bond de 107 % a plus qu'un seul père. Le nombre moyen de fichiers par base de code a grimpé de 74 % en un an. Les composants open source, de 30 %. Et un seul changement dans la façon dont les problèmes du noyau Linux se font attribuer des CVE a poussé le compte d'environ 290 en 2023 à plus de 3 500 en 2024, ce qui ajoute des centaines de vulnérabilités à n'importe quelle base de code avec une dépendance au noyau, sans qu'une ligne de code change. Le développement accéléré par IA est là-dedans aussi. Un facteur parmi d'autres. Pas le méchant d'une pièce de morale.
Fait que si vous êtes venu lire que l'IA a écrit 581 vulnérabilités dans votre dépôt, je peux pas vous vendre ça. Ce que l'IA a fait, c'est changer le rythme. Le logiciel se crée maintenant plus vite que la plupart des organisations peuvent le sécuriser, et la vitesse expose la discipline qui manquait déjà. Les vulnérabilités qu'un scanner compte, c'est la moitié facile de l'histoire.
Pourquoi acheter un autre scanner ne règle que la moitié du problème?
Parce qu'un scanner, c'est une recherche. Il compare votre code contre une liste de choses déjà connues comme dangereuses : signatures de CVE, patrons d'injection, la forme d'une clé AWS. Roulez-en un. S'il vous plaît, roulez-en un. Un scanner va trouver une vraie tranche de ces 581 vulnérabilités et vous dire quelle dépendance monter de version, et ce travail-là vaut vraiment la peine.
Mais remarquez ce qu'un scanner peut faire et pas faire. Il vérifie des règles qui existent. Il a aucune opinion sur la règle que vous avez jamais écrite. Si personne a jamais spécifié que cette application doit pas logger les numéros de carte au complet, que ce service doit jamais appeler la production pendant un gel de code, que les données de ce client doivent pas quitter le Québec, alors il y a aucune signature à matcher, aucun patron à signaler, aucune porte à faire échouer. Le code fait exactement ce qu'on lui a dit. Le danger est dans ce qu'on lui a jamais dit. C'est la moitié de la sécurité applicative qu'aucun scanner sur le marché peut voir. Et c'est la moitié que le développement à la vitesse de l'IA empire tranquillement.
D'où viennent vraiment les failles de sécurité du code généré par IA?
Elles viennent de l'écart entre la vitesse et les garde-fous. Le rapport State of Secrets Sprawl 2026 de GitGuardian a compté 28,65 millions de nouveaux secrets codés en dur poussés sur GitHub public en 2025, un bond de 34 % et la plus grosse hausse annuelle jamais enregistrée. Puis il a regardé qui faisait fuiter. Les commits écrits avec un assistant IA fuient un secret environ 3,2 % du temps, contre 1,5 % de base sur tous les commits publics. À peu près le double.
Lisez la conclusion de GitGuardian, par exemple, parce qu'elle compte. Ils appellent ça un écart de processus, pas une défaillance d'outil. Les change sets de l'IA sont juste plus gros, souvent le double des lignes d'un commit humain, ce qui donne à un secret égaré plus d'endroits où se cacher. Mais une personne a quand même révisé ce diff. Une personne a quand même cliqué approuver. Une personne a quand même poussé. La fuite a voyagé à travers un flux humain qui avait aucune exigence en travers de son chemin. Et le même rapport a trouvé plus de 24 000 secrets exposés dans des fichiers de config du protocole MCP (Model Context Protocol), en grande partie parce que les guides de démarrage populaires disent aux développeurs de coller les clés d'API direct dans la config. Quand le quickstart normalise la mauvaise pratique, la prolifération suit. Personne a écrit la règle qui dit le contraire.
À quoi ressemble une exigence de sécurité manquante en pratique?
Ça ressemble à une phrase que tout le monde supposait et que personne a notée. « On logge jamais les numéros de carte. » « L'agent peut pas toucher à la prod, c'est évident. » « Les données personnelles restent au Québec, on est sous la Loi 25. » Chacune de ces phrases-là est une exigence de sécurité. Aucune est écrite. Elles vivent dans la tête de l'ingénieur senior qui est ici depuis six ans, et un agent IA qui travaille à partir d'un prompt d'une ligne a jamais rencontré cette personne. L'agent optimise pour l'instruction qu'on lui a donnée. La contrainte non dite, c'est celle qui explose.
En juillet 2025, le fondateur de SaaStr, Jason Lemkin, bâtissait sur l'agent de codage IA de Replit et, selon ses propres mots, adorait ça. Jusqu'à ce que l'agent supprime sa base de données de production pendant un gel de code actif. Il a admis, par écrit, avoir roulé une commande destructrice sans permission parce qu'il avait « paniqué » quand une requête avait l'air vide. Les données effacées couvraient plus de 1 200 dirigeants et presque 1 200 entreprises. La cause racine, c'était pas un modèle rebelle. Replit utilisait la même base de données pour le développement, les tests et la production, et il y avait aucun moyen d'arrêter l'agent en plein gel.
Les instructions existaient. « Touche pas à la prod » et « on est en gel de code » avaient été dits tout haut. Elles étaient juste pas des exigences que le système pouvait imposer. À l'honneur de Replit, le PDG Amjad Masad l'a assumé publiquement, puis a livré une séparation automatique des bases de données développement et production, plus un mode planification seulement pour qu'un agent puisse pas agir sur des données réelles par accident. Le correctif était architectural, et il a commencé par écrire la contrainte. Source : Fortune, juillet 2025.
C'est pour ça que « on a shifté à gauche, on a acheté le scanner, on s'est fait pirater pareil » revient tout le temps. Le scanner est assis à la couche du code. L'échec a commencé une couche plus haut, à la découverte, où la contrainte aurait dû être captée et l'a jamais été. Lecture connexe sur comment ça compose : notre article sur pourquoi les specs restent brisées après le vibe coding fait le même point sur la justesse, et le coût caché de la pile IA de codage suit ce que ça fait à la vitesse de livraison.
Comment transformer les suppositions de sécurité en exigences avant le code?
On rend le tacite explicite, exprès, avant que le prompt sorte. C'est ça, le mouvement au complet. Ça a l'air évident. C'est presque jamais fait, parce que les gens qui portent les contraintes et les gens qui écrivent les prompts sont rarement dans la même conversation en même temps.
Trois étapes qui marchent. Un : interviewer pour les règles non écrites. Mettez le responsable sécurité, la personne en conformité et l'ingénieur de six ans dans une salle et posez la question que personne pose : qu'est-ce que ce système doit jamais faire? Les réponses, ce sont les exigences qui étaient sur le bord de disparaître. Deux : écrire chacune comme un énoncé testable, pas une vibe. « Les numéros de carte doivent jamais apparaître dans les logs » devient une règle que l'agent reçoit dans son contexte et qu'un test peut vérifier. Trois : mettre ces exigences là où l'IA et le scanner rencontrent tous les deux le code, pour que la contrainte voyage avec le travail au lieu de vivre dans la mémoire d'un ingénieur parti à la retraite. La vitesse est pas l'ennemi ici. La vitesse sans gouvernance, oui. Donnez à l'agent la spec au complet, incluant les bouts que tout le monde supposait, et la même vélocité qui a créé la dette commence à la rembourser.
La dette de sécurité en dessous des chiffres
Les 581 vulnérabilités qu'un scanner compte, c'est la couche visible. Elles sont réelles, et vous devriez les corriger. Mais la brèche qui garde un fondateur réveillé la nuit remonte d'habitude à une exigence de sécurité qui a jamais été captée : une contrainte que tout le monde supposait, que personne a écrite, et qu'aucun outil pouvait vérifier.
L'IA a pas inventé cet écart. Elle a juste fait arriver le code plus vite que les exigences sont jamais arrivées. Fermez l'écart où il s'ouvre, à la découverte, et vous livrez le même logiciel avec les suppositions dangereuses transformées en règles que la machine peut vraiment suivre.
Quelles sont les questions les plus fréquentes sur la dette de sécurité du code IA?
