Copilot Studio + Microsoft Fabric : construire un agent qui lit ton data lake
Microsoft Fabric place tes données dans OneLake ; Copilot Studio te laisse construire des agents par-dessus. Voici comment les deux se connectent — grounding, l'endpoint SQL, les agents de données Fabric — et les pièges à éviter.
- Copilot Studio
- Microsoft Fabric
- OneLake
- Agents IA
- Azure
« Peut-on simplement discuter avec nos données ? » est la demande que toute équipe de données entend désormais chaque semaine. La réponse de Microsoft coud deux produits ensemble : Fabric garde les données, Copilot Studio construit l'agent qui leur parle. La démo est magique. La version de production a des arêtes vives. Voici comment les pièces s'emboîtent vraiment — et où les équipes se coupent.
Les pièces : Fabric, OneLake, Copilot Studio
Microsoft Fabric est une plateforme d'analytique SaaS qui regroupe l'ingénierie des données, le warehousing, l'analytique en temps réel et Power BI. OneLake est son data lake unique à l'échelle du tenant — pense-le comme le « OneDrive des données » — bâti sur ADLS Gen2 et, point crucial, stockant tout en Delta-Parquet ouvert. Le même format que le lakehouse Databricks, et ce n'est pas un hasard : l'industrie a largement convergé sur Delta et Iceberg comme couche de table ouverte.
Copilot Studio est la plateforme low-code de Microsoft pour construire des agents — le descendant de Power Virtual Agents. Tu donnes à un agent des instructions, des sources de connaissance et des actions, et il répond en utilisant l'IA générative. La question, c'est comment tu pointes cet agent vers le lake.
Où vivent les données : OneLake et l'endpoint SQL
Un lakehouse ou un warehouse Fabric expose ses tables Delta de deux façons qu'un agent peut utiliser. L'endpoint d'analytique SQL est une surface T-SQL en lecture seule sur les tables : tout ce qui parle SQL peut l'interroger. Le modèle sémantique se place au-dessus : mesures nommées, relations et logique métier, interrogeables en mode Direct Lake, qui lit Parquet directement depuis OneLake sans importer ni mettre en cache une seconde copie. Les shortcuts permettent à OneLake de référencer des données situées dans S3 ou un autre compte ADLS sans les déplacer, si bien que « ton data lake » peut s'étendre sur plusieurs clouds.
La leçon : un agent ancré sur un modèle sémantique bien construit est bien plus fiable qu'un agent pointé vers des tables brutes, parce que le modèle encode ce que signifie réellement un « client » ou le « chiffre d'affaires ».
Trois façons d'ancrer un agent sur ton lake
- L'agent de données Fabric (la voie native). Fabric a son propre agent d'IA — auparavant « AI Skills » — que tu construis sur un lakehouse, un warehouse ou un modèle sémantique. Il traduit le langage naturel en requêtes sur tes données, et tu peux l'ajouter dans Copilot Studio comme source de connaissance connectée. C'est la route la plus courte et celle dans laquelle Microsoft investit.
- La connaissance Copilot Studio sur un modèle sémantique. Pointe l'agent vers un modèle sémantique Power BI comme source de connaissance. Bon pour les questions-réponses sur des mesures définies ; plus faible pour les recherches ouvertes au niveau de la ligne.
- Le grounding sur mesure. Utilise Power Automate ou un connecteur personnalisé pour taper sur l'endpoint SQL, ou monte Azure OpenAI « sur tes données ». Contrôle maximal, plomberie maximale : tu prends en charge la récupération, la construction du prompt et la mise en forme du résultat.
Une construction minimale
La voie qui fonctionne le plus fiablement, de bout en bout :
- Fais atterrir les données dans un lakehouse Fabric et façonne une couche or propre — la discipline medallion s'applique ici exactement comme dans Databricks.
- Construis un petit modèle sémantique avec des mesures nommées et des relations. C'est là que la précision se gagne ou se perd.
- Crée un agent de données Fabric sur ce modèle et teste ses requêtes générées contre des réponses connues.
- Dans Copilot Studio, crée un agent, ajoute l'agent de données Fabric comme connaissance, écris des instructions serrées et publie sur Teams ou le web.
La sécurité, c'est tout l'enjeu
L'échec qui brise les carrières, c'est un agent qui renvoie joyeusement des lignes qu'un utilisateur ne devrait jamais voir. Règle ça avant de livrer :
- L'identité circule. Préfère que l'agent interroge au nom de l'utilisateur authentifié (Entra ID), et non avec un service principal fixe doté d'un accès tout-puissant.
- La sécurité au niveau de la ligne et de la colonne vit dans le modèle sémantique et le lakehouse — applique-la là, pas dans le prompt. Un prompt n'est pas une frontière de contrôle d'accès.
- Moindre privilège sur OneLake. Les shortcuts et les rôles de workspace décident de ce que l'agent peut même atteindre.
Où ça casse
- Du SQL halluciné ou incorrect. Le langage-naturel-vers-requête est probabiliste. Sans modèle sémantique pour le contraindre, l'agent invente des agrégations plausibles mais fausses. Valide toujours contre un jeu de questions de référence.
- Direct Lake retombe sur DirectQuery quand un modèle devient trop grand ou trop complexe, et la latence se dégrade en silence. Surveille-le.
- La dérive de coût. Les unités de capacité Fabric plus les appels génératifs s'additionnent. Mesure-le dès le premier jour.
Copilot Studio sur Fabric est la façon la plus rapide de donner aux utilisateurs non techniques une vraie conversation avec des données gouvernées — à condition d'investir dans le modèle sémantique et de traiter la sécurité comme un problème de la couche de données, pas du prompt. Quand tes agents dépassent le low-code et que tu dois posséder le modèle et la boucle, la pièce suivante examine le stack agentique ouvert — Hermes et NVIDIA Nemotron.
Cet article vous a été utile ?