L'intégration de l'IA chez Plop : du discovery au delivery

Cet article est la partie 1 d'une suite comprenant :

• Partie 1 : vue d'ensemble des pratiques agiles, DDD, ATDD, TBD et des autres trucs en DD chez Plop
• Partie 2 : un plugin IA avec MCP pour augmenter et challenger la discovery produit, de l'event storming à l'impact mapping
• Partie 3 : comment garder le contrôle de l'IA dans le chaos génératif, grâce à des skills Claude Code
• Partie 4 : un plugin Claude Code avec test first et refacto pédagogique et pour enfin dire adieu aux pull requests et au Git Flow

L'IA générative s'est imposée très rapidement dans le quotidien des équipes produit et tech depuis fin 2022. Le vibe coding a rapidement gagné en visibilité, trouvé des cas d'usage, mais aussi montré ses limites. Le grand remplacement annoncé des développeurs n'a pas eu lieu. En revanche, nos métiers sont déjà en train d'être profondément transformés, et cette transformation s'accélère avec l'arrivée de modèles de plus en plus performants (Opus 4.6, GPT 5.4 et Mythos qui fait déjà parler de lui avant sa sortie) et d'agents avec de l'outillage de plus en plus vaste (Claude Code).

Si "oublier" le code façon vibe code peut fonctionner pour des prototypes, des explorations ou des projets jetables, cette approche n'est pas viable dès qu'un système porte des enjeux de maintenabilité, de performance ou encore de scalabilité.

“Ce n'est donc pas le métier de développeur qui disparaît, mais une certaine manière de le définir, centrée avant tout sur l'écriture de code.”

Comme le résume Ian Cooper dans "coding is dead, long live programming".

Qu'est-ce que cela change ? Beaucoup de choses, et finalement assez peu à la fois.

L'écriture de code n'a jamais été, à elle seule, le cœur de la complexité d'un système. La complexité se situe surtout dans la compréhension du métier, la formulation des besoins, les arbitrages d'architecture, la définition de bonnes pratiques adaptées au contexte, la cohérence globale du système et la circulation de la connaissance dans l'équipe. D'ailleurs, plusieurs études récentes montrent que les développeurs passent une minorité de leur temps à écrire du code.

“Autrement dit, l'enjeu n'est pas seulement d'aller plus vite : il est surtout de mieux structurer le travail pour tirer parti de l'IA sans dégrader la qualité.”

De la discovery métier à la delivery, cette série d'articles présente la manière dont Plop structure ses process agile et craft en tirant parti de l'IA à chaque étape du cycle de vie d'un projet.

Event Storming

Pour définir des spécifications pertinentes, une équipe doit d'abord s'immerger dans le quotidien des utilisateurs, comprendre leurs pratiques, leurs contraintes et leurs objectifs.

Si l'on ne comprend pas réellement le contexte des personnes pour lesquelles on conçoit une solution, on ne comprend pas non plus précisément le problème que l'on cherche à résoudre. C'est l'un des fondements de la dimension stratégique du Domain Driven Design.

Dans cette perspective, l'atelier d'Event Storming Big Picture est particulièrement efficace. Il permet aux utilisateurs d'exposer leurs processus actuels, leurs points de douleur, leurs interactions... Les différents acteurs sont identifiés, leurs usages deviennent plus lisibles, et un premier glossaire métier peut être formalisé.

Impact Mapping

Une fois le terrain mieux compris, les objectifs deviennent plus faciles à formuler.

Quelle problématique veut-on résoudre ? Quel objectif métier veut-on atteindre ? Augmenter le nombre d'utilisateurs inscrits ? Améliorer le taux de conversion ? Réduire le temps de traitement d'une opération ? Et surtout : comment saura-t-on que l'objectif est atteint ?

L'Impact Mapping part de l'objectif — le "pourquoi" — pour faire émerger les acteurs concernés, les impacts attendus, puis enfin les fonctionnalités à concevoir. Chez Plop, nous cherchons à coupler cet atelier avec des pratiques issues du User Story Mapping et de l'Example Mapping, afin que chaque fonctionnalité soit explicitement reliée à un besoin métier. Cela facilite ensuite la priorisation.

