LLM ou agent IA : l’architecture qui transforme un modèle en outil métier

Un modèle de langage peut analyser un message, produire une synthèse et proposer un plan. Pour traiter une demande dans votre entreprise, il lui faut aussi accéder au bon dossier, comprendre les règles applicables et agir dans les limites des droits de l’utilisateur. Ces capacités dépendent de l’application construite autour du modèle.

Cette distinction change la manière de cadrer un projet. Choisir un LLM répond à une question de capacité. Concevoir un agent répond à une question opérationnelle : comment obtenir un résultat vérifiable à partir de vos données et de vos systèmes ? C’est à cette seconde question que je consacre le travail d’architecture.

Distinguer modèle, workflow et agent

Le LLM génère une réponse à partir des informations qui lui sont fournies et de ce qu’il a appris pendant son entraînement. Il dispose de connaissances générales, mais un appel isolé ne lui donne pas automatiquement accès à votre base de données, à vos droits internes ou au dernier état d’un dossier.

Un workflow organise des étapes prévues par le développeur. Un agent donne au modèle une latitude pour choisir certaines étapes et certains outils selon les résultats observés. Cette distinction est utile pour décider où placer l’autonomie ; elle correspond notamment à celle proposée par Anthropic. Définitions des workflows et des agents.

Une application peut combiner les deux. Je peux conserver un parcours fixe pour authentifier un utilisateur et contrôler une opération, tout en confiant à un agent la recherche des informations nécessaires. Le degré d’autonomie devient alors un choix explicite, adapté à chaque responsabilité.

Construire un contexte utilisable

Prenons un exemple illustratif dans la maintenance industrielle. Un responsable veut comprendre pourquoi une intervention est en retard et préparer une réponse au client. Le modèle peut avoir besoin de l’ordre de travail, du statut des pièces, du compte rendu précédent et de la procédure interne applicable.

Ces informations n’ont pas toutes le même rôle. Le statut d’une pièce doit venir du système qui le gère. La procédure demande une recherche documentaire avec sa version et son périmètre. Le compte rendu contient des observations qui peuvent être incomplètes. Je conserve ces distinctions lorsque je fournis les éléments au modèle.

Le contexte doit aussi indiquer ce qui manque. Une API indisponible ne signifie pas qu’aucune pièce n’est attendue. Une absence de document ne prouve pas qu’aucune procédure n’existe. L’application doit transmettre l’état de la recherche, la source et les limites du résultat.

Sur la partie documentaire, un dispositif de génération augmentée par recherche, ou RAG, peut retrouver les passages utiles. Il s’intègre au parcours ; il ne remplace ni la vérification des accès ni la consultation des systèmes opérationnels.

Exposer des outils avec des contrats précis

Un outil relie une intention du modèle à une opération logicielle. Pour notre assistant de maintenance, je pourrais définir trois capacités : consulter une intervention, lire l’état d’un approvisionnement et enregistrer un brouillon de réponse.

Chaque contrat précise les paramètres acceptés, les permissions nécessaires, les résultats possibles et les erreurs. La consultation d’une intervention exige un identifiant ; elle retourne un objet structuré avec sa date de mise à jour. L’enregistrement d’un brouillon retourne une confirmation d’écriture, pas seulement le texte que le modèle souhaitait enregistrer.

Cette précision réduit les ambiguïtés. Je distingue également les opérations de lecture des opérations qui modifient le système. Un message demandant une explication ne vaut pas, à lui seul, autorisation d’envoyer une communication ou de changer une date d’intervention.

MCP fournit un protocole commun pour connecter une application à des serveurs exposant notamment des outils et des ressources. Il facilite cette intégration ; l’orchestration métier reste à concevoir dans votre application. Architecture du Model Context Protocol.

Piloter l’exécution et conserver son état

L’agent fonctionne généralement par étapes : examiner les éléments disponibles, proposer un appel d’outil, recevoir le résultat, puis décider de la suite. Autour de cette boucle, je définis une durée maximale, un budget d’appels et des conditions d’arrêt.

Pour l’exemple de maintenance, l’exécution peut se terminer lorsqu’un brouillon sourcé est prêt, lorsqu’une donnée indispensable reste inaccessible ou lorsqu’une décision humaine est nécessaire. Ces sorties doivent être représentées dans l’état de l’application. Un simple texte « j’ai terminé » ne suffit pas à distinguer une réussite d’un abandon.

Je prévois aussi la reprise après incident. Si une connexion coupe juste après l’enregistrement du brouillon, relancer aveuglément l’action peut créer un doublon. Un identifiant d’opération et une vérification du résultat permettent de retrouver ce qui a effectivement été fait avant de décider de recommencer.

Encadrer la partie probabiliste

Le comportement d’un modèle peut varier ; les services autour de lui peuvent également répondre différemment selon leur état. Une application robuste traite les propositions du modèle comme des entrées à vérifier avant exécution.

Dans notre scénario, le serveur contrôle que l’intervention appartient au périmètre accessible à l’utilisateur. Il refuse une modification non autorisée, même si le modèle l’a proposée avec une justification convaincante. Les règles d’accès se placent dans le code et dans les systèmes concernés ; elles ne reposent pas uniquement sur une consigne textuelle.

Les documents consultés peuvent eux-mêmes contenir des instructions trompeuses. Leur contenu doit être traité comme une donnée à analyser, sans pouvoir élargir les permissions de l’agent. Je détaille ces frontières dans mon article sur la sécurité des agents IA.

Évaluer le résultat métier complet

Pour décider si le système fonctionne, je vérifie l’ensemble du parcours. Le bon dossier a-t-il été consulté ? Les informations sont-elles à jour ? Le brouillon distingue-t-il un fait établi d’une hypothèse ? Une action a-t-elle été réalisée sans autorisation ?

Les traces d’exécution doivent permettre de relier ces observations à la version du modèle, aux instructions et aux retours d’outils. Cette visibilité rend les corrections ciblées : une mauvaise réponse peut venir d’un document obsolète ou d’un contrat d’outil ambigu, sans que changer de modèle résolve le problème.

Chez LeoWeb, je vous accompagne pour définir ce périmètre, connecter vos systèmes et construire les contrôles qui rendent le service exploitable. Si vous disposez déjà d’un prototype conversationnel, échangeons sur le parcours métier à lui faire prendre en charge. Le point de départ est un résultat attendu précis, avec des données identifiées et une responsabilité claire pour chaque action.