IA : comment être plus ambitieux dans ses demandes ?
Les quatre formes d’ambition selon Felix Rieseberg, puis une méthode en deux conversations pour préparer une demande précise avec des critères de vérification.
Que demander après une première réponse utile ?
Vous demandez à une IA de corriger un bouton. Elle propose un changement cohérent. Pourtant, le formulaire reste difficile à utiliser : les erreurs arrivent trop tard et certains champs demandent une information que le client ne possède pas. La demande initiale laissait une grande partie du problème hors champ.
Dans « How to be more ambitious: A tutorial for humans with models », publié le 13 octobre 2026, Felix Rieseberg propose quatre façons d’élargir ses demandes. Engineering Manager chez Anthropic, il indique avoir dirigé l’ingénierie de Claude.ai, Cowork et Claude Code Desktop. Voici les principes de son article, puis une application que je propose pour un projet web.
Les quatre formes d’ambition selon Felix Rieseberg
- Vitesse : réaliser le même travail en moins de temps. C’est l’usage déjà familier sur lequel l’auteur s’attarde peu.
- Altitude : remonter de la tâche au résultat recherché, puis donner au modèle les moyens de le poursuivre.
- Profondeur : travailler avec les données brutes et les méthodes du métier, contester les hypothèses et vérifier le résultat indépendamment.
- Étendue : emprunter à d’autres disciplines leurs techniques concrètes, en évitant le simple jeu de rôle.
Son conseil sur la validation mérite d’être conservé tel quel : « Do not ask the model to judge itself. » Autrement dit : ne demandez pas au modèle de se juger lui-même (traduction du Journal).
Que manque-t-il à « Tu es expert en… » ?
« Tu es expert en UX, améliore ce formulaire » donne une orientation, mais laisse les décisions essentielles ouvertes. Quels utilisateurs rencontre-t-on ? Que peut-on modifier ? Sur quelles observations faut-il s’appuyer ? Le rôle annoncé ne répond pas à ces questions. Je propose de les traiter dans la demande elle-même.
Pour notre formulaire fictif, on peut demander d’examiner la validation des champs, de distinguer les erreurs détectées avant l’envoi de celles renvoyées par le serveur et de vérifier que la saisie reste disponible après un échec. Ces termes techniques désignent des comportements que l’équipe peut examiner. Ajouter du jargon sans expliquer son rapport au problème rendrait la demande plus difficile à relire.
Une demande construite précise aussi ce qui doit être livré. Par exemple : pour chaque problème constaté, donner les étapes qui le reproduisent et proposer un critère d’acceptation. On pourra alors discuter un cas précis : après le refus d’une pièce jointe trop volumineuse, le client comprend-il quoi corriger et retrouve-t-il ses autres réponses ?
Un exemple : améliorer un formulaire de devis
Prenons un cas fictif : une PME reçoit des demandes de devis incomplètes. Le bouton d’envoi semble être un bon point de départ, mais je proposerais de formuler d’abord le résultat attendu : permettre au client d’envoyer les informations nécessaires à une première réponse commerciale. L’équipe doit préciser quelles informations sont réellement indispensables.
Pour préparer le travail, on peut fournir une copie de test du formulaire et des exemples anonymisés de demandes incomplètes. La question devient alors : à quel endroit manque-t-il une information, et le formulaire permet-il de comprendre ce qui est attendu ? Une suggestion sur la couleur du bouton devra justifier son rapport avec cette difficulté.
On peut aussi examiner le parcours avec des méthodes d’ergonomie et de rédaction : nommer les champs dans le vocabulaire du client, expliquer pourquoi une pièce est demandée, observer le retour affiché après une erreur. Chaque piste doit déboucher sur une modification précise, que l’on pourra examiner dans une pull request.
Pour cet essai, je garderais une limite simple : travailler sur une copie, sans envoi réel ni modification en production. Le scénario de contrôle pourrait vérifier qu’un client sait repérer un champ manquant, le corriger et conserver les informations déjà saisies. Un test automatisé peut contrôler ce comportement ; une observation avec un utilisateur aidera à évaluer si les explications sont compréhensibles.
Première conversation : approfondir la demande
On ne connaît pas toujours les termes du métier ni les vérifications à demander. Je propose alors de consacrer une première conversation à la préparation. Décrivez votre sujet avec vos mots, indiquez ce dont vous disposez et demandez à l’IA de vous aider à construire une demande plus précise. La méthode en deux conversations qui suit est une proposition du Journal.
Aide-moi à préparer une demande pour une seconde conversation IA.
Ne réalise pas encore la tâche.
Sujet : notre formulaire de devis reçoit des demandes incomplètes.
Je dispose d’une copie de test et de quelques exemples anonymisés.
Je veux comprendre ce qui manque avant de demander une modification.
Repère les ambiguïtés et pose les questions qui changeraient la démarche.
Propose les méthodes pertinentes en expliquant leurs termes techniques.
Pour chaque méthode, précise les informations nécessaires et le contrôle
qui permettrait de décider si la modification répond au besoin.
Garde un périmètre limité à ce formulaire.
Après mes réponses, rédige une demande autonome à copier dans une
nouvelle conversation. Distingue les faits confirmés des hypothèses.
Liste les documents à joindre et les questions encore ouvertes.
N’invente pas de données, de résultats ni d’accès aux outils.Relisez cette préparation avant de la transmettre. Si l’IA propose de mesurer le taux d’abandon, vérifiez que vous disposez réellement des données nécessaires. Si elle ajoute une refonte du parcours commercial, demandez pourquoi cela serait utile pour le formulaire choisi. Une question mieux documentée peut rester courte ; chaque ajout doit aider à prendre une décision.
Seconde conversation : transmettre un contexte autonome
Une fois les points utiles clarifiés, copiez la demande dans une nouvelle conversation, avec la même IA ou une autre. Joignez les documents autorisés qu’elle doit examiner. Le texte doit reprendre les décisions prises pendant la préparation : un renvoi comme « utilise les données vues plus haut » ne donne pas ce contexte à la seconde conversation.
Pour notre cas fictif, le résultat de cette préparation pourrait ressembler au texte ci-dessous. Il reste à compléter avec la liste des champs indispensables validée par l’équipe et les fichiers réellement accessibles.
Sur cette copie du formulaire de devis, aide le client à fournir
les informations nécessaires à une première réponse commerciale.
La liste des champs indispensables validée par l’équipe est jointe.
Examine les exemples anonymisés de demandes incomplètes.
Pour chaque changement proposé, indique l’observation qui le motive
et un critère d’acceptation observable.
Vérifie notamment les messages de validation et la conservation de la
saisie après une erreur, avec les outils déjà disponibles dans le projet.
Si les données manquent, précise ce qu’il faut observer avant de décider.
Prépare une modification limitée et une pull request avec les contrôles
exécutés et leurs limites. Aucun envoi réel ni déploiement.Changer de conversation organise le passage de la préparation à l’exécution. Cela ne garantit pas la justesse du résultat : deux IA peuvent reprendre la même hypothèse erronée. Pour décider, revenez au formulaire et aux contrôles convenus. Demandez les résultats des vérifications effectuées et gardez visibles les points qui exigent encore une observation avec un utilisateur.
