D-EDGE est l'un des leaders mondiaux des solutions technologiques pour l'hôtellerie. Au fil de sa croissance, sa facturation s'est répartie entre plusieurs systèmes. Le chiffre d'affaires est bien consolidé en comptabilité, mais pas en vue ARR. Or sur le marché du logiciel en SaaS, l'ARR est l'indicateur de référence : il mesure la part récurrente et prévisible du revenu, celle qui fait la valeur d'un éditeur. C'est le premier chiffre que regardent une direction et ses investisseurs.
D-EDGE a missionné Solstice Lab pour consolider son Customer Cube : un pipeline unique dans BigQuery qui réunit toutes les sources de facturation, ventile le revenu mois par mois par client et par produit, et reconstitue la dynamique annuelle du chiffre d'affaires (acquisitions, expansions, contractions, résiliations, reconquêtes). L'objectif était d'amener D-EDGE aux meilleurs standards du marché sur ce pilotage.

Comme une boule de cristal, mais cubique
Dans ce but, l'algorithme a besoin, pour chaque facture, de comprendre le type de revenu, le type de client, mais surtout la période couverte. Une facture annuelle de janvier se répartit sur douze mois, une facture trimestrielle sur trois. À l'échelle de D-EDGE, ce sont des centaines de milliers de lignes de facturation à ventiler, chacune supposant de connaître les dates de début et de fin de couverture. La plupart des systèmes les fournissent dans des champs dédiés. Mais pas une des sources de D-EDGE.
Le problème : des dates enfouies dans du texte libre
Sur cette source, qui représente des dizaines de milliers de lignes, l'information de période existe bien, mais dans un champ de description en texte libre, saisi par les équipes commerciales sans convention imposée, dans au moins trois langues. Quelques exemples réels :
• « Période du 01/03/2024 au 31/03/2024 »
• « Subscription from 01/01/2024 to 31/12/2024 »
• « Abonnement du 15/01/24 au 14/02/24 »
• « Servicio del 01/03/2024 al 31/03/2024 »
Français, anglais, espagnol. Années sur deux ou quatre chiffres. Des mots de liaison propres à chaque langue (« du… au », « from… to », « del… al »). Et des pièges : le « du » français apparaît aussi dans « produit du mois », le « to » anglais est un mot courant. Il fallait extraire la bonne paire de dates de façon fiable, sans faux positifs.
Deux options
L'idée d'utiliser l'IA pour interpréter ces champs libres a émergé vite : « voilà le champ, dis-moi à quelles dates de début et de fin il correspond ». Mais cette voie posait trois problèmes. Il aurait fallu rappeler l'IA à chaque nouvelle facture, donc à chaque rafraîchissement du Customer Cube, avec un coût et une variabilité qui se répètent. Le volume de texte à traiter aurait pesé lourd en tokens. Et il aurait fallu découper les demandes pour éviter de noyer l'IA sous un volume excessif et la faire halluciner.
Alors, nous avons choisi une autre voie : utiliser l'IA pour produire l'outil qui ferait le travail, plutôt que pour réaliser la tâche directement. Nous avons donc fait coder par Claude un jeu d'expressions régulières (ou regex), ce format de code complexe qui permet d'indiquer la partie d'une chaîne de caractères que l'on souhaite extraire. Un regex couvrant proprement les trois langues, les deux formats d'année et les cas limites aurait représenté deux à trois jours de travail pour un développeur expérimenté. En quelques heures d'itération, l'IA a produit une première version sur la base d'un échantillon aléatoire de factures, que nous avons affinée en la confrontant aux données réelles. Tout ce qui restait encore non couvert était échantillonné et passé à l'IA pour ajustement du regex. Jusqu'à ce que 99,99 % de la base soit couverte.
Ce que recouvre « un regex complexe »
Prenons un cas simple pour comprendre. Pour isoler le nom de domaine d'une adresse email, un regex cherche ce qui suit le « @ » jusqu'au point : appliqué à contact@solstice-lab.com, il retient solstice-lab. Une règle, un motif, le tour est joué.
Nos descriptions de factures sont d'un autre ordre. Pour repérer une date de début, il ne suffit pas de chercher une suite de chiffres : il faut reconnaître le mot qui l'annonce, et ce mot change selon la langue (« du » en français, « from » en anglais, « del » en espagnol). Déjà, un motif par langue. Ensuite, la date elle-même s'écrit tantôt sur quatre chiffres (2024), tantôt sur deux (24) : encore une variante à prévoir, avec un garde-fou pour qu'un « 24 » ne vienne pas rogner le début d'un « 2024 ». Puis les faux amis : le « du » de « produit du mois » n'introduit aucune date et ne doit rien déclencher. S'ajoute enfin une contrainte technique de BigQuery, qui n'extrait qu'un élément à la fois : il faut donc une passe pour la date de début, une autre pour la fin, puis un mécanisme qui teste les langues dans leur ordre de fréquence et retient la première lecture valide.
Chaque règle est triviale prise seule. C'est leur imbrication, le bon ordre de priorité et les garde-fous entre elles, qui transforme l'exercice en deux à trois jours de travail pour un développeur expérimenté, et que l'IA a condensés en quelques heures.
Le résultat couvre aujourd'hui l'essentiel du chiffre d'affaires récurrent de cette source par extraction directe des dates, complété par quelques règles métier validées empiriquement pour les rares cas restants.
L'intérêt : un livrable qui tourne sans IA
Le regex est désormais intégré au code SQL du pipeline. Il s'exécute sur les centaines de milliers de lignes du périmètre à chaque rafraîchissement du Customer Cube, sans appel à un modèle d'IA, sans coût au token, sans dépendance à la disponibilité d'un éditeur, et avec un résultat stable d'une exécution à l'autre. Un même texte produit toujours la même sortie, garantie que le comportement probabiliste des modèles d'IA empêche d'offrir.
L'IA a servi là où elle excelle : compresser plusieurs jours d'expertise en quelques heures. Le produit final, lui, appartient à D-EDGE. Il est lisible, auditable et portable. Le jour où le robinet de l'IA se ferme ou devient hors de prix, ce code continue de tourner exactement comme la veille.
On y revient : la bonne façon d'intégrer l'IA en profondeur sans s'en rendre dépendant consiste à s'en servir pour fabriquer les outils précis dont on a besoin, puis à les faire tourner sans elle.


















