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é à 2 (+1/-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é à 2 (+0/-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
# Tout n'est pas perdu ?
Posté par steph1978 . Évalué à 3 (+1/-0). 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é à 1 (+0/-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.
# ma femme
Posté par ChocolatineFlying . Évalué à 1 (+0/-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é à 1 (+0/-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.
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.