Qu'est-ce qu'un agent d'intelligence artificielle ? Définition concrète pour l'entreprise

« Nous cherchons un agent IA » : trois projets différents derrière une même phrase

Un responsable des opérations écrit dans son cahier des charges : « nous cherchons un agent IA capable de traiter les demandes fournisseurs ». Trois semaines plus tard, les trois prestataires reçus en démonstration montrent trois produits qui n'ont rien à voir : le premier est un chatbot qui répond à partir de la documentation achats, le deuxième est un scénario d'automatisation qui recopie des champs dans un formulaire, le troisième lit une relance, vérifie le bon de commande dans l'ERP, détecte un écart de quantité et prépare une réponse à valider. Les trois s'appellent « agent IA » sur la plaquette commerciale.

Le problème n'est pas commercial, il est opérationnel. Sans définition partagée, l'entreprise compare des objets non comparables, choisit celui qui fait la meilleure impression en réunion, et se retrouve avec un pilote qui tourne sur dix documents triés à la main sans jamais passer en production. Un agent n'est pas un niveau de qualité de chatbot : c'est une architecture d'exécution, avec des propriétés vérifiables. C'est cette définition qu'il faut mettre dans le cahier des charges avant de parler de modèle, de fournisseur ou de prix.

La définition opérationnelle : un objectif borné, une boucle, des outils, une mémoire, des garde-fous

Un agent d'intelligence artificielle est un programme qui reçoit un objectif formulé en langage naturel, le décompose en étapes, appelle des outils (recherche dans les documents, API métier, base de données, outil de ticketing), observe le résultat de chaque appel, ajuste sa trajectoire, puis s'arrête soit parce que l'objectif est atteint, soit parce qu'un garde-fou s'est déclenché. Deux propriétés comptent pour un acheteur : la sortie n'est pas seulement du texte, mais une action ou une action préparée ; et le chemin n'est pas figé à l'avance, il est choisi à l'exécution.

C'est exactement ce qui le distingue des deux technologies voisines avec lesquelles on le confond le plus souvent. Un moteur RPA suit un script écrit à la main : il est fiable tant que le processus ne change pas, et il casse à la première exception. Un agent choisit sa séquence à l'exécution : c'est sa valeur quand les cas varient, et c'est son risque quand le périmètre est flou. D'où la règle de base : plus l'agent est autonome, plus l'objectif doit être étroit et les outils limités.

• Chatbot documentaire — best for répondre vite et de façon sourcée à une question ; ne décide pas, n'agit pas, ne franchit aucune étape seul.
• Workflow / RPA — best for un processus stable, répétitif et connu à l'avance ; coût faible, mais aucune tolérance à l'imprévu.
• Agent IA — best for des tâches à étapes variables où il faut lire, croiser plusieurs sources, décider d'un prochain pas et préparer une action.
• Employé — best for le jugement, la relation et la responsabilité ; dans un dispositif sain, l'agent prépare le dossier et l'humain tranche.

Les cinq briques à retrouver dans une démonstration, pas seulement dans un slide

Une démonstration d'agent se juge sur ce qu'elle refuse de faire autant que sur ce qu'elle réussit. Demandez à voir le journal d'exécution : quelles étapes, quels outils appelés, avec quels paramètres, quel résultat retourné. Si le prestataire ne peut pas afficher cette trace, ce n'est pas un agent, c'est un formulaire avec une réponse générée. La traçabilité n'est pas un bonus de conformité, c'est le seul moyen de diagnostiquer une erreur en production et de répondre à un auditeur interne.

La deuxième brique à examiner est la couche d'accès aux systèmes. Un agent qui lit les documents mais ne peut pas interroger l'ERP reste un assistant documentaire. À l'inverse, un agent branché sur un compte de service aux droits trop larges est un incident de sécurité qui attend son heure. Entre les deux, il y a un travail ingénieur peu spectaculaire : connecteurs, mapping des champs, gestion des erreurs, reprise après échec, filtrage des droits selon l'utilisateur qui pose la question.

