Le blogBrique après brique · Épisode 3/5
Publié le
Une bonne réponse adressée à personne
Le vrai goulot d'étranglement n'est pas l'intelligence du modèle. C'est l'état de ce à quoi on voudrait le brancher.
Série « Brique après brique », Épisode 3/5 · 1. L'Auditeur de code · 2. La recherche documentée · 4. ITFacto · 5. Le modèle est la dernière question
Le compliment qui n'en était pas un
Quand on montre un système de recherche documentaire à un professionnel, il y a un moment précis où son enthousiasme retombe. Il ne le dit pas toujours, mais on le voit.
Il a posé une question générale, pour tester. Il a obtenu une bonne réponse, sourcée, honnête. Il hoche la tête. Puis il pense au dossier qui l'attend, et la question qu'il aurait vraiment voulu poser n'est pas celle-là. Sa question à lui commence par « pour ce patient, qui a ceci et cela, et à qui on a déjà fait ça ».
Une réponse exacte mais adressée à personne reste un document. Elle a de la valeur, elle ne fait pas gagner grand-chose : le professionnel savait déjà chercher dans la documentation, il n'a jamais manqué de documentation. Ce qui lui coûte du temps, c'est de faire le lien entre son dossier et la documentation.
Autrement dit : mon système ne savait pas de quoi on lui parlait. C'est ce trou dans la raquette que la troisième brique vient combler.
Le vrai goulot d'étranglement n'est pas l'intelligence
Voilà l'idée que cet épisode veut faire passer, et elle est valable très au-delà de la santé.
Dans la quasi-totalité des projets, ce qui bloque n'est pas la capacité du modèle à raisonner. C'est l'état de ce à quoi on voudrait le brancher.
L'information existe. Elle est là, quelque part, dans un logiciel métier, un dossier, un export. Mais elle est écrite dans un format qui ne correspond à aucun autre, avec des codes maison, des identifiants qui ne se recoupent pas, des champs libres remplis différemment selon les services. Chacun de ces systèmes fonctionne parfaitement. Ils ne se parlent simplement pas.
Ce problème porte un nom peu glamour : l'interopérabilité. Il ne fait pas la une, il n'est mentionné dans aucune annonce de modèle, et il décide pourtant du calendrier réel des projets.
Pourquoi j'ai choisi le secteur le mieux outillé
Il y a une logique dans mon choix, et elle prolonge celle de l'épisode précédent.
La santé est probablement le domaine qui a le plus travaillé la question. Il existe un standard international pour échanger des données de santé, des terminologies partagées pour désigner les pathologies de façon non ambiguë, et en France un serveur national qui met ces terminologies à disposition. Des décennies de normalisation, des institutions dédiées, des financements publics.
Autrement dit : les meilleures conditions possibles. Si raccorder proprement un dossier à une base de connaissances y demandait encore un travail d'orfèvre, alors l'argument valait pour tout le monde.
C'est exactement ce que j'ai constaté.
Le démonstrateur fait une chose simple à énoncer. Il lit un dossier patient au format standard. Il prend les problèmes qui y sont codés, sous forme d'identifiants qui ne veulent rien dire pour un humain, et les résout en libellés français en interrogeant le serveur national de terminologies - 97,3 % des codes rencontrés y obtiennent une désignation française, ce qui est excellent et ce qui laisse quand même un code sur trente-sept sans traduction. Puis il pose au moteur de l'épisode 2 une question devenue précise, et obtient une réponse dont chaque phrase cite l'extrait qui la fonde.
Rien à réinventer. Tout à raccorder. Le travail n'a pas été de créer de l'intelligence, il a été de faire tenir ensemble des briques qui existaient déjà et ne se connaissaient pas.
Ce que les serveurs disent, et ce qu'ils font
Voilà le passage que je n'attendais pas, et qui a fini par devenir le cœur du démonstrateur.
J'ai branché le même client sur trois serveurs de dossiers patients - un simulateur de référence et deux bacs à sable d'un éditeur majeur. Puis j'ai mesuré ce que chacun appliquait réellement, au lieu de lire ce qu'il annonçait.
Les trois se comportent différemment, et deux s'écartent de leur propre documentation.
Le premier valide un jeton d'autorisation quand on lui en présente un, mais n'en exige aucun pour lire. Le deuxième n'a aucune couche d'autorisation du tout : il ne publie même pas la configuration qui décrirait comment s'y connecter, parce qu'il n'y a rien à décrire - il laisse lire, point. Le troisième est le seul des trois à appliquer véritablement les portées qu'il accorde.
Le meilleur exemple est le premier. Sa configuration publie noir sur blanc qu'il accepte le lancement autonome d'une application. Il refusait pourtant toutes mes demandes, jusqu'à ce que je comprenne qu'il attendait des options de lancement encodées dans l'adresse - en pratique, un objet JSON vide encodé en base64. Trois caractères. Rien dans la spécification ne le laissait deviner, et rien dans le message d'erreur ne le disait.
C'est ça, l'interopérabilité en 2026. Pas l'absence de standards : ils existent, ils sont bons. L'écart entre le standard annoncé et le standard appliqué. Un écart qu'on ne découvre qu'en mesurant, et que la page du démonstrateur affiche désormais serveur par serveur - parce que c'est précisément ce que le projet a d'intéressant à montrer.
Notez au passage que ce n'est pas la première fois que je rencontre ce mur. Deux ans plus tôt, en entreprise, une application parfaitement fonctionnelle est partie en production sans jamais servir, pour une raison du même ordre : l'information dont elle avait besoin n'existait pas sous une forme exploitable. C'est l'histoire de l'épisode 4.
Savoir où s'arrêter fait partie de la construction
Un mot sur ce que ce démonstrateur n'est pas, parce que la retenue est un choix de conception au même titre que les autres.
Il tourne sur des dossiers synthétiques. C'est un outil de recherche documentaire. Il ne constitue ni un dispositif médical, ni une aide au diagnostic, ni une aide à la décision thérapeutique, et il ne prétend à aucun moment le devenir.
Ce n'est pas une clause de style ajoutée en bas de page. C'est une frontière posée avant d'écrire la première ligne, et qui a déterminé ce que je m'autorisais à construire. Un système qui rapproche un dossier d'une documentation publique et montre ses sources est une chose. Un système qui suggère une conduite à tenir en est une autre, avec un cadre réglementaire, des exigences de validation et des responsabilités entièrement différentes.
Confondre les deux serait une faute technique avant d'être une faute juridique. Une bonne partie du travail d'ingénierie consiste à savoir jusqu'où va le système, et à le dire clairement à celui qui l'utilise.
La même exigence s'applique aux briques qu'on emprunte. La terminologie que le démonstrateur interroge est sous licence : sa version, son autorisation d'usage et l'attribution de l'agence qui la publie sont affichées sur la page. Personne ne me l'a demandé - mais un système dont on ne peut pas dire d'où vient le vocabulaire n'est pas plus traçable qu'un système dont on ne peut pas dire d'où vient la réponse.
La brique
Elle tient en une phrase, et c'est celle que j'emporte dans tous mes projets depuis :
La valeur d'un système d'IA se joue moins dans le modèle que dans ce à quoi on l'a correctement raccordé.
Ce qui se traduit, au premier rendez-vous, par une question très peu spectaculaire et très décisive : à quoi faut-il brancher ce système, et dans quel état sont ces données ?
La réponse à cette question contient le vrai calendrier du projet. Pas le choix technique, qui se règle en une après-midi. Le raccordement, lui, se compte en semaines, parfois en mois, et personne ne l'inscrit au planning initial.
Le mot de la fin
Trois briques posées. Décrire la qualité avant de produire. Répondre en montrant ses sources, ou se taire. Raccorder le système au réel pour que sa réponse s'adresse à quelqu'un.
Trois briques construites seul, devant un écran. Et c'est précisément leur limite.
Un démonstrateur n'a pas d'utilisateurs. Il n'a pas de comité de direction à convaincre, pas d'équipe qui devra changer ses habitudes, personne qui décidera au bout de trois semaines de retourner à son ancienne méthode. Rien de tout cela ne se simule.
La brique suivante n'est pas la dernière posée. C'est la première, chronologiquement, et elle est d'une autre nature : vingt mois en entreprise, cinq applications, et des gens en face.
C'est l'épisode 4.
📖 Dans la même série - Épisode 1 : l'Auditeur de code (mon premier projet ne construit rien) · Épisode 2 : la recherche documentée (citer ses sources, ou se taire) · Épisode 4 : ITFacto (vingt mois, cinq applications, des utilisateurs) · Épisode 5 : le modèle est la dernière question (les quatre questions du premier rendez-vous).
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.