← Toutes les publications

En analyse de données, mieux vaut utiliser l'IA une fois pour toutes qu'à chaque fois

5 minutes de lecture (ou 3 bullet points si vous n’avez vraiment pas le temps)
01Pour le Customer Cube de D-EDGE, il fallait extraire des dates de période enfouies dans des descriptions de factures en texte libre, multilingues et sans format imposé.
02Plutôt que d'appeler l'IA sur chaque ligne (coûteux, variable, risque d'hallucination), nous avons fait produire par l'IA un regex sur mesure : quelques heures d'itération pour un travail de deux à trois jours.
03Le regex tourne désormais en SQL pur, sans appel à un modèle. Le livrable appartient au client, reste auditable et portable, et continue de fonctionner même si l'IA devient indisponible ou trop chère.
Cas client D-EDGE

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.

Un cube jaune organise des factures et des données dans un univers bleu.
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.

§1Le 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.

§2Deux 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.

§3Ce 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.

§4L'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.
05 — Publications

Découvrez nos analyses...

Cas clients et analyses sur la Data et l’IA, une fois par mois dans votre boîte mail.

Derniers cas clientsTout voir →
Dernières analysesTout voir →

Un projet à partager avec nous ?

Nous serions ravis d’en discuter pour vous conseiller sur les premières orientations.

Parler à un expert