Structurer un prompt long

Pourquoi la structure d’un prompt compte

Un prompt de 5 lignes ne pose pas de probleme de lisibilite. Mais des que la demande depasse 15-20 lignes — plusieurs fichiers a modifier, des contraintes croisees, du contexte technique — la structure devient critique. Sans elle, l’agent peut ignorer une instruction noyee au milieu, confondre une donnee avec une directive, ou interpreter l’ordre des consignes a l’envers.

Point cle : La structure ne change pas le contenu du prompt. Elle change la probabilite que l’agent le comprenne correctement du premier coup.

Dans le Core Four (Model, Prompt, Context, Tools), structurer son prompt, c’est optimiser le levier Prompt sans ajouter un seul token de contenu. C’est un gain de precision gratuit.

---

Balises XML : le standard de fait

Les balises XML sont le mecanisme le plus fiable pour delimiter des sections dans un prompt long. Elles sont supportees nativement par les principaux modeles et permettent de creer une hierarchie explicite que l’agent peut parser sans ambiguite.

Principe de base

Chaque section du prompt est encadree par une paire de balises ouvrante/fermante. Le nom de la balise decrit le role du contenu :

<instructions>
Refactore le service de commandes en extrayant
la logique de validation dans une classe separee.
</instructions>

<contraintes>
- C# 12, .NET 8
- Pas de dependance externe
- Garde l'API publique identique
</contraintes>

<code_source>
// le fichier OrderService.cs a modifier
public class OrderService { ... }
</code_source>

Point cle : Les balises XML separent les roles : ce que l’agent doit faire (<instructions>), les regles a respecter (<contraintes>), et la matiere premiere (<code_source>). L’agent ne confond plus une contrainte avec du code a modifier.

Noms de balises courants

Balise	Role	Contenu type
<instructions>	Directives principales	Ce que l’agent doit faire
<contraintes>	Regles et limites	Langage, framework, interdictions
<contexte>	Informations de fond	Architecture, conventions d’equipe
<code_source>	Donnees a traiter	Le code existant, les fichiers
<format_sortie>	Livrable attendu	Fichier complet, diff, test
<exemples>	Illustrations	Avant/apres, patterns a suivre

Piege : N’inventez pas des dizaines de balises differentes. 3 a 6 balises bien nommees suffisent. Au-dela, la structure elle-meme devient du bruit.

---

Hierarchie : les instructions les plus importantes en premier

Les modeles de langage ont un biais de position : les instructions placees au debut et a la fin du prompt sont mieux retenues que celles du milieu. Ce phenomene (souvent appele “lost in the middle”) a une consequence directe sur l’organisation d’un prompt long.

Point cle : Regle pratique : placez l’instruction principale tout en haut du prompt, les contraintes critiques juste apres, et le code source (les donnees) en dernier. Ne noyez jamais la consigne la plus importante au milieu d’un bloc de contexte.

C’est exactement le principe qu’applique un fichier CLAUDE.md bien structure : les conventions prioritaires sont en tete, les details secondaires sont plus bas.

---

Separer instructions et donnees

L’erreur la plus frequente dans un prompt long est de melanger les directives et les donnees dans le meme paragraphe. Par exemple :

# Mauvais : tout melange
Voici le fichier OrderService.cs, je voudrais que tu
extraies la validation, le code utilise C# 12, voici
le code : public class OrderService { ... } et
n'oublie pas de garder l'API publique.

L’agent doit demeler ce qui est une instruction, ce qui est une contrainte, et ce qui est du code. Sur un prompt court, il s’en sort. Sur un prompt de 50 lignes avec 3 fichiers, il va rater quelque chose.

# Bon : separation claire
<instructions>
Extrais la logique de validation de OrderService
dans une classe separee OrderValidator.
</instructions>

<contraintes>
- C# 12
- Garde l'API publique de OrderService identique
</contraintes>

<code_source fichier="OrderService.cs">
public class OrderService { ... }
</code_source>

Piege : Si vous collez du code directement dans le texte de vos instructions sans delimiteur, l’agent peut interpreter une ligne de code comme une directive. C’est une source classique de resultats inattendus.

---

Quand un prompt long est justifie — et quand decouper

Un prompt long est justifie quand la tache est atomique mais necessite beaucoup de contexte : un refactoring qui touche plusieurs fichiers lies, une migration avec des regles de transformation precises, un endpoint complet avec ses tests.

Un prompt long n’est pas justifie quand il regroupe des taches independantes. “Refactore ce service ET ajoute un endpoint ET corrige ce bug” devrait etre 3 prompts separes, car l’agent ne peut pas commiter partiellement et un echec sur une tache contamine les autres.

Situation	Approche recommandee
Tache unique, contexte riche (3 fichiers lies)	Un seul prompt long, bien structure
3 taches independantes	3 prompts separes
Tache complexe avec etapes sequentielles	Un prompt pour la premiere etape, puis iterer
Beaucoup de contraintes sur une seule tache	Un prompt long avec section <contraintes> dediee

Point cle : La regle : un prompt = une tache. Si la tache est complexe, structurez le prompt. Si ce sont plusieurs taches, decoupez en plusieurs prompts.

---

Recapitulatif : les regles de structure

Regle	Pourquoi
Balises XML pour delimiter les sections	L’agent parse les roles sans ambiguite
Instruction principale en tete	Biais de position : le debut est mieux retenu
Separer instructions et donnees	Evite la confusion directive/code
3 a 6 balises maximum	Au-dela, la structure devient du bruit
Un prompt = une tache	Plusieurs taches = plusieurs prompts
Contraintes critiques en haut, details en bas	Le milieu du prompt est la zone la moins fiable

---