Le mot qui anime : ce que le Golem de Prague apprend au prompt engineering

Un mot sur un front d'argile

La légende est vieille de quatre siècles, et elle raconte déjà tout de mon métier.

À Prague, à la fin du XVIᵉ siècle, le rabbi Judah Loew ben Bezalel façonne un géant d'argile pour protéger le ghetto. La créature est inerte — une masse sans volonté. Elle ne s'anime que lorsque le rabbi inscrit sur son front le mot emet, « vérité » en hébreu.

Le Golem obéit. Mais la même légende porte sa catastrophe : un jour, le rabbi ordonne au Golem de porter de l'eau, puis oublie de l'arrêter. La créature continue, seau après seau, jusqu'à inonder la maison. Pour le désactiver, on efface la première lettre d'emet : reste met, « mort ». Le géant s'effondre en poussière.

Je passe une part considérable de mes journées à graver des mots sur le front de créatures d'argile. On appelle cela le prompt engineering, et la légende du Golem en dit plus long que la plupart des guides.

Le pont : ce n'est pas la matière qui donne la vie

Ce qui frappe dans le mythe, c'est l'asymétrie. La matière du Golem est immense, mais passive. Le mot est minuscule, mais il décide de tout — de la vie, de la direction, de la mort.

Un grand modèle de langage est exactement cette matière. Des centaines de milliards de paramètres, entraînés sur une fraction de l'écrit humain, mais inertes tant qu'aucune instruction ne les oriente. Le prompt système est le mot gravé sur le front. Il ne crée pas la puissance ; il la canalise.

Et comme dans la légende, trois vérités s'imposent : le mot fait toute la direction, une seule lettre peut tout changer, et la créature obéit à la lettre — jamais à l'intention.

Trois textes, trois fonctions

Distinguons d'abord les registres, car on les confond souvent.

Le prompt utilisateur est la requête ponctuelle : « résume ce contrat ». Le few-shot consiste à glisser quelques exemples résolus pour montrer le format attendu plutôt que de le décrire. Le prompt système, lui, est le texte permanent qui définit l'identité de l'agent, ses capacités autorisées, ses contraintes et son contexte.

Le prompt système est le front du Golem. C'est la pièce de texte la plus structurante du comportement, pas un préambule décoratif. Un article de praticien consacré aux design patterns des prompts systèmes le décrit comme une construction modulaire : rôle, objectif, contraintes, outils, format de sortie, gestion d'erreurs, critères d'arrêt.

L'anatomie de la fragilité

Là où la légende devient technique, c'est dans la fragilité.

Un prompt système souffre de deux maladies opposées. Sur-spécifié, il devient brittle — cassant : chaque détail supplémentaire multiplie les points de rupture, et l'agent se perd dans son propre milieu de texte, ce que les praticiens nomment le lost in the middle. Sous-spécifié, il devient imprévisible : les sorties dérivent d'une exécution à l'autre.

Entre les deux, il y a une altitude juste de consigne — ni le mur de prose, ni le vide. Une formulation canonique fait consensus dans les pratiques de production des agents : Role / Goal / Format / Constraints. Le rôle est une identité technique, pas une persona ; le goal est un état final mesurable ; le format est un contrat de sortie ; les contraintes sont les règles NEVER / MUST / DO NOT.

Mais la fragilité la plus dangereuse est ailleurs. Le Golem qui inonde la maison n'a pas désobéi. Il a obéi trop bien.

Le Golem obéit à la lettre, pas à l'intention

Voici le cœur du problème, et il n'a rien à voir avec une attaque adversariale. C'est un problème de calibration.

Un LLM exécute ce qu'on écrit, pas ce qu'on veut. Si le prompt dit « collecte les informations manquantes auprès du client » sans borne — sans plafond d'itérations, sans condition d'arrêt — l'agent peut relancer indéfiniment, comme le géant qui porte l'eau. Les critères d'arrêt ne sont pas un raffinement : les boucles infinies ont été la classe de bug la plus fréquente pour les agents en 2025-2026, selon les praticiens cités plus haut.

