Aller au contenu
ai-workflowmodel-selectionclaudechatgptpractitioner

Ne laissez pas votre IA corriger ses propres devoirs

Avant qu'un livrable important ne quitte vos mains, donnez-le au modèle qui ne l'a pas écrit. Ce que cette habitude de quatre minutes détecte vraiment, la recherche derrière elle, et où ça relève du théâtre.

Fabian Mösli Fabian Mösli
· 13 min de lecture · 2026-08-05

L'essentiel en bref

  • • Avant qu'un livrable important ne quitte vos mains, collez-le, avec un brief de deux lignes, dans un modèle qui ne l'a pas écrit. Ne collez jamais la conversation: c'est justement ce regard neuf que vous achetez.
  • • Rapportez ensuite la critique au premier modèle et faites-le se défendre point par point. Sautez cette étape et il capitule devant chaque critique, même les mauvaises, et vous obtenez un brouillon pire qu'avant.
  • • Demandez la seconde lecture, ne l'automatisez pas. Dans des expériences préenregistrées, montrer systématiquement un second avis aux gens les a fait se méfier des bons conseils presque aussi souvent que des mauvais. Les personnes qui choisissaient quand demander en tiraient le bénéfice sans ce coût.
Dans ce guide

Je paie pour Claude et je paie pour ChatGPT, et on me demande sans cesse lequel je garderais si je devais en abandonner un. Pendant environ un an, j’ai donné une mauvaise réponse à cette question: je parlais de points forts, l’un meilleur sur les documents longs, l’autre sur l’actualité, à choisir selon votre travail.

Ce n’est pas pour ça que j’ai les deux.

La vraie raison remonte à une soirée un peu embarrassante. J’avais passé des heures avec Claude à travailler un dossier business, le genre avec une douzaine d’hypothèses liées où un seul chiffre faux empoisonne discrètement tout ce qui suit. Bonne session, le genre où vous poussez et où ça vous pousse en retour, et où à la fin vous avez vraiment réfléchi à fond. Je lui ai ensuite demandé de relire le résultat avant de le présenter à l’équipe. Il m’a dit que la logique tenait.

Par curiosité, j’ai collé la même chose dans ChatGPT, à froid, sans aucun historique de comment c’était construit. Dès le deuxième paragraphe, il m’a demandé pourquoi je traitais l’un de mes coûts unitaires comme fixe alors que rien dans le brief ne le disait. Il avait raison. J’avais fait cette hypothèse trois heures plus tôt, Claude avait construit dessus, et au moment où j’ai demandé une relecture, cette hypothèse n’était plus quelque chose à vérifier. Elle faisait partie du décor. Le dossier a survécu, mais le sol sous lui avait bougé, et je préfère le découvrir un mardi soir que devant l’équipe le jeudi.

Le second modèle, c’est donc un lecteur qui n’était pas dans la pièce pendant la fabrication.

Toute l’habitude tient en quatre étapes, et vous pouvez arrêter de lire après ce paragraphe et garder l’essentiel de la valeur. Terminez le travail dans un modèle. Ouvrez l’autre dans un chat neuf et donnez-lui deux choses: le livrable terminé, et un énoncé de deux lignes de ce qu’il devait accomplir. Jamais la conversation. Demandez-lui où le brouillon ne répond pas au brief. Rapportez ensuite ce qu’il renvoie au premier modèle et faites-le débattre de chaque point plutôt que d’acquiescer.

La suite explique pourquoi ça marche, ce que ça détecte vraiment, quand ça vous fait perdre du temps, et comment le faire dans les applis de chat ou en ligne de commande.

Pourquoi un modèle ne peut pas corriger sa propre copie

Il y a une vraie recherche derrière ça, et c’est la partie la plus solide du dossier.

À NeurIPS 2024, Arjun Panickssery, Samuel Bowman et Shi Feng ont publié LLM Evaluators Recognize and Favor Their Own Generations. Des modèles chargés de juger un texte notent leur propre production plus haut que celle d’autres modèles, sur des travaux que des annotateurs humains jugent de qualité égale. On appelle ça le biais de préférence pour soi. Ce que l’article ajoute, c’est une cause: les modèles reconnaissent leur propre écriture, bien au-delà du hasard, et quand les chercheurs ont fait varier cette capacité de reconnaissance par un réglage fin, l’ampleur du biais a varié avec elle. Plus un modèle est doué pour repérer son propre travail, plus il le flatte.

