Connecter Supabase à un tableau de bord

Supabase distribue deux familles de clés, et le choix n'est pas une préférence : il décide de ce qui arrive en cas de fuite.

La clé publique — anondans l'ancien format, publishabledans le nouveau — est conçue pour être lue par n'importe qui. Elle est déjà dans le JavaScript envoyé aux navigateurs de vos visiteurs. Elle ne donne accès qu'à ce que vos politiques de sécurité au niveau des lignes autorisent.

La clé secrète — service_role ou secret— ignore totalement ces politiques. Elle lit et écrit tout, dans toutes les tables. Elle n'a rien à faire dans un navigateur, ni dans un dépôt, ni dans une conversation. Si elle fuit, la seule réponse est de la révoquer immédiatement.

Pour un tableau de bord, la règle est simple : la clé secrète ne sort jamais du serveur. C'est lui qui interroge la base et n'envoie au navigateur que le résultat agrégé — un nombre d'inscrits, pas la liste des inscrits.

La tentation est d'interroger directement users ou orders. Cela fonctionne le premier jour et se retourne contre vous au premier changement de schéma : renommer une colonne casse le tableau de bord, et ajouter une colonne sensible l'expose sans que personne y pense.

Créez plutôt des vues qui ne contiennent que ce que le tableau de bord doit voir. Une vue stats_inscriptionsqui renvoie une date et un compte n'expose aucune adresse e-mail, aucun mot de passe haché, aucune donnée personnelle. Le jour où vous restructurez la table, vous adaptez la vue et rien d'autre ne bouge.

Cette indirection a un second mérite : elle vous force à décider ce que vous voulez mesurer. Une vue par question — les inscriptions par jour, les comptes actifs à trente jours, les projets créés — se lit et se corrige, là où une requête improvisée dans un écran ne se relit jamais.

Le contrôle d'accès de Supabase — la row level security— n'est actif que si vous l'avez activé table par table. Une table sans politique et sans RLS est lisible par toute personne disposant de la clé publique, donc par tout visiteur de votre site.

Le tableau de bord Supabase signale ces cas dans ses avis de sécurité. Prenez trente secondes pour les lire avant de brancher quoi que ce soit : c'est le moment où l'on découvre qu'une table de test créée six mois plus tôt est ouverte à tous les vents.

Attention à une subtilité fréquente : activer la RLS sansécrire de politique ne protège pas, cela bloque tout — ce qui a l'avantage d'être bruyant. En revanche, une politique du type using (true)annule la protection tout en donnant l'impression qu'elle existe. C'est le pire des deux mondes.

Une base contient des milliers de chiffres et trois ou quatre indicateurs utiles. Pour un produit en ligne, ceux qui reviennent toujours :

Les inscriptions par jour. La mesure la plus simple, et celle qui réagit le plus vite à ce que vous faites — une page modifiée, un article publié, une mention quelque part.

Les comptes actifs. Combien de personnes se sont servies du produit dans les trente derniers jours. Rapporté au nombre total de comptes, ce ratio dit si vous avez des utilisateurs ou seulement des inscrits.

Le premier geste utile.Chaque produit a une action qui sépare celui qui reste de celui qui part : créer un projet, inviter quelqu'un, connecter un outil. Mesurer la part des inscrits qui la franchissent en dit plus long que n'importe quel total.

Rapprochés de vos revenus et de votre trafic, ces trois chiffres suffisent à savoir si un mois s'est bien passé. Voir aussi analytics et visites pour le versant comportemental, et suivre son MRR Stripe pour le versant financier.

Un écran qui interroge la base à chaque affichage paraît anodin tant qu'on est seul à le regarder. Ouvert dans un onglet laissé en arrière-plan, rafraîchi toutes les trente secondes, il devient une charge permanente sur la base qui sert vos utilisateurs — et la facture Supabase suit.

Deux gestes suffisent à l'éviter. Le premier : compter côté base plutôt que côté écran. select count(*)renvoie un nombre ; charger dix mille lignes pour les compter dans le navigateur transfère dix mille lignes. Le second : mettre le résultat en cache quelques minutes. Un compteur d'inscriptions n'a pas besoin d'être exact à la seconde — personne ne prend de décision sur la base d'une inscription survenue il y a quarante secondes.

Vérifiez aussi vos index. Une vue qui filtre sur une date sans index sur cette colonne balaie la table entière à chaque appel : imperceptible à mille lignes, coûteux à cent mille. Supabase signale ces manques dans ses avis de performance, au même endroit que les avis de sécurité.

Le scan public d'Edificia reconnaît Supabase sur votre site sans que vous ayez à le déclarer. Vous renseignez ensuite votre clé une fois, dans l'onglet Configuration du projet, et les chiffres rejoignent vos revenus Stripe, votre trafic et vos positions Google sur le même écran.

La clé est chiffrée avant stockage et n'est jamais renvoyée au navigateur. Les écrans affichent des agrégats, pas des lignes de vos tables. Le détail des connexions disponibles est sur la page fonctionnalités, et les formules sur la page tarifs.