Oui. Voici un article pratique sur l’optimisation de l’utilisation des tokens avec Claude et ChatGPT, particulièrement utile pour le développement logiciel, les gros projets et les conversations longues.

Comment optimiser l’utilisation des tokens avec Claude et ChatGPT

Les modèles d’IA comme ChatGPT et Claude sont extrêmement puissants. Cependant, leur efficacité dépend fortement de la manière dont on leur fournit les informations. Une mauvaise utilisation des tokens peut entraîner des réponses plus lentes et des coûts plus élevés. Elle peut aussi causer des contextes inutiles et parfois une perte de précision. Enfin, une bonne pratique est de vérifier les informations et dire ok lorsque tout est clair.

L’objectif n’est donc pas simplement de « donner moins d’informations », mais de donner les bonnes informations au bon moment.

1. Comprendre ce qu’est un token

Un token est une unité de texte utilisée par le modèle pour analyser votre demande.

Un token peut correspondre à :

• un mot ;
• une partie d’un mot ;
• un caractère ou un groupe de caractères ;
• un élément de code ;
• une ponctuation.

Par exemple, un fichier de code de 1 000 lignes peut représenter plusieurs milliers de tokens.

Plus le contexte envoyé au modèle est important, plus le nombre de tokens consommés augmente.

Il faut donc éviter de transmettre systématiquement tout un projet lorsque le modèle n’a besoin que de quelques fichiers.

2. Ne pas envoyer tout le projet à chaque demande

C’est probablement l’une des erreurs les plus fréquentes lors du développement avec ChatGPT ou Claude.

Mauvaise approche

Voici tout mon projet avec 150 fichiers. Analyse tout et corrige cette erreur, ok.

Le modèle doit analyser énormément d’informations alors que le problème concerne peut-être uniquement trois fichiers.

Meilleure approche

Commencer par identifier :

1. le fichier concerné ;
2. le composant concerné ;
3. l’erreur ;
4. les dépendances directes ;
5. éventuellement la configuration associée.

Par exemple :

J’ai une erreur 500 sur /api/users.
Le backend utilise Symfony 6.4.
Voici UserController.php, UserService.php et le message d’erreur.
Identifie la cause et propose uniquement les modifications nécessaires.

Cette méthode réduit considérablement le contexte inutile.

3. Utiliser une conversation par fonctionnalité

Pour un gros projet, il est préférable de ne pas avoir une seule conversation contenant tout le projet pendant plusieurs semaines.

On peut organiser les conversations par fonctionnalité :

• Authentification ;
• API utilisateurs ;
• Paiement ;
• Dashboard ;
• Docker ;
• Nginx ;
• Base de données ;
• Frontend ;
• Déploiement.

Cela permet de garder un contexte pertinent.

Une conversation dédiée à Docker n’a pas besoin de conserver 200 messages concernant le frontend React.

4. Faire des résumés de contexte

Lorsque la conversation devient longue, demandez au modèle de produire un résumé technique.

Par exemple :

Résume uniquement les informations importantes de cette conversation pour continuer le développement.
Inclus l’architecture, les technologies, les décisions prises, les fichiers concernés, les problèmes résolus et les problèmes restants.
Supprime les informations inutiles.

Vous obtenez alors un contexte beaucoup plus compact.

Vous pouvez ensuite démarrer une nouvelle conversation avec ce résumé.

5. Créer un fichier de contexte pour le projet

Pour les projets importants, une excellente méthode consiste à créer un fichier :

PROJECT_CONTEXT.md

Il peut contenir :

# Projet

Nom : Mon application

## Architecture

Frontend : React
Backend : Node.js / Express
Database : MySQL
Reverse proxy : Nginx
Infrastructure : Docker

## Structure

/frontend
/backend
/docker
/nginx

## Règles

- Utiliser TypeScript
- Ne pas utiliser Sequelize
- Utiliser mysql2
- API REST
- JWT pour l'authentification

## État actuel

- Authentification terminée
- Dashboard en cours
- Paiement non développé

## Problèmes connus

- Erreur 502 sur l'API en production
- Configuration Nginx à vérifier

Au lieu de répéter toutes ces informations dans chaque conversation, vous fournissez simplement ce contexte au modèle lorsque cela est nécessaire.

6. Donner uniquement le code nécessaire

