Supabase "Bucket not found" : les trois choses que cela veut dire

Votre application affiche une image cassée là où une photo devrait se trouver. Ou bien un upload échoue, et le message qui revient tient en trois mots : "Bucket not found". Vous ouvrez alors Supabase, vous allez dans Storage, et le bucket est bien là, dans la liste.

Ouvrez l'adresse de l'image dans un onglet à part et Storage répond ceci :

{
  "statusCode": "404",
  "code": "NoSuchBucket",
  "error": "Bucket not found",
  "message": "Bucket not found"
}

C'est le corps que construit aujourd'hui le code source de Supabase Storage, lu le 17 octobre 2026. Supabase "Bucket not found" couvre trois situations différentes avec ce même corps, et dans la première, le bucket est exactement là où vous l'avez laissé.

Et c'est là que guide après guide se trompe : la première solution que vous trouverez consiste à rendre le bucket public, et quand elle marche, elle marche parce que chaque fichier de ce bucket devient public lui aussi. Pour deux des trois causes, elle ne change absolument rien. Pour la dernière, elle échange une image cassée contre un bucket que peut lire quiconque détient l'adresse d'un fichier.

Que signifie Supabase "Bucket not found" ?

Storage a cherché un bucket portant exactement le nom de votre requête, dans le projet atteint par cette requête, et n'en a trouvé aucun qu'il accepterait de servir à cette requête.

Cette dernière précision est là parce qu'un bucket a plus d'une porte, et que chaque porte pose la question à sa façon. Le code source de Storage en montre trois :

• Une adresse de fichier publique, celle que fabrique getPublicUrl. Cette porte ne compte que les buckets marqués publics, donc un bucket privé y est "introuvable" alors qu'il existe.
• Un upload. Cette porte compte tous les buckets du projet, privés compris. "Introuvable" veut dire ici que ce nom est vraiment absent de ce projet.
• Une demande de la liste des fichiers d'un bucket. Cette porte ne dit jamais "Bucket not found". Un bucket qui n'existe pas répond par une liste vide, la même réponse qu'un bucket vide, ce que nous voyons de l'extérieur à chaque fois que notre scanner pose la question.

Le premier travail consiste donc à savoir par quelle porte la requête en échec est passée.

Les deux nombres de ce message se contredisent, et cela trompe la gestion des erreurs. Le corps dit "statusCode": "404", alors que la requête elle-même échoue avec le statut HTTP 400. Storage envoie cette erreur avec un 400 et garde son propre 404 dans le corps. La bibliothèque supabase-js transmet les deux à votre code : error.status vaut 400 et error.statusCode vaut "404". Un code que votre builder a écrit pour attraper un 404 laissera passer celui-ci.

Cause 1 : un lien public vers un bucket privé

C'est la cause des images cassées. L'adresse a été construite pour un bucket public, et le bucket est privé.

getPublicUrl ne demande rien à Supabase. Elle assemble l'adresse de votre projet, le nom du bucket et le nom du fichier en un lien, dans votre application, et vous le rend. La note placée au-dessus de cette fonction, dans la propre bibliothèque client de Supabase, le dit en deux phrases :

Cette fonction ne vérifie pas si le bucket est public. Si une URL publique est créée pour un bucket qui n'est pas public, vous ne pourrez pas télécharger le fichier.

Plus tard, le navigateur d'un visiteur demande ce lien, et Storage cherche le bucket uniquement parmi les buckets publics. Un bucket privé échoue à cette recherche exactement comme un bucket absent, et la réponse est "Bucket not found".

Vous pouvez reconnaître cette cause au lien lui-même. Une adresse de fichier publique contient /storage/v1/object/public/ suivi du nom du bucket. Si ce bucket ne porte aucune mention publique dans Storage → Buckets, le lien ne pouvait pas s'ouvrir, quelle que soit l'orthographe du nom.

