Mettre en œuvre Dynamics 365 Contact Center : canaux, routage et déploiement

Pourquoi les projets de centre de contact sont différents

La plupart des projets Dynamics 365 que je mène portent sur des données, des processus et des formulaires. Un projet de centre de contact y ajoute trois éléments qui changent le rythme du travail : la téléphonie, le routage en temps réel et des collaborateurs dont l'activité se mesure à la minute. Lorsqu'un chat arrive dans la mauvaise équipe ou qu'un appel attend dans une file à laquelle personne n'est abonné, le client s'en aperçoit immédiatement. C'est ce qui fait de Dynamics 365 Contact Center l'une des mises en œuvre les plus gratifiantes quand elle est réussie, et l'une des moins indulgentes quand elle ne l'est pas.

Cet article décrit ma façon d'aborder une mise en œuvre de Contact Center : choisir le bon modèle de déploiement, mettre en place les canaux vocaux et numériques, concevoir le routage unifié, préparer l'espace de travail des conseillers et Copilot, puis déployer par phases. Commencez par la présentation officielle de Dynamics 365 Contact Center.

Embedded, standalone ou Customer Service : décidez d'abord

Microsoft documente Dynamics 365 Contact Center en deux variantes, et la plupart des articles de configuration précisent explicitement à laquelle ils s'appliquent. C'est la première décision à prendre, car elle détermine où se trouvent vos données de dossiers et quelle application vos conseillers ouvrent le matin.

• Contact Center – embedded : le widget de conversation est intégré dans un CRM non Microsoft comme Salesforce ou ServiceNow, et des connecteurs synchronisent les contacts et les comptes. Cette option convient aux organisations qui veulent le routage, la voix et l'IA de Microsoft tout en conservant leur gestion des dossiers dans un autre CRM. Microsoft documente aussi une troisième variante : Dynamics 365 Customer Service, où les canaux, le routage et Copilot fonctionnent au sein de Customer Service ; si vous l'utilisez déjà, c'est presque toujours le choix naturel.
• Contact Center – standalone : Copilot Service workspace fonctionne comme une application à part entière sur Dataverse, sans la gestion des dossiers de Customer Service. Pour les autres CRM, Microsoft fournit des connecteurs pour Salesforce et ServiceNow, ainsi qu'un connecteur pour tout autre CRM.

Ne sous-estimez pas l'effort d'intégration avec un CRM externe (mode embedded). L'identification des clients, la recherche d'enregistrements et la réécriture de l'historique des interactions dans le CRM externe relèvent de l'intégration, avec leurs propres tests, leur sécurité et leur modèle de support. Budgétez-les comme tels.

Venir d'Omnichannel for Customer Service

Si vous avez mis en œuvre Omnichannel for Customer Service ces dernières années, une grande partie de Contact Center vous semblera familière. La documentation de Microsoft présente désormais les fonctionnalités de canaux et de routage de Customer Service sous le nom Contact Center : la page « Introduction à Dynamics 365 Contact Center » se trouve à l'URL qui décrivait autrefois Omnichannel, et ce sont les mêmes routage unifié, flux de travail (workstreams), files d'attente et profils de capacité qui sous-tendent les deux. Pour la plupart des clients existants, il s'agit donc d'une évolution du produit et des licences, pas d'une reconstruction à partir de zéro.

Ce qu'il faut examiner dans un environnement Omnichannel existant

• Applications utilisées : les conseillers doivent utiliser Copilot Service workspace pour recevoir du travail via le routage unifié. Les copies personnalisées de l'application workspace et Unified Service Desk ne sont pas prises en charge à cet effet ; planifiez la transition si vous les utilisez encore.
• Ancien routage : si vous routez encore les incidents avec des règles de routage de base ou des workflows personnalisés, passez au routage des enregistrements (record routing) du routage unifié, afin que les incidents et les conversations partagent un seul modèle d'attribution.
• Workstreams vocaux et bots : Microsoft documente un chemin de migration pour rendre les workstreams vocaux existants compatibles avec les agents Copilot Studio vocaux plus récents. Consultez-le avant de reconstruire votre SVI.
• Personnalisations : inventoriez les modèles de session, les modèles de notification, les macros et les scripts du volet de productivité. En général, ils suivent, mais ce sont aussi les premiers éléments à casser lorsque vous changez d'application.

Canaux vocaux et numériques

Les canaux sont provisionnés dans Copilot Service admin center, sous Customer Support > Channels. Les cases que vous pouvez cocher dépendent de vos licences. Les familles de canaux disponibles sont le chat, la voix, le SMS, la messagerie sociale et Microsoft Teams.

