Agent IA en grand compte : quels cas d’usage passent en production

Qu’est-ce qu’un cas d’usage d’agent IA en production ?

Un agent IA se démontre en quelques jours devant un comité. Il se met en production en quelques trimestres, et souvent jamais : S&P Global relevait en 2025 que 46 % des POC d’IA étaient abandonnés avant d’atteindre la production. Dans les grands comptes du CAC 40 et du SBF 120, le tri entre ce qui reste bloqué au stade pilote et ce qui passe en production se joue tôt, au moment du choix du cas d’usage, bien avant les questions d’architecture.

Un cas d’usage d’agent IA en production désigne une tâche métier récurrente qu’un agent exécute sur le système d’information réel, avec un propriétaire métier nommé, des points de validation humaine explicites et une trace consultable de chaque action. Tant qu’une de ces conditions manque, le déploiement reste un pilote, quel que soit le volume traité.

Ce qui change au passage en production

La frontière relève de l’organisation. Elle décide qui signe, qui prend l’appel quand l’agent se trompe un vendredi soir, et sur quelle ligne budgétaire il vit l’année suivante. Un pilote se finance sur un budget d’innovation. Un agent en production se finance sur le budget de la fonction métier qu’il sert, et c’est ce transfert qui bloque la plupart des projets.

Dans un grand compte, ce passage déclenche aussi les contrôles que le pilote avait contournés : revue de sécurité par l’équipe du RSSI, gestion des identités et des droits de l’agent, analyse d’impact sur la protection des données quand le traitement l’exige, rattachement au support informatique et à la gestion des changements. Ce sont les contrôles de toute application qui écrit dans le système d’information, et un agent qui agit sur un ERP ou un CRM en est une.

Quels cas d’usage d’agents IA passent réellement en production ?

Ceux qui partagent une même forme : une tâche répétitive à volume connu, une sortie qu’un humain vérifie plus vite qu’il ne la produirait et des données déjà accessibles sans nouveau chantier d’intégration. Dans les grandes entreprises françaises, cette forme se retrouve dans les familles de tâches suivantes.

1. Traitement documentaire à volume : contrats, factures fournisseurs, dossiers d’adhésion, pièces de sinistre. L’agent lit, extrait, contrôle la cohérence et prépare la décision.
2. Support interne et service client de premier niveau : qualification de la demande, recherche dans les procédures, rédaction de la réponse, escalade dès que le cas sort du cadre prévu.
3. Recherche et synthèse sur corpus internes : juridique, conformité, qualité, R&D. L’agent retrouve les pièces pertinentes et rend une note sourcée que l’expert relit.
4. Assistance au développement et à la maintenance applicative : lecture de code ancien, tests, documentation, préparation de correctifs sur des applications que plus personne ne connaît de mémoire.
5. Préparation de dossiers et de comités : achats, risque, crédit, revue de portefeuille. L’agent rassemble les éléments et met en évidence les écarts, l’humain décide.
6. Contrôle et rapprochement : conformité réglementaire, qualité des données de référence, écarts entre deux systèmes qui devraient dire la même chose.

Des tâches qui ont cette forme, dans le retail et la finance

Dans le retail, un agent peut par exemple traiter les réclamations de livraison à partir du suivi transporteur et de l’historique client : il répond seul aux demandes courantes, dans les limites fixées par l’entreprise, et laisse un conseiller valider les gestes commerciaux hors règles ou la réponse à un client mécontent. C’est la structure du travail qui rend ce déploiement possible, et elle se retrouve en banque, en industrie ou dans le service public.

Une direction financière fonctionne de la même façon. Un agent de rapprochement en comptabilité fournisseurs peut traiter seul les factures qui correspondent exactement à une commande et à une réception, préparer un dossier pour chaque exception et laisser la direction financière arbitrer les écarts au-delà du seuil qu’elle a fixé. Le volume est connu d’avance, et chaque rapprochement proposé se contrôle en un instant.

