Build vs Buy : validation Factur-X interne vs API — coûts

En bref

• Build : scénario de validation XML à 33–51 jours, ou pipeline élargi à 90–125 jours, avec une hypothèse de 700 EUR HT/jour.
• Buy (API SaaS) : hypothèse de 2–5 jours d’intégration, à laquelle ajouter abonnement, surconsommation et maintenance de l’intégration.
• Les coûts de maintenance ci-dessous sont des budgets illustratifs, à ajuster aux profils, aux artefacts et aux cas métier réellement pris en charge.
• Comparez les deux options sur trois ans à volume et périmètre identiques. Il n’existe pas de seuil de volume universel qui rende l’une plus économique.
• La validation documentaire ne remplace ni la transmission ni l’acceptation par une Plateforme Agréée (PA).

Pour les opérations dans le champ de la réforme française, la facturation électronique passe par une PA. Le choix du format et du profil documentaire doit tenir compte des exigences du flux. La validation Factur-X, les contrôles France CTC et l’acceptation par la PA sont des étapes distinctes. La DGFiP précise le rôle des PA. Chaque éditeur ERP, chaque plateforme de gestion, chaque service comptable doit décider : construire un pipeline de validation et de conversion en interne, ou s’appuyer sur un service externe.

Ce choix n’est pas anodin. Le périmètre technique de “la conformité Factur-X” dépasse largement la validation d’un fichier XML. Il s’agit d’un pipeline multi-étapes, maintenu dans le temps, soumis à des mises à jour réglementaires régulières. Sous-estimer ce périmètre est l’erreur la plus fréquente dans les évaluations Build vs Buy.

Cet article propose des scénarios de charge, pas des prix de marché ni un devis. Les montants comparent la préparation et la validation documentaires; les coûts de PA, de transmission, d’e-reporting et d’archivage légal restent à chiffrer séparément dans les deux options. L’objectif n’est pas de vendre une solution plutôt qu’une autre, mais de donner aux CTO et architectes les éléments concrets pour une décision éclairée. Pour le contexte réglementaire complet, voir Facturation électronique 2026 : le guide technique complet pour développeurs.

Ce que la validation documentaire Factur-X exige techniquement

Contrôler un fichier Factur-X demande plusieurs familles de contrôles. Les quatre groupes suivants aident à estimer le travail; le profil Factur-X et les règles France CTC applicables doivent aussi être explicitement couverts par votre cible.

Couche 1 — Conformité PDF/A-3 (ISO 19005-3). Le conteneur PDF doit être conforme au standard d’archivage long terme : polices embarquées, profils ICC, métadonnées XMP, absence de dépendances externes. L’outil de référence est veraPDF. Les détails sont couverts dans PDF/A-3 pour Factur-X : checklist de conformité et pièges courants.

Couche 2 — Structure Factur-X. Le XML factur-x.xml doit être embarqué dans le PDF avec le bon AFRelationship, le namespace fx: dans le XMP, et le GuidelineID correspondant au profil déclaré. Un PDF/A-3 valide sans ces métadonnées n’est pas un Factur-X valide.

Couche 3 — Validation XSD CII D22B. Le XML extrait doit passer la validation structurelle contre le schéma UN/CEFACT Cross-Industry Invoice. Factur-X 1.08 / ZUGFeRD 2.4 utilisent le schéma D22B.

Couche 4 — Validation Schematron EN16931. Les règles métier BR-* du CEN TC 434 vérifient la cohérence arithmétique, les listes de codes, les contraintes conditionnelles (TVA, autoliquidation, escompte). Le catalogue des erreurs BR-* détaille chaque règle.

Au-delà de la validation, un périmètre complet inclut aussi :

• La conversion : transformer un PDF classique en Factur-X PDF/A-3 avec XML CII embarqué (voir Convertir une facture PDF en Factur-X)
• La réparation XML : appliquer les corrections déterministes couvertes, puis revalider. Dans FacturX API, /repair reçoit et renvoie du XML; le conditionnement PDF/A-3 relève de /convert. Les données métier manquantes doivent provenir d’une source fiable.
• La mise à jour des artefacts : les schémas Schematron sont versionnés, les profils Factur-X évoluent, les CIUS nationales changent

Chacun de ces éléments représente du code à écrire, tester, maintenir et mettre à jour. La validation seule peut suffire si votre système produit déjà les documents et gère les autres étapes. Ne financez que le périmètre nécessaire à votre flux.

Option Build : scénarios de coût

Hypothèses

Les scénarios ci-dessous utilisent les hypothèses de calcul suivantes, sans mesure de marché ni garantie de délai :

• TJM : 700 EUR HT/jour, hypothèse illustrative à remplacer par votre coût réel
• Stack : Java (Saxon pour Schematron, veraPDF, Apache PDFBox ou Ghostscript pour PDF/A-3)

Le coût varie significativement selon le périmètre retenu. Trois niveaux se distinguent.

Périmètre 1 — Validation seule (XSD + Schematron)

