Invoice Validator RFE

Validez vos factures électroniques UBL, CII et Factur-X directement dans VS Code — conformité EN 16931, Peppol et règles françaises de la réforme, avec des messages d'erreur en français.

➜ Installer depuis le Marketplace VS Code

_{Créé et maintenu par Yassin Y. — logiciel libre sous licence MIT}

📖 Sommaire

• À quoi ça sert ?
• Fonctionnalités
• Formats et règles pris en charge
• Prérequis
• Installation
• Démarrage rapide
• Anonymiser une facture
• Les commandes
• Configuration
• Comment ça marche
• Structure du projet
• Mise à jour des règles officielles
• FAQ
• Limites et périmètre
• Contribuer
• Licence et composants tiers
• Avertissement

🎯 À quoi ça sert ?

La réforme française de la facturation électronique impose des factures structurées conformes à la norme européenne EN 16931 et à des règles nationales spécifiques. Avant d'envoyer une facture à une Plateforme Agréée (PA) ou au Portail Public de Facturation, encore faut-il qu'elle soit valide.

Invoice Validator RFE est une extension VS Code qui vérifie vos factures localement, sans rien envoyer sur Internet, et vous pointe précisément chaque anomalie — avec des messages en français et l'identifiant de la règle violée (ex. BR-CO-17, BR-FR-08).

Elle s'adresse aux éditeurs de logiciels, intégrateurs, comptables, DSI et équipes conformité qui préparent ou déboguent des flux de factures électroniques.

Architecture inspirée de xslt-transformer-vscode (détection du document → Saxon-HE → Schematron compilé en XSLT → rapport SVRL → diagnostics VS Code), étendue aux trois formats du socle de la réforme.

✨ Fonctionnalités

• ✅ Validation en 1 clic de fichiers .xml (UBL / CII) et .pdf (Factur-X), avec détection automatique du format.
• 🇫🇷 Messages en français : ~1560 règles EN 16931 traduites (92 % de couverture, dont 100 % des règles métier BR-*). Commutable en anglais.
• 🏛️ Règles françaises officielles embarquées : Schematron FNFE-MPE v1.4.0.03 du 04/08/2026 (BR-FR-CTC, profil étendu), en application de la norme AFNOR XP Z12-012.
• 🧱 Validation en deux couches : structure XSD (UBL 2.1 / CII D16B) puis sémantique Schematron (EN 16931 + règles FR).
• 📍 Pointage précis : chaque erreur se place sur la balise exacte désignée par le XPath du rapport SVRL ; si la balise est absente, le message indique la balise attendue.
• 🧮 Contrôles complémentaires bi-syntaxe (cohérences arithmétiques, clé de Luhn SIREN/SIRET…) absents des jeux standard.
• 🏷️ Annotation BT/BG/EXT : commente chaque balise avec son terme métier (483 entrées), pour lire une facture sans connaître la norme par cœur.
• 📋 Inventaire des termes présents dans un document.
• 🛡️ Anonymisation des identifications (SIREN, SIRET, TVA, IBAN, BIC, noms, adresses, contacts) par pseudonymes cohérents et valides : la facture anonymisée passe encore la validation, et un même vendeur garde le même pseudonyme dans tout un lot.
• 🔒 100 % local : aucune donnée de facture n'est transmise sur le réseau.

📄 Formats et règles pris en charge

Jeux activés par défaut : controles-plus + en16931 + fr-ctc. Le profil extended-ctc-fr s'utilise à la place de en16931.

🔧 Prérequis

Vérifiez Java avec java -version. Si Java n'est pas dans le PATH, indiquez son chemin via le paramètre factureValidator.javaPath.

📦 Installation

Option A — Depuis le Marketplace VS Code (recommandé)

Dans VS Code : onglet Extensions (Ctrl+Shift+X) → rechercher « Invoice Validator RFE » → Installer.

Ou en ligne de commande :

code --install-extension Yassin-Y.invoice-validator-rfe

Page de l'extension : marketplace.visualstudio.com/items?itemName=Yassin-Y.invoice-validator-rfe

⚠️ N'oubliez pas Java 11+ (voir Prérequis) : sans lui, le moteur de validation ne démarre pas.

Option B — Depuis un paquet .vsix

Téléchargez le .vsix de la dernière release, puis :

code --install-extension invoice-validator-rfe-0.19.0.vsix

