Un moteur de connaissances Web vers MCP : registres de sources, deux critiques et intégration de la vie privée

Les chercheurs qui suivent la littérature scientifique, les patients qui associent les nouveaux études à leurs propres dossiers, ainsi que les coordonnateurs de l’aide aux personnes handicapées ou les soignants qui surveillent l’évolution rapide des politiques ont une tâche quotidienne en commun : ils doivent savoir ce qui a changé, quand cela a changé et qui l’a déclaré. Ils préféreraient ne pas devoir parcourir Internet chaque matin pour obtenir ces informations. Les outils couramment utilisés s’avèrent insuffisants. Les alertes par mot-clé traitent un blog d’un fournisseur et une modification légale officielle de la même manière, ne retiennent rien au-delà du contenu de leur boîte de réception et ne peuvent pas accéder aux dossiers privés. Les chatbots dotés de fonction de recherche résument simplement ce qui était en tête des résultats ce matin-là, s’appuient sur la hiérarchie obsolète intégrée dans leurs données d’entraînement, oublient les documents de la veille et omettent parfois ou inventent des dates et des faits.

L’une des solutions proposées est un système que les praticiens appellent « horizon scan ». Il fonctionne comme une base de connaissances constituée à partir du Web, un bulletin quotidien, ainsi qu’un serveur consultable utilisant le Model Context Protocol (MCP). Il ne collecte que des informations provenant de sources fiables et vérifiées par des humains, respecte les abonnements et licences en vigueur, et conserve un stock qui s’agrandit à chaque exécution programmée. Lorsque les preuves pour une journée donnée sont insuffisantes, un critique peut décider de ne rien publier, ne laissant qu’un enregistrement expliquant les raisons. Ce stock survit à toute édition spécifique et peut être consulté à tout moment sous un angle choisi, en comparaison avec les données personnelles de l’utilisateur, toujours derrière une barrière de confidentialité locale. Le contexte de l’utilisateur participe à la discussion, mais n’est jamais stocké dans ce système. Étant donné que les détails personnels, cliniques et relatifs aux cas ne y entrent jamais, cette organisation est conforme à la loi australienne sur la protection de la vie privée de 1988 (Cth), tandis que le stock public reste accessible à tous les professionnels du domaine.

La première version met à jour les règles et les prix du National Disability Insurance Scheme (NDIS) en Australie, un système dans lequel une date de début incorrecte ou un plafond de prix peut nuire aux personnes concernées. Un planificateur déclenche l’action à 06:00, heure de Sydney. Le service éditorial publie ou retient le rapport d’information et enregistre une raison explicite dans un registre de déploiement à chaque fois, tandis que la base de données continue de s’agrandir indépendamment. Le rapport est envoyé dans un canal Slack, où les utilisateurs peuvent consulter la base de connaissances en taguant Claude, ce qui déclenche l’appel au serveur MCP. Par exemple, le rapport d’une semaine indiquait que les données des participants auraient pu atteindre la plateforme d’analyse de Palantir, aux côtés d’une décision de la Fair Work Commission concernant un licenciement pour violation du Code de conduite NDIS.

Les dates et les liens de chaque édition sont tirés de données stockées, et toute citation doit correspondre à un passage conservé par le système. Ce registre est basé sur NDIS, mais en modifiant les lignes, on peut utiliser le même mécanisme pour suivre un domaine de recherche, une condition de santé ou un organisme réglementaire.

Collecte pilotée par un registre de sources

La collecte est dirigée par un registre de sources, qui est une table de configuration des points d’accès surveillés, et non par ce que les moteurs de recherche classent en premier. Chaque ligne décrit une source selon un schéma fixe : nom de l’éditeur, méthode d’accès, fréquence des vérifications, niveau d’autorité, contraintes de réutilisation, conditions et règles de licence pour l’extraction des dates.

Il existe quatre niveaux d’autorité :

• T1 couvre les registres principaux d’un domaine, tels que la législation, les flux de décisions officielles ou les index de citations.
• T2 couvre les organismes gouvernementaux officiels et les régulateurs.

T3 concerne les organismes de référence et les associations professionnelles.

T4 concerne les médias fiables et les commentaires.

Chaque ligne comporte également l’une de trois contraintes de réutilisation afin que les conditions établies par l’éditeur soient respectées :

• REUSE_OK signifie que le texte intégral peut être stocké car une licence ouverte l’autorise.
• LINK_SUMMARISE_ONLY signifie qu’un hyperlien et un bref extrait seulement sont conservés.
• NO_BULK supprime l’élément de la récupération automatisée et le soumet à une révision manuelle.

Les lignes enregistrent également des informations obtenues sur le site hôte, telles que les délais de balayage à respecter ou une limite pour les pages centrales, par exemple moins de trois articles datés. Sans ces notes, une ligne n’est qu’un signet statique que le collecteur ne peut pas utiliser en toute sécurité.

