La facturation d’un opérateur télécom, c’est une activité qu’on ne voit jamais depuis l’extérieur. Chaque mois, il faut consolider les données de consommation de dizaines de clients (lignes actives, extensions PBX, numéros DIDs, SMS, tickets de support facturable), les faire correspondre avec les contrats CRM, générer les documents comptables et déclencher les virements fournisseurs. Le tout sans erreur, parce qu’une erreur de facturation vers un client, c’est une crise de confiance.
Pendant trop longtemps, on faisait ça à la main. Ou plutôt : semi-manuellement, avec des fichiers Excel, des copier-coller entre interfaces, et une dose d’appréhension le premier lundi du mois. Ça prenait des heures. Et ça produisait des erreurs.
Cet article décrit comment on a construit un pipeline de facturation automatisé en 9 étapes, ce que ça orchestre vraiment derrière, et ce qu’on a appris en le faisant. Ce n’est pas une démo de concept : c’est ce qui tourne en production chez nous chaque mois.
Pourquoi la facturation télécom est un problème de plomberie
Un opérateur télécom facture plusieurs types de consommation simultanément. Il y a les lignes SIP, des trunks qui transitent par des fournisseurs différents. Il y a le PBX cloud, avec les extensions, messageries vocales et DIDs par tenant. Il y a les SMS, les tickets support à facturer, et les prestations ponctuelles. Chaque source de données vit dans un système différent, avec son propre format et son propre rythme de mise à jour.
Le problème n’est pas la comptabilité en elle-même, Zoho Books gère ça très bien. Le problème, c’est l’agglutination : aller chercher les données dans sept systèmes, les réconcilier, détecter les anomalies, construire les lignes de facture correctes, et faire tout ça dans le bon ordre sans perdre de donnée en route.
C’est de la plomberie. Ingrate, invisible, mais critique.
Les 9 étapes du pipeline
Le pipeline s’appelle AUTO-FACTURATION. Il tourne sur Python/FastAPI avec une interface HTMX pour le pilotage. Chaque étape peut être lancée indépendamment, en mode dry-run ou en mode réel.
Étape 1 : import des consommations SIP
Un de nos fournisseurs amont fournit un export Excel de la consommation SIP par trunk. L’étape 1 parse cet export avec Pandas, valide la structure (colonnes attendues, périodes), et stocke les données localement. C’est volontairement basique : si le format d’export change côté fournisseur, on veut le détecter tôt et bloquer la suite, pas propager une donnée corrompue dans huit étapes suivantes.
Étape 2 : balances des trunks
Trois APIs ici, celles de nos fournisseurs de trunks. Chacune retourne les balances de trunks différents. Le travail de cette étape consiste à agréger ces trois sources et à les faire correspondre avec les comptes CRM. Ce n’est pas trivial parce que les identifiants ne matchent pas nativement : il a fallu construire une table de correspondance qui est maintenue manuellement.
C’est l’une des étapes où on a passé le plus de temps. Les trois APIs ont des comportements différents en cas d’erreur, des timeouts variables, et des formats de réponse qui évoluent sans notice. Le fallback est simple : si une API ne répond pas, l’étape se termine en erreur partielle avec un log explicite. On ne continue pas avec une donnée manquante.
Étape 3 : tickets de support
Zoho Desk contient les tickets marqués “à facturer”. Cette étape récupère les time entries et les montants associés par client. C’est en apparence simple, une API bien documentée et un filtre sur le statut, mais en pratique, les tickets peuvent être liés à plusieurs contacts et plusieurs organisations, et la correspondance avec les comptes de facturation demande une logique de résolution.
Étape 4 : statistiques SMS
Les données SMS sont dans Supabase, organisées par tenant. Cette étape agrège les volumes par période et calcule les montants selon la grille tarifaire. Rien de spectaculaire, mais c’est une source qu’on avait oubliée dans la première version du pipeline. Ce genre d’oubli, sur une facturation, ça se remarque.
Étape 5 : scan PBX
L’étape la plus spécifique à notre activité : on interroge notre PBX cloud (Digitis Cloud) pour récupérer, pour chaque tenant client, le nombre d’extensions actives, de messageries vocales et de DIDs portés. Ce sont les unités qui fondent le calcul de l’abonnement mensuel.
Le scan se fait via l’API de notre PBX cloud. Un tenant peut avoir des écarts entre ce qui est configuré et ce qui est facturable, des extensions désactivées mais non supprimées par exemple. Cette étape les expose : c’est à l’humain de trancher avant de continuer.
Étape 6 : simulation
C’est l’étape pivot. Elle prend toutes les données précédentes (balances CRM, tickets, SMS, PBX) et construit une preview complète de la facturation avant de toucher quoi que ce soit dans les systèmes comptables.
La simulation génère un récapitulatif par client : ce qui va être facturé, à quel montant, sur quelle base de calcul. On peut la relire ligne par ligne. C’est ici qu’on détecte les anomalies : un client avec un volume anormalement élevé, une ligne de ticket qui semble être un doublon, un tenant PBX dont le nombre d’extensions a augmenté sans contrat signé.
On n’a pas conçu cette étape comme une formalité. C’est un point d’arrêt délibéré. La facturation ne continue que si on valide la simulation.
Étape 7 : facturation
Après validation de la simulation, l’étape 7 crée les drafts dans Zoho Books et les soumet. Pour les clients éligibles, les factures sont poussées via Peppol (le réseau européen de facturation électronique). Pour les autres, l’envoi se fait par email classique en fallback.
C’est l’étape irréversible. Une facture envoyée existe. On a donc été très conservateurs sur les garde-fous : double vérification du montant total avant envoi, journal des factures créées avec les IDs Zoho, et rollback possible sur les drafts non encore transmis.
Étape 8 : paiements SEPA
Les fournisseurs de trunks facturent eux aussi. Cette étape orchestre les virements SEPA en masse via une API bancaire. Elle récupère les factures fournisseurs à régler, construit les ordres de paiement, et les soumet au batch SEPA.
C’est celle qui m’a donné le plus de sueurs froides au début. Un virement SEPA, c’est irréversible et immédiat. On a mis en place une validation par montant maximum par virement, une liste blanche d’IBAN autorisés, et une étape de confirmation manuelle pour tout ordre au-dessus d’un certain seuil.
Étape 9 : rapprochement
Le rapprochement bancaire n’est pas automatisé, et c’est voulu. Cette étape fournit une interface split-view : d’un côté les transactions bancaires reçues (via notre API bancaire), de l’autre les factures clients en attente de paiement. On extrait les PDFs, on visualise, on fait le matching manuellement ou semi-automatiquement.
Le rapprochement complet automatique est techniquement possible, mais on a choisi de garder un œil humain ici. C’est la dernière ligne de défense contre les erreurs d’imputation.
Ce qui n’a pas marché
Plusieurs choses.
La première tentative de connexion aux trois APIs de trunks simultanément a produit des conditions de course. L’ordre d’exécution n’était pas garanti, et les données se mélangeaient dans le buffer de consolidation. On a ajouté des queues explicites et un schéma de validation intermédiaire.
Le scan PBX s’est révélé beaucoup plus lent que prévu sur les tenants avec beaucoup d’extensions. L’API de notre PBX cloud n’est pas conçue pour des requêtes massives en rafale. On a limité le taux de requêtes et mis en place un cache local avec TTL court.
L’étape de simulation était initialement trop optimiste : elle ne présentait que le total par client, pas le détail par ligne. On a eu un cas où un montant paraissait correct globalement mais incluait une erreur compensée par une autre erreur en sens inverse. Ça ne se détecte qu’avec le détail. On a refait l’affichage.
Et il y a eu le cas du client dont le tenant PBX avait été renommé entre deux mois. La correspondance avec le compte CRM a planté silencieusement : les données du mois étaient justes mais affectées au mauvais compte. On a ajouté une vérification d’intégrité de correspondance en début de pipeline.
Ce que ça change vraiment
On ne gagne pas de temps sur la réflexion ou la décision, celles-là restent humaines. On gagne du temps sur l’assemblage et la détection d’erreurs.
Avant : plusieurs heures de collecte manuelle, des risques d’oubli, une fatigue d’attention qui augmente les erreurs en fin de session.
Aujourd’hui : le pipeline collecte tout en quelques minutes. On consacre le reste du temps à lire la simulation et à vérifier ce qui est flaggé comme anormal. Le premier lundi du mois est devenu une opération de validation, pas une opération de construction.
La réduction d’erreurs est plus difficile à quantifier, mais elle est réelle. Les erreurs qu’on fait encore sont des erreurs de jugement : un client dont le contrat est ambigu, une prestation dont la classification n’est pas évidente. Pas des erreurs d’oubli ou de calcul.
Ce que ça n’est pas
Ce pipeline n’est pas une solution produit. Il est taillé sur mesure pour nos systèmes, nos fournisseurs, notre CRM. Il n’est pas généralisable tel quel à un autre opérateur.
Ce n’est pas non plus une vitrine d’IA. La seule partie qui utilise un modèle de langage, c’est la détection d’anomalies dans les tickets, et c’est optionnel. Le reste, c’est de l’orchestration d’APIs, de la validation de schémas et de la logique métier classique.
Et ce n’est pas infaillible. Le mode dry-run existe précisément parce qu’on a eu des surprises. Le pipeline peut planter à l’étape 3 si Zoho Desk est lent, rater une correspondance PBX si un tenant a été renommé, ou produire une simulation incomplète si une API retourne une erreur partielle. On a des alertes. On vérifie. On intervient si nécessaire.
Pourquoi raconter ça
Pas pour vanter une technologie. Mais parce que beaucoup de PME font encore des opérations de facturation entièrement à la main, ou avec des demi-solutions qui créent autant de problèmes qu’elles en résolvent.
Ce qu’on a construit n’est pas hors de portée techniquement. Ce qui prend du temps, c’est de bien cartographier son propre processus, de comprendre où sont les données et comment elles se correspondent, et de construire les garde-fous au bon endroit.
L’automatisation n’est pas une baguette magique. C’est de la plomberie bien faite.
Cet article est le premier d’une série sur l’automatisation des processus opérateurs. Les prochains épisodes raconteront d’autres automatisations concrètes, le bon comme le moins bon.