Copilot dans Dynamics 365 et SAP : ce que le Product Owner doit cadrer avant l’activation

Sommaire

• Introduction : l’IA qui manage déjà le dernier kilomètre de votre ERP
• La vague 2026 : ce que Microsoft déploie réellement dans Dynamics 365
• Joule rencontre Copilot : la fin du problème des deux assistants
• Le grand écart : ROI à trois chiffres, confiance négative
• Ce que Copilot révèle (et ne crée pas) : le vrai risque de gouvernance
• Business Central : quand un agent Anthropic traite vos notes de frais
• Le vrai travail du Product Owner face à ces agents
• Une méthode de cadrage en cinq points, testée sur le terrain
• Trois erreurs de cadrage qui coûtent cher
• Conclusion : la techno est prête, la gouvernance rarement
• FAQ
• Regard d’expert
• Passons à l’action
• Références

Introduction : l’IA qui manage déjà le dernier kilomètre de votre ERP

En mars 2026, Microsoft a publié son calendrier de la « 2026 release wave 1 » pour Dynamics 365, Power Platform et les Copilot par rôle : un ensemble de fonctionnalités déployées entre avril et septembre 2026, couvrant les ventes, le service, la finance, la supply chain, les ressources humaines et le commerce. Le message central tient en une phrase de Microsoft lui-même : l’innovation ne se produit plus deux fois par an, elle est désormais continue.

Pour un DSI ou un directeur financier qui pilote un environnement Dynamics 365 ou SAP, cette continuité n’est pas une bonne nouvelle en soi. C’est une pression permanente : chaque trimestre apporte de nouveaux agents capables d’agir directement dans l’ERP — passer des commandes, rapprocher des factures, générer des devis — sans qu’un cadrage clair n’ait forcément suivi le rythme.

J’ai passé les quinze dernières années à cadrer des déploiements Dynamics 365 CRM et Business Central sur des environnements multi-pays, certifié Microsoft PL-300 (Power BI Data Analyst) et MB-800 (Dynamics 365 Business Central Functional Consultant). Ce que je vois arriver en 2026 n’est pas un problème technique. C’est un problème de cadrage — exactement le métier du Product Owner.

Cet article ne cherche pas à vous convaincre d’adopter Copilot : la pression concurrentielle et l’ampleur de l’investissement de Microsoft rendent cette question largement tranchée pour la plupart des organisations. L’enjeu est ailleurs. Il est dans la manière dont on cadre cette adoption — quelles données un agent peut consulter, quelles actions il peut exécuter sans validation, et comment on documente tout cela pour rester auditable. C’est précisément ce que révèlent, en creux, les chiffres d’adoption et de confiance de 2026 : la technologie avance plus vite que la gouvernance qui devrait l’encadrer.

La vague 2026 : ce que Microsoft déploie réellement dans Dynamics 365

Le plan de publication 2026 wave 1 de Dynamics 365 introduit des innovations agentiques dans presque tous les modules. Dynamics 365 Sales permet désormais aux commerciaux de s’appuyer sur Copilot pour construire leur pipeline, enrichir les opportunités et accélérer la conclusion des affaires, avec des expériences Copilot unifiées qui croisent les données CRM et Microsoft Graph — emails, comptes rendus de réunion. Dynamics 365 Customer Service continue d’étendre ses capacités agentiques sur la gestion des dossiers, l’email, la détection d’intention client et l’évaluation qualité.

Du côté de l’ERP, Business Central « accélère le passage vers un ERP intelligent » avec des agents IA qui automatisent les scénarios de vente et d’achat dès la 2026 release wave 1. Trois agents structurent aujourd’hui cette automatisation : le Sales Order Agent, qui lit les demandes clients et prépare devis ou commandes pour validation ; le Payables Agent, qui traite les factures fournisseurs, rapproche les enregistrements d’achat et prépare les transactions pour approbation ; et l’Expense Agent, qui utilise les informations d’un reçu pour classer et préparer les notes de frais.

Le point commun à ces trois agents : ils ne remplacent pas la décision humaine, ils préparent le travail pour validation. C’est une nuance que beaucoup de communications marketing effacent, et qui est pourtant au cœur du sujet de gouvernance.

