Supervision humaine des agents IA : ce que le règlement européen sur l'IA vous impose concrètement de construire

La supervision humaine au titre du règlement européen sur l'IA signifie qu'une personne nommément désignée peut comprendre ce que fait votre agent, le contredire ou l'arrêter, et prouver après coup qu'elle en avait la capacité. Pour la plupart des agents, cela se résume à quatre choses à construire : une fiche de capacités, une frontière décisionnelle appliquée dans le code, un mécanisme d'arrêt qui interrompt réellement le système, et un journal enregistrant chaque décision décisionnelle ainsi que son auteur. L'article 14 ne s'applique qu'aux systèmes à haut risque, mais si vous vendez dans les secteurs de la santé, des RH, du crédit ou des services publics, considérez que vous êtes dans le périmètre et concevez le système en conséquence dès maintenant, plutôt que de le rétrofiter sous la pression d'un appel d'offres.

À qui cela s'applique concrètement

L'article 14 figure au chapitre III du règlement (UE) 2024/1689, le chapitre qui fixe les obligations pour les systèmes d'IA à haut risque. La qualification de votre agent comme système à haut risque est déterminée par deux annexes. L'annexe I couvre les IA constituant un composant de sécurité d'un produit réglementé, notamment les dispositifs médicaux. L'annexe III liste les cas d'usage : biométrie, infrastructures critiques, éducation, emploi et gestion des travailleurs, accès aux services privés et publics essentiels, répression pénale, migration et administration de la justice.

Traduit en termes d'agents :

• Pas à haut risque : un agent WhatsApp qui répond à des questions sur des produits et conseille une taille. Les règles de transparence de l'article 50 s'appliquent quand même, et nous les avons couvertes dans les règles de divulgation pour les agents de vente IA.
• À haut risque : un agent qui trie les messages de patients, présélectionne des candidats à un emploi, évalue un dossier de prêt ou détermine l'éligibilité à une prestation sociale. Même stack, même modèle, obligations radicalement différentes.

Les obligations de l'annexe III étaient prévues pour s'appliquer à partir du 2 août 2026. Ce calendrier a fait l'objet de propositions d'amendements ; vérifiez le texte consolidé en vigueur avant de vous engager sur une date dans un contrat. Ce qui n'a pas attendu l'échéance légale, c'est la commande publique : les acheteurs hospitaliers et gouvernementaux exigent déjà une documentation sur la supervision dans les appels d'offres, ce qui explique pourquoi le sujet a une portée commerciale aujourd'hui.

Ce que demande l'article 14, en langage clair

L'article exige que les systèmes à haut risque soient conçus de manière à permettre aux personnes physiques de les superviser efficacement pendant leur utilisation. La personne chargée de la supervision doit être en mesure de :

• comprendre les capacités et les limites du système, et surveiller son fonctionnement pour détecter les anomalies
• rester consciente du biais d'automatisation, c'est-à-dire la tendance à faire confiance excessivement aux résultats
• interpréter correctement les résultats, avec les outils nécessaires à cet effet
• décider de ne pas utiliser le système, ou d'ignorer, contredire ou annuler ses résultats
• intervenir dans son fonctionnement, ou l'interrompre via un bouton d'arrêt ou une procédure similaire

Deux points sont faciles à manquer. Premièrement, l'obligation de mettre en place ces mesures incombe au fournisseur — c'est-à-dire vous ou votre agence — tandis que l'obligation d'affecter des personnes compétentes incombe au déployeur. Deuxièmement, l'article n'exige jamais qu'un humain approuve chaque action. Les mesures doivent être proportionnées au risque. Cette proportionnalité est votre espace de conception, et c'est là que résident la plupart des décisions d'ingénierie.

Les quatre choses à construire

1. Une fiche de capacités

Un document d'une page, livré avec le produit, qui indique à quoi sert l'agent, sur quoi il a été testé, ce qu'il est connu pour mal faire, et ce qu'il ne doit en aucun cas faire. Cela ressemble à de la paperasse, mais c'est aussi le cahier des charges des trois éléments suivants. Si vous n'êtes pas en mesure de formuler par écrit ce que l'agent ne doit jamais faire, vous ne pouvez pas le bloquer.

2. Une frontière décisionnelle appliquée dans le code, pas dans le prompt

L'erreur la plus courante que nous observons dans les démos d'agents est un prompt système qui stipule « ne jamais envoyer un message sans approbation », et rien d'autre. Un prompt est une suggestion adressée à un modèle probabiliste. Ce n'est pas un système de permissions, et les propres rapports d'Anthropic sur les actions non intentionnelles des agents rappellent utilement que les instructions peuvent être ignorées sous une pression de contexte suffisante.

