For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /fr/docs/mobile/entitlements.md (or send Accept: text/markdown).
Droits d’accès mobiles
Configurez les achats RevenueCat et laissez le serveur décider des accès.
Comprendre l'état d'accès affiché sur votre téléphone
Un droit est l’autorisation d’utiliser une fonctionnalité payante. Il appartient à l'espace de travail actif, le groupe de données de compte que votre équipe utilise. Effectuez d’abord la connexion native, puis ouvrez Paramètres → Facturation de l’application téléphonique. Lire l'état d'accès affiché ; chargement ou une erreur ne signifie pas que vous avez un abonnement.
Avec les achats désactivés, l'application ne devrait pas proposer de paiement en magasin. Pour vendre l'accès, complétez le guide d'achat RevenueCat ci-dessous et testez dans une version de développement native. Après un achat test, rouvrez la facturation et confirmez que le serveur signale un accès actif ; après expiration, confirmez que la fonction est à nouveau verrouillée. Si un achat réussit mais que l'accès ne s'actualise pas, utilisez Restaurer les achats et vérifiez la connexion backend plutôt que d'acheter une seconde fois.
Lire l’accès depuis le serveur
Le client mobile des droits lit l’état détenu par le serveur. Distinguez le chargement ou l’échec d’une requête d’un abonnement actif ; une requête en échec ne doit jamais faire supposer à l’interface que l’accès payant est accordé.
Utilisez la logique de présentation dans apps/mobile/src/entitlements pour traduire cet état dans l’interface native.
Rendre explicite la frontière d’achat
Les achats natifs utilisent RevenueCat lorsqu’il est configuré ; la facturation Web reste une surface distincte. N’exposez pas Stripe Checkout dans l’interface mobile et ne considérez pas un statut actif dans la boutique comme preuve d’accès côté serveur.
Le guide des achats intégrés décrit les clés client, les contrôles de rôle administrateur, l’identité de l’espace de travail, la synchronisation achat/restauration, la vérification serveur et la configuration sandbox. La validation réelle de StoreKit ou Play Billing nécessite une build de développement EAS ; le guide de soumission aux boutiques couvre la publication.
Vérifier les accès refusés et expirés
Testez les états de droit indisponible, inactif et actif, ainsi que les erreurs réseau. Vérifiez que les actions restreintes restent indisponibles lorsque le serveur refuse l’accès et que la déconnexion efface l’affichage de la session précédente.
Pour poursuivre la configuration, consultez Créer les comptes mobiles.