<!-- GENERATED translation. Edit the English source or glossary.json, not this file. -->

Au cours des deux dernières années, j'ai construit plus de cinquante systèmes agentiques de preuve de valeur pour de grandes entreprises : banques, desks de marchés de capitaux, gestionnaires de patrimoine, assureurs, assureurs santé, détaillants, télécoms. Des stacks différents, des environnements réglementaires différents, des définitions différentes de ce qui est "terminé". Vers la trentième construction, le pattern a cessé d'être intéressant pour devenir fiable. C'est la meilleure chose qu'un pattern puisse faire. Les patterns ennuyeux sont ceux sur lesquels on peut baser une feuille de route.

Voici le pattern : les agents prouvent leur utilité dans les chemins d'exception, pas dans les chemins nominaux. Le chemin nominal de presque tous les processus d'entreprise est déjà bien servi par du code. Il est déterministe, à grand volume, peu coûteux à exécuter, et il a généralement déjà été automatisé deux fois. Le chemin d'exception est l'endroit où les documents arrivent avec des pages manquantes, où les contreparties sont en désaccord, où trois systèmes rapportent trois vérités différentes, et où une personne passe quarante minutes à reconstituer ce qui s'est réellement passé. Le chemin nominal veut du code. Le chemin d'exception veut du jugement. Les agents sont un moyen d'acheter du jugement à la vitesse de la machine, et ils ne valent leur coût que là où le jugement était le goulot d'étranglement.

