Prompt engineering Gemini : les techniques qui font la différence

L’écosystème Gemini repose sur une famille de modèles au comportement voisin mais aux réglages distincts. Gemini 3.6 Flash équipe l’app au quotidien, Gemini 3.7 Flash sert le code et les agents depuis le 13 août, Gemini 3.1 Pro reste disponible pour le raisonnement long, et Deep Think couvre les problèmes scientifiques. Un même prompt peut donc donner trois résultats selon le modèle, le niveau de raisonnement choisi et les instructions persistantes actives. Les techniques qui suivent viennent du guide de prompting officiel de Google pour la génération 3 et du retour d’usage de terrain.

Les System Instructions : votre prompt permanent

Gemini offre deux niveaux d’instructions persistantes. Elles changent le comportement du modèle avant même que vous écriviez quoi que ce soit.

Instructions générales, dans les paramètres de l’app

Dans les paramètres de l’app Gemini (Settings → Instructions personnalisées), vous définissez qui vous êtes, votre métier, vos préférences de ton et de format. Ces instructions s’appliquent ensuite à toutes vos conversations, sans avoir à les répéter.

L’erreur la plus courante consiste à y mettre trop de texte. Les instructions générales gagnent à tenir en moins de 500 mots. Au-delà, le modèle dilue en effet son attention et ignore les contraintes les moins saillantes.

Instructions de Gem, par tâche

Les Gems sont des assistants personnalisés avec leurs propres instructions, fichiers de référence et outils par défaut. Contrairement aux instructions générales, un Gem ne s’applique que quand vous l’ouvrez. Vous pouvez ainsi en créer autant que nécessaire : un pour la rédaction, un pour l’analyse financière, un pour le debug de code.

Google recommande de traiter les instructions d’un Gem comme un programme, pas comme une conversation. Le framework le plus efficace tient en cinq blocs : Rôle + Objectif + Contraintes + Exemples + Format de sortie. Le rôle définit l’expertise, l’objectif dit quoi faire, les contraintes donnent les règles métier. Les exemples montrent un ou deux cas concrets, pas davantage, sous peine de sur-apprentissage. Le format spécifie enfin la sortie attendue.

Un Gem complet, prêt à copier

# Gem — Analyste de rapports annuels

Rôle : Tu es un analyste financier senior spécialisé dans
les sociétés cotées européennes.

Objectif : Quand je te donne un rapport annuel (PDF ou texte),
produis une analyse structurée.

Contraintes métier : Je suis directeur financier d'un fonds
d'investissement mid-cap. J'ai besoin d'identifier les
risques non évidents et les incohérences entre le discours
du management et les chiffres.

Exemple de signal d'alerte attendu : "Le rapport mentionne
une croissance organique de 8%, mais le détail par segment
(p.47) montre que 6 points viennent d'un effet de change
favorable non récurrent."

Format de sortie :
1. Résumé exécutif (5 phrases max)
2. Tableau : CA, EBITDA, dette nette, FCF (3 derniers exercices)
3. 3 signaux d'alerte (avec numéro de page source)
4. 2 questions à poser au management
5. Verdict : acheter / conserver / éviter — avec justification

Contrainte finale : si une donnée n'est pas dans le document,
écris "[donnée absente]". Ne jamais inventer un chiffre.

Ce Gem transforme dès lors chaque upload de PDF en analyse structurée en quelques secondes. Vous n’écrivez plus un seul prompt : vous uploadez et vous lisez.

Le multimodal natif : penser au-delà du texte

Gemini accepte en entrée du texte, des images, de la vidéo et de l’audio dans le même prompt. Cette capacité change donc la façon de formuler une demande. La documentation officielle précise que chaque modalité doit être traitée comme une entrée de même niveau, et vos instructions doivent référencer explicitement chaque élément. Sur l’API, le paramètre media_resolution arbitre par ailleurs entre finesse d’analyse visuelle et consommation de tokens.

Images : extraire d’abord, interpréter ensuite

Quand vous envoyez une image à Gemini, demandez d’abord une extraction factuelle, puis une interprétation. La génération 3 est en effet optimisée pour des réponses directes. Sans cette étape, le modèle comble les zones d’ombre par des déductions non signalées, ce qui dégrade la précision.

# Prompt multimodal — analyse d'image en deux temps

[Image uploadée : capture d'écran d'un dashboard Google Analytics]

Étape 1 : Décris factuellement ce que tu vois dans cette
capture d'écran. Liste tous les chiffres, libellés, axes
et légendes visibles.

Étape 2 : À partir de cette description, identifie les
3 tendances les plus significatives et propose 2 actions
concrètes pour améliorer le trafic organique.

