Le 1er septembre 2026 marque le début effectif du déploiement de la réforme de la facturation électronique en France. Toutes les entreprises doivent désormais être capables de recevoir des factures électroniques ; les grandes entreprises et les ETI doivent également les émettre sous cette forme. Comme souvent avec ce genre de changement, je vois passer beaucoup d’agitation sur les réseaux. Ironie du calendrier : la DGFiP a elle-même révélé mi-août des accès illégitimes à une partie de son système d’information , tout en précisant que cet incident est sans lien avec le dispositif de facturation électronique.

Bref, tout ça m’a donné l’occasion de repenser à un petit outil que j’avais écrit pour NuCorder il y a déjà quelques mois.

Rassurez-vous, je ne vais pas vous vendre une plateforme de facturation, ce n’est pas du tout mon métier. Je vais plutôt profiter de l’occasion pour vous parler d’un problème voisin, beaucoup plus modeste, mais qui concerne pratiquement toutes les entreprises : la corvée mensuelle de collecter les factures des fournisseurs avant de les transmettre à la comptabilité.

Deux personnes vérifient des factures et des documents comptables

Photo : Mikhail Nilov / Pexels.

Une demi-heure de perdue tous les mois

NuCorder , c’est une plateforme de répétition en ligne pour musiciens sur laquelle j’interviens comme CTO fondateur, à côté de mon activité de conseil. Le projet est porté par une petite SAS, Ugly Cat, qui réunit les trois fondateurs.

Pas de service comptable, pas d’office manager : on fait tout nous-mêmes. Chaque mois, c’est donc moi qui me connecte aux différents sites de nos fournisseurs pour télécharger leurs factures une par une, avant de les transmettre à notre expert-comptable.

Rien de bien compliqué en soi : c’est juste répétitif, chronophage et suffisamment ennuyeux pour que la tâche glisse vers le bas de la pile. Dans les faits, ça part toujours à temps : le volume reste modeste et Jean-Noël, notre président, me le rappelle si je traîne. Mais comme toute obligation, plus j’attends, plus je finis par m’en occuper dans l’urgence.

Comme beaucoup d’autres corvées administratives, ce type de tâche est prévisible, revient toujours sous la même forme et ne demande pratiquement aucune décision humaine. En raisonnant comme un développeur, c’est exactement le genre de travail qu’un petit outil peut prendre en charge, sans pour autant nécessiter des heures de développement ou un énorme projet.

Une commande pour les gouverner tous

bills-collector, c’est le nom de l’outil que j’ai fini par écrire pour NuCorder.

Concrètement, c’est un projet en Go d’environ 2 000 lignes de code, sous la forme d’une CLI — autrement dit, un programme sans interface graphique.

Au lancement, la commande charge un fichier de configuration (ce n’est pas parce que le projet est petit qu’on doit committer des secrets), détermine le mois précédent, puis interroge les API des fournisseurs qui en proposent une.

go 
// BillType represents the category of a bill
type BillType string

const (
	// BillTypeExpense represents bills the company pays
	BillTypeExpense BillType = "expense"
	// BillTypeRevenue represents bills the company issues to customers
	BillTypeRevenue BillType = "revenue"
)

// Bill represents a downloaded bill/invoice
type Bill struct {
	Provider    string
	BillType    BillType
	Date        time.Time
	Filename    string
	Content     []byte
	ContentType string // "pdf", "csv", etc.
}

type BillProvider interface {
    FetchBills(ctx, month) ([]Bill, error)
    GetName() string
    IsEnabled() bool
}

Le reste du code n’a pas beaucoup d’intérêt ici, et je préfère éviter de publier la liste exacte des fournisseurs et des intégrations utilisés par NuCorder. L’idée importante tient surtout dans cette interface : chaque fournisseur expose la même façon de récupérer ses factures, ce qui permet au programme de les traiter de manière uniforme.

L’opération prend quelques secondes et me crée une arborescence de fichiers que je n’ai plus qu’à vérifier, zipper et envoyer à la comptabilité. La version manuelle me demandait facilement une vingtaine de minutes, à condition d’être déjà connecté aux différents services et d’avoir préparé mes marque-pages.

L’outil est volontairement simple et ne cherche pas à couvrir tous les cas particuliers, notamment lorsqu’un fournisseur ne propose pas d’API exploitable. Je n’avais aucune envie de partir dans une longue rétro-ingénierie avec, au passage, le risque de me faire bloquer : le but était de me faire gagner du temps, pas d’en perdre.

