Data Source Instructions dans Microsoft Fabric

La brique qui manquait à l’IA pour (enfin) comprendre votre modèle

Depuis l’arrivée du Copilot et des agents conversationnels dans l’écosystème Microsoft Fabric, une promesse forte est posée sur la table : permettre aux utilisateurs de dialoguer naturellement avec leurs données.
Mais dans les faits, cette promesse s’est souvent heurtée à une réalité bien connue des professionnels de la donnée : le contexte métier, les règles implicites, et la complexité des modèles ne se devinent pas.

Et c’est précisément là qu’intervient la nouveauté Data Source Instructions.

Le problème : une IA sans contexte reste une IA bancale

Lorsqu’un utilisateur interroge un agent dans Fabric avec une simple question en langage naturel, celui-ci doit décider quelle table interroger, comment construire la requête, quelles jointures appliquer, quels filtres considérer… Bref, il fait des hypothèses.

Et sans guide clair, ces hypothèses sont parfois complètement à côté de la plaque.

Jusqu’à maintenant, la configuration de ces agents se faisait principalement à un niveau global. On pouvait donner quelques grandes orientations, mais cela restait souvent trop générique pour gérer des jeux de données un peu riches, ou des logiques métier fines.

Ce que Microsoft ajoute avec les Data Source Instructions

Avec cette mise à jour, chaque source de données connectée à un agent peut désormais recevoir ses propres instructions spécifiques.

On parle ici de la possibilité de documenter, orienter, cadrer le comportement de l’agent au niveau de chaque source, et non plus uniquement de manière globale.

En pratique, cela permet de :

• Prioriser certaines tables selon les cas d’usage.
• Définir des jointures par défaut à appliquer systématiquement.
• Expliquer la signification métier de certaines colonnes (codes région, statut, etc.).
• Ajouter des filtres implicites qui reflètent les règles business (ne prendre en compte que les données actives, par exemple).
• Uniformiser l’interprétation des requêtes même lorsque la terminologie est floue côté utilisateur.

Ce que ça change vraiment

Ce n’est pas une simple option en plus dans la configuration de vos agents.
C’est un changement de paradigme.

Là où auparavant l’IA tentait de « faire de son mieux », elle peut désormais travailler avec des consignes explicites, proches d’un cahier des charges, source par source.

C’est exactement comme si vous ajoutiez une couche de documentation technique et métier que l’agent peut lire, comprendre et appliquer à chaque requête.

Et dans des contextes où :

• plusieurs sources contiennent des données similaires,
• des règles métiers évoluent dans le temps,
• certaines jointures sont obligatoires pour éviter les erreurs d’analyse,

… cette fonctionnalité est tout simplement vitale.

Exemples concrets d’instructions

Quelques exemples d’instructions que vous pouvez maintenant définir :

• « Lorsque la question porte sur les ventes passées, utilisez la table Orders et appliquez un filtre sur OrderDate. »
• « Joindre systématiquement Sales et Products via ProductID avant d’agréger des montants. »
• « La colonne State contient des abréviations : utilisez ‘CA’, ‘NY’ et non ‘California’ ou ‘New York’. »
• « Ne jamais afficher les lignes dont le statut est ‘Archivé’. »

Mon retour terrain : un vrai pas en avant, mais pas une baguette magique

Cette nouveauté est une excellente nouvelle pour les équipes data, mais elle demande de la rigueur. Voici quelques points d’attention si vous voulez en tirer parti :

1. Il faut investir du temps.
Écrire des instructions claires, utiles et robustes, ça ne se fait pas en 5 minutes. Il faut connaître le modèle, parler avec les métiers, et tester.

2. L’instruction ne remplace pas la modélisation.
Si vos jeux de données sont mal conçus, si vos jointures sont incohérentes, ou si vos colonnes sont mal typées, aucune instruction ne sauvera l’agent. Ce n’est pas une rustine, c’est un amplificateur de qualité.

3. Attention à la maintenance.
Plus vous ajoutez d’instructions, plus vous devrez les maintenir. Si vos règles métier changent ou si votre modèle évolue, vous devrez faire le ménage pour ne pas introduire de décalage entre le discours de l’IA et la réalité des données.

Pourquoi c’est une avancée stratégique

Si Microsoft veut que les agents conversationnels deviennent des copilotes métier réellement efficaces, il fallait passer par là.

Le discours « demandez ce que vous voulez, l’IA se débrouillera » a montré ses limites. Il faut outiller cette IA avec du contexte, du sens, de la structure.

Et avec cette fonctionnalité, on se rapproche d’un équilibre intéressant : une IA guidée, mais toujours accessible, qui ne demande pas d’écrire du code, mais qui peut enfin s’appuyer sur des règles solides pour éviter les réponses absurdes.

Ce que je recommande

Commencez petit.

Prenez un agent, une ou deux sources bien connues, et testez l’impact des instructions. Formulez quelques règles simples, testez des requêtes avec et sans instruction, et mesurez la différence. Vous verrez très vite l’effet.

Ensuite, industrialisez : définissez des conventions pour écrire ces instructions, centralisez leur gestion, et intégrez ce travail dans vos processus de data governance.

---

Ressources utiles

• Guide de configuration
• Bonnes pratiques d’écriture

---

En conclusion

Cette nouveauté ne fera pas le buzz comme un Copilot qui génère un rapport en un clic. Et pourtant, elle a beaucoup plus d’impact réel.

Elle permet à vos agents de ne plus juste “réagir”, mais de comprendre votre univers métier.

Avec les Data Source Instructions, Microsoft Fabric franchit une étape essentielle : celle d’une IA plus intelligente non pas parce qu’elle devine mieux, mais parce qu’on lui a enfin expliqué les règles du jeu.