Vers un développement logiciel piloté par des workflows d'ingénierie : un mois plus tard

Il y a environ un mois, je publiais un article consacré à une expérimentation autour d'OpenClaw, OpenCode et de l'Agentic SDLC.

L'idée était de sortir progressivement d'une utilisation de l'intelligence artificielle centrée sur le prompt pour construire un véritable workflow d'ingénierie.

Une évolution importante devait commencer par une Story, puis produire une succession d'artefacts persistants :

• Repository Analysis
• Implementation Plan
• Implementation Report
• Code Review
• Engineering Report

Les Architecture Decision Records devaient conserver les décisions structurantes, tandis que des validations humaines restaient présentes aux étapes importantes.

À ce moment-là, la répartition des responsabilités semblait assez naturelle.

OpenClaw jouait le rôle de coordinateur du workflow.

OpenCode intervenait principalement lorsque venait le moment d'implémenter les changements approuvés.

Un mois plus tard, l'expérimentation a suffisamment évolué pour commencer à confronter cette architecture à l'usage réel.

Certaines intuitions se sont confirmées.

D'autres méritent aujourd'hui d'être remises en question.

Le workflow a mieux résisté que les outils

Le premier constat est probablement le plus important.

Le workflow lui-même fonctionne.

Les Stories continuent de servir de point d'entrée aux évolutions importantes.

Les analyses du repository permettent de comprendre l'existant avant de modifier le code.

Les plans d'implémentation obligent à expliciter une stratégie avant de commencer à développer.

Les rapports d'implémentation et les revues permettent ensuite de conserver une trace de ce qui a réellement été réalisé.

Les ADR ont également pris une place croissante à mesure que les projets et les décisions architecturales sont devenus plus complexes.

Cette organisation n'a pas disparu lorsque les outils utilisés pour l'exécuter ont changé.

Au contraire.

Elle s'est progressivement imposée comme la partie la plus stable de l'expérimentation.

C'est un premier enseignement intéressant : un workflow d'ingénierie bien défini semble pouvoir survivre beaucoup plus facilement à l'évolution des modèles et des agents qui l'exécutent.

OpenCode a progressivement dépassé son rôle initial

Dans mon expérimentation initiale, OpenCode occupait principalement le rôle d'agent d'implémentation.

Une analyse était produite.

Un plan était validé.

Puis OpenCode intervenait pour modifier le repository.

Dans la pratique, son rôle a progressivement évolué.

Aujourd'hui, je peux lui confier une mission beaucoup plus complète :

• investiguer un problème ;
• analyser l'architecture existante ;
• préparer une Engineering Story ;
• rédiger un Repository Analysis ;
• proposer un Implementation Plan ;
• implémenter les changements ;
• écrire et exécuter les tests ;
• reconstruire et redéployer l'application lorsque cela est nécessaire ;
• effectuer une première revue du code ;
• produire un Engineering Report.

Cette évolution a modifié une partie de l'équation initiale.

Si un même agent d'exécution est capable de suivre correctement le workflow, de respecter ses contraintes et de produire ses artefacts, l'ajout systématique d'un orchestrateur supplémentaire devient moins évident.

J'ai même commencé à utiliser deux sessions OpenCode en parallèle sur deux projets différents.

L'expérience n'est pas totalement gratuite en ressources pour la machine, mais du point de vue du workflow elle reste étonnamment simple à superviser.

Cela soulève une question que je ne m'étais pas posée aussi directement lors de la première expérimentation :

si je peux encore coordonner efficacement quelques agents d'exécution moi-même, ai-je réellement besoin d'un agent supplémentaire chargé de coordonner ces agents ?

Pour l'instant, la réponse est plutôt non.

Une abstraction peut être correcte et pourtant prématurée

Cette conclusion ne signifie pas qu'OpenClaw était un mauvais choix.

Elle signifie plutôt que le problème auquel je voulais l'appliquer n'était peut-être pas encore suffisamment présent.

Ajouter un orchestrateur n'est pas neutre.

Un workflow relativement simple :

Humain
 ├── OpenCode — projet A
 └── OpenCode — projet B

peut devenir :

Humain
   ↓
Orchestrateur
   ├── OpenCode — projet A
   └── OpenCode — projet B

Cette nouvelle couche doit alors gérer sa propre part de complexité : délégation, contexte, état des tâches, erreurs, reprise, permissions et observabilité.

Cette complexité peut être parfaitement justifiée.

Mais seulement si elle résout un problème réel.

C'est probablement l'un des enseignements les plus utiles de cette expérimentation jusqu'ici :

une architecture cible peut être pertinente tout en étant prématurée à implémenter.

Plutôt que de chercher immédiatement à réintroduire OpenClaw dans le workflow, je préfère donc attendre que le besoin d'orchestration devienne suffisamment concret pour pouvoir mesurer sa valeur.