Ces familles se recoupent avec ce que nous observons sur les agents IA en entreprise. Elles sont techniquement modestes et franchement ennuyeuses, ce qui les rend industrialisables : le volume se prévoit, le contrôle est rapide et le périmètre bouge peu d’un mois à l’autre.

Assistance au développement et rapprochement : les limites à connaître

L’assistance au développement monte vite en charge, mais elle exige une discipline de revue, faute de quoi l’agent ajoute discrètement du travail en aval. Le rapprochement paraît trivial jusqu’au moment où l’on découvre que les deux systèmes divergent par construction : l’agent a alors mis au jour un désaccord d’organisation. Reste à décider quel système fait foi avant d’autoriser l’agent à corriger quoi que ce soit.

Qu’est-ce qui distingue un cas d’usage qui passe d’un cas d’usage qui cale ?

Le tri repose sur des critères que l’on peut tous vérifier avant la première ligne de code, en atelier avec le métier et sans prototype.

Un volume mesuré et une sortie rapide à vérifier

La répétition se mesure. Si personne ne sait combien de fois par mois la tâche est réalisée, ni par combien de personnes, l’agent reposera sur des anecdotes. Or le comité d’investissement demandera un dénominateur.

La sortie se vérifie plus vite qu’elle ne se produit. Une note de synthèse pourrait se relire en quelques minutes là où sa rédaction en demanderait bien davantage. Un plan de trésorerie généré par un agent échoue au test : le vérifier revient à le refaire. Les cas d’usage où le contrôle coûte aussi cher que la production ne franchissent pas la mise en service.

Des données accessibles, une erreur réversible, un propriétaire nommé

L’accès aux données est déjà tranché. Un agent qui a besoin d’un référentiel dont la propriété n’est pas arbitrée déclenche un projet de gouvernance de la donnée avant de déclencher un projet d’IA. Ce projet dure plus longtemps que la fenêtre d’attention du sponsor.

Le coût d’une erreur est borné et réversible. Une proposition mal rédigée se corrige. Un virement lancé, beaucoup moins. Les premiers agents en production travaillent presque toujours en amont d’un geste irréversible.

Un propriétaire métier est nommé. Le nom d’une personne, au niveau où les cas limites se tranchent. Elle valide les règles d’escalade et rend compte du résultat. C’est le critère qui manque le plus souvent, et il ne se rattrape pas après coup : au moment de passer en production, on découvre que le cas d’usage appartenait à l’équipe innovation, donc à personne.

Appliquer les critères comme des filtres

Une grille pondérée, où chaque critère reçoit une note sur cinq, laisse un cas d’usage spectaculaire compenser l’absence de propriétaire par une forte valeur estimée : c’est ainsi que des projets sans responsable arrivent jusqu’au comité de mise en production, où ils s’arrêtent. Nous conseillons de traiter les critères comme des filtres éliminatoires : un critère non rempli sort le cas d’usage de la liste courte, jusqu’à ce que le métier ait réglé le point en question.

Ces filtres forment une première étape, que l’entreprise peut conduire seule avant de chiffrer la valeur des cas d’usage restants. La priorisation en est une autre : un audit flash comme Claude Ignite applique à toutes les opportunités identifiées une matrice valeur/faisabilité à six critères, dont le volume traité, la disponibilité des données et le risque de gouvernance, et en retient trois à cinq pour une feuille de route jalonnée de décisions go/no-go.

Pourquoi les cas d’usage les plus spectaculaires ne passent-ils pas ?

Parce qu’ils ont été choisis pour convaincre un comité. L’agent qui négocie et décide seul à la place d’une expertise entière fait une excellente démonstration en comité de direction. Il échoue ensuite sur les cinq critères en même temps : volume mal connu, sortie invérifiable, données éparpillées, erreurs coûteuses, personne pour en répondre.

Les chiffres du MIT et de Gartner, et notre lecture

