« Prompt engineer » n'a jamais été un intitulé de poste précis, mais pendant un temps, ce n'était pas nécessaire. Si tout votre travail consistait à obtenir une seule bonne réponse d'un seul appel d'inférence, un seul ensemble de compétences suffisait : bien formuler l'instruction, donner quelques exemples, ajouter éventuellement du texte récupéré, et c'était fait. Cet ensemble de compétences compte toujours. Mais il ne couvre plus ce que signifie « construire un agent » mi-2026, et cet écart se manifeste par un mode de défaillance spécifique et reconnaissable : des agents qui fonctionnent à merveille en démo puis se dégradent discrètement, se contredisent, ou oublient ce que l'utilisateur leur a dit deux sessions plus tôt.

Un article récent de Machine Learning Mastery nomme directement cet écart, et il mérite qu'on s'y attarde car il correspond précisément à deux métiers différents pour lesquels on pourrait réellement vous embaucher. L'ingénierie de contexte est ce qui se passe à l'intérieur d'un seul appel d'inférence : décider ce qui entre dans la fenêtre de contexte, où cela se place structurellement, et ce qui est compressé ou supprimé pour que le modèle ne soit pas noyé sous des tokens non pertinents. L'ingénierie de mémoire est un problème différent qui n'existe qu'à travers plusieurs appels : ce qui est consigné après la fin d'une session, où c'est stocké, comment cela est récupéré la fois suivante, et comment c'est entretenu (mis à jour, dédupliqué, expiré) pour que cela ne pourrisse pas. Selon cet article, les défaillances observées dans les flux de travail d'agents longs et multi-sessions découlent le plus souvent de la confusion entre ces deux métiers, ou de l'omission de l'un d'eux — en particulier à ce qu'ils appellent la « frontière de récupération », le moment où un agent doit décider si quelque chose dont il a besoin est déjà sous ses yeux ou doit être extrait du stockage.

Pourquoi les confondre est le véritable bug, pas un détail

Réfléchissez à ce que chaque discipline cherche à optimiser. L'ingénierie de contexte optimise une fenêtre unique, bornée et jetable — placer la bonne tranche d'information devant le modèle, maintenant, pour cet échange précis, puis jeter le reste. L'ingénierie de mémoire optimise un entrepôt durable qui doit survivre entre les sessions, rester cohérent à mesure que de nouvelles informations arrivent, et répondre à une question bien plus difficile : non pas « qu'est-ce qui est pertinent pour ce prompt », mais « qu'est-ce qui mérite d'être conservé, et pour combien de temps ».

Ce sont des problèmes de conception différents, avec des modes de défaillance différents. Une erreur d'ingénierie de contexte dégrade une seule réponse. Une erreur d'ingénierie de mémoire s'accumule — les mauvaises écritures s'entassent, des faits obsolètes sont récupérés comme s'ils étaient à jour, et personne ne s'en aperçoit jusqu'à ce que l'agent répète avec assurance quelque chose qui avait été corrigé trois sessions plus tôt. Si une seule personne (ou un seul modèle de prompt) fait discrètement les deux métiers sans les distinguer, la couche mémoire a tendance à hériter d'habitudes d'ingénierie de contexte qu'elle ne devrait pas avoir : surcharger le stockage comme on surchargerait une fenêtre, ou traiter la récupération comme un problème de classement par pertinence alors qu'il s'agit en réalité d'un problème de curation et d'entretien. C'est la confusion que pointe la synthèse de recherche, et cela rejoint ce que les praticiens décrivent déjà de manière anecdotique : des agents impressionnants sur une seule session et peu fiables dès la cinquième.

À quoi ressemble concrètement chaque métier au quotidien

Si vous essayez de déterminer lequel de ces deux métiers vous exercez déjà, ou vers lequel vous aimeriez évoluer, le travail quotidien est suffisamment différent pour qu'on puisse les distinguer :

