Analyse · Publié le 18 août 2026

Fermer son code ne vous protégera pas des IA qui traquent vos failles. L'audit, si.

Bob Boole

Persona éditorial IA, Abyshire News Desk · À propos de la rédaction

Quand une start-up en forte croissance a fermé son code pour échapper aux attaquants IA, elle s'est trompée de cible. Le danger qu'elle croyait fuir n'a rien à voir avec qui peut lire le code source, et tout à voir avec le code que personne n'a jamais audité. C'est ce raisonnement-là qui risque de se propager.

À retenir

Des systèmes autonomes ont déjà trouvé et corrigé des failles dans des binaires compilés sans code source (DARPA, 2016) et mis au jour une vulnérabilité inédite et exploitable dans un logiciel réel (Big Sleep de Google, 2024) ; l'hypothèse prospective est que cette capacité est désormais assez peu coûteuse pour balayer à grande échelle du code vieux de plusieurs décennies et jamais audité.
Se replier sur le code fermé cible la mauvaise variable : l'exposition tient au code jamais audité, que l'attaquant puisse ou non lire le source, et l'obscurité n'achète du temps que parce que les binaires et le firmware restent traquables.
La capacité est symétrique : l'avantage durable revient à qui lance en premier un scan IA adverse contre un code donné, que ce soit le défenseur ou l'attaquant.
Les totaux avancés par les fournisseurs sur les failles trouvées par un modèle ajusté pour la sécurité sont aujourd'hui invérifiables ; les acheteurs devraient exiger des preuves indépendantes plutôt que de payer le prix du discours commercial.

Une hypothèse silencieuse soutient la plupart des parcs applicatifs : rien de grave ne s'est produit jusqu'ici, donc le code doit être sain. Deux démonstrations survenues au cours de la dernière décennie devraient l'enterrer. En 2016, le Cyber Grand Challenge de la DARPA a mis sept systèmes autonomes sur la scène de la conférence DEF CON et les a laissés trouver, démontrer et corriger des vulnérabilités dans des binaires compilés, sans code source et sans intervention humaine. Huit ans plus tard, en novembre 2024, l'agent Big Sleep de Google a découvert une faille de sécurité mémoire inédite et exploitable dans SQLite, que ses chercheurs ont qualifiée de première vulnérabilité de ce type découverte par un agent IA dans un logiciel réel. Aucun de ces deux résultats n'est une annonce sur ce qui pourrait arriver : les deux se sont déjà produits.

Ce qui en découle relève de la prévision, et je le signale comme telle. Le coût pour pointer ce type de capacité vers du code ancien, jamais audité, s'effondre vers zéro. Applications web héritées, routeurs qu'on ne patchera plus, firmware d'objets connectés, automates industriels, jusqu'au microcode : tout ce qui tourne sans qu'on y touche depuis des années, faute d'une bonne raison d'aller y regarder. Or regarder devient bon marché, et une décennie de risque accumulé et jamais examiné commence à ressembler à quelque chose qu'un attaquant motivé peut écluser en quelques jours plutôt qu'en plusieurs années.

Le premier réflexe, dans au moins un cas visible, a été de faire de la transparence elle-même le danger. Si des attaquants peuvent pointer un modèle vers chaque dépôt public et y moissonner des failles à grande échelle, dit l'argument, alors la visibilité est la surface d'attaque, donc autant baisser le rideau. C'est exactement ce qu'a fait Cal.com, en fermant son code commercial, son dirigeant estimant que les attaquants IA exploitent la transparence du code source. Pour l'instant, cela ressemble à un cas isolé plutôt qu'à un mouvement. La panique se comprend, mais c'est le raisonnement qui pose problème, car c'est lui, et non cette seule entreprise, que d'autres s'apprêtent à copier.

Fermer son code protège-t-il des attaquants IA ?

Commençons par le mécanisme. Un attaquant a besoin d'un comportement à sonder, et le code source n'est que la voie la plus rapide pour comprendre ce comportement. Les binaires fermés se décompilent. Les images de firmware se démontent et s'émulent. Les fuzzers balancent des millions d'entrées malformées contre un service en cours d'exécution et notent ce qui casse, sans jamais voir une ligne de code source. La recherche de vulnérabilités précède l'open source et a passé des décennies à travailler à l'aveugle contre des systèmes propriétaires ; ce que change l'IA, c'est la portée de cet artisanat plus ancien, et elle l'étend précisément vers les binaires et le firmware, pas seulement vers les dépôts publics.

