Cent une plateformes agréées par la DGFiP au 16 janvier 2026, et autant d’approches techniques pour les connecter à un ERP, un SaaS métier ou un back-office maison. Côté développeur, le sujet n’est plus de comprendre la réforme : il est de savoir quelle API tient la production, supporte les volumes, et n’imposera pas une réécriture dans douze mois.
L’écart entre les plateformes agréées ne se mesure plus aux fonctionnalités UI. Il se mesure à la profondeur des endpoints, à la qualité de la documentation, et à la stabilité des webhooks sous charge. Pour resituer la fonctionnalité API dans l’arbre de décision plus large, on peut s’appuyer sur le guide de choix par fonctionnalité qui couvre les autres critères techniques.
Cet état des lieux part d’un constat simple : sur les 101 PA immatriculées, une dizaine seulement publie une vraie documentation développeur, et une poignée encore propose un sandbox sans engagement. Le reste tient du marketing. On regarde ce qui sépare une PA API-first d’une PA dotée d’une API d’appoint, et ce que ça implique côté intégration.
La PA n°1 côté sociétés, équipes tech et expert-comptables
API Entreprise V2 documentée, import Factur-X natif, écosystème d’intégrations (Stripe, Shopify, ERP) et OAuth2 standard. Conforme à la réforme 2026.
- Statut DGFiP confirmé
- API REST publique avec documentation complète
- 14 jours d’essai sans CB
Ce que change vraiment une API pour intégrer une plateforme agréée
Côté développeur, une plateforme agréée n’est pas un logiciel à utiliser, c’est un service à orchestrer. La question n’est plus « est-ce que l’interface est ergonomique » mais « combien de lignes de code pour pousser une facture, récupérer un statut, et propager une réception ». Trois flux distincts cohabitent, et beaucoup d’éditeurs sous-estiment encore le troisième.
Émission, réception, e-reporting : trois flux à automatiser séparément
L’émission couvre la génération d’une facture structurée (Factur-X, UBL ou CII), sa signature éventuelle, et sa soumission à la PA qui la route vers la PA du destinataire via le PPF. C’est la partie la mieux outillée : tout le monde a un endpoint POST /invoices. La réception est plus subtile, parce qu’elle implique d’écouter en continu les factures qui arrivent dans votre annuaire électronique, de les ingérer, et de remonter un statut à l’émetteur. Sans webhook, vous tombez dans le polling, et le polling à 7 millions d’assujettis n’est pas une stratégie viable.
L’e-reporting arrive en troisième et concerne les flux hors périmètre B2B France : B2C, B2B international, données de paiement. La DGFiP attend ces données agrégées à fréquence régulière, et c’est typiquement la partie qu’on découvre en intégration tardive. Une PA sérieuse expose un endpoint dédié plutôt que de mélanger e-invoicing et e-reporting dans la même structure de payload. Cette séparation se voit dans les plateformes agréées avec intégration comptable native, qui adressent l’e-reporting via une couche dédiée alimentée par la compta.
L’« API-first » n’est pas un argument, c’est une architecture
La plupart des PA actuelles ont été conçues comme des SaaS UI-first, avec une API ajoutée a posteriori pour cocher la case. Le symptôme se voit vite : endpoints documentés mais incomplets, pagination capricieuse, codes erreur génériques, rate-limits non publiés, format des webhooks variable selon les événements. À l’inverse, une PA vraiment API-first (Iopole, B2Brouter, Tenor, FactPulse, Pennylane sur sa partie comptabilité) traite l’API comme le produit principal. La différence opérationnelle se mesure en jours d’intégration.
Le vrai différenciant tient à trois choses : un sandbox accessible sans contrat signé, une documentation OpenAPI à jour, et un changelog public versionné. Si l’un des trois manque, partez du principe que l’API est un sous-produit du SaaS principal, et que les évolutions se feront sans préavis. C’est la sortie de route classique en production : un endpoint déprécié qui casse une intégration sans email d’alerte.
Les endpoints à exiger d’une plateforme agréée sérieuse
Sur le papier, toutes les PA exposent « une API REST ». Dans la réalité, le périmètre couvert varie d’un facteur trois entre la plus complète et la plus pauvre. Voici les endpoints qui doivent figurer au minimum syndical, et ceux qui distinguent une PA grand-public d’une PA dimensionnée pour un intégrateur.
Création, soumission et formats supportés
Le minimum, c’est un endpoint POST /invoices qui accepte au moins Factur-X, UBL et CII, les trois formats du socle EN 16931. Pennylane, par exemple, expose une route POST /e-invoice-import qui ingère un PDF Factur-X (PDF lisible + XML embarqué) et déclenche l’écriture comptable associée. Sur la partie sortie, l’endpoint doit retourner un identifiant durable et un statut initial (queued, submitted, accepted), pas une réponse 200 vide.
Attention au champ SIREN destinataire, devenu obligatoire dans le socle 2026. Une PA qui le laisse optionnel signale un mapping incomplet, et vos factures seront rejetées en réception sans message d’erreur explicite. Demandez aussi le support du format JSON pour les flux non-EDI : il devient majoritaire sur les intégrations modernes.
Statuts, webhooks et suivi du cycle de vie
Le cycle de vie d’une facture électronique compte une dizaine de statuts officiels (déposée, refusée, suspendue, encaissée, etc.), à propager dans les deux sens. Une PA qui force le polling expose en général GET /invoices/:id/status. Une PA mature expose des webhooks par événement, avec retry exponentiel et signature HMAC. Sur 50 000 factures mensuelles, l’écart de coût d’infrastructure entre les deux modèles dépasse les 10 000 € annuels en compute.
Vérifiez en sandbox : signature HMAC, idempotency key, politique de retry, et delivery log accessible côté PA. Sans ces quatre piliers, l’intégration ne tient pas la charge réelle.
E-reporting et propagation vers le PPF
L’e-reporting n’est pas une fonctionnalité bonus, c’est une obligation distincte de l’e-invoicing pour toutes les transactions hors B2B France. Une PA bien architecturée expose POST /e-reports ou équivalent, avec un schéma propre, et pas un POST sur le même endpoint que les factures. Idem côté Peppol : une PA qui veut couvrir l’international doit être point d’accès Peppol certifié, et l’exposer comme un canal de routage transparent dans l’API. Pour aller plus loin sur ce canal européen, voir les plateformes agréées Peppol.
Pour un freelance ou une petite société qui veut une PA gratuite à l’entrée, conforme DGFiP, sans surcouche technique à maintenir : Indy est encore le rapport conformité/prix le plus net.
Sécurité, authentification et SLA de propagation
La sécurité d’une API de PA n’est pas un sujet à reléguer au pen-test final. Elle conditionne l’éligibilité même de la plateforme à l’immatriculation DGFiP, qui exige des standards stricts. Côté intégrateur, trois points doivent être validés avant la moindre ligne de code en production.
OAuth2, clés API et certificats
L’authentification standard sur les API modernes, c’est OAuth2 en autorisation code flow, avec scopes granulaires (lecture factures, écriture factures, e-reporting, admin). Une PA qui n’expose qu’une clé API statique est utilisable pour un POC, jamais en production multi-tenant. Le client_secret doit être stocké dans un gestionnaire de secrets (Vault, AWS Secrets Manager, Doppler), jamais en clair dans un repository. Sur les flux les plus sensibles, certaines PA ajoutent un mTLS via certificat client, en plus de l’OAuth2 : c’est la norme côté ETI et secteurs régulés.
Si l’intégration relie aussi un compte bancaire pro à la facturation (réconciliation automatique des encaissements), vérifiez la robustesse de l’agrégation côté PA. Les plateformes agréées avec connexion bancaire ont des architectures de sécurité spécifiques qui s’ajoutent au flux facturation.
Webhooks signés, chiffrement et piste d’audit
Trois invariants techniques distinguent une intégration de production d’un POC : TLS 1.3 sur tous les échanges, signature HMAC sur les webhooks entrants (sinon n’importe qui peut envoyer un faux callback), et piste d’audit exposée par l’API (qui a fait quoi, quand, avec quel scope OAuth2). Si la PA ne propose pas un endpoint GET /audit-logs, vous reconstruisez la traçabilité côté client, ce qui est lourd et fragile.
Avant de signer le contrat d’intégration, vérifiez le statut sur la liste officielle DGFiP (impots.gouv.fr). Le marketing « PA agréée » ne vaut pas immatriculation définitive, et l’écart en production est non-négociable. Sans ce statut, les factures émises ne seront pas considérées comme conformes.
Trois patterns d’intégration selon votre SI
Une fois la PA choisie, reste à décider comment elle s’insère dans le système d’information. Trois modèles dominent, avec des implications très différentes en termes de coût, d’image de marque, et de complexité réglementaire. Le choix ne se fait pas au niveau technique seul, c’est aussi une décision produit.
Marque blanche, marque grise, Solution Compatible
En marque blanche, la PA est invisible côté utilisateur final : vos clients ne voient que votre logiciel, et vous portez juridiquement le rôle de PA (immatriculation à votre nom, audits ISO 27001, support N1). C’est le modèle le plus coûteux, mais le plus protecteur de votre image de marque. En marque grise, l’utilisateur sait qu’il opère sur la PA tierce (B2Brouter, Iopole, Tenor, Docoon), même si l’accès se fait depuis votre interface. Vous gardez la relation commerciale, la PA porte la conformité. C’est le modèle dominant chez les éditeurs SaaS qui veulent un time-to-market court.
La Solution Compatible (SC) est un statut intermédiaire : votre logiciel n’est pas PA, mais il est labellisé comme compatible avec une PA tierce immatriculée. C’est l’option la moins lourde côté audit, et celle que choisissent par défaut les outils métiers qui ne veulent pas devenir prestataire de facturation électronique. Le trade-off est clair : moins de souveraineté technique, mais aucun risque d’immatriculation à porter.
| Critère | Marque blanche | Marque grise | Solution Compatible |
|---|---|---|---|
| Visibilité de la PA | Aucune | Identifiée | Explicite |
| Immatriculation DGFiP | À votre nom | À la PA tierce | À la PA tierce |
| ISO 27001 requis | Oui (à votre charge) | Non (mutualisé) | Non |
| Time-to-market | 6 à 12 mois | 2 à 8 semaines | 2 semaines à 2 mois |
| Coût d’entrée | Élevé | Modéré | Faible |
| Cible type | Éditeurs ERP majeurs | SaaS verticaux, cabinets | Outils métier, no-code |
ERP, SaaS et stack technique : où placer la plateforme agréée
Côté ERP (Sage, Cegid, SAP, Odoo), l’usage est de connecter la PA via un middleware (Tenor, Generix, Docoon) qui mappe les pièces commerciales sur les schémas Factur-X et gère les statuts retour. Côté SaaS vertical, on intègre directement la PA via API REST avec OAuth2, et on expose les statuts dans l’UI métier. Côté no-code et low-code, on passe par des connecteurs Zapier ou Make qui font le pont entre une PA grand public (Pennylane, Indy, Abby) et l’outil principal.
Pour les groupes avec filiales, la gestion multi-tenant est critique. Une PA qui ne sépare pas proprement les environnements (un tenant = une entité juridique = un jeu de credentials) impose des contorsions côté intégrateur. Voir les plateformes agréées multi-entités pour les solutions adaptées à ce cas, et les plateformes agréées multi-utilisateurs côté gestion des droits par équipe. Sur les modèles d’abonnement récurrent ou de SaaS B2B, ajouter le routage automatique des factures récurrentes implique un endpoint dédié, exposé chez certaines PA seulement, comme on le voit chez les plateformes agréées pour facturation récurrente.
Pour les flux EDI massifs et l’industrie
Si l’intégration cible un environnement ERP profond, des volumes EDI significatifs ou des connecteurs Factur-X sur-mesure, YouSeeMe est dimensionné pour absorber sans saturer. Hub multi-formats, conforme aux standards CTC européens.
Découvrir YouSeeMe →Questions fréquentes
Indy et Pennylane proposent-ils une API pour la facturation électronique B2B ?
Pennylane expose une API Entreprise V2 publique, accessible via OAuth2, avec un endpoint dédié à l’import Factur-X (POST /e-invoice-import) et la gestion complète des objets comptables (factures, clients, écritures). La documentation couvre l’ensemble des cas d’usage, avec exemples de code. Indy propose un accès programmatique via connecteurs partenaires plutôt qu’une API REST publique standalone, ce qui la positionne plutôt côté Solution Compatible. Le choix entre les deux dépend du degré d’autonomie technique souhaité.
Faut-il devenir soi-même plateforme agréée si on intègre une PA tierce via API ?
Non, sauf en mode marque blanche totale. En marque grise ou en Solution Compatible, c’est la PA tierce qui porte l’immatriculation DGFiP, l’ISO 27001 et la responsabilité technique. Votre logiciel reste un consommateur d’API, sans obligation d’immatriculation. Cette distinction est critique : devenir PA implique un dossier d’immatriculation, des tests d’interopérabilité avec le Portail Public de Facturation, et un audit annuel. Le coût total dépasse facilement 200 000 € en première année pour une structure non préparée.
Quel volume de factures absorbe une API de plateforme agréée ?
Les PA dimensionnées pour l’éditique annoncent des capacités de 100 000 à plusieurs millions de factures par mois en API, avec des SLA contractuels de propagation sous 60 secondes vers le PPF. Les PA grand public (cible TPE/freelance) sont calibrées pour des volumes par tenant beaucoup plus faibles, typiquement 500 à 5 000 factures mensuelles. Si l’intégration vise un éditeur SaaS B2B avec plusieurs milliers de clients finaux, exigez des rate-limits publiés et un contrat SLA explicite, pas juste une mention marketing.
Combien coûte une intégration API à une plateforme agréée ?
Côté abonnement PA, les tarifs publics vont de 0 € (offres freemium des PA mainstream) à 99 € HT par mois par entité juridique, avec souvent un coût à la facture au-delà d’un quota. Côté intégration, comptez 5 à 15 jours-homme pour un connecteur simple (POST facture + webhooks statuts), 30 à 60 jours-homme pour une intégration ERP avec mapping complexe et e-reporting. Sur 3 ans, le coût total d’usage dépend surtout du volume traité et du nombre de tenants, rarement du prix d’appel affiché.
Comment basculer d’une plateforme agréée à une autre quand l’intégration API est en production ?
La réglementation impose la portabilité sur 12 mois : la PA quittée doit transférer l’historique et les références à la nouvelle PA. En pratique, la migration reste opérationnellement lourde : il faut redéclarer l’adresse de réception électronique côté annuaire DGFiP, reparamétrer les credentials OAuth2 de tous les tenants, retester les webhooks, et migrer les archives à valeur probante. Compter 8 à 16 semaines pour une bascule industrielle sans interruption du flux entrant. C’est l’argument le plus solide en faveur d’une couche d’abstraction côté SI dès l’intégration initiale.