Quel processus confier à un agent IA ? Une méthode de sélection en 7 critères

Le meilleur processus à confier à un agent IA n'est pas nécessairement le plus long ni le plus coûteux. C'est un processus dont le chemin varie selon le contexte, qui exige d'interpréter des informations non structurées et dont le résultat peut être évalué. Il doit aussi disposer d'outils maîtrisés, d'un propriétaire et de limites d'action explicites. Si les étapes peuvent être décrites par des règles stables, une automatisation classique reste souvent plus fiable, moins chère et plus facile à auditer.

Réponse en bref

Avant de construire un agent IA, comparez quatre options : ne pas automatiser, automatiser avec des règles, intégrer un modèle dans un workflow borné ou laisser un agent choisir certaines étapes et certains outils. Un cas favorable à l'agent cumule ambiguïté, chemins variables, données non structurées, valeur métier mesurable et résultats vérifiables. Il reste cependant inéligible si les actions irréversibles ne peuvent pas être bloquées, si les droits sont trop larges ou si aucune équipe ne peut l'évaluer et l'exploiter.

La grille Nexxom proposée dans cet article note sept critères. Elle sert à structurer une discussion et à comparer des processus. Elle ne remplace ni une analyse de risque, ni un test sur des données réelles, ni une décision de conformité.

Arbre de décision Nexxom. Une porte de risque ou d'évaluation peut arrêter le projet même si le processus semble adapté à un agent.

Qu'est-ce qui distingue un agent IA d'une automatisation ?

Une automatisation classique exécute un chemin défini à l'avance. Les règles déterminent l'étape suivante, les données à lire et l'action à réaliser. Un workflow IA ajoute un ou plusieurs modèles à ce chemin sans leur donner le contrôle général de l'exécution. Le modèle peut, par exemple, classer une demande ou extraire des données, puis le logiciel applique des règles déterministes.

Un agent IA va plus loin. Il utilise un modèle pour décider comment poursuivre un objectif, sélectionner des outils et déterminer si le travail est terminé, dans les limites prévues par le système. Cette définition rejoint le guide pratique d'OpenAI sur les agents et la distinction d'Anthropic entre workflows et agents.

Cette distinction évite un faux choix entre « sans IA » et « agent autonome ». Dans de nombreux projets, le meilleur système est hybride : un modèle interprète, un workflow contrôle l'état et un humain approuve les actions sensibles.

Les sept critères pour sélectionner un processus agentique

1. Le travail contient-il une ambiguïté utile ?

Un agent apporte de la valeur lorsque le processus exige de comprendre une intention, rapprocher plusieurs informations, traiter des exceptions ou adapter un plan. OpenAI cite trois familles de cas : décisions complexes, règles devenues difficiles à maintenir et forte dépendance à des données non structurées. Si la même entrée doit toujours produire la même action selon une règle connue, cette ambiguïté n'existe pas. Un moteur de règles est alors préférable.

L'ambiguïté doit être utile au résultat. Ajouter un modèle à une simple copie de données ne crée pas de raisonnement pertinent. Cela introduit seulement une nouvelle source d'erreur.

2. Le chemin d'exécution varie-t-il réellement ?

Un workflow prédéfini convient lorsque les étapes peuvent être dessinées avant l'exécution. Un agent devient intéressant lorsque l'ordre des recherches, des vérifications ou des outils dépend de ce qu'il découvre en cours de route. Anthropic recommande néanmoins de commencer par la solution la plus simple et d'augmenter la complexité seulement si nécessaire.

Posez une question concrète : sur cinquante cas représentatifs, combien exigent un chemin différent et impossible à décrire proprement par quelques branches ? Si les variations sont connues et peu nombreuses, le routage classique reste plus prévisible.

3. La valeur métier est-elle observable ?

Un processus agentique doit produire un résultat économique ou opérationnel mesurable : dossier correctement préparé, demande résolue, incident qualifié, délai réduit ou travail manuel évité. Le nombre d'étapes ou le caractère impressionnant d'une démonstration ne mesure pas cette valeur.

Définissez l'unité de résultat avant le prototype. Elle peut être « dossier accepté sans reprise majeure » ou « demande transmise à la bonne équipe avec les preuves requises ». Le coût doit ensuite être rapporté à cette unité, en intégrant les modèles, outils, reprises, contrôles humains et opérations.

4. Les données et outils nécessaires sont-ils accessibles de façon sûre ?

Un agent sans outils fiables ne peut pas exécuter un processus. Un agent doté de droits excessifs peut en revanche créer un risque disproportionné. Chaque outil doit avoir une fonction claire, des entrées contraintes, des erreurs explicites et les permissions minimales. Les actions de lecture, de proposition et d'écriture doivent être séparées lorsque le risque le justifie.