• Objectif borné : un périmètre écrit, avec les cas exclus explicitement listés (par exemple hors litiges et hors marchés publics).
• Boucle de raisonnement : planifier, agir, observer, corriger — et une condition d'arrêt claire, y compris en cas d'échec répété.
• Outils et permissions : chaque outil appelable est nommé, avec ses droits, ses limites de débit et son comportement en cas d'erreur.
• Mémoire : mémoire de la conversation pour le contexte, mémoire organisationnelle pour les documents et leur version — sans quoi l'agent cite une procédure périmée.
• Garde-fous : seuils de montant ou de sensibilité déclenchant une validation humaine, journalisation, possibilité de désactivation immédiate.

Ce qu'un agent change vraiment dans le travail réel

Les cas d'usage qui tiennent en production partagent une caractéristique : un volume suffisant, des sources documentaires identifiées, et des exceptions fréquentes mais bornées. Le traitement des demandes fournisseurs en est un exemple classique — lire la demande, retrouver la commande, comparer les quantités, vérifier la clause de pénalité dans le contrat, préparer un brouillon de réponse avec les pièces jointes. Le support de niveau 2 en est un autre : l'agent cherche dans la base de connaissances, propose une manipulation, et escalade avec un résumé déjà constitué si l'utilisateur confirme que cela ne fonctionne pas.

Ce que l'agent change n'est pas le métier, c'est le temps passé à reconstituer le contexte. Un gestionnaire qui passe vingt minutes à retrouver trois documents et deux champs dans l'ERP ne devient pas inutile : il devient disponible pour l'arbitrage. En revanche, un agent placé sur une routine à trois étapes sans exception coûtera plus cher que le script équivalent, parce qu'on paie une flexibilité dont personne n'a besoin. La question de cadrage n'est donc pas « où mettre de l'IA ? » mais « où la variabilité coûte-t-elle plus cher que le script ? ».

• Bon candidat : volumétrie régulière, sources de vérité identifiées, exceptions fréquentes mais typées, action finale vérifiable.
• Mauvais candidat : processus déjà stable et scripté, données non consolidées, responsabilité juridique directe sans possibilité de validation.
• Signal d'alerte : la démonstration fonctionne uniquement sur un jeu de documents préparé par le prestataire.

Les coûts cachés : intégration, droits, supervision et dérive

L'essentiel de l'effort d'un projet d'agent ne se situe presque jamais dans le choix du modèle. Il se situe dans les connecteurs vers les systèmes existants, dans la définition des droits — l'agent agit-il avec les droits de l'utilisateur qui l'interroge, ou avec ceux d'un compte technique ? — et dans le traitement des cas limites que personne n'avait documentés. Ces trois postes sont difficiles à chiffrer en amont, et c'est précisément là que les budgets de pilote se consument.

S'ajoutent deux coûts de fonctionnement souvent oubliés. Le premier est la supervision : un agent qui produit cent dossiers par jour doit être échantillonné, et cet échantillonnage coûte du temps humain qualifié. Le second est la dérive : les documents changent de version, les procédures évoluent, le modèle sous-jacent est mis à jour par le fournisseur. Un agent non réévalué après un changement de procédure ne devient pas mauvais progressivement : il devient silencieusement faux. Il faut donc un propriétaire nommé, une date de revue, et des indicateurs simples — taux de validation humaine, taux d'escalade, taux de reprise après erreur d'outil, coût par dossier traité.

• Intégration : compter les connecteurs réellement nécessaires, pas ceux de la démonstration.
• Droits : un agent ne doit jamais devenir un compte administrateur déguisé.
• Supervision : prévoir dès le départ qui échantillonne, à quelle fréquence, et ce qu'il fait d'une anomalie.
• Résidence des données : vérifier où sont stockés documents, journaux et traces d'exécution, et si un déploiement sur site est possible.
• Réversibilité : pouvoir désactiver l'agent sans arrêter le processus métier qu'il assiste.

Checklist : six questions à poser avant de signer

Cette liste n'est pas un audit technique complet, c'est un filtre. Elle sert à éliminer rapidement les offres qui utilisent le mot agent sans en fournir les propriétés, et à orienter les discussions vers ce qui coûtera cher plus tard : les droits, la trace, la maintenance du périmètre. Posez-les à l'écrit, et demandez une réponse écrite : les réponses orales en réunion sont toujours meilleures que les réponses contractuelles.

Une offre qui répond précisément à ces six points, même avec un périmètre plus modeste que la concurrence, est presque toujours un meilleur achat qu'une démonstration spectaculaire sans journal d'exécution. L'objectif d'un premier déploiement n'est pas d'impressionner le comité de direction, c'est de produire un dossier traçable que quelqu'un acceptera de valider.

