Recette Dynamics 365 (UAT) : le guide pratique

Quand faire une UAT dans Dynamics 365

Un test d'acceptation utilisateur répond à une seule question : le métier peut-il faire son travail dans cette version de Dynamics 365 ? Ceux qui font le travail le testent, avec leurs propres mots, avant la mise en production. Vous en avez besoin à ces moments-là.

• Une mise en production. Le premier Dynamics 365 Sales ou Customer Service, ou une migration depuis un autre CRM.
• Une nouvelle application ou un nouveau module. Customer Service à côté de Sales, une nouvelle application pilotée par modèle pour une équipe, un portail client ou des fonctionnalités Copilot que vous activez.
• Un changement important. Une nouvelle intégration avec l'ERP, ou une nouvelle façon de router les incidents.
• Les mises à jour de Microsoft. Microsoft ne regroupe plus les changements de Dynamics 365 en deux release waves par an. Les nouvelles fonctionnalités et les changements sont déployés tout au long de l'année. Les plans de publication ont été archivés en octobre 2026 ; ce qui arrive figure désormais dans la roadmap Microsoft, sur aka.ms/AIatWorkRoadmap. Chaque mise à jour peut changer le fonctionnement de votre système, même si vous n'avez rien modifié vous-même.

Une mise en production demande une UAT complète. Les mises à jour demandent un test de régression plus court des processus les plus importants, à un rythme fixe. Pour en savoir plus, voir Après la mise en production.

Environnements

Ne testez jamais en production. Dans le Centre d'administration Power Platform, chaque environnement a un type. Pour une UAT, il vous faut un bac à sable (sandbox).

Une copie de la production

Le plus proche de la réalité, c'est une copie de la production dans un environnement sandbox. Quand vous copiez un environnement, vous choisissez ce qui est copié :

• Tout : les personnalisations, le schéma et toutes les données. Au plus près de la production, mais cela inclut de vraies données clients et chaque enregistrement créé par vos utilisateurs.
• Personnalisations et schémas uniquement : la configuration sans les données. Vous chargez ensuite vos propres données de test.

Une copie remplace le contenu de l'environnement cible : faites-la avant l'UAT, jamais pendant. Ensuite, pointez les intégrations et les flux Power Automate vers des systèmes de test, pas vers la production, vérifiez les boîtes aux lettres, et sortez l'environnement du mode Administration quand il est prêt.

Les solutions et le build

Les changements du projet arrivent dans l'environnement d'UAT sous forme de solutions. Importez-les en tant que solutions gérées, via un pipeline si vous en avez un, pour que l'environnement d'UAT reçoive exactement ce que la production recevra ensuite.

• Convenez du moment où les solutions sont importées pendant que les tests continuent, par exemple une fois par jour après le triage. Une importation au milieu d'un test peut changer l'écran sous les yeux d'un testeur.
• Notez quelles solutions et quelles versions se trouvent dans l'environnement d'UAT. Le numéro de version d'une solution est le build que vous testez, et chaque anomalie et chaque nouveau test s'y rattachent.

Données de test

Les testeurs perdent des heures quand les données ne sont pas prêtes. Préparez-les avant la première journée de test :

• Des comptes et des contacts pour chaque type de client que vous testez, avec le bon propriétaire et la bonne division.
• Des produits et des listes de prix. Un produit a besoin d'un élément de liste de prix avant de pouvoir être ajouté au bon prix, et il doit être publié avant que les commerciaux puissent l'utiliser. Vérifiez que la liste de prix de chaque équipe commerciale est présente.
• Des files d'attente, des SLA et des articles de connaissances pour Customer Service : les files d'attente vers lesquelles les incidents sont routés, des SLA actifs et des articles publiés à trouver.
• Des enregistrements ouverts sur lesquels travailler : des prospects, des opportunités à différentes phases et des incidents ouverts.
• Pas de vraies données personnelles quand vous pouvez l'éviter. Une copie avec Tout les contient toutes : masquez ou anonymisez ce que les testeurs n'ont pas besoin de voir.

