Plateforme de données

Implantation de Microsoft Fabric

Fabric vaut le coup quand il remplace quelque chose : une dispersion d’extractions, un entrepôt que personne n’ose modifier, ou deux piles là où une seule couche gouvernée suffirait. Nous livrons le lakehouse, les pipelines et les modèles sémantiques, et la gouvernance qui les garde fiables au douzième mois.

Ce que nous construisons

Nous implantons Microsoft Fabric comme couche de données unique et gouvernée, dimensionnée en fonction de votre charge réelle, qui alimente à la fois la restitution et l’ancrage des charges d’IA à partir des mêmes tables. L’alternative avec laquelle la plupart des organisations arrivent, c’est un entrepôt pour les rapports et une copie séparée pour le projet d’IA : deux fois plus de pipelines, et la garantie que les deux ne diront pas la même chose.

Conception du lakehouse et de l’entrepôt. Un modèle en couches : atterrissage brut, données nettoyées et conformées, puis tables métier qu’un rapport ou un agent peut consommer sans mise en garde. Nous disons explicitement quelles charges relèvent du lakehouse et lesquelles relèvent de l’entrepôt, parce que tout mettre dans celui qu’on connaît est l’erreur de conception dont nous héritons le plus souvent.

Pipelines Data Factory. Ingestion depuis SQL Server, Azure SQL, SAP, dépôts de fichiers plats, Dataverse et API métier. En incrémental quand la source le permet, en rechargement complet sinon, avec une gestion d’échec qui déclenche une alerte au lieu de laisser tranquillement les chiffres de la veille en place. Une donnée périmée en silence est pire qu’une panne : personne ne cesse de faire confiance au rapport.

Modèles sémantiques Direct Lake. Des modèles qui lisent directement les tables du lakehouse, ce qui supprime la fenêtre de rafraîchissement et la copie des données qui allait avec. Nous écrivons les mesures, la logique de calendrier, la sécurité au niveau des lignes et les descriptions de champs que le métier lit vraiment dans la liste de champs.

Gouvernance des espaces de travail et de la capacité. Une structure qui sépare développement, test et production, avec des pipelines de déploiement entre les trois et des accès accordés par groupes Entra ID plutôt que par personne nommée. Les métriques de capacité sont visibles pour ceux qui peuvent agir : un carnet qui s’emballe devient une conversation le jour même, pas une surprise sur la facture.

Catalogage et classification. Microsoft Purview sur le parc : ce qui existe, qui en est propriétaire, ce qui est sensible et où ça a le droit de circuler. C’est ce qui permet de répondre, en une séance, à la question de savoir si une table contenant des renseignements personnels alimente un rapport partagé avec un fournisseur. Utile bien au-delà de l’analytique quand la Loi 25 s’applique.

Dimensionnement F, mesuré. Nous démarrons prudemment, nous instrumentons la capacité, et nous redimensionnons sur deux mois de consommation réelle.

Le chemin d’une donnée dans un espace de travail Fabric De la source au rapport, à lire vers le bas. Les pipelines déposent la donnée brute, trois zones ordonnées la rendent fiable, et l’entrepôt comme le modèle sémantique lisent les mêmes tables plutôt que chacun sa copie. C’est un dessin d’espace de travail dans notre propre typographie, pas une capture et pas un logo.
Espace de travail Microsoft Fabric Analytique, production Une capacité, une couche de stockage, un seul jeu de fichiers. Tous les éléments ci-dessous lisent les mêmes tables, et aucun ne garde une seconde copie qui s’écarterait en silence.

D’où vient la donnée

  • Système source Azure SQL La base transactionnelle, lue selon un horaire plutôt qu’exportée à la main dans un fichier qui devient ensuite la version à laquelle quelqu’un se fie.
  • Système source Dataverse Les applications métier, lues par leur propre connecteur : aucun extrait à maintenir, donc aucun extrait à oublier.
  • Système source Dépôt de fichiers Le fichier mensuel qui arrive encore par courriel dans la plupart des organisations. Traité comme une vraie source, avec un contrôle d’arrivée, plutôt que passé sous silence.

Ce qui la dépose, selon un horaire

  • Pipeline Data Factory Ingestion Incrémentale quand la source le permet, rechargement complet sinon, et une alerte en cas d’échec. Une donnée périmée en silence est pire qu’une panne, parce que personne ne cesse de se fier au rapport.
  • Notebook Mise en conformité Types corrigés, doublons résolus, le même client identifié de la même façon dans trois systèmes. C’est là qu’est l’essentiel du travail.

Lakehouse, trois zones, dans cet ordre

