Prompts pour Gemini : ce que recommande Google, et les réglages que Gemini 4 n'écoute plus

La documentation de l'API Gemini comporte une page de stratégies de conception de prompts. Elle n'affiche pas de date, mais elle couvre les modèles récents. Google y présente ses conseils comme des points de départ à affiner par essais.

Les règles de rédaction

• Des exemples, toujours. Google recommande d'inclure systématiquement quelques exemples dans le prompt et estime qu'un prompt sans exemple a des chances d'être moins efficace. Deux réserves : trop d'exemples poussent le modèle à les imiter de trop près, et leur mise en forme doit être identique de l'un à l'autre (balises, espaces, retours à la ligne).
• Le contexte d'abord, la question à la fin. Avec un contexte volumineux, documents ou code, tout le contenu se place en premier et la consigne tout à la fin, introduite par une phrase de transition.
• Un seul style de délimiteur. Balises XML ou titres Markdown, mais pas les deux dans le même prompt.
• Être direct. Les modèles Gemini 3 répondent par défaut de façon brève. Un ton conversationnel ou une réponse détaillée se demandent explicitement.
• Utiliser les outils. La recherche Google intégrée sert pour les faits récents ou peu connus, l'exécution de code pour les calculs et les décomptes.

Pour Gemini 3 Flash, la page propose des clauses à ajouter aux instructions système : suivre la date du jour fournie, rappeler au modèle la limite de ses connaissances, et, pour un assistant documentaire, n'utiliser que le contexte transmis et dire quand l'information en est absente.

Température, top_p, top_k : des réglages en voie de disparition

C'est le point le plus concret pour les développeurs. Ces trois paramètres règlent le degré d'aléa dans le choix des mots. D'après la page :

• sur les premiers modèles Gemini 3, il faut les laisser à leur valeur par défaut, sous peine de dégrader le raisonnement ;
• Gemini 4 et Gemini 3.6 et suivants ignorent les valeurs personnalisées et renvoient un en-tête d'avertissement de dépréciation ;
• une version future répondra par une erreur 400.

Google ne donne pas de date pour ce passage à l'erreur. Une application qui envoie encore une température continue donc de fonctionner, sans que le réglage ait d'effet, jusqu'au jour où la requête sera refusée.

La page conserve par ailleurs un conseil hérité des modèles précédents : augmenter la température quand un filtre de sécurité renvoie une réponse de repli. Il ne peut plus s'appliquer aux modèles qui ignorent ce paramètre.

Un gabarit pour les agents

Pour les agents, qui enchaînent des appels d'outils, Google fournit un modèle d'instructions système en neuf principes. Les plus utiles à retenir :

• Évaluer le risque. Une lecture exploratoire est à faible risque, une modification d'état à risque élevé. S'il manque un paramètre facultatif pour une simple recherche, l'agent doit appeler l'outil plutôt que d'interroger l'utilisateur.
• Ne pas s'arrêter à la cause évidente. Tester plusieurs hypothèses et réviser le plan quand une observation les contredit.
• Persévérer avec discernement. Réessayer après une erreur passagère ; changer de méthode après une autre erreur, au lieu de répéter le même appel.

Les limites

La page ne mesure l'effet d'aucune de ces consignes. Le gabarit pour agents est long, et Google ne dit pas quels principes pèsent le plus. Plusieurs passages visent Gemini 3 sans préciser ce qui reste valable pour Gemini 4.

Notre lecture

Une action s'impose à toute entreprise qui appelle l'API Gemini, directement ou par un prestataire : rechercher temperature, top_p et top_k dans le code et dans les outils d'automatisation, puis les retirer avant qu'ils ne provoquent des erreurs. Si un comportement reposait sur une température basse, par exemple pour obtenir des réponses stables, il faut le retrouver autrement : consignes plus précises, exemples, sortie structurée.

Pour les agents, la distinction entre lecture et écriture est le principe à reprendre en priorité.