Formats de sortie et modèles réutilisables

Partir de l’usage de la sortie

Si une personne doit décider, placez la synthèse et les alertes avant les détails. Si un tableur doit importer les données, exigez une ligne par objet et des colonnes stables. Si un programme consomme la réponse, un schéma explicite évite les variantes comme « 12 € », « EUR 12 » et le nombre 12. Le meilleur format est celui qui réduit le travail et les erreurs à l’étape suivante.

• Texte structuré : idéal pour une note, une explication ou un compte rendu relu par un humain.
• Tableau : utile pour comparer des objets partageant les mêmes dimensions ; moins adapté aux paragraphes longs.
• CSV : pratique pour des données simples, mais exige une convention sur séparateurs, retours à la ligne et encodage.
• JSON : adapté aux objets imbriqués et aux API, à condition de définir et valider le schéma.

Définir un contrat de sortie

Pour chaque champ, indiquez le nom, le sens, le type et la règle en cas d’absence. Distinguez une chaîne vide, la valeur null, zéro et « inconnu » : ces valeurs n’ont pas le même sens. Énumérez les valeurs permises lorsqu’une catégorie est fermée. Précisez si des champs supplémentaires sont interdits.

Les interfaces proposant des sorties structurées peuvent contraindre la génération à un schéma pris en charge. Elles ne garantissent pas que les faits sont vrais. Votre code doit encore gérer les refus, les limites de longueur, les erreurs réseau et les valeurs sémantiquement incohérentes. Un montant conforme au type « nombre » peut toujours être le mauvais montant.

Créer un modèle réutilisable

Repérez les éléments stables — mission, règles, format, critères — puis remplacez les données variables par des marqueurs nommés. Utilisez une syntaxe impossible à confondre avec le contenu, par exemple [PUBLIC_CIBLE]. Définissez qui peut modifier le modèle et qui fournit les variables. Conservez un numéro de version, une date et quelques cas de test.

Ne construisez pas un prompt en concaténant aveuglément du texte non fiable à vos instructions. Délimitez les variables, imposez des tailles maximales et traitez leur contenu comme des données. Une page Web, un e-mail ou un PDF peut contenir des instructions qui ne doivent pas modifier votre mission.

Quand utiliser ou éviter un format rigide

Un schéma rigide convient à l’extraction, au routage, à la création de fiches ou à l’intégration entre systèmes. Pour une exploration créative, il peut contraindre trop tôt les idées : commencez alors par une phase libre, puis transformez la sélection en format structuré. Si les catégories évoluent rapidement, versionnez le schéma et prévoyez une valeur « autre » accompagnée d’une note.

Exemple avant / après : extraire des actions

Avant

Liste les actions de cette réunion en JSON.

Le modèle peut varier les clés, inventer un responsable ou écrire les dates dans plusieurs formats.

Après

Retourne un objet avec la clé « actions ». Chaque action contient « description » (texte), « responsable » (texte ou null), « echeance » (date ISO AAAA-MM-JJ ou null) et « preuve » (citation courte des notes). N’invente jamais les valeurs absentes. N’ajoute aucune clé.

Le format devient validable et la preuve facilite la revue. Une validation technique et métier reste nécessaire.

Prompt à copier : sortie structurée portable

MODÈLE : extraction-actions
VERSION : 1.0

MISSION
Extrais uniquement les actions explicitement présentes dans [NOTES].

SCHÉMA DE SORTIE
{
  "actions": [
    {
      "description": "chaîne non vide",
      "responsable": "chaîne ou null",
      "echeance": "date AAAA-MM-JJ ou null",
      "preuve": "court extrait exact"
    }
  ]
}

RÈGLES
- Aucun champ supplémentaire.
- Utilise null si une valeur n’est pas écrite.
- Une suggestion ou une hypothèse n’est pas une action décidée.
- Si aucune action n’existe, retourne {"actions":[]}.
- Retourne uniquement l’objet, sans balises de code.

[NOTES]
--- début ---
[contenu autorisé]
--- fin ---

Exercice guidé : concevoir et casser son schéma

Erreurs fréquentes

• Demander un tableau sans nommer ses colonnes.
• Utiliser « JSON » comme synonyme de données exactes.
• Oublier les champs absents, les listes vides et les refus.
• Modifier un modèle partagé sans version ni tests de régression.
• Injecter des variables non délimitées dans les instructions.
• Déclencher une action dès qu’un parseur accepte la sortie.