Un cœur, trois surfaces

Telaria exploite sa base documentaire par l'IA selon trois usages : un serveur MCP pour les clients agentiques, un chatbot documentaire, et une veille technique validée par IA. Ces trois usages partagent une même règle de conception : ils ne réimplémentent pas la logique IA, ils consomment un seul cœur.

Cette pièce explique pourquoi ce design a été retenu, quels arbitrages il porte, et ce qu'il fait gagner. Elle ne décrit pas les composants dans le détail : pour cela, voir les fiches de référence du moteur RAG, du serveur MCP et du bundle produit doc-IA.

Le problème que ce design résout

Trois usages ont en commun une même mécanique : transformer une base de documents Markdown en connaissance interrogeable, puis restituer les passages pertinents avec leur provenance. Le chatbot en a besoin pour répondre en citant ses sources ; le serveur MCP en a besoin pour offrir un outil de recherche à un agent externe ; la veille en a besoin pour dédupliquer et classer ce qu'elle collecte.

La tentation naïve serait de traiter ces trois usages comme trois projets séparés, chacun avec son ingestion, son découpage, ses embeddings et son index. Ce serait trois fois la même logique — donc trois fois la maintenance, trois occasions de diverger, et trois surfaces à durcir indépendamment.

Le choix retenu est l'inverse : un cœur, trois surfaces. La mécanique commune est isolée une fois ; les trois usages ne sont que des façons différentes de la solliciter.

Ce qu'est le cœur, ce que sont les surfaces

Le cœur : la mécanique RAG, sans opinion sur l'usage

Le cœur est un composant headless : il n'a ni interface, ni idée de qui l'appelle. Il fait une seule chose — le volet retrieval d'une chaîne RAG : ingérer du Markdown, le découper en fragments porteurs de leur provenance (fichier, section, ancre, position), les vectoriser, et répondre à une requête par les passages les plus proches sémantiquement, chacun scoré et sourcé.

Deux propriétés le rendent réutilisable :

• Il ne génère pas de texte. La génération par un modèle de langage vit dans les surfaces qui en ont besoin, pas dans le cœur. Le cœur retrouve ; il n'invente pas.
• Il est substituable par contrat. Découpage, embeddings et stockage vectoriel sont derrière des interfaces : on peut remplacer l'un sans toucher aux autres, ni aux surfaces. Voir la fiche moteur RAG.

Ce périmètre volontairement étroit est ce qui autorise la mutualisation : un composant qui ne prend pas position sur son usage peut servir tous les usages.

Les trois surfaces : trois manières de solliciter le même cœur

• Surface MCP — expose la documentation comme des outils invocables par un client agentique (assistant de bureau, IDE, CLI) via le protocole Model Context Protocol. Son outil de recherche délègue au retrieval du cœur ; il y ajoute ce qui lui est propre : authentification, périmètres d'accès, quotas, journal d'audit. Voir la fiche serveur MCP.
• Surface chatbot — pose une question en langage naturel, récupère les passages via le cœur, puis assemble un prompt et fait générer une réponse sourcée par un modèle. Un garde-fou notable : si le cœur ne renvoie rien de suffisamment proche, la surface répond « information absente de la documentation » sans même appeler le modèle — anti-hallucination et économie.
• Surface veille — un pipeline planifié collecte des sources externes, s'appuie sur la même logique de fragments et de similarité pour dédupliquer et classer, et produit des propositions résumées, à valider par un humain.

Les deux dernières vivent dans le bundle produit doc-IA ; la première dans le serveur MCP. Toutes s'adossent au même cœur.

Pourquoi ce design plutôt que trois piles séparées

Un seul endroit à faire évoluer

La qualité d'un système RAG se joue sur des détails : taille des fragments, chevauchement, modèle d'embeddings, métrique de similarité. Améliorer l'un de ces réglages dans un cœur mutualisé, c'est l'améliorer pour les trois surfaces en une fois. Avec trois piles séparées, la même amélioration serait à refaire trois fois — ou, plus probablement, ne serait faite qu'à un endroit, et les trois usages divergeraient silencieusement.

Un seul endroit à durcir

C'est l'argument de sécurité, et il est décisif. Les garde-fous sensibles — quels fichiers sont indexables, l'exclusion des zones privées, le refus de sortie hors du périmètre autorisé — sont d'autant plus fiables qu'ils vivent à un seul endroit. Le cœur applique ses filtres de gouvernance à l'ingestion (allowlist, exclusions dures non configurables) une fois pour toutes ; la surface MCP ajoute par-dessus son propre confinement d'accès. Concentrer la logique sensible réduit la surface d'audit : on vérifie une barrière, pas trois copies qui peuvent dériver.

Cohérence de comportement

Parce que les trois surfaces posent la même question au même moteur, elles voient le même corpus, la même notion de pertinence, la même provenance. Une réponse du chatbot et une recherche via MCP portant sur le même sujet s'appuient sur les mêmes passages. Cette cohérence n'est pas un effet secondaire heureux : c'est une conséquence directe du partage du cœur.

Réemploi au-delà de Telaria

Le cœur et les surfaces sont packagés comme des composants réutilisables, pensés pour être branchés sur plusieurs projets et non sur la seule vitrine. Le serveur MCP est d'ailleurs conçu multi-locataire dès l'origine : la mutualisation interne (un cœur pour trois usages) se prolonge en mutualisation externe (un même composant pour plusieurs projets).

Les arbitrages assumés

Un design se juge aussi à ce qu'il coûte. Ceux-ci ont été acceptés en connaissance de cause :

• Séparation génération / récupération. Garder la génération hors du cœur ajoute une frontière à traverser pour les surfaces qui génèrent (chatbot). Le bénéfice — un cœur neutre, réutilisable par des usages qui ne génèrent pas du tout (veille, recherche MCP) — a été jugé supérieur au léger surcoût d'indirection.
• Embeddings délégués à un service externe. Le cœur ne calcule pas lui-même les vecteurs : il appelle un service dédié via un contrat réseau. Cela introduit une dépendance externe, mais isole la partie coûteuse en calcul et permet de la faire évoluer sans toucher au cœur.
• Couplage au contrat, pas à l'implémentation. Chaque surface dépend d'interfaces du cœur, jamais de leurs détails internes. C'est ce qui rend l'ensemble maintenable — mais cela impose la discipline de garder ces contrats stables, ce qui est un engagement, pas une gratuité.

Aucun de ces arbitrages n'est neutre. Ce qui en fait de bons choix, c'est qu'ils vont tous dans le même sens : concentrer la complexité et la sensibilité dans un composant unique, et garder les surfaces fines.

En une phrase

La logique IA est difficile à faire bien et risquée à faire mal : on la met donc à un seul endroit, qu'on peut faire évoluer et durcir une fois pour toutes, et on la réexpose par des surfaces qui n'ont, chacune, qu'à savoir demander.

Pour aller plus loin

• Moteur RAG — référence — le cœur : pipeline, contrats, formats de données.
• Serveur MCP — référence — la surface agentique : outils, périmètres, quotas, audit.
• Bundle produit doc-IA — référence — les surfaces chatbot et veille.