Donner aux agents IA un accès utile aux données de vos opérations.
Pour aider une équipe, un agent doit trouver une information fiable et utiliser des fonctions bien définies. La connexion se prépare avec le contexte, les accès et les limites du travail.
Des informations accessibles. Des fonctions et des permissions définies.
Un collègue demande où en est une commande avant de rappeler un client. Pour l’aider, un agent IA doit identifier le bon dossier, consulter une information suffisamment récente et comprendre ce que le statut signifie. Une réponse plausible ne suffit pas à préparer cet échange commercial.
Nous abordons donc les agents par les données et les fonctions dont ils auront besoin. Boutik peut servir de fondation pour rendre des informations et certaines opérations accessibles à différents outils. Le périmètre à exposer à un assistant se définit selon vos systèmes, les interfaces disponibles et les responsabilités des utilisateurs.
Partir d’une question que votre équipe pose déjà.
Nous choisissons une demande concrète avant d’ouvrir un ensemble de données : retrouver une commande, préparer une vérification ou expliquer un écart documentaire. Il faut connaître la personne qui pose la question, le contexte du compte et les éléments nécessaires à une réponse utile.
Cette demande permet de préciser le résultat attendu. Consulter un statut, préparer une proposition et modifier une commande n’engagent pas les mêmes fonctions. Le premier parcours peut se limiter à retrouver des informations et à les présenter avec leur contexte, puis être élargi après validation de son utilité.
Préparer les données et conserver leur sens.
Une copie préparée des données peut servir les consultations sans interroger directement l’ERP à chaque demande. Sa synchronisation sollicite toujours le système source. Nous devons choisir les données utiles, leurs identifiants et le rythme de mise à jour adapté à l’usage.
L’agent doit aussi recevoir le contexte qui rend ces données compréhensibles. Une quantité disponible, une réception partielle et une livraison confirmée ne décrivent pas la même situation. Quand la fraîcheur ou une correspondance est incertaine, le parcours doit rendre cette limite visible plutôt que transformer l’absence d’information en certitude.
Exposer des fonctions dont le rôle est clair.
Une API fournit une interface par laquelle un logiciel peut demander des informations ou appeler certaines fonctions. Nous disposons d’une API pour des échanges; cela ne signifie pas que toutes les opérations sont déjà exposées à tous les assistants. Nous examinons les fonctions pertinentes pour le parcours retenu.
Pour chacune, il faut préciser les informations requises, la réponse retournée et les contrôles appliqués. Si une référence n’existe pas, comment le système le signale-t-il? Si une demande est répétée, comment évite-t-on une double action? Ces décisions relient la connexion technique au fonctionnement attendu par vos équipes.
Comprendre où MCP peut intervenir.
MCP, pour Model Context Protocol, est un protocole ouvert qui organise les échanges entre une application d’IA et des systèmes externes. Son architecture distingue l’application hôte, ses clients et les serveurs qui exposent des ressources ou des outils. Il fournit un cadre commun pour découvrir des capacités et les utiliser.
Un serveur MCP peut s’appuyer sur une API métier pour accomplir une opération. Il reste à définir les outils exposés, les capacités prises en charge par l’assistant et les autorisations applicables. Dans un projet Boutik, le périmètre MCP disponible doit être confirmé pour l’environnement visé; nous ne présumons pas une compatibilité complète avec chaque assistant.
Faire respecter les accès au point où l’action est autorisée.
Un représentant et une personne de la comptabilité n’ont pas nécessairement accès aux mêmes comptes ou documents. Les fonctions utilisées par un agent doivent respecter ces responsabilités. Les contrôles d’accès se vérifient dans les systèmes qui fournissent les données et autorisent les opérations.
Les instructions données au modèle complètent ce cadre sans remplacer ces vérifications. Il faut aussi décider quelles actions demandent une confirmation et quelle information permet à la personne de se prononcer. Une permission technique ne suffit pas à établir qu’une décision commerciale a été approuvée.
Un accès utile, de la demande à la décision
01DemandeUne tâche, un utilisateur et un contexte définis.
02Fonction autoriséeDes entrées, des données et un périmètre explicites.
03Résultat vérifiableUne réponse, ses limites et les documents utiles.
04Suite appropriéeConsulter, proposer ou faire confirmer l’action.
Schéma de conception, indépendant d’un assistant particulier. Les intégrations et permissions sont à valider pour chaque projet.
Essayer un premier parcours avec les personnes concernées.
Nous pouvons préparer un prototype avec quelques cas représentatifs, puis examiner les réponses avec les utilisateurs. Une donnée manquante, un accès refusé et une information périmée sont aussi instructifs qu’un cas habituel. Une base de test peut aider à explorer le parcours sans engager les opérations réelles.
Cette étape sert à décider ce qui doit être connecté et comment valider la suite. Un agent capable de retrouver les bonnes pièces pour préparer une décision peut déjà répondre à un besoin précis. L’élargissement des fonctions repose ensuite sur les accès disponibles, les essais et les règles que votre équipe souhaite appliquer.
Définir un premier accès utile
✓ Une question réelle et le rôle de la personne qui la pose.
✓ La source, le sens et la fraîcheur attendue des données.
✓ Les fonctions nécessaires et leurs permissions.
✓ Les confirmations requises avant une action engageante.
✓ Des cas habituels et des exceptions pour valider le parcours.
