Tutoriel d’édition en plusieurs tours de Nano Banana 2.1 : les 3 éléments à renvoyer pour modifier une image en 2 tours successifs sans perdre de détails

Note de l’auteur : à partir d’un exemple complet — remplacer la couronne par un chapeau rouge, puis le cœur rose par un cœur bleu —, découvrez quelles informations renvoyer à chaque tour d’édition avec Nano Banana 2.1 : l’historique de conversation, l’image du tour précédent et la signature de pensée. Vous pourrez ainsi modifier une zone sans perdre les résultats des étapes précédentes.

Beaucoup de développeurs rencontrent le même problème lors de leurs premiers essais avec gemini-nano-banana-2.1 : le résultat de la première modification est très bon, mais lorsqu’ils veulent ajuster un petit détail au deuxième tour, la modification précédente est « effacée » ou le style de toute l’image est recréé. Cet article explique comment renvoyer correctement les données pour l’édition en plusieurs tours avec Nano Banana 2.1, afin de réaliser deux retouches successives sans perdre de détails.

Il ne s’agit pas d’un autre article théorique, mais d’un exemple reproductible : au premier tour, remplacer la couronne du personnage par un chapeau rouge ; au deuxième, changer uniquement le cœur rose en cœur bleu, tout en conservant le chapeau rouge. Nous vous fournirons le code complet des deux requêtes et préciserons les données à inclure à chaque tour.

L’essentiel : à la fin de cet article, vous comprendrez le fonctionnement de l’édition en plusieurs tours avec Nano Banana 2.1, saurez quels sont les trois éléments à renvoyer à chaque requête et pourrez reprendre directement le code pour effectuer des retouches locales successives.

Points clés de l’édition en plusieurs tours avec Nano Banana 2.1

Commençons par préciser le concept. L’édition dite « native en plusieurs tours » de Nano Banana 2.1 est plus exactement une édition « continue » : chaque tour correspond à une requête API indépendante. Si le modèle semble « se souvenir » des modifications précédentes, c’est parce que vous lui renvoyez l’intégralité du contexte dans la requête, et non parce que le serveur conserve la session à votre place.

Pourquoi l’édition en plusieurs tours avec Nano Banana 2.1 fait-elle « perdre des détails » ?

L’erreur la plus courante consiste à envoyer, au deuxième tour, une simple instruction comme « Remplace le cœur rose par un cœur bleu », accompagnée de l’image d’origine. Le modèle voit alors toujours l’image avec la couronne et la conserve naturellement : le bonnet rouge du premier tour disparaît. Une autre erreur consiste à joindre uniquement l’image produite au premier tour, sans l’historique. Le modèle dispose alors bien de la version avec le bonnet rouge, mais ne sait pas que celui-ci vient d’être modifié volontairement et qu’il doit être conservé. Il risque donc de changer au passage sa couleur ou sa forme au deuxième tour.

La méthode la plus fiable consiste à renvoyer l’interaction complète du premier tour comme historique de conversation : ce que l’utilisateur a demandé, l’image renvoyée par le modèle et la signature associée à sa réponse. La documentation officielle de Google décrit également les scénarios d’édition d’images en plusieurs tours de cette façon : grâce à la signature présente dans l’historique, le modèle prolonge le contexte de raisonnement et ne modifie que la zone indiquée.

Structure des requêtes pour l’édition en plusieurs tours avec Nano Banana 2.1

Le champ contents de la deuxième requête est un tableau organisé dans l’ordre chronologique. Il comprend au minimum trois éléments : le message user du premier tour (image d’origine et instruction), la réponse model du premier tour (image produite et signature), puis la nouvelle instruction user du deuxième tour. L’essentiel est de « rejouer » telle quelle la partie correspondant à la réponse model. Si vous en extrayez uniquement l’image en base64 pour la reconstituer, le champ de signature risque facilement d’être perdu lors de la conversion.

