← Retour aux articles
1 September 2026 6 min de lecture gofactFacturation électroniqueFactur-XGoMCPOpen SourceAGPL

Mon skill m'a généré une facture électronique, puis l'a envoyé et elle est arrivée du premier coup ! Ensuite, il a fallu en faire un produit...

Comment un skill Claude Code est devenu gofact : un binaire Go autonome qui produit des factures Factur-X conformes EN 16931 et les envoie à une PDP, piloté en langage naturel via MCP. L'IA comme interface, le code comme garant.

La réforme de la facturation électronique française arrive, et comme beaucoup d’indépendants, j’avais tout pour la détester : des factures HTML soignées que j’imprimais en PDF d’un Ctrl+P, un régime simple, et aucune envie de payer un SaaS pour transformer trois factures par mois en Factur-X.

Factur-X, pour situer : un PDF/A-3 qui embarque un XML structuré (CII, sémantique EN 16931). Le PDF pour les humains, le XML pour les machines et l’administration. Et l’envoi ne se fait plus par mail mais via une plateforme de dématérialisation (PDP), qui route la facture jusqu’à ton client.

Cet article raconte comment un script perso est devenu gofact, un outil open source où créer une facture conforme se résume à dire à son IA : « fais-moi une facture pour ACME, 2 jours à 600 € ».

Acte 1 — un skill, et une facture qui passe du premier coup

La première version n’était pas un produit. C’était un skill Claude Code : un fichier d’instructions qui apprenait à l’IA à lire mes données de facture, générer le XML, assembler le PDF/A-3 et soumettre le tout à ma PDP (SuperPDP).

Je lance, je regarde le cycle de vie : fr:200 soumise, fr:201 émise, fr:202 reçue. Acceptée du premier coup. Pas de rejet, pas d’aller-retour avec un validateur obscur.

Ce premier succès a posé l’idée fondatrice de tout ce qui a suivi : l’IA est une excellente interface, mais un mauvais garant. Elle comprend « 2 jours à 600 € », elle retrouve le client, elle remplit le modèle. Mais tout ce qui engage légalement — les montants, la conformité, la numérotation — doit être calculé et vérifié par du code déterministe. L’IA propose, l’outil garantit.

Le problème : un skill, c’est personnel

Un skill qui marche chez moi, c’est bien. Mais il était collé à ma machine : mes chemins, mon .env, et surtout mes dépendances. La conversion PDF/A-3 passait par Ghostscript, la validation EN 16931 par Mustang — donc par une JVM. Impossible de dire à un autre freelance « installe Java, Ghostscript, configure trois variables, et ça devrait aller ».

Pour distribuer l’outil, il fallait le rendre autonome. Et j’ai posé une règle : remplacer une dépendance, c’est la supprimer. Pas de mode de repli, pas de « on garde Ghostscript au cas où » — un repli aurait vidé le portage de son sens.

Acte 2 — tout ramener dans un binaire Go

Le portage, dans l’ordre :

  • La validation EN 16931 en Go. Les règles métier (BR-50, BR-CO-15…) sont appliquées sur le modèle avant de produire quoi que ce soit. gofact refuse d’émettre une facture qu’il sait non conforme, et te dit quelle règle casse et quel champ corriger. Exit la JVM.
  • L’assemblage PDF/A-3 en pur Go (pdfcpu). Profil ICC sRGB embarqué dans le binaire. Exit Ghostscript.
  • veraPDF gardé comme oracle — mais uniquement en intégration continue, pour vérifier la conformité PDF/A-3b profonde. Jamais sur la machine de l’utilisateur.

Il reste une seule dépendance système : un navigateur. Le rendu HTML → PDF passe par Chrome, Edge ou Chromium en headless — déjà présent sur à peu près toutes les machines, auto-détecté sur Linux, macOS et Windows. Le PDF est identique à ton Ctrl+P, fonds et styles compris : ta facture reste ta facture.

Un détail technique qui n’en est pas un : le XML est embarqué verbatim, octet pour octet. Un assembleur qui re-sérialise le XML à travers son propre modèle perd des champs étendus — notamment les adresses de routage électronique (BT-34/BT-49), celles-là mêmes sur lesquelles la PDP route la facture. gofact ne retouche jamais le XML qu’il a produit, et se relit après écriture pour le vérifier.

Acte 3 — le skill devient un serveur MCP

Restait à généraliser l’interface. Le skill était propre à Claude Code ; le Model Context Protocol permet d’exposer les mêmes capacités à n’importe quel client : Claude Desktop, LM Studio, Cursor…

gofact mcp lance un serveur MCP local, en stdio. Pas de cloud, pas de compte : tes factures, ton registre et ton identité restent dans des répertoires chez toi. Chaque entité émettrice est une « organisation » autonome : son .env, son registre de numérotation, son journal d’audit, son modèle de facture, ses factures.

C’est ici que la frontière IA/outil devient une architecture :

  • La numérotation est l’invariant sacré. Séquence continue, sans trou, jamais réutilisée, attribuée sous verrou de façon transactionnelle, compteur qui ne peut que monter. L’IA ne voit un numéro qu’une fois attribué — elle ne peut pas en inventer un.
  • Le visuel est libre. Le modèle HTML est figé à la première émission pour la cohérence, mais tu peux itérer en aperçu et le remplacer délibérément. L’obligation légale porte sur les numéros, pas sur ta mise en page.
  • Les clients se retrouvent tout seuls. Recherche dans l’historique local (insensible à la casse, aux accents, aux séparateurs), et découverte des nouveaux clients via la base SIRENE et l’annuaire Peppol — le SIRET et l’adresse de routage arrivent pré-remplis.
  • L’envoi est le seul outil destructif, et il exige une confirmation explicite. Derrière, l’interface PDP est générique : SuperPDP est le premier fournisseur implémenté, d’autres suivront.

Acte 4 — la distribution

Un binaire autonome ne sert à rien s’il est pénible à installer. Donc : binaires précompilés via GoReleaser, install.sh en une ligne, et un gofact install qui détecte tes clients MCP (Claude Desktop, Claude Code, LM Studio, Cursor), montre ce qu’il compte écrire — dry-run par défaut — et sauvegarde chaque fichier avant de le modifier. Le repo est aussi un plugin Claude Code, skill compris.

Ce que j’en retiens

  1. L’IA comme interface, le code comme garant. C’est le pattern qui rend l’IA utilisable sur un sujet à obligation légale : la conversation en entrée, des invariants déterministes en sortie.
  2. Supprimer une dépendance est une décision produit. Chaque « installe aussi X » perdu en route est un utilisateur perdu. Le portage complet — sans filet — est ce qui a rendu la distribution possible.
  3. Valider avant de produire. Refuser d’émettre une facture non conforme, avec la règle et le champ en cause, vaut mieux que n’importe quel validateur après coup.

gofact est gratuit et open source (AGPL v3). Je l’ai fait pour moi ; autant qu’il serve à d’autres.

👉 github.com/kolapsis/gofact — installation en une ligne, doc incluse. Si tu testes et que ça coince, ouvre une issue : c’est un outil de terrain, il s’améliore à l’usage.

Besoin d'aide sur ce sujet ?

Réserver un créneau