Connecter Pennylane à Power BI : le guide complet

À la date de publication, il n’existe pas de connecteur Power BI officiel dans Pennylane. Ce n’est pas un problème : Pennylane expose une API externe v2 propre et documentée, et c’est par elle que passent tous les montages sérieux.

Concrètement, l’API donne accès à tout ce qu’il faut pour piloter : les écritures comptables (ledger_entries), la balance (trial_balance), les factures clients et fournisseurs (customer_invoices, supplier_invoices), les tiers, les journaux et les catégories analytiques. L’authentification se fait par un jeton créé dans les paramètres de votre compte Pennylane : un Company API token pour une société, un Firm API token pour un cabinet qui gère plusieurs dossiers.

Il reste ensuite à choisir le chemin entre Pennylane et Power BI. Il y en a trois, et le bon choix dépend surtout du nombre de sociétés et de ce que vous voulez faire de l’historique. On les prend dans l’ordre.

C’est la méthode la plus directe : Power BI interroge lui-même l’API. Aucun serveur, aucune passerelle, aucun logiciel à installer. Pour une société unique avec des volumes de PME, elle tient très bien la route.

1. Créez votre jeton API dans Pennylane. Dans les paramètres du compte, section API, générez un Company API token. Traitez-le comme un mot de passe : il donne accès à toute la comptabilité du dossier.
2. Créez un paramètre Power Query pour le jeton. Dans Power BI Desktop : Accueil → Gérer les paramètres → Nouveau paramètre, type Texte, nommé par exemple JetonPennylane. Le jeton ne doit jamais apparaître en clair dans une requête.
3. Collez le squelette de requête ci-dessous dans une requête vide (Accueil → Obtenir les données → Requête vide → Éditeur avancé). Il appelle l’API, suit la pagination par curseur et empile toutes les pages.
4. Développez les colonnes et typez-les. La réponse arrive dans un champ items : convertissez la liste en table, développez les enregistrements, puis fixez les types (dates en date, montants en nombre décimal). Sans ce typage, les cumuls DAX réservent des surprises.
5. Publiez et configurez l’actualisation planifiée. La source est 100 % cloud : dans le service Power BI, paramètres du modèle sémantique, informations d’identification de la source : méthode Anonyme (l’authentification passe par l’en-tête, pas par l’identifiant). Programmez l’actualisation la nuit et le tableau de bord se met à jour seul.

Le squelette M complet, pagination comprise :

let
    BaseUrl = "https://app.pennylane.com/api/external/v2",
    Appel = (curseur as nullable text) =>
        Json.Document(
            Web.Contents(
                BaseUrl,
                [
                    RelativePath = "ledger_entries",
                    Query = [ limit = "100" ]
                        & (if curseur = null then [] else [ cursor = curseur ]),
                    Headers = [ Authorization = "Bearer " & JetonPennylane ]
                ]
            )
        ),
    Pages = List.Generate(
        () => Appel(null),
        each _ <> null,
        each if [has_more] = true then Appel([next_cursor]) else null,
        each [items]
    ),
    Lignes = List.Combine(Pages),
    Table = Table.FromList(Lignes, Splitter.SplitByNothing(), {"ligne"})
in
    Table

Trois points de vigilance sur cette méthode :

• La limite de débit. L’API v2 autorise 25 requêtes par tranche de 5 secondes. Avec limit=100, un dossier de PME se charge sans y penser ; si vous frôlez la limite, l’API répond 429 avec un en-tête retry-after qui indique combien de secondes attendre.
• Les filtres et le curseur. Si vous filtrez une requête (par période, par journal), la doc est formelle : il faut renvoyer les mêmes filtres à chaque page, avec le curseur. Un filtre oublié en page 2 ne provoque aucune erreur, juste des données fausses. C’est le genre de bug qui se découvre en comité de direction.
• L’URL de base doit rester statique. Le service Power BI n’actualise pas les sources dont l’URL est construite dynamiquement. D’où le pattern ci-dessus : l’URL fixe dans Web.Contents, tout le reste dans RelativePath et Query.

