Comment évaluer Nano Banana 2 pour l’édition visuelle en plusieurs tours

Ce que nous savons et ce que la documentation ne démontre pas encore

La question de ce benchmark n’est pas de savoir si une image est séduisante ni si le modèle peut produire une retouche convaincante dans un exemple isolé. Elle est plus précise : lorsqu’une personne demande plusieurs modifications successives, celles-ci sont-elles appliquées et les éléments que le modèle ne devait pas toucher restent-ils stables ? Il faut également déterminer si les erreurs introduites lors d’une retouche se répercutent sur les suivantes et finissent par s’accumuler.

Dans sa documentation destinée aux développeurs, Google présente Nano Banana 2 et décrit des capacités liées à la génération et à l’édition d’images ainsi qu’à l’itération. Cette description permet de comprendre les usages annoncés, mais elle ne constitue pas une mesure indépendante de la préservation des détails sur plusieurs tours. Les sources disponibles ne fournissent ni résultats quantitatifs pour cette tâche précise ni protocole permettant d’en déduire un niveau de performance.

Ce qui suit est donc une proposition d’évaluation, et non un compte rendu de résultats. Le texte n’attribue au modèle aucun taux de réussite, ne le déclare ni meilleur ni moins bon qu’une alternative et ne suppose pas qu’une retouche conserve automatiquement l’état de la précédente. Avant de lancer le test, il faudra confirmer quelle version exacte est accessible, par quelle interface et avec quels contrôles.

La question opérationnelle du benchmark

Le cas d’usage consiste à partir d’une image et à demander des modifications successives. On pourrait, par exemple, commencer par changer la couleur d’une veste, puis remplacer l’arrière-plan et enfin ajouter un objet sur une table. À chaque étape, le test doit vérifier à la fois la modification demandée et la préservation des éléments qui ne sont pas concernés : visage, pose, vêtements non mentionnés, objets, cadrage et caractéristiques importantes de l’arrière-plan.

L’évaluation doit distinguer deux obligations. La première est le respect de la consigne : la modification demandée apparaît-elle ? La seconde est la préservation : les éléments désignés comme témoins restent-ils suffisamment stables ? Une sortie peut satisfaire à l’une de ces obligations et échouer à l’autre. Si l’on se contente d’évaluer la ressemblance générale ou l’attrait de l’image, ces échecs risquent de passer inaperçus.

Il faut aussi noter si un résultat produit lors d’un tour introduit des défauts qui affectent les tours suivants. Une main déformée dès le début peut rester déformée par la suite, même si les consignes suivantes portent sur d’autres éléments. Le benchmark ne devrait pas attribuer automatiquement ce défaut à la dernière instruction : il faut conserver les images de chaque étape et évaluer la trajectoire complète.

Conception des tâches et sélection des images

Le jeu de test devrait réunir des images initiales variées : personnes, objets, scènes intérieures et extérieures, ainsi que différents niveaux de complexité. Cette diversité ne suffit pas à établir la représentativité du jeu ; elle permet plutôt de vérifier si le comportement observé dépend du type de contenu. Les conclusions devront se limiter aux catégories et aux conditions effectivement évaluées.

Pour chaque image, il est utile de préparer à l’avance une séquence de consignes et une liste d’éléments cibles et témoins. Les cibles sont les éléments à modifier. Les témoins sont ceux que la consigne ne doit pas altérer. Une fiche de tâche peut préciser ce qui doit changer, ce qui doit être préservé, les modifications collatérales jugées importantes et les ambiguïtés susceptibles de provoquer des désaccords entre évaluateurs.

Les consignes doivent être précises, sans être si rigides que le benchmark revienne à vérifier une seule réponse exacte. Par exemple, remplacer une tasse par une tasse bleue autorise des variations de forme et de texture ; en revanche, conserver le nombre de personnes ou maintenir la position approximative d’une lampe constitue un critère plus objectif. Les critères d’acceptation et les exclusions doivent être fixés avant de consulter le modèle.

La sélection des cas ne doit pas non plus se limiter aux exemples faciles ou visuellement spectaculaires. Il est recommandé d’expliquer comment les images ont été réunies, combien de tâches ont été exclues et pour quelles raisons. Si les supports sont soumis à des restrictions d’utilisation ou contiennent des données personnelles, le protocole doit décrire leur provenance et les mesures pertinentes. Les sources disponibles ne permettent pas d’affirmer quelles données d’entraînement ont été utilisées pour le modèle ni s’il existe un chevauchement avec un jeu d’évaluation particulier ; cette incertitude doit être explicitement signalée.

Conditions d’exécution et comparaison

Avant de lancer les tests, l’équipe doit identifier précisément le modèle et la version proposés par le canal d’accès choisi. Le nom affiché sur une page ou dans une interface ne suffit pas s’il ne permet pas de distinguer avec certitude Nano Banana 2 des autres modèles d’image. Il faut également consigner la date du test, l’interface ou l’API, les paramètres disponibles, le format et la taille des images, ainsi que toute instruction système susceptible d’influencer la retouche.

La gestion de l’état entre les tours est une condition essentielle. L’interface peut conserver le contexte de la conversation, ou la personne qui réalise le test peut devoir renvoyer l’image résultante à chaque étape. Ces deux situations ne sont pas équivalentes : dans la seconde, le modèle reçoit une nouvelle image en entrée à chaque tour. Le protocole doit préciser le fonctionnement retenu et conserver les instructions, ainsi que les images envoyées et reçues.

