{"id":896,"date":"2026-10-23T21:30:00","date_gmt":"2026-10-23T20:30:00","guid":{"rendered":"https:\/\/www.ludovicfavre.ch\/blog\/?p=896"},"modified":"2026-10-24T22:02:44","modified_gmt":"2026-10-24T21:02:44","slug":"du-prompt-iteratif-a-lequipe-dagents-sites-web-un-an-et-demi-plus-tard","status":"publish","type":"post","link":"https:\/\/www.ludovicfavre.ch\/blog\/2026\/10\/du-prompt-iteratif-a-lequipe-dagents-sites-web-un-an-et-demi-plus-tard\/","title":{"rendered":"Du prompt it\u00e9ratif \u00e0 l’\u00e9quipe d’agents : sites web, un an et demi plus tard"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

En mars 2025, j’avais racont\u00e9 ici comment j’ai red\u00e9velopp\u00e9 mon site avec React et CodeIgniter gr\u00e2ce \u00e0 Grok 3<\/a>, sans presque aucune exp\u00e9rience en React. La m\u00e9thode tenait en quelques \u00e9tapes : une poign\u00e9e de prompts, puis des allers-retours quand quelque chose coin\u00e7ait. Le r\u00e9sultat arrivait en quelques heures, m\u00eame si \u00ab tout ne marchait pas du premier coup \u00bb.<\/p>\n\n\n\n

Aujourd’hui, je travaille un autre site de domaine viticole (PHP, CodeIgniter, MariaDB), et la fa\u00e7on de travailler avec l’IA n’a plus grand-chose \u00e0 voir. On n’encha\u00eene plus les prompts dans une fen\u00eatre de chat. J’utilise Claude Code avec une configuration qui organise une petite \u00e9quipe virtuelle : des r\u00f4les, des documents et des points de contr\u00f4le. Ce billet se veut une suite logique du premier : ce qui a chang\u00e9, et pourquoi.<\/p>\n\n\n\n

Mars 2025 contre aujourd’hui :<\/em><\/p>\n\n\n\n

<\/th>Mars 2025<\/th>Aujourd’hui<\/th><\/tr>
Outil<\/td>Grok 3 dans un chat, compar\u00e9 \u00e0 GPT-4o, Claude 3.5 et Copilot<\/td>Claude Code dans l’\u00e9diteur, avec acc\u00e8s direct au code<\/td><\/tr>
M\u00e9thode<\/td>Prompts it\u00e9ratifs : je demande, j’essaie, je relance<\/td>Un circuit : besoins, conception, plan, impl\u00e9mentation, revue<\/td><\/tr>
Qui pilote<\/td>Moi, \u00e0 chaque \u00e9change<\/td>Un agent chef d’orchestre, et moi aux points de validation<\/td><\/tr>
Contexte fourni \u00e0 l’IA<\/td>Ce que je colle dans le prompt<\/td>Le code, la configuration et des r\u00e8gles projet \u00e9crites une fois pour toutes<\/td><\/tr>
V\u00e9rification<\/td>Surtout \u00e0 l’\u0153il, au fil des essais<\/td>Tests automatiques, relecture du code et de la s\u00e9curit\u00e9<\/td><\/tr>
Quand \u00e7a casse<\/td>Un nouveau prompt avec l’erreur<\/td>Une enqu\u00eate, une contre-expertise, puis seulement une correction<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

La diff\u00e9rence de fond : en 2025, la qualit\u00e9 d\u00e9pendait surtout de la r\u00e9ponse du mod\u00e8le. Aujourd’hui, elle d\u00e9pend surtout du cadre dans lequel il travaille.<\/p>\n\n\n\n

Un chef d’orchestre et des sp\u00e9cialistes<\/h2>\n\n\n\n

L’id\u00e9e centrale : la session Claude principale ne code pas. Elle joue le chef de projet et confie chaque \u00e9tape \u00e0 un sous-agent sp\u00e9cialis\u00e9. Chaque sous-agent a un seul r\u00f4le, ses propres outils et un format de r\u00e9ponse impos\u00e9.<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n
R\u00f4le<\/th>Ce qu’il fait<\/th><\/tr>
Analyste des besoins<\/td>Mesure ce que la demande touche dans le code et ce qu’elle va co\u00fbter<\/td><\/tr>
Concepteur technique<\/td>R\u00e9dige le document de conception<\/td><\/tr>
Planificateur<\/td>D\u00e9coupe la conception en t\u00e2ches<\/td><\/tr>
Ex\u00e9cutant<\/td>Impl\u00e9mente une t\u00e2che, rien de plus<\/td><\/tr>
Contr\u00f4leur qualit\u00e9<\/td>Lance les tests et les v\u00e9rifications, corrige ce qui casse<\/td><\/tr>
Relecteurs<\/td>Relisent le code et la s\u00e9curit\u00e9 \u00e0 la fin<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Le chef d’orchestre dit quoi<\/strong> faire et o\u00f9<\/strong>, jamais comment<\/strong>. Il donne \u00e0 l’ex\u00e9cutant un fichier de t\u00e2che, pas une liste de lignes \u00e0 modifier. Chaque sp\u00e9cialiste repart d’un contexte propre, ce qui \u00e9vite qu’une longue conversation finisse par tout m\u00e9langer.<\/p>\n\n\n\n

Toutes les demandes ne m\u00e9ritent pas ce circuit complet. Le chef d’orchestre classe d’abord la demande : petite<\/strong>, moyenne<\/strong> ou grande<\/strong>. Une petite correction passe directement \u00e0 l’impl\u00e9mentation ; une grosse fonctionnalit\u00e9 traverse toutes les \u00e9tapes. Il existe aussi un mode \u00ab Lite \u00bb, celui que j’utilise, qui r\u00e9duit le nombre d’agents appel\u00e9s sans supprimer les validations humaines.<\/p>\n\n\n\n

Des documents comme garde-fous<\/h2>\n\n\n\n

Pour une demande moyenne ou grande, rien ne se code avant que trois documents soient \u00e9crits et valid\u00e9s par un humain :<\/p>\n\n\n\n

    \n
  1. Le cahier des charges<\/strong> : ce que l’utilisateur doit pouvoir faire, et ce qui est explicitement exclu.<\/li>\n\n\n\n
  2. Le document de conception<\/strong> : comment on s’y prend, avec des crit\u00e8res d’acceptation v\u00e9rifiables.<\/li>\n\n\n\n
  3. Le plan de travail<\/strong> : la liste ordonn\u00e9e des t\u00e2ches.<\/li>\n<\/ol>\n\n\n\n

    Chaque document est relu par un agent relecteur, puis confront\u00e9 au code r\u00e9el par un agent v\u00e9rificateur. Celui-ci attrape les affirmations du type \u00ab la fonction X existe d\u00e9j\u00e0 \u00bb quand elle n’existe pas.<\/p>\n\n\n\n

    L’int\u00e9r\u00eat n’est pas la paperasse. C’est d’avoir des points d’arr\u00eat o\u00f9 je peux dire \u00ab non, pas comme \u00e7a \u00bb avant que cinquante fichiers soient modifi\u00e9s. Le deuxi\u00e8me b\u00e9n\u00e9fice de cette approche, c’est la reprise du d\u00e9veloppement avec des mini-\u00e9tapes, par exemple le lendemain ou apr\u00e8s une attente sur un quota de token expir\u00e9.<\/p>\n\n\n\n

    Pour diagnostiquer un bug : l’avocat du diable<\/h2>\n\n\n\n

    Le pi\u00e8ge classique avec une IA qui d\u00e9bogue, c’est qu’elle trouve une<\/strong> cause plausible, s’y accroche et corrige le sympt\u00f4me. Le framework Claude Code<\/em> s\u00e9pare donc le diagnostic en trois r\u00f4les :<\/p>\n\n\n\n

      \n
    1. L’enqu\u00eateur<\/strong> suit le chemin que prend l’ex\u00e9cution et liste tous les endroits o\u00f9 \u00e7a peut casser, preuves \u00e0 l’appui.<\/li>\n\n\n\n
    2. Le v\u00e9rificateur<\/strong> essaie de d\u00e9monter ce travail.<\/li>\n\n\n\n
    3. Le solveur<\/strong> propose des corrections seulement une fois les causes confirm\u00e9es.<\/li>\n<\/ol>\n\n\n\n

      Sur mon projet, il a d’ailleurs d\u00e9mont\u00e9 une hypoth\u00e8se qui me paraissait \u00e9vidente : je pensais que le probl\u00e8me venait du contr\u00f4leur alors que la cause \u00e9tait finalement dans la configuration d’un composant tiers.
      Pour chaque cause suppos\u00e9e, il joue l’avocat du diable<\/strong> :<\/p>\n\n\n\n

        \n
      • Et si ce comportement \u00e9tait en fait normal ?<\/li>\n\n\n\n
      • Quelle preuve contraire a-t-on oubli\u00e9e ?<\/li>\n\n\n\n
      • Quelle hypoth\u00e8se implicite est peut-\u00eatre fausse ?<\/li>\n<\/ul>\n\n\n\n

        Il va aussi chercher dans une source que l’enqu\u00eateur n’a pas consult\u00e9e : l’historique Git, la configuration ou la documentation officielle. Si la doc officielle contredit une hypoth\u00e8se, celle-ci est automatiquement affaiblie. Enfin, il ne d\u00e9signe pas un coupable unique : chaque cause est jug\u00e9e s\u00e9par\u00e9ment, car un bug en a souvent plusieurs.<\/p>\n\n\n\n

        Choisir comment impl\u00e9menter : le plus petit design possible<\/h2>\n\n\n\n

        Avant d’\u00e9crire du code, le concepteur suit une m\u00e9thode en sept \u00e9tapes. Le c\u0153ur tient en une question : quel est le design le plus simple qui atteint le r\u00e9sultat, et qu’est-ce qui oblige \u00e0 en faire plus ?<\/strong><\/p>\n\n\n\n

        Concr\u00e8tement :<\/p>\n\n\n\n

          \n
        1. Partir de l’existant.<\/strong> On trace le chemin le plus court qui livre le r\u00e9sultat avec ce que le code sait d\u00e9j\u00e0 faire.<\/li>\n\n\n\n
        2. Chercher ce qui manque.<\/strong> On ne garde que les besoins que ce chemin ne couvre pas.<\/li>\n\n\n\n
        3. Combler au moindre co\u00fbt.<\/strong> Pour chaque manque, on essaie d’abord de r\u00e9utiliser, de d\u00e9duire d’une donn\u00e9e existante ou de calculer \u00e0 la vol\u00e9e. On n’ajoute une table, une option ou une classe qu’en dernier recours.<\/li>\n\n\n\n
        4. Le test de soustraction.<\/strong> On retire chaque ajout, un par un, et on regarde si le r\u00e9sultat tient encore. Si oui, l’ajout dispara\u00eet.<\/li>\n<\/ol>\n\n\n\n

          Ce dernier test est redoutable contre la tendance des IA \u00e0 \u00ab bien faire \u00bb : un service, une interface et un fichier de config pour afficher trois lignes. Chaque \u00e9l\u00e9ment qui reste dans le design doit pouvoir dire quelle exigence casserait sans lui.<\/p>\n\n\n\n

          Les \u00e9tapes suivantes sont plus classiques : comparer au moins deux strat\u00e9gies, lister les risques avec une parade pour chacun, v\u00e9rifier les contraintes (version de PHP, h\u00e9bergeur, d\u00e9lais), puis consigner le choix et ses raisons dans le document de conception.<\/p>\n\n\n\n

          Par tranches ou par couches ?<\/h2>\n\n\n\n

          Une fois le design fix\u00e9, il reste \u00e0 d\u00e9cider dans quel ordre le construire. Il y a trois options :<\/p>\n\n\n\n

          Approche<\/th>Principe<\/th>Quand la choisir<\/th><\/tr>
          Verticale<\/td>Une fonctionnalit\u00e9 compl\u00e8te \u00e0 la fois, de la base de donn\u00e9es \u00e0 l’\u00e9cran<\/td>Fonctionnalit\u00e9s peu d\u00e9pendantes entre elles, utilisables d\u00e8s qu’elles sont finies<\/td><\/tr>
          Horizontale<\/td>Une couche \u00e0 la fois : d’abord les donn\u00e9es, puis la logique, puis l’affichage<\/td>Plusieurs fonctionnalit\u00e9s reposent sur un socle commun qui doit \u00eatre solide<\/td><\/tr>
          Hybride<\/td>Un m\u00e9lange, phase par phase<\/td>Besoins encore flous, ou passage d’un prototype \u00e0 la version finale<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

          Le crit\u00e8re de choix n’est pas l’effort. C’est le risque le plus faible et la v\u00e9rification la plus rapide.<\/p>\n\n\n\n

          Chaque t\u00e2che vise aussi un niveau de preuve, du plus fort au plus faible :<\/p>\n\n\n\n