Intégration de l'API AFNOR

L’API AFNOR, formellement la norme française XP Z12-013, est une interface commune que toute plateforme agréée (PA, anciennement PDP) peut proposer. Un logiciel qui l’implémente une fois peut se connecter à toute plateforme qui la propose, sans développement supplémentaire. C’est le rôle de ce canal : plutôt que de prendre en charge l’API propre de chaque plateforme l’une après l’autre, le module parle la norme, et vous le dirigez vers une plateforme qui l’implémente.

Le module propose une entrée AFNOR, SUPER PDP (AFNOR API). D’autres plateformes sont ajoutées à mesure qu’elles sont vérifiées. Si une plateforme précise vous intéresse, écrivez à contact@nomu.agency.

Tout ce qui suit s’applique au module à partir de la version 1.11.0, et à la réforme française. Voir La réforme en France pour savoir qui doit émettre des factures électroniques, et à partir de quand.

Lequel des deux fournisseurs choisir

Le module liste SUPER PDP deux fois, une pour son API JSON propre et une pour l’API AFNOR. Les deux atteignent la même plateforme et le même compte, et la plateforme partage les mêmes données entre les deux. Rien n’est perdu si vous commencez par l’un et passez ensuite à l’autre.

	SUPER PDP	SUPER PDP (AFNOR API)
Interface	L’API JSON propre à la plateforme	La norme XP Z12-013
Fonctionne avec une autre plateforme	Non	Oui, une fois cette plateforme ajoutée au module
Le test de connexion indique	L’entreprise et l’environnement auxquels appartiennent vos identifiants	Seulement que les identifiants ont été acceptés
L’adresse du client	Vérifiée avant l’acceptation de la facture	Vérifiée par la plateforme après l’acceptation

Choisissez le fournisseur AFNOR si vous voulez la norme plutôt que l’interface d’un éditeur. Choisissez SUPER PDP si c’est la seule plateforme que vous utilisez et que vous voulez un retour plus complet.

Prérequis

Prérequis	Remarques
Le module installé et fonctionnel	Vous pouvez déjà télécharger une facture électronique depuis une commande
Un compte sur une plateforme qui propose l’API AFNOR	SUPER PDP est celle qui figure aujourd’hui dans la liste du module
Un identifiant client et un secret client de cette plateforme	Délivrés par la plateforme, pas par la norme
L’extension PHP `curl`	Le test de connexion signale son absence
Une connexion HTTPS sortante vers `api.superpdp.tech`	Demandez à votre hébergeur si les connexions sortantes sont filtrées
Le SIREN de votre entreprise	Saisi dans le bloc Paramètres réglementaires France du module
Le SIREN de vos clients	Seules les factures adressées à une entreprise identifiée sont envoyées

La norme couvre l’envoi des factures, pas l’inscription. Chaque plateforme gère sa propre création de compte, ses propres vérifications d’identité et ses propres identifiants. La configuration ci-dessous est donc la procédure de SUPER PDP. Une autre plateforme a la sienne, et seuls les champs du module restent identiques.

Créer un compte et obtenir les identifiants

L’API AFNOR de SUPER PDP utilise le même compte et le même type d’application OAuth que l’API propre de la plateforme. La configuration ne change donc pas :

Créez le compte sur superpdp.tech, via Connexion puis Créer un compte. Deux entreprises fictives du bac à sable (sandbox), Burger Queen et Tricatel, sont créées avec lui.
Allez dans Applications, cliquez sur Nouvelle application, choisissez l’entreprise, puis cliquez sur Créer.
Copiez tout de suite le client_id et le client_secret. Le secret n’est affiché qu’une fois.

Intégration SUPER PDP décrit ces deux étapes en détail, y compris le passage du bac à sable à la production.

Le module s’authentifie en OAuth 2.1 avec le flux client credentials, celui que la norme prévoit pour un logiciel qui accède à son propre compte. Le bac à sable et la production se distinguent par les identifiants que vous utilisez, pas par un réglage.

Saisir les identifiants dans PrestaShop

Allez dans Modules → Gestionnaire de modules → Facturation électronique Prestashop 2026 → Configurer, puis descendez jusqu’au bloc Paramètres PDP.

