Ce que nous entendons par agent
Un agent IA est un logiciel qui utilise un modèle de langage pour décider des étapes à suivre, puis les exécute au moyen d’outils : recherche dans des documents, appels d’API, mise à jour d’enregistrements. Ce qui le distingue d’un chatbot, c’est l’action. Ce qui le distingue de l’automatisation classique, c’est le jugement.
Ce jugement est aussi risqué qu’utile, et c’est pourquoi le travail de conception compte davantage que le choix du modèle.
Là où les agents excellent aujourd’hui
Les agents donnent le meilleur d’eux-mêmes quand l’objectif est clair, que les informations nécessaires sont accessibles via des outils et que les erreurs sont faciles et peu coûteuses à repérer. Ces tâches correspondent à cette description :
- Recherche dans les documents et systèmes internes
- Transformation de documents en données structurées
- Rédaction de réponses, rapports et relances à faire valider
- Orientation et tri des demandes, avec le raisonnement affiché
Là où ils peinent encore
Les longues chaînes de décisions interdépendantes, les objectifs flous et les actions difficiles à annuler restent compliqués. Un agent qui a raison 95 % du temps à chacune de dix étapes n’a raison qu’environ 60 % du temps sur l’ensemble du parcours.
C’est pour cette raison que nous laissons des humains valider les étapes à fort impact et que nous concevons les agents autour de séquences courtes et vérifiables.
Choisir votre premier agent
Évaluez les processus candidats selon le volume, la valeur par tâche, la disponibilité des données et la réversibilité. Le meilleur premier agent prend généralement en charge une tâche fréquente dont le résultat est déjà relu par quelqu’un. Il fait gagner du temps sans ajouter de nouveau risque.
La gouvernance à mettre en place avant le deuxième agent
Trois éléments : un inventaire des agents et de ce à quoi chacun a accès, une journalisation de chaque action, et un processus de revue pour élargir les droits. Aucun n’est difficile à mettre en place tôt. Tous sont pénibles à ajouter après coup, une fois que dix équipes ont leurs propres agents.
Décrire la mission avant de choisir l’agent
Le premier périmètre décrit déclencheur, informations nécessaires, actions autorisées et critères d’achèvement. Il nomme la personne capable d’accepter le résultat. Sans frontières, le modèle doit interpréter l’entreprise en plus d’exécuter la tâche : démonstration et incident deviennent difficiles à évaluer.
Pour orienter des demandes, étiqueter un message ne suffit pas. Il faut des destinations autorisées, le contexte client accessible et un relais pour les cas incertains ou sensibles. Le processus manuel fournit la comparaison : demandes traitées, contrôles et découverte des erreurs. Ce périmètre donne des tests concrets et révèle si une règle déterministe résoudrait le besoin avec moins d’incertitude.
Le contrat d’outil est une frontière métier
Les outils transforment une décision du modèle en effet réel. Chaque opération demande entrées validées, identifiants limités et résultat observable. Une recherche client et un ordre de paiement ne doivent pas partager une interface sans limites parce qu’il s’agit de deux appels API. Les droits suivent la mission et l’autorisation requise.
Un timeout peut survenir après acceptation. Rejouer sans identifiant d’opération peut répéter l’action. Une réponse peut être incomplète ou contenir des données à ne pas exposer. Ces cas appartiennent à la conception et aux tests. Le dirigeant n’a pas à examiner chaque champ, mais le plan doit expliquer les limites du rôle et le traitement des résultats incertains.
Évaluer le processus complet
Une réponse convaincante n’est qu’une observation. Le processus doit aussi utiliser la bonne source, les droits corrects, un appel valide et atteindre l’état attendu. L’évaluation couvre tâches représentatives, informations absentes, dossiers contradictoires, accès refusé et système indisponible. Des exemples faciles ne justifient pas des droits élargis.
Le calcul des étapes répétées est une illustration de planification : multiplier des taux suppose que les probabilités restent pertinentes dans la séquence. Les échecs peuvent être corrélés et les entrées modifier le comportement. Testez donc des tâches complètes plutôt qu’un score global. Versionnez les exemples, examinez les échecs et relancez les contrôles après changement de consignes, récupération, modèle ou outils. Consignez les critères réussis, pas seulement une moyenne séduisante.
Concevoir la validation humaine comme un produit
La revue présente action, preuves et effet attendu sous une forme compréhensible. Un clic sans contexte déplace le risque au lieu de le contrôler. Il faut pouvoir refuser, corriger ou escalader et conserver la décision dans la trace d’exécution.
Définissez l’attente et l’absence d’approbation : une demande client ne doit pas rester indéfiniment dans une file. Le responsable métier choisit actions automatiques et actions revues. L’ingénierie impose ces choix par permissions et outils. Le modèle ne peut pas s’attribuer un rôle plus large avec une explication persuasive. Le temps de revue fait partie du coût opérationnel.
Budgéter l’exploitation de l’agent
La facture du modèle ne représente qu’une partie du coût. Récupération, systèmes, évaluations, support et exceptions comptent aussi. Identifiez l’usage qui génère la dépense et son attribution. Budgets et alertes doivent atteindre une personne capable d’enquêter ou de suspendre le système, avec une voie de continuité pour le travail métier.
La qualité demande aussi un responsable pour examiner les échecs, enrichir l’évaluation et adapter l’agent au processus. Un droit approprié hier peut ne plus l’être après une intégration. Nommez responsable métier, mainteneur et autorité de publication. Le choix est opérationnel et produit, pas seulement un achat de modèle : le système complet doit valoir la peine d’être exploité après la démonstration.
La décision à apporter à l’appel de cadrage
Apportez un processus candidat et son fonctionnement actuel, les systèmes, les données disponibles et les actions nécessitant approbation. Pour un pilote existant, fournissez le code ou une description de ce qu’il fait et de ses limites. Sans pilote, apportez le problème plutôt qu’une obligation d’utiliser un modèle précis.
La suite peut être découverte, validation ciblée, intégration ou agent sur mesure, mais aussi correction du processus ou des connaissances. La proposition précise chemin, preuves, dépendances et propriétaires. Comparez package et service selon leurs livrables. Le guide donne des fourchettes ; le périmètre écrit fixe l’engagement. Cela permet un premier investissement responsable sans supposer que toute entreprise doit commencer par l’autonomie.
