Le gouvernement vient d’interdire un modèle d’IA. Le point de vue d’un ingénieur.

Depuis près de trois ans, j’intègre l’IA aux méthodes de développement et de déploiement de mes équipes. Alors, quand j’ai appris cette semaine que le gouvernement américain avait, de fait, coupé l’accès à un modèle d’IA, j’ai été sincèrement stupéfait. Pas pour un seul pays. Pas pour une seule entreprise. Pour tout le monde, partout dans le monde, en même temps.

Trois jours. C’est le temps pendant lequel les modèles Fable 5 et Mythos 5 d’Anthropic ont été disponibles avant que le gouvernement n’ordonne leur désactivation pour tout le monde.

Pas restreints. Pas soumis à des contrôles à l’exportation pour une liste de pays. Désactivés. Complètement. Pour tous les utilisateurs. L’ordre visait techniquement l’accès des ressortissants étrangers, mais Anthropic n’avait aucun moyen fiable de distinguer en temps réel les ressortissants étrangers des personnes américaines. Pour s’y conformer, l’entreprise a donc retiré les deux modèles pour tout le monde. Ils ont été lancés le 9 juin. Le 12 juin, ils avaient disparu.

Si vous travaillez dans la sécurité, vous devriez y prêter toute votre attention. Pas à cause des enjeux politiques. Mais parce que cet événement nous montre où nous en sommes et où nous allons.

Que s’est-il passé ?

Voici les grandes lignes.

Mythos 5 s’est révélé exceptionnellement doué pour détecter les vulnérabilités logicielles. Vraiment très doué. Au point de déceler des bogues enfouis dans des bases de code depuis des décennies. Puis un chercheur a découvert un jailbreak qui a débloqué ces capacités de détection des vulnérabilités d’une manière qu’Anthropic n’avait jamais prévue. Le gouvernement a jugé qu’il s’agissait d’un risque pour la sécurité nationale, craignant que des adversaires utilisent Mythos pour découvrir des vulnérabilités zero-day et les exploiter à grande échelle.

Le gouvernement a donc émis une directive de contrôle des exportations et, comme Anthropic ne pouvait pas distinguer de façon fiable les personnes américaines des autres, l’entreprise n’avait pas vraiment le choix. Elle a désactivé Fable 5 et Mythos 5 pour tout le monde.

Anthropic conteste la gravité réelle de la situation. L’entreprise estime que le jailbreak était limité et que la réponse était totalement disproportionnée. On peut raisonnablement en débattre, et mon collègue Stephen Thoemmes a publié un compte rendu détaillé des événements : ce qui s’est exactement passé et la façon dont le secteur de la sécurité a toujours géré les capacités à double usage. Lisez son article pour comprendre les faits. Ici, je veux parler de ce que cela signifie.

Problème n° 1 : votre fournisseur d’IA est désormais un risque dans votre chaîne d’approvisionnement

Parlons de ce dont personne n’a envie de parler.

Si votre équipe d’ingénierie avait intégré Fable 5 ou Mythos 5 à un flux de travail — revue de code, triage des vulnérabilités, analyse de sécurité, peu importe —, le 12 juin, vous vous êtes réveillé et cette capacité avait tout simplement… disparu. Pas d’avis de fin de service. Pas de période de transition. Pas de « nous maintiendrons le service pendant 90 jours, le temps que vous trouviez une solution de remplacement ». Juste disparue.

C’est un incident de chaîne d’approvisionnement.

Depuis des années, le secteur apprend, parfois à ses dépens, à quel point nos chaînes d’approvisionnement logicielles sont fragiles. Nous avons vu une seule personne responsable d’un projet supprimer en masse des paquets npm et paralyser la moitié d’Internet. Nous avons vécu SolarWinds. Log4Shell. Nous avons créé des SBOM et des outils d’analyse des dépendances, ainsi que toute une catégorie d’outils pour gérer le risque de voir le code de quelqu’un d’autre disparaître ou devenir malveillant sous nos yeux.

Alors, voici ma question : combien d’entre nous appliquent cette même rigueur à l’accès aux modèles d’IA ?