Prise en main rapide de l’édition multi-tour avec Nano Banana 2.1

Dans cet exemple, nous appelons directement l’API au format generateContent natif de Gemini avec Python et la bibliothèque requests. Nous n’utilisons pas le format de chat compatible avec OpenAI, car l’édition multi-tour nécessite de renvoyer la signature de pensée et les éléments image. Le format natif permet de préserver au mieux leur structure d’origine.

Liste des éléments à préparer

Exemple minimal : au premier tour, remplacer la couronne par un chapeau rouge

Le premier tour est une requête classique de retouche d’image : un message user contenant l’image d’origine et une instruction. Le point essentiel est de conserver intégralement le contenu renvoyé par le modèle, car il sera nécessaire au tour suivant.

import base64, requests

BASE_URL = "https://api.apiyi.com/v1"  # Interface unifiée d’APIYI ; consultez la documentation pour connaître le chemin au format natif
API_KEY = "YOUR_API_KEY"
MODEL = "gemini-nano-banana-2.1"
URL = f"{BASE_URL}/models/{MODEL}:generateContent"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}

img_b64 = base64.b64encode(open("origin.png", "rb").read()).decode()
user1 = {"role": "user", "parts": [
    {"inline_data": {"mime_type": "image/png", "data": img_b64}},
    {"text": "把角色头上的皇冠换成一顶红色的帽子，其他内容保持不变。"}]}

resp = requests.post(URL, headers=HEADERS, json={
    "contents": [user1],
    "generationConfig": {"responseModalities": ["TEXT", "IMAGE"]}}).json()
model1 = resp["candidates"][0]["content"]  # Conserver tel quel, y compris l’image et thoughtSignature

Le point le plus important est la dernière ligne : model1 récupère directement l’objet complet candidates[0].content, et pas seulement les données de l’image. Les parts de cet objet peuvent contenir du texte, une image et un champ thoughtSignature. En le conservant tel quel, vous ne risquez d’omettre aucun élément.

Exemple complet : au 2e tour, passez uniquement le cœur rose au bleu et gardez le chapeau rouge

L’essentiel au deuxième tour consiste à assembler contents ainsi : [user1, model1, user2]. Le code complet ci-dessous comprend les deux appels, la vérification de la signature et l’enregistrement des images. Vous pouvez l’exécuter directement.

import base64
import requests

BASE_URL = "https://api.apiyi.com/v1"  # Appel via APIYI ; pour le chemin au format natif, consultez docs.apiyi.com
API_KEY = "YOUR_API_KEY"
MODEL = "gemini-nano-banana-2.1"
URL = f"{BASE_URL}/models/{MODEL}:generateContent"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}
GEN_CONFIG = {"responseModalities": ["TEXT", "IMAGE"]}


def call(contents):
    """Envoie une requête generateContent et renvoie l’objet content complet de la réponse du modèle."""
    r = requests.post(URL, headers=HEADERS,
                      json={"contents": contents, "generationConfig": GEN_CONFIG},
                      timeout=180)
    r.raise_for_status()
    return r.json()["candidates"][0]["content"]


def save_image(content, path):
    """Extrait l’image de la réponse du modèle et l’enregistre."""
    for part in content.get("parts", []):
        data = part.get("inlineData") or part.get("inline_data")
        if data:
            open(path, "wb").write(base64.b64decode(data["data"]))
            return True
    return False


def has_signature(content):
    """Vérifie si la réponse contient une signature de pensée."""
    return any("thoughtSignature" in p or "thought_signature" in p
               for p in content.get("parts", []))


# ---------- 1er tour : remplacer la couronne par un chapeau rouge ----------
img_b64 = base64.b64encode(open("origin.png", "rb").read()).decode()
user1 = {"role": "user", "parts": [
    {"inline_data": {"mime_type": "image/png", "data": img_b64}},
    {"text": "Remplace la couronne sur la tête du personnage par un chapeau rouge. Ne change rien d’autre."}]}