Pour chaque user story priorisée, nous définissons des règles — métier, UI, système — ainsi que des exemples ou scénarios (les critères d'acceptation). Lorsque les règles sont complexes, ce travail est fait avec le client ; sinon, il peut être mené avec l'équipe de développement.

Plop s'appuie sur un plugin FigJam sur mesure, couplé à un serveur MCP custom, à GitHub Projects et à Claude Code, pour créer automatiquement les issues / tickets Github liés aux US, scénarios etc, assister l'écriture des scénarios, vérifier la cohérence avec le glossaire métier, challenger les user stories ainsi que les exemples associés, proposer des options divergentes (et d'autres fonctionnalités) tout en ayant accès au code actuel.

ATDD

Définir des scénarios en amont permet d'expliciter les comportements attendus d'une user story, puis de transformer ces exemples en tests automatisés avant l'implémentation du code. On utilise le terme ATDD chez Plop. Mais il pourrait être Test-first, TDD, ATDD, BDD… La terminologie sur ces pratiques déclenche généralement une guerre entre devs (ce qui est ironique quand on pense que la majorité des devs prônant ces pratiques aiment définir un langage ubiquitaire avec leur client).

Si l'IA change profondément la manière de développer, elle ne rend pas obsolètes les pratiques craft / lean / XP ; au contraire, elle les rend encore plus justifiées. Sur des projets à enjeux, il est difficile de justifier une approche yolo vibe coding mode, dans laquelle on accepte du code sans en maîtriser précisément le sens, la structure ou les conséquences.

Chaque équipe a ses pratiques, ses contraintes et ses critères de qualité. L'intérêt de l'IA n'est pas d'effacer ces exigences, mais de permettre leur mise en œuvre plus systématique, à condition qu'elle soit cadrée. Lorsque ce cadre existe, le coût marginal de production du code diminue fortement (le coût de la ligne de code s'approche de 0 avec l'IA).

L'opposition entre qualité et vitesse devient alors moins pertinente : le vrai sujet n'est plus "faut-il sacrifier la qualité pour aller vite ?", mais "comment mieux diriger l'IA pour garantir la qualité" et "comment mieux spécifier le comportement attendu". Rien à réinventer ici, la réponse se trouve évidemment dans les user stories et leurs scénarios / exemples / critères d'acceptation. Plus ces specs sont précises, plus l'IA les "comprend" et mieux elle peut les transformer en code, les rendre exécutables.

“On se rend alors compte que l'IA n'est ni plus ni moins qu'un compilateur du langage naturel vers un langage de programmation. La difficulté réside dans le fait que ce compiler n'est pas déterministe.”

Dans cette logique, les tests reprennent une place centrale. Ils fournissent à l'IA un cadre de vérification concret : produire le minimum de code nécessaire pour faire passer un test, dans des cycles courts, avec un feedback rapide. Cette approche limite plusieurs défauts classiques du code généré par IA : génération de code mort, dérive fonctionnelle, régressions peu visibles, ou surproduction de complexité.

Chez Plop, nous utilisons un skill Claude Code ATDD qui récupère les user stories et leurs scénarios depuis la release priorisée, puis les implémente selon une boucle structurée : rédaction d'un test exprimé dans une DSL métier pour chaque scénario, échec initial du test, validation manuelle du test, commit, implémentation du code nécessaire au passage au vert, vérification manuelle, puis nouveau commit. Le tout s'appuie sur les autres skills définis par l'équipe pour le projet, notamment autour du DDD, de la clean architecture, des vertical slices ou des conventions locales.

Trunk-Based Development et réduction du rôle des PR

Chez Plop, nous cherchons également à limiter l'usage systématique des pull requests et à sortir du réflexe Git Flow.

Git Flow est régulièrement critiqué pour sa complexité opérationnelle : branches longues à vivre, divergences fréquentes, merges coûteux, synchronisation difficile. Ce modèle peut être pertinent dans certains contextes, notamment en open source ou dans des environnements très distribués, mais il n'est pas toujours le plus adapté à une équipe produit travaillant au quotidien sur une même base de code.

Le Trunk-Based Development propose une autre logique : travailler au plus près d'une branche commune, avec des branches très courtes lorsqu'elles existent, et des intégrations fréquentes. Cette approche suppose un niveau de confiance élevé, mais aussi des mécanismes de sécurisation beaucoup plus robustes.

Les pull requests, elles aussi, ont des limites bien connues : délais de revue, asynchronisme, files d'attente, feedback tardif, concentration de la validation sur quelques personnes. La question n'est donc pas simplement "faut-il garder les PR ?", mais "comment garantir la sécurité technique, le partage de connaissance et la progression des développeurs sans en faire un goulot d'étranglement ?".

Chez Plop, nous avons développé un plugin Claude Code qui permet d'aller dans cette direction : génération automatique de tests end-to-end en test-first pour les scénarios à implémenter, accompagnement pédagogique progressif, développement jusqu'à validation des tests, puis suggestions de refactoring alignées avec les bonnes pratiques définies sur le projet.

L'objectif n'est pas de supprimer le contrôle, mais de le déplacer : moins de validation tardive, plus de feedback immédiat, plus de garde-fous automatisés, et plus de cohérence avec les standards de l'équipe.

Tous ces process seront détaillés dans la suite de cette série, avec la publication en open source de nos outils. Le prochain article sera centré sur la partie discovery, avec l'event storming, l'impact mapping et un exemple de l'utilisation du plugin FigJam / serveur MCP et skill claude code.