Dynamics 365 Customer Insights — Journeys pousse le même principe vers l’orchestration marketing : des engagements client agentiques de bout en bout sur les ventes, le marketing et le service, permettant aux entreprises de réagir de façon proactive au comportement client via Copilot et des agents IA. Comme pour l’ERP, chaque interaction bénéficie de données partagées et d’une intelligence cohérente à travers les applications CRM — ce qui signifie, du point de vue gouvernance, qu’une donnée mal cloisonnée dans un module se propage désormais automatiquement aux autres.

Le rythme de publication lui-même a changé de nature. Microsoft l’assume explicitement : la structure biannuelle classique cède la place à une cadence continue, avec une mise à jour mensuelle des « Business Applications Update » entre les deux grandes vagues. Pour un Product Owner qui pilote un backlog de gouvernance IA, cela signifie qu’un cadrage figé au moment du déploiement initial devient obsolète en quelques mois — la gouvernance doit elle-même devenir un processus itératif, pas un document de projet livré une fois pour toutes.

Joule rencontre Copilot : la fin du problème des deux assistants

L’annonce la plus structurante de 2026 ne vient pas uniquement de Microsoft. Lors de SAP Sapphire et Microsoft Build 2026, les deux éditeurs ont dévoilé une interopérabilité bidirectionnelle entre Joule, l’assistant IA de SAP, et Microsoft Copilot — avec des intégrations en production livrées dans Teams, Excel, Outlook et Microsoft Fabric.

Pour comprendre l’ampleur du changement, il faut revenir au problème qu’il résout. Historiquement, un collaborateur qui travaillait dans un contexte SAP basculait vers Joule ; le même collaborateur, dans un contexte Microsoft 365, utilisait Copilot. Aucun des deux assistants n’avait de réelle conscience du domaine de l’autre. Cette frontière est en train de disparaître. Joule est désormais disponible comme application native dans Teams, approuvée pour un déploiement entreprise via le Microsoft Teams App Store.

Pour les organisations qui tournent sur les deux piles technologiques — on estime que c’est le cas d’environ 70 % des entreprises du Fortune 500 — cette intégration n’a rien d’incrémental. Elle élimine la partie la plus pénible du « problème des deux assistants IA » : la duplication de contexte, la ressaisie, la confusion sur quel assistant interroger pour quelle donnée. Mais elle pose aussi, de façon plus aiguë, la question de qui gouverne quoi lorsque deux IA d’éditeurs différents accèdent aux mêmes données d’entreprise.

Concrètement, un commercial qui prépare une réunion client dans Teams pourra bientôt interroger, dans une seule conversation, des données de commande SAP et des données de pipeline Dynamics 365 — sans savoir techniquement, ni avoir besoin de savoir, laquelle des deux IA a traité chaque fragment de réponse. C’est un vrai gain d’efficacité opérationnelle. Mais du point de vue de la gouvernance des données, cela complique sensiblement la question de la traçabilité : quand une information erronée circule, remonter à sa source — Joule ou Copilot, donnée SAP ou donnée Microsoft — devient un exercice technique plus complexe qu’avant, à un moment où les deux éditeurs communiquent surtout sur la fluidité, rarement sur l’auditabilité de cette fluidité.

C’est un point que je recommande systématiquement d’inscrire au cahier des charges de tout projet de convergence SAP/Microsoft en 2026 : exiger, dès le cadrage, un mécanisme de traçabilité qui identifie la source de chaque réponse composite. Sans cette exigence posée en amont, elle n’apparaît jamais spontanément dans les livrables standards des intégrateurs.

Le grand écart : ROI à trois chiffres, confiance négative

Les chiffres d’adoption de Copilot en 2026 racontent une histoire à deux vitesses. D’un côté, l’échelle est spectaculaire : Microsoft a rapporté 420 millions d’utilisateurs actifs mensuels de Copilot au premier trimestre 2026, contre 230 millions un an plus tôt. Plus de 90 % des entreprises du Fortune 500 utilisent Copilot sous une forme ou une autre, et 64 % en ont un déploiement actif — contre 40 % fin 2024. Une étude Forrester Consulting commanditée par Microsoft évalue le ROI à 116 % pour les grandes entreprises et jusqu’à 353 % pour les PME sur trois ans, avec plus de neuf heures de productivité gagnées par utilisateur et par mois.

