Les nouvelles clés API Supabase : laquelle va dans votre app ?

Si vous avez ouvert votre tableau de bord Supabase récemment et trouvé des clés qui commencent par sb_publishable_ et sb_secret_ là où se trouvaient anon et service_role, rien n'est cassé. Supabase a renommé ses clés API, et la paire que vous connaissiez est en train de sortir.

Le changement est petit dans ce qu'il fait et grand dans ce qu'il évite. Les deux clés remplissent toujours exactement les deux mêmes rôles. Ce qui est nouveau, c'est que vous voyez désormais laquelle est laquelle sans rien ouvrir.

Ce que Supabase a réellement changé

Supabase a annoncé les nouvelles clés en juillet 2025, en même temps qu'un changement dans la façon dont il signe les jetons d'authentification. Deux choses en ont remplacé deux autres :

• La clé publiable, sb_publishable_…, remplace la clé anon.
• Les clés secrètes, sb_secret_…, remplacent la clé service_role.

Les droits sont inchangés. Une clé publiable identifie toujours votre projet et ne porte aucun droit propre ; une clé secrète contourne toujours toutes les règles que vous avez écrites. Si vous savez déjà quelles clés sont sûres dans un frontend, rien de cette intuition n'est devenu faux.

Deux différences pratiques valent d'être connues. Vous pouvez détenir plusieurs clés secrètes à la fois et les révoquer une par une : faire tourner une clé ne signifie donc plus un moment où tout ce qui l'utilisait est cassé. Et les anciennes clés avaient une propriété que presque personne n'avait remarquée : c'étaient des JWT qui expirent dix ans après la création du projet. Les nouvelles ne portent pas d'expiration en elles.

La clé anon est-elle la même que la clé publiable ?

Oui pour ce qu'elle fait, non pour ce qu'elle est.

sb_publishable_… fait exactement le travail de la clé anon : elle nomme votre projet pour qu'une requête sache où aller, elle ne porte aucune permission propre, et elle est faite pour rester dans votre appli où n'importe qui peut la lire. Tout ce que vous aviez compris de la clé anon reste vrai. Si vous remplacez l'une par l'autre, aucune table ne devient plus ou moins lisible, car aucune des deux n'a jamais protégé vos lignes. C'est le rôle de Row Level Security.

Ce qui change, c'est la valeur elle-même. Ce sont des chaînes différentes dans des formats différents, émises séparément, et un projet peut détenir les deux paires en même temps pendant la migration. « La même clé sous un nouveau nom » est donc la mauvaise image. C'est une nouvelle clé pour un ancien travail, et votre appli doit en être informée.

Une conséquence surprend souvent : activer les nouvelles clés ne bascule pas votre appli. Supabase les émet et laisse votre appli tourner avec ce que vous lui avez donné. Le changement est une modification d'une ligne que vous faites vous-même, là où votre appli crée son client Supabase.

Laquelle des deux a sa place dans votre application

La clé publiable, et elle seule.

Votre application tourne dans le navigateur de votre visiteur, et la requête vers votre base part de là. Elle doit dire à quel projet elle appartient, et cet identifiant parvient à chaque visiteur par conception. sb_publishable_… est la clé construite pour cela : la trouver dans votre application n'est pas un problème, et ne l'a jamais été.

sb_secret_… est l'inverse. Elle lit et écrit chaque ligne de chaque table depuis n'importe où, en ignorant entièrement vos politiques, et c'est toute sa raison d'être. Sa place est sur un serveur, dans une edge function, dans un worker : nulle part où un navigateur peut aller. Si l'une a déjà été collée dans du code frontend, renouvelez-la dans le tableau de bord avant de modifier quoi que ce soit : supprimer la ligne ne ferme pas la porte.

À quoi ressemble une clé sb_publishable_ ?

Une seule chaîne continue qui commence par le littéral sb_publishable_, suivi d'un milieu aléatoire. Aucun point dedans, et rien à l'intérieur que vous puissiez décoder. Sa contrepartie secrète se lit pareil, avec sb_secret_ devant.

L'ancienne paire ne ressemble en rien à cela. anon et service_role sont des JWT : trois blocs séparés par des points, longs de quelques centaines de caractères, commençant par eyJ. Le bloc du milieu n'est pas chiffré, seulement encodé, donc n'importe qui peut le coller dans un décodeur et lire le champ role à l'intérieur. C'est ainsi qu'on distinguait les deux avant, et c'est pourquoi tant de gens ne l'ont jamais fait.

