Le modèle est la dernière question

Quatre questions à poser avant d'ouvrir la moindre documentation technique. Et ce qui se passe quand on ne les pose pas.

Série « Brique après brique », Épisode 5/5 · 1. L'Auditeur de code · 2. La recherche documentée · 3. La passerelle FHIR · 4. ITFacto

Neuf heures trente, salle de réunion

On vous fait asseoir. Café tiède. Au mur, une présentation de six pages : la direction a décidé que l'entreprise « ferait de l'IA cette année ». Autour de la table, un directeur général qui y croit, un responsable métier qui attend de voir, et quelqu'un de la DSI qui a déjà tenté l'aventure l'an dernier - le prototype dort quelque part dans un dépôt Git, tout le monde évite d'en parler.

Puis la question arrive. Elle arrive toujours. Elle arrive dans les cinq premières minutes.

« Vous partiriez sur quel modèle ? »

J'ai mis du temps à trouver la bonne réponse. Aujourd'hui, je dis : je ne sais pas encore. Pas par prudence commerciale, pas pour gagner du temps. Parce que cette question arrive quatre questions trop tôt.

Le modèle est une conséquence. Il se choisit en une après-midi quand le reste est clair, et il ne se choisit jamais correctement quand le reste ne l'est pas. Ce qui décide vraiment du sort d'un projet, ce sont quatre questions qu'on peut poser dès le premier rendez-vous, avec un tableau blanc et personne de technique dans la pièce.

Les voici, dans l'ordre.

Question 1 - « Comment saurons-nous que ça marche ? »

Posez-la et regardez ce qui se passe. Il y a d'abord un silence, puis trois réponses différentes.

Le directeur général parle de temps gagné. Le responsable métier dit : qu'il ne me fasse pas perdre plus de temps à vérifier qu'à faire moi-même. La DSI répond : qu'il ne tombe pas le vendredi soir. Trois personnes, trois définitions du succès, et aucune n'est écrite nulle part.

Tant que personne autour de la table ne sait décrire à quoi ressemble un bon résultat, il n'y a pas encore de projet. Il y a une intention. Ce n'est pas la même chose, et ça ne se finance pas pareil.

Le remède est presque décevant tant il est simple : avant d'écrire une ligne de code, on rassemble trente à cinquante cas réels - des vraies questions, des vrais dossiers, des vrais documents - et on écrit à côté la réponse qu'on attend. Un après-midi de travail, souvent pénible, parfois conflictuel, parce que c'est là qu'on découvre que deux services n'ont pas la même définition du bon dossier.

C'est le document le plus utile du projet. Il servira à trancher tous les désaccords des six mois suivants, et il transforme les débats d'opinion en constats mesurables.

J'ai appris ça en construisant mon premier outil, qui ne produisait rien du tout : il analysait du code existant et proposait quoi améliorer en premier. Impossible de le faire sans écrire d'abord, noir sur blanc, ce que j'appelais du code bien construit - puis sans construire un corpus de 2 784 dépôts pour que la note signifie quelque chose. Décrire la qualité est un travail en soi. C'est même le travail qui précède tous les autres.

Question 2 - « Que doit faire le système quand il ne sait pas ? »

Celle-là, on ne me l'a jamais posée spontanément. Pas une fois. Et c'est pourtant elle qui décide si les équipes utiliseront encore l'outil dans trois semaines.

Un système qui répond toujours est un système qu'il faut toujours vérifier. Faites le calcul de ce que ça coûte : si un utilisateur doit contrôler chaque réponse à la source, il fait le travail deux fois. L'outil ne fait pas gagner du temps, il en fait perdre, avec le sourire et une jolie interface.

À l'inverse, un système qui sait dire « je ne trouve rien qui réponde à votre question » rend chacune de ses autres réponses crédible. Le refus n'est pas une panne. C'est ce qui donne de la valeur à tout le reste.

C'est pour éprouver cette idée que j'ai posé mon premier système complet dans le domaine le plus exigeant que je connaisse : la recherche documentaire en santé. Un terrain où une réponse plausible mais fausse fait plus de dégâts qu'une absence de réponse. La règle y était non négociable : chaque affirmation cite l'extrait qui la fonde, ou le système se tait.

Ce qui tient dans ces conditions tient partout ailleurs. L'inverse n'a jamais été vrai.

Un détail de méthode, parce qu'il dit tout le reste : la mesure de qualité de ce système se publie en fourchette, de 0,322 à 0,693 selon ce qu'on accepte comme succès. La borne haute était la plus flatteuse. Elles voyagent ensemble.

Retenez la formulation à emporter en réunion : la confiance ne se gagne pas en ayant raison souvent, elle se gagne en étant prévisible.

Question 3 - « À quoi faut-il le brancher, et dans quel état sont ces données ? »

Voilà où se trouve le vrai calendrier du projet. Pas dans le choix technique - dans l'état de vos données.

Ce qu'on découvre en ouvrant les dossiers, systématiquement : trois versions de la même procédure sans date, un référentiel produit maintenu dans un tableur par une personne partie en juin, deux logiciels qui décrivent le même client avec deux identifiants différents, des exports qui ne se parlent pas.

