L'effort de Claude Code, expliqué : dépenser du temps, pas de l'intelligence

Un collègue vous confie une tâche et vous dit : « Tu as douze heures, prends-les. » Vous relisez la demande deux fois, vous essayez les cas tordus, vous vérifiez votre propre travail, vous refaites peut-être un morceau qui ne vous plaît pas. Même collègue, même tâche, mais cette fois : « Il me faut quelque chose dans une heure. » Vous ne devenez pas moins compétent pendant cette heure. Vous visez simplement une bonne première version, vous la rendez, et vous comptez itérer ensemble.

Entre les deux scènes, vos compétences n’ont pas bougé. Seul a changé le temps que vous aviez le droit de dépenser, et donc la quantité de vérification que vous pouviez vous offrir. C’est exactement ce que fait le réglage d’effort dans Claude Code.

L’idée en une phrase

L’effort ne rend pas Claude plus intelligent : il règle combien de calcul il dépense, donc combien il vérifie et teste les cas limites.

Ce que l’effort règle vraiment

Dans l’article qui a inspiré ce billet, Thariq Shihipar décrit l’effort comme une approximation, donnée au modèle, de la quantité de calcul que vous voulez qu’il consacre à la tâche, un peu comme votre propre estimation de sa difficulté. Claude essaiera toujours de faire le travail raisonnablement. Ce qui change avec un effort plus élevé, c’est la part d’initiative qu’il prend pour juger et vérifier par lui-même.

Les niveaux que vous croiserez dans Claude Code sont low, medium, high, xhigh et max. Sur Fable 5.1 et Opus 5.5, chaque cran apporte à la fois un meilleur score aux benchmarks et davantage de tokens consommés. Et un détail pratique compte beaucoup : ces modèles répondent à l’effort sans casser le cache du prompt, c’est pourquoi on peut le changer en pleine conversation.

Revenons au collègue aux douze heures. Prendre son temps ne rend pas plus savant, et l’effort ne change pas ce que le modèle sait. Il change la forme du travail.

Là où l’effort paie : les cas limites cachés

La leçon la plus nette de la source : un effort élevé sert surtout les tâches pleines de cas limites cachés. Son exemple phare est html-js-filter, une tâche de Terminal-Bench 3.0 qui demande un nettoyeur HTML capable de retirer toutes les façons de glisser du JavaScript dans une page. Fable 5.1 est passé de 1/5 en low à 5/5 en xhigh.

La différence tient au comportement, pas au savoir. Une tentative typique en low prenait environ 2 minutes : écrire un filtre à peu près d’une traite, le tester sur une seule page écrite à la main, terminé. Un essai en effort élevé durait environ 33 minutes : relecture adverse de son propre premier jet, lecture du code source du parseur installé pour y chercher des bugs, passage d’une suite de tests XSS standard, et pour finir l’écriture d’un fuzzer de documents aléatoires. Le collègue aux douze heures, version logiciel.

On retrouve le même motif par domaine. Le taux de réussite de Fable 5.1 grimpe fortement en matériel (de 34 % à 75 %) et en sécurité (de 64 % à 87 %), là où la vérification compte, et beaucoup moins en opérations (de 12 % à 22 %), un travail qui ressemble à l’application d’un règlement.

Ce que l’effort ne répare pas

Vérifier plus longtemps ne sauve pas une mauvaise idée. La source classe chaque tentative de Terminal-Bench 3.0 selon sa manière d’échouer. Pour Fable 5.1, en passant de low à max, sur 370 tentatives, les réussites montent de 140 à 214 et les échecs pour cas oublié tombent de 59 à 24. Mais les échecs où le modèle a fait le mauvais choix, comme mal lire une exigence ou retenir la mauvaise interprétation du problème, ne passent que de 133 à 107.

Plus d’effort réduit donc les cas limites oubliés, pas une mauvaise approche. Si le plan est faux, une heure de tests minutieux en plus ne fait que polir la mauvaise chose. D’où le conseil : avant de tourner le bouton, assurez-vous que le plan est le bon.

Quel niveau pour quel travail

Le compromis a aussi un côté humain. Un effort bas permet à Claude de répondre vite avec un point de départ pendant que vous restez dans la boucle. Un effort plus haut abat plus de travail, mais Claude fait aussi davantage d’hypothèses à votre place. Sur la consigne volontairement floue « build a personal fitness and workout tracker app », le niveau low a livré un journal et un graphique simple en 1,5 minute ; max a pris 67 minutes et ajouté, entre autres, une carte de chaleur.

La règle empirique de l’auteur :

• Low : des réponses rapides en restant dans la boucle, par exemple pour un brainstorming, une esquisse, une modification facile.
• Medium : l’essentiel du travail de développement courant, comme implémenter une nouvelle fonctionnalité.
• High : le travail où la vérification compte ou où les cas limites rôdent, comme corriger un bug dans une base de code existante.
• Max : laisser Claude travailler en totale autonomie sur des problèmes difficiles, comme construire et vérifier une application de bout en bout, ou chercher des failles de sécurité dans un logiciel critique.

Pour essayer

1. Changez l’effort dans Claude Code, même en cours de conversation.

   /effort

2. Donnez une spec à Claude et demandez-lui de vous interviewer sur ce qui manque.

3. Implémentez en effort low, relisez, itérez en low si besoin.

4. Vérifiez et testez en effort high.

En bref

L’effort est un budget de temps, pas un réglage de QI. Dépensez peu quand vous voulez une esquisse et comptez piloter vous-même ; dépensez beaucoup quand le danger se cache dans les cas limites et que vous voulez que Claude vérifie son propre travail. Et quel que soit le niveau, réglez d’abord l’approche : aucune vérification supplémentaire ne sauvera une mauvaise idée.