Le modèle n'est plus le goulot d'étranglement. C'est nous.

Il y a deux façons d’utiliser le même modèle en ce moment. D’un côté, des gens qui se demandent si Claude a aidé un astronome amateur à repérer une nouvelle planète, ou Terence Tao qui parle d’une nouvelle ère pour les mathématiques. De l’autre, la grande majorité d’entre nous, qui demande encore au modèle de reformuler un mail ou de résumer une réunion.

Même outil, même abonnement, deux usages qui n’ont rien à voir.

Si la différence ne vient pas de l’outil, elle vient de ce qu’on ose lui demander. C’est la thèse d’un article que j’ai lu la semaine dernière et que je veux décortiquer ici, en le confrontant à d’autres sources et à un projet perso qui m’a servi de terrain d’essai.

Felix Rieseberg et la question de l’ambition

Felix Rieseberg est engineering manager chez Anthropic, où il dirige l’ingénierie de Claude.ai, de Cowork et de Claude Code Desktop. Il co-maintient aussi Electron, et il est passé par Slack, Stripe, Notion et Microsoft.

Le 13 octobre 2026, il a publié How to be more ambitious: a tutorial for humans with models.

Son point de départ est simple. Il répète souvent qu’il faut être « plus ambitieux » avec les modèles, et il s’est rendu compte que le conseil, tel quel, ne sert à rien. Personne ne sait quoi faire d’un « sois plus ambitieux ». Son article essaie donc de le rendre actionnable.

Il cite au passage Terence Tao, pour qui les modèles sont stupéfiants dans certaines directions et insuffisants dans d’autres. Gardez cette idée en tête, elle reviendra.

Les quatre ambitions

Felix découpe l’ambition en quatre axes.

La vitesse. Faire la même chose, plus vite. C’est le gain que tout le monde connaît et qui a déjà une valeur économique établie. Felix l’écarte volontairement, et c’est un bon choix : si on s’arrête là, on reste dans le mail reformulé.

L’altitude. Demander un résultat plutôt qu’une tâche. Se demander ce qu’on veut qu’il se passe ensuite, et ce qu’il y a au-delà de l’objectif immédiat.

Son exemple personnel : il est passé de « corrige ce bug » à « garde l’application sans bug ».

Il donne aussi un exemple de revue trimestrielle en trois étapes :

1. confier au modèle toutes les données brutes et lui demander ce qui a changé et pourquoi ;
2. lui faire isoler les trois décisions les plus urgentes, avec les arguments pour et contre ;
3. lui demander de concevoir un meilleur dispositif que le deck trimestriel pour repérer les problèmes plus tôt, et de le faire tourner en parallèle pendant un trimestre.

Un indice qu’on est sur ce terrain : le travail aurait normalement demandé des réunions.

La profondeur. Travailler comme le ferait le meilleur expert du domaine, sur les données et les outils réels plutôt que sur la surface de la tâche.

Là où le modèle produirait volontiers un tableau markdown, exiger une base de données et un modèle statistique. Se fixer des objectifs déraisonnables et les traiter comme raisonnables : viser 200 ms de chargement quand l’objectif actuel est de 5 secondes.

Et surtout, point sur lequel je reviendrai : faire juger le travail par quelque chose d’extérieur au modèle, plutôt que de lui demander s’il est content de ce qu’il a fait. La nuance compte : c’est le modèle qui lance le juge, idéalement un outil qu’il peut exécuter lui-même pour avoir un retour immédiat, mais ce n’est pas lui qui rend le verdict. Un test qui échoue ne se laisse pas convaincre.

L’étendue. Puiser dans plusieurs disciplines, plus qu’il n’aurait été rentable de le faire avant.

Felix reprend une astuce de The Art of Innovation de Tom Kelley et Jonathan Littman : remplacer les noms par des verbes. Une « revue trimestrielle » devient « amener des gens occupés à croire une histoire de cause à effet et à décider dans l’incertitude ». Dit comme ça, on voit tout de suite qu’un journaliste, un monteur ou un analyste auraient leur mot à dire.

D’où l’idée de constituer une équipe de spécialistes, red team comprise. Avec une nuance que je trouve très juste : demander au modèle de faire ce que fait un spécialiste, pas d’écrire comme lui. Le jeu de rôle rend les échanges plus étranges sans rendre le résultat meilleur.

