Vous êtes depuis vingt minutes en comité de direction trimestriel. La diapositive indique que l’annonce sur la transformation a touché 4 100 personnes sur l’intranet. Quelqu’un de la direction financière a ouvert l’export d’usage SharePoint sur son ordinateur, parce qu’il l’avait demandé la semaine précédente, et il y lit 3 600 sur la même période. Il pose la question, légitime : lequel des deux est le bon ?
Ce que vous répondez à cet instant détermine la suite de l’année. Si vous ne savez pas expliquer l’écart en une phrase, la perte de crédibilité touche l’ensemble du dossier de reporting, pas seulement cette diapositive. Cet article porte sur ce moment précis : pourquoi les deux divergent, comment décider lequel fait référence, et à quoi ressemble un rapprochement mené sérieusement.
Aucun des deux chiffres ne ment, et c’est bien le problème
Le réflexe consiste à chercher une anomalie technique. Il n’y en a généralement pas. Les deux chiffres divergent parce qu’ils répondent à des questions légèrement différentes, sur des systèmes et des horloges différents.
Les rapports d’usage SharePoint sont générés dans le service et affichés dans le site lui-même, agrégés sur des fenêtres fixes de 7, 30, 90 jours et 12 mois[1]. Un rapport Power BI construit par votre DSI lit presque toujours les points de terminaison de reporting Microsoft Graph, qui exposent les données d’activité au niveau du tenant selon leur propre calendrier et leurs propres règles d’agrégation[2]. Deux chaînes de traitement, deux définitions du jour, deux définitions de la personne unique.
Quatre différences expliquent l’essentiel des écarts.
- L’horloge. Les données de reporting Graph sont exprimées en UTC. Votre modèle Power BI les agrège peut-être en heure locale, et votre fenêtre SharePoint est ancrée ailleurs encore. Un lundi à Singapour et un lundi à Chicago ne sont pas le même lundi.
- L’unité. Une vue n’est pas une visite, qui n’est pas un lecteur unique. Si la mesure Power BI compte des utilisateurs distincts et que le panneau natif compte des pages vues, les deux ne s’accorderont jamais, et c’est normal.
- Le périmètre. Un modèle Power BI qui interroge tous les sites du tenant compte les sites d’équipe et l’activité OneDrive personnelle en plus de l’intranet. L’inflation est importante et largement invisible : c’est la cause la plus fréquente d’un chiffre Power BI supérieur au chiffre natif. Nous détaillons cette frontière dans l’article sur OneDrive et SharePoint.
- La latence. Les données d’activité arrivent avec un décalage. Interrogez la même période une semaine plus tard et vous obtiendrez légitimement un chiffre plus élevé.
Les trois choses à dire à voix haute sur Power BI
Au-delà de la dérive des définitions, trois propriétés de cette pile doivent être énoncées clairement, de préférence avant qu’un dirigeant ne les découvre.
Premièrement, l’API de reporting Microsoft Graph n’est pas régulièrement fiable. Elle produit des journées de données manquantes. Pas corrompues, simplement absentes, et un graphique qui trace une ligne entre les deux points voisins affichera une tendance régulière qui n’a jamais existé.
Deuxièmement, des clients ont observé dans Power BI des valeurs d’indicateurs qui ne se rapprochent pas des rapports SharePoint natifs sur la même période. Ce n’est pas un cas limite rare : c’est l’état normal d’un développement non rapproché, et c’est exactement la situation décrite en ouverture.
Troisièmement, un développement fiable exige un processus d’ingestion solide et un rapprochement planifié avec les chiffres natifs. Le tableau de bord est la partie bon marché. La chaîne qui comble les trous, détecte les journées manquantes, relance les extractions en échec et se compare chaque mois à une référence connue est la partie coûteuse, et c’est celle qui saute au cadrage. Budgétez la chaîne plutôt que le tableau de bord. Le guide honnête sur les analytics SharePoint avec Power BI traite ce coût complet.
Choisissez un chiffre de référence, et écrivez-le
Voici la position que défend cet article : l’échec en comité de direction n’était pas analytique, il était de gouvernance. Personne n’avait décidé, à l’avance et par écrit, quel système fait autorité pour quelle affirmation. Dès lors que deux systèmes peuvent répondre à la même question et qu’aucun n’a été désigné comme la réponse, chaque réunion devient une négociation.
Un chiffre de référence tient en quatre éléments écrits : l’indicateur, le système qui le produit, la définition exacte, et la personne qui en répond. Cela s’écrit en un après-midi et met fin au débat durablement.
Le partage raisonnable est le suivant. Le reporting natif SharePoint fait référence pour un site unique sur une fenêtre standard, parce qu’il est le système d’origine. Power BI fait référence dès qu’il faut combiner des sites, rapprocher des attributs organisationnels ou couvrir une période plus longue que la conservation native. Là où les deux se recouvrent, le chiffre natif l’emporte et le modèle Power BI est corrigé pour s’y aligner.
| Ce que vous voulez affirmer | Chiffre de référence | Pourquoi |
|---|---|---|
| La page d’actualité a été vue 3 600 fois le mois dernier | Usage natif SharePoint | Système d’origine, site unique, fenêtre standard. Chacun peut le vérifier. |
| La campagne a touché 41 % de la fonction commerciale | Power BI ou couche dédiée | Suppose un rapprochement avec des attributs organisationnels que le natif ne détient pas. |
| La portée de l’intranet progresse de 12 points sur trois ans | Power BI ou couche dédiée | Dépasse la fenêtre de conservation native : l’historique doit vivre ailleurs. |
| La consigne de sécurité a atteint les ateliers | Ce qui détient les attributs de site et de métier | Le natif rend compte de la page, pas de la population visée. |
| Activité totale intranet, Viva Engage et newsletter | Couche multicanale | Aucun panneau natif ne couvre les trois canaux, et les unités diffèrent. |
Le rituel de rapprochement
Une fois le chiffre de référence établi, le rapprochement devient une tâche mensuelle plutôt qu’une crise. Il doit prendre moins d’une heure et relever d’une personne identifiée.
Choisissez trois ou quatre sites de référence, dont votre site d’actualité le plus fréquenté et un site régional calme. Chaque mois, extrayez le chiffre d’usage natif sur la fenêtre standard de 30 jours et comparez-le à ce que le modèle Power BI annonce pour le même site, la même fenêtre, la même mesure. Consignez les deux chiffres et l’écart dans un tableau qui n’est jamais supprimé. Fixez une tolérance à l’avance, 5 % est un point de départ courant, et traitez tout dépassement comme un incident.
Deux choses font fonctionner ce rituel. Le journal est tenu même quand l’écart est nul, ce qui vous permet de montrer une année de stabilité plutôt que de l’affirmer. Et le contrôle des journées manquantes se fait séparément : comptez les jours de la période qui n’ont renvoyé aucune donnée, car un modèle peut se rapprocher parfaitement sur les totaux tout en ayant discrètement perdu un mardi.
Le jour de la présentation, montrez l’écart. Une direction de la communication interne qui déclare « ces deux systèmes s’accordent à 3 % près, et voici le journal » a clos le sujet. Celle qui répond « je vais vérifier » le voit revenir chaque trimestre. Notre note sur le reporting exécutif en communication interne précise ce qui relève de la diapositive et ce qui relève de l’annexe.
Quand Power BI est réellement le bon endroit
Rien de ce qui précède ne plaide contre le développement interne. Power BI est un outil de modélisation capable, déjà sous licence dans la plupart des organisations Microsoft 365, et c’est l’endroit naturel pour combiner des sources[3]. Si vous disposez d’un ingénieur data qui assume la chaîne de traitement, d’un rapprochement en fonctionnement et d’un besoin assez spécifique pour qu’aucun produit ne le couvre, construire est le bon choix.
C’est le mauvais choix dans deux cas. Quand personne ne détient la chaîne de traitement, le développement se dégrade silencieusement et vous l’apprenez en réunion. Et quand le vrai besoin est un reporting multicanal segmenté, car vous ne construisez alors plus un rapport mais une plateforme de données. Pour l’architecture, le guide sur l’analyse de SharePoint avec Power BI expose ce qu’exige un développement qui tient devant un comité, et la marche à suivre sur la création d’un reporting de communication interne avec Power BI traite la conception du rapport.
Ce qu’une couche de mesure dédiée change à la question
Tryane se place au-dessus de Microsoft 365 plutôt qu’à côté. La plateforme lit SharePoint, Viva Engage, Teams et les outils de newsletter ensemble, rapproche cette activité de votre structure organisationnelle via Entra ID ou un fichier RH, et conserve l’historique au travers des transitions produit. Le rapprochement décrit plus haut existe toujours, mais il s’opère contre une définition stable dans le produit plutôt que dans un tableur que vous entretenez.
Les éléments pratiques : certification SOC 2 Type 2, conformité RGPD par conception, hébergement en Europe par défaut avec résidence des données aux États-Unis sur demande, authentification unique Azure AD ou Entra ID, aucun agent à installer, déploiement en quelques heures. Tryane publie vers Power BI via son API : une équipe qui a standardisé Power BI comme couche de restitution la conserve et ne remplace que l’ingestion en dessous. Si vous reconstruisez le jeu d’indicateurs en parallèle, le guide des indicateurs de communication interne est l’article compagnon, et celui sur les limites des analyses natives SharePoint explique où les chiffres natifs cessent de suffire.
Questions fréquentes
Pourquoi mon rapport Power BI affiche-t-il plus de vues que SharePoint ?
Le plus souvent parce que le modèle interroge un périmètre plus large que l’intranet. Une requête à l’échelle du tenant inclut les sites d’équipe et l’activité OneDrive personnelle, ce qui gonfle le total face à un rapport natif limité à un site de communication. Vérifiez le périmètre, puis la définition de la mesure, puis le fuseau horaire.
Quel chiffre mettre sur la diapositive du comité ?
Celui que vous avez désigné comme chiffre de référence pour cette affirmation, et vous devez pouvoir le nommer avant d’entrer en réunion. Pour un site unique sur une fenêtre standard, utilisez le chiffre natif. Dès que la mesure est segmentée ou dépasse la conservation native, utilisez le chiffre modélisé et indiquez-le en note.
À quelle fréquence faut-il rapprocher les chiffres ?
Chaque mois, sur un ensemble fixe de sites de référence, avec l’écart consigné qu’il soit intéressant ou non. Un rapprochement qui n’a lieu que lorsque quelqu’un se plaint est de la gestion d’incident, et il ne produit jamais la preuve dont vous avez besoin en réunion.
L’API de reporting Microsoft Graph est-elle assez fiable pour construire dessus ?
Assez fiable pour construire avec précaution, pas assez pour construire avec légèreté. Elle produit des journées de données manquantes, et des clients ont observé dans Power BI des valeurs d’indicateurs qui ne se rapprochent pas des rapports SharePoint natifs sur la même période. Un développement fiable exige une ingestion solide, une détection des trous, une logique de relance et un rapprochement planifié. Budgétez cette chaîne, pas le tableau de bord.
Tryane remplace-t-il notre reporting Power BI ?
Pas nécessairement. De nombreux clients conservent Power BI comme couche de restitution et utilisent Tryane comme source, via l’API, afin que les visuels restent là où l’organisation a l’habitude de les lire. Ce qui change se situe en dessous : une ingestion maintenue, attributs organisationnels rapprochés et historique conservé, à la place d’une chaîne sur mesure qu’une seule personne comprend.
Sources
• Microsoft Learn, usage des sites SharePoint et santé du portail
• Microsoft Learn, présentation des rapports Microsoft Graph
• Microsoft Learn, présentation de Power BI
Pour aller plus loin
• Analyser SharePoint avec Power BI
• Construire des analytics SharePoint avec Power BI, un guide honnête
• OneDrive et SharePoint, bien utiliser les deux outils
• Le reporting exécutif en communication interne
• Les limites des analyses natives SharePoint
Tryane anime une session de travail de 15 minutes avec les directions de la communication interne, pour passer en revue les chiffres que vous publiez et les points où ils divergent des chiffres natifs sur votre tenant. Réservez un créneau avec Jérémy.