Pourquoi je développe un facturier électronique libre pour les artisans
Depuis quelques mois, je m'intéresse de près à la réforme de la facture électronique qui va progressivement concerner toutes les entreprises françaises.
Comme beaucoup, je pensais au départ qu'il suffirait de générer une facture PDF et de l'envoyer à une plateforme. En réalité, le sujet est beaucoup plus complexe : formats normalisés, Factur-X, EN16931, plateformes de dématérialisation partenaires (PDP), Peppol, annuaires, e-reporting… On découvre rapidement tout un écosystème.
L'idée de ce projet ne vient pourtant pas d'une veille technologique.
Elle vient d'une discussion avec un charpentier.
Il réalise aujourd'hui toutes ses factures avec… Microsoft Word.
Cela peut sembler surprenant à des développeurs, mais c'est finalement assez courant chez les artisans. Son besoin est simple : quelques devis, quelques factures par semaine, pas de comptabilité intégrée, pas de CRM, pas de gestion de stock. Jusqu'à présent, Word lui suffisait largement.
Sa question était très simple :
« Est-ce que je vais devoir acheter un logiciel compliqué juste pour continuer à faire mes factures ? »
Je me suis alors demandé si l'on ne pouvait pas conserver cette simplicité tout en respectant les nouvelles obligations.
J'ai donc commencé à développer un prototype très minimaliste.
L'idée est volontairement à l'opposé d'un ERP complet.
On remplit un simple formulaire web, comme on remplirait un facturier papier. L'application calcule les montants, génère une facture au format Factur-X, puis permet de la transmettre à une plateforme de dématérialisation via son API.
Le point qui m'a surpris pendant le développement est que les deux problèmes sont finalement assez indépendants :
- générer une facture conforme ;
- la transmettre à une PDP.
En séparant ces deux briques, il devient possible d'utiliser n'importe quelle PDP compatible, sans que celle-ci impose l'interface de création des factures.
Pour mes premiers essais, j'ai utilisé l'API de SuperPDP, qui propose un environnement de test bien documenté et gratuit pour les petits volumes. Cela m'a permis de développer un connecteur relativement simplement.
Aujourd'hui, le prototype permet déjà :
- de créer une facture via une interface HTML très simple ;
- de générer un document Factur-X conforme ;
- de transmettre cette facture à une PDP via son API.
Le projet est entièrement open source et j'essaie de le construire de manière la plus transparente possible.
Mon objectif n'est pas de concurrencer Dolibarr, Odoo ou les nombreuses solutions existantes. Ces logiciels répondent à des besoins beaucoup plus larges.
Je cherche plutôt à répondre à un cas d'usage très précis : les artisans et petites structures qui ont des besoins très simples mais qui devront malgré tout se conformer à la réforme.
Je pense d'ailleurs publier régulièrement des journaux sur LinuxFr pour partager les choix techniques, les difficultés rencontrées (Factur-X, XML CII, EN16931, APIs des PDP…) et recueillir vos retours.
Le dépôt GitHub est disponible ici :
https://github.com/sepp67/facturier-app
Une démonstration est également accessible ici :
https://facturier.lavallee.tech/app/
Je serais très intéressé par vos retours, aussi bien sur l'approche technique que sur le positionnement du projet. Si certains d'entre vous connaissent des artisans, indépendants ou petites associations susceptibles de tester l'application et de me faire un retour d'expérience, je serais ravi d'échanger avec eux.
À bientôt pour un prochain journal où je raconterai probablement mes aventures avec Factur-X et la norme EN16931… je pense que beaucoup ici apprécieront le sujet !
# Pas mal !
Posté par tontonrico . Évalué à 5 (+4/-0).
Bonjour,
Je viens de cliquer sur la demo, je n'y connais rien et ne connais pas non plus les nouvelles (ni les anciennes) règles d'émission de factures mais franchement ça a l'air très bien, c'est clair et simple.
Je connais quelqu'un qui va être intéressé, ça va m'obliger à remonter un serveur….
J'essaierai de te tenir informé.
[^] # Re: Pas mal !
Posté par Luc-Skywalker . Évalué à 6 (+4/-0).
Tout pareil :)
Quelques remarques toutefois:
=> ceci afin d'éviter les erreurs de saisie.
Je vois qu'il n'y a pas de bdd, ce qui se comprend dans l'optique d'avoir un outil simple qui fait ce qu'on lui demande. Mais amha, c'est dommage de saisir des formulaires et de n'en garder aucune trace. Ça aurait son utilité pour le suivi comptable, suivre l'évolution des couts des fournitures etc.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Pas mal !
Posté par Voltairine . Évalué à 5 (+3/-0).
[^] # Re: Pas mal !
Posté par Luc-Skywalker . Évalué à 5 (+3/-0).
Alors, oui, sur le principe général (nota, je suis loin d'être un expert en la matière).
Mais quand tu pars de factures faites à la mano avec Word pour aller vers quelque chose d'un peu plus formel/automatisé, c'est déjà un premier pas (c'est mon coté naturellement optimiste qui me fait dire ça).
Parce que c'est pas dit du tout qu'au paravent, la facture était strictement conforme non plus
Je crois comprendre que c'est une réponse spécifique à une demande spécifique, donc il ne faut pas avoir trop d'exigences amha.
Cela dit, comme c'est du FOSS (contrairement à d'autres trucs qu'on a pu voir passer ces jours ci), libre à chacun d'apporter sa pierre.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Pas mal !
Posté par Voltairine . Évalué à 5 (+3/-0). Dernière modification le 09 juillet 2026 à 15:22.
Je me doute que certains artisans utilisent Word ou autre outil basique pour faire leurs devis/factures.
Mais outre l'insécurité juridique1, c'est au final une grosse perte de temps par rapport à l'usage d'un logiciel dédié (dolibarr par exemple). Et cela ne doit pas faciliter la tâche du comptable s'il y en a un.
Sur l'outil proposé, autant qu'il soit conforme aux exigences actuelles, sinon il n'y a aucun avantage à l'utiliser. Quand on veut rendre service en créant cela, il est bon de passer une heure à se renseigner sur les mentions obligatoires et utiles sur une facture.
(Tiens j'ai oublié que aussi que l'adresse du chantier, si différente de celle du client, doit figurer sur la facture.)
bien des artisans s'en foutent royalement, mais pour le client c'est une sécurité de base d'avoir un devis comportant toutes les mentions légales, notamment les assurances. ↩
[^] # Re: Pas mal !
Posté par devnewton 🍺 (site web personnel) . Évalué à 0 (+1/-4).
Pour être sûr d'avoir une faille owasp bien connue ?
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Pas mal !
Posté par Voltairine . Évalué à 3 (+1/-0).
Qu'est-ce qu'une faille OWASP ? Merci de m'en donner une définition précise et me permettre de comprendre le rapport avec l'obligation d'avoir des numéros de factures uniques et qui se suivent dans le temps.
[^] # Re: Pas mal !
Posté par fork_bomb . Évalué à 4 (+3/-0). Dernière modification le 09 juillet 2026 à 19:35.
C'est soit du troll soit une tentative d'humour ratée.
Il fait référence à un type de faille qui s'appelle l'énumération.
Si un contenu est référencé par un numéro séquentiel, par exemple banquefr.com/compte/1, banquefr.com/compte/2, etc. et qu'il n'y a pas de contrôle d'accès, un attaquant peut accéder à tous les contenus, y compris ceux auxquels il n'a pas le droit, en changeant le numéro. C'est également possible de connaître le nombre de contenus en créant un nouveau contenu et en regardant son numéro.
Aucun rapport avec les factures donc, à part qu'il y a des numéros séquentiels.
[^] # Re: Pas mal !
Posté par fearan . Évalué à 7 (+4/-0). Dernière modification le 10 juillet 2026 à 09:02.
Supposons que tu veuille laisser tes factures disponible à tes client. Notamment parce que ces derniers sont incapables de retrouver un papier datant d'il y'a 6 mois, ou que tu veuille simplement envoyer un lien vers la facture.
Tu vas laisser le client un accès en consultation, avec potentiellement le n° dans l'url; comme il n'a pas de compte, pas d'authentification. Et paf il a accès a toute tes facture; voir que son concurrent s'est payé une terrasse…
Faut pas oublier que bon nombre de personne mettant en place des solution informatisé n'ont pas forcément un bagage sécurité (surtout que c'est chiant à mettre en œuvre, ça bouge souvent, ça fait chier l'utilisateur, ça fait chier le mainteneur, ça fait chier le développeur)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Pas mal !
Posté par gUI (Mastodon) . Évalué à 5 (+2/-0).
À ça on ajoute les concurrents qui peuvent facilement surveiller ton activité.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Pas mal !
Posté par Faya . Évalué à 3 (+1/-0).
Il faut un numéro incrémental donc oui si tu as une facture, tu peux en déduire l'activité. Par contre pour l'attaque du dessus ce n'est pas si évident parce que tu peux ajouter d'autres choses au numéro incrémental. Par exemple tu as le droit de faire une facture
FA-20260711-666. Avec donc la date format ISO8601 qui précède le n° incrémental (ici666). Donc pour pouvoir télécharger une facture il te faudra connaître son numéro ET sa date. Bon ce n'est pas hors de portée de quelqu'un qui veut vraiment trouver tes factures, on est pas sur unUUID, mais bon ce n'est pas non plus du téléchargement automatique il va falloir coder et bruteforcer (dans un intervalle connu) pour trouver les bonnes combinaisons.[^] # Re: Pas mal !
Posté par Sébastien B. . Évalué à 2 (+0/-0).
C'est ça, mais l'attaquant principal c'est l'inspecteur des impôts pendant un contrôle.
[^] # Re: Pas mal !
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
Je suis d’accord sur le principe pour éviter les collisions, mais le choix de la séquence chronologique continue ne doit pas forcément être la première idée basique venue.
Genre quand tu débutes ton entreprise, t’as pas forcément envie que le devis indique à ton client que c’est ton premier devis de l’année… Façon 20260001. 🤭️
Ou genre t’as pas encore beaucoup de client, mais magiquement tu révèles à tous tes clients à chaque mensualité/annuité combien tu édites de facture entre chaque date… Et donc combien tu as de clients si la prestation est assez standardisée. 🫣️
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pas mal !
Posté par fork_bomb . Évalué à 2 (+2/-1).
Ce n'est pas "pour éviter les collisions", c'est une obligation légale pour que l'administration fiscale puisse s'assurer qu'elle est en possession de toutes les factures et qu'il n'y ait pas de factures antidatées créées a posteriori.
[^] # Re: Pas mal !
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 3 (+1/-1).
Il n’y a pas de contradiction dans nos deux messages, et ajouter d’autres contraintes (pouvoir compter tes factures) n’enlève pas la contrainte d’évitement de collisions…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pas mal !
Posté par fork_bomb . Évalué à 1 (+0/-0).
Je ne comprends pas comment il peut ne pas y avoir contradiction ? Tu parles du "choix" de la séquence chronologique continue puis de ses inconvénients.
Ça me parait incompatible avec le fait que la séquence chronologique continue est obligatoire 1.
Certes il y a des possibilités d'utiliser des préfixes et de remettre à zéro la séquence, mais ce n'est utilisable que pour certaines raisons décrites dans le BOFIP idoine, et certainement pas pour dissimuler la séquence des factures. ↩
[^] # Re: Pas mal !
Posté par devnewton 🍺 (site web personnel) . Évalué à 2 (+0/-1). Dernière modification le 11 juillet 2026 à 07:50.
Avec la chronologie de la Brigade Temporelle, ça marche ?
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Pas mal !
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
La numérotation peut être en continu avec ce que je vais appeler un "identifiant" avant genre aa-N°. Le numéro est en continu et donc si tu as terminé l'année avec la facture N°52 (25-52), la première de l'année pourra être 26-53 ou la graphie que tu veux.
Je trouve ça très pratique.
Je n’ai aucun avis sur systemd
[^] # Re: Pas mal !
Posté par Voltairine . Évalué à 2 (+0/-0). Dernière modification le 10 juillet 2026 à 06:15.
Sauf exceptions les clients ne s'amusent pas à décortiquer tes numéros de factures. Des pistes ont été données dans les autres commentaires pour le premier point (pas d'obligation de commencer à 1), le second est presque inévitable (sauf à avoir un préfixe par client).
De toute façon mieux vaux cela que de s'exposer à des risques juridiques et fiscaux.
[^] # Re: Pas mal !
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 3 (+1/-1).
Ce n’est pas parce que j’indique un point faible d’un système que je ne connais pas de possibles mesures d'atténuation (qui ont leurs limites).
Mon commentaire était pourtant explicite sur le fait qu’il n’y a pas forcément une seule façon de faire :
Je ne sais pas ce que vous essayez de prouver ici.
Je ne cherche pas une solution, je décris un problème et dis qu’il existe des solutions, et je n’ai pas besoin de lister moi-même ces solutions pour décrire le problème.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pas mal !
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 3 (+1/-1).
Pour faire une analogie :
Si je dis à quelqu’un « n’oublie pas ton parapluie » alors qu’il s’apprête à sortir sous la pluie, m’apporter à moi un parapluie et/ou me dire « mais on t’a déjà apporté deux parapluies » est une réponse inappropriée.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pas mal !
Posté par Voltairine . Évalué à 3 (+1/-0).
Ce n'est pas une idée, c'est une obligation légale.
[^] # Re: Pas mal !
Posté par Graveen . Évalué à 5 (+3/-0).
C'est vrai, mais dans ce cas autant prendre un dolibarr qui peut fonctionner avec le module facturation et ses dépendances.
--
Je n'ai jamais trop cru en ces outils "simples" pour la facturation.
Parce que, bah c'est pratique d'avoir les tiers clients et les tiers fournisseurs, c'est pratique d'avoir l'historique de tes factures, de calculer la tva, etc etc… et à la fin on se demande comment on faisait sans un Dolibarr. On faisait, mais avec des tas de temps administratifs à côté :D
Un ERP simplifié, c'est quelques heures pour y rentrer dedans, et des jours de gain à la fin de l'année :)
Merci à OP pour ce dev en tous cas :)
# Tout n'est pas perdu ?
Posté par steph1978 . Évalué à 10 (+11/-1). Dernière modification le 09 juillet 2026 à 11:50.
Mon détecteur d'AI slop est à 0. Du code qui semble pensé et écrit par un humain. Je n'ose y croire.
Merci !
Je n'ai pas d'usage immédiat mais je pousserai à des connaissances.
[^] # Re: Tout n'est pas perdu ?
Posté par fork_bomb . Évalué à 6 (+5/-0).
Il est peut-être en panne. Le code et le designe de la démo ne me paraissent pas vibe codés mais :
Le site est très clairement vibe-codé ("pill" avant les h1, les textes de réassurance qui font très LLM, la taille et le "professionnalisme" de la page sans commune mesure avec le code)
Nouveau compte
"L'idée de ce projet ne vient pourtant pas d'une veille technologique. Elle vient d'une discussion avec un charpentier." dans le journal est plus que suspect, non seulement la tournure de phrase et le type d'exemple sont typiques d'un LLM, mais elle est aussi très générique pour une expérience personnelle.
[^] # Re: Tout n'est pas perdu ?
Posté par steph1978 . Évalué à 3 (+1/-0).
Ou nécessite un petit réglage pour augmenter la sensibilité.
Oui, c'est ça que j'ai regardé.
Je suis d'accord. Les liens en bas aussi qui ne sont pas câblés. La présentation globale ; ça se voit.
Ça m'a mis la puce à l'oreille, c'est pour ça que j'ai regardé le code
oui, il n'est pas exclu qu'un LLM ai été utilisé
Il n'y a que trois commit. Autant quand on a un claude, on va se retrouver avec 1500 commits par jour. Pas ici. Mais à l'inverse, 3 commit, ça fait un peu codé à côté et mis en ligne à posteriori.
Mais honnêtement, le code a l'air clean : pas de tartine de commentaires paraphrasant le code. Même pas de framework côté frontend, juste du JS.
Y a peut-être du LLM mais je dirai qu'il n'est pas en mode yolo.
Mais @sebastien67 va nous dire tout ça ;)
# ma femme
Posté par ChocolatineFlying . Évalué à 4 (+3/-0). Dernière modification le 09 juillet 2026 à 12:04.
comme dirait colombo, ma femme est 100% à son compte, et n’émet que des factures à destination de particulier avec un facturier papier sans TVA. environ 20 par mois.
elle sera concerné uniquement par le e-reporting (quel nom atroce !)
je regarde qqchose de simple mais je n'ai pas encore trouvé. J'ai noté qu'elle travail qd même normalement avec ton Iphone, je pense que sa transition serait plus facile soit avec un site web utilisable sur iphone soit une app.
Pour elle ce serait aucun champ obligatoire avec rien en bdd ou pris dans les contacts, juste la somme qui serait gérer. comme une prise de note avec uniquement le champ de la somme à gérer de votre coté. Au pire un champ : nom prenom objet , si cela reste légal
comme cela elle écrira a chaque fois ce qu'elle veut + la somme à déclarer.
et chaque déclaration a un numéro unique automatique et peut être envoyer en pdf sur son mail pour être imprimé. Et j'imagine un fichier xml a donné/envoyer/telechargé sur une PA, de ce coté je ne sais pas comment sa fonctionne
voila elle est concerné en 2027, elle n'a pas hate d s'y mettre, je vais suivre ton projet assidument et lui soumettre l'utilisation
# Un conseil
Posté par fork_bomb . Évalué à 8 (+7/-0).
Ton approche pour la génération du PDF (faire du dessin sur un canvas) n'est pas bonne (exemple de fonction) : plus les documents vont être complexes, plus ça va être difficile de générer quelque chose de correctement formaté.
D'ailleurs si on génère la facture sur la démo avec les paramètres par défaut, il y a déjà des soucis de textes qui se dépassent ou se recouvrent.
Une approche beaucoup plus efficace est de générer une facture dans un format intermédiaire (typiquement HTML ou LaTeX) puis de convertir ce format en PDF.
[^] # Re: Un conseil
Posté par oau . Évalué à 4 (+2/-0).
Le plussois à mille pourcent. Puis latex c'est la classe.
[^] # Re: Un conseil
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 09 juillet 2026 à 14:04.
XML plus proche du HTML je dirais.
Je n’ai aucun avis sur systemd
[^] # Re: Un conseil
Posté par steph1978 . Évalué à 5 (+3/-0). Dernière modification le 09 juillet 2026 à 16:18.
weasyprint peut être ?
Ça fait du HTML+CSS -> PDF.
[^] # Re: Un conseil
Posté par Voltairine . Évalué à 3 (+1/-0). Dernière modification le 09 juillet 2026 à 17:24.
Attention la facture électronique est un PDF qui embarque du XML. Les générateurs de PDF « classiques » ne sont pas toujours adaptés pour générer ce format hybride (il semble que weasyprint sache faire).
[^] # Re: Un conseil
Posté par steph1978 . Évalué à 4 (+2/-0).
ça tombe bien alors :)
Blague à part, je suppose qu'il est possible "d'injecter" le XML à posteriori de la génération.
[^] # Re: Un conseil
Posté par JeanScotch . Évalué à 1 (+1/-0).
oui. c'est d'ailleurs de que fait l'auteur avec l'usage de la librairie factur-x qui sert précisément à cela ;) (j'ai lu le code source de l'app dont on parle). Et je plussoie que la méthode de génération du premier PDF sur base de dessiner un canvas me chipote.
je crois que je vais reprendre le workflow de base pour mon besoin propre (je suis auto-entrepreneur en IT) car je cherchais un truc simple tel que cette lib factur-x (qui visiblement expose également un CLI pour faire le taf).
Merci à l'auteur de m'avoir fait découvrir factur-x!
[^] # Re: Un conseil
Posté par oliverpool (site web personnel) . Évalué à 1 (+1/-1).
Weasyprint c'est bien sûr le papier, mais au niveau sécurité c'est compliqué : https://doc.courtbouillon.org/weasyprint/stable/first_steps.html#security (oui, j'ai découvert ce paragraphe après avoir identifié une faille chez un client…)
[^] # Re: Un conseil
Posté par steph1978 . Évalué à 5 (+3/-0). Dernière modification le 10 juillet 2026 à 11:35.
On est pas dans ce cas.
Le HTML+CSS serait utilisé comme modèle de présentation côté back-end pour y mettre des données métier : nom et adresse client, lignes de facture, TVA, total.
Il n'est donc pas "untrusted".
Et puis l'avertissement est valable pour toute application : on ne process pas une donnée provenant de l'utilisateur sans la nettoyer. Weasyprint a simplement la gentillesse de le rappeler.
[^] # Re: Un conseil
Posté par oliverpool (site web personnel) . Évalué à 3 (+2/-0).
Pour être plus moderne, je conseillerai Typst (il y a même un binding python dispo: https://pypi.org/project/typst/).
Ça supporte les "attachment" pdf, donc le xml devrait pouvoir y être ajouté sans soucis.
Exemple: https://typst.app/universe/package/invoice-pro
# Ça semble être un bon cas pour une application Electron
Posté par cg . Évalué à 2 (+0/-0).
Je n'aime pas trop Electron, mais en l'occurrence, faire une appli qui puisse tourner sur Linux/Windows/MacOS, et non pas sur un site Internet, permettrait peut-être à un plus grand nombre d'utiliser ce logiciel pour produire ses factures et les envoyer à l'intermédiaire, sans risquer pour autant d'envoyer ses infos de facturation (qui contiennent très souvent des données personnelles) sur un site qui se fera trouer à un moment où un autre.
Après y'a peut-être des alternatives à Electron qui seraient mieux placées.
En tout cas j'aime vachement l'idée de cet outil. Perso, je suis "informaticien", et je dois dire que quand j'étais freelance, ben je faisais mes factures sur LibreOffice Writer, j'ai toujours trouvé ça plus simple et efficace qu'un logiciel dédié, quand tu fais seulement une à deux factures par mois.
[^] # Re: Ça semble être un bon cas pour une application Electron
Posté par sebas . Évalué à 3 (+1/-0).
Deltachat a une version principale Electron (le deb fait 115 mb) et une version alternative deltachat-tauri (voir dans les assets) pour ordis (je ne la vois pas pour spyphone, malgré ce que dit le texte cité ci-dessous), qui fait 35 mb, qui est un peu moins peaufinée que la v. Electron mais qui marche bien également. Comme la v. Tauri sort en même temps que la v. Electron, j'imagine qu'il y a un socle commun.
Voici l'explication du site nlnet.nl sur Delta-tauri :
# Mentions légales ?
Posté par TuxMips . Évalué à 3 (+1/-0).
Très intéressant !!
Merci beaucoup !
Sinon le bas de page de ton site, le lien mention légales ne renvoie visiblement sur rien :-(
C'est me semble t'il un point important à compléter ;-)
# merci pour vos commentaires
Posté par sebastien67 . Évalué à 1 (+5/-4).
Bonjour,
Merci pour vos commentaires. Vous êtes tous ultra éfficaces.
Voici une synthèse de vos remarques :
A. Numérotation automatique des factures
B. Gestion des clients
C. Catalogue de prestations
D. Historique
E. Version smartphone
Les remarques juridiques
Les remarques d'architecture. → ajouter les mentions légales
Canvas → PDF pas top
Version Desktop
IA ou pas IA ?
Oui ma landing page est faite avec l”IA. Dans la vie, je fais du support technique. Je sais lire des logs interminables d’un serveur RADIUS et vous dire pourquoi la connexion VPN plante. Je n'aime pas coder du HTML. Beaucoup de personnes à qui j’ai montré mon projet m'ont fait la remarque qu’il manquait une landing page qui expliquait le projet. Alors oui, j’ai pris l’IA pour faire la landing page. Parce que sinon ça allé prendre trop de temps.
L’application est codée par moi-même quand j’ai le temps. C’est pour ça qu’il n’y a que 3 commits.
Voici un petit topo technique
Architecture du facturier : du formulaire HTML au document Factur-X
Le principe de l'application est volontairement simple pour l'utilisateur : remplir un formulaire, cliquer sur « Générer » et obtenir une facture électronique conforme.
En interne, le traitement est découpé en plusieurs étapes indépendantes afin de séparer explicitement les responsabilités.
L'architecture générale est la suivante :
Interface HTML/JavaScript
│
▼
JSON métier
│
▼
API FastAPI
│
▼
Orchestrateur Python
│
┌──────┴────────┐
▼ ▼
PDF lisible XML CII EN16931
└──────┬────────┘
▼
Fusion Factur-X (PDF/A-3)
▼
Facture électronique finale
L'ensemble du pipeline repose sur un modèle de données unique. Le formulaire HTML ne génère pas directement un PDF ou un XML : il produit un objet JSON représentant la facture. Toutes les étapes suivantes travaillent sur cette même structure de données, ce qui garantit la cohérence entre le document visible par l'utilisateur et les données structurées destinées aux plateformes de dématérialisation (PDP)
Pour faciliter la compréhension de l’application, la partie JavaScript pré-remplit automatiquement certains identifiants techniques propres à la sandbox SuperPDP (endpoint_id, SIREN, etc.) pour deux entreprises fictives. J’ai initialement basé mon projet sur superPDP. C’est un PDP qui propose une API avec une documentation détaillée. Un compte gratuit si on ne dépose pas plus de 1000 factures par mois. L’entreprise Burgeer Queen et Tricatel sont les entreprises de leur Sandbox.
Le navigateur ne produit donc aucun document final.
Il ne fait qu'envoyer un modèle de facture normalisé au serveur.
L'API FastAPI
L'API constitue le point d'entrée de toute l'application.
La route :
POST /api/generate-facturx
reçoit le JSON transmis par le navigateur.
Avant tout traitement :
• le payload est validé par Pydantic ;
• les types sont contrôlés ;
• les champs obligatoires sont vérifiés.
Une fois ces contrôles effectués, l'API ne réalise aucun traitement métier.
Son rôle est simplement de transmettre le modèle de facture à l'orchestrateur principal.
Cette séparation permet de conserver une API très légère.
L'orchestrateur
Le cœur de l'application est la fonction :
generate_all_from_json()
Elle coordonne l'ensemble du pipeline.
Son rôle consiste à exécuter successivement trois traitements indépendants :
JSON
│
├──► génération PDF
│
├──► génération XML CII
│
└──► fusion Factur-X
Chaque étape possède son propre script spécialisé.
L'orchestrateur ne connaît pas le détail de leur implémentation.
Il se contente de leur fournir les données et de récupérer les fichiers produits.
Cette architecture facilite les évolutions futures.
Par exemple, il serait possible de remplacer complètement le moteur PDF sans modifier le générateur XML.
Les adresses sont restructurées afin d'obtenir systématiquement :
• rue ;
• code postal ;
• ville ;
• pays.
Cette étape évite de propager des formats différents dans le reste de l'application.
Recalcul complet des montants
Le serveur ne fait jamais confiance aux calculs effectués dans le navigateur.
Toutes les lignes sont recalculées à partir des données brutes.
Les calculs utilisent systématiquement Decimal afin d'éviter les erreurs liées aux nombres flottants.
Les montants sont arrondis selon les règles comptables (ROUND_HALF_UP).
Le moteur calcule ensuite :
• total HT ;
• TVA par taux ;
• total TTC.
Construction du document
Le PDF est entièrement construit par Python.
Chaque bloc de la facture possède sa propre fonction :
• coordonnées ;
• informations générales ;
• tableau des lignes ;
• TVA ;
• mentions légales ;
• paiement.
Avant chaque généraion de page, le moteur estime la hauteur nécessaire.
S'il ne reste plus suffisamment d'espace sur la page, une nouvelle page est automatiquement créée et l'en-tête est redessiné.
Le tableau des lignes utilise les composants de ReportLab capables de gérer automatiquement le retour à la ligne des descriptions longues.
Le résultat est un PDF classique, destiné uniquement à la lecture humaine.
Le document est organisé autour de plusieurs sections :
• contexte du document ;
• informations générales ;
• lignes de facture ;
• vendeur ;
• acheteur ;
• taxes ;
• totaux ;
• paiement.
Le générateur utilise les espaces de noms XML officiels (rsm, ram, udt) afin de produire un document directement exploitable par les validateurs et les plateformes de dématérialisation.
Enrichissement métier
Avant la génération du XML, certaines informations sont enrichies automatiquement.
Pour la sandbox SuperPDP, le générateur complète notamment :
• SIREN ;
• endpoint électronique ;
• identifiant légal ;
• identifiant global.
Cette logique est actuellement limitée aux entreprises de démonstration mais prépare le futur raccordement à un véritable annuaire PDP.
Normalisation des données
Le générateur convertit également plusieurs informations vers les codes normalisés attendus par EN16931.
Par exemple :
• unités UN/CEFACT ;
• catégories de TVA ;
• quantités ;
• montants.
Le XML obtenu est totalement indépendant de la présentation graphique.
Cette étape est volontairement déléguée à la bibliothèque spécialisée factur-x.
Le projet ne réimplémente donc pas les mécanismes complexes liés au standard PDF/A-3.
La bibliothèque prend en charge :
• la conversion en PDF/A-3 ;
• l'intégration du XML dans le PDF ;
• les métadonnées XMP ;
• la création du document Factur-X final.
Le résultat reste un fichier PDF parfaitement lisible tout en contenant l'ensemble des données structurées destinées aux traitements automatiques.
Une architecture fondée sur la séparation des responsabilités
L'application repose sur un principe simple :
• le navigateur construit les données ;
• l'API valide les données ;
• l'orchestrateur pilote les traitements ;
• un moteur produit le PDF ;
• un moteur produit le XML ;
• une bibliothèque assemble le document Factur-X.
Chaque composant possède une responsabilité unique.
Cette organisation présente plusieurs avantages :
• facilité de maintenance ;
• faible couplage entre les composants ;
• possibilité de remplacer un moteur sans modifier le reste de l'application ;
• meilleure testabilité ;
• préparation aux évolutions futures (nouveaux moteurs PDF, autres formats XML, intégration de plusieurs PDP).
# Odoo
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Mais est-ce qu'Odoo permet de générer la FacturX?
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Odoo
Posté par Cédric Krier (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Tryton le pourra dans sa prochaine version: https://foss.heptapod.net/tryton/tryton/-/merge_requests/3412
# Merci pour le partage
Posté par ZankFrappa . Évalué à 1 (+0/-0).
Merci, c'est intéressant. Je me suis effectivement demandé plusieurs fois quel logiciel libre on pourrait développer pour des artisans ou de petites entreprises et ton journal m'aide à y voir plus clair.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.