Et il pose une condition à tout ça : le modèle a besoin d’un ordinateur qu’il peut utiliser, pour installer des logiciels, et d’un accès aux données utiles.

Pour son exemple des crashs, Felix a d’abord dû refaire son propre workflow : donner à Claude les rapports de crash, la correspondance entre versions de l’app et commits git, et des machines de test sous Windows, macOS et Linux pour reproduire et vérifier les correctifs.

Un exemple : FinOps Terminal

Je me suis retrouvé, sans l’avoir planifié, à tester cette grille sur un projet perso. Je me suis fixé un objectif volontairement démesuré : m’inspirer du Bloomberg Terminal pour construire mon propre terminal de marché, gratuit, pour mon usage personnel.

Le Bloomberg Terminal, c’est l’outil de référence des salles de marché, facturé autour de 32 000 dollars par an et par poste selon les estimations publiques.

Je le dis tout de suite pour que ce soit clair : FinOps Terminal ne joue pas dans la même catégorie et ne prétend pas le faire.

Il lui manque des pans entiers de ce qui fait Bloomberg :

• le chat entre abonnés, qui est en grande partie ce qui retient les utilisateurs ;
• l’API et l’intégration aux outils des salles de marché ;
• la fraîcheur des données, puisque j’utilise des sources gratuites dont certaines sont différées et non officielles, là où Bloomberg vend du temps réel sous licence ;
• la vitesse et la fiabilité d’une infrastructure professionnelle.

C’est un exemple pour illustrer le propos de Felix, pas un concurrent.

Ce qui m’intéresse, c’est comment les trois axes ont joué.

L’altitude. Je n’ai pas demandé « fais-moi un graphique de cours ». J’ai demandé un terminal.

Le résultat est une app macOS en SwiftUI avec 17 fonctions pilotables au clavier (cotation, graphiques, fondamentaux, dépôts SEC, courbe des taux, screener, portefeuille, alertes…), une app iPad qui peut servir de clavier de terminal, des tableaux de bord sur Apple TV et un backend dédié.

FinOps Terminal sur Mac. Les fonctions s’appellent par leur mnémonique (CHART, DESC, FIN, DCF…) ou d’un clic dans la barre latérale.

Un détail résume bien l’état d’esprit. Le Bloomberg Terminal est célèbre pour son clavier physique, avec ses touches de couleur : une touche par classe d’actifs, un GO pour lancer une commande, un CANCEL pour revenir en arrière. Je n’ai pas ce clavier. Plutôt que de laisser tomber l’idée, j’ai demandé à l’iPad de jouer ce rôle. En mode Keypad, il pilote le panneau actif du Mac avec des touches de marché, des touches de fonction, un CANCEL rouge, un GO vert, un pavé numérique et des raccourcis vers les listes de suivi. Il manquait un morceau de matériel, on l’a remplacé par un appareil qu’on avait déjà sous la main.

Pas de clavier Bloomberg ? L’iPad en tient lieu. Ticker, touche jaune, fonction, GO.

La profondeur. Le projet n’a pas commencé par du code mais par une étude « clean room » du Bloomberg Terminal, uniquement à partir de documentation publique : comment les professionnels s’en servent, la grammaire titre → fonction → GO, les panneaux liés, le contexte qui suit d’un écran à l’autre.

C’est exactement le « que ferait le meilleur expert du domaine ? » de Felix.

Derrière, de vraies sources de données (SEC EDGAR, FRED, Yahoo Finance, Binance) et de vraies méthodes : valorisation par actualisation des flux, études d’événements, analyse du sentiment des news par Claude.

L’étendue. SwiftUI, Python et FastAPI, iPadOS, tvOS, Docker, TimescaleDB, Proxmox, Tailscale, flux crypto en temps réel. Pour une seule personne, couvrir autant de domaines n’aurait jamais été rentable avant.

Un tableau de bord composé sur le Mac et affiché sur l’Apple TV du salon.

Mais la partie qui illustre le mieux l’article, c’est la condition de Felix. J’ai donné à l’IA quasiment les pleins pouvoirs.

Elle avait un jeton d’API sur mon Proxmox. Elle a créé elle-même la machine virtuelle à partir d’une image Debian avec cloud-init, y a installé la clé SSH, a configuré le pare-feu, Tailscale et la stack Docker Compose, puis a déployé le backend. Les scripts sont idempotents, donc elle pouvait relancer chaque étape après une erreur sans rien casser.

