Comprendre la technologie

REPERES combine une doctrine structurée et une bibliothèque documentaire.

La doctrine aide à déterminer quoi chercher, quelles relations examiner, quelles nuances conserver et quels points de vigilance ne pas oublier. La bibliothèque permet de revenir aux textes, décisions, recommandations, rapports et autres documents sur lesquels une réponse peut s'appuyer.

Une réponse utile nécessite les deux : une accumulation de documents ne fournit pas, à elle seule, une méthode pour les mobiliser.

Toutes les sources n'ont pas la même autorité. Un article de code en vigueur, une circulaire datée, une décision de justice et une recommandation ne se lisent pas de la même manière : REPERES conserve ce statut jusqu'à la réponse.

Chaque source citée dispose d'une fiche publique (éditeur, date, extrait, lien vers le document d'origine), accessible depuis la réponse.

Avant la recherche documentaire, REPERES qualifie la demande. Il identifie notamment le sujet, le secteur concerné, l'intention, le niveau de profondeur nécessaire et les risques associés à une mauvaise réponse.

Cette étape ne répond pas à la question. Elle décide de la manière dont le système doit travailler.

Une question n'est pas recherchée d'une seule manière.

REPERES combine une recherche sémantique, capable de retrouver des passages qui parlent de la même idée avec des mots différents, et une recherche lexicale, utile pour les formulations exactes, les références, les sigles ou les articles.

Les deux listes sont fusionnées. Les passages sont ensuite reclassés pour distinguer ce qui ressemble à la question de ce qui est réellement utile pour y répondre.

Les questions chiffrées sont traitées par un moteur distinct de la recherche documentaire, en parallèle de celle-ci. Le modèle de langage ne produit aucun chiffre : les valeurs viennent d'une base de données publiques, avec leur source, leur édition, leur définition et leurs réserves.

Une valeur non publiée est présentée comme absente, jamais comme zéro, avec d'autres repères identifiés comme tels. Une évolution demandée sans période porte sur les cinq dernières années publiées ; une borne hors des données est ramenée à la donnée disponible, et la réponse le dit. Chaque territoire est situé par rapport à un groupe de départements comparables et à la France.

La recherche documentaire ne suffit pas. REPERES construit ensuite un paquet de contexte propre à la question : doctrine utile, relations entre thèmes, éventuels contrepoints, actualité pertinente, passages documentaires, résultats statistiques et informations fournies par l'utilisateur.

Le modèle de génération ne reçoit donc ni toute la bibliothèque ni toute la doctrine. Il reçoit ce qui a été sélectionné pour la situation traitée.

Tout ce qui se trouve dans le contexte n'a pas le même statut.

REPERES demande au modèle de partir de la doctrine professionnelle sélectionnée, d'appuyer les affirmations sur les sources documentaires lorsqu'elles existent et de n'utiliser des connaissances générales qu'en dernier recours. Cette hiérarchie aide à distinguer ce qui vient du corpus de ce qui vient du modèle.

Lorsqu'une base documentaire ne permet pas de soutenir suffisamment une conclusion, la réponse doit pouvoir signaler cette limite.

1. 1. Doctrine REPERES
2. 2. Sources documentaires
3. 3. Connaissance générale, en dernier recours et avec prudence

Le moteur principal de REPERES est écrit en Rust. Ce choix privilégie la prévisibilité des performances, la maîtrise de la mémoire, la sûreté d'exécution et la capacité à faire fonctionner dans un même service la recherche, l'orchestration et le streaming.

Les opérations d'administration, d'ingestion ou d'actualisation peuvent utiliser d'autres langages. Elles sont séparées du runtime exposé aux utilisateurs.

REPERES peut produire lui-même une réponse ou fournir seulement le contexte nécessaire à un autre outil.

Dans le second cas, un assistant compatible — Claude, ChatGPT, Microsoft Copilot, Mistral Vibe, un agent métier ou une IA exécutée localement — peut utiliser la connaissance sélectionnée par REPERES tout en conservant sa propre interface et ses propres capacités.

La disponibilité de MCP dépend du client, de son offre et, le cas échéant, des politiques de l'administrateur de l'organisation.

Lorsqu'un utilisateur joint un document, REPERES extrait le texte nécessaire au traitement et l'ajoute au contexte de la demande. Si le document ne contient pas de texte directement exploitable, une étape d'OCR peut être mobilisée.

REPERES ne constitue pas une base réutilisable des conversations. Les questions, réponses et pièces jointes ne sont pas persistées dans un historique serveur que le service pourrait rappeler spontanément lors d'un échange futur.

La mémoire d'une conversation utilisée dans l'application est gérée côté client et retransmise lorsque le tour courant en a besoin. Des événements techniques ou d'audit sans contenu peuvent être conservés pour faire fonctionner, sécuriser et superviser le service.

Lorsque la protection des données identifiantes est activée, une couche de pseudonymisation intervient avant l'appel au moteur. L'utilisateur peut contrôler le résultat avant de poursuivre. Cette protection réduit l'exposition ; elle ne vaut pas automatiquement anonymisation juridique.

Le cœur applicatif de REPERES est hébergé en France sur Scaleway. Les dépendances externes sont limitées à des fonctions identifiées et choisies pour un rôle précis.

La doctrine de REPERES est versionnée afin de conserver la trace de son état dans le temps. La version actuellement utilisée constitue la première version de référence.

Chaque nouvelle version pourra être datée, comparée et reconstruite. Les mécanismes d'actualisation sont séparés du runtime public : la production ne réécrit pas spontanément sa propre doctrine.

Des outils internes permettent déjà de préparer et d'appliquer des actualisations. Ils pourront être adaptés pour les projets de personnalisation, sans que leur fonctionnement interne soit publié.

REPERES ne propose pas encore de corpus organisationnels dans le service public actuel. L'architecture cible des projets personnalisés prévoit une isolation logique stricte entre organisations.

Selon les exigences de sécurité, de gouvernance ou d'intégration, un projet pourra également être étudié dans un environnement dédié ou sous une forme auto-hébergée.

• aucun corpus d'une organisation ne doit être visible par une autre ;
• aucun document organisationnel ne rejoint le corpus commun sans processus explicite ;
• les droits d'accès doivent suivre les périmètres définis par l'organisation ;
• les options dédiée et auto-hébergée ne constituent pas encore des offres standard en libre-service.

REPERES évalue séparément la recherche, l'exploitation des sources, la qualité de génération, la gestion de l'incertitude et la robustesse sur des conversations complexes. Le moteur statistique dispose de sa propre recette : valeurs relues à la main contre les sources, questions de référence rejouées à chaque mise en production.

Les scénarios doivent inclure des questions centrales, des demandes transversales et des situations situées en bordure du corpus. Une bonne réponse n'est pas seulement complète : elle doit aussi savoir suspendre une conclusion lorsque les sources ne permettent pas de trancher.

Les limites à présenter clairement sont :

• une source peut être absente, ancienne ou ambiguë ;
• le corpus de jurisprudence est sélectif : l'absence d'une décision ne prouve pas l'absence de jurisprudence ;
• les statistiques sont publiques et agrégées ; certaines ne sont publiées que pour la France entière ou à une date ancienne ;
• le retrieval peut retenir un passage secondaire ou manquer un document ;
• un modèle peut mal interpréter un contexte pourtant pertinent ;
• une réponse générée reste une production probabiliste ;
• une décision professionnelle, juridique ou institutionnelle exige parfois une expertise complémentaire.