
Sommaire
Mais si, vous savez, le poisson bleu qui “aide” Marin a retrouver son fils Némo le poisson clown.
Mon IA, c’est Dory : toujours volontaire pour aider, mais à qui il faut constamment rappeler ce qu’elle doit faire.
Passe encore de devoir réexpliquer le contexte à chaque nouvelle session de code ; à la longue, on s’en fait une raison. Mais quand l’assistant subit un “trouble de la mémoire immédiate” en plein travail, on a franchement envie de l’envoyer nager au large voir si on y est.
Les raisons profondes
Les LLM (Large Language Models) derrière les assistants ne "pensent" pas, ils travaillent sur une fenêtre de contexte (nombre maximum de tokens). Cette fenêtre de contexte est plus ou moins étendue (et par conséquent plus ou moins coûteuse) en fonction des modèles mais n’est jamais illimitée. Quand elle est “remplie”, l’IA commence à oublier. Et dans une session de développement qui s’éternise, c’est systématique.
De plus, la plupart des IA en SaaS ne gardent pas de vraie mémoire persistante. Chaque session est une (bu)bulle : tout doit être réintroduit (librairies utilisées, conventions, contexte métier).
Les conséquences concrètes
Alors que l’IA est censée nous libérer, ses limitations créent un surcoût cognitif permanent : au lieu d’avancer, on passe son temps à répéter le contexte, les règles, les conventions. Un peu comme réexpliquer chaque matin à son collègue que le TDD c’est la vie.
Pire encore : cette impression de fluidité masque des régressions insidieuses. Dans une session longue, l’assistant peut réintroduire un bug déjà corrigé, ignorer des tests, ou repartir dans une voie qu’il avait lui-même abandonnée dix prompts plus tôt.
Pour un développeur expérimenté, ces oublis se rattrapent. Mais pour un junior, c’est un vrai piège : il prend pour argent comptant ce code “de confiance”, alors qu’il est parfois incohérent. La dette technique invisible s’accumule, et l’équipe fait face à une frustration grandissante.
Comme Dory, l’IA est capable de tourner en rond, d’oublier ce qu’elle a vu, et de s’émerveiller à chaque détour… pendant que vous, vous regardez votre backlog et votre facture s’allonger.
Comment atténuer “l’effet Dory” ?
La règle d’or que chaque dev qui veut s’équiper doit respecter est “chéris tes prompts”. Chaque session doit démarrer par un rappel des règles élémentaires. Ces règles se doivent d’être compactes (elles ont un coût et occupent une place dans la fenêtre), ciblées par activité, et affinées au fil des échanges. Chaque outil propose son format, son nommage (CLAUDE.md, GEMINI.md…) voire même un standard (AGENTS.md de OpenAI) pour favoriser la portabilité.
Les activités aussi doivent être ciblées. Croire qu’on va obtenir une feature parfaite (TU, TR, monitoring, sécurité) en trois prompts est une douce illusion.
Le contexte (c'est-à dire les fichiers que vous mettez en avant pour nourrir votre LLM) est primordial. Il est souvent contre productif de fournir l’ensemble de la base de code.
Dernier conseil, réservé aux spécialistes des cascades assistées par IA : alterner plusieurs modèles (et donc leurs contraintes spécifiques) peut parfois compenser les pertes de mémoire. Il est même pertinent de séparer les tâches entre différents modèles (Gemini pour établir le plan de bataille, Claude Code pour l’implémenter). Mais bien malin est celui qui pourra donner la recette miracle.
Pour finir
Mon IA, c’est Dory : courageuse, enthousiaste, mais qui oublie tout. Si tu veux pouvoir bâtir quelque chose de durable avec elle, applique lui la méthode Memento : tatoue-lui directement sur les nageoires tout ce que tu veux qu’elle n’oublie jamais.
“Code droit devant toi, code droit devant toi.”
Références, pour aller plus loin
- Claude's context window
- Developer notes on the Realtime API
- Riley Goodside: The Art and Craft of Prompt Engineering
Source : https://www.franceinfo.fr/pictures/7ABDwDulfHt7-SnV2jnzfT7nxGQ/1200x1200/2016/06/21/phpqU3vtk_1.jpg