Le NIST AI Agent Standards Initiative place l'identité, l'autorisation et l'interopérabilité parmi les priorités de l'écosystème agentique. La préparation d'un cas d'usage doit donc inclure les identités techniques, les secrets, les sources de données, la journalisation et les frontières réseau, pas seulement le prompt.

5. La réussite peut-elle être vérifiée ?

Un processus n'est pas prêt pour un agent si personne ne sait reconnaître une bonne exécution. Il faut un résultat attendu, des erreurs critiques, des cas d'abstention et une procédure de revue. Les tests doivent couvrir le chemin complet : compréhension, plan, choix des outils, arguments transmis, respect des droits et résultat final.

Le projet NIST AI 800-2 rappelle que les évaluations agentiques doivent préciser les outils, les instructions, les budgets et la condition d'arrêt. Pour construire un protocole plus complet, consultez aussi notre guide sur l'évaluation d'un LLM au-delà des classements publics.

6. Les erreurs sont-elles détectables et réversibles ?

La capacité d'un agent à agir ne signifie pas qu'il doit agir seul. Une recherche, un brouillon ou une recommandation peuvent souvent être annulés ou contrôlés. Un paiement, une suppression, une décision réglementée ou l'envoi d'une information sensible exigent des barrières plus fortes.

OpenAI recommande une intervention humaine lorsque les actions sont sensibles, irréversibles ou à fort enjeu. Le contrôle peut prendre plusieurs formes : approbation préalable, plafond, double validation, exécution simulée, environnement isolé ou outil de retour arrière. Si aucune mesure ne ramène le risque à un niveau acceptable, le processus n'est pas un bon candidat à l'autonomie.

7. Une équipe peut-elle posséder et exploiter le système ?

Un agent en production est un service, pas un prompt livré une fois. Il lui faut un propriétaire métier, un propriétaire technique, une procédure d'incident, des tests de régression, un suivi des versions et un budget. Les journaux doivent permettre de relier une sortie aux données, aux outils et aux décisions observables sans exposer inutilement des informations sensibles.

Le NIST AI RMF Core demande de définir les responsabilités, les bénéfices, les coûts, les limites et la supervision humaine, puis de mesurer le système dans des conditions proches du déploiement. Sans cette capacité d'exploitation, même un prototype convaincant reste un mauvais candidat à la production.

Une grille de notation utilisable en atelier

Attribuez à chaque critère 0, 1 ou 2 points. Le score indique une adéquation potentielle à un agent. Il ne neutralise jamais une porte éliminatoire.

Comment interpréter le total ?

• 0 à 4 points : conserver le processus humain ou utiliser une automatisation déterministe simple.
• 5 à 8 points : tester un workflow IA borné sur une étape précise, sans donner le contrôle général au modèle.
• 9 à 11 points : envisager un pilote d'agent borné avec peu d'outils et une validation humaine.
• 12 à 14 points : le processus peut justifier une autonomie plus large, mais uniquement après les portes de risque, les évaluations et un pilote observé.

Ces seuils sont une méthode de cadrage Nexxom, pas une norme. Un score élevé ne compense pas une donnée interdite, une action irréversible non contrôlée ou l'absence de responsable.

Les portes éliminatoires avant tout prototype

Arrêtez ou redessinez le cas si l'une de ces conditions reste vraie :

• le résultat attendu ne peut pas être défini ni évalué ;
• les données nécessaires ne sont pas autorisées pour cet usage ;
• l'agent aurait des droits plus larges que le processus qu'il exécute ;
• une erreur critique pourrait être exécutée sans détection ni approbation ;
• aucune condition d'arrêt, limite de temps, d'appels ou de coût n'est prévue ;
• aucun responsable ne peut suspendre le service et traiter un incident ;
• la solution ne peut pas être comparée à une référence humaine ou logicielle existante.

Le rapport NIST AI 800-5 publié en mai 2026 souligne que les agents présentent des menaces nouvelles et que les principes classiques de cybersécurité doivent être adaptés. Ces portes ne sont donc pas une formalité après le prototype. Elles font partie du choix du cas d'usage.

Quelle architecture choisir selon le processus ?

Le tableau ne remplace pas l'analyse locale. Un même processus change de catégorie selon les données, les droits et l'impact. La qualification d'un incident en lecture seule n'a pas le même profil qu'un agent autorisé à modifier l'infrastructure.

Comment construire un pilote qui apprend réellement ?

1. Établir une référence