DevLog fait déjà partie du workflow

DevLog AI n'est cependant pas encore un agent autonome.

Il intervient déjà dans le workflow à travers son serveur MCP.

Lorsqu'OpenCode commence une nouvelle investigation ou une Engineering Story, je lui demande désormais d'interroger DevLog avant d'explorer largement le repository.

Le principe est simple :

OpenCode
    ↓
DevLog MCP
    ↓
get_engineering_context
    ↓
Contexte d'ingénierie initial
    ↓
Investigation ciblée

À travers MCP, OpenCode peut demander à DevLog de construire un contexte adapté à l'intention de la tâche.

Ce contexte peut contenir des éléments issus de l'historique Git, des changements récents, des Engineering Stories et des connaissances déjà analysées par DevLog.

Lorsque le contexte initial ne suffit pas, OpenCode peut également utiliser d'autres capacités exposées par DevLog, notamment la recherche dans l'historique du projet, afin de retrouver des évolutions plus anciennes ou des éléments liés à une question précise.

L'objectif n'est pas d'empêcher OpenCode de lire le repository.

Au contraire.

Le repository reste indispensable lorsqu'il faut vérifier l'implémentation actuelle, inspecter un contrat précis, lire les tests ou confirmer une hypothèse.

DevLog sert plutôt de point d'entrée contextuel.

Au lieu de commencer chaque tâche avec une connaissance presque nulle du projet et d'explorer largement le repository, OpenCode peut commencer avec une première représentation de son histoire et des connaissances déjà accumulées.

Dans mes prompts d'ingénierie, cette séquence est devenue progressivement explicite :

1. Interroger DevLog
2. Évaluer la fraîcheur et la pertinence du contexte
3. Rechercher l'historique si nécessaire
4. Explorer directement le repository pour compléter ou vérifier
5. Réaliser l'investigation ou l'implémentation

Cette utilisation réelle a également révélé les limites actuelles de DevLog.

Lors de plusieurs Stories, OpenCode obtenait correctement une partie du contexte, notamment autour de l'activité Git récente, mais devait encore explorer directement le repository pour retrouver certaines décisions d'architecture, Stories, contrats ou connaissances plus précises.

Ces observations sont devenues elles-mêmes une source d'évolution pour DevLog.

Plutôt que de concevoir son futur agent uniquement à partir d'une architecture théorique, je peux observer ce qu'un véritable agent de développement cherche, ce qu'il trouve, ce qui lui manque et les raisons pour lesquelles il revient au repository.

C'est notamment ce qui a progressivement déplacé la réflexion de la simple mémoire technique vers un véritable problème de context engineering.

DevLog change progressivement la nature du problème

Cette intégration MCP constitue cependant seulement une première étape.

OpenCode reste aujourd'hui responsable de l'interprétation du contexte reçu, de l'identification de ce qui lui manque et de la reconstruction d'une partie importante de la compréhension nécessaire à sa tâche.

Autrement dit, DevLog fournit progressivement de meilleures capacités de contexte, mais OpenCode effectue encore lui-même une partie du travail de context engineering.

L'objectif à plus long terme est donc différent.

DevLog doit progressivement devenir capable de reconstruire lui-même le contexte d'ingénierie pertinent pour une tâche et de le transmettre à l'agent chargé de l'exécution.

Un véritable DevLog Agent pourrait par exemple relier :

• l'historique Git ;
• les changements de code ;
• les Engineering Stories ;
• les ADR ;
• les décisions précédentes ;
• les connaissances validées ;
• l'état actuel du projet.

Le workflow commencerait alors à ressembler à ceci :

Engineering Task
      ↓
DevLog Agent
      ↓
Reconstruction du contexte
      ↓
OpenCode
      ↓
Implémentation
      ↓
Analyse du changement
      ↓
Validation humaine

Et cette évolution change complètement la question de l'orchestration.

Quand plusieurs agents ont réellement des responsabilités différentes

Dans le workflow actuel, OpenCode peut encore prendre en charge une grande partie de la chaîne.

Avec un véritable DevLog Agent, les responsabilités deviennent beaucoup plus spécialisées.

DevLog ne serait pas un agent de code.

Il serait responsable du contexte, de l'historique et de la connaissance technique.

OpenCode resterait responsable de l'exécution locale : modification du repository, build, tests et production des changements.

D'autres agents spécialisés pourraient apparaître progressivement.

À ce moment-là, il faudra répondre à de nouvelles questions.

Qui décide qu'une tâche nécessite d'abord une analyse DevLog ?

Qui transmet le contexte produit à OpenCode ?

Qui suit l'exécution ?

Qui déclenche une analyse après l'implémentation ?

