Clés API dans une app Expo : lesquelles garder secrètes ?

Une variable d’environnement n’est pas forcément un secret

Dans une app Expo, une variable préfixée par EXPO_PUBLIC_ est destinée au code de l’application. Elle ne doit pas contenir un secret serveur. Expo explique que ces valeurs sont intégrées au JavaScript compilé et peuvent être lues par les utilisateurs de l’app. Déplacer une clé dans un fichier .env ne suffit donc pas à la protéger. Source : variables d’environnement Expo.

Avant de demander à une IA de « brancher l’API », classe ce que tu lui confies : une adresse de service, une clé prévue pour être publique, ou une clé qui autorise des actions privilégiées. Ce classement détermine où le code doit s’exécuter.

Le tableau suivant est une grille de conception, pas un audit de ton application.

Élément	Où le placer	Vérification à faire
Adresse publique du backend	Configuration de l’app	Elle pointe vers le bon environnement.
Clé Supabase publishable, ou ancienne clé anon	App si les autorisations sont correctement configurées	Les règles de données bloquent réellement l’accès au compte d’un autre utilisateur.
Clé Supabase secret ou service_role	Serveur uniquement	Elle n’apparaît ni dans le bundle mobile, ni dans les journaux accessibles au client.
Clé secrète d’un fournisseur d’IA	Serveur uniquement	L’app appelle ton serveur, qui contrôle l’utilisateur et les limites avant le fournisseur.

Supabase distingue les clés prévues pour les clients des clés secrètes destinées aux environnements de confiance. Une clé publique identifie le projet ; elle ne remplace pas les permissions sur les données. Source : clés API Supabase.

Exemple : une app fictive de carnet de lecture

Imaginons une app dans laquelle Léa et Sami enregistrent leurs livres et leurs notes privées. Cet exemple sert à préparer les tests ; il ne décrit pas des résultats obtenus sur une app Devoria.

Le parcours normal semble correct : Léa se connecte et voit ses notes. Mais cela ne répond pas encore à la question importante : le serveur refuse-t-il une demande de Léa visant une note de Sami ?

Un filtre dans l’interface, comme « afficher les notes de l’utilisateur connecté », améliore l’affichage. L’autorisation doit aussi être appliquée côté données. Dans Supabase, les règles Row Level Security permettent de restreindre les lignes accessibles selon la session. Supabase recommande leur activation pour les tables exposées par l’API et explique les politiques de lecture et d’écriture. Source : Row Level Security.

Pour ton propre projet de test, associe chaque note à son propriétaire et définis séparément qui peut la lire, la créer, la modifier et la supprimer. Vérifie également les fichiers : protéger une ligne de base de données ne prouve pas qu’une image est privée.

La recette à exécuter avec deux comptes de test

Prépare deux comptes que tu contrôles, un livre différent dans chacun et une petite note reconnaissable. Utilise des données fictives dans un environnement de test autorisé.

1. Lire sa note. Le compte A retrouve la note A.
2. Lire la note de B depuis A. La demande ne révèle pas son contenu privé.
3. Modifier la note de B depuis A. Le serveur refuse ; la note B reste inchangée.
4. Créer au nom de B depuis A. Le serveur refuse cette attribution.
5. Lire sans session. Aucun contenu privé n’est retourné.
6. Ouvrir le fichier privé de B depuis A. Le fichier n’est pas accessible.

Consigne le résultat réel, la version testée et l’éventuelle erreur. « Les règles sont activées » n’est pas un résultat de test. La grille de recette disponible dans les ressources peut servir de base pour garder ces preuves.

Faire passer un appel payant par ton serveur

Pour une fonction qui résume un livre avec une API d’IA, le parcours peut être : app → ton serveur → fournisseur → ton serveur → app. La clé secrète reste sur le serveur. Cette architecture ne suffit pas seule : l’accès au serveur doit aussi être contrôlé.

Dans l’exemple fictif, le serveur doit notamment vérifier la session, vérifier que le livre appartient à la personne, limiter les demandes répétées et renvoyer une erreur compréhensible si le fournisseur ne répond pas. Le client ne décide pas lui‑même qu’un utilisateur bénéficie d’un accès payant.

Prépare quatre essais : utilisateur non connecté, livre d’un autre compte, limite atteinte et fournisseur indisponible. Le dernier permet de vérifier que l’app quitte son état de chargement sans perdre la saisie.

Ce que tu peux demander à ton assistant de code

Voici une consigne de revue à adapter à ton dépôt, sans y coller tes valeurs secrètes :

Recense les variables utilisées par le code mobile et par le serveur, en affichant seulement leurs noms. Identifie les appels privilégiés présents côté client. Pour les données privées, décris les contrôles de lecture et d’écriture, puis propose une recette avec deux comptes de test. N’effectue aucune rotation de clé ou modification de production sans validation.

Lis la réponse avec le code correspondant. Un assistant peut repérer une incohérence ; sa réponse ne remplace pas l’exécution des tests. Le guide créer une application avec Claude Code explique comment découper ce travail.

Avant de poursuivre ton app

Tu dois pouvoir expliquer trois choses simplement : quelles valeurs sont publiques, quelles opérations passent par le serveur et quels tests montrent qu’un compte ne voit pas les données d’un autre. Si l’un de ces points reste flou, clarifie-le avant d’ajouter des fonctions.

La page créer une application iPhone replace cette étape dans le projet complet. Pour identifier ton prochain blocage et l’ordre des étapes, fais ton diagnostic gratuit.