Le scénario minimal ci-dessous vise le XML CII, son schéma XSD et les règles Schematron EN16931. Ajoutez une estimation distincte si vous devez aussi prendre en charge UBL.

Coût initial : 33 × 700 = 23 100 EUR HT (bas) / 51 × 700 = 35 700 EUR HT (haut).

Budget annuel illustratif de maintenance : 15 K EUR HT/an (mise à jour des artefacts Schematron, XSD, code lists, re-test).

Périmètre 2 — Validation + conversion + extraction + réparation

Un périmètre élargi : contrôles documentaires + conversion PDF vers Factur-X + extraction XML + réparation XML. Les données, profils et extensions à couvrir doivent être précisés avant de reprendre cette estimation.

Coût initial : 90 x 700 = 63 000 EUR HT (bas) / 125 x 700 = 87 500 EUR HT (haut)

Budget annuel illustratif de maintenance : 35 K EUR HT/an (artefacts + infrastructure + évolutions fonctionnelles).

Périmètre 3 — Pipeline documentaire maintenu trois ans

Le périmètre 2 projeté sur 3 ans, incluant la maintenance continue.

Développement initial : 63–87,5 K EUR
Maintenance année 1   : 35 K EUR
Maintenance année 2   : 35 K EUR
Maintenance année 3   : 35 K EUR
─────────────────────────────────
Total 3 ans           : 168–192,5 K EUR

Le total sur trois ans comprend ici trois budgets annuels de maintenance de 35 K EUR HT, en plus du développement initial. Ajustez le calendrier, le TJM et le contenu de cette maintenance à votre organisation, sans compter deux fois les mêmes charges.

Option Buy : le coût API

L’alternative est de déléguer les traitements documentaires couverts à une API spécialisée.

Coût d’abonnement

Le coût Buy dépend du plan, du nombre de documents et des opérations facturées. Relevez le tarif et sa date, les crédits inclus, les dépassements et les limites nécessaires à votre flux sur la page pricing. Les endpoints couverts incluent validate, convert, extract et repair, avec des fonctions distinctes. Aucun montant sur trois ans ne peut être déduit du seul prix d’entrée.

Coût d’intégration

L’intégration d’une API REST dans un système existant est un travail bien balisé :

• Appels HTTP vers les endpoints (validate, convert, repair)
• Gestion des réponses (parsing JSON, codes d’erreur)
• Circuit breaker / retry pour la résilience réseau
• Tests d’intégration

Hypothèse d’intégration initiale : 2 à 5 jours, soit 1 400 à 3 500 EUR HT à 700 EUR HT/jour. Ce scénario suppose des données disponibles et un flux simple; les adaptations ERP, la supervision et les essais avec votre PA se chiffrent selon votre contexte.

Total sur 3 ans

Pour un abonnement mensuel constant, utilisez cette formule :

Coût Buy sur 3 ans = 36 × abonnement mensuel
                  + surconsommation sur 36 mois
                  + jours d’intégration × TJM
                  + maintenance de l’intégration sur 3 ans

Si le plan ou le volume change, additionnez les coûts mois par mois. Comparez ensuite ce total avec le périmètre Build qui couvre les mêmes fonctions. Le total dépend donc d’un scénario de volume et d’un tarif daté.

Le vrai coût caché du Build : la maintenance réglementaire

La sous-estimation la plus fréquente dans un projet Build concerne la maintenance des artefacts de validation. Ce n’est pas du code que vous écrivez une fois et oubliez. C’est un système vivant, soumis à des évolutions externes que vous ne contrôlez pas.

Les schémas Schematron sont versionnés. Les artefacts de validation (Schematron, code lists) et les syntaxes évoluent régulièrement : suivez les publications des mainteneurs et prévoyez du temps pour leur qualification. Chaque mise à jour peut ajouter de nouvelles règles BR-*, modifier des seuils de tolérance, ou changer le comportement de règles existantes. Vous devez télécharger les nouveaux artefacts, les compiler, les tester contre votre corpus, et les déployer.

Les profils Factur-X évoluent. Le passage de Factur-X 1.07 (CII D16B) à 1.08 (CII D22B) a introduit de nouvelles structures XML, de nouveaux éléments optionnels, et un changement de schéma XSD. Le travail d’adaptation dépend ensuite des changements de chaque publication.

Les CIUS nationales changent. Si vous traitez des factures XRechnung (Allemagne), Chorus Pro (France B2G), ou Peppol BIS, chaque CIUS a son propre cycle de mise à jour. Suivez les cycles et les dates d’application des versions que votre flux utilise.

La combinatoire explose. Chaque mise à jour d’artefact doit être testée contre chaque profil, chaque CIUS, et chaque cas métier que vous supportez. Un corpus de test de 50 factures avec 5 profils et 3 CIUS, c’est 750 validations à rejouer à chaque mise à jour.

Ce coût de maintenance est souvent invisible à l’évaluation initiale parce qu’il ne se manifeste qu’après la mise en production. C’est précisément le moment où l’équipe est passée à d’autres projets et où le budget de maintenance est réduit.