Rôles de sécurité, divisions et utilisateurs par rôle

Une UAT prouve que chaque rôle peut faire son travail, et uniquement son travail. Dans Dynamics 365, cela dépend des rôles de sécurité, de la division et des équipes d'un utilisateur. Les applications sont aussi partagées par le biais des rôles de sécurité : sans le bon rôle, un utilisateur ne voit même pas l'application.

• Listez les rôles que vous testez, par exemple un commercial, un responsable commercial, un agent du service client et un superviseur du service client, avec leur division.
• Donnez à chaque testeur un utilisateur avec exactement ce rôle dans l'environnement d'UAT. Chaque utilisateur a besoin d'une licence, dans un environnement sandbox aussi.
• Quand une même personne teste plusieurs rôles, utilisez un utilisateur de test distinct par rôle, ou changez le rôle entre les tests et notez lequel a été utilisé.
• Ne testez jamais avec le rôle Administrateur système. Il voit tout et peut tout faire, et masque donc précisément les problèmes qu'une UAT doit trouver.

Ce qu'il faut dire aux testeurs sur l'environnement

• L'adresse de l'environnement d'UAT. Le favori habituel ouvre la production.
• Quelle application ouvrir, comme Hub des ventes ou Espace de travail Customer Service, et avec quel compte se connecter.
• Que les données sont des données de test : rien de ce qu'ils font n'atteint un vrai client, et rien de ce qu'ils voient n'est à jour.
• Qui appeler quand ils ne parviennent pas à se connecter ou ne voient pas l'application.

Dans UAT StudioChaque testeur reçoit un Test role, par exemple le rôle de sécurité, et un Test account, affichés en haut de ses tests sous la forme Log in as …. Les Notes for testers contiennent l'adresse de l'environnement, les boîtes mail de test et qui appeler. Les testeurs se connectent à UAT Studio avec un code reçu par email, ou avec Sign in with Microsoft.

Des cas de test à partir des user stories et des processus

Partez des processus du métier, pas des tables de Dataverse. Deux processus couvrent l'essentiel d'une UAT Dynamics 365 :

• Du prospect à l'opportunité et au devis. Un prospect arrive et est qualifié en compte, contact et opportunité. L'opportunité suit le flux des processus d'entreprise, reçoit des produits de la liste de prix, un devis est créé, approuvé et activé, puis l'affaire est gagnée et passe à l'équipe ou au système suivant.
• Gestion des incidents. Un incident arrive par email ou via le portail, est routé vers la bonne file d'attente ou le bon agent, suit son SLA, est traité avec un article de connaissances, escaladé si nécessaire, puis résolu.

Découpez chaque processus en cas de test portant chacun sur un seul scénario métier, par exemple Qualifier un prospect avec un compte existant. Vérifiez ensuite que chaque user story du périmètre a au moins un cas de test.

Flux des processus d'entreprise

Un flux des processus d'entreprise guide les utilisateurs à travers des phases, avec des étapes qui peuvent être obligatoires avant la phase suivante. Testez-le comme le fait un utilisateur :

• Chaque phase, et ce qui se passe quand une étape obligatoire est vide.
• Chaque branche, et chaque rôle : un flux peut n'être activé que pour certains rôles de sécurité.

Routage, SLA et connaissances

Dans Customer Service, une grande partie du travail se fait sans un clic. Testez ce que le système doit faire de lui-même : un email devient un incident pour le bon compte, l'incident arrive dans la bonne file d'attente, le SLA affiche la bonne durée et avertit avant son expiration, et l'agent trouve le bon article de connaissances.

Des étapes que les testeurs métier comprennent

Rédigez chaque étape comme une action et un résultat attendu, avec les mots du testeur. Ajoutez des données de test là où c'est utile. Un testeur ne doit jamais avoir à deviner si une étape a réussi.

Priorité et risque

