Retour aux publications
Transformation métiers

Copilot Studio : construire un agent métier qui tient en production

Construire un agent dans Copilot Studio est devenu simple. Le faire tenir six mois en production ne l'est pas : les quatre questions à trancher avant d'ouvrir l'outil.

7 min
Les quatre décisions à trancher pour construire un agent Copilot Studio : instructions, connaissances, actions, déclencheurs.

Copilot Studio est l'atelier dans lequel une organisation construit ses propres agents : des assistants spécialisés sur un processus, branchés sur ses données, plutôt qu'un assistant généraliste qui répond à tout et à rien.

L'outil abaisse fortement la barrière technique. Il ne supprime pas les questions qui décident de la réussite, et c'est là que se joue la différence entre une démonstration réussie et un agent qui tourne encore dans six mois.

Ce qu'est réellement un agent

Un agent, au sens de Copilot Studio, est la combinaison de quatre choses : des instructions qui décrivent son rôle et ses limites, des connaissances — les sources documentaires ou métier qu'il a le droit de consulter, des actions qu'il peut déclencher dans les outils, et des déclencheurs qui décident quand il intervient.

La tentation est de tout ouvrir : plus de connaissances, plus d'actions, plus d'autonomie. C'est l'inverse qui produit un agent fiable. Un agent utile fait peu de choses, toujours de la même façon, et sait dire qu'il ne sait pas.

Les quatre questions à trancher avant d'ouvrir l'outil

  1. Quel processus précisément ? Pas « le service client », mais « répondre aux questions de niveau 1 sur les conditions de garantie ». Un périmètre qu'on ne peut pas énoncer en une phrase ne se teste pas.
  2. Sur quelles sources ? Une source à jour, dont quelqu'un est propriétaire. Un agent branché sur une base documentaire que personne ne maintient produira des réponses périmées avec assurance.
  3. Quelles actions, et jusqu'où ? Lire est sans risque. Écrire, envoyer, valider ne le sont pas. La frontière doit être écrite avant la première démonstration.
  4. Qui garde la main ? Un humain doit pouvoir arrêter, corriger et reprendre — avec le temps et l'information nécessaires pour le faire. C'est aussi une exigence réglementaire, pas seulement une bonne pratique.

Le point que les démonstrations masquent

Un agent qui répond bien sur cinq questions choisies ne prouve rien. Ce qui prédit sa tenue en production, c'est un jeu d'évaluation : une trentaine de cas réels, avec la réponse attendue, rejoués à chaque modification.

Sans ce jeu, deux choses arrivent sans qu'on les voie. Une modification d'instruction qui améliore un cas en dégrade trois autres. Et une mise à jour du modèle côté éditeur change le comportement du jour au lendemain, sur un périmètre que personne ne mesure.

C'est le même mécanisme que celui décrit dans pourquoi les POC IA échouent : ce n'est pas le modèle qui manque, c'est la mesure.

Connaissances : la question du RAG se pose ici

Brancher un agent sur des documents, c'est faire du RAG — de la recherche documentaire augmentée. Les arbitrages de coût et de qualité qui vont avec sont réels, et nous les détaillons dans RAG ou fine-tuning sur données propriétaires.

Le piège le plus fréquent est la minimisation : par défaut, on indexe tout ce qu'on a sous la main. Or le règlement impose de ne traiter que ce qui est nécessaire à la finalité, et chaque document indexé en trop est à la fois un risque de conformité et une source de bruit dans les réponses.

Ce que l'agent hérite, et qu'on ne voit pas

Un agent construit sur les données de l'organisation hérite des droits d'accès existants. Il n'ouvre rien de fermé, mais il révèle ce qui était ouvert sans que personne ne le regarde. La revue des partages est un préalable, pas une étape de fin de projet — le mécanisme est détaillé dans sécuriser les agents IA contre le data leakage.

Et ensuite : l'exploitation

Un agent mis en production est un système à exploiter, pas un livrable à recetter. Il lui faut un propriétaire métier, une journalisation des entrées, des sorties et des décisions, une revue périodique des cas ratés, et une procédure quand il se trompe.

Cette traçabilité n'est pas seulement de l'hygiène technique : c'est la condition pratique de l'auditabilité qu'exige le règlement européen, dont nous donnons le détail dans notre checklist d'auditabilité d'un système d'IA.

Pour le cadre plus large — comité, registre des usages, indicateurs — voir la gouvernance de l'IA.