Vers un développement logiciel piloté par des workflows d'ingénierie
Une nouvelle expérimentation autour d'OpenClaw, OpenCode et de l'Agentic SDLC.
Depuis plusieurs mois, mes projets évoluent autour d'une idée simple : l'intelligence artificielle ne doit pas remplacer l'ingénierie logicielle, elle doit l'améliorer.
Cette réflexion a d'abord influencé l'architecture de Trading OS, puis celle de DevLog AI et plus récemment celle du futur Developer OS.
Aujourd'hui, cette philosophie franchit une nouvelle étape.
Plutôt que d'utiliser un assistant IA uniquement pour générer du code ou répondre à des questions, j'expérimente une approche où plusieurs outils spécialisés collaborent au sein d'un véritable workflow d'ingénierie.
L'objectif n'est plus simplement de produire du code plus rapidement.
Il est de rendre le processus de développement lui-même plus structuré, plus reproductible et plus traçable.
Du prompt au workflow
Jusqu'à présent, mon utilisation de l'IA ressemblait à celle de nombreux développeurs.
Une idée.
Un prompt.
Une réponse.
Puis une nouvelle discussion.
Cette approche fonctionne très bien pour résoudre un problème ponctuel, mais elle montre rapidement ses limites lorsqu'un projet prend de l'ampleur.
Les décisions se dispersent dans différentes conversations.
Les raisons ayant conduit à certains choix disparaissent progressivement.
Et il devient difficile de reconstituer le cheminement ayant mené à une implémentation.
Je souhaitais expérimenter une approche différente.
Une approche où chaque évolution du projet suit un processus explicite.
Une chaîne d'ingénierie plutôt qu'une conversation
L'expérimentation repose aujourd'hui sur un workflow simple.
Chaque évolution importante commence par une GitHub Issue.
Cette Issue devient ensuite une Story qui sert de point d'entrée au processus d'ingénierie.
À partir de cette Story, une succession d'artefacts est produite :
- Repository Analysis
- Implementation Plan
- Implementation Report
- Code Review
- Engineering Report
Chaque étape possède une responsabilité clairement définie.
Les validations humaines restent présentes entre les étapes importantes.
L'objectif est que chaque décision puisse être comprise plusieurs semaines ou plusieurs mois plus tard sans dépendre d'une conversation avec un modèle de langage.
Le rôle d'OpenClaw et d'OpenCode
Pour cette expérimentation, j'utilise principalement deux outils.
OpenClaw joue le rôle de coordinateur.
Il exécute un workflow d'ingénierie, produit les différents artefacts, respecte les étapes de validation et orchestre la progression de la Story.
OpenCode intervient lorsque vient le moment d'implémenter les changements approuvés.
Cette séparation me paraît importante.
Le coordinateur ne devient pas automatiquement l'implémenteur.
Chaque outil conserve une responsabilité bien définie.
Cette organisation rappelle finalement les équipes d'ingénierie traditionnelles, où différentes personnes interviennent selon leurs compétences, tout en suivant un même processus.
Les premiers résultats
Pour valider cette approche, j'ai commencé par créer un dépôt dédié nommé Engineering Skills.
L'objectif n'était pas de développer une application.
Il s'agissait de construire un workflow réutilisable capable de piloter le développement d'autres projets.
Le point le plus intéressant est probablement le suivant :
Engineering Skills est capable de s'utiliser lui-même.
Les Stories, les analyses, les plans d'implémentation, les revues de code et même les premières décisions d'architecture sont produits en suivant le workflow qu'il définit.
Une fois cette première étape validée, j'ai commencé à tester le même processus sur un second dépôt, Engineering Playground.
Le workflow s'est adapté au contexte du nouveau projet sans modification majeure, ce qui constitue un premier signal encourageant quant à sa réutilisabilité.
Les enseignements
Cette première expérimentation confirme une intuition que j'avais depuis quelque temps.
La véritable valeur n'est probablement pas dans le modèle de langage lui-même.
Elle réside dans le processus qui l'entoure.
Les modèles évolueront.
Les outils changeront.
De nouveaux agents apparaîtront.
En revanche, un bon processus d'ingénierie reste valable, quel que soit l'outil qui l'exécute.
C'est cette idée qui guide désormais mes expérimentations.
Et maintenant ?
Cette expérimentation n'en est qu'à ses débuts.
Le prochain objectif sera d'utiliser ce workflow pour développer de véritables fonctionnalités au sein d'Engineering Playground, puis de l'étendre progressivement à Developer OS et Trading OS.
À terme, j'aimerais que chaque projet partage le même langage d'ingénierie :
- des Stories comme point d'entrée ;
- des Architecture Decision Records pour les décisions importantes ;
- des artefacts d'ingénierie persistants ;
- des agents spécialisés responsables d'une seule étape ;
- des validations humaines systématiques avant les décisions structurantes.
Je ne cherche pas à construire un développement entièrement autonome.
Je cherche à construire un environnement où humains, services déterministes et agents IA collaborent selon un processus clair, documenté et reproductible.
Je pense que c'est cette combinaison, davantage que les outils eux-mêmes, qui représente aujourd'hui la piste la plus prometteuse pour faire évoluer ma manière de concevoir des logiciels.