Pennylane sait exporter à peu près tout en CSV, et le FEC (fichier des écritures comptables) sort en un clic. Pour un besoin ponctuel, c’est parfaitement honorable : un audit, une reprise d’historique, une analyse à date qu’on ne refera pas.

Le FEC mérite une mention particulière : c’est souvent le meilleur moyen de récupérer l’historique des exercices précédents pour l’asseoir sous les données vivantes de l’API. Un import, un nettoyage, et vos comparatifs N-1 et N-2 existent.

En revanche, ne construisez pas un pilotage récurrent là-dessus. Un reporting alimenté à la main s’arrête le jour où la personne qui faisait l’export part en congés. Pas d’actualisation automatique, pas de traçabilité, des versions qui se multiplient dans les boîtes mail : tout ce qu’un tableau de bord était censé faire disparaître.

Dès que le besoin dépasse la société unique, on intercale une brique entre Pennylane et Power BI : un script d’ingestion qui appelle l’API chaque nuit et dépose les données dans un entrepôt (une base SQL ou des fichiers Parquet suffisent largement à l’échelle d’une PME ou d’une ETI). Power BI ne lit plus l’API : il lit l’entrepôt.

Ce détour de quelques jours de mise en place change la nature de ce qu’on peut construire :

• La consolidation multi-sociétés. L’API raisonne par dossier : un jeton par société, pas de vue groupe. L’entrepôt collecte chaque dossier, harmonise les plans de comptes et sert une vue consolidée que Power BI restitue avec un simple filtre par entité.
• L’historisation. L’API renvoie l’état vivant de la comptabilité, pas des photos. L’entrepôt fige chaque mois un arrêté : vous savez ce que disait le P&L au moment du comité, même si des écritures ont bougé depuis.
• Les croisements. La trésorerie prend son sens à côté du CRM, du prévisionnel ou de la paie. Ces sources se rejoignent dans l’entrepôt, pas dans une requête Power Query qui refait le travail à chaque actualisation.
• La maîtrise du débit et des reprises. Le script gère la limite de 25 requêtes par 5 secondes, reprend sur erreur et ne recharge que le delta. L’actualisation Power BI, elle, devient triviale et rapide.

C’est le montage type de nos missions : on démarre par un audit court, et le premier tableau de bord tourne en production sous 5 à 10 jours ouvrés, mis à jour chaque nuit sans intervention de personne.

La connexion technique, honnêtement, c’est la partie facile. Voici ce qui fait vraiment dériver les projets Pennylane × Power BI, dans l’ordre où on le rencontre :

• Reconstruire le P&L depuis les factures. L’erreur classique. Additionner customer_invoices ne donne pas le chiffre d’affaires comptable : il manque les avoirs, les factures à établir, les produits constatés d’avance, les extournes. Le P&L se construit depuis les écritures et la balance, les factures servent au détail et au recouvrement.
• Le sens des montants. Une écriture porte un débit et un crédit ; le signe d’un solde dépend de la classe de compte. Posez la règle une fois, en amont, puis contrôlez votre P&L au centime contre la balance officielle avant de montrer quoi que ce soit. Ce contrôle de cohérence est la première chose qu’on installe.
• Les plans de comptes hétérogènes. En multi-sociétés, le compte 706 de l’une n’est pas le 706 de l’autre. La table de correspondance entre plans de comptes se construit avant la consolidation, avec le cabinet comptable, pas après la découverte d’un écart.
• Les dates. Date de pièce, date de saisie, date d’échéance : trois réponses différentes à « ça se rattache à quel mois ? ». Tranchez dès le départ, sinon le cut-off mensuel devient un débat récurrent.
• Le jeton qui traîne. Un jeton API donne accès à toute la comptabilité. Il vit dans un coffre ou un paramètre sécurisé, jamais dans un classeur partagé ni dans une requête copiée-collée entre collègues. Prévoyez sa rotation, et un jeton distinct par usage.