La levée de boucliers contre GPT-5 a été intense, et les raisons ne manquent pas, mais nous sommes en train de réaliser une chose : les gens ont vraiment aimé la fonction de mémoire de ChatGPT.
Petite confession : nous ne l’utilisons pas vraiment. Pourquoi ? Parce que nous ne lui faisons pas vraiment confiance… elle ne nous a jamais semblé très fiable et, même si elle s’est améliorée, elle nous a paru davantage relever du gadget que de l’utilité concrète (voir mon article sur l’apprentissage continu pour comprendre pourquoi).
Google et Anthropic en prennent note, et viennent tous deux de lancer leur propre version préliminaire de la mémoire : Google a rendu Gemini plus personnel en lui permettant d’apprendre de vos conversations passées (fonction activée par défaut), tandis qu’Anthropic a déployé une recherche à la demande dans les conversations Claude précédentes que vous lui demandez explicitement d’examiner.
Le contraste est intéressant (personnalisation par défaut contre rappel explicite), avec des implications évidentes pour les équipes qui doivent trouver un équilibre entre commodité et confidentialité.
Voici comment les deux fonctionnent :
- « Contexte personnel » de Gemini. Lorsqu’elle est activée, la fonctionnalité permet à Gemini de mémoriser des informations clés et vos préférences issues de conversations précédentes afin d’adapter ses réponses. Elle est activée par défaut et est d’abord déployée sur Gemini 2.5 Pro dans certains pays, avec un bouton d’activation dans les Paramètres.
- La mémoire de Claude. La version d’Anthropic, qui recherche et référence les conversations (déploiement progressif pour les offres Max, Team et Enterprise), ne récupère les échanges passés pertinents que lorsque vous le lui demandez (il ne s’agit pas d’un profil persistant), sur le Web, ordinateur et mobile. Bouton d’activation dans Paramètres → Profil.
Quelques exemples :
- Demandez à Gemini : « Peux-tu me proposer de nouvelles idées de vidéos, dans le style de la série sur la culture japonaise dont nous avons parlé ? » Il se souviendra de vos conversations et vous proposera des pistes de suivi.
- Demandez à Claude : « Reprends la refonte du tableau de bord que nous avions mise en pause avant les vacances. » Il recherchera et résumera les conversations passées pertinentes, puis poursuivra le travail.
Passez à Sonnet 4
Anthropic vient également d’offrir à son modèle Claude Sonnet 4 une mise à niveau massive : une fenêtre de contexte d’un million de jetons, dont Gemini dispose déjà depuis quelque temps. Pour donner un ordre de grandeur, cela suffit pour lire l’intégralité d’une base de code de plus de 75 000 lignes dans un seul prompt.
Au-delà de l’évidence, pourquoi la mémoire et un long contexte sont-ils importants ?
Parce qu’ils ont un impact sur la fiabilité dans le monde réel. Vous vous souvenez de cette étude dans laquelle le laboratoire de recherche en IA METR avait constaté que, même si les développeurs pensaient que l’IA les rendait 20 % plus rapides, elle les rendait en réalité 19 % plus lents?
Les chercheurs de METR viennent de mettre au jour une autre déconnexion préoccupante qui l’explique. Dans ce rapport, intitulé « Évaluation algorithmique contre évaluation holistique », les chercheurs ont confié à un agent d’IA autonome propulsé par Claude 3.7 Sonnet (notamment une version moins puissante que le Claude 4 Sonnet de pointe) 18 tâches d’ingénierie logicielle du monde réel, tirées de dépôts open source vastes et complexes. Ils ont ensuite évalué le travail de l’IA de deux façons.
Tout d’abord, ils ont utilisé une notation algorithmique, la méthode standard de la plupart des benchmarks d’IA. Ils se sont contentés d’exécuter les tests automatisés que le développeur humain d’origine avait écrits pour la tâche. Selon cette mesure, l’agent d’IA semblait modérément performant : il réussissait tous les tests dans 38 % des cas. S’il s’agissait d’un benchmark comme le populaire SWE-Bench, ce serait un score respectable.
Mais la deuxième évaluation est ensuite arrivée : la notation holistique. Un expert humain a examiné manuellement le code de l’IA pour vérifier s’il était réellement utilisable — s’il pouvait être intégré au projet du monde réel. Les résultats ont été accablants. Aucun des livrables de l’IA, soit 0 %, ne pouvait être fusionné tel quel.
Même dans les 38 % de cas où le code de l’IA était « correct sur le plan fonctionnel » et réussissait tous les tests, il restait dans un état lamentable. Les chercheurs ont estimé qu’un développeur humain expérimenté aurait besoin en moyenne de 26 minutes pour corriger le travail « réussi » de l’IA. Ce temps de nettoyage représentait environ un tiers du temps total qu’il aurait fallu à un humain pour accomplir toute la tâche à partir de zéro.
Cela dit, améliorer sa productivité de 33 % reste une excellente chose. Mais passer du temps à nettoyer le travail bâclé de l’IA est-il gratifiant ? Nous y réfléchissons beaucoup lorsque nous testons l’IA pour nous aider à rédiger nos articles. Parfois, nous passons plus de temps à remettre les éléments en forme et à recréer tous les hyperliens que cela finit par ressembler au travail ingrat de débutant qui est en train d’être automatisé sous nos yeux. Alors pourquoi est-ce que moi, un soi-disant « travailleur du savoir », je fais le travail qu’une IA devrait par défaut être capable d’accomplir ? Pour reprendre les mots de Sam Altman, est-ce un « problème de compétences » ?
Le côté plus « subjectif » de l’échec
Alors, où l’IA échouait-elle ? Pas dans la logique fondamentale, que les tests automatisés pouvaient vérifier. Elle échouait dans tous les aspects cruciaux et plus « subjectifs » d’une bonne ingénierie logicielle, qui exigent une compréhension globale du projet. L’IA produisait systématiquement du code avec :
- Une couverture de tests insuffisante : Elle n’écrivait pas assez de tests pour s’assurer que son nouveau code était robuste.
- Une documentation absente ou incorrecte : Elle n’expliquait pas ce que faisait le code, ce qui constitue une faute critique dans les projets collaboratifs.
- Des violations des règles de linting et de formatage : Le code ne respectait pas le guide de style établi par le projet.
- Une mauvaise qualité de code : Le code était souvent verbeux, fragile ou difficile à maintenir pour un humain.
Chaque tentative de l’IA comportait au moins trois de ces cinq types d’échec. C’était comme embaucher un architecte brillant, capable de concevoir une pièce structurellement solide, mais qui aurait oublié d’y prévoir une porte, des fenêtres ou des prises électriques, avant de laisser les plans sur une serviette tachée.
Cette nouvelle étude fournit l’explication définitive du paradoxe de la productivité des développeurs. Les développeurs ont l’impression d’être plus rapides parce que l’IA prend en charge le cœur du problème logique, souvent fastidieux, au centre d’une tâche. Mais ils finissent par être plus lents parce qu’ils doivent passer énormément de temps à nettoyer les dégâts et à corriger tous les éléments contextuels ignorés par l’IA. L’IA gagne la bataille, mais perd la guerre.
Les benchmarks actuels du code généré par l’IA ignorent ce temps supplémentaire perdu, ce qui explique peut-être pourquoi les développeurs sont paradoxalement plus lents avec l’IA, malgré l’impression d’être plus productifs.
Ah, et vous vous souvenez de l’autre étude de METR, qui mesurait la capacité de l’IA à effectuer de longues tâches et montrait que leur durée doublait ? Cette étude repose elle aussi sur des cas de test, et non sur une mise en œuvre dans le monde réel… il reste donc à voir à quel point ces tâches sont réellement « complètes » dans la vie courante.
C’est là que les longs contextes et la mémoire entrent en jeu
L’étude de METR prouve que l’IA échoue lorsqu’elle ne peut pas voir l’ensemble du tableau. Des fonctionnalités comme une fenêtre d’un million de jetons permettent à une IA de lire toute la base de code d’un coup, afin d’en comprendre la structure et les normes. La mémoire l’aide à se rappeler les instructions précédentes et les objectifs du projet (et, espérons-le, ces capacités vont ENCORE s’améliorer). C’est le genre de fonctionnalité qui peut résoudre le problème « de milieu à milieu » de l’IA (le fait que nous soyons souvent happés par la vérification — autrement dit, la correction — des résultats de l’IA au lieu de la laisser mener les tâches à bien).
Dans ce cas, une meilleure mémoire et des fenêtres de contexte plus longues pourraient être exactement ce qu’il faut pour combler l’écart entre une IA qui réussit les tests et une IA qui écrit du code réellement utilisable.
Réfléchissez-y : lorsque les agents de METR n’ont pas réussi à produire du code pouvant être fusionné, ce n’était pas parce qu’ils étaient incapables de résoudre le problème algorithmique central, mais parce qu’ils ne disposaient pas du contexte plus large définissant ce qui rend le code prêt pour la production dans ce dépôt précis. Ils ne tenaient pas compte des normes de documentation, des conventions de test, des attentes en matière de qualité du code et des exigences de formatage qu’un développeur expérimenté travaillant sur ce projet connaîtrait de mémoire.
Les outils d’IA actuels fonctionnent avec une fenêtre étroite de contexte immédiat et se concentrent uniquement sur les exigences fonctionnelles, tout en ignorant les dizaines de normes et de pratiques implicites qui rendent réellement le code intégrable. Grâce à de meilleurs systèmes de mémoire capables de se rappeler les normes de codage propres au projet, les remarques antérieures sur la qualité du code et les connaissances accumulées sur ce à quoi ressemble un « bon » code dans une base donnée, l’IA pourrait commencer à s’attaquer à ces 26 minutes de corrections qui rendent actuellement inutilisables même les livrables de code « réussis » de l’IA… et potentiellement réduire l’écart entre avoir l’impression d’être productif et être réellement productif. Du vibe coding… au vrai code.
Note de la rédaction : ce contenu a d’abord été publié dans notre publication sœur, The Neuron. Pour lire davantage d’articles de The Neuron, inscrivez-vous à sa newsletter ici.