Donner une mémoire technique à mon workflow d’ingénierie

Une expérimentation autour de DevLog AI, OpenClaw et OpenCode.

Dans mon précédent article, je présentais une expérimentation autour d’OpenClaw et OpenCode avec une idée simple : utiliser l’intelligence artificielle au sein d’un workflow d’ingénierie structuré plutôt que comme un simple générateur de code.

Depuis, ce workflow a continué à évoluer.

Les Stories servent de point d’entrée au développement. Elles donnent naissance à une analyse du repository, un plan d’implémentation, une phase de développement, une revue de code et plusieurs étapes de validation humaine.

Mais son utilisation a également fait apparaître une nouvelle limite.

À chaque nouvelle Story, l’agent chargé de préparer l’analyse technique doit reconstruire une partie importante du contexte du projet.

Quels modules sont concernés ?

Quels fichiers semblent pertinents ?

Quels tests existent déjà ?

Quelles décisions d’architecture doivent être prises en compte ?

Quels changements récents ont touché cette partie du projet ?

Le workflow possède progressivement une mémoire documentaire grâce aux artefacts qu’il produit, mais l’agent doit encore redécouvrir une grande partie du contexte technique à chaque nouvelle évolution.

C’est le problème que j’ai commencé à explorer avec DevLog.

Préparer le contexte avant de raisonner

DevLog est progressivement devenu un système capable de construire un contexte technique à partir de différentes informations déjà présentes dans un projet.

Il peut aujourd’hui travailler notamment avec :

structure du repository
modules
fichiers source
tests
configuration
décisions d’architecture
historique Git
fichiers modifiés
connaissances déjà validées

L’idée qui m’intéresse n’est cependant pas de demander à DevLog de produire lui-même une analyse du projet.

Je préfère séparer les responsabilités.

DevLog
→ découvre et priorise le contexte

Kiko / OpenClaw
→ orchestre le workflow et raisonne

OpenCode
→ implémente les changements approuvés

Repository
→ reste la source de vérité

Humain
→ conserve l’autorité de validation

Lorsqu’une Engineering Story arrive, DevLog transforme les informations disponibles en éléments de preuve structurés, puis utilise un classement et un budget déterministes pour sélectionner ce qui semble pertinent.

Kiko peut ensuite utiliser ce contexte comme point de départ avant d’inspecter directement les éléments qui nécessitent une compréhension plus précise.

J’aime résumer cette séparation ainsi :

DevLog
→ où regarder ?

Kiko
→ qu’est-ce que cela signifie ?

Repository
→ qu’est-ce qui existe réellement ?

Intégrer DevLog à l’analyse du repository

Jusqu’ici, la phase de Repository Analysis reposait principalement sur l’exploration directe du projet.

Engineering Story
        ↓
Kiko
        ↓
recherches repository
inspection Git
lecture des fichiers
lecture des ADR
        ↓
Repository Analysis

Cette approche reste très efficace, notamment parce qu’elle travaille directement avec l’état actuel du code.

Elle implique cependant de reconstruire régulièrement le même type de contexte.

J’expérimente donc maintenant un fonctionnement légèrement différent :

Engineering Story
        ↓
Kiko / OpenClaw
        ↓
DevLog
        ↓
contexte repository classé
        ↓
Kiko
        ↓
inspection ciblée du repository
        ↓
Repository Analysis

DevLog intervient uniquement au début de l’analyse pour orienter l’exploration.

Si le service est indisponible ou si son contexte n’est pas exploitable, le workflow revient simplement à son fonctionnement précédent.

Je ne souhaite pas que cette nouvelle couche devienne une dépendance nécessaire au développement.

Un premier problème très concret

La première version de cette intégration transmettait la description de la Story à DevLog dans un paramètre HTTP :

GET /engineering-story-context?description=...

Cela fonctionnait pendant le développement.

Puis nous avons envoyé une véritable Engineering Story complète.

La requête est devenue trop importante pour être correctement transportée dans l’URL.

Le contrat a donc évolué vers une requête POST :

POST /engineering-story-context

{
  "description": "complete Engineering Story"
}

Ce problème est assez banal techniquement, mais je le trouve intéressant dans le contexte du projet.

Il n’est apparu qu’au moment où DevLog a réellement été utilisé par un autre composant.

L’intégration a donc commencé à faire évoluer le système lui-même.

C’est exactement le type de retour que je cherchais en décidant d’intégrer DevLog avant de considérer son analyse comme terminée.

Premier essai sur une vraie Engineering Story

Une fois l’intégration fonctionnelle, j’ai voulu observer son comportement sur une Story réelle.

Je ne cherchais pas à réaliser un benchmark scientifique ni à démontrer que DevLog était nécessairement plus performant.

L’objectif était simplement de voir ce qu’il apportait réellement à Kiko au début d’une Repository Analysis.

Le résultat peut être résumé ainsi :

USEFUL_WITH_LIMITATIONS

DevLog a sélectionné 58 éléments de preuve pour environ 2 745 tokens estimés sur un budget maximal de 6 000.

Il a correctement identifié les trois modules principaux du projet :

backend
ai-engine
frontend

Plusieurs fichiers de configuration importants ont également été remontés, notamment autour de Docker, Spring et Angular.

La provenance des informations et les raisons du classement étaient disponibles, ce qui permettait de comprendre d’où venait le contexte proposé.

Sur ce point, DevLog a rempli le rôle que j’espérais : fournir une première carte du terrain.

Mais cette carte était encore très incomplète.

Après réception du contexte, Kiko a tout de même dû effectuer approximativement :

1 recherche globale
5 recherches ciblées
25 fichiers ou sections inspectés
2 recherches Git supplémentaires
plusieurs lectures d’ADR et de documentation