Vidéo : timestamps et questions ciblées

Gemini traite des vidéos longues, jusqu’à une heure sur les plans payants et davantage via l’API. En pratique, la clé consiste à ne pas demander « résume cette vidéo ». Posez plutôt des questions précises ou demandez une extraction par timestamp. « À quel moment le présentateur mentionne le changement de pricing ? Que dit-il exactement ? » donne un bien meilleur résultat qu’un résumé générique.

Audio et vocal : le prompt conversationnel

Gemini Live, le mode vocal, tourne sur un modèle speech-to-speech basse latence. Vous pouvez montrer un objet à votre caméra en parlant, le modèle intégrant les deux flux. Pour le prompt vocal, la règle est simple : soyez aussi spécifique à l’oral qu’à l’écrit. « Qu’est-ce que tu penses de ça ? » donne un résultat vague. « Est-ce que cette pièce semble être un composant original pour une Fender Stratocaster des années 60 ? » donne un résultat utile.

Les thinking levels : piloter la profondeur de raisonnement

C’est la nouveauté de prompt engineering la plus structurante. La génération 3 expose un paramètre thinking_level qui contrôle la profondeur de raisonnement avant la réponse. Il remplace désormais l’ancien thinking_budget des modèles 2.5, exprimé en tokens. Chaque niveau arbitre différemment latence, coût et qualité.

• Minimal — Équivaut à ne pas raisonner du tout sur la plupart des requêtes. Le modèle ne réfléchit un peu que sur les tâches de code complexes.
• Low — Minimise latence et coût. Pour le suivi d’instructions simples, le chat et les applications à haut débit.
• Medium — Équilibre standard, et niveau par défaut. Bon choix pour la revue de code, l’analyse de données courtes, la rédaction structurée.
• High — Profondeur maximale. Le premier token met sensiblement plus de temps à sortir, mais la réponse est bien mieux raisonnée. Pour le code complexe, la recherche, les problèmes multi-étapes.

Conséquence directe pour vos prompts. Si vous venez de Gemini 2.5, vous avez sans doute pris l’habitude de décomposer vos demandes en étapes (« d’abord fais A, ensuite B, puis C »). Cette décomposition n’est plus nécessaire, elle est même contre-productive. Utilisez thinking_level: high et laissez le modèle décomposer lui-même. Les techniques chain-of-thought explicites des générations 2.x deviennent dès lors de l’overkill.

Quel modèle traite votre prompt : le routing automatique

Quand vous utilisez l’app Gemini en mode automatique, le système décide quel modèle traite votre requête. Les tâches simples — traduction, résumé court, question factuelle — partent vers le modèle rapide. Les tâches complexes — analyse multi-étapes, raisonnement, code — mobilisent en revanche un modèle plus profond. Vous ne choisissez pas : le routing décide pour vous.

Ce point mérite attention, car un prompt court et simple a toutes les chances d’être traité au niveau le plus léger. Si vous avez besoin de plus de profondeur, deux options s’offrent à vous.

• Sélectionnez manuellement le modèle — dans l’app, le sélecteur reste sommaire. Pour un vrai contrôle (niveau de raisonnement, sortie structurée, version de modèle figée), passez par l’API dans Google AI Studio.
• Rendez votre prompt suffisamment complexe — en restant en automatique, structurez votre demande avec plusieurs contraintes explicites et un format de sortie détaillé. Le router interprète alors la complexité du prompt pour décider.

Les spécificités de la génération 3 documentées par Google

Le guide officiel révèle plusieurs comportements qui justifient d’ajuster vos habitudes. Les connaître évite d’ailleurs des frustrations inutiles.

Le modèle est moins bavard par défaut

Le modèle répond ainsi de façon directe, concise, quasi sèche, bien moins bavarde que les modèles 2.x. Si votre cas d’usage demande une réponse conversationnelle ou développée, vous devez le demander explicitement.

La formulation recommandée par Google tient en une phrase : « Explique cela comme un assistant amical et bavard. » Sans cette consigne, attendez-vous à des réponses courtes et sans prélude.

Les contraintes négatives sont fragiles

« Ne fais pas X » fonctionne moins bien que sur les générations précédentes. Google le documente : les contraintes négatives et les contraintes de format peuvent être ignorées si elles apparaissent trop tôt dans le prompt. La règle tient en une ligne : placez vos restrictions à la fin de votre instruction, pas au début.

# Mauvais — contrainte au début, souvent ignorée

Ne dépasse pas 200 mots. Résume ce rapport trimestriel
en identifiant les 3 points clés.

