Être plus ambitieux avec l'IA : la méthode de Felix Rieseberg, lue par une équipe d'ingénierie

Le 13 octobre 2026, Felix Rieseberg, engineering manager chez Anthropic où il a dirigé l'ingénierie de plusieurs produits Claude, a publié un court tutoriel pour rendre opérationnel un conseil devenu slogan : « soyez plus ambitieux avec l'IA »¹. Le 15 octobre, Ken Huang relevait déjà plus de 3,1 millions de vues pour son annonce². Voici ce que j'en retiens, et ce que cela change pour une équipe d'ingénierie.

Un slogan enfin outillé

Dans les équipes qui travaillent sur l'IA, « nous ne sommes pas assez ambitieux » est devenu un réflexe. Felix Rieseberg l'admet lui-même : c'est devenu « a rallying cry », un cri de ralliement qu'on poste sous chaque démonstration spectaculaire¹. Un cri de ralliement ne dit pas quoi taper dans le prompt du lendemain matin.

Rieseberg est bien placé pour en parler. Il se présente sur X comme « an eng lead working on Claude »³ et, sur son site, comme engineering manager chez Anthropic, où il a dirigé l'ingénierie de Claude.ai, de Cowork et de Claude Code Desktop. Il est aussi co-mainteneur d'Electron¹. Son point de départ est une phrase de Terence Tao, qu'il cite : les modèles sont « astounding in some directions, while inadequate in others »¹. Certains utilisateurs ont appris à piloter les capacités spectaculaires ; beaucoup d'autres en sont encore à demander la capitale de la France ou à adoucir un mail énervé.

Son tutoriel découpe l'ambition en quatre types¹. Je les trouve utiles parce qu'ils se transforment en questions à poser avant de lancer une tâche.

Speed : l'acquis

La vitesse, c'est le même travail en moins de temps. Écrire du code plus vite avec Claude, par exemple. Rieseberg la décrit comme le « bread and butter » de la valeur économique de l'IA et la passe en une ligne, parce qu'elle ne demande aucune créativité¹. La plupart des organisations en restent pourtant là, et c'est le piège : mesurer le gain d'un assistant au nombre de lignes produites, c'est rester au rez-de-chaussée.

Altitude : viser le but derrière le but

La question centrale de l'altitude tient en une phrase : « what do you want to happen next? »¹. Quand on confie une tâche à un modèle, il exécute notre meilleure hypothèse sur la manière d'obtenir un résultat. Monter en altitude, c'est lui confier le résultat.

L'exemple de Rieseberg parlera à tous les responsables d'applications. Début 2025, il demandait encore à Claude de corriger des crashs un par un. Il a fini par lui demander de « simply keep our apps crash-free ». Le détail qui compte est la suite : pour que ce soit possible, il a d'abord fallu que le modèle puisse récupérer les rapports de crash, relier chaque version à un commit git et disposer de machines Windows, macOS et Linux pour reproduire et vérifier ses correctifs¹. L'altitude se paie en plomberie.

Son deuxième exemple est plus quotidien : la revue trimestrielle (QBR). Premier palier, donner au modèle toutes les données disponibles et demander ce qui a changé, pourquoi, et quoi faire. Deuxième palier, lui faire identifier les trois décisions les plus urgentes avec arguments pour et contre. Troisième palier, plus radical : concevoir un meilleur dispositif qu'un deck trimestriel pour détecter les problèmes, prouver sur l'historique de l'entreprise qu'il les aurait vus plus tôt, et le faire tourner en parallèle pendant un trimestre¹. Rieseberg donne un indice simple : si une tâche va donner lieu à des réunions, c'est probablement un bon candidat. Il reconnaît aussi les limites actuelles, « Claude, go make money » ne fonctionnant pas encore pour la plupart des entreprises¹.

Depth : travailler comme le meilleur du domaine

