Copilots et agents IA en production : périmètre, contrôle et obligations.

Un agent d’intelligence artificielle est un système qui ne se contente pas de répondre : il exécute des actions dans des systèmes tiers pour atteindre un objectif, en enchaînant lui-même les étapes. Le passage de la réponse à l’action change tout, parce qu’une réponse fausse se corrige et qu’une action fausse s’exécute. C’est ce qui explique l’écart entre le nombre d’organisations qui expérimentent et celles qui atteignent la production. Cette page traite ce qui distingue un agent défendable, les causes d’échec récurrentes et les obligations à traiter avant déploiement, dans le prolongement de notre couverture IA, données et plateformes.

Ce qu’est un agent, et ce qui le rend différent

Définition. Un agent d’IA associe un modèle de langage, un ensemble d’outils qu’il peut appeler, et un périmètre définissant les systèmes accessibles, les droits accordés et les actions interdites. Il décide lui-même de la suite d’actions à mener pour atteindre l’objectif qui lui est confié.

Trois briques, et la troisième est celle que les projets négligent.

Le modèle fournit le raisonnement et la formulation. Il est interchangeable, et va le devenir de plus en plus.

Les outils définissent ce que l’agent peut faire : interroger un système, écrire dans une base, envoyer un message, déclencher un traitement. Chaque outil ajouté élargit la surface d’action et la surface de risque.

Le périmètre définit les limites. Systèmes accessibles, droits accordés, actions interdites, seuil de bascule vers un humain. Un agent sans périmètre écrit est un agent que personne ne pourra défendre le jour d’un incident. C’est le document qui manque dans la quasi-totalité des projets arrêtés.

Pourquoi la plupart des agents ne dépassent pas le pilote

L’écart entre expérimentation et production est massif, et les causes sont constantes.

Le jugement demandé n’est pas formalisable. Personne dans l’organisation ne sait énoncer la règle, chaque cas se tranche à l’expérience. L’agent produit alors des décisions que le métier refuse, non parce qu’elles sont fausses mais parce qu’elles ne correspondent à aucune règle explicitée. Un processus qu’un collaborateur ne sait pas documenter ne s’automatise pas.

Le périmètre est resté ouvert. Vouloir couvrir un service entier dès le premier jour expose l’agent à des dizaines de cas limites en quelques jours. La confiance tombe avant la première mesure, et le projet s’arrête.

Les données sont sales. L’agent hérite de la qualité du système d’information qu’il interroge. Un référentiel client incohérent produit des actions incohérentes, à une vitesse qu’aucun humain n’aurait atteinte.

L’intégration au système d’information bloque. C’est l’obstacle le plus cité par les organisations : connecter un agent aux systèmes métier existants, avec les bons droits et une traçabilité exploitable, représente l’essentiel de la charge du projet. Le modèle n’en est pas le sujet.

En complément : En 2026, les chiffres circulants opposent 40% d’entreprises déployant des agents à 95% d’initiatives GenAI sans impact financier mesurable. Ces écarts reflètent des périmètres et définitions hétérogènes : adoption, passage en production, ROI ou valeur business ne sont pas comparables. Source Mckinsey

Ce qui distingue un agent qui tient en production

La ligne la plus importante est la dernière. Un agent sans propriétaire métier désigné devient orphelin dès que l’équipe projet passe au sujet suivant, et personne ne traite les dérives.

Le seuil de rupture du pilotage

Un point rarement documenté mérite d’être posé aux organisations qui multiplient les cas d’usage : le suivi artisanal, par tableurs, canaux de discussion et revues manuelles, cesse de fonctionner au-delà de quelques dizaines de systèmes en production.

Passé ce seuil, plus personne ne sait quels agents tournent, avec quels droits, ni qui les a validés. C’est le moment où il faut un registre des systèmes d’IA, des indicateurs communs et un comité de pilotage avec revue périodique des métriques et des incidents. Ce registre est par ailleurs la pièce maîtresse de la conformité, traitée dans notre section gouvernance IA et AI Act.

L’instrumentation à prévoir : qualité des décisions sur un jeu de contrôle, taux d’escalade vers un humain, erreurs d’appel d’outils, coût par exécution, latence, adoption réelle. Voir notre section observabilité et monitoring.

L’obligation que les projets découvrent trop tard

Le déploiement d’un agent qui modifie les conditions de travail relève de l’information et de la consultation des instances représentatives du personnel. Ce n’est pas une formalité : la Cour d’appel de Paris a jugé le 21 mai 2026 qu’un déploiement d’outils d’IA générative ou d’agents métier sans consultation préalable du comité social et économique peut entraîner la suspension judiciaire de l’outil.

La conséquence pratique pour une DSI : le calendrier de consultation doit figurer dans le plan de déploiement, au même titre que la recette technique. Une suspension prononcée après mise en production coûte davantage qu’un trimestre de préparation.

En complément : Arrêts CA Paris, pôle 1 ch. 2, 21 mai 2026, RG n° 25/13232 et 25/13234 : suspension d’outils IA générative déployés sans consultation préalable du CSE, qualifiés de « technologie nouvelle » impactant l’organisation du travail. Portée : tout déploiement d’IA métier doit intégrer le calendrier CSE au plan de projet, sous peine de suspension judiciaire coûteuse.

À cela s’ajoutent les obligations de transparence en vigueur depuis le 2 août 2026, et la qualification du système au regard des annexes du règlement européen lorsqu’il intervient dans un processus de recrutement, de notation ou de gestion des ressources humaines.

Séquencer un déploiement

1. Choisir un processus formalisable, dont la règle peut être écrite par le métier. C’est le critère de sélection le plus prédictif.

2. Écrire le périmètre avant la première ligne de code : systèmes accessibles, droits, actions interdites, conditions d’arrêt.

3. Prototyper sur données réelles, pas sur un jeu préparé. Un prototype qui ne rencontre aucun cas limite n’a rien démontré.

4. Lancer la consultation des instances représentatives en parallèle du développement, pas après.

5. Faire tourner en parallèle du processus existant sur un volume restreint, et comparer les décisions.

6. Mettre en production avec supervision, seuil d’escalade actif et propriétaire métier désigné.

7. Mesurer et corriger, en faisant évoluer le jeu de contrôle avec les cas rencontrés.

Explorer le cluster

Cette page fait partie de notre couverture de l’intelligence artificielle, de la donnée et des plateformes : gouvernance, socle technique et industrialisation.

iTPro+ : recevez chaque semaine les analyses IA et data qui concernent les directions informatiques.