model1 = call([user1])
save_image(model1, "round1_red_hat.png")
print("Signature présente au 1er tour :", has_signature(model1))

# ---------- 2e tour : passer le cœur rose au bleu et garder le chapeau rouge ----------
user2 = {"role": "user", "parts": [
    {"text": "À partir de l’image précédente, change uniquement la couleur du cœur rose sur la poitrine pour le rendre bleu."
             " Garde le chapeau rouge et tous les autres détails à l’identique."}]}

# Important : l’historique complet et model1 renvoyé tel quel (avec l’image et la signature du tour précédent)
history = [user1, model1, user2]
model2 = call(history)
save_image(model2, "round2_blue_heart.png")
print("Signature présente au 2e tour :", has_signature(model2))

# Pour un 3e tour, continuez en ajoutant : history += [model2, user3]

🚀 Pour commencer rapidement : nous vous conseillons d’exécuter ces deux appels sur APIYI, apiyi.com, avec le quota d’essai gratuit. Vérifiez que le chapeau rouge est toujours présent sur l’image du deuxième tour et que seul le cœur a changé de couleur, puis intégrez le code à votre propre processus.

Conseils pour formuler la consigne du deuxième tour

Pour que les modifications successives restent « ciblées », la structure renvoyée n’est pas le seul facteur : la formulation de la consigne compte aussi. Dans la consigne du deuxième tour, précisez trois choses : sur quelle image effectuer la modification, quelle partie modifier et quels éléments doivent rester inchangés. Par exemple, « À partir de l’image précédente, remplace uniquement le cœur rose par un cœur bleu, et conserve le chapeau rouge ainsi que tous les autres détails » donnera un résultat bien plus stable qu’un simple « Passe-le en bleu ».

Évitez aussi de joindre à nouveau l’image d’origine au deuxième tour. Elle se trouve déjà dans user1. Si vous la renvoyez dans user2, le modèle risque de la prendre pour une nouvelle image de référence et de revenir à la version avec la couronne.

Comparaison de trois méthodes de transmission pour l’édition en plusieurs tours avec Nano Banana 2.1

Pour comprendre pourquoi les « trois éléments doivent être présents », comparons trois méthodes courantes. Le tableau ci-dessous décrit qualitativement le comportement de chacune afin de vous aider à identifier rapidement celle utilisée dans votre code.

Analyse comparative

Méthode A — analyse : son principal avantage est sa simplicité de mise en œuvre : chaque tour est une requête indépendante. Mais le modèle ne voit pas le résultat du premier tour ; il reprend donc l’édition à zéro, comme s’il s’agissait d’une nouvelle requête à un seul tour. À l’inverse, le renvoi de l’historique complet permet au modèle de poursuivre les modifications à partir du résultat du premier tour.

Méthode B — analyse : cette méthode réduit la taille de la requête, puisqu’elle ne transmet qu’une seule image. Mais le modèle ne sait pas que le « chapeau rouge a été ajouté intentionnellement » et ne reçoit pas la signature ; la cohérence locale n’est donc pas garantie. Pour les maquettes à retoucher en plusieurs étapes, les images principales de produits de commerce en ligne et les cas similaires, la méthode C reste le choix le plus fiable.

💡 Conseil : si votre application doit enchaîner plus de deux tours de modification, nous vous recommandons d’adopter directement la méthode C. Vous pouvez tester les trois méthodes avec le même code sur APIYI apiyi.com et comparer les images obtenues : les différences seront très visibles.

Choisir Nano Banana 2.1 ou un autre modèle de la même série

APIYI propose plusieurs modèles de la série Nano Banana. L’édition en plusieurs tours est une utilisation avancée de leurs capacités de retouche. Le tableau ci-dessous vous aidera à choisir un modèle de la série.