Ma traduction de profane, c’est que la familiarité fait tout le travail, et c’est exactement ce qui vous arrive avec votre propre brouillon. Vous le relisez et ça sonne bien, parce que vous savez déjà ce que chaque phrase essaie de dire. Vous n’évaluez pas le texte, vous le reconnaissez.

Une fois qu’on a vu ça, « demander à Claude de vérifier le travail de Claude » cesse de ressembler à un contrôle qualité. Le modèle qui a écrit la chose, ou qui est resté trois heures avec vous pendant que vous l’écriviez, est le lecteur le plus mal placé que vous puissiez choisir. Et un meilleur prompt n’y changera rien. J’ai déjà écrit sur la difficulté de prompter un modèle pour qu’il arrête de vous donner raison. « Sois critique » se fait balayer par la disposition de fond. C’est le même problème, un cran au-dessus, et la solution est structurelle plutôt que verbale: changez qui lit.

C’est aussi ce qui distingue ça du pipeline de recherche que j’utilise avec Perplexity et Claude. Celui-là découpe une tâche en étapes et confie chaque étape à l’outil fait pour elle. Ici, les deux modèles font le même travail sur le même matériau, et tout l’intérêt, c’est que l’un des deux ne l’a pas écrit.

Ce qu’une lecture à froid détecte vraiment

Les prompts sont faciles à copier et difficiles à juger, alors voici à quoi ressemble un de ces passages.

Le brief que j’ai donné au modèle à froid tenait en deux lignes: « Ceci est un dossier business avec une projection à cinq ans. Il doit tenir devant une équipe de direction qui demandera d’où vient chaque chiffre. »

Trois des quatre points qu’il a renvoyés étaient du bruit. Une suggestion d’ajouter une analyse de sensibilité que j’avais déjà écartée, une remarque sur la mise en forme, un avertissement générique sur la réaction de la concurrence. Ce ratio est normal, et ça vaut la peine de le dire pour que vous ne pensiez pas mal faire. Le quatrième point était celui-ci:

« Vous traitez le coût unitaire comme une donnée fixe, mais le brief ne dit pas qu’elle l’est, et la marge est justement la plus sensible à ce chiffre. S’il bouge de 10 %, le dossier ne tient plus. Soit vous justifiez pourquoi il est fixe, soit la conclusion ne tient pas. »

C’est celui-là, le bon. Pas une erreur de calcul. Une décision que j’avais cessé de voir comme une décision.

Ce qui compte plus que la trouvaille, c’est ce qui a suivi. J’ai rapporté les quatre points à Claude et je lui ai demandé de discuter chacun plutôt que de les accepter. Il a donné raison sur l’hypothèse de coût et a réécrit cette section. Sur l’analyse de sensibilité, il a résisté et expliqué pourquoi la complexité ajoutée ne changerait pas la décision que l’équipe de direction devait réellement prendre. J’étais d’accord, et nous n’avons rien changé à cet endroit.

C’est la boucle qui fonctionne: une vraie trouvaille, un refus défendu, deux points abandonnés. Prenez chaque critique du second modèle au pied de la lettre et vous finirez avec un document pire qu’au départ, parce qu’un modèle qu’on charge de relire trouvera toujours quelque chose.

La partie qui fait mal

Les preuves qui vont dans l’autre sens sont plus solides que ce qu’admettent la plupart des gens qui vantent les workflows multi-modèles, alors autant les mettre en avant tout de suite.

L’histoire rassurante, c’est que deux modèles de deux labos différents font des erreurs indépendantes, et qu’à eux deux ils rattrapent presque tout. Cette histoire est largement fausse. À l’ICML 2025, une équipe de Cornell a publié Correlated Errors in Large Language Models, le regard empirique le plus large que j’aie trouvé sur la question. Sur plus de 350 modèles, sur l’un des deux classements testés, deux modèles qui se trompaient tous les deux sur une question choisissaient la même mauvaise réponse environ 60 % du temps. Très au-dessus du hasard.