À titre de référence, on peut comparer le flux itératif à une condition en un seul passage : une consigne rassemble les modifications prévues dans la séquence, puis une seule retouche est effectuée. Cette comparaison ne sera informative que si les deux flux utilisent le même modèle, les mêmes images initiales, la même qualité d’entrée, les mêmes paramètres et des possibilités de génération comparables, dans la mesure où le canal le permet. Si ces conditions diffèrent, il faut le signaler et éviter d’attribuer l’écart uniquement au nombre de tours.

La comparaison n’est pas toujours parfaitement équivalente. Une consigne combinée peut être plus longue ou plus ambiguë que plusieurs consignes successives ; une séquence peut aussi permettre des corrections impossibles en un seul passage. Ces différences font partie de la question pratique, mais elles doivent être décrites avec précision. Si l’accès ne permet pas de créer une condition comparable, l’équipe peut réaliser le test itératif et le présenter comme tel, sans prétendre avoir démontré un avantage par rapport à une retouche en un seul passage.

Mesures, évaluation humaine et résultats

Le résultat principal ne devrait pas être réduit à un score unique sans expliquer ce qu’il combine. Il faut au minimum présenter séparément le respect de chaque modification, la préservation de chaque témoin, la cohérence avec l’image initiale et les erreurs nouvelles ou persistantes. Il est possible de calculer le pourcentage de critères satisfaits, mais il faut aussi publier les décomptes et des exemples d’échec afin que l’agrégation ne masque pas des cas importants.

L’évaluation humaine est pertinente, car certains critères — comme la préservation de l’apparence d’une personne — peuvent nécessiter un jugement visuel. Pour limiter les biais, la grille d’évaluation doit être rédigée avant l’examen des sorties. Lorsque c’est possible, les personnes chargées de la notation ne devraient pas savoir quelle condition a produit chaque image. Si plusieurs évaluateurs participent, le niveau d’accord et la manière de résoudre les désaccords doivent être indiqués. Une impression informelle ne doit pas être présentée comme une mesure reproductible.

Des mesures automatiques peuvent aider à comparer des images ou à détecter des changements, mais elles ne doivent pas remplacer la vérification du respect de l’intention de la consigne. L’équipe devra préciser les outils employés et l’aspect qu’ils mesurent. Une forte similarité globale, par exemple, peut coexister avec la modification indue d’un petit détail ; une différence globale importante peut être normale lorsqu’on demande de remplacer un arrière-plan.

Pour décrire la variation entre les exécutions, les cas seront répétés dans des conditions documentées, si le canal permet de générer de nouvelles sorties. Le nombre de répétitions devra être fixé avant l’interprétation des résultats et publié avec les échecs, les sorties invalides et tout incident. Il ne faut pas sélectionner uniquement la meilleure sortie de chaque cas : cette pratique mesure la performance après sélection, et non la fiabilité d’une exécution ordinaire.

Reproductibilité, limites et portée des conclusions

Un rapport reproductible devrait publier la liste des tâches, les consignes exactes, la provenance ou la description des images, les paramètres disponibles, le nombre d’exécutions et la grille d’évaluation. Il devrait également montrer les résultats ayant échoué et expliquer les exclusions. Si les images ne peuvent pas être partagées pour des raisons de licence, de confidentialité ou d’autres contraintes, cette limite doit être expliquée et une description suffisamment détaillée doit permettre de comprendre comment les cas ont été constitués.

Les travaux antérieurs disponibles ne suffisent pas à trancher cette évaluation. Une étude de Nano Banana Pro portant sur différentes tâches de vision concerne un autre modèle et un autre protocole de test ; ses conclusions ne peuvent pas être transposées à Nano Banana 2 ni à l’édition conversationnelle en plusieurs tours. De même, un benchmark de Nano Banana 2 Lite ne constitue pas une comparaison directe du modèle exact étudié ici. Une évaluation de la restauration d’images avec Nano Banana 2 peut apporter un contexte sur une tâche voisine, mais elle ne mesure pas nécessairement la préservation des éléments après des consignes successives.

Si le protocole est mis en œuvre, les conclusions devront être limitées aux versions, conditions, images et tâches effectivement testées. Un bon résultat sur quelques scènes ne démontrerait pas la fiabilité du modèle pour toute forme d’édition visuelle, pour d’autres canaux d’accès ou pour des usages professionnels assortis d’exigences différentes. Il ne permettrait pas non plus de tirer de conclusions sur les tâches qui n’ont pas été incluses. Si aucun canal vérifiable ne permet d’identifier le modèle ou de consigner les conditions, le test pourra être décrit comme exploratoire, et non comme une comparaison pleinement reproductible.

Critères pratiques avant de prendre une décision

Pour une équipe qui envisage d’intégrer l’édition en plusieurs tours à un flux de travail, la décision devrait s’appuyer sur des tâches proches de ses propres usages, et non seulement sur des images de démonstration choisies par le fournisseur. Il est utile de donner la priorité aux éléments dont l’altération aurait des conséquences importantes : identité, texte, logos, objets de produit ou composants d’une scène. Il faut aussi définir le niveau de changement collatéral considéré comme acceptable.

Avant d’interpréter un score, vérifiez quatre points : le modèle testé est-il identifié sans ambiguïté ? La manière dont l’état est transmis d’un tour à l’autre est-elle connue ? Les modifications demandées et les éléments à préserver sont-ils évalués séparément ? Le rapport présente-t-il la variabilité, les erreurs et les limites ? Si l’un de ces éléments manque, les preuves obtenues seront plus fragiles, et cette incertitude doit peser dans la décision.

La documentation disponible justifie de poser la question de l’évaluation, mais elle n’en préjuge pas la réponse. L’étape suivante n’est pas de proclamer un vainqueur : il s’agit de mener un test contrôlé, d’en conserver l’enregistrement complet et de publier des résultats permettant de distinguer une retouche réussie d’une séquence réellement stable.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.