AI agent pour les ops

Un AI agent pour les ops est un logiciel qui reçoit un objectif de haut niveau, le décompose en sous-tâches au moment de l’exécution, décide quels outils appeler et dans quel ordre, et révise son plan lorsque les résultats intermédiaires modifient la situation — sans qu’un humain spécifie chaque étape. La distinction qui compte dans un contexte ops n’est pas de savoir si un produit utilise un LLM, mais si le système prend des décisions de branchement de façon autonome en fonction de ce qu’il trouve, ou si un humain a pré-programmé les points de branchement.

Un AI agent n’est pas un chatbot qui répond à des questions à la demande, un outil de workflow qui exécute une séquence fixe d’étapes prédéfinies, ni un bot RPA qui rejoue des schémas de clics enregistrés. Les trois peuvent intégrer des LLMs ; aucun ne se qualifie comme agent à moins de pouvoir changer de cap de manière indépendante lorsque les conditions changent.

Pourquoi cette distinction compte pour les acheteurs ops

La majorité des logiciels commercialisés comme « agentiques » en 2025 et 2026 ne le sont pas. Gartner a forgé le terme « agentwashing » pour désigner ce phénomène. Un outil qui rédige un email, résume un appel ou remplit un champ CRM sur un déclencheur n’est pas un agent — c’est un workflow amélioré par l’AI. C’est quelque chose de légitime et souvent plus fiable à acheter, mais le cadrage marketing induit en erreur les acheteurs qui cherchent à comprendre ce qu’ils acquièrent réellement.

Les équipes ops — RevOps, Legal Ops, TA — se préoccupent de cette distinction pour deux raisons. D’abord, les agents requièrent une gouvernance différente : un outil capable d’envoyer des emails, de mettre à jour des enregistrements ou de router des décisions de façon autonome nécessite des pistes d’audit et des contrôles de rollback qu’un outil de workflow n’exige pas. Ensuite, les agents débloquent une catégorie de travail différente : des tâches qui nécessitent du jugement aux points de branchement, pas seulement l’exécution d’un chemin connu.

Ce que fait un vrai agent

Un vrai agent présente quatre comportements :

1. Réception de l’objectif. Il accepte un objectif formulé en langage naturel, non un formulaire de configuration. « Trouve et qualifie les comptes correspondant à cet ICP, rédige des messages outreach pour les 20 premiers et signale les trois les plus susceptibles de se conclure ce trimestre » est un objectif. Une séquence fixe « enrichir → scorer → séquencer » déclenchée sur un nouveau lead est un workflow — même si chaque étape utilise un LLM.

2. Sélection dynamique des outils. L’agent choisit quels outils externes (fournisseurs de données, CRM, email, calendrier) appeler en fonction de ce qu’il apprend à chaque étape. Si l’enrichissement firmographique renvoie des données incomplètes, l’agent interroge une deuxième source plutôt que d’échouer ou de passer silencieusement à la suite.

3. Révision du plan en cours d’exécution. Lorsque les résultats intermédiaires changent la situation — le prospect a répondu avant l’envoi du deuxième follow-up, le contrat signale une clause non standard — l’agent remplace ses étapes restantes par un plan révisé plutôt que de compléter le script d’origine.

4. Critères de succès au niveau de l’objectif. L’agent dispose d’une définition de « terminé » qu’il vérifie, et pas seulement d’une dernière étape à exécuter. Un workflow se termine lorsque le dernier nœud est exécuté ; un agent se termine lorsque sa condition de succès est satisfaite ou lorsqu’il expose explicitement un échec qu’il ne peut pas résoudre.

Comment les agents apparaissent dans le travail ops

RevOps — Le cas d’usage initial le plus évident est la recherche et la qualification de comptes. Un agent auquel on confie une liste de comptes cibles peut croiser de façon indépendante les données d’utilisation produit, les signaux d’intention tiers et l’historique CRM, puis produire une shortlist priorisée avec justification — sans qu’un analyste spécifie chaque requête. La différence avec un workflow : lorsqu’il rencontre une entreprise absente du fournisseur de données, il s’adapte plutôt que d’enregistrer une erreur.

Legal Ops — Les agents de revue de contrats peuvent recevoir un contrat, appliquer un playbook de positions de repli et renvoyer un redline — mais surtout, ils peuvent signaler une clause non standard qu’ils n’ont jamais rencontrée comme une décision nécessitant l’avis d’un juriste, plutôt que de l’ignorer silencieusement ou de planter. Un outil de workflow applique des règles ; un agent expose ce que les règles ne couvrent pas.

