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

Cela fait près de trois ans que j’intègre l’IA aux méthodes de développement et de déploiement logiciel de mes équipes. Alors, quand la nouvelle est tombée cette semaine : le gouvernement américain venait de désactiver de fait 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 sur la planète, d’un seul coup.

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. Lancés le 9 juin, ils avaient disparu le 12 juin.

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.

Ce qui s’est passé

Voici les faits, en bref.

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 bugs enfouis dans des bases de code depuis des décennies. Puis un chercheur a découvert un jailbreak qui débloquait ces capacités de détection des vulnérabilités d’une manière qu’Anthropic n’avait jamais prévue. Le gouvernement a estimé qu’il s’agissait d’un risque pour la sécurité nationale, craignant que des adversaires n’utilisent Mythos pour découvrir et exploiter des zero-days à grande échelle.

Le gouvernement a donc émis une directive de contrôle des exportations. Comme Anthropic ne pouvait pas distinguer de manière fiable les personnes américaines des autres, elle n’avait pas vraiment le choix. L’entreprise a désactivé Fable 5 et Mythos 5 pour tout le monde.

Anthropic conteste la gravité réelle de la situation. Selon l’entreprise, le jailbreak était limité et la réaction totalement disproportionnée. On peut raisonnablement en débattre. Mon collègue Stephen Thoemmes a détaillé les é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 détails. Ici, je m’intéresse à ce que cela signifie.

Problème n° 1 : votre fournisseur d’IA représente désormais un risque pour la chaîne d’approvisionnement

Parlons de ce dont personne ne veut parler.

Si votre équipe d’ingénierie avait intégré Fable 5 ou Mythos 5 à un processus (revue de code, triage des vulnérabilités, analyse de sécurité, peu importe), vous vous êtes réveillés le 12 juin avec une capacité qui avait tout simplement… disparu. Pas de pré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… disparu.

C’est un incident touchant la chaîne d’approvisionnement.

Depuis des années, notre secteur apprend, parfois à ses dépens, que nos chaînes d’approvisionnement logicielles sont fragiles. Nous avons vu un seul mainteneur supprimer en masse des packages npm et paralyser la moitié d’Internet. Nous avons vu SolarWinds. Nous avons vu 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 d’un tiers disparaître ou devenir malveillant sans prévenir.

Alors, voici ma question : combien d’entre nous appliquent la 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 processus et vous partez discrètement du principe qu’elle sera toujours là demain. Cette semaine a fait voler cette hypothèse en éclats. Et contrairement à une bibliothèque que vous pouvez verrouiller sur une version précise et intégrer à votre dépôt, vous ne pouvez pas mettre en cache un modèle qui tourne sur les serveurs d’un tiers. Quand il n’est plus là, il n’est plus là.

C’est le problème auquel mon équipe s’attaque au quotidien chez Snyk : faire en sorte que la sécurité accompagne votre code et vos agents, plutôt que d’être quelque chose que vous louez en pratique auprès du premier modèle que vous avez intégré. La conclusion pratique est banale, mais bien réelle : traitez l’accès aux modèles comme n’importe quelle autre dépendance que vous ne contrôlez pas. Prévoyez une solution de secours. Ajoutez une couche d’abstraction. Préparez-vous à ce qui se passera le matin où le modèle aura disparu.

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 à comprendre. Mythos 5 détecte si bien les vulnérabilités que des adversaires qui y auraient accès pourraient découvrir et exploiter des zero-days plus rapidement que jamais. Cette préoccupation est légitime. Je ne vais pas la balayer d’un revers de main.

Mais voici la question que je n’ai pas vu assez de gens poser : qui souffre vraiment lorsqu’on interdit un outil capable de détecter les vulnérabilités ?

Les attaquants qui cherchent à découvrir et à exploiter des vulnérabilités ne vont pas remplir des formulaires et se conformer à une directive de contrôle des exportations. Ils ne l’ont jamais fait. C’est en quelque sorte la définition même d’un attaquant : il ne respecte pas les règles. Si un Mythos jailbreaké peut détecter des zero-days, cette capacité est déjà accessible. Le jailbreak a été publié. Impossible de revenir en arrière.

