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.

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.

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.

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 :

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.