Un agent d’IA peut préparer un message, consulter une application, modifier une information et déclencher une étape suivante. Si une mauvaise hypothèse entre dans cette chaîne, plusieurs actions peuvent être engagées avant qu’un collaborateur ne remarque le problème.
Qui doit alors répondre ? La question recouvre deux sujets : déterminer les responsabilités juridiques d’un dommage et organiser la capacité de l’entreprise à prévenir, interrompre et corriger une action. La première demande une analyse des faits et des règles applicables. La seconde doit être traitée avant de laisser le système agir.
L’autonomie d’un agent exige une chaîne de responsabilité opérationnelle explicite : qui autorise quoi, qui observe, qui peut arrêter et qui décide de la reprise ? Écrire « un humain supervise » laisse trop de questions ouvertes si cet humain ne dispose ni du temps, ni des informations, ni de l’autorité nécessaires.
Un agent ne fait pas seulement une réponse
Dans cet article, un agent désigne un système d’IA capable d’enchaîner des étapes et d’utiliser des outils pour poursuivre un objectif, avec un degré d’autonomie variable. Les produits regroupés sous ce nom diffèrent fortement.
Préparer un brouillon pour relecture, modifier un dossier interne et envoyer un engagement à un client ne produisent pas les mêmes conséquences. Un système peut être utile sur la première activité sans être acceptable sur les suivantes.
Il faut donc décrire les actions accessibles. Quelles informations peut-il consulter ? Que peut-il modifier ? Peut-il communiquer vers l’extérieur, appeler un autre service ou déclencher une opération qui ne s’annule pas simplement ?
Cette description donne une base de discussion plus solide que la seule étiquette « assistant autonome ». Elle permet aussi de voir où plusieurs acteurs interviennent : fournisseur du modèle, intégrateur, éditeur d’application et entreprise utilisatrice.
Répondre d’un dommage et organiser le travail sont deux questions
Il serait trompeur d’attribuer, dans tous les cas, la responsabilité juridique au fournisseur, à l’entreprise ou au salarié qui a lancé la tâche. Les rôles, les contrats, les circonstances, les données et les régimes applicables doivent être examinés par les professionnels compétents.
Une répartition interne des tâches ne suffit pas à établir qui devra indemniser un dommage. Inversement, attendre la conclusion de cette analyse ne permet pas d’organiser le fonctionnement quotidien.
Sur ce second plan, l’entreprise peut désigner des interlocuteurs et des pouvoirs : autoriser un usage, limiter ses actions, examiner une alerte, interrompre une exécution et prendre en charge les conséquences. Ces fonctions peuvent être réparties ; elles doivent pouvoir se rejoindre lorsqu’une situation sort du cadre.
La bonne question de direction devient alors : notre organisation sait-elle encore agir lorsqu’un système réalise plusieurs étapes à notre place ?
Ce que les sources récentes permettent d’affirmer
Le document de travail de l’OCDE Agentic AI in organisations, publié le 16 septembre 2026, examine le développement, le déploiement et la gouvernance de ces systèmes à partir d’entretiens avec des organisations de différents secteurs et régions. Il s’agit de premiers éclairages de praticiens, pas d’un taux représentatif de réussite ou d’incident.
En France, le bulletin CERTFR-2026-ACT-016, daté du 13 avril 2026, alerte sur les assistants personnels autonomes agissant sur les postes de travail et les mobiles. Dans ce périmètre, il demande de ne pas déployer en production les produits non éprouvés et de limiter les usages à des tests isolés sans données sensibles. Ajouter une validation humaine ne transforme donc pas ce bulletin en feu vert pour la production.
Le NIST a, de son côté, publié le 29 septembre 2026 une synthèse des commentaires sur son projet relatif à l’identité et à l’autorisation des agents. Le chantier porte notamment sur leur identification, leur authentification et leurs autorisations. Il ne faut pas le présenter comme une norme finale déjà applicable aux entreprises françaises.
Ces sources éclairent le problème. Elles ne dispensent pas d’examiner un produit et son usage précis.
Le cadre européen doit être lu avec ses dates
Pour une entreprise concernée par le droit européen, l’expression « agent IA » ne suffit pas à déterminer les obligations. La Commission présente l’AI Act selon les risques et les usages, avec des rôles distincts dans la chaîne de fourniture et de déploiement.
Au 27 octobre 2026, son annonce du 27 juillet sur l’entrée en vigueur de l’AI Omnibus indique notamment des échéances reportées au 2 décembre 2027 pour les systèmes à haut risque de l’annexe III et au 2 août 2028 pour ceux intégrés aux produits relevant de l’annexe I.
Ces reports ciblés ne doivent être interprétés ni comme un report général de toutes les règles ni comme une autorisation d’agir sans examen. La qualification du système, les autres obligations et les textes en vigueur doivent être vérifiés pour le cas concerné. Cet article propose une réflexion d’organisation ; il ne tranche pas un dossier de responsabilité civile ou pénale.
Un scénario fictif : annoncer une nouvelle date de livraison
Imaginons une entreprise de services logistiques. Un agent doit préparer des informations de suivi à partir d’un dossier client. Une note contient une date envisagée, mais non confirmée. Le système la traite comme une décision acquise.
S’il prépare seulement un brouillon, une relecture peut repérer l’incertitude avant diffusion. S’il peut aussi modifier le dossier et envoyer un message, l’hypothèse devient une information communiquée au client. D’autres personnes peuvent ensuite travailler sur cette base.
Ce scénario ne décrit aucun incident réel ni client Learning Coach. Il montre pourquoi la question de responsabilité doit suivre les actions, plutôt que rester attachée au nom de l’outil.
L’entreprise doit savoir qui valide une nouvelle date, ce que l’agent peut faire lorsqu’elle manque et comment les opérations suivantes seront bloquées en cas de doute. Une consigne demandant de « rester prudent » ne précise pas ces conditions.
Définir le mandat par les actions et leurs conséquences
Nous proposons de préparer une fiche de mandat avant un usage autorisé. Elle décrit le but, les opérations permises, les limites et les situations où le système doit attendre une décision.
Cette proposition Learning Coach sert à structurer la discussion. Elle ne remplace pas les contrôles techniques, contractuels et réglementaires.
Dans notre exemple, le mandat pourrait distinguer la recherche d’une information confirmée, la préparation d’un brouillon et la communication externe. Une autorisation sur la première étape ne vaut pas autorisation sur toute la chaîne.
Le mandat doit également prévoir l’absence d’information. Si la date n’est pas confirmée, qui reçoit la question ? Que devient la demande en attente ? Une réponse manquante ne devrait pas être silencieusement transformée en approbation.
Enfin, le cadre doit être réexaminé lorsque les outils, les accès ou les actions changent. Un système limité à la lecture n’exerce plus le même rôle lorsqu’on lui ajoute la possibilité d’écrire ou de transmettre.
Préparer la reprise avant de chercher un responsable après coup
Une erreur en cours demande une organisation capable de répondre rapidement. Voici les fonctions à clarifier pour un usage donné.
| Fonction | Question à résoudre avant l’incident |
|---|---|
| Autoriser | Qui peut approuver le périmètre et ses modifications ? |
| Observer | Qui reçoit les alertes et sait apprécier ce qu’elles signifient ? |
| Interrompre | Qui dispose effectivement du moyen de suspendre les opérations ? |
| Corriger | Qui examine les actions déjà réalisées et coordonne leur traitement ? |
| Reprendre | Qui décide des conditions nécessaires avant un redémarrage ? |
Ces fonctions ne correspondent pas nécessairement à cinq personnes. Dans une petite structure, certaines peuvent être réunies. L’important est de ne pas découvrir, au moment de l’erreur, que chacun attend la décision d’un autre.
Dans le scénario logistique, suspendre de nouveaux messages ne corrige pas celui qui est déjà parti. Il faut aussi vérifier les dossiers modifiés et organiser une réponse appropriée avec les interlocuteurs concernés. L’arrêt est une étape de la reprise, pas la preuve que toutes les conséquences ont disparu.
Une validation humaine doit pouvoir changer le cours de l’action
Une personne peut cliquer sur « valider » sans disposer des informations nécessaires pour décider. Elle peut aussi recevoir trop de demandes ou croire que la vérification a déjà été faite ailleurs.
Pour rendre son rôle réel, il faut préciser ce qu’elle examine et ce qu’elle peut refuser. Dans notre exemple, elle doit retrouver la source de la date, reconnaître son statut et savoir demander une confirmation.
La validation doit arriver à un moment où elle peut encore empêcher l’action concernée. Un contrôle effectué après l’envoi n’offre pas le même pouvoir qu’une approbation préalable. Les deux peuvent avoir leur place, mais il faut nommer ce qu’ils permettent.
Cette question touche directement les compétences. La formation doit aider la personne à comprendre le périmètre de son jugement, à reconnaître une situation non résolue et à solliciter le bon recours.
Notre réflexion sur le transfert des apprentissages au travail rappelle que connaître une procédure en séance et l’utiliser sous contrainte sont deux observations différentes.
Conserver des faits exploitables, avec un périmètre maîtrisé
Après un problème, les équipes ont besoin de comprendre ce qui a été demandé, ce que le système était autorisé à faire et quelles opérations ont effectivement eu lieu.
Cela ne signifie pas tout enregistrer sans distinction. Les traces peuvent contenir des informations personnelles, confidentielles ou sensibles. Leur contenu, leurs accès et leur conservation doivent être définis avec les responsables compétents.
Une explication produite après coup par l’agent ne suffit pas, à elle seule, à établir la séquence réelle. Il faut pouvoir rapprocher les éléments disponibles dans les systèmes concernés et distinguer les faits des hypothèses.
Cette démarche aide aussi à éviter une réaction trop simple : désigner le dernier utilisateur visible et fermer la discussion. Une erreur peut révéler une limite du produit, un accès inadapté, une ambiguïté métier ou une organisation de contrôle impraticable. Ces possibilités demandent un examen.
Apprendre à intervenir dans un exercice préparé
Une équipe peut travailler sur un scénario fictif avant toute opération sensible. L’exercice consiste à repérer une condition manquante, identifier l’interlocuteur compétent et expliquer comment l’action serait interrompue ou reprise.
Il faut annoncer le but : tester le dispositif et les besoins de préparation. Une simulation ne doit pas devenir une évaluation individuelle cachée.
Notre article sur la parole en formation avec managers et collaborateurs invite à expliciter ce cadre. On peut examiner les décisions sans demander à chacun de révéler publiquement un incident personnel.
L’exercice peut mettre au jour une alerte mal comprise ou un recours qui n’aboutit à personne. Ce sont des informations pour améliorer le fonctionnement. Une simulation réussie ne certifie cependant pas la sûreté du système.
Un débat de direction avant un débat de démonstration
Une keynote sur les agents IA peut aider à poser les distinctions : capacité technique, autorisation d’agir, supervision effective et responsabilité juridique. Un atelier complémentaire peut examiner une chaîne d’actions fictive et faire apparaître les décisions encore manquantes.
Ces formats ne remplacent ni l’audit de sécurité ni l’analyse juridique ou l’organisation d’une réponse à un incident. Ils peuvent donner aux métiers, aux fonctions techniques et aux dirigeants un terrain commun pour préparer les choix.
Vous souhaitez ouvrir cette discussion sur l’IA et le jugement humain ? Découvrez les conférences Learning Coach et demandez une proposition adaptée à votre événement.
Avant de demander jusqu’où un agent peut aller seul, l’entreprise doit pouvoir expliquer comment elle saura reprendre la main — et qui disposera réellement des moyens de le faire.
Ressources
OCDE, Agentic AI in organisations: Early insights from practitioner interviews, document de travail, 16 septembre 2026. Présentation et résumé consultés.
CERT-FR, Vulnérabilités et risques des produits d’automatisation par IA agentique sur les postes de travail, 13 avril 2026.
NIST/NCCoE, Comments on Software and Agentic AI Identity Concept Paper, 29 septembre 2026. Projet en cours.
Commission européenne, présentation de l’AI Act et entrée en vigueur de l’AI Omnibus, annonce du 27 juillet 2026. Sources consultées le 27 octobre 2026.