Lire les quinze premiers caractères, c'est toute la vérification aujourd'hui. La clé dangereuse s'annonce dans la partie de la chaîne où votre œil se pose en premier, plutôt qu'au milieu de quelque chose qu'il faut ouvrir.

Comment savoir laquelle vous avez

Lisez les premiers caractères. C'est désormais toute la vérification.

Une clé actuelle est une longue chaîne en deux moitiés : un milieu aléatoire et une courte somme de contrôle à la fin. Une ancienne clé est faite de trois blocs séparés par des points, et celui du milieu est du texte lisible plutôt que du chiffrement, ce qui est la raison pour laquelle distinguer l'ancienne paire supposait de la décoder et de lire le champ role.

Si vous trouvez une clé dans votre application sans savoir laquelle c'est, notre scan gratuit lit votre site en ligne depuis l'extérieur et nomme ce qu'il voit. Cela prend une vingtaine de secondes et ne demande aucun compte : scanner votre application.

Mes anciennes clés anon et service_role fonctionnent-elles encore ?

Aujourd'hui, oui. Supabase a publié un calendrier, pas un interrupteur :

Il n'y a donc pas d'urgence cette semaine, et il y a une échéance cette année. Si votre application a été construite avant le renommage et n'a pas été touchée depuis, elle tourne en ce moment sur d'anciennes clés et continuera un moment.

L'argument pour bouger tôt n'est pas l'échéance. C'est le jour où quelqu'un colle la mauvaise clé dans un prompt : sb_secret_ s'annonce, eyJ… non.

Que sont les clés API legacy de Supabase ?

Legacy est le nom que Supabase donne aujourd'hui à la paire d'origine, anon et service_role, avec le secret JWT qui les signe. Tout projet créé avant mi-2025 a démarré avec elles, ce qui couvre la plupart des applis vibe-codées.

Elles diffèrent de la nouvelle paire sur des points qui méritent d'être connus. Étant des JWT, elles portent une expiration dix ans après la création du projet, logée dans la clé là où personne ne regarde. Elles ne peuvent pas être renouvelées du tout : Supabase a indiqué que renouveler les secrets legacy anon, service_role et JWT n'est plus possible, donc invalider une clé fuitée revient à passer aux nouvelles clés et à désactiver l'ancienne paire. Et un projet restauré après le 1er novembre 2025 ne les reçoit tout simplement pas.

Si l'une des vôtres a déjà fuité, cette migration est le seul moyen de l'invalider, et l'ordre dans lequel la mener dépend de si la clé se trouve déjà dans un bundle que vos visiteurs téléchargent.

Comment changer sans casser votre application

Le guide de migration de Supabase est la référence. La version courte, pour une application que vous n'avez pas écrite à la main, en supposant que vous sachiez déjà trouver la page où vivent vos clés :

1. Dans le tableau de bord, ouvrez Settings → API Keys et créez les nouvelles clés. Cela les ajoute ; cela ne retire pas les anciennes, et les deux paires fonctionnent en même temps.
2. Trouvez l'endroit où votre application crée son client Supabase et remplacez la clé publiable. Dans un builder comme Lovable ou Bolt, c'est en général une valeur dans les réglages du projet plutôt qu'une ligne de code.
3. Remplacez la clé secrète partout où elle est utilisée sur un serveur : edge functions, webhooks, tâches planifiées, tout ce qui n'est pas le navigateur.
4. Chargez votre application et parcourez les parties qui lisent et écrivent des données. Une mauvaise clé publiable échoue immédiatement et bruyamment, ce qui est le bon cas.
5. Une fois seulement que tout marche, désactivez les anciennes clés.

L'étape 5 est celle à garder pour la fin, et elle mérite d'être faite délibérément plutôt que jamais : les projets à moitié migrés, où l'application transporte encore une ancienne clé anon à côté d'une sb_publishable_ active, sont fréquents et déroutants à déboguer.

Que faire cette semaine

Si vous voulez la version propre à la plateforme de ce qu'il faut vérifier, nous avons un guide en langage clair pour les applications Supabase, et la checklist sécurité en 10 minutes couvre ce point à côté des autres choses à désactiver dans une application fraîchement lancée.