Divisez les actions de l'agent en deux listes. Autonomes : récupérer, classifier, résumer, rédiger, chercher. Soumises à validation : envoyer un message à un patient, mettre à jour un enregistrement, rejeter une candidature, émettre un remboursement au-delà d'un seuil. Appliquez ensuite cette séparation dans la couche des outils. L'agent dispose d'un outil request_approval et n'a tout simplement pas accès à send_message. Le service d'approbation est du code déterministe ordinaire avec des tests ordinaires. Nous approfondissons le routage et les chemins de secours dans les chemins d'escalade pour les agents IA, et le reste de la liste de durcissement figure dans notre checklist de sécurité pour les agents IA.

3. Un mécanisme d'arrêt qui arrête

L'article 14 est explicite sur l'interruption. Un véritable mécanisme d'arrêt comporte trois parties : un indicateur que l'agent vérifie avant chaque appel d'outil, l'annulation des exécutions déjà en cours, et le vidage de la file d'attente pour qu'aucune tâche ne reprenne d'elle-même quand quelqu'un réactive l'indicateur. Testez-le régulièrement, comme vous testez les sauvegardes. Si arrêter l'agent aujourd'hui signifie demander à l'équipe DevOps de mettre un déploiement à zéro, vous n'avez pas un bouton d'arrêt — vous avez une procédure d'incident.

4. Un registre de supervision qui prouve quelque chose

Le journal est la partie qu'un régulateur, un auditeur ou un tribunal lira effectivement. Pour chaque résultat décisionnel, il doit vous permettre de répondre à cinq questions :

• Qu'a perçu l'agent ? Les entrées, les documents récupérés, la version du modèle, la version du prompt.
• Qu'a-t-il proposé ? Le brouillon, la classification, la décision recommandée.
• Qu'a fait l'humain ? Approuvé, modifié, rejeté, ou n'a jamais regardé.
• Qui était cet humain ? Une identité, pas un compte de service partagé.
• Quand, et pendant combien de temps ? Une décision approuvée en moins d'une seconde est un simple tampon, et le registre doit le rendre visible.

Stockez-le en mode append-only, avec la même rigueur que celle que nous décrivons dans l'architecture à valeur probatoire pour l'IA en santé.

Notre propre moteur de prospection est loin d'être à haut risque, mais il est conçu de cette façon parce que le registre est utile indépendamment de toute réglementation. Il analyse le site de chaque prospect avec une instance Firecrawl auto-hébergée, et un LLM local extrait les faits pertinents et rédige un e-mail personnalisé par entreprise en un seul appel. Ce schéma en appel unique a surpassé une chaîne multi-étapes aussi bien sur le coût que sur la qualité des résultats, avec un effet de bord que nous n'avions pas anticipé : les faits sur lesquels le modèle s'est appuyé et le brouillon qu'il a produit ressortent du même appel, de sorte que le relecteur voit les preuves à côté de la conclusion, et il n'y a qu'une entrée et une sortie à stocker par e-mail plutôt qu'une chaîne d'états intermédiaires à reconstituer ultérieurement.

Le biais d'automatisation est l'exigence que l'on ignore

Le règlement cite explicitement le biais d'automatisation, et c'est la mesure qu'aucun produit d'agent ou presque ne prend en compte. Si le bouton d'approbation est l'élément sélectionné par défaut, si le relecteur ne voit que la réponse finale, et si la file d'attente est longue, votre supervision est une façade — et le journal le montrera.

Trois choix de conception en corrigent l'essentiel :

• Montrer les preuves, pas seulement la réponse. Le passage récupéré, le fait extrait, la règle qui a déclenché l'action.
• Masquer la suggestion pour un échantillon d'éléments. Laisser le relecteur décider à froid sur une fraction des cas, puis comparer.
• Suivre le taux de correction par relecteur. Zéro correction sur plusieurs semaines est un signal d'alerte, pas un indicateur de réussite.

Ce que cela coûte et comment le cadrer

Intégré dès le premier sprint, la supervision représente une part modeste d'un projet d'agent : le service d'approbation, l'indicateur et le schéma du journal sont des composants de petite taille et bien maîtrisés. Greffé après le lancement, c'est une réécriture de la couche des outils et une migration de toutes les exécutions historiques que vous regrettez de ne pas avoir enregistrées. Lorsque vous cadrez un agent à haut risque, inscrivez ces quatre éléments explicitement dans le cahier des charges plutôt que d'espérer les voir apparaître sous la rubrique « sécurité ».

Si vous évaluez une agence pour ce type de travail, quatre questions distinguent une implémentation réelle d'une présentation en slides :

1. Montrez-moi le mécanisme d'arrêt, et montrez-moi la dernière fois qu'il a été testé.
2. Montrez-moi une entrée de journal complète pour une décision réelle.
3. Quelles actions sont soumises à validation, et où dans le code cela est-il appliqué ?
4. Comment détectez-vous que les relecteurs ont cessé de relire ?

Si vous développez un agent pour un hôpital, une équipe RH, un organisme de crédit ou un service public, et que vous souhaitez qu'il survive au questionnaire de l'appel d'offres et à l'audit qui s'ensuit, parlons-en.