Pas parce que le retrieval est défaillant. Pas parce que les sources manquent. Mais parce qu’une réponse juste et une réponse utile ne sont pas la même chose. Un directeur d’ESSMS qui demande si une prime de partage de la valeur est opposable à son tarificateur n’attend pas une synthèse de l’article L. 314-6 du CASF. Il attend qu’on lui dise si ça va passer, dans quel contexte ça peut être contesté, et ce qu’il risque à insister. C’est une différence d’architecture, pas de contenu.

J’y reviendrai. Mais d’abord, les fondations.

Un RAG qui donne de la profondeur repose sur des choix techniques qui se prennent tôt et se paient cher si on les rate. Trois d’entre eux ont été déterminants dans ce que j’ai construit.

Le premier concerne la jurisprudence. Ingérer des décisions JADE brutes dans un vecteur, c’est ingérer du bruit autant que du signal. Une décision du CNTSS sur l’agrément d’un accord collectif et une décision sur la fixation d’un tarif PA n’ont pas la même portée, pas le même public, pas le même niveau d’urgence pour un directeur. J’ai donc construit un pipeline d’enrichissement en tiers : les décisions structurantes — celles qui font jurisprudence, qui définissent une doctrine de tarification ou précisent les limites d’un pouvoir de l’autorité tarifaire — sont enrichies manuellement après génération par Opus. Chaque chunk porte une qualification explicite : type de recours, problématique centrale, portée, catégorie d’établissement concernée. Les décisions de second rang reçoivent une notice de positionnement plus légère, générée par Haiku. Les autres restent brutes avec leur contexte hiérarchique. Le retrieval ne cherche plus dans une masse homogène — il cherche dans un corpus qui a déjà une opinion sur sa propre importance.

Le deuxième choix concerne la performance sur corpus dense. J’utilise des vecteurs à 3072 dimensions stockés en halfvec, indexés via HNSW avec des paramètres calibrés pour le secteur. Ce qui semble être un détail d’implémentation a eu des conséquences très concrètes : un bug de cast halfvec non détecté pendant des semaines faisait tomber certaines requêtes en sequential scan à 5400ms au lieu des 130ms attendus avec l’index. La correction tenait en une migration SQL. Mais sans le diagnostic, le système semblait fonctionner — les réponses arrivaient, juste lentement. Sur un corpus juridico-réglementaire où la requête complexe doit remonter cinq sources pertinentes en moins de deux secondes pour rester utilisable, ce type d’écart n’est pas anodin. Le reranking Cohere en aval affine la sélection finale — mais il ne peut travailler que sur ce que le retrieval lui amène.

Le troisième choix est le chunking. Les textes réglementaires — CASF, CCN66, CCN51 — ont une structure interne forte : articles, alinéas, renvois, tableaux de grilles salariales. Un chunking naïf par taille de token découpe au milieu d’une disposition, sépare un article de son contexte, isole un tableau de la règle qu’il illustre. J’ai opté pour un chunking structurel adaptatif qui respecte les découpages natifs du texte, avec réintégration du contexte hiérarchique dans chaque chunk. Un article R. 314-9 extrait seul ne dit presque rien — replacé dans la logique du financement par dotation globale avec le contexte de section, il devient retrievable sur des questions terrain qui n’utilisent pas ses mots.

Ces trois choix combinés donnent un système qui répond juste. Retrieval précis, latence maîtrisée, cohérence des sources. Un bon résultat.

Mais la mauvaise réponse.

Ce que j’ai compris assez tôt, c’est qu’un directeur d’ESSMS interroge rarement une base de connaissances. Il consulte un pair avec plus d’expérience que lui sur un sujet précis. La différence n’est pas rhétorique — elle est architecturale.

Un pair ne cite pas les textes. Il les a lus, il les a croisés avec du terrain, il a une lecture. Il sait que l’instruction budgétaire de novembre dernier change quelque chose sur la reprise des résultats excédentaires, mais que les services des Conseils départementaux ne l’ont pas encore intégrée dans leurs pratiques. Il sait que la jurisprudence CNTSS sur les accords agréés laisse une marge, mais qu’un établissement déjà en déficit a peu de chances de la faire valoir. Ce savoir-là n’est dans aucune source publique. Il est dans l’expérience accumulée de quelqu’un qui a passé des années à lire le secteur.

C’est cette couche que j’ai voulu encoder.

