API facturation électronique 2026 — guide développeurs

Pour développeurs, intégrateurs, éditeurs SaaS et DSI. La réforme facturation électronique 2026-2027 introduit plusieurs APIs distinctes selon le rôle de votre application. Ce guide explique les spécifications, les standards (Factur-X, UBL, EN 16931), les modèles d’authentification (OAuth 2.0, mTLS), et liste les Plateformes Agréées (PA) qui exposent une API publique ou partenaire.

Les 3 APIs distinctes de la facturation électronique

La réforme expose en réalité trois APIs distinctes selon votre rôle :

1. API d’une Plateforme Agréée (PA)

Pour qui : éditeurs ERP, applications SaaS, marketplaces qui veulent émettre/recevoir des factures pour le compte de leurs utilisateurs.

Ce que vous pouvez faire :

• Émettre une facture Factur-X / UBL via la PA
• Recevoir des factures destinées à votre utilisateur (webhook ou polling)
• Récupérer les statuts (envoyée, reçue, acceptée, payée, refusée)
• Gérer les annuaires partenaires (recherche par SIREN)
• Transmettre les e-reportings agrégés

Authentification typique : OAuth 2.0 (client_credentials ou authorization_code) + JWT signé pour chaque appel.

2. API du Portail Public de Facturation (PPF) — APIs AIFE

Pour qui : Plateformes Agréées et Opérateurs de Dématérialisation (OD) — pas pour les TPE/PME directes¹.

Ce que vous pouvez faire (en tant que PA opératrice), depuis le recentrage du PPF¹ sur ses deux missions (annuaire central et concentrateur e-reporting) :

• Consulter et alimenter l’annuaire central des destinataires
• Pousser les agrégats e-reporting au concentrateur PPF

Authentification : mTLS (mutual TLS) + certificats émis par l’AIFE selon les spécifications publiées¹.

→ Cette API n’est pas ouverte aux entreprises directes : elle est réservée aux PA et OD.

3. API d’e-reporting (intégrée aux PA)

Pour qui : applications qui gèrent les transactions B2C, ventes étrangères, achats étrangers — typiquement des caisses, des plateformes e-commerce, des outils comptables.

Ce que vous pouvez faire :

• Pousser les agrégats de transactions à votre PA (qui transmet ensuite au PPF)
• Récupérer les statuts de transmission
• Gérer les rectifications

Authentification : OAuth 2.0 via votre PA.

→ Détail e-reporting.

Standards et formats — ce qui transite via l’API

Toute API PA expose ou consomme des documents conformes à au moins un des trois formats :

Factur-X

• Structure : PDF/A-3 contenant un fichier XML CII intégré
• Profils : Minimum, Basic WL, Basic, EN 16931, Extended
• Profil obligatoire : a minima EN 16931 pour la conformité 2026-2027
• Avantage : double lisibilité humaine (PDF visuel) + machine (XML)
• Bibliothèques : voir l’écosystème référencé par le FNFE-MPE² (implémentations Java, PHP, .NET, Python publiées par la communauté Factur-X).

UBL (Universal Business Language)

• Structure : XML pur, standard OASIS³
• Version : UBL 2.1 minimum, profils EN 16931 compatibles⁴
• Avantage : supporté nativement par Peppol et largement utilisé en EDI international
• Bibliothèques : OpenPeppol SDKs et bibliothèques OASIS UBL — voir le site OASIS UBL³

CII (Cross Industry Invoice)

• Structure : XML pur, standard UN/CEFACT⁵
• Profils : EN 16931 pour la conformité réforme⁶
• Cas d’usage : EDI traditionnel, échanges B2B industriels lourds
• Bibliothèques : disponibles via les SDKs PA et les bibliothèques EDI standards — voir UN/CEFACT XML Schemas⁵

→ La norme européenne EN 16931 publiée par le CEN⁴ est le socle commun aux trois formats : tout document conforme EN 16931 est accepté par l’administration⁶, quel que soit son format de sérialisation (Factur-X, UBL ou CII).

Modèles d’authentification typiques

Liste des PA exposant une API publique ou partenaire

Au 31/05/2026, toutes les Plateformes Agréées disposent nécessairement d’une interface technique d’interconnexion avec le PPF (obligation d’agrément). En revanche, l’existence d’une API publique ou partenaire ouverte à des tiers (clients, intégrateurs) varie selon les éditeurs — c’est ce dernier point qui fait la différence pour un acheteur cherchant à automatiser ses flux. Consulter la page développeur de chaque PA pour le détail (existence de Sandbox publique, OpenAPI/Swagger en ligne, mode d’authentification, rate limits, tarification API). Quelques PA SaaS publient une page d’intégrations grand public (Pennylane⁷, Sellsy⁸, Cegid⁹, Sage¹⁰) ; d’autres acteurs orientés EDI/B2B (Sovos¹¹, Esker¹², Pagero¹³) communiquent leurs interfaces sur leurs pages produit.

Choix d’une API PA — checklist développeur

Avant de signer avec une PA, vérifier :