La direction de la tendance est la partie dérangeante. Les modèles plus gros et plus précis avaient davantage d’erreurs corrélées, et ça tenait à travers différentes architectures et différents fournisseurs. Tout le monde s’entraîne sur des tranches qui se recoupent du même web, et les recettes de post-entraînement ont fini par se ressembler. Deux modèles de pointe ressemblent moins à deux experts indépendants qu’à deux diplômés du même cursus qui ont simplement eu des professeurs différents.

Calibrez donc l’affirmation. Une seconde lecture rattrape une part réelle de ce que le premier modèle a manqué. Ce n’est pas un audit, ça ne vous met pas à l’abri, et là où les deux modèles se trompent avec assurance, ils se trompent généralement avec assurance dans la même direction.

Demandez-le, ne l’automatisez pas

La découverte suivante a changé ma façon de travailler, et j’aurais parié le contraire.

Trois expériences préenregistrées, publiées dans les Proceedings of the ACM on Human-Computer Interaction, ont observé ce qu’un second avis fait aux décisions humaines. Quand on montrait systématiquement un second avis à côté de la recommandation de l’IA, la sur-confiance envers l’IA baissait, ce qu’on pouvait espérer. Mais la sous-confiance montait en même temps. Les gens se sont mis à contredire l’IA quand elle avait raison. Résultat net: pas franchement meilleur. Et ça ne changeait rien que le second avis vienne d’une autre IA ou d’un pair humain.

La troisième condition fonctionnait différemment. Quand les gens pouvaient décider eux-mêmes quand aller chercher un second avis, la sur-confiance baissait sans ce coût de l’autre côté.

Un chœur permanent de désaccord semble apprendre à se méfier de tout. Choisir de demander signifie que vous avez déjà repéré quelque chose qui méritait d’être vérifié, donc vous lisez la réponse avec votre jugement en éveil.

C’est une étude de laboratoire sur la prise de décision humaine, pas sur les pipelines de relecture, donc j’extrapole. Mais ça me rend sceptique face au dispositif que la plupart des gens construisent en premier: un arrangement permanent à deux modèles où tout est vérifié croisé automatiquement avant que vous ne le voyiez. Ça produit du bruit, ça coûte le double, et ça laisse votre confiance moins bien calibrée plutôt que mieux. Gardez le second modèle à une étape volontaire de distance, et allez-y quand l’enjeu le justifie. Constat un peu agaçant, parce que la version automatisée est celle qui a l’air sophistiquée.

Vous pouvez faire l’essentiel de ça avec un seul outil

Si votre entreprise a bloqué les outils IA grand public et vous a donné Copilot ou un chatbot interne, les quatre dernières sections vous semblent probablement écrites pour quelqu’un d’autre. Ce n’est pas le cas, et c’est la partie que j’aurais aimé qu’on m’explique clairement.

Ce que vous achetez avec un second modèle, c’est un regard neuf. Un fournisseur différent en est la version la plus forte, mais pas la seule. Ouvrez un chat tout neuf dans l’outil que vous êtes autorisé à utiliser, mémoire et instructions de projet désactivées, et collez-y seulement le livrable et le brief de deux lignes. Pas d’historique, pas de raisonnement, rien sur la façon dont vous y êtes arrivé. Vous avez retiré la conversation qui rendait le modèle aveugle, ce qui fait l’essentiel de l’effet. Ce que vous n’avez pas retiré, c’est l’entraînement partagé et les habitudes partagées, donc il manquera des choses qu’un modèle vraiment différent aurait rattrapées.

Disons 60 à 70 % de la technique sans dépenser un centime, et ça marche à l’intérieur d’une stack d’entreprise sanctionnée. Apprenez la boucle là. Si vous obtenez plus tard l’accès à un second outil, vous saurez déjà l’utiliser. Les règles à deux filières s’appliquent toujours: le matériel professionnel reste dans l’outil professionnel, l’apprentissage privé se fait sur des outils privés avec du matériel privé, et les deux ne se mélangent jamais. Le guide sur le travail quand votre entreprise a bloqué ChatGPT traite cette séparation en détail.

Quand ça vaut le coup, et quand c’est du théâtre

