API annuaire administration et routage SIRET : identifier et router les factures électroniques en 2026

Générer une facture Factur-X conforme ne suffit pas. Il faut aussi qu’elle arrive au bon destinataire, via la bonne plateforme. Dans le modèle décentralisé de la réforme française, chaque entreprise est inscrite auprès d’une PDP (Plateforme de Dématérialisation Partenaire). Pour acheminer une facture, l’émetteur doit d’abord identifier quelle PDP est enregistrée pour le destinataire. C’est le rôle de l’annuaire.

Ce guide couvre la chaîne complète : de l’identification d’une entreprise par son SIRET, à la résolution de sa PDP dans l’annuaire, en passant par les API publiques qui fournissent les données nécessaires et leur mapping dans les champs Factur-X.

Pour le contexte complet de la réforme et l’architecture PDP, voir Facturation électronique 2026 : le guide technique complet.

L’annuaire : le routeur central de la facturation électronique

Pourquoi un annuaire ?

Dans le modèle à 5 coins de la réforme française, les factures circulent entre PDP, pas directement entre entreprises. L’émetteur soumet sa facture à sa propre PDP d’émission, qui doit la transmettre à la PDP du destinataire. Le problème technique : comment la PDP émettrice sait-elle vers quelle PDP réceptrice envoyer la facture ?

C’est précisément le rôle de l’annuaire central, opéré dans le cadre du PPF (Portail Public de Facturation). L’annuaire est un référentiel qui associe chaque entreprise à son adresse de facturation électronique et à la PDP qu’elle a désignée pour recevoir ses factures.

┌──────────────┐     ┌──────────────────┐     ┌──────────────┐
│  PDP émission│────▶│    Annuaire PPF   │────▶│ PDP réception│
│              │     │                   │     │              │
│  "À qui      │     │  SIRET 12345...  │     │  "C'est pour │
│   envoyer ?" │     │  → PDP_ID: xyz   │     │   moi."      │
└──────────────┘     └──────────────────┘     └──────────────┘

Ce que l’annuaire contient (principes confirmés)

D’après les spécifications publiées par la DGFiP et les documents d’architecture de la réforme, l’annuaire associe au minimum :

• L’identifiant de l’entreprise : SIREN ou SIRET
• L’adresse de facturation électronique : l’identifiant technique permettant le routage
• La PDP désignée : la plateforme accréditée choisie par l’entreprise pour recevoir ses factures

Chaque entreprise assujettie à la TVA doit s’inscrire dans cet annuaire via sa PDP. C’est une obligation : sans inscription, aucune facture ne peut lui être adressée par voie électronique.

Ce qui reste en évolution

Avertissement : les modalités exactes d’accès à l’annuaire (API, protocole, format de réponse, authentification) font l’objet de spécifications techniques qui ont évolué au cours de la mise en place de la réforme. Les développeurs doivent se référer aux spécifications officielles publiées par la DGFiP et l’AIFE pour les détails d’intégration technique. Ce qui suit décrit les principes architecturaux confirmés, pas les détails d’implémentation des API de l’annuaire.

Le flux de routage

Le processus complet, du point de vue d’un logiciel émetteur :

1. Identifier le destinataire : récupérer le SIRET de l’acheteur
2. Consulter l’annuaire : interroger le référentiel central pour résoudre le SIRET vers une PDP et une adresse de facturation
3. Soumettre à sa PDP : transmettre la facture Factur-X à la PDP d’émission, avec les métadonnées de routage
4. La PDP d’émission route : elle utilise les informations de l’annuaire pour transmettre à la PDP de réception
5. La PDP de réception délivre : la facture arrive dans le système du destinataire

L’étape 2 est critique. Si le SIRET est incorrect, inexistant, ou si l’entreprise n’est pas inscrite dans l’annuaire, la facture ne peut pas être routée. La validation en amont du SIRET est donc un prérequis technique, pas une formalité administrative.

SIRET et SIREN : structure et validation pour développeurs

Structure

Le système d’identification des entreprises françaises repose sur deux identifiants complémentaires gérés par l’INSEE :

Le NIC (Numéro Interne de Classement) identifie un établissement au sein de l’entreprise. Une entreprise a un seul SIREN mais potentiellement plusieurs SIRET — un par établissement actif.

