France — Annuaire central PPF

L'annuaire central du Portail Public de Facturation est le service de résolution unique permettant à toute PDP émettrice de retrouver la PDP réceptrice compétente, son format préféré et son certificat de signature, à partir d'un SIREN/SIRET.

Rôle de l'annuaire central

L'annuaire central est l'élément critique du modèle français 5-corner décentralisé (cf. page CTC 5-corner). Il joue le rôle conjoint d'un SMP+SML PEPPOL et d'un registre métier :

• Résolution PDP destinataire : pour un SIREN/SIRET donné, retourne l'identifiant de la PDP enregistrée, son endpoint AS4, et le format de facturation préféré du destinataire.
• Référentiel métier officiel : contient les informations administratives d'une entreprise assujettie (raison sociale, adresse, code APE, numéro TVA intracommunautaire, statut actif/radié) consolidées depuis la base SIRENE de l'INSEE et enrichies des données de facturation.
• Référentiel des certificats : porte le certificat de signature de la PDP destinataire, permettant à la PDP émettrice de vérifier les acquittements AS4 sans dépendre d'une AC tierce.
• Source du contrôle d'assujettissement : un acteur économique français non présent dans l'annuaire (ou en statut EXEMPT) signifie hors-périmètre — la PDP émettrice doit basculer en mode e-reporting (déclaration au lieu de facture inter-PDP).

Modèle de données

Une fiche partenaire (partner record) est un objet JSON versionné, identifié par SIREN. Exemple complet de payload renvoyé par GET /v1/partner/802145795 :

{
  "siren": "802145795",
  "siret": "80214579500024",
  "denomination": "Atelier Numerique SAS",
  "address": {
    "street": "12 rue de la Faisanderie",
    "postalCode": "75116",
    "city": "Paris",
    "countryCode": "FR"
  },
  "ape": "6201Z",
  "tvaIntracom": "FR62802145795",
  "registeredPdp": {
    "pdpId": "PDP-FR-007",
    "name": "Plateforme Demat Acme",
    "endpoint": "https://pdp-acme.fr/as4/inbox",
    "as4PartyType": "iso6523-actorid-upis",
    "as4PartyId": "0009:80214579500024"
  },
  "acceptedFormats": [
    "urn:cen.eu:en16931:2017",
    "urn:factur-x.eu:1p0:en16931",
    "urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100",
    "urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
  ],
  "preferredFormat": "urn:factur-x.eu:1p0:en16931",
  "signingCertificate": {
    "issuer": "CN=PPF Issuer CA, O=AIFE, C=FR",
    "serial": "0A:1B:2C:3D:4E:5F",
    "notAfter": "2027-12-31T23:59:59Z"
  },
  "lifecycle": {
    "createdAt": "2026-06-15T09:22:11Z",
    "updatedAt": "2026-08-30T17:45:00Z",
    "status": "ACTIVE"
  }
}

Onboarding et auto-enregistrement

Deux voies d'enregistrement sont prévues par les spécifications AIFE :

1. Auto-enregistrement via le portail web PPF : l'entreprise se connecte sur impots.gouv.fr avec ses identifiants espace pro, sélectionne sa PDP destinataire, déclare ses formats acceptés, et signe électroniquement la fiche. Idéal pour une PME ou TPE qui n'a pas d'intégration PDP côté SI.
2. Enregistrement via API depuis une PDP immatriculée : la PDP soumet un POST /v1/partner au nom de l'entreprise avec une preuve de mandat (token OAuth délégué par l'entreprise via la procédure FranceConnect+ Pro). Idéal pour les ETI et grandes entreprises gérées par leur PDP de manière industrielle.

Dans les deux cas, l'enregistrement est validé par un workflow DGFiP (vérification SIRENE temps réel + contrôle anti-doublon) et activé après typiquement 30 secondes à 2 minutes. Le statut intermédiaire est PENDING_VALIDATION.

API REST + OAuth 2.0

L'API expose 8 endpoints principaux. Toutes les requêtes nécessitent un access token OAuth 2.0 émis via le flow client_credentials (les PDP sont les seuls clients OAuth ; les ERP passent par leur PDP).

Authentification — obtenir un access token

curl -X POST https://annuaire.ppf.gouv.fr/oauth2/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=PDP-FR-007" \
  -d "client_secret=$PPF_CLIENT_SECRET" \
  -d "scope=annuaire.read annuaire.subscribe"

