Frameworks de prompt : RTF, RODES, CO-STAR, CRISPE… lequel choisir ?

RTF, RODES, CO-STAR, CRISPE, CRAFT, RACE, RCT, CARTEL : il existe des dizaines de frameworks de prompt, et chaque formateur a son favori. La bonne nouvelle, c’est qu’ils reposent tous sur les mêmes ingrédients. La mauvaise, c’est qu’aucun n’est le meilleur pour toutes les tâches. Ce guide compare les principaux, dit ce que l’on sait de leur origine, montre lequel utiliser selon la situation et vous évite le piège classique : collectionner les acronymes au lieu d’en maîtriser un.

Cet article fait partie de notre série sur le prompt engineering. Il prolonge notre guide sur les règles d’un bon prompt : un framework n’est rien d’autre qu’une façon de ne pas oublier ces règles.

En bref

• Un framework de prompt est un aide-mémoire : une liste de rubriques à remplir (rôle, contexte, tâche, format, ton, audience, exemples) avant d’envoyer une demande à une IA.
• Tous recombinent les mêmes sept briques. La différence tient à celles que chacun met en avant.
• Aucun n’est le meilleur partout. Un framework court va vite sur une tâche simple, un framework riche évite les oublis sur une tâche complexe.
• Repères : RTF pour aller vite, CO-STAR quand le ton et le lecteur comptent, CRISPE pour comparer plusieurs pistes, RODES au quotidien, CARTEL pour une demande à enjeu.
• Deux frameworks seulement ont une origine documentée par leur auteur : CO-STAR (agence numérique de l’État de Singapour) et CRISPE (Matt Nigh, février 2023).
• Les éditeurs ne recommandent aucun acronyme. Google et Microsoft décrivent chacun quatre éléments, et précisent qu’ils ne sont pas tous obligatoires.

Pour ancrer une méthode commune dans vos équipes, découvrez notre parcours de formation à l’IA générative.

Un framework de prompt, c’est quoi

Posez la question « comment écrire un bon prompt » à dix personnes, vous obtiendrez dix réponses. Certains disent de faire court, d’autres d’ajouter du détail, d’autres encore de donner un rôle ou des exemples. Ils ont tous en partie raison, et c’est le problème : sans structure, la qualité d’un prompt dépend de l’inspiration du moment.

Un framework règle cela. C’est un gabarit qui découpe votre demande en rubriques, à la place d’un paragraphe écrit d’un seul jet. Pensez à une recette de cuisine : elle ne rend pas le plat meilleur par magie, elle vous évite d’oublier le sel. Un framework ne rend pas votre demande plus intelligente. Il vous empêche d’oublier l’essentiel et rend la demande reproductible d’une fois sur l’autre.

Cette nature d’aide-mémoire explique pourquoi les frameworks ne dépendent pas d’un outil. Ils organisent un texte, et ce texte peut être envoyé à ChatGPT, Claude, Gemini, Copilot ou Vibe. Ce qui change d’un assistant à l’autre, c’est la mise en forme qui lui convient le mieux, pas la liste des informations utiles.

Le tableau se lit en ligne. RTF tient en trois briques. CO-STAR en mobilise cinq, dont l’audience, que la plupart des autres laissent de côté. RODES, CRISPE et les quatre éléments de Microsoft ajoutent chacun une rubrique qui leur est propre : la vérification finale, les variantes, la source.

D’où viennent ces frameworks de prompt

On présente souvent ces méthodes comme des standards. La plupart n’ont ni auteur identifié ni texte de référence. Voici ce que nous avons pu établir à partir de sources de première main.

Deux précisions utiles.

Microsoft ne parle pas de « GCSE ». Sa page d’aide liste quatre éléments (goal, context, expectations, source) sans leur donner de sigle. L’acronyme GCSE, que l’on trouve dans de nombreux guides et dans la première version de cet article, est un raccourci d’utilisateurs. Il met d’ailleurs les lettres dans un ordre que Microsoft n’emploie pas.

CRISPE ne vient pas d’OpenAI. On le lit parfois. Le dépôt d’origine nomme son auteur, qui dit avoir créé la méthode pour son propre usage. Nous détaillons cette histoire dans notre article sur la méthode CRISPE.

Cette absence de source pour la moitié des frameworks n’enlève rien à leur utilité. Elle invite à les prendre pour ce qu’ils sont : des conventions pratiques, pas des normes. Vous pouvez les adapter sans trahir personne.

Aucun framework de prompt n’est le meilleur partout

