Comment j’ai optimisé le contexte de mes agents IA

J’adorais Opus 1M pour une raison très simple : tu pouvais être un peu sale.

Tu chargeais trop de contexte. Tu lisais trop de fichiers. Tu laissais un skill embarquer la moitié du repo “au cas où”. Et malgré ça, ça passait souvent.

Quand je suis repassé sur GLM 5.1 avec une fenêtre bien plus serrée, le système m’a rappelé une vérité que beaucoup oublient avec les LLM : le contexte n’est pas gratuit.

C’est un budget. Et si tu le dépenses mal, tout le reste devient fragile.

Le vrai problème n’était pas le modèle

Le réflexe classique, quand un workflow casse après un changement de modèle, c’est de dire :

“Le nouveau modèle est moins bon.”

Parfois c’est vrai. Mais dans mon cas, le vrai problème était ailleurs : mes skills et mes crons avaient pris de mauvaises habitudes.

Avec une énorme fenêtre de contexte, beaucoup de workflows deviennent paresseux :

• ils lisent des fichiers optionnels upfront
• ils chargent des historiques complets alors qu’un extrait suffirait
• ils embarquent des checklists entières qu’on pourrait résumer
• ils répètent les mêmes règles dans le payload du cron et dans le skill
• ils gardent des instructions “safe” mais verbeuses qui gonflent chaque run

Le résultat, je l’ai vu très vite sur certains runs Reddit et Instagram : context overflow.

Pas un petit overflow élégant. Le genre de run qui explose alors qu’il n’a même pas encore commencé le vrai travail.

Ce que le retrait d’Opus 1M m’a forcé à faire

En pratique, le passage vers un modèle plus compact m’a obligé à faire un vrai ménage d’architecture sur la couche agent.

Et honnêtement, c’était sain.

J’ai commencé à traiter mes prompts comme je traite du code prod :

• supprimer le dead weight
• différer ce qui peut être chargé plus tard
• éviter les doublons d’instructions
• distinguer le must-have du nice-to-have
• réduire les lectures “par confort”

En clair : passer d’une logique “charge tout, on verra bien” à une logique “charge le strict nécessaire, puis élargis seulement si besoin.”

1. J’ai introduit une doctrine “minimal context first”

Le plus gros changement, c’est celui-là.

Avant, beaucoup de skills faisaient une sorte de préflight XXL :

• contexte app
• stratégie
• templates
• variantes
• anti-patterns
• exemples
• tracking complet
• docs annexes

Tout ça avant même la première action.

Maintenant, je structure mes skills comme ça :

Phase A, contexte minimal obligatoire

On lit seulement ce qui est nécessaire pour prendre la première bonne décision.

Exemple typique :

• le fichier de config du compte
• le contexte app
• la stratégie
• un fichier template principal

Phase B, lecture à la demande

Tout le reste devient optionnel :

• exemples
• anti-patterns longs
• variantes supplémentaires
• historique détaillé
• docs de secours

Tant qu’un run n’en a pas besoin, il ne les charge pas.

Ça paraît évident dit comme ça. Mais dans les systèmes multi-agents, cette discipline change tout.

2. J’ai arrêté de charger des fichiers entiers “juste au cas où”

Le pire coupable, ce sont les fichiers historiques : CSV de tracking, logs, listes de posts, gros markdowns d’exemples.

Avant, certains workflows lisaient le fichier entier pour “avoir le contexte complet”.

En réalité, dans 90% des cas, tu n’as pas besoin du fichier entier. Tu as besoin de :

• l’en-tête
• les dernières lignes utiles
• ou d’un lookup ciblé sur un username / statut / subreddit

J’ai commencé à remplacer la logique “read all” par :

• lecture des 50 premières lignes ou d’un extrait utile
• puis lookup ciblé pendant l’exécution si un cas concret l’exige

Ce changement tout seul réduit énormément la taille du prompt de départ.

Et surtout, il rend le run plus robuste : le système n’est plus dépendant d’un énorme blob de contexte avant de pouvoir agir.

3. J’ai retiré les doublons entre cron payload et skill

Un autre piège classique : tu mets les mêmes consignes partout.

Le cron dit :

• sois discret
• pas de préambule
• utilise un contexte minimal
• pas de lecture complète du dossier

Puis le skill répète :

• sois discret
• pas de préambule
• lis seulement l’essentiel
• évite le tracking complet

Individuellement, chaque phrase semble raisonnable. Collectivement, tu paies deux fois pour la même règle.

Du coup, j’ai fait un ménage simple :

• le cron payload garde les contraintes runtime essentielles
• le skill garde la logique opérationnelle détaillée

Le payload n’est plus un mini-manuel. Il redevient une enveloppe d’exécution.

4. J’ai gardé les garde-fous qualité… mais en version embarquée

Je ne voulais pas faire l’erreur inverse : compresser tellement que le résultat devient nul.

Sur Reddit par exemple, il y a un garde-fou critique pour moi : le humanizer. Je ne veux pas de posts qui sentent l’IA à dix kilomètres.

Le problème, c’est que charger un skill complet de humanizer à chaque run public coûte du contexte.

La solution que j’ai adoptée :

• garder le humanizer obligatoire
• mais utiliser d’abord une checklist embarquée compacte
• ne charger le skill complet qu’en fallback si le draft reste suspect

En pratique, ça donne quelque chose comme :

