Agents outillés connectés au SI

Le problème

Les tâches qui coûtent le plus traversent plusieurs applications : une demande arrive dans l’outil de tickets, l’information utile est dans la GED, la réponse se prépare dans le CRM, l’écriture finit dans l’ERP. Quelqu’un fait le lien à la main, plusieurs fois par jour, et produit des erreurs précisément parce que c’est ennuyeux.

Les automatisations classiques par règles butent sur ces cas : elles demandent un format d’entrée stable, et un e-mail, un ticket ou un compte rendu n’ont jamais deux fois la même forme. Les modèles de langage tolèrent cette variation. Mais un agent lâché dans un SI sans cadre pose un problème que toute équipe d’exploitation reconnaît : des actions non tracées, des droits trop larges, des effets de bord que personne n’a validés.

Mon approche

Un agent est un composant du SI comme un autre. Il a un compte, des droits, des journaux et une procédure de reprise. Je le construis dans cet ordre.

• Des outils explicites. L’agent n’a accès qu’aux actions déclarées, à travers les API de vos applications ou des serveurs MCP. MCP (Model Context Protocol) est le standard ouvert qui décrit à un modèle les outils qu’il peut appeler ; j’écris des clients MCP en Python et je m’en sers tous les jours.
• Lecture libre, écriture validée. L’agent lit et prépare seul. Toute écriture qui engage quelque chose passe par une validation humaine, ou par une file de vérification quand le niveau de confiance est insuffisant. Un humain garde la main, et peut l’annuler.
• Moindre privilège. Un compte de service dédié, des droits limités aux actions prévues, révocables. Comme pour n’importe quel composant.
• Tout tracer. Chaque appel d’outil est journalisé avec ses entrées, ses sorties et la décision prise, dans vos outils d’observabilité ou avec Langfuse. C’est indispensable pour corriger, et exigé dès qu’une décision produit un effet notable sur une personne.
• Des contrôles déterministes. Un total qui doit tomber juste, une référence qui doit exister, un statut qui doit être cohérent : ce qui peut se vérifier par une règle se vérifie par une règle, avant toute écriture.

Concrètement, un agent se compose d’un déclencheur (un ticket créé, un fichier déposé, une file, un appel programmé), du modèle et de ses outils, des contrôles, puis d’une écriture dans vos applications par leurs API. Le modèle tourne où vous le décidez, chez vous ou chez un fournisseur acceptable pour vos données, avec un coût d’inférence estimé avant la mise en production.

Ce que vous recevez

• L’agent et ses outils, déployés dans votre infrastructure, avec les connecteurs ou serveurs MCP vers les applications concernées.
• Une supervision : ce qui est passé automatiquement, ce qui attend une validation, ce qui a échoué et pourquoi.
• Le journal d’audit des actions, exploitable par votre sécurité.
• Le rapport de mesure avant/après : taux de traitement automatique, taux d’erreur résiduel, temps rendu aux équipes.
• L’estimation du coût d’exécution mensuel, appels de modèles compris, avec les leviers pour le réduire.
• La procédure de reprise manuelle si le service est indisponible.

Pour qui

Une DSI ou une direction métier qui a un processus à la fois volumineux, répétitif, et qui traverse plusieurs applications dont on peut atteindre les API. Côté ESN, une mission d’intégration IA à pourvoir chez un client, où il faut à la fois écrire l’agent et le faire accepter par l’exploitation.

Si vous hésitez entre plusieurs processus, la page cadrage et évaluation décrit la démarche qui permet de les classer par gain réel et par difficulté d’intégration.