Je tranche avec une seule question: qu’est-ce que ça me coûte si c’est faux et que je ne m’en rends compte que plus tard?

Si la réponse est « rien, je le remarquerai et je corrigerai », utilisez un seul modèle et passez à la suite. E-mails, premiers brouillons, brainstorming, résumé d’un document que vous alliez lire de toute façon, tout ce dont vous êtes le consommateur immédiat et où une erreur remonte vite à la surface. C’est le cas de presque tout mon usage de l’IA, et ça reste à un seul modèle.

La seconde lecture se justifie sur un type de travail précis: le résultat quitte vos mains, et le temps que quelqu’un trouve la faille, vous avez déjà agi dessus. Un chiffre qui entre dans un dossier business. Un mémo de stratégie sur lequel l’équipe de direction va décider. Une analyse destinée à un client, un plan de migration, un résumé de contrat sur lequel vous vous appuyez au lieu de le lire. Dans ces cas-là, vous vérifiez parce que vous aviez cessé de voir le travail environ une heure avant de le terminer.

Trois situations où c’est du théâtre, et je suis passé par les trois:

Les deux modèles reçoivent le même contexte. Donnez au second modèle toute la conversation, avec votre raisonnement et votre cadrage, et vous avez recréé les conditions qui rendaient le premier modèle aveugle. Il vous donnera raison. Livrable et brief, jamais l’historique.

Vous ne pouvez pas dire quelle réponse est meilleure. Si les deux modèles se contredisent et que vous n’avez aucun moyen de trancher, tout ce que vous avez acheté, c’est une égalité. Dans ce cas, rangez le désaccord dans l’une de deux cases. S’il porte sur un fait, allez vérifier; les modèles viennent de vous dire quel fait est essentiel. S’il s’agit d’un jugement, c’est à vous de trancher, et le désaccord a fait son vrai travail en révélant une décision que vous étiez sur le point de prendre sans vous en rendre compte. Ce qu’il ne faut pas faire, c’est garder la réponse qui vous plaisait et la déclarer vérifiée.

Vous savez déjà quelle réponse vous voulez. Vous garderez alors le modèle qui vous a donné raison et écarterez discrètement l’autre. C’est le piège que je dois surveiller chez moi, et il a exactement l’apparence de la rigueur.

Il y a aussi un coût. Anthropic a rapporté que son dispositif de recherche multi-agents consommait environ quinze fois plus de tokens qu’un échange de chat normal, et a présenté ça comme n’ayant de sens que si la tâche est assez importante pour le justifier. Les ingénieurs de Cognition sont allés plus loin et ont publié Don’t Build Multi-Agents, soutenant que répartir le travail entre agents produit un résultat incohérent parce que chacun prend des décisions implicites que les autres ne voient pas. Ils ont depuis assoupli leur position: paralléliser la réflexion, garder la rédaction sur un seul fil. C’est à peu près là où j’en suis arrivé. Relecture en parallèle, un seul rédacteur.

Comment faire dans les applis de chat

Aucune configuration technique, environ quatre minutes de travail en plus sur un livrable court.

Avant toute chose, réglez la question de là où le matériel a le droit d’aller. S’il s’agit de travail professionnel, utilisez le compte que votre entreprise a sanctionné, et vérifiez s’il s’agit d’une offre grand public ou d’une offre entreprise. Les offres grand public ont historiquement utilisé les conversations pour l’entraînement par défaut, et les offres entreprise non, et ce réglage par défaut mérite d’être vérifié plutôt que supposé. Ne collez jamais du matériel professionnel dans un abonnement personnel pour économiser quelques francs. Si le livrable est vraiment confidentiel et que vous n’avez que des comptes grand public, cette technique ne vous est pas disponible pour ce document, et aucun bénéfice de workflow ne vaut la peine d’argumenter le contraire.

Côté coût, puisque je recommande une habitude et non un achat: Claude comme ChatGPT ont des offres gratuites, et cette tâche est à peu près la plus légère qu’on puisse demander à une IA. Un livrable, une lecture, peut-être une relance. Vous pouvez tester toute la technique cette semaine sans payer personne. Ce que vous trouverez sur l’offre gratuite, c’est un modèle plus faible et un plafond de messages, ce qui est le mauvais endroit pour économiser dès que vous faites ça sur du travail qui compte.