Ce guide est la carte que j'aurais aimé avoir à la cinquième construction. Il couvre les domaines où l'IA agentique a réellement fonctionné parmi ces plus de cinquante constructions, organisés de deux manières : par forme de workflow (l'abstraction utile) et par industrie (la manière dont les acheteurs posent réellement la question). Aucun nom de client n'est mentionné ; les institutions sont généralisées à leur silhouette honnête, comme "une grande banque nord-américaine". Les chiffres sont généralisés de la même manière, comme "de jours à minutes". Et là où quelque chose a échoué, je le dis, car les échecs ont autant dessiné cette carte que les succès.

## L'heuristique d'adéquation : déviation × nombre d'outils × enjeux

Avant tout détail sectoriel, voici le test de sélection que j'applique à chaque cas d'usage candidat. Trois questions, dans l'ordre.

**Déviation.** Dans quelle mesure un cas individuel diffère-t-il du modèle ? Si 95 % des cas suivent les cinq mêmes branches, écrivez du code. Énumérez les branches, encodez-les dans un moteur de règles ou une table de décision, et le tour est joué. Les agents dans les workflows à faible déviation sont une pure surcharge : plus lents, plus coûteux et non déterministes précisément là où le déterminisme était l'exigence. Une déviation élevée est le signal inverse. Lorsque chaque cas est un désordre légèrement différent, l'énumération des branches ne converge jamais, et le coût de maintenance de l'arbre de décision codé à la main dépasse le coût d'exécution d'un modèle capable de lire la situation.

**Nombre d'outils.** C'est mon raccourci, et je l'ai dit dans suffisamment de salles pour le mettre par écrit : trois outils contre dix outils. Si le workflow touche trois systèmes dans un ordre fixe, l'orchestration est un problème résolu. Écrivez les trois appels, câblez la gestion des erreurs, livrez. Si le workflow nécessite dix outils et que le bon appel suivant dépend de ce que le dernier appel a renvoyé, vous n'écrivez plus de code d'intégration. Vous codez à la main un problème de planification, et ce code se dégrade dès que le processus change. C'est là que la boucle de planification d'un agent commence à justifier sa surcharge : non pas parce que le modèle est intelligent, mais parce que l'alternative est un arbre de décision que personne ne maintiendra.

**Enjeux.** Des enjeux élevés ne disqualifient pas les agents. Ils disqualifient les agents non supervisés. Un workflow à forte déviation et à enjeux élevés (juger un prêt hypothécaire, examiner une lettre de crédit, trier une autorisation préalable) est souvent le meilleur cas d'usage possible pour un agent, à condition que l'agent s'exécute à l'intérieur d'un <dfn class="term" data-en="control plane">plan de contrôle</dfn> : portes de validation, une <dfn class="term" data-en="audit trail">piste d'audit</dfn> qui capture chaque appel d'outil et ses entrées, des points de contrôle humains aux décisions importantes, et un fallback déterministe lorsque l'agent est indisponible ou incertain. J'ai couvert l'architecture du <dfn class="term" data-en="control plane">plan de contrôle</dfn> en profondeur dans [Gouverner l'IA Agentique](/fr/guides/governing-agentic-ai/) ; ce guide le considère comme acquis.

La version en grille, puisque la grille est ce que les gens photographient sur la diapositive :

| Déviation | Enjeux | Ce qu'il faut construire |
| --- | --- | --- |
| Faible | Faible | Du code. Ne vous compliquez pas la vie. |
| Faible | Élevé | Du code plus un moteur de règles plus une piste d'audit. Le déterminisme est la fonctionnalité. |
| Élevé | Faible | Un agent léger, révisé après coup, amélioré par des évaluations. |
| Élevé | Élevé | Un agent à l'intérieur d'un plan de contrôle : portes de validation, points de contrôle humain dans la boucle, fallback déterministe. |

Le nombre d'outils est le critère de départage à l'intérieur de chaque cellule. Trois outils vous poussent vers le code même en cas de forte déviation. Dix outils vous poussent vers un agent même lorsque la déviation semble modérée, car une déviation modérée sur dix systèmes se compose en plus de branches que quiconque n'énumérera.

![Quadrant d'adéquation déviation par enjeux : écrire du code, du code plus une révision, un agent légèrement gouverné, et un agent plus un plan de contrôle, avec le critère de départage trois outils contre dix outils sur l'axe de la déviation](/diagrams/fit-heuristic.svg)

> Commentaire de révision : si votre démo d'agent ne montre que le chemin nominal, vous avez démontré la partie du processus qui avait le moins besoin d'un agent.

## Les quatre formes de workflow

Parmi plus de cinquante constructions, presque tout ce qui a fonctionné s'est résumé à quatre formes. Les industries les décorent différemment, mais la structure porteuse se répète. Pour chaque forme, je donnerai les quatre mêmes réponses : ce que fait l'agent, ce qui reste déterministe, où se situe l'humain, et ce qu'il faut mesurer. Si un fournisseur ou une équipe interne ne peut pas vous donner ces quatre réponses concernant leur agent, ils ont une démo, pas une conception.

![Les quatre formes de workflow sous forme de cartes : examen de documents par rapport à un recueil de règles, investigation de preuves à travers les systèmes, triage et résolution d'exceptions, et un concierge guidant un parcours en plusieurs étapes, chacune avec la position de l'humain et un exemple de domaine](/diagrams/workflow-shapes.svg)

### Examen : documents par rapport à un recueil de règles

Un ou plusieurs documents comparés à une norme codifiée. Examen de lettres de crédit par rapport à l'UCP 600. Adjudication de réclamations par rapport aux termes de la police. Soumissions de souscription par rapport aux directives d'appétit. Le recueil de règles est stable et versionné ; les entrées sont désordonnées, scannées et incohérentes. Cette asymétrie est toute l'opportunité.

**Ce que fait l'agent.** Lit l'entrée désordonnée, extrait et normalise les champs, les compare champ par champ au recueil de règles, et rédige un récit de divergence qu'un humain formé peut vérifier en quelques minutes au lieu de le reconstituer en quelques heures.

**Ce qui reste déterministe.** Chaque règle que vous pouvez encoder sans interprétation. L'arithmétique des dates, les seuils de tolérance (la tolérance de quantité de l'UCP 600 est arithmétique, pas un jugement), la logique de routage et la transition de statut finale. L'agent propose ; le code dispose.

**Où se situe l'humain.** Révision des divergences signalées au-dessus d'un seuil de matérialité, et toujours sur la décision de refus ou de rejet. Les documents de personne ne sont rejetés par un modèle seul.

**Ce qu'il faut mesurer.** La précision et le rappel des divergences par rapport à des examinateurs expérimentés, par champ. Le chiffre unique le plus important est le taux de faux positifs : une divergence manquée signifie payer contre des documents non conformes, et cet échec est silencieux jusqu'à ce qu'il devienne coûteux.

### Investigation : preuves à travers les systèmes

Recueillir des preuves de nombreuses sources, résoudre les conflits et synthétiser un dossier. Enquêtes KYC. Triage d'incidents réseau. La propriété définissante est que personne ne sait à l'avance quelles sources seront importantes pour ce cas particulier, ce qui est exactement la propriété qui tue les pipelines codés à la main.

**Ce que fait l'agent.** Planifie ses propres requêtes à travers les registres, les listes de surveillance, les magasins de documents, les journaux et les systèmes internes. Rapproche les preuves contradictoires (deux registres, deux orthographes, une entité). Produit un dossier avec des citations renvoyant aux enregistrements sources.

**Ce qui reste déterministe.** La liste de contrôle des sources obligatoires. Un agent ne peut pas ignorer le filtrage des sanctions parce qu'il se sentait confiant. La formule de notation des risques reste également dans le code, ainsi que les seuils d'escalade. L'agent recueille les preuves ; une formule transforme les preuves en un score.

**Où se situe l'humain.** Sur la décision finale, et de manière non négociable sur les décisions défavorables. Le travail de l'agent est de faire disparaître les quarante minutes d'assemblage de l'humain, pas de faire disparaître la décision.

**Ce qu'il faut mesurer.** L'exhaustivité des preuves : le pourcentage de sources obligatoires que l'agent a réellement consultées, mesuré à partir des journaux d'appels d'outils, et non supposé à partir du prompt. La précision des citations : chaque affirmation du dossier renvoie-t-elle à un enregistrement source réel. Ensuite, le temps de décision, qui est le chiffre que l'entreprise a acheté.

### Triage et résolution : classer, puis choisir un chemin

Une exception arrive ; quelque chose ne correspond pas. Discrepances de bons de commande, paiements échoués, divergences d'avis d'expédition, écarts facture-réception. Le workflow est un diagnostic suivi d'un choix parmi des chemins de remédiation.

**Ce que fait l'agent.** Diagnostique l'exception à partir des preuves et sélectionne un chemin de remédiation parmi un menu limité. Porte un à porte sept. L'agent choisit la porte ; il ne construit jamais une nouvelle porte à l'exécution.

**Ce qui reste déterministe.** Les actions de remédiation elles-mêmes. Chaque chemin est un flux pré-construit, testé et déterministe. L'autorité de l'agent se termine à la sélection ; l'exécution est du code.

**Où se situe l'humain.** Approuvant les chemins irréversibles ou de grande valeur avant l'exécution, et gérant la file d'attente "aucun des choix ci-dessus". Cette file d'attente n'est pas un échec ; c'est le backlog à partir duquel vous concevez le prochain chemin de remédiation.

**Ce qu'il faut mesurer.** Le taux de chemin correct par rapport à un jeu de référence étiqueté. Le taux d'auto-résolution. Et l'asymétrie des coûts d'un mauvais chemin, car cette asymétrie, et non la précision moyenne, détermine où vont les portes d'approbation.

### Concierge : un parcours guidé avec une interface utilisateur générative

Un parcours en plusieurs étapes où l'agent guide une personne à travers un processus : intégration de compte, un achat complexe, une demande de service. Le choix de conception critique, appris à la dure, est l'interface utilisateur générative plutôt que le chat. L'agent génère l'étape suivante de l'interface (un formulaire pré-rempli, un résumé à confirmer, un choix à faire) au lieu de tenir une conversation. Les gens remplissent les formulaires. Ils abandonnent les conversations.

**Ce que fait l'agent.** Conduit le parcours, adapte l'étape suivante à ce qu'il sait déjà de l'utilisateur et du cas, pré-remplit ce qui peut l'être, et explique ce dont il a besoin et pourquoi.

**Ce qui reste déterministe.** La machine à états du processus sous-jacente. Les règles de validation, les étapes de conformité (vérifications d'identité, adéquation) et les limites des données pouvant être affichées. L'agent décore la machine à états ; il ne la remplace pas.

**Où se situe l'humain.** Le client est l'<dfn class="term" data-en="human-in-the-loop">humain dans la boucle</dfn>, étape par étape. Dans les parcours réglementés, il y a un deuxième humain : le réviseur du back-office qui signe avant que quelque chose de contraignant ne se produise.

**Ce qu'il faut mesurer.** Le taux de complétion par rapport à la base de référence du formulaire statique. Où les gens abandonnent. Le taux de correction (à quelle fréquence les valeurs pré-remplies de l'agent sont-elles remplacées). Le taux d'escalade vers un humain.

Les quatre formes, côte à côte :

| Forme | Tâche de l'agent | Noyau déterministe | Position de l'humain | Métrique phare |
| --- | --- | --- | --- | --- |
| Examen | Extraire, comparer, narrer les divergences | Calculs du recueil de règles, seuils, routage | Validation du refus/rejet | Taux de faux positifs |
| Investigation | Recueillir, rapprocher, construire le dossier | Sources obligatoires, formule de notation | Décision finale | Exhaustivité des preuves |
| Triage & résolution | Diagnostiquer, choisir un chemin de remédiation | Les flux de remédiation eux-mêmes | Approbation des chemins irréversibles | Taux de chemin correct |
| Concierge | Conduire le parcours, générer l'étape suivante | Machine à états du processus, portes de conformité | Est le parcours (plus un réviseur) | Taux de complétion |

Une note sur la plomberie avant le tour d'horizon sectoriel. Je les construis sur Camunda parce que je veux le noyau déterministe, les tâches humaines et la <dfn class="term" data-en="audit trail">piste d'audit</dfn> dans une seule couche d'orchestration, mais rien dans les quatre formes ne dépend de ce choix. Les mêmes conceptions se transposent à Temporal, LangGraph avec un bon stockage d'état, ou du Node.js simple avec de la discipline. Les formes d'abord, les produits ensuite.

## Banque : investigation à l'échelle du dossier

La construction bancaire phare, répétée avec des variations dans plusieurs institutions, y compris des banques canadiennes du top 5, était un agent d'enquête KYC : vérification d'identité, analyse de documents, filtrage des sanctions et des médias défavorables, et preuves structurées alimentant un score de risque. Le résultat honnête a été une réduction du temps de préparation des dossiers de jours à minutes. Pas pour la décision, mais pour la préparation. Les analystes sont passés de l'assemblage des dossiers à leur examen, ce qui est à la fois le gain de productivité et le contrôle : un humain reste propriétaire de chaque décision. Autour de ce noyau se trouvaient les autres constructions bancaires : adjudication de crédits et de prêts hypothécaires avec des portes de validation de type agent-juge sur le produit de travail, gestion des exceptions de paiement (une forme de triage pur), et des flux d'open banking où les agents orchestrent l'accès aux données consenties entre les institutions, un pattern sur lequel j'ai écrit publiquement sur le blog Camunda.

La banque convient parce que le KYC est parfaitement de forme investigation. Chaque cas est un désordre différent : structures d'entreprise complexes, variantes de noms à travers les écritures, données de registre qui se contredisent. L'énumération des branches ne converge jamais, et le nombre d'outils dépasse largement dix avant même d'avoir fini de lister les listes de surveillance. C'est la cellule la plus claire à forte déviation et à enjeux élevés de la grille, c'est pourquoi elle exige également le plan de contrôle le plus lourd que je construise.

Le piège dans la banque est de laisser l'agent calculer le score de risque. Il le fera volontiers, et il aura l'air autoritaire. Gardez la séparation claire : preuves de l'agent, score d'une formule que les équipes de risque de modèle peuvent lire, versionner et contester. Un régulateur demandant "pourquoi cette notation" obtient une réponse construite à partir de preuves vérifiables par l'homme et d'une formule déterministe. "Le modèle a pesé les facteurs" n'est pas une réponse, et d'après mon expérience, les institutions le savent avant leurs fournisseurs.

## Marchés de capitaux : le recueil de règles était le cadeau

La construction que je cite le plus est l'examen des lettres de crédit par rapport à l'UCP 600 : détection des divergences champ par champ entre la LC, la facture, le connaissement et les certificats de support, avec un fallback déterministe à l'examen manuel chaque fois que la confiance d'extraction tombait en dessous du seuil. La forme mesurée dans la preuve de valeur était de quelques heures à quelques secondes par ensemble de documents. J'ajouterai immédiatement la mise en garde honnête : ce chiffre provenait d'un ensemble de documents organisé. Les scans de production sont pires, l'écriture manuscrite existe, et le chemin de fallback n'est pas un extra facultatif, c'est la raison pour laquelle le chiffre est autorisé à exister. À côté de l'examen des LC se trouvaient la réconciliation des transactions, la remédiation post-transaction, et la gestion des demandes et exceptions de transactions, qui se sont toutes avérées être des formes de triage : l'agent classe la rupture et sélectionne la remédiation, le code l'exécute.

Les marchés de capitaux conviennent parce qu'ils vous offrent l'actif le plus rare dans ce travail : un recueil de règles stable, versionné et régi de l'extérieur. L'UCP 600 n'a pas changé depuis 2007. Les entrées sont le chaos, la norme est de pierre, et les agents de forme examen vivent exactement dans cet écart. Les examinateurs de documents sont rares, coûteux et partent à la retraite ; le côté demande de cette construction n'a jamais été difficile à expliquer.

Le piège est de considérer le "conforme" de l'agent comme définitif. Un faux positif dans l'examen des LC signifie qu'une banque paie contre des documents non conformes, et la perte arrive des mois plus tard, portant la signature de quelqu'un d'autre. Chaque version sérieuse de cette construction a maintenu un régime d'échantillonnage humain réexaminant une partie des verdicts "propres", avec le taux de faux positifs sur un tableau de bord où le chef de desk pouvait le voir. Lorsque le taux d'échantillonnage tend vers zéro, le contrôle a échoué, quoi que dise le graphique de précision.

## Gestion de patrimoine : le concierge qui a dû gagner la confiance des conseillers

Pour les gestionnaires de patrimoine, j'ai construit des concierges d'intégration avec une interface utilisateur générative (la forme de parcours, exactement comme décrit ci-dessus) et un flux d'évaluation des risques et de recommandation de portefeuille où l'agent rédige et un conseiller révise. Le travail d'intégration est l'endroit où je suis devenu convaincu que l'interface utilisateur générative l'emporte sur le chat pour les parcours : la complétion, et non la qualité de la conversation, est la métrique, et les interfaces en forme d'étapes se complètent. Le flux de recommandation est l'endroit où le placement de l'<dfn class="term" data-en="human-in-the-loop">humain dans la boucle</dfn> a le plus compté. L'agent assemble le profil client et rédige une proposition ; les règles d'adéquation s'exécutent de manière déterministe ; le conseiller révise, modifie et est responsable de ce que le client voit.

La gestion de patrimoine est aussi l'endroit où ma pratique d'évaluation s'est développée. Lors d'une preuve de valeur dans une grande banque nord-américaine, nous avons comparé les modèles sur le workflow réel plutôt que de faire confiance à la tarification par niveau, et avons constaté qu'un modèle de niveau intermédiaire égalait la précision du modèle premium à environ 1/13e du coût, avec des <dfn class="term" data-en="skip rate">taux d'omission</dfn> d'outils mesurés à partir des journaux, et non supposés. Cette découverte a changé la façon dont j'aborde chaque construction depuis, et c'est l'histoire d'origine de [Évaluer les Systèmes Agentiques](/fr/guides/evaluating-agentic-systems/). La leçon générale est la suivante : dans les workflows agentiques, la boucle d'outils et les garde-fous font plus de travail que la qualité brute du modèle, alors mesurez avant de payer.

Le piège dans la gestion de patrimoine est d'envoyer la recommandation directement au client parce que le brouillon semble soigné. Le soin est précisément le risque. Une proposition de portefeuille fluide mais erronée est plus dangereuse qu'une proposition maladroite, car rien à sa surface n'invite à l'examen. La porte du conseiller n'est pas un arrangement transitoire à optimiser ; dans un régime d'adéquation, c'est le produit.

## Assurance : la souscription comme examen plus jugement

La construction pour l'assurance était un support de souscription P&C commerciale : intelligence documentaire sur la soumission (historiques de sinistres, tableaux de valeurs, e-mails de courtiers qui enterrent le fait matériel au paragraphe neuf), règles déterministes d'appétit et de risque, et un agent de jugement validant le produit de travail assemblé avant qu'un souscripteur ne le voie. Le résultat a été une réduction du temps de préparation du devis, passant de jours d'assemblage à moins d'une heure de révision, avec chaque extraction et chaque règle déclenchée enregistrées pour la piste d'audit. Le système a été conçu dès le premier sprint pour répondre aux attentes des régulateurs, et non adapté après coup, car dans l'assurance, l'aspect audit fait partie de la vente.

La souscription convient parce qu'elle a la forme d'un examen avec une garniture d'investigation. Le guide d'appétit est le recueil de règles ; la soumission est l'ensemble de documents désordonné ; et la déviation est énorme car aucun risque commercial n'arrive décrit de la même manière. Le nombre d'outils dépasse également la barre, une fois que l'on compte les parseurs d'historiques de sinistres, les services de données immobilières, les contrôles de sanctions et les systèmes d'exposition internes.

Le piège est d'enterrer les règles d'appétit dans le prompt. Cela fonctionne dans la démo, puis cela dérive, silencieusement, d'une manière qu'aucun responsable des risques ne peut inspecter. Les règles qui décident si l'assureur veut le risque appartiennent à un moteur de règles (DMN ou équivalent) que la direction de la souscription peut lire, versionner et modifier sans ingénieur de prompt dans la pièce. Le travail de l'agent est de structurer la soumission afin que les règles puissent se déclencher, et non de devenir une copie non versionnée de celles-ci.

## Santé : la vitesse là où la vitesse est sûre

Pour un grand assureur santé américain (généralisé, comme tout ici), j'ai construit un traitement des réclamations et un triage de type autorisation préalable. Le principe de conception était l'automatisation asymétrique : l'agent accélère les approbations et rassemble les preuves, et les humains sont propriétaires de chaque refus. Un cas de type approbation est vérifié de manière déterministe par rapport aux critères cliniques et se déplace en quelques minutes. Un cas se dirigeant vers un refus reçoit un dossier de preuves complet et cité et un réviseur humain, point final. La forme mesurée a été le passage de la file d'attente d'approbation de jours à le jour même, tandis que la qualité des décisions de refus s'est améliorée plutôt que de s'accélérer, car les réviseurs partaient d'un dossier assemblé au lieu d'une pile de documents.

Les soins de santé s'adaptent parfaitement aux formes (les réclamations sont de l'examen, le triage des autorisations préalables est du triage), mais ils méritent leur propre section car les enjeux ne sont pas symétriques et la conception doit l'encoder. Une approbation lente coûte de l'argent. Un refus erroné coûte des soins, puis des litiges, puis des gros titres. Toute architecture qui traite ces deux erreurs comme la même classe de défaut est erronée avant la première ligne de code.