Dépannage des problèmes fréquents lors de l’édition en plusieurs tours avec Nano Banana 2.1

En pratique, la plupart des problèmes liés à des modifications « perdues » s’expliquent par quelques causes récurrentes. Voici une liste de vérification classée selon leur fréquence : passez chaque point en revue pour trouver l’origine du problème.

1. Signature perdue : après avoir converti la réponse du modèle dans votre propre structure de données, vous la recomposez, mais la casse des noms de champs ou la structure imbriquée a changé. Le champ thoughtSignature n’est alors pas transmis. Pour éviter ce problème, enregistrez directement l’objet content d’origine et renvoyez-le tel quel.
2. Rôle incorrect : si vous attribuez le rôle user à la réponse du modèle au premier tour, celui-ci risque de prendre sa propre sortie pour une nouvelle image envoyée par l’utilisateur. La réponse du modèle doit conserver role: model.
3. Ordre inversé : les éléments de contents doivent être classés dans l’ordre chronologique : user1, model1, puis user2. Ne placez pas la nouvelle instruction au début.
4. Formats mélangés : si vous utilisez le format compatible avec OpenAI au premier tour, puis passez au format natif au tour suivant, la conversion des champs peut entraîner la perte de la signature. Pour tout le processus en plusieurs tours, mieux vaut utiliser systématiquement le format natif de Gemini.
5. Historique trop long : plus les tours s’enchaînent, plus la requête contient d’images, ce qui augmente son volume et son temps de traitement. Pour les processus qui dépassent deux ou trois tours, vous pouvez repartir sur un nouvel historique en utilisant le résultat obtenu à une étape clé comme nouvelle image d’origine.

🎯 Conseil technique : pour commencer le diagnostic, affichez la structure parts de model1 et vérifiez que le champ thoughtSignature est bien présent. Vérifiez ensuite qu’il est transmis à l’identique dans le corps de la requête du deuxième tour. Le centre de documentation d’APIYI, sur apiyi.com, propose des exemples d’assemblage au format natif de Gemini et de conversation en plusieurs tours pour vous aider à effectuer ces vérifications.

FAQ

Points clés de l’édition en plusieurs tours avec Nano Banana 2.1

• Il s’agit d’une édition continue : chaque tour est une requête distincte, et le client maintient le contexte en le renvoyant.
• Trois éléments sont indispensables : l’historique complet de la conversation, l’image générée au tour précédent et la signature de réflexion.
• Renvoyez le contenu du modèle tel quel : enregistrez directement candidates[0].content pour éviter de perdre la signature.
• Utilisez le format natif : la structure contents de generateContent est la plus adaptée pour renvoyer l’image et la signature.
• Précisez ce qui doit rester inchangé : au deuxième tour, indiquez clairement ce qui doit être modifié et ce qui doit être conservé. Les modifications locales sont ainsi plus fiables.
• Ne joignez pas l’image d’origine une deuxième fois : au deuxième tour, cela risque de ramener le modèle à la version antérieure aux modifications.
• Validez à faible coût : utilisez le crédit gratuit d’APIYI, sur apiyi.com, pour vérifier que deux tours fonctionnent avant la mise en production.

Conclusion

Voici les points essentiels de l’édition en plusieurs tours avec Nano Banana 2.1 :

1. Mécanisme : l’édition en plusieurs tours repose sur le renvoi du contexte par le client. La mémorisation automatique côté serveur n’ayant pas été vérifiée, mieux vaut ne pas s’y fier.
2. Contenu à renvoyer : la deuxième requête doit inclure user1, model1 tel quel (avec l’image et la signature de réflexion), puis user2.
3. Conseils pratiques : utilisez toujours le format natif de Gemini, précisez ce qui doit être conservé dans vos instructions et ne joignez pas à nouveau l’image d’origine au tour suivant.

