Agent Copilot Studio

Vous lancez votre premier agent Copilot Studio et, au lieu d'impressionner votre public, il répond à côté ou invente un chiffre. Ce scénario est fréquent chez les débutants, et il se corrige avec quelques réglages ciblés : ancrer l'agent dans un vrai document, lui donner une identité claire, déboguer méthodiquement et publier prudemment.

Cet article montre comment reproduire une mauvaise réponse dans le volet de test, la corriger pour que l'agent cite le bon document, puis publier un pilote fonctionnel.

Pourquoi un agent parfait dans le volet de test échoue en production

Dans Copilot Studio, les entrées sont soignées. Les questions sont courtes, bien formulées et ressemblent souvent aux exemples préparés. Cela donne une impression de réussite. En production, les gens écrivent comme des gens : un cadre demandera « quel montant puis-je réclamer pour mon hôtel ? », un autre fera une faute de frappe dans « limite frais hôtel », un troisième écrira « rappelle-moi le budget voyage ». L'intention est la même, mais le bot peut ne réagir qu'à la formulation testée.

Le test des trois variantes

Pour mesurer l'écart, ouvrez le volet de test et posez la même question de trois façons :

• la version propre ;
• une reformulation décontractée ;
• une version avec faute de frappe.

Si seule la version propre fonctionne, c'est un premier signal d'alerte : un beau résultat de test ne garantit pas la survie en conditions réelles.

La couverture des intentions

Les agents s'appuient sur des phrases déclencheurs et des définitions de sujets. Si tous vos exemples se ressemblent, le modèle devient rigide et un simple synonyme peut le déstabiliser. Ajoutez des phrases déclencheurs plus larges, avec des formulations abrégées, familières ou un peu brouillonnes. Il n'en faut pas des dizaines, juste assez pour couvrir les variations évidentes. Puis testez à nouveau.

Le rôle des canaux

Le volet de test n'est qu'une simulation. Une fois publié sur Teams, SharePoint ou un site de démonstration, le traitement du texte saisi et le rendu des réponses peuvent changer. Teams peut fractionner les lignes autrement, une page web peut supprimer la mise en forme, et un petit déplacement d'expression peut modifier la pondération du modèle. D'où l'importance de tests itératifs sur chaque canal.

Prenons un exemple : dans Studio, « Quel est le plafond de dépense ? » obtient la bonne réponse, 200 $ par jour pour l'hébergement. Mais « Combien puis-je me faire rembourser pour un hôtel ? » peut renvoyer vers les RH ou donner une estimation approximative. L'intention est identique, le résultat est tout autre.

Grounding : ancrer votre agent Copilot Studio dans des connaissances réelles

La première erreur de débutant consiste à traiter Copilot Studio comme une boule de cristal plutôt que comme un manuel de règles. Un agent sans ancrage ressemble à un stagiaire envoyé en rendez-vous de conseil sans préparation : il parle vite, paraît sûr de lui, et la moitié de ses propos s'effondre dès qu'on vérifie.

Le risque des hallucinations

Sans base de connaissances, le système s'appuie sur des modèles de langage, pas sur des faits. Le pire résultat est l'hallucination : l'agent invente une réponse plausible sans fondement. Un employé réserve un hôtel sur cette base, et vous voilà avec des litiges de notes de frais et des e-mails agacés.

Dans l'exercice pratique, un fichier expensepolicy.docx fixe la limite d'hébergement à 200 $ par nuit. Sans ce fichier, à la question « Quelle est la politique hôtelière ? », l'agent peut répondre avec aplomb « 100 $ par nuit », un chiffre inventé. Une fois le fichier joint, il répond que, selon la politique de voyage de l'entreprise, l'hébergement est limité à 200 $.

Comment ajouter des connaissances

1. Ouvrez votre agent dans Copilot Studio.
2. Depuis la vue d'ensemble, cliquez sur « Connaissances ».
3. Choisissez « Ajouter des connaissances », puis le téléversement d'un fichier.
4. Indiquez votre document ou une autre source de confiance.

Vous pouvez aussi vous connecter à un site web public ou à un emplacement SharePoint, mais les fichiers sont plus simples. Patience : l'indexation peut prendre 10 minutes ou plus. Une fois terminée, reposez votre question. Un agent correctement ancré donne la réponse réelle accompagnée d'une petite citation renvoyant à votre document. Cette citation prouve que l'ancrage fonctionne.

L'amélioration conversationnelle ne comble pas les lacunes

