En bref
- Build : pipeline multi-étapes (PDF/A-3, XSD, Schematron, veraPDF) à construire, tester et maintenir. Investissement initial 15-40 j/h, maintenance ~5 j/h/an.
- Buy (API SaaS) : intégration en 1-3 jours, coût proportionnel au volume, maintenance déléguée (mises à jour schémas, veraPDF, profils).
- Le vrai coût du build : pas la première version — les mises à jour régulières des artefacts EN16931, les nouvelles extensions CIUS, les patchs veraPDF.
- Point de bascule : au-delà de ~1000 factures/mois, le coût API mensuel peut justifier un investissement Build. En dessous, l’API est quasi toujours plus économique.
- Plan Free : 10 opérations/mois (dev/test). Integration : 99 €/mois (production). Business : 249+ €/mois (gros volumes).
La réforme de facturation électronique impose la conformité EN16931 pour les échanges B2B via les PDP. 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 chiffre les deux approches avec des hypothèses explicites. 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 “conformité Factur-X” exige techniquement
La conformité Factur-X ne se résume pas à “valider un XML”. C’est un pipeline en quatre couches, chacune nécessitant ses propres outils, artefacts et compétences.
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 200+ 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 automatique : corriger les erreurs réparables dans les factures reçues (namespaces manquants, formats de date, codes TVA)
- 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. Un périmètre réduit (validation seule, sans conversion ni réparation) coûtera moins — mais un périmètre réduit est rarement suffisant en production.
Option Build : le coût réel
Hypothèses
Les estimations ci-dessous sont développées par un backend senior en France. Les hypothèses communes :
- TJM : 700 EUR HT/jour (taux journalier moyen senior backend, marché français 2026)
- 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 périmètre minimal : valider un XML CII ou UBL contre le schéma XSD et les règles Schematron EN16931.
| Composante | Jours-homme | Ce qu’elle couvre |
|---|---|---|
| Architecture + setup pipeline | 8-10 | Design du pipeline de validation, orchestration, gestion d’erreurs |
| Validation XSD | 5-8 | Intégration schéma CII D22B, parsing des erreurs |
| Validation Schematron (Saxon) | 12-18 | Compilation XSLT, exécution des règles BR-*, mapping des codes d’erreur |
| Tests + dataset de référence | 5-10 | Corpus de factures valides/invalides, couverture des profils |
| Documentation | 3-5 | API interne, runbooks |
| Total | 30-50 |
Coût initial : 30 x 700 = 21 000 EUR HT (bas) / 50 x 700 = 35 000 EUR HT (haut), soit ~25 K EUR en médiane.
Maintenance annuelle estimée : ~15 K EUR/an (mise à jour des artefacts Schematron, XSD, code lists, re-test).
Périmètre 2 — Validation + conversion + extraction + réparation
Le périmètre de production courant : validation 4 couches + conversion PDF vers Factur-X + extraction XML + réparation automatique.
| Composante | Jours-homme | Ce qu’elle couvre |
|---|---|---|
| Architecture + setup pipeline | 15-20 | Design du pipeline complet, choix de stack, orchestration des étapes, gestion d’erreurs |
| Intégration veraPDF | 10-15 | Validation PDF/A-3, parsing des rapports, gestion des profils ICC et polices |
| Validation Schematron (Saxon) | 15-20 | Compilation XSLT, exécution des règles BR-*, parsing des résultats, mapping des codes d’erreur |
| Génération PDF/A-3 + embedding XML | 20-30 | Conversion Ghostscript, embedding factur-x.xml, métadonnées XMP, AFRelationship |
| Tests + dataset de référence | 20-30 | Corpus de factures valides/invalides, couverture des profils, edge cases (autoliquidation, multi-taux, BTP) |
| Documentation | 10 | API interne, runbooks, procédures de mise à jour des artefacts |
| Total | 90-125 |
Coût initial : 90 x 700 = 63 000 EUR HT (bas) / 125 x 700 = 87 500 EUR HT (haut)
Maintenance annuelle estimée : ~35 K EUR/an (artefacts + infrastructure + évolutions fonctionnelles).
Périmètre 3 — Full compliance engine maintenu 3 ans
Le périmètre 2 projeté sur 3 ans, incluant la maintenance continue.
Développement initial : 63-87 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 K EURCes estimations reflètent le périmètre 2 ou 3. Le périmètre 1 est significativement moins coûteux. Un TJM parisien senior peut atteindre 900 EUR/jour ; un développeur en région ou en offshore sera en dessous de 700 EUR. Adaptez le TJM et le périmètre à votre contexte.
Option Buy : le coût API
L’alternative est de déléguer le pipeline de conformité à une API spécialisée.
Coût d’abonnement
Le coût Buy dépend du plan choisi. À titre indicatif, les plans production commencent à moins de 100 EUR/mois pour un volume PME, soit un coût total sur 3 ans inférieur à 10 K EUR (intégration incluse). Consultez la page pricing pour les tarifs actuels. Les endpoints couverts incluent validate, convert, extract et repair.
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
Effort estimé : 2 à 5 jours-homme, soit 1 400 à 3 500 EUR.
Total sur 3 ans
Le total Buy sur 3 ans se situe typiquement sous les 10 K EUR pour un volume PME (intégration initiale + abonnement 36 mois). Ce montant peut varier selon le plan et le volume — consultez la page pricing pour un calcul précis.
Le différentiel avec le Build (périmètre 2 ou 3) est d’un ordre de grandeur significatif. Mais le coût brut n’est pas le seul critère de décision.
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 — par exemple, une release EN16931 v1.3.15 a été publiée en mars 2026. Il n’y a pas de calendrier fixe, mais compter 2 à 4 mises à jour significatives par an est une estimation raisonnable. 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. La prochaine version nécessitera le même travail d’adaptation.
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. XRechnung publie une nouvelle version tous les six mois.
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 très élevé (> 100 000 factures/mois). Au-delà d’un certain volume, le coût marginal d’une API par facture peut dépasser le coût marginal d’un pipeline interne dont l’infrastructure est amortie. Le point d’inflexion dépend du pricing de l’API et du coût de votre infrastructure, mais il existe.
É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 souveraineté des données. Certaines organisations (défense, santé, administration) interdisent que les données de facturation transitent par un service externe. Les données sont traitées en transit et supprimées après traitement — consultez la documentation du fournisseur pour les détails de rétention. Si cette politique ne suffit pas, le Build est une contrainte, pas un choix.
Quand Buy est le bon choix
Vous êtes un éditeur ERP qui doit ajouter la conformité avant l’échéance. La réforme impose un calendrier. Le time-to-market d’un Build (3 à 6 mois) peut ne pas tenir dans le planning. Une intégration API en 2 à 5 jours libère l’équipe pour se concentrer sur le coeur de métier.
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.
Le volume est modéré (< 10 000 factures/mois). À ce volume, le coût annuel d’une API SaaS est largement inférieur au coût de maintenance annuel d’un pipeline interne (~35 K EUR pour le périmètre 2, ~15 K EUR pour le périmètre 1), même en excluant le développement initial.
Tableau comparatif
| Critère | Build (interne, périmètre 2) | Buy (API SaaS) |
|---|---|---|
| Coût initial | 63-87 K EUR | ~1.4-3.5 K EUR |
| Coût annuel | ~35 K EUR | < 100 EUR/mois (plan PME) |
| Total 3 ans | ~168-192 K EUR | < 10 K EUR |
| Time to market | 3-6 mois | 2-5 jours |
| Maintenance artefacts | Votre équipe | Le fournisseur |
| Souveraineté données | Totale | Dépend du fournisseur (UE / non-UE, politique de rétention) |
| Couverture cas spéciaux (BTP, autoliquidation, B2G) | À développer au cas par cas | Inclus dans l’API |
| Expertise requise | Saxon, veraPDF, Schematron, CII, PDF/A-3 | REST / HTTP |
| Risque technique | Élevé (faux négatifs, edge cases) | Transféré au fournisseur |
| Évolutivité | Dépend de votre architecture | Transparente (côté fournisseur) |
Ces estimations reflètent le périmètre 2 (validation + conversion + réparation). Le périmètre 1 (validation seule, ~25 K EUR initial, ~15 K EUR/an) coûtera significativement moins côté Build, mais ne couvre pas l’ensemble des besoins de production.
Critères de décision : la grille
Au-delà des chiffres, voici les questions qui permettent de trancher.
1. Quel est votre volume mensuel ? Moins de 10 000 factures/mois : le Buy est presque toujours plus économique. Au-delà de 100 000, le Build peut devenir compétitif.
2. La conformité Factur-X est-elle votre coeur de métier ? Si oui (vous êtes PDP, é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 ? L’échéance de septembre 2026 pour la réception laisse un budget temps limité. Un Build de 3-6 mois consomme la majorité de ce budget.
5. Quelle est votre politique de souveraineté données ? Si vos factures ne doivent jamais quitter votre infrastructure, le Build est une contrainte. Sinon, une API dont les données sont traitées en transit et supprimées après traitement (consultez la documentation pour les détails de rétention) et hébergée en UE peut satisfaire les exigences RGPD.
Et maintenant ?
Obtenir une clé API gratuite →
10 opérations gratuites par mois, sans carte bancaire. 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 conforme — 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 — du plan gratuit pour les tests au plan Integration pour la production