Suppression de compte iOS : le parcours à tester avant Apple

Le bouton ne suffit pas : il faut vérifier ce qui disparaît

Si ton app permet de créer un compte, Apple demande que la personne puisse en lancer la suppression depuis l’app. Une simple désactivation ne remplit pas cette exigence. Le parcours doit être facile à trouver et expliquer ses conséquences. Si une partie se termine sur le Web, le lien doit mener directement à la page concernée. Source : suppression de compte selon Apple.

Le travail ne s’arrête donc pas à un bouton rouge dans les réglages. Il faut inventorier les données, exécuter la suppression côté serveur, traiter les erreurs et vérifier ce que l’utilisateur voit ensuite. Ce guide propose une recette produit et technique ; les données soumises à une obligation de conservation demandent un traitement adapté à ton activité.

Commencer par une carte des données

Prenons une app fictive de carnet de lecture. Elle possède un compte, un profil, des notes privées et des photos de couverture ajoutées par l’utilisateur. L’exemple ci-dessous décrit un plan à vérifier, pas une suppression déjà exécutée sur une app Devoria.

• Identité de connexion : comment rendre le compte inutilisable après la suppression ?
• Profil et notes : quelles lignes appartiennent à cette personne et comment sont-elles supprimées ?
• Photos stockées : quel traitement retire les fichiers et leurs références ?
• Cache du téléphone : l’écran efface-t-il les données locales quand l’opération a réellement abouti ?
• Services tiers : les données liées à ce compte nécessitent-elles une suppression distincte ?
• Données à conserver : lesquelles, pour quelle obligation, et avec quelle information de l’utilisateur ?

Cette carte évite de découvrir après coup qu’une photo reste accessible alors que la fiche utilisateur a disparu. Elle te donne aussi les objets à rechercher dans les tests.

Un parcours lisible en quatre états

Voici une proposition pour l’app fictive, à adapter aux conséquences réelles de ton produit :

1. Réglages du compte. Une entrée « Supprimer mon compte » reste accessible.
2. Confirmation. L’écran décrit les données concernées et présente une action d’annulation aussi compréhensible que l’action de suppression.
3. Traitement. Le bouton évite les doubles demandes et l’interface indique que l’opération est en cours.
4. Résultat. Un succès confirmé ouvre l’état déconnecté. Un échec conserve un message utile et un moyen de réessayer, sans prétendre que le compte a disparu.

Si le traitement prend du temps, Apple accepte un parcours différé à condition d’informer la personne et de confirmer l’achèvement. L’app ne doit pas laisser croire qu’une suppression est terminée quand seule la demande a été enregistrée. La même documentation Apple précise aussi les cas de réauthentification et les exceptions propres aux activités fortement réglementées.

Ce qu’il faut anticiper avec Supabase

La suppression d’un utilisateur Auth ne constitue pas, à elle seule, la preuve que tous les objets de ton produit ont été traités. Supabase explique notamment qu’un utilisateur possédant des objets Storage ne peut pas être supprimé tant que cette situation n’est pas résolue. La documentation signale aussi que supprimer un utilisateur ne déconnecte pas instantanément tous les JWT déjà émis : leur validité doit être prise en compte dans la conception. Source : gestion des utilisateurs Supabase.

Définis donc un traitement serveur qui vérifie l’identité du demandeur et les ressources qui lui appartiennent. Ne te fie pas à un identifiant envoyé librement par le téléphone pour choisir le compte à supprimer. Les droits d’administration restent côté serveur, conformément à la documentation des clés Supabase.

Pour un traitement en plusieurs étapes, décide ce qu’un nouvel essai doit faire si une première étape a réussi et la suivante a échoué. Par exemple, si les fichiers sont déjà retirés, une nouvelle demande ne doit pas échouer uniquement parce qu’ils sont absents. C’est un scénario à écrire avant le test, pas un comportement à supposer.

Compte et abonnement : deux vérifications distinctes

Une personne peut supprimer son compte alors qu’un abonnement Apple continue. Apple demande d’expliquer le devenir de la facturation et de donner accès à la gestion de l’abonnement. Prévois aussi la révocation appropriée des jetons si tu utilises Sign in with Apple. Ces points sont détaillés dans les consignes Apple sur la suppression.

Dans ton plan de test, sépare donc la disparition du compte, l’état d’accès payant et la gestion de l’abonnement. Le guide abonnement ou achat unique aide à replacer ce parcours dans ton modèle commercial.

La recette à exécuter sur une build de test

Utilise uniquement un compte de test et des données fictives. Note la build, l’appareil, le résultat observé et les limites de chaque vérification.

1. Annuler. Le compte et les données restent accessibles.
2. Supprimer un compte rempli. L’état final correspond au traitement annoncé ; les données concernées sont effectivement retirées.
3. Couper le réseau. L’app ne montre pas un succès fictif.
4. Relancer après un échec partiel. La demande peut aboutir sans cibler d’autres données.
5. Ouvrir une seconde session. Les anciens accès sont traités conformément au mécanisme prévu.
6. Recréer un compte avec la même adresse, si autorisé. Les anciennes données privées ne réapparaissent pas.

Ajoute ces cas à la grille de recette Devoria. Pour les distribuer à des testeurs, suis le guide TestFlight. L’absence de message d’erreur dans la console ne remplace pas la vérification des données et du parcours.

Préparer l’envoi à App Review

Dans tes notes de revue, explique où se trouve l’action et comment la tester. Si une étape dépend d’un service, assure-toi qu’il est disponible pendant la revue. N’utilise pas les notes pour promettre une fonction qui n’existe pas encore dans la build envoyée.

La page application refusée par Apple aide à organiser une réponse quand un problème est déjà signalé. Si tu prépares ta première sortie, fais ton diagnostic gratuit pour remettre les étapes dans l’ordre.