Vos règles métier, enfin dans un outil.

Vous connaissez vos règles mieux que personne. Le problème, c'est qu'elles vivent dans un tableur, dans un classeur de procédures que plus personne ne lit, et surtout dans quelques têtes. Une règle qui n'existe que dans une tête n'est pas une règle : c'est une dépendance.

• Une seule personne sait

  « Il n'y a que le fondateur, ou le premier développeur, qui sait comment on calcule ça. » Dit en riant, c'est la description d'un risque que personne n'a chiffré. La règle vit dans le code sous forme de conditions imbriquées, sans commentaire : personne d'autre n'ose y toucher.

• Le module que personne ne veut reprendre

  Un fichier de deux mille lignes, des fonctions que plus personne ne comprend, des copies collées-modifiées qui divergent d'un produit à l'autre. Tout le monde s'en sert, personne ne le touche.

• Le coût de la dépendance au recrutement

  À chaque recrutement, la nouvelle personne ne peut pas avancer sans interrompre celle qui livre déjà — elle doit lui demander comment fonctionne cette partie du code. Le recrutement, censé accélérer l'équipe, la ralentit.

Plus votre métier est encadré — conformité, éligibilité, contrats — plus cette dépendance coûte cher le jour où elle casse.

Vous n'avez pas à décider d'un projet complet pour commencer. La première étape est courte, bornée, et son montant est déduit du projet si nous continuons. Vous repartez avec quelque chose d'utile même si nous nous arrêtons là.

Autant y répondre ici plutôt qu'au bout de trois échanges de mails.

Et nos données confidentielles ?

Elles restent dans le périmètre défini au démarrage : hébergement en Union européenne, aucune donnée versée à l'entraînement d'un modèle public, accès tracés. Je travaille depuis Antananarivo. Le contrat de sous-traitance et les clauses contractuelles types sont signés au démarrage — rédigés pour être transmis en l'état à vos propres clients quand ils vous interrogeront sur votre chaîne de sous-traitance. Le spike, lui, se fait sur documents anonymisés : aucune donnée personnelle réelle pour commencer. Sur les corpus les plus sensibles, le modèle tourne sur votre infrastructure et rien n'en sort.

Combien ça coûte ?

Le spike est une prestation courte et bornée, et son montant est déduit du projet si nous continuons. Le budget d'un projet complet dépend de ce qu'il révèle — c'est précisément ce qu'il sert à établir. Certaines PME françaises en font financer une partie (Diag Data IA, IA Booster) : on en parle si le sujet se pose.

Vous êtes seul. Que se passe-t-il si vous n'êtes plus là ?

C'est la question que je vous pose sur votre fondateur ou votre premier développeur ; il est normal que vous me la posiez. Le code vous appartient, il vit sur votre dépôt, il est documenté, et il repose sur des technologies courantes qu'un autre développeur reprend sans moi. Une dépendance qu'on peut quitter n'en est plus une.

On a déjà une équipe de dev. Pourquoi vous ?

Parce que vous ne cherchez pas des bras. Faire tourner un LLM sur des documents propres, n'importe quelle bonne équipe y arrive. Le faire tenir sur des scans de travers, des tableaux à cheval sur deux pages et vingt variantes de mise en forme selon le client, c'est un autre métier — et c'est celui que j'ai exercé sur six produits en environnement réglementé. Le spike existe précisément pour que vous le vérifiiez avant de vous engager.

On a déjà un logiciel. Il faut tout remplacer ?

Presque jamais. Dans la plupart des cas, la brique ou le module s'intègre dans votre base de code existante et prend en charge la seule partie que personne n'a réussi à automatiser — sans réécriture ni migration imposées. Remplacer un système qui fonctionne est le meilleur moyen de transformer un projet de six semaines en projet de six mois.

Combien de temps avant de voir quelque chose ?

Le compte-rendu du spike sous 5 jours. Une première version de la brique IA utilisable par vos équipes en trois à cinq semaines. Vous ne financez pas six mois à l'aveugle avant la première démonstration.

Et si la réglementation change ?

C'est justement le but. Une règle posée dans un outil se modifie à un endroit, et la modification s'applique partout. Une règle répartie dans quatorze onglets se modifie quatorze fois — et on en oublie toujours une.