La règle mécanique qui fait que ça marche: donnez le livrable et le brief, jamais la conversation.

Claude en tête est mon réglage par défaut pour tout ce qui est rédactionnel ou analytique. Je travaille le problème là, puis j’apporte le résultat dans ChatGPT, dans un nouveau chat:

Je vous donne un brief et un brouillon produit à partir de ce brief. Vous n’avez pas écrit ce brouillon et vous n’avez aucun enjeu dedans. Ne le réécrivez pas et ne me donnez pas de version améliorée. Dites-moi trois choses: où le brouillon ne répond pas au brief, quelle est l’affirmation la plus faible et pourquoi, et ce qu’un lecteur hostile et bien informé attaquerait en premier. Si le brouillon est en fait bon, dites-le au lieu de chercher un problème.

Cette dernière phrase compte plus qu’il n’y paraît. Sans elle, vous obtenez une critique fabriquée, qui est le même réflexe de complaisance sous un autre habit, et pire que l’éloge parce que ça a l’air rigoureux.

ChatGPT en tête pour tout ce qui dépend de faits actuels et vérifiables. Sa recherche et sa recherche approfondie ont été plus poussées pour moi, il est meilleur pour aller chercher l’information, donc la recherche et la première synthèse se font là, et Claude prend le rôle du critique. Même forme de prompt, un ajout: vérifiez chaque affirmation factuelle par rapport aux sources données et listez toute affirmation que ces sources ne soutiennent pas. Ça rattrape l’échec spécifique du travail de recherche: une phrase assurée avec une citation attachée qui ne dit pas ce que la phrase dit.

La plupart des gens s’arrêtent là, et c’est l’étape qu’ils sautent qui contient la vraie valeur:

Voici une relecture de votre brouillon par un autre modèle. Passez point par point. Pour chacun, dites si vous êtes d’accord, partiellement d’accord ou pas d’accord, et pourquoi. Là où vous n’êtes pas d’accord, défendez la version originale et ne changez rien. Ne révisez que ce que vous pensez réellement être faux.

Sans ce cadrage, le premier modèle capitule devant chaque critique, même les mauvaises, et vous obtenez un brouillon pire qui a pris deux fois plus de temps. Les modèles sont aussi conciliants entre eux qu’ils le sont avec vous.

Quelques notes pratiques après l’avoir fait souvent. Le markdown survit au trajet entre les applis, le texte formaté non, donc copiez en texte brut. Les fichiers ne passent pas, vous devez les recharger des deux côtés. La mémoire et les instructions de projet ne passent pas non plus, ce qui est exactement ce que vous voulez ici. Et si vous gardez un dispositif de critique permanent, un Claude Project ou un Custom GPT qui porte les instructions de relecture, ne le laissez pas accumuler de mémoire de vos projets, sinon vous avez lentement reconstruit le lecteur impliqué que vous cherchiez à éviter.

Si vous codez, la version en ligne de commande est meilleure

Sautez cette section si ce n’est pas votre cas. Rien de ce qui suit ne change les conseils ci-dessus.

Le livrable relu ici est un diff, et les deux agents peuvent lire le dépôt eux-mêmes. Claude Code en tête dispose d’une voie officiellement supportée: OpenAI publie et maintient un plugin qui branche Codex sur Claude Code. Installez-le depuis Claude Code:

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/codex:setup

Ça vous donne /codex:review pour une relecture standard des changements non commités, et /codex:adversarial-review, celle qui vaut vraiment le coup. Elle discute l’approche plutôt que de vérifier si le code tourne. Il y a aussi /codex:rescue pour confier un problème bloqué comme tâche déléguée, et --background pour que Codex travaille pendant que vous continuez. /codex:setup --enable-review-gate rend la relecture automatique à chaque changement, et d’après la recherche citée plus haut, je laisse ça désactivé. Le README du plugin lui-même avertit que ça « can create a long-running Claude/Codex loop and may drain usage limits quickly » (en substance: ça peut créer une boucle Claude/Codex qui tourne longtemps et épuiser vite votre quota).

Un labo construit et maintient l’outillage pour que l’agent de son concurrent puisse le consulter. Ce n’est plus un bricolage de communauté.

