COCA : le framework de prompt engineering qui s'adapte à tout, ou presque

Quand on commence à s'intéresser sérieusement au prompt engineering, on tombe vite sur la même liste : RTF, CO-STAR, CRISPE, RACE, TAG, APE, ICIO... Chaque framework a sa logique, ses cas d'usage de prédilection, ses limites. Le problème, c'est qu'à force d'en accumuler, il faudrait presque en maîtriser une dizaine pour couvrir tous les contextes : un prompt de rédaction n'a pas les mêmes besoins qu'un prompt de code, de documentation ou de spécification.

C'est ce constat qui m'a conduit à modéliser COCA : Contexte, Objectif, Contraintes, Actions. Pas pour remplacer les frameworks existants par principe, mais parce qu'aucun d'entre eux ne tenait la route sur l'ensemble des situations où j'écris des prompts au quotidien : code, documentation, prompt de prompt, spécifications... Je m'en sers aujourd'hui presque partout.

Pourquoi un nouveau framework de prompt engineering ?

Quand j'ai commencé à structurer mes prompts, je me suis documenté sur les frameworks existants, avec l'idée de transmettre cette connaissance aux professionnels que je formais. Mais plus j'avançais, plus la même limite revenait : chaque framework couvrait bien un type de tâche, mais aucun ne fonctionnait de façon satisfaisante sur l'ensemble des contextes que je rencontrais réellement. Continuer sur cette voie aurait signifié en enseigner une dizaine, au risque de perdre les professionnels en cours de route plutôt que de les outiller.

C'est cette conviction qui a fait naître COCA : un framework à la fois logique dans son enchaînement et suffisamment polyvalent pour s'appliquer à un très grand nombre de contextes, sans perdre en rigueur.

La structure COCA en quatre blocs

COCA s'organise en quatre blocs, toujours dans le même ordre : Contexte, Objectif, Contraintes, puis Actions. Chacun a un rôle précis et un poids très différent dans le prompt final. Le bloc Contraintes est volontairement le plus dense : c'est lui qui absorbe l'essentiel du travail de cadrage, là où la plupart des autres frameworks le diluent dans le contexte ou la tâche, au risque de l'oublier.

Voici, bloc par bloc, ce que je mets dedans, illustré par un même exemple filé : cadrer la rédaction d'une spécification technique.

Contexte

Le contexte pose le cheminement de pensée : d'où vient la demande, quelle situation l'a déclenchée, quel problème on cherche à résoudre. C'est mécaniquement le bloc le plus long, parce qu'il doit concentrer toute l'information nécessaire pour que le modèle comprenne la situation sans avoir à deviner : plus le contexte est précis, moins le modèle comble les vides par des suppositions.

Objectif

L'objectif tient en une seule phrase, à l'infinitif, sans détail. Il cadre la finalité, pas la manière d'y arriver : le mot-clé initial ("Créer", "Produire", "Générer"...) suffit à orienter le modèle avant même qu'il ne lise les contraintes. C'est volontairement le bloc le plus court : y ajouter du détail reviendrait à dupliquer ce que le contexte et les contraintes précisent déjà.

Contraintes

C'est le bloc le plus dense, et c'est un choix délibéré. Il rassemble tout ce qui borde la réponse attendue : format de sortie, ton, longueur, éléments à inclure ou à exclure, standards à respecter, pièges à éviter. Plus les contraintes sont explicites, moins le modèle a de marge pour partir dans une direction plausible mais non désirée.

Actions

Les actions décrivent la suite logique du raisonnement à suivre : comment tenir compte des éléments fournis, quelles questions poser en cas d'ambiguïté, puis comment construire la réponse jusqu'à l'objectif. Elles sont systématiquement présentées en liste numérotée, jamais en prose. C'est ce qui rend le raisonnement du modèle vérifiable étape par étape.

Le gabarit que j'utilise systématiquement

Concrètement, tous mes prompts partent du même squelette :

Les actions sont systématiquement présentées sous forme de liste numérotée, jamais en prose. Quand j'ai besoin de sous-parties, je les introduis en gras suivi de deux-points, par exemple :

