Accusations du ministère de la Défense : manipulation possible en pleine guerre

Le ministère de la Défense affirme que certains développeurs d’IA disposeraient d’un pouvoir technique leur permettant de modifier un modèle pendant un conflit, avec des conséquences opérationnelles majeures : altération des recommandations, suppression d’alertes, ou injection d’instructions contraires aux intérêts militaires. Exemples concrets cités dans ce registre comprennent des capacités telles que la mise à jour à distance de poids ou de filtres de sortie, ou l’activation de portes dérobées intégrées lors du déploiement. Points clés évoqués :

• Mises à jour à distance des modèles via cloud ou pipeline CI/CD;
• Contrôle exclusif par l’éditeur des versions déployées;
• Possibilité d’intervention sans validation externe pendant une crise.

Réponse des dirigeants : pourquoi ils disent que c’est impossible

Les cadres de l’entreprise réfutent ces allégations en s’appuyant sur des mécanismes techniques et contractuels qu’ils présentent comme des garanties : signatures numériques des modèles, images immuables, journaux d’audit, et politiques d’accès strictes. Ils expliquent que, en pratique, il serait improbable voire techniquement impossible de modifier un modèle en production sans laisser de traces détectables. Illustrations de leurs arguments :

• Signatures cryptographiques et hachage des fichiers modèles pour vérifier leur intégrité;
• Déploiements en environnements isolés (air-gapped) pour les usages sensibles;
• Procédures contractuelles limitant les droits d’administration et imposant audits indépendants.

Comment un modèle pourrait réellement être manipulé : voies techniques

Sur le plan technique, la littérature et les incidents en cybersécurité montrent plusieurs voies de manipulation plausibles, même si leur mise en œuvre n’est pas triviale. Exemples et vecteurs identifiés par les chercheurs :

• Empoisonnement des données (data poisoning) : injection de données malveillantes lors de l’entraînement pour créer des comportements indésirables (ex. recherche académique « BadNets »);
• Backdoors / trojans : insertion intentionnelle d’une porte cachée qui s’active sur un stimulus spécifique;
• Mises à jour malveillantes : remplacement de checkpoints ou push d’une nouvelle version contenant des altérations;
• Attaques sur la chaîne d’outils (supply chain) : modification de bibliothèques ou d’infrastructure, à l’image de l’affaire SolarWinds en cybersécurité.

Détection et preuve : comment savoir si un modèle a été altéré

Détecter une manipulation suppose d’instaurer des méthodes d’audit et des preuves techniques robustes. Des pratiques éprouvées et des exemples concrets permettent de tracer, vérifier et comparer :

• Hachage et signatures des artefacts (modèles, poids, conteneurs) pour vérifier l’intégrité;
• Snapshots et checkpoints publics ou remis à un tiers de confiance pour comparaison;
• Tests de régression automatisés et évaluations indépendantes en continu (benchmarks et jeux de données de contrôle);
• Utilisation de preuves d’exécution (attestation via TEE comme Intel SGX) pour garantir qu’un modèle s’exécute tel que signé.

Risques opérationnels en situation de conflit : scénarios et impacts

Si une manipulation survenait pendant un conflit, les conséquences pourraient être graves : décisions erronées, informations trompeuses et perte de confiance envers les systèmes d’IA. Scénarios plausibles et illustrations :

• Fausse alerte ou suppression d’alerte entraînant des erreurs tactiques;
• Altération des règles d’engagement dans des systèmes d’aide à la décision;
• Diversion ou tromperie via des conseils manipulés, induisant un commandement en erreur;
• Effet secondaire : erosion de la confiance entre l’État et les fournisseurs, complexifiant les partenariats futurs.

Vers des garanties robustes : mesures techniques et contractuelles

Pour réduire le risque de manipulation et répondre aux tensions entre autorités et éditeurs, plusieurs mesures combinées s’imposent. Elles reposent sur la transparence technique, la vérifiabilité et des mécanismes juridiques. Recommandations concrètes :

• Clauses contractuelles imposant audits indépendants et accès aux logs;
• Mise en place de reproductibilité : checkpoints, pipelines versionnés et preuves d’entraînement;
• Adoption de standards d’attestation cryptographiques et d’environnements d’exécution sécurisés;
• Programmes de red-teaming et tests d’injection pour identifier vulnérabilités avant déploiement;
• Création d’un tiers de confiance capable de conserver et de comparer des snapshots en cas de litige.