La plupart des équipes considèrent l’accès aux modèles d’IA comme un service public. Vous vous inscrivez, vous obtenez une clé API, vous l’intégrez à votre flux de travail et vous partez tranquillement du principe qu’il sera toujours là demain. Cette semaine a fait voler cette hypothèse en éclats. Et contrairement à une bibliothèque que vous pouvez figer à une version donnée et intégrer à votre dépôt, vous ne pouvez pas mettre en cache un modèle qui tourne sur les serveurs de quelqu’un d’autre. Quand il disparaît, il disparaît.

C’est le problème sur lequel mon équipe travaille chaque jour chez Snyk : intégrer la sécurité à votre code et à vos agents, pour que vous ne dépendiez pas, en pratique, du modèle que vous avez choisi en premier. La mesure concrète à retenir n’a rien de spectaculaire, mais elle est essentielle : traitez l’accès aux modèles comme n’importe quelle dépendance que vous ne maîtrisez pas. Prévoyez une solution de secours. Ajoutez une couche d’abstraction. Ayez un plan pour le lendemain où le modèle disparaît.

Problème n° 2 : interdire les capacités défensives n’arrête pas les attaquants

Passons maintenant à la cybersécurité, où la situation devient vraiment inconfortable.

La préoccupation du gouvernement est assez simple. Mythos 5 est si doué pour détecter les vulnérabilités que des adversaires qui y auraient accès pourraient découvrir et exploiter des zero-days plus vite que jamais. C’est une vraie préoccupation. Je ne vais pas la balayer d’un revers de main.

Mais voici la question que je n’ai pas entendu poser assez souvent : qui est réellement pénalisé quand on interdit un outil capable de détecter les vulnérabilités ?

Les attaquants qui veulent trouver et exploiter des vulnérabilités ne vont pas remplir de formulaires et se conformer à une directive de contrôle des exportations. Ils ne l’ont jamais fait. C’est précisément ce qui définit un attaquant. Ils ne respectent pas les règles. Si un Mythos jailbreaké peut découvrir des zero-days, cette capacité est déjà accessible. Le jailbreak a été publié. Impossible de revenir en arrière.

Alors, qui est pénalisé ? Les défenseurs. Les chercheurs en sécurité. Les équipes d’entreprises comme la vôtre, qui s’efforcent de trouver et de corriger les vulnérabilités avant les acteurs malveillants.

La cybersécurité a toujours été une course aux armements. Elle l’est depuis les débuts du secteur. La sécurité moderne des applications repose entièrement sur l’idée que les défenseurs doivent disposer d’au moins autant de capacités que les attaquants, et idéalement de meilleures. Vous analysez votre propre code avant que quelqu’un d’autre ne le fasse. Vous testez vos propres systèmes d’intrusion. Vous lancez les mêmes outils qu’un attaquant sur votre propre infrastructure, pour trouver les failles avant lui.

Retirez cette capacité à toutes les personnes qui respectent les règles : vous ne ralentirez pas du tout les attaquants. Vous affaiblirez simplement les défenseurs. Et presque tout ce qui compte en sécurité peut être utilisé à double fin ; c’est dans la nature même du domaine. L’article de Stephen explique comment le secteur a toujours géré cette tension, de la divulgation coordonnée aux mesures de contrôle à plusieurs niveaux. Voici ma version courte : chaque fois que vous supprimez une capacité parce qu’elle pourrait être détournée, l’interrupteur finit par pénaliser les personnes qui défendent réellement les systèmes.

Cela crée un précédent dangereux

Soyons clairs. Je comprends pourquoi le gouvernement est intervenu. La sécurité nationale est un enjeu majeur, et l’idée que des États hostiles puissent s’appuyer sur une IA qui génère des zero-days est réellement effrayante. Ces inquiétudes ne sont pas futiles.

Mais le précédent m’inquiète davantage que l’incident.

Nous avons désormais établi qu’un modèle d’IA peut être désactivé pour tout le monde, dans le monde entier, sans préavis, à cause d’un scénario de détournement potentiel. Pas une attaque réelle. Pas une violation confirmée. Un jailbreak qui pourrait, en théorie, servir à faire du mal.

