Copilot et agents dans Dynamics 365 Customer Engagement

Copilot dans Customer Engagement : bien plus qu'un interrupteur

Presque chaque projet Dynamics 365 Customer Engagement que je démarre aujourd'hui commence par la même question du métier : « Que peut faire Copilot pour nous ? » La réponse honnête, c'est que tout dépend du Copilot dont on parle. Certaines fonctionnalités s'activent en un après-midi dans un centre d'administration ; d'autres sont des agents que vous concevez, testez et maintenez comme n'importe quel autre composant de votre solution.

Dans cet article, je décris ma façon d'aborder Copilot et les agents dans les projets CE : ce que les fonctionnalités intégrées de Sales et de Customer Service vous apportent, comment créer des agents Copilot Studio qui s'appuient sur vos propres données Dataverse, comment gouverner l'ensemble, et où placer la frontière entre configurer et développer.

Trois niveaux à bien distinguer

Avant chaque atelier, je m'assure que tout le monde autour de la table utilise le même vocabulaire. En pratique, il existe trois niveaux :

• Copilot intégré aux applications : résumés d'enregistrements, rédaction d'e-mails et préparation de rendez-vous dans Sales ; réponses, brouillons de réponse et résumés dans Customer Service. Ce sont des fonctionnalités natives de Microsoft que vous activez et ajustez, sans les développer.
• Agents fournis par Microsoft : des agents prêts à l'emploi que Microsoft livre pour les scénarios de vente et de service, de plus en plus accessibles dans Microsoft 365 Copilot comme dans les applications Dynamics 365. Vous configurez leurs sources de données et leurs autorisations, mais leur logique ne vous appartient pas.
• Agents personnalisés dans Copilot Studio : des agents que vous concevez vous-même, avec vos propres instructions, sources de connaissances, outils et rubriques. Ce sont des composants de solution qui ont leur place dans votre processus ALM.

La plupart des déceptions autour de Copilot viennent d'une confusion entre ces niveaux : attendre d'un simple interrupteur qu'il comprenne un modèle de données personnalisé, ou développer un agent sur mesure pour quelque chose que le produit fait déjà très bien.

Copilot dans Dynamics 365 Sales

Copilot dans Sales est un assistant de conversation et de synthèse intégré à l'application Sales. Il résume les prospects, les opportunités et les comptes, met en évidence les modifications récentes des enregistrements, aide les commerciaux à préparer leurs rendez-vous, rédige des e-mails et peut répondre à des questions à partir de documents SharePoint. Microsoft décrit l'ensemble des fonctionnalités dans la présentation de Copilot dans Dynamics 365 Sales.

Ce qui fait la différence

• Des données propres et complètes : le résumé d'une opportunité sans description, sans activités et sans interlocuteurs n'est qu'un résumé vide, simplement mieux rédigé.
• Des colonnes personnalisées dans les résumés : vérifiez quels champs sont utilisés pour les résumés de prospects et d'opportunités (de 4 à 15 champs pour les résumés, 10 au maximum pour les modifications récentes) et ajoutez les colonnes personnalisées sur lesquelles vos commerciaux s'appuient réellement ; ce paramétrage est à refaire dans la configuration de l'agent Sales.
• De la discipline dans les activités : la préparation des rendez-vous et les synthèses des modifications récentes ne reflètent que ce qui se trouve dans Dataverse. Si les e-mails et rendez-vous ne sont pas suivis, Copilot ne peut pas les voir.
• Le modèle de sécurité : Copilot ne lit que les enregistrements et fichiers auxquels l'utilisateur connecté a accès ; une structure de business units et d'équipes bien conçue est donc automatiquement respectée.

Microsoft présente par ailleurs l'agent Sales dans Microsoft 365 Copilot comme l'évolution de cette expérience, afin que les commerciaux qui travaillent surtout dans Outlook et Teams y retrouvent le même contexte CRM. Consultez la documentation à jour pour votre tenant avant de bâtir vos supports de formation autour d'un point d'accès précis.

Copilot dans Customer Service et Contact Center

Pour les équipes de service, les fonctionnalités les plus utiles sont généralement le volet d'aide Copilot (poser une question, rédiger une réponse, composer un e-mail) et les résumés de conversations et de dossiers. La configuration se fait dans le Copilot Service admin center, y compris les filtres (prédéfinis, des agents et automatiques, cinq au maximum par catégorie) qui déterminent quels articles de connaissances Copilot utilise. Voir Configurer les fonctionnalités Copilot dans le volet d'aide.

Votre base de connaissances est le vrai projet

La qualité des réponses du volet d'aide dépend en grande partie des sources de connaissances qui l'alimentent. Dans les projets de service, je prévois du temps pour :