Ou dans VS Code : palette de commandes → Extensions: Install from VSIX…

Option C — Depuis les sources (contributeurs)

git clone https://github.com/Yassin-xyz/Invoice-validator.git
cd Invoice-validator
npm install
npm run compile

Ouvrez le dossier dans VS Code et appuyez sur F5 pour lancer un Extension Development Host avec l'extension chargée. Pour générer un paquet : npx @vscode/vsce package.

🚀 Démarrage rapide

1. Ouvrez une facture .xml (UBL ou CII) ou un .pdf Factur-X.
2. Clic droit → « Facture: Valider (détection auto UBL / CII / Factur-X) » (ou via la palette de commandes, Ctrl+Shift+P).
3. Les anomalies apparaissent dans l'onglet Problèmes, positionnées sur la balise concernée, avec l'identifiant de règle (ex. BR-CO-17) et le jeu de règles source.

Essayez avec les fichiers fournis dans examples/ : exemple-ubl.xml, exemple-cii.xml, exemple-facturx.pdf, et les cas conformes/non conformes de examples/tests-controles-plus/.

📊 Valider un lot de factures

Pour contrôler un ensemble de factures d'un coup :

1. Bouton « Valider un dossier → rapport Excel/CSV » du panneau latéral Facture électronique, clic droit sur un dossier dans l'explorateur, ou commande « Facture: Valider un dossier… » dans la palette.
2. Choisissez le dossier : tous les .xml et .pdf situés à sa racine (les sous-dossiers ne sont pas parcourus) sont validés l'un après l'autre, avec les jeux de règles configurés. La progression est annulable — en cas d'interruption, un rapport partiel reste proposé.
3. Choisissez le format (Excel .xlsx ou CSV ;), puis l'emplacement d'enregistrement.

Le rapport contient une ligne par anomalie :

Le classeur Excel ajoute un onglet Synthèse (une ligne par fichier + total), un en-tête figé, des filtres automatiques et des lignes colorées selon la gravité. Les anomalies restent également consultables dans l'onglet Problèmes de VS Code.

🛡️ Anonymiser une facture

Pour transmettre une facture à un support, un intégrateur ou un ticket public sans divulguer l'identité des parties :

1. Bouton « Anonymiser cette facture » du panneau latéral, clic droit sur un .xml ou un .pdf dans l'explorateur, ou commande « Facture: Anonymiser… ».
2. Le fichier d'origine n'est jamais modifié : le résultat est écrit à côté, sous le nom …anonymise.xml (ou …anonymise.pdf).

Ce qui est remplacé — les identifiants légaux, fiscaux et bancaires (SIREN BT-30/47, SIRET BT-29b, TVA BT-31/48/63, IBAN BT-84/91, BIC BT-86, carte BT-87) et, par défaut, les noms, adresses postales et coordonnées de contact (BT-27/28/41→45, BT-50→58, BG-5/6/8/9/15…). Les codes pays sont conservés : ils conditionnent les règles de TVA.

Le repérage s'appuie sur la table des termes métier déjà utilisée par l'annotation BT, complétée par l'attribut schemeID (0002 = SIREN, 0009/0225 = SIRET) — l'UBL et le CII sont donc traités par le même mécanisme. Une seconde passe balaie le texte libre (cbc:Note, ram:Content, libellés) où IBAN, courriels et numéros se glissent souvent en clair.

Des pseudonymes valides, pas des XXXXXXXXX

Un identifiant masqué ferait échouer la facture anonymisée sur les contrôles de l'extension elle-même (règle ID-01, clé de Luhn). Les valeurs de substitution sont donc générées avec des clés correctes :

Cohérence

Les substitutions sont déterministes : à graine égale, une même valeur d'origine donne toujours le même pseudonyme. Un vendeur reste donc le même vendeur d'une facture à l'autre, et les liens internes (SIREN ↔ SIRET ↔ TVA) restent vrais. La commande « Anonymiser un dossier » traite tous les .xml / .pdf de la racine d'un dossier vers un sous-dossier anonymise/.

Changez factureValidator.anonymize.seed pour obtenir un tout autre jeu de pseudonymes.

⚠️ Sur un PDF Factur-X, le visuel n'est pas anonymisé

