Une seule Plateforme Agréée devient un goulot d’étranglement dès la deuxième entité
Une seule Plateforme Agréée suffit pour une société à entité unique. Pour un groupe qui en compte plusieurs, miser tout sur le connecteur d’une seule plateforme enferme chaque filiale dans sa tranche tarifaire, sa couverture et son calendrier de version — et personne qui vous vend un connecteur n’a intérêt à le dire avant que vous signiez.
Pourquoi le choix de plateforme change-t-il dès qu’un groupe a plus d’une entité ?
La tarification des Plateformes Agréées est généralement à la facture et dégressive au volume, donc consolider la volumétrie du groupe sur une plateforme peut améliorer la tranche de prix. Mais les entités ne se ressemblent pas : une filiale qui émet 200 factures par mois avec de la vente aux particuliers n’a pas le même profil d’e-reporting qu’une entité B2B qui en émet 20 000. On détaille les six décisions de groupe que ça soulève dans un article compagnon ; celui-ci reste sur une seule décision — le connecteur lui-même — et ce que « verrouillé » coûte en pratique, pas en théorie.
Qu’est-ce que « verrouillé sur un connecteur » veut dire techniquement ?
La plupart des connecteurs de facturation électronique sont des intégrations point à point : la logique du brouillon d’achat — rapprochement, TVA, suivi de statut — est écrite directement contre le contrat d’API d’une plateforme et sa structure JSON. Ce n’est pas un problème de relation fournisseur qu’on renégocie ; c’est du code. Les noms de champs de la plateforme, son flux d’authentification, son modèle de pagination sont tissés dans les mêmes routines qui créent le brouillon d’achat. Changer de plateforme ne veut pas dire signer un nouveau contrat — ça veut dire retrouver et détricoter chaque endroit où le format de l’ancienne plateforme s’est infiltré dans la logique métier, puis le reconstruire contre la nouvelle.
C’est ça, le vrai goulot d’étranglement, et il est invisible jusqu’à ce qu’un groupe essaie d’ajouter une deuxième plateforme sous pression de calendrier — exactement ce qu’une réforme à date fixe finit par imposer.
Comment le connecteur Business Central est-il construit pour éviter ça ?
On a construit la connexion à la plateforme comme une interface : un contrat fixe — récupérer les nouveaux documents électroniques depuis la plateforme, vérifier le statut d’un document, renvoyer un statut — que doit remplir toute implémentation de Plateforme Agréée. La logique du brouillon d’achat dans Business Central ne parle qu’à ce contrat. Elle n’appelle jamais l’API d’une plateforme directement, ne parse jamais la structure JSON propre à cette plateforme dans les routines de rapprochement ou de TVA.
Deux implémentations existent aujourd’hui, pour SuperPDP et Tréso2. Ajouter une troisième Plateforme Agréée veut dire écrire une nouvelle implémentation du même contrat — une unité de travail autonome — sans toucher à la logique du brouillon d’achat, au suivi des statuts AFNOR, ni à rien dont un utilisateur dépend déjà. C’est ce qu’on a construit avec FacturaLink : la couche connecteur entre Business Central et une Plateforme Agréée, bâtie sur cette interface exprès.
Comment le connecteur reste-t-il synchronisé avec une plateforme ?
Les Plateformes Agréées comme SuperPDP ne poussent pas d’événements vers Business Central — il n’y a pas de webhook. Le connecteur interroge sur un rythme planifié (une tâche Job Queue, toutes les 15 à 30 minutes) et demande à la plateforme ce qui est nouveau depuis la dernière vérification, en utilisant un identifiant strictement croissant comme curseur. C’est un compromis assumé : l’interrogation régulière est plus lente qu’un modèle push par définition, mais elle évite à Business Central d’exposer un point d’entrée entrant sur internet, et un cycle d’interrogation manqué ne perd pas de document — le cycle suivant reprend simplement au même curseur.
L’authentification suit la même discipline. Le connecteur s’authentifie en OAuth 2.1 avec des identifiants applicatifs — aucun utilisateur n’est impliqué — et met en cache le jeton obtenu pendant toute sa durée de vie de trente minutes plutôt que d’en redemander un à chaque appel. Ces deux choix sont anodins pris séparément. Ensemble, ils expliquent pourquoi la couche connecteur doit être un contrat auquel la logique métier peut faire confiance, pas une série d’appels spécifiques à une plateforme éparpillés dans le code du brouillon d’achat.
Qu’est-ce qu’ignorer ça coûte vraiment à un groupe ?
Le mode d’échec qu’on observe n’est pas spectaculaire, il est juste tardif. Un groupe signe un contrat exclusif avec une plateforme, négocié sur la volumétrie de la société mère. Une filiale au profil différent — forte vente aux particuliers, rythme d’e-reporting différent — colle moins bien aux forces de cette plateforme. Le groupe a alors deux mauvaises options : forcer l’entité mal assortie sur une plateforme qui la sert mal, ou reconstruire le connecteur pour ajouter une deuxième plateforme en cours de programme, avec une échéance réglementaire qui ne bouge pas. Les deux coûtent plus cher que de trancher l’architecture du connecteur avant que la première entité ne démarre.
Faire tourner deux plateformes coûte-t-il vraiment plus cher qu’une seule ?
Pas de la façon dont ça paraît au premier regard. Le surcoût d’un connecteur bâti sur une interface est un coût d’ingénierie ponctuel, payé une fois, pas par plateforme ajoutée ensuite. L’alternative — une intégration point à point reconstruite chaque fois qu’une plateforme cesse de convenir — paie ce coût de façon répétée, généralement contre une échéance plutôt que sur son propre calendrier. Un groupe peut très bien faire tourner une plateforme pour la majorité de ses entités et consolider cette volumétrie pour le prix ; l’interface est ce qui transforme l’ajout d’une deuxième plateforme pour les cas atypiques en un changement contenu plutôt qu’une réécriture.
L’approche Asio Services
On n’a pas démarré FacturaLink comme une gamme de produits. On l’a démarré parce que le connecteur mono-plateforme était le mur qu’on rencontrait en pilotant des programmes Business Central pour des groupes multi-entités, et reconstruire la même logique de connecteur à chaque client n’était pas une position qu’on voulait garder. Si votre groupe hésite entre une Plateforme Agréée et plusieurs, commencez par notre formulaire clarté — c’est le moyen le plus rapide d’avoir une réponse nette sur ce que votre mix d’entités demande vraiment.
FAQ
La réforme de la facturation électronique impose-t-elle une seule plateforme par groupe ?
Non. Rien dans la réforme n’impose une plateforme unique pour tout le groupe, et des profils d’entité différents justifient souvent une répartition. La contrainte est tarifaire, pas réglementaire : la tarification étant généralement dégressive au volume, répartir les entités sans raison fait perdre un levier de négociation.
Un groupe peut-il changer de Plateforme Agréée après la mise en production ?
Proprement, seulement si le connecteur a été construit pour le permettre. Avec une intégration point à point, changer veut dire retrouver et réécrire chaque endroit où le format de l’ancienne plateforme est infiltré dans la logique métier. Avec un connecteur bâti sur une interface, ça veut dire ajouter une nouvelle implémentation du même contrat.
FacturaLink remplace-t-il SuperPDP ou Tréso2 ?
Non. FacturaLink est le connecteur côté Business Central vers une Plateforme Agréée, pas une Plateforme Agréée lui-même. Il se connecte aujourd’hui à SuperPDP et Tréso2 via la même interface.
Est-ce un sujet réservé aux grands groupes ?
Ça devient pertinent dès qu’un groupe a plus d’une entité avec un profil de facturation sensiblement différent — volumétrie, mix B2B/B2C, ou complexité d’e-reporting. Ce seuil est plus bas que « grand groupe ».