i

Description

Vue aérienne d’un grand lac aux rives boisées, traversé par une chaussée.

Source

Mx. Granger · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

OneLake + applications mobiles en SaaS : contribution de l'IA

Vous saurez situer l'offre IA de Fabric et Power BI (Copilot, agents de données, AI Functions, notebooks) et son état de maturité en octobre 2026.

En bref

• Vous saurez situer l'offre IA de Fabric et Power BI (Copilot, agents de données, AI Functions, notebooks) et son état de maturité en octobre 2026.
• Vous disposez d'un tableau de cas d'usage avec gain, risque et maturité sur /5, prérequis et garde-fous, appliqué aux données d'applications de terrain.
• Vous saurez formuler des prompts utiles et cadrer ce que l'IA ne remplace pas : jugement, responsabilité, confidentialité.
• Contexte : vue d'ensemble, architecture, pièges.

Sur cette page

1. 1. Panorama de l'offre IA
2. 2. Cas d'usage notés
3. 3. Copilot et agents de données en détail
   1. 3.1 Ce qui fait réussir un agent de données
   2. 3.2 Ce que Copilot Power BI peut ou ne peut pas faire
   3. 3.3 Notebooks et Spark
4. 4. Qualité des données par l'IA
   1. 4.1 Déduplication des clients terrain
   2. 4.2 Détection d'anomalies
   3. 4.3 Enrichissement
5. 5. Prompts d'exemple
6. 6. Garde-fous
7. 7. Ce que l'IA ne remplace pas
8. 8. Voir aussi

Niveau : 🟢→🔴

1. Panorama de l'offre IA#

🟢 Novice.

Vocabulaire à fixer (Glossaire) :

Disponibilité : d'après les annonces Microsoft, Copilot et les capacités d'IA sont ouverts aux SKU payantes à partir de F2 depuis le 30 avril 2025 (état 2026-10). La consommation s'impute sur les CU de la capacité (il n'y a pas de facturation par requête) ; une capacité « Copilot » dédiée peut être créée pour isoler la consommation. À revérifier avant décision : les conditions, régions et paramètres d'administration évoluent vite.

2. Cas d'usage notés#

🟡 Praticien.

Notes /5 : gain (valeur attendue), risque (5 = très risqué), maturité (5 = éprouvé). Appréciations d'expert, contextuelles — cf. NOTATION. Contexte : équipe BI de 3 à 6 personnes, données SFA terrain.

3. Copilot et agents de données en détail#

🟡 Praticien.

3.1 Ce qui fait réussir un agent de données#

Un agent traduit une question en requête (SQL, DAX, KQL) sur les sources que vous lui ouvrez. Sa qualité dépend de ce que vous lui fournissez :

1. Périmètre étroit : quelques tables du gold (faits visite/commande, dimensions client/produit/date), pas tout le lac.
2. Schéma lisible : noms explicites, descriptions de colonnes, clés et relations claires.
3. Consignes : définitions métier (« visite réalisée = statut X et durée > Y »), conventions de période, devise, langue.
4. Exemples de requêtes validées (few-shot), pour les questions fréquentes et les ambiguïtés.
5. Jeu de test : 30 à 50 questions avec réponses attendues, rejoué à chaque évolution du modèle ou de l'agent.
6. Sécurité : l'agent doit s'exécuter avec les droits de l'utilisateur ; la couche de sécurité (OneLake security, RLS du modèle) s'applique sans contournement. Les agents avec principal de service sont en preview (état 2026-10) : ne les utilisez pas pour contourner la sécurité (sécurité RLS et accès).

3.2 Ce que Copilot Power BI peut ou ne peut pas faire#

• Peut : proposer une page de rapport, une mesure DAX, résumer un visuel, répondre à une question simple sur un modèle bien décrit.
• Ne peut pas : connaître vos règles de gestion non écrites, deviner la différence entre « date de visite » et « date de synchronisation », corriger un modèle mal conçu.
• Risque : réponse plausible mais fausse (jointure inadaptée, filtre manquant, contexte RLS).

3.3 Notebooks et Spark#

