Développer avec des agents IA : Le pipeline à 5 compétences que j'utilise

Ingénierie avec les agents IA : le pipeline en 5 compétences que j'utilise

J'ai perdu un dimanche entier sur une fonctionnalité Laravel qui aurait dû me prendre quatre heures.

Pas parce que le code était difficile. Le code était simple. J'ai perdu ce dimanche parce que j'ai laissé Claude Code commencer à écrire avant d'avoir répondu aux questions qui auraient dû orienter la conception. À mi-chemin du deuxième prompt, j'ai réalisé que l'agent avait supposé une relation un-à-plusieurs alors qu'il fallait du plusieurs-à-plusieurs, généré trente tests sur le mauvais contrat, et refactorisait maintenant avec assurance en s'enfonçant toujours plus dans la mauvaise abstraction. Au dîner, j'avais annulé la branche jusqu'à son premier commit et ouvert un fichier vierge.

C'est le mode d'échec de l'ingénierie avec les agents IA que personne ne met sur la page marketing. L'agent écrira volontiers tout ce que vous demandez. Il ne vous empêchera pas de demander la mauvaise chose. Et parce que chaque nouvelle conversation démarre sans aucune mémoire de la précédente, la même erreur vous attend lundi matin à moins que quelque chose dans votre workflow ne force les décisions à se prendre avant le code.

Quelques semaines après ce dimanche perdu, j'ai regardé un ingénieur nommé John Lindquist détailler le pipeline exact qu'il utilise pour éviter ça, construit autour de cinq compétences finement délimitées qui s'exécutent dans un ordre fixe. Le déclic s'est fait. J'ai reconstruit mon propre workflow autour de ces cinq mêmes compétences, je l'ai appliqué à trois projets en avril, et la différence était du genre à me faire éclater de rire si quelqu'un me l'avait décrite six mois plus tôt. Moins de code réécrit. Plus de fonctionnalités livrées. Moins de dimanches perdus.

Voici le pipeline. Cinq compétences, l'ordre dans lequel elles s'exécutent, ce que chacune fait réellement sous le capot, et les parties qui n'apparaissent pas dans les démos.

Le modèle mental qui change tout dans l'utilisation des agents

Avant les compétences, le modèle mental. Sautez cette partie et le reste de l'article n'est qu'une suite de commandes.

L'agent n'est pas un développeur junior qui s'améliorera au prochain sprint. L'agent est un expert sans mémoire — un ingénieur senior sans aucun souvenir d'hier, sans aucune connaissance de votre base de code qui n'ait été collée dans la fenêtre de contexte actuelle, et sans capacité à poser une question de suivi dans trois jours. Chaque session est le premier jour au travail.

Cela ressemble à un inconvénient. C'est en réalité la contrainte qui fait fonctionner le pipeline. Parce que l'agent n'a pas de mémoire, chaque décision doit être rendue explicite. Chaque hypothèse doit être mise en lumière. Chaque exigence doit être consignée quelque part de durable, dans un fichier que la prochaine session pourra lire. Le pipeline que je vais détailler n'est, au fond, qu'un système pour produire ces artefacts durables dans le bon ordre.

Il y a une idée plus profonde derrière tout ça, qui vient de The Design of Design de Frederick P. Brooks. Brooks décrit l'ingénierie comme l'exploration d'un arbre de conception — chaque décision se ramifie en d'autres décisions, et on ne comprend vraiment le design que lorsqu'on a parcouru les branches assez loin pour voir lesquelles se ferment et lesquelles s'ouvrent. La plupart des logiciels ratés viennent d'avoir coupé l'arbre trop tôt. On s'est engagé sur une feuille avant de comprendre le tronc.

Un agent sans mémoire coupera l'arbre à la toute première branche, à moins que quelque chose ne le force à aller plus loin. Ce quelque chose, c'est la première compétence du pipeline.

Compétence 1 : Grill Me — Interroger l'idée avant de coder

La compétence Grill Me est la plus contre-intuitive de la liste. On penserait que le premier réflexe avec un agent IA serait de lui donner un prompt et de le regarder écrire du code. Grill Me fait l'inverse. Vous confiez à l'agent une idée brute — trois phrases, un paragraphe, une demande de fonctionnalité à moitié formée — et il vous interroge.

L'entretien est structuré autour de l'arbre de conception de Brooks. L'agent identifie chaque point de décision que votre idée implique mais ne résout pas, et les passe en revue un par un. Pour une fonctionnalité courte, il peut poser seize questions. Pour quelque chose de complexe — un système de facturation multi-tenant, un pipeline de contenu avec des workflows à embranchements, une nouvelle surface d'authentification — je l'ai vu générer trente à cinquante questions avant d'être satisfait. La plupart de ces questions sont celles que j'aurais dû me poser moi-même et que je ne me posais pas.