Prolongeons ce raisonnement. Que se passe-t-il si le prochain modèle détecte remarquablement bien les anomalies du trafic réseau, mais que cette même capacité peut être détournée à des fins de surveillance ? Que se passe-t-il si un modèle excelle dans la génération de correctifs de sécurité, mais peut aussi, en théorie, être amené à générer du code d’exploitation ? Presque toutes les capacités réellement utiles en sécurité sont, par nature, à double usage. Ce n’est pas un défaut. C’est inhérent à notre domaine.

Réagissez ainsi à chaque fois, et les défenseurs finiront par se battre avec une main attachée dans le dos, tandis que les attaquants, qui n’auraient de toute façon jamais respecté un contrôle des exportations, garderont les deux mains libres.

Personne n’en sortira plus en sécurité. Nous aurons simplement l’impression d’avoir agi.

Ce que le secteur de la sécurité doit faire correctement

Alors, comment avancer ? Je ne prétends pas avoir toutes les réponses, mais voici quelques idées qui méritent d’être exprimées.

Nous avons besoin d’un véritable cadre pour les capacités d’IA à double usage. « Interdisons tout, puisque nous ne savons pas contrôler les accès » est une réponse brutale. Depuis des décennies, nous gérons cette tension par la divulgation responsable, les licences, les cadres juridiques et les normes communautaires, et non en interdisant les outils eux-mêmes. Nous devons apporter la même nuance à l’IA, au lieu de nous précipiter sur l’interrupteur.

La communauté de la sécurité doit participer aux discussions. Cette décision a été prise par des responsables du commerce, et non par les personnes qui réfléchissent chaque jour à la sécurisation concrète des logiciels. Ce n’est pas une critique du ministère du Commerce. Les contrôles à l’exportation relèvent de sa mission. Mais leurs répercussions sur la sécurité défensive sont considérables, et les personnes qui les comprennent doivent avoir leur mot à dire avant la prochaine décision, pas après.

Les entreprises doivent dès maintenant renforcer la résilience de leur stratégie d’IA. N’attendez pas que le prochain modèle soit retiré. Si vous bâtissez des flux de travail critiques sur une IA que vous ne contrôlez pas, vous devez prévoir des solutions de secours dès aujourd’hui : stratégies multi-fournisseurs, couches d’abstraction, solutions de repli. Traitez cela pour ce que c’est vraiment : un risque de chaîne d’approvisionnement.

Et, chez Snyk, toute notre philosophie repose sur cette idée : mettre des outils de sécurité entre les mains des développeurs, et désormais des agents d’IA, rend les logiciels plus sûrs, pas moins. Plus il y a de personnes capables de détecter et de corriger les vulnérabilités, plus tout le monde est en sécurité. Cela s’est vérifié avec l’analyse statique, les bases de données de vulnérabilités open source et toutes les capacités de sécurité que nous avons réussi à démocratiser. Je suis convaincu qu’il en ira de même pour la sécurité basée sur l’IA.

À « cet outil est puissant », la réponse devrait être : « veillons à ce que les bonnes personnes puissent l’utiliser de manière responsable ». Pas : « veillons à ce que personne ne puisse l’utiliser ».

Le temps presse

Nous sommes à un tournant. Les capacités de l’IA en matière de sécurité progressent rapidement, et les cadres réglementaires peinent à suivre. C’est dans cet écart entre ce que la technologie permet et ce que les règles autorisent que réside le véritable risque.

L’interdiction de Fable 5 et Mythos 5 cette semaine annonce un débat bien plus vaste, qui va nous occuper pendant des années. La façon dont nous gérons l’IA à double usage en cybersécurité déterminera si les défenseurs restent au niveau des attaquants ou prennent un retard irrémédiable.

Je préfère que nous prenions le temps de bien faire les choses plutôt que d’aller vite. Mais nous devons lancer le débat dès maintenant, car les décisions que nous prenons aujourd’hui façonneront le paysage de la sécurité pendant longtemps.

Et en attendant ? Vérifiez vos dépendances à l’IA. Vraiment. Tout de suite. Car si cette semaine nous a appris quelque chose, c’est que le modèle sur lequel vous comptez aujourd’hui pourrait ne plus être là demain.