La profondeur, c'est exécuter une tâche comme le ferait un expert de premier plan, en descendant d'un niveau vers les données, les outils et les problèmes sous-jacents¹. Rieseberg liste cinq techniques. Exiger les instruments des meilleurs : quand le modèle produit des tableaux Markdown, demander des bases de données et des modèles statistiques. Fixer des objectifs déraisonnables et affirmer qu'ils sont raisonnables : si votre site charge en 10 secondes, ne demandez pas 5, demandez 200 ms. Confronter ce que l'on croit savoir aux données brutes, par exemple en demandant au modèle de reproduire depuis les logs l'hypothèse selon laquelle le churn vient de l'onboarding. Produire de la connaissance nouvelle, comme une simulation des clients qui retrouve un signal de churn encore inconnu. Enfin, recourir à un juge extérieur¹.

Il propose un prompt de « deepening » que je recommande de garder sous la main. Il commence par « I want a deeper version of this task, not a bigger one ». Le modèle doit ensuite dire ce qu'un professionnel de haut niveau ferait que l'on ne demande pas, nommer la matière la plus brute dont il partirait, citer ses méthodes et ses outils précis, et indiquer ce qui, en dehors de lui et de nous, prouverait que le résultat est juste. Puis il réécrit la demande initiale¹.

Le juge doit sortir de la pièce

Pour une équipe d'ingénierie, cette dernière question pèse plus que les autres. Rieseberg l'écrit en toutes lettres : « Do not ask the model to judge itself. » Il pense que le problème se résoudra avec des modèles plus intelligents, mais en octobre 2026 il insiste sur une validation extérieure, idéalement un outil que le modèle peut exécuter lui-même pour obtenir un retour immédiat¹.

Traduit dans notre métier, ce juge a des noms connus : une suite de tests, un benchmark de performance mesuré plusieurs fois, un jeu de validation que le modèle n'a pas vu, des métriques de production. Paul Kuo l'a relevé le 17 octobre 2026 sur paulkuo.tw : les résultats doivent être vérifiés « against original sources or executable tools », et le processus de revue protégé par des permissions appliquées couche par couche et des journaux relus⁴. Il rappelle même que, quand deux modèles se trompent sur une même question, ils donnent la même mauvaise réponse environ six fois sur dix, d'après une étude de Kim et al. qu'il cite, menée sur plus de 350 modèles et deux benchmarks de classement⁵. Sans juge extérieur, l'ambition produit surtout des démonstrations convaincantes.

Range : remplacer les noms par des verbes

L'étendue consiste à mobiliser plus de disciplines que la tâche n'en réclame en surface, plus qu'il n'aurait été économique de le faire auparavant. Rieseberg emprunte une technique à The Art of Innovation de Tom Kelley et Jonathan Littman : remplacer les noms par des verbes. Une revue trimestrielle n'est pas « un deck », c'est convaincre des gens occupés d'une histoire de cause à effet et les faire décider dans l'incertitude, en 30 minutes. Une fois le verbe posé, on voit quels métiers convoquer : un analyste, un journaliste, un éditeur, puis une red team composée d'un short seller et d'un forensic accountant¹.

Rieseberg ajoute une mise en garde. Le jeu de rôle rend la conversation plus étrange sans améliorer le résultat : on demande au modèle de faire ce qu'un short seller fait pour instruire sa position, pas d'écrire comme un short seller. Il précise aussi un prérequis qui vaut pour tous les axes : le modèle doit disposer d'un ordinateur où installer des logiciels et d'un accès aux données utiles, via des connecteurs MCP ou autrement¹.

Croire que c'est possible, et s'autoriser à rater

La dernière partie du texte quitte la technique pour la psychologie. Rieseberg s'appuie sur la notion de self-efficacy (le sentiment d'efficacité personnelle)¹ et sur la synthèse d'Edwin A. Locke et Gary P. Latham, « Building a practically useful theory of goal setting and task motivation: A 35-year odyssey » (American Psychologist, vol. 57, n° 9, 2002) : des objectifs précis et difficiles produisent de meilleures performances qu'un simple « faites de votre mieux »⁶. Il renvoie aussi à la liste « Fast » de Patrick Collison, un catalogue de réalisations menées avec des objectifs audacieux et des délais serrés¹.