# Bon — contrainte à la fin, mieux respectée

Résume ce rapport trimestriel en identifiant les 3 points clés.
Contrainte stricte : ta réponse ne doit pas dépasser 200 mots.

Évitez les interdictions trop larges

« Ne déduis rien » ou « ne fais aucune supposition » paralyse le modèle. Il l’interprète littéralement et refuse ensuite de faire des calculs simples ou de synthétiser des évidences. Préférez une formulation positive : « Base tes réponses uniquement sur les données fournies. Si une information manque, indique-le explicitement. »

La température ne sert plus à rien — et personne ne vous préviendra

C’est le changement le plus important de l’été pour qui code. Sur les modèles 3.6 et 3.7 Flash, les paramètres temperature, top_p et top_k ne sont plus seulement déconseillés : ils sont dépréciés et purement ignorés. L’API les accepte, ne renvoie aucune erreur, et n’en tient aucun compte.

Le piège est réel. Un pipeline qui posait temperature=0 pour garantir des sorties déterministes continue de tourner, renvoie un code 200, et a perdu sa garantie sans que rien ne le signale. Pire, ces paramètres sont souvent enfouis dans une couche wrapper ou un fichier de configuration, loin de l’appel d’API : un simple grep ne les trouve pas tous. Si vous migrez du code, auditez vos configurations avant de constater la dérive en production.

Le persona colle très fort

Quand vous assignez un persona à Gemini, le modèle y adhère fortement. Google prévient qu’il peut ignorer certaines de vos instructions ultérieures si elles contredisent le persona défini. C’est un atout pour la cohérence, un piège pour sortir du rôle. Notez aussi que le persona et le format de sortie doivent figurer dans l’instruction système ou tout au début du prompt utilisateur.

# Persona strict — exemple officiel Google

Tu es un extracteur de données.
Tu as l'interdiction de clarifier, d'expliquer ou de
développer des termes. Renvoie uniquement les données
demandées au format spécifié.

Thought Signatures, côté API

Pour les développeurs qui appellent l’API sur plusieurs tours, la génération 3 utilise des Thought Signatures : des représentations chiffrées du raisonnement interne du modèle. Elles maintiennent ainsi le contexte de réflexion d’un appel à l’autre, ce qui améliore les tâches multi-étapes comme le debug itératif. En mode sans état, vous devez renvoyer ces signatures exactement telles que reçues pour que l’API les valide.

Structurer ses prompts pour la grande fenêtre de contexte

La fenêtre d’un million de tokens est un avantage technique, mais elle ne garantit pas une attention uniforme. Plus le contexte est long, plus les tokens pertinents risquent de se perdre parmi les autres. Google documente une règle claire pour contrer ce phénomène.

Données d’abord, question à la fin

C’est l’inverse de ce qu’on ferait instinctivement. Pour faire la transition entre le bloc de données et la question, ajoutez une phrase d’ancrage explicite du type « En te basant uniquement sur les informations ci-dessus… ».

Séparez instructions et données avec des balises

Ne mélangez jamais vos consignes avec le contenu à analyser. Utilisez plutôt des séparateurs explicites, les balises de type XML fonctionnant très bien ici. Une règle importante : ne mélangez pas XML et Markdown dans le même prompt, choisissez un format et tenez-vous-y.

# Structure avec séparateurs — données d'abord, question à la fin

<document>
[coller le contrat ici]
</document>

<instructions>
Tu es un juriste spécialisé en droit du travail français.
Analyse le document ci-dessus et identifie les clauses
qui pourraient être contestées devant les prud'hommes.
Pour chaque clause problématique, cite l'article du Code
du travail concerné.
</instructions>

<format_sortie>
Tableau : Clause | Page | Risque | Article du Code du travail
Suivi d'un paragraphe de recommandation par clause.
Contrainte finale : ne traite que les clauses effectivement
problématiques. Si le contrat est conforme, dis-le.
</format_sortie>

En te basant uniquement sur les informations ci-dessus,
produis l'analyse demandée.

Demandez une vérification de lecture

Avant de lancer l’analyse d’un document long, demandez à Gemini de résumer ce qu’il a compris en trois phrases. Si le résumé est correct, enchaînez avec votre vraie question. S’il est faux, le document n’a pas été bien ingéré : rechargez-le ou segmentez-le.

Prompts courts ou détaillés : la règle de la génération 3

C’est la différence la plus contre-intuitive pour qui vient des modèles précédents ou d’autres assistants. Sur Gemini 2.x, on s’est habitué à des prompts longs, pleins de garde-fous, avec une décomposition étape par étape. Cette approche est en revanche devenue contre-productive.

