Agent IA : classer l'usage avant de signer le pilote

La Commission européenne vient de répondre à une question que beaucoup de devis laissent volontairement floue : comment l’AI Act traite-t-il les « agents IA » ? Sa réponse est moins spectaculaire que le vocabulaire commercial, mais beaucoup plus utile pour une PME. Un agent n’est pas une nouvelle catégorie juridique.

Le terme reste mouvant. La Commission décrit généralement un agent comme un système capable de recevoir des informations de son environnement, de les traiter puis d’exécuter des actions qui affectent cet environnement, par exemple en appelant une fonction. Elle précise toutefois que le mot n’est pas défini dans l’AI Act et qu’il recouvre des objets très différents.

Un assistant qui prépare un brouillon, un agent qui répond à un client, un outil qui classe des candidatures et un système qui modifie une commande peuvent tous porter la même étiquette. Ils ne touchent ni les mêmes personnes, ni les mêmes données, ni les mêmes décisions. Les classer ensemble parce que la brochure dit « agentique » produit donc un mauvais dossier de conformité.

Le bon point de départ n’est pas le niveau d’autonomie annoncé. C’est la tâche réelle, la personne touchée et l’effet possible.

Le nom du produit ne classe rien

Deux agents construits avec le même modèle peuvent suivre des routes très différentes.

Le premier lit des procédures internes et propose une réponse à un collaborateur. Il n’agit pas dans le système de gestion et sa sortie reste un brouillon. Le deuxième reçoit une réclamation client, décide d’un geste commercial et modifie la facture. Le troisième trie des candidatures et recommande les personnes à rencontrer. Le quatrième publie automatiquement une fiche produit.

Le modèle sous-jacent peut être identique. Les finalités, les personnes exposées et les conséquences ne le sont pas.

Pour éviter le faux raccourci « agent = haut risque », une PME peut poser cinq questions avant même de choisir un fournisseur :

Question	Ce qu’elle révèle	Exemple de preuve
Qui rencontre l’agent ?	Interaction avec un client, un candidat, un salarié ou seulement un opérateur formé.	Écrans, premier message et catégories d’utilisateurs.
Que produit-il ?	Brouillon interne, contenu publié, score, recommandation ou décision.	Exemples de sorties et règle de validation.
Sur quoi peut-il agir ?	Lecture seule, création d’une tâche, envoi, paiement, modification ou suppression.	Liste exacte des droits et des appels autorisés.
Quelle personne peut subir un effet ?	Simple confort, accès à un service, emploi, crédit ou autre décision sensible.	Finalité écrite et procédure de recours humain.
Qui a construit et modifié le système ?	Répartition entre fournisseur, intégrateur et PME déployeuse.	Contrat, versions et dossier des modifications.

FAQ de l'AI Act Service Desk sur les agents IA, vérifiée le 26 juillet 2026

Cette fiche fait mieux qu’une matrice abstraite. Elle relie directement le système à un flux observable. Elle permet aussi de repérer un changement de projet : un outil présenté comme aide à la rédaction devient autre chose lorsqu’on lui donne le droit d’envoyer, de classer ou de refuser.

Parler, publier et décider sont trois sujets différents

À partir du 2 août 2026, l’article 50 prévoit notamment qu’une personne soit informée lorsqu’elle interagit directement avec un système IA, sauf si ce caractère est évident dans le contexte. L’information doit arriver au plus tard lors de la première interaction et respecter les exigences d’accessibilité.

Cette obligation de conception vise le fournisseur du système interactif. Pour la PME qui achète l’outil, la question pratique est contractuelle : le premier écran, le premier message et chaque canal rendent-ils réellement cette information visible ? Un widget web peut être conforme tandis que la même fonction, intégrée dans WhatsApp ou une borne, ne l’est plus.

La génération de contenu suit une autre logique. Les fournisseurs de systèmes qui génèrent ou manipulent du texte, des images, de l’audio ou de la vidéo doivent prévoir un marquage lisible par machine dans les cas couverts. Les déployeurs ont leurs propres obligations de divulgation pour les deepfakes et certains textes publiés afin d’informer le public.

Enfin, une fonction qui intervient dans une décision sensible ne devient pas acceptable parce qu’elle se présente poliment comme un assistant. Le classement à haut risque dépend de la finalité prévue. Le recrutement, l’accès à certains services essentiels ou des usages réglementés appellent un examen distinct. La Commission rappelle d’ailleurs que les considérations spécifiques aux agents restent préliminaires et pourront évoluer.

La conclusion utile est simple : ne cherchez pas une seule case « agent IA ». Ouvrez une ligne par usage.

Déployeur n’est pas fournisseur, jusqu’au moment où le projet change

Une PME qui utilise un système acheté selon sa finalité prévue agit généralement comme déployeur. Elle doit comprendre les instructions, les limites et les données traitées. Elle ne devient pas automatiquement le fournisseur du modèle ou du produit.