L’architecture est simple : à chaque requête, un classificateur d’intention détermine le registre de la question — tarification, RH, qualité, relations institutionnelles, tension financière. Ce routing appelle un fichier de contexte correspondant, mis en cache, qui contient ma lecture du domaine. Pas une synthèse de textes publics. Ma lecture : les zones grises que les textes ne tranchent pas, les pratiques réelles des tarificateurs que les circulaires n’explicitent jamais, les points de vigilance que seul le terrain enseigne. Ce fichier est injecté dans le contexte avant que le modèle compose sa réponse. Le RAG apporte les sources. Le contexte éditorial apporte le regard.

Le fichier le plus original de ce dispositif s’appelle signaux_tension.md.

Il n’encode pas une thématique au sens habituel. Il encode une doctrine sur ce que les établissements ne disent pas. La sous-consommation de crédits qui n’est pas un signe de bonne gestion mais d’un gel défensif. Le taux d’occupation “tenu” artificiellement par des admissions précipitées. Le turn-over que les ETP moyens annuels lissent et cachent. La distinction entre un établissement qui souffre conjoncturellement et un dont le projet est épuisé — qui ne le sait pas encore.

Ce fichier n’est pas appelé quand un utilisateur demande explicitement une analyse de risque. Il est chargé transversalement, silencieusement, dès que certains signaux apparaissent dans la requête — des mots qui évoquent la fragilité, le dialogue de gestion tendu, la masse salariale qui dérape. L’idée sous-jacente : un directeur ne demande pas “analysez mes signaux de tension”. Il dit “regardez mon ERRD” ou “j’ai un problème de recrutement”. C’est le système qui doit voir ce que lui ne voit pas encore.

Ce que j’essaie de formuler ici, c’est peut-être ceci : dans un RAG sectoriel, l’expertise du praticien n’est pas un input. Elle est une couche architecturale.

Les sources sont reproductibles. Le CASF, la jurisprudence JADE, les CCN — n’importe qui peut les ingérer. Un retrieval bien calibré est une question de temps et de méthode. Mais la couche qui donne au système sa capacité à lire entre les lignes, à contextualiser une réponse dans les pratiques réelles du secteur, à percevoir ce qu’un établissement cache dans ses chiffres — cette couche-là ne s’achète pas et ne se copie pas. Elle s’accumule.

Le praticien qui construit un RAG dans son domaine a une ressource que les généralistes n’ont pas : il sait ce que les textes ne disent pas. La question est de savoir s’il la met dans la machine.

Patrick Danto

Co-fondateur de ConfiensIA, société de R&D pour l’IA de secteur social et médico-social

Subscribe now

Il y a une conviction qui traverse tout ce que je fais chez ConfidensIA : on ne traite bien une matière qu’en sachant ce qu’on a entre les mains.

Je viens du secteur social et médico-social — douze ans à le pratiquer de l’intérieur, à lire des ERRD, à négocier des CPOM, à comprendre pourquoi certaines organisations tiennent et d’autres décrochent. Puis une bifurcation vers l’ingénierie des données et l’IA, pas pour quitter ce terrain mais pour y revenir autrement.

ConfidensIA est né de ce croisement. Trois programmes — REPÈRES, un RAG sectoriel pour les professionnels ESSMS ; Data ESSMS, de l’ingénierie de la donnée pour rendre lisibles les leviers économiques du secteur ; LaPlume, un pipeline de pseudonymisation pour protéger les données sensibles sans appauvrir les récits. Ce que ces trois chantiers ont en commun : ils travaillent une matière déjà présente dans les organisations, sans la trahir.

Ce Substack est l’endroit où je documente ce travail — pas en mode communication, mais en mode carnet de bord. Les choix d’architecture qui ont de la conséquence. Les problèmes que la technique seule ne résout pas. Ce qu’on apprend quand on construit des outils pour un secteur qu’on connaît vraiment.

Le premier article, publié hier, porte sur quelque chose que j’avais du mal à formuler jusqu’ici : pourquoi la couche éditoriale d’un RAG — la lecture du praticien encodée dans le système — est une décision d’architecture autant qu’une décision de contenu. Ce sera le registre de ce qui suit.

Je n’ai pas de cadence fixe. J’écris quand quelque chose mérite d’être écrit. Probablement une fois par mois, parfois plus.

Si vous travaillez dans le secteur, si vous construisez des outils d’IA dans des domaines à forte densité réglementaire, ou si la question de ce qu’on met — vraiment — dans un système vous intéresse : vous êtes au bon endroit.