Tout le monde partage ses skills. Personne ne partage son workflow

Si on regarde ce qui circule autour du développement agentique via claude code, on trouve surtout des skills.

Par centaines.

Des marketplaces, des collections, des dépôts qu'on installe en une commande. Rédiger un message de commit, relire une pull request, générer une documentation, appliquer une charte graphique : pour chaque geste isolé, quelqu'un a empaqueté sa recette et vous pouvez la prendre.

Maintenant, cherchez des workflows, car oui, claude permet de définir des workflows, comme des skills.

Il y en a quelques-uns. Très peu, au regard du reste, et surtout : ceux qui circulent sont tous génériques. Spécifier, découper, implémenter, tester. Des séquences qui pourraient s'appliquer à n'importe quel projet.

Cette asymétrie est bizarre. Le workflow est pourtant l'endroit où se joue l'essentiel, celui qui décide de la forme de ce qui sera produit. Pourquoi personne ne partage le sien ?

Je crois que ce n'est ni un oubli ni de la rétention. C'est structurel.

Un skill est partageable parce qu'il ignore votre architecture. Un workflow ne l'est pas, parce qu'il en est le miroir.

Un workflow qui voyage est un workflow qui ne contient aucune architecture. Voilà pourquoi ceux qu'on trouve sont génériques : ils ne peuvent pas être autre chose. Et voilà pourquoi le mien ne vous servira à rien directement, En revanche cela peut vous être utile pour créer celui qui sera adapté a votre contexte.

Ce que fait mon workflow

Huit phases. Chacune produit un fichier, validé avant de passer à la suivante. On ne code pas pendant les phases 2 à 7 : le code arrive à la phase 8, à l'implémentation des cartes.

1. Design, les maquettes
2. Architecture front, la composition entre widget et la répartition des traitements front / back
3. Architecture back, l'organisation des traitements entre les bounded contexts si besoin
4. Contrats de données, les DTOs d'entrée et de sortie
5. Use cases, la couche commande
6. Domaine, la logique métier
7. Effets de bord : persistance, événements, réponses
8. Ecriture des Cartes kanban, chacune identifiée, et prête a être codée

Maintenant, regardez à côté l'anatomie d'un de mes bounded contexts.
- io/web pour les templates, les contrôleur d'api et les fragments,
- use_cases/ pour la couche applicative,
- domain/ pour l'agrégat et ses événements,
- io/repository/ pour les projections, ports.rs pour les contrats sortants.

Il y a une correspondance directe avec les étapes 2,5,6,7.

La phase 2 spécifie la composition de widgets, qui est exactement la façon dont mes contextes s'assemblent à l'écran. La phase 7 spécifie la persistance et les événements, c'est-à-dire mon event store et mes deux bus. La phase 8 produit des cartes de kanban, qui est mon flux de production.

Mon workflow ne décrit pas une méthode générale de conception. Il décrit mon hexagone, traversé une couche à la fois.

Donc si on décrivait le workflow, vu d'avion, il se découpe en :
- La spec graphique de l'effet métier à obtenir et le découpage pressenti: étapes 1 à 3
- Sa déclinaison dans l'architecture hexagonale que j'ai adopté : étapes 4 à 8
Pour au final produire des items de développement (carte kanban) totalement dépourvue d'ambiguïté et prête à être réalisée. Le codage devient anecdotique et quasi sans risque.

Mon workflow colle donc à mon approche et à mon architecture. J'ai ainsi la garantie que je maitrise la manière dont le code sera organisé.

Le détail qui devrait vous gêner

Regardez l'ordre.

Le domaine est le cœur. Il ne dépend de rien, tout dépend de lui. C'est la couche la plus importante et la plus stable.

Il est spécifié en sixième position.

On part de l'écran, on descend vers le métier. C'est l'inverse exact de l'ordre de dépendance, et c'est délibéré.

J'ai toujours trouvé que le maquettage graphique est un excellent moyen de designer un processus.
Si les écrans sont clairs, l'utilisabilité sera au rendez vous, et le job sera fait. Et ce en étant davantage "user-centric" que les modélisations type Event Storming, ou story mapping.
Quand il faut décider ce qu'on affiche quand la valeur est absente, ce qui est cliquable et ce qui ne l'est pas, ce qui se passe si l'utilisateur revient en arrière. Ces questions-là sortent rarement d'un atelier de modélisation. Elles sortent d'une maquette.

Un workflow générique n'aurait pas fait ce choix. Il aurait commencé par le domaine, parce que c'est ce que la théorie recommande et ce que tout le monde écrit dans les livres.

