France — Modèle CTC 5-corner vs PEPPOL 4-corner

La France a fait un choix d'architecture singulier en Europe : un modèle CTC (Continuous Transaction Controls) hybride à cinq corners où la DGFiP reçoit en quasi-temps réel les données fiscales, en parallèle du routage métier inter-PDP.

Qu'est-ce que le CTC ?

Continuous Transaction Controls désigne tout modèle de facturation électronique où l'administration fiscale ou un tiers de confiance valide ou reçoit les données de la transaction en quasi-temps réel, plutôt qu'a posteriori via des déclarations périodiques (DSF, déclarations TVA mensuelles). Le terme est structuré par l'OECD dans son rapport Tax Administration 3.0 (2020) et par l'IETF dans le brouillon draft-ietf-vatcontrols-models.

L'OECD distingue quatre familles de CTC :

1. Periodic e-reporting (modèle européen historique avant 2014) : les contribuables transmettent des déclarations agrégées mensuelles. Pas de CTC à proprement parler.
2. Real-time e-reporting (Espagne SII, Hongrie NAV) : les factures sont transmises en temps réel à l'administration après émission, sans validation préalable.
3. Centralised clearance (Italie SdI, Turquie GİB, Egypte ETA, Pologne KSeF dès 2026) : la facture est obligatoirement déposée auprès d'une plateforme étatique qui la valide puis la transmet au destinataire.
4. Decentralised CTC + e-reporting (France PPF/PDP, Belgique PEPPOL+ à venir, Allemagne Wachstumschancengesetz) : le routage métier reste décentralisé (PEPPOL 4-corner ou variante) mais l'administration reçoit en parallèle les données fiscales agrégées.

Rappel : PEPPOL 4-corner

Le modèle PEPPOL 4-corner, standardisé par OpenPEPPOL et utilisé par défaut en Norvège, Belgique B2G, Suède, Pays-Bas, et de nombreux pays en B2G, repose sur quatre acteurs et un annuaire SMP/SML :

┌──────────────┐       ┌───────────────┐       ┌──────────────┐
│ SP-Emetteur  │──AS4─>│  SMP/SML      │<──AS4─│ SP-Recepteur │
│  (corner 1)  │       │  (annuaire)   │       │  (corner 4)  │
└──────┬───────┘       └───────────────┘       └──────▲───────┘
       │                                                │
       │                AS4 / SBDH                      │
       └────────────────────────────────────────────────┘
        Corner 2 (Access Point emetteur) → Corner 3 (AP recepteur)

• Corner 1 : SP-Émetteur — Service Provider de l'émetteur (logiciel/SaaS de facturation).
• Corner 2 : Access Point émetteur — passerelle AS4 du SP-émetteur.
• Corner 3 : Access Point récepteur — passerelle AS4 du SP-récepteur, résolue via SMP+SML.
• Corner 4 : SP-Récepteur — Service Provider du destinataire (ERP, comptabilité).

L'annuaire SMP/SML (Service Metadata Publisher / Service Metadata Locator) joue un rôle de DNS de facturation : un identifiant métier (SIRET, VAT, GLN…) est résolu vers l'URL de l'Access Point receveur compétent. La transmission utilise AS4 (SOAP 1.2 + WS-Security) avec le wrapper SBDH (Standard Business Document Header). L'administration fiscale n'a aucun rôle technique direct.

France 5-corner : la cinquième corner DGFiP

Le modèle français reprend la structure 4-corner mais ajoute une boucle parallèle vers la DGFiP, qualifiée par les spécifications AIFE de « cinquième corner ». Le PPF (Portail Public de Facturation) joue un double rôle : il héberge l'annuaire central de résolution (équivalent fonctionnel du SMP/SML PEPPOL) et agrège les données fiscales à destination de la DGFiP.

┌──────────┐    ┌───────┐    ┌───────────────┐    ┌───────┐    ┌──────────┐
│ ERP      │───>│ PDP   │───>│ Annuaire PPF  │───>│ PDP   │───>│ ERP      │
│ Vendeur  │    │ Em.   │    │ + concentr.   │    │ Recep.│    │ Acheteur │
│ corner 1 │    │ corn.2│    │ corner X      │    │ corn.3│    │ corner 4 │
└──────────┘    └───┬───┘    └───────┬───────┘    └───────┘    └──────────┘
                    │                │
                    │      lifecycle │
                    │                ▼
                    │       ┌────────────────┐
                    │       │  DGFiP         │
                    └──────>│  (5e corner)   │
                            │  e-reporting   │
                            │  TVA temps reel│
                            └────────────────┘

Trois flux distincts circulent dans cette architecture :

