Faire évoluer DevLog sans casser ce qui fonctionne

RAG, MCP et découplage architectural autour d'une mémoire technique pour les agents de développement.

Dans mon précédent article, j'explorais une question qui commence à prendre une place importante dans le développement de DevLog :

jusqu'où une mémoire technique structurée peut-elle aider un workflow d'ingénierie à mieux comprendre les projets qu'il fait évoluer ?

Les premiers essais ont montré quelque chose d'intéressant.

DevLog est déjà capable de préparer une première carte du contexte d'un projet : structure du repository, historique Git, décisions d'architecture, connaissances validées ou encore fichiers potentiellement pertinents.

Mais cette carte reste imparfaite.

Certaines informations importantes ne sont pas encore connues, certaines sont mal classées et certaines catégories de preuves peuvent prendre trop de place.

J'avais résumé ces problèmes en trois mots :

COVERAGE
RELEVANCE
DIVERSITY

Depuis, la réflexion a continué.

Deux technologies sont progressivement apparues comme intéressantes pour la suite du projet :

RAG
→ mieux retrouver le contexte pertinent

MCP
→ rendre ce contexte accessible aux outils et agents

Mais leur introduction pose une question architecturale plus importante :

comment ajouter ces capacités sans transformer DevLog en un système fortement couplé où chaque nouvelle évolution oblige à reconstruire ce qui existe déjà ?

Le RAG n'est pas la prochaine feature

Lorsqu'un projet commence à accumuler beaucoup de connaissances, l'idée d'ajouter un système RAG arrive assez naturellement.

DevLog possède progressivement :

commits
diffs
ADRs
Engineering Stories
historique projet
connaissances validées
projections
relations entre éléments

Une recherche uniquement structurée finira probablement par montrer ses limites.

Une recherche sémantique pourrait permettre de retrouver des informations conceptuellement proches même lorsqu'elles n'utilisent pas exactement les mêmes termes.

Mais ajouter immédiatement :

embeddings
+
vector database
+
LLM
=
RAG

serait probablement une erreur.

Le problème actuel de DevLog n'est pas simplement de rechercher dans davantage de données.

Il faut d'abord améliorer ce que DevLog connaît réellement du projet.

Le premier travail reste donc l'enrichissement et la projection.

Repository
    ↓
Ingestion
    ↓
Enrichment
    ↓
Trusted Knowledge
    ↓
Projections

Ces projections doivent progressivement représenter des informations utiles comme :

commit
  ↓
modifie
  ↓
fichier
  ↓
concerne
  ↓
Engineering Story
  ↓
contrainte par
  ↓
ADR

Une fois cette base suffisamment riche, un Retrieval Layer pourra être introduit au-dessus.

Trusted Knowledge
      +
Projections
      ↓
Retrieval Layer
      ↓
structured search
lexical search
semantic search
temporal search
relationship expansion
      ↓
ContextPackage

Le RAG devient alors une technique de récupération supplémentaire.

Il ne devient pas la mémoire du projet.

La base vectorielle ne doit pas devenir la source de vérité

Cette distinction me semble particulièrement importante.

Une future base vectorielle devra rester une projection technique reconstruisible.

Repository / Knowledge
        ↓
   Enrichment
        ↓
   Projections
        ↓
 Vector Index

et jamais :

Vector Database
      =
Project Knowledge

Cela permet de modifier plus tard :

le modèle d’embedding
la base vectorielle
la stratégie de chunking
le reranking
la stratégie de retrieval

sans modifier la connaissance métier de DevLog.

Le Retrieval Layer peut évoluer.

La mémoire du projet reste indépendante.

Un autre problème est apparu pendant le développement

Pendant cette réflexion autour du RAG, un problème beaucoup plus concret est apparu dans notre workflow.

Une partie du travail était orchestrée par Kiko.

Lorsque Kiko devenait temporairement indisponible --- par exemple à cause d'une limite de provider ou de tokens --- il fallait continuer directement avec un autre agent comme OpenCode.