C’est le point le plus utile de cet article, et celui que les classements passent sous silence. Nous ne connaissons aucune étude publiée qui compare ces frameworks entre eux de façon rigoureuse. Méfiez-vous donc des pourcentages de gain attribués à l’un ou à l’autre : ceux que nous avons cherché à vérifier n’avaient pas de source.

La logique, elle, se comprend sans chiffres. Un framework court comme RTF va droit au but et suffit pour une tâche cadrée, mais il n’a pas de rubrique pour le ton, le lecteur ou les exemples. Un framework riche comme CO-STAR ou CARTEL évite les oublis sur une production où plusieurs dimensions comptent, au prix d’un temps de rédaction qui devient superflu sur une tâche banale.

Les éditeurs vont dans le même sens. Le guide de prompts de Google pour Workspace retient quatre éléments (persona, tâche, contexte, format) et précise qu’il n’est pas nécessaire de les employer tous à chaque fois. Microsoft écrit que seul un objectif clair est indispensable. Le bon réflexe consiste donc à faire correspondre le framework au type de tâche et à l’enjeu.

Les frameworks courts : pour aller vite

Deux frameworks tiennent en trois rubriques et s’écrivent en moins d’une minute.

RTF signifie Rôle, Tâche, Format. Vous dites à l’IA quel rôle tenir, ce qu’elle doit faire et sous quelle forme rendre le résultat. C’est le gabarit le plus rapide, adapté à une instruction directe ou à des tâches en série : dix descriptions de produit, cinq publications, une liste d’objets de courriel.

RCT signifie Rôle, Contexte, Tâche. Même esprit, avec le contexte à la place du format. Ludovic Salenne, qui le présente, le réserve aux demandes du quotidien. On le préfère quand la situation compte plus que la mise en forme.

Ces deux gabarits partagent une limite : dès qu’une demande exige un ton précis, des exemples ou des garde-fous, il faut leur ajouter des lignes. Ils gagnent en vitesse ce qu’ils perdent en finesse.

Les frameworks tout-terrain : l’usage quotidien

Un cran au-dessus, plusieurs frameworks à quatre ou cinq rubriques couvrent la majorité des usages professionnels sans être lourds.

RODES signifie Rôle, Objectif, Détails, Exemples, Sense check. C’est le framework que nous utilisons en formation pour les contenus détaillés. Son intérêt tient à deux rubriques que les gabarits courts n’ont pas : les exemples, qui cadrent le style mieux que dix adjectifs, et le sense check, une consigne de vérification finale. Le détail est dans notre article sur la méthode RODES.

CRAFT signifie Contexte, Rôle, Action, Format, Ton. Il équilibre les dimensions sans excès, ce qui en fait un gabarit par défaut fréquent.

RACE signifie Rôle, Action, Contexte, Exemple. Sa structure simple se prête aux modèles de prompts qu’une équipe réutilise.

Les frameworks spécialisés : quand une dimension prime

Certains frameworks poussent une dimension particulière au premier plan.

CO-STAR signifie Contexte, Objectif, Style, Ton, Audience, Réponse. Il vient de GovTech, l’agence numérique de l’État de Singapour, qui l’utilise pour ses propres agents. Sa particularité est de donner une rubrique à l’audience et de séparer le style du ton. On le choisit pour un contenu où le lecteur et la voix comptent : communication, marketing, contenu de marque. Voir notre article sur la méthode CO-STAR.

CRISPE signifie Capacity and Role, Insight, Statement, Personality, Experiment, soit Capacité et Rôle, Insight, Statement, Personnalité, Expérimentation. Vous définissez le rôle de l’IA, vous donnez le contexte, vous formulez la demande, vous fixez le style, et vous demandez plusieurs variantes. C’est cette dernière rubrique qui le distingue : CRISPE sert quand vous voulez comparer plusieurs pistes plutôt que recevoir une réponse unique.

Les quatre éléments de Microsoft sont l’objectif, le contexte, les attentes et la source. La source fait la différence : elle désigne les fichiers, les courriels ou les réunions sur lesquels Copilot doit s’appuyer. C’est le cadre à suivre dans Microsoft 365, puisqu’il vient de l’éditeur.

Voici ces frameworks côte à côte.

Le même besoin dans trois frameworks

Rien ne montre mieux les différences qu’un même besoin écrit trois fois. Prenons une relance commerciale : un client du BTP n’a pas répondu à une proposition de formation au management envoyée il y a dix jours.

Avec RTF, la demande tient en trois lignes :

text

Rôle : tu es chargé de clientèle dans un organisme de formation.
Tâche : rédige un courriel de relance à un client qui n'a pas répondu
à notre proposition de formation au management, envoyée il y a dix jours.
Format : moins de 120 mots, un objet, une question ouverte à la fin.