Rien de tout cela n'est un problème d'intelligence artificielle. Ce sont des problèmes d'interopérabilité, de vocabulaire commun, de tuyauterie. Et ils sont la première cause de retard des projets IA, très loin devant la performance des modèles.

J'ai voulu m'y confronter dans le secteur qui a le plus travaillé la question : la santé, avec ses formats d'échange et ses terminologies nationales. Un domaine outillé, normé, financé pour ça.

Le plus instructif n'a pas été l'absence de standards : ils existent et ils sont bons. Ce n'est pas non plus le raccordement lui-même, qui n'a rien d'un exploit une fois les briques identifiées. C'est l'écart entre le standard annoncé et le standard appliqué. Sur trois serveurs branchés au même client, chacun s'est comporté différemment, et deux s'écartaient de leur propre documentation. Cet écart-là ne se lit nulle part. Il se mesure. Et s'il se trouve dans le secteur le mieux outillé de tous, ne pariez pas sur son absence chez vous.

La bonne nouvelle, et elle est réelle : ce chantier-là vaut le coup d'être mené même si le projet IA s'arrête. Des données propres, datées, identifiées, c'est un actif. Vous ne l'aurez pas fait pour rien.

Question 4 - « Qui s'en servira, et qu'est-ce que ça change dans son travail ? »

Cette question ne correspond à aucune brique technique. Elle les traverse toutes.

Je l'ai apprise sur le seul de mes projets qui avait des utilisateurs, une direction générale et une adoption à obtenir : vingt mois en alternance auprès d'un acteur des médias et du marketing B2B, du premier prototype à cinq applications que des équipes ouvrent le matin. C'est là que j'ai compris quelque chose que les démonstrateurs ne peuvent pas enseigner.

Un système livré à des équipes et que personne n'ouvre coûte deux fois. Le travail déjà fait, d'abord. Puis l'envie d'essayer la fois suivante, et ce second coût-là se paie sur des projets qui n'ont pas encore commencé.

Les gens ne refusent presque jamais un outil. Ils refusent qu'on décide à leur place de la façon dont ils travaillent. La différence entre les deux se joue au démarrage : est-ce que les personnes concernées ont participé à la définition du bon résultat de la question 1, ou est-ce qu'on le leur présente à la livraison ?

Alors on passe du temps dans les bureaux avant d'en passer devant l'écran. On écoute comment le travail se fait réellement, y compris ce qui ne figure dans aucune procédure. On repère ce qui ralentit vraiment les gens. Et on choisit le premier cas d'usage là, pas en comité.

On répond à cette question au démarrage, ou on la découvre à la livraison. Le prix n'est pas le même.

Et le modèle, alors ?

Il arrive maintenant, et il arrive vite.

Quand les quatre réponses sont sur la table, les décisions techniques s'enchaînent presque mécaniquement. La sensibilité des données dit où héberger. Le volume dit s'il faut une interface simple ou une infrastructure. Le niveau d'exigence de l'évaluation dit quelle taille de modèle est nécessaire - et la réponse est plus souvent « le petit suffit » qu'on ne le croit.

L'inverse ne marche pas. Aucune prouesse technique ne rattrape un projet dont les quatre réponses manquent. On obtient une démonstration impressionnante, des félicitations en comité, et un dépôt Git qui dort.

Le mot de la fin

On me demande parfois ce qui me plaît dans ce métier. Ce n'est pas la partie technique - elle est passionnante, mais elle est la plus documentée, la plus outillée, celle où l'on est le moins seul.

Ce que j'aime, c'est la traduction. Dans les deux sens.

D'un côté, transformer un besoin flou, exprimé avec les mots d'un métier que je ne connais pas encore, en quelque chose d'assez précis pour qu'une machine puisse l'honorer - et pour qu'on sache dire si elle l'a honoré. De l'autre, ramener les limites réelles du système vers les équipes, honnêtement, pour qu'elles sachent quand lui faire confiance et quand ouvrir le dossier elles-mêmes.

Un système d'IA utile, c'est presque toujours ça : une traduction fidèle, posée sur des données propres, dont on a mesuré la justesse et accepté les silences.

Alors la prochaine fois qu'on vous demande, à la cinquième minute, sur quel modèle vous partiriez, vous avez la réponse.

Bonne question. On la garde pour la fin.

📖 Dans la même série - Épisode 1 : l'Auditeur de code (décrire la qualité avant de la produire) · Épisode 2 : la recherche documentée (une réponse qui cite ses sources, ou qui se tait) · Épisode 3 : la passerelle FHIR (brancher la connaissance sur le réel) · Épisode 4 : ITFacto (vingt mois, cinq applications, des utilisateurs).

Les trois systèmes évoqués dans cette série sont en ligne et publics. Je conçois des systèmes d'IA traçables et vérifiables, du cas d'usage au déploiement - en savoir plus sur mon parcours, ou écrire à contact@lamoulinette.ai.

← Retour au blog