# Reponse:
# {
#   "access_token": "eyJhbGciOi...",
#   "token_type": "Bearer",
#   "expires_in": 3600,
#   "scope": "annuaire.read annuaire.subscribe"
# }

Les scopes typiques : annuaire.read (lecture des partenaires), annuaire.write (enregistrement, réservé PDP), annuaire.subscribe (souscription webhooks).

GET /v1/partner/<siren>

curl -X GET "https://annuaire.ppf.gouv.fr/v1/partner/802145795" \
  -H "Authorization: Bearer $PPF_ACCESS_TOKEN" \
  -H "Accept: application/json" \
  -H "If-None-Match: \"v3-1730289302\""

# Reponses possibles:
# 200 OK -> body partner + ETag, Cache-Control: max-age=86400
# 304 Not Modified -> cache local valide, ne pas recharger
# 404 Not Found -> entreprise non enregistree ou non assujettie
# 410 Gone -> entreprise radiee, ne plus router vers cette adresse

Le header If-None-Match avec l'ETag obtenu lors de la requête précédente permet de bénéficier des réponses 304 Not Modified : c'est le mécanisme d'invalidation paresseuse complémentaire des webhooks.

GET /v1/partner — recherche paginée

curl -X GET "https://annuaire.ppf.gouv.fr/v1/partner?denomination=cooperative&cursor=eyJpZCI6MTAwfQ&limit=100" \
  -H "Authorization: Bearer $PPF_ACCESS_TOKEN"

# Reponse:
# {
#   "results": [ { "siren": "521452014", ... }, ... ],
#   "pageInfo": {
#     "hasNextPage": true,
#     "endCursor": "eyJpZCI6MjAwfQ",
#     "pageSize": 100
#   }
# }

La pagination est cursor-based opaque : le client réutilise tel quel l'endCursor renvoyé par la page précédente. Cela évite les sauts de page incohérents en cas de modification concurrente du dataset (entreprise radiée pendant la pagination, par exemple).

Cache, TTL et webhooks d'invalidation

Les spécifications AIFE prescrivent un cache local côté PDP avec un TTL de 24h par défaut. Le risque sans cache est double : saturation de l'API centrale (multipliée par le nombre de factures), et latence d'un saut RTT par facture (préjudiciable au SLA contractuel client).

L'invalidation du cache est event-driven via le système de webhooks PPF. Une PDP souscrit via POST /v1/subscriptions avec un endpoint HTTPS callback et un secret HMAC partagé. Les événements émis incluent partner.created, partner.updated, partner.suspended, partner.radiated. Exemple d'événement reçu :

{
  "eventType": "partner.updated",
  "eventTimestamp": "2026-09-12T11:04:23Z",
  "eventId": "evt_2026091200004523",
  "schemaVersion": "PPF-1.2",
  "subject": {
    "siren": "802145795",
    "siret": "80214579500024"
  },
  "changes": [
    "registeredPdp.endpoint",
    "preferredFormat"
  ],
  "newVersion": "v4-1731060123",
  "ttlInvalidate": true
}

1. Signature HMAC-SHA256 : chaque webhook est signé via le header X-PPF-Signature. Une PDP qui ne vérifie pas la signature accepte des invalidations forgées.
2. Idempotence : chaque événement porte un eventId opaque. Les PPF peuvent réémettre des événements en cas de timeout : traiter en idempotent (dédupliquer par eventId).
3. Délai de propagation : la cible AIFE est de moins de 60 secondes entre la modification dans l'annuaire et la réception par l'ensemble des PDP souscrites.
4. Gestion des échecs callbacks : backoff exponentiel jusqu'à 24h, puis désinscription automatique et notification opérateur. La PDP doit re-souscrire manuellement après remise en service.

Liens transverses

• France — Vue d'ensemble du mandat 2026/2027.
• France — Modèle CTC 5-corner — rôle de l'annuaire dans l'architecture.
• France — Spécifications Factur-X FNFE-MPE.
• France — Chorus Pro et bascule PPF.
• Standards — PEPPOL (SMP/SML pour comparaison).
• Sources : AIFE — Spécifications externes API PPF, INSEE — Base SIRENE, Décret 2024-266 du 25 mars 2024, RFC 6749 OAuth 2.0, RFC 6585 HTTP 429 Too Many Requests.