Vous venez de créer votre compte sur une plateforme de Business Intelligence et l’écran d’accueil affiche une dizaine d’onglets. Par où commencer ? La tentation est forte de se lancer directement dans la création de rapports. Avec une planbi connection mal configurée dès le départ, les problèmes surgissent plus tard : rafraîchissements en erreur, données inaccessibles, identifiants éparpillés. Quelques réglages posés lors de la première connexion évitent ces impasses.
Gateway standard ou gateway personnel : le premier choix qui conditionne tout le reste
Les concurrents parlent souvent de passerelles de données sans distinguer le moment où ce choix se pose. Il se pose dès la première connexion, pas après.
La gateway personnel s’installe sur votre poste. Elle fonctionne tant que votre machine est allumée. Éteignez le PC le vendredi soir, et le rafraîchissement planifié du samedi matin échoue. Pour un usage individuel ou un prototype, cela suffit.
La gateway standard garantit la continuité des rafraîchissements même si le poste d’un utilisateur est éteint. Elle s’installe sur un serveur dédié ou une machine partagée. Plusieurs administrateurs peuvent la gérer. Les identifiants passent par des comptes de service plutôt que par des comptes nominatifs, ce qui simplifie la gestion des accès dans une entreprise.
Vous hésitez entre les deux ? Posez-vous une question simple : combien de personnes utiliseront les données connectées à cette passerelle ? Si la réponse dépasse une seule personne, la gateway standard s’impose dès le départ.
Nommage des sources de données : éviter les erreurs de connexion silencieuses
Ce point passe souvent inaperçu dans les guides de configuration, mais il génère la majorité des tickets de support lors des premières semaines.
Quand vous créez un rapport sur votre poste (Power BI Desktop par exemple), vous saisissez un nom de serveur pour accéder à votre base de données. Ce nom doit être strictement identique entre Desktop et le Service en ligne. Un écart suffit à bloquer le rafraîchissement via la passerelle.
Le piège du nom court face au nom complet
Imaginons que vous vous connectiez à votre base en tapant SRVBI01 dans Desktop. Sur le Service, la passerelle attend peut-être SRVBI01.internal.local (le nom complet, avec le domaine). Ces deux chaînes désignent la même machine, mais le Service les considère comme deux sources distinctes.
Le résultat : un message du type « la passerelle n’est pas configurée correctement ». Le réflexe est de réinstaller la passerelle ou de vérifier les pare-feu. La cause réelle est un simple écart de nommage.
Définissez un nom canonique pour chaque serveur dès la première connexion et documentez-le. Partagez cette convention avec toute l’équipe. Un tableau simple suffit :
| Serveur | Nom canonique à utiliser | Nom à ne pas utiliser |
|---|---|---|
| Base SQL production | srvbi01.internal.local | SRVBI01, srvbi01, 192.168.1.50 |
| Base Azure | moninstance.database.windows.net | moninstance (sans suffixe) |
Paramètres de sécurité et niveaux de confidentialité des données
La planbi connection passe aussi par un réglage que beaucoup ignorent lors de la première utilisation : les niveaux de confidentialité des sources de données.
Trois niveaux, trois comportements
Power Query propose trois niveaux de confidentialité pour chaque source :
- Public : les données peuvent être combinées librement avec d’autres sources, sans restriction. Adapté aux jeux de données ouverts (statistiques publiques, catalogues produits en ligne).
- Organisationnel : les données restent combinables uniquement avec d’autres sources du même niveau ou de niveau public. C’est le réglage par défaut recommandé pour les bases internes d’une entreprise.
- Privé : aucune combinaison avec d’autres sources. Le moteur isole complètement ces données. Utile pour les informations sensibles (données RH, données financières nominatives).
Si vous laissez le niveau par défaut sans y réfléchir, deux scénarios se présentent. Soit des combinaisons de données échouent sans explication claire. Soit des données sensibles se retrouvent mélangées avec des sources moins protégées.
Attribuez un niveau de confidentialité à chaque source dès la première connexion. Cela prend quelques secondes par source et évite des blocages frustrants plus tard.
Comptes de service et gestion des identifiants : séparer les accès dès le départ
Lors de la configuration initiale, la tentation est de renseigner ses propres identifiants personnels pour connecter les sources de données. Cela fonctionne, jusqu’au jour où vous changez de mot de passe ou quittez l’entreprise.
Pourquoi un compte de service change la donne
Un compte de service est un compte dédié, non rattaché à une personne physique. Il sert uniquement à authentifier les connexions entre la passerelle et les bases de données. Ses avantages concrets :
- Le mot de passe ne change pas au rythme des politiques de renouvellement individuelles.
- Le départ d’un collaborateur ne casse aucun flux de données.
- La gestion centralisée des identifiants facilite les audits de sécurité et la conformité.
Configurez ce compte dès la première connexion à la passerelle. Renseigner un compte nominatif « en attendant » crée une dette technique que personne ne corrige ensuite.
Vérification du réseau et tests de connectivité à la première utilisation
Un dernier point mérite votre attention avant de publier le moindre rapport. Testez chaque connexion depuis le Service en ligne, pas seulement depuis Desktop.
Une connexion qui fonctionne en local ne garantit pas qu’elle fonctionnera via la passerelle. Les règles de pare-feu, les restrictions de ports ou les politiques réseau de l’entreprise peuvent bloquer le flux entre la passerelle et la source distante.
Dans les paramètres de la passerelle, utilisez la fonction de test de connexion sur chaque source enregistrée. Si le test échoue, vérifiez que le port utilisé par votre base de données est ouvert sur le réseau où la passerelle est installée.
Ces vérifications prennent quelques minutes lors de la première connexion. Elles évitent des heures de diagnostic quand un rapport tombe en erreur trois semaines plus tard, devant un comité de direction qui attend ses indicateurs. Un plan BI fiable repose sur des fondations posées dès la configuration initiale, pas sur des corrections en urgence.