Pour un .pdf, l'extension anonymise le XML embarqué, les métadonnées XMP et le dictionnaire Info — pas les pages imprimées, qui continuent d'afficher la raison sociale, l'adresse et l'IBAN d'origine. Un avertissement le rappelle à chaque traitement. Le PDF produit reste donc utilisable comme jeu d'essai structuré, jamais comme document diffusable en l'état.

Enfin, « anonymiser » est ici un raccourci : montants, dates et désignations d'articles sont conservés, et peuvent suffire à ré-identifier l'émetteur dans un secteur étroit. Il s'agit d'une pseudonymisation.

⚠️ Le texte libre n'est traité qu'en partie

Les notes (cbc:Note, ram:Content), les libellés et autres champs rédigés sont bien balayés : les valeurs déjà pseudonymisées ailleurs dans la facture y sont propagées, et les motifs reconnaissables (courriel, IBAN, n° de TVA, et — en texte rédigé — téléphone, SIREN/SIRET précédés d'un mot-clé) y sont remplacés.

En revanche, une identification que rien ne permet de reconnaître comme telle y subsiste : un nom propre qui n'apparaît dans aucune balise identifiée, ou un identifiant isolé sans mot-clé (SIREN, SIRET, TVA…) dans le même texte. Ce garde-fou est volontaire — sans lui, une référence de commande à neuf chiffres serait prise pour un SIREN — mais il laisse un angle mort. Un avertissement le rappelle à chaque anonymisation. Relisez les notes du fichier produit avant diffusion ; le détail est dans LIMITES.md.

⌨️ Les commandes

Accessibles via la palette (Ctrl+Shift+P), le menu contextuel ou la barre de titre de l'éditeur :

⚙️ Configuration

Réglages disponibles dans les paramètres VS Code (préfixe factureValidator.) :

Les limites connues et assumées de l'extension (annotation des remises CII, éléments hors socle EN 16931, performance des lots) sont documentées dans LIMITES.md.

Jeux de règles disponibles : controles-plus, en16931, peppol (UBL), fr-ctc, extended-ctc-fr (remplace en16931), facturx-en16931 (CII), en16931-cef.

Ajouter vos propres règles françaises (spécifications externes AIFE/DGFiP, profils Factur-X…) : compilez un .sch avec scripts/compile-schematron.sh, puis référencez le XSLT généré dans customSchematronXslt. Voir validation-artifacts/schematron/fr/README.md.

🔬 Comment ça marche

La couche XSD s'appuie sur une classe Java précompilée (messages traduits, lignes exactes). La couche Schematron utilise Saxon-HE pour exécuter les Schematron compilés en XSLT 2.0, qui produisent un rapport SVRL (Schematron Validation Report Language) transformé en diagnostics VS Code.

🗂️ Structure du projet

src/
  extension.ts                  Point d'entrée, commandes, validate-on-save
  commands/                     Orchestration des commandes (valider, annoter, inventaire, anonymiser)
  detection/formatDetector.ts   UBL / CII / PDF Factur-X
  facturx/
    extractFacturX.ts           Extraction du XML embarqué dans le PDF
    replaceFacturX.ts           Réinjection du XML anonymisé + nettoyage XMP / Info
  validation/
    schematronValidator.ts      Résolution des jeux de règles + exécution Saxon
    svrlParser.ts               Parsing du rapport SVRL
    diagnostics.ts              SVRL → diagnostics VS Code
    xsdValidator.ts             Couche structurelle XSD
    xmlLocator.ts               Localisation d'une balise par XPath
  annotation/btAnnotator.ts     Annotation des balises BT/BG/EXT
  anonymize/
    btTargets.ts                Termes porteurs d'une identification → nature du pseudonyme
    anonymizer.ts               Passes structurelle et texte libre
    vault.ts                    Table origine → pseudonyme, cohérence SIREN/SIRET/TVA
    generators.ts               Valeurs de substitution à clés valides (Luhn, mod 97)
  i18n/translator.ts            Traduction FR des messages
  ui/panelView.ts               Panneau latéral « Facture électronique »
scripts/
  compile-schematron.sh         Compile un .sch en .xslt (règles FR)
  download-artifacts.sh         Met à jour Saxon + Schematron officiels
tools/iso-schematron/           Squelette ISO Schematron (.sch → XSLT 2.0)
validation-artifacts/
  schematron/                   XSLT prêts à l'emploi (en16931, peppol, fr, controles-plus)
  xsd/                          Schémas structurels UBL 2.1 / CII D16B
  i18n/                         Traductions FR, carte BT → balise
lib/saxon-he-10.9.jar           Moteur XSLT 2.0
examples/                       Factures d'exemple (UBL, CII, Factur-X) + cas de test

🔄 Mise à jour des règles officielles

Les normes EN 16931 et Peppol évoluent trimestriellement, et les règles françaises FNFE-MPE au fil des publications. Pour rester à jour :

scripts/download-artifacts.sh   # Saxon + Schematron EN 16931 / Peppol officiels

Pour les règles françaises, récupérez la nouvelle release du FNFE-MPE (fnfempe/France_RFE) et recompilez.

❓ FAQ

Mes factures sont-elles envoyées quelque part ? Non. Toute la validation est locale ; aucune donnée n'est transmise sur le réseau.

Une facture « valide » ici est-elle certifiée conforme ? Non. La validation opposable reste celle de votre Plateforme Agréée. Cet outil vous aide à détecter les anomalies en amont, il ne remplace pas la PA.

Pourquoi Java est-il requis ? Le moteur Saxon-HE (XSLT 2.0) qui exécute les Schematron est écrit en Java. C'est le seul prérequis externe.

Puis-je ajouter mes propres règles ? Oui, via factureValidator.customSchematronXslt (voir Configuration).

La traduction française est-elle officielle ? Non, c'est une traduction de courtoisie (couverture 92 %). En cas de doute, basculez sur messageLanguage: original et consultez le texte de la norme.

L'extension gère-t-elle la conformité PDF/A-3 du Factur-X ? Non, c'est hors périmètre — utilisez veraPDF pour cela.

Et l'e-reporting ? Non. L'extension valide la facture (e-invoicing) ; les données de transaction et de paiement du Flux 10 relèvent d'un autre format et d'un autre jeu de règles. L'AIFE a publié un Schematron pour ce flux en juillet 2026, mais réservé aux Plateformes Agréées : il n'est ni redistribuable ni actualisable depuis une source publique, donc pas embarquable. Si vous y avez accès, voir LIMITES.md pour le brancher via customSchematronXslt.

🚧 Limites et périmètre

• La conformité aux règles nationales ne vaut pas certification : la validation finale reste celle de votre Plateforme Agréée / PPF.
• Hors périmètre : la conformité PDF/A-3 du conteneur Factur-X (voir veraPDF) et les contrôles de plateforme (existence du SIREN à l'annuaire, doublons, cycle de vie) qui nécessitent le PPF/PA.
• L'e-reporting (Flux 10) n'est pas validé : l'extension ne traite que la facture elle-même. Le Schematron du Flux 10 publié par l'AIFE en juillet 2026 n'est diffusé qu'aux Plateformes Agréées, donc ni redistribuable ni actualisable depuis une source publique. Détail dans LIMITES.md.
• La traduction FR couvre 92 % des règles (100 % des règles métier BR-*) ; le reste s'affiche en anglais.
• Anonymisation : le rendu visuel d'un PDF Factur-X n'est pas modifié, et les données non identifiantes (montants, dates, désignations) sont conservées. Détail dans LIMITES.md.

🤝 Contribuer

Les contributions sont les bienvenues — corrections de traduction, nouvelles règles, documentation, tests. Lisez d'abord le guide de contribution et le code de conduite.

⚠️ Ne partagez jamais de facture réelle contenant des données personnelles ou commerciales dans une issue ou une PR : anonymisez, ou repartez des exemples de examples/.

Pour signaler une faille de sécurité, suivez la politique de sécurité.

📜 Licence et composants tiers

Le code de l'extension est distribué sous licence MIT.

Les artefacts de validation tiers embarqués (Saxon-HE, Schematron EN 16931, règles Peppol, règles FNFE-MPE, schémas XSD OASIS/UN-CEFACT…) restent régis par leurs licences respectives — voir NOTICE.md pour le détail.

⚠️ Avertissement

Ce logiciel est fourni « en l'état », sans garantie. Il constitue une aide au contrôle, pas un outil de certification. La conformité réglementaire de vos factures relève de votre responsabilité et de la validation par votre Plateforme Agréée. Les textes normatifs (EN 16931, XP Z12-012, spécifications AIFE/DGFiP) évoluent : vérifiez toujours la version en vigueur.