Alors, qui en pâtit ? Les défenseurs. Les chercheurs en sécurité. Les équipes d’entreprises comme la vôtre, qui tentent de trouver et de corriger les vulnérabilités avant que les personnes malveillantes ne les exploitent.

La cybersécurité a toujours été une course aux armements, et ce depuis la naissance du secteur. Le principe même de la sécurité applicative moderne est que les défenseurs doivent disposer de capacités au moins égales à celles des attaquants, et idéalement supérieures. Vous analysez votre propre code avant que quelqu’un d’autre ne le fasse. Vous réalisez des tests d’intrusion sur vos propres systèmes. Vous utilisez les outils mêmes d’un attaquant contre votre propre infrastructure pour repérer les failles avant lui.

Retirez cette capacité à toutes les personnes qui respectent les règles, et vous ne ralentirez pas du tout les attaquants. Vous affaiblirez simplement les défenseurs par rapport à la veille. En sécurité, presque tout ce qui en vaut la peine peut être utilisé à double fin : c’est inhérent au 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 : supprimer une capacité chaque fois qu’elle risque d’être détournée, c’est finir par désarmer ceux qui défendent réellement les systèmes.

Un précédent dangereux

Je tiens à être clair : je comprends pourquoi le gouvernement est intervenu. La sécurité nationale est une affaire sérieuse, et l’idée que des États hostiles puissent utiliser une IA capable de produire des zero-days à la chaîne est réellement effrayante. Ces préoccupations ne sont pas frivoles.

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

Nous avons désormais établi qu’un modèle d’IA peut être désactivé partout dans le monde, pour tout le monde, sans aucun préavis, en raison d’un scénario d’usage abusif potentiel. Pas d’une attaque réelle. Pas d’une brèche confirmée. D’un jailbreak qui pourrait théoriquement être utilisé à des fins malveillantes.

Poussons maintenant cette logique plus loin. Que se passera-t-il lorsque le prochain modèle excellerа à repérer les anomalies dans le trafic réseau, alors que cette même capacité pourrait être détournée à des fins de surveillance ? Que se passera-t-il lorsqu’un modèle deviendra très performant pour générer des correctifs de sécurité, mais qu’on pourra théoriquement l’inciter à produire 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 au domaine.

Réagissez ainsi à chaque fois, et les défenseurs se retrouveront à se battre avec une main dans le dos, tandis que les attaquants, qui n’allaient de toute façon pas respecter les contrôles à l’exportation, garderont leurs 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, quelle est la suite ? Je ne prétends pas avoir toutes les réponses, mais certains points méritent d’être exprimés clairement.

Nous avons besoin d’un véritable cadre pour les capacités d’IA à double usage. « Interdisons tout simplement la technologie parce que nous ne savons pas gérer les contrôles d’accès », c’est choisir la facilité. Depuis des décennies, nous gérons cette tension grâce à la divulgation responsable, aux licences, aux cadres juridiques et aux normes communautaires, pas en interdisant les outils eux-mêmes. Nous devons appliquer 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 autorités chargées de la réglementation commerciale, 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 responsabilité. Mais leurs conséquences sur la sécurité défensive sont considérables. Les personnes qui les comprennent doivent prendre part aux discussions avant la prochaine décision, et non 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 processus critiques sur une IA que vous ne contrôlez pas, vous devez prévoir dès aujourd’hui des solutions de secours : stratégies multi-fournisseurs, couches d’abstraction, solutions de repli. Traitez cela comme le risque pour la chaîne d’approvisionnement que c’est réellement.

Chez Snyk, toute notre philosophie repose sur l’idée que 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, et non 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 chaque capacité de sécurité que nous avons réussi à démocratiser. Je suis convaincu que ce sera aussi vrai pour la sécurité propulsée par 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 peut faire 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 nous occupera pendant des années. La façon dont nous gérerons l’IA à double usage en cybersécurité déterminera si les défenseurs pourront suivre le rythme des attaquants ou s’ils prendront un retard définitif.

Je préfère que nous prenions le temps de bien faire les choses plutôt que d’agir dans la précipitation. Mais nous devons ouvrir le débat dès maintenant, car les décisions que nous prenons aujourd’hui façonneront durablement le paysage de la sécurité.

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