00:00:00Même si Claude Code est l'un des outils les plus puissants pour le développement de l'IA,
00:00:03pourquoi échoue-t-il sur certaines tâches ? Entre les fonctionnalités qu'Anthropic a
00:00:08sorties récemment et les flux de travail que nous avons bâtis autour, la manière de
00:00:12l'utiliser est totalement différente d'il y a quelques semaines. Notre équipe utilise Claude
00:00:16Code quotidiennement, et pas seulement pour le développement, mais aussi pour la recherche, la gestion de notre
00:00:21pipeline de production et l'automatisation de tâches sans rapport avec le code. Laissez-moi vous montrer tout
00:00:26ce que nous avons découvert. Anthropic a récemment ajouté la commande “insights” pour Claude Code. Elle analyse
00:00:31toutes vos sessions passées sur une période donnée et génère un rapport. Ce rapport
00:00:36analyse votre style de travail, critique vos habitudes, souligne ce que vous faites bien
00:00:40ou mal, et vous indique comment progresser. Ce qui nous intéressait surtout, c'était d'identifier
00:00:45là où ça coinçait, car c'est là que nous pouvons apprendre à nous améliorer. Le rapport a mis en avant
00:00:49les points de friction majeurs et a suggéré des fonctionnalités pour optimiser
00:00:54notre flux de travail. Par exemple, nous nous souvenons d'une session où l'agent principal a consulté
00:00:58la liste des tâches en boucle pendant longtemps lors de l'utilisation d'équipes d'agents. La session est devenue trop longue
00:01:03et nous avons dû l'arrêter nous-mêmes. Pour éviter que cela ne se reproduise, nous pouvons copier cette consigne
00:01:07dans le fichier cloud.md afin que, lors de l'utilisation de multi-agents, Claude ne tourne pas
00:01:12en boucle indéfiniment. Nous pouvons importer ces astuces dans nos projets futurs pour que
00:01:17notre expérience avec Claude Code s'améliore avec le temps. Notre équipe a passé beaucoup de temps sur
00:01:22Claude Code, et l'étape la plus cruciale reste la qualité du contexte fourni à l'agent.
00:01:26Il peut s'agir d'exigences de projet décomposées ou de la documentation des frameworks et
00:01:30bibliothèques utilisés ; avec un bon contexte, les erreurs chutent quasiment à zéro
00:01:35car l'IA sait sur quoi agir. Pour la documentation du projet, nous préférons laisser Claude l'écrire
00:01:39plutôt que de le faire nous-mêmes. Nous lui avons donné une consigne précise contenant toutes les informations
00:01:44nécessaires pour structurer l'idée du projet en documents requis. Nous lui avons demandé de créer
00:01:48quatre documents, chacun axé sur un aspect spécifique de l'application. Le plus important est le PRD,
00:01:53qui contient les exigences et la portée du projet. Vient ensuite architecture.md,
00:01:57qui détaille le formatage des données, la structure des fichiers, les API et l'architecture.
00:02:02Puis decision.md, qui répertorie toutes les décisions prises par Claude durant la création du projet,
00:02:08servant de référence future. Enfin, le plus crucial : feature.json, qui contient
00:02:12toutes les fonctionnalités au format JSON. Il détaille chaque fonction de manière optimisée en jetons
00:02:17et définit les critères de complétion, avec une clé “passes” pour
00:02:22suivre l'état d'avancement de l'implémentation. Maintenant que votre grosse tâche est divisée en
00:02:27petites sections, nous devons fournir la documentation des outils nécessaires via
00:02:31le MCP Context 7. Il contient la doc de toutes les bibliothèques et frameworks et est mis à jour
00:02:36fréquemment pour que les agents récupèrent les dernières infos et comblent l'écart entre les connaissances du modèle
00:02:41et la réalité actuelle. Configurer le MCP ne prend que quelques étapes. Une fois installé,
00:02:46il utilise les outils de Context 7 pour extraire directement les infos des bibliothèques. Cela lui permet d'utiliser
00:02:50la doc la plus récente, d'éviter les erreurs de dépendances et d'obtenir une
00:02:55implémentation plus précise. Les “hooks” sont une autre fonctionnalité sous-utilisée. Les hooks dans Claude Code
00:03:00sont des commandes shell qui se déclenchent à des moments précis du cycle de vie. Il en existe plusieurs,
00:03:05comme au début de la session, avant ou après l'utilisation d'un outil. Mais le plus important
00:03:11est de les configurer avec des codes de sortie spécifiques. Ces codes indiquent à Claude s'il doit continuer,
00:03:16bloquer ou ignorer une action. Un code 0 signifie un succès. Un code 2 indique une erreur bloquante. Ainsi,
00:03:22si Claude tente une action interdite, il reçoit un code 2, obtient un message d'erreur
00:03:27et peut se corriger. Tout autre code est non-bloquant, affiché en mode verbeux,
00:03:32et l'exécution continue. Ce code 2 est essentiel car il permet de contrôler
00:03:37le comportement de l'agent. Si vous avez déjà fait du développement piloté par les tests (TDD) avec Claude Code,
00:03:41vous avez peut-être remarqué qu'il a tendance à modifier les tests s'il n'arrive pas à les valider. Pour éviter
00:03:46cela, nous avons configuré un hook personnalisé qui se déclenche avant l'utilisation d'un outil. Ce hook protège
00:03:50il affiche un message d'erreur interdisant la modification et renvoie
00:03:55it shows an error message saying modifications to test folders are not allowed and returns
00:04:00le code de sortie 2. Avec ce hook, quand nous avons demandé à Claude de lancer les tests et qu'ils
00:04:05ont échoué, il a tenté de modifier les fichiers de test. Mais le script l'a bloqué et un message
00:04:10d'interdiction est apparu. Cela a empêché Claude d'éditer des fichiers intouchables. Si vous connaissez
00:04:15les MCP, vous savez qu'ils encombrent la fenêtre de contexte. Sur un projet d'envergure,
00:04:19le nombre de MCP connectés augmente. Tous les outils MCP finissent par saturer
00:04:25la mémoire. Pour pallier cela, Claude Code propose un mode expérimental “MCP CLI” qui règle le problème.
00:04:31Nous avons activé ce flag expérimental. Une fois activé, tous les MCP qui apparaissaient
00:04:36dans le contexte ont disparu, libérant ainsi de l'espace mémoire. La question était
00:04:41de savoir comment accéder aux outils s'ils ne sont plus chargés en mémoire. Au lieu de charger tous les
00:04:45schémas d'outils au départ, Claude Code utilise des appels MCP CLI et exécute tous les MCP
00:04:52connectés via bash. Avec ce paramètre, quand nous lui donnons une consigne, au lieu d'appeler
00:04:56l'outil MCP directement, il passe par l'interface CLI et lance des commandes bash. De cette
00:05:03façon, il ne charge l'outil que sur demande, évitant la saturation. D'ailleurs,
00:05:08si vous appréciez notre contenu, n'hésitez pas à cliquer sur le bouton “hype” pour nous aider à en créer
00:05:13davantage et toucher plus de monde. Dans nos précédentes vidéos, nous avons insisté sur l'usage
00:05:18de Git pour suivre le travail des agents. Vous pouvez ainsi revenir en arrière si les agents
00:05:23n'implémentent pas les choses correctement. Nous avons aussi montré comment utiliser Git pour lancer un agent sur une
00:05:28tâche de longue durée. Nous avons utilisé des agents en parallèle sur différents “worktrees”
00:05:32pour qu'ils créent toutes les fonctionnalités du projet en restant isolés les uns des autres.
00:05:37Ainsi, nous avons pu fusionner leurs résultats plus tard sans interférence, car des agents travaillant
00:05:41sur les mêmes fichiers créent des conflits. Les branches ne sont pas idéales car elles posent problème :
00:05:46les agents ont du mal à changer de branche car elles partagent le même répertoire, contrairement aux worktrees.
00:05:50Nous lui avons donc demandé d'implémenter plusieurs fonctionnalités en précisant
00:05:55que chaque agent devait travailler sur un worktree séparé. Il a utilisé un agent distinct
00:05:59par environnement et a développé les fonctions en isolation, même quand leurs
00:06:03descriptions se chevauchaient. Une fois que Claude a tout implémenté correctement dans
00:06:08des branches séparées, nous lui avons fait fusionner le tout dans un seul répertoire de travail.
00:06:13Le mode strict est essentiel pour déléguer la vérification des erreurs à l'agent. C'est
00:06:18une configuration indispensable quel que soit votre langage, car elle détecte les bugs
00:06:22à la compilation plutôt qu'au moment de l'utilisation. Comme notre langage principal est TypeScript,
00:06:26nous activons toujours le mode strict. Cela active la vérification des valeurs nulles et des types
00:06:31implicites, imposant un typage rigoureux, ce qui réduit les erreurs d'exécution. C'est crucial
00:06:36pour les agents IA, car ils n'ont pas de moyen intégré de détecter les erreurs au runtime. Le mode strict
00:06:41minimise ces risques et laisse le compilateur gérer ces problèmes. Les agents peuvent
00:06:46s'appuyer sur les logs d'erreurs du terminal pour appliquer des correctifs connus. Au lieu de se limiter
00:06:51à des tests par scripts, il existe une couche de test supplémentaire intéressante : les “user stories”.
00:06:56Vous décrivez comment l'utilisateur interagit avec le système pour guider le processus de test une fois
00:07:00l'application bâtie. Nous définissons ces histoires avant même l'implémentation car cela fixe
00:07:05un standard à suivre. Via une consigne, Claude a écrit plusieurs histoires
00:07:10dans un dossier regroupant toutes les interactions possibles. Chaque histoire
00:07:15détaille un aspect de l'app, sa priorité et les critères d'acceptation pour les tests.
00:07:21Ces histoires couvrent tous les scénarios, cas classiques comme cas limites. Elles
00:07:26dictent aux agents comment interagir avec le système que nous venons de créer. Avec les bonnes
00:07:31instructions, n'importe quel agent peut appliquer ces principes à l'application
00:07:35qu'il construit pour mieux répondre aux attentes. Une fois documentées, nous avons demandé à
00:07:40Claude de les implémenter une par une, en commençant par le chemin optimal de chaque
00:07:45histoire, tout en couvrant les cas limites. Résultat : moins de lacunes et une meilleure
00:07:50satisfaction utilisateur. Toutes les astuces dont nous parlons sont disponibles sous forme de
00:07:55templates prêts à l'emploi dans AI Labs Pro. Pour ceux qui ne connaissent pas, c'est notre
00:08:00nouvelle communauté où vous trouverez templates, consignes, commandes et compétences à
00:08:05intégrer directement dans vos projets. Si vous appréciez notre travail et souhaitez nous
00:08:10soutenir, c'est le meilleur moyen. Liens en description.
00:08:14Il faut utiliser la parallélisation au maximum, car c'est ainsi que l'agent accélère
00:08:20son flux de travail et traite les tâches indépendantes. Claude détecte automatiquement
00:08:25si une tâche peut être parallélisée ou non et décide seul, mais il
00:08:29est utile de créer nos propres agents. Nous avons déjà abordé ces capacités dans notre
00:08:34vidéo précédente sur l'optimisation du flux de travail, mais cette vitesse a un
00:08:39coût en jetons. Cependant, l'effort en vaut la peine. À un moment,
00:08:43nous travaillions sur l'impact des améliorations d'Opus 4.6 et le modèle n'arrêtait pas
00:08:49d'halluciner, même avec des sources. Il écrivait des informations erronées que nous devions
00:08:54corriger sans cesse. Cette recherche devenait inutile car nous faisions tout le travail.
00:08:58Pour éviter cela, nous avons utilisé des agents en parallèle. Nous avons configuré une tâche
00:09:03pour comparer les capacités d'essaimage d'agents (agent swarm) de KimiK 2.5 et de Claude.
00:09:09Nous avons utilisé deux agents : un pour la recherche et l'autre pour vérifier les faits. L'idée
00:09:14était qu'ils communiquent entre eux pour garantir l'exactitude des résultats sans que nous
00:09:19ayons à intervenir. Dans cette configuration, un agent exécute la tâche tandis que l'autre l'analyse
00:09:24de manière critique, créant un système contradictoire. L'agent chercheur a commencé et le
00:09:28vérificateur a attendu le premier brouillon. Dès que celui-ci a été produit, le vérificateur
00:09:33a commencé son analyse. Il a immédiatement identifié de nombreuses erreurs dans les
00:09:38données listées, nous évitant de les trouver manuellement. Les deux agents ont maintenu
00:09:43une communication constante pour un contrôle rigoureux. Un agent est dédié
00:09:47à signaler les erreurs de l'autre. Ce modèle contradictoire s'applique à bien des tâches.
00:09:52Pas seulement la recherche, mais aussi le développement : un agent code une fonction et
00:09:57un autre révise l'implémentation par rapport au plan. Selon le créateur de Claude Code,
00:10:02l'agent est plus efficace s'il peut vérifier son propre travail. Le concept clé est de donner
00:10:07des “yeux” à l'agent, c'est-à-dire la capacité de vérifier si la fonction répond aux
00:10:12attentes. Comme ces agents sont basés sur le terminal, ils ne voient pas les bugs
00:10:17d'exécution, surtout côté client. Nous utilisons plusieurs méthodes de vérification.
00:10:21La première est l'extension Chrome de Claude, qui offre des outils de capture du DOM
00:10:26ou de vérification de la console. Un autre outil est le MCP Puppeteer. Il est utile
00:10:31car il tourne dans un navigateur séparé, sans vos sessions actuelles, contrairement à l'extension.
00:10:36C'est isolé et n'interfère pas avec votre navigation, offrant ainsi plus de
00:10:41confidentialité. Mais notre option préférée est l'Agent Browser de Vercel. Ce n'est pas un MCP,
00:10:46mais un outil CLI qui donne aux agents des capacités de test sur navigateur. Il permet de naviguer,
00:10:51de prendre des captures d'écran, etc. Contrairement aux autres, il ne se base pas que sur les images.
00:10:56Il utilise l'arbre d'accessibilité où chaque élément a une référence unique. Cela réduit le DOM
00:11:01de milliers de jetons à environ 200 ou 400, ce qui est bien plus efficace. C'était le souci majeur
00:11:07de l'extension Chrome que l'Agent Browser a résolu : elle sature vite la fenêtre
00:11:12de contexte en chargeant tout le DOM. Nous avons ajouté des instructions dans cloud.md pour que
00:11:17Claude privilégie l'Agent Browser avant de se rabattre sur les tests MCP. C'est donc sa
00:11:23méthode principale. Mais il y a un autre aspect : les tests sont cruciaux, mais on peut
00:11:28réduire les erreurs sans passer par le code ou les tests. Nous demandons à Claude d'anticiper.
00:11:33Nous lui demandons d'analyser l'implémentation pour identifier les points de rupture potentiels.
00:11:38Cela fonctionne car Claude peut prédire des problèmes par analogie avec des erreurs
00:11:43rencontrées sur d'autres applications, même si nous ne les avons pas encore subies.
00:11:47Cela pousse Claude à regarder le code sous un angle totalement différent.
00:11:52En faisant cela, il a identifié des failles critiques qui avaient échappé à nos tests
00:11:57multi-couches, trouvant 18 problèmes potentiellement graves en production.
00:12:01Nos processus de test classiques ne les avaient pas vus. Ils n'étaient identifiables
00:12:06qu'en poussant Claude à changer de perspective. Voilà qui conclut cette vidéo. Si vous voulez
00:12:10nous soutenir et nous aider à continuer, vous pouvez utiliser le bouton “Super Thanks”
00:12:15ci-dessous. Comme toujours, merci d'avoir regardé et à la prochaine !