Quand une entreprise structure son système d’information pour alimenter ses rapports décisionnels, la question du raccordement des données se pose très tôt. Deux approches coexistent : le plan BI connection, qui centralise les flux autour de quelques sources gouvernées, et les connecteurs classiques, qui multiplient les liaisons directes entre applications et outils de reporting comme Power BI Desktop. Le choix entre ces deux modèles engage la maintenabilité, la sécurité et le coût réel du SI sur plusieurs années.
Gouvernance DLP et connecteurs : ce qui change côté tenant
Les politiques de prévention de perte de données (DLP) appliquées au niveau du tenant Microsoft transforment la manière dont les connecteurs sont exploités. La règle de base est simple : la politique la plus restrictive l’emporte, connecteur par connecteur. Une stratégie DLP tenant-wide combinée à des politiques d’environnement crée un filtre qui peut rendre inopérant tout connecteur non explicitement autorisé.
Plusieurs DSI structurent désormais leurs connecteurs en tiers hiérarchisés :
- Tier 1 (coeur SI) : SharePoint, Dataverse, Azure SQL, sources validées et exposées via un modèle de données central.
- Tier 2 (SaaS partenaires) : connecteurs vers des plateformes métier identifiées, soumis à validation préalable.
- Tier 3 (custom/expérimental) : connecteurs sur mesure ou peu répandus, limités à des environnements de test.
- Tier 4 (personnel/consommateur) : bloqué par défaut, sans dérogation possible.
Ce cadre pénalise mécaniquement les architectures reposant sur une multitude de connecteurs applicatifs. Sans configuration d’allowlist, nombre de connecteurs restent inopérants après déploiement d’une DLP tenant-wide. L’approche plan BI, qui concentre les flux sur quelques sources centrales (OneLake, Dataverse, SQL), s’inscrit naturellement dans ce modèle de gouvernance.
Connecteurs natifs Power BI Desktop : capacités réelles et limites terrain
Power BI Desktop affiche la compatibilité avec un grand nombre de sources de données. La liste inclut des bases SQL, des fichiers Excel, des services Microsoft (Dynamics, SharePoint) et des plateformes anglo-saxonnes comme Salesforce ou Google Analytics. L’interface propose deux expériences d’accès aux données : la nouvelle expérience Power Query (en préversion) et l’expérience classique via la boîte de dialogue « Obtenir des données ».
Sur le papier, la couverture paraît large. En pratique, les retours terrain divergent sur un point précis : les logiciels métier français ne disposent quasiment pas de connecteur natif. Sage, Cegid, ACD, Pennylane, Silae ou encore Tiime ne figurent pas dans le catalogue « click and load » de Microsoft.
Ce que cela implique pour un projet de reporting
Quand un connecteur natif n’existe pas, trois chemins restent possibles : l’export manuel (FEC, CSV, balances), la connexion via ODBC ou API REST, ou le recours à une plateforme SaaS intermédiaire. Chacun a un coût de mise en oeuvre et de maintenance différent.
L’export manuel fonctionne pour un prototype. Il devient un goulet d’étranglement dès que la fréquence de rafraîchissement dépasse le rythme mensuel. La connexion ODBC ou API demande un développement technique et une passerelle Power BI Gateway, dont la configuration et la maintenance sont souvent sous-estimées. Les plateformes SaaS spécialisées réduisent le temps de raccordement, mais ajoutent une couche de dépendance et un abonnement récurrent.
Plan BI connection : centraliser les sources pour réduire la dette technique
L’approche plan BI ne consiste pas simplement à « acheter un outil de BI ». Elle repose sur une architecture où quelques sources centrales sont approuvées et exposées via un modèle de données unique, plutôt que via une prolifération de connecteurs point à point.
Le principe est celui du hub : les données métier transitent par un entrepôt ou un lakehouse (OneLake dans l’écosystème Microsoft Fabric, par exemple) avant d’être consommées par les rapports. Les connecteurs existent toujours, mais ils alimentent le hub, pas directement les rapports Power BI.
Avantage concret sur la maintenance
Quand un éditeur modifie son API ou son schéma de données, une architecture en connecteurs directs oblige à corriger chaque rapport impacté. Avec un plan BI centralisé, la correction se fait une seule fois au niveau de l’ingestion dans le hub. Le nombre de points de rupture diminue proportionnellement au nombre de rapports raccordés.
Cette réduction de la surface de maintenance explique pourquoi les stratégies DLP hiérarchisées favorisent les architectures centralisées. Moins de connecteurs actifs signifie moins de vecteurs à surveiller, moins de politiques d’exception à gérer.
Connecteurs classiques ou plan BI : critères de décision pour votre SI
Le choix ne se résume pas à une opposition binaire. Certains contextes justifient les connecteurs directs, d’autres appellent un investissement dans un plan BI structuré.
Les connecteurs classiques restent pertinents quand le SI comporte peu de sources, que les rapports sont consommés par une équipe restreinte et que la fréquence de rafraîchissement reste modérée. Un cabinet qui exploite deux logiciels comptables et produit des tableaux de bord mensuels n’a pas forcément besoin d’un lakehouse.
En revanche, dès que le nombre de sources dépasse la demi-douzaine, que plusieurs équipes consomment des rapports avec des besoins de rafraîchissement quotidien ou temps réel, la dette technique des connecteurs directs croît plus vite que le nombre de rapports. L’investissement initial d’un plan BI se rentabilise alors sur la réduction du temps passé à corriger les ruptures de flux et à gérer les accès.
La question du mode de requête
Le choix entre Import, DirectQuery et Direct Lake (pour les environnements Fabric) influence aussi la pertinence de chaque approche. Un mode Import avec des connecteurs classiques copie les données dans le modèle Power BI, ce qui fonctionne bien pour des volumes modérés. DirectQuery interroge la source en temps réel, mais les performances dépendent de la qualité du connecteur et de la latence réseau.
Direct Lake, propre à Fabric, lit directement les fichiers Parquet dans OneLake sans copie ni requête distante. Ce mode suppose une architecture centralisée préalable.
Les données disponibles ne permettent pas de fixer un seuil universel de bascule entre connecteurs classiques et plan BI. Le point de bascule dépend du nombre de sources, du volume de données, de la fréquence de rafraîchissement et de la maturité de l’équipe data. Un audit du SI existant, centré sur le temps réel passé à maintenir les connexions, reste le meilleur indicateur pour trancher.
