La revue mensuelle de la communication est le moment où un reporting Power BI est réellement testé. Quatorze visuels, un filtre de dates, un filtre de sites, une carte en haut avec le total des pages vues. La direction regarde le chiffre de l’intranet, approuve, puis demande si la campagne sécurité a atteint les usines ou seulement les sièges. Le rapport ne peut pas répondre, parce que rien dans le modèle ne sait ce qu’est une usine. Aucune mise en forme ne corrigera cela.
Cet article porte sur les décisions qui précèdent le premier visuel : ce qui doit figurer sur la diapositive mensuelle, quelle maille le modèle doit porter, et où un développement Power BI sur des données Microsoft 365 se casse. Si vous en êtes au choix de la connexion, notre guide sur l’analyse de SharePoint avec Power BI traite la plomberie, et le guide honnête sur les analytics SharePoint dans Power BI traite de la qualité des données. Ici, nous supposons qu’elles arrivent déjà.
Concevoir la diapositive avant de concevoir le modèle
Presque tous les reportings de communication interne sous Power BI sont construits dans le mauvais sens. Quelqu’un se connecte à ce que livrent les rapports d’activité Microsoft 365 et l’API de reporting Microsoft Graph, constate quels champs existent, et fabrique des visuels de ces champs[1]. Le rapport épouse la forme de l’API plutôt que celle de la conversation à laquelle il doit survivre.
Inversez la démarche. Avant d’ouvrir Power BI Desktop, écrivez les cinq ou six phrases que vous voulez prononcer en revue. De vraies phrases, en langage métier :
- « La campagne sécurité a touché 71 % de la production et 94 % du siège. Au trimestre précédent, l’écart était deux fois plus grand. »
- « La lecture des actualités en Allemagne baisse pour le troisième mois consécutif. Elle tient partout ailleurs, ce n’est donc pas un problème de plateforme. »
Chaque phrase est un cahier des charges. La première exige une portée en taux, donc un dénominateur, donc un effectif par segment, donc une dimension d’audience que Microsoft 365 ne porte pas. La seconde exige le pays et une tendance qui survit à la fenêtre de conservation native. Écrivez ces phrases et vous avez écrit le brief du modèle.
Les quatre questions auxquelles un reporting mensuel doit répondre
Les mêmes quatre questions reviennent chaque mois, et chacune casse le modèle à un endroit précis et prévisible.
| Question | Indicateur impliqué | Maille nécessaire | Où cela casse |
|---|---|---|---|
| Le message a-t-il atteint les personnes visées ? | Lecteurs uniques d’un segment rapportés à l’effectif de ce segment | Une ligne par personne, contenu, canal et jour, jointe à une dimension d’audience | Aucun dénominateur d’effectif dans les données du tenant |
| L’attention se maintient-elle ? | Visites répétées ou temps passé sur douze mois glissants | Faits quotidiens au niveau du contenu, au-delà de la fenêtre native | La fenêtre native tronque la tendance |
| Quel canal a réellement porté ? | Personnes uniques touchées par canal, dédoublonnées | Une clé de personne commune à SharePoint, Viva Engage, Teams et l’e-mail | Chaque source a son identifiant et la jointure ne tient pas |
| Est-ce que cela progresse ? | Le même indicateur, défini à l’identique, d’un mois sur l’autre | Des définitions figées, avec journal des modifications | Les définitions changent sans que personne le consigne |
Le modèle derrière la diapositive
Fixer la maille une bonne fois
L’erreur la plus coûteuse consiste à agréger trop tôt. Si votre chaîne dépose des compteurs de vues quotidiens par site, vous avez déjà perdu toute réponse à la question « combien de personnes distinctes ? », car les comptages distincts ne s’additionnent pas. Trois visites d’une personne et une visite de trois personnes produisent le même chiffre après agrégation, avec un sens radicalement différent.
Déposez les faits à la maille personne, contenu, canal, jour, puis agrégez dans la couche d’indicateurs. Cela coûte du stockage. C’est aussi la différence entre un rapport qui répond aux questions de suivi et un rapport qui provoque une deuxième réunion.
La dimension d’audience est celle qui compte
Tout ce qui a de la valeur dans un reporting de communication interne vient de la jointure entre l’activité et la structure organisationnelle : une dimension personne alimentée par Entra ID ou un extrait RH, portant la fonction, le pays, le site, la langue et le type de contrat. Microsoft 365 vous donne l’activité, pas cela, et c’est pourtant là que se trouve l’analyse. Notre note sur la segmentation d’audience explique comment structurer ces attributs en amont.
Deux points de gouvernance, aucun facultatif. Convenez avec la DRH et le comité social et économique des attributs utilisables pour le reporting de communication. Puis fixez une taille minimale de segment dans le modèle, afin qu’aucun visuel ne puisse afficher un groupe assez petit pour identifier une personne. Un rapport dans lequel on descend jusqu’à un individu cesse d’être un rapport de communication.
Gardez aussi la liste d’indicateurs courte. Dix indicateurs bien définis valent mieux que soixante, nommés dans le vocabulaire du comité de direction plutôt que dans celui de l’API, avec une page de définitions consignant chaque formule, sa source et sa date de modification.
Ce que personne ne met dans le plan de projet
Un développement Power BI sur des données Microsoft 365 n’est pas un projet de tableau de bord. C’est un projet de chaîne de données avec un tableau de bord au bout, et c’est la chaîne qui consomme l’effort[2]. Trois éléments méritent d’être connus avant de vous engager.
D’abord, l’API de reporting Microsoft Graph n’est pas régulièrement fiable. Elle produit des journées de données manquantes. Sur une courbe, une journée manquante ne s’annonce pas : elle creuse un trou, et l’équipe passera un après-midi à l’expliquer avant de découvrir qu’il n’y avait rien à expliquer[3].
Ensuite, 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. Pas des écarts spectaculaires, faciles à repérer, mais des écarts suffisants pour qu’un dirigeant ayant les deux écrans ouverts demande lequel dit vrai. Cette question, posée une fois en comité de pilotage, a mis fin à davantage de projets que n’importe quelle panne technique.
Enfin, un développement fiable exige donc un processus d’ingestion solide et un rapprochement planifié avec les chiffres natifs, sous la responsabilité d’une personne identifiée. Budgétez le pipeline plutôt que le tableau de bord. Les visuels représentent deux jours de travail ; l’ingestion, les reprises, le dédoublonnage, la correspondance des identités et le rapprochement mensuel constituent le vrai projet.
Un détail surprend souvent tard : le centre d’administration Microsoft 365 propose un paramètre de confidentialité qui masque les noms d’utilisateurs, de groupes et de sites dans tous les rapports. Si votre tenant l’active, et beaucoup d’organisations régulées le font, la jointure au niveau de la personne ne fonctionne pas tant qu’il n’est pas désactivé avec les validations nécessaires. Vérifiez-le en semaine un, pas au troisième mois.
Mettre le rapprochement sur une page
Les équipes dont le reporting Power BI survit ont toutes fait la même chose, peu spectaculaire : une page qualité de données dans le rapport, laissée visible. Lignes chargées par source et par jour, avec signalement de toute journée à zéro. Une ligne d’écart comparant votre chiffre de portée aux statistiques natives des sites SharePoint sur un échantillon témoin[4]. La date du dernier rafraîchissement réussi, en gros caractères.
Elle attrape les défaillances silencieuses avant la revue, et lorsqu’un chiffre est contesté vous l’ouvrez au lieu de promettre de vérifier.
Ce qui va réellement sur la diapositive mensuelle
Une diapositive, le reste en annexe. Elle porte le taux de portée du mois face à la cible, ce même taux ventilé sur les deux segments qui comptent ce mois-ci plutôt que sur les douze, la direction prise sur six mois, et une phrase d’interprétation écrite par un humain. C’est cette phrase qui vous vaut d’être réinvité. Notre guide du reporting exécutif va plus loin sur le cadrage, et le modèle de reporting mensuel donne une structure de départ.
Quand Power BI est le bon choix, et quand il ne l’est pas
Power BI est le bon choix plus souvent que les éditeurs ne l’admettent. Si votre périmètre porte sur un seul canal, que vos questions sont stables, que vous disposez d’un ingénieur données et que la licence est déjà payée, construisez-le et gardez-en la maîtrise.
C’est le mauvais choix lorsque l’équipe de communication interne finit par porter le pipeline. Cela tient jusqu’au jour où la personne qui l’a construit change de poste, après quoi le rapport se dégrade discrètement pendant deux trimestres. C’est aussi le mauvais choix lorsque le périmètre est réellement multicanal : la correspondance des identités entre SharePoint, Viva Engage, Teams et votre outil de newsletter est la partie la plus difficile de l’exercice, et Power BI vous laissera volontiers la remettre à plus tard. Notre article sur la mesure des communications internes multicanales détaille cette jointure.
Tryane se place dans ce second cas : la plateforme lit ces canaux ensemble, rapproche l’activité de la structure organisationnelle via Entra ID ou un fichier RH, conserve l’historique au travers des transitions produit, et renvoie le modèle vers Power BI si c’est là que votre organisation regarde. Vous gardez l’interface et cessez d’entretenir la chaîne. Côté pratique : SOC 2 Type 2, conformité RGPD par conception, hébergement européen par défaut avec résidence des données aux États-Unis sur demande, authentification unique via Entra ID, déploiement en quelques heures, aucun agent à installer. Pour le ROI d’une campagne, voir le ROI des campagnes internes dans Power BI.
Questions fréquentes
Combien de temps faut-il pour construire un reporting de communication interne sous Power BI ?
Les visuels prennent quelques jours. Le pipeline prend des mois, car il faut deux ou trois cycles de rapprochement avant que quiconque fasse confiance aux chiffres. Une estimation de trois semaines chiffre le tableau de bord, pas les données.
Puis-je exprimer la portée en pourcentage sans fichier RH ?
Pas de façon fiable. Un pourcentage exige un dénominateur, et les données d’activité Microsoft 365 disent qui a fait quelque chose, pas combien de personnes auraient pu le faire. Entra ID vous mène une partie du chemin si la fonction et le pays sont bien renseignés, mais le type de contrat et le site viennent en général du SIRH. Sans dénominateur, vous rapportez du volume, et le volume ne répond pas à la question posée.
Pourquoi mes chiffres Power BI diffèrent-ils des statistiques de page SharePoint ?
Plusieurs causes se cumulent : règles de dédoublonnage différentes, traitement différent des comptes de service, fuseaux horaires, et journées où l’API Graph n’a rien renvoyé. Des clients observent régulièrement des valeurs qui ne se rapprochent pas des rapports natifs sur la même période. La solution n’est pas de chercher le chiffre vrai, mais de publier une définition documentée, de rapprocher selon un calendrier et d’afficher l’écart ouvertement.
L’équipe de communication interne doit-elle être propriétaire du modèle Power BI ?
Elle doit être propriétaire des définitions d’indicateurs et de la diapositive. Pas de l’ingestion. Quand la communication porte le pipeline, la maintenance entre en concurrence avec les campagnes et perd.
Tryane remplace-t-il Power BI ?
Non. De nombreux clients conservent Power BI comme couche de restitution et utilisent Tryane comme couche de mesure qui l’alimente, ce qui supprime la charge d’ingestion et de rapprochement tout en laissant les rapports là où l’organisation les cherche déjà. Le reporting natif Microsoft continue de faire ce qu’il fait ; Tryane ajoute la jointure multicanale, la segmentation organisationnelle et l’historique.
Sources
• Microsoft Learn, rapports d’activité Microsoft 365
• Microsoft Learn, présentation de Power BI
• Microsoft Learn, API de reporting Microsoft Graph
• Microsoft Learn, statistiques de site SharePoint
Pour aller plus loin
• Analyser SharePoint avec Power BI
• Construire des analytics SharePoint avec Power BI, un guide honnête
• Construire un tableau de bord de communication interne
• Les indicateurs de communication interne 2026
Tryane anime une session de travail de 15 minutes avec les directions de la communication interne, pour passer en revue votre dispositif Power BI actuel et montrer où se situent les angles morts de segmentation et de rapprochement sur votre propre tenant. Réservez un créneau avec Jérémy.