Agents IA en entreprise : quelles tâches automatiser et quels contrôles conserver ?

Distinguer assistant, workflow et agent

Un assistant peut préparer une réponse sans modifier un système. Un workflow enchaîne des étapes prévues par l’application. Un agent choisit davantage ses prochaines actions à partir du contexte et du résultat des outils. Cette distinction de conception, présentée notamment par Anthropic, aide à comprendre où se trouve la décision pendant l’exécution.

Une tâche stable n’exige pas nécessairement un agent. Pour extraire un champ puis appliquer une règle connue, un enchaînement déterministe peut être plus facile à tester et à expliquer. L’autonomie devient intéressante lorsque le chemin varie et que le système doit rechercher une information ou choisir un outil. Elle ajoute cependant des trajectoires possibles, donc un effort d’évaluation et de supervision.

Pour approfondir : Anthropic — distinguer workflows et agents

Choisir un périmètre dont les effets sont maîtrisables

Décrivez les entrées, le résultat attendu, les systèmes consultés et les modifications possibles. Séparez lecture, préparation et exécution. Un agent qui rassemble des éléments pour un dossier ne porte pas le même risque qu’un agent qui change un contrat ou envoie une réponse au client.

Évaluez la réversibilité et la détection des erreurs. Une opération visible, limitée et facilement annulable se prête mieux à un premier pilote qu’une action diffuse dont les effets apparaissent plus tard. Définissez également les tâches exclues. Un objectif vague comme « résoudre la demande » ne doit pas donner un pouvoir implicite sur tous les outils disponibles. Le responsable métier doit savoir ce que l’agent peut engager en son nom.

Concevoir les outils comme des interfaces contrôlées

L’appel d’outils transforme une proposition du modèle en opération applicative. Le serveur doit valider le type d’action, les paramètres, l’identité et les droits. Le principe du moindre privilège conduit à exposer des fonctions limitées plutôt qu’un accès général à une base ou à un interpréteur de commandes.

Un outil de consultation peut retourner seulement les champs utiles. Un outil de modification peut exiger un identifiant, une version attendue et un état autorisé. La consigne adressée au modèle ne remplace aucun de ces contrôles. Les documents externes peuvent contenir des instructions trompeuses ; le risque d’injection décrit par l’OWASP justifie de garder les autorisations hors du contenu interprété par le modèle.

Pour approfondir : OWASP — injection d’instructions

Donner un contenu précis à la validation humaine

La validation humaine doit présenter ce qui va changer, pourquoi, sur quelle source et avec quelles conséquences. L’utilisateur doit pouvoir corriger ou refuser. Un bouton d’accord sur un résumé vague laisse une incertitude sur l’action réellement autorisée.

L’approbation doit être liée à l’opération préparée. Si le montant, le destinataire ou le document change après validation, le système doit réexaminer la nécessité d’un nouvel accord. Une autorisation ancienne ne doit pas être réutilisée pour une action différente. Prévoyez aussi l’expiration, l’absence du valideur et la reprise : attendre une décision ne doit pas déclencher une exécution par défaut.

Prévoir les interruptions, doublons et conditions d’arrêt

Une condition d’arrêt peut limiter le nombre d’étapes, la durée, la dépense ou la répétition d’une erreur. Elle doit être appliquée par l’orchestrateur, qui connaît l’état du travail. Une simple phrase dans le prompt ne garantit pas le respect du budget.

L’idempotence aide à empêcher la répétition d’un même effet après une coupure. Associez une identité à l’opération métier et vérifiez son état avant une reprise. Ne relancez pas automatiquement une action dont le résultat est inconnu. Conservez des états explicites : préparée, en attente, exécutée, échouée ou à vérifier. La personne qui reprend doit voir les actions confirmées et les incertitudes, sans reconstituer tout le parcours à partir d’un dialogue.

Évaluer les trajectoires et organiser l’exploitation

Testez le résultat final, mais aussi les étapes : outils appelés, accès demandés, actions refusées et coût cumulé. Incluez une source indisponible, une validation refusée, une interruption après exécution et un changement d’état concurrent. Des outils simulés permettent d’explorer ces cas sans effets externes.

En production limitée, surveillez les transferts à une personne, les reprises et les sorties hors périmètre. Un taux de réussite élevé ne suffit pas si les opérations réussies mobilisent un contrôle excessif. Documentez qui peut suspendre le service et comment revenir au traitement habituel. La décision d’élargir l’autonomie doit s’appuyer sur cette capacité d’exploitation autant que sur la performance du modèle.

Pour approfondir : NIST — gestion des risques IA