Prompt engineering pour les agents de code IA

Qu'est-ce que le prompt engineering ?

Le prompt engineering est la pratique consistant à écrire et affiner l'instruction donnée à un modèle — sa formulation, sa structure, ses exemples, son format de sortie — pour qu'il fasse ce que vous vouliez réellement dire. Il opère sur une seule chose : le message que vous envoyez, plus le système prompt qui le surplombe. Cette définition paraît étroite, et elle l'est. Elle a longtemps suffi. Dans un chat en un tour, votre prompt est l'entrée : bien formulé vous obtenez une bonne réponse, mal formulé aucun nombre de tentatives ne rattrape. Tout un artisanat s'est construit là-dessus, et l'essentiel en est solide. Puis les agents de code sont arrivés et ont discrètement changé l'arithmétique. Un agent ne répond pas une fois — il planifie, lit des fichiers, lance des commandes, lit les résultats, recommence, vingt ou trente fois. À chacun de ces tours, il relit tout ce qui précède. Votre instruction soigneusement rédigée est toujours là, fait toujours son travail, et représente désormais peut-être 2 % de ce que le modèle voit. Je construis des outils de réduction de tokens, donc j'aborde ça sous un angle particulier : je passe mes semaines à mesurer ce que lisent les agents. Le constat est constant — la qualité du prompt décide si l'agent comprend la tâche, le volume de contexte décide de ce qu'elle coûte et de la fiabilité avec laquelle elle aboutit. Ce sont deux problèmes distincts, et l'industrie a passé cinq ans à très bien maîtriser le premier.

Le prompt engineering compte-t-il encore pour les agents de code ?

Oui — il est rétrogradé, pas supprimé, et la nuance compte parce que beaucoup ont conclu l'inverse. Une instruction vague produit un mauvais résultat quelle que soit la propreté de votre contexte. « Corrige le bug d'auth » envoie un agent explorer la moitié du dépôt ; « le refresh JWT dans auth/session.ts renvoie un token périmé après le premier renouvellement — trouve pourquoi » l'envoie dans un seul fichier. C'est le prompt engineering faisant exactement ce qu'il a toujours fait, et sur un agent il paie deux fois : une fois en meilleure réponse, une fois en vingt fichiers non ouverts. Ce qui a changé, c'est le plafond. Une fois l'instruction sans ambiguïté, la polir davantage rapporte très peu, tandis que le contexte autour continue de grossir à chaque tour. Passé ce point, l'effort de reformulation est de l'effort non investi là où ça s'accumule. Résumé honnête : le prompt engineering est un prérequis qu'on règle une fois par tâche. Ce n'est pas là que se trouve le levier restant.

Quelles pratiques de prompt engineering tiennent encore ?

Celles qui réduisent l'ambiguïté survivent. Celles qui compensaient les faiblesses d'un modèle, beaucoup moins. Soyez précis sur la cible, pas seulement sur l'objectif. Nommez le fichier, la fonction, le symptôme. Chaque unité de précision dans l'instruction est une unité d'exploration que l'agent n'a pas à faire — et l'exploration est la partie chère. Énoncez les contraintes d'emblée. « Ne change pas l'API publique », « reste en TypeScript, pas de nouvelle dépendance ». Une contrainte énoncée au départ coûte une phrase ; découverte à la relecture, elle coûte une réécriture et tous les tokens qui l'ont produite. Demandez un plan avant l'édition sur tout ce qui n'est pas trivial. Un plan est peu cher à lire et à corriger. Une refactorisation fausse sur douze fichiers, non. C'est l'habitude à plus forte valeur que je garderais de l'ère du prompt engineering. Donnez un exemple quand le format compte. Pour un style de message de commit ou une structure de test précise, un exemple vaut mieux que trois paragraphes de description. C'est le vieux réflexe few-shot, et il fonctionne toujours. Gardez le système prompt stable. Celui-ci bascule côté coût : le prompt caching ne paie que si le préfixe est identique octet pour octet d'un tour à l'autre, et une lecture de cache coûte environ 10 % d'un token d'entrée neuf. Un CLAUDE.md modifié en cours de session casse le cache et se refacture plein tarif — voir comment un CLAUDE.md surchargé gonfle la facture. Ce qui a mal vieilli : les préambules de jeu de rôle élaborés (« tu es un ingénieur senior avec 20 ans d'expérience… »), les menaces et récompenses, et les longues listes d'exhortations génériques à la qualité. Les modèles récents n'ont pas besoin d'être convaincus d'être compétents, et chaque token de cérémonie est relu à chaque tour de la boucle.