Mesurez le processus actuel sur des unités utiles : temps de traitement, taux de reprise, erreurs critiques, coût complet et satisfaction des utilisateurs. Sans référence, un pilote ne peut démontrer ni amélioration ni dégradation.

2. Réduire le périmètre

Choisissez un seul objectif, une population d'utilisateurs et peu d'outils. Commencez en lecture seule ou en mode proposition. Les permissions et approbations recommandées dans le Skill Lab OpenAI du 5 mai 2026 doivent être conçues avant l'ouverture du pilote.

3. Définir les métriques et les budgets

Suivez au minimum :

• taux de tâches acceptées selon une grille explicite ;
• taux d'erreurs critiques et d'actions non autorisées ;
• taux d'abstention et d'escalade correcte ;
• reprises humaines par tâche ;
• durée, appels d'outils et coût par tâche acceptée ;
• incidents, quasi-incidents et retours utilisateurs.

Fixez une condition d'arrêt et des limites de tours, de temps, d'appels et de dépense. Un agent qui finit parfois correctement après une consommation imprévisible n'est pas encore un système exploitable.

4. Comparer trois architectures

Testez si possible la même tâche avec une automatisation, un workflow IA borné et un agent. Cette comparaison révèle si l'autonomie ajoute une valeur réelle. Elle évite d'attribuer au concept d'agent un gain qui vient simplement d'une meilleure extraction ou d'un meilleur accès aux données.

5. Décider avec des critères écrits

La décision finale doit être « arrêter », « redessiner », « poursuivre en mode assisté » ou « élargir progressivement ». Documentez la version du modèle, les outils, les permissions, les tests, les limites connues, le propriétaire et la date de révision. Pour le choix du modèle lui-même, utilisez notre méthode pour sélectionner un modèle d'IA en entreprise.

Questions fréquentes

Un chatbot est-il un agent IA ?

Pas nécessairement. Un chatbot qui répond à une question sans piloter un processus ni sélectionner d'outils reste une application conversationnelle. Il devient agentique lorsque le modèle contrôle des étapes, utilise des outils et agit vers un objectif dans des limites définies.

Faut-il commencer par un système multi-agent ?

Non. Un agent unique avec peu d'outils est plus simple à évaluer, sécuriser et exploiter. Un système multi-agent ne se justifie que si la séparation des responsabilités ou la nature des tâches apporte un avantage vérifié.

Peut-on utiliser un agent pour un processus réglementé ?

Parfois, mais le contexte juridique, les personnes affectées, les données et les décisions doivent être analysés. L'agent peut être limité à la recherche ou à la préparation, tandis qu'une personne conserve la décision. Une consultation juridique et métier est nécessaire lorsque l'usage est sensible.

Quelle est la meilleure première permission à donner ?

La lecture d'une source nécessaire et limitée est généralement plus facile à contrôler qu'une action d'écriture. Ensuite, le système peut proposer une action structurée qu'une personne approuve. L'autonomie d'écriture s'élargit seulement après des évaluations et une observation suffisantes.

Comment calculer le retour sur investissement ?

Comparez le coût complet du processus actuel au coût du système pour une tâche acceptée. Incluez les modèles, l'infrastructure, les outils, les validations, les reprises, la surveillance et les incidents. N'utilisez pas uniquement le prix d'un appel API ou le temps économisé sur les cas réussis.

Conclusion

Un bon cas d'usage agentique associe un travail variable à un résultat vérifiable. L'agent doit disposer d'outils précis, de droits minimaux, de budgets, de journaux et d'une voie d'escalade. Lorsque le chemin est stable, l'automatisation classique gagne. Lorsque seule une étape exige de l'interprétation, un workflow IA borné suffit. L'agent devient pertinent lorsque la flexibilité apporte une valeur mesurable que ces architectures plus simples n'atteignent pas.

La première décision n'est donc pas « quel agent acheter ? », mais « quelle autonomie ce processus mérite-t-il, sous quelles preuves et sous quels contrôles ? » Nexxom peut transformer cette méthode en atelier de sélection, protocole d'évaluation et architecture de pilote adaptés à un processus réel.

Sources primaires

• OpenAI : A practical guide to building agents
• Anthropic : Building effective agents
• OpenAI Academy : Build Your First Workspace Agent, 5 mai 2026
• NIST AI 800-2 : Practices for Automated Benchmark Evaluations, janvier 2026
• NIST : AI RMF Core
• NIST : AI Agent Standards Initiative, 2026
• NIST AI 800-5 : Security Considerations for AI Agents, mai 2026

Sources et informations vérifiées le 9 août 2026. Les architectures, produits et recommandations de sécurité évoluent. Vérifiez les documentations et les obligations applicables avant un déploiement.