Les nouveaux buckets démarrent privés, le réglage se comporte donc comme prévu. Ce qui s'est passé, c'est que vous ou votre builder avez écrit du code pour un bucket public et l'avez dirigé vers un bucket privé.

Cause 2 : un nom qui n'est pas tout à fait celui du bucket

Storage compare le nom du bucket caractère par caractère, donc Avatars et avatars sont deux buckets différents, tout comme avatar et avatars.

Dans le code source de Storage, la recherche est une simple égalité sur l'id du bucket. Les majuscules comptent, une lettre manquante compte, et un tiret là où le bucket a un tiret bas compte. Chacun de ces cas revient sous les mêmes trois mots.

Une application construite avec un outil d'IA peut arriver ici sans que personne n'ait fait de faute de frappe. Le code qui envoie ou affiche un fichier est écrit à une étape, et le bucket qu'il nomme est censé être créé à une autre. Si cette seconde étape n'a jamais eu lieu, ou a eu lieu avec un nom légèrement différent, le code demande un bucket que personne n'a créé.

La vérification demande deux listes. Ouvrez Storage → Buckets et notez le nom de chaque bucket exactement tel qu'il apparaît. Puis dites à votre builder, avec des mots simples : liste chaque nom de bucket Storage que cette application utilise, et montre-moi où chacun est utilisé. Tout nom de sa liste qui manque dans la vôtre est celui qui échoue.

Cause 3 : le bucket est dans un autre projet

Votre application parle à un seul projet Supabase, celui de son adresse Supabase, et un bucket créé dans n'importe quel autre projet n'existe tout simplement pas pour votre application.

C'est sur un upload que cette cause se voit le plus clairement. Lors d'un upload, Storage cherche le bucket dans tout le projet sans appliquer vos règles d'accès, donc "Bucket not found" sur un upload n'est jamais un problème de permissions. Quand le bucket existe et que vos règles refusent le fichier, Storage répond par un autre message, qui parle de row-level security. "Bucket not found" sur un upload veut donc dire que ce nom est absent du projet dans lequel écrit votre application.

Il y a des façons très ordinaires de se retrouver avec deux projets : un projet de test à côté du projet en production, une copie de l'application branchée sur un projet neuf, un projet créé à la main pour essayer quelque chose. Le bucket est créé dans celui qui se trouvait ouvert dans le tableau de bord à ce moment-là.

La vérification consiste à comparer deux courtes chaînes. L'adresse Supabase de votre application ressemble à https://<ref>.supabase.co, et la partie avant .supabase.co est la référence du projet. L'adresse de votre tableau de bord porte la même référence après /project/. Si les deux diffèrent, vous regardez un projet pendant que votre application parle à un autre.

Faut-il rendre le bucket public pour corriger l'erreur ?

Seulement si chaque fichier du bucket est destiné à quiconque possède son adresse, et seulement pour la première cause. Pour un mauvais nom ou un mauvais projet, l'interrupteur ne change rien.

Un bucket public fait une seule chose, et la documentation de Supabase la décrit en une ligne : quiconque possède l'adresse d'un fichier peut l'ouvrir. Aucune connexion n'entre en jeu. Les propres exemples de Supabase sont les photos de profil, les médias publics et le contenu d'articles de blog, et les logos ou les photos de produits appartiennent au même groupe.

C'est le mauvais réglage pour des factures, des scans de pièces d'identité, des exports, ou tout ce qui appartient à une seule personne. L'interrupteur s'applique au bucket entier et à chaque fichier qui y arrivera plus tard, y compris les fichiers d'une fonctionnalité que vous n'avez pas encore construite.

Le même raccourci a un jumeau du côté des règles, et c'est celui que nous mesurons. Une règle sur storage.objects qui ne nomme que le bucket fait marcher les téléchargements pour tout le monde, et elle livre aussi la liste des noms contenus dans le bucket. Nous avons scanné 8 435 applications en ligne qui nomment un projet Supabase. La vérification des buckets a obtenu une réponse sur 4 703 d'entre elles, et 792 ont répondu à notre demande de liste avec les noms de ce qui se trouvait à l'intérieur, sans que personne soit connecté. Cela fait environ une sur six des applications que nous avons pu interroger. Quand un bucket est public et que sa liste est ouverte aussi, chaque nom de cette liste est un lien qui fonctionne.

