Résumé
- Rapport d’expérimentation indiquant qu’après avoir refactoré la structure du code (patterns stratégie et factory, séparation des fichiers, réorganisation de
.cursorrules) avec un prompt d’une seule ligne, puis exécuté le même prompt d’ajout de fonctionnalité, l’usage des tokens par l’IA a fortement diminué (Zero-context, N=5). Les prompts et le code source utilisés pour l’expérience sont publiés, ce qui permet de la reproduire.
Données clés
-
Claude-4 Sonnet : moyenne de 390,159 → 242,265 tokens (−37,91 %)
-
GPT-5 : moyenne de 315,839 → 233,634 tokens (−26,03 %)
-
Référence : Total Tokens affiché par Cursor. Comparer les valeurs absolues entre modèles n’a pas de sens (différences de comptabilisation selon les modèles).
Configuration (résumé)
-
IDE Cursor 1.6.6, modèles GPT-5 / Claude-4 Sonnet
-
Tous les prompts en Zero-context, redémarrage complet de l’éditeur à chaque round
-
Critère de réussite : compté comme réussi si les exigences sont implémentées avec un seul prompt
Pourquoi c’est important
-
Une « bonne structure de code » ne facilite pas seulement la lecture humaine, elle a aussi un impact mesurable sur les tokens, les coûts et le temps pour l’IA
-
La publication des prompts et du dépôt garantit la reproductibilité (directement exploitable en pratique et pour des expériences de suivi)
Avis personnel
- En tant qu’utilisateur de Cursor, cette proposition présente une excellente méthodologie pour réduire les coûts.
- Comme le texte le souligne aussi, l’échantillonnage reste toutefois un peu insuffisant.
34 commentaires
Vous avez pris des cours pour trouver des titres, ou quoi..
J'ai trouvé l'expérience très intéressante à suivre.
Merci.
Indépendamment du contenu, j’ai l’impression que c’est d’autant plus le cas que, à cause du titre parlant d’« une seule ligne de prompt », ce qu’on s’attend à voir et le contenu de l’article ne correspondent pas.
Oui, je pense la même chose. snif
Désolé ;;
Merci beaucoup pour l’intérêt porté à cet article. Comme il visait avant tout une diffusion à l’international, il a été rédigé en anglais, mais cela semble avoir entraîné divers problèmes.
Je partage donc un billet récapitulatif en coréen.
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
Voici un récapitulatif complémentaire concernant le prompt utilisé.
Il est sans doute plus avantageux pour les développeurs lorsqu’il s’agit de rédiger des prompts destinés à améliorer la structure. Comme chaque programme a ses propres caractéristiques, un certain niveau de connaissances en développement est nécessaire pour obtenir des améliorations très efficaces.
Cela ne signifie pas pour autant que les vibe coders non développeurs ne peuvent pas utiliser cette méthode. L’efficacité peut varier, mais même avec une instruction simple comme « Fais un peu de ménage dans le code du projet. Supprime le code inutilisé. », l’IA peut séparer et réorganiser les fichiers et les classes.
En revanche, comme les différences de détail dans l’amélioration de la structure peuvent entraîner des écarts d’efficacité, il faut faire attention aux ressources de référence.
Il faut n’ajouter au prompt que l’essentiel, de façon logique. Autrement dit, plus on y ajoute toutes sortes de choses, plus il y a de bruit, donc le code produit devient lui aussi plus complexe et plus bruité, c’est bien ça ?
L’idée centrale est qu’après avoir demandé à l’IA de refactoriser la structure du code, la quantité de tokens consommés a diminué.
À l’inverse, on peut aussi expliquer que si l’on continue à donner des instructions alors que le code présente des défauts structurels, l’utilisation de tokens augmente.
En résumé, il faut améliorer la structure du code source ; cela ne signifie pas qu’il suffit de rédiger un prompt de façon logique en n’y mettant que l’essentiel.
Moi aussi, j’ai trouvé cette introduction et le texte original beaucoup trop verbeux, au point de donner l’impression d’avoir été écrits par quelqu’un qui ne sait pas très bien écrire, ce qui a rendu la lecture difficile.
En gros, l’idée est la suivante :
« ajoutez une instruction d’une ligne contenant une contrainte structurelle pour réduire le nombre de tokens »
C’est à peu près ainsi qu’on peut le résumer.
Comme ce texte s’apparente davantage à une étude « expérimentale »,
toutes les valeurs qu’il contient ont été pensées pour permettre à toute personne qui le lit de le « reproduire ».
C’est pourquoi j’ai consigné l’intégralité du code source original utilisé ainsi que toutes les procédures de test,
afin de fournir les informations nécessaires pour que tous les expérimentateurs puissent obtenir les mêmes résultats.
À en juger par l’ambiance dans les commentaires,
je me demande s’il ne vaudrait pas mieux, à l’avenir, séparer cela en deux textes :
un article avec un résumé en 3 lignes, et un autre destiné à ceux qui veulent connaître les détails.
Si vous pouvez m’indiquer quelles parties de ce texte vous ont semblé inutilement complexes ou trop longues,
cela m’aidera beaucoup pour la rédaction des prochains articles.
J’ai eu un ressenti assez proche moi aussi.
Je comprends l’intention de l’auteur, mais j’ai l’impression que le texte est excessivement complexe par rapport à ce qui a été fait.
On dirait que c’est écrit ainsi pour intégrer au maximum dans l’article les détails utilisés dans l’expérience,
mais je pense que si vous n’en reteniez que l’essentiel de façon concise, les personnes intéressées par ce sujet comprendraient probablement quand même.
À mon avis, ce serait mieux d’élaguer franchement les détails et de ne garder que les points clés.
Pour ma part, j’ai trouvé intéressante l’intention de l’auteur ainsi que le résultat lui-même.
L’idée principale, c’est qu’un meilleur code source conduit à une consommation de tokens plus faible,
et il me semble que c’est dans cette optique que l’expérience a été conçue et menée.
Si je liste seulement ce que j’ai compris de l’expérience :
Voilà ce qu’il me semble avoir compris.
Et si mon interprétation est correcte, la conclusion serait que le code source prétraité par prompt consomme globalement moins de tokens.
C’est une conclusion intéressante, mais voici mon avis sur l’expérience.
La comparaison n’est pas équitable
Numériquement, cela semble avoir baissé, mais il faudrait sans doute comparer le nombre total de tokens nécessaires pour traiter le code source.
Autrement dit, le nombre de tokens utilisés pour le prétraitement devrait lui aussi être pris en compte.
Si le nombre de tokens utilisé pour le prétraitement est excessivement élevé, alors au final on consomme davantage de tokens, ce qui rend l’approche sans intérêt ; et même s’il est faible, l’écart réel de consommation de tokens sera probablement bien moindre que ce que laisse entendre l’article.
Il faudrait comparer le code source avant et après prétraitement
Si l’on exclut les tokens utilisés pour le prétraitement, la consommation de tokens au moment de la requête semble effectivement avoir diminué de manière significative.
Mais si l’on analysait précisément quelles différences dans le code source produisent cet écart, l’article gagnerait davantage en portée.
Cela voudrait dire qu’il serait possible d’optimiser le prompt de prétraitement pour maximiser ces différences.
L’auteur affirme que c’est le refactoring de la structure du code qui a produit ce résultat, mais je ne suis pas d’accord : je pense qu’on ne peut pas encore le savoir.
Il est possible que d’autres améliorations que le refactoring apportées par l’IA réduisent elles aussi la consommation de tokens.
Il faudrait des expériences plus variées
Je pense qu’il faudrait reproduire la même expérience sur d’autres bases de code, pas seulement sur le code actuel.
Il faut pouvoir déterminer si le résultat est systématiquement positif ou non.
Cela dit, je comprends qu’en pratique ce type de test puisse être difficile à réaliser, donc il vaut peut-être mieux prendre cela simplement comme une piste de réflexion.
Je suis entièrement d’accord. J’accueille très favorablement ce type de critique.
On ne vit pas seul dans ce monde, et les capacités comme les situations de chacun sont différentes.
Moi aussi, je ne suis qu’un simple développeur, et je ne peux pas financer personnellement l’ensemble des tests.
J’espère que cet article servira de graine, aura un impact positif sur beaucoup de personnes et deviendra le point de départ de nombreuses recherches à venir.
Le sous-titre ne correspond pas vraiment au contenu. En le reformulant, quelque chose comme « une analyse plus claire des facteurs qui entraînent la réduction des tokens est nécessaire » semblerait mieux convenir comme sous-titre.
Je suis largement d’accord avec ce point de vue. Cela dit, la nature de cet article inclut aussi l’idée de « proposer aux lecteurs des méthodes d’application réalistes ».
On peut déjà sentir l’ambiance rien qu’en regardant les commentaires laissés sous cet article, et c’est aussi quelque chose que j’ai découvert récemment : il semble qu’il y ait beaucoup d’utilisateurs de l’IA parmi les non-développeurs, notamment des vibe coders.
Si l’auteur obtient des résultats remarquables à partir d’un code ajusté directement par lui-même, sans passer par l’IA,
cela peut facilement être perçu comme une manière de mettre en avant ses compétences de développement tout en rabaissant les capacités de l’IA.
C’est pourquoi j’ai choisi d’aborder un exemple que tout le monde peut concrètement apprécier, à travers l’élément du « prompt », que les vibe coders peuvent eux aussi exploiter.
J’espère qu’à la suite de cette étude, d’autres recherches permettront d’affiner et de catégoriser plus précisément les facteurs qui influencent l’usage des tokens par l’IA.
Si une modification structurelle unique permet de réduire le taux de consommation de tokens de n prompts, la réduction du volume de tokens se répercute alors sur les n exécutions identiques.
n est une valeur déterminée par l’objectif du projet, le nombre de fonctionnalités, ainsi que la quantité et la complexité du code nécessaire ;
et comme les agents récents de Cursor / Claude Code font l’objet de mises à jour visant à limiter les boucles infinies d’exécution ou l’usage excessif de tokens par l’IA en réduisant la taille des unités d’exécution,
il me semble juste de mener séparément une étude sur la valeur de n en lien avec la complexité du projet.
Le point à ne pas manquer ici est que l’amélioration de la structure n’est absolument pas une action qui se produit indépendamment du développement du code.
Elle peut influencer le contexte de base via le prompt initial, ou via des contraintes comme un ruleset IA (
.cursorrules),et, au cours du cycle de développement du projet, une seule amélioration structurelle ne peut pas tout résoudre.
Autrement dit, plutôt que de planifier des améliorations de code à intervalles réguliers, il est préférable d’orienter correctement la structure dès le contexte de base.
Par ailleurs, il semble également juste de mener séparément une étude comparant les cas où il existe ou non, dans le contexte de base, des règles de consigne orientant la structure.
Pour résumer le point 1,
affirmer qu’il faut additionner la consommation de tokens d’un unique prompt d’amélioration structurelle dans le calcul est un argument discutable.
J’ai du mal à bien comprendre ce que vous voulez dire dans votre commentaire. Mon propos était que, pour comparer équitablement les deux méthodes, ne faut-il pas comparer le nombre total de tokens consommés ? Le refactoring ne consomme-t-il pas lui aussi des tokens ?
Par ailleurs, ce que vous avez ajouté dans votre réponse ne semble pas être écrit dans l’article, et l’expérience ne semble pas non plus avoir été menée sur ce point. Il me semble que vous ne parlez pas d’une comparaison du nombre de tokens par requête unique, mais plutôt de l’idée que, sur plusieurs requêtes, le surcoût du refactoring diminue et que, comme le nombre attendu de tokens par requête baisse, on finirait par y gagner sur le total de tokens. Mais cela ne me paraît valable que si la réduction de coût se maintient effectivement sur plusieurs requêtes, comme vous l’imaginez, ce qui me semble être une hypothèse très idéale. Rien ne garantit que la baisse de coût due au refactoring se maintiendra indépendamment du nombre de requêtes suivantes, et on ne peut pas non plus le supposer sans expérimentation. Si vous voulez défendre ce point, il faudrait montrer expérimentalement une baisse de coût sur plus d’une requête. Or l’expérience n’a-t-elle pas été réalisée une seule fois pour cette comparaison ?
J’ajoute que ce n’est qu’une hypothèse de ma part, mais si l’on répétait indéfiniment les requêtes pour atteindre le même objectif (la sortie finale idéale), alors, dans une situation idéale, le code devrait converger vers une forme identique, qu’il y ait eu refactoring ou non. (La sortie finale idéale est unique.)
Si cette hypothèse est raisonnable, alors plus les requêtes se répètent, plus la différence entre la présence ou non d’un refactoring devrait se réduire, et donc plus le gain de réduction du coût en tokens devrait diminuer progressivement. Dès lors, à un niveau macroscopique, si ce bénéfice de réduction de coût ne se maintient pas suffisamment dans le temps, la différence du nombre total de tokens utilisés pour les requêtes pourrait ne pas être significative, non ?
Vous m’avez aussi interrogé au sujet de l’expérience liée au nombre d’enchaînements de prompts,
mais en réalité, c’est à l’inverse un élément idéal pour que l’auteur, pour le dire crûment, puisse tricher.
L’activité de développement elle-même comporte énormément de choix dans la direction à prendre, et si l’on accumule les prompts dans un sens où la consommation de tokens se creuse davantage, ce chiffre gonflera encore plus, comme une boule de neige.
Dans la recherche, il existe une philosophie appelée « Cumulative Science ».
Comme, de mon point de vue du moins, je n’ai encore jamais trouvé la moindre étude sur la consommation de tokens pour une seule instruction,
je me suis donc concentré non pas sur une étude immédiate sur N exécutions, mais sur des tests solides et des conclusions portant sur une seule exécution,
et pour l’étude sur N exécutions, il suffira qu’elle prolonge cette expérimentation.
J’ai aussi déjà abordé, dans un autre article, les différences de comportement de l’IA selon les écarts entre codebases.
(Cela a d’ailleurs aussi déjà été présenté sur GeekNews : https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)
Pour l’expliquer brièvement, il s’agit de tests et de résultats montrant que la qualité du résultat produit varie selon la codebase fournie en entrée à l’IA.
Selon la qualité initiale de la codebase et son orientation, la qualité du code produit ensuite peut soit se maintenir, soit continuer à se dégrader.
Autrement dit, le coût d’un refactoring au début d’un projet et le coût d’un refactoring sur un projet déjà bien avancé peuvent être très différents.
Si la personne qui pose la question est développeuse, elle a peut-être déjà entendu l’expression « un porte-avions sur un voilier ».
Le refactoring est un sujet profond : à quel moment faut-il le réaliser, et à quel point les idées et l’architecture appliquées au début d’un projet peuvent-elles faire exploser les coûts.
Plutôt que d’inclure cela comme variable et d’aboutir à une conclusion instable,
j’ai mené un test qui permet au moins d’expliquer clairement ceci : « ah, quand la qualité de la codebase est bonne, l’utilisation de tokens diminue. »
Je vais essayer de l’expliquer à nouveau.
Les pratiquants du vibe coding couvrent un spectre très large, des non-développeurs jusqu’aux développeurs expérimentés. Selon leur niveau de connaissances, et indépendamment du contenu de cet article, la qualité du résultat produit peut varier énormément.
Certains, en partant naturellement du principe qu’ils utilisent Cursor, peuvent renseigner dans
.cursorrulesdes conventions OOP de base ainsi que des règles de séparation des classes et des méthodes, au point d’obtenir un fonctionnement qui ne nécessite presque aucun refactoring ;d’autres, au contraire, peuvent produire en masse du code de bas niveau simplement faute d’avoir saisi des points essentiels pourtant très basiques.
Il existe même déjà de nombreux articles et retours d’expérience expliquant qu’il faut, par défaut, maintenir une bonne qualité de code via la configuration des règles du projet.
Cela suggère que certains bénéficient peut-être déjà d’un gain en matière de consommation de tokens, même sans refactoring explicite.
Cependant, les cas ci-dessus ne récapitulent pas clairement la réduction de consommation de tokens par unité d’exécution obtenue grâce à la définition de ces règles. C’est pourquoi cet article teste la différence de consommation de tokens selon la qualité de la base de code et en résume les résultats.
Autrement dit, selon l’utilisateur, le nombre de refactorings explicites devient lui-même une variable allant de 0 à n,
et l’intention essentielle de cet article peut être comprise comme suit : « pourquoi est-il utile de prêter attention à la qualité d’une base de code ? »
Je suis l’auteur. Merci pour vos retours. J’en tiendrai compte lors de la rédaction du prochain article.
Le fait d’ajouter aussi ce prompt a donc réduit les coûts ? Je ne suis pas sûr d’avoir bien compris l’idée générale.
Pour préciser, la structure du code doit être améliorée selon un modèle adapté au projet concerné. Comme dans la réponse ci-dessous, si vous demandez à l’IA des pistes de refonte structurelle, elle vous indiquera une méthode appropriée au projet.
Ma recommandation personnelle est de ne pas lui donner directement un ordre de refonte structurelle : demandez-lui plutôt de faire des propositions. Elle vous répondra, et il est préférable de poursuivre l’échange jusqu’à arriver à une proposition suffisamment efficace, puis de lui demander de l’appliquer.
Un conseil supplémentaire : il vaut mieux, autant que possible, terminer le travail avant qu’une contextual summarization (réinitialisation du buffer de contexte) ne se produise. Et si cette réinitialisation est inévitable, il est préférable de lui demander à l’avance d’ajouter des règles d’amélioration dans
.cursorrules. Si le contexte est réinitialisé en cours de travail, l’IA a davantage de chances de faire des erreurs.Pour référence, le fait que la quantité de tokens consommés diminue à mesure que la taille du code source en entrée se réduit est une évidence bien connue. C’est d’ailleurs pour cette raison que le fichier
.cursorignorea été créé.De manière générale, quand on demande à une IA d’améliorer la structure, le volume du code source a presque toujours tendance à diminuer. Dire que faire du rangement, pour quelque raison que ce soit, réduit les coûts semble donc être une affirmation crédible.
Cet article ajoute l’idée qu’il est possible d’obtenir une réduction supplémentaire de l’usage des tokens en induisant une meilleure structure.
C’est exact. Comme indiqué dans l’article, il est vrai que la taille du code du projet a diminué après l’amélioration du code.
Cependant, dans cet exemple, la réduction est d’environ 10 % en nombre de caractères, et cela seul ne suffit pas à expliquer une baisse de 37,91 % de l’utilisation des tokens.
Le lien vers le dépôt source figure dans l’article, et n’importe qui peut reproduire le test lui-même.
Je n’ai pas fait ce test moi-même de cette façon,
mais j’ai l’impression que le prompt
« Analyse le code actuel et améliore la structure pour qu’elle soit plus facile à maintenir pour toi »
pourrait aussi fonctionner.
L’idée centrale, à mon sens, est qu’au lieu de transmettre à l’IA uniquement les exigences fonctionnelles, bien orienter une structure adaptée et correcte peut aussi aider à réduire les coûts.
https://modgo.org/dib-rag-gaelreogtig-modeu-seuteurimeoreul-wihan-ciji…
Avez-vous créé vous-même ce mode Deep Rock Gal ?
Vous l’avez fait aussi en vibe coding ?
Bonjour. Je suis l’auteur du blog.
Oui, c’est bien moi qui ai créé directement le mode DeepRAGGal, et il est actuellement proposé via un serveur personnel. (C’est nécessaire à cause de l’authentification OAuth de Chzzk)
Le développement de ce mode inclut une partie sous Unreal Engine, mais malheureusement, le vibe coding est difficile du côté d’Unreal Engine.
En revanche, la méthode de développement du mode en elle-même n’est pas compliquée. Donc, si cela vous intéresse, vous pouvez l’apprendre facilement grâce au guide de développement du mode (https://modgo.org/dib-rag-gaelreogtig-modeu-gaebal-part-1/).
J’ai vu sur une autre communauté que vous aviez publié le mode, donc c’était bien un texte écrit par la personne qui l’a créé.
Je ne pensais pas non plus que vous iriez jusqu’à écrire un article de tutoriel sur le mode Blueprint, merci.
Vous étiez déjà quelqu’un de très doué en développement à la base !
Ah, vous aviez donc déjà vu mon pseudo sur une autre communauté.
Les articles que j’ai écrits ont beaucoup de points perfectibles, mais j’en serais heureux s’ils pouvaient vous être utiles.
Ah, ça m'énerve.
Si vous m’indiquez ce qui vous a agacé, je vous répondrai avec bienveillance.
Veuillez consulter la section sur les commentaires dans le guide d’utilisation du site.
Merci de vous exprimer avec courtoisie et retenue.
Si vous avez un désaccord, veuillez n’écrire que son contenu.