De l’autre côté, un signal beaucoup plus inconfortable circule dans les mêmes études. Le taux de pénétration réel — nombre de sièges payants rapporté à la base totale d’utilisateurs Microsoft 365 — reste autour de 6,5 %. Et surtout : selon une analyse de Recon Analytics, 44,2 % des utilisateurs qui abandonnent Copilot citent la méfiance envers les réponses comme raison principale. Le Net Promoter Score de précision de l’outil s’établissait à -19,8 en janvier 2026 — un score négatif signifie que les utilisateurs qui testent l’outil sont statistiquement plus enclins à s’en méfier qu’à le recommander.

Ces deux réalités coexistent parce qu’elles mesurent des choses différentes. L’adoption massive mesure la disponibilité de l’outil et la pression concurrentielle à l’installer. La confiance mesure la qualité du cadrage qui a précédé le déploiement — et c’est précisément là que le rôle du Product Owner ou du Business Analyst change la trajectoire d’un projet.

La segmentation par taille d’entreprise confirme cette lecture. Selon une étude de marché publiée début 2026, les grandes entreprises de plus de 5 000 salariés affichent un taux d’adoption de 64 % — en forte hausse — pendant que le segment mid-market (500 à 4 999 salariés) plafonne à 31 %, et les PME de moins de 500 salariés à seulement 12 %, concentrées principalement dans la tech et les services professionnels. Cette hiérarchie n’est pas un hasard : les grandes organisations disposent de directions data et de fonctions de gouvernance dédiées capables d’encadrer le déploiement, quand les structures plus petites activent souvent Copilot sans cette capacité de cadrage préalable — et se retrouvent statistiquement surreprésentées parmi les 44,2 % de désabonnements par méfiance.

Le nombre d’agents actifs dans l’écosystème Microsoft 365 a lui-même été multiplié par 15 en un an, jusqu’à 18 fois dans les grandes entreprises. Ce n’est pas qu’une évolution quantitative : avant 2025, la majorité des agents étaient expérimentaux et déclenchés manuellement. Ils gèrent désormais des flux de travail multi-étapes de bout en bout, sans intervention à chaque étape. C’est exactement ce changement de nature — d’assistant réactif à agent qui agit — qui rend le cadrage préalable non négociable : un agent expérimental qu’on interrompt à tout moment n’a pas les mêmes exigences de gouvernance qu’un agent qui traite une chaîne complète de rapprochement comptable sans supervision continue.

Ce que Copilot révèle (et ne crée pas) : le vrai risque de gouvernance

Une analyse largement relayée en 2026 pointe un mécanisme précis : Copilot ne crée pas de nouvelles failles de sécurité. Il amplifie des erreurs de gestion des droits d’accès qui existaient déjà sur les réseaux internes. Concrètement, un mauvais paramétrage de permissions SharePoint ou Teams qui restait invisible depuis des années devient, avec Copilot, immédiatement exploitable : l’outil rend des données sensibles instantanément accessibles à des collaborateurs qui n’auraient jamais dû les consulter, simplement parce qu’ils avaient techniquement un droit de lecture mal configuré.

Ce constat a poussé Microsoft à investir massivement dans la couche de gouvernance. Le Système de contrôle Copilot fournit aux équipes IT et sécurité des outils pour détecter les risques de sur-partage, appliquer des recommandations de correction des autorisations et anticiper les problèmes avant qu’ils ne se matérialisent. En mai 2026, Microsoft a lancé Agent 365, une couche de gouvernance dédiée spécifiquement aux agents IA, facturée 15 dollars par utilisateur et par mois en offre autonome — signe que la gouvernance des agents est devenue un marché à part entière, pas une fonctionnalité annexe.

Un exemple technique illustre bien pourquoi l’expertise fonctionnelle reste irremplaçable. Un consultant ayant audité une mesure DAX générée par Copilot pour un client des services financiers a découvert que l’outil avait utilisé la fonction SUM là où une mesure semi-additive exigeait LASTNONBLANK — une erreur qui aurait surestimé les soldes de comptes de 300 à 400 %. Le constat documenté par les experts Power BI est sans appel : Copilot gère fiablement des patterns courants (intelligence temporelle, mesures de variance, classification), mais peine sur les mesures semi-additives, la manipulation de filtres complexes et les mesures sensibles à la sécurité au niveau ligne. Sur ces cas, l’expertise humaine reste indispensable.