Tous les cas de test n'ont pas la même importance. Marquez chacun Must, Should ou Could : Must, c'est ce qui doit fonctionner dès le premier jour, comme créer un devis ou router un incident. Ajoutez le risque : ce que cela coûte si cela tourne mal après la mise en production. Les testeurs commencent par Must et risque élevé, pour que les tests importants soient faits même quand le temps manque.

Ajoutez aussi les cas d'échec : un champ obligatoire laissé vide, une remise au-dessus de la limite, un utilisateur d'une autre division qui ne devrait pas voir un enregistrement.

Dans UAT StudioImportez vos cas de test depuis Excel avec les colonnes Priority et Risk, lisez-les depuis Azure DevOps Test Plans, ou partez des scripts Dynamics 365 de la bibliothèque de modèles, une option de chaque formule payante. Avec AI test design, l'IA propose des cas de test à partir de vos user stories dans Azure DevOps, y compris avec le propre modèle de votre entreprise, comme Microsoft Foundry / Azure OpenAI. Rien ne devient un cas de test tant que vous ne l'avez pas validé.

Testeurs

Choisissez des personnes qui font le travail au quotidien : des responsables de comptes, des agents du service client, et leurs managers pour les approbations, les files d'attente et les tableaux de bord. Prenez des testeurs dans chaque équipe et chaque pays qui utilise Dynamics 365, car leurs processus, leurs divisions et leurs listes de prix diffèrent.

Combien de temps

Convenez du temps par testeur avec son manager, et gardez du temps pour les nouveaux tests. Des testeurs qui continuent à prendre des appels ou à visiter des clients ne finiront pas.

Une réunion de lancement

Commencez par une courte réunion de lancement : pourquoi leur test compte, comment ouvrir l'environnement d'UAT, comment enregistrer un résultat et comment signaler une anomalie. Faites se connecter chaque testeur une fois pendant le lancement et faites-lui ouvrir l'application. La plupart des problèmes de licences, de rôles et de mauvais environnement apparaissent là, pas le jour du test.

Une journée de test ou une semaine

Une journée de test apporte de la concentration et des réponses rapides, et convient à un petit périmètre. Une semaine par blocs de quelques heures laisse de la place pour de nouveaux builds et de nouveaux tests, et convient à une mise en production avec de nombreux processus. Dans les deux cas, fixez un créneau pour le triage chaque jour.

Pendant l'UAT

Signaler les anomalies

Une bonne anomalie peut être corrigée sans réunion. Demandez aux testeurs :

• L'étape, ce qu'ils attendaient et ce qui s'est passé à la place.
• Une capture d'écran de la page, avec le message d'erreur s'il y en avait un.
• Le lien vers l'enregistrement. Il se trouve dans la barre d'adresse du navigateur et mène le consultant directement à l'opportunité ou à l'incident où le problème est survenu.
• L'utilisateur et le rôle de sécurité avec lesquels ils ont testé.

Dans UAT StudioL'extension de navigateur pour Chrome et Edge affiche les tests dans un panneau latéral à côté de Dynamics 365. Une étape en échec emporte la capture d'écran, le lien vers l'enregistrement et les messages d'erreur de la page. Le rôle du testeur est affiché à côté de son nom sur l'anomalie.

Triage

Passez en revue les nouvelles anomalies chaque jour, avec le métier et l'équipe Dynamics 365 ensemble. Donnez à chacune une gravité et une personne qui la corrige, et décidez :

• Corriger : un vrai problème, corrigé dans cette release.
• Rejeter : Dynamics 365 fonctionne comme prévu, ou le test était erroné.
• Demande d'évolution : un souhait, pas un défaut. Elle va dans le backlog, pas dans cette release.

Envoyez les anomalies à corriger aux développeurs, souvent dans Azure DevOps, avec la capture d'écran et le lien vers l'enregistrement.

Nouveau test