Voici à quoi ressemblait une session Grill Me sur un vrai projet le mois dernier. J'ai dit que je voulais ajouter des « espaces de travail d'équipe » à un tableau de bord SaaS. L'agent est revenu avec :

1. Un espace de travail est-il détenu par un seul utilisateur ou par une équipe ?
2. Si c'est une équipe, un utilisateur peut-il appartenir à plusieurs équipes simultanément ?
3. Les espaces de travail héritent-ils des permissions de l'organisation parente ou définissent-ils les leurs ?
4. Que se passe-t-il pour les ressources d'un espace de travail lorsque son propriétaire quitte l'organisation ?
5. La facturation de l'espace de travail est-elle intégrée à la facture de l'organisation ou facturée séparément ?

J'étais sur le point de demander à Claude « ajoute des espaces de travail d'équipe au tableau de bord ». Si je l'avais fait, l'agent aurait fait cinq hypothèses cachées à ma place, écrit du code basé sur ces hypothèses, et j'aurais découvert l'incohérence autour de la question 4, en production, quand quelqu'un aurait quitté une équipe. L'interrogatoire a rendu les hypothèses visibles avant qu'une seule ligne de code n'existe.

Le schéma est le même à chaque fois. La plupart des questions semblent évidentes avec le recul, ce qui est précisément la raison pour laquelle elles méritent d'être posées — les questions évidentes-après-coup sont celles qu'on saute parce que notre cerveau nous dit qu'on connaît déjà la réponse. L'agent n'a pas ce biais. Il parcourt simplement l'arbre.

On peut considérer la sortie comme un transcript, mais le transcript n'est pas le livrable. Le livrable est la compréhension partagée — un état où vous et l'agent êtes d'accord sur chaque décision conséquente qu'implique la fonctionnalité. Une fois que vous l'avez, la compétence suivante prend le relais.

Compétence 2 : Write a PRD — Figer la compréhension partagée sous forme durable

La sortie de l'entretien meurt au moment où la fenêtre de chat se ferme. C'est la taxe de l'agent-sans-mémoire que j'ai mentionnée plus tôt. La compétence Write a PRD existe pour résoudre ce problème en un seul geste : elle convertit le transcript de Grill Me en un document d'exigences produit (PRD), formaté pour un lecteur IA, et le soumet comme ticket dans le système de suivi de votre projet — généralement une issue GitHub.

Il y a trois choses à remarquer dans la façon dont cette compétence est structurée.

Premièrement, elle est écrite pour le prochain agent, pas pour vous. Un PRD traditionnel se lit comme un document commercial. Celui-ci se lit comme une signature de fonction avec de la prose. Chaque exigence est testable. Chaque contrainte est explicite. Chaque décision de conception issue de l'interrogatoire est capturée avec le raisonnement qui la sous-tend. La prochaine session n'aura pas accès à votre mémoire de pourquoi vous avez choisi le plusieurs-à-plusieurs plutôt que le un-à-plusieurs — mais elle aura accès au PRD, et le PRD le lui dira.

Deuxièmement, il vit dans le système de suivi. Pas dans un dossier docs/, pas dans Notion, pas collé dans un chat. La raison est importante : le système de suivi est l'endroit où chaque autre outil — humains, agents, CI, compétences en aval — cherchera la source de vérité pour cette fonctionnalité. Mettre le PRD ailleurs crée un embranchement dans l'historique de conception qui vous hantera dans six semaines.

Troisièmement, il vous engage. Une fois le PRD sur GitHub, vous avez transformé une conversation en artefact. Le vous-du-futur peut le relire. Le Claude-du-futur peut le relire. Un coéquipier qui rejoint le projet la semaine prochaine peut le relire. La conversation, avec ses tangentes et ses pensées à moitié formées, a disparu. Ce qui survit, c'est le design résolu.

J'avais l'habitude de considérer les PRD comme quelque chose que les product managers écrivaient pour justifier leur salaire. Regarder un agent sans mémoire traverser une fonctionnalité complexe en utilisant un PRD concis d'une page comme seule entrée de contexte m'a complètement fait changer d'avis. Le PRD n'est pas de la bureaucratie. C'est la mémoire de travail de l'agent entre les sessions.

Compétence 3 : PRD to Issues — Tranches verticales, pas couches horizontales