Pourquoi mieux prompter ne règle-t-il pas une grosse facture ?

Parce que le prompt est un coût fixe et le contexte un coût croissant : optimiser le prompt améliore le petit nombre pendant que le grand continue de s'accumuler. Le mécanisme en un paragraphe. Au premier tour, le modèle lit votre instruction plus le système prompt — disons 2 000 tokens. Au deuxième, il relit tout ça, plus le fichier ouvert par l'agent. Au vingtième, il relit l'ensemble : chaque fichier, chaque sortie de commande, chaque mot déjà écrit. Un fichier de 6 000 tokens lu tôt est facturé à tous les tours suivants. Votre instruction, elle, fait toujours 2 000 tokens — désormais une erreur d'arrondi face à une fenêtre de 120 000. Réduire un prompt de 2 000 à 1 500 tokens économise 500 tokens par tour. Ne pas lire un fichier de 6 000 tokens dont vous n'aviez pas besoin en économise 6 000 par tour, à partir de ce tour. Les deux sont réels ; ils ne sont pas du même ordre de grandeur. C'est aussi pourquoi « sois bref » est un si mauvais conseil courant. Il vise la sortie, la direction petite et chère au token. La facture est dominée par l'entrée — la charge utile renvoyée à chaque tour. La brièveté en sortie ne la bouge quasiment pas. C'est dans la fenêtre de contexte que se trouve l'argent.

En quoi le context engineering est-il différent ?

Le context engineering contrôle tout ce que le modèle lit à un tour — fichiers, sorties d'outils, historique, schémas d'outils — et pas seulement l'instruction. Même discipline d'entrée délibérée, une échelle au-dessus. La différence pratique apparaît dans ce qu'on optimise. Le prompt engineering demande « que dois-je dire ? ». Le context engineering demande « que doit voir le modèle, sous quelle forme, dans quel ordre ? » — et dans une session d'agent, la réponse à la seconde question est mille fois plus volumineuse que celle à la première. Les quatre leviers qui bougent réellement l'aiguille :

Récupérer, pas lire. Pointez l'agent sur un symbole plutôt qu'un fichier. La recherche sémantique de code renvoie les 200 tokens pertinents au lieu des 6 000 du fichier entier.
Filtrer les sorties d'outils. Un test qui échoue peut cracher 15 000 tokens dont une cinquantaine comptent. L'output filtering garde l'assertion en échec et jette le reste.
Lire la structure avant les corps. Donnez d'abord signatures et exports au modèle ; qu'il n'ouvre un corps que s'il en a besoin. C'est la context compression appliquée au code.
Charger les outils paresseusement. Chaque serveur MCP connecté annonce ses schémas à chaque tour, utilisé ou non. Différer cela jusqu'au premier appel supprime une taxe permanente.

Aucun de ces leviers n'est une astuce de prompt, et c'est tout le propos. Context engineering vs prompt engineering détaille la césure, et le context engineering pour les agents de code IA expose la discipline complète.

Comment appliquer tout ça sans micro-gérer chaque session ?