Le piège, évidemment mais il faut le dire car l'industrie continue d'essayer, est d'automatiser les refus. C'est le pire endroit dans toutes les industries où je travaille pour placer l'autonomie du modèle : juridiquement exposé, éthiquement indéfendable et réputationnellement radioactif. Le discours qui vend et survit est celui des "oui" plus rapides et des "peut-être" mieux préparés. J'ai refusé de construire l'autre version.

## Commerce de détail : les exceptions à l'échelle du Fortune 10

Pour des détaillants de la taille du Fortune 10, j'ai construit un triage des exceptions de commandes et de bons de commande : incohérences de quantité, litiges de prix, divergences d'avis d'expédition, écarts facture-réception. Forme de triage pur. L'agent classe l'exception, rassemble les deux ou trois faits qui la désambiguïsent, et la dirige vers l'un des chemins de remédiation d'un ensemble limité ; les chemins de grande valeur et irréversibles sont mis en file d'attente pour approbation humaine. À cette échelle, l'arithmétique est simple : le volume d'exceptions est si important qu'un taux d'auto-résolution de l'ordre de 60 à 70 % rapporte de l'argent réel, et la file d'attente résiduelle arrivant pré-classifiée avec des preuves jointes rend la moitié humaine plus rapide également.

Le commerce de détail convient parce que la déviation se situe exactement là où se trouve le volume. Le chemin nominal (commande passée, expédiée, reçue, payée) a été automatisé il y a des décennies. La queue d'exceptions n'a jamais été automatisée parce que chaque exception est un cas unique, et les cas uniques sont ce que l'heuristique d'adéquation sélectionne. Le deuxième fil du commerce de détail est le commerce agentique, la forme concierge appliquée à l'achat, que je garde architecturalement séparée car dès qu'un agent peut dépenser de l'argent, le problème de contrôle change d'espèce. Ce problème a sa propre surface de protocole et son propre guide : le [guide de terrain AP2](/fr/guides/ap2-field-guide/).

