5.2Actualisation planifiée & passerelle (gateway)
L'essentiel en 30 secondes
- Un rapport publié affiche les données de sa dernière actualisation ; l'actualisation planifiée rejoue tout le pipeline (Power Query compris) à heures fixes.
- Sources cloud (SharePoint/OneDrive) : pas de passerelle ; sources locales, oui — et alors la passerelle standard d'entreprise, jamais la personnelle en production.
- La cause n°1 des échecs, ce sont les informations d'identification ; on regarde d'abord l'historique d'actualisation.
Mini-cas filé — Zineb automatise la fraîcheur de son rapport à Alger
Le rapport ventes de Zineb, contrôleuse de gestion à Alger, affiche les données d'hier : elle veut qu'il se rafraîchisse seul. Elle applique le cycle : elle déplace le fichier source sur SharePoint (source cloud, pas de passerelle), republie, configure les informations d'identification du modèle sémantique, puis active l'actualisation planifiée tous les jours à 7 h — avant l'arrivée des lecteurs. Elle modifie la source, lance « Actualiser maintenant » et vérifie l'historique. Son réflexe : un échec ? l'historique d'abord, souvent un identifiant expiré.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 5.2.
1. L'actualisation rejoue le pipeline
Un rapport publié n'affiche pas du direct : il montre les données de sa dernière actualisation. L'actualisation planifiée rejoue tout le pipeline — sources, Power Query, modèle — à heures fixes. D'où l'importance de requêtes propres : ce qui casse dans Power Query casse à chaque actualisation. Zineb planifie son rapport chaque matin, sans intervention.
2. Cloud ou passerelle
Pour les sources cloud (SharePoint, OneDrive, bases cloud), le Service accède seul : pas de passerelle. C'est le bon réflexe dès le choix de l'emplacement source. Pour les sources locales (fichiers sur le réseau, SQL interne), il faut une passerelle (gateway) : le pont installé côté entreprise. Et on choisit la standard/entreprise (sur serveur, supervisée par l'IT), jamais la personnelle pour la production — elle dépend d'un PC allumé. Zineb passe donc à SharePoint.
3. Identifiants, échecs et historique
La cause n°1 des échecs d'actualisation, ce sont les informations d'identification : jetons expirés, mots de passe changés. On les configure dans les paramètres du modèle sémantique. En cas d'échec, le premier réflexe est de consulter l'historique d'actualisation, qui détaille l'erreur. Zineb documente les comptes utilisés pour anticiper les expirations.
🔎 Exemple concret — 🔎 Exemple concret — Le cycle de fraîcheur
Zineb rend son rapport autonome :
1. Fichier source sur OneDrive/SharePoint → source cloud, pas de passerelle
2. Service → Paramètres du modèle → Informations d'identification
3. Actualisation planifiée : tous les jours à 7 h
4. Modifier la source → « Actualiser maintenant » → vérifier l'historiqueLecture : un rapport publié n'est pas du direct : c'est la planification qui apporte la fraîcheur.
Leçon : source cloud = pas de passerelle ; un échec se diagnostique d'abord dans l'historique.
Vocabulaire de la section
- Actualisation planifiée
- Paramètres du modèle sémantique → Actualiser : les horaires (jusqu'à 8/jour en Pro, 48 en Premium) où le Service recharge les données.
Exemple simple : Zineb planifie son rapport chaque matin à 7 h.
Ce que ce n'est pas : une actualisation manuelle oubliée.
Réflexe : données fraîches → planifier.
- Passerelle (gateway)
- Le logiciel-pont installé sur un serveur de l'entreprise : il permet au Service d'atteindre les sources locales, de façon sécurisée.
Exemple simple : Zineb en aura besoin pour un fichier resté sur son réseau.
Ce que ce n'est pas : une source cloud, accessible sans pont.
Réflexe : source locale → passerelle.
- Personnelle vs standard
- Personnelle : sur votre PC, pour vous (dépend de votre machine allumée !) ; standard/entreprise : sur serveur, mutualisée et supervisée par l'IT.
Exemple simple : Zineb réserve la standard à la production.
Ce que ce n'est pas : la personnelle qui s'arrête si le PC est éteint.
Réflexe : production → passerelle standard.
- Informations d'identification
- Les accès aux sources que le Service utilise pour actualiser, à configurer dans les paramètres du modèle.
Exemple simple : Zineb reconfigure l'accès quand un jeton expire.
Ce que ce n'est pas : un accès jamais saisi, source d'échec.
Réflexe : échec d'actualisation → identifiants d'abord.
- Historique d'actualisation
- Le journal des tentatives (réussites/échecs + erreurs détaillées).
Exemple simple : Zineb y lit l'erreur exacte après un échec.
Ce que ce n'est pas : une supposition à l'aveugle.
Réflexe : « pas à jour » → lire l'historique.
En pratique — En pratique — Automatiser la fraîcheur des données
- Déplacez votre fichier source sur OneDrive/SharePoint et refaites la connexion depuis Desktop : source cloud = pas de passerelle, comme Zineb.
- Republiez, puis dans le Service : Paramètres du modèle sémantique → Informations d'identification → configurez l'accès.
- Activez l'actualisation planifiée : tous les jours à 7 h — avant l'arrivée des lecteurs.
- Modifiez la source, lancez « Actualiser maintenant » et vérifiez le rapport ET l'historique.
Script pas-à-pas — rendre le rapport autonome (5 min)
1) Rangez le fichier source sur OneDrive/SharePoint et reconnectez-le dans Desktop (source cloud, pas de passerelle). 2) Republiez le rapport vers votre espace de travail. 3) Dans le Service, ouvrez les paramètres du modèle sémantique et renseignez les informations d'identification. 4) Activez l'actualisation planifiée à 7 h, tous les jours. 5) Modifiez la source, lancez Actualiser maintenant et contrôlez l'historique — comme Zineb, l'échec se lit d'abord là.
Un échec d'actualisation ? L'historique donne l'erreur détaillée : le plus souvent une information d'identification expirée.
Modèle copier-coller — ma check-list d'actualisation
[ ] Source en cloud (SharePoint/OneDrive) → pas de passerelle
[ ] Fichier local ? → passerelle STANDARD d'entreprise (jamais la personnelle)
[ ] Informations d'identification configurées (cause n°1 des échecs)
[ ] Actualisation planifiée activée (ex. chaque jour à 7 h)
[ ] Historique vérifié après « Actualiser maintenant »Source cloud
Zineb déplace son fichier sur SharePoint : le Service l'atteint seul, sans passerelle.
Source locale
Un fichier reste sur le réseau de l'usine : Zineb demande la passerelle standard d'entreprise à l'IT.
Identifiants
Un jeton expire : Zineb reconfigure l'accès dans les paramètres du modèle et relance l'actualisation.
Chaque matin
Zineb planifie l'actualisation à 7 h : à l'arrivée des lecteurs, les données sont déjà fraîches.
✓ Bonnes pratiques
- Choisir des sources cloud (SharePoint/OneDrive) : pas de passerelle nécessaire.
- Pour du local, la passerelle standard d'entreprise — jamais la personnelle.
- En cas d'échec, consulter l'historique d'actualisation (souvent un identifiant expiré).
✗ Pièges fréquents
- Utiliser la passerelle personnelle en production (dépend d'un PC allumé).
- Négliger les informations d'identification (cause n°1 des échecs).
- Oublier que l'actualisation rejoue tout le pipeline (requêtes sales = échecs).
Points clés à retenir
- L'actualisation rejoue tout le pipeline : sources → Power Query → modèle.
- Sources cloud : pas de passerelle ; sources locales : passerelle standard d'entreprise.
- Les informations d'identification sont la cause n°1 des échecs.
- Échec d'actualisation : l'historique d'abord.
Défi 48h — appliquez demain
Rendez un rapport autonome comme Zineb : rangez la source en cloud (pas de passerelle), configurez les informations d'identification, activez l'actualisation planifiée à 7 h, puis modifiez la source et prouvez via l'historique que le rafraîchissement a fonctionné.
- Je configure l'actualisation planifiée d'un modèle sémantique publié.
- Je sais quand une passerelle s'impose et laquelle choisir.
- Je privilégie les sources cloud et je diagnostique via l'historique.
Questions fréquentes
Mon actualisation échoue avec une erreur d'identifiants : que faire ?
C'est la cause majoritaire. Allez dans Paramètres du modèle sémantique → Informations d'identification et reconnectez-vous : les jetons OAuth2 expirent et les mots de passe changent. Vérifiez aussi que le chemin de la source n'a pas bougé. Méthode : lire l'historique (erreur détaillée), reconnecter les identifiants, contrôler le chemin — ce trio résout l'écrasante majorité des cas.
Puis-je actualiser plus souvent que 8 fois par jour ?
En Pro : 8 fois par jour maximum ; en Premium/Fabric : 48. Au-delà, il faut changer de paradigme (DirectQuery, streaming). Mais demandez-vous surtout si le besoin métier justifie mieux que « chaque matin » : dans l'immense majorité des cas, un rafraîchissement nocturne suffit.
Quand une passerelle (gateway) est-elle nécessaire ?