L'API Pennylane pour cabinets comptables : ce qu'elle permet vraiment

Un associé m'a montré un jour son rituel du 3 du mois : ouvrir Pennylane dossier par dossier, exporter le grand livre en CSV, le coller dans un tableur, recommencer soixante fois. Il ne s'en plaignait pas vraiment, c'était sa façon de garder un œil sur chaque client. Mais quand je lui ai demandé combien de temps ce rituel prenait sur une année, il n'avait jamais fait le calcul. Vingt minutes par dossier, soixante dossiers, ça fait vingt heures par mois passées à déplacer une donnée qui existait déjà, quelque part, sous une forme exploitable.

C'est exactement le problème que résout une API bien utilisée : elle supprime le geste de l'export manuel, pas le travail de fond qui vient après. La question mérite d'être posée sans raccourci, parce qu'elle revient dans presque toutes les discussions avec un cabinet sous Pennylane : qu'est-ce que cette API permet réellement, et où s'arrête-t-elle. Ce sujet s'inscrit dans une réflexion plus large sur la façon d'automatiser sans perdre le contrôle sur l'ensemble d'un portefeuille de dossiers ; cet article se concentre sur la brique technique elle-même.

Ce que recouvre concrètement l'API Pennylane

Pennylane expose une API REST documentée, avec une authentification par clé propre à chaque dossier, ou, pour un cabinet, un accès qui couvre l'ensemble du portefeuille depuis un point d'entrée unique selon la formule souscrite. Concrètement, une requête programmatique peut aller chercher, sans passer par l'interface, la donnée d'un client précis ou d'un lot de clients, à la demande ou selon un planning régulier. La différence avec un export manuel n'est pas seulement la vitesse : c'est la répétabilité. Le même script qui interroge un dossier aujourd'hui fonctionne demain, et sur le dossier suivant, sans réapprendre l'export à chaque fois.

Au-delà de l'interrogation à la demande, Pennylane propose aussi des webhooks : la possibilité d'être notifié en temps réel qu'une facture vient d'être créée, qu'une transaction bancaire a été rapprochée, qu'une écriture a été validée. Pour un cabinet qui gère un volume de dossiers important, c'est la différence entre interroger l'API toutes les nuits en espérant ne rien avoir raté, et être averti au moment où l'événement se produit. Peu de cabinets exploitent cette possibilité aujourd'hui. La plupart se contentent d'extractions programmées, largement suffisantes pour un usage mensuel de pilotage.

Cinq familles d'objets couvrent l'essentiel de ce qu'un cabinet va chercher :

• Les factures clients et fournisseurs, avec leur statut de paiement, ligne par ligne.
• Les écritures comptables, journal par journal, avec le plan comptable propre au dossier.
• Les transactions bancaires, rapprochées ou non, telles qu'elles remontent des connexions bancaires du client.
• Le FEC, généré à la demande plutôt qu'exporté manuellement à chaque clôture.
• Le référentiel des tiers (clients, fournisseurs) et des catégories, utile pour recouper avec un CRM externe.

Le point le plus sous-estimé, pour un cabinet, tient dans un mot : homogénéité. Soixante-dix clients sous Pennylane répondent au même format de données, avec la même structure d'API, quelle que soit la taille du dossier ou son secteur. Un cabinet qui gère aussi des clients sous un autre outil comptable n'a pas ce luxe : chaque export a sa propre logique, ses propres colonnes, ses propres approximations. Sous Pennylane, la brique technique construite pour un dossier se réutilise sur le suivant avec un effort marginal qui décroît vite, la logique de base ne change pas.

Ce que ça change une fois qu'on branche vraiment l'API

Trois effets concrets, une fois la connexion en place. D'abord la fin de la ressaisie : une donnée saisie une fois dans Pennylane par le client ou son comptable ne se retape nulle part ailleurs, elle circule. Ensuite la fraîcheur : au lieu d'un export mensuel figé au 5 du mois, la donnée disponible reflète l'état du dossier à l'instant où on l'interroge, transactions bancaires de la veille comprises. Enfin la scalabilité : le temps nécessaire pour ajouter un soixante et unième dossier au périmètre automatisé n'a presque rien à voir avec celui du premier, une fois le pipeline construit.

Un exemple, chiffres composites

Un cabinet de vingt-deux collaborateurs, quatre-vingt-cinq dossiers sous Pennylane, a testé la bascule sur un lot de trente clients représentatifs du reste du portefeuille (des PME de services, entre cinq et quarante salariés). Avant le projet, l'extraction mensuelle du grand livre et des transactions bancaires pour ces trente dossiers mobilisait environ vingt-huit heures cumulées, réparties sur deux collaborateurs, avant même de commencer l'analyse. Une fois la connexion API mise en place et le script de collecte automatisé, cette même extraction s'est ramenée à moins de deux heures par mois, essentiellement du contrôle de cohérence sur les dossiers qui affichaient une anomalie.