Le piège est de viser 100 % d'auto-résolution. Le dernier décile d'exceptions n'est pas comme les neuf premiers : c'est là que se trouve la fraude, là que se trouvent les échecs véritablement nouveaux, et là qu'une remédiation erronée et confiante entraîne des pertes d'argent réelles. Limitez l'autorité de l'agent par la valeur et la réversibilité, gardez la file d'attente "aucun des choix ci-dessus" humaine, et traitez cette file d'attente comme le backlog de conception pour le prochain chemin de remédiation plutôt que comme un nombre de défauts à ramener à zéro.

## Télécom : triage avant la salle de crise

La construction pour les télécoms était le triage d'incidents NOC : un agent qui rencontre la tempête d'alarmes, corrèle à travers les couches réseau et les gestionnaires d'éléments, extrait les enregistrements de changements et la topologie, et produit un résumé d'incident avec la cause probable, le rayon d'impact et la prochaine étape de diagnostic suggérée. Forme d'investigation sous pression temporelle. Le résultat a été une réduction du temps de première action significative, passant de dizaines de minutes à quelques minutes, ce qui, en cas de panne, est la seule horloge qui compte.

Les télécoms conviennent parce que les preuves d'incident sont dispersées par conception : alarmes dans un système, changements dans un autre, topologie dans un troisième, impact client dans un quatrième. La corrélation est le travail, chaque incident se corrèle différemment, et le nombre d'outils dépasse confortablement dix. C'est aussi un cas rare où l'"utilisateur" est un expert sous stress, ce qui élève la barre de la qualité du résumé : une cause probable erronée ne fait pas que perdre du temps, elle dirige toute la salle de crise vers la mauvaise couche.

