Dans beaucoup d'entreprises régulées, l'IA n'est plus un pilote. Elle score la fraude, répond aux clients, rédige des notes de conformité, aide les développeurs à écrire du code et agit à l'intérieur des CRM. Une démo qui fonctionne ne suffit plus. Les équipes ont besoin de savoir si le système reste fiable aujourd'hui, sous trafic réel, avec les données, les instructions, les outils et les fournisseurs du moment.
La démo n'est pas le système en production
Le Stanford AI Index 2026 recense 362 incidents IA rapportés en 2025, contre 233 en 2024. L'OECD AI Incidents and Hazards Monitor a relevé un pic à 435 incidents en janvier 2026. Le rapport MIT NANDA d'août 2025 indique, lui, que 95 % des pilotes GenAI en entreprise n'ont produit aucun impact mesurable sur le compte de résultat.
Ces chiffres convergent vers le même constat. Une démo contrôlée reste un test au périmètre restreint. La production, elle, est plus instable : les utilisateurs posent des questions imprévues, les documents évoluent, les index de recherche dérivent, les fournisseurs mettent à jour leurs modèles et les agents reçoivent de nouveaux outils. Sans compter les hypothèses de sécurité qui semblaient solides en recette et qui ne tiennent plus face à de vraies données.
Les défaillances touchent les données, les finances et les opérations
Les défaillances publiques ne se résument plus à des chatbots qui inventent une règle. En novembre 2025, Anthropic a révélé GTG-1002, une campagne d'espionnage quasi autonome menée à l'aide de Claude Code contre une trentaine d'organisations. En janvier 2026, Microsoft a corrigé ShareLeak, une faille de Copilot Studio qui permettait d'exfiltrer des données via une instruction cachée. En avril 2026, Salesforce Agentforce a exposé des données CRM via PipeLeak, une vulnérabilité d'injection indirecte dans les pipelines d'agents.
Ces incidents importent parce qu'ils touchent le fonctionnement réel. Un modèle peut divulguer des données, citer la mauvaise source, approuver la mauvaise action ou continuer à tourner alors que tout son environnement a déjà changé. Un dashboard d'infrastructure au vert ne le montrera pas. CPU, latence et taux d'erreur peuvent rester nominaux pendant que l'IA donne une mauvaise réponse ou prend une mauvaise initiative.
Quatre risques exigent des tests continus
- Défaut d'ancrage : la réponse contredit la source qu'elle était censée utiliser, ou cite une source qui n'étaie pas l'affirmation.
- Dérive silencieuse : les données, les labels, les instructions, la logique de recherche ou le modèle du fournisseur changent, et le système continue à scorer sans qu'aucune erreur d'infrastructure ne soit visible.
- Injection de prompt : une consigne cachée dans un e-mail, un document, une page web, une page wiki ou une réponse d'outil détourne le comportement du système.
- Défaillance d'action d'un agent : le système appelle le mauvais outil, utilise le mauvais paramètre, répète une action ou exécute une action irréversible sans approbation.
Un audit annuel est trop lent face à ces risques. Ils peuvent apparaître après une mise à jour de modèle, une réindexation de corpus, l'ajout d'un connecteur, la modification d'un garde-fou ou la mise à jour d'un fournisseur. Les tests doivent suivre les changements du système, pas le seul calendrier d'audit.
Le monitoring n'est pas l'évaluation
Le monitoring décrit ce qui s'est passé : instructions, extraits récupérés, appels d'outils, latence, nombre de tokens, erreurs. L'évaluation, elle, pose une autre question : le système aurait-il dû faire cela ? Les deux sont utiles, mais seule la seconde permet de dire à un conseil, à un régulateur ou à un auditeur si l'IA se comporte encore comme prévu.
Un dashboard d'infrastructure au vert peut très bien cacher un système IA en train de défaillir.
Le NIST a explicité cette distinction dans AI 800-4, publié en mars 2026. Un programme crédible a besoin à la fois de télémétrie d'infrastructure et de télémétrie sur le comportement du modèle. Il lui faut aussi des jeux de tests reliés aux obligations qui s'appliquent au système : AI Act, NIST AI RMF, ISO 42001, DORA ou doctrine sectorielle.
Les régulateurs attendent désormais des preuves dans la durée
L'AI Act impose un monitoring post-commercialisation et une déclaration des incidents graves pour les systèmes à haut risque. L'accord politique Digital Omnibus du 7 mai 2026 a décalé certaines échéances, mais il n'a pas levé l'obligation de suivre la performance et les incidents tout au long de la vie du système.
Les autres référentiels vont dans le même sens. NIST AI 800-4 sépare l'évaluation au moment du déploiement et le suivi à mener une fois en production. ISO/IEC 42001 exige de mesurer et d'évaluer la performance et le risque IA tout au long du cycle de vie. En banque et en assurance, les textes BCE, BaFin, ABE et ACPR raccrochent tous la gouvernance IA aux contrôles opérationnels, TIC et prudentiels déjà en place.
Cinq tests devraient bloquer une mise en ligne
- Réponses régulées : rejouer un jeu de référence qui couvre les politiques, les frais, les critères d'éligibilité et les autres réponses contrôlées. Toute dérive au-delà du seuil doit bloquer la mise en ligne.
- Injection de prompt : rejouer des attaques via e-mails, documents, pages web, contenus récupérés et réponses d'outils.
- Ancrage : rejeter les réponses sans source, avec une source obsolète ou avec une source qui n'étaie pas la réponse.
- Outils des agents : bloquer les outils à fort impact (supprimer, envoyer, déployer, exécuter une transaction) tant que l'approbation humaine requise n'est pas tracée.
- Fuite de données : signaler toute réponse qui expose une donnée régulée hors de son périmètre déclaré, même partiellement.
Les seuils exacts dépendent du système. Un chatbot fiscal, un modèle anti-fraude et un agent de code ne défaillent pas de la même manière. Le point commun, c'est la règle de mise en ligne : avant la production, décidez quels échecs de test doivent bloquer une publication ou faire revenir en arrière un changement.
Par où commencer
Si vous exploitez un seul système IA à haut risque, commencez modestement. Identifiez les deux normes ou règlements qui vous engagent vraiment. Écrivez les cinq tests ci-dessus pour le système réel, tel qu'il tourne. Rejouez-les à chaque changement significatif. Conservez les résultats avec les versions du modèle, des instructions, des données et des outils utilisées à ce moment-là.
Si vous en exploitez dix ou plus, l'approche manuelle atteint vite ses limites. L'objectif n'est pas d'ajouter un dashboard de plus. C'est d'avoir, en permanence, une réponse à la question que votre conseil et vos régulateurs finiront par poser : qu'avez-vous testé, quand, avec quelle version, et qu'avez-vous changé une fois le résultat connu ?
Références
- Stanford HAI, AI Index Report 2026, 13 avril 2026, hai.stanford.edu/ai-index/2026-ai-index-report.
- OECD AI Incidents and Hazards Monitor, oecd.ai/en/incidents.
- MIT NANDA, The GenAI Divide: State of AI in Business 2025, août 2025.
- Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign (GTG-1002), 13 novembre 2025.
- Microsoft Security Response Center, CVE-2026-21520 ShareLeak, janvier 2026.
- Salesforce Trust, avis Agentforce PipeLeak, avril 2026.
- Règlement (UE) 2024/1689 sur l'IA, articles 72 et 73, eur-lex.europa.eu ; accord politique Digital Omnibus, 7 mai 2026.
- NIST AI 800-4, Challenges to the Monitoring of Deployed AI Systems, mars 2026.
- ISO/IEC 42001:2023.
- BCE Banking Supervision, priorités de supervision 2026 à 2028, 18 novembre 2025.
- BaFin, Orientation sur les risques TIC liés à l'utilisation de l'IA dans les entités financières, 30 janvier 2026.
- ABE, factsheet sur le mapping AI Act, 21 novembre 2025 ; ACPR, programme de travail 2026.