Le chiffre qui compte n'est pas les heures gagnées en soi, modestes rapportées à un cabinet entier. C'est ce qu'elles sont devenues : du temps de lecture facturable, là où l'extraction manuelle ne l'était jamais.

Ce que l'API ne fait pas, et ne fera jamais seule

L'API donne accès à une matière première propre. Elle ne la transforme pas en décision. Trois limites reviennent systématiquement, et les ignorer explique la plupart des projets d'automatisation qui s'arrêtent après trois mois. La réconciliation d'abord : une transaction bancaire et une facture ne se rapprochent pas toutes seules dès qu'on sort du strict périmètre Pennylane, dès qu'un client encaisse via un prestataire de paiement ou un CRM externe qui a sa propre notion de la vente. Le plan comptable ensuite : deux clients sous Pennylane peuvent nommer et classer leurs charges différemment, l'API respecte ce plan tel qu'il existe, elle ne l'harmonise pas entre dossiers.

• Elle ne rapproche pas automatiquement une vente CRM, un encaissement de paiement et une facture comptable.
• Elle ne construit pas d'entrepôt de données ni d'historique consolidé au-delà de ce que Pennylane conserve.
• Elle ne détecte pas seule une incohérence entre deux dossiers qui utilisent le même plan comptable différemment.
• Elle ne se maintient pas toute seule : un changement de structure côté Pennylane, un renouvellement de clé, une erreur de synchronisation exigent une surveillance technique continue.

Il faut ajouter une contrainte moins visible mais bien réelle : l'API évolue, les versions changent, des quotas de requêtes existent. Un script qui tourne sans supervision depuis six mois peut s'arrêter silencieusement le jour où une clé expire ou où un endpoint change de format. Ce n'est pas un défaut de l'API, c'est la nature de toute intégration technique vivante : elle demande une main qui la surveille, au même titre qu'un serveur ou une sauvegarde. Un cabinet qui construit son propre pipeline doit budgéter cette maintenance, pas seulement la mise en place initiale.

Ce sont exactement les mêmes limites que rencontre un dirigeant qui tente de brancher Pennylane à un tableau de bord sans passer par cette étape de réconciliation, le sujet traité en détail dans le guide sur la connexion de Pennylane à un tableau de bord fiable. Les fondations techniques sont identiques des deux côtés, côté cabinet ou côté dirigeant : l'API ouvre la porte, la réconciliation construit la pièce.

Industrialiser une offre à partir de cette matière première

C'est ici que la brique technique devient un actif de cabinet plutôt qu'un projet informatique isolé. Une fois le pipeline construit et fiabilisé sur un premier dossier pilote, sa réplication sur le reste du portefeuille suit une courbe de coût décroissante : le deuxième dossier reprend l'essentiel du script du premier, le dixième ne demande plus qu'un paramétrage. C'est cette mécanique qui permet de transformer une contrainte technique en offre vendable, plutôt que de la garder comme un chantier interne sans traduction commerciale. Une offre de pilotage structurée à partir de cette matière première tient en trois briques : le socle technique, le rythme de restitution, la grille tarifaire.

Par où commencer sans tout casser

La première décision technique, avant même de coder quoi que ce soit, porte sur le référentiel commun : quelle nomenclature de catégories utiliser pour représenter des plans comptables qui varient d'un client à l'autre. Sauter cette étape, vouloir automatiser avant d'avoir tranché ce référentiel, produit un pipeline qui fonctionne dossier par dossier mais ne se généralise jamais proprement au reste du portefeuille.

Trois clients pilotes, pas trente. Choisis parmi ceux qui posent déjà des questions de pilotage que le cabinet a du mal à honorer avec les outils actuels, pas les dossiers les plus simples. Le pipeline se construit sur ce lot restreint, avec le temps de corriger les cas particuliers de plan comptable ou de connexion bancaire incomplète, avant d'envisager une réplication à grande échelle. Un cabinet qui tente de tout automatiser d'un coup sur cent dossiers découvre ses cas limites en même temps qu'il les facture, rarement la meilleure position de départ.

L'API Pennylane fait ce qu'une bonne API doit faire : elle rend la donnée disponible sans détour. Elle ne remplace ni le jugement comptable, ni le travail de réconciliation, ni la relation client. Ces trois éléments restent, et resteront, la valeur du cabinet. Ce qu'elle change, c'est le temps qu'il reste pour les exercer une fois la ressaisie éliminée.

Si votre cabinet gère déjà plusieurs dizaines de dossiers sous Pennylane et veut savoir ce que cette donnée permettrait concrètement de construire, un échange de vingt minutes suffit pour cadrer un premier périmètre pilote.