Le piège est de mesurer les résumés produits au lieu du comportement de l'opérateur modifié. Si le NOC ouvre toujours les cinq mêmes consoles et effectue la même corrélation manuelle après avoir lu le résumé de l'agent, vous avez construit une décoration, et une décoration coûteuse de surcroît. Instrumentez ce que les opérateurs font ensuite. Et gardez la remédiation strictement contrôlée : un agent qui peut redémarrer des éléments sur un réseau en direct sans étape d'approbation n'est pas un agent de triage, c'est un changement non révisé du réseau avec un modèle de langage attaché.

## Leçons transversales

Quatre leçons ont survécu au contact avec chaque industrie ci-dessus.

**L'intelligence documentaire est le cheval de bataille.** La vérité peu glamour de cinquante constructions : dans la plupart d'entre elles, la majorité de la valeur livrée consistait à transformer des documents désordonnés en affirmations structurées et notées en confiance. LC, historiques de sinistres, documents KYC, paquets d'autorisations préalables, e-mails de courtiers. Personne ne met l'extraction sur la diapositive de présentation, et rien en aval ne survit sans elle. Si je ne pouvais financer qu'une seule capacité dans un programme d'agents d'entreprise, ce serait celle-ci.

**Les agents de jugement comme portes de validation.** Un deuxième modèle, avec un prompt différent et idéalement une famille de modèles différente, vérifie le produit de travail du premier agent par rapport à une rubrique explicite avant qu'il n'atteigne un humain ou un système d'enregistrement. J'ai utilisé cela dans l'adjudication hypothécaire et la souscription, et c'est l'assurance la moins chère de la pile. Cela ne rend pas le premier agent plus intelligent ; cela rend ses échecs visibles avant qu'ils ne se composent, et cela détecte la dérive que les évaluations par version manquent car cela s'exécute sur chaque cas.