Techniquement, OpenCode avait accès au repository.

Mais une partie importante du contexte devait être reconstruite manuellement.

Kiko
  ↓
contexte accumulé
  ↓
indisponible

OpenCode
  ↓
repository disponible
  ↓
contexte projet incomplet

Il fallait alors expliquer à nouveau :

l’objectif de la tâche
les décisions précédentes
les contraintes d’architecture
l’historique pertinent
les éléments déjà analysés

Le problème n'était finalement pas OpenCode.

Le problème était que le contexte nécessaire pour poursuivre le travail dépendait encore trop du consommateur qui l'avait construit.

Cela nous a conduit à formuler un nouveau principe :

Engineering context must belong to the project, not to the agent currently consuming it.

MCP comme frontière

C'est ici que MCP devient intéressant.

L'idée n'est pas de construire un serveur MCP simplement parce que le protocole est populaire.

L'objectif est de créer une frontière standardisée entre DevLog et les outils qui souhaitent utiliser sa mémoire technique.

                    DevLog
                       ↓
               Project Memory
                       ↓
                Context Engine
                       ↓
                     MCP
                       ↓
          ┌────────────┼────────────┐
          ↓            ↓            ↓
        Kiko       OpenCode       IDE Agent

Kiko devient alors un consommateur parmi d'autres.

OpenCode également.

Et demain cela pourrait être :

un plugin IDE
un agent de code review
un agent de documentation
un workflow Developer OS
un autre coding agent

DevLog ne doit pas savoir lequel utilise son contexte.

MCP ne doit pas devenir DevLog

Là encore, le découplage est essentiel.

Le serveur MCP ne doit contenir ni la logique métier de DevLog ni sa propre représentation de la connaissance.

Son rôle doit rester celui d'un adapter.

MCP Client
    ↓
MCP Adapter
    ↓
DevLog Application
    ↓
Context / Knowledge / Projections

et surtout pas :

MCP
 ↓
Database

ou :

MCP
 ↓
nouvelle logique de recherche indépendante

Si MCP disparaissait demain, DevLog devrait continuer à fonctionner.

Si MCP était remplacé par un autre protocole, la logique métier ne devrait pas être réécrite.

Commencer volontairement petit

Nous avons donc décidé de ne pas commencer directement par :

get_engineering_context()

connecté à toutes les connaissances DevLog.

Le premier prototype est volontairement beaucoup plus simple.

Spring Boot
    ↓
Spring AI MCP
    ↓
STDIO
    ↓
devlog://server/info

La première Resource retourne simplement :

{
  "name": "devlog-mcp",
  "version": "0.1.0",
  "status": "ready"
}

Avec MCP Inspector, nous avons pu vérifier toute la chaîne :

MCP Client
    ↓
resources/list
    ↓
devlog://server/info
    ↓
resources/read
    ↓
DevLog MCP Server

Ce n'est évidemment pas encore une fonctionnalité utile.

Mais c'est précisément l'objectif.

Avant de connecter DevLog, nous voulons comprendre le protocole et valider chaque frontière indépendamment.

Faire évoluer l'intérieur sans modifier l'extérieur

C'est probablement la partie de cette expérimentation qui m'intéresse le plus.

Aujourd'hui, une future capacité pourrait fonctionner ainsi :

Agent
  ↓
get_engineering_context
  ↓
DevLog Application
  ↓
Projections déterministes

Plus tard :

Agent
  ↓
get_engineering_context
  ↓
DevLog Application
  ↓
Retrieval Layer
  ↓
Hybrid Retrieval
  ↓
ContextPackage

Du point de vue de l'agent :

get_engineering_context

n'a pas nécessairement changé.

L'intérieur de DevLog, lui, a considérablement évolué.

C'est exactement ce que nous recherchons avec le découplage.

RAG et MCP ne résolvent pas le même problème