Beaucoup supposent que l'amélioration conversationnelle compensera l'absence de source. Ce n'est pas le cas : elle n'invente pas de connaissance des politiques, elle amplifie des schémas textuels. Si aucune correspondance n'est trouvée dans vos connaissances, elle peut se rabattre sur les connaissances générales du modèle et renvoyer des réponses vagues ou inexactes. Pour les sujets critiques (conformité, finance, RH), configurez donc l'agent afin qu'il n'interroge que vos sources ajoutées.

Persona : nom, description et instructions de votre agent

La précision sans personnalité fait fuir les utilisateurs, et dans Copilot Studio, la personnalité ne vient pas toute seule : il faut l'écrire. Laissez les champs vides et l'agent apparaît comme un copilot générique, sans historique, avec des réponses plates. Dans un contexte RH ou finance, ce ton générique laisse penser qu'on teste un prototype et non un outil fiable.

Les trois champs à remplir sur la page de présentation

• Le nom : limité à 30 caractères, il doit être bref et indiquer la fonction (expert en politique de dépenses, guide de voyage, assistant avantages sociaux).
• La description : environ un millier de caractères, soit quelques phrases claires. Par exemple : l'agent fournit aux employés des réponses à jour fondées sur la politique de voyage officielle, cite les passages pertinents et évite toute spéculation.
• Les instructions : jusqu'à 8 000 caractères pour fixer les règles de fonctionnement. « Soyez utile » ne suffit pas. Précisez par exemple de toujours citer la ligne de politique concernée, d'éviter les réponses spéculatives et de résumer en une phrase claire avant la citation.

Checklist de création

1. Nommez le rôle.
2. Rédigez une courte description d'expertise.
3. Définissez le ton : formel, décontracté, simple pour les non-experts.
4. Remplissez les instructions : ce qu'il faut inclure, éviter, et comment formater.

Vous pouvez orienter le ton explicitement (« formel et professionnel » ou « décontracté et facile à comprendre pour un personnel sans bagage technique ») et ajouter des exemples directement dans les instructions.

Deux améliorations rapides

Chacune prend moins de 5 minutes. D'abord, modifiez le sujet de démarrage de la conversation : remplacez l'accueil générique par une introduction liée au rôle, par exemple « Je suis là pour vous aider à comprendre la politique de voyage et je citerai le document officiel si possible ». Ensuite, changez l'icône : le système accepte un PNG jusqu'à 192 × 192 pixels et de moins de 30 Ko. Même un simple logo évite l'aspect « prototype ». Ces détails ne sont pas optionnels : ils constituent l'armure de base de votre agent.

Déboguer un agent Copilot Studio en temps réel

Le débogage consiste à transformer les erreurs en leçons : observer, isoler, corriger, relancer.

La routine en cinq étapes

1. Reproduisez exactement la requête défaillante dans le volet de test.
2. Réinitialisez la conversation (icône de rafraîchissement ou nouvelle discussion) pour repartir d'une base propre.
3. Ouvrez les rubriques pour voir laquelle a été déclenchée. Si c'est la rubrique de renforcement conversationnel du système plutôt que l'une des vôtres, l'agent s'est appuyé sur le modèle, pas sur vos connaissances.
4. Dans ce cas, vérifiez que votre fichier ou site a bien été téléversé et indexé : pas d'index, pas de fondement.
5. Modifiez les instructions ou le contenu du sujet, enregistrez, puis relancez exactement les mêmes requêtes.

Sauter cette boucle, c'est espérer que le dé tombera mieux la prochaine fois.

Créer un sujet à partir d'une description

Si le problème vient d'un manque de structure, la page des sujets permet d'ajouter un sujet à partir d'une description avec Copilot. Vous décrivez le besoin (par exemple répondre directement aux questions sur les plafonds de dépenses), cliquez sur Ajouter, et le système ébauche une arborescence. C'est utile quand l'agent esquive toujours la même question élémentaire.

Comparer deux tons en 10 minutes

Rédigez une variante A des instructions dans un langage formel de politique d'entreprise, enregistrez, posez une question sur le plafond des frais de déplacement et notez la réponse. Passez ensuite à une variante B, un guide RH amical qui explique simplement tout en citant les règles, et reposez la même question. Vous décidez du ton sur des preuves, avec le seul volet de test.

Traiter une réponse vague comme un retour d'information

Si, à « quels frais d'hôtel puis-je me faire rembourser ? », l'agent répond « voyez avec les RH », ce n'est pas un échec total. Le document n'est peut-être pas encore indexé, ou vos expressions déclencheuses n'incluent pas « hôtel ». Vérifiez l'onglet des connaissances, ajoutez « frais d'hôtel » comme expression déclencheuse dans votre sujet de déplacement et relancez.