Avec CO-STAR, le lecteur et la voix prennent leur place :

text

Contexte : PME du BTP de 40 salariés. Proposition de formation
au management envoyée il y a dix jours, sans réponse.
Objectif : obtenir un échange téléphonique de quinze minutes.
Style : direct, phrases courtes, sans jargon de la formation.
Ton : courtois, sans insistance.
Audience : le dirigeant, peu disponible, qui lit ses courriels
sur son téléphone entre deux chantiers.
Réponse : un objet et un corps de moins de 120 mots.

Avec RODES, un exemple et une vérification s’ajoutent :

text

Rôle : tu es chargé de clientèle dans un organisme de formation.
Objectif : rédige un courriel de relance pour obtenir un échange
téléphonique.
Détails : PME du BTP, proposition de formation au management
envoyée il y a dix jours, dirigeant peu disponible.
Exemples : voici un courriel que nous avons envoyé et dont le ton
nous convient : [coller l'exemple].
Sense check : avant de répondre, vérifie que le courriel fait moins
de 120 mots et se termine par une question ouverte.

Le premier prompt s’écrit en trente secondes et donne un courriel correct. Le deuxième produit un texte mieux ajusté au lecteur. Le troisième se rapproche de votre façon d’écrire, grâce à l’exemple. Pour une seule relance, RTF suffit. Si vous préparez un modèle que cinq commerciaux réutiliseront, le temps passé sur CO-STAR ou RODES se rembourse.

Comment choisir son framework de prompt

Plutôt que de mémoriser neuf gabarits, partez de votre tâche.

Le principe est économique. Un framework doit vous faire gagner du temps net. S’il vous faut plus de temps pour remplir ses rubriques que pour réaliser la tâche, il est surdimensionné : revenez à un gabarit plus court. À l’inverse, si vous multipliez les allers-retours pour préciser ce que vous vouliez, votre gabarit est trop maigre : ajoutez-lui une rubrique.

Deux signaux aident à trancher. Si la réponse manque de justesse sur le ton, il vous manque l’audience : passez à CO-STAR ou à CARTEL. Si elle manque de ressemblance avec vos écrits, il vous manque un exemple : passez à RODES, RACE ou CARTEL.

À ne pas confondre avec un agent IA : un framework structure une demande à laquelle un assistant répond, et que vous relisez. Un agent IA reçoit un objectif et enchaîne des actions dans vos outils. Les consignes qu’on lui écrit obéissent à d’autres règles, avec des permissions et des points de contrôle. Ce sujet relève de notre formation aux agents IA.

Bien remplir un framework : quatre erreurs courantes

Choisir le bon gabarit ne suffit pas. Un framework mal rempli donne une réponse aussi vague qu’une demande sans structure. Voici les quatre erreurs que nous voyons le plus souvent en formation.

Des rubriques remplies de généralités. « Contexte : entreprise de services » ne dit rien à l’assistant. Une rubrique utile contient une information qu’il ne peut pas deviner : la taille de l’entreprise, ce qui s’est passé avant, ce que le lecteur sait déjà. Si vous pouvez supprimer une ligne sans changer la réponse, elle était décorative.

Un rôle chargé de tout faire. « Tu es un expert mondial du marketing » ne remplace ni le contexte ni la tâche. Le rôle oriente le vocabulaire et l’angle. Écrivez-le en une ligne et consacrez votre temps aux autres rubriques.

Des exemples décrits plutôt que montrés. « Un ton chaleureux et professionnel » laisse une large marge d’interprétation. Trois lignes d’un courriel que vous avez réellement envoyé en disent plus. Quand un framework prévoit une rubrique d’exemples, collez un vrai texte. La technique est détaillée dans notre guide du few-shot prompting.

Deux tâches dans le même prompt. Un framework structure une demande, pas deux. Google le recommande dans ses conseils de rédaction : découper une tâche complexe en prompts séparés. Si votre rubrique Tâche contient « et » trois fois, écrivez plusieurs prompts.

Un dernier repère : gardez vos prompts réussis. Un gabarit rempli qui a donné un bon résultat devient un modèle pour la fois suivante, et c’est ainsi qu’une équipe se constitue sa bibliothèque.

L’approche Proactive Academy : RODES et CARTEL

Dans nos formations, nous n’imposons pas un catalogue de frameworks à retenir. Nous en enseignons deux, complémentaires.

RODES est le gabarit du quotidien. Ses cinq rubriques structurent la plupart des demandes professionnelles, et son sense check installe le réflexe de vérification. L’exemple de la section précédente montre sa logique : chaque rubrique ferme une source d’imprécision, et la dernière transforme la relecture en consigne intégrée au prompt.

CARTEL est le gabarit des demandes à enjeu. Il signifie Contexte, Audience, Rôle, Tâche, Exemples, Livrable. Proposé par le formateur Ludovic Salenne, il ajoute à RODES deux rubriques qui comptent quand le résultat sera diffusé : l’audience, c’est-à-dire le lecteur final, et le livrable, c’est-à-dire la forme exacte attendue. Nous l’utilisons pour les prompts qu’une équipe doit pouvoir reprendre telle quelle. Son fonctionnement est détaillé dans notre article sur la méthode CARTEL.

La première version de cet article décrivait CARTEL comme une grille de relecture en six éléments différents (contexte, action, rôle, ton, exemples, limites). Cette description était inexacte : nous l’avons corrigée.

L’idée n’est pas de choisir entre les deux, mais de les articuler : RODES pour écrire vite et bien au quotidien, CARTEL quand le prompt doit être partagé ou que le résultat part chez un client.

Notre atelier pour construire les gabarits de prompts de votre équipe s’appuie sur ces deux méthodes.

Les frameworks de prompt sont-ils encore utiles ?

Une objection revient souvent : les modèles récents comprennent si bien le langage courant qu’une demande formulée simplement suffirait. C’est vrai en partie. Les formules magiques d’hier ne servent plus à grand-chose, et un assistant récent pardonne beaucoup d’imprécisions sur une tâche courante.

Il faut aussi relativiser une rubrique présente dans presque tous les frameworks : le rôle. Une étude publiée sur arXiv a testé 162 rôles sur 2 410 questions factuelles : ajouter un rôle n’améliore pas les résultats. Un rapport de la Wharton School, en décembre 2025, conclut de même pour les rôles d’expert. Le rôle règle le vocabulaire, le ton et l’angle ; il ne rend pas la réponse plus exacte. Nous développons ce point dans notre article sur le role prompting.

Deux situations gardent pourtant aux frameworks toute leur utilité. La première est la tâche complexe ou à enjeu, où oublier une information (le format, le lecteur, une contrainte) coûte un aller-retour ou une erreur. Anthropic le résume dans son guide de bonnes pratiques : il faut voir l’assistant comme un employé brillant mais nouveau, qui ignore vos usages. La seconde est le travail en équipe, où un gabarit partagé donne à chacun une qualité comparable et rend la demande transmissible.

Le framework a donc changé de fonction. Il compensait les faiblesses des premiers modèles ; il organise aujourd’hui l’information que l’assistant ne peut pas deviner.

L’erreur à éviter : collectionner les frameworks

La tentation, face à cette abondance, est d’en apprendre le plus possible. C’est une fausse bonne idée. La valeur d’un framework vient de l’automatisme qu’il installe. Un gabarit que vous appliquez sans réfléchir vaut mieux que dix que vous consultez à chaque fois.

La bonne stratégie est l’inverse de la collection. Repérez votre tâche la plus fréquente, choisissez le framework qui lui correspond et pratiquez-le jusqu’à ce qu’il devienne un réflexe. Ajoutez-en un second seulement si un type de tâche récurrent le justifie : CO-STAR si vous produisez beaucoup de contenu, les quatre éléments de Microsoft si vous travaillez dans Copilot.

Deux prolongements, si vous hésitez encore. Vous pouvez demander à l’IA de reformuler votre demande selon un framework donné : c’est le principe du méta-prompting, que nous expliquons dans notre guide pour faire écrire ses prompts par l’IA. Et pour savoir si un framework donne de meilleurs résultats qu’un autre sur vos propres cas, comparez-les avec la méthode d’évaluation et d’A/B test de prompts. C’est la seule comparaison qui vaille pour vous.

FAQ : frameworks de prompt

Framework de prompt : ce qu’il faut retenir

Les frameworks de prompt sont des recettes qui vous évitent d’oublier les ingrédients d’une bonne demande. Ils recombinent tous les mêmes briques, la plupart n’ont pas d’auteur connu, et aucun n’est le meilleur partout. Votre travail consiste à faire correspondre le gabarit à la tâche : court pour aller vite, riche quand plusieurs dimensions comptent, spécialisé quand le ton, le lecteur ou vos fichiers priment. Nous retenons deux repères, RODES au quotidien et CARTEL pour les demandes à enjeu. Et s’il ne fallait garder qu’une idée : maîtrisez-en un vraiment, plutôt que dix à moitié.

Pour installer une méthode commune de prompt dans vos équipes, adaptée à vos métiers et à vos outils, découvrez notre formation au prompt engineering en entreprise.