Comment afficher un fichier privé sans le rendre public

Donnez à la page un lien signé : une adresse qui fonctionne pendant un nombre de secondes que vous choisissez, puis cesse de fonctionner.

La documentation de Supabase cite deux façons de sortir un fichier d'un bucket privé. L'une est un téléchargement qui transporte la session de la personne connectée. L'autre est createSignedUrl, qui fabrique un lien "accessible pendant une durée limitée". C'est cette seconde façon qui remplace getPublicUrl partout où une page affiche une image.

Un lien signé reste soumis à vos règles. Avant que Storage ne signe quoi que ce soit, son code source vérifie que la personne qui demande a le droit de lire ce fichier, donc un bucket privé a besoin d'une règle select sur storage.objects qui dit qui peut lire quoi. L'erreur d'upload explique comment ces règles s'écrivent, y compris pourquoi une règle de lecture qui ne nomme que le bucket ouvre aussi sa liste.

Pour confier cela à votre builder, avec des mots simples : pour le bucket qui provoque l'erreur "Bucket not found", remplace getPublicUrl par createSignedUrl, garde le bucket privé, et ajoute une policy Storage qui ne laisse chaque personne lire que les fichiers qu'elle doit voir. Rechargez ensuite la page qui avait l'image cassée.

Ce que vos buckets montrent aux inconnus en ce moment

Deux écrans du tableau de bord vous disent ce que vous avez réglé, et une vérification depuis l'extérieur vous dit ce qu'obtient un inconnu.

Storage → Buckets montre quels buckets sont publics. Pour chacun d'eux, demandez-vous si chaque fichier qu'il contient est quelque chose que vous montreriez à un inconnu. Storage → Policies montre les règles. Une règle select dont la seule condition est le nom du bucket permet à n'importe qui de lire ce bucket, liste des fichiers comprise.

Notre scan gratuit demande à votre projet en ligne la liste des fichiers de chaque bucket en n'utilisant que la clé déjà présente dans le code de votre application, comme le ferait un inconnu, et vous dit quels buckets ont répondu avec des noms. Il lit des noms et ne télécharge jamais de fichier. Il prend environ 20 secondes et ne demande aucun compte : scannez votre application.

Garder vos fichiers là où vous les avez mis

Deux choses peuvent encore bouger après la correction d'aujourd'hui : un réglage basculé pendant que quelqu'un poursuit un autre bug, et un fichier supprimé dont quelqu'un avait besoin.

Reeve Monitor continue de vérifier depuis l'extérieur :

• la vérification de sécurité complète, relancée selon un calendrier, y compris celle de la liste des buckets
• si votre application répond
• un message quand un résultat change, pour qu'un bucket ouvert pendant la nuit n'attende pas que vous alliez voir
• un rapport mensuel, en langage clair, de ce qu'il a vu

Reeve Care garde une copie de ce qu'il y a dedans :

• une copie chiffrée de votre base de données Supabase selon un calendrier, sur le stockage propre de Reeve dans l'UE, en dehors de votre compte Supabase
• chaque copie vérifiée avant de compter, en comptant les lignes de chaque table
• vos fichiers envoyés aussi, dès que vous connectez un accès Storage
• une restauration en un clic, avec une copie de sécurité de l'état actuel prise d'abord
• tout ce que fait Monitor

Ce qu'il faut faire aujourd'hui

Commencez par la requête qui a échoué, car la porte qu'elle a empruntée vous dit laquelle des trois causes vérifier. La checklist de sécurité en 10 minutes couvre ce qu'une application tout juste lancée laisse souvent ouvert par ailleurs, et ce qu'expose un bucket public est la lecture suivante si l'un de vos buckets s'est révélé public.