SIRET : 12345678901234
        └───┬────┘└─┬─┘
          SIREN    NIC
        (9 digits) (5 digits)

Conséquence pour le routage : une facture est envoyée à un établissement, identifié par son SIRET. Le SIREN seul ne suffit pas si l’entreprise a plusieurs établissements avec des PDP différentes (cas rare mais possible). L’annuaire utilise le SIRET comme clé de routage primaire.

Algorithme de validation Luhn

Les numéros SIREN et SIRET sont validés par l’algorithme de Luhn (ISO/IEC 7812-1). C’est une vérification de checksum qui détecte les erreurs de saisie courantes (inversion de chiffres, chiffre manquant).

Principe : en partant de la droite, doubler un chiffre sur deux. Si le résultat dépasse 9, soustraire 9. La somme de tous les chiffres doit être divisible par 10.

def is_valid_luhn(number: str) -> bool:
    """Valide un SIREN (9 chiffres) ou SIRET (14 chiffres) avec l'algorithme de Luhn."""
    if not number.isdigit():
        return False
    if len(number) not in (9, 14):
        return False

    digits = [int(d) for d in number]
    total = 0
    for i, digit in enumerate(reversed(digits)):
        if i % 2 == 1:
            digit *= 2
            if digit > 9:
                digit -= 9
        total += digit

    return total % 10 == 0

function isValidLuhn(number: string): boolean {
  if (!/^\d+$/.test(number)) return false;
  if (number.length !== 9 && number.length !== 14) return false;

  const digits = number.split("").map(Number).reverse();
  const total = digits.reduce((sum, digit, i) => {
    if (i % 2 === 1) {
      digit *= 2;
      if (digit > 9) digit -= 9;
    }
    return sum + digit;
  }, 0);

  return total % 10 === 0;
}

Exception connue : La Poste (SIREN 356000000) ne respecte pas l’algorithme de Luhn. C’est la seule exception documentée. En pratique, la validation Luhn est un premier filtre rapide mais ne remplace pas une vérification auprès de la base SIRENE.

Cas limites

• SIRET fermé : un établissement peut être fermé (cessation d’activité). Le SIRET reste valide au sens de Luhn mais n’est plus actif. L’annuaire de facturation ne devrait pas accepter de factures vers un SIRET fermé.
• Transfert de siège : quand une entreprise déménage, un nouveau SIRET est créé pour le nouvel établissement. L’ancien SIRET est fermé. Le SIREN reste identique.
• Entreprise en cours de création : le SIRET peut ne pas encore être référencé dans la base SIRENE. Un délai de quelques jours est normal entre l’immatriculation et l’apparition dans les API.

API SIRENE (INSEE) : vérifier un SIRET

L’API SIRENE, maintenue par l’INSEE, donne accès à la base de données SIRENE — le répertoire officiel de toutes les entreprises et établissements en France. C’est la source de vérité pour valider l’existence et l’état d’un SIRET.

Accès et authentification

• URL de base : https://api.insee.fr/entreprises/sirene/V3.11
• Authentification : token Bearer OAuth 2.0 (inscription sur api.insee.fr)
• Quotas : 30 requêtes par minute en accès libre, plus avec un contrat

Rechercher un établissement par SIRET

curl -X GET "https://api.insee.fr/entreprises/sirene/V3.11/siret/12345678901234" \
  -H "Authorization: Bearer ${INSEE_TOKEN}" \
  -H "Accept: application/json"

import httpx

INSEE_API_BASE = "https://api.insee.fr/entreprises/sirene/V3.11"

async def get_etablissement(siret: str, token: str) -> dict | None:
    """Récupère les informations d'un établissement depuis l'API SIRENE."""
    if len(siret) != 14 or not siret.isdigit():
        raise ValueError(f"SIRET invalide : {siret} (attendu : 14 chiffres)")

    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"{INSEE_API_BASE}/siret/{siret}",
            headers={
                "Authorization": f"Bearer {token}",
                "Accept": "application/json",
            },
        )

        if response.status_code == 404:
            return None  # SIRET inexistant
        response.raise_for_status()

        data = response.json()
        return data.get("etablissement")

