L’entreprise qui délègue reste souvent la première exposée. Un agent IA peut signer, transférer, négocier ou déclencher une action sans validation humaine claire. Le droit rattrape doucement le sujet, mais le vrai enjeu, c’est de savoir qui contrôle quoi, et quelles preuves vous gardez.
Pourquoi un agent IA change la donne ?
Un agent IA change la donne parce qu’il ne se contente pas d’exécuter une commande fixe, il peut décider d’une suite d’actions pour atteindre un objectif. C’est ça le vrai saut. On ne parle plus juste d’un chatbot qui répond à une question, mais d’un système qui agit dans votre environnement.
Un logiciel classique suit une logique prévue à l’avance. Si telle condition arrive, il fait telle action. C’est souvent rigide, parfois complexe, mais ça reste cadré. Une IA agentique, elle, perçoit un contexte, raisonne sur un objectif, choisit des outils, appelle des API, écrit des emails, modifie un CRM, lance un paiement ou prépare un dépôt réglementaire. Une API, c’est simplement une porte d’entrée technique entre deux logiciels. Donc si l’agent y a accès, il peut vraiment déclencher des actions.
Le sujet devient sensible pour trois raisons.
- Autonomie. L’agent peut choisir le chemin pour atteindre le résultat demandé. Vous lui dites “récupère ce client”, et il décide peut-être de relancer, négocier, promettre une remise ou prioriser un dossier. Le détail n’a pas toujours été validé par un humain.
- Comportement émergent. Ça veut dire qu’un comportement apparaît à partir de la combinaison du modèle, des données, des outils et du contexte, sans avoir été explicitement programmé ligne par ligne. Personne n’a forcément écrit “fais cette promesse commerciale”, mais l’agent peut y arriver tout seul.
- Délégation d’autorité. Le vrai point est là. Si vous donnez à l’agent des accès réels, il ne simule plus. Il engage potentiellement l’entreprise, même si ce n’était pas l’intention au départ.
J’ai vu ce genre de scénario arriver très vite dans des projets d’automatisation commerciale. Une entreprise donne à un agent un accès email, un CRM et un outil de devis. L’agent discute avec un prospect, comprend qu’il faut être agressif pour conclure, envoie une proposition avec une remise trop forte et des conditions trop engageantes. Le prospect répond “Bon pour accord”. Maintenant, il considère que l’entreprise est liée.
Le problème ne vient pas seulement du modèle. Il vient aussi de l’autorité qu’on lui a donnée. Qui a fauté ? Le fournisseur du modèle ? L’intégrateur ? Le dirigeant qui a validé les accès ? L’équipe commerciale qui n’a pas posé de garde-fous ? Il n’y a pas toujours un moment simple où un humain a pris la mauvaise décision.
Si l’agent agit avec de vrais accès et produit de vrais effets business, le sujet n’est plus seulement technique. Il devient juridique.
Où le droit bloque aujourd’hui ?
Le droit bloque surtout pour une raison simple : il a été construit autour d’une décision humaine identifiable. Quelqu’un signe, valide, clique, donne un ordre. Avec un agent IA, cette décision se dilue entre le modèle, l’intégrateur, l’entreprise, les outils connectés et parfois l’utilisateur qui a juste fixé un objectif assez vague.
Le premier terrain, c’est le contrat. Un agent IA n’a pas de personnalité juridique. Il ne signe pas pour lui-même, il ne devient pas “partie” au contrat. La vraie question devient donc : est-ce qu’il avait une autorité réelle ou apparente pour engager l’entreprise ? C’est facile à comprendre quand un commercial signe un devis avec son nom, son mail pro et son mandat. C’est beaucoup moins net quand un agent autonome récupère une demande, vérifie un prix dans un CRM, génère une réponse, puis envoie une acceptation via un outil de messagerie.
Le deuxième terrain, c’est la responsabilité civile. Là, on cherche souvent une faute, un manque de prudence, une négligence. Mais qui devait prévoir le risque ? Le développeur du modèle ? L’entreprise qui a construit l’agent ? Celle qui l’a déployé ? La personne qui a fixé l’objectif ? J’ai déjà vu ce flou chez un client : chaque acteur avait fait “sa partie correctement”, mais personne n’avait vraiment testé le comportement complet de l’agent en situation réelle. La faute devient difficile à localiser quand chacun ne contrôle qu’un morceau de la chaîne.
Le troisième terrain, c’est la responsabilité du fait des produits. La directive européenne révisée sur la responsabilité du fait des produits, adoptée en 2024, va dans le bon sens. Elle inclut les logiciels et peut couvrir des systèmes d’IA. Elle facilite aussi, dans certains cas définis, l’accès à des éléments techniques et certains mécanismes de preuve. C’est une avancée importante, surtout quand la victime n’a pas les moyens de comprendre ce qui s’est passé dans le système. Mais ça ne règle pas tout, notamment pour des agents qui apprennent, s’adaptent ou dépendent fortement du contexte de déploiement.
L’AI Act de l’Union européenne, entré en vigueur en août 2024, ajoute une autre couche. C’est un cadre de conformité fondé sur le risque. Il impose, pour certaines IA, notamment à haut risque, des obligations de documentation, de transparence, de supervision humaine et de gestion des risques. C’est utile. Mais ce n’est pas un régime complet d’indemnisation des victimes.
On a donc un écart de responsabilité, pas parce que le droit ne dit rien, mais parce que les bons outils juridiques ne couvrent pas encore proprement toute la chaîne agentique.
Qui peut être tenu responsable ?
Plusieurs acteurs peuvent être exposés en même temps, et c’est exactement ce qui rend la responsabilité IA compliquée. On cherche souvent un seul coupable. Dans la vraie vie, c’est rarement aussi propre.
Le premier acteur visible, c’est souvent l’entreprise qui déploie l’agent. C’est elle qui donne les accès, fixe le cadre, profite de l’automatisation et présente parfois l’agent comme une extension de son activité. Dans les projets que je vois, c’est là que le risque est le plus sous-estimé. On branche un agent sur Gmail, Slack, un CRM, un outil de facturation, parfois même un ERP, puis on découvre après coup qu’il peut vraiment engager l’entreprise.
L’intégrateur ou l’équipe qui construit l’agent peut aussi être concerné. Si l’architecture est bancale, si les permissions sont trop larges, si aucun garde-fou n’est prévu, si personne ne journalise les actions, ça devient difficile de dire “ce n’est pas notre problème”. Un journal d’action, c’est simplement une trace claire de ce que l’agent a fait, quand, avec quelle instruction et quel outil.
Le fournisseur du modèle ou du logiciel n’est pas hors-jeu non plus. Il peut être concerné si le produit est défectueux, mal documenté, ou s’il ne respecte pas des obligations applicables. Mais il faut rester lucide. Tout dommage causé par un agent ne remonte pas automatiquement au fournisseur du modèle. Si vous donnez à un agent des droits excessifs sur vos outils internes, le problème vient aussi du déploiement local.
Le responsable métier compte aussi. S’il demande à l’agent de maximiser les ventes, réduire les coûts ou accélérer un processus sans poser de limites claires, il crée parfois les conditions du risque. Une API, c’est une interface qui permet à deux logiciels de se parler. Si elle est mal configurée, elle peut amplifier très vite une mauvaise décision.
| Acteur | Ce qu’il contrôle | Risque typique | Preuve à garder |
| Entreprise qui déploie | Accès, objectifs, données, supervision | Agent qui engage l’entreprise ou agit hors cadre | Politiques internes, validations, logs, droits accordés |
| Intégrateur | Architecture, garde-fous, orchestration | Permissions trop larges ou absence de contrôle | Spécifications, tests, documentation, journal d’actions |
| Fournisseur de modèle ou logiciel | Produit, documentation, sécurité du service | Défaut produit, comportement mal documenté | Contrat, notices, versions, incidents déclarés |
| Responsable métier | Objectifs, règles métier, arbitrages | Consignes trop agressives ou limites floues | Cahier des charges, critères de succès, validations |
| Fournisseur d’API ou outil connecté | Accès technique, disponibilité, permissions | Action exécutée sans contrôle suffisant | Logs API, paramètres d’accès, historique des appels |
La bonne question n’est donc pas seulement “qui a tort ?”. C’est plutôt “qui avait le pouvoir d’éviter le dommage ?”. Et cette question, elle change beaucoup de choses.
Comment réduire le risque maintenant ?
Je traite un agent IA comme un collaborateur numérique à pouvoirs limités, pas comme un simple chatbot sympa qu’on branche partout. Dès qu’il peut envoyer un mail, créer une facture, modifier un CRM ou déclencher un paiement, on n’est plus dans la discussion. On est dans l’action, donc dans le risque.
Avant de connecter un agent à des outils réels, je veux savoir cinq choses très concrètes. Ce qu’il peut faire. Ce qu’il ne peut jamais faire. Qui valide les actions sensibles. Où sont les logs, c’est-à-dire les traces techniques de ce qu’il a fait. Comment je coupe l’accès en urgence si ça part de travers.
Dans les projets que je vois, le problème vient rarement d’un “grand bug IA”. Il vient plutôt d’un agent trop libre, avec trop de droits, pas assez de validation humaine, et personne capable de dire précisément pourquoi telle action a été déclenchée.
- Permissions limitées : L’agent doit avoir uniquement les accès nécessaires, jamais plus.
- Validation humaine : Toute action sensible doit passer par une personne identifiée.
- Seuils financiers : Un montant maximum doit bloquer l’exécution automatique.
- Sandbox avant production : Je teste l’agent dans un environnement isolé avant de le laisser toucher au réel.
- Journalisation complète : Je garde les décisions, les appels d’outils, les prompts, les objectifs donnés et les réponses obtenues.
- Suivi des versions : Je sais quel modèle, quelle configuration et quelles règles étaient actifs au moment de l’action.
- Tests limites : Je provoque volontairement des cas tordus pour voir comment l’agent réagit.
- Revue des accès : Je vérifie régulièrement que les droits restent cohérents.
- Procédure d’incident : Je sais qui prévient qui, quoi couper, quoi conserver, et comment analyser après coup.
Ces contrôles ne sont pas là pour faire joli dans un dossier conformité. Ils répondent directement aux attentes de l’AI Act autour de la documentation, de la gestion du risque, de la supervision humaine, de la traçabilité et de la transparence. Ils servent aussi en cas de litige, parce qu’ils montrent que l’entreprise n’a pas laissé l’agent agir en roue libre.
Un agent finance peut préparer un virement, mais il ne doit pas l’exécuter seul au-dessus d’un seuil. Un agent commercial peut rédiger une offre, mais il ne doit pas accepter une clause contractuelle non standard. Un agent support peut répondre à un client, mais il ne doit pas promettre un remboursement hors politique interne.
La responsabilité IA se pilote avant l’incident. Après, on ne fait souvent que reconstruire une chaîne de décisions qu’on aurait dû tracer dès le départ.
Alors, vous laissez vos agents agir jusqu’où ?
La responsabilité IA n’est pas un sujet théorique. Dès qu’un agent a des accès, des objectifs et la capacité d’agir, il peut produire des effets business et juridiques. Le droit avance avec l’AI Act et la nouvelle responsabilité du fait des produits en Europe, mais il ne règle pas encore toute la chaîne. Pour moi, le vrai réflexe, c’est de cartographier qui contrôle quoi, limiter les pouvoirs, garder les preuves et mettre une validation humaine là où l’impact est réel. Vous gagnez en automatisation sans transformer chaque agent IA en risque caché pour votre entreprise.
FAQ
- Qu’est-ce que la responsabilité IA ? La responsabilité IA désigne la question de savoir qui doit répondre d’un dommage causé par un système d’intelligence artificielle. Avec les agents IA, le sujet devient plus sensible parce que le système peut agir avec une certaine autonomie, utiliser des outils et produire des effets concrets pour une entreprise.
- Un agent IA peut-il engager juridiquement une entreprise ? Il peut créer une situation où l’entreprise semble engagée, surtout s’il utilise des canaux officiels comme l’email, un CRM, une plateforme commerciale ou une API interne. L’agent n’a pas de personnalité juridique, mais l’autorité que l’entreprise lui donne peut devenir un vrai sujet contractuel.
- L’AI Act règle-t-il la question de la responsabilité IA ? Pas complètement. L’AI Act européen encadre surtout la conformité, la gestion des risques, la documentation, la transparence et la supervision humaine. C’est très utile, mais ce n’est pas un régime complet qui dit automatiquement qui indemnise qui après un dommage.
- La responsabilité du fait des produits peut-elle viser une IA ? Oui, la directive européenne révisée en 2024 étend la logique de responsabilité du fait des produits aux logiciels, ce qui peut inclure des systèmes d’IA. C’est une avancée importante, mais l’analyse reste complexe quand le dommage dépend du contexte, des données, des outils connectés et du déploiement local.
- Comment une entreprise peut-elle réduire son risque avec les agents IA ? Elle doit limiter les permissions, tracer les actions, documenter les objectifs, prévoir une validation humaine pour les décisions sensibles, tester les scénarios à risque et garder un vrai plan d’incident. Le but n’est pas de bloquer l’IA, c’est de garder le contrôle sur ce qu’elle peut réellement faire.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent automatiser sérieusement, sans perdre le contrôle sur leurs données, leurs workflows et leurs risques. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer vos projets IA, agentiques ou automatisation, contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking avancé (GTM server, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.