Ca y est, le repository de CLI d'AWF (pour AI Workflow Framework) est officiellement ouvert à tout le monde et ça signifie que vous pouvez jouer avec si le coeur vous en dit.
Mais parlons en un peu quand même.
Le projet
Pourquoi ?
AWF est né d'un besoin personnel concret : j'ai mieux à faire. C'est très pragmatique, et j'en ai déjà parlé dans mes précédents posts, mais je ne suis plus payé pour coder. C'est un fait qui bouscule mes affinités mais c'est là où j'en suis dans ma vie professionnelle. Aujourd'hui, si je dois commencer à coder, c'est généralement qu'il y a un problème ou que nous sommes dans une phase très précise d'un projet (comme l'amorçage).
Cependant, cela ne signifie pas que je n'ai plus envie de créer ou de coder, ne serait-ce que pour de petits projets. J'utilise donc des solutions LLM en essayant de les piloter au mieux. Résultat : chaque fois que j'ai tenté de "driver" un LLM de manière traditionnelle (avec un laptop posé à côté de mon ordinateur principal), j'ai buté sur l'impossibilité d'être en permanence derrière cet écran.
Le temps (et le coût cognitif) est donc le premier problème.
Le second problème est structurel. Quand je dirige une équipe, je peux m'assurer que le travail est fait correctement en suivant les PR, avec une CI/CD, de la QA, des réunions, etc. S'il y a un "trou dans la raquette", il est facile à identifier. Avec un LLM, c'est une autre histoire : la machine n'en fait régulièrement qu'à sa tête et il est complexe de la contrôler.
Le manque de déterminisme est le second problème.
Enfin, il y a l'évolution ultra-rapide des usages et des solutions d'IA. Tout s'achète au mois le mois, les solutions se challengent continuellement, les usages mutent et les bonnes idées fusent.
M'assurer de pouvoir faire ce que je veux dans la durée est le troisième problème.
Comment ?
Début décembre 2025, je me suis dit qu'il y avait certainement mieux à faire. J'ai utilisé Ansible à différents moments et ce que j'apprécie, c'est son aspect binaire : ça marche ou ça casse. Il n'y a pas d'entre-deux. C'est contraignant, mais efficace.
C'est ainsi qu'est née l'idée d'un CLI basé sur une certaine granularité et, déformation Symfony oblige, sur un workflow.
Initialement, je penchais pour le Rust, mais j'ai eu peur d'avoir du mal à gérer les problèmes en cas de souci majeur. Le Go m'a semblé plus adapté pour répondre à ce besoin, d'autant que l'idée de développer autre chose que du CLI m'intéresse.
Le Go, j'en avais déjà lu via le code source d'Ethereum et je sais que des amis dans l'écosystème PHP mènent de beaux projets avec.
J'ai donc commencé à bosser rapidement sur AWF, et l'outil a été très vite fonctionnel.
Où en sommes-nous ?
AWF est pleinement opérationnel. C'est d'ailleurs AWF qui assure son propre développement au travers des workflows que j'utilise, lesquels évoluent continuellement. Je pourrais m'arrêter là : it works.
Mais bien entendu, nous allons aller plus loin, car il reste énormément de pistes intéressantes à explorer.
AWF CLI
Le CLI d'AWF est un binaire qui permet d'interagir avec votre système via un workflow. Ce dernier est décrit sous forme de steps, chaque étape réalisant des opérations spécifiques.
Le CLI d'AWF n'est pas un énième "claw". C'est même tout le contraire : plus vous maîtriserez votre ligne de commande et vos outils, plus vous serez en mesure de créer un système complexe autour des solutions IA telles que Claude, Gemini ou Codex. De même, mieux vous comprendrez le fonctionnement d'un contexte et l'évaluation de vos prompts, plus vous créerez un système agnostique et fiable.
Je pense pouvoir prétendre être un professionnel du développement et j'ai conçu un outil fait pour être utilisé par des profils comme le mien.
Les fonctionnalités
À ce jour, AWF propose les fonctionnalités suivantes :
- Création et suivi d'un workflow écrit en YAML via des "steps".
- Exécution arbitraire : chaque étape peut exécuter une action avec transition et suivi (succès ou erreur).
- Steps spécialisées "Agent LLM" : disponibles pour Claude Code, Gemini, Codex et les solutions compatibles OpenAI.
- Logique avancée : conditions, parallélisme, boucles, appel de workflows tiers, support de XDG pour le travail en équipe, etc.
- Gestion robuste : gestion des erreurs, audit trail, fonctionnalités d'export, etc.
La structure pour les futurs développements est là. Il n'y a plus qu'à avancer en consolidant la base.
Le futur
Le Go a toujours fait partie des langages qui m'intéressaient, au même titre que le JS/TS, le Rust, le Python ou, plus récemment, le Zig. J'ai dirigé le développement avec Claude dès le début, puis via des workflows AWF dès la mi-décembre. On peut donc affirmer sans détour qu'AWF a été "vibe codé".
Le "problème", c'est que j'ai très envie de mettre les mains dans le cambouis. J'ai également d'autres projets à mener ou reprendre pour progresser sur l'IA au sens large (dont Embrex). Il va falloir que je trouve le moyen de faire avancer tout cela pour qu'au final, on oublie presque qu'AWF a été amorcé par un LLM.
Je prendrai évidemment tous vos retours pour améliorer l'outil, alors n'hésitez pas à le tester. Un skill Claude est disponible, ainsi qu'une documentation et une tonne de tests avec des workflows d'intégration. Mes DMs et mails vous sont ouverts.
Le développement d'AWF va se poursuivre sereinement. J'ai l'intention de piloter cela comme un véritable produit.
Un produit technique, certes, mais un produit avant tout. Comprenez ce qu'il y a à comprendre :)