Tu publies un correctif de sécurité sur ton projet open source. Dix minutes plus tard, un exploit tourne dans la nature. Pas parce que des hackers surveillaient ton repo 24h/24 — mais parce que des agents IA lisent tes diffs en temps réel et reconstruisent automatiquement les failles depuis ce que tu viens de corriger. Simon Willison a documenté le phénomène le 28 août. Ce n’est pas une anecdote. C’est une rupture de mécanique.
10 minutes entre le patch et l’exploit
Anil Madhavapeddy est professeur à Cambridge et mainteneur du projet OCaml. Ce qu’il observe depuis quelques semaines est simple : dès qu’un correctif de sécurité est partagé publiquement — même partiellement, même juste la description du bug — des exploits apparaissent en environ dix minutes. Avant, c’était plusieurs jours, parfois une semaine.
Nick Craig-Wood, mainteneur de rclone (l’outil de synchronisation cloud que des milliers de builders utilisent), confirme de son côté : plus de 40 signalements de sécurité reçus en un mois, contre 20 en 10 ans d’existence du projet. Pas parce que rclone est soudainement plus vulnérable. Parce que des agents IA scrutent les diffs publiés et génèrent des proof-of-concept d’exploitation automatiquement.
La logique est brutale : les agents lisent ce que tu as corrigé, comprennent ce que tu avais cassé, et reconstruisent l’exploit depuis les indices que tu as révélés en montrant ta solution.
L’ironie de la transparence open source
L’open source repose sur la transparence. Tous les commits sont publics. Les pull requests sont archivées. Les changelogs sont détaillés. C’est ce qui rend l’écosystème robuste — et c’est exactement ce qui se retourne contre lui.
Un correctif de sécurité bien rédigé contient par définition toutes les informations nécessaires pour comprendre la faille : la ligne incorrecte, la logique cassée, le chemin d’attaque. Les agents IA n’inventent rien. Ils lisent ce que tu viens de publier, et en quelques minutes, ils ont reconstitué l’exploit original que tu voulais précisément fermer.
Le délai d’embargo — ce temps entre « j’ai trouvé la faille » et « je publie le correctif » — était le rempart principal. Ce rempart est en train de s’effondrer, non pas parce que les pratiques de sécurité ont changé, mais parce que la vitesse de traitement de l’information a changé.
Le goulot d’étranglement CVE aggrave tout
Il y a un deuxième problème que Willison pointe : le système officiel de référencement des failles (les CVE — Common Vulnerabilities and Exposures) ne suit plus. On est passé de 2-3 jours de délai d’attribution à 3-4 semaines.
En pratique : un exploit est exploité en 10 minutes après la publication du patch, mais il faut potentiellement un mois avant qu’un CVE officiel permette d’alerter proprement les utilisateurs. Il y a une fenêtre où des attaques actives circulent, sans référence officielle pour déclencher les alertes automatiques dans les gestionnaires de dépendances.
« Just a rumour of a bug is enough to find a security exploit these days. »
Simon Willison, 28 août 2026
Ce que ça change pour toi concrètement
Si tu construis avec des dépendances open source — et qui n’en a pas — le délai entre « un patch est disponible » et « tu dois absolument mettre à jour » est passé de jours à minutes. Quelques réflexes pratiques :
- Activer les alertes Dependabot ou équivalent sur tous tes projets, y compris les side-projects dormants. La paresse sur les mises à jour est devenue une vulnérabilité structurelle.
- Ne jamais communiquer publiquement sur une faille non encore patchée, même vaguement. Un « nous travaillons sur un problème de sécurité dans le module X » suffit à orienter des agents vers le bon endroit.
- Surveiller les projets critiques dont tu dépends, pas uniquement tes propres repos. Si rclone publie un patch aujourd’hui et que tu l’utilises, tu dois le savoir dans l’heure.
La conséquence plus large : les projets modestes, maintenus par 1-2 personnes dans leur temps libre, sont les plus exposés. Ils n’ont pas de processus de divulgation responsable formalisé. Ils publient leur correctif, et dix minutes après, les exploits arrivent.
Soutenir l’open source sur lequel tu t’appuies — contributions, dons, triage d’issues — n’est plus uniquement une question d’éthique. C’est une question de sécurité de ton propre stack. La santé des mainteneurs qui gardent ces projets en vie, c’est directement ta santé à toi.
Ma lecture : on est en train de vivre un changement de régime dans la sécurité open source, pas une simple accélération. Les pratiques qui fonctionnaient il y a deux ans — délai de publication, embargo informel, notification par email — sont devenues obsolètes. Les agents IA ne sont pas la cause des failles. Mais ils ont réduit à zéro le tampon de temps qui permettait de les corriger en ordre.
Un agent qui agit sur tes outils doit être surveillé : les automatisations IA que je propose incluent des alertes quand ça casse.