Pensez aussi aux amorces de conversation : préremplissez 3 à 5 suggestions depuis la page de présentation, comme « Quel est le plafond pour l'hôtel ? », « Comment déposer une note de frais ? » ou « Quels repas sont remboursés ? ». Les utilisateurs ne se retrouvent pas devant une zone vide, et vous testez plus vite des parcours réels.

Publication et canaux : quand l'agent devient public

Publier n'est pas un simple clic. Chaque canal (Teams, SharePoint, site de démonstration) a ses particularités. Une réponse claire dans Studio peut changer d'aspect, voire échouer. Un agent qui répond correctement dans Studio peut, dans Teams, répondre « Je ne comprends pas » alors que rien n'a changé : la manière dont Teams ajuste le texte et transmet les métadonnées suffit à briser l'alignement. SharePoint gère l'espacement à sa façon, et le site de démonstration peut afficher le formatage différemment. Chaque cible est une arène distincte à tester séparément.

Checklist de publication

1. Confirmez que les fichiers de connaissances sont entièrement indexés.
2. Configurez l'authentification. Pour une démonstration large, choisissez « Aucune authentification » afin que toute personne disposant du lien puisse essayer.
3. Publiez et vérifiez la bannière de confirmation verte ou la mise à jour du statut sur la page des canaux.
4. Dans les paramètres du canal du site de démonstration, mettez à jour le message d'accueil et les annonces de conversation.
5. Lancez un pilote restreint plutôt qu'un déploiement sur tout le tenant.

Le pilote restreint

Un petit groupe, avec des consignes claires, vaut mieux qu'une diffusion complète. Demandez aux testeurs d'écrire naturellement, de faire des fautes de frappe, voire de téléverser des fichiers. Leurs erreurs révèlent les points faibles. Rejouez ensuite sur chaque canal cible vos tests : requêtes formelles, expressions familières, fautes de frappe, citations. Vérifiez comment Teams affiche les réponses, comment SharePoint modifie l'espacement, et si la démo web conserve la citation de la source.

Surveiller après la publication

Une fois l'agent en ligne, les données d'usage arrivent. Le centre d'administration Power Platform et les analyses intégrées montrent l'adoption, le nombre d'erreurs et les conversations n'ayant déclenché aucun sujet. C'est votre système de surveillance : on ne publie pas pour oublier. Considérez la publication comme une nouvelle phase de test, pas comme la fin du projet.

Les erreurs de débutant à éviter

• Se fier à la répétition dans Studio : elle donne un faux sentiment de sécurité. Un seul échec en démonstration suffit à faire disparaître la confiance.
• Tester une seule formulation : sans synonymes ni formulations informelles, l'agent reste fragile.
• Lancer un agent sans ancrage : il bluffe et risque d'inventer des règles, ce qui génère de vrais tickets de support, par exemple si des employés déposent des demandes à de mauvais montants.
• Compter sur l'amélioration conversationnelle pour combler l'absence de source.
• Laisser nom, description et instructions vides : l'agent paraît générique et inspire peu confiance.
• Ignorer les réponses ratées en espérant que la prochaine passera.
• Déployer partout d'un coup sans tester chaque canal ni suivre les journaux.

Takeaways pratiques

• Testez toujours trois variantes d'une même question : propre, décontractée, avec faute de frappe.
• Élargissez les phrases déclencheurs avec des synonymes et un langage courant.
• Ancrez l'agent dans un document ou une source fiable, et attendez la fin de l'indexation avant de retester.
• Pour les sujets sensibles, limitez l'agent à vos sources ajoutées.
• Renseignez le nom (30 caractères max.), la description et les instructions, avec règles de ton et de citation.
• Personnalisez le message d'accueil, l'icône et 3 à 5 amorces de conversation.
• Appliquez la boucle : reproduire, corriger, relancer, répéter.
• Avant de publier : indexation, authentification, bannière de confirmation, message d'accueil, pilote restreint.
• Retestez sur chaque canal et surveillez la télémétrie après la mise en ligne.

Conclusion

Un agent Copilot Studio fiable repose sur trois piliers : un ancrage dans des sources vérifiées pour qu'il cesse de deviner, une personnalité définie par son nom, sa description, son ton et ses instructions, et une validation qui ne s'arrête pas à une répétition réussie, mais passe par le volet de test, un pilote restreint, la publication et la surveillance. La création d'un agent n'est pas un travail ponctuel : c'est un système que l'on ajuste en continu, et c'est ce qui permet de gagner la confiance des utilisateurs plutôt que de générer des tickets.