C'est le rôle d'un agent IA. Il associe un modèle capable de traiter le langage à un logiciel qui organise les étapes et interagit avec les outils autorisés. L'objectif n'est pas seulement de produire une réponse, mais d'avancer sur une tâche, puis de vérifier ce qui a effectivement été fait.12
Chez Opvia, le point de départ reste un cas de votre entreprise. Les explications ci-dessous décrivent les mécanismes possibles ; les connexions, les modèles et le degré d'autonomie sont définis pour le cas retenu.3
01
Un modèle, un agent et une automatisation : trois rôles différents
Le modèle d'IA traite les informations qu'il reçoit. Il peut extraire une date, résumer un échange, proposer une catégorie ou rédiger un texte.
L'automatisation exécute un enchaînement prévu : lorsqu'un formulaire arrive, créer une ligne ; lorsqu'une échéance est atteinte, ouvrir une tâche. Si les règles suffisent, ajouter un modèle n'est pas nécessaire.
L'agent peut choisir certaines étapes en fonction de la demande et des résultats obtenus. Il consulte un dossier, constate qu'une information manque, puis prépare une question plutôt qu'une réponse définitive. Cette capacité d'adaptation doit rester limitée au périmètre prévu.1
Un chatbot désigne surtout une interface de conversation. Certains restent limités aux réponses textuelles ; d'autres donnent accès à de véritables agents. La bonne question n'est donc pas « y a-t-il une fenêtre de chat ? », mais « quelles données le système peut-il consulter, et quelles actions peut-il déclencher ? ».
Dans une entreprise, ces mécanismes peuvent être combinés. Une procédure fixe encadre le travail ; l'IA intervient là où il faut interpréter une formulation variable. Un calcul de total, lui, reste confié au logiciel de devis ou à une fonction de calcul.
02
Ce que fait réellement l'IA
Un modèle entraîné, puis utilisé sur votre demande
Un grand modèle de langage, ou LLM, est un réseau de neurones entraîné sur des données. Cet entraînement ajuste ses paramètres pour apprendre des régularités et produire des sorties adaptées à un contexte.
Lors de son utilisation, le texte est représenté sous forme de tokens : des unités qui peuvent correspondre à des mots, des fragments de mots ou des signes. Les modèles de type Transformer utilisent notamment des mécanismes d'attention pour mettre en relation les éléments du contexte. À chaque étape, ils estiment quels tokens peuvent suivre dans le contexte reçu, puis en sélectionnent un selon les réglages de génération. La sortie se construit ainsi progressivement. Cette phase d'utilisation s'appelle l'inférence.4
Le contexte fourni peut réunir votre demande, des instructions, des extraits de documents et les résultats d'outils. Ce n'est pas la totalité de votre entreprise : c'est ce que l'application transmet au modèle à cet instant.
Une réponse plausible n'est pas une preuve
Un modèle peut produire une formulation convaincante avec une information fausse. Il peut aussi mal interpréter une pièce ou manquer une contradiction. La qualité du texte ne garantit donc pas l'exactitude du contenu.5
Pour un devis, par exemple, le montant doit venir du catalogue et du calcul prévus, pas d'une estimation improvisée par le modèle. Pour un rendez-vous, la disponibilité doit être vérifiée dans l'agenda. Lorsqu'une surface ou une référence manque, le traitement doit le signaler au lieu de la compléter arbitrairement.
03
De la demande à l'action : une boucle contrôlée
Le fonctionnement repose sur un échange entre le modèle et le programme qui l'entoure. Le modèle peut demander l'utilisation d'une fonction ; c'est l'application qui exécute cette fonction et lui retourne son résultat. Ce mécanisme est appelé appel d'outil, ou tool calling.2
Prenons une tâche illustrative : préparer la réponse à une demande de devis.
- 01
La demande déclenche le traitement. Un message, un formulaire ou une échéance fournit le point de départ. L'application identifie le cas et les ressources qu'il est autorisé à utiliser.
- 02
Le contexte utile est rassemblé. Le traitement récupère le message, le dossier correspondant et les règles nécessaires. Une ambiguïté sur le client ou le chantier doit rester visible.
- 03
Le modèle propose la suite. Il peut demander une recherche, extraire les informations présentes ou préparer une question. Il n'obtient pas, pour autant, un accès général aux logiciels.
- 04
L'application contrôle la demande d'action. Elle vérifie les paramètres, le périmètre et les validations requises avant d'utiliser le connecteur.
- 05
Le résultat est vérifié. Un identifiant de brouillon retourné par la messagerie constitue un résultat observable. Une phrase produite par le modèle disant « le brouillon est créé » n'en constitue pas un.
- 06
Le traitement continue ou s'arrête. Il peut terminer, demander une information ou passer la main. Des limites de durée, de nombre d'étapes et de coût évitent qu'une tâche continue sans borne.12
Le point essentiel : le modèle propose une action ; les permissions et le code décident si elle peut être exécutée. Une consigne textuelle ne doit pas être la seule protection d'une opération sensible.9
04
Comment l'agent se connecte à vos logiciels
Votre environnement peut réunir une messagerie, un agenda, un outil de devis, des fichiers partagés, un CRM et quelques tableurs. L'intégration consiste à ouvrir les fonctions nécessaires au cas choisi, pas à donner une clé générale à tout cet ensemble.
Les API : des fonctions accessibles par logiciel
Une API est une interface permettant à un programme de demander une opération à un autre : rechercher une fiche client, lire un événement, enregistrer un document ou créer un brouillon.
Le connecteur traduit les outils proposés au modèle en appels vers l'API du logiciel métier. Il traite également les réponses et les erreurs. Le modèle n'a pas besoin de connaître le mot de passe de l'utilisateur pour produire les paramètres d'un appel.2
Lorsque le service le permet, OAuth sert à déléguer des autorisations au moyen de jetons, sans remettre son mot de passe à l'application. Les permissions doivent être réduites au nécessaire et pouvoir être révoquées.6
Il faut toutefois examiner la granularité réelle des droits. Écrire « uniquement ce dossier » dans une consigne n'équivaut pas à une restriction technique sur ce dossier. L'intégration doit faire respecter ce périmètre, y compris lorsque les permissions proposées par l'éditeur sont plus larges.
Les événements : quand faut-il démarrer ?
Un traitement peut démarrer à la demande, à une heure prévue ou à la réception d'un événement. Un webhook est une notification envoyée par un logiciel à un autre lorsqu'un événement survient. En son absence, une vérification périodique peut être envisagée.
Ces mécanismes déclenchent le travail ; ils ne sont pas l'IA. Il faut notamment prévoir l'authentification des notifications et le traitement des événements reçus plusieurs fois.
MCP : une façon commune de présenter les outils
Le Model Context Protocol, ou MCP, standardise les échanges entre une application d'IA et des serveurs qui exposent des outils ou des ressources. Un serveur MCP peut, par exemple, présenter une fonction de recherche documentaire ou une action dans un logiciel.7
MCP n'est ni un modèle ni un accès universel. Il ne crée pas les autorisations et ne remplace pas les contrôles métier. L'intérêt est d'uniformiser la connexion ; la sécurité dépend toujours du serveur, des droits accordés et de l'usage qui en est fait.
Et les logiciels sans API ?
Un import ou export de fichiers, un connecteur spécifique ou une automatisation du navigateur peut parfois convenir. Le choix se vérifie sur le logiciel concerné.
Pour un parcours piloté à l'écran, il faut anticiper les changements d'interface, les demandes de réauthentification et les situations que l'automatisation ne sait pas traiter. L'objectif n'est pas de promettre une compatibilité universelle, mais de retenir un chemin exploitable et maintenable.
05
Comment il utilise vos documents sans « tout apprendre »
Un agent n'a pas nécessairement besoin d'entraîner un nouveau modèle sur vos fichiers. Il peut rechercher les informations pertinentes, puis les fournir au modèle au moment de répondre. Cette approche est appelée RAG, pour génération augmentée par la recherche documentaire.8
Pour préparer une réponse sur une prestation, le traitement peut chercher la fiche correspondante et la procédure à jour. Il transmet les passages utiles plutôt que l'ensemble des archives. La recherche peut être textuelle, sémantique ou combiner plusieurs méthodes ; une base vectorielle n'est pas une obligation pour chaque cas.8
L'intégration doit conserver la référence des sources utilisées, respecter les droits de lecture et gérer les mises à jour. Retrouver un ancien tarif n'en fait pas le tarif applicable.
Il faut aussi séparer trois éléments : les documents de référence, qui restent dans les systèmes prévus ; le contexte temporaire, transmis pour une tâche ; et une éventuelle mémoire persistante, conservée entre les tâches. Ajouter une mémoire augmente les données stockées et doit répondre à un besoin défini.10
Fournir un document pendant une requête n'est pas, en soi, réentraîner le modèle. L'éventuelle réutilisation de ce document par le fournisseur est une autre question, à examiner dans ses conditions et ses réglages.5
06
Qui décide de ce que l'agent peut faire ?
L'autonomie se règle par action, et non par une permission générale accordée à « l'IA ». Chez Opvia, le principe présenté est de commencer par préparer le travail, puis de faire évoluer ce qui peut être exécuté selon le cas et vos décisions.3
Pour cadrer un projet, trois niveaux sont utiles :
Niveau 1
Préparer
Il produit un résultat sans effectuer l'action finale.
Exemple illustratif : un brouillon de réponse.
Niveau 2
Soumettre
Il attend une validation identifiable avant l'exécution.
Exemple illustratif : un devis à transmettre après relecture.
Niveau 3
Exécuter dans un cadre défini
Il réalise uniquement les actions et conditions autorisées.
Exemple illustratif : enregistrer un compte rendu dans le dossier prévu.
La validation doit porter sur l'action réelle : contenu, destinataire, pièces et objet concernés. Si ces éléments changent après l'accord, une nouvelle validation peut être nécessaire.
Autre risque à prévoir : une instruction malveillante cachée dans un message ou un document. Cette injection de prompt cherche à détourner le comportement du système. Un document reçu doit être traité comme une source d'information, pas comme une nouvelle autorité capable d'accorder des droits.9
La protection combine donc des fonctions limitées, des contrôles côté application et des autorisations adaptées. Elle ne repose pas uniquement sur la capacité du modèle à reconnaître une mauvaise instruction.
07
Que se passe-t-il en cas d'erreur ?
Le comportement attendu doit être défini avant la mise en service. Une donnée manquante appelle une question ; un accès refusé appelle une alerte ; une réponse ambiguë ne doit pas être transformée en succès.
Une attention particulière concerne les interruptions. Si le logiciel a créé un rendez-vous mais que sa réponse n'est pas parvenue à l'agent, recommencer immédiatement peut créer un doublon. L'intégration doit prévoir, selon les capacités de l'API, une clé d'idempotence ou une vérification de l'état avant une nouvelle tentative.
Le journal d'exécution doit permettre de retrouver la tâche, l'outil appelé, le résultat reçu et la validation éventuelle. Il ne s'agit pas de conserver des mots de passe ou toutes les données sans limite, mais les éléments nécessaires au suivi et au diagnostic.
Enfin, toutes les actions ne sont pas annulables. Un brouillon se corrige ; un message déjà reçu par un client ne se retire pas avec certitude. La prévention doit être proportionnée aux conséquences de l'action.
08
Où passent les données ?
Il faut distinguer l'endroit où fonctionne l'agent et l'endroit où fonctionne le modèle. Un agent installé sur une infrastructure dédiée peut appeler un modèle externe par API. Les informations incluses dans la requête sont alors traitées par ce service. Un modèle local constitue une autre architecture.11
La question concerne également les services annexes : transcription d'un vocal, lecture d'une image, recherche web, stockage de mémoire ou supervision. Ils doivent faire partie de la cartographie des flux, pas disparaître derrière le seul nom du modèle principal.
Pour chaque cas, le cadrage doit préciser les données nécessaires, leurs destinataires techniques, les lieux de traitement, les durées de conservation et les accès d'administration. Les conditions de réutilisation pour l'entraînement se vérifient fournisseur par fournisseur.510
Une infrastructure dédiée ne suffit donc pas à promettre que toutes les données restent locales. Elle décrit un périmètre d'hébergement, pas automatiquement toute la chaîne de traitement.
09
Un exemple complet : une demande de devis chez un artisan
Scénario illustratif, et non résultat mesuré chez un client Opvia
Un client envoie un message et deux photos pour une intervention. L'artisan souhaite que les demandes soient préparées dans ses outils habituels, sans envoi automatique.
Le traitement récupère le message autorisé et recherche le dossier correspondant. Il extrait la prestation demandée et les informations présentes. La surface manque : ce champ reste indiqué comme manquant. Une photo n'est pas utilisée pour inventer une mesure.
Le connecteur consulte ensuite les références utiles dans les documents ou le logiciel de devis. Les montants éventuels proviennent des données et règles disponibles, pas d'une génération libre. Si les informations ne permettent pas de préparer le devis, l'agent rédige plutôt une demande de précisions.
Le résultat est enregistré sous forme de brouillon. Le dossier de suivi reçoit le statut prévu, par exemple « informations complémentaires à demander ». Le journal conserve la référence du message traité et celle du brouillon créé.
L'artisan relit et envoie. Le bénéfice recherché est d'éviter de rassembler manuellement les mêmes éléments dans plusieurs outils, tout en gardant la décision et la relation client.
10
Comment vérifier que le cas est prêt à fonctionner ?
Le cadrage commence par un résultat observable : un brouillon dans la bonne boîte, un document dans le bon dossier, une tâche au bon statut. Il précise également ce que le système ne doit jamais faire.
Les essais doivent couvrir des situations normales, mais aussi un doublon, un document illisible, deux clients homonymes, une information contradictoire, un accès expiré et une demande hors périmètre. Le contrôle porte sur le résultat dans le logiciel, pas seulement sur la réponse de l'IA.
Une première phase de préparation et de relecture permet d'observer les corrections nécessaires. Ensuite, l'autonomie peut évoluer action par action. Le suivi doit porter sur les erreurs, le temps de correction et le coût du traitement complet : multiplier les tâches exécutées n'a pas d'intérêt si elles demandent toutes une reprise.
11
Questions fréquentes
Faut-il changer de logiciels ?
Ce n'est pas l'objectif d'Opvia. Le projet part des outils déjà utilisés. La faisabilité se vérifie toutefois pour chaque logiciel : fonctions accessibles, permissions, abonnement éventuel et contraintes d'intégration. Une présence dans votre environnement ne garantit pas que toutes ses fonctions soient automatisables.3
L'agent doit-il avoir accès à toute ma messagerie ?
Non, ce n'est pas une nécessité de principe. Il faut déterminer le périmètre utile et vérifier comment le faire respecter techniquement. Une boîte dédiée, des droits restreints ou un filtrage contrôlé peuvent être étudiés selon le service. Le périmètre écrit doit correspondre aux accès réellement ouverts.
Peut-il travailler sans que je lui écrive ?
Oui, lorsqu'un déclenchement planifié ou événementiel est configuré. L'exécution ne dépend alors pas d'une conversation ouverte. Elle nécessite néanmoins une infrastructure disponible, des accès valides et un traitement prévu pour les exceptions.11
Est-il capable de se tromper ?
Oui. Il faut contrôler les informations extraites, les sources et les actions sensibles. Un système utile doit aussi savoir s'arrêter ou signaler un manque, plutôt que produire une réponse définitive à tout prix.5
Que se passe-t-il si je coupe les accès ?
La révocation doit empêcher les futurs appels concernés. Elle ne rappelle pas un message déjà envoyé et n'efface pas automatiquement les copies conservées. L'arrêt du service doit donc prévoir aussi les tâches en cours, les traitements planifiés et le sort des données stockées.
12
Votre cas, dans vos outils
Décrivez une tâche que vous faites régulièrement. Le premier travail consiste à repérer les informations nécessaires, les logiciels concernés et les décisions qui doivent rester entre vos mains.
Un cas concret. Le vôtre.
Décrire votre cas13
Quelques termes utiles
- LLM
- Modèle de langage utilisé pour traiter ou produire du texte.
- Inférence
- Utilisation d'un modèle déjà entraîné.
- API
- Interface permettant à des logiciels d'échanger.
- MCP
- Protocole présentant des outils et ressources à une application d'IA.
- RAG
- Recherche d'informations utiles avant la génération d'une réponse.
- Idempotence
- Propriété permettant de répéter une même opération sans en multiplier l'effet.
14
Sources
Documentation consultée le 5 septembre 2026. Les exemples et les modalités de cadrage sont des propositions d'architecture, pas la description d'un déploiement audité.
- 1Anthropic - Building Effective AI Agents. Distinction entre workflows et agents, boucle d'exécution et choix d'une architecture simple. anthropic.com/engineering/building-effective-agents
- 2OpenAI - Function calling. Le modèle émet une demande d'outil ; l'application exécute la fonction et retourne le résultat. developers.openai.com/api/docs/guides/function-calling
- 3Opvia - Accueil et À propos. Positionnement public, intégration aux outils existants et autonomie réglable. opvia.fr et opvia.fr/a-propos
- 4Google for Developers - Introduction to Large Language Models. Tokens, contexte et fonctionnement des modèles de langage. developers.google.com/machine-learning/crash-course/llm
- 5CNIL - Questions-réponses sur l'utilisation d'un système d'IA générative. Limites, précautions et choix du mode de déploiement. cnil.fr/fr/les-questions-reponses-de-la-cnil-sur-lutilisation-dun-systeme-dia-generative
- 6Google for Developers - Using OAuth 2.0 to Access Google APIs. Autorisations, jetons et périmètres d'accès. developers.google.com/identity/protocols/oauth2
- 7Model Context Protocol - Architecture overview. Rôles des hôtes, clients et serveurs MCP. modelcontextprotocol.io/docs/2026-07-28/learn/architecture
- 8Anthropic - Contextual Retrieval. Recherche documentaire, recherche sémantique et combinaison avec la recherche textuelle. anthropic.com/engineering/contextual-retrieval
- 9OWASP - LLM01:2025 Prompt Injection. Instructions malveillantes dans les contenus et mesures de réduction du risque. genai.owasp.org/llmrisk/llm01-prompt-injection
- 10CNIL et CIANum - IA agentique et données personnelles, 20 juillet 2026. Multiplication des flux, mémoire persistante et responsabilités. cnil.fr/fr/ia-agentique-cnil-cianum-note
- 11Hermes Agent - Architecture et LLM and Model Providers. Déclenchements, moteur d'exécution et fournisseurs distants ou locaux. hermes-agent.nousresearch.com/docs/developer-guide/architecture et hermes-agent.nousresearch.com/docs/integrations/providers