Lakehouse Tables curées Trois zones d’un seul lakehouse, et non trois produits. La donnée descend la liste sans jamais sauter une étape, ce qui rend un chiffre contesté traçable jusqu’à ce qui est arrivé, et quand.
  1. Zone bronze Brut, tel qu’arrivé Exactement ce que la source a envoyé, non modifié et daté. Rien en aval n’a le droit de le lire.
  2. Zone argent Nettoyé et conformé Dédoublonné, typé, joint sur des clés qui concordent. Ce n’est pas encore une réponse d’affaires.
  3. Zone or Prêt pour l’usage Les tables vers lesquelles un rapport ou un agent peuvent être pointés sans réserve. La seule zone que l’aval lit.

Ce qui lit les tables de la zone or

  • Entrepôt Entrepôt de rapports Pour les charges qui veulent un schéma strict et du SQL. Nous disons lesquelles vont là et lesquelles vont dans le lakehouse : tout mettre dans celui que l’on connaît est l’erreur de conception que nous héritons le plus souvent.
  • Direct Lake Modèle sémantique Lit directement les tables de la zone or : plus de fenêtre d’actualisation d’import, et plus de seconde copie des données à laisser se décaler. Les mesures, la logique de dates et la sécurité par ligne vivent ici, une seule fois.

Ce que les gens et les agents ouvrent

  • Power BI Rapport certifié Bâti sur le modèle partagé plutôt que sur sa propre copie de la logique, ce qui est la façon dont deux rapports cessent de donner deux réponses à la même question.
  • Ancrage Charge d’IA Les mêmes tables curées ancrent un agent, au lieu d’un second jeu de pipelines bâti pour l’alimenter à part. Une couche gouvernée, pas deux piles.

En dessous de tout cela

  • Stockage Une seule couche de stockage pour l’espace de travail Tout ce qui précède y est rattaché. Le lakehouse, l’entrepôt et le modèle sémantique lisent un seul jeu de fichiers, et non trois copies de celui-ci.
  • Gouvernance Microsoft Purview Ce qui existe, qui en est responsable, ce qui est sensible et jusqu’où cela peut circuler. Savoir si une table contenant des renseignements personnels alimente un rapport partagé à l’extérieur doit se répondre en une séance.
  • Accès Microsoft Entra ID L’accès à l’espace de travail est accordé à des groupes plutôt qu’à des personnes nommées : il suit le mouvement de personnel au lieu d’un tableur que personne n’a mis à jour.
  • Livraison Pipelines de déploiement Développement, test et production, avec les définitions des éléments dans votre propre dépôt Git. Rien d’important n’existe uniquement dans un portail.
  • Un dessin, pas une capture. Reproduire l’interface du produit ou son logo serait imiter une marque déposée, et une imitation approximative se repère aussitôt chez qui utilise l’outil tous les jours.
  • Les trois zones sont numérotées et non coloriées. C’est l’ordre qui porte le sens, et la couleur seule ne porte jamais d’information ici.
  • Chaque boîte est un élément d’un même espace de travail, déployé depuis votre dépôt plutôt que créé au clic.

Fabric, ou pas

Nous déconseillons Fabric plus souvent que le marché ne s’y attend. Si tout votre besoin analytique tient en huit rapports sur une seule base transactionnelle, un modèle sémantique Power BI bien construit sur une licence Pro y répond, et une capacité Fabric n’est qu’un coût d’exploitation sans contrepartie.

Fabric se justifie quand au moins deux de ces conditions sont vraies : plusieurs sources à conformer, un volume où les rafraîchissements d’import sont devenus un problème d’ordonnancement, une vraie exigence de gouvernance, ou une charge d’IA qui a besoin de données d’ancrage curées plutôt que d’un déversement de documents.

Comment le mandat se déroule

Semaines 1 et 2, sources et décisions. Inventaire des sources, accord sur le modèle en couches, structure des espaces de travail et de la capacité, choix des deux premiers domaines d’affaires par valeur métier et non par facilité d’extraction. Livrable : un registre de décisions écrit et un schéma cible.

Semaines 3 à 6, premier domaine de bout en bout. Ingestion, transformation, tables curées, modèle sémantique et un rapport en production. Le bout en bout compte : un pipeline sans rapport au bout ne prouve rien.

Semaines 7 et 8, deuxième domaine et gouvernance. Le deuxième domaine est construit majoritairement par votre équipe, sous notre revue. C’est là que le transfert a réellement lieu. En parallèle : catalogue Purview, étiquettes de confidentialité, pipelines de déploiement, alertes de capacité.

Semaines 9 et 10, durcissement et transfert. Tests de modes de défaillance sur les pipelines, réglage de la capacité sur deux mois de métriques, documentation, et une séance de travail avec ceux qui reprennent la plateforme.

