Prompting Gemini Omni : la syntaxe de tags que Google documente et que personne ne cite
L'essentiel des conseils de prompting Omni publiés cette semaine est inventé.
Le « framework en cinq éléments issu de la documentation officielle de Google » que citent une demi-douzaine de guides ne figure sur aucune page Google que nous ayons pu trouver, et les guides qui le citent ne s'accordent même pas sur le fait qu'il y ait cinq ou six éléments. L'affirmation selon laquelle mettre les dialogues entre guillemets ferait basculer le modèle dans un mode lip-sync n'est dans aucun document Google non plus — les guillemets n'apparaissent dans les exemples de Google que pour du texte affiché à l'écran.
Ce que Google documente réellement est plus utile et presque personne ne l'a écrit : une syntaxe de tags qui permet à un seul prompt de s'adresser nommément à des images et des clips précis. C'est par là que commence ce guide.
Deux remarques sur ce qui suit
Tout ce qui est cité ici vient des pages de Google elles-mêmes — la section guide de prompt de la documentation de l'API Gemini Omni, et le guide de prompting commun qui couvre Omni et Veo ensemble. Là où Google est silencieux, nous le disons plutôt que de combler le vide avec quelque chose qui sonne autoritaire.
Les clips ci-dessous ont été générés avec Veo 3.1 Fast sur notre propre API, pas avec Omni. Gemini Omni 1.1 Flash n'est pas encore sur E2X, et nous n'allons pas illustrer un guide avec des images d'un modèle en prétendant qu'elles viennent d'un autre. Les techniques qu'ils démontrent — vocabulaire de caméra, l'instruction de plan unique, la direction sonore — viennent du guide de prompt que Google publie pour les deux modèles, donc elles se transfèrent. La syntaxe de tags de la section suivante, non : cette partie-là est propre à Omni, et nous la montrons comme syntaxe plutôt que comme résultat.
La syntaxe de tags
Omni accepte des tags en ligne qui pointent vers des entrées précises. C'est la partie de la documentation la moins couverte par les tiers et celle qui gagne le plus à être lue.
Pour les images :
<FIRST_FRAME> a woman is walking
<LAST_FRAME> marque l'image sur laquelle atterrir, et Google est explicite : elle « doit être utilisée avec » <FIRST_FRAME>. Quand un prompt devient assez compliqué pour que la position devienne ambiguë, il existe une forme de déclaration explicite :
[# Sources <FIRST_FRAME>@Image1 <LAST_FRAME>@Image2]
Pointez les deux tags vers la même image et vous obtenez une boucle. Google le documente directement — le clip revient à son point de départ :
[# Sources <FIRST_FRAME>@Image1 <LAST_FRAME>@Image1]
Pour les références, les tags sont numérotés et commencent à zéro :
in the style of <IMAGE_REF_0> a woman <IMAGE_REF_1> is walking
Cette seule ligne tire le style d'une image et le sujet d'une autre. L'équivalent vidéo est <VIDEO_REF_0>, également indexé à zéro, avec une limite ferme : « Video references support a maximum of 3 clips, up to 3 seconds each », et tout audio présent dans un clip de référence est ignoré.
Le mode d'échec ici, c'est que le modèle traite une référence comme une image d'ouverture littérale. Le correctif de Google est une instruction ajoutée au prompt :
Use the given image(s) as references for video generation.
The images should not be used as literal initial frames.
Une limite à connaître avant de concevoir autour : « Referencing or reasoning across multiple videos is not supported ». Plusieurs références image, aucun problème — l'exemple de Google lui-même en utilise six — mais le prompting multi-vidéo se dégrade.
Omni découpe votre clip en plusieurs plans si vous ne l'en empêchez pas
C'est la ligne la plus surprenante de la documentation, et elle explique beaucoup de résultats déroutants :
« Par défaut, Omni Flash essaiera de créer une vidéo avec quelques plans différents. Il tentera de construire un récit intéressant à partir du prompt. Si vous avez besoin que la vidéo de sortie contienne une scène unique, vous devez le demander explicitement dans le prompt »
Demandez huit secondes d'une personne qui franchit une porte et vous pouvez en obtenir trois plans montés. Le modèle ne vous lit pas mal. Il fait ce qu'il fait par défaut.
Le correctif tient en une proposition, et Google en donne trois formulations : « In a single unbroken scene », « In a single continuous shot », ou « No scene cuts ».
Voici cette instruction en action, avec un mouvement de caméra documenté et une ligne de son attachée :
In a single continuous shot, no scene cuts. Slow dolly in on a battered
enamel coffee pot sitting on a cast-iron stove in a dim cabin kitchen.
Steam rises and catches a hard shaft of morning light from a window to the
left. Medium shot, shallow depth of field, warm amber and deep green
palette. Sound design: the low hiss of steam and a wood fire ticking.
No dialogue.
Quatre secondes, 720p, généré avec Veo 3.1 Fast à un centime la seconde. Notez la faible part d'adjectifs dans ce prompt et la grande part d'instructions sur lesquelles le modèle peut agir.
Le son se dirige dans ses propres phrases
L'audio est généré avec l'image, et la consigne de Google est de le décrire séparément : « We recommend that you use separate sentences in your prompt to describe the audio ». La documentation le découpe en trois : effets sonores, ambiance, et dialogue — avec des exemples distincts pour chacun.
C'est sur le dialogue que le folklore se trompe. La convention documentée est un deux-points et pas de guillemets :
the man in the red hat says: Where is the rabbit?
L'exemple le plus long de Google fait parler deux personnages dans un même prompt et se termine sur l'ambiance :
A medium shot in a dimly lit interrogation room. The seasoned detective
says: Your story has holes. The nervous informant, sweating under a single
bare bulb, replies: I'm telling you everything I know. The only other
sounds are the slow, rhythmic ticking of a wall clock and the faint sound
of rain against the window
Les exemples propres à Omni préfixent l'audio hors parole par Sound design:, comme dans « Sound design: Gentle breeze, distant bird chirps. No dialogue. » Et quand vous voulez de la musique en particulier, dites-le — Google signale que c'est le cas le plus souvent oublié : « This is especially important if you want music in your video ».
Deux contraintes à intégrer dès la conception : l'édition de voix n'est pas prise en charge, et « Uploading audio references is unsupported in the current version of the API ». Vous dirigez le son avec des mots ou pas du tout.
Les timecodes fonctionnent, et ils se recalent quand vous étendez
Le minutage ne demande aucune syntaxe spéciale — « there is no precise syntax needed and you can use natural language », donc « At 5s the chorus starts in the background audio » est une instruction valide. Il existe aussi une forme de timecode entre crochets :
[0-3s] A person is walking
[3-6s] They stop and turn around
[6-10s] They start running
Maintenant le piège, et c'en est un vrai. Quand vous étendez un clip existant, 0s ne désigne plus le début de la vidéo. Il désigne le début de l'extension. Google l'écrit noir sur blanc :
« Si vous utilisez des timestamps ou une syntaxe de timecode, 0s désigne le début de la partie étendue de la vidéo. Si vous étendez une vidéo de 10 s, la coupe de scène de ce prompt se produira après 12 s »
Donc After 2s cut to a new scene tombe à la douzième seconde de la pièce finie. Quiconque construit un découpage sur des timecodes absolus se trompera une fois, puis plus jamais.
Tant qu'on y est : les prompts d'extension doivent décrire la continuation, pas redire toute la scène. Les formes suggérées par Google sont aussi courtes que « Extend this video » ou « The scene continues », avec des ajouts uniquement là où quelque chose change — « The music continues into the chorus » pour l'audio, « Show the same characters in the next scene » pour un raccord. L'extension ne fait qu'ajouter à la fin ; vous ne pouvez pas ajouter avant ni insérer au milieu.
L'édition veut moins de mots, pas plus
Tout ce qui précède récompense le détail. L'édition inverse la règle : « Simple prompts work best for video editing. Overly descriptive prompts can lead to unintended changes. »
Google publie ses propres paires avant-après, et elles méritent d'être lues comme un motif plutôt que comme deux exemples :
Avoid: In the video of the man sitting on the sofa, please add a small
black cat that runs from the right side of the screen, jumps onto
his lap, and then he starts to stroke its head while looking down.
Simplify: Add a cat that jumps onto his lap, he begins to pet it.
Keep everything else the same.
Avoid: Please remove the cell phone that the person is holding in their
hand and fill in the background so it looks like they are just
holding their hand empty.
Simplify: Make the phone invisible. Keep everything else the same.
La proposition qui fait le travail dans les deux cas est « Keep everything else the same », que Google recommande d'inclure chaque fois que vous modifiez un aspect d'un plan. Chaque détail supplémentaire que vous fournissez est une chose de plus que le modèle peut décider de régénérer.
L'image-to-video repart dans l'autre sens : « Vague prompts like 'make it move' produce less compelling results than detailed descriptions of the camera movement, subject motion, and environmental effects. » Du détail pour la génération, de la brièveté pour l'édition.
Les mots de caméra que Google nomme vraiment
Google publie une liste de vocabulaire, plus fiable que les termes qui circulent dans les fils d'astuces de prompt. Les mouvements qu'il nomme : static, pan, tilt, dolly in et out, truck left et right, pedestal up et down, zoom, crane, aerial ou drone, handheld, whip pan, arc. Les angles : eye-level, low, high, bird's-eye, worm's-eye, Dutch, close-up et extreme close-up, medium, full, wide ou establishing, over-the-shoulder, point-of-view. Les effets optiques : wide-angle, telephoto, shallow et deep depth of field, lens flare, rack focus, fisheye, et l'effet vertigo — le dolly zoom.
Google distingue aussi explicitement le zoom du dolly, parce que les modèles les confondent : un zoom change la focale, et « This is different from a dolly, as the camera itself doesn't move. »
Gardez toutefois la réserve que Google énonce deux fois : « Some advanced camera angles are not officially supported. The results and reliability may vary depending on the overall prompt and your specific use case. » Nommer un mouvement est une demande, pas une garantie.
Voici un plan en arc, l'un des mouvements documentés, prompté simplement :
Slow arc shot travelling left around a weathered brass sextant resting on
an unrolled nautical chart on a scuffed wooden table. Low winter sunlight
rakes in from the right and the brass catches moving highlights as the
camera travels. Single continuous shot, no scene cuts, shallow depth of
field. Sound design: faint harbour ambience, rigging tapping in wind.
No dialogue.
Les termes cinématographiques et de montage sont documentés eux aussi — match cut, jump cut, establishing shot sequence, montage, split diopter effect. Des termes que vous avez pu voir attribués à Google et qui ne sont sur aucune des deux pages : oner, push in, et natural smartphone zoom.
Prompts négatifs : deux pages Google se contredisent
Omni n'a pas de paramètre de prompt négatif. La documentation de l'API est catégorique : « System instructions, temperature, top_p, stop sequences, and negative prompts are not supported (you can put your negatives in the regular prompt: e.g., 'Do not do X'). »
Et le guide de prompt Omni recommande exactement ça, en suggérant « No dialogue », « No embellishments », « No extra sound effects ».
Le guide commun Omni-et-Veo de Google dit l'inverse sur la formulation :
« Non recommandé : employer un langage instructif ou des mots comme "no" ou "don't". Par exemple, évitez des prompts comme "no walls" ou "don't show walls". Recommandé : décrivez ce que vous ne voulez pas voir. Par exemple, "wall, frame" »
Nous n'allons pas prétendre trancher. L'explication la plus probable est que la seconde page décrit le champ negativePrompt dédié de Veo — que Omni n'a pas — tandis que la page Omni décrit les négations en prose, qui sont tout ce qu'Omni propose. C'est une inférence, pas quelque chose que Google énonce. En pratique : utilisez la formulation de la page Omni pour Omni, et si une négation est ignorée, essayez l'autre forme avant de conclure que le modèle en est incapable.
Une autre contradiction honnête, puisqu'elle touche à ce que vous pouvez promettre à un client. Le guide de prompt Omni dit que le modèle rend le texte à l'écran « in a way that is correct and readable ». La model card DeepMind range « rendering perfectly accurate text » parmi les choses qui « remain a challenge ». Les deux sont de Google. Testez avant de vous engager.
Une checklist réellement utilisable
À partir de ce qui précède, un prompt qui respecte le comportement du modèle porte en général :
- Une instruction sur le nombre de plans, parce que le multi-plan est le défaut et n'est probablement pas ce que vous voulez
- Le sujet et son mouvement, précisément — pas « make it move »
- Un mouvement de caméra documenté, nommé depuis la liste de Google
- La lumière : direction, qualité, couleur
- Une phrase séparée pour le son, préfixée
Sound design:s'il ne s'agit pas de dialogue - Le dialogue sous la forme
speaker says: line, deux-points, sans guillemets - Les négations en courtes propositions de prose à la fin
- Pour les éditions seulement : retirez l'essentiel de ce qui précède et ajoutez « Keep everything else the same »
Le résumé de structure de Google lui-même est plus long — sujet, action, scène, angle de caméra, mouvement de caméra, optique, style visuel, éléments temporels, audio, termes cinématographiques, négations — avec cette assurance : « You don't need to use all elements in every prompt ».
Où faire tourner tout ça aujourd'hui
Le prompting est une compétence qu'on acquiert en échouant à répétition, ce qui fait du prix par échec le chiffre qui compte le plus. Un test de quatre secondes sur Veo 3.1 Fast coûte quatre centimes. Le même test sur Gemini Omni 1.1 Flash, en ligne ici depuis le 28 août 2026 à neuf centimes la seconde, en coûte trente-six — ou environ douze si vous le brouillonnez d'abord en 360p, le palier que la 1.1 a ajouté exactement pour ça. Sur un après-midi passé à chercher où une instruction de caméra cesse d'être suivie, cet écart décide du nombre de fois où vous avez le droit de vous tromper.
Alors travaillez à bas coût la moitié transférable — nombre de plans, vocabulaire de caméra, direction sonore, négations — qui vient entièrement du guide que Google publie pour les deux modèles. Les deux clips ci-dessus ont été faits exactement comme ça. Montez vers la famille Omni quand vous avez besoin de ce qu'elle seule fait : la syntaxe de tags, l'extension, et la cohérence pilotée par référence. Une note sur les tags d'image auxquels ce guide consacre le plus de place : ils ont désormais leur propre endpoint, start-end-frame-to-video, qui prend les deux images comme des champs plutôt que comme des tags, et image-to-video fait de même pour une seule image d'ouverture. Veo 3.1 Fast couvrira encore en chemin l'entraînement à l'image-to-video et à la première et dernière image. Tarifs courants au 28 août 2026.
Nous avons traité ce qui est sorti dans la 1.1 et ce que disent réellement les classements à son sujet à part. Parcourez par job depuis text-to-video, ou lisez la spec lisible par machine si vous préférez comparer des paramètres plutôt que lire de la prose.
Les prix et les conditions produit peuvent changer. Vérifiez le tarif courant de chaque fournisseur avant toute décision d'achat.
Questions fréquentes
Comment écrire un prompt pour Gemini Omni 1.1 Flash ?
Nommez d'abord le nombre de plans, parce qu'Omni produit plusieurs plans par défaut et que vous en voulez généralement un seul. Décrivez ensuite le sujet et son mouvement, un mouvement de caméra nommé, et l'éclairage. Mettez l'audio dans sa propre phrase, préfixée « Sound design: » pour le hors-parole, et écrivez le dialogue sous la forme « speaker says: line » avec un deux-points et sans guillemets. Ajoutez les négations en courtes propositions à la fin.
Qu'est-ce que le tag FIRST_FRAME dans Gemini Omni ?
C'est un tag en ligne qui indique à Omni d'utiliser une image fournie comme image d'ouverture, écrit sous la forme du tag suivi de votre description. Son pendant LAST_FRAME marque l'image de fin et, selon la documentation de Google, doit être utilisé conjointement avec FIRST_FRAME. Pointer les deux tags vers la même image produit un clip en boucle.
Gemini Omni prend-il en charge les prompts négatifs ?
Pas en tant que paramètre. La documentation de l'API de Google indique que les prompts négatifs ne sont pas pris en charge et vous dit de placer vos négations dans le prompt ordinaire, du type « Do not do X ». Le guide de prompt Omni suggère de courtes propositions comme « No dialogue » ou « No extra sound effects ». Le guide commun Omni et Veo de Google déconseille cette formulation, ce qui semble décrire le champ de prompt négatif distinct de Veo plutôt qu'Omni.
Pourquoi Gemini Omni ajoute-t-il des coupes de scène que je n'ai pas demandées ?
Parce que le multi-plan est le comportement par défaut. La documentation de Google indique qu'Omni essaiera de créer une vidéo à plusieurs plans et de construire un récit à partir de votre prompt, sauf indication contraire. Ajouter « In a single continuous shot » ou « No scene cuts » au prompt est le correctif documenté.
Comment fonctionnent les timestamps quand on étend une vidéo Omni ?
Ils se recalent. Une fois que vous étendez un clip, 0s désigne le début de l'extension plutôt que le début de l'original. L'exemple de Google : étendre une vidéo de 10 secondes avec une instruction à 2s place ce moment à 12 secondes dans la pièce finie. L'extension ne fait qu'ajouter à la fin — vous ne pouvez ni ajouter avant ni éditer le milieu d'un clip.
Faut-il mettre les dialogues entre guillemets pour Gemini Omni ?
Non. La forme documentée par Google est « speaker says: line » — un deux-points, sans guillemets. L'affirmation largement reprise selon laquelle les guillemets déclencheraient un mode lip-sync n'apparaît dans aucune documentation Google. Les guillemets n'apparaissent dans les exemples de Google que pour du texte destiné à être affiché à l'écran, ce qui est probablement l'origine de la confusion.
Combien coûte l'entraînement au prompting Omni ?
Sur notre API, Gemini Omni 1.1 Flash tourne à $0.09 la seconde en 720p, donc un test de quatre secondes revient à $0.36, ou environ $0.12 si vous brouillonnez en 360p, au 28 août 2026. Veo 3.1 Fast est à $0.01 la seconde, ce qui ramène le même test à quatre centimes. Puisque les techniques de caméra, de nombre de plans et d'audio viennent du guide de prompt que Google publie pour les deux modèles, s'entraîner sur le moins cher coûte un neuvième et travaille les mêmes réflexes.