C'est là que la plupart des workflows IA s'effondrent. Vous avez un PRD. Vous le confiez à l'agent. L'agent décide d'« implémenter la fonctionnalité ». Quarante-cinq minutes plus tard, vous avez trois cents lignes d'abstraction à moitié construite et aucun logiciel fonctionnel.

La solution est la compétence PRD to Issues, et elle s'inspire directement d'un pattern qu'Andy Hunt et Dave Thomas ont appelé les balles traçantes dans The Pragmatic Programmer. Une balle traçante est une tranche verticale — une implémentation fine, de bout en bout, qui traverse chaque couche du système de l'interface utilisateur à la base de données, fait une petite chose du début à la fin, et prouve que le design fonctionne de bout en bout avant qu'aucune couche ne soit complètement construite.

PRD to Issues prend le PRD et le décompose en tranches verticales, chacune dimensionnée pour une seule balle traçante. Pour la fonctionnalité d'espaces de travail d'équipe que j'ai mentionnée plus tôt, la compétence a découpé le PRD en quatre tickets :

1. Ticket 1 (sans bloquant) : Créer le modèle workspace, la migration, et un seul endpoint qui permet à un utilisateur authentifié de créer un espace de travail pour lui-même. Interface : un bouton. Tests : création du modèle, l'endpoint retourne 201, le bouton envoie le bon payload.
2. Ticket 2 (bloqué par le Ticket 1) : Ajouter l'appartenance multiple — permettre à un utilisateur d'appartenir à plusieurs espaces de travail, avec une table de jointure workspace_user et un sélecteur d'espace dans la barre de navigation.
3. Ticket 3 (bloqué par le Ticket 1, parallèle au Ticket 2) : Ajouter les règles d'héritage de permissions du PRD. Pure logique métier avec sa propre suite de tests.
4. Ticket 4 (bloqué par les Tickets 2 et 3) : Ajouter la logique de consolidation de facturation et la génération de lignes de facture.

Deux choses à noter dans cette décomposition. Premièrement, le Ticket 1 est une fonctionnalité complète et opérationnelle en soi — si vous vous arrêtiez après le Ticket 1, vous auriez un logiciel livrable. C'est la promesse de la balle traçante : chaque tranche est utilisable de bout en bout. Deuxièmement, le graphe de blocage est explicite. Les Tickets 2 et 3 peuvent s'exécuter en parallèle, ce qui signifie que je peux lancer deux agents, un pour chaque ticket, et ils travailleront simultanément sans se marcher dessus.

Ce parallélisme est le déverrouillage que la plupart des équipes n'ont pas encore intégré. Quand on cesse de penser aux agents comme un travailleur unique et qu'on commence à les considérer comme un pool de travailleurs avec des dépendances explicites, le débit d'une session d'ingénierie change de forme. J'ai détaillé le modèle mental plus large dans l'architecture en essaim d'agents pour Claude Code — PRD to Issues est l'artefact concret qui rend le travail en mode essaim sûr plutôt que chaotique.

L'autre chose que PRD to Issues empêche est le pire mode d'échec de l'ingénierie IA : le piège de la tranche horizontale. Sans découpage vertical, un agent aura tendance à construire tous les modèles d'abord, puis tous les contrôleurs, puis toutes les vues, puis tous les tests. À mi-parcours, votre branche a une couche de données complète que rien n'utilise, une interface mockée sur le mauvais contrat, et zéro logiciel fonctionnel. Avec le découpage vertical, vous avez toujours un système qui fonctionne ; vous avez simplement un système fonctionnel plus petit que la fonctionnalité finale.

Compétence 4 : TDD — Rouge, Vert, Refactoriser (et pourquoi le refactoring fait mal)

Maintenant vous avez le PRD, vous avez les tickets, et vous êtes prêt à écrire du code. C'est là que la compétence TDD prend le relais, et là où le pipeline commence à révéler comment les agents IA se comportent réellement sous pression.

La compétence TDD exécute la boucle classique rouge/vert/refactoriser, mais adaptée aux agents :

1. Rouge : L'agent écrit un test en échec pour le prochain comportement du ticket en cours. On lance le test. On confirme qu'il échoue pour la bonne raison. (Cette sous-étape est importante — les agents écrivent parfois un test qui échoue pour la mauvaise raison, et vous le découvrirez deux heures plus tard quand « passe » ne signifiera pas ce que vous pensiez.)
2. Vert : L'agent écrit le minimum de code nécessaire pour faire passer le test. On lance le test. On confirme qu'il passe.
3. Refactoriser : L'agent améliore le code sans changer le comportement. On lance le test. On confirme qu'il passe toujours.

