00:00:00Aucun modèle Claude ne suffit à lui seul. Opus a le raisonnement mais épuise vos
00:00:04limites. Sonnet est rapide mais bloque sur les décisions difficiles. La réponse n'est pas d'en choisir un
00:00:10plutôt que l'autre. C'est de les utiliser ensemble. Claude Code le fait déjà dans une certaine mesure.
00:00:14Il orchestre les modèles de lui-même. Mais Anthropic vient de sortir quelque chose qui
00:00:18non seulement économise des jetons, mais rend aussi les petits modèles presque aussi capables que les grands.
00:00:23En construisant avec Claude, vous l'avez peut-être remarqué. Quand vous confiez une tâche à Opus
00:00:28et qu'il juge qu'elle ne nécessite pas tant d'efforts, il la passe à Sonnet ou Haiku et
00:00:32délègue aux plus petits modèles pour gérer l'usage des jetons. Mais cette approche pose un problème.
00:00:37Comme mentionné dans notre vidéo précédente, Anthropic a abaissé les limites de débit,
00:00:42donc aux heures de pointe, votre fenêtre de 5 heures se remplit plus vite. De plus, Opus consomme beaucoup
00:00:47de jetons, même sur des tâches simples, ce qui signifie qu'utiliser Opus sature plus vite votre limite.
00:00:52Anthropic a décidé de changer la donne et a lancé ce qu'ils appellent la
00:00:55stratégie « Advisor ». Dans cette stratégie, vous donnez le rôle d'exécuteur au modèle
00:01:00Sonnet et utilisez Opus uniquement comme un conseiller consulté seulement quand l'exécuteur en a besoin.
00:01:05Deux agents sont impliqués. L'exécuteur est votre agent principal tournant sur Sonnet et gère
00:01:10tous les appels d'outils, changements de code et sorties utilisateur. Le conseiller tourne sur Opus et son seul
00:01:15rôle est de guider l'exécuteur s'il bloque. Le conseiller n'écrit jamais de code et ne fait aucun changement.
00:01:20Lorsqu'Anthropic a testé cette approche, elle a surpassé Sonnet seul sur le
00:01:25SWE-bench. Ils ont trouvé que ce duo surpassait Sonnet seul en termes de performance et de coût.
00:01:31Et cela coûte bien moins cher que d'utiliser Opus comme agent principal car Opus n'est invoqué
00:01:36que quand c'est vraiment important, pas pour chaque itération. Vous pourriez penser que nous
00:01:40avons déjà beaucoup de frameworks prêts à l'emploi, alors pourquoi s'embêter avec cette
00:01:45configuration ? La raison est que la plupart des frameworks actuels ne sont pas conçus pour l'efficacité.
00:01:50Même s'ils font le travail, ils échouent quand il s'agit de faire durer Claude plus longtemps
00:01:54car ils se concentrent sur la création de l'application plutôt que sur l'optimisation
00:01:59des jetons. Avec ce système, vous créez une application fonctionnelle avec un modèle plus faible,
00:02:04rendant le tout bien plus économe. Et cela nous ramène au problème de limites mentionné
00:02:09plus tôt. Nous avons fait une vidéo sur les limites de Claude en vous conseillant de passer à un petit modèle.
00:02:13Voici le lien. Sonnet consomme beaucoup moins de jetons et nécessite moins d'efforts
00:02:19qu'Opus pour effectuer la même tâche. Opus est un modèle très grand et puissant, il consomme donc
00:02:24énormément, même pour des tâches simples. Sonnet gère beaucoup de ces tâches plus efficacement.
00:02:30Utiliser Opus uniquement pour combler l'écart sur les décisions difficiles est là où réside l'impact.
00:02:35Vous n'invoquez cette puissance que par nécessité, pas pour tout. Cela rend
00:02:40l'usage global plus économe et permet d'en faire plus avec les mêmes limites. Nous partageons
00:02:45tout sur la création de produits IA sur cette chaîne, alors pour plus de vidéos,
00:02:50abonnez-vous. Nous voulions tester comment cela se passe concrètement sur une
00:02:55application déjà bâtie avec Sonnet. Pour utiliser la stratégie dans Claude Code, on définit la commande
00:03:00Advisor avec Opus 4.6 comme conseiller. Notre agent principal était l'exécuteur, que j'avais
00:03:05déjà réglé sur Sonnet pour construire l'appli. L'application devait avoir une synchro en temps réel et
00:03:10si le déplacement d'éléments fonctionnait, la suppression ne se synchronisait pas du tout. Nous avons
00:03:16tenté de déboguer plusieurs fois avec Sonnet seul, mais le problème persistait malgré ses
00:03:20tentatives de correction. Donc, après avoir activé Opus en conseiller, nous avons donné le prompt
00:03:25décrivant le problème. Comme Sonnet avait déjà échoué, au lieu de réessayer
00:03:30seul, il a décidé d'invoquer le conseiller. Le conseiller a examiné la
00:03:34conversation pour évaluer la situation. Il a fourni les changements exacts à faire, ciblant
00:03:40où la logique de synchro cassait et ce qu'il fallait restructurer. L'exécuteur a suivi
00:03:45ces conseils et a appliqué les correctifs directement sans autre aller-retour. Nous avons testé
00:03:50sur plusieurs appareils pour vérifier la synchro et le problème était résolu. Les deux côtés
00:03:55reflétaient bien les suppressions, même si l'élément était sélectionné d'un côté et
00:04:00supprimé de l'autre, ce qui n'arrivait pas avant. Si nous avions tenté de corriger cela avec Sonnet
00:04:05seul, cela aurait pris plus de cycles de prompts car Sonnet est intrinsèquement un
00:04:09modèle plus faible, incapable de gérer seul une logique complexe. À l'inverse, utiliser Opus seul
00:04:15aurait consommé bien plus de jetons et n'aurait sans doute pas été aussi rapide. Utiliser Sonnet avec Opus
00:04:20comme conseiller a rendu le processus bien plus efficace. Globalement, cette stratégie a aidé à déboguer
00:04:25la synchro plus vite qu'avant. Mais avant de continuer, un mot de notre sponsor Juni par JetBrains.
00:04:30Si vous êtes développeur, vous connaissez la difficulté de changer de contexte entre terminal, IDE et CI
00:04:36juste pour avancer. La plupart des agents vous enferment dans un environnement ou un LLM
00:04:41spécifique. Juni CLI est différent. C'est un agent agnostique qui fonctionne partout. Votre
00:04:47terminal, IDE, GitHub, CI/CD, et même votre gestionnaire de tâches. Un seul agent partout. Déléguez-lui
00:04:54du vrai travail : tests, backends, refactoring, revues de code automatiques à chaque commit.
00:04:59JetBrains propose un accès anticipé gratuit avec 50 $ de crédits Gemini pour tester
00:05:04l'agent, plus le support BYOK pour utiliser le modèle de votre choix. Accès complet aux fonctions,
00:05:10nouveautés et support direct de l'équipe. C'est simplement mieux avec Juni.
00:05:15Cliquez sur le lien en commentaire pour rejoindre gratuitement. Nous voulions tester si Sonnet
00:05:20consulte réellement le conseiller pour des changements d'UI majeurs. Nous avions une application
00:05:25existante et voulions transformer son UI vers une autre bibliothèque. De plus, nous voulions
00:05:31faire plusieurs changements d'un coup, ce qui n'est pas recommandé, pour voir la coordination.
00:05:36Il a d'abord accédé à l'UI actuelle via Playwright MCP. Une fois le layout compris,
00:05:41au lieu de coder directement, il a consulté le conseiller pour déterminer la meilleure approche
00:05:46car c'était un changement critique qui pouvait tout casser s'il était mal géré.
00:05:50Le conseiller a signalé que la nouvelle bibliothèque choisie et celle déjà utilisée
00:05:55avaient des problèmes de version. Avant tout travail d'UI, Claude devait donc
00:06:00résoudre cela. Sonnet s'en est chargé, a lancé les commandes pour les dépendances,
00:06:04puis a vérifié l'état via Playwright pour confirmer que l'appli tournait toujours sans erreur.
00:06:09Une fois les dépendances réglées, il a commencé les changements suggérés par le conseiller,
00:06:14traitant chaque composant un par un et redessinant efficacement l'ensemble.
00:06:18L'UI créée était bien plus interactive et bien plus soignée qu'auparavant.
00:06:23Il restait quelques soucis, mais l'amélioration était claire. Mais voici où
00:06:27la limite est apparue. Le processus a pris environ 31 minutes. Opus seul l'aurait
00:06:32fait bien plus vite car il est meilleur pour orchestrer les tâches en identifiant ce qui peut
00:06:37tourner en parallèle. Sonnet, étant plus petit, a tout traité de façon séquentielle
00:06:43sans diviser le travail en sous-agents parallèles. Pour une application peu complexe,
00:06:4831 minutes, c'est trop long. Il gère aussi les petits changements seul sans
00:06:53solliciter le conseiller, ce qui est le bon comportement pour des retouches mineures. Mais pour
00:06:58des changements à grande échelle sur toute une appli, mieux vaut utiliser Opus directement car
00:07:03cela vous fera gagner beaucoup de temps et d'efforts. Nous avons ensuite testé
00:07:08l'implémentation d'une nouvelle fonctionnalité sur un code existant. Nous voulions ajouter
00:07:13une page avec une fonction différente. Nous avons donné un prompt décrivant nos attentes
00:07:17et nous pensions qu'il utiliserait le conseiller car ce n'était pas simple, mais il a
00:07:22implémenté les changements tout seul sans consulter le conseiller du tout. Il a traité cela
00:07:27comme un travail de routine, ce qui n'était pas le cas vu la portée. En testant
00:07:31l'application, nous avons trouvé plusieurs problèmes. Si on modifiait quelque chose, des changements
00:07:37comme les titres ou couleurs se reflétaient hors du volet de prévisualisation,
00:07:41ce qui ne devrait pas arriver. De plus, nous voulions une synchro directe sans devoir
00:07:46appuyer sur « Run » à chaque fois. Nous l'avons donc relancé en lui disant d'utiliser le conseiller.
00:07:51À notre prompt, il a d'abord invoqué l'agent conseiller. Le conseiller a examiné
00:07:56l'implémentation et identifié la cause des deux problèmes : le mauvais
00:08:00choix de composant. Il a expliqué ce qu'il fallait changer et pourquoi l'approche initiale
00:08:06avait créé ces soucis. L'exécuteur a suivi ces directives et les a appliquées. En testant
00:08:10à nouveau, le streaming fonctionnait. Tout se reflétait immédiatement lors de l'édition sans
00:08:16cliquer sur « Run ». Le problème de débordement entre composants était aussi
00:08:20résolu et tout se mettait à jour dans les bonnes limites. Il y a donc des fois
00:08:25où cela marche parfaitement, mais d'autres où l'exécuteur juge la tâche mineure et
00:08:30ne consulte pas le conseiller. Dans ces cas, il faut le pousser pour qu'il suive
00:08:35le flux prévu. Le modèle n'évalue pas toujours la complexité comme vous le faites,
00:08:40et s'il se trompe, vous finissez avec des bugs que le conseiller aurait vus d'emblée. Aussi,
00:08:44si vous appréciez notre contenu, pensez à cliquer sur le bouton « Hype » pour nous aider
00:08:49à en créer plus et à toucher plus de monde. Avec un état distribué en temps réel,
00:08:54cette approche a quand même nécessité plusieurs rounds de prompts avant que tout fonctionne.
00:08:58La stratégie aide, mais elle a un plafond qu'il faut comprendre avant de s'engager.
00:09:02Pour des applications de taille simple à moyenne, la stratégie Advisor peut vous épargner
00:09:07bien des allers-retours que vous passeriez à pousser Sonnet au-delà de ses limites.
00:09:11Si votre projet demande un raisonnement profond occasionnel mais une implémentation
00:09:16souvent directe, c'est une très bonne structure. Vous produisez plus sous vos limites de jetons
00:09:20sans devoir surveiller chaque décision ou repasser sur Opus pour toute la session.
00:09:25Pour les applis complexes avec beaucoup de dépendances ou points de faille, mieux vaut
00:09:30utiliser Opus directement comme agent principal. Même quand Sonnet suit bien le conseiller,
00:09:36il peut choisir la mauvaise voie d'implémentation car il n'a pas la profondeur de raisonnement
00:09:40pour évaluer plusieurs approches et leurs conséquences. Le conseiller aide à réduire
00:09:45cet écart, mais pas totalement. Parfois, les allers-retours coûtent plus de temps
00:09:50qu'utiliser Opus dès le début. Cette stratégie est donc utile si vos jetons sont
00:09:54limités et que l'application ne requiert pas le niveau d'Opus à chaque étape. Si
00:09:58ces deux conditions sont réunies, cela vaut le coup. Nous arrivons
00:10:03à la fin de cette vidéo. Pour soutenir la chaîne et nous aider à continuer,
00:10:08vous pouvez utiliser le bouton « Super Thanks » ci-dessous. Merci d'avoir regardé et
00:10:12à la prochaine !