On me demande souvent comment mieux écrire un prompt. Le gain est rarement là. Le progrès le plus net de mon année ne vient pas d'une formulation plus habile, mais d'une poignée de fichiers texte que mes assistants lisent avant de commencer à travailler. Il n'y a rien d'astucieux dedans : des noms propres, des orthographes, des décisions déjà prises.
Trois symptômes
Tu sais qu'il te manque quand tu vois ça :
- L'assistant te propose une option que tu as écartée il y a trois semaines, avec de bons arguments, et tu dois refaire le débat.
- Il écrit le nom d'un de tes outils, d'un de tes produits ou d'un de tes clients avec une orthographe fantaisiste, et ça part dans un document que tu envoies.
- Il travaille très sérieusement sur un état des choses qui n'est plus d'actualité, parce que personne ne lui a dit que c'était de l'historique.
Aucun de ces trois cas n'est un problème de modèle. C'est un problème de matière. Tu as le contexte dans la tête, lui ne l'a pas, et tu le redonnes à l'oral, par morceaux, à chaque fois.
Ce qui mérite d'être écrit
Les noms propres, avec l'orthographe exacte
Le bloc le plus bête et le plus rentable. Les noms de tes outils, de tes produits, de tes structures, des personnes avec qui tu travailles. Et surtout les cas où ce que tu prononces ne correspond pas à ce qui s'écrit.
Je dicte beaucoup à la voix. Mes propres noms d'agents finissent en -ie et se prononcent en -y : sans la ligne qui le précise, j'ai deux orthographes du même nom dans mes fichiers au bout d'une semaine. Même chose pour un nom de plateforme en un seul mot que la dictée coupe en deux. Écris la forme juste, et écris la forme fausse à côté — c'est celle-là qui permet de la rattraper.
Si deux entités portent un nom proche, dis laquelle fait référence. Deux structures successives avec le même nom légal, deux comptes du même outil, deux versions d'un fichier : sans arbitrage écrit, l'assistant choisit, et il choisit parfois la mauvaise.
Les décisions déjà tranchées, et leur raison
Format : on a retenu X plutôt que Y, parce que Z. Avec la mention explicite que c'est tranché.
Sans ce bloc, tu ré-arbitres en boucle. Un assistant qui ne sait pas qu'une option a été étudiée et rejetée la reproposera, puisqu'elle est raisonnable dans l'abstrait. Et toi, trois semaines plus tard, tu ne te souviens plus toujours pourquoi tu l'avais écartée — donc tu hésites. La raison compte autant que la décision : c'est elle qui te dit si une décision mérite d'être rouverte quand le contexte change.
Le vocabulaire imposé et le vocabulaire interdit
Chaque projet a ses mots maison et ses mots bannis. Une organisation qui ne veut jamais lire « newsletter » dans ses textes publics et qui dit autrement. Un terme technique qu'on n'emploie pas devant les clients. Un mot que tu trouves creux et qui revient quand même.
Deux lignes par entrée : le mot à employer, le mot à ne pas employer. C'est ce qui fait la différence entre un texte à reprendre et un texte à relire.
La frontière entre l'actuel et l'historique
Un fichier de contexte vit plusieurs mois, donc il accumule. Au bout d'un moment, il contient ce qui est vrai aujourd'hui et ce qui l'était en juin.
Deux habitudes suffisent : date les lignes qui portent une décision, et marque explicitement comme historique ce qui a été remplacé. On garde l'historique, parce qu'il évite de refaire les mêmes essais — mais il doit être signalé comme tel, sinon il fait exactement l'inverse.
Ce qui ne doit pas sortir
Le bloc qu'on oublie, et le plus important si tu produis du contenu public. Ce que tu ne publies pas : les noms de clients, les chiffres de résultats, les lieux sensibles, ce qui relève d'un échange privé.
Une consigne négative écrite une fois vaut mieux qu'une relecture angoissée à chaque production. C'est aussi la seule façon de confier une publication à une tâche programmée sans la surveiller.
Un fichier par sujet, une ligne par fait
Trois règles d'écriture, et c'est tout.
Un fichier par sujet. Un projet, un client, un domaine. Un gros document unique n'est jamais lu en entier, et surtout il n'est jamais chargé au bon moment.
Une ligne par fait. Pas de paragraphes. Une ligne se corrige, se supprime, se retrouve. Un paragraphe se contredit tout seul au bout de trois relectures.
Une phrase de description en tête du fichier. Ce qu'il contient, et quand il faut le lire. C'est ce qui permet de savoir lequel ouvrir sans tous les ouvrir.
La règle de déclenchement : si tu as dû le réexpliquer deux fois, ce n'est pas une consigne, c'est une ligne de contexte à écrire.
Ce que ça ne remplace pas
Ce n'est pas la documentation de tes automatisations. Celle-là répond à d'autres questions — à quoi sert cet agent, comment le couper, comment le tester — et elle s'adresse à des humains. Le fichier de contexte, lui, s'adresse à la machine : il lui donne les faits qu'elle ne peut pas deviner.
Ce n'est pas non plus un substitut à la relecture. Un bon contexte réduit les erreurs grossières, il ne garantit pas le jugement.
Et ça périme. La maintenance consiste autant à retirer qu'à ajouter : une ligne devenue fausse est plus nuisible qu'une ligne absente, parce qu'elle est appliquée avec confiance.
Par où commencer
Prends le sujet sur lequel tu te répètes le plus. Ouvre un fichier et écris dix lignes : les trois noms propres qu'on écorche, les deux décisions déjà prises, les deux mots à ne pas employer, ce qui ne sort pas. Un quart d'heure.
Puis relance ton assistant sur une tâche que tu lui as déjà confiée, avec ce fichier en entrée. Tu verras immédiatement ce que tu portais tout seul.