1. Conformité : la PA est-elle dans le registre officiel ? Annuaire officiel.
2. Documentation publique : peut-on lire l’OpenAPI/Swagger sans NDA préalable ?
3. Sandbox / environnement de test : disponible sans contrat commercial ?
4. SDKs officiels : Java, Python, PHP,.NET, Node.js disponibles ?
5. Webhooks fiables : retry, signature, ordering ? SLA documenté ?
6. Rate limits : connus, suffisants pour votre volumétrie ?
7. Tarification API : par requête, par facture, ou inclus dans l’abonnement utilisateur final ?
8. Support technique : SLA développeur, channel dédié, status page ?
9. Annuaire SIREN : recherche d’un destinataire via SIREN/SIRET ?
10. Cycle de vie de facture : événements de cycle (envoyée → reçue → acceptée → payée) accessibles via webhook ou polling ?

Implémentation type — “Hello World” Factur-X via API PA

Pseudo-code générique (sans clé API réelle) :

1. POST /oauth/token { client_id, client_secret, grant_type: client_credentials }
 → access_token

2. POST /invoices { recipient_siren, amount, vat_rate, items, format: "factur-x" }
 Authorization: Bearer {access_token}
 → { invoice_id, status: "queued" }

3. Webhook POST {votre_endpoint} { event: "invoice.sent", invoice_id, status: "sent" }

4. (optionnel) GET /invoices/{invoice_id} pour polling
 → { status: "delivered", recipient_acceptance: "pending" }

→ Chaque PA expose une variante de ce flux. La spécification exacte est dans la doc OpenAPI de la PA cible.

Tarification API — modèles courants

Trois modèles tarifaires observés sur les pages développeurs publiques :

1. Facturation incluse dans l’abonnement utilisateur final : modèle annoncé par les PA orientées SaaS comptable (Pennylane⁷, Sellsy⁸, Tiime¹⁴, Indy¹⁵, Cegid⁹) — la PA facture l’utilisateur final, l’éditeur intégrateur ne paie pas séparément.
2. Tarification API par requête / par facture : modèle annoncé sur les pages produit des opérateurs EDI traditionnels (Sovos¹¹, Esker¹², Pagero¹³) — voir les conditions tarifaires de chaque éditeur.
3. Tarification API forfaitaire éditeur : abonnement mensuel par volume avec cap par requête, à vérifier sur la page tarif de chaque éditeur.

→ Pour un éditeur SaaS qui revend à ses utilisateurs finaux : modèle 1 est le plus simple (pas de coût additionnel, marge sur l’abonnement utilisateur). Pour un éditeur EDI B2B lourd : modèle 2 est standard.

Sécurité — bonnes pratiques

• Chiffrement TLS 1.2+ partout (TLS 1.3 préféré)
• Stockage des secrets : Vault, KMS, HashiCorp Vault — jamais en clair dans le code ou le repo
• Rotation OAuth tokens : refresh_token vs re-authentification client_credentials
• Signature HMAC des webhooks entrants (vérifier X-Signature ou équivalent)
• Rate limit côté votre app pour éviter de saturer la PA cible
• Logs séparés des données fiscales (ne pas écrire les XML factures en log clair — RGPD + secret fiscal)
• Audit trail : conserver les correlation_id de chaque appel pour traçabilité 10 ans

FAQ courte

Puis-je connecter mon ERP custom directement au PPF (sans PA) ?

Non, sauf à devenir vous-même Plateforme Agréée⁶ — process administratif et fiscal complet décrit sur la page officielle (cahier des charges, audit, conditions d’immatriculation). Durée typique non publique : à mesurer sur la trajectoire des PA récemment immatriculées via le registre¹⁶. Pour la quasi-totalité des cas d’usage, vous passez par une PA tierce qui expose son API.

Quel format choisir entre Factur-X, UBL et CII ?

Factur-X est le plus simple si vous voulez un PDF lisible humain en plus du XML (pratique pour les TPE/PME). UBL est dominant en flux Peppol et international. CII reste utilisé en EDI lourd. Tous les trois sont conformes EN 16931, donc réforme-compatibles.

Quelle PA pour intégrer un projet open-source (Dolibarr, Odoo) ?

Pennylane et Sellsy documentent une sandbox publique avec inscription self-service selon leur page développeur. Cegid Apidae ou Sage Connect si vous êtes déjà dans l’écosystème Cegid/Sage. Voir Dolibarr vs Odoo pour les implications connecteur.

Y a-t-il une API officielle PPF pour les développeurs externes ?

Non, l’API du PPF est réservée aux PA et OD immatriculés. Les développeurs externes passent obligatoirement par une PA tierce.

Quelle latence d’envoi typique ?

La latence dépend de la PA émettrice, de l’annuaire central et de la PA réceptrice. Depuis le recentrage du PPF¹, la facture transite PA émettrice → PA réceptrice (avec consultation de l’annuaire central opéré par le PPF), pas par un “tunnel PPF”. Les latences observées varient selon les éditeurs — consulter les SLA techniques publiés par chaque PA dans sa documentation développeur.

Pour conclure : choisir une API PA n’est pas un choix technique pur — c’est aussi un choix commercial (modèle tarifaire), un choix de stack (SaaS comptable vs EDI lourd) et un choix de conformité (registre officiel¹⁶ officiel). Notre comparateur inclut le filtre “API ouverte” pour identifier rapidement les PA accessibles aux développeurs.