Les étapes 1 et 2 fonctionnent magnifiquement avec les agents. Claude est excellent pour écrire des tests ciblés, tout aussi excellent pour écrire des implémentations minimales qui font passer ces tests. La première fois que je l'ai regardé dévorer une classe de service Laravel en vingt minutes, avec chaque méthode couverte par un test écrit avant que la méthode n'existe, j'ai sincèrement eu l'impression d'avoir mal fait mon travail pendant une décennie.

L'étape 3 est là où les problèmes résident.

Voici la partie honnête de tout cet article. Les agents IA sont profondément réticents à refactoriser leur propre code dans le même contexte. Le schéma est le suivant : vous écrivez un test vert, l'agent écrit le code minimal, vous lui dites de refactoriser, et il renvoie le même code avec un commentaire disant « c'est déjà bien structuré ». Il ne ment pas. De son propre contexte, le code a effectivement l'air correct. Le problème est que l'agent a fixé sa propre logique pendant une heure et a perdu la perspective nécessaire pour détecter l'odeur.

Le contournement qui fonctionne pour moi — et que la compétence TDD intègre — est de sortir l'étape de refactoring dans une session d'agent fraîche. Nouvelle fenêtre de contexte. Aucun historique d'écriture du code original. Vous confiez à la nouvelle session le test passé-du-rouge-au-vert et l'implémentation verte, et vous demandez de refactoriser. Sans le biais de l'auteur original, l'agent est disposé à remanier le code en profondeur. Le test lui donne un contrat contre lequel refactoriser. Le refactoring se termine. Vous committez.

C'est le moment que beaucoup de gens ratent quand ils disent « l'IA ne peut pas vraiment faire du TDD ». Elle le peut — mais seulement si vous traitez chaque phase de la boucle rouge/vert/refactoriser comme une session d'agent séparément délimitée, pas comme une seule conversation. La compétence impose ce cadrage. Le principe est le même que celui que j'ai couvert dans pourquoi le prompting précis surpasse le prompting astucieux — l'agent n'est aussi bon que le contexte que vous lui donnez, et cela inclut le contexte que vous ne lui donnez pas.

Il y a un deuxième élément subtil que la compétence TDD gère. Elle refuse de laisser l'agent sauter l'étape rouge. Si vous laissez un agent écrire un test contre du code existant, il écrira un test qui passe du premier coup — et vous n'aurez aucune idée si le test exerce réellement le comportement qui vous importe. La compétence bloque cela en imposant l'état d'échec initial. On n'avance pas tant que le test n'a pas échoué pour une raison qu'on peut articuler.

Compétence 5 : Improve Codebase Architecture — Quand le pipeline boucle sur lui-même

Les quatre compétences précédentes vous mèneront à une fonctionnalité opérationnelle. Elles ne suffiront pas, en soi, à empêcher votre base de code de se dégrader. Au fil de cinq ou dix fonctionnalités, vous accumulerez le type de dette structurelle qui n'apparaît dans aucune PR individuelle mais rend progressivement chaque fonctionnalité future plus difficile à construire. La cinquième compétence est ce qui rattrape cette dérive.

Improve Codebase Architecture est différente des autres. Elle ne s'exécute pas dans le pipeline linéaire — elle s'exécute périodiquement, entre les cycles de fonctionnalités, comme une passe de nettoyage. Son rôle est d'examiner la base de code actuelle et de proposer des refactorisations délibérées, puis de transformer les meilleures en nouveaux tickets qui réintègrent le pipeline par le haut.

Son fonctionnement est différent de tout le reste du workflow. La compétence lance trois sous-agents parallèles ou plus, chacun prompté pour proposer un design d'interface radicalement différent pour la zone de la base de code à refactoriser. Trois sous-agents parce qu'un seul confirmerait le statu quo et deux se cantonneraient à un binaire — trois est le plus petit nombre qui force de véritables alternatives à émerger.

J'ai exécuté ceci le mois dernier sur un module de pipeline de contenu devenu désordonné. Les trois sous-agents sont revenus avec :

• Proposition A : Un pipeline purement fonctionnel d'étapes composables, chacune étant une fonction pure sur un payload typé.
• Proposition B : Un design événementiel avec une file d'attente et un ensemble de consommateurs indépendants.
• Proposition C : Une hiérarchie traditionnelle de classes de service avec une classe de base et trois stratégies concrètes.

L'agent parent a ensuite évalué les trois par rapport aux contraintes réelles de la base de code — couverture de tests, forme de déploiement, modèle de données existant — et a recommandé un hybride de A et B : des étapes purement fonctionnelles à l'intérieur, dispatchées sur l'infrastructure de file d'attente existante. Aucune des trois propositions pures n'était la bonne réponse. L'hybride l'était. Et je n'y serais jamais arrivé seul, parce que mon cerveau était ancré à la forme existante des classes de service depuis des mois.