Ses exemples sont bien choisis. En 1939, George Dantzig, arrivé en retard à un cours de Jerzy Neyman à Berkeley, recopie deux problèmes inscrits au tableau, les prend pour des devoirs et les rend résolus : c'étaient deux problèmes ouverts, comme il le raconte lui-même dans un entretien de 1986⁷. Roger Bannister court le mile en 3 min 59 s 4 le 6 mai 1954 à Oxford et reste seul sous les quatre minutes pendant 46 jours¹, jusqu'aux 3 min 58 s 0 de John Landy à Turku le 21 juin 1954. Le 26 avril 2026, à Londres, Sabastian Sawe court le premier marathon officiel sous les deux heures, en 1 h 59 min 30 s, et Yomif Kejelcha, deuxième, passe aussi sous la barre en 1 h 59 min 41 s pour son premier marathon⁸. Pour le droit à l'échec, Rieseberg cite The Inner Game of Tennis et l'annonce de Linux, présenté par Linus Torvalds sur le groupe Usenet comp.os.minix le 25 août 1991 comme « just a hobby, won't be big and professional like gnu »¹.

Rieseberg parle de s'autoriser à échouer¹. J'en tire un message pour les managers : si une tentative ambitieuse coûte cher en cas d'échec, personne ne la tentera. Avec des agents, une tentative ratée coûte quelques heures de calcul, à condition qu'un juge extérieur dise qu'elle a raté.

De l'humeur au protocole

En quelques jours, la communauté a fait ce que fait toujours la communauté logicielle : elle a transformé le texte en code. Dès le 14 octobre, Trey Causey écrivait avoir déjà utilisé ces conseils plusieurs fois dans la journée⁹. Ken Huang résume l'enjeu dans un titre efficace, « Your Agent Isn't Lazy. It Has No Protocol for Ambition. » Son argument : sous pression, avec une échéance, la version ambitieuse perd contre la version rapide à chaque fois, sauf protocole. Il en a tiré work-hard-protocol, un fichier de skill unique sous licence MIT qui convertit le tutoriel en sept règles dures, trois protocoles exécutables et quatre playbooks par domaine².

D'autres ont suivi. Le skill be-ambitious de RoboNuggets reformule une demande sur les axes altitude, profondeur et étendue, liste les accès et données manquants, et réécrit le prompt en terminant par un contrôle extérieur assorti d'un critère de réussite¹⁰. Le skill ambition d'Erik MacKinnon, sous licence MIT, cherche le résultat derrière la demande, les méthodes des meilleurs, des techniques venues d'autres domaines et une cible qui paraît déraisonnable mais reste atteignable, puis attend l'approbation de l'utilisateur¹¹. Dan McAteer a publié /be-ambitious, construit sur les questions du prompt de deepening¹², et arome3 un deepen-prompt centré sur ce seul prompt¹³. En français, zoesagan.com en a tiré un « prompt de la hauteur » qui fusionne altitude, profondeur et étendue, avec deux règles maison : ne rien inventer, et ne rien déclarer fini sans preuve extérieure¹⁴.

Le point commun de ces implémentations m'intéresse davantage que leurs différences : toutes ajoutent une étape de réécriture avant exécution, et toutes rendent explicite le juge extérieur.

Ce que ça change pour une équipe d'ingénierie

Chez SFEIR, nous nous définissons comme une AI Engineering Company, et ce texte décrit assez bien la frontière entre « utiliser l'IA » et « faire de l'ingénierie avec l'IA ». J'en tire quelques conséquences pratiques.

L'altitude est un chantier d'infrastructure avant d'être un prompt. L'exemple « crash-free » ne fonctionne que parce que le modèle a accès aux rapports de crash, à l'historique git et à des environnements de test sur trois systèmes¹. Pour un DSI, la question utile devient : à quoi nos agents ont-ils le droit d'accéder, et dans quelles conditions de sécurité ?