Même structure de registre est appliquée aux autres champs :

• Pour la recherche scientifique, les lignes T1 renvoient à des index de citations tels que MEDLINE, Crossref et OpenAlex, associés à des dépôts de textes intégraux en accès libre ainsi qu’à des flux de revues configurés pour ne conserver que des résumés ou des liens.
• Pour la gestion de sa santé personnelle, ces lignes indiquent les directives officielles de pratique pour une maladie donnée, ainsi que les informations sur les produits médicaux fournies par l’autorité de régulation, en plus de flux cliniques vérifiés.
• Pour suivre les questions juridiques et les procès, la ligne principale T1 suit le flux officiel des jugements du tribunal.

Une voie de recherche dynamique complète la liste fixe afin que la base ne devienne pas obsolète. Chaque matin, elle effectue un petit nombre de recherches ciblées sur une liste secondaire d’origines, limitées par un plafond de mots, un nombre restreint d’essais de récupération par source et un budget total de pages par exécution. Afin d’assurer la précision temporelle, toute page sans date de publication vérifiable, ou présentant une date future, est automatiquement éliminée. Les consultations ouvertes avec date de clôture constituent l’unique exception : elles sont mises sur une liste de suivi, récupérées chaque jour et marquées comme des problèmes en cours. Les pages provenant d’hébergeurs non figurant sur la liste reçoivent un niveau d’autorité faible, de sorte que les commentaires extérieurs sont identifiés tels qu’ils sont.

Lecture directe des registres de premier niveau

Chaque domaine dispose d’une source principale qui a la priorité sur les autres, qu’il s’agisse d’un registre législatif, d’un index de citations primaires ou d’une source judiciaire. Le collecteur lit ces sources via des API structurées. Par exemple, le pipeline NDIS obtient la législation primaire à partir de l’API OData du Federal Register of Legislation. Il préfère les fichiers EPUB structurés aux PDF et effectue une vérification quotidienne des modifications par rapport à un curseur persistant afin d’identifier ce qui est nouveau. Les textes législatifs longs sont divisés en blocs de 60 000 caractères et extraits progressivement pour ne pas dépasser les limites du modèle.

Des identifiants explicites permettent de distinguer une véritable modification légale d’un simple réindexage de routine :

• Les textes législatifs nouvellement adoptés sont des lois promulguées récemment par le Parlement, et ils déclenchent des notifications de modification actives.

Les compilations sont des textes principaux consolidés contenant les amendements antérieurs intégrés. Le planificateur d’ingestion les marque comme références en arrière-plan, de sorte que la réindexation régulière ne génère jamais d’alertes fausses de modification.

Ingestion indépendante de la publication

Les artefacts bruts sont hachés avec SHA-256 et enregistrés dans Postgres avant tout début de synthèse, de sorte que la base de données s’agrandit à chaque exécution, qu’une édition soit publiée ou non. L’état de publication est déterminé de manière fiable grâce à une contrainte UNIQUE(briefing_date, channel) qui stocke le chargement serialisé ainsi que son hash JSON. Si une exécution échoue ou si la livraison vers le canal se bloque, la prochaine exécution retrouve la réservation en attente et publie le chargement figé à sa place, sans écrire de nouveau texte.

Trois types d’exécutions laissent des traces différentes :

• Lors d’une matinée calme sans nouveaux faits, les documents sont marqués comme ayant été évalués en une seule transaction avant d’être retirés.
• Lors d’une matinée de retrait, où un critique rejette le projet, aucune ligne d’évaluation n’est écrite et les documents sont renvoyés dans la file de la matinée suivante.
• Lors d’une matinée de publication, les documents cités sont marqués comme traités et retirés.

Le fait de conserver les données initiales assure une traçabilité temporelle stricte. Une question posée en mars sur ce qui était connu en janvier est répondue uniquement à partir des informations conservées en janvier, sans être affectées par les modifications ultérieures sur le site en ligne.

Le bureau de rédaction

Afin d’éviter les hallucinations, la rédaction suit une règle stricte : le modèle ne traite jamais directement des faits vérifiés.

Le code supprime toutes les dates littérales et les URL d’un dossier de preuves avant qu’il n’atteigne la personne chargée de sa rédaction. Les vérifications de motifs déterministes rejettent tout projet prétendant à un statut juridique ou opérationnel, tel que en vigueur ou commencé. Les dates vérifiées ne sont affichées qu’après l’acceptation d’un projet, réinsérées à partir des champs de la base de données afin que leur provenance reste présente dans le texte. Cette règle est utile dans tous les domaines mentionnés : les tailles d’échantillons, les estimations d’effet et les doses de médicaments restent liés aux enregistrements de la base de données et hors de la mémoire paramétrique du modèle.

Le service suit un flux de travail déterministe en plusieurs étapes :

