Mesuré, pas affirmé

Moteurs de validation comparés

Beleggo, Mustangproject, phive et 21 autres moteurs comparés

24 moteurs de validation contrôlent les mêmes 722 factures électroniques du kit de données Beleggo — XRechnung, ZUGFeRD / Factur-X, Peppol BIS 3 et CIUS nationaux, valides comme défectueuses — sur la même machine, un document après l’autre. Le validateur officiel KoSIT tourne en parallèle comme référence. Mustangproject et phive, les validateurs open source les plus répandus, sont ensuite comparés en détail à Beleggo.

Mesuré le 30 septembre 2026 sur linux x64, Intel(R) Xeon(R) Processor @ 2.10GHz × 4, 16 GiB, Node v22.22.2

Les 24 moteurs en un coup d’œil

« Profils » : combien des 11 profils du kit le moteur déclare contrôler lui-même. « Corrects » : part des documents de ces profils dont le verdict (valide ou défectueux) correspond au verdict attendu ; un document que le moteur ne peut pas juger compte comme faux. Chaque moteur couvrant d’autres profils, les pourcentages portent sur des nombres de documents différents. Le validateur KoSIT est la référence officielle pour XRechnung. Mesuré 25–30 septembre 2026.

« Règle nommée » : sur les 338 échantillons défectueux du kit, combien le moteur rejette en nommant la règle enfreinte. « Médiane » : temps par document après la mise en route ; « Mémoire » : pic du processus entier.

En détail : Beleggo, Mustangproject et phive

Verdicts corrects

Vitesse et coût

Beleggo exécute les règles Schematron officielles sous forme de code traduit en JavaScript, lues dans les mêmes feuilles de style que celles qu’exécute Saxon-JS et contrôlées sur tous les corpus de test avec Saxon-JS comme référence : mêmes constats, même texte, même ordre. Un document que les règles traduites ne peuvent pas juger exactement est confié à Saxon-JS. Le temps processeur dépasse le temps par document parce que Node.js récupère la mémoire sur ses propres threads. Le même moteur tourne dans le navigateur.

Ce que fait chaque moteur

Où et pourquoi ils diffèrent

Mustang s’écarte du verdict attendu sur 54 documents sur 722, dont 24 dans des profils qu’il ne contrôle pas du tout. Les autres ont cinq causes :

• Mustang n’applique pas les niveaux de gravité de la configuration XRechnung officielle : il manque une règle que la KoSIT élève en erreur et rejette sur une règle qu’elle abaisse en avertissement.
• Il contrôle XRechnung en CII avec le schéma Factur-X, plus étroit, au lieu de CII D16B, et signale donc des erreurs qu’aucun validateur officiel ne voit.
• Un fichier ZUGFeRD MINIMUM est du Factur-X valide, mais pas une facture électronique au sens du § 14 UStG allemand. Beleggo le dit, Mustang non : une question de droit, pas de technique.
• Mustang embarque les règles françaises CTC dans l’ancienne édition 1.3.0, où presque toutes ne font qu’avertir, et pour le CII seulement. Il accepte une facture française qui les enfreint ; à partir du 1er octobre 2026, elle est défectueuse.
• Il contrôle XRechnung avec le Schematron 2.4.0. Ce qui a été durci depuis — BR-TMP-2, un lien de pièce jointe sans https://, par exemple — il ne le signale qu’en avertissement.

Par profil

Méthode de mesure

Kit de données 0.1.0 (969f6f3ec8fdccbc), 722 documents, jugés par rapport au verdict attendu de chaque échantillon. Ce verdict vient du projet Beleggo ; pour qu’il confirme plus que Beleggo, chaque désaccord de Mustang a été vérifié à la main par rapport aux spécifications, et le validateur officiel KoSIT tourne en parallèle comme référence indépendante. Là où il juge autrement que Beleggo, la règle lui manque : les règles françaises CTC et une liste de codes Factur-X.

Beleggo artefacts 2026-08-31, Mustangproject 2.26.0, phive 4.6.0 (avec tous les modules phive-rules ; la détection de documents de phive choisit le jeu de règles), validateur KoSIT 1.6.3 · Validator Configuration XRechnung 3.0.2 2026-09-02. Chaque moteur tourne dans son propre processus, qui vit toute la mesure — les temps mesurent donc le moteur, pas le démarrage d’une machine virtuelle Java.