Voix

Le canal vocal repose sur Azure Communication Services et offre aux conseillers des appels RTC entrants et sortants dans l'espace de travail, avec contrôles d'appel, transferts, consultations, messagerie vocale, transcription en direct et analyse des sentiments. Le SVI est un agent Copilot Studio rattaché au workstream vocal, construit avec les mêmes outils qu'un chatbot.

C'est dans la téléphonie que se trouvent les dépendances externes. Seuls les numéros américains peuvent être achetés directement dans le centre d'administration ; pour les autres pays, vous les achetez dans Azure Communication Services et les synchronisez, ou vous apportez votre propre opérateur via le routage direct Azure. Décidez-le tôt et impliquez la personne qui gère aujourd'hui vos numéros. Porter des numéros belges et coordonner une bascule avec l'ancienne plateforme prend un temps calendaire qu'aucune configuration ne peut raccourcir.

Canaux numériques

Les canaux numériques se mettent en place plus rapidement, mais chacun a son propre comportement, qui influence la conception du routage :

• Live chat : un widget sur votre site web ou portail, avec des questions avant chat qui alimentent le routage (langue, sujet, client connecté). Le chat persistant permet de poursuivre une conversation sur plusieurs sessions.
• SMS : asynchrone par nature. Les clients répondent des heures plus tard ; la conversation passe donc en attente et revient dans la file en fonction de l'heure de la dernière interaction.
• Réseaux sociaux et WhatsApp : également asynchrones, avec les règles propres au fournisseur en matière de modèles et de délais de réponse. Convenez avec le marketing et le service juridique de qui est propriétaire de ces comptes avant de les connecter.
• Microsoft Teams : utile pour les services d'assistance internes, comme le support IT ou RH, où les « clients » sont vos propres collaborateurs.

Concevoir le routage unifié

Le routage unifié est le cœur du produit et mérite l'essentiel de votre temps de conception. Il fonctionne en deux étapes : la classification enrichit l'élément de travail entrant (compétences, priorité, segment client, langue) et l'attribution sélectionne le conseiller le plus adapté en fonction des compétences, de la présence et de la capacité. Lisez la présentation du routage unifié puis concevez sur papier avant de cliquer quoi que ce soit. Les briques de base sont :

• Workstream : le conteneur par canal et par type de travail, avec les présences autorisées, les exigences de capacité et le mode de distribution (push ou pick).
• File d'attente : le groupe de conseillers pouvant traiter un type de travail, avec une méthode d'attribution et un calendrier d'heures d'ouverture.
• Règles de classification : des conditions sur l'élément de travail et les enregistrements liés, qui définissent compétences, priorité ou autres attributs avant le routage.
• Règles route-to-queue : un ensemble ordonné de règles qui envoie l'élément vers la bonne file. Prévoyez toujours une file de repli réellement surveillée.
• Profils de capacité : la quantité de travail simultané ou journalier qu'un conseiller peut prendre par type, et si un appel téléphonique bloque les autres canaux. Microsoft recommande d'utiliser soit les profils de capacité, soit les unités de capacité, mais pas les deux.
• Présence : Disponible, Occupé, Ne pas déranger et statuts personnalisés. Chaque workstream définit les présences qui peuvent encore recevoir du travail.

Choisir une méthode d'attribution

Chaque file reçoit une méthode d'attribution. Les options intégrées couvrent la plupart des besoins ; sinon, vous pouvez définir vos propres ensembles de règles de priorisation et d'attribution. La documentation sur les méthodes d'attribution détaille la logique exacte en cas d'égalité. En pratique :

L'espace de travail du conseiller

Les conseillers travaillent dans Copilot Service workspace, une application multisession où chaque conversation acceptée ou incident ouvert devient une session, avec ses propres onglets. Microsoft documente une limite de neuf sessions et de dix onglets par session, ce qui dépasse déjà ce qu'un conseiller devrait gérer en même temps.

L'essentiel de l'expérience utilisateur se configure au lieu de se développer :

• Modèles de session : définissent la page qui s'ouvre à l'acceptation d'une conversation, par exemple le profil client avec l'incident actif à côté.
• Modèles de notification : déterminent ce que le conseiller voit dans la notification de travail entrant, y compris les réponses avant chat et le nom du client.
• Identification du client : des règles d'identification d'enregistrement associent automatiquement la conversation à un contact ou à un compte, pour que le conseiller ne commence pas par une recherche.
• Macros et scripts : les agent scripts guident les conseillers dans les conversations réglementées ou complexes, et les macros automatisent les étapes répétitives comme la création d'un incident à partir de la conversation.

