Points clés
- Créez un framework personnalisé lorsque vous ajoutez les mêmes 3+ composants à chaque prompt d'un workflow
- Utilisez 3 à 6 composants : moins est une technique, plus crée de la friction
- Testez sur 10 prompts réels avant de documenter
- Vérifiez la fiabilité multi-modèles sur GPT-4o et Claude 4.6 Sonnet
- Stockez la spec du framework dans le contrôle de version avec un modèle et 3 exemples annotés
Framework vs. technique : quelle est la différence ?
📍 In One Sentence
Un framework de prompts est un modèle structurel définissant quels composants appartiennent à chaque prompt ; une technique est un modèle appliqué à l'intérieur d'un de ces composants.
💬 In Plain Terms
Le framework est l'échafaudage de chaque prompt — il définit les sections. Une technique est ce que vous faites à l'intérieur d'une section, par exemple demander au modèle de raisonner étape par étape.
Un framework de prompts est un modèle structurel définissant quels composants appartiennent à chaque prompt ; une technique est un modèle appliqué à l'intérieur d'un de ces composants. Le chain-of-thought prompting est une technique — vous l'appliquez à l'intérieur du composant "tâche" d'un framework. CO-STAR est un framework — il définit 6 composants qui structurent l'ensemble du prompt.
Cette distinction est importante car les frameworks et les techniques résolvent des problèmes différents. Un framework résout la cohérence : tout le monde dans votre équipe produit des prompts avec la même structure. Une technique résout la capacité : elle change la façon dont le modèle aborde une étape spécifique du raisonnement.
Utilisez un framework existant (CO-STAR, CRAFT, RISEN, RTF) quand votre type de tâche correspond à ce pour quoi le framework a été conçu. Créez-en un personnalisé quand vous ajoutez régulièrement les mêmes composants spécifiques à un domaine qu'aucun framework existant n'inclut.
📌 Distinction clé
Les frameworks résolvent la cohérence au sein de l'équipe. Les techniques résolvent la capacité dans une étape de prompt. Les deux sont nécessaires ; l'un ne remplace pas l'autre.
Quand créer un framework de prompts personnalisé
Créez un framework personnalisé lorsque vous appliquez les mêmes 3+ modifications à un framework standard pour chaque prompt d'un workflow. Si vous ajoutez toujours une contrainte de conformité, un vocabulaire de domaine et un schéma de sortie — ces éléments doivent devenir des composants de votre propre framework.
Signes que vous avez besoin d'un framework personnalisé :
- Vous ajoutez les mêmes champs à chaque prompt qu'aucun framework standard n'inclut
- Votre équipe produit des prompts incohérents malgré l'utilisation de CO-STAR ou CRAFT
- Les nouveaux membres prennent plus d'une semaine pour écrire des prompts acceptables
- Vos prompts dépassent 600 mots car vous expliquez toujours le même contexte
- Vous avez créé un "prompt de base" que tout le monde copie et adapte manuellement
Créer un framework de prompts personnalisé en 5 étapes
Le processus en 5 étapes : définir l'objectif → identifier les composants → tester sur 10 prompts → affiner → documenter. Chaque étape a un critère de sortie clair. Ne sautez pas à l'étape 5 — documenter un framework non testé crée une fausse confiance.
- 1Définir l'objectif en une phrase
Why it matters: Écrivez exactement quelle sortie ce framework doit produire de manière fiable. Cette phrase gouverne chaque décision de composant. - 2Identifier 3 à 6 composants requis
Why it matters: Listez les éléments d'entrée que chaque prompt de ce workflow nécessite. Commencez par écrire 5 prompts de mémoire, puis extrayez ce qu'ils partagent. - 3Appliquer à 10 prompts réels
Why it matters: Utilisez des prompts réels de votre workflow — pas des exemples inventés. Évaluez chaque sortie. Testez sur GPT-4o et Claude 4.6 Sonnet via PromptQuorum. - 4Affiner la liste des composants
Why it matters: Supprimez les composants qui apparaissent dans moins de 7 prompts sur 10. Ajoutez ceux que vous avez improvisés dans 5+ cas. Retestez. - 5Documenter et standardiser
Why it matters: Rédigez une spec d'une page : nom du framework, définition de chaque composant, modèle avec espaces réservés, et 3 exemples annotés. Stockez dans Git ou PromptHub.
⚠️ Ne sautez pas l'étape 3
Sans tester 10 prompts réels, le framework contiendra presque toujours des composants ignorés sous la pression du temps. Testez d'abord, documentez ensuite.
Exemple : créer un framework pour une équipe support
Le framework personnalisé d'une équipe support — nommé REPAIR — comprend 5 composants : Role, Escalation condition, Policy anchor, Action path, Intent confirmation. Les frameworks standard comme CO-STAR et CRAFT n'incluent pas la logique d'escalade ni l'ancrage de politique, nécessaires pour chaque prompt support.
L'équipe a constaté qu'elle ajoutait manuellement les mêmes éléments à chaque prompt CO-STAR : le niveau de rôle spécifique de l'agent, la politique SLA applicable et un chemin d'escalade conditionnel. Après 3 semaines, ces ajouts ont été formalisés comme composants du framework.
💡 Mesurez l'impact
Suivez le temps d'onboarding et les scores de cohérence avant et après le déploiement d'un framework personnalisé. S'il ne s'améliore pas en 4 semaines, le framework nécessite un raffinement.
Erreurs courantes lors de la création de frameworks personnalisés
L'erreur la plus courante est de créer un framework sans tester 20+ prompts réels manuellement. Les frameworks construits à partir de la théorie incluent des composants qui semblent importants mais sont ignorés en pratique.
❌ Trop de composants (7+)
Why it hurts: Les rédacteurs sautent des sections sous pression, brisant la cohérence.
Fix: Limitez à 6 composants. Déplacez les champs spécifiques au domaine dans des extensions, pas dans le framework principal.
❌ Copier un framework standard et le renommer
Why it hurts: Un CO-STAR renommé n'est pas un framework personnalisé.
Fix: Formalisez un framework uniquement si vous avez au moins 2 composants qui n'existent dans aucun framework standard.
❌ Pas de jeu de test avant la documentation
Why it hurts: Vous documentez un framework qui ne résiste pas aux prompts réels.
Fix: Testez 10 prompts réels avant d'écrire la spec.
Questions fréquentes
Qu'est-ce qu'un framework de prompts ?
Un framework de prompts est un modèle structurel qui définit quels composants inclure dans un prompt et dans quel ordre. Les frameworks améliorent la cohérence et réduisent le temps de rédaction.
Quand créer un framework personnalisé ?
Créez-en un quand vous appliquez les mêmes 3+ modifications à un framework standard pour chaque prompt d'un workflow.
Combien de composants doit avoir un framework ?
Utilisez 3 à 6 composants. Moins est une technique. Plus crée de la friction.
Comment nommer un framework personnalisé ?
Un acronyme le rend mémorable. Choisissez des lettres correspondant aux composants dans l'ordre. Test : un nouveau membre peut-il se souvenir de tous les composants rien qu'avec le nom ?
Comment versionner un framework ?
Stockez chaque version dans un fichier daté. Changements majeurs = version principale, raffinements = version mineure.
Peut-on combiner plusieurs frameworks ?
Oui, mais traitez le résultat comme un nouveau framework. Nommez-le, documentez-le et testez-le comme s'il était original.
Lectures complémentaires
Sources
Questions fréquemment posées
Quelle est la différence entre une technique de prompt et un framework de prompt?
Une technique est une instruction ou méthode unique (par exemple, "réfléchis étape par étape"). Un framework est une structure réutilisable avec 3+ composants qui définissent comment les prompts doivent être construits. Les frameworks sont répétables; les techniques sont ad hoc.
Quand devrais-je créer un framework personnalisé plutôt que d'utiliser CO-STAR, CRAFT ou RISEN?
Créez-en un lorsque vous appliquez régulièrement les mêmes 3+ modifications à un framework existant pour chaque prompt dans un workflow. Si vous ajoutez toujours une contrainte de politique, une terminologie de domaine et un schéma de sortie à CO-STAR, ceux-ci devraient devenir des composants de votre propre framework.
Un framework personnalisé peut-il fonctionner sur différents modèles d'IA?
Oui, s'il est correctement conçu. Évitez la syntaxe spécifique au modèle et construisez autour de composants universels (tâche, contraintes, format de sortie). Testez sur GPT-4o et Claude avant de finaliser. Si le framework nécessite une reformulation par modèle, simplifiez-le.
Combien de composants mon framework personnalisé devrait-il avoir?
Utilisez 3–6 composants. Moins de 3 est une technique, pas un framework. Plus de 6 crée des frictions et les rédacteurs sautent des sections. Si vous en avez besoin de plus, divisez-les en deux frameworks spécialisés pour différents types de tâches.
Comment tester si mon framework personnalisé fonctionne réellement?
Appliquez-le à 10 prompts représentatifs de votre workflow. Évaluez les sorties selon trois critères: (1) accomplissement de la tâche, (2) respect du format, (3) cohérence de qualité. Un framework efficace score 8/10 ou mieux sur tous les trois. Testez sur plusieurs modèles avec PromptQuorum.
Comment devrais-je nommer un framework personnalisé?
Utilisez un acronyme mappant vos composants dans l'ordre (comme REPAIR). Le test de l'acronyme: un nouveau membre de l'équipe peut-il se souvenir de tous les composants uniquement à partir du nom? Si non, simplifiez votre liste de composants.
Puis-je combiner des composants de CO-STAR, CRAFT et RISEN?
Oui, mais traitez cela comme un nouveau framework, pas un hybride. Nommez-le, documentez-le, testez-le et stockez-le dans le contrôle de version. Combiner sans formaliser crée juste un schéma ad hoc non documenté.
Comment je versionne un framework personnalisé?
Stockez chaque version dans un fichier daté (par exemple, repair-v1-2026-05.md) dans votre bibliothèque de prompts. Marquez les changements majeurs (composant ajouté/supprimé) comme versions majeures. Marquez les raffinements comme versions mineures. Documentez la raison de chaque changement.
Que dois-je documenter pour mon framework personnalisé?
Écrivez une spécification d'une page: (1) nom et objectif du framework, (2) définitions des 3–6 composants avec exemples, (3) un modèle à remplir, (4) 3 exemples de prompts complets annotés utilisant le framework. Conservez-le en contrôle de version.
Comment je fais en sorte que mon équipe utilise le framework personnalisé que j'ai créé?
Commencez avec une présentation de 30 minutes utilisant des exemples de tâches réelles. Testez ensemble sur 2–3 prompts. Créez une spécification d'une page partageable. Suivez les métriques de conformité et d'impact pour le premier mois. Itérez selon les commentaires.