Claude AI, le Yémen et la nouvelle course aux armements de l'IA : quand les agents de code entrent dans les conflits modernes
Renseignement sur les menaces · 12 septembre 2026
La guerre est entrée dans la fenêtre de chat
Une cellule d'armement du nord du Yémen a fait passer trois programmes de missiles par un assistant de code. Les refus du modèle n'ont pas mis fin à l'histoire. Ils ont simplement changé le routage.
Le 11 septembre 2026, Anthropic a publié un rapport de renseignement sur les menaces couvrant décembre 2025 à août 2026. La presse a surtout retenu les groupes de rançongiciels. Le cas le plus important tient en quatre paragraphes et se déroule au Yémen.
Une cellule de développement d'armes dans le nord du Yémen, sous contrôle houthi, a utilisé Claude pour développer des logiciels de guidage, de navigation et de contrôle destinés à des engins volants. Pas une expérience de pensée. Trois programmes menés en parallèle :
Ils n'ont pas travaillé dans un seul chat. Ils ont lancé plusieurs instances en parallèle et réparti le travail : une pour le code, une pour la recherche, une pour la relecture. Tout ingénieur ayant monté un pipeline multi-agents reconnaît immédiatement cette forme, parce que c'est celle que nous utilisons pour livrer un produit SaaS en un week-end.
Ils ont ensuite testé la roquette guidée sur le terrain, et l'essai a échoué. Selon le rapport, en quelques heures les opérateurs étaient de retour devant le modèle pour comprendre pourquoi. Ce détail résume tout l'article. La boucle de débogage qui rend un développeur junior productif transforme un essai raté en révision.
Ce qui a réellement franchi la restriction
Anthropic a banni les comptes et affirme n'avoir aucune preuve qu'un engin opérationnel ait été déployé. Le rapport reconnaît aussi, en clair, que toutes les tentatives de blocage n'ont pas abouti et que la cellule avait déjà construit une chaîne de simulation hors ligne qui ne dépendait pas de Claude.
On imagine l'échec d'un garde-fou comme une phrase magique qui débloque une réponse interdite. Dans les cas documentés, ce n'est jamais cela. C'est de l'architecture. Quatre schémas reviennent, et chacun relève de la conception système, pas du prompt astucieux :
Les quatre surfaces de défaillance
1. Décomposition. Un refus se déclenche sur l'intention. L'intention réside dans la tâche entière, pas dans ses morceaux. Une boucle d'asservissement, un filtre de Kalman, un pilote d'actionneur et un changement de repère sont des problèmes d'ingénierie ordinaires pris séparément. L'assemblage se fait sur le portable de l'opérateur, là où aucun classifieur ne regarde.
2. Double usage. Guidage, navigation et contrôle, c'est un programme universitaire. Les mathématiques d'un engin volant stabilisé sont celles d'un drone de livraison. Un modèle ne lit pas le site de lancement dans une équation différentielle.
3. Transfert de capacité hors ligne. C'est le point que le secteur sous-estime le plus. Une fois que le modèle a aidé à bâtir le simulateur, le banc de test et la chaîne d'outils, il devient optionnel. La capacité a quitté la plateforme. Bannir le compte ne la rappelle pas.
4. Accès emprunté. Ailleurs dans le même rapport, des groupes ont récolté des clés API dans des applications mobiles, des images Docker et des dépôts publics, puis ont mené leurs opérations sur le compte d'autrui. Une équipe a analysé 1,8 million d'APK à la recherche de secrets en dur. Une autre a visé une trentaine d'entreprises d'IA en quatre jours en injectant des instructions dans des bacs à sable d'évaluation automatisés pour extraire des clés de production.
Relisez le dernier point, car c'est celui qui atterrit sur votre bureau et non sur celui d'une équipe juridique. La protection n'a jamais été contournée au niveau du modèle. Elle l'a été au niveau de la clé. Et la clé se trouvait dans un APK livré, poussé par un développeur pressé.
Le reste du rapport est un problème de développeurs
| Cas | Rôle de l'IA | Ampleur |
|---|---|---|
| Espionnage d'État russe | Développement automatisé de maliciels, réécriture des charges dès détection | 20+ organisations, 300 000+ dossiers d'identité |
| Collectif criminel | Recherche massive de secrets, compromission de chaîne d'approvisionnement en quelques heures | 1,8 M d'applications analysées, plus d'1 To exfiltré |
| Atelier d'exploits | Essaims d'agents autonomes pour la reconnaissance et l'analyse binaire | ~50 cibles, flotte de 13 agents |
| Hacktiviste isolé | A bâti seul une plateforme de doxxing complète avec pipelines d'ingestion | 14 cibles compromises, 12 à 26 Go |
Une seule personne a construit une plateforme d'attaque de masse. L'écart entre un service de renseignement étatique et un individu motivé muni d'une clé API relève désormais surtout de la patience, plus de la capacité.
Ce que je fais concrètement quand je construis des systèmes d'agents
Les clés ne vivent jamais côté client
Aucune clé de modèle dans un bundle mobile, un build front, une couche Docker ou un dépôt. Chaque appel passe par une route serveur. Jetons de courte durée, rotation planifiée, alerte sur les anomalies de dépense : une clé volée se voit d'abord sur la facture.
Tout document récupéré est une entrée hostile
Les attaques contre les bacs à sable d'évaluation reposaient sur l'injection : des instructions cachées dans du contenu qu'un système automatisé a lu et exécuté. Si votre agent lit un PDF, une page web, un ticket ou une pull request, ce texte est une donnée non fiable et n'entre jamais dans le canal d'instructions.
Limiter les outils, pas le prompt
Un prompt est une suggestion. Un outil qui ne peut lire que trois tables et écrire que dans une file est une contrainte. Les limites de capacité appartiennent à la couche outils, avec une liste blanche de sortie réseau pour qu'un agent compromis ne puisse pas rappeler chez lui.
Validation humaine sur les actions irréversibles
Paiements, suppressions, déploiements, messages aux clients. L'agent propose, une personne approuve. L'avantage de la cellule yéménite tenait à une boucle sans frottement. Le frottement est une fonctionnalité quand l'action est irréversible.
Journaliser toute la trajectoire
Prompt, appels d'outils, arguments, résultats, coût, identité de session. Si vous ne pouvez pas reconstituer ce que votre agent a fait mardi dernier, vous ne pouvez répondre ni à un client ni à un régulateur.
La direction du rapport est claire : moins de supervision humaine, plus d'autonomie, un coût par cible en baisse. Quand attaquer une cible marginale devient bon marché, chaque petite entreprise devient une cible, et cette entreprise fait tourner un site construit au rabais et jamais mis à jour.
Je n'écris pas en spécialiste des politiques publiques, mais en développeur qui livre du code pour des clients et lit les rapports d'incident pour anticiper les douze prochains mois. Les fournisseurs durciront le modèle, c'est leur couche. Votre couche, ce sont les clés, les outils, les règles de sortie réseau et les journaux d'audit.
Vous construisez un produit avec un agent dedans ?
Je suis Zubair Hussain Shah, développeur full-stack en Next.js, React et Node. Je livre des applications web, des plateformes e-commerce et des fonctionnalités IA, et je durcis la couche agent au passage : clés côté serveur, outils cloisonnés, récupération résistante à l'injection, traçabilité.
Sources et lectures
- Anthropic, Countering misuse of AI: September 2026.
- Anthropic, Threat Intelligence.
- Arab News, Yemen's Houthis used Claude AI to build guided weapons.
- The New Arab, Anthropic report exposes AI misuse across the MENA region.
- OWASP, Top 10 for LLM Applications.
- MITRE, ATLAS.
- NIST, AI Risk Management Framework.
Par Zubair Hussain Shah. Plus d'articles sur le blog et sur GitHub.