1. Planification et exclusion. Un planificateur attribue chaque document à une affaire ou note une raison explicite pour l’exclure, telle qu’un document dupliqué, irrelevant ou insuffisant.

Rédaction et validation. Le rédacteur compose un texte concis, limité à moins de 400 mots, avec une limite stricte concernant les extraits cités. Un validateur déterministe vérifie chaque citation avant que tout lecteur ne puisse en prendre connaissance.

Examen par deux critiques. Le premier critique peut approuver, rejeter ou demander une seule révision ciblée. Un deuxième critique, agissant de manière indépendante sans conserver d’historique, examine ensuite le texte, se concentrant uniquement sur les questions de date ou d’état non résolues. Un rejet de la part de l’un ou de l’autre entraîne le report de la publication.

Présentation avec information sur l’origine. Avant toute publication, le responsable de la mise en forme récupère les dates vérifiées ainsi que les liens correspondants depuis le stockage et les intégre dans le texte.

Les schémas JSON, les validateurs déterministes, deux outils de critique et un outil d’affichage définissent ce contrat. Le texte public peut être traité à l’aide d’inférences hébergées n’importe où, mais les bases de données contenant des informations médicales privées ou des recherches non publiées doivent effectuer ces inférences en interne, au sein de leurs propres limites territoriales.

Interrogation via MCP et intégration de contextes privés par session

Un serveur en lecture seule implémentant le Model Context Protocol expose la base de données persistante à travers trois outils : search_knowledge_base, get_document et list_changes. Afin de garantir l’intégrité factuelle, les extraits générés du côté serveur doivent se terminer aux limites des mots. Un passage interrompu au milieu d’un mot incite un modèle génératif à compléter le texte manquant de manière plausible au niveau de la présentation, un risque inacceptable dans le cas des doses médicamenteuses ou des limites légales.

Les preuves publiques sont identiques pour tous dans un domaine donné, mais chaque utilisateur dispose de son propre contexte privé. Une équipe chargée du respect des réglementations souhaite que de nouvelles règles soient évaluées au regard de la politique interne, tandis qu’un clinicien veut que des recherches mises à jour soient analysées en fonction de l’historique d’un patient spécifique. Mélanger des preuves publiques et des données locales sensibles dans une seule base de données créerait de graves problèmes en matière de traçabilité des données et de protection de la vie privée.

L’architecture sépare donc le stockage public du contexte privé. Les données personnelles et cliniques sensibles restent dans des environnements locaux authentifiés, derrière une frontière de confiance stricte. Les faits publics vérifiés sont fournis sur demande depuis le serveur MCP en lecture seule, et l’assistant les combine avec les données locales uniquement au cours de la session en cours de l’utilisateur. Le contexte privé ne pénètre jamais dans le stockage partagé, ce qui permet à la base de données publique d’être partagée entre de nombreux utilisateurs.

Pourquoi la recherche ouverte et le récupération simple ne suffisent pas

Diriger un agent autonome directement vers une recherche sur le web ouvert, ou vers un connecteur RAG standard, ne répond pas aux exigences de fiabilité nécessaires dans des domaines à haut risque. La recherche en temps réel ignore les contraintes de réutilisation imposées par les éditeurs, ne conserve aucune trace hachée de l’origine des données que un auditeur pourrait examiner, et ne peut pas indiquer ce qui a changé depuis hier. Lorsqu’on lui pose des questions hors de son champ indexé, un assistant dépourvu de fondements a tendance à deviner ou à compléter des informations tronquées, et les erreurs se transmettent aux analyses ultérieures.

Cette même conception s’applique à plusieurs contextes :

• Dans le cadre du NDIS et du secteur des personnes handicapées plus large, les modifications législatives et tarifaires constituent le contexte des politiques publiques, tandis que les budgets des plans des participants et leurs dossiers médicaux ne correspondent à ce contexte qu’au cours d’une session en temps réel.

Dans la recherche scientifique, les index de citations primaires et les dépôts en accès ouvert suivent la littérature publiée, tandis que les résultats de laboratoire non publiés restent isolés.

Dans la gestion de la santé, les directives émises par des autorités cliniques ainsi que les données réglementaires relatives aux médicaments fournissent des preuves publiques vérifiées, tandis que les dossiers diagnostiques et médicaux restent privés et locaux.

Dans le domaine du respect des lois et réglementations, les registres législatifs et les bases de données des jugements judiciaires établissent une référence publique, tandis que les manuels de politique interne restent protégés par une authentification locale.

Faire confiance à une modélisation linguistique non fondée pour assurer la précision factuelle relève du hasard. Un registre de sources structuré, une base de données persistante, un service éditorial composé de deux critiques ainsi qu’un serveur MCP en lecture seule sous-jacent à l’assistant transforment les mises à jour rapides du web en une base de connaissances fiable, respectueuse de la vie privée et autorisée.