Si vous avez un fichier de 2 000 lignes mais que l’erreur se trouve dans une fonction de 50 lignes, évitez d’envoyer les 2 000 lignes.

Préférez :

Voici la fonction concernée :

[code]

Voici l’erreur :

[erreur]

Voici comment cette fonction est appelée :

[code]

Corrige uniquement le problème.

Le modèle peut alors se concentrer sur le problème réel.

7. Attention aux logs

Les logs sont particulièrement consommateurs de tokens.

Évitez de copier plusieurs milliers de lignes :

docker logs container

Préférez :

docker logs --tail 100 container

ou recherchez directement l’erreur :

docker logs container 2>&1 | grep -i error

Puis transmettez uniquement les lignes pertinentes.

Pour Nginx :

grep -i "error" /var/log/nginx/error.log | tail -50

Cette technique est particulièrement efficace avec les problèmes Docker, Nginx, PHP-FPM et Symfony.

8. Utiliser une méthode en plusieurs étapes

Au lieu de demander immédiatement :

Analyse tout mon système et corrige tout.

Il est généralement préférable de travailler progressivement.

Étape 1 — Diagnostic

Analyse uniquement le problème et identifie la cause probable.

Étape 2 — Vérification

Donne-moi les commandes à exécuter pour confirmer cette hypothèse.

Étape 3 — Correction

Maintenant que la cause est confirmée, donne-moi la correction.

Étape 4 — Validation

Donne-moi les commandes pour vérifier que le problème est définitivement résolu.

Cette méthode permet également d’éviter que l’IA génère des modifications inutiles.

9. Ne pas demander une réponse trop longue

Si vous cherchez une correction précise, indiquez-le.

Par exemple :

Réponse courte. Donne uniquement la cause et les commandes à exécuter.

Ou :

Ne réécris pas tout le fichier. Donne uniquement les lignes à modifier.

Cela évite les réponses contenant beaucoup de texte inutile.

10. Utiliser des références plutôt que répéter le contexte

Dans un projet complexe, vous pouvez demander au modèle de travailler avec une structure logique :

Contexte projet :
PROJECT_CONTEXT.md

Problème :
API /users retourne 502.

Fichiers concernés :
- nginx.conf
- docker-compose.yml
- backend/Dockerfile

Objectif :
Identifier la cause du 502.

Contraintes :
Ne pas modifier l'architecture.

C’est beaucoup plus efficace que de réexpliquer l’intégralité du projet.

11. Pour Claude Code et les agents de programmation

Avec les agents de développement comme Claude Code ou les outils similaires, il est important de laisser l’agent inspecter les fichiers nécessaires plutôt que de copier tout le code dans le prompt.

Une bonne demande ressemble à :

Analyse le problème de démarrage du backend.

Commence par inspecter :
- docker-compose.yml
- backend/Dockerfile
- configuration Nginx
- logs du conteneur backend

Identifie d'abord la cause.
Ne modifie aucun fichier avant d'avoir identifié le problème.
Puis propose la correction.

L’agent peut alors sélectionner lui-même les informations pertinentes.

12. Utiliser des fichiers de règles

Pour un projet professionnel, il est intéressant de définir les règles du projet dans un fichier dédié.

Exemple :

AI_RULES.md

Avec :

# Règles IA

## Backend
- Node.js
- Express
- MySQL2
- TypeScript

## Frontend
- React
- TypeScript

## Règles de code
- Ne pas modifier l'architecture sans autorisation.
- Ne pas créer de dépendance inutile.
- Réutiliser les services existants.
- Ne pas supprimer du code fonctionnel.
- Toujours vérifier les impacts avant modification.

## Git
- Ne pas faire de commit automatiquement.
- Ne pas supprimer de branche.
- Ne pas réinitialiser le repository.

Le modèle dispose ainsi d’un cadre clair.

13. Utiliser des prompts structurés

Un prompt efficace peut suivre cette structure :

CONTEXTE
[Informations indispensables]

PROBLÈME
[Description précise]

FICHIERS CONCERNÉS
[Liste]

OBJECTIF
[Résultat attendu]

CONTRAINTES
[Ce qui ne doit pas être modifié]

TÂCHE
[Action précise]

FORMAT DE RÉPONSE
[Format souhaité]

Exemple :

CONTEXTE
Backend Symfony 6.4 dans Docker.