En automatisant les leviers, parce que ces techniques ne valent que si elles sont appliquées avec constance — et que la constance humaine s'effrite sous la pression. La voie manuelle est honnête et fonctionne : écrire des instructions précises, demander des plans, garder CLAUDE.md stable, faire passer les commandes bavardes par un filtre, ouvrir une session fraîche par tâche, débrancher les serveurs MCP inutilisés. Si vous le faites vraiment tous les jours, vous n'avez rien à acheter — et je préfère le dire que faire semblant du contraire. Tokenade existe pour les jours où vous ne le ferez pas. Il applique récupération sémantique, filtrage des sorties, lectures structure-d'abord et chargement paresseux des MCP automatiquement dans Claude Code, Cursor, Codex, Copilot et Windsurf, avec un tableau de bord qui montre les économies mesurées au lieu de vous demander d'y croire. C'est source-available sous licence MIT : vous pouvez lire exactement ce qu'il fait à votre contexte, et l'offre gratuite suffit à voir si les chiffres bougent sur votre propre travail.

Ce qui tourne mal (anti-patterns)

Prendre le prompt engineering pour tout le travail. C'est la partie sur laquelle on a le plus écrit, ce qui la fait passer pour la frontière. Sur un agent, c'est le coup d'ouverture, pas la partie. Réécrire le prompt pour régler un problème de coût. Si votre facture est élevée, le prompt n'en est presque jamais la cause. Mesurez ce que l'agent a lu avant de réécrire ce que vous avez dit. Les préambules cérémoniels. Jeu de rôle, affirmations de compétence et exigences génériques de qualité sont relus à chaque tour de la session. C'est un abonnement payé pour une réassurance ponctuelle. Modifier CLAUDE.md en cours de session. Chaque édition casse le préfixe caché et refacture l'ensemble plein tarif. Stabilisez-le, puis n'y touchez plus. Confondre brièveté et efficacité. Demander une réponse brève réduit la sortie. Votre facture, c'est l'entrée. Deux bouts différents du compteur.

Foire aux questions

Le prompt engineering est-il une compétence en voie de disparition ?

Non, mais il cesse d'être une spécialité. Il devient l'équivalent de savoir rédiger un bon rapport de bug : une compétence professionnelle de base plutôt qu'un intitulé de poste. Ce qui s'efface vraiment, c'est la couche folklorique — incantations, menaces, personas élaborés. Ce qui dure, c'est la précision sur ce que l'on veut, qui n'a jamais vraiment concerné les modèles.

Quelle différence entre un prompt et le contexte ?

Le prompt est ce que vous écrivez ; le contexte est tout ce que le modèle lit, ce qui inclut votre prompt plus le système prompt, le contenu des fichiers, les sorties d'outils, les schémas et l'historique accumulé. Dans un chat, les deux se confondent presque. Dans une session d'agent, le prompt est une petite fraction du contexte — d'où deux noms distincts.

Le prompt engineering réduit-il la consommation de tokens ?

Marginalement et indirectement. Une instruction précise évite de l'exploration inutile, ce qui économise réellement des tokens — effet bien réel et bon à prendre. Mais raccourcir le prompt lui-même économise une quantité fixe par tour, alors que le contexte croît de tour en tour. La précision aide ; la brièveté de l'instruction ne pèse presque rien.

Faut-il apprendre le prompt engineering ou le context engineering d'abord ?

Le prompt engineering : il est plus petit, se transpose partout, et on ne peut pas le sauter. Ensuite, regardez ce que votre agent a réellement lu pour satisfaire votre instruction — c'est là que sont les surprises, et mesurer la consommation d'un agent montre comment les voir.

Ces pratiques valent-elles aussi pour Cursor, Copilot et Codex ?

Oui. Les conseils de prompt sont au plus teintés par le modèle, et la mécanique de coût est agnostique à l'agent : tout outil qui relit son transcript à chaque tour a le même problème d'accumulation. Comment réduire la consommation de tokens des agents de code IA en traite la version multi-agents.

À voir aussi :

Context engineering vs prompt engineering — là où les deux disciplines se séparent.
Le context engineering pour les agents de code IA — la discipline complète vers laquelle ce pilier renvoie.
Comment un CLAUDE.md surchargé gonfle la facture — le versant système prompt, chiffré.
Comment réduire la consommation de tokens des agents de code IA — les six leviers, tous agents.
Mesurer la consommation d'un agent — obtenir sa propre référence.