La sortie de la compétence est un RFC, également déposé comme issue GitHub. Le RFC décrit la refactorisation proposée, les alternatives considérées et rejetées, le raisonnement derrière la recommandation, et le chemin de migration incrémentale suggéré. Une fois le RFC approuvé, il réintègre le pipeline à l'étape 1 — vous passez la proposition de refactoring au Grill Me, écrivez un PRD pour elle, la décomposez en tickets, et appliquez le TDD.

Ce cycle est la partie la plus difficile à communiquer sans le voir fonctionner. Le pipeline n'est pas vraiment linéaire. C'est une boucle. Les fonctionnalités passent par 1→2→3→4. Les raffinements architecturaux périodiques passent par 5→1→2→3→4. Sur un trimestre, la base de code évolue dans une direction que vous avez choisie plutôt que de dériver dans une direction qu'elle a trouvée.

La chronologie — Comment une vraie fonctionnalité traverse le pipeline

Permettez-moi de détailler à quoi cela ressemble concrètement dans le temps, pour la fonctionnalité d'espaces de travail d'équipe que je n'arrête pas de mentionner, afin que l'abstraction prenne forme.

Lundi matin, 45 minutes. Je lance Grill Me sur l'idée brute. Vingt-deux questions. J'y réponds. À la fin de la session, l'arbre de conception a été parcouru assez loin pour que je puisse décrire la fonctionnalité en un seul paragraphe sans hésiter.

Lundi matin, 20 minutes. Je lance Write a PRD. La compétence génère le document à partir du transcript d'interrogatoire, je le relis, modifie deux phrases, et le soumets comme issue GitHub. Issue #341.

Lundi matin, 15 minutes. Je lance PRD to Issues. Il décompose #341 en les quatre sous-tickets que j'ai décrits plus haut, avec le graphe de blocage attaché. Issues #342, #343, #344, #345.

Lundi après-midi à mardi. Je lance TDD sur le ticket #342 (la tranche fondamentale). Environ quatre heures au total. Rouge, vert, refactoring sur chaque comportement. Je garde l'étape de refactoring dans une fenêtre de contexte séparée. Le ticket se ferme.

Mercredi. Je lance deux sessions TDD en parallèle, une sur #343 et une sur #344. Ce sont des tickets indépendants par conception. Environ trois heures chacune, exécutées dans des fenêtres parallèles. Les deux se ferment.

Jeudi matin. Je lance TDD sur #345, la consolidation de facturation. Environ cinq heures, parce que la surface de test est plus large. Se ferme en fin de journée.

Vendredi. Je lance Improve Codebase Architecture sur le module workspace. Les trois sous-agents proposent trois structures. Le parent recommande une petite refactorisation pour extraire la logique de vérification des permissions dans un module pur. RFC déposé comme issue #346. Je décide que ça vaut le coup, relance la boucle, et livre la refactorisation vendredi après-midi.

Total écoulé : environ trente heures de travail concentré sur cinq jours, pour une fonctionnalité que j'aurais estimée à deux semaines avant de commencer à utiliser ce pipeline. La raison de cette compression n'est pas que les agents tapent plus vite que moi. Ils le font — mais la saisie n'a jamais été le goulot d'étranglement. La raison est que le pipeline a éliminé presque tous les cycles de retravail qui dévoraient habituellement les trois jours du milieu de la semaine.

La partie honnête — Où ce pipeline s'effondre

Je vous ai dit ce qui fonctionne. L'article ne mérite votre confiance que si je vous dis aussi où ça casse.

Le pipeline suppose que vous pouvez écrire de bonnes réponses pendant le Grill Me. Si vous ne pouvez pas articuler ce que vous voulez réellement, les questions ne font qu'exposer la lacune. La compétence n'est pas un substitut à la réflexion — c'est un catalyseur de réflexion. J'ai vu des développeurs essayer d'utiliser Grill Me comme moyen de « découvrir ce qu'ils veulent » en cours de session, et le résultat est un transcript rempli de « Je ne sais pas, qu'en pensez-vous ? » qui produit un PRD qui reflète essentiellement les préférences de l'agent, déguisées en celles de l'utilisateur. Ce PRD sera ensuite le contrat auquel chaque agent en aval sera tenu, et vous découvrirez au ticket #4 que les préférences de l'agent n'étaient pas les vôtres.