Ce type d’erreur n’est pas anodin dans un contexte réglementé. Une mesure de solde de compte surestimée de 300 à 400 % qui remonterait, sans contrôle, dans un rapport destiné à un comité de direction ou à un régulateur constituerait un incident sérieux — pas seulement une gêne opérationnelle. C’est précisément ce type de scénario que la préparation du modèle sémantique en amont permet d’éviter : Microsoft recommande explicitement de documenter les conventions de nommage, les descriptions de champs et les règles de modélisation avant d’ouvrir l’accès à Copilot, un chantier qui relève typiquement du Business Analyst ou du Product Owner data, pas de l’administrateur système.

La documentation Microsoft de gouvernance Power BI insiste également sur un principe simple, souvent contourné par précipitation : accorder l’accès à Copilot uniquement par groupes de sécurité, et seulement après qu’un utilisateur a suivi une formation ou démontré sa compréhension des limites de l’outil. Cette approche incrémentale, déployée par phases, contraste fortement avec la pratique observée sur le terrain — une activation globale en un clic, suivie d’une gestion des incidents au fil de l’eau.

Business Central : quand un agent Anthropic traite vos notes de frais

Un détail technique passe souvent inaperçu dans les guides de déploiement grand public : l’Expense Agent de Business Central ne tourne pas sur la même infrastructure que les autres agents Copilot. Contrairement au Sales Order Agent et au Payables Agent, il s’appuie sur des modèles Anthropic, sous approbation formelle de sous-traitant, et il est facturé à la réception traitée via les Copilot Credits plutôt que d’être inclus dans une licence utilisateur classique. Mi-2026, il était encore en préversion, limité à l’anglais aux États-Unis, avec une extension au Royaume-Uni et au Canada à partir de juillet 2026.

Ce détail n’est pas anecdotique pour un Product Owner : il signifie que la cartographie des sous-traitants IA d’un environnement Dynamics 365 n’est plus homogène. Un audit de conformité RGPD ou une clause de sous-traitance contractuelle doit désormais distinguer, agent par agent, quel modèle traite quelle donnée — et non plus se contenter de valider « Microsoft » comme sous-traitant unique.

Au-delà de ce cas précis, Business Central introduit dans sa version 2026 la possibilité de concevoir ses propres agents personnalisés via l’AI Development Toolkit. Les objectifs et instructions s’y définissent en langage naturel plutôt qu’en code AL complexe, testables en environnement sandbox, avec des profils et permissions assignables, et des journaux d’exécution consultables pour comprendre le raisonnement suivi. Les définitions d’agents peuvent être exportées en JSON et versionnées dans un système comme GitHub — une discipline d’ingénierie logicielle appliquée à des objets qui, il y a encore deux ans, relevaient uniquement du paramétrage fonctionnel.

Le vrai travail du Product Owner face à ces agents

Face à ce paysage, la question qui revient dans la plupart des missions que je cadre n’est jamais « faut-il activer Copilot ? ». La réponse est presque toujours oui : la pression concurrentielle et le ROI documenté rendent l’attentisme intenable. La vraie question est : quelles actions confie-t-on à l’agent sans validation humaine, et lesquelles restent bloquées derrière un point de contrôle ?

C’est un arbitrage produit, pas un paramétrage technique. Il suppose de connaître le métier assez finement pour savoir qu’une mesure semi-additive en finance mérite une double validation, qu’un droit d’accès SharePoint mal calibré devient un risque dès l’activation de Copilot, ou qu’un agent de notes de frais tournant sur un sous-traitant distinct change la cartographie de conformité. C’est exactement l’interface entre le métier, la donnée et l’IT que porte un Product Owner ou un Business Analyst senior — et c’est un rôle qu’aucun outil, aussi puissant soit-il, ne remplace.

Une méthode de cadrage en cinq points, testée sur le terrain

Sur mes missions de cadrage Dynamics 365 et SAP, cinq points reviennent systématiquement avant toute activation de Copilot en production :

1. Audit des droits d’accès avant activation. Cartographier qui a accès à quoi dans SharePoint, Teams et les modèles sémantiques Power BI — pas après l’activation de Copilot, avant. C’est la recommandation explicite de Microsoft lui-même dans sa documentation Power BI Copilot, et c’est le point le plus souvent négligé.
2. Préparation du modèle sémantique. Conventions de nommage métier, descriptions de champs, bonnes pratiques de modélisation. Microsoft le formule sans détour : négliger cette préparation produit des résultats Copilot plus inutiles et imprécis.
3. Cartographie des sous-traitants par agent. Identifier quel modèle (OpenAI, Anthropic, autre) traite quelle donnée, agent par agent, pour documenter correctement la conformité RGPD.
4. Matrice d’autonomie par action. Pour chaque agent activé — Sales Order, Payables, Expense ou autre — définir explicitement ce qu’il peut exécuter seul et ce qui reste soumis à validation humaine, avec une attention particulière aux mesures financières semi-additives et aux calculs sensibles aux droits d’accès.
5. Déploiement incrémental avec formation préalable. Accorder l’accès à Copilot par groupes de sécurité, uniquement après formation ou preuve de compréhension des limites de l’outil — l’approche que Microsoft recommande explicitement dans sa documentation de gouvernance.