Recruiting / TA — Un agent de sourcing peut recevoir une fiche de poste, générer des requêtes de recherche, interroger des outils de sourcing, filtrer les profils renvoyés selon des critères d’embauche et rédiger des messages outreach — en ajustant les critères si aucun profil ne correspond dans un canal avant d’en essayer un autre. Le jugement du recruteur reste nécessaire pour la shortlist finale, mais l’agent comprime plusieurs jours de recherche en quelques minutes.

Les questions diagnostiques que les acheteurs doivent poser aux éditeurs

Lorsqu’un éditeur affirme que son produit est un « AI agent », ces questions font apparaître la réalité :

1. Que se passe-t-il quand une étape intermédiaire échoue ou renvoie un résultat inattendu ? Un vrai agent décrit un plan de fallback. Un outil de workflow décrit un état d’erreur ou une file d’attente de révision manuelle.

2. Peut-on lui donner un objectif qu’il n’a jamais rencontré, ou faut-il d’abord configurer un playbook ? Les vrais agents généralisent ; les outils de workflow sophistiqués généralisent uniquement dans les scénarios que leurs concepteurs ont anticipés.

3. Où se situe la validation humaine dans le cycle ? Ce n’est pas un critère éliminatoire — beaucoup d’architectures d’agents en production utilisent délibérément des points de contrôle humains. Mais la réponse indique si l’autonomie est réelle ou théâtrale. « Les humains approuvent chaque action » signifie généralement qu’il s’agit d’un workflow avec assistance AI, pas d’un agent.

4. À quoi ressemble le journal d’audit ? Les agents produisent des journaux de décision — pourquoi a-t-il appelé cet outil ? pourquoi a-t-il révisé le plan ? — et pas seulement des journaux d’actions. Les outils de workflow journalisent les actions ; les agents devraient journaliser le raisonnement.

5. Quel est le modèle de coût quand l’agent emprunte un long chemin ? Les agents autonomes peuvent consommer nettement plus de tokens LLM sur des objectifs complexes que sur des objectifs simples. Si l’éditeur ne peut pas donner une fourchette de coût par type de tâche, soit il n’a pas mesuré, soit la variabilité des coûts est un problème connu.

Erreurs fréquentes

Acheter un agent quand on a besoin d’un workflow. Les agents échangent la prévisibilité contre la flexibilité. Si chaque instance d’une tâche suit les mêmes étapes, un workflow bien configuré est plus rapide, moins cher et plus auditable qu’un agent. La bonne question est de savoir si la tâche présente une variabilité significative aux points de branchement ; si ce n’est pas le cas, un agent ajoute de la charge sans apporter de valeur.

Protection : Cartographiez la tâche avant la démo du fournisseur. Listez chaque point de décision. Si toutes les décisions peuvent être encodées comme des règles que vous connaissez déjà, achetez l’outil de workflow.

Pas de plan de rollback. Les agents qui prennent des actions autonomes — envoyer des emails, mettre à jour des enregistrements, signaler des éléments dans un système d’enregistrement — ont besoin d’une capacité de rollback. Un agent qui a effectué 400 appels outreach sur la base d’un ICP mal configuré ne peut pas annuler ces messages.

Protection : Exigez un mode dry-run (l’agent planifie mais n’exécute pas) pour tout agent qui touche des systèmes externes, ainsi qu’un relevé de chaque action externe effectuée avec l’état des données au moment de l’action.

Vide de gouvernance. Les équipes Legal Ops utilisant des agents de contrats et les équipes TA utilisant des agents de sourcing dans des juridictions soumises à des réglementations sur l’AI dans l’embauche (NYC LL 144, EU AI Act) doivent savoir exactement ce que l’agent a fait et pourquoi. « L’AI a décidé » n’est pas une réponse défendable lors d’un audit.

Protection : Tout agent touchant des décisions réglementées doit produire des enregistrements de décision structurés — quels signaux il a utilisés, quelles règles il a appliquées, ce qu’il a soumis à la révision humaine — dans un format qu’une équipe de conformité peut interroger.

Rubriques associées

• GTM engineering — la discipline ops qui construit et gouverne les systèmes agentiques
• Claude — le LLM le plus couramment déployé pour les agents ops personnalisés