• Le nettoyage des articles : archivez les articles obsolètes, supprimez les doublons et veillez à ce que chaque article réponde clairement à une seule question.
• Les métadonnées pour les filtres : étiquetez les articles par produit, langue ou région afin que les filtres prédéfinis, des agents et automatiques puissent restreindre les réponses au bon contexte.
• La couverture linguistique : pour les service desks belges qui travaillent en néerlandais, en français et en anglais, décidez dans quelles langues vous maintenez vos articles, et testez Copilot dans chacune d'elles.
• La boucle de retour : utilisez les pouces levés et baissés des agents pour repérer les articles à retravailler.

Créer des agents Copilot Studio sur Dataverse

Lorsque les fonctionnalités intégrées ne suffisent pas, par exemple pour un agent interne qui répond à des questions sur des contrats, un parc installé ou des accords de niveau de service stockés dans des tables personnalisées, Copilot Studio est l'outil adapté. Les tables Dataverse peuvent être ajoutées directement comme source de connaissances ; Microsoft décrit la procédure dans Ajouter des tables Dataverse comme source de connaissances.

Des prérequis faciles à oublier

1. La recherche Dataverse doit être activée dans l'environnement, et les tables et colonnes que vous souhaitez utiliser doivent faire partie de l'index de recherche.
2. L'agent doit utiliser l'option « Authenticate with Microsoft ». Les agents sans authentification ou avec authentification manuelle ne peuvent pas utiliser les connaissances Dataverse, ce qui signifie aussi que les données sont récupérées dans le contexte de l'utilisateur connecté.
3. Une seule source de connaissances Dataverse peut contenir jusqu'à 15 tables : regroupez donc les tables par domaine métier plutôt que de tout ajouter d'un coup.
4. Le créateur doit avoir accès aux données sous-jacentes : les tables qu'il ne peut pas lire n'apparaissent pas lors de la configuration.

Apprenez votre modèle de données à l'agent

Les tables personnalisées comportent des préfixes d'éditeur, des noms de colonnes techniques et des valeurs de choix qui ne signifient rien pour un modèle de langage. Copilot Studio permet d'ajouter des synonymes pour les colonnes et des termes de glossaire pour le vocabulaire métier. Avec des instructions claires pour l'agent, c'est là que se joue l'essentiel de la qualité des réponses. Voici un exemple simplifié de ce que j'écris pour un agent dédié aux contrats de service :

# Agent instructions (excerpt)
You help account managers answer questions about service contracts.
Only use the Dataverse knowledge source "Service contracts".
If a question is about pricing or legal terms, say you cannot answer
and suggest contacting the contract manager.
Always mention the contract number when you refer to a contract.
Answer in the language the user writes in (Dutch, French or English).

# Column synonyms
crx_contractnumber   -> contract number, contract reference, contract id
crx_enddate          -> end date, expiry date, renewal date
crx_slalevel         -> SLA, service level, support level

# Glossary terms
active contract      -> a crx_servicecontract row where statecode is Active
                        and crx_enddate is today or later
expiring contract    -> an active contract with crx_enddate within 90 days
key account          -> an account where crx_accounttier is "Key"

Des actions, pas seulement des réponses

Un agent qui répond à des questions est utile ; un agent qui peut aussi agir apporte une vraie valeur ajoutée. Les outils permettent à l'agent d'appeler des actions de connecteur ou des agent flows, par exemple pour créer un dossier ou mettre à jour un enregistrement. Mes règles de base :

• Réutiliser la logique côté serveur : si une règle métier existe déjà dans un plugin ou une API personnalisée Dataverse, appelez-la via le connecteur Dataverse au lieu de la réécrire dans un flux.
• Limiter la portée des actions d'écriture : proposez « créer une tâche de suivi pour ce compte » plutôt qu'un outil générique « mettre à jour n'importe quel enregistrement ».
• Confirmer avant d'écrire : faites résumer par l'agent ce qu'il s'apprête à modifier et demandez la confirmation de l'utilisateur.
• Rendre l'activité des agents traçable : veillez à ce que les enregistrements créés par des agents soient identifiables, par exemple via une colonne d'origine, afin de pouvoir les auditer et en faire le reporting.

Configurer ou développer ?

Voici le tableau que j'utilise avec mes clients pour décider où investir les efforts :

Gouvernance : décidez avant de développer

Stratégies de données

Les agents Copilot Studio sont régis par les stratégies de données de Power Platform (data policies, anciennement stratégies DLP), et leur application concerne tous les tenants. Vous classez les connecteurs Copilot Studio en business, non-business ou bloqués. Voir Configurer les stratégies de données pour les agents.

• Exigez l'authentification des utilisateurs pour les agents, sauf si vous publiez délibérément un agent public sur votre site web.
• Bloquez les requêtes HTTP et les connecteurs non approuvés en tant qu'outils dans les environnements à usage général.
• Limitez, par environnement, les canaux sur lesquels les agents peuvent être publiés.
• Utilisez un environnement distinct et strictement gouverné pour les agents destinés aux clients.

