Un agent n’est pas un chatbot auquel on a ajouté des outils
Une démonstration d’agent IA peut être montée rapidement : un modèle reçoit une consigne, choisit une fonction, consulte une source puis formule une réponse. Cette fluidité donne parfois l’impression que l’essentiel est déjà acquis. Pourtant, le passage à un usage métier change complètement la nature du problème.
Dans une entreprise, l’agent doit composer avec des données incomplètes, des droits d’accès, des outils indisponibles, des consignes contradictoires et des actions qui ont un coût. Une réponse plausible ne suffit plus. Il faut savoir ce que l’agent a compris, ce qu’il a consulté, pourquoi il a agi et comment revenir en arrière.
Un agent fiable est donc moins un personnage autonome qu’un système logiciel orchestré. Le modèle de langage y occupe une place importante, mais il reste entouré de code déterministe, de politiques d’accès, de validations et d’observabilité.
Partir d’un résultat métier délimité
« Automatiser le support » est trop large. « Préparer une proposition de réponse pour les demandes de niveau 1, à partir de la base de connaissances validée, puis la soumettre à un conseiller » est exploitable. Cette seconde formulation indique un déclencheur, une source, une sortie et un responsable final.
Avant de choisir une architecture, décrivez le parcours sous forme de contrat :
- l’événement qui déclenche le traitement ;
- les données nécessaires et leur propriétaire ;
- les outils que l’agent peut consulter ou modifier ;
- les actions interdites ou soumises à validation ;
- la forme attendue du résultat ;
- la personne ou le système responsable en cas d’incertitude.
Ce cadrage permet aussi de définir une unité de valeur mesurable. Pour un agent qui prépare un dossier commercial, il peut s’agir d’un dossier complet, sourcé et accepté par le chargé d’affaires. Le nombre de messages échangés avec le modèle est secondaire.
Concevoir une architecture en couches
Une architecture robuste sépare les responsabilités. Le modèle raisonne sur un contexte préparé ; il ne devrait pas porter seul la sécurité, la persistance ou la logique transactionnelle.
Orchestration
Elle contrôle les étapes, les délais, les reprises et les transitions d’état.
Connaissance
Elle fournit des informations autorisées, versionnées et traçables.
Contrôle
Il valide les entrées, les sorties et les actions avant tout effet réel.
:::
L’orchestrateur garde la maîtrise du parcours
L’orchestrateur doit savoir où en est chaque exécution. Il peut imposer un nombre maximal d’étapes, interrompre une boucle, reprendre après une erreur temporaire et demander une validation humaine. Les transitions importantes — par exemple « brouillon », « approuvé », « envoyé » — gagnent à être représentées explicitement plutôt que déduites d’une conversation.
Les outils restent petits et prévisibles
Un outil destiné à l’agent devrait effectuer une opération claire, avec un schéma d’entrée strict et une réponse structurée. Une fonction « gérer le CRM » est difficile à contrôler. Des fonctions séparées « rechercher une entreprise », « lire une opportunité » et « proposer une mise à jour » sont plus faciles à autoriser, tester et journaliser.
Pour les opérations sensibles, distinguez lecture et écriture. L’agent peut préparer une modification, tandis qu’une règle ou un humain décide de son application. Cette séparation réduit fortement le rayon d’impact d’une mauvaise interprétation.
La mémoire n’est pas un historique illimité
Accumuler toutes les conversations dans le contexte finit par augmenter le bruit, le coût et les risques de fuite. La mémoire utile est sélective : préférences explicitement acceptées, faits vérifiés, état de la tâche et résumé des décisions. Chaque élément devrait avoir une origine, une durée de conservation et, si nécessaire, un niveau de confidentialité.
Organiser le travail de l’agent
Comprendre la demande
Classer l’intention, relever les informations manquantes et vérifier que la demande appartient bien au périmètre autorisé.
Préparer un plan borné
Choisir les outils nécessaires, définir un nombre maximal d’actions et identifier les points qui exigent une approbation.
Exécuter avec preuves
Conserver les sources consultées, les paramètres transmis et les résultats utiles à la justification.
Contrôler la sortie
Valider le format, les règles métier, les citations et l’absence de données interdites avant restitution.
Apprendre de l’usage
Transformer les échecs observés en cas de test, puis ajuster les instructions, outils ou règles déterministes.
:::
Choisir le bon niveau d’autonomie
L’autonomie n’est pas un objectif en soi. Elle doit suivre la réversibilité et le risque de l’action.
| Type d’action | Exemple | Contrôle recommandé |
|---|---|---|
| Lecture | Rechercher une procédure interne | Journalisation et filtrage des droits |
| Proposition | Rédiger une réponse ou un devis | Relecture humaine selon le contexte |
| Écriture réversible | Ajouter une note dans un dossier | Validation automatique et historique |
| Action externe | Envoyer un e-mail à un client | Confirmation humaine ou règle stricte |
| Action critique | Modifier un paiement ou un droit | Processus déterministe, double contrôle |
Une stratégie efficace consiste à démarrer en mode « copilote ». L’agent prépare, explique et recommande ; l’utilisateur décide. Lorsque les évaluations et les retours terrain montrent qu’une classe d’actions est stable, elle peut devenir automatique dans un périmètre précisément défini.
Agent autonome trop tôt
- Objectif général et difficile à mesurer
- Accès large aux outils
- Erreurs découvertes par les utilisateurs
- Diagnostic fondé sur des conversations brutes
Autonomie progressive
- Parcours métier étroit et mesurable
- Permissions minimales par action
- Évaluations avant élargissement
- Traces structurées et reprise contrôlée
:::
Prévoir les échecs ordinaires
La majorité des incidents ne ressemble pas à un scénario spectaculaire. Une API expire, un document a changé de nom, un utilisateur fournit une référence ambiguë ou l’agent reçoit deux résultats similaires. Le produit doit rendre ces situations banales et récupérables.
Prévoyez au minimum : des délais maximums, des tentatives limitées, des clés d’idempotence pour éviter une action en double, un état d’échec explicite et une voie d’escalade. Si un outil devient indisponible, l’agent doit pouvoir expliquer ce qui manque sans inventer le résultat attendu.
La journalisation doit répondre à des questions opérationnelles : quelle version du modèle et des instructions a été utilisée ? Quelles données ont été récupérées ? Quel outil a échoué ? Quelle validation a autorisé l’action ? Évitez toutefois d’enregistrer aveuglément les données personnelles ou les secrets présents dans les échanges.
Évaluer avant d’étendre
Un agent se juge sur des tâches représentatives, pas sur quelques conversations choisies. Constituez un jeu de cas issus du travail réel : cas normaux, données manquantes, ambiguïtés, tentatives d’obtenir une action interdite et indisponibilités d’outils. Mesurez séparément la compréhension, le choix des outils, la qualité des arguments, le respect des règles et le résultat métier.
Le retour humain reste précieux, à condition d’être structuré. Un simple pouce rouge indique qu’un problème existe ; une catégorie comme « mauvaise source », « action trop tôt » ou « réponse inexploitable » permet de le corriger.
Mettre en production par paliers
Le premier déploiement peut se limiter à un groupe interne, sur un flux non critique et avec validation systématique. Observez les motifs d’abandon, les corrections humaines et les appels d’outils inutiles. Chaque palier d’autonomie doit correspondre à des critères explicites : couverture des évaluations, taux d’escalade acceptable, absence d’incident critique et procédure de retour arrière testée.
Cette approche produit parfois un agent moins impressionnant en démonstration, mais beaucoup plus utile dans la durée. La confiance ne vient pas d’un ton assuré : elle vient d’un système qui connaît ses limites, conserve ses preuves et laisse les équipes reprendre la main.
Faut-il utiliser plusieurs agents spécialisés ?
Seulement si la séparation apporte une responsabilité claire ou des permissions différentes. Plusieurs agents ajoutent des échanges, des états et des modes d’échec. Un flux unique avec des outils bien conçus suffit souvent au départ.
Un humain doit-il valider chaque action ?
Non. La validation doit être proportionnée au risque. Les lectures peuvent être automatiques ; une action externe ou difficilement réversible demande davantage de contrôle.
Comment savoir si le projet est prêt à s’élargir ?
Lorsque les scénarios critiques sont couverts, les erreurs sont explicables, les équipes savent reprendre la main et les gains métier sont observables sur une période représentative.
:::