• 1. Quel est l'objectif exact, et quels cas sont explicitement hors périmètre ?
• 2. Quels outils l'agent peut-il appeler, avec quels droits, et comment sont-ils révoqués ?
• 3. Peut-on voir le journal complet d'une exécution : étapes, outils, paramètres, résultat ?
• 4. À quel moment une validation humaine est-elle obligatoire, et qui la porte ?
• 5. Comment l'agent gère-t-il une version obsolète d'un document ou une procédure modifiée ?
• 6. Où sont stockées les données et les traces, et que se passe-t-il si l'on doit tout arrêter en une heure ?

En résumé : un agent est un contrat d'exécution, pas une personnalité

Un agent d'intelligence artificielle ne se définit pas par le ton de ses réponses ni par le nom du modèle qui le fait fonctionner, mais par ce qu'il est autorisé à faire, sur quelles sources, avec quelle trace et sous quel contrôle. Les quatre questions utiles sont donc simples : quel objectif borné, quels outils et quels droits, quelle mémoire avec quelles versions, quels garde-fous et quel journal. Tant que ces réponses ne sont pas écrites, la comparaison entre offres reste une conversation d'impressions.

C'est aussi ce qui permet de dimensionner honnêtement un premier projet. Un agent utile commence souvent petit : une tâche, un service, un type de dossier, avec une validation humaine systématique. On élargit ensuite le périmètre quand les indicateurs tiennent. Dans un dispositif de ce type, Pilardin regroupe dans un même espace de travail la recherche documentaire avec citations, les connecteurs vers les systèmes métier et les modules Matrix spécialisés ; le cadrage d'un premier cas d'usage se fait via /pipeline, et les niveaux d'offre sont détaillés sur /pricing. L'agent n'y remplace pas la décision : il rend le dossier lisible assez vite pour qu'un humain puisse décider.

FAQ

Un agent d'intelligence artificielle, est-ce la même chose qu'un chatbot ?

Non. Un chatbot produit une réponse textuelle à partir d'un contexte ; un agent poursuit un objectif en plusieurs étapes, appelle des outils et peut préparer ou exécuter une action. La différence se voit dans le journal d'exécution : un chatbot n'en a pas, un agent doit en avoir un. Un chatbot peut être intégré à un agent comme interface de dialogue, mais l'inverse n'est pas vrai.

Faut-il forcément un grand modèle de langage pour construire un agent ?

Un modèle de langage est ce qui permet de décomposer une demande en étapes et de choisir l'outil suivant, donc il est présent dans la majorité des agents actuels. Mais l'essentiel de la fiabilité vient de l'architecture autour : outils bien définis, paramètres validés, conditions d'arrêt, reprise sur erreur. Un agent adossé à un modèle modeste mais à des outils stricts sera plus fiable qu'un agent très autonome branché sur des API mal contrôlées.

Peut-on utiliser un agent sur des documents internes sensibles ?

Oui, à condition de traiter trois points séparément : la résidence des données (où sont stockés les documents, les embeddings et les journaux), le contrôle d'accès (l'agent doit filtrer les résultats selon les droits de l'utilisateur qui pose la question, pas selon ceux d'un compte technique), et la conservation des traces. Un déploiement sur site ou dans un environnement contrôlé est souvent requis pour les corpus RH, juridiques ou industriels.

Comment savoir si un agent fonctionne réellement en production ?

Suivez quatre indicateurs : le taux de dossiers validés sans correction par un humain, le taux d'escalade, le taux d'échec d'appel d'outil, et le coût par dossier traité. Un agent dont le taux de validation est élevé mais dont les corrections portent toujours sur le même champ n'est pas bon : il est prévisiblement faux sur un point précis, ce qui est corrigeable. À l'inverse, un agent très autonome sans échantillonnage humain ne fournit aucune mesure exploitable.

Un agent peut-il agir sans validation humaine ?

Techniquement oui, et c'est parfois justifié pour des actions réversibles à faible enjeu, comme créer un brouillon ou classer un document. Dès qu'une action engage de l'argent, un tiers ou une obligation réglementaire, la validation humaine reste la règle. Le bon modèle est un curseur de délégation par type d'action, revu périodiquement à partir des indicateurs, et non un choix binaire fixé au démarrage du projet.