Dalya — une phrase en français, une facture vérifiée
Logiciel de facturation pour indépendants et petites entreprises françaises : devis, factures, avoirs, relances. L’enjeu tenait en une ligne — obtenir une facture à partir d’une phrase écrite en français, sans qu’un texte inventé par une intelligence artificielle devienne un document légal faux.
Secteur : édition de logiciels
Période : 2023
Rôle : interface, et contribution à la fonctionnalité assistée par IA
Statut : produit d’équipe, mission terminée
Le contexte
Une facture n’est pas un écran, c’est une pièce comptable. Elle porte un numéro qui doit se suivre sans trou, un taux de TVA qui engage, une identité d’entreprise qui doit correspondre à un registre public, et une fois émise elle ne se corrige pas : elle s’annule par un avoir. Ce sont des règles anciennes, connues, et l’essentiel du travail d’un logiciel de facturation consiste à empêcher ses utilisateurs de les enfreindre sans le savoir. Le produit émet d’ailleurs ses factures au format Factur-X, profil BASIC : un PDF que le logiciel comptable du destinataire lit directement.
La fonctionnalité demandée était séduisante et exactement au bon niveau de danger : écrire une phrase du type « facture trois jours de conseil à Martin SAS » et obtenir la facture. Un modèle de langage sait produire ce texte. Il sait aussi produire, avec le même aplomb et dans la même seconde, un taux de TVA qui n’existe pas, une forme juridique inventée, ou un numéro d’entreprise qui appartient à quelqu’un d’autre. Rien, dans la forme de sa réponse, ne distingue les deux cas — et c’est là toute la difficulté : l’erreur ne ressemble pas à une erreur, elle ressemble à une facture.
La question n’a jamais été la qualité du modèle. Elle était de savoir où passe la frontière entre ce qu’une intelligence artificielle propose et ce que le logiciel enregistre, et comment rendre cette frontière vérifiable par la machine à chaque écriture.
Le périmètre, dit précisément
Dalya est un produit d’équipe. Le dépôt compte huit contributeurs ; j’y ai signé environ un commit sur trois, de février à novembre 2023. L’architecture que décrit cette fiche — l’étanchéité entre entreprises clientes, la modélisation des états de facture — était en place avant mon arrivée et revient à ceux qui l’ont posée. Ce que j’y ai porté : l’interface, la contrainte de format imposée au modèle de langage, et un test qui audite ce que ce modèle renvoie.
Cette fiche décrit donc un système que j’ai servi, pas un système que j’ai décidé. Elle est ici parce que savoir lire une architecture rigoureuse, l’expliquer à un non-technicien et dire où elle s’arrête est exactement le travail qu’on achète dans un audit — et parce qu’un prestataire qui s’attribue les décisions des autres se fait démentir au premier appel de référence.
Les règles qui tiennent ce système
Ce que l’IA produit n’est pas de la donnée métier, c’est une proposition.
Sa réponse est confrontée aux règles du métier — unités, taux de TVA, formes juridiques. Si elle échoue, l’erreur lui est renvoyée pour une seconde tentative, ce qui suffit dans la plupart des cas. L’identité de l’entreprise cliente est revérifiée au registre officiel des entreprises avant toute écriture : la source de vérité sur l’existence d’une société n’est pas le modèle, c’est le registre.
Enfin, rien n’est enregistré tant qu’une personne n’a pas cliqué — et la proposition emprunte alors exactement le même chemin que la saisie au clavier. La même porte d’écriture, les mêmes contrôles, dans le même ordre.
C’est ce point qui décide de tout le reste. Quand une fonctionnalité assistée par IA se voit accorder un chemin d’écriture à elle, plus court parce qu’il est plus simple à construire, elle contourne du même coup tous les contrôles accumulés sur le chemin normal depuis des années — et personne ne s’en aperçoit, puisque le résultat a l’air correct. Faire passer la proposition par la porte commune demande du travail au moment de la construction. C’est ce travail qui garantit qu’une règle ajoutée l’an prochain s’appliquera aussi, sans que personne y pense, à tout ce que produit l’IA.
L’étanchéité entre entreprises clientes ne repose pas sur la mémoire du développeur.
Un logiciel de facturation héberge tous ses clients dans une base commune. La fuite, dans ce genre de produit, ne vient presque jamais d’une intrusion : elle vient d’un filtre oublié dans une requête, un jour où quelqu’un ajoutait un écran de statistiques.
Le tri est donc confié au moteur de base de données lui-même : trente-six règles sur vingt-deux tables, appliquées à chaque lecture, quelle que soit la question posée et quel que soit le morceau de code qui la pose. L’oubli n’a plus d’effet.
La différence entre les deux approches est de nature, pas de degré. Dans le premier cas, la confidentialité dépend de la vigilance de la personne qui écrira la prochaine requête — y compris quand cette personne est un assistant IA qui n’a jamais lu vos conventions internes et qui produit du code plausible en quantité. Dans le second, la question ne se pose plus : la base ne sait pas répondre autre chose.
Brouillon, validée, payée ne sont pas trois valeurs d’un même indicateur, mais trois objets différents.
La manière habituelle consiste à poser un statut sur la facture. Elle a un défaut discret : rien n’empêche d’écrire une opération qui n’a aucun sens pour ce statut — encaisser un brouillon, modifier une facture déjà numérotée. Le garde-fou existe alors sous forme de condition, quelque part, qu’on peut oublier de recopier.
En traitant chaque état comme un objet distinct, l’opération absurde ne s’écrit plus : le logiciel refuse de se construire. L’erreur n’est plus découverte à l’exécution, chez le client, par un utilisateur qui appelle le support ; elle est refusée sur le poste du développeur, avant d’exister. Le compteur de numérotation, lui, ne peut être ni créé ni supprimé depuis l’application.
Une erreur qu’un programme refuse de laisser écrire ne quitte jamais le poste où elle a été tapée. La même erreur découverte par l’expert-comptable du client coûte une facture rectificative, une explication, et une entaille dans la confiance qu’on met dans le logiciel.
Ce qui n’est pas verrouillé
La validation d’une facture et l’incrément du compteur de numérotation forment un enchaînement applicatif : le logiciel exécute les deux opérations l’une après l’autre. Ce n’est pas une transaction garantie par la base de données, c’est-à-dire un tout-ou-rien dont la machine se porte garante. Dans un cas limite — une coupure entre les deux opérations — un écart est possible. Je ne l’ai pas observé, et je ne l’écris pas pour me couvrir. Je l’écris parce qu’un système de facturation qui prétendrait n’avoir aucune zone de ce genre mentirait, et parce que savoir précisément où elles se trouvent est exactement ce qu’on achète dans un audit.
LE PRINCIPE DIRECTEUR
Une intelligence artificielle n’est pas un collègue de confiance, c’est une source. Tout ce qui en sort est confronté aux règles du métier avant d’engager qui que ce soit, et attend la décision d’une personne pour exister.
La stack
TypeScript, Next.js, React, Effect-TS et fp-ts, PostgreSQL (Supabase auto-hébergé), Prisma, Puppeteer et pdf-lib, Factur-X profil BASIC, Stripe, Jest, Cypress, GitHub Actions, Docker.
Ce que dit le client
« Quentin a su s’adapter très rapidement à l’architecture et livrer des features dès la deuxième journée. […] Force de proposition, communicant. »
— Valentin Rabot, NEXAS
L’ÉTAPE SUIVANTE
Si vous êtes dans cette situation — une fonctionnalité assistée par IA déjà en service, ou sur le point de l’être, et aucune certitude sur ce qu’elle peut écrire dans vos données — l’audit de trois jours établit ce qui peut aujourd’hui être enfreint sans que rien ne le signale.
Audit de codebase généré par IA : ce qui tient, ce qui doit être repris — 3 jours, 2 400 € HT
Nous utilisons des cookies uniquement pour le bon fonctionnement du site. Avec votre accord, nous activons aussi le module de prise de rendez-vous Calendly, qui dépose ses propres cookies. Vous pouvez changer d’avis à tout moment depuis le pied de page. En savoir plus
