Le problème n’est pas d’émettre, c’est de ne rien oublier
Émettre une facture d’abonnement prend deux minutes. Le problème est ailleurs, dans les choses qui ne se voient pas :
Le contrat signé en mars et facturé à partir de juin, parce que personne ne l’a ajouté à la liste. Ce chiffre d’affaires-là est perdu, pas différé.
L’avenant qui fait passer un client de 400 à 550 euros par mois, appliqué avec deux cycles de retard.
L’indexation annuelle prévue au contrat et jamais appliquée, parce que la vérifier sur quarante contrats demande une journée que personne n’a.
La facture émise à un client qui a résilié, avec l’échange désagréable qui suit.
Toutes ces erreurs ont la même cause : l’état contractuel réel vit dans des courriels, des signatures et des têtes, pendant que la facturation vit dans une liste tenue à la main. L’automatisation ne consiste pas à émettre plus vite, mais à faire de l’état contractuel la source de la facturation.
Ce qu’on automatise
Le référentiel des contrats. Client, prestation, montant, périodicité, date d’effet, durée, clause d’indexation, conditions de résiliation, mode de paiement.
L’émission au bon moment, à échoir ou à terme échu selon le contrat, avec la période clairement indiquée sur la facture.
Les calculs de proratas à l’entrée, à la sortie et au changement de formule.
Les indexations, avec le courrier d’information envoyé au bon délai.
L’envoi, au bon interlocuteur — qui n’est presque jamais celui qui a signé — et au bon format.
Le suivi d’encaissement et le rapprochement avec le compte.
Les relances en cas d’impayé, selon votre séquence.
Les signaux contractuels. Échéance de contrat qui approche, préavis de tacite reconduction, fin d’engagement : prévenus à l’avance, pas constatés après.
Comment ça marche techniquement — pour qui veut le détail
Le modèle de données. Trois entités distinctes, et la distinction compte : le contrat (relation durable, avec ses clauses), l’abonnement (une ligne facturable, avec sa période et son tarif, versionnée dans le temps), et la facture (un événement immuable une fois émise). Un changement de formule ne modifie pas la ligne existante : il la clôt à une date et en ouvre une nouvelle. Cette immuabilité est ce qui rend l’historique reconstituable et les proratas calculables sans ambiguïté.
La numérotation. Une séquence PostgreSQL dédiée par exercice ou par série, attribuée dans la transaction d’émission. Point important : une séquence PostgreSQL n’est pas transactionnelle par nature — un ROLLBACK consomme quand même le numéro. Quand l’absence totale de trous est exigée, on utilise une table de compteur verrouillée par SELECT … FOR UPDATE plutôt qu’une séquence, au prix d’une sérialisation qui n’a aucune importance au volume d’une facturation d’entreprise. Le brouillon n’a pas de numéro ; l’émission est l’opération qui en attribue un, une fois.
Les dates et les périodes. Toutes les périodes sont stockées comme des intervalles semi-ouverts [début, fin[ — le type daterange de PostgreSQL, avec une contrainte d’exclusion GIST qui rend impossible en base le chevauchement de deux périodes facturées pour le même abonnement. C’est une protection structurelle contre la double facturation, bien plus solide qu’un contrôle applicatif qu’on oublie de faire un jour.
Les calculs monétaires. Entiers de centimes, arrondi au demi supérieur appliqué une seule fois et au bon niveau. Un prorata sur trois lignes calculé ligne par ligne puis totalisé ne donne pas le même résultat que le calcul sur le total : la règle est fixée une fois, écrite dans la documentation, et la même partout. La TVA se calcule sur la base HT arrondie, dans cet ordre.
L’ordonnancement du cycle. Un timer systemd quotidien, pas mensuel : chaque jour, on cherche les abonnements dont la prochaine date de facturation est atteinte. Un cycle quotidien qui ne trouve rien coûte une milliseconde ; un cycle mensuel qui échoue coûte un mois. Persistent=true rattrape une exécution manquée après une coupure.
L’idempotence du cycle. Chaque exécution porte une clé (abonnement_id, période) avec contrainte d’unicité. Relancer le cycle deux fois le même jour, ou le relancer après une interruption au milieu, ne produit aucune facture en double. C’est ce qui permet de rejouer sereinement après un incident — et un cycle de facturation qu’on n’ose pas relancer est un cycle qu’on répare à la main.
Les indexations. Les indices publics (INSEE, ILC, ICC, SYNTEC selon les contrats) sont récupérés et stockés avec leur date de publication. Le calcul suit la formule du contrat, et le résultat est figé dans la base avant application, avec la valeur d’indice utilisée. Recalculer une indexation trois ans plus tard doit donner le même chiffre, ce qui suppose d’avoir conservé l’indice et pas seulement le résultat.
La facturation électronique. Les formats structurés — Factur-X (PDF/A-3 avec XML CII embarqué), UBL, le CII seul — sont produits à partir des mêmes données. Factur-X a l’avantage de rester lisible par un humain tout en étant exploitable par une machine, ce qui en fait une bonne cible de transition. Le routage vers une plateforme agréée est une couche d’envoi, découplée de la production du document : quand la plateforme ou le format change, seule cette couche bouge.
Le prélèvement SEPA. Fichier pain.008 avec le mandat, sa date de signature, sa référence unique et la séquence (FRST, RCUR, FNAL). Pré-notification au délai contractuel. Les rejets reviennent en pain.002 avec un code motif normalisé, traité automatiquement : un rejet pour provision insuffisante déclenche une relance, un rejet pour mandat révoqué déclenche une alerte commerciale — ce ne sont pas les mêmes situations et les traiter identiquement fait perdre des clients.
L’archivage. Facture émise figée en PDF avec empreinte SHA-256, stockée en écriture non modifiable, avec le jeu de données qui a servi à la produire. Une facture est un document comptable : la regénérer plus tard doit donner exactement le même fichier, ce qui suppose de conserver aussi la version du modèle.