Structure de la réponse (champs utiles)

La réponse de l’API SIRENE pour un établissement contient de nombreux champs. Voici ceux qui sont directement pertinents pour la facturation électronique :

Noms complets des champs abrégés (préfixe adresseEtablissement.) :

activitePrincipaleEtablissement
adresseEtablissement.numeroVoieEtablissement
adresseEtablissement.libelleVoieEtablissement
adresseEtablissement.codePostalEtablissement
adresseEtablissement.libelleCommuneEtablissement
etatAdministratifEtablissement

Vérifier qu’un SIRET est actif

async def is_siret_active(siret: str, token: str) -> bool:
    """Vérifie qu'un SIRET existe et correspond à un établissement actif."""
    etablissement = await get_etablissement(siret, token)
    if etablissement is None:
        return False

    etat = etablissement.get("etatAdministratifEtablissement")
    return etat == "A"  # A = actif, F = fermé

Rate limiting : l’API SIRENE applique des quotas stricts. En contexte de génération de factures en masse, implémentez un cache local avec une durée de vie raisonnable (24-72h). Les données SIRENE changent rarement pour un établissement actif.

Recherche par SIREN

Pour retrouver tous les établissements d’une entreprise (utile quand vous avez le SIREN mais pas le SIRET) :

curl -X GET "https://api.insee.fr/entreprises/sirene/V3.11/siret?q=siren:123456789" \
  -H "Authorization: Bearer ${INSEE_TOKEN}" \
  -H "Accept: application/json"

La réponse liste tous les établissements (actifs et fermés) de l’entreprise. Filtrez sur etatAdministratifEtablissement: "A" pour ne garder que les actifs.

API Entreprise (api.gouv.fr) : données enrichies

L’API Entreprise, opérée par la DINUM et accessible via entreprise.api.gouv.fr, agrège les données de plusieurs sources administratives (INSEE, Infogreffe, DGFIP, etc.). Elle fournit des informations plus riches que l’API SIRENE seule.

Conditions d’accès

L’API Entreprise n’est pas en accès libre. Elle est réservée aux :

• Administrations publiques
• Organismes investis d’une mission de service public (organismes sociaux, délégataires)

L’accès nécessite une demande formelle avec justification du cas d’usage. Les éditeurs de logiciels privés n’y ont pas accès directement — ils doivent passer par les API ouvertes (API SIRENE de l’INSEE) pour les données d’identification entreprise. L’accès à l’API Entreprise est réservé aux acteurs investis d’une mission de service public.

Données disponibles

L’API Entreprise expose des endpoints spécialisés qui agrègent des données que l’API SIRENE ne fournit pas :