**Chaque système destiné à la production avait un fallback déterministe.** Agent indisponible, confiance d'extraction faible, budget de coût dépassé, verdict du juge échoué : le cas est acheminé vers le chemin manuel ou codé préexistant. Le système se dégrade vers le processus d'hier, pas vers le néant. C'est aussi, discrètement, ce qui a fait que les équipes de risque et de conformité ont donné leur accord. Le discours n'est pas "faites confiance à l'agent", c'est "le pire des cas est le processus que vous exécutez déjà".

**Le placement de l'humain dans la boucle est une décision de conception, pas une réflexion après coup.** Approuver avant d'agir lorsque les actions sont irréversibles ou de grande valeur. Réviser après coup lorsqu'elles sont faciles à annuler. Régimes d'échantillonnage lorsque le volume interdit une révision complète. Chaque placement achète un compromis différent entre risque et débit, et le choix appartient à l'atelier de conception, pas à la semaine de panique après la lecture du pilote. Chaque histoire d'échec de l'humain dans la boucle que j'ai vue était un placement choisi par défaut plutôt que par décision.

## Ce qui n'a pas fonctionné

La section honnête, car les échecs ont dessiné la carte.

**Workflows à faible déviation forcés dans des agents.** Le cas le plus clair était un flux d'approbation de gestion des accès. La logique d'approbation était une matrice : rôle, ressource, sensibilité, chaîne de managers. Entièrement encodable. La version agent que nous avons d'abord esquissée était plus lente, plus coûteuse et non déterministe précisément là où l'équipe de sécurité avait besoin de déterminisme. Le code a gagné, et ce n'était pas serré. Le seul agent qui a survécu était un agent léger à l'entrée, interprétant les requêtes en texte libre en requêtes structurées, ce qui est de l'intelligence documentaire sous un autre nom. La déviation était faible, les outils étaient trois, et l'heuristique avait la réponse avant nous.