Il serait donc prématuré d’affirmer que DevLog réduit déjà le coût global de l’analyse.

Ce que le premier test a surtout révélé

La Story utilisée pour ce test concernait fortement la configuration des différents services.

Or plusieurs informations déterminantes n’avaient pas été remontées, notamment dans :

frontend/proxy.conf.json
ai-engine/app/core/config.py
.env.example

DevLog avait identifié certaines bonnes zones du projet, mais pas les relations précises nécessaires pour comprendre le problème :

port hôte → port conteneur
service → URL interne
configuration → valeur par défaut
proxy Angular → backend
configuration source → comportement testé

Le classement a également montré ses limites.

Sur les 58 preuves sélectionnées, 40 étaient des fichiers de test.

Un test sans rapport direct avec la problématique s’est même retrouvé en tête du classement.

Cette expérience m’a permis de distinguer trois problèmes qui me semblaient jusque-là beaucoup plus proches :

COVERAGE
Certaines informations utiles ne sont pas encore connues.

RELEVANCE
Certaines informations connues sont mal classées.

DIVERSITY
Une catégorie de preuves peut occuper trop de place.

C’est probablement le résultat le plus utile de ce premier essai.

Avant de l’effectuer, j’aurais naturellement pensé que la prochaine étape consistait surtout à analyser davantage le contenu du code source.

Le test suggère quelque chose de plus nuancé.

Pour cette Story, des preuves de configuration plus précises auraient probablement été plus utiles qu’une compréhension supplémentaire des classes Java.

Cela pose une question intéressante pour la suite : plutôt que d’ingérer toujours davantage d’informations, comment produire le contexte réellement utile à la tâche en cours ?

DevLog ne remplace pas l’analyse du repository

Ce premier test confirme également une limite importante.

DevLog n’est aujourd’hui pas suffisamment mature pour remplacer l’analyse directe effectuée par Kiko.

Il peut identifier un fichier, son module, certains changements Git ou une décision d’architecture associée.

Mais il ne possède pas encore une représentation suffisamment précise des classes, méthodes, dépendances, relations entre composants ou comportements d’implémentation.

Lorsque ces informations deviennent nécessaires, Kiko doit toujours revenir au repository.

Et je pense que c’est une bonne limite à conserver pour le moment.

L’objectif n’est pas de supprimer l’exploration native d’OpenClaw.

Il est de réduire progressivement ce qu’il doit redécouvrir.

Cette approche permet également d’éviter de considérer le contexte préparé par DevLog comme une vérité absolue.

Un classement peut être mauvais.

Une information peut devenir obsolète.

Un fichier important peut manquer.

Le code actuel reste donc la référence finale.

Une autre réflexion autour du déterminisme

Cette expérimentation rejoint une autre réflexion apparue pendant le développement du workflow.

Une partie de ce que j’essaie de construire consiste à sortir progressivement certaines responsabilités du modèle lorsqu’elles peuvent être gérées de manière déterministe.

La sélection et la provenance du contexte dans DevLog en sont un exemple.

Les Human Approval Gates en sont un autre.

Les premières versions du workflow demandaient explicitement au modèle de s’arrêter avant certaines étapes pour obtenir une validation humaine.

L’expérience a montré qu’une instruction très claire ne constitue pas forcément une garantie d’exécution.

Certains modèles pouvaient poursuivre le workflow après une première validation.

J’expérimente donc également un plugin chargé de représenter les transitions autorisées dans une machine à états plutôt que de dépendre uniquement des instructions données au modèle.

Ce travail est encore en cours, mais les deux sujets reposent finalement sur la même idée :

ce qui peut être structuré, vérifié ou garanti de manière déterministe ne devrait pas dépendre inutilement du comportement probabiliste d’un modèle.

Cela ne réduit pas le rôle de l’IA.

Cela permet plutôt de réserver son utilisation aux problèmes pour lesquels son raisonnement apporte réellement quelque chose.

Et maintenant ?

Ce premier test ne démontre pas que DevLog rend déjà une Repository Analysis plus rapide, moins coûteuse ou meilleure.

Il montre en revanche que l’intégration est suffisamment fonctionnelle pour commencer à confronter le projet à des besoins réels.

Et c’est probablement ce que je recherchais à ce stade.

Les prochaines améliorations pourront maintenant être guidées par ces observations plutôt que par une roadmap entièrement théorique.

À court terme, cela pourrait signifier travailler sur :

des preuves de configuration plus précises ;
un classement plus discriminant ;
une meilleure diversité des preuves ;
la réduction du poids des termes trop génériques.

Puis, progressivement, DevLog pourra probablement enrichir sa compréhension du contenu des fichiers, des symboles et des relations entre composants.

À plus long terme, une autre boucle m’intéresse particulièrement.

Contexte
   ↓
Engineering Story
   ↓
Décisions
   ↓
Implémentation
   ↓
Historique
   ↓
DevLog
   ↓
Nouveau contexte

Chaque évolution d’un projet pourrait ainsi contribuer au contexte utilisé pour comprendre les suivantes.

Je ne cherche pas à construire un système où un agent autonome finirait par prendre l’ensemble des décisions de développement.

Je cherche plutôt à expérimenter une organisation où les services déterministes structurent ce qui peut l’être, où les agents raisonnent sur un contexte mieux préparé, où le repository reste la source de vérité et où l’humain conserve l’autorité sur les décisions importantes.

Dans mon précédent article, je concluais que la valeur se trouvait probablement davantage dans le processus entourant le modèle que dans le modèle lui-même.

Cette expérimentation ajoute pour moi une nouvelle question à cette réflexion :

si un workflow permet de structurer le développement, jusqu’où une mémoire technique structurée peut-elle l’aider à mieux comprendre les projets qu’il fait évoluer ?