Une précision quand même, pour qu’on ne retienne pas seulement « donnez une clé root à votre IA » : le jeton est injecté depuis 1Password sans jamais apparaître en clair, et tout tourne sur mon homelab, pas en production.

Et surtout, elle avait le droit de tester tout le logiciel de A à Z. La VM répond, l’API accepte la connexion, l’app Mac récupère les données, les tests pytest et swift test passent.

Attention, ce n’est pas l’IA qui a jugé son propre travail. Elle n’avait pas à me dire « c’est bon, ça marche » : presque à chaque étape, c’est une vraie machine qui répondait à sa place. La VM démarre ou ne démarre pas, l’API répond ou ne répond pas. L’IA lançait le juge, le juge rendait le verdict. C’est exactement la distinction de Felix.

Avec une limite que je préfère dire : les tests, c’est aussi elle qui les a écrits. Un juge que l’on rédige soi-même n’est qu’à moitié indépendant. Le dernier mot revient donc à l’infrastructure réelle et à moi, en utilisant l’app.

Le résultat : 4 jours, 31 commits, environ 19 000 lignes de Swift et de Python.

Le vrai sujet : l’auto-efficacité

La partie de l’article de Felix qui m’a le plus marqué n’est pas la méthode. C’est sa réponse à la question : pourquoi est-ce si difficile d’être ambitieux ?

Sa réponse : on est limité par ce qu’on croit possible. On ne se fait confiance que dans un périmètre étroit.

Il rappelle que Michel-Ange se considérait comme sculpteur et ne voulait pas peindre la chapelle Sixtine.

Le concept derrière porte un nom en psychologie : l’auto-efficacité, la croyance en sa propre capacité à réussir une tâche. Et cette croyance influence la performance réelle.

Le concept vient d’Albert Bandura, qui l’a formalisé en 1977 et lui a identifié quatre sources. Ce qui est intéressant, c’est que les exemples de Felix en couvrent trois.

Croire que c’est possible. En 1939, George Dantzig, étudiant à Berkeley, arrive en retard en cours, recopie deux problèmes au tableau en pensant que c’est un devoir, et les résout. C’étaient deux problèmes de statistiques réputés non résolus. Personne ne lui avait dit que c’était impossible.

Voir les autres réussir. Roger Bannister court le mile en moins de quatre minutes en mai 1954. Il reste seul à l’avoir fait pendant 46 jours, avant que John Landy ne le batte.

Plus récemment, en avril 2026 au marathon de Londres, Sabastian Sawe est devenu le premier à courir un marathon officiel en moins de deux heures, en 1:59:30. Et dans la même course, Yomif Kejelcha est passé sous les deux heures lui aussi.

Avoir le droit d’échouer. The Inner Game of Tennis, de Timothy Gallwey, défend l’idée que trop vouloir bien faire dégrade la performance.

Et Linus Torvalds a annoncé Linux en 1991 comme « juste un hobby », qui ne serait pas un gros projet professionnel.

La quatrième source de Bandura, Felix ne la nomme pas, et c’est pourtant celle qu’on considère comme la plus puissante : l’expérience de maîtrise. Avoir déjà réussi soi-même quelque chose de comparable.

J’en tire une conclusion très pratique : l’ambition avec les modèles ne se décrète pas, elle se construit. Chaque objectif un peu trop gros qui aboutit, et qui est vérifié, rend le suivant plus facile à oser.

Felix s’appuie aussi sur la revue de Locke et Latham, qui synthétise 35 ans de recherche sur la fixation d’objectifs : les gens à qui on donne des objectifs précis et difficiles font mieux que ceux à qui on dit simplement « faites de votre mieux ».

Et sur la liste Fast de Patrick Collison, qui recense des réalisations obtenues avec des objectifs audacieux et des délais serrés.

Sa conclusion : l’auto-efficacité est un vieux problème, mais il compte plus que jamais, parce que les capacités des modèles progressent toutes les quelques semaines. Ce qu’on croyait impossible le mois dernier ne l’est peut-être plus.

Les contrepoints

Je ne veux pas en rester à l’enthousiasme, parce que plusieurs études nuancent sérieusement le discours.

La frontière irrégulière. En 2023, une équipe de Harvard et du BCG menée par Fabrizio Dell’Acqua a fait travailler 758 consultants avec et sans GPT-4.