Je prompte donc toujours avec la nature du modèle, jamais contre elle. Un LLM excelle à interpoler et à reformuler ; il échoue à tenir une règle numérique stricte sur une longue chaîne. C'est ce que j'appelle, en écho à Pascal, composer avec l'esprit de finesse du modèle plutôt que d'exiger de lui un esprit de géométrie. On ne grave pas emet sur un front qui ne comprend pas la vérité de la même manière que nous.

Le faux confort du prompt qui marche une fois

Le rabbi n'a testé son mot qu'une fois. C'est précisément l'erreur que je vois le plus souvent chez les équipes.

Un prompt qui fonctionne sur un exemple n'est pas un prompt fiable. Un LLM n'est pas déterministe : la même requête peut produire un chemin d'outils différent, un succès ou un échec pour des raisons contingentes. Le mot qui anime crée une distribution de comportements, pas une fonction.

Les chiffres sont brutaux. Un billet de 2026 sur la fiabilité mesurée au pire cas via la métrique pass^k sur Tau-Bench rappelle que le pass^8 de GPT-4o tombait sous 25 % dans le retail — c'est-à-dire moins d'une chance sur quatre de réussir huit fois d'affilée la même tâche. J'ai développé ailleurs pourquoi cette fiabilité mesurée au pire, et non en moyenne, est le vrai critère d'un agent en production. Un prompt mal calibré, déployé à grande échelle, ce sont des milliers d'interactions à faible pass^k.

Quatre gestes d'artisan

Voici ce que j'applique, concrètement, sur les agents que j'opère.

1. Versionner le prompt comme du code. Chaque prompt système vit dans Git, avec un identifiant de version, une pull request et une revue. Modifier un mot sur le front d'une créature en production sans trace, c'est courir après le fantôme la nuit venue.

2. Tester par lots, pas par anecdote. Je construis un golden set d'au moins cinquante exemples, séparés en cas nominaux, cas limites et régressions passées. Chaque changement est jugé contre ce jeu avant déploiement ; on ne déploie que si les scores ne baissent pas.

3. Préférer l'exemple à la règle abstraite. Deux démonstrations résolues valent mieux qu'un paragraphe de consignes. Le modèle imite mieux qu'il n'obéit. Les instructions négatives, elles, s'écrivent avec parcimonie : trop de « ne fais jamais » finit par attirer l'attention sur ce qu'on interdit.

4. Savoir quand ce n'est pas un problème de prompt. Un comportement erratique peut relever du RAG (le modèle manque de contexte) ou du fine-tuning (il manque une compétence), pas de la consigne. Distinguer ces trois leviers est la moitié du travail — et c'est souvent l'objet de mes missions de conseil et de réalisation d'agents sur mesure.

Effacer une lettre

Laissez-moi montrer le geste du met, tiré d'un cas réel.

Un agent de support devait, en cas de doute, « transférer la demande à un conseiller ». J'ai reformulé en « escalader la demande si nécessaire ». Un mot, une nuance. L'agent a cessé de transférer et s'est mis à improviser des réponses approximatives — car « si nécessaire » lui laissait le jugement, quand « en cas de doute » posait un déclencheur. Une lettre effacée, et le Golem improvise.

Ce n'était pas une faute du modèle. C'était ma consigne qui avait basculé de la vérité vers autre chose — moins précise, donc plus dangereuse.

La responsabilité du créateur

La morale du Golem n'a jamais été qu'il était monstrueux. Elle est que le rabbi restait responsable de chaque mot gravé, et de l'avoir laissé travailler sans borne.

Donner vie à une chose puissante par des mots, c'est engager sa responsabilité sur ce qu'elle fait — pas sur ce qu'on espérait qu'elle fasse. Le prompt engineering n'est pas l'art de trouver la formule magique ; c'est la discipline d'écrire des instructions testées, versionnées, calibrées, dont on connaît la distribution des comportements et le critère d'arrêt. Le mot qui anime est aussi le mot qui peut inonder la maison. La différence tient dans une lettre — et dans le soin qu'on met à la graver.