La mémoire persistante de votre assistant de code est un pharmakon

Un dieu égyptien offre un cadeau empoisonné

Dans le Phèdre, Platon raconte une scène étrange. Le dieu Theuth présente au roi Thamous son invention la plus précieuse : l'écriture.

Theuth la vante comme un remède — en grec, un pharmakon — contre l'oubli. Grâce aux signes tracés, prétend-il, les hommes deviendront plus savants et retiendront tout. Le roi refuse de s'extasier.

Thamous répond que ce prétendu remède est aussi un poison. En confiant leur savoir à des traces extérieures, les hommes cesseront de cultiver leur propre mémoire. Ils auront « l'air de tout connaître sans rien savoir ». Le mot pharmakon désigne précisément cette ambivalence : la même substance soigne et empoisonne, selon la dose et l'usage.

Je repense à cette scène chaque fois qu'on me vante la nouveauté qui change, paraît-il, le métier de développeur : la mémoire persistante des assistants de code, et notamment celle de GitHub Copilot.

Ce que Copilot retient désormais

La documentation officielle de GitHub décrit un mécanisme précis. Copilot distingue deux types de souvenirs.

D'un côté, les faits propres au dépôt : conventions de code, décisions d'architecture, commandes de build, règles du projet. De l'autre, les préférences personnelles du développeur, qui restent attachées à leur auteur. Les faits du dépôt, eux, sont partagés entre tous les utilisateurs autorisés.

La promesse est séduisante. Fini le travail de réexplication à chaque session : l'assistant retient que vous utilisez tel gestionnaire de paquets, telle convention de nommage, telle commande de test.

GitHub a prévu des garde-fous sérieux. Chaque fait est enregistré avec une citation pointant vers le code qui le justifie. Avant de réutiliser un souvenir, Copilot vérifie cette citation dans la branche courante. Les faits inutilisés disparaissent automatiquement après 28 jours, délai réinitialisé à chaque réutilisation validée.

Sur le papier, le pharmakon n'est ici que remède. Mais la pratique est plus rugueuse.

Quand le souvenir cesse d'être vrai

L'erreur d'une autocomplétion est ponctuelle : elle apparaît, vous la corrigez, elle s'efface. L'erreur d'une mémoire persistante est d'une autre nature — elle se rejoue.

Un mauvais pattern appris une fois contamine chaque session suivante. Une convention devenue obsolète fossilise un choix périmé. Une hypothèse fausse sur l'architecture se propage silencieusement dans toutes les suggestions futures.

Ce glissement a été mesuré. Dans une étude de 2026 consacrée à la validité temporelle de la mémoire des assistants de code (Yadav, Temporal Validity on Real Software Histories), l'auteur part d'une observation simple : dans un logiciel vivant, le nom d'une fonction, le chemin d'une API, une version de dépendance ou une valeur de configuration changent.

Une mémoire fondée sur la seule similarité sémantique retrouve alors l'ancienne et la nouvelle valeur — sans savoir laquelle est actuelle. Sur 130 transitions réelles extraites de correctifs GitHub issus de SWE-bench, le système RAG étudié restitue une valeur obsolète dans 36 à 38 % des cas lorsqu'il doit répondre.

Un mécanisme de « supersession » — retirer explicitement l'ancien fait quand un nouveau le remplace — réduit fortement l'erreur. L'étude reste honnête sur sa portée : ces 130 cas ne représentent qu'environ 18 % des correctifs examinés, les changements les plus atomiques et faciles à modéliser.

La difficulté réelle n'est donc pas de se souvenir. C'est de savoir si le souvenir est encore vrai.

Le poison n'est pas technique, il est cognitif

Voilà où Thamous nous rattrape. Le vrai danger n'est pas qu'une valeur obsolète se glisse dans une suggestion — ça, une revue le corrige.

Le danger est plus insidieux. Une convention mémorisée cesse d'être une hypothèse révisable et prend l'apparence d'un fait permanent. Si personne dans l'équipe ne se demande plus pourquoi une règle existe, la mémoire de l'outil devient une autorité silencieuse.

C'est exactement la critique du Phèdre : l'écriture « a l'air de penser », mais si on l'interroge, elle répète toujours la même chose. Une mémoire d'assistant non gouvernée répond de même — avec l'aplomb d'un fait et la rigidité d'une trace morte.

J'ai déjà écrit sur la dette cognitive que creuse un copilote trop zélé, quand le développeur perd la compréhension de son propre code. La mémoire persistante aggrave cette dette d'un cran : elle ne fossilise plus seulement l'ignorance d'un individu, mais celle de toute l'équipe, session après session.

Quatre gestes pour gouverner la mémoire

La réponse n'est pas de refuser le remède. Elle est de maîtriser la dose. Sur mes propres projets, où j'opère ces assistants avant de les recommander, j'applique quatre gestes.

Premier geste : donner une date de péremption aux conventions apprises. GitHub propose déjà 28 jours d'expiration ; je ne considère pas cela comme un détail à subir mais comme un réglage à défendre. Une convention qui n'a pas été réutilisée depuis un mois mérite d'être oubliée plutôt que ressuscitée par automatisme.

Deuxième geste : relire les « faits » mémorisés comme on relit du code. Les souvenirs d'un assistant ne sont pas sacrés. Une revue périodique de ce que l'outil croit vrai — trimestrielle au minimum — débusque l'hypothèse fausse avant qu'elle ne se propage.

Troisième geste : séparer strictement mémoire projet et mémoire équipe. La distinction de GitHub entre faits du dépôt et préférences personnelles est un bon point de départ. Une préférence individuelle (« j'aime ce style de commentaire ») ne doit jamais contaminer une décision d'architecture partagée par tous.

Quatrième geste : prévoir un désapprentissage explicite quand l'architecture change. C'est le plus négligé. Lorsqu'on renomme une fonction, change un endpoint ou migre une dépendance, il faut retirer l'ancien fait, pas seulement en ajouter un nouveau. C'est la logique de supersession de l'étude, transposée en discipline d'équipe.

Ces gestes relèvent d'une compétence plus large : savoir quand une machine doit oublier. J'ai défendu la nécessité de l'oubli pour les agents autonomes, et le principe vaut tout autant ici — gouverner une mémoire, c'est d'abord décider ce qu'on y laisse mourir.

Le roi Thamous avait raison, à moitié

Le roi égyptien se trompait sur un point : l'écriture n'a pas dépossédé l'humanité de son jugement. Elle l'a augmentée — à condition qu'on apprenne à lire et à douter de ce qu'on lit.

La mémoire persistante d'un assistant de code suit la même courbe. C'est un remède réel pour qui l'inspecte, la conteste, la corrige et sait l'oublier. C'est un poison lent pour qui la laisse devenir une vérité par défaut.

La question n'est donc jamais « faut-il activer la mémoire ? », mais « qui, dans l'équipe, est le gardien de ce qu'elle retient ? ». Chez dac.consulting, c'est la première chose qu'on règle avant d'équiper une équipe : non pas comment la machine se souvient, mais comment elle désapprend. Un pharmakon ne devient remède qu'entre les mains de quelqu'un qui en connaît la dose.