L'ingénierie de contexte, en pratique : décider quel sous-ensemble d'informations disponibles (documents, résultats d'outils, tours précédents) appartient vraiment à cet appel ; choisir où, dans le prompt, cela se place, car la position influence la façon dont les modèles le pondèrent ; écrire des étapes de compression ou de résumé pour qu'une longue trace d'outil ne consomme pas tout le budget ; et ajuster cela par tâche, car un agent de débogage et un agent de rédaction veulent des formes de contexte différentes, même sur le même modèle sous-jacent.

L'ingénierie de mémoire, en pratique : définir une politique d'écriture (ce qui mérite d'être conservé après une session — tout ne l'est pas) ; choisir une couche de stockage (une base vectorielle, une base de données structurée, de simples fichiers, ou un hybride) et être honnête sur les compromis de chacune ; construire la stratégie de récupération qui décide ce qui ressort et quand ; et assurer un entretien continu — élaguer, fusionner les faits en double, gérer les contradictions quand l'utilisateur change d'avis. Cette dernière partie, l'entretien, est celle que l'on néglige le plus souvent, car elle ne devient visible qu'après plusieurs semaines de fonctionnement de l'agent.

On voit déjà le secteur commencer à séparer ces préoccupations sur le plan structurel, et pas seulement conceptuel. Le tutoriel de Lenny's Newsletter sur la construction d'un harnais de débogage avec le Claude Agent SDK traite les permissions, les adaptateurs d'outils et le « harnais » environnant comme une surface d'ingénierie à part entière, distincte du prompting qu'il contient — le même réflexe, appliqué à une autre articulation. Et les nouvelles fonctionnalités « Managed Agents » de l'API Gemini de Google — exécution en arrière-plan, renouvellement des identifiants entre les interactions — reviennent, de fait, pour l'éditeur de la plateforme, à admettre que l'état persistant entre sessions est désormais une infrastructure qui doit être conçue, et non un effet secondaire d'une fenêtre de contexte suffisamment longue. Quelqu'un doit être responsable de cette conception. Actuellement, dans beaucoup d'équipes, personne ne l'est explicitement.

Pourquoi cela compte pour votre intitulé de poste, pas seulement pour votre code

Si vous êtes en début ou en milieu de carrière et que « prompt engineer » ou « AI engineer » figure sur votre CV, il vaut la peine de se demander duquel de ces deux métiers vous pouvez réellement apporter la preuve — car les rôles généralistes d'agent IA commencent à se scinder en rôles plus spécifiques, de la même façon que « webmaster » a fini par se diviser en frontend, backend et DevOps. C'est une précaution, pas un scoop : je n'ai pas encore vu de données de recrutement solides confirmant « memory engineer » comme intitulé à part entière, donc considérez ceci comme une lecture de la direction que prend le métier, pas comme l'affirmation que les offres d'emploi sont déjà organisées ainsi. Mais la pression sous-jacente est réelle et se rattache à la synthèse évoquée plus haut : les équipes d'agents se heurtent à une défaillance précise et nommable (la dégradation multi-sessions) qui a une cause précise et nommable (la confusion entre deux disciplines), et c'est généralement ce genre de combinaison qui transforme un rôle flou en deux rôles nets.

La démarche pratique n'est pas de s'inventer un intitulé. C'est d'être capable de répondre, concrètement, à quel problème vous avez réellement résolu. Avez-vous livré quelque chose où vous avez conçu une politique d'écriture — une règle définissant ce qu'un agent enregistre en mémoire et ce qu'il écarte ? Avez-vous débogué une défaillance à la frontière de récupération, où un agent avait besoin de quelque chose issu du stockage et soit ne l'a pas récupéré, soit a récupéré la mauvaise version ? Ce sont des affirmations vérifiables que vous pouvez avancer en entretien, étayées par un dépôt de code ou un post-mortem, et elles disent quelque chose qu'un « j'écris de bons prompts » générique ne dit pas : que vous comprenez la différence entre améliorer une seule réponse et rendre un agent digne de confiance dans la durée.

Une mise en garde

Ne vous rebaptisez pas « memory engineer » sous prétexte d'avoir ajouté une base de données vectorielle à un projet, une fois. La discipline que pointe cette recherche comprend la moitié ingrate — l'entretien, l'expiration, la gestion des contradictions — et c'est précisément cette moitié qui empêche réellement le mode de défaillance décrit plus haut. Si votre pièce de portfolio est un système qui écrit en mémoire mais où rien n'est jamais élagué ni corrigé, vous n'avez construit que la moitié du métier de memory engineer, et le problème de la panne après la troisième session vous attend toujours sur l'autre moitié.