La question vient en général de la DSI plutôt que de vous, et elle est légitime. L’organisation paie déjà Power BI, SharePoint produit déjà des données d’usage, et quelqu’un de sensé veut savoir pourquoi la communication interne aurait besoin d’une plateforme analytique séparée alors qu’un développeur pourrait câbler tout cela en quinze jours. Ce développeur a raison sur un point : c’est constructible. Ce que l’estimation à quinze jours oublie, c’est que la difficulté n’est pas le rapport. C’est de garder les chiffres défendables pendant les dix-huit mois qui suivent sa livraison.
Cet article est la version pratique : à quoi vous vous connectez réellement, une architecture qui tient, l’habitude de rapprochement qui maintient la crédibilité du tableau de bord, et une lecture honnête des cas où il ne faut pas construire. Les modes de défaillance précis sont traités à part dans notre article sur les analytics SharePoint avec Power BI, à lire en complément.
Vous vous connectez à trois choses, pas à une
La première erreur de conception consiste à traiter SharePoint comme une source unique. Il y en a trois, elles n’ont pas la même granularité, et elles ne concordent pas par construction.
| Rapports d’usage Microsoft 365 | Statistiques de site et de page SharePoint | Journal d’audit et Purview | |
|---|---|---|---|
| Granularité | Site et utilisateur, agrégats quotidiens | Page et site, dans l’interface | Événements individuels |
| Accès | API de reporting Microsoft Graph | Panneau d’utilisation, export limité | Recherche d’audit ou API d’activité |
| Conservation type | Fenêtres glissantes jusqu’à 180 jours | Fenêtre glissante par panneau | Selon la licence et la politique de rétention |
| Identité des personnes | Masquée par défaut par le réglage de confidentialité | Agrégée uniquement | Nominative, selon la politique |
| Utile pour | Tendances et comparaison entre sites | Vérifier une page précise | Questions de conformité et d’investigation |
| Inadapté pour | Tout ce qui exige des personnes nommées ou un long historique | Tout ce qui doit être automatisé | Le reporting courant, trop coûteux à interroger |
Un réglage mérite d’être nommé, car il casse plus de projets que tous les autres. Dans le centre d’administration Microsoft 365, les rapports masquent par défaut les noms d’utilisateurs, de groupes et de sites, et l’API renvoie des identifiants pseudonymisés en conséquence[1]. Si votre modèle rapproche l’usage d’un extrait RH sur le nom principal d’utilisateur, il ne renverra rien, et il ne vous dira pas pourquoi. Modifier ce réglage est une décision de confidentialité à l’échelle du tenant : elle relève de votre DPO et de vos instances représentatives, pas du développeur qui construit le modèle.
Les trois choses à savoir avant de commencer
Ce ne sont pas des cas limites. Toute organisation ayant fait vivre un tel projet pendant un an les a rencontrées toutes les trois.
L’API de reporting Microsoft Graph n’est pas régulièrement fiable. Elle produit des journées de données manquantes[2]. Non pas des données corrompues, des données absentes. Si votre modèle additionne un mois sans détecter les trous, le mois est simplement bas et le tableau de bord annonce une baisse de l’engagement.
Les chiffres ne se rapprocheront pas toujours des rapports natifs. Des clients ont observé dans Power BI des valeurs d’indicateurs qui ne correspondent pas aux rapports SharePoint natifs sur la même période. Quand un propriétaire de site ouvre son propre panneau d’utilisation et y lit un chiffre différent de celui de votre tableau de bord exécutif, la conversation qui suit porte sur votre crédibilité, pas sur l’écart.
Un projet fiable exige un processus d’ingestion solide et un rapprochement planifié. Pas une requête directe depuis le rapport vers l’API. Un vrai travail d’ingestion avec reprise, détection des trous et historique stocké, plus un rapprochement mensuel avec les chiffres natifs, plus une personne nommée qui en répond, y compris pendant ses congés. Budgétez le pipeline plutôt que le tableau de bord : le tableau de bord est la partie bon marché, et il l’a toujours été.
Une architecture qui tient
Quatre couches. C’est en sautant l’une d’elles qu’on arrive à l’estimation de quinze jours.
- Une ingestion planifiée et idempotente. Interrogez l’API de reporting Graph selon un calendrier, écrivez les réponses brutes dans un stockage, et rejouez toute journée revenue vide. Idempotent signifie qu’une réexécution ne double pas les compteurs, ce qui compte la première fois qu’un traitement échoue à moitié à deux heures du matin.
- Un entrepôt d’atterrissage avec un vrai historique. La fenêtre glissante de l’API est la raison pour laquelle votre tendance pluriannuelle n’existe pas. En conservant chaque extraction quotidienne, vous accumulez l’historique que la plateforme ne conserve pas. C’est peu coûteux et c’est l’élément de plus forte valeur de tout le projet.
- Un modèle sémantique avec des définitions écrites. Utilisateur actif, portée, visiteur unique : définissez chacun une fois, dans le modèle, et documentez-le. La plupart des disputes de rapprochement sont des disputes de définition déguisées en problème de données.
- Le rapport, en dernier. Branchez Power BI sur les données modélisées plutôt que sur l’API[3]. Un rapport construit directement sur une source instable hérite de son instabilité.
Si vous concevez ce qui figurera réellement à l’écran, notre guide pour construire un tableau de bord de communication interne traite la mise en page et les mesures, et la note sur le ROI des campagnes internes dans Power BI traite la vue par campagne.
L’habitude de rapprochement
Une heure par mois, et c’est ce qui sépare un tableau de bord auquel on se fie d’un tableau de bord que l’on cesse discrètement d’ouvrir. Choisissez trois indicateurs. Recalculez-les depuis le rapport natif d’utilisation des sites SharePoint pour le mois complet précédent[4]. Consignez l’écart avec votre modèle. Puis publiez cet écart à côté du tableau de bord, au lieu de le dissimuler.
Cette dernière étape est contre-intuitive et c’est la plus importante. Un tableau de bord qui annonce se situer à deux pour cent des chiffres natifs a de l’autorité. Un tableau de bord qui ne dit rien la perd entièrement la première fois que quelqu’un découvre un écart tout seul.
Quand construire, et quand s’abstenir
Construisez si le périmètre couvre un ou deux canaux, si vous disposez d’un ingénieur data avec de la capacité, si la DSI accepte de porter le pipeline comme un service et non comme un projet, et si une segmentation au niveau du tenant vous suffit. C’est une situation réelle, et le développement y répond très bien.
Réfléchissez davantage si l’un des points suivants est vrai. Vous avez besoin de la participation par fonction, site, pays ou type de contrat, ce qui suppose un rapprochement avec Entra ID ou un fichier RH et une confrontation au réglage de pseudonymisation ; notre note sur la segmentation d’audience précise ce qu’exige ce rapprochement. Vous avez besoin de SharePoint, Viva Engage, Teams et votre outil de newsletter dans une seule mesure de portée. Ou vous avez besoin d’un historique traversant une refonte ou une transition produit, qu’aucune fenêtre glissante ne vous donnera. L’étude State of the Sector de Gallagher identifie chaque année la mesure comme la première compétence manquante citée par les communicants internes, et un projet Power BI inachevé en est l’une des causes les plus fréquentes[5].
Tryane existe pour cette seconde colonne. La plateforme lit SharePoint aux côtés de Viva Engage, Teams et des outils de newsletter, rapproche l’activité de votre structure organisationnelle via Entra ID ou un fichier RH, et conserve un historique illimité au travers des refontes et des transitions produit. Elle expose aussi une API : si Power BI est l’endroit où vos dirigeants lisent déjà leurs chiffres, Tryane l’alimente au lieu de le concurrencer. Tryane est certifié SOC 2 Type 2 et conforme au RGPD par conception, héberge en Europe par défaut avec résidence américaine sur demande, se déploie en quelques heures via l’authentification unique Entra ID, sans agent à installer. Si vous n’avez pas encore épuisé ce qui est gratuit, commencez par le guide des statistiques natives SharePoint et la note sur les limites des analytics SharePoint.
Questions fréquentes
Power BI peut-il se connecter directement aux statistiques SharePoint ?
Pas au panneau d’utilisation du site, qui est une interface et non un point de terminaison. Ce à quoi vous vous connectez, c’est l’API de reporting Microsoft Graph pour les données d’usage au niveau du tenant, et éventuellement le journal d’audit pour les événements. Les listes et bibliothèques SharePoint sont directement connectables, mais elles contiennent vos contenus, pas vos statistiques d’usage.
Pourquoi mes chiffres Power BI diffèrent-ils du panneau d’utilisation SharePoint ?
En général pour l’une de ces trois raisons : l’API a renvoyé des journées vides et votre modèle a compté le trou comme un zéro, les deux sources ne définissent pas l’indicateur de la même façon, ou les fenêtres de dates ne coïncident pas parce que l’une est glissante et l’autre calendaire. Faites un rapprochement mensuel sur trois indicateurs, consignez l’écart, et publiez-le à côté du tableau de bord pour qu’il soit documenté plutôt que découvert.
Puis-je produire un reporting par direction ou par pays ?
Seulement si vous rapprochez les données d’usage d’une source d’attributs comme Entra ID ou un extrait RH, et seulement si le réglage de tenant qui masque les noms d’utilisateurs, de groupes et de sites a été examiné. Ce réglage est actif par défaut et renvoie discrètement des identifiants pseudonymisés qui ne correspondront pas à vos clés RH. Traitez sa modification comme une décision de confidentialité impliquant votre DPO, pas comme une tâche de configuration.
Quel historique puis-je récupérer ?
Depuis l’API, des fenêtres glissantes allant jusqu’à 180 jours selon le rapport. Au-delà, c’est à vous d’accumuler, raison pour laquelle un entrepôt conservant chaque extraction quotidienne compte davantage que les visuels. Si vous commencez à stocker aujourd’hui, vous disposerez dans deux ans de quelque chose que la plateforme ne peut vous vendre à aucun prix.
Tryane remplace-t-il Power BI ?
Non, et ce n’est pas nécessaire. Tryane fournit la couche de mesure, réalise les rapprochements entre canaux et conserve l’historique. Si Power BI est l’endroit où votre direction lit ses chiffres, Tryane l’alimente via son API. Vous conservez votre investissement Microsoft 365 et vous cessez d’entretenir vous-même le pipeline d’ingestion.
Sources
• Microsoft Learn, rapports d’activité Microsoft 365 et réglage de confidentialité
• Microsoft Learn, API de reporting Microsoft Graph
• Microsoft Learn, connecter Power BI à des services
• Microsoft Learn, rapport d’utilisation des sites SharePoint
• Gallagher, State of the Sector
Pour aller plus loin
• Construire des analytics SharePoint avec Power BI, un guide honnête
• Créer un reporting de communication interne avec Power BI
• Power BI et SharePoint pour analyser la communication interne
• Construire un tableau de bord de communication interne
• Les limites des analytics SharePoint pour la communication interne
Tryane anime une session de travail de 15 minutes avec les directions de la communication interne : nous comparons ce que rapporte votre modèle Power BI aux chiffres natifs de votre propre tenant et nous montrons où les deux divergent. Réservez un créneau avec Jérémy.