Google est explicite : la génération 3 extrait mieux une structure à partir d’un indice léger, tient une instruction en une seule phrase, et conserve les contraintes sur plusieurs tours. La règle pratique qui en découle tient en cinq points.

• Commencez par un prompt court — une phrase pour l’objectif, une phrase pour le format de sortie. Stop.
• Ajoutez des contraintes seulement si la sortie dérive — une par une, pas toutes d’un coup.
• Ne répétez pas les contraintes à chaque tour — le modèle les conserve mieux que ses prédécesseurs.
• Retirez les étapes explicites et utilisez thinking_level: high à la place.
• Retirez les règles JSON évidentes — « renvoie un JSON valide » suffit largement.

# Prompt Gemini 2.x (overkill sur la génération 3)

D'abord, lis le document en entier. Ensuite, identifie
les thèmes clés. Puis, extrais les citations pertinentes.
Enfin, synthétise le tout. Assure-toi de ne pas halluciner,
de ne pas inventer de citations, de rester factuel.
Renvoie un JSON valide avec des guillemets doubles,
sans virgules traînantes, avec les clés "themes" et "quotes".

# Prompt génération 3 équivalent (court, efficace)

Extrais les thèmes clés du document avec les citations
qui les appuient. Renvoie en JSON.

Le second prompt donne pourtant un meilleur résultat, avec moins de tokens consommés. Si la sortie n’est pas satisfaisante, ajoutez ensuite UNE contrainte à la fois et retestez.

Cinq prompts Gemini prêts à copier

Ces prompts exploitent les spécificités de Gemini : multimodal, grand contexte, Gems, thinking levels. Ils fonctionnent aussi bien dans l’app que via l’API.

Analyser un document ou une vidéo longue

# 1. Analyse vidéo avec timestamps

Regarde cette vidéo de formation interne (uploadée).
Pour chaque changement de sujet, note le timestamp
et résume le point clé en une phrase.
À la fin, identifie les 3 moments où le formateur dit
quelque chose qui contredit la documentation officielle
que je t'ai envoyée hier dans ce notebook.

# 2. Comparaison de 5 documents longs

Voici 5 contrats de fournisseurs (uploadés).
Construis un tableau comparatif avec ces colonnes :
- Durée d'engagement
- Clause de résiliation anticipée
- Pénalités de retard
- Plafond de responsabilité
- Exclusivité (oui/non)
Indique le numéro de page pour chaque donnée.
Si une clause est absente d'un contrat, écris "absent".

Automatiser une tâche qui revient chaque semaine

# 3. Gem pour la veille concurrentielle quotidienne

[À coller dans les instructions d'un Gem]
Tu es mon analyste concurrentiel.
Chaque matin, je te donne 2-3 URLs d'articles.
Pour chaque article, produis :
- Entreprise concernée
- Fait nouveau (1 phrase)
- Impact potentiel sur notre marché (1 phrase)
- Action recommandée : ignorer / surveiller / réagir
Format : tableau, pas de prose.

# 4. Recherche dans vos propres données (Notebook + Gem)

[Gem connecté à un Notebook contenant vos sources]
Dans mes sources, que disent les études publiées après 2024
sur l'effet du jeûne intermittent sur la masse musculaire
chez les plus de 50 ans ?
Cite chaque source avec son titre et la page.
Si les études se contredisent, présente les deux positions.

Déboguer en croisant une capture et un log

# 5. Debug multimodal

[Upload : capture d'écran d'une erreur + fichier de log]
Voici une capture d'écran de l'erreur et le fichier de log.
1. Lis l'erreur dans la capture.
2. Cherche cette erreur dans le fichier de log.
3. Identifie la ligne exacte qui a déclenché l'erreur.
4. Propose un correctif avec le code modifié.

Ce que vous devez retenir — et la suite

Le prompt engineering Gemini n’a rien d’un prompt engineering générique. Les règles clés tiennent en une liste courte : prompts courts par défaut, contraintes négatives à la fin, chain-of-thought remplacé par thinking_level, persona pris très au sérieux, données avant question sur les contextes longs, XML ou Markdown mais jamais les deux. Côté API, retirez temperature, top_p et top_k de vos configurations : ils ne font plus rien et ne vous le diront pas.

Deux réflexes à adopter tout de suite. Créez d’abord un Gem pour votre tâche la plus fréquente : le temps investi se rentabilise dès la troisième utilisation. Commencez ensuite toujours par un prompt court, en n’ajoutant des contraintes que si la sortie dérive. C’est l’inverse de l’intuition héritée des modèles précédents.