Ces mots-clés en majuscules (CONTEXTE, OBJECTIF, CONTRAINTES, ACTIONS) sont la seule exception à une règle que j'applique partout ailleurs : pas de majuscules en dehors des acronymes. Toutes mes phrases commencent par une majuscule et se terminent par un point, et l'ensemble du prompt est mis en forme en Markdown. Ce n'est pas un détail cosmétique : la cohérence typographique aide le modèle à repérer instantanément la structure du prompt, et elle m'aide moi à rester discipliné dans ma rédaction.

Pour vos équipes

Formation IA en entreprise

Des formations pratiques pour intégrer l'intelligence artificielle dans vos processus industriels et administratifs.

Découvrir les formations

COCA face aux frameworks de prompt engineering les plus utilisés

COCA

Structure : Contexte -> Objectif -> Contraintes -> Action

Cas d'usage principal : cadrer des tâches variées et souvent complexes (code, documentation, spécifications, prompt de prompt) où le contexte et les contraintes doivent être explicités pour éviter que le modèle ne comble les vides par des suppositions.

RTF (Role, Task, Format)

Structure : Rôle -> Tâche -> Format

Cas d'usage principal : des tâches courtes et à faible enjeu où l'on veut une réponse rapide, sans avoir besoin de cadrer un contexte ou des contraintes détaillées (reformuler un texte, générer une liste, une réponse simple).

CO-STAR

Structure : Context -> Objective -> Style -> Tone -> Audience -> Response

Cas d'usage principal : des contenus orientés communication où le ton, le style et l'audience ciblée pèsent autant que le fond (rédaction marketing, réseaux sociaux, communication externe).

CRISPE

Structure : Capacity/Role -> Insight -> Statement -> Personality -> Experiment

Cas d'usage principal : l'exploration créative et le brainstorming itératif, où l'angle et la personnalité donnés au modèle comptent autant que le résultat final.

RACE

Structure : Role -> Action -> Context -> Expectation

Cas d'usage principal : des tâches orientées action où l'on veut aller droit au but, le contexte venant ensuite préciser le cadre plutôt que l'ouvrir (proche de COCA mais avec un enchaînement inversé).

TAG

Structure : Task -> Action -> Goal

Cas d'usage principal : les prompts jetables, ponctuels et à faible enjeu, où la rapidité de rédaction prime sur la structure.

APE

Structure : Action -> Purpose -> Expectation

Cas d'usage principal : cadrer un livrable précis avec un objectif orienté résultat, sans nécessiter un contexte détaillé en amont.

ICIO

Structure : Instruction -> Context -> Input -> Output

Cas d'usage principal : les tâches de transformation texte vers texte (traduction, reformulation, résumé, extraction d'information) où l'entrée et la sortie doivent être clairement délimitées.

Ce qui distingue vraiment COCA

Trois éléments expliquent pourquoi ce framework fonctionne dans autant de contextes différents :

1. Le bloc Contraintes est autonome. La plupart des frameworks (RTF, RACE, TAG, APE) diluent les contraintes dans le contexte ou la tâche, ce qui les rend faciles à oublier. COCA force à les expliciter, et leur consacre mécaniquement la moitié du prompt.
2. L'ordre suit un cheminement cognitif naturel. On situe (contexte), on vise (objectif), on borne (contraintes), puis on déclenche (action). C'est proche de la façon dont on briefe un collaborateur.
3. Un bon compromis complétude/simplicité. Plus structuré que RTF, TAG ou APE, mais moins verbeux que CO-STAR.

Un framework qui s'utilise partout, ou presque

Ce qui me sert le plus au quotidien avec COCA, ce n'est pas tant sa rigueur que sa portabilité. Le même squelette me sert à cadrer une tâche de développement, à rédiger une documentation, à écrire un prompt de prompt, ou à poser des spécifications.

Je n'ai plus besoin de changer de grille de lecture selon le sujet, seul le contenu de chaque bloc change, jamais leur logique.