Le problème de refactoring du TDD ne se résout pas entièrement, même avec une session fraîche. Parfois le nouvel agent regardera le code et produira un nettoyage marginal qui passe à côté du problème structurel plus profond. Le schéma sur lequel j'ai convergé : je lance le refactoring deux fois, dans deux sessions fraîches séparées, et je regarde les deux résultats. S'ils concordent, je committe. S'ils divergent, la divergence est généralement là où vit le vrai refactoring, et soit je choisis le meilleur des deux, soit je renvoie les deux à un troisième agent pour réconciliation. C'est plus lent que je ne le voudrais.

Les tickets parallèles ne sont pas vraiment gratuits. Quand je lance deux sessions TDD en parallèle sur des tickets indépendants, je divise ma propre attention — et c'est le vrai coût, pas le calcul de l'agent. Le graphe de blocage dans PRD to Issues empêche les agents d'interférer entre eux sur le code, mais il ne peut pas m'empêcher de mal gérer le changement de contexte. Je me limite à deux sessions parallèles pour cette raison. Trois me brisent.

La compétence d'architecture peut sur-refactoriser. La première fois que j'ai lancé Improve Codebase Architecture sur un module sain, elle a généré trois propositions sérieuses de refactorisation pour du code qui n'avait pas besoin d'être refactorisé. La compétence a un biais vers la recherche de travail. Vous êtes le frein. Si aucune des trois propositions ne rend la base de code matériellement meilleure, la bonne réponse est de passer la refactorisation et de relancer la compétence dans deux mois. La discipline compte plus ici que dans toute autre étape.

La longueur d'une compétence n'est pas sa qualité. Les deux meilleures compétences de ce pipeline — Grill Me et PRD to Issues — sont courtes. Peut-être une centaine de lignes chacune. Les auteurs de compétences que j'ai vus produire les pires résultats sont ceux qui traitent la longueur comme un indicateur d'exhaustivité. La précision dans quand une compétence se déclenche et ce qu'elle produit compte bien plus que la quantité de texte d'instruction qu'elle contient. J'ai couvert ce pattern dans comment les compétences Claude exécutent réellement un workflow — le même principe s'applique ici, au double.

Comment cela transforme la journée d'un ingénieur

Prenez du recul par rapport aux cinq compétences un instant. La forme du travail que le pipeline produit est véritablement différente de ce que je faisais en 2024, et ça vaut le coup de dire tout haut ce qui a changé.

J'écris moins de code. J'écris plus de contrats. Le PRD est un contrat. Les tickets sont des contrats. Les tests sont des contrats. Les RFC sont des contrats. L'implémentation réelle est de plus en plus quelque chose qu'un agent produit contre un contrat que j'ai rédigé, et mon temps-passé-par-fonctionnalité s'est fortement déplacé vers la rédaction de contrats.

Je pense davantage en arbres de décision, moins en syntaxe. Les trois premières compétences du pipeline portent toutes sur la résolution de l'arbre de conception avant qu'aucun code n'existe. Les deux suivantes portent sur l'exécution propre contre l'arbre résolu. Une fois que j'ai remarqué ce pattern, mes habitudes d'ingénierie en dehors du pipeline ont aussi commencé à changer — je me surprends, en pleine conversation sur une fonctionnalité, à poser le genre de questions que Grill Me pose, avant que le moindre outil ne s'exécute.

Je m'appuie sur le parallélisme d'une façon que je n'avais jamais pratiquée. Deux sessions TDD simultanées sur des tickets indépendants ressemblent à une astuce de productivité. C'est en réalité un mode d'ingénierie différent. La compétence mentale qu'il requiert est la capacité à concevoir correctement le graphe de blocage en amont — si vous décomposez mal les tickets, les sessions parallèles entrent en collision. Si vous les décomposez bien, le parallélisme est presque gratuit. Le pipeline punit la mauvaise décomposition et récompense la bonne, ce qui est une boucle de rétroaction que je n'avais jamais eue auparavant.

Je traite la mémoire comme un artefact, pas comme une hypothèse. Chaque décision importante vit dans un endroit que le futur Claude peut lire. Le PRD, les tickets, les noms de tests, les messages de commit, les RFC — tout est structuré comme si un ingénieur senior sans mémoire pouvait débarquer sur le dépôt demain sans contexte, parce qu'en pratique, c'est exactement ce qui se passe chaque fois que j'ouvre une nouvelle session d'agent.

Si vous voulez un regard plus approfondi sur la façon dont le système de compétences sous-jacent permet ce type d'accumulation, le guide de l'architecture des compétences d'agent est le billet que je vous indiquerais ensuite. Le pipeline que je décris ici est ce à quoi ressemblent les compétences quand on les connecte avec intention.