La frontière peut toutefois bouger pour un système à haut risque. L’article 25 prévoit qu’un distributeur, un importateur, un déployeur ou un tiers peut reprendre les obligations du fournisseur s’il appose son nom sur le système, le modifie substantiellement ou change sa finalité de manière à le rendre à haut risque.

Ce déplacement ne concerne pas chaque réglage, chaque prompt ou chaque connecteur. Il ne faut donc pas transformer toute configuration en audit réglementaire. Mais trois modifications méritent une alerte :

• un agent de support est réutilisé pour évaluer des candidats ;
• un assistant qui proposait des réponses reçoit le droit de décider et d’exécuter ;
• une solution interne est emballée puis vendue sous la marque de la PME.

Le contrat doit nommer ces seuils avant le pilote. Qui valide une nouvelle finalité ? Qui vérifie si une modification est substantielle ? Qui fournit la documentation si la classification change ? Sans ces réponses, la partie qui maîtrise le moins la technique découvre souvent trop tard qu’elle porte la nouvelle responsabilité.

Le calendrier n’autorise pas l’attente

Toutes les obligations n’arrivent pas à la même date. Le calendrier officiel actuel place les règles de transparence au 2 août 2026. Il affiche plus tard l’application des règles relatives aux systèmes à haut risque de l’annexe III et à ceux intégrés dans certains produits réglementés.

Ce décalage ne signifie pas qu’un projet sensible peut avancer sans contrôle. Le RGPD, le droit du travail, la sécurité informatique, les interdictions déjà applicables et les obligations contractuelles continuent d’exister. Il signifie surtout qu’il faut séparer deux travaux :

1. ce qui doit être visible et vérifiable dès le premier contact ;
2. ce qui doit être préparé pour un usage susceptible d’être classé à haut risque.

Pour un système à haut risque, l’article 26 prévoit notamment une supervision humaine confiée à des personnes compétentes et autorisées, le suivi du fonctionnement, la gestion des incidents et la conservation des journaux sous contrôle du déployeur pendant au moins six mois. Dans le contexte du travail, il prévoit aussi l’information des représentants des travailleurs et des personnes concernées avant l’utilisation.

Une PME n’a pas besoin de bâtir aujourd’hui le dossier maximal pour chaque assistant. Elle a besoin de ne pas perdre les éléments qui coûteront cher à reconstruire : finalité, versions, instructions, droits, incidents, décisions humaines et journaux.

Le pilote doit tester une frontière, pas une démo

Un bon pilote d’agent ne cherche pas seulement à montrer que le système sait terminer une tâche. Il teste l’endroit où l’action doit s’arrêter.

Prenons un agent de service client. Le scénario nominal est facile : il lit une demande, retrouve la commande et prépare une réponse. Les scénarios utiles commencent ensuite :

• le client demande un remboursement supérieur au plafond ;
• deux commandes portent le même nom ;
• la politique commerciale et le contrat se contredisent ;
• une donnée nécessaire manque ;
• le connecteur renvoie une erreur après l’envoi ;
• l’agent prépare une action correcte pour le mauvais compte ;
• un collaborateur change la règle pendant une conversation.

Le système doit alors refuser, demander une validation, reprendre sans doubler l’action et laisser une trace compréhensible. Le score de réussite moyen ne suffit pas. Une seule action silencieuse sur la mauvaise personne peut être plus importante que cent réponses correctes.

Cette discipline reste utile même lorsque l’usage n’est pas à haut risque au sens de l’AI Act. Elle protège les données, la continuité du travail et la capacité de corriger une erreur.

La fiche d’une page à exiger lundi matin

Avant de signer un pilote, demandez une fiche commune au métier, à l’IT et au fournisseur. Elle doit tenir sur une page et répondre sans jargon :

• Finalité précise et tâche que l'agent ne doit pas accomplir.
• Personnes qui interagissent avec lui ou subissent ses effets.
• Données lues, écrites, envoyées au modèle et conservées.
• Sorties produites et actions techniquement autorisées.
• Décisions qui exigent une validation humaine.
• Rôle de chaque partie : fournisseur, intégrateur, déployeur.
• Journaux disponibles, durée de conservation et accès.
• Procédure d'arrêt, de reprise et de contestation.

Si une réponse manque, le pilote n’est pas bloqué pour autant. Il doit simplement rester en lecture seule ou en mode brouillon sur ce point. C’est le moyen le plus court de tester la valeur sans laisser une incertitude juridique devenir une action irréversible.

L’agent IA n’a donc pas besoin d’une grande théorie propre. Il a besoin d’une destination écrite, de droits bornés et d’un responsable humain identifiable. Le mot « agent » décrit une manière de construire. La conformité commence seulement quand on décrit ce que cette construction fait à quelqu’un.