« Deux équipes ont apporté deux chiffres de revenus à la même réunion »
La version qu’on entend le plus souvent a une texture précise. Il existe un cahier mensuel dont des gens haut placés dépendent, et il est assemblé à partir d’exportations. Une analyste entretient un chiffrier qui porte réellement l’organisation, tout le monde sait que c’est un risque, et personne n’a le temps de le régler. Il y a une tâche nocturne qui a échoué en silence plus d’une fois, découverte seulement parce qu’un chiffre paraissait étrange.
En dessous, il y a habituellement deux ou trois définitions de la même mesure, chacune défendable. Les finances comptent le revenu à la facturation, les opérations à la livraison, l’équipe client à la signature. Aucune n’est fausse. Personne n’a écrit laquelle sert au cahier du conseil, alors la discussion revient chaque mois et se fait attribuer à des « données de mauvaise qualité ».
Puis un projet d’IA arrive, doit s’ancrer sur ces mêmes données, et cale au deuxième mois. C’est là que le problème de reporting cesse d’être un inconfort et devient un blocage sur un dossier suivi par la direction.
Pourquoi la réponse habituelle échoue
Acheter la plateforme et déplacer l’entrepôt. Le programme le plus fréquent est une migration : lever le schéma existant vers Microsoft Fabric ou un nouvel entrepôt, repointer les rapports, déclarer la modernisation faite. Ce qui arrive de l’autre côté, ce sont les mêmes définitions contradictoires, les mêmes transformations non documentées et le même vide de propriété, désormais sur une capacité que vous payez au mois. Le moteur de stockage n’était pas la contrainte. Reproduire fidèlement la sémantique est exactement ce qu’il ne fallait pas faire.
Le libre-service comme stratégie. Donner Power BI, un espace de travail et une journée de formation à chaque équipe. Ça produit un vrai gain de vitesse et une sérieuse détérioration de l’accord, parce que quarante jeux de données bâtis indépendamment sur la même source encoderont quarante opinions légèrement différentes. Le libre-service sans modèles sémantiques certifiés en dessous, c’est du désaccord décentralisé avec de plus beaux graphiques. Le correctif n’est pas de retirer l’outil, c’est d’offrir un modèle certifié pour que le chemin rapide et le chemin correct soient le même.
La gouvernance comme documentation. On achète un catalogue, on rédige un dictionnaire de données, un comité d’intendance se réunit. Six mois plus tard, le catalogue décrit le parc tel qu’il était à la rédaction. Une gouvernance qui n’est pas appliquée là où les données sont consommées, par certification, traçabilité, classification et contrôle d’accès, se dégrade en wiki que personne n’ouvre.
Vouloir tout modéliser d’abord. Un modèle de données d’entreprise couvrant tous les domaines, conçu avant toute livraison. Dix-huit mois de modélisation, aucune décision servie, et un commanditaire qui a changé de poste entre-temps. L’alternative n’est pas d’abandonner le modèle, c’est de le construire un domaine à la fois, contre une décision que quelqu’un attend.
La capacité achetée avant la charge. Une F-SKU choisie dans un tableau de dimensionnement plutôt que par la mesure. Trop petite, les actualisations sont limitées dès le premier mois, et la plateforme y perd sa crédibilité. Trop grande, elle devient la ligne que les finances pointent du doigt. Ni l’un ni l’autre ne se rattrape par l’argumentation.
Comment nous construisons la couche gouvernée
Partir d’un chiffre contesté. Nous prenons la mesure qui cause la dispute récurrente, nous la traçons jusqu’à la source, et nous faisons convenir la définition par écrit avec un propriétaire nommé. C’est ingrat et c’est le travail. Un modèle sémantique encode une décision : si la décision n’est pas prise, le modèle la prendra en silence.
Un lakehouse, en couches. Microsoft Fabric avec une structure en médaillon : réception brute, données conformées, puis une couche organisée que lisent la BI et l’IA. Des pipelines Data Factory avec des contrats testés, des alertes en cas d’échec et une politique de reprise, en remplacement de la tâche nocturne qui échoue sans prévenir.
Des modèles sémantiques certifiés, pas des exportations. Modèles Direct Lake sur la couche organisée, avec sécurité au niveau des lignes et des objets pour qu’un seul modèle serve des publics qui ne doivent pas voir les mêmes lignes. Jeux de données certifiés et pipelines de déploiement, pour que le chemin de moindre effort d’un analyste soit le chemin gouverné.
Un catalogue réellement appliqué. Microsoft Purview pour la traçabilité, la classification et les étiquettes de confidentialité, appliquées aux données qui portent des obligations plutôt qu’à tout. Quand ces obligations sont formelles, les règles de rétention et de résidence viennent de l’ architecture de conformité et sont imposées par politique au niveau de la plateforme. Les données cliniques ajoutent un cloisonnement, décrit dans nos travaux en santé.
Une seule couche pour la BI et pour l’IA. La même couche organisée ancre la recherche, ce qui fait qu’un assistant répond avec des chiffres que l’organisation accepte déjà. Construire une deuxième pile pour l’IA, c’est se donner une quatrième définition du revenu. C’est le passage vers l’ingénierie IA sur Azure AI Foundry, et la raison pour laquelle un projet d’agent qui cale sur la qualité des données appartient souvent ici d’abord.
La gouvernance de capacité dès le départ. Stratégie d’espaces de travail, surveillance de la capacité, et dimensionnement F-SKU décidé à la fin de la construction sur le comportement mesuré. Réservation achetée sur des faits, avec la même discipline que notre optimisation des coûts cloud.
Le mandat qui livre ça
Huit semaines, un domaine, de bout en bout. Les semaines 1 et 2 font convenir les définitions, cartographient les sources et choisissent les décisions que le domaine doit soutenir. Les semaines 3 à 5 construisent les couches du lakehouse, les pipelines et le premier modèle sémantique certifié, avec quelque chose de relisible chaque semaine. Les semaines 6 et 7 reconstruisent les rapports qui comptent sur le modèle certifié, appliquent la sécurité et retirent les doublons avec leurs propriétaires. La semaine 8 couvre le dimensionnement de capacité, la configuration Purview, la documentation et le transfert.
Vous gardez les pipelines et les modèles en code dans votre dépôt, les définitions de mesures écrites avec leurs propriétaires, le modèle de sécurité, les preuves de dimensionnement et un backlog des domaines que nous n’avons volontairement pas touchés.
Tout ceci suppose un parc Azure gouverné en dessous. Quand la plateforme se construit dans un environnement sans groupes d’administration, sans politiques et sans modèle réseau, la landing zone Azure passe en premier : une plateforme de données déployée dans une souscription non gouvernée hérite de tous les problèmes de cette souscription.
Questions fréquentes
Faut-il tout déplacer dans Fabric ?
Non, et commencer ainsi est l’erreur habituelle. Nous construisons un domaine de bout en bout, nous prouvons les chiffres contre la source, puis nous étendons. Les entrepôts existants, les bases Azure SQL et les systèmes métier restent où ils sont et alimentent la couche gouvernée. Une plateforme à laquelle personne ne fait encore confiance ne mérite pas une migration complète.
Est-ce un problème technique ou organisationnel ?
Les deux, et la moitié organisationnelle est la plus grosse. Deux équipes qui rapportent des revenus différents ont généralement deux définitions défendables, pas un pipeline brisé. Le mandat consacre du temps réel à faire convenir ces définitions et à les écrire avec un propriétaire nommé, parce qu’un modèle sémantique encode une décision et que quelqu’un doit la prendre.
Quelle capacité F-SKU nous faut-il ?
Nous ne la dimensionnerons pas avant de mesurer. Une capacité achetée avant la charge est soit en limitation sous pression, soit inutilisée à vos frais, et les deux minent la plateforme politiquement. Nous démarrons sur une petite capacité, nous mesurons le comportement réel des actualisations et des requêtes pendant la construction, puis nous dimensionnons la réservation sur des faits.
Notre projet d’IA est bloqué par la qualité des données. Est-ce le correctif ?
Souvent, oui. Ancrer un assistant sur des chiffres que deux services contestent produit des réponses assurées que personne n’accepte. Une seule couche gouvernée servant à la fois Power BI et la recherche pour l’IA fait disparaître l’argument, et c’est pourquoi nous traitons la BI et l’ancrage de l’IA comme une seule plateforme plutôt que deux piles.
Que deviennent les quarante rapports Power BI existants ?
Ils sont triés, pas conservés en bloc. La plupart des parcs comptent une poignée de rapports qui portent de vraies décisions et une longue traîne qui les duplique. Nous identifions ceux qui comptent, nous les reconstruisons sur des modèles sémantiques certifiés avec sécurité au niveau des lignes, et nous retirons les autres avec leurs propriétaires plutôt qu’à leur insu.
Comment éviter que ça dérive à nouveau ?
Jeux de données certifiés, discipline des espaces de travail et des pipelines de déploiement, traçabilité et classification dans Microsoft Purview, et une règle simple : un rapport utilisé dans une décision gouvernée doit être bâti sur un modèle certifié. Une gouvernance qui n’est pas appliquée au point de consommation devient une page de wiki en un trimestre.