Ce que vous gardez

  • Carnets, définitions de pipelines et de modèles sémantiques dans votre dépôt Git.
  • Le modèle de données en couches documenté, avec la raison du placement de chaque table.
  • Les pipelines de déploiement entre développement, test et production, déjà utilisés deux fois.
  • Un catalogue Purview avec propriétaires et classifications sur les tables qui comptent.
  • L’analyse de dimensionnement de la capacité, avec les données de consommation derrière.
  • Une procédure d’incident de pipeline, écrite pour la personne de garde et non pour nous.
  • Un backlog priorisé des domaines non encore construits, avec notre estimation pour chacun.

Pour qui c’est

Des organisations avec plusieurs systèmes sources qui se contredisent, une restitution bâtie sur des extractions, et une direction qui a décidé qu’un chiffre contesté devait se trancher en une heure plutôt qu’en une semaine. C’est la suite naturelle une fois qu’une landing zone Azure existe, et la couche que nous recommandons de bâtir avant un projet d’ingénierie IA.

Pour qui ce n’est pas

Si vous avez une source propre et une poignée de rapports, n’achetez pas de capacité. Construisez le modèle sémantique.

Si personne dans le métier n’accepte d’être propriétaire d’une définition, Fabric n’y changera rien. La plateforme peut montrer que deux directions calculent le revenu différemment. Elle ne peut pas décider laquelle a raison, et nous n’avons jamais vu un outil trancher ce débat.

Si votre besoin est le pilotage en temps réel d’un procédé en usine, ce n’est ni le bon outil ni la bonne latence. Et si l’intention est d’acheter la plateforme et de la doter en personnel plus tard, elle se dégradera en silence jusqu’au premier audit des chiffres.

Pages liées

Questions fréquentes

Quelle capacité F nous faut-il ?

Nous la dimensionnons à partir de la charge mesurée, pas d’un tableau de fournisseur. En pratique, la plupart des organisations de moins de 500 personnes démarrent en F8 ou F16, observent deux mois de métriques de capacité, puis ajustent. La capacité se met en pause et se redimensionne : l’erreur coûteuse est de réserver une F64 avant que quiconque ait mesuré un rafraîchissement.

Faut-il encore Power BI Premium ?

Une capacité Fabric couvre les charges Power BI, donc la plupart des parcs consolident sur une seule capacité au lieu d’en exploiter deux. L’exception est un locataire dont le profil d’usage convient au Premium par utilisateur. Nous modélisons les deux avant de recommander, parce que c’est presque toujours la plus grosse ligne du budget de la plateforme.

Fabric peut-il remplacer notre entrepôt actuel ?

Parfois. Si votre entrepôt est un SQL Server vieillissant qui porte la logique de calcul dans des procédures stockées, Fabric est une cible crédible et nous le migrons. Si c’est une plateforme bien réglée que votre équipe maîtrise et que le vrai problème est la couche de restitution, la remplacer relève du théâtre coûteux.

En quoi c’est différent de bâtir le lakehouse nous-mêmes ?

Vous n’avez peut-être pas besoin de nous pour le lakehouse. Ce qui casse au sixième mois, c’est la gouvernance des espaces de travail et de la capacité, le déploiement entre environnements, la propriété des modèles sémantiques et l’absence de traçabilité quand un chiffre est contesté. C’est cette partie que nous construisons, et c’est celle qui coûte cher à rattraper.

Où se situe Purview ?

Catalogage, classification et étiquettes de confidentialité sur les données avant qu’elles n’alimentent un rapport ou un agent. C’est le préalable que personne ne budgète, et la raison pour laquelle les projets d’IA calent au deuxième mois quand quelqu’un demande lesquelles de ces tables contiennent des renseignements personnels.

Récupérons-nous le code ?

Oui. Carnets, définitions de pipelines, définitions de modèles sémantiques et configuration des pipelines de déploiement vivent dans votre dépôt Git dès le premier sprint. Les espaces de travail Fabric sont intégrés à Git : rien d’important n’existe uniquement dans un portail.

Une question sur ce mandat ?

Trois champs. Un architecte le lit et répond en un jour ouvrable.

Tous les champs sont nécessaires.

Nous répondons à cette adresse. Rien d’autre n’y est envoyé.

L’objectif, l’échéance, et ce qui bloque. Trois lignes suffisent.

Ce que vous envoyez passe en TLS vers notre propre fonction Azure au Canada Est, puis dans notre propre CRM Odoo à Montréal. Aucun script de formulaire tiers, aucun témoin publicitaire. Nous le gardons pour vous répondre, et le supprimons après vingt-quatre mois si rien n’en découle. Politique de confidentialité.

Amenez la charge de travail. Nous apportons l’architecture.

Trente minutes, un architecte, aucune présentation. Venez avec un problème, repartez avec un avis sur lequel agir.