Quand le correctif se trouve dans un nouveau build de l'environnement d'UAT, le testeur qui a trouvé l'anomalie teste à nouveau l'étape. Notez sur quel build chaque nouveau test a été fait. Après un correctif important, testez aussi à nouveau les processus autour.

Statut quotidien

Envoyez chaque jour au comité de pilotage un court statut : l'avancement par rapport au plan, les anomalies ouvertes par gravité et ce qui bloque. Pas de surprises à la réunion go/no-go.

Dans UAT StudioLe triage se fait sur un écran partagé avec Fix, Reject et Change request. Une anomalie devient un work item Bug dans Azure DevOps ; quand il y est terminé, l'anomalie passe en Ready for retest et le testeur reçoit un email. Chaque cycle conserve sa version, son build et son environnement. Les nouvelles anomalies, les cycles et les validations arrivent dans un canal Microsoft Teams.

Validation et go/no-go

L'UAT se termine par une décision du métier. Convenez des critères de sortie avant la première journée de test, pour que personne n'en discute à la fin :

• Aucune anomalie Critical n'est ouverte.
• Chaque cas de test Must est réussi.
• Chaque anomalie High ouverte a un contournement ou une date de correction que le métier accepte.
• Chaque cas de test du périmètre a un résultat.

Qui valide

Le responsable de chaque processus valide, par exemple le directeur commercial pour le parcours du prospect au devis et le responsable du service client pour la gestion des incidents. Il choisit : accepté, accepté sous conditions ou rejeté. Notez chaque condition, avec qui s'en charge et pour quand. Le comité de pilotage décide ensuite de la mise en production.

Ce que contient le rapport

• Ce qui faisait partie du périmètre, et ce qui n'a pas été testé.
• Les résultats par processus ou par équipe, et par priorité.
• L'environnement, les solutions et le build testés.
• Les anomalies ouvertes par gravité, avec la décision pour chacune.
• Les validations, avec leurs conditions, et les risques connus pour les premières semaines.

Dans UAT StudioValidation par groupe : Accepted, Accepted with conditions ou Rejected. Par défaut, personne ne peut accepter tant qu'une anomalie Critical est ouverte. Le rapport go/no-go est prêt en PDF ou en diapositives dès que le dernier résultat est saisi.

Des cycles de régression à un rythme fixe

Après la mise en production, les mises à jour continuent d'arriver, toute l'année, et chacune peut changer un formulaire, un flux ou une autorisation. Vos cas de test d'UAT sont le meilleur test de régression dont vous disposez : ils décrivent exactement ce que le métier a accepté.

• Choisissez un rythme, par exemple un cycle de régression chaque mois ou chaque trimestre, et inscrivez dès maintenant les dates dans l'agenda des testeurs.
• Avant chaque cycle, lisez la roadmap Microsoft et les messages destinés à vos administrateurs, et notez quels changements touchent vos processus.
• Essayez d'abord les fonctionnalités en préversion ou en accès anticipé dans un environnement sandbox, avant qu'elles n'atteignent vos utilisateurs.
• Testez à nouveau les cas de test Must, et Should s'il reste du temps, avec quelques testeurs du métier.
• Enregistrez les anomalies comme pendant l'UAT, et corrigez-les avant que le changement n'atteigne vos utilisateurs.

Dans UAT StudioChoisissez Dynamics 365 comme CRM du projet. Start a regression round copie les cas de test choisis d'une UAT précédente, avec leurs étapes, leurs données de test et leurs résultats attendus : Must and Should, Only Must ou All test cases in scope.

Libre d'utilisation

Pour tout ce qu'il faut organiser avant, pendant et après l'UAT, voir la checklist UAT pour une mise en production CRM, également en fichier Excel gratuit. Pour ce que UAT Studio apporte à une UAT Dynamics 365, voir UAT Dynamics 365.

Microsoft, Dynamics 365, Power Platform, Azure DevOps et Microsoft Teams sont des marques du groupe de sociétés Microsoft. UAT Studio n'est ni affilié à Microsoft ni approuvé par Microsoft.