Ces cinq points ne constituent pas une checklist bureaucratique de plus : chacun répond directement à un mode d’échec documenté dans les sections précédentes. L’audit des droits répond au constat que Copilot amplifie les permissions mal configurées. La préparation du modèle sémantique répond au risque d’erreurs comme le cas SUM/LASTNONBLANK. La cartographie des sous-traitants répond à la fragmentation introduite par des agents comme l’Expense Agent tournant sur une infrastructure distincte. La matrice d’autonomie répond à la nécessité de distinguer les agents à faible et haut risque. Le déploiement incrémental répond directement à la recommandation de gouvernance la plus explicite de Microsoft elle-même.

Sur le terrain, ce cadrage se formalise généralement en un document court — deux à trois pages — mais vivant, revu à chaque nouvelle vague de release plutôt que figé au lancement. C’est la différence entre une gouvernance IA qui accompagne réellement le rythme continu des mises à jour Microsoft, et une gouvernance qui devient obsolète au premier trimestre suivant sa rédaction.

Trois erreurs de cadrage qui coûtent cher

Activer Copilot avant d’auditer les droits d’accès. C’est l’erreur la plus fréquente et la plus coûteuse : l’outil ne fait qu’exposer des permissions déjà mal configurées, mais il le fait à une vitesse et une échelle qu’aucun audit manuel n’atteint.

Traiter tous les agents comme équivalents en termes de gouvernance. Un agent qui rédige un email et un agent qui rapproche des factures fournisseurs n’appellent pas le même niveau de supervision — ni, on l’a vu avec l’Expense Agent, nécessairement le même sous-traitant technique.

Confondre déploiement de sièges et adoption réelle. Les statistiques 2026 le montrent sans ambiguïté : la disponibilité de l’outil (sièges provisionnés) et son usage effectif mesurable (utilisateurs actifs, invites traitées) sont deux courbes distinctes. Piloter uniquement sur le nombre de licences achetées masque le vrai indicateur de succès.

Conclusion : la techno est prête, la gouvernance rarement

Le paysage 2026 de Dynamics 365 et de l’écosystème Copilot n’a plus grand-chose d’expérimental. Les agents traitent déjà des factures, préparent des devis et rapprochent des comptes en production, chez des dizaines de milliers d’entreprises. La technologie a dépassé le stade de la preuve de concept.

Ce qui n’a pas suivi au même rythme, c’est le cadrage : qui décide de ce qu’un agent peut faire seul, comment la cartographie des sous-traitants IA est documentée, quelles mesures financières méritent une double validation. C’est un travail de Product Owner, de Business Analyst ou de consultant fonctionnel senior — pas un paramètre qu’on coche dans un panneau d’administration. Les organisations qui investissent dans ce cadrage avant l’activation captent le ROI documenté par Forrester. Celles qui l’ignorent alimentent les statistiques de méfiance et d’abandon.

La convergence Joule-Copilot annoncée en 2026 va accélérer cette dynamique dans les deux sens. Elle va rendre l’IA générative encore plus transparente et plus puissante dans le quotidien des équipes SAP et Microsoft — et elle va, dans le même mouvement, complexifier la traçabilité pour quiconque n’a pas anticipé la question dès le cahier des charges. Les organisations qui gagneront sur ce terrain en 2026 et 2027 ne seront pas nécessairement celles qui auront déployé Copilot le plus vite, mais celles qui auront su documenter, mesurer et faire évoluer leur gouvernance IA au même rythme que les mises à jour trimestrielles de leurs éditeurs.

