00:00:00Tout le monde sait qu'il faut un framework pour travailler avec des agents de codage, mais peu de gens
00:00:04en ont un qui soit simple, qui leur soit propre et qu'ils puissent faire évoluer. Il existe
00:00:09énormément de frameworks sur-conçus sur GitHub. Tous ces systèmes multi-agents que
00:00:15les gens créent... je respecte leur travail, mais souvent, on a juste besoin de quelque chose
00:00:19de très simple qui fait le travail. Parce que je sais que vous avez de bonnes idées à réaliser,
00:00:24et vous ne voulez pas passer plus de temps à créer vos workflows agentiques qu'à
00:00:29coder réellement. C'est donc ce que je vous propose. Voici mon framework ultra simple
00:00:35que j'utilise à chaque fois que je lance un nouveau projet avec mon agent de codage. Le
00:00:40développement « brownfield », sur une base de code existante, est un peu différent. Ce sera pour une autre vidéo.
00:00:45Ici, on se concentre sur le « Greenfield ». On veut un framework simple pour démarrer
00:00:50le plus vite possible sur du neuf. Tout ce que je couvre ici est universel.
00:00:56Ces principes s'appliqueront quel que soit l'agent de codage que vous utilisez. Cette vidéo
00:01:00comporte deux parties, et je vais construire un projet en direct avec vous tout en expliquant
00:01:05pour que ce soit très concret. Pour l'instant, ma base de code est quasi vide,
00:01:11à part ma couche IA. J'ai importé quelques commandes et compétences. C'est mon point de départ
00:01:16pour chaque projet. Nous allons créer quelque chose de zéro,
00:01:21nous devons donc commencer par la planification initiale : créer ce qu'on appelle un PRD.
00:01:27C'est le périmètre de travail initial pour créer le produit minimum viable (MVP). Il y a
00:01:32beaucoup à faire, comme configurer notre couche IA initiale avant de passer au code.
00:01:37Ensuite, on prend notre PRD et on le divise en phases de travail, qu'on boucle avec des cycles PIV.
00:01:43J'expliquerai ce que c'est avec un exemple. Tout au long de
00:01:47l'implémentation, je couvrirai les quatre règles d'or à suivre en permanence.
00:01:52Elles s'intégreront naturellement pendant la création du PRD, de la couche IA
00:01:57et des boucles PIV. Par exemple, la gestion du contexte.
00:02:03Le contexte est votre ressource la plus précieuse avec les assistants IA. Ce sera un thème central.
00:02:08Il y a aussi la création de commandes et de compétences, et l'état d'esprit d'évolution du système,
00:02:14car le but est de créer quelque chose de fiable et de
00:02:18reproductible. J'en parlerai au fur et à mesure. Ce sont les thèmes
00:02:23clés que vous verrez. C'est une vidéo riche en valeur. Commençons
00:02:28par la planification initiale : créer ce que j'appelle la couche IA. Je vais vous expliquer
00:02:34ce que c'est et nous allons la construire ensemble. Votre couche IA, ce sont tous les actifs
00:02:39créés dans votre code pour servir de contexte à l'agent. Comme votre PRD : qu'allons-nous construire ?
00:02:45Vos règles globales : comment allons-nous construire ? Les commandes : pour avoir des workflows
00:02:50réutilisables. On se focalisera d'abord sur la principale. Et enfin les sous-agents, pour déléguer
00:02:55la recherche. En général, pour ma couche IA — et je vous mets cette ressource à disposition —
00:03:01j'ai un ensemble de commandes génériques que j'importe dans chaque projet. Ensuite,
00:03:07à mesure que le code se développe, je fais évoluer ces commandes pour les rendre
00:03:13plus puissantes et spécifiques à mon cas d'usage. C'est ce que je
00:03:18vous recommande de faire. Utilisez ceci comme point de départ si vous le souhaitez. Le lien vers
00:03:23le dépôt GitHub est en description. L'intérêt de rester simple est que vous
00:03:27pouvez vous l'approprier et l'adapter facilement à vos besoins et votre façon de travailler.
00:03:33C'est pourquoi je recommande cela plutôt que des frameworks complexes comme Beemad ou le kit de spécifications GitHub.
00:03:38Ils sont puissants, mais difficiles à personnaliser. Je veux que vous puissiez
00:03:42faire vôtre ce système. Je vais maintenant vous montrer comment créer un PRD complet, définir
00:03:48les règles initiales et personnaliser un peu notre première commande.
00:03:52Je parlerai des sous-agents en cours de route. Je sais qu'on planifie beaucoup avant d'écrire
00:03:57le moindre code avec les boucles PIV, mais c'est crucial. Planifier en amont
00:04:03peut donner l'impression de ralentir, mais avec un bon plan, de bonnes
00:04:07règles et un bon PRD, tout le développement ultérieur sera beaucoup plus rapide
00:04:13et fiable. Commençons par le PRD. Certains appellent ça une « spec ». C'est simplement
00:04:18tout le périmètre nécessaire pour bâtir la version initiale de l'application. Une fois
00:04:24que les bases sont saines, on passe au développement brownfield. C'est l'objet de
00:04:28ma prochaine vidéo, alors restez connectés. Ici, avec Claude Code,
00:04:34sur ce projet vide à part ma couche IA, je vais simplement avoir une conversation informelle
00:04:40au début. Je lui parle de mon idée, de mes pistes pour la stack technique et
00:04:45l'architecture. On commence de façon non structurée, ce qui facilite le lancement.
00:04:50Ensuite, on utilise cette conversation comme contexte pour créer
00:04:55un PRD structuré. J'ai une commande pour cela. Je l'expliquerai le moment
00:05:01venu, mais commençons par l'idée. Ce que je veux construire,
00:05:06pour l'exemple, c'est une sorte de Linktree, mais en version auto-hébergée
00:05:12où l'on crée sa page d'accueil avec des liens organisés. On y trouve
00:05:16des analyses, comme le taux de clic sur les liens. C'est ce que je veux bâtir.
00:05:20C'est un bon exemple car ce n'est pas trivial au point de pouvoir
00:05:24coder ça à l'instinct en deux secondes, mais ce n'est pas non plus
00:05:29si complexe qu'on n'aurait rien de concret à la fin de la vidéo.
00:05:33Je vais utiliser un outil de reconnaissance vocale pour ça. Je recommande vivement
00:05:39d'utiliser quelque chose comme Aqua Voice. C'est ce que j'utilise. Il existe aussi d'excellentes options gratuites et open source.
00:05:43Whisper Flow, Epicenter Whispering... de super outils. J'adore la dictée vocale
00:05:48car je vous garantis que je ne pourrai jamais taper 226 mots par minute. J'utilise
00:05:54donc cet outil pour faire un premier grand déballage d'idées sur ce que je veux construire.
00:05:59Ce sera très brut, mais je vais faire ce « brain dump » en direct pour vous. Soyez
00:06:03attentifs à ce que je demande à Claude Code, car c'est aussi important que les idées
00:06:09elles-mêmes. J'expliquerai cela juste après. D'ailleurs, vous pouvez faire
00:06:13tout cela avec n'importe quel assistant de codage IA. C'est parti : je veux créer un générateur de page « lien en bio ».
00:06:20Comme Linktree. Les utilisateurs créent un compte, puis leur propre
00:06:24page de destination avec des liens. Ils peuvent modifier l'ordre. Je veux
00:06:29des statistiques pour voir les taux de clics sur les liens, et qu'ils puissent personnaliser
00:06:33le thème. Pour la stack, je pense à Next.js, j'aimerais utiliser Neon pour
00:06:37ma base de données et l'authentification Neon. Donc, lance un sous-agent pour faire
00:06:43des recherches là-dessus. Pour l'architecture, je ne suis pas fermé. J'attends tes recommandations
00:06:48sur la gestion du thémage et de la construction des liens. Et enfin,
00:06:55je veux que tu lances un agent pour faire des recherches web sur les meilleures pratiques
00:07:00pour ce type d'applications à la Linktree. Reviens ensuite vers moi
00:07:04avec une série de questions pour qu'on soit sur la même longueur d'onde, même sur les détails,
00:07:10pour ce qu'on construit ici. Très bien. J'envoie ça, la transcription se fait
00:07:14en quelques secondes. Et voilà, c'est parti. La chose la plus
00:07:20importante que j'ai faite là, c'est à la fin, quand je lui ai dit de me poser des questions
00:07:25après ses recherches. C'est un point crucial. Votre objectif numéro un
00:07:32dans toute planification avec des agents de codage est de réduire le nombre d'hypothèses
00:07:37que l'agent doit faire. Car au final, quand un agent fait une erreur dans votre code,
00:07:42souvent ce n'est pas parce que le code est mauvais, c'est que vous n'étiez pas alignés sur
00:07:48ce qu'il fallait construire. Le dicton dit qu'une ligne de mauvais code n'est qu'une ligne de mauvais code.
00:07:54Une mauvaise ligne dans un plan peut générer cent lignes de mauvais code. Mais une seule mauvaise ligne dans un PRD,
00:08:02c'est mille lignes de code erronées par manque d'alignement. J'ai beaucoup expérimenté
00:08:08pour trouver comment réduire ces hypothèses. Demander à l'agent
00:08:13de me bombarder de questions a fonctionné incroyablement bien. Surtout
00:08:17Claude Code avec son outil « ask user question », qui peut proposer des choix multiples ou une réponse libre.
00:08:23On verra ça bientôt, c'est puissant. Ils font un excellent travail pour anticiper les cas
00:08:28limites et les détails auxquels on ne pense pas forcément. Il est difficile pour nous
00:08:33de deviner les suppositions que l'agent pourrait faire. C'est donc très efficace. L'autre
00:08:38chose que j'ai faite, c'est utiliser différents sous-agents qui tournent
00:08:42pour la recherche. J'adore les utiliser pour la planification, la création du PRD,
00:08:48ou même pour planifier les boucles PIV dont nous parlerons plus tard. Avec
00:08:53Claude Code, je n'ai pas besoin de créer mes propres sous-agents car les agents d'exploration
00:08:59et de recherche sont intégrés. Pour d'autres agents, vous devrez peut-être les
00:09:04créer vous-même, d'où ma précision. Mais aujourd'hui, presque tous les bons
00:09:08agents supportent ce concept. Je les adore pour la recherche pour une raison :
00:09:14l'isolation du contexte. L'un des thèmes clés est de protéger
00:09:20le contexte de notre agent principal. La recherche est le cas d'usage idéal
00:09:26pour les sous-agents car lorsqu'ils explorent, ils regardent tout. Ils font de l'exploration
00:09:32de base de code ou de la recherche web, chargeant des dizaines, voire des centaines de milliers
00:09:36de tokens. Or, ce qui nous importe, ce sont leurs conclusions, le résumé final
00:09:41qu'ils renvoient au contexte principal. On garde ainsi ce dernier propre. Je déconseille
00:09:46les sous-agents pour l'implémentation car là, on a besoin de tout le
00:09:51contexte des fichiers édités et créés. Sinon, d'après mon expérience, cela mène à des hallucinations.
00:09:57C'est pourquoi Claude Code n'a pas d'agents intégrés pour l'implémentation,
00:10:01uniquement pour la recherche. Et c'est exactement ce qu'on voit ici. Je vais
00:10:06laisser tout cela se terminer et je reviendrai quand les questions seront prêtes. Voilà,
00:10:12la recherche des sous-agents est finie et nous avons notre première série de questions. En les
00:10:17parcourant, vous comprendrez l'intérêt car nous clarifions énormément
00:10:22de points. Chaque réponse supprime une hypothèse de l'agent de
00:10:26codage. Comme c'est du choix multiple et que les options sont souvent pertinentes, on peut
00:10:31aller très vite. On peut ainsi aborder l'implémentation avec la certitude
00:10:36que tous les détails sont verrouillés. Par exemple : quelle structure de page publique
00:10:41pour l'URL ? L'option 1 me plaît, hop, suivante. Combien de pages
00:10:46chaque utilisateur peut-il créer ? Disons une seule. Pour certaines,
00:10:50je garde les valeurs par défaut, mais il arrive souvent que l'IA
00:10:54comprenne mal un point fondamental. C'est là que j'écris ma propre réponse. Je ne sais pas
00:10:59si j'aurai un exemple ici, mais je vais répondre
00:11:03à toutes ses questions et je reviens. Pas besoin de me voir répondre à
00:11:07chaque question, il peut y en avoir 20 ou 25. Il va assez loin.
00:11:14Encore une fois, il faut être patient, mais chaque réponse peut
00:11:19vous épargner des centaines de lignes de code erronées. En voici un bon exemple justement.
00:11:24Je veux clarifier un point totalement différent de ce qu'il suggère. On est dans
00:11:30la deuxième salve de questions de Claude. L'éditeur de liens doit-il avoir un aperçu
00:11:35en temps réel dans un cadre de téléphone ? Comme sur Lovable ou Bolt.new, où l'on voit ce qu'on crée
00:11:39avec le générateur à gauche, ou bien doit-il être en ligne ? En fait, je veux
00:11:44les deux options. Je peux donc en discuter dans le chat. Il me posera
00:11:49les autres questions après, mais on peut avoir une mini-conversation sur ce point précis. Je
00:11:53vais lui dire : je veux un éditeur en ligne, mais avec la possibilité de voir
00:11:58l'aperçu. En gros, trois boutons : un pour l'éditeur seul, un
00:12:03pour voir les deux, et un pour l'aperçu seul. J'envoie ça, il reviendra
00:12:08avec d'autres questions et je poursuivrai le processus. Voilà, Claude a fini de me poser
00:12:13ses questions, sans doute plus qu'il n'en faut, mais on peut ajuster comme on veut.
00:12:18C'est le moment de créer notre PRD car, comme on le voit dans le résumé final de la spec,
00:12:23il a une compréhension très précise de ce qu'on va construire,
00:12:28même pour le déploiement. Je vais déployer sur Vercel. C'est
00:12:31fantastique. J'ai l'impression qu'il ne fait plus d'hypothèses au hasard. Maintenant,
00:12:36je vais lancer ma commande « create PRD ». Je vais mettre ça dans .claud/prd.md. Vous
00:12:43pouvez le mettre n'importe où et l'appeler comme vous voulez. J'utilise la commande
00:12:47mentionnée plus tôt car, pour revenir à nos quatre règles d'or, l'une des
00:12:53plus importantes est de tout transformer en commande (« commandify »). Si vous faites quelque chose plus de deux fois,
00:12:59et j'ai lancé pas mal de projets, vous devez en faire une commande. Ou une
00:13:03compétence, car Claude Code a récemment fusionné les deux, mais j'aime garder la distinction :
00:13:10les commandes sont ce qu'on invoque soi-même, comme /commit. Les compétences,
00:13:15c'est quand un agent décide de lire un contexte, comme apprendre à faire quelque chose de nouveau.
00:13:20Ici, je crée une commande car je décide qu'à ce stade de la conversation,
00:13:27je veux l'exécuter pour générer un PRD structuré. Dans cette commande, je donne la structure exacte,
00:13:32toutes les sections que je veux voir. Ainsi, je rends tout mon processus reproductible.
00:13:38L'intérêt du système que je vous montre est de créer une méthode qui fonctionne
00:13:42pour vous, puis de la répéter à l'infini pour de nouvelles fonctionnalités ou projets.
00:13:48Je lance donc /create PRD et je reviens une fois qu'on a
00:13:53le PRD final. Voilà, notre PRD est créé et il est très complet. C'est une bonne
00:14:00chose, car on ne va pas l'envoyer tel quel à l'agent pour qu'il l'implémente.
00:14:04On va construire par phases, décrites dans ce PRD. Je ne vais pas tout
00:14:09valider en détail à l'écran, ce n'est pas utile pour vous, mais il est
00:14:14crucial de le relire pour s'assurer d'être parfaitement aligné. Sinon,
00:14:18le code sera mauvais par la suite. La première chose que je veux vous montrer
00:14:22rapidement, c'est le périmètre du MVP. On y retrouve toutes nos questions qui prennent
00:14:29vie dans le PRD. C'est important car notre conversation n'était qu'un contexte
00:14:34non structuré pour nourrir le PRD. Seul le PRD va subsister. Il faut donc
00:14:40s'assurer que toute la conversation avec l'agent y est intégrée. Nous avons la section
00:14:44« hors périmètre », tout aussi capitale pour savoir ce qu'on ne construit pas. On a toute
00:14:49la structure des répertoires. Il comprend déjà globalement ce qui ira dans le code,
00:14:53ce qui est bien puisqu'on a fixé la stack et l'architecture. Le point
00:14:58essentiel, ce sont les phases de travail. Grâce à cela, quand on utilisera notre commande
00:15:04« prime » dont on parlera après, on pourra établir : qu'est-ce qui est déjà fait
00:15:09dans le code ? Que doit-on construire ensuite d'après le PRD ? Ce sera
00:15:13un élément de contexte majeur au début de chaque échange pour bâtir notre MVP.
00:15:19D'ailleurs, voici la section où je détaille les phases. Chacune sera une
00:15:24implémentation granulaire, une boucle PIV. On pose les bases, on gère les liens,
00:15:29puis le thème. On planifie chaque phase individuellement pour ne jamais
00:15:33demander trop de choses à l'agent à la fois. Voilà, le PRD est fait
00:15:38et c'est l'étape la plus grosse. On touche au but pour la première implémentation. L'étape
00:15:43suivante est de définir nos règles. Ce sera basique au début car les règles
00:15:48vont surtout évoluer en même temps que la base de code. Comme j'utilise
00:15:53Claude Code, je me réfère à .agents et agents.md car c'est devenu le standard
00:15:58universel pour nommer les règles globales. L'important ici, ce sont les contraintes
00:16:04et les conventions que l'agent doit toujours suivre ; elles vont dans ce fichier de règles globales.
00:16:10Ce sont des choses comme les commandes pour lancer l'appli, la stratégie de test, la stratégie
00:16:16de logging. Quoi qu'on construise, l'agent doit toujours voir ça. On va donc
00:16:20créer cela maintenant, au moins une version initiale. L'autre
00:16:25composant est le dossier « reference ». On peut aussi utiliser les compétences Claude Code pour ça,
00:16:30mais c'est plus universel ainsi car on a souvent d'autres contextes utiles à l'agent,
00:16:35mais seulement pour certaines parties de l'application. Par exemple, un guide
00:16:40pour les composants front-end si on travaille sur le front-end. On ne veut pas
00:16:44tout mettre dans agents.md car ce fichier est chargé dans le contexte de l'agent
00:16:49à chaque conversation. Et rappelez-vous : le contexte est précieux. On veut rester concis
00:16:55et simplement pointer vers ces fichiers. On dit à l'agent : si tu travailles
00:17:00sur le front-end, lis ce fichier. Si tu crées des points d'API, lis celui-là.
00:17:04C'est essentiellement de la divulgation progressive. Nous avons différentes couches de contexte
00:17:09que l'agent peut découvrir au fil du temps pour s'assurer qu'il ne charge que ce dont il a besoin
00:17:14selon la tâche en cours. Et pour cela, j'ai encore une autre commande. Encore une fois, il faut
00:17:20tout "commandifier". Tout comme j'ai un modèle pour mes PRD, j'en ai un pour créer
00:17:25mes règles globales. D'abord, nous allons découvrir ce que nous avons déjà dans la base de code.
00:17:30Car j'ai créé cela pour que ça fonctionne avec des bases de code existantes ou nouvelles. Ici,
00:17:35tout ce qu'il va explorer, c'est le PRD. Il va déterminer notre pile technique, notre
00:17:38architecture, faire des recherches web sur les stratégies de test et de journalisation, puis
00:17:43rassembler tout cela avec mes conseils pour créer mes règles globales. J'ai la structure exacte ici.
00:17:50Ce sera basé sur ce modèle que j'ai. Je vais vous le montrer très rapidement aussi,
00:17:55car c'est le modèle que j'adore utiliser pour toutes mes règles globales. Et vous voyez que
00:17:59tout ce qui est ici nous importe pour notre agent, quoi qu'il arrive. Comme : voici notre pile technique,
00:18:04les commandes pour lancer et tester les choses, notre structure de projet. Il a donc un index
00:18:08de notre base de code, l'architecture, les modèles de code, les conventions de nommage,
00:18:13les stratégies de test et de validation. C'est assez basique, mais nous allons d'abord créer ceci,
00:18:17puis je vous donnerai des exemples de documents de référence comme notre contexte secondaire à la demande.
00:18:22Je vais donc dans Claude et, dans la même conversation où j'ai créé mon PRD,
00:18:27je vais simplement taper "create rules" car je peux utiliser toute cette discussion comme contexte.
00:18:33Il sait tout de suite : d'accord, voici notre PRD, voici notre pile technique, etc.
00:18:38La commande "create rules" est terminée, et nous avons maintenant nos règles globales.
00:18:43Je les ai déjà ouvertes. C'est assez standard. Nous avons la pile technique, les commandes,
00:18:47comme l'utilisation de Drizzle ORM pour la base de données, la structure, l'architecture,
00:18:52les modèles de code. Par souci de brièveté, je ne personnalise pas trop les choses ici
00:18:57et je n'y applique pas trop mes propres pensées, mais selon votre niveau technique, c'est le moment
00:19:03de vous assurer que les contraintes, les conventions et les modèles de code sont bien alignés
00:19:07avec la façon dont vous voulez créer vos bases de code. Vous pouvez y passer beaucoup de temps.
00:19:12Je ne le fais pas car je me concentre sur les concepts de haut niveau avec vous ici.
00:19:16J'ai aussi dû faire des recherches web sur les meilleures pratiques pour créer
00:19:21des composants front-end et des points de terminaison d'API. Sur cette base, j'ai dû créer
00:19:24du contexte à la demande. Encore une fois, cela pourrait être des "Claude Code Skills".
00:19:29Si on retourne aux règles globales et qu'on descend à la section du contexte à la demande, voilà.
00:19:34Pour les composants front-end, lis ce fichier. Pour les routes d'API, lis celui-là. Seul "clod.md"
00:19:40est chargé au départ, puis il décidera d'importer le reste si besoin. D'après mon expérience,
00:19:45il est très doué pour s'y référer, surtout si nos règles globales sont concises. On n'a
00:19:50même pas 240 lignes ici ; il y en a 233. Et puis nous avons "api.md" et "components.md".
00:19:58Ceux-là sont beaucoup plus gros car quand on travaille sur une tâche très spécifique,
00:20:03il est acceptable d'apporter beaucoup plus d'informations pour bien guider notre agent de codage.
00:20:08Donc, pour en revenir à notre diagramme, les règles définissent comment nous voulons construire.
00:20:14Le PRD définit ce que nous allons construire exactement. Avec ces deux éléments en tête,
00:20:19la dernière chose dont je veux parler ici, ce sont les commandes, spécifiquement la commande "prime".
00:20:23Ensuite, nous passerons au plan de la première phase et à la création du code. À ce stade,
00:20:29nous avons la couche IA initiale. Notre PRD, nos règles et ces commandes génériques
00:20:34que j'ai importées et que vous pouvez utiliser. Passons maintenant à l'implémentation.
00:20:39Mais voici le truc : au début de chaque nouvelle conversation avec un assistant de codage IA,
00:20:44il doit se mettre à jour sur la base de code. Que construit-on ? Quelle est la suite ?
00:20:50C'est là qu'intervient la commande "prime". On lancera "/prime" au début de chaque
00:20:56nouvelle session. C'est un processus guidé pour qu'il explore notre base de code et arrive
00:21:02au point où il a le modèle mental prêt pour l'implémentation de la fonctionnalité suivante.
00:21:06Nous lui ferons lire la documentation, explorer la structure. Il peut aussi utiliser des sous-agents.
00:21:11Vérifier le journal Git, car c'est une autre chose dont je parlerai plus tard : utiliser
00:21:15le journal Git comme mémoire à long terme. Il peut voir comment la base de code a évolué,
00:21:21ce qui l'aidera à prendre des décisions sur la suite. Après cette commande,
00:21:26il va nous présenter sa compréhension de la base de code. Ainsi, nous pouvons valider
00:21:31qu'il est à jour, et nous pouvons passer à la suite. Sans trop détailler la commande "prime",
00:21:36nous effectuons des opérations avec Git pour profiter de l'historique. Ensuite, nous lisons
00:21:40les fichiers de base et identifions tout ce qui nécessite une attention particulière,
00:21:45comme les points d'entrée principaux de l'application. Et ce rapport de sortie nous permet
00:21:49de valider sa compréhension. Nous pouvons le faire évoluer pour le rendre spécifique au projet.
00:21:55Pour donner un petit exemple, pour la lecture de la documentation de base,
00:22:01je pourrais dire : lis les migrations Drizzle pour comprendre le schéma de la base de données.
00:22:08L'autocomplétion a même fonctionné, il savait exactement ce que je voulais. Au fur et à mesure
00:22:12que vous déterminez les éléments clés que l'agent doit surveiller dans cette base de code,
00:22:16comme d'autres documents dans le dossier de référence, vous pouvez les ajouter ici.
00:22:20Maintenant, je vais retourner dans Claude, mais je vais commencer une toute nouvelle conversation,
00:22:25car nous allons entamer notre première boucle PIV. J'expliquerai tout cela dans un instant,
00:22:30mais regardez : je lance juste "Prime". Ce sera le début de ma conversation.
00:22:34Avant de faire quoi que ce soit, je veux explorer. Dans ce cas, il va réaliser que
00:22:39c'est un nouveau projet. Il va vérifier le PRD et recommander de faire la phase 1,
00:22:44pour créer les fondations de notre projet. La commande Prime est terminée. Voici l'aperçu :
00:22:49générateur de page "link in bio". État actuel : dépôt vide avec juste de la documentation.
00:22:54J'avais fait un test avant, c'est pour ça qu'il dit ça, mais j'ai tout effacé pour l'instant.
00:22:59Ensuite, il a extrait la première phase, la fondation, de notre PRD. C'est ce qu'il recommande
00:23:04de construire, et c'est exactement ce que je veux. Je veux qu'il choisisse les phases
00:23:10une par une dans le PRD pour avoir des implémentations granulaires pour nos boucles PIV.
00:23:14En parlant de boucles PIV, nous y arrivons. PIV est l'acronyme de Planifier, Implémenter, Valider.
00:23:20On prend un travail ciblé, généralement une phase du PRD, et on suit tout ce processus.
00:23:29On crée un plan structuré sur ce qu'on va aborder. Cette étape est en fait assez similaire
00:23:34à la création d'un PRD. Ensuite, on passe à l'implémentation. Notre objectif ici est de
00:23:38déléguer tout le code à l'agent de codage. Et enfin, nous procédons à la validation.
00:23:44Je vais vous présenter rapidement ce processus avant de le voir en action. D'abord,
00:23:50pour la planification, nous avons deux niveaux : la planification globale du projet,
00:23:55ce qu'on a déjà fait avec le PRD et les règles, et maintenant la planification spécifique à la tâche.
00:24:00Comme je l'ai dit, c'est assez similaire. Créer un plan structuré ressemble beaucoup
00:24:07à la création d'un PRD structuré. La différence majeure est que le plan structuré est
00:24:13très focalisé sur une fonctionnalité individuelle et toutes les tâches associées.
00:24:19On rentre dans le code. On n'est plus au haut niveau, mais on commence quand même par
00:24:24une conversation très peu structurée. J'appelle ça le "vibe planning", on explore les idées générales.
00:24:30Quelle est l'architecture pour ce qu'on construit ? On lance des sous-agents pour l'analyse
00:24:35de la base de code et la documentation, puis on définit les tâches spécifiques à accomplir
00:24:40pour cette fonctionnalité. On a cette discussion, et je vais vous en montrer un exemple,
00:24:44puis on transforme cela en un document structuré, comme pour le PRD. Le but est de créer
00:24:50un plan d'attaque détaillé pour l'assistant IA basé sur notre conversation. La discussion
00:24:56fait partie du contexte, mais ici je veux des sections très spécifiques dans le plan structuré.
00:25:02L'objectif et les critères de succès, la documentation à référencer trouvée par les sous-agents,
00:25:09notre liste de tâches, qui peut même préciser les fichiers individuels à créer ou modifier.
00:25:13Et la partie probablement la plus importante de tout ce plan est la stratégie de validation.
00:25:18C'est un peu comme le développement piloté par les tests (TDD) où l'on veut être très précis
00:25:23sur la validation de la fonctionnalité avant même d'écrire une seule ligne de code.
00:25:27Cela nous oblige, nous et l'agent, à être très spécifiques sur les critères de réussite.
00:25:33On crée notre plan structuré, nous y participons activement, mais ensuite on délègue
00:25:38tout le code à l'agent lui-même. Ce n'est pas du "vibe coding" pour autant. La seule raison
00:25:45pour laquelle je fais confiance à l'agent tout en vérifiant, c'est que j'encadre l'implémentation
00:25:51par la planification et la validation, étapes où je suis très impliqué dans le processus.
00:25:56On va demander à l'agent de vérifier son travail avec des tests unitaires, d'intégration
00:26:01et de bout en bout. Nous verrons cela aussi. Mais ensuite, je ferai ma propre revue de code
00:26:06et je testerai manuellement l'application. Je l'utiliserai moi-même comme un utilisateur
00:26:11pour m'assurer que tout fonctionne bien avant de faire le commit et de l'envoyer
00:26:16en production ou en pré-production. L'important ici est qu'entre la planification
00:26:20et l'implémentation, je réinitialise le contexte. C'est l'une des règles d'or : le contexte
00:26:26est précieux. J'ai une conversation longue et détaillée pour définir la fonctionnalité.
00:26:32Et le plan structuré que je crée doit contenir tout le contexte dont l'agent a besoin
00:26:38pour faire le travail. Ainsi, j'ai une conversation fraîche où le plan est la seule chose
00:26:44que j'envoie, car il contient toute la documentation de référence et la liste des tâches.
00:26:50On sait ce qu'il faut faire et comment valider. On peut ainsi passer à l'exécution de manière
00:26:55très ciblée. On veut éviter de surcharger la conversation de contexte inutile au moment
00:27:00d'écrire le code. Très bien, lançons notre première boucle PIV. Ce sera beaucoup plus simple
00:27:06que vous ne le pensez car nous allons récolter les fruits de toute la planification initiale.
00:27:12Nous sommes sur la même longueur d'onde que notre agent. Nous sommes confiants qu'il comprend
00:27:16ce qu'on veut bâtir. Il n'y aura donc pas énormément de planification pour chaque phase au début.
00:27:22De retour ici, nous avons fini le "prime". Nous sommes raccord avec l'agent.
00:27:27Je lui ai juste donné une instruction simple : "La phase 1 semble correcte, confirme-moi
00:27:31exactement tout ce qu'on va construire." D'habitude, après la première boucle, c'est plus détaillé.
00:27:36On examine la base de code pour voir comment construire précisément. Mais ici, c'est simple.
00:27:40Ça semble correct. Maintenant, rappelez-vous : il faut tout "commandifier".
00:27:44Je veux transformer cette discussion sur la phase 1 en un plan structuré avec tâches et validation.
00:27:49J'ai une commande pour ça : "/plan-feature". Je l'envoie et maintenant cette commande,
00:27:53tout comme la création du PRD, intègre l'idée d'un plan structuré. Je vais vous montrer
00:27:59cette commande également. Elle accepte un argument optionnel pour spécifier ce que je veux
00:28:04construire. Ici, j'utilise l'historique de la conversation. Il savait donc déjà quoi faire.
00:28:10On suit un processus par étapes : compréhension de la fonctionnalité, plongée dans le code,
00:28:17beaucoup de recherches pour extraire la documentation pertinente et avoir un contexte riche
00:28:23avant l'exécution. Et voici le modèle : décrire le problème, le contexte ou les références,
00:28:28le plan d'implémentation avec la liste des tâches et, bien sûr, la stratégie de test.
00:28:33On définit la validation à l'avance. Une fois le plan créé, on va le valider pour être
00:28:38très précis sur chaque étape de validation de l'application. J'utilise d'ailleurs
00:28:44le "Vercel agent browser CLI skill", sur lequel j'ai fait une vidéo. On va intégrer
00:28:49une automatisation complète du navigateur. L'agent va lancer le back-end, le front-end,
00:28:55les migrations de base de données, créer son propre "link tree" et s'assurer que tout
00:29:00fonctionne comme pour un vrai utilisateur. C'est passionnant. La validation sera très
00:29:05détaillée pour qu'au moment où l'on reprend la main, on soit confiant dans l'implémentation,
00:29:11même si on valide encore nous-mêmes. Ce sera beaucoup moins de travail. Le plan est créé.
00:29:17Jetons un œil. J'ai fait un peu de validation hors caméra. Vous verrez ça plus tard.
00:29:21En général, on itère pas mal car on veut s'assurer que sa compréhension de la phase 1
00:29:26est alignée avec le PRD et ce qu'on veut vraiment. Je vous encourage à revoir toutes les sections.
00:29:31Voici notre plan avec la liste des tâches. C'est très détaillé, ce qui est bien pour rester
00:29:36focalisé sur une fonctionnalité. On a la validation avec toute la pyramide de tests :
00:29:42vérification des types, linting, tests unitaires et tests de bout en bout très spécifiques
00:29:47pour les parcours utilisateurs. On peut être confiant. Au début, il ne faisait pas ça très bien.
00:29:52J'ai donc fait un suivi pour vous montrer comment on peut affiner le plan avant
00:29:56de lancer l'implémentation. Autre pépite, on passe à l'implémentation dans une seconde,
00:30:01mais c'est crucial : en général, les agents de codage ne sont pas très bons avec les variables
00:30:05d'environnement. Ils s'embrouillent. Si elles ne sont pas définies avant, l'agent fera des tests
00:30:10simulés et dira que tout est validé alors que ce n'est pas le cas. C'est frustrant.
00:30:15D'habitude, parallèlement à la planification, on crée un fichier ".env.example".
00:30:20Je lui demande de regarder là pour connaître les variables d'environnement nécessaires.
00:30:24Ensuite, je configure mes propres variables. Évidemment, je ne montre pas ce fichier car il
00:30:29contient mes secrets comme l'URL de la base de données. Comme c'est prêt, on peut foncer.
00:30:34Il peut non seulement écrire le code, mais aussi lancer les migrations et les serveurs,
00:30:38utiliser l'outil Vercel pour tout tester, sans s'interrompre pour me demander de régler
00:30:43les variables d'environnement. Le terrain est parfaitement préparé pour l'implémentation
00:30:48et je suis satisfait du plan. Maintenant, réinitialisation du contexte car il est précieux.
00:30:53Je suis dans une nouvelle fenêtre contextuelle avec ma commande d'exécution, et le seul
00:30:57paramètre est le plan. C'est tout ce dont il a besoin maintenant. Je vais faire une pause
00:31:03et revenir quand il aura terminé. On délègue tout le codage à l'agent, récoltant les fruits
00:31:09de nos efforts de planification. Chaque boucle PIV sera désormais très rapide grâce à ce travail.
00:31:13L'implémentation est terminée. Les captures d'écran montrent qu'il a fait des tests complets.
00:31:19On peut être confiant car l'agent s'est occupé de tout, mais la validation humaine reste
00:31:23importante pour vérifier. La revue de code est très technique, donc je ne vais pas
00:31:29la faire là, mais si vous êtes technique, c'est indispensable. Par contre, je vais tester
00:31:34l'application en direct avec vous. J'ai juste créé un compte hors caméra pour vérifier
00:31:40l'authentification de base, mais je n'ai rien fait d'autre. Regardez ça. C'est génial.
00:31:45C'est déjà très joli. Je peux définir mon nom d'affichage, mettre une bio comme "cool AI builder".
00:31:51Je peux mettre l'URL de mon avatar, j'en ai mis une sur Imgur. Voilà, c'est très bien.
00:31:56Je peux ajouter des liens, comme YouTube, avec mon URL. Parfait. Ajoutons un autre lien,
00:32:01LinkedIn. Je ne l'ai pas sous la main, donc je mets juste linkedin.com, peu importe.
00:32:06Super. Ajoutons-en un dernier pour X. Voilà, x.com. Très cool. Je peux les faire glisser
00:32:11pour les réorganiser, c'est répercuté immédiatement. Je peux voir l'éditeur ou ajuster l'aperçu.
00:32:16Le thème n'est pas encore génial, c'est juste du blanc, mais je crois que ça vient plus tard
00:32:21car là nous ne construisons que les fondations. Ce n'est pas encore parfait, mais c'est
00:32:26déjà un excellent point de départ. Je clique sur "Sauvegarder", on charge les points d'API.
00:32:30Ça tourne en local. Voilà, modifications enregistrées. Je rafraîchis et tout est encore là.
00:32:35C'est incroyable. C'est vraiment très bien. Maintenant que la base est posée,
00:32:39je veux parler rapidement du message de commit. J'ai une autre commande, "/commit".
00:32:43C'est très basique, vous pouvez la détailler plus, mais l'idée est de donner des instructions
00:32:49à l'agent pour créer un message Git, car il servira de mémoire à long terme.
00:32:55Comme sur le diagramme, l'historique des commits est votre mémoire à long terme.
00:32:59En standardisant nos messages avec la commande "/commit", notre agent, lors du "prime",
00:33:08peut regarder le journal Git pour voir ce qui a été construit récemment. Cela guidera
00:33:11la suite et les modèles à suivre. C'est toute la puissance de ce message de commit.
00:33:18Je lance "/commit". Je pourrais le faire moi-même, mais ça garantit la cohérence des messages.
00:33:24Ici, il n'y a rien à commiter car je l'ai déjà fait hors caméra, mais c'est important
00:33:28après chaque implémentation. Une autre chose capitale une fois les fondations posées :
00:33:32vous voulez mettre en place un cadre pour les tests de régression. Nous voulons nous assurer
00:33:37que nous avons tout ce qu'il faut pour tester notre application au fur et à mesure de son évolution.
00:33:42Je vais vous montrer comment j'aime mettre cela en place. On retourne donc dans Claude.
00:33:46Je vais lui demander de créer les tests de régression pour ce qu'on vient de construire.
00:33:51Il va analyser le code, voir les fonctionnalités critiques et proposer une suite de tests.
00:33:57C'est essentiel pour ne pas casser ce qui fonctionne déjà quand on ajoutera la suite.
00:34:01L'agent s'occupe de générer les fichiers de test selon nos standards définis plus haut.
00:34:06Une fois que c'est fait, on a une base solide et sécurisée pour passer à la phase suivante.
00:34:11le diagramme ici, c'est l'une des règles d'or. Votre historique de commit est votre mémoire à long
00:34:17terme. En standardisant nos messages via la commande slash commit pour les rendre
00:34:22réutilisables, notre agent, lors de sa phase d'initialisation, peut consulter le log git pour voir
00:34:28l'historique de ce qui a été construit récemment. Cela guidera la suite et les modèles qu'il
00:34:32doit suivre. C'est tout l'intérêt de ce message de commit. Je vais donc faire slash commit,
00:34:38même si je pourrais lancer un git commit moi-même. C'est très simple, mais cela garantit
00:34:43une cohérence constante du message. Dans ce cas précis, il n'y a rien à commiter car
00:34:48je l'ai déjà fait hors caméra, mais c'est une étape cruciale après chaque nouvelle
00:34:53implémentation. Une autre chose super importante à couvrir une fois que les bases du
00:34:58projet sont posées, c'est la mise en place d'un framework de tests de régression. Nous devons
00:35:04nous assurer qu'au fil des futurs cycles PIV (que nous répéterons pour chaque
00:35:09fonctionnalité), l'existant ne soit pas altéré. J'aborderai plus en détail dans
00:35:14une autre vidéo toutes mes stratégies pour implémenter vous-même ce type de harnais
00:35:19de test. Concrètement, vous allez voir l'agent et lui dites : "Ok, ce qu'on a là est super,
00:35:25mais je pourrais aussi aller dans Aqua voice et lui demander : Liste-moi tous
00:35:31les tests de bout en bout que tu as effectués et mets-les dans une commande. Comme ça, je pourrai
00:35:36la relancer plus tard après avoir ajouté d'autres fonctions pour vérifier que tout ce qu'on a fait
00:35:41précédemment fonctionne toujours." C'est l'idée. Je ne vais pas trop rentrer dans les détails
00:35:46pour le moment. Configurer et créer un harnais de test prend du temps, mais c'est ainsi que
00:35:50vous garantissez la stabilité de votre application à mesure qu'elle évolue. Cela demande
00:35:55beaucoup de travail de création et de maintenance, car il faut sans cesse le mettre à jour. C'est pourquoi
00:36:00il existe des solutions qui s'en occupent pour vous, et elles sont très performantes. L'une d'elles
00:36:05est QA tech. Ils proposent des agents de test IA qui évoluent et s'adaptent à votre code.
00:36:11Ainsi, au fur et à mesure que vous ajoutez des fonctionnalités, ils ajoutent des cas de test pour
00:36:16s'assurer que tout fonctionne bien pendant le développement. Je vais vous montrer un
00:36:22exemple rapide. C'est très simple. Allez sur QA tech, ils ont une version gratuite
00:36:26pour essayer. Je crée un projet, puis il suffit de
00:36:30coller l'URL à tester. J'ai pris mon application (puisque j'avais déjà fait mon commit
00:36:35et pushé sur GitHub) et je l'ai déployée en une minute sur Vercel. C'est l'endroit idéal
00:36:40pour héberger vos sites gratuitement, surtout avec Next.js. Je vais sur mon projet et
00:36:45je colle cette URL. La création du projet et l'analyse du code vont prendre
00:36:50un peu de temps. On peut simplement dire : "Je veux une bonne configuration de test pour mon site.
00:36:55Aide-moi à créer les 3 à 5 premiers cas de test." C'est un peu comme dans bolt.new ou lovable,
00:36:59vous pouvez donner n'importe quel prompt pour configurer la suite de tests de votre
00:37:04projet. C'est ce qu'ils recommandent pour débuter. Je lance l'exécution.
00:37:08C'est génial car l'outil va explorer votre site, le parcourir entièrement, sans que vous ayez
00:37:12à gérer l'infrastructure. Il analyse votre site et génère les cas de test.
00:37:16Je reviens une fois que c'est fini. En cours d'exécution, je voulais juste vous montrer
00:37:21qu'il a parcouru mon site en quelques minutes seulement. L'un des points essentiels
00:37:25est d'avoir un moyen de se connecter au site pour que l'automatisation puisse le faire.
00:37:29Ils permettent de saisir un identifiant et un mot de passe qu'ils stockent de
00:37:34manière sécurisée. J'ai créé un compte de test ici. Je vais l'enregistrer et
00:37:38le système l'utilisera pour accéder au site, l'explorer en profondeur et comprendre les parcours
00:37:43utilisateurs à tester. Et voilà, il a généré une série de cas de test pour nous,
00:37:48et on peut même cliquer sur chacun d'eux pour voir le flux exact suivi. Maintenant,
00:37:53tous ces tests sont configurés. Les agents de test IA de QA tech vont faire évoluer ces
00:37:59cas de test au fil du temps pour couvrir l'intégralité du code. À mesure qu'on ajoute
00:38:04des fonctionnalités, c'est vraiment impressionnant. Encore une fois, on pourrait bâtir notre propre
00:38:09système de commandes pour faire ça, mais j'apprécie d'avoir une plateforme qui gère tout.
00:38:14Il y a des agents sous le capot avec qui je peux discuter pour affiner les tests
00:38:19et m'assurer que tout est bien testé en régression. Ainsi, dès que
00:38:24quelque chose casse, je peux venir ici et dire : "Ok, il y a un bug actuellement,
00:38:28crée un test qui échoue. Laisse-moi régler le problème, puis le test devrait
00:38:33passer." Cela nous amène à ma dernière règle d'or : l'état d'esprit d'évolution du système.
00:38:40Chaque fois qu'on rencontre un bug dans notre code, il est crucial de ne pas seulement
00:38:46corriger le bug, mais de réfléchir à ce qu'on peut améliorer dans notre couche IA pour que ça
00:38:51n'arrive plus. On peut être plus précis dans notre guide de style, nos règles, ou créer un nouveau contexte.
00:38:57On peut aussi ajouter des tests de bout en bout dans nos commandes ou nos workflows,
00:39:02tout ce qu'il faut pour ne plus revoir ce problème. Et on peut aussi
00:39:06faire comme je l'ai montré avec QA tech ou notre système de commandes, en ajoutant un test
00:39:12pour immuniser le code contre ce souci. L'intérêt de cette démarche,
00:39:16même si elle prend du temps, c'est de rendre notre agent de codage plus fiable et constant,
00:39:21en le faisant évoluer avec notre code. On mène donc trois chantiers en parallèle. Tout en développant
00:39:26notre code, nous faisons évoluer notre base de tests, notre codebase et notre couche IA.
00:39:32C'est un cercle vertueux puissant. De retour sur Cloud Code, je vais vous donner un exemple
00:39:37simple. Hors caméra, j'ai dû retravailler le style du site.
00:39:43Si vous revenez au début de la vidéo, vous verrez que j'avais oublié de préciser le style,
00:39:47le design exact que je voulais. Cloud Code a donc fait ses propres choix
00:39:51et le résultat n'était pas génial. J'ai dû itérer. Ce que je peux
00:39:56faire ici, c'est dire : "Au début, je n'aimais pas le style de l'interface. Nous
00:40:01n'avons pas assez d'instructions de style dans notre couche IA ou nos contextes.
00:40:06Faisons un peu de méta-réflexion : ne change rien au code pour l'instant, mais aide-moi
00:40:10à réfléchir à ce qu'on pourrait ajouter ou modifier dans nos règles ou nos contextes
00:40:15pour obtenir des styles plus cohérents à l'avenir, alors qu'on continue de
00:40:20construire les analyses et les autres pages de l'application."
00:40:25L'important ici est de lui dire de ne rien changer tout de suite,
00:40:29car je veux garder un contrôle total sur l'évolution de la couche IA, alors que pour le code
00:40:34pur, je préfère déléguer au maximum à l'agent. Je le fais réfléchir avec moi,
00:40:39mais j'aime effectuer moi-même ces petits changements ciblés. On voit ici
00:40:44qu'il recommande de créer un fichier style.md dans le dossier de référence. Un troisième contexte
00:40:50pour nous. Cela irait de pair avec components.md. L'un pour la
00:40:54structure des éléments, et styles.md pour le rendu visuel. Par exemple, comment
00:40:58utiliser Tailwind CSS et probablement ShadCN. Je ne vais pas aller jusqu'au bout de
00:41:03l'implémentation et tout corriger, mais je voulais vous montrer comment, face à un bug ou un
00:41:06simple manque d'alignement comme ici, il y a toujours une opportunité
00:41:11de faire évoluer l'IA. Ainsi, nous sommes de plus en plus en phase avec notre agent de codage
00:41:16pour ce projet spécifique au fil du développement.
00:41:20Et c'est là, mon ami, la partie la plus rentable de tout le processus ; j'ai gardé le meilleur pour
00:41:26la fin. C'est tout. C'est vraiment un processus simple pour obtenir des résultats fiables et
00:41:32reproductibles avec vos agents de codage sur de nouveaux projets. Après
00:41:35l'évolution du système, on repart de zéro et on enchaîne les cycles PIV en suivant
00:41:40le même processus pour bâtir toutes les phases du PRD, ajouter des fonctions, et tout ce qui
00:41:45est nécessaire pour atteindre le produit minimum viable. Ensuite, nous passerons au développement
00:41:49Brownfield dans l'une des prochaines vidéos de ma chaîne. Si tout cela
00:41:54vous intéresse et que vous voulez approfondir avec ma bibliothèque complète de commandes et de règles,
00:41:59voir concrètement ce qu'est l'évolution du système, j'ai ce qu'il vous faut.
00:42:04Allez voir ma formation sur le codage agentique dans la communauté Dynamics. Je mettrai
00:42:08un lien en description et en commentaire épinglé. C'est tout pour aujourd'hui.
00:42:13Si vous avez aimé cette vidéo et que vous attendez la suite sur le développement
00:42:17Brownfield, n'hésitez pas à liker et à vous abonner. Sur ce, je vous
00:42:22dis à la prochaine vidéo.