OpenPeppol a repris le SML de Peppol : pourquoi les recherches dans l’ancienne zone de la CE renvoient silencieusement des données obsolètes

Le 2 septembre 2026, OpenPeppol a achevé la reprise du Service Metadata Locator (SML), l’annuaire fondé sur le DNS qui indique au point d’accès expéditeur où sont publiées les métadonnées d’un destinataire. Jusqu’alors, le SML était hébergé par la Commission européenne sous edelivery.tech.ec.europa.eu. Il est désormais exploité par OpenPeppol sous participant.sml.prod.tech.peppol.org. Sur le plan technique, le changement est mineur - il s’agit simplement d’une autre zone DNS -, mais il a un effet secondaire facile à manquer : l’ancienne zone continue de répondre, avec des résultats de plus en plus erronés.

Ce qui a changé, et quand

• 19 mars 2026 - ouverture de la fenêtre de migration ; la nouvelle zone OpenPeppol commence à répliquer la zone de la CE.
• 31 mai 2026 - date limite pour que les prestataires SMP transfèrent leurs appels d’enregistrement et de gestion vers le point de terminaison OpenPeppol.
• 31 août 2026 - date limite pour que les points d’accès et les autres clients de recherche basculent leurs requêtes DNS vers la nouvelle zone.
• 2 septembre 2026 - le SML d’OpenPeppol devient le système principal ; l’environnement de la CE ne fait plus partie de la chaîne de production.
• Septembre 2026 - la zone de la CE doit être mise hors service à la discrétion de la Commission.

Pourquoi l’ancienne zone est dangereuse, et pas seulement obsolète

Une zone mise hors service échouerait de manière évidente : chaque recherche renverrait « introuvable » et tout système de surveillance le détecterait en quelques minutes. L’ancienne zone de la CE fait pire. Elle continue de renvoyer des enregistrements, mais les prestataires SMP ayant achevé leur migration ne la mettent plus à jour. Pour un client qui interroge encore l’ancienne zone, trois phénomènes se produisent sans le moindre avertissement :

• les participants enregistrés par l’intermédiaire d’un SMP migré après sa bascule n’existent pas - la recherche renvoie « non enregistré » ;
• les participants passés d’un prestataire à un autre semblent toujours dépendre de leur ancien prestataire ;
• les participants désinscrits par un SMP migré apparaissent toujours comme enregistrés.

Aucune erreur ne se produit. Les données cessent simplement d’évoluer pour une part croissante du réseau, à mesure que chaque SMP migre.

Ce que nous avons observé dans nos propres données

Si nous écrivons cet article, c’est parce que cela nous est arrivé. L’attribution d’un prestataire et l’indicateur « acheminable / non acheminable » figurant sur chaque page de participant sont issus des recherches dans le SML. Entre le 2 et le 14 septembre 2026, ces recherches étaient encore effectuées dans l’ancienne zone. Nous avons découvert le problème lorsque Michael Walther, de The Invoicing Hub, nous a envoyé trois exemples dans lesquels notre page contredisait la recherche de référence sur peppol.helger.com : un participant présenté comme non acheminable alors qu’il l’était manifestement - il avait été enregistré par l’intermédiaire d’un SMP migré le 13 septembre - et deux participants encore associés à leur ancien prestataire après avoir migré respectivement vers Pennylane et ITEMS.

Le 14 septembre, nous avons redirigé toutes les recherches vers la zone OpenPeppol, puis résolu de nouveau l’ensemble du réseau pendant la nuit. Les chiffres montrent à quelle vitesse les deux zones divergent :

• Sur environ 183 000 participants que nous avions classés comme « non acheminables » et revérifiés pendant la nuit, 3 532 (environ 1,9 %) étaient en réalité enregistrés sur le réseau. Ils nous étaient invisibles uniquement parce que leur SMP avait déjà migré.
• Parmi les participants enregistrés durant la semaine précédant la correction, la situation était bien pire : dans un échantillon de résultats récents indiquant « introuvable », 9 sur 10 étaient faux.
• D’un jour à l’autre, le nombre de participants associés à un prestataire a augmenté d’environ 39 000 - soit à peu près trois fois la hausse d’une journée normale - et 18 800 participants jusque-là classés comme « inconnus » se sont vu attribuer un prestataire. Les plus fortes progressions ont concerné Pennylane (+8 558), Indy (+6 826), Banqup/Jefacture (+6 719), Saphety (+3 089) et Axway (+2 362). Une partie correspond à la croissance quotidienne ordinaire, le reste au rattrapage entre les deux zones.

Dans nos données, les écarts les plus importants entre les deux zones concernaient les SMP ayant migré tôt, notamment Pennylane, Jefacture (Banqup), peppolint (ITEMS), eezi, Odoo, Storecove et Myflowin. Les enregistrements effectués par l’intermédiaire de SMP ayant migré tardivement, ou des grands SMP nationaux, restaient identiques dans les deux zones.

Deux conséquences sont à retenir pour les lecteurs de nos statistiques : les décomptes par prestataire et les chiffres des participants « non acheminables » ont évolué le 15 septembre pour des raisons techniques, et non sous l’effet d’une croissance organique ou d’une rotation des participants ; toute comparaison entre nos données du 2 au 14 septembre et l’état réel du réseau doit donc en tenir compte.

Si vous effectuez vos propres recherches Peppol

Toute personne ayant développé à partir du SML des outils de vérification des participants, de surveillance ou d’analyse - intégrateurs, éditeurs d’ERP, services de vérification d’identifiants, chercheurs - devrait contrôler la zone interrogée par son code. La zone de production est iso6523-actorid-upis.participant.sml.prod.tech.peppol.org ; la zone de test (SMK) est iso6523-actorid-upis.participant.sml.test.tech.peppol.org. Le hachage de l’identifiant du participant - Base32 de SHA-256, enregistrement U-NAPTR - reste inchangé : la bascule ne nécessite donc que la modification d’une ligne de configuration. Pour vérifier rapidement un résultat, il est possible d’utiliser l’outil de recherche de participants sur peppol.helger.com, qui interroge déjà la zone OpenPeppol.

Nous en tirons une leçon qui dépasse cette seule migration : un service de découverte qui continue de répondre alors qu’il ne fait plus autorité pose un problème de qualité des données, et non de disponibilité. Il nécessite donc un autre type de contrôle que la simple surveillance de la disponibilité. De notre côté, nous interrogeons désormais immédiatement le SML chaque fois qu’un SMP ne reconnaît plus un participant, nous actualisons dans l’heure toute page de participant consultée dont les données datent de plus de trois jours et nous affichons une date de « dernière vérification » sur chaque page de participant.

Remerciements

Nous remercions Michael Walther, de The Invoicing Hub, qui, pour la deuxième fois, a pris le temps de comparer nos pages de participants avec l’état réel du réseau et de nous transmettre des exemples précis et reproductibles. Sans eux, nous n’aurions constaté cette divergence qu’au moment où la Commission aurait désactivé l’ancienne zone.