Copilot dans un notebook : génération de code PySpark, explication, correction d'erreurs, complétion inline (preview, état 2026-10). Utile pour les motifs standards (MERGE, lecture JSON imbriqué, jointures). Risques : API Delta mal utilisées, absence de gestion de l'idempotence, secrets dans le code. Le code produit doit passer en Git, en revue de code et en test comme tout autre (CI/CD pour la data).

4. Qualité des données par l'IA#

🔴 Expert.

4.1 Déduplication des clients terrain#

Approche en entonnoir, du moins coûteux au plus coûteux :

1. Règles déterministes : normalisation (casse, accents, ponctuation, abréviations d'adresse), clé exacte (code ERP, SIRET si légal).
2. Similarité : distance d'édition, n-grammes, phonétique, distance géographique, regroupement par blocs.
3. Modèle (embeddings ou LLM) sur les cas restants : « ces deux fiches décrivent-elles le même point de vente ? » avec score et raisons.
4. Humain pour les scores intermédiaires ; la décision alimente la table de correspondance (et améliore les règles).

Pourquoi ne pas tout confier à un LLM ? Coût en CU, variabilité, non-reproductibilité, difficulté d'audit. Un LLM est un bon juge des cas limites, pas un moteur de déduplication à grande échelle.

# Esquisse : on ne soumet au modèle que les paires ambiguës (score intermédiaire)
ambigues = paires.filter((F.col("score") >= 0.70) & (F.col("score") < 0.92))
# puis revue humaine ou LLM avec sortie structurée {decision, confiance, raison}

4.2 Détection d'anomalies#

Avant le ML, utilisez des règles lisibles : durée de visite négative ou supérieure à 12 h, nombre de visites par jour supérieur à un seuil plausible, coordonnées à zéro, prix hors de ± 5 écarts-types de l'historique par produit. Le ML (isolation forest, séries temporelles) vient compléter pour les motifs non triviaux. Dans tous les cas : signaler vers le terrain, ne pas corriger en silence.

4.3 Enrichissement#

Catégorisation de commentaires libres (motifs de non-vente, litiges), extraction d'entités depuis des notes, résumé de comptes rendus. Précautions : masquer ou pseudonymiser les données personnelles avant l'appel à un modèle externe ; tracer la version du modèle et du prompt utilisés pour chaque ligne enrichie (reproductibilité) ; mesurer la précision sur un échantillon étiqueté ; ne pas écraser la donnée source, créer des colonnes dérivées.

5. Prompts d'exemple#

🟡 Praticien.

Génération d'un MERGE Delta idempotent

Documentation de modèle

Revue de DAX

Instruction d'agent de données (extrait)

6. Garde-fous#

🔴 Expert.

7. Ce que l'IA ne remplace pas#

🔴 Expert.

• Le jugement métier : décider qu'une visite « compte » ou qu'un client est « actif » relève de règles de gestion que l'IA ne peut pas découvrir seule.
• La responsabilité : le chiffre publié engage son auteur ; « c'est Copilot qui l'a généré » n'est pas une défense.
• La recette : l'IA propose, le test et le métier valident (recette et validation métier).
• La modélisation : un mauvais modèle produit de mauvaises réponses plus convaincantes.
• L'architecture et l'arbitrage de coût : où copier, quelle capacité, quel mode de stockage (architecture).
• La conduite du changement : l'adoption par les commerciaux dépend de la simplicité de saisie et du retour qu'ils en obtiennent.

Pour la dimension IA du pilotage de projet : IA et conduite de projet ; pour l'IA dans l'outillage : IA et outils ; synthèse : IA transverse. Pour la variante relationnelle : IA avec SQL Server en SaaS.

8. Voir aussi#

• Dossier : Vue d'ensemble · Architecture · Difficultés et pièges · Comparatif OneLake vs SQL Server · Bonnes pratiques transverses · Checklist de projet
• Matrices : Développement BI · Gouvernance des données · Métadonnées, lignage et documentation
• Termes : Glossaire

✻ Rédigé par Claude Sonnet 5.5