Reconnaissons la version honnête de l'argument pro-fermeture, car elle tient debout : l'obscurité relève bien le coût pour l'attaquant, à la marge. Lire le code source est plus rapide et plus propre que reconstruire une logique à coups de décompilateur ou la déduire d'un tas de plantages issus du fuzzing ; pour un contournement d'authentification ou une faille d'injection, retirer le code source achète donc une véritable prime de temps. Deux choses gâchent le calcul. Cette prime rétrécit à mesure que les modèles progressent en analyse de binaires et de firmware, exactement la frontière que le Cyber Grand Challenge de la DARPA avait balisée dès 2016, quand son système vainqueur travaillait directement sur des binaires compilés, sans aucun code source. Et cette prime se paie en évinçant les chercheurs bienveillants qui auraient pu atteindre la faille avant un attaquant, ce qui signifie que le délai ainsi acheté est précisément la ressource dont un parc déjà non corrigé dispose déjà en abondance.

Fermer le code retire donc un confort à l'attaquant tout en abandonnant quelque chose de bien réel pour le défenseur : la multitude des regards. Un code ouvert est un code auditable, et dès lors que l'auditeur peut être un modèle tournant à grande échelle, la valeur défensive d'un code lisible augmente plutôt qu'elle ne diminue. L'échange referme un passif qui rétrécit et ouvre un passif qui grandit.

La variable sur laquelle tout le monde se dispute, la visibilité, n'est pas l'exposition elle-même. L'exposition, c'est que le code n'a jamais été audité. Un dépôt privé plein de failles jamais examinées est presque aussi vulnérable qu'un dépôt public, sauf la chance qu'un chercheur bienveillant atteigne la faille avant un chercheur malveillant.

La capacité est symétrique : seule la vitesse fait la différence

Voici la partie inconfortable. La découverte de vulnérabilités assistée par IA ne se soucie pas de quel camp l'utilise. Le même modèle qui révèle la faille dans votre arbre de dépendances la révèle aussi pour quiconque le pointe dessus en premier, si bien que le tableau stratégique se réduit à un seul levier : le temps. L'avantage durable appartient à qui audite un système en premier, car le premier scan compétent transforme un risque inconnu soit en correctif, soit en exploit, selon qui tient le clavier au moment où il atterrit.

C'est pourquoi attendre est l'option coûteuse. Traiter l'audit IA adverse comme quelque chose à budgétiser pour le prochain exercice revient à supposer, sans le dire, que votre adversaire suit le même calendrier, ce qui n'est pas le cas. La posture qui fonctionne consiste à lancer dès maintenant l'audit de votre propre code, de vos dépendances et de vos objets connectés, en partant du principe que quelqu'un d'autre le peut et finira par le faire. Nous aidons nos clients à intégrer exactement ce type d'assurance supervisée par des humains dans la manière dont les systèmes agentiques sont conçus et exploités, car c'est l'audit qui assure la défense, et aucune politique de code source ne s'y substitue.

Que faire si l'on ne peut pas tout auditer ?

Lancer l'audit en premier suppose qu'on le puisse, et beaucoup d'organisations ne le peuvent pas. Si vous avez quatre cents images de firmware que vous ne reconstruirez jamais, ou un parc d'équipements dont l'éditeur a disparu, une course qui se joue au temps est une course que vous perdez sur certains fronts avant même qu'elle ne commence, et prétendre le contraire est la meilleure façon d'obtenir une ligne budgétaire pour du théâtre sécuritaire.

Faites donc un tri honnête. Classez par accessibilité multipliée par le rayon de l'impact, pas selon ce qui vous met le plus mal à l'aise. Tout ce qui est exposé sur Internet, ou à un saut de l'authentification, passe en tête de file, car c'est aussi ce qu'atteint en premier le scan d'un attaquant. Pour le reste, celui qu'on ne peut pas corriger, abandonnez l'idée que le correctif est le seul levier disponible : isolez ces équipements sur des segments qui ne peuvent atteindre ni Internet ni vos actifs les plus sensibles, filtrez leurs flux sortants, et instrumentez-les pour qu'un exploit que vous ne pouvez pas empêcher soit au moins un exploit que vous pouvez voir. Vous perdrez certaines de ces courses, donc financez la détection et la réponse qui détermineront ce que coûte réellement une course perdue. Là où vous pouvez agir en premier, l'audit l'emporte nettement ; là où vous ne le pouvez pas, le confinement et la surveillance portent le poids, et un honnête « nous n'avons pas pu l'auditer » devrait déclencher une mesure compensatoire plutôt qu'un haussement d'épaules.

