Quiconque souhaite intégrer Peppol dans un système ERP, un logiciel comptable ou son propre produit logiciel fait face à deux choix. Le premier est architectural : comment votre logiciel se connecte-t-il au réseau Peppol ? Le second est pratique : à quelles exigences l’API d’un fournisseur de services doit-elle répondre pour rendre cette connexion fiable et évolutive ? Cette page compare les quatre modèles d’architecture courants et propose une liste de contrôle pour évaluer une API. Le mappage des champs et les règles de validation détaillées sortent du cadre de cette page. Pour en savoir plus sur la norme sous-jacente, consultez la page consacrée à la norme EN 16931.
Quatre modèles d'architecture
Aucun modèle n'est systématiquement le meilleur choix. Le bon choix dépend de votre échelle, du degré de maîtrise souhaité sur le processus et de la capacité dont vous disposez pour assurer vous-même la maintenance.
Connecteur dans le logiciel
Un connecteur Peppol prêt à l'emploi, intégré sous forme de plugin ou de module, souvent proposé par un fournisseur de services ou un tiers. Convient pour : une mise en production rapide, peu de maintenance propre. Avantage : délai de mise sur le marché court, fonctionnalités éprouvées. Inconvénient : moins de marge pour le sur-mesure, dépendance à la feuille de route du fournisseur.
Connexion via l'API d'un fournisseur de services
Votre logiciel communique directement avec l'API d'un fournisseur de services, qui assure la connexion au réseau. Convient pour : décider vous-même du fonctionnement de l'envoi, de la réception et du suivi des statuts. Avantage : maîtrise totale du processus et de la gestion des erreurs. Inconvénient : vous développez et maintenez vous-même la couche d'intégration.
Middleware propre
Une couche intermédiaire développée en interne ou achetée, qui donne accès à plusieurs systèmes et éventuellement à plusieurs fournisseurs de services via une interface interne unique. Convient pour : les grandes organisations disposant de plusieurs systèmes sources. Avantage : indépendance vis-à-vis d'un seul fournisseur, journalisation centralisée. Inconvénient : investissement initial plus élevé et gestion plus lourde.
Devenir vous-même fournisseur de services
Vous développez ou exploitez vous-même un point d'accès Peppol et un SMP, et devenez membre du réseau par l'intermédiaire d'une autorité Peppol. Vous disposez d'une maîtrise maximale, mais assumez aussi toutes les obligations : tests et certification, identification de vos utilisateurs finaux, disponibilité, sécurité (aux Pays-Bas, ISO 27001) et rapports obligatoires à OpenPeppol. Convient aux acteurs pour qui Peppol est au cœur de leur offre de services. Voir Qu'est-ce qu'un point d'accès Peppol ? et Devenir fournisseur de services Peppol certifié.
Les points d'attention pour une API
Si vous optez pour une connexion via une API, directement ou via un middleware, la qualité de cette API détermine en grande partie la charge de travail de l’intégration et sa stabilité dans le temps. Passez en revue ces points pour chaque API candidate.
Envoi et réception
- Validation avant envoi, avec des messages d’erreur exploitables.
- La manière dont les factures électroniques entrantes vous parviennent (push ou pull), fichier original compris.
- Webhooks ou messages de statut, et prise en charge de l’Invoice Response.
Utilisateurs finaux
- Enregistrement et gestion des identifiants Peppol via l’API.
- Multi-tenant : plusieurs clients sous une seule connexion, chacun avec son propre identifiant Peppol.
- Qui effectue l’identification de vos utilisateurs finaux, et si cela peut se faire via l’API.
- Pouvez-vous transférer les enregistrements vers un autre fournisseur ? Aux Pays-Bas, l’ancien fournisseur doit coopérer dans un délai de trois jours ouvrables.
Pays et formats
- Peppol BIS Billing 3.0 et les variantes nationales comme XRechnung et NLCIUS.
- La manière dont les nouvelles versions sont appliquées.
- La couverture des pays dotés de leur propre système, comme la plateforme agréée en France.
Technique et gestion
- Une sandbox qui simule le réseau.
- Politique de versions.
- Limites de débit (rate limits).
- Protection contre les envois en double.
- ISO 27001 ou une attestation équivalente.
Pour en savoir plus sur les formats, lisez Les formats de facture et Types de documents et normes Peppol.
Tester avant la mise en production
Une connexion API fonctionnelle ne signifie pas que l’ensemble du processus fonctionne. Testez de bout en bout dans la sandbox avec quelques partenaires commerciaux réguliers avant de mettre un client en production. Vérifiez à cette occasion l’envoi et la réception, le traitement des messages de statut et la gestion des documents rejetés.
Déployez ensuite par étapes. Commencez par un client ou un flux de documents, par exemple uniquement les factures sortantes, et montez en charge dès que ce flux fonctionne de manière stable. Les erreurs restent ainsi limitées à un petit groupe et vous tirez les leçons de la pratique avant la migration de l’ensemble de votre clientèle.
Ce que cela signifie pour les intégrateurs
Traduisez le choix d’architecture et la liste de contrôle API en actions concrètes.
- Déterminez quel modèle d’architecture correspond à votre échelle : une seule intégration ou plusieurs clients et tenants
- Interrogez chaque fournisseur d’API candidat sur la disponibilité d’une sandbox, la gestion des erreurs et la prise en charge du multi-tenant
- Prévoyez, avant la mise en production, une phase de tests avec de vrais partenaires commerciaux
- Définissez comment l’enregistrement des identifiants Peppol est automatisé dans votre processus d’onboarding
- Définissez qui réalise l’identification de vos clients finaux
Trouvez des fournisseurs de services proposant une API dans le comparateur (filtrez sur la catégorie Peppol Access Point as a Service).
Ce que cela signifie pour les éditeurs de logiciels
Pour les éditeurs de logiciels, ce choix est aussi une décision produit. Schématiquement, il existe trois voies, les mêmes que dans Démarrer avec Peppol : devenir vous-même fournisseur de services Peppol, intégrer via une API les fonctionnalités d’un fournisseur de services (éventuellement en marque blanche, sous votre propre nom), ou collaborer avec un service externe auquel vous vous connectez. Devenir vous-même fournisseur de services offre une maîtrise maximale, mais vous prenez aussi en charge la certification et la gestion dans la durée. L’intégration via une API maintient l’expérience utilisateur dans votre propre produit et externalise la connexion au réseau. Un service externe demande le moins d’investissement, mais vous laisse le moins de maîtrise.
Évaluez le rôle que joue la facturation électronique dans votre proposition de valeur : s’agit-il d’une fonction clé qui vous distingue, ou d’une fonctionnalité de base qui doit simplement fonctionner ?
Conclusion
Une bonne intégration Peppol commence par un choix d’architecture réfléchi et une évaluation critique de l’API sur laquelle vous construisez. Quel que soit le modèle choisi, les questions de la liste de contrôle déterminent l’évolutivité et la maintenabilité de votre solution. Pour en savoir plus sur les formats de facture et les types de documents, consultez Les formats de facture et Types de documents et normes Peppol. Vous cherchez des fournisseurs de services proposant une API ? Consultez le comparateur de Peppol.now.