Les deux technologies peuvent facilement être mélangées lorsqu'on parle d'agents et de contexte.

Je préfère les considérer comme deux responsabilités différentes.

RAG / Retrieval
      ↓
Quel contexte est pertinent ?

MCP
      ↓
Comment un consommateur externe
accède-t-il à cette capacité ?

Et DevLog reste entre les deux.

Project Knowledge
       ↓
Retrieval
       ↓
ContextPackage
       ↓
MCP
       ↓
Agent

Cette séparation permet également d'introduire les technologies progressivement.

Nous pouvons travailler sur MCP aujourd'hui sans disposer du RAG.

Nous pouvons améliorer les projections sans MCP.

Nous pourrons expérimenter plusieurs stratégies de retrieval sans modifier les consommateurs.

Le découplage comme moyen d'expérimenter

Au début du projet, découper les responsabilités peut parfois sembler produire davantage de code.

Il faut définir des contrats.

Créer des adapters.

Éviter les accès directs.

Résister à la tentation de placer une logique là où elle est simplement pratique à court terme.

Mais cette expérimentation commence à montrer l'autre côté de cette approche.

Parce que DevLog distingue progressivement :

Knowledge
Enrichment
Projection
Retrieval
Integration
Agent reasoning

nous pouvons faire évoluer chacune de ces responsabilités indépendamment.

Le futur RAG ne nécessite pas de reconstruire DevLog.

MCP ne nécessite pas de déplacer la connaissance dans un nouveau service.

Un nouvel agent ne nécessite pas une nouvelle représentation du projet.

Et un changement de provider ne devrait progressivement plus signifier une perte du contexte d'ingénierie.

Une architecture qui doit rester remplaçable

Je commence à utiliser un critère assez simple lorsque nous introduisons une nouvelle technologie dans DevLog :

Que se passe-t-il si nous décidons de la remplacer dans six mois ?

Si remplacer la technologie implique de réécrire le domaine, le découplage est probablement insuffisant.

Pour le RAG :

Vector Store A
      ↓
Vector Store B

DevLog Knowledge
      =
inchangé

Pour MCP :

MCP
 ↓
autre integration adapter

DevLog Application
      =
inchangé

Pour les agents :

Kiko
 ↓
OpenCode
 ↓
autre agent

Engineering Context
      =
inchangé

Ce n'est évidemment jamais totalement gratuit.

Mais l'objectif est que les décisions techniques périphériques restent remplaçables sans remettre en cause la connaissance et les règles du projet.

Et maintenant ?

Le travail MCP vient seulement de commencer.

La première Resource fonctionne et le protocole a été validé avec un vrai client.

Les prochaines étapes seront volontairement progressives :

première Resource
      ↓
premier Tool
      ↓
première capability DevLog
      ↓
contexte projet réel
      ↓
connexion depuis l’IDE

En parallèle, DevLog continuera à améliorer son enrichissement et ses projections.

Le Retrieval Layer viendra ensuite, lorsque ces informations seront suffisamment riches pour justifier une recherche hybride.

Puis MCP pourra exposer progressivement cette capacité aux différents consommateurs.

La trajectoire commence donc à ressembler à ceci :

Repository
    ↓
Enrichment
    ↓
Project Knowledge
    ↓
Projections
    ↓
Retrieval Layer
    ↓
ContextPackage
    ↓
MCP
    ↓
┌─────────┬──────────┬───────────┐
│         │          │           │
Human    Kiko     OpenCode   Future Agent

Je ne sais pas encore jusqu'où cette architecture évoluera.

Mais cette phase du projet renforce une idée qui devient progressivement centrale dans DevLog :

la valeur ne vient peut-être pas seulement de la quantité de contexte qu'un système peut accumuler, mais de sa capacité à structurer cette connaissance de manière suffisamment indépendante pour qu'elle puisse évoluer, être recherchée et être consommée sans dépendre d'un modèle, d'un agent ou d'une technologie particulière.