• retire les formulations corporate
• supprime les tournures trop propres
• évite l’em dash et la symétrie trop parfaite
• garde une légère imperfection humaine
• vérifie que le texte passerait devant quelqu’un qui chasse le contenu IA

Résultat : je garde la qualité, sans payer le coût complet d’un chargement systématique.

5. J’ai séparé “contexte de décision” et “contexte d’exécution”

C’est une distinction qui m’aide beaucoup maintenant.

Contexte de décision

C’est ce qu’il faut pour choisir la bonne action. Exemple : quel compte utiliser, quel sub viser, quel template prendre.

Contexte d’exécution

C’est ce qu’il faut une fois que l’action est décidée. Exemple : flair exact, historique précis d’un sub, ligne CSV d’un contact donné.

Avant, beaucoup de skills mélangeaient les deux et chargeaient tout dès le départ.

Maintenant, je force une séparation :

1. d’abord décider avec un contexte léger
2. ensuite seulement charger ce qu’il faut pour exécuter proprement

Cette séquence rend les agents plus disciplinés. Et surtout, elle rend les erreurs plus faciles à diagnostiquer.

6. J’ai redécouvert que la fenêtre de contexte cache des dettes de design

C’est probablement la leçon la plus intéressante de toute cette histoire.

Une grande fenêtre de contexte peut masquer :

• des skills trop bavards
• des workflows mal découpés
• des instructions redondantes
• des fichiers workspace devenus trop gros
• des crons qui ont accumulé des couches successives de patchs

Quand tu reviens à une fenêtre plus stricte, tout ça remonte à la surface.

Et c’est une bonne nouvelle.

Parce qu’au fond, ce n’est pas juste un problème de tokens. C’est un problème de design opérationnel.

Si un agent a besoin de 15 fichiers et 200 règles avant de cliquer sur un bouton, le problème n’est pas seulement le modèle. Le problème, c’est que ton workflow est trop lourd.

Ce que j’ai optimisé concrètement côté crons

Les crons étaient les premiers candidats, parce qu’ils tournent tout seuls et qu’ils doivent être fiables.

J’ai commencé par réduire les payloads des runs les plus sensibles :

• outreach Instagram
• inbox / cleanup Instagram
• posting Reddit
• warmup Reddit
• comment acquisition
• engage Reddit

La règle de base maintenant :

• execution-only
• pas de plan inutile
• pas de résumé de skill dans le run
• pas de préambule
• pas de chargement complet d’un dossier app
• pas de lecture intégrale d’un tracking file sans justification stricte

Un cron doit être pensé comme une unité opérationnelle serrée. Pas comme une session de brainstorming.

Et côté skills, le changement est encore plus important

Les skills, c’est là où tout se joue.

Quand un skill est bien écrit, le modèle a l’impression d’avoir plus de contexte qu’il n’en a vraiment. Parce que l’information est mieux hiérarchisée.

Quand un skill est mal écrit, même une grosse fenêtre ne suffit jamais vraiment.

Les patterns que je garde maintenant systématiquement :

• une entrée en matière très courte
• une doctrine de budget contexte explicite
• une section required minimal context
• une section read on demand only
• des règles métier regroupées au lieu d’être répétées partout
• un fallback clair si un contexte additionnel devient nécessaire

C’est plus propre pour le modèle, mais aussi pour moi. Quand je relis un skill, je vois immédiatement ce qui coûte cher et ce qui est indispensable.

Le résultat : moins spectaculaire qu’Opus 1M, mais plus sain

Soyons honnêtes : repasser d’un modèle ultra-large à un modèle plus serré, ce n’est pas fun.

Tu perds du confort. Tu dois être plus rigoureux. Tu vois plus vite les limites de tes instructions.

Mais le bénéfice caché est énorme : tu obtiens un système beaucoup plus propre.

Aujourd’hui, mes meilleurs workflows ne reposent plus sur la générosité d’une fenêtre de contexte géante. Ils reposent sur :

• un bon découpage
• une lecture progressive
• des règles compactes
• des fallbacks ciblés
• une vraie séparation entre l’essentiel et le reste

Et ça, c’est beaucoup plus transférable à long terme.

Mon conseil si tu fais tourner des agents en prod

Si tu dépends d’agents, de crons ou de workflows LLM récurrents, fais cet exercice même si tu as encore accès à une grande fenêtre de contexte.

Demande-toi :

• qu’est-ce qui est vraiment nécessaire au premier pas ?
• quels fichiers sont lus “par habitude” ?
• quelles règles sont dupliquées ?
• qu’est-ce qui peut passer en fallback ?
• quel historique peut être remplacé par un lookup ciblé ?

En général, tu découvriras que ton système peut perdre 30 à 70% de contexte upfront sans perdre en qualité.

Et parfois, il devient même meilleur.

Parce qu’un agent moins encombré prend souvent de meilleures décisions.

Conclusion

La fin d’Opus 1M m’a forcé à faire un truc que je repoussais : traiter mes prompts comme de l’architecture.

Pas comme du texte jetable. Pas comme un empilement de notes. Pas comme un “on met tout et on verra bien”.

Aujourd’hui, je vois beaucoup mieux la différence entre :

• un système qui marche parce qu’il a énormément de marge
• et un système qui marche parce qu’il est bien conçu

Le premier est confortable. Le second est durable.

Et si je dois choisir pour des agents qui tournent tous les jours en prod, je prends le second sans hésiter.

Youcef | Builder Créatif
Je construis des systèmes qui bossent pendant que je dors