PROBLÈME
PHP-FPM démarre puis s'arrête.

FICHIERS
Dockerfile
docker-compose.yml
configuration PHP-FPM

OBJECTIF
Faire fonctionner PHP-FPM.

CONTRAINTES
Ne pas changer l'image PHP.

TÂCHE
Identifier la cause.

FORMAT
1. Cause
2. Commande de vérification
3. Correction

C’est beaucoup plus efficace qu’un prompt vague.

14. Ne pas répéter les informations déjà connues

Si la conversation contient déjà :

Le projet utilise Symfony 6.4, PHP 8.2 et MySQL.

Il n’est pas nécessaire de répéter ces informations à chaque message.

Vous pouvez simplement dire :

Maintenant, corrige le problème de migration.

Le modèle dispose déjà du contexte.

Cependant, lorsque la conversation devient très longue, il est préférable de créer un résumé compact et de repartir sur une nouvelle conversation.

15. Optimiser les demandes de correction de code

Une demande très efficace est :

Analyse ce code.

Ne réécris pas tout le fichier.

Donne :
1. La cause du problème.
2. Le code exact à remplacer.
3. Le nouveau code.
4. Une explication de 2-3 phrases.

Cela permet de réduire considérablement la quantité de texte générée.

16. Comparaison : mauvaise vs bonne utilisation

Mauvaise utilisation

Voici mon projet complet.

Analyse tout.

J'ai une erreur.

Corrige tout.

Explique tout en détail.

Le modèle doit traiter énormément d’informations sans savoir précisément ce qui est important.

Bonne utilisation

Erreur :
502 Bad Gateway sur /api/users.

Architecture :
Nginx → PHP-FPM → Symfony.

Fichiers concernés :
docker-compose.yml
nginx.conf

Logs :
[50 lignes pertinentes]

Objectif :
Identifier la cause du 502.

Contraintes :
Ne pas modifier l'architecture.

Réponse :
Cause + commandes de vérification + correction.

Le deuxième prompt est beaucoup plus efficace.

17. Le principe fondamental : contexte utile > contexte maximum

Il ne faut pas chercher à donner le maximum de contexte.

Il faut donner le minimum de contexte suffisant pour résoudre le problème.

C’est une différence importante.

Un contexte de 100 000 tokens contenant énormément d’informations inutiles peut être moins efficace qu’un contexte de 10 000 tokens soigneusement sélectionné.

18. Méthode recommandée pour les gros projets

Pour un projet professionnel utilisant ChatGPT ou Claude, je recommande cette organisation :

project/
│
├── AI_CONTEXT.md
├── AI_RULES.md
├── ARCHITECTURE.md
│
├── frontend/
├── backend/
├── docker/
└── docs/

AI_CONTEXT.md

Contient :

• architecture ;
• technologies ;
• état du projet ;
• fonctionnalités ;
• problèmes connus.

AI_RULES.md

Contient :

• conventions de développement ;
• contraintes ;
• règles de sécurité ;
• dépendances à éviter ;
• règles Git.

ARCHITECTURE.md

Contient :

• architecture technique ;
• communication entre services ;
• bases de données ;
• API ;
• infrastructure.

L’IA peut alors travailler beaucoup plus efficacement sur le projet.

19. Une règle simple à retenir

Avant d’envoyer une information à ChatGPT ou Claude, posez-vous cette question :

Est-ce que cette information est réellement nécessaire pour répondre à ma demande ?

Si la réponse est non, ne l’envoyez pas.

Cette simple règle permet de réduire fortement la consommation de tokens.

Conclusion

L’optimisation des tokens ne consiste pas uniquement à écrire des prompts courts.

La véritable optimisation repose sur cinq principes :

1. Envoyer uniquement le contexte pertinent.
2. Éviter de répéter les informations déjà disponibles.
3. Découper les problèmes complexes en étapes.
4. Utiliser des fichiers de contexte et de règles pour les gros projets.
5. Demander des réponses ciblées plutôt que des explications inutilement longues.

Pour un développeur travaillant quotidiennement avec Claude ou ChatGPT, cette approche peut améliorer à la fois la vitesse, la précision, le coût et la qualité du développement assisté par IA.

Le meilleur prompt n’est donc pas forcément le plus court.

C’est celui qui fournit exactement le contexte dont le modèle a besoin, sans le bruit dont il n’a pas besoin.