Chemins complets (base : https://entreprise.api.gouv.fr) :

/v3/insee/sirene/unites_legales/{siren}
/v3/insee/sirene/etablissements/{siret}
/v3/european_commission/unites_legales/{siren}/numero_tva
/v3/infogreffe/rcs/unites_legales/{siren}/extrait_kbis
/v3/dgfip/etablissements/{siret}/attestation_fiscale

Cas d’usage pour la facturation électronique

Pour une administration ayant accès à l’API Entreprise, les cas d’usage principaux dans le contexte de la facturation sont :

1. Vérification TVA : récupérer et valider le numéro de TVA intracommunautaire via VIES (évite les saisies manuelles erronées)
2. Auto-complétion : pré-remplir les coordonnées vendeur/acheteur à partir du SIREN/SIRET
3. Attestations fiscales et sociales : dans un contexte B2G, vérifier la régularité fiscale et sociale d’un fournisseur avant émission (l’API Entreprise fournit des attestations fiscales et sociales, pas des indicateurs de solvabilité à proprement parler)

Si vous n’avez pas accès à l’API Entreprise (cas de la majorité des éditeurs privés), l’API SIRENE (section précédente) reste la source principale pour la validation des identifiants. Pour la vérification TVA, le service VIES de la Commission européenne est accessible directement.

Mapper SIRET/SIREN vers les champs Factur-X

Le lien entre les identifiants entreprise et la facture Factur-X se fait via des Business Terms EN16931 spécifiques, chacun avec un code EAS (Electronic Address Scheme) ou ICD (International Code Designator) qui précise le type d’identifiant.

Identifiants légaux (ICD codes)

Les identifiants légaux utilisent des codes ICD définis dans ISO 6523. Pour la France :

BT-30 — Identifiant légal du vendeur

BT-30 (SpecifiedLegalOrganization/ID) identifie l’entité juridique du vendeur. En France, c’est typiquement le SIREN avec le schemeID="0002", ou le SIRET avec schemeID="0009" quand l’identification de l’établissement est nécessaire.

<!-- Avec SIREN (identifiant de l'entité juridique) -->
<ram:SellerTradeParty>
  <ram:Name>Ma Société SAS</ram:Name>
  <ram:SpecifiedLegalOrganization>
    <ram:ID schemeID="0002">123456789</ram:ID>
  </ram:SpecifiedLegalOrganization>
</ram:SellerTradeParty>

<!-- Avec SIRET (identifiant de l'établissement) -->
<ram:SellerTradeParty>
  <ram:Name>Ma Société SAS</ram:Name>
  <ram:SpecifiedLegalOrganization>
    <ram:ID schemeID="0009">12345678901234</ram:ID>
  </ram:SpecifiedLegalOrganization>
</ram:SellerTradeParty>

BT-29 — Identifiant du vendeur

BT-29 (GlobalID) est un identifiant commercial du vendeur. Il peut aussi porter le SIRET :

<ram:SellerTradeParty>
  <ram:GlobalID schemeID="0009">12345678901234</ram:GlobalID>
  <ram:Name>Ma Société SAS</ram:Name>
</ram:SellerTradeParty>

BT-46 et BT-47 — Identifiants acheteur

Côté acheteur, les mêmes principes s’appliquent :

• BT-46 (BuyerTradeParty/GlobalID) : identifiant commercial de l’acheteur
• BT-47 (BuyerTradeParty/SpecifiedLegalOrganization/ID) : identifiant légal de l’acheteur

<ram:BuyerTradeParty>
  <ram:GlobalID schemeID="0009">98765432109876</ram:GlobalID>
  <ram:Name>Client SARL</ram:Name>
  <ram:SpecifiedLegalOrganization>
    <ram:ID schemeID="0002">987654321</ram:ID>
  </ram:SpecifiedLegalOrganization>
</ram:BuyerTradeParty>

Adresses électroniques de facturation (EAS codes)

Les codes EAS (Electronic Address Scheme) sont utilisés dans le champ EndpointID pour identifier l’adresse de facturation électronique d’une partie. C’est ce champ qui est prévu pour servir au routage. L’annuaire de facturation électronique est accessible via une interface web ; une API technique est prévue pour les PDP, mais sa documentation publique reste limitée à ce jour.

<!-- Adresse électronique de facturation du vendeur -->
<ram:SellerTradeParty>
  <ram:URIUniversalCommunication>
    <ram:URIID schemeID="0009">12345678901234</ram:URIID>
  </ram:URIUniversalCommunication>
</ram:SellerTradeParty>

<!-- Adresse électronique de facturation de l'acheteur -->
<ram:BuyerTradeParty>
  <ram:URIUniversalCommunication>
    <ram:URIID schemeID="0009">98765432109876</ram:URIID>
  </ram:URIUniversalCommunication>
</ram:BuyerTradeParty>

Point clé : le EndpointID (adresse électronique, BT-34 vendeur / BT-49 acheteur) est distinct de l’identifiant légal (BT-30/BT-47). BT-34 et BT-49 sont les identifiants techniques utilisés pour le routage dans les réseaux d’échange (Peppol, PPF). Leur rôle exact dans l’annuaire français dépend de l’implémentation opérationnelle de la plateforme, mais le principe est que ces champs servent au routage tandis que BT-30/BT-47 servent à l’identification juridique. Les deux peuvent contenir un SIRET, mais avec des rôles différents dans le processus.

BT-31 — Numéro de TVA du vendeur

Le numéro de TVA intracommunautaire est un identifiant fiscal distinct du SIRET. En France, il suit le format FR + 2 chiffres (clé de contrôle) + SIREN (9 chiffres) = 13 caractères.

<ram:SpecifiedTaxRegistration>
  <ram:ID schemeID="VA">FR32123456789</ram:ID>
</ram:SpecifiedTaxRegistration>

La clé de contrôle est calculée par : (12 + 3 × (SIREN % 97)) % 97. La vérification formelle peut être complétée par un appel au service VIES de la Commission européenne.

Synthèse du mapping

SIRET 12345678901234
├── SIREN : 123456789
│   ├── BT-30 schemeID="0002" → identifiant légal vendeur
│   ├── BT-47 schemeID="0002" → identifiant légal acheteur
│   └── BT-34 schemeID="0002" → adresse électronique (EAS SIREN)
│
├── SIRET complet
│   ├── BT-29 schemeID="0009" → identifiant commercial vendeur
│   ├── BT-30 schemeID="0009" → identifiant légal vendeur (si établissement)
│   ├── BT-46 schemeID="0009" → identifiant commercial acheteur
│   ├── BT-47 schemeID="0009" → identifiant légal acheteur
│   └── BT-34/BT-49 schemeID="0009" → adresse électronique (EAS SIRET)
│
└── TVA : FR32123456789
    ├── BT-31 schemeID="VA" → numéro TVA vendeur
    ├── BT-48 schemeID="VA" → numéro TVA acheteur
    └── BT-34/BT-49 schemeID="9957" → adresse électronique (EAS TVA FR)

Pour la cartographie complète des champs obligatoires EN16931, voir Champs obligatoires EN16931 : cartographie et mapping ERP.

Validation pré-envoi : vérifier avant de soumettre

Soumettre une facture avec un SIRET erroné à une PDP déclenche un rejet. Le rejet est asynchrone — il peut prendre des heures — et nécessite une correction manuelle puis une re-soumission. Valider les identifiants en amont est un investissement qui évite les cycles de rejet/correction.

Checklist de validation

VALIDATION IDENTIFIANTS — AVANT SOUMISSION PDP
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

SIRET vendeur
☐ Format : 14 chiffres
☐ Luhn : checksum valide
☐ API SIRENE : établissement existant
☐ État : actif (etatAdministratifEtablissement = "A")
☐ Présent dans BT-30 (schemeID "0002" ou "0009")

SIRET acheteur
☐ Format : 14 chiffres
☐ Luhn : checksum valide
☐ API SIRENE : établissement existant
☐ État : actif
☐ Présent dans BT-47 ou BT-46 si requis

TVA vendeur (BT-31)
☐ Format : FR + 2 chiffres + SIREN (13 caractères)
☐ Clé de contrôle cohérente avec le SIREN
☐ VIES : numéro actif (si vérification croisée)

Adresse électronique (BT-34 / BT-49)
☐ EndpointID présent avec schemeID EAS valide
☐ Valeur cohérente avec les identifiants déclarés

Cohérence croisée
☐ SIREN dans BT-30 = 9 premiers chiffres du SIRET
☐ SIREN dans le numéro TVA = SIREN déclaré
☐ Raison sociale cohérente avec les données SIRENE

Implémentation de la validation

import re

def validate_invoice_identifiers(
    seller_siret: str,
    seller_vat: str,
    buyer_siret: str,
    insee_token: str,
) -> list[str]:
    """
    Valide la cohérence des identifiants d'une facture avant soumission.
    Retourne une liste d'erreurs (vide si tout est valide).
    """
    errors: list[str] = []

    # --- SIRET vendeur ---
    if not seller_siret.isdigit() or len(seller_siret) != 14:
        errors.append(f"SIRET vendeur invalide : {seller_siret!r} (attendu : 14 chiffres)")
    elif not is_valid_luhn(seller_siret):
        errors.append(f"SIRET vendeur {seller_siret} : checksum Luhn invalide")

    # --- TVA vendeur ---
    vat_pattern = re.compile(r"^FR\d{2}\d{9}$")
    if not vat_pattern.match(seller_vat):
        errors.append(f"Numéro TVA vendeur invalide : {seller_vat!r} (attendu : FR + 11 chiffres)")
    elif seller_siret.isdigit() and len(seller_siret) == 14:
        siren_from_siret = seller_siret[:9]
        siren_from_vat = seller_vat[4:]  # FR + 2 chiffres clé + SIREN
        if siren_from_vat != siren_from_siret:
            errors.append(
                f"Incohérence SIREN : SIRET indique {siren_from_siret}, "
                f"TVA indique {siren_from_vat}"
            )

    # --- SIRET acheteur ---
    if not buyer_siret.isdigit() or len(buyer_siret) != 14:
        errors.append(f"SIRET acheteur invalide : {buyer_siret!r} (attendu : 14 chiffres)")
    elif not is_valid_luhn(buyer_siret):
        errors.append(f"SIRET acheteur {buyer_siret} : checksum Luhn invalide")

    return errors

Intégrer dans le pipeline de validation Factur-X

La validation des identifiants s’insère dans le pipeline global de validation, avant les passes XSD et Schematron :

Génération XML CII (ERP / logiciel)
        │
        ▼
[0] Validation identifiants ── ✗ ──▶ SIRET invalide / fermé / incohérent
        │ ✓
        ▼
[1] Validation XSD ──── ✗ ──▶ Corriger la structure XML
        │ ✓
        ▼
[2] Validation Schematron ─── ✗ ──▶ Corriger les règles métier BR-*
        │ ✓
        ▼
[3] Conformité PDF/A-3 ──── ✗ ──▶ Corriger le conteneur PDF
        │ ✓
        ▼
  Soumission à la PDP

L’étape 0 (validation identifiants) est un ajout au pipeline standard. Elle détecte les erreurs de routage avant qu’elles ne deviennent des rejets PDP, qui sont plus coûteux à résoudre.

Pour le détail des étapes XSD et Schematron, voir Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-*.

Parallèle avec Peppol : SMP et SML

Le réseau Peppol (Pan-European Public Procurement OnLine) utilise un mécanisme de routage conceptuellement similaire mais techniquement différent. La comparaison éclaire les choix architecturaux de la réforme française.

Architecture Peppol

Peppol utilise un système à deux niveaux :

• SML (Service Metadata Locator) : annuaire DNS centralisé. Étant donné un identifiant de participant, le SML indique quel serveur SMP contient ses métadonnées. Géré par OpenPeppol.
• SMP (Service Metadata Publisher) : serveur de métadonnées décentralisé. Contient les capacités de réception d’un participant (formats acceptés, endpoint technique, certificat).

La résolution fonctionne par requête DNS :

1. Hash(participant_id) → requête DNS vers SML
2. SML répond avec l'URL du SMP
3. Requête HTTP vers SMP → métadonnées du participant
4. Envoi via Access Point Peppol

Différences avec l’annuaire français

Convergence possible

Les PDP françaises qui sont également Access Points Peppol devront gérer les deux systèmes de routage : l’annuaire français pour le trafic domestique, et SMP/SML pour le trafic Peppol international. Cette dualité implique un mapping entre les identifiants :

• Un SIRET peut être enregistré dans l’annuaire français et comme Peppol Participant ID avec le schéma 0009 (SIRET)
• Le code ICD 0009 (ISO 6523) est le même dans les deux systèmes, utilisable comme schéma d’identifiant Peppol et comme schemeID EN16931

Pour les développeurs intégrant les deux réseaux, la bonne pratique est de normaliser les identifiants en interne et d’interroger le bon annuaire selon le contexte (domestique vs international).

Pour un comparatif détaillé des formats acceptés sur chaque réseau, voir Factur-X vs UBL vs CII : quel format choisir.

Ressources

• Facturation électronique 2026 : le guide technique complet — architecture PDP, calendrier, pipeline de validation
• Champs obligatoires EN16931 : cartographie et mapping ERP — mapping complet des Business Terms vers XML CII
• Factur-X vs UBL vs CII : quel format choisir — comparatif des formats par cas d’usage
• Valider EN16931/Factur-X : XSD vs Schematron, erreurs BR-* — debug des erreurs de validation
• API SIRENE — INSEE — documentation officielle de l’API SIRENE
• API Entreprise — api.gouv.fr — portail d’accès à l’API Entreprise
• VIES — Commission européenne — vérification des numéros de TVA intracommunautaires