Étude de cas — mise en place de la facture électronique dans un ERP/CRM open source auto-hébergé, connecté à une plateforme agréée.
Le contexte
Depuis le 1er septembre 2026, toutes les entreprises françaises doivent pouvoir recevoir des factures électroniques. L’émission devient obligatoire en même temps pour les grandes entreprises et les ETI, puis au 1er septembre 2027 pour les PME et micro-entreprises. Les factures ne circulent plus par e-mail : elles transitent par une plateforme agréée par l’État, que chaque entreprise doit choisir.
JAMTOLY, mon entreprise, est une SASU de transport de personnes (VTC) en Île-de-France. Sa gestion — facturation, banque, comptabilité — tourne sur un ERP/CRM open source, que j’héberge moi-même en conteneurs Docker sur un serveur privé. Plutôt que d’attendre 2027, j’ai choisi de basculer dès la rentrée 2026 : en émission comme en réception.
Particularité du métier : une partie du chiffre d’affaires passe par des plateformes de réservation, une autre par des clients professionnels directs. Ces deux flux ne se traitent pas du tout de la même façon.
L’architecture
- Un ERP/CRM open source auto-hébergé (Docker), accès protégé par une authentification en amont
- Un module de facture électronique complémentaire, qui génère des factures au format Factur-X (un PDF lisible par un humain, avec le fichier XML structuré embarqué) et dialogue avec la plateforme agréée par API
- Une plateforme agréée qui transmet les factures émises, reçoit celles des fournisseurs et assure le lien avec l’administration
Le principe retenu : à la validation d’une facture client, la transmission est automatique — à condition que le destinataire soit concerné. Le circuit a été testé de bout en bout avec une vraie facture avant d’être ouvert.
Les règles métier
1. Les plateformes s’autofacturent : ne rien leur transmettre
Les plateformes VTC fonctionnent en autofacturation : c’est la plateforme qui émet les factures au nom du chauffeur, en vertu d’un mandat. Leur envoyer en plus une facture électronique créerait un doublon.
Dans l’ERP, les factures de plateformes restent nécessaires à la comptabilité (une par plateforme et par mois). Elles sont donc conservées, mais marquées « ignorées » pour la facture électronique, une par une. Ces plateformes étant souvent des sociétés étrangères immatriculées en France, le comportement par défaut du module ne suffisait pas : il a fallu une règle par tiers pour décider explicitement qui reçoit quoi.
2. Les clients directs : automatique, et ça doit le rester
Pour un client professionnel français, la facture part seule à la validation. C’est le cas le plus simple — et précisément celui qu’il ne faut jamais casser. D’où une règle de fonctionnement : les réglages globaux du module ne se modifient pas. Les seuls leviers autorisés sont le statut d’une facture donnée et la règle propre à un tiers.
3. Les factures reçues : relues à la main, par choix
Le module sait importer automatiquement les factures fournisseurs reçues. J’ai fait le choix inverse : chaque facture reçue est relue avant d’entrer en comptabilité. Pour une TPE, le volume le permet, et cela évite d’enregistrer une erreur de fournisseur sans la voir.
Les pièges rencontrés
Une facture transmise ne se modifie plus. Une fois envoyée électroniquement, une facture ne peut pas être repassée en brouillon : c’est voulu, puisqu’elle a une existence officielle. Toute correction passe par un avoir. Conséquence pratique : on vérifie avant de valider, pas après.
Les traitements par lot sont dangereux. Lors d’une régénération en masse de documents, des factures de plateformes ont été transmises alors qu’elles n’auraient pas dû l’être : la règle « par tiers » était active sur ces plateformes au moment du traitement. Depuis, tout script qui valide ou régénère des factures commence par une simulation : quelles factures partiraient, et vers qui ? Rien n’est lancé tant que la liste n’est pas vérifiée.
Éviter les doublons fournisseurs. Un même achat peut arriver deux fois : en facture électronique et en ticket ou PDF scanné. La déduplication repose sur deux éléments : la fiche fournisseur doit porter son SIREN et son numéro de TVA pour être reconnue, et la facture doit être enregistrée sous le vrai numéro du fournisseur (et non une référence interne). Une liste des fournisseurs qui facturent électroniquement est tenue à jour pour ne pas saisir leurs justificatifs papier en double.
L’import automatique a ses limites. Pour importer une facture reçue, le module doit rapprocher chaque ligne d’un produit connu. Sans correspondance, il faut soit créer des produits automatiquement, soit importer en lignes libres — deux réglages globaux. Plutôt que de les modifier, les factures reçues sont saisies avec leur numéro réel, en joignant la version lisible et le XML d’origine récupérés depuis la plateforme.
Un centime d’écart. Il arrive que le montant d’une facture électronique diffère d’un centime du PDF ou du prélèvement bancaire, à cause des arrondis. La règle a été fixée une fois pour toutes : on retient le montant du PDF et de la banque, pour que le rapprochement bancaire reste juste.
Le résultat
- Émission automatique pour les clients directs, aucune transmission vers les plateformes
- Réception en place, avec une relecture humaine de chaque facture
- Une comptabilité qui reste rapprochée au centime avec la banque
- Des règles écrites, pour que la mise en place survive aux évolutions du logiciel et aux traitements ponctuels
Ce que je retiens
- Cartographier les flux avant de brancher quoi que ce soit : qui facture qui, qui s’autofacture, qui est étranger.
- Figer les réglages globaux et agir au niveau d’une facture ou d’un tiers.
- Simuler avant tout traitement en masse.
- Le numéro du fournisseur et son SIREN sont la clé anti-doublon.
- Une facture transmise est définitive : valider, c’est publier.
Compétences mobilisées : ERP/CRM open source (paramétrage, modules, scripts PHP), Docker et auto-hébergement, comptabilité TPE, réglementation de la facture électronique, Factur-X.