L'assistance Copilot pour les conseillers

C'est avec Copilot que Contact Center se distingue le plus de ce qu'offrait Omnichannel il y a quelques années. Parmi les fonctionnalités activables dans Copilot Service admin center :

• Résumés de conversations et d'incidents : un résumé de la conversation lors d'un transfert ou de la clôture (et des résumés de dossiers si vous utilisez Dynamics 365 Customer Service), pour que le conseiller suivant ne demande pas au client de tout répéter.
• Ask a question : les conseillers interrogent Copilot dans le volet d'aide et obtiennent des réponses fondées sur vos sources de connaissances.
• Rédaction de réponses et d'e-mails : des propositions de réponses de chat et d'e-mails que le conseiller relit et adapte avant l'envoi.
• Traduction : les conseillers peuvent traduire les réponses générées par Copilot dans leur langue préférée, ce qui est utile dans un pays multilingue comme la Belgique.

La qualité de ces fonctionnalités est limitée par celle de votre base de connaissances. Si vos articles sont obsolètes, en double ou rédigés pour des experts internes, Copilot le répétera avec assurance. Prévoyez un nettoyage de la base de connaissances dans le projet et utilisez les filtres prédéfinis et les filtres des conseillers (les filtres de connaissances sont une fonctionnalité de Dynamics 365 Customer Service), afin que Copilot s'appuie sur les bons articles pour chaque produit ou marque.

Enregistrement, vie privée et spécificités européennes

L'enregistrement et la transcription des appels se configurent par workstream vocal, avec un démarrage automatique ou manuel et la possibilité de mettre en pause et de reprendre. Microsoft indique explicitement que de nombreuses juridictions encadrent l'enregistrement des appels et peuvent exiger un consentement, et que la conformité relève de votre responsabilité. Lisez les recommandations sur l'enregistrement, la transcription et la traduction en temps réel des appels puis prenez les décisions juridiques avant les décisions techniques. Pour les organisations belges et européennes, je vérifie au minimum les points suivants avec l'équipe juridique ou vie privée du client :

• Base légale et information : comment les appelants sont informés de l'enregistrement et de la transcription, et ce que le SVI annonce avant qu'un conseiller ne décroche.
• Conservation : combien de temps les enregistrements, transcriptions et conversations sont conservés, et comment ils sont supprimés à l'échéance.
• Résidence des données : dans quelle région l'environnement et les ressources des canaux sont hébergés, et si une fonctionnalité activée déplace des données hors de cette région.
• Suivi des collaborateurs : la supervision, les analyses et les enregistrements concernent aussi votre propre personnel. Microsoft précise que les fonctionnalités de capacité et de performance ne sont pas destinées à des décisions relatives à l'emploi ; impliquez tôt les RH et, le cas échéant, les représentants du personnel.

Rapports sur les conversations

Contact Center inclut des tableaux de bord d'analyse en temps réel et historiques pour les superviseurs, et c'est par là qu'il faut commencer. Pour des vérifications ponctuelles pendant les tests, j'interroge directement la table Conversation (msdyn_ocliveworkitem). Cette requête FetchXML compte les conversations vocales de la semaine écoulée par file et par raison de statut :

<fetch aggregate="true">
  <entity name="msdyn_ocliveworkitem">
    <attribute name="activityid" alias="conversations" aggregate="count" />
    <attribute name="msdyn_cdsqueueid" alias="queue" groupby="true" />
    <attribute name="statuscode" alias="status" groupby="true" />
    <filter>
      <condition attribute="createdon" operator="last-x-days" value="7" />
      <!-- msdyn_channel is a multi-select choice; 192440000 = Voice call (PSTN voice channel) -->
      <condition attribute="msdyn_channel" operator="contain-values">
        <value>192440000</value>
      </condition>
    </filter>
  </entity>
</fetch>

Pendant les tests d'acceptation, une telle requête montre rapidement si du travail aboutit dans la file de repli ou reste plus longtemps que prévu au statut Open, ce qui révèle généralement un problème de règle de routage ou de configuration des présences.

ALM pour la configuration de Contact Center

La configuration du routage n'est pas une simple personnalisation dans une solution, et c'est là que beaucoup de projets perdent du temps. Les workstreams et les paramètres de canaux peuvent voyager dans des solutions, mais les files d'attente, les profils de capacité et les ensembles de règles de routage par compétences nécessitent le Configuration Migration tool, dans un ordre précis. Suivez le guide de Microsoft pour migrer les configurations de canaux à l'aide de solutions et scriptez-le, afin que chaque environnement soit construit de la même manière :