Aujourd’hui, il ne me reste plus que deux cas à gérer à la main.

Sortie de bills-collector après la collecte des factures
La commande bills-collector après une collecte réussie

Pourquoi construire un petit outil sur mesure ?

Parce que le problème ne justifie ni un abonnement supplémentaire ni des frais d’infrastructure pour une structure aussi petite.

bills-collector n’a pas d’interface graphique, pas de compte utilisateur et pas d’abonnement mensuel. C’est un petit programme que je lance lorsque j’en ai besoin et qui s’arrête une fois son travail terminé.

Techniquement, le principe est assez banal : quelques appels aux API des fournisseurs et une interface en ligne de commande pour lancer l’ensemble. Go, mon langage de prédilection, se prête très bien à ce genre d’exercice : il permet de produire rapidement un exécutable autonome, facile à déployer et à relancer sans installer tout un environnement autour.

Ce n’est évidemment pas une recommandation universelle : pour un autre besoin, ou une autre équipe, le bon choix sera peut-être Python, JavaScript, PowerShell ou tout autre outil déjà maîtrisé. L’important est surtout de choisir ce qui permet de résoudre le problème simplement.

Bien sûr, « petit outil » ne veut pas dire « aucune maintenance » : une API peut changer, un mode d’authentification évoluer. On reste cependant sur un périmètre très limité par rapport à une application complète.

Dans le cas de NuCorder, environ deux heures de développement et de validation ont suffi pour éliminer l’essentiel d’une tâche qui revenait tous les mois : c’est précisément parce que le problème est modeste que la solution peut l’être aussi.

L’IA pour construire l’outil, pas pour le faire tourner

Dans le monde de la tech, une forme de chambre d’écho tend parfois à faire croire qu’il faut mettre de l’IA partout et lui confier toutes les automatisations. Je ne pense pas que ce soit nécessaire, et j’y vois même un risque croissant de dépendance (sans compter les questions éthiques liées aux jeux de données utilisés pour l’apprentissage des modèles).

J’y vois en revanche une autre opportunité : s’attaquer à des besoins qui ne sont jamais vraiment prioritaires, non pas parce qu’ils n’existent pas, mais parce qu’il y a toujours plus urgent.

L’IA générative permet aujourd’hui de prototyper et de construire très rapidement de petits outils à usage ciblé, pour peu qu’on sache déjà ce qu’on veut faire et comment l’aborder. Dans ce genre de cas, je ne vois pas forcément l’intérêt de redemander chaque mois à un modèle de résoudre exactement le même problème, avec à la clé un coût récurrent, une dépendance supplémentaire et le risque d’obtenir un résultat différent d’une exécution à l’autre.

L’IA peut donc réduire le coût de création de petits outils sans nécessairement devenir une dépendance permanente de leur fonctionnement. Pour beaucoup de tâches mécaniques, c’est une approche plus sobre — et souvent plus adaptée — que d’ajouter un agent là où quelques lignes de logique déterministe suffisent.

Ce que j’en retiens

bills-collector n’est pas un projet spectaculaire : c’est environ deux heures de travail pour supprimer une tâche d’une vingtaine de minutes qui revenait chaque mois. C’est justement ce qui le rend intéressant.

On pense facilement à la technologie pour résoudre les gros problèmes : lancer une nouvelle application, refaire une architecture, déployer une plateforme ou introduire de l’IA. On pense moins souvent à l’utiliser pour éliminer les petites frictions qui s’accumulent silencieusement dans le quotidien d’une entreprise.

Toutes ne méritent évidemment pas d’être automatisées ; mais lorsqu’une tâche est répétitive, prévisible et ne demande pratiquement aucune décision humaine, il vaut parfois la peine de se demander si quelques heures de développement ne coûteront pas moins cher que de continuer à la répéter pendant des années.

L’outil adapté n’est pas forcément le plus complet ni le plus impressionnant : c’est celui qui répond au besoin avec le moins de complexité possible.

Parfois, ce n’est qu’une commande.

Vous avez ce genre de tâche dans votre entreprise ?

Une collecte manuelle, des fichiers à consolider chaque semaine, des exports à retraiter ou un processus interne qui prend du temps sans vraiment apporter de valeur ?

C’est précisément le genre de sujet sur lequel j’interviens chez Cabestan : comprendre le besoin, identifier ce qui mérite réellement d’être automatisé et construire la solution la plus simple qui y répond.

Si cet article vous a fait penser à une corvée que vous ou vos équipes répétez encore à la main, n’hésitez pas à me contacter.

Parlons-en