Le MIT chiffrait en 2025 à 95 % la part des pilotes d’IA générative sans effet mesurable sur le compte de résultat. Gartner anticipait en 2025 l’annulation de plus de 40 % des projets d’IA agentique d’ici fin 2027, en raison de la hausse des coûts, d’une valeur métier peu claire ou de contrôles de risque insuffisants. Nous lisons dans ces deux chiffres un même mécanisme : un portefeuille de démonstrations impressionnantes qu’aucune direction métier ne veut reprendre à son budget.

Partir d’une tâche fréquente et peu visible

L’approche inverse se défend moins bien en comité, et c’est celle que nous privilégions : commencer par la tâche que personne ne revendique en réunion, celle qui occupe plusieurs personnes une partie de leur semaine et dont le résultat se contrôle d’un coup d’œil. Un tel cas d’usage remplit plus facilement les critères décrits plus haut, et les mesures relevées en exploitation servent de base pour choisir le suivant.

Quelles erreurs de sélection font caler un cas d’usage ?

Elles reviennent d’un comité à l’autre, et la plupart se commettent avant la première ligne de code.

• Choisir le cas d’usage d’après une démonstration d’éditeur, jouée sur des données propres et un scénario préparé, sans le confronter aux tâches que la fonction exécute vraiment.
• Confondre la valeur d’une tâche et son volume. Une analyse rare confiée à un expert vaut cher, mais elle ne fournit ni assez de cas pour évaluer l’agent ni le gain répété qui financera son exploitation.
• Sous-estimer le temps de vérification. Si l’expert doit tout relire en détail parce que la sortie ne cite pas ses sources, le gain disparaît, et l’adhésion de l’équipe avec lui.
• Confier la propriété du cas d’usage à l’équipe innovation ou à la DSI, qui portent le projet sans pouvoir trancher les cas limites du métier.
• Viser l’automatisation complète dès le premier jour. Un agent qui commence par proposer, avec une validation humaine systématique, accumule les traces qui justifieront ensuite de lui confier davantage d’autonomie.
• Repousser la question de l’exploitation : qui surveille l’agent, qui met à jour ses instructions, qui répond quand un utilisateur conteste une décision.

Que faut-il mettre en place avant de passer un agent en production ?

Une supervision qui existe avant l’incident. Selon l’édition 2026 du rapport State of AI in the Enterprise de Deloitte, 21 % seulement des entreprises disposent d’une gouvernance mature de leurs agents. À notre lecture, ce manque explique une bonne part de la longueur du dernier mètre.

Zones de confiance, traçabilité et règles d’escalade

Le socle de départ est court. Des zones de confiance, qui définissent ce que l’agent fait seul, ce qu’il propose à validation et ce qu’il n’a pas le droit de toucher. Une traçabilité exploitable, où chaque action retrouve son déclencheur, son contexte et son validateur. Des règles d’escalade écrites, qui disent quoi faire quand l’agent sort de son périmètre. C’est l’objet de notre méthodologie LOOP™ de gouvernance IA. De son côté, l’AI Act imposera aux entreprises qui déploient des systèmes classés à haut risque d’en assurer la surveillance humaine et d’en conserver les journaux, ce qui recoupe largement ce socle. Le règlement (UE) 2026/1744 (omnibus numérique sur l’IA), en vigueur depuis le 27 juillet 2026, fixe les échéances au 2 décembre 2027 pour les systèmes à haut risque autonomes de l’annexe III, comme ceux utilisés pour le recrutement ou le crédit, et au 2 août 2028 pour l’IA intégrée à des produits réglementés, relevant de l’annexe I.

Dans LOOP™, le classement se fait action par action, et un même agent peut relever de plusieurs zones selon ce qu’il s’apprête à faire. En zone verte, au-dessus de 90 % de confiance, l’agent exécute seul et tout est tracé. La zone orange couvre la plage de 70 à 90 % : l’agent propose, un humain désigné valide avant exécution. Sous 70 %, l’agent passe en zone rouge : il s’arrête, documente ce qui lui manque et alerte le responsable désigné, qui doit décider sous 4 heures, sans aucune action automatique entre-temps. La zone noire regroupe ce qui est hors périmètre absolu, avec blocage immédiat et alerte du RSSI.

