Dans cette page

Documentation technique

Comprendre la technologie

Comment REPERES transforme une question en contexte, puis en réponse.

REPERES n'utilise pas un modèle de langage comme base de connaissances. Il construit, pour chaque demande, le contexte que le modèle doit utiliser.
Questionqualificationplan de contexterecherche hybridererankingassemblagegénérationsources

Depuis l'assemblage : contexte → MCP / API → Claude, ChatGPT, Microsoft Copilot, Mistral Vibe, agent métier ou IA locale

fonction actuellearchitecture cibleintégration externe
01

Deux plans de connaissance

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.

Doctrine REPERESBibliothèque documentaire
Contenunotions, raisonnements, relations, repères, vigilance et actualitétextes, jurisprudence, recommandations, rapports et documentation institutionnelle
Organisation actuelle16 contextes, 773 sous-thèmes5 892 documents, 76 131 passages indexés
Fonctionorienter le raisonnement et la rechercheretrouver les sources et les preuves
Mise à jourtravail professionnel et veille structuréeingestion, qualification et réindexation

Détail technique

La doctrine et le corpus documentaire restent séparés dans leur rôle. Le runtime sélectionne les éléments doctrinaux utiles et les passages documentaires pertinents, puis les réunit dans un contexte propre à la demande. Cette séparation évite de confondre une interprétation professionnelle avec une source primaire.

02

Comprendre avant de chercher

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.

Détail technique

La qualification produit une sortie structurée utilisée par l'orchestration. Elle distingue plusieurs familles d'intentions et de risques, avec un mécanisme de repli déterministe lorsque le modèle de qualification n'est pas disponible. La qualification actuelle utilise Mistral Small via l'API Mistral.

03

Une recherche hybride, puis un second classement

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.

Détail technique

La recherche vectorielle utilise des embeddings Qwen3-Embedding-8B en 1 536 dimensions, servis par les Generative APIs de Scaleway en France. Le stockage et la recherche reposent sur PostgreSQL et pgvector avec index HNSW. Les résultats vectoriels et lexicaux sont fusionnés par Reciprocal Rank Fusion, puis reclassés par un modèle de langage (Mistral Small) qui répartit les passages en cinq niveaux d'utilité.

sens de la question ────┐

mots et références ─────┼─ fusion RRF ─ reranking ─ passages retenus

04

Construire un contexte propre à chaque question

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 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.

Détail technique

Un planificateur de contexte sélectionne les sections utiles et leurs dépendances, coordonne les résultats documentaires et adapte la profondeur de traitement. Il applique également des règles de cohérence et des budgets de contexte. L'architecture distingue des niveaux logiques de traitement simples ou complexes, qui déterminent notamment le modèle de génération employé pour la réponse.

Le modèle ne connaît pas REPERES. REPERES construit ce qu'il doit connaître pour cette question.
05

Générer à partir d'une hiérarchie explicite

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.

Détail technique

La génération repose sur deux modèles selon la complexité estimée de la demande : Mistral Small pour les demandes simples, et GLM 5.2 — modèle tiers de Z.ai servi via l'API Mistral — pour les demandes complexes. Le modèle est traité comme une dépendance remplaçable : le corpus, la doctrine, la recherche et l'orchestration n'en dépendent pas structurellement. La réponse est diffusée progressivement vers le client par streaming.

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

Un runtime principal en Rust

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.

Détail technique

Le service s'appuie sur un runtime asynchrone Rust, avec Axum pour la couche HTTP, Tokio pour l'exécution asynchrone et un flux SSE pour la restitution progressive. Le cœur applicatif et ses bases sont hébergés sur l'infrastructure Scaleway en France.

07

Application, MCP et API

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.

ModeRecherche par REPERESContexte construit par REPERESGénération par REPERESTarification publique
Application REPERESouiouiouiselon l'accès à l'application
MCP connaissanceouiouinongratuit
MCP générationouiouioui2 € / mois / utilisateur
API personnaliséeconfigurableconfigurableconfigurablesur devis

Détail technique

MCP expose un mode de construction de contexte distinct du mode de génération. L'API permet des intégrations plus spécifiques. La page publique décrit les responsabilités de chaque mode, mais ne constitue pas une référence exhaustive des endpoints ou des schémas d'authentification.

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

08

Pièces jointes et OCR

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.

Détail technique

L'OCR actuel repose sur Mistral OCR lorsqu'il est nécessaire. Le document et son texte extrait sont utilisés pour le traitement demandé ; ils ne deviennent pas automatiquement des sources du corpus commun.

Une pièce jointe utilisée dans une conversation n'est pas ingérée silencieusement dans la bibliothèque REPERES.
09

Non-conservation et protection des données

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.

question / document → protection activée → contexte → services → réponse

hors flux de contenu : événements techniques et d'audit sans conversation

10

Hébergement et dépendances

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.

BriqueFournisseur / technologieFonctionStatut
Runtime, application et basesRust + Scaleway, Francecœur applicatif, orchestration, stockage et streamingactuel
IdentitéLogto OSS auto-hébergécomptes et authentificationactuel
QualificationMistral Small via Mistral AIanalyse structurée de la demandeactuel
GénérationMistral Small et GLM 5.2 via Mistral AIrédaction de la réponse selon la complexitéactuel
Recherche sémantiqueQwen3-Embedding-8B via Scaleway (France)embeddingsactuel
ReclassementMistral Small (reranking par modèle de langage)rerankingactuel
OCRMistral OCRextraction de texte lorsque nécessaireactuel
La souveraineté n'est pas présentée comme l'absence de toute dépendance. Elle repose ici sur la connaissance des dépendances, la maîtrise de leur rôle et la capacité à les remplacer.
11

Une doctrine versionnée et actualisée

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é.

Version de référencemodifications qualifiéesnouvelle version datée

Détail technique

Le versionnement porte sur les artefacts de doctrine et leur compilation. Il permet de rattacher un état de connaissance à une date et de séparer clairement l'édition de la connaissance de son usage en production.

12

Corpus organisationnels et architectures de déploiement

CIBLE — NON DISPONIBLE DANS LE SERVICE PUBLIC ACTUEL

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.

Option cibleDescriptionDisponibilité actuelle
Multi-tenant isoléservice partagé, corpus et droits séparés par organisationcible
Environnement dédiéressources réservées à un projet ou à une organisationétude au cas par cas
Auto-hébergédéploiement dans un environnement maîtrisé par le clientétude au cas par cas
  • 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.
13

Évaluation et limites connues

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.

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 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.