Le cours que je suis en train de regarder

Je serais malhonnête si je ne mentionnais pas d'où la plupart de ces patterns ont émergé pour moi. Matt Pocock — l'ingénieur derrière une grande partie de l'éducation TypeScript sur laquelle je me suis discrètement appuyé pendant des années — a animé une cohorte de deux semaines appelée Claude Code for Real Engineers du 30 mars au 13 avril 2026, et le programme correspond presque exactement au pipeline que je viens de décrire. Protocole Plan/Execute/Clear. Implémentation par balles traçantes. Rédaction de PRD pour lecteurs IA. Le pattern de boucle autonome à la fin de la deuxième semaine.

Le cours coûte 795 $ sur AI Hero. Je ne suis pas affilié, je ne touche pas de commission, et je ne me suis pas inscrit à la cohorte live — la version à la demande est ce qui est disponible maintenant, et j'évalue si la structure justifie le coût étant donné que la plupart des patterns sont publics et reproductibles si vous êtes prêt à les assembler. L'avis honnête : si vous voulez comprimer la courbe d'apprentissage de mois en semaines et que vous préférez ne pas reconstituer le pipeline de cinq compétences à partir d'articles de blog comme celui-ci, la cohorte est un pari raisonnable. Si vous êtes patient et que le pipeline ci-dessus vous donne assez pour avancer, vous pouvez probablement y arriver seul.

Ce que je dirai, c'est que la catégorie qu'occupe ce cours — la pratique d'ingénierie structurée autour des agents IA, par opposition au contenu « trucs et astuces » — est celle qui va le plus compter au cours des deux prochaines années. Le marché va se diviser entre les ingénieurs qui traitent l'IA comme un accélérateur de frappe et les ingénieurs qui la traitent comme un collaborateur sans mémoire qui a besoin d'un vrai pipeline. Le deuxième groupe va tourner en rond autour du premier en termes de livraisons.

Au-delà des cinq compétences — Vers quoi j'avance

Le pipeline tel quel est solide. Ce n'est pas là que je veux qu'il s'arrête.

Ce sur quoi j'expérimente en ce moment est l'intégration d'agents autonomes aux extrémités. Plus précisément : un agent planifié qui relance Improve Codebase Architecture sur le dépôt toutes les deux semaines, dépose des RFC comme issues, et me tague pour revue. Je n'ai pas besoin de me souvenir de lancer la compétence. La compétence se lance elle-même. Les RFC arrivent dans ma file. Soit j'approuve et je réintègre le pipeline, soit je ferme en wontfix. Le problème de dérive architecturale devient une case à cocher passive au lieu d'une habitude active.

L'autre volet est la discipline de fenêtre de contexte à travers le pipeline. Chaque étape produit un artefact qui devient le contexte d'entrée de l'étape suivante. Si l'artefact est trop verbeux, le contexte de l'étape suivante se remplit et l'agent devient moins performant. L'art consiste à rendre chaque artefact aussi concis que possible tout en restant un contrat complet. J'ai rogné mon template de PRD au cours du dernier mois, et la qualité du code en aval s'est mesurément améliorée à chaque paragraphe que j'ai supprimé parce qu'il ne faisait pas son poids. Ce principe — l'idée que moins de contexte précisément choisi bat plus de contexte vaguement sélectionné — est le levier le plus puissant de l'ingénierie avec les agents IA dont personne ne parle dans les tutoriels.

Le troisième volet est l'application agnostique du langage. J'ai fait tourner ce pipeline sur du Laravel, du Next.js, un pipeline de données Python, et un dépôt d'infrastructure riche en Bash. Il fonctionne sur les quatre. Les compétences ne savent pas dans quel langage elles opèrent ; elles opèrent sur l'arbre de conception, le PRD, les tickets, les tests et les patterns architecturaux. Cet agnosticisme linguistique est la propriété qui me fait penser que ce pipeline est le bon dans lequel investir pour les deux prochaines années, quel que soit le stack sur lequel je finirai par travailler.

Ce qu'il faut faire avant lundi matin

Si vous avez lu jusqu'ici et que vous êtes convaincu par l'idée, voici l'ordre dans lequel je vous suggère de l'essayer. N'installez pas les cinq compétences d'un coup. Le pipeline est séquentiel pour une bonne raison, et essayer de l'adopter en Big Bang submergera le workflow que vous avez actuellement.