Quand Build fait sens malgré tout

Le Build n’est pas toujours le mauvais choix. Il existe des contextes où construire en interne est la bonne décision.

Volume élevé et stable. Comparez le tarif négocié de l’API avec l’infrastructure, l’exploitation et la maintenance internes. Un volume élevé peut favoriser le Build, mais ne suffit pas à démontrer sa rentabilité.

Équipe XML/validation dédiée en interne. Si votre organisation dispose déjà d’ingénieurs qui maîtrisent Saxon, Schematron, veraPDF et les spécifications CII, le coût de développement initial est significativement réduit. L’expertise existante réduit aussi le risque technique.

Vous êtes éditeur de solutions de conformité. Si la validation Factur-X est votre produit (et non un composant auxiliaire de votre produit), alors la maîtrise du pipeline est un avantage compétitif, pas un coût.

Exigences de maîtrise des données. Si votre politique interdit le traitement externe, une solution interne peut être nécessaire. Sinon, évaluez les lieux de traitement, les sous-traitants, la rétention et les engagements contractuels de chaque fournisseur.

Quand Buy est le bon choix

Vous êtes un éditeur ERP qui doit ajouter des contrôles documentaires. Une API peut réduire le travail sur les validateurs et leurs artefacts. Les 2 à 5 jours du scénario d’intégration ne comprennent pas un projet complet de facturation électronique ou de raccordement PA.

Vous n’avez pas d’expertise Schematron/PDF-A en interne. Schematron et veraPDF sont des technologies de niche. Recruter ou former une équipe sur ces sujets a un coût et un délai. Le risque d’erreurs techniques (faux positifs, faux négatifs, edge cases non couverts) est élevé sans expertise.

Vous voulez vous concentrer sur votre métier. La conformité Factur-X est de la plomberie réglementaire. Chaque jour-homme passé sur le pipeline de validation est un jour-homme en moins sur les fonctionnalités qui différencient votre produit.

Votre scénario économique favorise l’API. Si abonnement, dépassements et maintenance client restent inférieurs au coût du périmètre interne nécessaire, le Buy présente un avantage chiffrable. Faites ce calcul avec vos volumes et vos besoins réels.

Tableau comparatif

La comparaison porte sur le périmètre documentaire retenu. Pour la validation XML seule, le scénario Build est de 23 100–35 700 EUR HT initialement, puis 15 K EUR HT/an de maintenance à titre illustratif. Ce périmètre peut suffire si les autres étapes sont déjà couvertes.

Critères de décision : la grille

Au-delà des chiffres, voici les questions qui permettent de trancher.

1. Quel est votre volume mensuel ? Calculez les deux options avec votre volume, les opérations facturées et les pics de charge. Aucun seuil de factures ne remplace ce calcul.

2. La conformité Factur-X est-elle votre coeur de métier ? Si oui (vous êtes PA, éditeur de conformité), le Build est un investissement stratégique. Si non (vous êtes ERP, SaaS, cabinet comptable), c’est un coût d’infrastructure.

3. Avez-vous l’expertise en interne ? Saxon, Schematron, veraPDF, CII D22B, PDF/A-3 : si ces termes ne sont pas familiers à votre équipe, le risque technique du Build est élevé.

4. Quel est votre délai ? Depuis le 1er septembre 2026, l’obligation de réception est entrée en vigueur pour les entreprises concernées. L’émission des PME et micro-entreprises suit au 1er septembre 2027. Comparez votre reste à faire au calendrier officiel, en séparant contrôle documentaire et raccordement PA.

5. Quelle est votre politique de souveraineté données ? Si vos factures ne doivent jamais quitter votre infrastructure, retenez une architecture qui respecte cette contrainte. Sinon, examinez le contrat de sous-traitance, les transferts, la rétention et les mesures de sécurité. L’hébergement en UE et la suppression après traitement ne suffisent pas, à eux seuls, à établir la conformité RGPD de votre traitement.

Et maintenant ?

Clé Sandbox : 100 factures traitées offertes les 14 premiers jours, puis 10 factures traitées/mois. Le scanner public reste gratuit et séparé du quota API. Obtenir une clé API.

Aller plus loin

Pour approfondir chaque aspect de cette décision :

• Comparatif des outils open source : Déployer un validateur Factur-X : KoSIT, Mustangproject ou API SaaS ? — détails d’installation, limites réelles, et matrice de décision pour chaque outil
• Conversion PDF vers Factur-X : Convertir une facture PDF en Factur-X 1.08 contrôlé — les deux approches (extraction PDF et données ERP) avec exemples de code
• Automatisation CI/CD : Automatiser la validation Factur-X dans votre pipeline CI/CD — intégration GitHub Actions / GitLab CI avec gestion d’erreurs
• Comprendre les erreurs Schematron : Catalogue des erreurs BR-* EN16931 — chaque règle BR-* expliquée avec cause et correction
• Tarifs et plans : Voir les plans FacturX API — de Sandbox pour les tests à Launch puis Scale/Business