Champ	Valeur à saisir
Envoyer à la PDP	Activé. Rien n’est envoyé tant qu’il est désactivé
Fournisseur PDP	SUPER PDP (AFNOR API)
Identifiant client PDP	Le `client_id` de l’étape précédente
Secret client PDP	Le `client_secret` de l’étape précédente

Cliquez sur Enregistrer.

Le secret est stocké chiffré et n’est jamais renvoyé à votre navigateur, le champ paraît donc vide après l’enregistrement. Le laisser vide conserve le secret enregistré. Saisissez une valeur uniquement pour le remplacer.

Il n’y a pas de champ pour l’adresse de la plateforme. L’URL de base de chaque plateforme prise en charge est intégrée au module, car vos identifiants et chaque facture que vous émettez partent vers cette adresse. Un champ du back-office ne doit pas pouvoir la rediriger.

Tester la connexion

Dans le bloc Paramètres PDP, cliquez sur Tester la connexion PDP. Le test utilise les valeurs affichées dans le formulaire, vous pouvez donc essayer des identifiants avant de les enregistrer. Si le champ du secret est vide, le secret enregistré est utilisé.

Le test fait deux choses : il échange vos identifiants contre un jeton, puis il appelle le contrôle de santé de la plateforme. En cas de succès, une alerte verte s’affiche, Connecté à SUPER PDP (AFNOR API). Identifiants acceptés. En cas d’échec, une alerte rouge en donne la raison.

Un succès ne vous dit pas tout. La norme ne prévoit aucune opération qui décrit le compte derrière les identifiants. Le module ne peut donc ni nommer votre entreprise, ni dire si vous êtes dans le bac à sable ou en production. Notez de quelle application viennent les identifiants que vous avez collés.

Message	Signification
`A client ID and a client secret are required.`	L’un des deux champs est vide
`HTTP 401: Client authentication failed (...)`	Identifiant client ou secret erroné, ou application supprimée
`HTTP 503` ou `HTTP 500`	Les identifiants ont été acceptés, mais le service ne répond pas. Consultez status.superpdp.tech
`The platform could not be reached.`	Aucune connexion sortante vers la plateforme
`The PHP curl extension is not installed or enabled.`	Demandez à votre hébergeur d’activer `curl`

Envoyer une facture de test depuis le bac à sable

Le parcours est le même qu’avec l’API propre de la plateforme : une facture de Burger Queen, votre boutique, à Tricatel, votre client.

Configurez le module avec les identifiants de l’application Burger Queen, et renseignez le SIREN vendeur avec le numéro de Burger Queen.
Dans l’adresse de facturation d’un client de test, remplissez les champs SIREN et Suffixe avec l’adresse de facturation électronique de Tricatel dans le bac à sable. Les adresses du bac à sable ont la forme technique 315143296_XXX : 315143296 va dans le champ SIREN et la partie XXX dans le suffixe. En production, l’adresse est normalement le SIREN seul du client.
Passez une commande pour ce client et générez sa facture, en mettant la commande dans un statut qui en crée une, par exemple Paiement accepté.
La facture est déposée à ce moment-là, et la commande conserve le résultat.
Vérifiez-la dans votre compte sur la plateforme.

Cette dernière étape compte davantage sur ce canal que sur l’autre. La plateforme répond que le dépôt est accepté pour traitement, et une acceptation n’est pas une validation : le contrôle au regard des règles officielles, la recherche dans l’annuaire et la remise à votre client ont lieu ensuite. Une facture que le module enregistre comme envoyée peut encore être rejetée un instant plus tard, et seul votre compte sur la plateforme le montre.

Renvoyer une facture en échec

Il n’y a pas de nouvelle tentative automatique. Lorsque l’envoi est activé, chaque ligne de Commandes propose une action Envoyer à la PDP. Elle redépose toutes les factures de la commande et remplace le résultat précédent. La marche à suivre :

Lisez la cause de l’échec, dans le message affiché ou dans Paramètres avancés → Logs, en cherchant ExportPeppol.
Corrigez la cause, le plus souvent le SIREN ou le suffixe de l’adresse de facturation du client.
Cliquez sur Envoyer à la PDP sur la commande.

Une facture rejetée après acceptation reste comptée comme envoyée dans PrestaShop. Dans ce cas, le renvoi part de ce que vous voyez dans votre compte sur la plateforme.