Prompts pour les modèles Command de Cohere : huit conseils du guide officiel

Cohere documente la façon d'écrire des prompts pour sa famille de modèles Command. Le guide s'applique aussi bien à l'interface de test en ligne qu'à l'API. Ses exemples de code utilisent le modèle command-a-plus-05-2026.

Les huit conseils

1. Des consignes en tête, des sections titrées. Les instructions se placent au début. Consignes, contexte et texte à traiter sont séparés par des titres explicites, précédés de ##, par exemple ## Instructions puis ## Input Text.

2. Du contexte. Indiquer de quoi parle le texte fourni, par exemple le sujet d'un article de presse, améliore le résultat.

3. Un exemple de sortie. Plutôt qu'une formule vague comme « utilisez des puces si nécessaire », le guide conseille de montrer le gabarit attendu : une ligne de résumé, puis trois puces.

4. Une sortie structurée. Demander un format précis et en donner un exemple. Le guide cite un JSON à deux champs, un résumé court et une liste d'événements.

5. Dire quoi faire. Une consigne négative isolée (« évitez d'extraire des phrases entières ») fonctionne moins bien qu'une consigne positive suivie de l'interdiction : reformuler le contenu, puis ne pas recopier les phrases du texte.

6. Une longueur explicite. Selon Cohere, les modèles Command A respectent bien les contraintes de longueur. Elles s'expriment en paragraphes, en phrases (« entre 3 et 5 ») ou en mots (« au moins 100 et pas plus de 200 »).

7. Amorcer la réponse. Écrire soi-même le début de la sortie oriente la suite. Pour obtenir une page HTML bien formée, l'exemple commence la réponse par les balises d'ouverture du document.

8. Découper la tâche. Une demande complexe devient une suite d'étapes numérotées. L'exemple : lire le texte, en extraire le paragraphe le plus important, puis la phrase la plus importante, la résumer en 30 à 50 mots et ne renvoyer que ce résumé.

Le point fort : les documents en paramètre

C'est la partie la plus propre à Cohere. Au lieu d'insérer les documents dans le prompt, le guide recommande de les transmettre par le paramètre documents de l'API, sous forme d'extraits de 100 à 400 mots organisés en paires clé-valeur.

Cohere en attend trois bénéfices :

• moins d'informations incorrectes ;
• des réponses plus directement utiles, sans préambule ;
• des citations précises, qui permettent de remonter à la source.

Les citations sont renvoyées dans un champ distinct de la réponse (response.message.citations). C'est à l'application de les insérer dans le texte et d'afficher la liste des documents d'origine.

Les limites et les points à vérifier

• Les bénéfices annoncés ne sont pas chiffrés. Ce sont des affirmations de l'éditeur.
• La page n'est pas datée et mêle les générations de modèles : elle indique que le JSON fonctionne particulièrement bien avec les modèles Command R, alors que ses exemples reposent sur un modèle Command A. Avant de s'appuyer sur un format, mieux vaut le tester sur le modèle réellement utilisé.
• Le découpage en extraits de 100 à 400 mots est à la charge du développeur, tout comme l'affichage des citations.
• Le conseil sur la longueur en nombre de mots contredit celui de Mistral, qui déconseille de faire compter un modèle. Les deux éditeurs parlent de leurs propres modèles : la règle n'est pas transposable sans essai.

Notre lecture

Les conseils 1 à 8 valent pour la plupart des modèles et ne coûtent rien à appliquer. Le paramètre documents mérite davantage d'attention pour une petite entreprise qui construit un assistant sur sa propre documentation : contrats types, fiches produits, procédures internes.

Une réponse accompagnée de citations se vérifie en quelques clics, ce qui change la confiance que les équipes peuvent lui accorder. Un essai sur une vingtaine de questions réelles, en contrôlant chaque citation à la main, suffit à décider si l'effort se justifie.