Il y a une différence de nature entre un assistant qui répond et un assistant qui agit.

Le premier vous explique la procédure de remboursement. Le second ouvre le dossier client, vérifie le statut du paiement et prépare le courrier. C'est ce qu'on appelle un agent : un système d'IA autorisé à se servir de vos outils.

C'est précisément ce qui le rend utile. Et c'est exactement ce qui le rend délicat.

La bonne façon d'y penser : un nouveau collègue

L'image qui aide le plus, y compris dans les discussions non techniques, est celle du stagiaire compétent qui arrive lundi matin.

Il est vif, il lit vite, il ne se fatigue pas. Mais il ne connaît ni vos habitudes, ni vos exceptions, ni les conséquences réelles de ses actes. Quels accès lui donnez-vous le premier jour ?

Personne ne répond « tous ». On lui laisse consulter les dossiers, on lui fait préparer des brouillons, et on relit avant d'envoyer quoi que ce soit à un client. Ce raisonnement, parfaitement naturel avec un humain, est exactement celui qu'il faut appliquer à un agent.

La question centrale n'est donc pas « le modèle est-il intelligent ? » mais : que peut-il faire, et que se passe-t-il s'il se trompe ?

Trois niveaux d'action, trois niveaux de prudence

Nous classons systématiquement les outils confiés à un agent en trois catégories. C'est simple, et cela structure toute la conception.

Consulter. Chercher un document, lire un statut, retrouver l'historique d'un dossier. En cas d'erreur, la réponse est inexacte, mais rien n'a bougé dans vos systèmes. Le risque est faible et réversible.

Préparer. Rédiger un brouillon, ajouter un commentaire interne, proposer une réponse. L'erreur est visible avant d'avoir des conséquences, et quelqu'un peut la corriger.

Engager. Envoyer un email à un client, valider un paiement, modifier un enregistrement officiel. Ici, l'erreur sort de la maison et coûte quelque chose immédiatement.

Notre règle est constante : la troisième catégorie ne s'exécute jamais sans validation humaine explicite, quelle que soit l'assurance affichée par le système. Ce n'est pas une précaution provisoire en attendant de meilleurs modèles. C'est un choix d'architecture, et il ne changera pas parce qu'un modèle plus récent est sorti.

La plupart des agents réellement utiles en entreprise passent l'essentiel de leur temps à consulter. La valeur vient de leur capacité à rassembler des informations éparpillées dans cinq systèmes, pas à décider à votre place.

Peu d'outils, mais bien expliqués

L'erreur la plus répandue consiste à donner trop d'outils à un agent, en supposant que plus il a de possibilités, plus il sera utile. C'est l'inverse qui se produit. Au-delà d'une dizaine, les confusions augmentent nettement : il choisit un outil voisin mais inadapté, ou enchaîne des appels inutiles.

Ce qui fonctionne bien mieux :

  • Des outils formulés en langage métier, pas en langage technique. Un seul outil « rechercher un dossier client » plutôt que trois opérations séparées pour interroger la base, filtrer puis mettre en forme.
  • **Des descriptions qui disent aussi quand ne pas s'en servir.** C'est au moins aussi utile que d'expliquer à quoi l'outil sert.
  • Des messages d'erreur compréhensibles. Un outil qui répond error 500 laisse l'agent sans issue. Un outil qui répond « aucun dossier trouvé pour ce numéro, le format attendu est AAAA-NNNN » lui permet de corriger seul. La différence de fiabilité entre les deux est spectaculaire.
  • Des choix contraints plutôt que du texte libre, pour que les demandes invalides soient tout simplement impossibles.

Ce dernier point mérite d'être souligné, car il est contre-intuitif : la fiabilité d'un agent dépend davantage du soin apporté à ses outils qu'à la puissance du modèle qui les utilise. C'est une bonne nouvelle, parce que c'est la partie que vous maîtrisez entièrement.

MCP : la prise universelle

Se pose alors une question très concrète : comment brancher un système d'IA sur votre GED, votre CRM ou votre ERP ?

Sans standard, chaque branchement est un développement spécifique, à refaire pour chaque nouvel assistant. Trois assistants, trois fois le travail — et trois fois la surface à sécuriser.

Le Model Context Protocol, ou MCP, répond à ce problème en jouant le rôle d'une prise universelle, un peu comme l'USB a fini par unifier les périphériques. Vous exposez vos outils une fois, selon un format commun ; n'importe quel assistant compatible peut ensuite s'y brancher.

L'intérêt est donc autant organisationnel que technique : le connecteur vers votre référentiel documentaire est développé, sécurisé et audité une seule fois, puis réutilisé par plusieurs cas d'usage.

Deux points de vigilance, à vérifier dès la première revue :

L'identité de l'utilisateur doit être transmise de bout en bout. Si le connecteur accède aux données avec un compte technique unique, tout votre modèle de droits est court-circuité : l'agent voit tout, quel que soit l'utilisateur. Il doit agir au nom de la personne, avec ses droits à elle. C'est le premier point que nous contrôlons, et celui qui pose le plus souvent problème.

Chaque action doit laisser une trace : qui a demandé quoi, quel outil a été appelé avec quels paramètres, quel résultat est revenu. Sans ce journal, un incident est tout simplement inexplicable après coup.

Savoir ce qui s'est passé

Un agent qui échoue ne renvoie généralement pas d'erreur. Il renvoie une réponse plausible et fausse. C'est ce qui rend l'instrumentation indispensable plutôt que confortable.

Pour chaque exécution, il faut conserver :

  1. la demande initiale de l'utilisateur ;
  2. la suite des outils appelés, avec les paramètres et les résultats ;
  3. le nombre de tentatives avant d'aboutir ou d'abandonner ;
  4. la réponse finale et, si possible, la réaction de l'utilisateur.

Ces traces servent trois choses : comprendre un incident, repérer les outils mal conçus — un outil systématiquement appelé deux fois de suite a un problème de description — et constituer une série de scénarios de test pour vérifier que les évolutions ne cassent rien.

Les garde-fous qui évitent la plupart des dérapages

Quelques mécanismes simples suffisent à écarter l'essentiel des mauvaises surprises :

  • Une limite au nombre de tentatives. Un agent qui tourne en rond doit s'arrêter et le dire, pas consommer indéfiniment.
  • Un budget par demande, en nombre d'actions comme en coût.
  • Une vérification des résultats avant toute action qui engage : le format est-il correct, les identifiants existent-ils vraiment ?
  • Un droit de dire non. L'agent doit pouvoir répondre « je ne sais pas traiter cette demande » et passer la main à un humain. Privé de cette porte de sortie, il inventera une réponse — c'est mécanique.

Commencer petit, mais utile

Les déploiements qui réussissent commencent presque toujours par un agent en consultation seule, sur un périmètre étroit : répondre à des questions sur un ensemble de dossiers, rassembler des informations réparties entre deux ou trois systèmes, préparer une synthèse qu'une personne relit.

Cela paraît modeste. En réalité, cette première étape construit déjà l'essentiel de l'infrastructure : l'authentification, la transmission des droits, la journalisation, la mesure de la qualité. Une fois ces fondations posées et éprouvées, ajouter des capacités d'action devient une décision progressive et maîtrisée, plutôt qu'un saut dans le vide.

Vous envisagez de connecter vos outils métier à un système d'IA, et vous vous demandez par où commencer ? Découvrez notre approche des agents IA et intégrations MCP, ou parlons de votre contexte.