Transcript
00:00:00Pendant longtemps, le modèle de référence de tout le monde pour le codage était Claude.
00:00:03Non seulement parce qu'il était performant, mais parce qu'il n'y avait pas d'autres options du même calibre.
00:00:07Ensuite, les modèles GPT ont progressé et ont comblé l'écart, surtout avec la sortie de GPT 5.5, qui
00:00:12l'a réduit à presque rien.
00:00:14Pour comparer les deux, nous devions les placer dans les environnements les mieux conçus pour eux, ce qui
00:00:18signifie leurs propres CLI.
00:00:19Nous mettons donc Opus 4.7 et GPT 5.5 à l'épreuve, pour voir comment ils se comportent l'un par rapport
00:00:25à l'autre.
00:00:26Nous les testerons dans 9 catégories pour découvrir lequel l'emporte réellement et,
00:00:29à la fin, vous saurez lequel mérite sa place dans vos flux de travail.
00:00:33L'ergonomie est le point où Claude Code commence à nous faire défaut.
00:00:36Nous l'utilisions pour la plupart de nos tâches, de codage ou non, mais c'était bien seulement
00:00:40jusqu'à la mise à jour 2.1.0.
00:00:43Après cela, les choses ont commencé à se dégrader pour Claude Code.
00:00:46L'interface utilisateur est la partie la plus frustrante car elle a le plus grand impact sur l'expérience.
00:00:50Le terminal bugge, le rendu s'interrompt, et beaucoup de ce qui semblait peaufiné auparavant semble
00:00:55bancal désormais.
00:00:56C'était l'une des meilleures TUI, mais seulement jusqu'à ce qu'elle commence à être codée "au feeling".
00:00:59Elle semble maintenant plus cassée avec de multiples bugs comme des problèmes de rendu, des fuites de cache,
00:01:03ce dont nous n'étions pas les seuls à nous plaindre.
00:01:05Le plus gros problème est qu'ils ont supprimé le mode de permissions "dangereusement ignorées" pour le remplacer
00:01:09par le mode auto par défaut.
00:01:11Nous utilisions le mode de contournement des permissions pour la plupart de nos tâches, avec des hooks configurés pour
00:01:15les fichiers que nous ne voulions pas que Claude touche.
00:01:17Maintenant, il demande des permissions même dans ce mode ; quand nous avons donné une instruction à Claude pour créer un skill,
00:01:22sommes passés à une autre session Claude pour faire autre chose, et avons découvert plus tard que la création du skill
00:01:27était bloquée par une demande de permission pour écrire dans le dossier .claude pendant tout ce temps.
00:01:32Nous sommes revenus en pensant que le skill serait créé, et il était juste là, en attente.
00:01:36Codex gère mieux cela car son mode YOLO ne demande aucune permission comme le fait
00:01:40le mode auto de Claude Code.
00:01:42La CLI est construite en Rust, donc l'interface est bien plus fluide que la configuration de Claude Code basée sur React,
00:01:47et même après une longue session, rien ne casse.
00:01:49La configuration de la personnalité est un autre point où Codex prend l'avantage.
00:01:53Nous pouvons régler la personnalité sur un langage plus direct et concis.
00:01:56C'est parce que GPT 5.5 est nettement plus flagorneur et acquiesce à chaque instruction
00:02:02davantage qu'Opus 4.7.
00:02:04C'est pourquoi changer la personnalité dans Codex empêche ce comportement par défaut du modèle.
00:02:08Pour rendre Opus 4.7 direct, nous devons nous fier aux instructions dans Claude.md, alors que Codex le fait
00:02:14avec un simple changement de réglage.
00:02:16Les compétences pré-installées marquent une autre différence.
00:02:18Codex en propose beaucoup que Claude Code n'a pas, y compris la compétence de navigation par agent.
00:02:22Cela compte pour quiconque développe des applications, car dans Codex, nous n'avons pas besoin de connecter explicitement
00:02:26les MCP pour la vérification par navigateur.
00:02:29Il le fait automatiquement après avoir implémenté n'importe quelle fonctionnalité.
00:02:31Il possède aussi un créateur de compétences intégré : quand nous voulons une nouvelle compétence, il en génère une complète
00:02:35avec la bonne structure et les fichiers de référence.
00:02:38Dans Claude, nous devrions installer le créateur de compétences séparément pour obtenir une compétence
00:02:42correctement structurée.
00:02:43Sinon, il écrit simplement un fichier MD.
00:02:45Maintenant, il reste deux choses que Claude Code fait mieux.
00:02:47Codex ne propose pas de retour en arrière (rewinding), qui est la fonctionnalité que nous utilisons le plus, donc ne pas l'avoir est
00:02:51un véritable inconvénient.
00:02:52Claude Code nous permet aussi de voir son raisonnement en le développant avec Ctrl+O, ce que Codex
00:02:57ne fait pas bien.
00:02:58Visualiser le raisonnement est utile car nous pouvons corriger l'approche en cours de tâche au lieu
00:03:02d'attendre que l'implémentation se termine pour ensuite la recommencer.
00:03:05Ainsi, en voyant comment l'expérience utilisateur de Claude Code se dégrade à chaque mise à jour, Codex marque
00:03:10un point pour l'ergonomie.
00:03:11Côté coût, Claude Code est l'outil le plus cher, et de loin.
00:03:15Non pas en termes de prix réels, mais en termes d'utilisabilité pour un même prix.
00:03:19Claude Code n'est pas du tout disponible sur l'offre gratuite et ne l'est qu'à partir
00:03:23des forfaits Pro et Max.
00:03:24Les forfaits ont des tarifs presque identiques.
00:03:26Le forfait Pro est pratiquement inutilisable pour toute application d'envergure car il atteint ses
00:03:30limites en seulement quelques tâches.
00:03:32On ne peut même pas utiliser correctement Opus 4.7 pour une tâche significative sur Pro.
00:03:36Les limites s'épuisent très vite, même sur le forfait Max que nous utilisons.
00:03:39Codex est dans une meilleure position dès le départ.
00:03:41Il est disponible même sur le forfait gratuit avec un usage limité.
00:03:44Les deux utilisent un mécanisme similaire de fenêtre de 5 heures, donc pour voir lequel abat le plus de travail,
00:03:49nous les avons testés sur des tâches de même envergure.
00:03:51Claude Code a déjà une commande contextuelle qui visualise combien de tokens une session a utilisés,
00:03:56mais Codex n'a pas d'équivalent intégré, nous avons donc dû trouver une solution pour la comparaison.
00:04:00Les deux outils stockent leurs sessions sous forme de fichiers JSON, juste organisés différemment.
00:04:04Nous avons donc construit un petit outil qui les lit et compte les tokens utilisés dans chaque session.
00:04:08Sur la même application et un niveau de débogage similaire, Opus 4.7 a consommé 173 000 tokens tandis que
00:04:15GPT 5.5 n'en a utilisé que 82 000.
00:04:18C'est parce que GPT 5.5 accomplit le travail avec moins de tokens et bien moins d'essais.
00:04:23Codex a donc duré nettement plus longtemps et s'est avéré bien plus rentable pour le même travail.
00:04:28Mais avant de poursuivre, un mot de notre sponsor, Stream.
00:04:32Vous construisez une appli et vos utilisateurs ont besoin de parler, streamer et se connecter.
00:04:35Vous essayez de gérer ça vous-même et 3 mois plus tard, vous déboguez encore au lieu de livrer.
00:04:39Stream évite tout cela.
00:04:40Stream vous offre tout de suite le chat intégré, les appels vidéo, les flux d'activité
00:04:44et la modération par IA pour que vous livriez des fonctionnalités, pas une infrastructure de zéro.
00:04:49On parle de messagerie type WhatsApp, d'appels vidéo type Zoom et de flux type Instagram, tout inclus.
00:04:55Ce qui sort vraiment du lot, c'est le nouveau lancement de Stream : Vision Agents.
00:04:58Vous pouvez bâtir des agents IA intelligents qui voient, entendent et agissent sur la vidéo et l'audio en direct,
00:05:02tout ça en Python avec seulement quelques lignes de code.
00:05:05Tout tourne sur un réseau edge mondial pour une faible latence partout.
00:05:08Des startups aux applis à grande échelle, les plateformes leaders du social, du fitness et de la communauté
00:05:13font confiance à Stream pour servir plus d'un milliard d'utilisateurs finaux.
00:05:16Si vous êtes un développeur créant la prochaine grande appli, Stream évolue avec vous dès le premier jour.
00:05:20Commencez gratuitement sur getstream.io, liens dans le commentaire épinglé.
00:05:24Le vrai test pour les deux modèles réside dans leur façon de construire des produits.
00:05:27Comme dit précédemment, GPT 5.5 est plus rapide et consomme moins de tokens, il livre donc des applis fonctionnelles plus vite.
00:05:33Opus 4.7 passe plus de tokens à réfléchir, planifie plus en profondeur et itère sur tous les aspects de
00:05:38l'application en même temps.
00:05:40La planification était la première chose que nous voulions tester.
00:05:42Nous utilisons le mode planification de Claude Code depuis longtemps.
00:05:45Il couvre l'essentiel, présente quelques défauts, mais reste tout à fait exploitable.
00:05:48Nous voulions donc voir comment GPT 5.5 s'en sortait, car OpenAI affirme qu'il est meilleur
00:05:53pour planifier des tâches et les exécuter.
00:05:55Nous avons activé le mode plan et l'avons ouvert dans un dossier contenant déjà le backend d'une appli,
00:06:00une API construite avec FastAPI, et lui avons demandé d'en créer le frontend.
00:06:04Il a exploré le projet en profondeur et a posé quelques questions, mais elles étaient assez
00:06:08simples.
00:06:09Il aurait pu aller plus loin sur l'apparence souhaitée du frontend, car pour du travail
00:06:13sur le frontend, c'est important.
00:06:14Le plan qu'il a produit était très simple.
00:06:16Il incluait un résumé du flux principal, les changements clés, les pages à ajouter et comment
00:06:20les tester.
00:06:21La chose qu'il a bien faite a été de séparer clairement ses hypothèses, ainsi nous savions exactement ce qu'il
00:06:25considérait comme acquis.
00:06:26Nous lui avons dit de continuer et il a terminé en environ 8 minutes.
00:06:28La même tâche sur Claude Code a pris 24 minutes.
00:06:31Mais le plan d'Opus 4.7 était bien plus détaillé, considérait plus d'aspects de l'application,
00:06:36et a même intégré Shadcn UI pour améliorer l'expérience utilisateur.
00:06:39Opus 4.7 s'en sort donc mieux en termes de planification.
00:06:42Ensuite, nous avons voulu les tester tous les deux sur une application partant de zéro.
00:06:45Nous leur avons donné la même instruction : créer un monorepo avec un backend Python Flask et
00:06:50un frontend Next.js, avec le pipeline complet et les exigences clés sur le fonctionnement
00:06:55de l'application.
00:06:56Il est passé en mode planification de lui-même à cause de sa conception.
00:06:59Codex n'est pas passé en mode planification et a commencé l'implémentation directement.
00:07:04Il a fini bien plus vite que Claude Code, qui a pris environ 16 minutes à cause de l'étape
00:07:08de planification.
00:07:09La version de l'app de GPT 5.5 avait une UI beaucoup plus simple et se concentrait surtout sur le fait que l'app
00:07:14fonctionne.
00:07:15Elle n'a pas fonctionné correctement au début, nous l'avons donc déboguée de manière itérative.
00:07:17Une chose que nous avons remarquée est que les prompts d'entretien étaient écrits en dur car nous n'avions fourni
00:07:22aucune clé API.
00:07:23L'instruction spécifiait l'utilisation de l'API Gemini comme backend, mais comme aucune clé n'était disponible,
00:07:27il a implémenté une solution de secours pour que l'app ne plante pas complètement.
00:07:30Codex avait en fait utilisé des questions de suivi locales sans aucune instruction explicite.
00:07:35Nous aimons cela car ces mécanismes de secours sont utiles en production puisqu'ils évitent
00:07:39les plantages.
00:07:40Après quelques itérations et l'ajout de la clé API, le flux de l'app fonctionnait bien même si
00:07:44l'UI était encore simple.
00:07:46GPT 5.5 a donc anticipé les cas limites et implémenté des mécanismes pour combler les lacunes.
00:07:51Opus 4.7, quant à lui, nous a demandé de lui donner la clé API avant de commencer l'implémentation
00:07:57et a construit toute l'application autour de cela.
00:07:59Contrairement à GPT 5.5, Opus 4.7 n'a pas prévu de secours et avait besoin que tout soit disponible
00:08:05dès le départ.
00:08:06De ce fait, quand l'API n'était pas là, l'app n'avait pas de solution de secours et affichait juste une erreur.
00:08:10Claude Code se concentre sur l'expérience utilisateur et la fonctionnalité ensemble, donc son implémentation
00:08:15semblait plus réaliste.
00:08:16C'est la force d'Opus 4.7 en UI qui ressort, ce que nous avions couvert dans notre vidéo précédente où
00:08:21nous disions qu'Opus 4.7 gère bien mieux l'UI, mais son implémentation avait aussi des soucis.
00:08:26Quand nous lui avons demandé de déboguer, il n'a pas inspecté directement l'implémentation comme Codex l'a fait.
00:08:31Au lieu de cela, il a commencé à nous poser des questions sur ce qui pourrait causer le problème et s'est fié
00:08:35à nos tests.
00:08:36Il a ajouté des points de débogage comme des indicateurs dans l'UI et des logs console et nous a demandé de vérifier les états
00:08:41et de lui faire un rapport.
00:08:42Après quelques allers-retours, il a fini par corriger le problème et la fonction d'entretien a fonctionné.
00:08:46Nous avons préféré la façon dont Codex utilisait le navigateur agent pour déboguer de lui-même.
00:08:49En termes de travail autonome, l'implémentation de Codex était meilleure, et en termes
00:08:53d'expérience utilisateur, Claude Code a fait un bien meilleur travail.
00:08:56Nous avons aussi voulu tester la manière dont les deux géraient la commande init.
00:08:59L'init de Claude Code s'exécute sans développer le prompt en ligne.
00:09:02Il crée un simple fichier Claude.md d'environ 90 lignes qui inclut l'architecture, le flux de l'app,
00:09:08la structure front-end et back-end, et toutes les commandes requises pour lancer l'app.
00:09:12Une grande partie de ces informations est redondante et ne profite pas vraiment à l'agent, c'est
00:09:15pourquoi il n'est pas toujours nécessaire de tout garder.
00:09:18La configuration de Codex était plus raffinée.
00:09:20Elle incluait des directives de commit, de pull request et des instructions de sécurité appropriées
00:09:24tout en gardant la section sur la structure du projet brève au lieu de la surcharger de détails.
00:09:28Aucun des deux n'était parfait, mais Codex a mieux géré le fichier agents.md.
00:09:32Ensuite, nous avons voulu tester leurs performances sur la revue de code.
00:09:35Nous avons donné la même instruction de revue de fiabilité à Codex et à Claude Code, en leur demandant
00:09:40de documenter la revue dans des fichiers séparés tout en travaillant sur la même base de code.
00:09:44Une fois que les deux eurent généré leurs rapports, nous avons ouvert une nouvelle session et demandé à Claude de sortir le
00:09:48diff entre les deux fichiers, pour comparer les conclusions.
00:09:51La revue de Claude était bien plus détaillée.
00:09:53Elle organisait chaque constatation par priorité et incluait les composants, les extraits de code exacts
00:09:57à l'origine des problèmes.
00:09:59Le rapport de Codex mentionnait les numéros de ligne mais n'incluait pas les extraits de code réels.
00:10:03Les deux rapports étaient complets, partageant plusieurs conclusions tandis que chacun en avait trouvé quelques-unes
00:10:07que l'autre avait manquées.
00:10:08Claude Code a également signalé des problèmes de sécurité comme une clé API fuitée et une vulnérabilité.
00:10:12La tâche était pourtant une revue de fiabilité et ces problèmes étaient hors sujet.
00:10:17Claude Code a signalé chaque problème supplémentaire rencontré en chemin tandis que Codex est resté strictement
00:10:21sur la fiabilité.
00:10:22Le rapport de Codex était donc plus en phase avec la demande initiale tandis que celui de Claude Code était plus large
00:10:27mais moins focalisé sur la tâche spécifique.
00:10:29S'il fallait les décrire en termes de construction, GPT 5.5 ressemble plus à un ingénieur backend
00:10:34soucieux de livrer correctement la fonctionnalité de l'application d'abord, tandis qu'Opus 4.7 ressemble
00:10:40plus à un ingénieur full stack essayant d'équilibrer fonctionnalité et expérience utilisateur.
00:10:45Sur la gestion du contexte, Codex a été bien plus performant que Claude Code.
00:10:48Claude Code dispose d'une édition du contexte en session qui supprime les appels d'outils et les étapes de raisonnement
00:10:53qui n'ont plus d'importance dans la conversation.
00:10:55Il nettoie les informations redondantes de la session pour éviter de l'alourdir.
00:10:58Le compactage n'est pas parfait mais au moins il ne garde pas de parties inutiles dans le contexte
00:11:02lors du compactage.
00:11:03Codex n'édite pas son contexte.
00:11:05Il compacte toute la conversation telle qu'elle a eu lieu.
00:11:08La chose qu'il fait mieux est de préserver les 20 000 derniers tokens en mémoire sans compacter
00:11:13cette portion du tout.
00:11:14Cela aide à prévenir la dégradation des performances dans Codex après compactage pour que la conversation
00:11:18puisse rester fluide à partir du prompt suivant.
00:11:21Nous avons testé leurs performances et Codex a mieux réussi après la compaction que Claude Code.
00:11:25Bien que Claude Code suive un processus de compaction par étapes plus détaillé, la partie finale
00:11:30préservée par Codex rend l'agent plus utile en pratique.
00:11:33La mémoire fonctionne différemment entre les deux.
00:11:35L'interface de Claude Code est principalement sans état entre les sessions, ce qui signifie que chaque session démarre
00:11:39sans aucun contexte de la précédente.
00:11:41Il dispose désormais d'une fonction de mémoire capable de stocker des préférences ou des instructions persistantes.
00:11:46Si nous lui disons d'éviter de faire quelque chose d'une certaine manière, il l'enregistre et l'applique
00:11:50plus tard au sein du même projet.
00:11:52Cela aide lorsqu'on travaille de manière répétée sur un seul projet.
00:11:54Mais la mémoire est limitée au projet ; changer de projet fait perdre ce comportement mémorisé.
00:11:58Codex choisit la voie opposée.
00:12:00Il regroupe les informations de plusieurs sessions au fil du temps et construit une mémoire globale à travers
00:12:05les interactions pour retenir des schémas au-delà d'un seul projet.
00:12:08Cela peut favoriser la cohérence entre différentes tâches.
00:12:11En résumé, Claude Code confine davantage la mémoire à un projet alors que Codex adopte
00:12:15une approche multi-sessions et multi-projets, ce qui modifie la façon dont chacun s'adapte
00:12:19avec le temps.
00:12:20Puisque Claude Code existe depuis plus longtemps et est constamment développé pour améliorer
00:12:24l'expérience développeur, il a plus à offrir par rapport à Codex.
00:12:27Claude Code possède un système de "hooks" qui nous permet de lancer nos propres scripts à des moments précis
00:12:32du cycle de vie de l'agent, comme avant ou après l'exécution d'un outil, entre autres points, pour des choses
00:12:36comme bloquer des commandes risquées, lancer des formateurs, etc.
00:12:39Nous pouvons aussi lancer des sous-agents dans un arbre de travail dédié pour que leurs performances n'affectent
00:12:43pas les autres.
00:12:44On peut contrôler le niveau d'effort des modèles, et même utiliser des mots-clés comme "ultra-think"
00:12:48pour pousser le raisonnement à son maximum sur une tâche spécifique.
00:12:51Rien de tout cela n'a d'équivalent dans Codex pour l'instant.
00:12:54L'écosystème est l'autre victoire claire pour Claude Code.
00:12:56Nous pouvons lancer des sessions via l'application de bureau Claude et déléguer des tâches depuis l'application mobile.
00:13:01Entre Claude Code, l'app de bureau, l'app web et les extensions de navigateur, la portée est bien
00:13:06plus large que Codex, qui consiste principalement en une app web et une app de bureau sortie
00:13:11récemment et qui ne semblait pas aussi robuste lors de nos tests.
00:13:14Les sessions circulent aussi plus facilement entre les environnements sur Claude Code, ce qui est plus
00:13:18pratique pour travailler sur différentes interfaces.
00:13:20Codex possède également de nombreuses fonctionnalités intéressantes.
00:13:22Dans le cloud, il dispose d'un flag d'essai qui lance la même tâche n fois.
00:13:26Il produit plusieurs implémentations et sélectionne la meilleure.
00:13:29Claude Code peut faire quelque chose de similaire mais seulement via des configurations et des instructions, pas
00:13:33via un flag.
00:13:34L'autre fonctionnalité exclusive à Codex, qui le distingue des autres, est son intégration avec
00:13:38les modèles d'images d'OpenAI.
00:13:39Il peut les utiliser directement dans le CLI pour générer des images pour les sites web sur lesquels il travaille.
00:13:44Claude s'appuie principalement sur la génération via SVG pour les visuels, ce qui ne rivalise pas
00:13:49en termes de qualité puisqu'il n'a pas encore de modèle d'image.
00:13:52Si nous construisons une interface nécessitant de vraies images, Codex est le seul des deux à le
00:13:56faire, sans même qu'on lui demande explicitement.
00:13:58Aussi, si vous appréciez notre contenu, n'hésitez pas à cliquer sur le bouton "hype" car cela nous aide
00:14:03à créer plus de vidéos de ce genre et à toucher plus de monde.
00:14:06Les deux utilisent des sous-agents, même si le concept a été introduit par Claude en premier.
00:14:10Comme il est apparu d'abord dans Claude Code, son intégration est plus mature car il est centré sur l'agent
00:14:15et focalisé sur l'expérience de codage depuis bien plus longtemps qu'OpenAI.
00:14:19Il supporte des agents orchestrables via des sessions distantes, alors que Codex supporte principalement
00:14:23des flux de travail multi-agents à l'intérieur de l'environnement du terminal.
00:14:27La plus grande différence réside dans la manière dont chacun invoque les sous-agents.
00:14:29Claude Code peut générer des agents sans invocation explicite, alors que Codex ne crée un agent
00:14:35que si nous en faisons la demande explicite dans le prompt.
00:14:37Quand Codex génère des agents, il leur donne un nom et leur transmet également un prompt approprié.
00:14:41En performance de codage, les deux sont assez similaires, mais les choix de conception diffèrent.
00:14:46Les sous-agents de Claude Code utilisent une liste d'autorisation explicite : l'agent parent définit exactement
00:14:51quels outils le sous-agent peut utiliser, tandis que les sous-agents Codex héritent par défaut
00:14:55de l'accès aux outils du parent.
00:14:57Claude Code donne également à chaque sous-agent une fenêtre de contexte totalement neuve.
00:15:01Un sous-agent n'a pas accès à l'historique de la conversation et ne voit que le prompt du parent,
00:15:06plus le prompt système et les règles globales, car Claude privilégie l'isolation du contexte.
00:15:10Le CLI de Codex fait l'inverse.
00:15:12Il duplique tout l'historique dans la session du sous-agent, avec le prompt du parent ajouté par-dessus.
00:15:17Les agents Codex conservent plus de contexte sur ce qui a déjà été discuté, ce qui aide à améliorer
00:15:22leurs performances.
00:15:23En pratique, l'isolation stricte de Claude Code a nui à nos sous-agents de recherche.
00:15:27Lorsque nous les utilisions, les résultats n'étaient pas assez bons, car ils ne voyaient que le prompt
00:15:30immédiat et n'avaient aucun contexte préalable.
00:15:33Les agents Codex reçoivent tout l'historique, peuvent itérer plus efficacement et sont plus performants
00:15:38sur les tâches où la continuité est essentielle.
00:15:39Cela nous amène à la fin de cette vidéo.
00:15:41Si vous souhaitez soutenir la chaîne et nous aider à continuer à faire des vidéos comme celle-ci,
00:15:45vous pouvez le faire via le bouton "Super Thanks" ci-dessous.
00:15:48Comme toujours, merci d'avoir regardé et je vous retrouve dans la prochaine.