Pour l’agent de rapprochement évoqué plus haut, les factures qui correspondent exactement peuvent relever de la zone verte et les exceptions au-dessus du seuil de la zone orange. Un paiement suspect, ou un fournisseur dont les coordonnées bancaires viennent de changer, relève de la zone rouge. Ce découpage s’écrit avant le développement, parce qu’il fixe les droits techniques de l’agent dans l’ERP.

Concevoir la supervision dès le cadrage

Ces trois éléments se conçoivent pendant le cadrage du cas d’usage. Ajouter de la traçabilité après coup à un agent déjà en production revient le plus souvent à le réécrire.

Écrits pour un agent précis, ils tiennent sur une page, avec un nom en face de chacun. C’est suffisant pour démarrer, et cela épargne à l’organisation un programme de gouvernance complet avant le premier agent.

Prévoir l’exploitation après la mise en service

Un agent en production peut changer de comportement sans que personne ne touche à son code : nouvelle version du modèle, procédure métier modifiée, documents ajoutés à sa base de connaissances. L’exploitation consiste à repérer ces dérives avant les utilisateurs, avec un jeu de cas réels rejoué avant chaque changement, un suivi du taux d’escalade et des corrections faites par les valideurs, et une procédure écrite pour suspendre l’agent sans interrompre le processus métier.

Cette partie manque souvent aux budgets initiaux. Un programme d’industrialisation des agents comme Claude Ops la prévoit dès le départ : il va de l’audit technique à l’agent en exploitation, maintenance applicative comprise.

Comment choisir le premier cas d’usage à industrialiser ?

En partant de l’inventaire. Listez les tâches récurrentes de deux ou trois fonctions, gardez celles dont le volume est documenté, écartez celles dont la sortie ne se vérifie pas rapidement, puis regardez lesquelles disposent déjà d’un propriétaire métier disposé à s’engager. La liste qui en sort est courte, et le premier cas d’usage se choisit parmi ces candidats.

Compter le volume et interroger le futur propriétaire

Deux habitudes aident à ce stade. Notez le volume avant que la discussion ne bascule sur la technologie : une tâche que personne n’a comptée ne survit pas à un comité d’investissement. Demandez ensuite au futur propriétaire ce qu’il fera le jour où l’agent se trompera. Une réponse floue signale un cas d’usage qui n’est pas prêt, quelle que soit la qualité de la démonstration.

Démarrer en mode miroir, puis ouvrir par étapes

Une fois le cas d’usage choisi, la mise en service gagne à se faire par étapes. L’agent tourne d’abord en mode miroir : il traite des cas réels, ses sorties sont comparées au travail des équipes sans être utilisées, et les écarts servent à régler ses instructions. On ouvre ensuite une partie du flux, avec validation humaine de chaque sortie, puis on élargit la zone verte à mesure que les traces s’accumulent. Le critère de succès se fixe avant la première étape, faute de quoi chaque partie prenante finit par le redéfinir à sa convenance.

Situer l’organisation avant le cadrage

En amont, notre diagnostic de maturité IA situe l’organisation sur le référentiel Koneetiv (édition 2026) en huit questions et environ trois minutes. Il rend un score, un radar sur les six axes du référentiel et un plan d’action priorisé, et ses questions portent entre autres sur le repérage des cas d’usage, les données et la gouvernance des agents. Un score faible sur l’axe des données ou sur celui de la gouvernance signale les cas d’usage que l’organisation ne peut pas encore exploiter.

La rubrique agents IA en production du blog prolonge ce choix du côté de l’architecture : arbitrage entre computer use et API, dépendance à un modèle.