Récemment, des clients utilisant Nano Banana Pro (ID du modèle : gemini-3-pro-image-preview) pour de la génération d'images (image vers image) ont rencontré une erreur 400 très typique de Google :
{
"status_code": 400,
"error": {
"message": "Unsupported file URI type: {{ $json.imageUrls }}. File URI must be a File API (e.g. https://generativelanguage.googleapis.com/files/<id>), Youtube (e.g. https://www.youtube.com/watch?v=<id>), or HTTPS (e.g. http://path/to/file).), or a valid gURI (e.g. gs://bucket/object",
"type": "",
"code": 400
}
}
Le message d'erreur de Nano Banana Pro pointe directement le coupable : Unsupported file URI type: {{ $json.imageUrls }}. Notez bien que {{ $json.imageUrls }} est une variable de modèle n8n non interprétée. En clair, le client a inséré une expression dynamique dans son workflow, mais celle-ci n'a pas été rendue par le moteur en une URL réelle ; elle a été transmise telle quelle, sous forme de chaîne de caractères, dans le champ fileUri de l'API Gemini. Google, ne pouvant pas reconnaître une URI commençant par {{ ... }}, a logiquement rejeté la requête.
Cet article s'appuie sur cette erreur réelle et sur la documentation officielle de Google concernant les formats d'entrée pour gemini-3-pro-image-preview. Nous allons décomposer les 5 scénarios les plus fréquents et fournir pour chacun un code minimal reproductible ainsi qu'une solution de réparation immédiate. Après lecture, vous devriez être capable de localiser et de corriger n'importe quelle erreur de type Unsupported file URI type en moins de 5 minutes.
Aperçu des informations essentielles sur l'erreur Nano Banana Pro
Avant de modifier le code, résumons les points clés de cette erreur et les formats d'URI acceptés officiellement.
| Dimension | Fait clé |
|---|---|
| ID du modèle | gemini-3-pro-image-preview (nom officiel de Nano Banana Pro dans l'API Gemini) |
| Code HTTP d'erreur | 400 (Bad Request, erreur de paramètre client) |
| Champ critique de l'erreur | Unsupported file URI type |
| Emplacement réel du problème | Champ fileData.fileUri dans le corps de la requête |
| Littéral apparaissant dans l'erreur | {{ $json.imageUrls }} (expression n8n non rendue) |
| Types d'URI acceptés par Gemini | URI File API / URL YouTube / URL HTTPS publique / URI GCS gs:// |
| Formats d'image acceptés | JPEG, JPG, PNG, WEBP, HEIF |
| Support d'URL externe par Nano Banana Pro ? | ✅ Oui (support natif des URL HTTPS publiques / pré-signées depuis Gemini 2.5+) |
| Cause probable | Variable de modèle non remplacée dans les workflows low-code (n8n / Make / Zapier) |
🎯 Conseil de dépannage rapide : Si votre client ne souhaite pas vous montrer le corps complet de la requête, demandez-lui d'effectuer un appel réussi via la console APIYI (apiyi.com) avec le même modèle
gemini-3-pro-image-previewet la même image de référence. Comparez ensuite le corps de la requête échouée avec celui de la requête réussie : c'est le moyen le plus rapide de résoudre une erreur Nano Banana Pro.
Après avoir analysé les cas réels, l'erreur Unsupported file URI type peut être ramenée à 5 causes typiques. Nous les avons classées par "fréquence d'apparition", de la plus courante à la plus rare.
Cause 1 : Les variables de modèle n8n / Make / Zapier ne sont pas rendues
C'est le suspect numéro un pour cette erreur spécifique. {{ $json.imageUrls }} est une syntaxe d'expression n8n qui, en temps normal, devrait être remplacée avant l'exécution par l'URL réelle issue du nœud précédent, par exemple https://cdn.example.com/uploads/abc.jpg. Cependant, plusieurs scénarios classiques font échouer ce remplacement :
- Le champ Body du nœud HTTP Request n'est pas en mode "Expression", mais en mode "Fixed", ce qui entraîne l'envoi de tout le bloc JSON sous forme de chaîne de caractères brute ;
- Le corps JSON utilise des guillemets imbriqués, ce qui pousse n8n à croire que l'expression fait partie du contenu de la chaîne, ignorant ainsi le rendu ;
- La structure de sortie du nœud précédent ne correspond pas au chemin écrit — par exemple, la sortie réelle est
imageUrl(singulier), mais vous avez écrit$json.imageUrls(pluriel) ; après l'échec de l'analyse, n8n renvoie l'expression originale ; - L'expression dans un sous-nœud ne s'itère pas selon l'élément, mais prend fixement le premier, ce qui donne
undefineddans certaines entrées, se transformant en texte brut après sérialisation.
Méthode de diagnostic : Si vous voyez {{ ... }} dans le message d'erreur de Gemini, c'est à 100 % ce type de problème, car une URL valide ne ressemble jamais à cela.
Cause 2 : Erreur de frappe dans le nom du champ, entraînant un undefined / null
Juste après, nous trouvons les problèmes de nommage de champs. Il est très probable que le code du client contienne ceci :
// Le champ réellement renvoyé par l'interface amont s'appelle imageUrl (singulier)
const upstream = { imageUrl: "https://cdn.example.com/a.jpg" };
// Mais l'aval écrit imageUrls (pluriel, avec un s)
fileUri: upstream.imageUrls // Résultat : undefined
Lorsqu'il est sérialisé en JSON ou concaténé dans une chaîne, undefined devient la chaîne "undefined". Gemini ne peut pas non plus l'identifier et renvoie une erreur 400 quasiment identique à celle d'une variable non rendue. La différence réside dans le fait que le littéral apparaissant dans l'erreur est undefined et non {{ ... }}.
Cause 3 : Transmission d'un tableau dans fileUri au lieu d'une chaîne
Cette troisième cause survient souvent dans les scénarios de "traitement par lots de plusieurs images". Le champ fileData.fileUri de l'API Gemini n'accepte qu'une seule chaîne de caractères, pas un tableau. Pourtant, de nombreux développeurs écrivent ceci :
// ❌ Erreur : insertion directe d'un tableau dans fileUri
{
"fileData": {
"fileUri": ["https://cdn.example.com/a.jpg", "https://cdn.example.com/b.jpg"],
"mimeType": "image/jpeg"
}
}
Après sérialisation JSON, ce champ fileUri devient la chaîne ["https://...", "https://..."]. Gemini échoue à l'analyse et renvoie directement Unsupported file URI type. La bonne pratique consiste à générer un élément parts distinct pour chaque image, plutôt que de fourrer un tableau dans un seul fileUri.
Cause 4 : Protocole d'URL ou format de chemin non pris en charge
La quatrième catégorie relève de l'incompatibilité de format. L'API Gemini n'accepte que 4 types d'URI ; toute écriture sortant de ce cadre déclenchera la même erreur :
| Type d'URI | Exemple | Accepté par gemini-3-pro-image-preview |
|---|---|---|
| Chemin File API | https://generativelanguage.googleapis.com/files/abc123 |
✅ |
| URL YouTube | https://www.youtube.com/watch?v=xxxxx |
✅ (principalement pour la compréhension vidéo) |
| URL HTTPS publique | https://cdn.example.com/img.jpg |
✅ (support natif depuis Gemini 2.5+) |
URI GCS gs:// |
gs://my-bucket/img.jpg |
✅ (chemin Vertex AI) |
http:// en clair |
http://cdn.example.com/img.jpg |
⚠️ Parfois refusé, passage au HTTPS recommandé |
Chemin local file:// |
file:///Users/me/a.jpg |
❌ |
data:image/...;base64, |
dataURL base64 | ❌ (à placer dans inlineData) |
| URL S3 pré-signée | https://bucket.s3.amazonaws.com/...?X-Amz-... |
✅ |
| URL SAS Azure | https://account.blob.core.windows.net/...?sv=... |
✅ |
Si vous insérez un chemin de fichier local, une chaîne base64 commençant par data: ou une URL de réseau interne privé dans fileUri, vous déclencherez sans exception l'erreur Nano Banana Pro.
Cause 5 : URL accessible mais nécessitant une authentification / ne renvoyant pas d'image
La dernière catégorie concerne les cas où "l'URL semble correcte, mais Gemini ne peut pas récupérer le contenu". Situations fréquentes :
- Le lien privé OSS / Qiniu / Cloudinary n'a pas les permissions publiques, Gemini reçoit une erreur 403 ;
- L'URL temporaire signée a expiré ;
- L'URL ne renvoie pas une image, mais une page HTML (par exemple, la "page de partage" d'un hébergeur d'images, et non le lien direct) ;
- L'URL redirige vers une page de connexion ;
- Le type MIME ne correspond pas au champ
mimeType.
Ces problèmes sont parfois signalés sous la forme Unsupported file URI type, ou parfois sous une autre erreur 400 Invalid or unsupported file uri. La solution est la même pour les deux : accédez directement à cette URL via une fenêtre de navigation privée pour vérifier si vous pouvez télécharger une image valide. C'est la méthode la plus simple et la plus efficace.
Reproduction minimale et solution unique pour l'erreur Nano Banana Pro
Après avoir passé en revue les 5 causes principales, voici le code de reproduction minimale + la version corrigée pour chaque scénario, que vous pouvez copier directement dans votre flux de travail ou votre backend.
Correction 1 : Transmettre correctement le paramètre imageUrls dans n8n
Si vous rencontrez cette erreur Nano Banana Pro et que vous utilisez le nœud HTTP Request de n8n, voici la syntaxe correcte :
Configuration du nœud HTTP Request :
- Method :
POST - URL :
https://api.apiyi.com/v1/messages(remplacez par votre adresse de service proxy API APIYI) - Authentication : Header Auth (insérez votre clé API)
- Body Content Type :
JSON - Specify Body : Sélectionnez
Using JSON(au lieu de Using Fields) - JSON Body (attention, utilisez le mode expression pour tout le bloc JSON, le bouton fx violet à gauche doit être activé) :
={
"model": "gemini-3-pro-image-preview",
"contents": [
{
"parts": [
{ "text": "Transforme cette image dans le style de Miyazaki" },
{
"fileData": {
"fileUri": "{{ $json.imageUrls }}",
"mimeType": "image/jpeg"
}
}
]
}
]
}
3 points clés à retenir :
- Le signe
=au début de la chaîne JSON indique à n8n qu'il s'agit d'une expression à analyser ; "{{ $json.imageUrls }}"doit être entouré de guillemets doubles pour que le contenu{{ }}soit remplacé par la chaîne réelle ;- Le nœud précédent doit impérativement renvoyer un champ nommé
imageUrls; si le nom estimageUrl(singulier) ouimage_url, ajustez le nom du champ en conséquence.
Si ces 3 conditions sont remplies, l'erreur Unsupported file URI type disparaîtra immédiatement.
Correction 2 : Éviter les fautes de frappe dans les noms de champs (Python / Node.js)
Si vous utilisez du code backend, nous vous recommandons d'ajouter une validation d'entrée pour détecter les erreurs avant l'invocation du modèle Gemini :
import requests
def call_nano_banana_pro(prompt: str, image_url: str):
# Validation défensive : intercepter les None / chaînes vides / chaînes de template avant l'envoi
if not image_url or not isinstance(image_url, str):
raise ValueError(f"image_url doit être une chaîne non vide, valeur actuelle : {image_url!r}")
if image_url.startswith("{{") or "undefined" in image_url:
raise ValueError(f"image_url semble être une variable de template non rendue : {image_url}")
if not image_url.startswith(("https://", "gs://")):
raise ValueError(f"image_url doit commencer par https:// ou gs:// : {image_url}")
payload = {
"model": "gemini-3-pro-image-preview",
"contents": [{
"parts": [
{"text": prompt},
{"fileData": {
"fileUri": image_url,
"mimeType": "image/jpeg"
}}
]
}]
}
resp = requests.post(
"https://api.apiyi.com/v1/messages",
headers={"Authorization": "Bearer VOTRE_CLE_API"},
json=payload,
timeout=120
)
return resp.json()
Cette approche "valider avant d'envoyer" permet d'intercepter 90 % des erreurs Nano Banana Pro avant l'appel, évitant ainsi de polluer les logs d'erreur côté Gemini.
Correction 3 : Découper correctement les images multiples en plusieurs parts
Si vous devez transmettre plusieurs images de référence à Nano Banana Pro (par exemple pour une migration de style + verrouillage de personnage), la méthode correcte consiste à créer des éléments parts distincts pour chaque image, au lieu d'insérer un tableau dans fileUri :
// ✅ Syntaxe correcte
const imageUrls = [
"https://cdn.example.com/style.jpg",
"https://cdn.example.com/person.jpg"
];
const payload = {
model: "gemini-3-pro-image-preview",
contents: [{
parts: [
{ text: "Dessine le personnage de la deuxième image dans le style de la première" },
...imageUrls.map(url => ({
fileData: { fileUri: url, mimeType: "image/jpeg" }
}))
]
}]
};
const resp = await fetch("https://api.apiyi.com/v1/messages", {
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": "Bearer VOTRE_CLE_API"
},
body: JSON.stringify(payload)
});
Cette méthode évite non seulement l'erreur Unsupported file URI type, mais permet également à Gemini de mieux comprendre la relation sémantique entre les images.
Correction 4 : Utiliser le base64 en ligne pour les URL inaccessibles
Si l'URL obtenue provient d'un bucket privé, d'un réseau interne ou d'une URL temporaire, les serveurs de Gemini pourraient ne pas être en mesure de la récupérer. La solution la plus fiable est d'utiliser inlineData + base64 :
import base64
import requests
def call_with_base64(prompt: str, local_path: str):
with open(local_path, "rb") as f:
b64 = base64.b64encode(f.read()).decode("utf-8")
payload = {
"model": "gemini-3-pro-image-preview",
"contents": [{
"parts": [
{"text": prompt},
{"inlineData": {
"mimeType": "image/jpeg",
"data": b64
}}
]
}]
}
return requests.post(
"https://api.apiyi.com/v1/messages",
headers={"Authorization": "Bearer VOTRE_CLE_API"},
json=payload
).json()
Note : inlineData utilise le champ data (base64 pur, sans le préfixe data:image/jpeg;base64,), tandis que fileData utilise fileUri. Ces deux champs sont mutuellement exclusifs, ne les remplissez pas simultanément.
🎯 Conseil de stabilité : Pour les scénarios où la source de l'URL est incontrôlable (ex: téléchargements clients / API tierces), nous recommandons d'utiliser par défaut l'encodage base64 pour le génération d'images (image vers image) et de passer par une plateforme de service proxy API comme APIYI (apiyi.com) pour invoquer
gemini-3-pro-image-preview, afin d'éviter les refus intermittents d'URL externes par Gemini dus à des problèmes de réseau ou de droits.
Liste de contrôle pour le dépannage de l'erreur Nano Banana Pro
Voici une liste de contrôle "5 minutes" pour diagnostiquer rapidement l'erreur Unsupported file URI type.
Liste de contrôle de dépannage (5 min)
| Étape | Action | Résultat attendu |
|---|---|---|
| 1 | Copiez la valeur littérale après Unsupported file URI type: dans le message d'erreur |
Obtenir la valeur fileUri réellement reçue par Gemini |
| 2 | Vérifiez si cette valeur contient {{, undefined, null, [ |
Si oui → 90 % de chances que ce soit un template non rendu ou une erreur de champ |
| 3 | Ouvrez cette URL directement dans une fenêtre de navigation privée | Attendu : téléchargement d'une image JPEG/PNG/WEBP valide |
| 4 | Vérifiez si le protocole de l'URL est https:// ou gs:// |
Sinon → changez le protocole ou passez au base64 |
| 5 | Vérifiez s'il s'agit d'un bucket privé, d'une signature expirée ou d'une redirection | Si oui → utilisez une URL publique ou passez au base64 |
| 6 | Testez avec le même modèle + une image publique connue sur la console APIYI (apiyi.com) | Succès → le problème vient du client ; Échec → contactez-nous |
En suivant ces 6 étapes, vous pourrez identifier la cause profonde de pratiquement n'importe quelle erreur Nano Banana Pro.
FAQ sur l'erreur "Unsupported file URI type" de Nano Banana Pro
Q1 : Pourquoi le message d'erreur affiche-t-il littéralement {{ $json.imageUrls }} ?
Parce que lorsque l'API Gemini reçoit la requête, elle renvoie la valeur du champ fileUri telle quelle dans le message d'erreur. C'est le comportement standard de Google, conçu pour vous aider à identifier rapidement ce que vous avez réellement envoyé. Si vous voyez un littéral ressemblant à {{ ... }}, c'est que la variable de modèle de votre workflow low-code n'a pas été rendue. S'il affiche undefined ou null, il s'agit d'une erreur de frappe dans le nom du champ. Je vous conseille de tester d'abord un appel réussi sur APIYI (apiyi.com) avec une URL publique fixe, puis d'aligner votre client sur ce corps de requête fonctionnel.
Q2 : Quelles URL sont réellement supportées par Nano Banana Pro / gemini-3-pro-image-preview ?
Selon la documentation officielle de Google, fileUri accepte 4 types d'URI : les chemins File API (https://generativelanguage.googleapis.com/files/...), les URL YouTube (principalement pour l'analyse vidéo), les URL HTTPS publiques (y compris S3 Pre-signed et Azure SAS) et les URI GCS gs://. Les modèles Gemini 2.5 et supérieurs supportent nativement les URL HTTPS publiques, donc gemini-3-pro-image-preview ne nécessite pas de téléverser l'image vers File API avant l'invocation du modèle.
Q3 : Que faire si {{ $json.imageUrls }} n'est pas rendu dans n8n ?
Il y a trois points de vérification courants : premièrement, le JSON Body du nœud HTTP Request doit avoir le mode expression activé (un signe = devant le JSON ou le bouton "fx" allumé) ; deuxièmement, le chemin du champ doit correspondre à la sortie réelle du nœud précédent (vérifiez le panneau "Output" après un "Execute Node" dans n8n) ; troisièmement, si vous utilisez un sous-nœud, l'expression ne prend par défaut que le premier élément. Utilisez le nœud principal ou un nœud "Item Lists" pour aplatir les données au préalable.
Q4 : Comment corriger une erreur indiquant undefined ?
Cela signifie que vous essayez d'accéder à un champ inexistant dans votre code. La correction la plus rapide consiste à ajouter une assertion avant d'appeler Gemini : assert image_url is not None and isinstance(image_url, str). Ensuite, vérifiez le nom du champ dans la réponse de l'interface amont. Les erreurs de frappe courantes incluent imageUrls vs imageUrl, image_url vs imageUrl, ou url vs uri. En production, je recommande de bloquer les chaînes qui ne sont pas en https ou gs avant l'envoi, comme dans l'exemple de code Python de la "Correction 2".
Q5 : Peut-on insérer plusieurs images directement dans fileUri ?
Non. fileUri n'accepte qu'une chaîne unique. Pour transmettre plusieurs images, la méthode correcte consiste à créer un nouvel élément { "fileData": { "fileUri": "...", "mimeType": "..." } } pour chaque image, puis à les placer toutes dans le même tableau parts. C'est ainsi que Gemini pourra correctement identifier les relations sémantiques entre les images.
Q6 : Que faire si les URL de buckets privés ou temporaires ne peuvent pas être rendues publiques ?
La solution de repli la plus robuste est d'utiliser inlineData + base64 : lisez l'image de votre côté, encodez-la en base64 et insérez-la directement dans le corps de la requête. Cela évite au serveur Gemini d'aller chercher des ressources externes, contournant ainsi tous les problèmes d'échec d'authentification, de signature expirée ou de MIME non reconnu. Le compromis est que le corps de la requête sera plus volumineux, ce qui convient aux scénarios d'image unique de petite taille. Si vous faites de la génération d'images à haute concurrence, il est toujours recommandé de téléverser l'image sur un CDN accessible publiquement, puis d'appeler gemini-3-pro-image-preview via APIYI (apiyi.com). Cela évite l'augmentation de taille due au base64 et facilite la mise en cache et les tentatives de nouvelle connexion au niveau de la plateforme.
Résumé : Bonnes pratiques après la correction d'erreur Nano Banana Pro
Concernant l'erreur spécifique Nano Banana Pro rencontrée par le client : Unsupported file URI type: {{ $json.imageUrls }}, nous pouvons affirmer avec certitude que ce n'est pas un problème lié à Gemini, mais au fait que n8n / le workflow low-code n'a pas remplacé la variable de modèle par l'URL réelle, ce qui a entraîné l'envoi du littéral {{ ... }} complet à l'API Gemini. La méthode de correction est indiquée dans la "Correction 1" : il suffit d'activer le mode expression dans le JSON Body du nœud HTTP Request et de confirmer que le nœud précédent produit bien le champ imageUrls.
De manière plus générale, l'erreur Unsupported file URI type révèle un problème très courant : de nombreuses équipes omettent une couche de "validation des entrées" lors de l'appel aux API d'image, ce qui rend difficile la distinction entre un problème de modèle, de réseau ou de paramètre lorsque Gemini rejette la requête. La liste de contrôle de dépannage, le code de validation Python et la syntaxe d'expression n8n fournis dans cet article peuvent être adoptés comme procédures standards par votre équipe.
🎯 Conseil final : Si vous construisez un workflow de génération d'images basé sur gemini-3-pro-image-preview pour vos clients, nous vous suggérons de centraliser tous les appels Nano Banana Pro via une plateforme de service proxy API comme APIYI (apiyi.com). Cela permet non seulement de reproduire et de comparer rapidement les requêtes échouées dans la console, mais aussi de basculer de manière transparente vers des modèles équivalents comme Nano Banana 2 ou Seedream en cas de panne chez Google, permettant ainsi de localiser et de corriger immédiatement les erreurs de paramètres telles que Unsupported file URI type.
Auteur : APIYI Team ｜ Passionnés par le déploiement de grands modèles de langage et l'ingénierie de stabilité. Pour plus de guides pratiques sur Gemini et les API d'image, visitez APIYI (apiyi.com).