Le juge extérieur doit devenir un livrable. Tests automatisés, observabilité, jeux d'évaluation : tout ce que les bonnes équipes faisaient déjà pour les humains devient la condition pour confier davantage aux modèles. Plus le mécanisme de vérification est fiable, plus on peut déléguer gros⁴.

La profondeur se joue au cadrage. Avant de lancer un chantier, demander à l'agent ce qu'un expert ferait, de quelle donnée brute il partirait et comment on saura que c'est juste prend cinq minutes et change souvent le périmètre. C'est une pratique que l'on peut ritualiser en revue de conception.

L'ambition se standardise. Un skill partagé dans le dépôt de l'équipe vaut mieux qu'une exhortation en réunion, parce qu'il applique la même discipline à chaque tâche, y compris un vendredi soir². C'est le passage de l'humeur au protocole.

Un mot de prudence. Les réactions relayées sur X sont enthousiastes, mais une objection s'impose : l'ambition a un coût en calcul, et un objectif déraisonnable sans juge ni budget devient vite une boucle, patch après patch. Rieseberg conclut d'ailleurs en demandant qu'on lui signale d'autres techniques¹. Prenons-le au mot : choisissez une tâche confiée à l'IA cette semaine, reposez-la un niveau plus haut, et donnez-lui un juge.

Sources

1. Felix Rieseberg, « How to be more ambitious: A tutorial for humans with models » (texte source : les quatre types, le prompt de deepening, la consigne « Do not ask the model to judge itself », la citation de Terence Tao, la self-efficacy, Collison, Dantzig, Bannister, Linux) — felixrieseberg.com, 13 octobre 2026.
2. Ken Huang, « Your Agent Isn't Lazy. It Has No Protocol for Ambition. » (vues de l'annonce au 15 octobre, work-hard-protocol, argument du protocole ; article en partie payant) — kenhuangus.substack.com, 15 octobre 2026.
3. Felix Rieseberg (@felixrieseberg), annonce du tutoriel, « I'm an eng lead working on Claude » — x.com, 13 octobre 2026.
4. Paul Kuo, « Want AI to Do Bigger Things? Build the Mechanisms That Catch Its Mistakes First » (vérification contre les sources et les outils exécutables, permissions et journaux) — paulkuo.tw, 17 octobre 2026.
5. Elliot Kim, Avi Garg, Kenny Peng et al., « Correlated Errors in Large Language Models » (plus de 350 modèles, deux benchmarks de classement), citée par Paul Kuo — arxiv.org, 2025.
6. Edwin A. Locke et Gary P. Latham, « Building a practically useful theory of goal setting and task motivation: A 35-year odyssey », American Psychologist, vol. 57, n° 9, p. 705-717, 2002.
7. D. J. Albers et C. Reid, « An Interview with George B. Dantzig: The Father of Linear Programming », The College Mathematics Journal, vol. 17, n° 4, 1986 (le récit des deux problèmes ouverts et du cours de Jerzy Neyman).
8. NBC Sports, « Sabastian Sawe runs first sub-2-hour marathon race, shatters world record in London » (1 h 59 min 30 s ; Yomif Kejelcha deuxième en 1 h 59 min 41 s) — nbcsports.com, 26 avril 2026.
9. Trey Causey, « On "How to be more ambitious: A tutorial for humans with models" » — treycausey.com, 14 octobre 2026.
10. RoboNuggets, skill be-ambitious (MIT) — github.com, octobre 2026.
11. Erik MacKinnon, skill ambition (MIT, v1.3.0) — github.com, octobre 2026.
12. Dan McAteer, skill be-ambitious — github.com, octobre 2026.
13. arome3, skill deepen-prompt — github.com, octobre 2026.
14. La rédaction (z/S SYSTEMS), « L'ambition se programme : la méthode Rieseberg et le prompt de la hauteur » — zoesagan.com, 15 octobre 2026.
15. Terence Tao, « Math 2.0 », billet du 10 octobre 2026 vers lequel renvoie Rieseberg (lecture complémentaire ; la citation reprise plus haut est celle de l'essai de Rieseberg) — terrytao.wordpress.com.