1. Flux métier facture (UBL/CII/Factur-X) : ERP vendeur → PDP émettrice → routage inter-PDP via l'annuaire central → PDP réceptrice → ERP acheteur. Le contenu métier complet circule uniquement entre les PDP.
2. Flux fiscal vers DGFiP : la PDP émettrice doit extraire et transmettre à la PPF un sous-ensemble fiscal (montants HT/TVA/TTC par taux, identifiants des parties, date d'opération, code opération). Le contenu métier détaillé (libellés de lignes, références internes) n'est pas transmis à la DGFiP.
3. Flux de cycle de vie : les changements de statut (déposée, reçue, acceptée, refusée, payée, encaissée…) remontent symétriquement par les deux PDP et sont également agrégés par la PPF. Exemple de payload de statut de cycle de vie :

{
  "messageType": "INVOICE_LIFECYCLE_STATUS",
  "schemaVersion": "PPF-1.2",
  "invoiceId": "FR-2026-09142",
  "issuer": { "siret": "80214579500024" },
  "recipient": { "siret": "52145201400018" },
  "status": "ENCAISSEE",
  "statusCode": "203",
  "statusTimestamp": "2026-11-15T14:32:01+01:00",
  "issuingPdp": "PDP-FR-007",
  "receivingPdp": "PDP-FR-022",
  "dgfipReportingFlag": true,
  "reportingTimestamp": "2026-11-15T14:32:05+01:00"
}

Avantages et inconvénients

Avantages du choix français

• Visibilité fiscale temps réel — la DGFiP dispose d'une vue agrégée des transactions avant la déclaration de TVA mensuelle, ce qui ouvre la voie au pré-remplissage déclaratif annoncé à l'horizon 2028.
• Concurrence des PDP préservée — contrairement au modèle italien SdI où une plateforme étatique unique est imposée, l'écosystème PDP privé garde sa liberté tarifaire et fonctionnelle.
• Continuité avec PEPPOL — les PDP peuvent réutiliser leur stack AS4 PEPPOL existante avec un overlay français limité (annuaire SIREN, format Factur-X recommandé, profils statuts).
• Pas de SPOF unique — l'indisponibilité d'une PDP n'arrête pas l'écosystème entier (à condition que l'annuaire central, lui, ait une haute disponibilité ≥ 99,95%).

Inconvénients et risques

• Complexité protocolaire — chaque acteur (éditeur ERP, PDP, intégrateur) doit maîtriser deux protocoles parallèles (routage métier + e-reporting fiscal) et leur orchestration.
• Latence accrue — la résolution de la PDP destinataire via l'annuaire central ajoute un saut RTT, et l'agrégation fiscale impose une lecture/transformation supplémentaire de la facture côté PDP.
• Dépendance annuaire central — l'indisponibilité de l'annuaire central PPF bloque toute nouvelle facturation : c'est le SPOF résiduel du modèle (atténué par mise en cache TTL 24h côté PDP).
• Coût d'intégration PDP — la procédure d'immatriculation des PDP (audit AIFE, conformité RGS***, dépôt de caution) crée une barrière à l'entrée significative.

Benchmarks internationaux

Comparaison des principaux modèles en 2026, par ordre croissant de centralisation :

Implications techniques pour les éditeurs

1. Architecture double-piste : prévoir dès la conception deux files de messages distinctes (routage métier inter-PDP et e-reporting fiscal vers PPF). Les volumétries et les SLA sont différents : l'e-reporting tolère un retard asynchrone de quelques minutes, le routage métier doit respecter les SLA contractuels client.
2. Mise en cache de l'annuaire : les spécifications AIFE recommandent un TTL de 24h sur le cache de résolution PPF côté PDP. Cela impose une politique d'invalidation sur événement (webhook DGFiP → PDP). Voir la page dédiée Annuaire central.
3. Gestion des statuts : ~10 statuts de cycle de vie sont normalisés (déposée, reçue, refusée, encaissée…) et doivent remonter dans les deux sens entre PDP, plus une copie à la PPF. Un statut perdu = une facture qui apparaît bloquée côté DGFiP.
4. Format pivot pour l'agrégation fiscale : les PDP doivent extraire les données fiscales depuis UBL, CII ou Factur-X, et les transmettre dans un format pivot JSON spécifié par l'AIFE. Tout changement de version Schematron côté FNFE-MPE peut impacter le pipeline d'extraction — prévoir une stratégie de versionning.
5. Résilience PDP-locale : la non-disponibilité d'une PDP destinataire ne doit pas bloquer l'émetteur. Le décret 2024-266 impose un mode dégradé avec re-routage automatique vers une PDP de secours après timeout T+15 minutes.

Liens transverses

• France — Vue d'ensemble du mandat 2026/2027.
• France — Spécifications Factur-X FNFE-MPE.
• France — Annuaire central PPF (API + spec).
• France — Chorus Pro et bascule vers le PPF.
• Standards — PEPPOL (BIS Billing 3.0 + AS4 + SBDH).
• Standards — AS4 / ebMS3 — protocole de transport entre Access Points.
• Sources : DGFiP — Spécifications externes B2B, OECD Tax Administration 3.0 (2020), Ordonnance 2021-1190 (Légifrance), Décret 2024-266 du 25 mars 2024, OpenPEPPOL eDelivery (AS4).