1. Cette semaine : Installez Grill Me. Utilisez-le sur la prochaine fonctionnalité que vous auriez autrement simplement demandé à Claude d'écrire. Remarquez les questions qu'il pose. Remarquez lesquelles vous n'auriez pas pu répondre sans lui. C'est la valeur.
2. La semaine prochaine : Ajoutez Write a PRD. Faites passer la sortie de Grill Me à travers. Déposez le PRD comme issue GitHub. Habituez-vous à ce que l'artefact vive quelque part de durable.
3. La semaine d'après : Ajoutez PRD to Issues. Regardez vos fonctionnalités se décomposer en balles traçantes. Apprenez à distinguer les bonnes tranches verticales des mauvaises — les mauvaises reviennent sous forme d'un ticket unique qui ne se ferme pas.
4. Quatrième semaine : Ajoutez TDD. Préparez-vous à la friction de l'étape de refactoring. Résolvez-la en lançant le refactoring dans une session séparée.
5. Sixième semaine : Ajoutez Improve Codebase Architecture. Lancez-la une fois. Voyez si vous faites assez confiance au résultat pour agir dessus.

À la huitième semaine, vous aurez un pipeline fonctionnel. À la douzième, vous concevrez vos propres variations. Au sixième mois, le workflow vous semblera aussi naturel que celui d'avant les agents, sauf qu'il sera plus rapide, plus délibéré, et plus difficile à casser.

Le dimanche que j'ai perdu sur Laravel était celui dont j'avais besoin. C'était le prix pour apprendre, dans mes tripes, que l'ingénierie avec les agents IA ne consiste pas à taper des prompts et regarder le code apparaître. Il s'agit de produire les bons artefacts dans le bon ordre pour qu'un expert sans mémoire puisse reprendre le travail à tout moment et le poursuivre sans perdre le design. Le pipeline est la façon de rendre cela possible.

Je n'ai plus perdu un seul dimanche comme celui-là depuis.

Questions fréquemment posées

Que signifie concrètement « ingénierie avec les agents IA » ?

L'ingénierie avec les agents IA consiste à traiter l'agent comme un ingénieur senior sans mémoire qui a besoin que chaque décision, exigence et contrainte soit capturée comme artefact durable avant que le code ne soit écrit. En pratique, c'est un pipeline fixe — Grill Me, PRD, Issues, TDD, Refactoring architectural — où chaque étape produit le contexte dont dépend la suivante. Pour le détail complet, consultez les sections du pipeline ci-dessus.

Ces compétences fonctionnent-elles uniquement dans Claude Code ?

Les cinq compétences sont agnostiques au langage et au concept — les patterns sous-jacents (arbre de conception, tranches verticales, rouge/vert/refactoriser, sous-agents parallèles) fonctionnent avec tout runtime d'agent prenant en charge les compétences ou des instructions de portée équivalente. Claude Code est l'environnement dans lequel je les exécute parce que le système de compétences y est le plus mature, mais le même pipeline peut être reproduit sur d'autres harnais avec des commandes slash personnalisées ou des prompts système.

Pourquoi les agents IA refusent-ils de refactoriser leur propre code ?

Les agents peinent à refactoriser dans le même contexte parce qu'ils ont raisonné sur le code pendant toute la session et ont perdu la perspective nécessaire pour détecter les défauts. La solution est d'ouvrir une session d'agent fraîche sans contexte préalable, de lui confier uniquement le test passé-du-rouge-au-vert et l'implémentation verte, et de lui demander de refactoriser contre le contrat du test. Le principe est couvert dans la section TDD ci-dessus.

Qu'est-ce qu'une « tranche verticale » ou « balle traçante » dans ce contexte ?

Une tranche verticale est une implémentation de bout en bout qui traverse chaque couche du système — interface utilisateur, API, logique métier, base de données — mais ne fait qu'une petite chose du début à la fin. Elle trouve son origine dans le pattern « balle traçante » de The Pragmatic Programmer et constitue l'unité de travail en laquelle PRD to Issues décompose une fonctionnalité. Le résultat est que chaque ticket que vous fermez livre un logiciel fonctionnel, pas une couche à moitié construite.

Le cours Claude Code for Real Engineers vaut-il 795 $ ?

La cohorte couvre les mêmes patterns décrits dans cet article — Plan/Execute/Clear, rédaction de PRD pour lecteurs IA, implémentation par balles traçantes, boucles autonomes — dans un format structuré de deux semaines. Elle vaut le coût si vous voulez comprimer la courbe d'apprentissage et préférez un enseignement guidé à l'assemblage du pipeline à partir de sources publiques. La version à la demande est actuellement disponible ; les cohortes en direct sont relancées périodiquement.

Travaillons ensemble

Vous cherchez à construire des systèmes IA, automatiser des workflows, ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous aider.

• Fiverr (développements personnalisés et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io