Sur les tâches que l’IA maîtrisait bien, les consultants assistés ont bouclé 12 % de tâches en plus, 25 % plus vite, avec un travail jugé 40 % meilleur.

Mais sur une tâche choisie pour être juste au-delà de ce que le modèle savait faire, ils ont été nettement moins nombreux à trouver la bonne réponse que ceux qui travaillaient sans IA.

Ethan Mollick, co-auteur, appelle ça la frontière technologique irrégulière : on ne sait pas toujours de quel côté on se trouve. C’est exactement le constat de Tao. Être ambitieux sans le savoir, c’est sortir de la frontière.

La perception n’est pas un juge. En 2025, l’organisme METR a mené un essai randomisé avec 16 développeurs open source expérimentés, sur 246 tâches réelles de leurs propres dépôts.

Avant l’expérience, ils pensaient que l’IA les rendrait 24 % plus rapides. Après, ils estimaient avoir gagné 20 %. Mesuré, ils avaient été 19 % plus lents.

L’échantillon est petit et les outils ont beaucoup progressé depuis, mais le message reste : notre impression d’efficacité ne prouve rien.

Le mythe Bannister. L’histoire de la barrière psychologique tombée d’un coup est en partie une légende. John Landy avait échoué plusieurs fois avant de réussir, et il était déjà tout près du record. La croyance compte, mais elle ne suffit pas : il fallait aussi l’entraînement.

Ce que le modèle ne m’a pas donné. Mon étude du Bloomberg Terminal le disait dès le départ : sa valeur durable tient à l’ampleur de ses données, à la vitesse de navigation et à son réseau.

Le modèle m’a donné la vitesse de navigation, et beaucoup de logiciel. Il ne m’a donné ni les données sous licence, ni le réseau d’utilisateurs, ni l’infrastructure.

C’est la frontière irrégulière vue sur un cas concret : l’ambition paie sur ce qui relève du logiciel, elle bute sur ce qui relève de l’accès et des gens.

Tout ça converge vers le même point. Le juge extérieur de Felix n’est pas un détail de méthode, c’est ce qui rend l’ambition sûre.

Sans lui, un objectif démesuré produit surtout des choses qui ont l’air de marcher. Avec lui, on sait de quel côté de la frontière on est.

Oser demander plus

En mars 2023, Simon Willison écrivait que le développement assisté par l’IA le rendait plus ambitieux, parce qu’il abaissait son seuil pour décider qu’un projet valait le coup. Des idées qui demandaient plusieurs jours de travail devenaient faisables en une heure.

Trois ans plus tard, le seuil est encore plus bas.

La question n’est plus vraiment de savoir ce que le modèle sait faire. C’est de savoir si on ose lui demander, si on lui donne un ordinateur et des données pour le faire, et si on a prévu de quoi vérifier le résultat.

Le reste, comme dit Felix, c’est une affaire de confiance en soi. Et ça, ça se travaille.

---

Sources

• Felix Rieseberg, How to be more ambitious: a tutorial for humans with models, felixrieseberg.com
• Terence Tao, Math 2.0, terrytao.wordpress.com
• Gizmodo, Did Claude help an amateur astronomer discover a new planet?, gizmodo.com
• Fabrizio Dell’Acqua et al., Navigating the Jagged Technological Frontier, Harvard Business School et BCG, d3.harvard.edu
• Ethan Mollick, Centaurs and Cyborgs on the Jagged Frontier, oneusefulthing.org
• METR, essai randomisé sur la productivité des développeurs expérimentés, résumé par Axios
• Albert Bandura, Self-Efficacy: Toward a Unifying Theory of Behavioral Change (1977), présentation sur simplypsychology.org
• Edwin Locke et Gary Latham, rétrospective sur 35 ans de recherche sur les objectifs, stanford.edu
• Patrick Collison, Fast, patrickcollison.com
• Simon Willison, AI-enhanced development makes me more ambitious with my projects, simonwillison.net
• NPR, Kenya’s Sabastian Sawe is first person to run sub-2-hour marathon, kunc.org
• Brain Food, The four-minute mile, brainfood.substack.com
• CostBench, prix estimé du Bloomberg Terminal, costbench.com
• FinOps Terminal, dépôt GitHub, github.com/gh-prim/finops-terminal
• Image d’en-tête : Debasish Biswas, Hillary Step near Everest top, Wikimedia Commons, licence CC BY-SA 4.0, recadrée