**Interfaces de chat boulonnées à des processus que personne n'avait demandés.** Au début, plus d'une fois, j'ai livré un "chat avec votre processus" parce que cela fait de belles démos. Cela a impressionné en réunion et est mort en pilote, à chaque fois. Le travail des utilisateurs était une file d'attente, et ils voulaient que la file d'attente soit traitée, pas une conversation sur la file d'attente. La distinction qu'il m'a fallu trop de temps pour articuler : l'interface utilisateur générative à l'intérieur d'un parcours fonctionne, car elle fait avancer l'utilisateur ; le chat comme couche sur un processus existant ajoute une étape de traduction à un travail qui avait déjà une interface plus rapide.

**Théâtre de l'autonomie.** Plusieurs demandes se sont résumées à envelopper un seul appel API dans une boucle d'agent afin que la feuille de route puisse dire "agentique". Un outil, un chemin, pas de jugement. C'est un appel de fonction avec des étapes supplémentaires et une facture par token. Je le dis maintenant dès la première réunion, et cela ne m'a rien coûté : les équipes qui l'entendent font confiance aux recommandations qui suivent.

> Commentaire de révision : une fenêtre de chat n'est pas un cas d'usage. Si le travail de l'utilisateur est une file d'attente, construisez pour la file d'attente.