# 1. Routing configuration data (queues, capacity profiles,
#    skill-based routing rulesets) via the Configuration Migration tool.
#    The schema files are created once with the Configuration Migration tool.
#    pac data runs only in the Windows (.NET Framework) build of the PAC CLI.
pac auth create --name dev --environment https://contoso-dev.crm4.dynamics.com
pac data export --schemaFile .\config\queues-schema.xml --dataFile .\out\queues.zip --overwrite

pac auth create --name test --environment https://contoso-test.crm4.dynamics.com
pac data import --data .\out\queues.zip

# 2. Workstreams and channel settings via a solution
pac auth select --name dev
pac solution export --name ContosoContactCenter --path .\out\ContosoContactCenter.zip --managed

pac auth select --name test
pac solution import --path .\out\ContosoContactCenter.zip

Notez que les paramètres de compte, de fournisseur de canal, de configuration des agents et d'IA et d'analyse sont hors du périmètre de cette migration. Les enregistrements de numéros de téléphone voyagent avec la solution, mais la connexion Azure Communication Services, la synchronisation des numéros et la configuration des agents doivent être refaites. Documentez-les dans un runbook et configurez-les par environnement. Pour les données de configuration, respectez l'ordre documenté : modèles de session et de notification, ensembles de règles, profils de capacité, puis files d'attente ; l'étape des flux de travail nécessite aussi l'outil de migration de configuration pour les réponses rapides, les balises et les messages système. Enfin, pac data n'est disponible que dans la version .NET Framework (Windows) de PAC CLI.

Un plan de déploiement par phases

Je ne recommande jamais une mise en production « big bang » pour un centre de contact. Voici l'enchaînement que je propose généralement :

1. Analyse et conception : cartographier les motifs de contact, les volumes par canal, les heures d'ouverture, les langues et les compétences ; choisir entre embedded, standalone et Customer Service ; arrêter la position juridique sur l'enregistrement et l'IA.
2. Fondations : environnements, rôles de sécurité, provisionnement des canaux, planification de la téléphonie et des numéros, et scripts ALM pour la configuration du routage.
3. Premier canal avec une équipe pilote : généralement le live chat ou le routage des incidents, car l'impact d'une erreur y est moindre que sur la voix.
4. Voix : agent SVI, files vocales, paramètres d'enregistrement et bascule des numéros soigneusement planifiée, idéalement en dehors des périodes de pointe.
5. Fonctionnalités Copilot : activer les résumés et Ask a question pour l'équipe pilote, évaluer la qualité des connaissances, puis étendre.
6. Montée en charge et optimisation : ajouter des équipes et des canaux, ajuster les méthodes d'attribution et la capacité sur la base des rapports réels, et transférer à une équipe de support qui maîtrise le routage.

Pièges fréquents

• Trop de files dès le premier jour : chaque file a besoin de membres, d'un calendrier, d'une gestion du débordement et de quelqu'un qui suit ses rapports.
• Pas de file de repli : les éléments de travail qui ne correspondent à aucune règle doivent aboutir dans un endroit visible, et non disparaître dans une file à laquelle personne n'est abonné.
• Discipline de présence : le routage ne vaut que par la présence des conseillers. Formez-les, et configurez ce qui se passe lorsqu'un travail est refusé ou expire.
• Ne tester que le scénario idéal : testez les transferts, les consultations, le comportement hors heures d'ouverture, les clients qui abandonnent et les conseillers qui se déconnectent en pleine conversation.
• Configuration manuelle par environnement : des files construites à la main en test et en production divergent en quelques semaines. Scriptez la migration dès le départ.
• Oublier les superviseurs : les superviseurs ont besoin de tableaux de bord, de supervision et du pouvoir de réattribuer le travail. Impliquez-les dans la conception, pas seulement dans la formation.

Conclusion

Dynamics 365 Contact Center réunit la voix, les canaux numériques, le routage unifié et Copilot sur la plateforme Dataverse que beaucoup d'entre nous connaissent déjà. La technologie est mûre ; la réussite dépend d'un modèle de routage clair, d'un plan de téléphonie réaliste, d'une ALM solide et d'un déploiement par phases qui laisse l'usage réel façonner la configuration. Si vous maîtrisez ces éléments, vos conseillers passeront leur temps à aider les clients plutôt qu'à lutter contre l'outil.