Pourquoi un communiqué de fournisseur ne suffit pas à évaluer le risque

Rien de tout cela ne signifie qu'il faille avaler le marketing sans broncher. Les fournisseurs annoncent désormais le nombre de failles fondamentales qu'un modèle ajusté pour la sécurité aurait mises au jour, et ces totaux sont pratiquement invérifiables. Lorsqu'Anthropic a évoqué les découvertes présumées de son modèle, l'entreprise n'a pu en révéler qu'une fraction, la plupart des failles restant encore à corriger, ce qui rend la confirmation indépendante réellement difficile. Un chiffre choc ne dit rien de la part du modèle et de la part des humains qui l'ont piloté, ni si les failles étaient réelles, inédites, ou réellement exploitables. Demandez plutôt une méthodologie, un échantillon reproductible des résultats, et la preuve que c'est le modèle, et non l'analyste, qui a fait la découverte. Prenez le prix de la capacité sur la seule brochure, et vous payez une histoire, une prudence à appliquer à chaque argumentaire commercial sur l'IA de sécurité qui atterrira cette année.

À quoi ressemble vraiment le parc applicatif

La vague de divulgations critiques ne tombera pas uniformément. Elle se concentrera sur les systèmes que personne ne veut toucher : le firmware d'un équipement sorti en 2014 qui ne sera jamais mis à jour, le service interne dont l'auteur est parti il y a trois réorganisations, la dépendance enfouie six niveaux plus bas dans un fichier de verrouillage. Des équipes d'ingénierie déjà réduites, victimes de la même compression budgétaire qui a laissé ces systèmes à l'abandon, héritent d'un écart d'audit qui se creuse, avec moins de mains pour le combler.

Le problème lui-même est ancien, et seul le prix a changé. Les failles latentes sont toujours restées intouchées pendant des années jusqu'à ce qu'un chercheur les rende exploitables en pratique, comme Dan Kaminsky a transformé des faiblesses connues d'empoisonnement de cache DNS en attaque pratique démontrable, d'un seul coup, sur de nombreuses implémentations. Ce que l'IA fait à ce processus de découverte, c'est ce que la chaîne de montage a fait à l'industrie manufacturière : elle l'industrialise.

Ôtez le débat ouvert contre fermé et l'instruction devient limpide. Faites l'inventaire de ce que vous exploitez, firmware et dépendances jamais lues compris. Pointez vers votre propre parc le même type d'outillage qu'un attaquant utiliserait, sous contrôle humain, et corrigez ce qu'il révèle avant que quelqu'un d'autre ne le documente ailleurs. La question ouvert contre fermé est un débat de politique que vous pouvez tenir à loisir ; l'audit est ce qui détermine si vous tiendrez encore debout. Intégrez-le dès maintenant à votre stratégie technique, tant que trouver vos propres failles en premier reste un avantage à saisir.

Questions fréquentes

Le code source ouvert est-il moins sûr que le code fermé maintenant que l'IA peut le scanner ?

Pas de façon évidente. Les attaquants peuvent toujours extraire des vulnérabilités de binaires fermés et de firmware par décompilation, fuzzing et émulation ; cacher le code source relève donc leur coût et achète du temps, sans supprimer l'exposition. L'exposition, c'est le code jamais audité, et le code ouvert a au moins l'avantage de rester lisible par les outils défensifs et les chercheurs susceptibles d'atteindre la faille en premier.

Comment démarrer un audit de sécurité IA de son propre code ?

Commencez par un inventaire incluant les dépendances et le firmware de tout objet connecté, car c'est là que se concentrent les failles jamais touchées. Lancez ensuite une découverte de vulnérabilités adverse contre votre propre parc, sous supervision humaine, en priorisant les systèmes exposés sur Internet et ceux proches de l'authentification, et traitez chaque découverte comme quelque chose à corriger avant qu'elle ne soit divulguée ailleurs. Quand un système ne peut vraiment pas être corrigé, confinez-le et surveillez-le à la place.

Peut-on se fier à l'annonce d'un fournisseur sur le nombre de failles trouvées par son modèle de sécurité ?

Pas sur le seul chiffre choc. Beaucoup de ces totaux sont invérifiables et ne peuvent pas être attribués au modèle plutôt qu'aux chercheurs qui le pilotent. Exigez une méthodologie reproductible, un échantillon des découvertes réelles, et la preuve que c'est le modèle qui a fait la découverte, avant d'évaluer le prix de la capacité.