Une fois ces trois points maîtrisés, vous pourrez reproduire de façon fiable des modifications successives en deux tours, comme « remplacer la couronne par un chapeau rouge, puis changer le cœur rose en bleu ». Cette structure peut aussi être étendue à un plus grand nombre de tours.

Pour tester rapidement le résultat, vous pouvez utiliser APIYI, sur apiyi.com. La plateforme propose des interfaces compatibles avec OpenAI ainsi que le format natif de Gemini. Une seule clé API suffit pour appeler la gamme Nano Banana et d’autres modèles courants. La facturation se fait à l’usage : idéal pour commencer par de petits tests avant de passer progressivement en production.

📚 Références

1. Documentation de l’API Google Gemini sur la génération et la retouche d’images : explications officielles sur la retouche d’images en plusieurs tours
2. Lien : ai.google.dev/gemini-api/docs/image-generation

3. Présentation : décrit la structure des requêtes de retouche d’images et le fonctionnement des échanges avec retouches successives

4. Documentation de l’API Google Gemini sur les signatures de pensée : explications sur le mécanisme des thought signatures

5. Lien : ai.google.dev/gemini-api/docs/thought-signatures

6. Présentation : explique le rôle des signatures et la manière de les renvoyer dans les requêtes à plusieurs tours

7. Centre de documentation APIYI : guides de développement de la gamme Nano Banana, guides d’implémentation des conversations à plusieurs tours et guides d’appel au format natif Gemini

8. Lien : docs.apiyi.com
9. Présentation : contient les points d’accès, les chemins au format natif et des exemples d’assemblage de l’historique, qui servent de référence pour la mise en pratique du code dans cet article

Auteur : équipe technique APIYI
Échanges techniques : contactez-nous depuis la page d’accueil du site APIYI. Pour consulter d’autres ressources d’intégration de la gamme Nano Banana, rendez-vous au centre de documentation docs.apiyi.com.

Articles connexes

• Nano Banana 2 vs 2.1 : comparaison en conditions réelles du rendu du texte sur 5 séries d’affiches et liste de critères de choix: Tout le monde dit que le rendu du texte est meilleur avec Nano Banana 2.1 ; pourquoi certains trouvent-ils la génération 2 plus précise ? Expliquez, à l’aide de 5 scénarios d’affiche reproductibles, de critères d’acceptation et de tarifs par génération, quand il faut changer et quand ce n’est pas nécessaire.
• Quelles améliorations apporte Nano Banana 2.1 ? Décryptage de ses 6 grandes évolutions et comparaison de ses performances avec Nano Banana Pro: Nano Banana 2.1 est une version améliorée de Nano Banana 2, dont le score aux tests de référence officiels dépasse celui de Nano Banana Pro, mais ses images sont-elles vraiment meilleures en pratique ? Cet article analyse 6 améliorations majeures, les résultats des évaluations officielles et indépendantes, et recommande quel modèle choisir entre Nano Banana 2.1 et Pro selon les cas d’usage.
• Tarification de Nano Banana 2.1 : analyse complète, comparaison des 5 différences clés avec Nano Banana 2 et estimation des économies: Analyse des tarifs de Nano Banana 2.1 à partir de la page officielle de Google : le prix unitaire des images générées est divisé par deux, mais les tokens d’entrée et de réflexion coûtent plus cher, la consommation en 4K augmente et le palier 0,5K disparaît ; coûts par image en 1K/2K/4K, tarifs en lot, seuil de rentabilité et conseils de migration.
• Une seule image a-t-elle trompé 3 millions de personnes ? Tutoriel en 2 étapes pour créer des images de voyage satiriques pseudo-documentaires avec GPT Image 2.5: Décomposez la vidéo satirique parisienne de Wytse Koetse : rédigez d’abord des invites structurées avec GPT, puis utilisez gpt-image-2.5-sunburst ou gemini-nano-banana-2.1 pour générer en série des images fixes pseudo-documentaires au ton de « fausse publicité touristique ».