C’est un chantier qui demande une double compétence, rarement réunie chez un seul profil : une maîtrise fonctionnelle réelle de l’ERP — assez fine pour repérer une mesure semi-additive mal calculée ou un droit d’accès mal calibré — et une capacité à traduire cette expertise en arbitrages produit clairs pour la direction. C’est cette double compétence, construite sur des déploiements réels plutôt que sur de la théorie, qui fait la différence entre un projet Copilot qui tient ses promesses et un projet qui grossit les statistiques d’abandon.

FAQ

Copilot dans Dynamics 365 remplace-t-il un Product Owner ou un Business Analyst ?
Non. Les agents Copilot préparent des actions (devis, rapprochements, classifications) pour validation humaine ; ils ne définissent pas la politique de gouvernance, l’arbitrage des risques métier ni la priorisation produit — c’est le cœur du rôle du Product Owner.

Faut-il auditer les droits d’accès avant ou après avoir activé Copilot ?
Avant, systématiquement. Copilot n’introduit pas de nouvelle faille : il rend immédiatement exploitables des permissions mal configurées qui existaient déjà.

L’Expense Agent de Business Central utilise-t-il le même modèle que les autres agents Copilot ?
Non. Il s’appuie sur des modèles Anthropic sous approbation de sous-traitant distincte, contrairement au Sales Order Agent et au Payables Agent — un point à documenter spécifiquement dans un audit de conformité.

Quel est le vrai taux d’adoption de Copilot en entreprise en 2026 ?
Cela dépend de l’indicateur : plus de 90 % des entreprises du Fortune 500 l’utilisent sous une forme ou une autre, mais la pénétration réelle rapportée à la base totale d’utilisateurs Microsoft 365 reste d’environ 6,5 %.

Regard d’expert

Ce qui me frappe le plus dans le cycle 2026 n’est pas la vitesse à laquelle Microsoft et SAP déploient des agents — c’est l’écart persistant entre cette vitesse et la maturité de gouvernance des organisations qui les reçoivent. J’ai vu des directions IT activer Copilot en quelques clics sans jamais avoir audité leurs droits SharePoint depuis des années. Le résultat n’est presque jamais un incident spectaculaire ; c’est une érosion lente de la confiance, exactement ce que traduit ce NPS négatif. Le rôle du Product Owner, dans ce contexte, n’est pas de ralentir l’adoption — c’est de la rendre mesurable, réversible et documentée, agent par agent.

Passons à l’action

Vous pilotez un déploiement Dynamics 365, Business Central ou un environnement SAP sous pression pour activer Copilot rapidement ? Le cadrage en amont — audit des droits d’accès, matrice d’autonomie par agent, cartographie des sous-traitants IA — fait la différence entre un ROI documenté et une adoption qui s’érode. Discutons de votre contexte Dynamics 365 ou, si votre environnement est basé sur Business Central, échangeons sur votre cadrage ERP.

Références

• Microsoft Learn — Dynamics 365 2026 release wave 1 plan
• Microsoft Dynamics 365 Blog — 2026 release wave 1 plans for Dynamics 365, Power Platform and Copilot Studio
• SAVIC Technologies — SAP Microsoft Copilot Integration 2026, CIO Guide
• Rand Group — Exploring the Microsoft Dynamics 365 Copilot 2026 release wave 1
• DynamicsSmartz — Microsoft 365 Copilot: Features, Pricing, Licensing & ROI, 2026 Guide (Forrester TEI data)
• StackMatix — Microsoft Copilot Enterprise Adoption in 2026: What the Data Shows
• StackMatix — Microsoft Copilot Adoption Statistics & Trends 2026
• AIBusinessWeekly — Microsoft Copilot Statistics 2026: Users, Seats & Revenue (Recon Analytics NPS data)
• HumanizeAI — Microsoft Copilot Adoption Trends 2026
• ERP Software Blog — Dynamics 365 Business Central AI Agents: 2026 MCP Guide
• MSDynamicsWorld — What’s Coming to Dynamics 365 Business Central in 2026
• Microsoft — Agentic ERP Software Solutions, Dynamics 365 (Forrester Total Economic Impact study, Feb-March 2026)
• ia-info.fr — Microsoft Copilot : les 5 risques de sécurité que les entreprises ignorent encore en 2026
• Microsoft Security — Sécuriser et régir Microsoft 365 Copilot (Purview)
• Power BI Consulting — Power BI Copilot: AI Report Creation Guide (cas DAX SUM/LASTNONBLANK)
• Learn Microsoft — Copilot dans Power BI : Vue d’ensemble et avantages de l’intégration