Qui sait qu'une validation humaine est nécessaire avant de continuer ?

Cette fois, le besoin d'orchestration ne serait plus théorique.

Il émergerait directement du workflow.

C'est probablement à ce moment qu'un outil comme OpenClaw pourrait retrouver une place beaucoup plus naturelle.

Non pas comme une couche ajoutée parce que l'idée d'un orchestrateur multi-agents est séduisante.

Mais comme une réponse à un problème réellement rencontré.

Orchestrer n'est pas gouverner

Cette réflexion m'a également conduit à préciser une distinction architecturale importante.

L'orchestration et la gouvernance du workflow ne sont pas la même responsabilité.

Un orchestrateur peut décider quel agent doit exécuter une étape, attendre son résultat et transmettre les informations nécessaires à l'étape suivante.

Mais les règles fondamentales du processus d'ingénierie ne devraient pas dépendre de cet orchestrateur.

Par exemple :

• une décision architecturale importante peut nécessiter un ADR ;
• un ADR doit être validé avant qu'une implémentation dépendante commence ;
• un agent de code ne doit pas modifier directement la branche principale ;
• une connaissance générée par IA ne doit pas devenir automatiquement une connaissance de confiance ;
• certaines étapes nécessitent explicitement une validation humaine.

Ces règles appartiennent au workflow d'ingénierie lui-même.

Dans la vision actuelle du futur Developer OS, cette séparation pourrait progressivement prendre cette forme :

Developer OS
Engineering Workflow
        │
        │ définit
        ▼
Workflow
Règles
Permissions
Validations humaines
Gouvernance
        │
        ▼
Agent Orchestrator
        │
        │ délègue
        ▼
Runtime d'orchestration
        │
   ┌────┴─────┐
   ▼          ▼
DevLog      OpenCode
Agent

OpenClaw pourrait devenir l'un des runtimes capables d'exécuter cette orchestration.

Mais il ne serait pas la source de vérité du processus.

Cette distinction permettrait également de conserver une architecture indépendante d'un outil particulier.

Si le runtime change un jour, les règles d'ingénierie, les responsabilités et les artefacts restent les mêmes.

Les agents sont peut-être moins importants que leurs responsabilités

Dans mon premier article, j'écrivais que la véritable valeur ne se trouvait probablement pas dans le modèle de langage lui-même, mais dans le processus qui l'entoure.

Un mois plus tard, c'est probablement l'idée qui a le mieux résisté à l'expérience.

Les modèles utilisés ont évolué.

Le rôle d'OpenCode a changé.

La place initialement imaginée pour OpenClaw est aujourd'hui remise en question.

DevLog commence à évoluer vers un rôle beaucoup plus spécialisé.

Pourtant, les Stories restent.

Les ADR restent.

Les analyses restent.

Les plans d'implémentation restent.

Les revues et les rapports restent.

Et les validations humaines restent.

Cela m'amène aujourd'hui à formuler l'idée légèrement différemment :

les agents sont remplaçables ; les responsabilités et le processus le sont beaucoup moins.

L'objectif n'est donc peut-être pas de construire le plus rapidement possible une équipe composée d'un grand nombre d'agents.

Il est d'abord de comprendre quelles responsabilités méritent réellement d'être séparées.

Puis de construire ou choisir un agent lorsque cette séparation apporte une valeur concrète.

Et maintenant ?

La prochaine étape n'est donc pas d'ajouter davantage d'orchestration.

Elle est de rendre le premier agent spécialisé réellement utile.

DevLog doit progressivement passer d'un ensemble d'outils exposés par MCP permettant de consulter la mémoire technique d'un projet à un agent capable de reconstruire le contexte d'ingénierie nécessaire à une tâche.

L'un des prochains tests importants sera de vérifier si ce contexte peut réellement améliorer le travail d'un agent d'exécution comme OpenCode et réduire la quantité d'exploration du repository nécessaire avant chaque évolution.

Si cette collaboration fonctionne, un nouveau problème apparaîtra naturellement : coordonner plusieurs agents possédant des responsabilités différentes au sein d'un même workflow.

Ce sera probablement le bon moment pour réévaluer OpenClaw.

Non plus parce qu'un orchestrateur semble être une composante naturelle d'une architecture multi-agents.

Mais parce que le système aura réellement commencé à avoir quelque chose à orchestrer.

Cette expérimentation continue donc de suivre le même principe que celui qui l'a initiée.

Je ne cherche pas à construire un développement entièrement autonome.

Je cherche à comprendre comment humains, services déterministes et agents IA peuvent collaborer au sein d'un processus clair, documenté et reproductible.

Un mois après la première expérimentation, ma conviction sur ce point n'a pas changé.

En revanche, la manière d'y parvenir commence déjà à évoluer.