## La version en un paragraphe

Après plus de cinquante constructions d'entreprise, le pattern est ennuyeux et fiable : les agents prouvent leur utilité dans les chemins d'exception, pas dans les chemins nominaux, car le chemin nominal veut du code et le chemin d'exception veut du jugement. Filtrez chaque candidat avec déviation × nombre d'outils × enjeux (trois outils dans un ordre fixe signifie écrire le code ; dix outils dont l'ordre dépend des données signifie qu'un agent peut justifier sa surcharge ; des enjeux élevés signifie que l'agent vit à l'intérieur d'un plan de contrôle). Presque tout ce qui fonctionne est l'une des quatre formes : examen (documents par rapport à un recueil de règles), investigation (preuves à travers les systèmes), triage et résolution (classer, puis choisir un chemin de remédiation limité), et concierge (un parcours guidé avec une interface utilisateur générative, pas de chat). Dans chaque forme, gardez les formules de notation, les recueils de règles et les actions de remédiation déterministes, placez un agent de jugement devant tout ce qui est conséquent, placez les humains aux décisions par conception plutôt que par défaut, et maintenez un fallback déterministe afin que le pire des cas soit le processus que vous exécutez déjà. Lorsque la déviation est faible, le code l'emporte, et la chose honnête est de le dire dès la première réunion.

## Références

- [Gouverner l'IA Agentique](/fr/guides/governing-agentic-ai/), mon guide de terrain sur l'architecture du plan de contrôle supposée tout au long de ce document : portes de validation, pistes d'audit, points de contrôle humain dans la boucle, fallbacks déterministes.
- [Évaluer les Systèmes Agentiques](/fr/guides/evaluating-agentic-systems/), la pratique d'évaluation derrière les chiffres "mesurés, non supposés" ici, y compris les <dfn class="term" data-en="skip rate">taux d'omission</dfn> d'outils et le benchmarking coût-qualité.
- [Guide de terrain AP2](/fr/guides/ap2-field-guide/), pour le commerce agentique et le problème de contrôle distinct des agents qui dépensent de l'argent.
- [Utiliser A2A pour atteindre vos objectifs commerciaux, partie 1](https://camunda.com/blog/2026/02/using-a2a-to-achieve-your-business-goals-pt-1/) et [partie 2](https://camunda.com/blog/2026/02/using-a2a-to-achieve-your-business-goals-pt-2/), articles de blog Camunda que j'ai co-écrits sur la coordination multi-agents.
- [L'IA Agentique met l'Open Banking au travail](https://camunda.com/blog/2025/12/agentic-ai-puts-open-banking-to-work/), article de blog Camunda couvrant les flux d'open banking référencés dans la section bancaire.
- ICC Uniform Customs and Practice for Documentary Credits (UCP 600), le recueil de règles derrière la construction d'examen des lettres de crédit.
- Dépôts publics et démos : [github.com/letmereviewyourcode](https://github.com/letmereviewyourcode).