Pourquoi c'est vital avec un agent, et seulement avec un agent

Voilà le point que je n'aurais pas fait il y a deux ans.

Un développeur humain qui connaît la base de code a une intuition architecturale. Vous lui demandez d'ajouter une fonctionnalité, il sait sans y penser que la validation va dans le domaine, que la requête SQL va dans le repository, que le contexte d'à côté ne doit pas être importé. Il a intériorisé la forme du système.

Un agent n'a rien intériorisé. Il n'a que ce qui se trouve dans son contexte au moment où il travaille. Un agent est bête, et on ne peut pas lui faire confiance.

Donc si le workflow ne lui dit pas où sont les couches, il ne les inventera pas. Il produira quelque chose de plausible et de générique : un handler qui fait tout, un modèle anémique, une requête SQL au milieu d'un controller. Du code qui marche et qui n'a aucune structure, parce que rien dans son contexte ne lui a indiqué qu'il y en avait une.

Et il le fera vite. C'est ça le vrai danger. À ce débit, une architecture non spécifiée ne dérive pas lentement comme avec une équipe humaine : elle est écrasée en trois sessions.

La différence entre prévenir et rattraper

J'ai par ailleurs un vérificateur d'architecture qui refuse mes commits non conformes. On pourrait croire que ça suffit, et que le workflow est un luxe.

Non, parce que les deux n'interviennent pas au même moment.

Le vérificateur agit après. Il constate qu'une dépendance interdite existe, et il la refuse. C'est indispensable, mais c'est un constat de dégât.

Le workflow agit avant. Il fait que la question « où va cette logique » soit tranchée à la phase 5, dans un fichier, validée par moi, avant qu'une seule ligne ne soit écrite.

Un workflow générique fait donc faire au vérificateur un travail qu'il n'aurait pas dû avoir à faire. On génère du code mal placé, puis on le refuse, puis on le régénère. Trois fois le coût, et une architecture qui n'existe que par la négative, comme la somme de ce qui a été interdit.

Le parallèle qui devrait alerter

On a déjà vécu cette histoire, il y a quinze ans, environ.

Rails, Django, Laravel n'ont jamais imposé seulement des conventions de nommage. Ils imposent un pattern de développement : du MVC, un ActiveRecord, une entité qui est une ligne de table. La convention plutôt que la configuration est un cadeau extraordinaire tant que votre métier entre dans le moule, c'est a dire pas longtemps généralement.

Le jour où il n'y entre pas, vous ne configurez pas votre framework. Vous vous battez contre lui, pendant des années, et vous finissez par tordre votre domaine pour qu'il ressemble à ce que l'outil sait exprimer.

Vu de ma fenêtre, les workflows agentiques génériques et les méthodes "spec driven" préparent le même type de piège.
Adoptez-en un, et votre architecture dérivera doucement vers ce que la méthode sait décrire. Si la méthode parle d'entités, de services et d'endpoints, vous aurez des entités, des services et des endpoints, dont l'organisation générale sera posée par défaut, sans forcément coller a votre besoin.

Ce que je ne prétends pas

Soyons clairs, mon workflow n'est pas transposable tel quel à n'importe quel projet, et c'est précisément ce que dit cet article. Il est taillé pour une application événementielle, avec des contextes étanches et une composition front par fragments. Si vous faites du CRUD avec un ORM et une SPA, mes huit phases n'ont aucun sens chez vous. Il vous en faut huit autres, qui décrivent votre système à vous.

Dans mon cas, l'utilisation du workflow claude n'est pas une silver bullet. Je ne l'utilise pas partout. Il est activé à la demande, pour les nouvelles fonctionnalités. Pas pour un correctif, pas pour une refonte isolée, pas pour une modification mineure. Appliquer huit phases de spécification à un bug d'affichage serait exactement le genre de bureaucratie qui fait détester les méthodes.

Ce que j'en retiens

Un outil qui ne connaît pas votre système vous imposera le sien. Ce n'est pas de la malveillance, c'est mécanique : il ne peut exprimer que ce qu'il sait nommer et la nature a horreur du vide.

Avec un framework web, le prix se payait en années de contorsion. Avec un agent sans workflow, ou sans contrainte d'architecture forte, il se paie en perte de maîtrise sur le code généré, ce qui sera très ennuyeux quand un bug surviendra.

Alors oui, écrivez votre propre workflow. Pas par orgueil d'ingénieur, et pas parce que ceux des autres sont mauvais.

Parce que le vôtre est le seul document qui dira à votre agent que votre architecture existe.