Environnements gérés

Je recommande de configurer en environnements gérés (managed environments) les environnements CE de production qui hébergent des agents. Ils ajoutent des contrôles de gouvernance tels que des limites de partage, l'application obligatoire du solution checker et des informations d'utilisation, et facilitent l'application de règles cohérentes via des groupes d'environnements plutôt qu'environnement par environnement.

Résidence des données pour les clients européens

Pour les environnements hébergés en Europe, Microsoft indique que les fonctionnalités d'IA générative utilisent un point de terminaison Azure OpenAI situé dans l'EU Data Boundary. Certaines fonctionnalités, comme la recherche web via Bing, traitent les données hors de la région et exigent qu'un administrateur autorise le déplacement des données entre régions dans le centre d'administration Power Platform. Depuis mars 2026, les environnements européens affichent aussi l'option « Allow flex routing during periods of peak load » (activée par défaut pour les nouveaux locataires), des consentements distincts pour la recherche Bing et les services Microsoft 365, ainsi qu'une règle de groupe d'environnements « Generative AI settings ». Lisez Déplacer des données entre régions pour les Copilots et les fonctionnalités d'IA générative.

Les rôles de sécurité s'appliquent toujours

Copilot dans les applications comme les connaissances Dataverse des agents authentifiés fonctionnent dans le contexte de l'utilisateur connecté. C'est une bonne nouvelle, mais cela signifie aussi que Copilot fera remonter chaque enregistrement qu'un utilisateur peut techniquement lire. Si votre modèle de sécurité est trop permissif aujourd'hui, un agent le rendra visible très rapidement. Passez en revue les privilèges de lecture larges au niveau de l'organisation avant le déploiement, pas après.

Les agents ont leur place dans des solutions

Créez les agents dans une solution personnalisée dès le premier jour, avec des références de connexion et des variables d'environnement pour tout ce qui varie d'un environnement à l'autre. Vous pourrez ainsi les déplacer avec le même pipeline que le reste de vos personnalisations CE. Après l'import, reconfigurez l'authentification des utilisateurs et republiez l'agent : l'icône et les paramètres de canaux ne sont pas transportés. Voir Exporter et importer des agents à l'aide de solutions.

Avec Power Platform CLI, le déploiement d'un agent se fait exactement comme celui de n'importe quelle autre solution :

# Export the solution that contains the agent from Dev (as managed)
pac auth create --name CRX-Dev --environment https://yourorg-dev.crm4.dynamics.com
pac solution export --name ServiceContractAgent --path ./out/ServiceContractAgent_managed.zip --managed

# Generate a settings file for connection references and environment variables
pac solution create-settings --solution-zip ./out/ServiceContractAgent_managed.zip --settings-file ./deploy/test.settings.json

# Import into Test with environment-specific values
pac auth create --name CRX-Test --environment https://yourorg-test.crm4.dynamics.com
pac solution import --path ./out/ServiceContractAgent_managed.zip --settings-file ./deploy/test.settings.json

Leçons tirées du terrain

• Partir de la technologie : commencez par deux ou trois cas d'usage concrets et des critères de réussite, pas par « activons Copilot ».
• Sous-estimer le travail de contenu : les articles de connaissances, les descriptions et les termes de glossaire demandent plus de temps que la configuration de l'agent elle-même.
• Ne tester que dans une seule langue : un agent qui répond bien en anglais peut se comporter différemment en néerlandais ou en français. Testez avec de vraies questions de vrais utilisateurs dans chaque langue.
• Créer des agents dans l'environnement par défaut : les agents qui y sont créés sont difficiles à gouverner et à déplacer. Utilisez des environnements de développement dédiés et des solutions.
• Ignorer la capacité : les index de recherche Dataverse et l'utilisation des agents consomment de la capacité. Convenez du suivi et des responsabilités avant la mise en production.
• Aucun responsable après la mise en production : un agent a besoin de quelqu'un qui analyse chaque mois les statistiques, les questions sans réponse et les retours des utilisateurs.

Conclusion

Copilot dans Dynamics 365 Customer Engagement n'est pas une fonctionnalité unique mais un ensemble de couches : une assistance intégrée que vous configurez, des agents Microsoft que vous connectez, et des agents Copilot Studio sur mesure que vous développez et dont vous êtes responsable. Commencez par les fonctionnalités intégrées, investissez dans la qualité des données et des connaissances, ne développez des agents sur mesure que là où votre modèle de données ou vos processus l'exigent, et mettez en place la gouvernance, la résidence des données et l'ALM avant que le premier agent n'arrive en production. Abordés ainsi, les agents deviennent un élément fiable de votre solution CE plutôt qu'une expérimentation.