Contexte et statut des versions
La norme expérimentale AFNOR XP Z12-013 définit les API standardisées permettant l’interfaçage des systèmes d’information des entreprises (SI/SC) avec les Plateformes Agréées (PA), dans le cadre de la réforme de la facturation électronique en France.
Deux éditions de cette norme doivent être distinguées dans nos échanges avec les clients :
| Édition | Date de publication | Statut au 01/07/2026 |
| Version 1.2 | Février 2026 | Annulée le 30/06/2026 — ne doit plus être utilisée comme référence |
| Version 1.3 | Juin 2026 | En vigueur — référence actuelle à utiliser dans les échanges clients |
Tout livrable, mapping technique ou support de communication client faisant encore référence à la version 1.2 doit être mis à jour vers la version 1.3.
Point de vigilance : la V1.3 reste présentée comme une version « Beta »
Ce point mérite d’être signalé aux clients avant toute communication d’engagement ferme sur le calendrier : l’avant-propos de la version 1.2 la présentait comme suffisamment stable pour servir de référence d’implémentation. À l’inverse, l’avant-propos de la version 1.3 revient à une présentation en tant que version « Beta », ouverte à une revue publique et à des commentaires, ce qui suggère que d’autres évolutions restent possibles avant une stabilisation définitive.
Recommandation : présenter la V1.3 aux clients comme la référence actuelle obligatoire, tout en les alertant sur le fait que des ajustements mineurs restent possibles dans les prochains mois.
Évolution terminologique structurante : « OD » remplacé par « SC »
La version 1.2 employait de façon systématique le terme « OD » (Opérateur de Dématérialisation) pour désigner les solutions tierces intervenant sur le périmètre facture, y compris dans le titre même du document (« Standardisation des API SI/SC/OD ⇔ PA »). La version 1.3 abandonne cette dénomination : le document est désormais intitulé « Standardisation des API SI/SC ⇔ PA » et ne mentionne plus que la notion de « SC » (Solution Compatible) déjà présente par ailleurs dans l’écosystème réglementaire.
Impact client : tout glossaire, schéma d’architecture ou support commercial utilisant encore le sigle « OD » doit être aligné sur la terminologie « SC ».
Évolutions de l’API Flux
Webhook : sortie du statut de préversion
En V1.2, le mécanisme de Webhook n’était présenté qu’à titre informatif, dans une annexe D explicitement qualifiée de « version de travail, pour information seulement », non normative. En V1.3, ce contenu est intégré au corps du chapitre 5.6 de la norme. Il conserve toutefois le statut de recommandation et non d’exigence obligatoire pour le Fournisseur API.
La configuration de l’abonnement a par ailleurs été simplifiée : suppression du mode d’authentification OIDC à base de jetons JWT signés et d’échange de clé publique, suppression du champ « processingRule » des critères d’abonnement, et assouplissement des métadonnées désormais non obligatoires.
FlowType : distinction claire entre flux client et flux vers le PPF
Le tableau unique de qualification des flux (Tableau 3) est scindé en deux tableaux distincts : le Tableau 3.A pour les échanges entre le Client API et le Fournisseur API, et le Tableau 3.B pour les échanges entre le Fournisseur API et le Concentrateur Public du PPF. La valeur « StateInvoice » disparaît au profit de valeurs plus précises : StateCustomerInvoice, StateSupplierInvoice, StateTransactionReport(LC) et StatePaymentReport(LC).
Pagination de la route de recherche (POST /search)
Le mécanisme de pagination de la recherche de flux passe d’un système fondé sur le paramètre « updatedAfter » à un système de curseur opaque (cursor), destiné à mieux garantir l’exhaustivité de la récupération des flux sur des jeux de données dynamiques.
Autres ajustements techniques de l’API Flux
- Allongement de l’identifiant « NotOnlyUuid » à 64 caractères.
- Ajout des champs obligatoires « processingRule » et « flowProfile » dans le schéma de réponse Flow.
- Ajout de la valeur « Undefined » pour ProfileType, FlowType et ProcessingRule, non utilisable lorsque le flux est en statut En attente ou Erreur.
- Ajout du chemin de base et du nom du service comme variables dans l’URL du serveur.
Évolutions de l’API Annuaire
La version 1.3 apporte plusieurs ajustements aux routes de consultation de l’annuaire, principalement sur la route POST /v1/directory-line/search :
- Ajout d’une règle définissant la ligne d’adressage à retourner sur la route GET dédiée.
- Possibilité pour le Fournisseur API de ne pas calculer le nombre total de résultats (retour de la valeur -1 dans ce cas).
- Suppression du code de réponse 206 et des codes d’erreur 204 pour les recherches.
- Ajout du paramètre « include » à la requête de recherche des lignes d’annuaire.
- Gestion explicite des notions de « legalUnit » et « facility ».
- Ajout de l’opérateur « startWith » sur les champs businessName, name, addressLines et postalCode.
- Ajout du chemin de base à l’URL du serveur, comme pour l’API Flux.
Attention à l’inversion de la terminologie « diffusible »
La version 1.2 documentait ce critère sous l’angle du champ « NonDiffusible » (valeurs O / P / M). La version 1.3 corrige la présentation du code « O » et documente désormais ce même critère sous l’angle inverse du champ « Diffusible ». La logique fonctionnelle et les codes eux-mêmes ne changent pas, mais toute intégration ayant repris littéralement le nom ou le sens du champ tel que documenté en V1.2 doit être revérifiée pour éviter une inversion de lecture (diffusible / non diffusible).
Tableau de synthèse à l’usage des clients
| Thème | V1.2 (annulée) | V1.3 (en vigueur) |
| Statut du document | Présenté comme stable / référence d’implémentation | Présenté comme version Beta, revue publique en cours |
| Terminologie tiers | « OD » (Opérateur de Dématérialisation) | « SC » (Solution Compatible) |
| Webhook | Préversion non normative (Annexe D) | Intégré au corps de la norme (§5.6), recommandation |
| FlowType Flux 1 / PPF | Tableau unique, valeur StateInvoice | Tableaux 3.A / 3.B distincts, valeurs State(Customer/Supplier)Invoice |
| Pagination Search | Basée sur updatedAfter | Basée sur un curseur opaque |
| Annuaire — recherche | Fonctionnalités de base | Ajout include, startWith, legalUnit/facility, retour -1 si total non géré |
| Champ diffusion annuaire | Documenté comme « NonDiffusible » | Documenté comme « Diffusible » (même logique) |
Recommandations pour la communication client
- Indiquer explicitement aux clients que la V1.2 est annulée depuis le 30/06/2026 et que la V1.3 fait désormais référence.
- Mettre à jour tout support ou glossaire client mentionnant « OD » au profit de « SC ».
- Signaler le caractère encore « Beta » de la V1.3 pour éviter tout engagement de calendrier trop rigide côté client.
- Revoir les intégrations Webhook prévues ou en cours à la lumière de la simplification de la configuration d’abonnement.
- Vérifier le mapping du champ « diffusible » de l’annuaire pour écarter tout risque d’inversion de lecture.
- Se référer systématiquement aux nouveaux Swaggers normatifs (Flow_Service-1.3.0 et Directory_Service-1.3.0) pour les développements.