Articles
Le plafond de votre usage de l'IA, c'est votre ambition : vitesse, hauteur, profondeur, étendue
Felix Rieseberg, responsable ingénierie chez Anthropic, décompose « être plus ambitieux avec l'IA » en quatre dimensions : vitesse, hauteur, profondeur et étendue. Cet article résume sa méthode et ses exemples, puis y ajoute mes notes de mise en pratique : donner des instructions orientées objectif et orchestrer une équipe d'experts Multi-AI Agents pour une revue croisée multi-angles, afin d'améliorer la qualité du travail.
· 7 min de lecture
Felix Rieseberg, responsable ingénierie chez Anthropic, écrit dans « How to be more ambitious: A tutorial for humans with models » que, lorsqu'il voit quelqu'un obtenir des résultats impressionnants avec l'IA, lui et son entourage ont souvent la même réaction : « Nous ne sommes pas assez ambitieux. »
Mon interprétation : la limite de ce que les humains tirent de l'IA tient souvent à leur propre ambition et à leur imagination, plutôt qu'au modèle.
Il décompose l'« ambition » en quatre dimensions :
- Vitesse (Speed) : faire le même travail en moins de temps.
- Hauteur (Altitude) : monter d'un niveau d'abstraction pour viser le résultat final, et non une tâche isolée.
- Profondeur (Depth) : travailler avec les standards, les outils et les méthodes des meilleurs experts du domaine.
- Étendue (Range) : sortir d'un seul domaine et chercher des solutions à travers les disciplines.
La conclusion d'abord : donnez des instructions précises, orientées objectif, et orchestrez une équipe d'experts Multi-AI Agents pour une collaboration multi-angles et une revue croisée ; c'est ainsi que la qualité du travail monte globalement.
I. Vitesse : la plus basique, et celle où l'on bloque le moins#
Faire le même travail en moins de temps. Felix estime que tout le monde connaît déjà bien ce point, et son article l'écarte directement.
Mon avis : la vitesse est la valeur la plus évidente de l'IA, mais si l'on ne cherche que la vitesse, la façon de collaborer ne change pas beaucoup. Ce sont les trois autres dimensions qui font vraiment la différence.
II. Hauteur : poser la question de « l'objectif derrière l'objectif »#
La question centrale : quel est vraiment le résultat que je veux ensuite ? Quel est l'objectif derrière mon objectif ?
Les exemples de Felix :
- De la correction d'un crash à une application qui ne plante plus. Il demandait d'abord à Claude de corriger un seul crash, puis a changé sa demande : que l'application reste à zéro crash. Pour que cela tourne en continu et de façon automatique, il a dû d'abord modifier son propre processus : rendre les rapports de crash faciles d'accès, relier les versions de l'application aux commits Git, et permettre à Claude d'utiliser des machines Windows, macOS et Linux pour reproduire et vérifier les correctifs.
- Une montée en trois temps pour la revue trimestrielle d'activité (QBR) :
- Partir autant que possible des données brutes pour expliquer ce qui a changé ce trimestre, pourquoi, et ce qu'il faut faire ensuite.
- Identifier les 3 décisions les plus urgentes, en rédigeant pour chacune les arguments pour et contre.
- Concevoir un mécanisme de remplacement qui détecte les problèmes plus tôt que la présentation trimestrielle, le tester sur des données historiques, puis le faire tourner en parallèle du processus actuel pendant un trimestre.
Il rappelle aussi une limite : en 2026, un objectif vague comme « Claude, va gagner de l'argent pour moi » ne fonctionne pas encore, mais il s'attend à ce que le niveau d'abstraction que les modèles savent traiter continue de monter.
III. Profondeur : viser les exigences des meilleurs experts du domaine#
La méthode de Felix :
- Utiliser les outils que ce secteur utilise réellement. Le modèle se contente souvent de changer de vocabulaire sans changer de méthode, et rend un tableau Markdown pour s'en tirer. Insistez pour qu'il utilise de vrais outils d'analyse, comme une base de données ou des modèles statistiques.
- Fixer un objectif qui semble déraisonnable, et dire au modèle qu'il est atteignable. Son exemple : après avoir ramené le chargement d'un site de 10 secondes à 5 secondes, demander 200 millisecondes. Quand le modèle recule, maintenir que cet objectif peut être atteint.
- Remettre en cause les hypothèses auxquelles vous croyez. Donnez au modèle les données brutes et faites-les examiner sous un angle contradictoire. Par exemple : « Nous pensons que le départ des utilisateurs vient de l'onboarding ; essaie de reproduire cette conclusion à partir des données brutes. »
- Produire de nouvelles connaissances. Construire une simulation à partir des logs, trouver le signal de départ le plus précoce que vous ne connaissiez pas encore, puis le valider sur des données jamais vues.
- Trouver un juge extérieur (Outside Judge). Ne laissez pas le modèle se corriger lui-même. Idéalement, branchez un outil que le modèle peut exécuter directement et qui donne un retour immédiat pour valider le résultat.
Sa règle de prompt : ce que vous voulez, c'est une « version plus profonde », pas une « version plus grande ». Demandez au modèle ce que les meilleurs professionnels feraient en plus, où se trouvent les données les plus brutes, quelles méthodes et quels outils utiliser, et ce qui, en dehors du modèle ou de votre propre jugement, peut prouver que le résultat est correct.
IV. Étendue : des verbes plutôt que des noms, et monter une équipe d'experts#
- Des verbes plutôt que des noms. Felix reprend ce concept de « The Art of Innovation ». Plutôt que « une présentation », le QBR devient « faire comprendre en 30 minutes les causes et les effets à des personnes très occupées, pour qu'elles décident dans l'incertitude ». Définir l'objectif avec un verbe permet de voir quelles compétences de quels domaines sont nécessaires.
- Monter une équipe. Pour réussir la présentation, il faut un analyste, un journaliste, un éditeur ; pour la présenter sur scène, ajoutez un designer d'animation et de son. Pour une revue contradictoire, faites appel à un chercheur de fonds vendeurs à découvert (short seller) et à un expert-comptable judiciaire.
- Pas de jeu de rôle sans substance. Il ne s'agit pas de demander au modèle d'écrire « sur le ton d'un fonds vendeur à découvert », mais de lui faire exécuter réellement une des méthodes de recherche de ce type de fonds. Changer seulement de ton n'améliore pas le résultat.
La condition préalable : le modèle doit disposer d'un ordinateur sur lequel il peut installer des logiciels, et pouvoir accéder aux données pertinentes, par exemple via des connecteurs MCP.
V. Mes notes de mise en pratique : du « transfert de données » à l'« atteinte d'une intention »#
Ce qui suit est mon prolongement, nourri par l'architecture logicielle et la pratique de l'ingénierie ; ce n'est pas le contenu de l'article original.
1. Jobs to be Done et orientation par l'intention (Intent-Based)#
- Ne demandez pas « quoi faire », demandez « quoi atteindre ». La conception ne doit pas en rester à un pipeline passif de transfert de données comme
generate_deck_pdf() ; elle doit s'élever jusqu'à l'intention d'une transition d'état comme resolve_leadership_uncertainty_and_commit_budget().
- Définissez une vraie fonction de perte. Si vous ne demandez qu'un livrable, le modèle produira du vide en apparence parfait ; si vous demandez de résoudre l'incertitude de la décision, le modèle et les Sub-agent combleront d'eux-mêmes les failles logiques et les marges de risque.
2. Diverger pour explorer, converger pour valider#
- En phase d'exploration, on diverge d'abord pour trouver des possibilités, puis on converge.
- En phase de validation, on ne diverge plus. Évitez des questions sans bornes comme « de quelles autres façons peut-on faire cela ? », qui ne produisent que des généralités.
- Écrivez explicitement le périmètre de l'objectif, les contraintes et les outils de vérification objectifs (un script de test précis, un seuil sur un indicateur métier), afin que l'équipe Multi-Agent fasse ses tests de résistance dans un cadre ciblé et livre un travail de haute qualité.
Synthèse de mes notes#
- Orientation objectif : des verbes plutôt que des noms. Livrer un résultat qui résout le problème, et non un livrable produit pour s'acquitter de la tâche.
- Exploration et convergence : en exploration, diverger pour trouver des possibilités ; en validation, converger strictement et vérifier les limites.
- Focalisation par l'abstraction : partir de la question centrale pour reconstruire tout le déroulé de la tâche.
- Profondeur d'expert : ne pas se contenter d'imiter le ton des experts, mais forcer le modèle à résoudre le problème avec les outils et les méthodes des meilleurs d'entre eux.
Article original : How to be more ambitious: A tutorial for humans with models (Felix Rieseberg, 2026-10-13)