Codex en tête n’a pas d’équivalent dans l’autre sens, donc c’est un second terminal et un brief partagé. Bien poser ce brief partagé est ce qui évite que la relecture ne tourne à la dispute de style. Codex et la plupart des autres agents lisent AGENTS.md. Pas Claude Code. La documentation est explicite: Claude Code lit CLAUDE.md, pas AGENTS.md, donc ne maintenez pas deux fichiers qui divergent. Mettez le vrai contenu dans AGENTS.md et réduisez CLAUDE.md à une ligne:

@AGENTS.md

Tout ce qui est spécifique à Claude vient en dessous. Les deux agents travaillent maintenant à partir des mêmes standards, et un commentaire de relecture signifie que le code est faux plutôt que simplement pensé différemment. Pointez le relecteur vers git diff et le ticket, pas vers la transcription, et donnez à chaque agent son propre worktree Git s’ils tournent en même temps, sinon ils se disputeront les mêmes fichiers.

Le second abonnement vaut-il le coup?

Ce passage relève de l’opinion. Si votre travail quitte régulièrement vos mains pour être suivi d’effet, oui. Vingt dollars par mois face à un mémo qui envoie une équipe dans la mauvaise direction pendant trois semaines, ce n’est pas un calcul serré, et ce qui coûte cher n’a jamais été l’erreur elle-même. C’est tout ce qui se construit par-dessus avant que quelqu’un ne s’en rende compte. Mais je veux être honnête: c’est un vrai coût récurrent sur un salaire normal, pas une erreur d’arrondi, et ma meilleure histoire ici est un incident évité de justesse que j’ai attrapé, pas un désastre que j’ai vécu. Testez d’abord gratuitement. Si deux mois de ça ne produisent pas une trouvaille qui aurait valu le prix, n’achetez pas le second abonnement. (Je n’ai de relation d’affiliation avec aucune des deux entreprises, et il n’y a aucun lien de parrainage dans ce guide.)

Un mot honnête sur le temps, puisque j’ai déjà dit quatre minutes deux fois. Quatre minutes, c’est l’essai: un livrable, une lecture. Un vrai passage sur un document qui compte, avec l’étape de défense et un arbitrage auquel il faut réfléchir, tourne plutôt autour de vingt minutes. Toujours bon marché pour quelque chose qui va passer devant une équipe de direction, et toujours pas rien.

Ce n’est vraiment pas fait pour tout le monde non plus. Ethan Mollick, qui enseigne à Wharton et qui est probablement la voix la plus lue de ce domaine, conseille de choisir Claude ou ChatGPT, payer les vingt dollars, et confier à un agent une vraie tâche tirée de sa vie. Pour la plupart des gens, dit-il, choisir simplement celui qu’on préfère suffit. Je pense qu’il a raison pour la plupart des gens. Deux modèles ne répareront pas un brief bancal; vous obtiendrez juste deux réponses à une mauvaise question. Si vous êtes encore en train de développer la compétence de base qui consiste à écrire un bon brief, devenez bon avec un seul outil d’abord. Et si vous vous surprenez à tout faire passer par les deux modèles par anxiété plutôt que par jugement, c’est une compulsion déguisée en vérification.

Essayez-le cette semaine sur un travail, avec le compte que vous êtes autorisé à utiliser pour ça. Notez en deux lignes ce que ce travail devait accomplir. Ouvrez un chat neuf dans le modèle qui ne l’a pas écrit, collez-y ces deux lignes et le livrable terminé, et utilisez le prompt de lecture à froid ci-dessus.

Faites attention à ce que vous faites de la réponse. Si vous vous surprenez à expliquer au second modèle pourquoi il ne comprend pas le contexte, c’est en général le signe que le brouillon suppose quelque chose qu’il ne dit jamais explicitement. Ce qui vaut mieux savoir avant que quelqu’un d’autre ne le lise.

Publié le: 2026-08-05

Dernière mise à jour: 2026-08-05

Restez au courant

Ne manquez pas la suite

Je sélectionne les meilleurs outils IA pour les professionnels. Inscrivez-vous à la liste et je vous écrirai quand j'aurai quelque chose qui vaut la peine d'être partagé.La newsletter est en anglais.