Note de l’auteur : ce guide de migration vers Nano Banana 2.1 couvre l’ID du modèle, les résolutions 1K/2K/4K, les 14 images de référence, les niveaux de réflexion et la facturation. Il comprend une liste complète des points à vérifier pour migrer depuis gemini-3.1-flash-image.
Commençons par l’essentiel : Nano Banana 2.1 est une version améliorée de Nano Banana 2 (gemini-3.1-flash-image). Il conserve un positionnement Flash en matière de vitesse et de coût. Pour migrer depuis l’ancien modèle, il suffit surtout de modifier l’ID du modèle et quelques paramètres, notamment la résolution, le nombre d’images de référence et le niveau de réflexion. Pas besoin de revoir toute votre chaîne de génération d’images.
Cet article ne cherche pas à vanter le modèle et ne tire aucune conclusion sur l’amélioration de la qualité visuelle par rapport à la version 2 : nous ne disposons pas encore de données comparatives fiables issues de tests. Nous suivons plutôt l’ordre des points à modifier lors de la migration : ID du modèle, résolution, images de référence, niveaux de réflexion, facturation et validation. Vous trouverez à la fin une liste de vérification directement exploitable pour migrer vers Nano Banana 2.1, destinée aux développeurs et aux équipes de design qui créent des visuels e-commerce, des affiches ou des compositions à partir de plusieurs images, ou qui travaillent sur la cohérence des personnages.
Points clés et ID du modèle Nano Banana 2.1
Commençons par un tableau qui rassemble les informations les plus utiles pour migrer vers Nano Banana 2.1. Toutes proviennent des descriptions publiques de la fiche officielle du modèle, de la documentation API et de la documentation APIYI. Aucune donnée ne repose sur des suppositions.
| Point clé | Nano Banana 2.1 | Effet sur la migration |
|---|---|---|
| ID du modèle | gemini-nano-banana-2.1 |
Remplace l’ancien ID gemini-3.1-flash-image |
| Date de sortie | 6 octobre 2026 | Version récente : consultez la documentation à jour pour les détails des paramètres |
| Résolution | 1K / 2K / 4K, 1K par défaut | La sortie est en 1K si aucune résolution n’est précisée : vérifiez votre ancienne configuration |
| Images de référence | Jusqu’à 14 images, avec un maximum de 4 personnages et 10 objets | Les limites pour la fusion d’images et les séries d’images sont à revoir |
| Niveau de raisonnement | minimal / medium (par défaut) / high |
Influe sur la latence et le coût : choisissez le niveau selon la tâche |
| Contexte et sortie | Contexte de 131 072, sortie maximale de 32 768 | Plus de marge pour les invites longues et les scénarios avec plusieurs images de référence |
ID du modèle Nano Banana 2.1 et modèle remplacé
L’ID de Nano Banana 2.1 est gemini-nano-banana-2.1. Selon les sources consultées, il s’agit du modèle recommandé pour remplacer gemini-3.1-flash-image, dont la version préliminaire a été arrêtée le 25 juin 2026. Si l’ancien ID est encore codé en dur dans votre projet, c’est le moment de passer au nouveau.
Attention, le style du nouvel ID est très différent : gemini-3.1-flash-image indique une version et une famille de modèles, tandis que le nouvel ID utilise directement le nom Nano Banana. Beaucoup d’équipes filtrent les noms de modèles par préfixe dans leur gestion de configuration, leurs variables d’environnement ou leurs règles de recherche dans les journaux. Pensez à mettre tous ces éléments à jour, sous peine de voir des données disparaître de vos tableaux de bord.
Deux descriptions du modèle sous-jacent de Nano Banana 2.1
Le modèle sous-jacent de Nano Banana 2.1 est actuellement décrit de deux façons. Mieux vaut mentionner les deux dans votre documentation technique :
- Selon la fiche officielle du modèle : il repose sur Gemini 3.6 Flash.
- Selon la documentation API : il s’agit d’une version améliorée de Nano Banana 2, qui conserve une vitesse et un coût de niveau Flash.
Ces deux descriptions ne sont pas forcément contradictoires : l’une parle du modèle de base, l’autre de l’évolution de la gamme de produits. Pour communiquer à l’extérieur, mieux vaut toutefois ne pas en retenir une seule. Dans une proposition destinée à un client ou lors d’une revue interne, précisez par exemple : « La fiche du modèle indique qu’il repose sur Gemini 3.6 Flash ; la documentation API le présente comme une version améliorée de Nano Banana 2. »
Au-delà de la génération d’images, Nano Banana 2.1 améliore aussi le rendu du texte et la mise en page des infographies. Il prend en charge le grounding avec Google Web/Image Search. Il accepte en entrée du texte, des images, des vidéos et des PDF, et produit des images et du texte. Ces capacités ouvrent davantage de possibilités pour les affiches, les visuels de produits avec du texte et les infographies.
Nano Banana 2.1 : quelle résolution choisir entre 1K, 2K et 4K ?
Nano Banana 2.1 propose trois résolutions : 1K, 2K et 4K. La résolution par défaut est 1K. Côté proportions, il prend en charge les formats courants 1:1, 3:2, 2:3, 3:4, 4:3, 4:5, 5:4, 9:16, 16:9 et 21:9, entre autres. De quoi couvrir l’essentiel des besoins : images principales pour l’e-commerce, visuels verticaux pour les réseaux sociaux, bannières, affiches et couvertures grand écran.
Cette version apporte une correction à prendre en compte lors de la migration : les artefacts de mosaïque qui apparaissaient en 2K/4K avec les formats larges et panoramiques (1:4, 4:1, 1:8, 8:1) ont été corrigés. Si vous évitiez les hautes résolutions pour vos images longues, bannières ou panoramas à cause de ces artefacts, c’est le moment de réévaluer vos réglages.
| Résolution | Tokens de sortie (environ) | Multiplicateur de tokens par rapport au 1K | Cas d’usage |
|---|---|---|---|
| 1K (par défaut) | Environ 1 120 | 1 fois | Esquisses, aperçus en lot, visuels pour les réseaux sociaux, tests A/B |
| 2K | Environ 1 680 | Environ 1,5 fois | Visuels de détail pour l’e-commerce, affiches classiques, images d’en-tête de pages de destination |
| 4K | Environ 3 780 | Environ 3,4 fois | Supports imprimés, publicités grand format, images sources destinées à être recadrées |
Conseils pour choisir la résolution dans Nano Banana 2.1
Les tokens de sortie indiqués dans le tableau sont un facteur clé de la tarification officielle au token : plus la résolution est élevée, plus chaque image consomme de tokens de sortie. Le 4K en consomme environ 3,4 fois plus que le 1K. Avec une facturation au token, choisir systématiquement le 4K « au cas où » augmente donc sensiblement les coûts.
Une approche pratique consiste à travailler en deux étapes : utilisez le 1K pour explorer les idées et trier les propositions en lot, afin de générer rapidement des images et d’écarter celles qui ne conviennent pas. Une fois la direction choisie, passez au 2K ou au 4K pour produire le visuel final. Si votre plateforme facture à l’image au même prix du 1K au 4K, le raisonnement change. Nous y reviendrons dans la section sur la tarification.
Lors de la migration, vérifiez aussi si votre ancien code indique explicitement la résolution. Si vos appels utilisaient la valeur par défaut alors que votre application a besoin d’une sortie en 2K ou plus, vous devrez la préciser après le passage à Nano Banana 2.1. Sinon, vous recevrez des images en 1K, la résolution par défaut. Consultez la documentation de l’interface utilisée pour connaître les noms exacts des champs de résolution et de proportions.
Images de référence de Nano Banana 2.1 : comment répartir les 14 images disponibles
Nano Banana 2.1 prend en charge jusqu’à 14 images de référence. C’est le changement à retenir pour fusionner plusieurs images ou créer des séries visuelles. Deux limites s’appliquent également : la cohérence des personnages est limitée à 4 personnages et celle des objets à 10 objets.
Ces deux chiffres déterminent la façon d’organiser vos images de référence. Pour une série d’illustrations de marque avec plusieurs personnages, par exemple, vous pouvez en verrouiller jusqu’à 4 et réserver les images restantes aux décors, aux accessoires ou aux exemples de style. Pour une série d’images produit, la limite de 10 objets suffit à couvrir une gamme de SKU de taille moyenne.
Utilisations courantes des images de référence avec Nano Banana 2.1
La documentation présente quatre grands cas d’usage :
- Création de personnages : utilisez des images de référence sous plusieurs angles pour 1 à 4 personnages, afin de conserver une apparence stable d’une image à l’autre.
- Séries de produits : utilisez les produits d’une même gamme comme objets de référence pour générer des images principales, des mises en situation et des compositions dans un style cohérent.
- Fusion de plusieurs images : combinez des références de décor, de sujet, de matière et d’éclairage dans une seule image. Cette approche convient aux affiches et aux visuels conceptuels.
- Identité visuelle de marque : utilisez les couleurs, les éléments de logo et les visuels existants de la marque comme références pour produire des supports cohérents à grande échelle.
Lors de la migration, ajoutez une vérification du nombre d’images de référence au niveau des appels : au-delà de 14 images, bloquez la demande côté client et affichez un message, plutôt que d’attendre une erreur de l’API. Les limites sur les personnages et les objets sont quant à elles d’ordre sémantique : l’API ne peut pas nécessairement les vérifier directement. Mieux vaut donc indiquer aux designers dans l’interface qu’ils peuvent « verrouiller au maximum 4 personnages et 10 objets à la fois », afin d’éviter que les personnages ne soient confondus dans le résultat.
Plus les images de référence sont nombreuses, plus le traitement des données d’entrée est généralement important, ce qui peut augmenter la latence. Lorsque le délai compte, il n’est pas nécessaire d’utiliser systématiquement les 14 images : sélectionner quelques références qui représentent le mieux les caractéristiques recherchées est souvent plus efficace.
Niveaux de réflexion de Nano Banana 2.1 : comment choisir entre minimal, medium et high
Nano Banana 2.1 propose trois niveaux de réflexion : minimal, medium (par défaut) et high. Plus le niveau est élevé, plus le modèle raisonne avant de générer l’image, ce qui se traduit généralement par une attente plus longue et une consommation de ressources accrue.
Le principe donné par la documentation est simple : augmentez le niveau pour les compositions complexes, la mise en page de texte ou la fusion de plusieurs images ; baissez-le pour les retouches simples afin de réduire l’attente et les coûts. Voici comment appliquer cette règle à des tâches concrètes.
| Niveau de réflexion | Tâches recommandées | Tendance en matière de latence et de coût | Conseil de migration |
|---|---|---|---|
minimal |
Changement d’arrière-plan, correction des couleurs, retouches locales, modifications simples | Les plus faibles | Adapté aux traitements par lots à forte concurrence |
medium (par défaut) |
Images produit classiques, visuels pour les réseaux sociaux, affiches avec un seul sujet | Modérés | En cas de doute, utilisez d’abord la valeur par défaut comme référence |
high |
Compositions complexes, mise en page de textes denses, infographies, fusion de plusieurs images | Les plus élevés | À réserver aux tâches qui en ont vraiment besoin |
Une stratégie de répartition des niveaux de réflexion de Nano Banana 2.1
Une erreur courante consiste à se dire : « Si je veux une qualité élevée, je mets tout en high. » En réalité, pour une retouche simple, un niveau de réflexion élevé apporte peu de bénéfices, mais allonge bel et bien le temps de réponse. Ce coût se fait particulièrement sentir dans les interactions où l’utilisateur attend en temps réel.
Une approche plus raisonnable consiste à sélectionner le niveau côté application selon le type de tâche. Par exemple, envoyez les « affiches contenant de longs textes », les « fusions de 14 images de référence » et les « infographies » vers high, les « changements d’arrière-plan par lots » vers minimal, et laissez le reste sur medium par défaut. Vous préservez ainsi la qualité des tâches importantes tout en maîtrisant la latence globale.
Si l’ancien modèle ne propose pas de réglage équivalent, le niveau utilisé après la migration sera medium par défaut. Il est conseillé de conserver cette valeur au début, d’établir d’abord un jeu de données de référence, puis d’ajuster progressivement le niveau à la hausse ou à la baisse selon les tâches. Vous éviterez ainsi de modifier trop de variables à la fois, ce qui rendrait les résultats difficiles à interpréter.
Tarification de Nano Banana 2.1 : à l’image ou au token
La tarification de Nano Banana 2.1 est l’un des aspects où l’on risque le plus de se tromper lors d’une évaluation de migration, car il existe deux modes de facturation. La tarification officielle dépend du nombre de tokens en sortie : ce nombre varie entre 1K, 2K et 4K, tout comme le coût. La documentation d’APIYI indique, elle, une facturation à l’image de $0.045, au même prix de 1K à 4K.
| Mode de facturation | Unité de facturation | Effet de la résolution sur le coût | Méthode d’estimation adaptée | Source |
|---|---|---|---|---|
| Tarification officielle au token | Token en sortie | Environ 3.4 fois plus de tokens en 4K qu’en 1K | Estimer le nombre total de tokens selon la répartition des résolutions | Documentation officielle |
| Facturation à l’image | Chaque image | Même prix de 1K à 4K | Estimer directement selon le nombre d’images générées | Documentation d’APIYI apiyi.com : $0.045 par image |
Les deux modes de facturation de Nano Banana 2.1 ne sont pas directement comparables
La facturation à l’image et la facturation au token reposent sur deux méthodes de calcul différentes : on ne peut pas comparer directement un prix par image à un prix par million de tokens. Pour obtenir une comparaison utile, partez de votre propre usage : quelle part de vos images est produite en 1K, 2K et 4K, et à combien de tokens correspond chaque image en moyenne ? Appliquez ensuite chaque mode de facturation à ces données.
Avec une facturation à l’image au même prix de 1K à 4K, le coût marginal d’une résolution plus élevée n’augmente plus avec le nombre de tokens. Pour les usages en e-commerce et en impression qui nécessitent beaucoup d’images finales en 2K ou 4K, cela peut changer l’arbitrage évoqué plus haut : explorer en 1K, puis augmenter la résolution pour le rendu final. Cela dit, la génération en 1K reste généralement plus rapide et conserve donc son intérêt pendant la phase d’exploration.
💰 À savoir sur la facturation : la documentation d’APIYI apiyi.com indique un tarif de $0.045 par image pour Nano Banana 2.1, identique de 1K à 4K. Les prix peuvent toutefois changer : fiez-vous aux montants affichés dans la console et la documentation. Vérifiez également dans la console si la plateforme prend en charge tous les paramètres, comme chaque format d’image et chaque niveau de réflexion.
Migrer de gemini-3.1-flash-image vers Nano Banana 2.1 en 6 étapes
Après avoir passé les paramètres en revue, voici comment les réunir dans un processus de migration concret. D’après la documentation de référence, la migration comprend six étapes :
- Remplacer l’ID du modèle : remplacez
gemini-3.1-flash-imagepargemini-nano-banana-2.1, puis mettez à jour le centre de configuration, les variables d’environnement, les recherches dans les journaux et les règles de surveillance. - Vérifier les dimensions et les rapports hauteur/largeur : déterminez si les appels existants dépendent de la résolution par défaut. Pour les usages qui nécessitent du 2K ou du 4K, indiquez-le explicitement. Réévaluez la haute résolution pour les formats larges et panoramiques.
- Vérifier la limite d’images de référence : validez côté client qu’il y a au maximum 14 images et indiquez dans le produit la limite de 4 personnages et 10 objets.
- Évaluer les niveaux de raisonnement : établissez d’abord une référence avec le niveau
mediumpar défaut, puis dirigez les requêtes versminimalouhighselon le type de tâche. Observez les variations de latence et de coût. - Comparer la qualité des résultats et la facturation : exécutez le même ensemble d’invites et d’images de référence sur l’ancien et le nouveau modèle, puis comparez la qualité visuelle, le rendu du texte et le coût par image.
- Conserver une option de retour arrière : gardez dans la configuration un commutateur permettant de revenir rapidement à l’ancien modèle en cas de baisse de qualité ou de coût anormal.
Accéder à Nano Banana 2.1 avec APIYI
Si vous utilisez une interface compatible avec OpenAI, il suffit de définir le base_url du client sur https://api.apiyi.com/v1, de saisir votre clé API APIYI, puis de remplacer la valeur du paramètre model par gemini-nano-banana-2.1. Une seule clé API permet d’invoquer les modèles Gemini, OpenAI, Claude et d’autres modèles. Vous pouvez donc comparer l’ancien et le nouveau modèle avec la même intégration pendant la migration.
Avant de migrer, vérifiez dans la liste des modèles de la console APIYI que gemini-nano-banana-2.1 est disponible et consultez son mode de facturation. Vérifiez aussi dans la console et la documentation la prise en charge des paramètres, comme un rapport hauteur/largeur donné ou le niveau de raisonnement high : ne supposez pas que tous les paramètres officiels sont disponibles.
🚀 Conseil de migration : après avoir vérifié le mode de facturation de Nano Banana 2.1 dans la liste des modèles d’APIYI sur apiyi.com, utilisez d’abord le crédit de test gratuit destiné aux nouveaux utilisateurs sur un petit échantillon. Comparez les résultats des deux modèles avant de décider d’une migration complète.
Valider la migration vers Nano Banana 2.1 avec les journaux d’utilisation
Pour valider la migration, il ne suffit pas de regarder les images : il faut aussi examiner les coûts. APIYI fournit des journaux d’utilisation qui permettent de consulter le modèle, le nombre d’appels et les frais par requête. Pendant la première semaine, comparez chaque jour les volumes d’appels et les courbes de coûts des deux modèles pour vérifier que la facturation correspond à vos attentes. Vérifiez notamment si certaines requêtes utilisent encore l’ancien ID de modèle.
Pour évaluer la qualité, préparez un jeu de tests fixe qui couvre vos usages principaux : images principales pour le commerce en ligne, affiches avec texte, séries nécessitant une cohérence des personnages et fusion de plusieurs images. Pour chaque catégorie, sélectionnez plusieurs ensembles d’invites et d’images de référence, exécutez-les avant et après la migration, puis demandez à des designers d’évaluer les résultats à l’aveugle. Tant que vous ne disposez pas de vos propres données d’évaluation, méfiez-vous des conclusions qui promettent une « amélioration sur tous les plans ».
Nano Banana 2.1 : questions fréquentes (FAQ)
Q1 : Quel est le lien entre Nano Banana 2.1 et gemini-3.1-flash-image ?
Nano Banana 2.1 (`gemini-nano-banana-2.1`) est une version améliorée de Nano Banana 2 (`gemini-3.1-flash-image`) et le modèle recommandé pour le remplacer. Il conserve une vitesse et un coût de niveau Flash. Concernant sa version sous-jacente, la fiche officielle du modèle indique qu’il repose sur Gemini 3.6 Flash, tandis que la documentation de l’API le présente comme une évolution de Nano Banana 2. Il est conseillé de mentionner les deux formulations.
Q2 : Faut-il modifier la logique du code pour passer à Nano Banana 2.1 ?
Dans la plupart des cas, il n’est pas nécessaire de remanier la logique : il suffit surtout de modifier l’ID du modèle et les paramètres de résolution, de nombre d’images de référence et de niveau de réflexion. Si vos appels existants utilisent la résolution par défaut et que vous avez besoin de 2K ou 4K, vous devrez la préciser explicitement. Avec l’interface compatible OpenAI d’APIYI apiyi.com, il suffit de modifier le paramètre `model` pour changer de modèle.
Q3 : Si les résolutions 1K à 4K sont au même prix, vaut-il toujours mieux choisir la 4K ?
Avec une facturation à l’appel et un tarif identique de 1K à 4K, la 4K n’augmente pas le coût par image, mais la génération et le transfert peuvent prendre plus de temps, et le stockage coûte plus cher. Pour l’exploration et le tri par lots, mieux vaut rester en 1K, puis passer en 2K ou 4K pour la version finale. Consultez la console APIYI apiyi.com pour connaître le tarif à l’appel en vigueur.
Q4 : Quelles sont les limites connues de Nano Banana 2.1 ?
Le modèle accepte jusqu’à 14 images de référence, avec un maximum de 4 personnages pour la cohérence des personnages et de 10 objets pour la cohérence des objets. Au-delà, il faut diviser la tâche. Le niveau de réflexion `high` augmente la latence et le coût. Il n’existe actuellement aucune comparaison publique et fiable de la qualité d’image fondée sur des tests pratiques : vérifiez donc les résultats de la migration avec votre propre jeu d’évaluation.
Bilan et liste de contrôle pour la migration vers Nano Banana 2.1
Nano Banana 2.1 : points clés
- Positionnement : une évolution de Nano Banana 2 qui remplace
gemini-3.1-flash-image, tout en conservant une vitesse et des coûts de niveau Flash. - Modèle sous-jacent : la fiche du modèle indique qu’il repose sur Gemini 3.6 Flash, tandis que la documentation API le présente comme une évolution de Nano Banana 2. Il faut mentionner les deux.
- Résolution : 1K/2K/4K, avec 1K par défaut. Les artefacts de mosaïque aux formats larges et panoramiques en 2K/4K ont été corrigés.
- Images de référence : jusqu’à 14 images, avec un maximum de 4 personnages et 10 objets. Pratique pour les séries d’images et la fusion de plusieurs images.
- Niveau de raisonnement :
mediumpar défaut,highpour les compositions complexes et la mise en page de texte,minimalpour les modifications simples. - Facturation : la tarification officielle est basée sur les tokens, tandis que la documentation APIYI indique un tarif identique par image. Les deux ne sont pas directement comparables ; référez-vous aux prix de la console.
Liste de contrôle pour la migration vers Nano Banana 2.1
| Élément à vérifier | Action | Critère de validation |
|---|---|---|
| ID du modèle | Remplacer toutes les occurrences de gemini-3.1-flash-image par gemini-nano-banana-2.1 |
Aucun appel avec l’ancien ID n’apparaît dans les journaux d’utilisation |
| Résolution | Vérifier que la résolution 1K par défaut répond aux besoins ; spécifier explicitement 2K/4K si nécessaire | Les dimensions de sortie correspondent aux besoins |
| Rapport hauteur/largeur | Réévaluer les formats larges et panoramiques en 2K/4K | Les images longues et les bannières ne présentent aucun artefact de mosaïque |
| Images de référence | Vérifier côté client la limite de 14 images et signaler les limites de ≤4 personnages et ≤10 objets | Les requêtes qui dépassent les limites sont bloquées côté client |
| Niveau de raisonnement | Établir une référence avec medium, puis orienter les requêtes selon la tâche |
La latence et les coûts restent acceptables |
| Format de sortie | Vérifier la compatibilité de la logique d’analyse des sorties image et texte | Le stockage et l’affichage en aval fonctionnent correctement |
| Vérification de la facturation | Estimer les coûts selon la répartition des résolutions utilisées et vérifier les prix dans la console | Les frais réels correspondent aux estimations |
| Évaluation de la qualité | Comparer les anciens et nouveaux modèles à l’aveugle sur un jeu d’évaluation fixe | Aucune régression de qualité sur les usages essentiels |
| Option de retour arrière | Conserver dans la configuration la possibilité de revenir à l’ancien modèle | Le retour arrière peut être effectué en quelques minutes |
La migration vers Nano Banana 2.1 consiste essentiellement à « changer l’ID, ajuster les paramètres et valider le résultat ». Configurez la résolution, les images de référence et le niveau de raisonnement selon les besoins, puis vérifiez le tout à l’aide du jeu d’évaluation et des journaux d’utilisation pour effectuer la transition sereinement.
Nous recommandons d’utiliser APIYI sur apiyi.com pour appeler en parallèle l’ancien et le nouveau modèle avec la même clé API et comparer leurs résultats. Vérifiez la facturation par appel dans les journaux d’utilisation avant de basculer entièrement vers le nouveau modèle.
Auteur : équipe technique APIYI
Échanges techniques : contactez-nous depuis la page d’accueil du site APIYI. Pour en savoir plus sur l’intégration, consultez le centre de documentation sur docs.apiyi.com.
