Suppression de compte dans une application : prévoir un départ sans mauvaises surprises

Un compte peut disparaître alors qu’un rendez-vous reste à honorer

Une personne réserve une consultation, puis décide de quitter l’application qui a servi à prendre rendez-vous. Elle supprime son compte. Le professionnel, lui, conserve le créneau dans son agenda et attend sa venue. Si l’application n’a rien expliqué, chacun peut comprendre une chose différente : fermeture du profil d’un côté, annulation de la réservation de l’autre.

Ce cas fictif montre pourquoi la suppression ne se résume pas à une ligne retirée de la base. Le service comporte des données personnelles, des opérations en cours et parfois des engagements distincts. Une bonne conception commence par identifier ces relations.

Il ne s’agit pas d’utiliser chaque rendez-vous restant comme prétexte pour empêcher le départ. Il faut décider comment traiter l’opération et permettre à la personne de comprendre ce qui continue, ce qui s’arrête et comment obtenir de l’aide. Les règles contractuelles et les obligations de conservation demandent une validation adaptée au pays et au service.

Cet article prépare le parcours produit et ses tests. La politique de confidentialité de l’application doit ensuite décrire le même fonctionnement, sans promettre un effacement que les systèmes ne réalisent pas.

Définir le périmètre avant de choisir les mots

Supprime-t-on le compte personnel, un profil public ou seulement l’accès à une organisation ? Dans un outil utilisé par plusieurs établissements, ces actions n’ont pas les mêmes conséquences. Un praticien qui quitte un cabinet ne souhaite pas nécessairement perdre tous ses autres espaces de travail.

La déconnexion termine une session. La désinstallation retire l’application du téléphone. La résiliation d’un abonnement agit sur une relation de paiement. La suppression du compte concerne le compte et les données associées dans le périmètre applicable. Employer un mot pour en désigner un autre entretient une confusion évitable.

Pour une application de réservation, décrivez concrètement le devenir du profil, des rendez-vous, des pièces jointes et des conversations. Certaines informations peuvent concerner aussi le professionnel ou un autre participant. La décision ne doit pas découler automatiquement d’un lien technique entre deux enregistrements.

Prévoyez une possibilité de récupérer des éléments utiles lorsque cela a du sens : un justificatif, un historique personnel, un document. Proposez-la sans la transformer en passage obligatoire. La personne doit pouvoir choisir de partir sans remplir un dossier supplémentaire simplement pour débloquer le bouton.

Une confirmation utile répond à des questions simples

Avant de confirmer, l’utilisateur doit savoir ce qu’il perd, ce qui sera éventuellement conservé pour une raison précisée et ce qu’il doit gérer séparément. « Cette action est irréversible » peut accompagner l’explication, mais ne la remplace pas.

Dans notre exemple, le texte doit préciser le sort d’un rendez-vous déjà confirmé. Il ne doit pas laisser supposer une annulation si le système ne l’effectue pas. De même, la présence d’un abonnement exige une information correspondant au canal d’achat réel, et non un avertissement générique recopié partout.

Écrivez aussi le bon statut. Si le traitement est en cours, « Votre demande a été reçue » est plus honnête que « Toutes vos données ont été supprimées ». Indiquez comment la personne sera informée et comment elle pourra retrouver son dossier sans devoir recréer un compte.

Une enquête de départ peut être facultative. Un appel commercial imposé, plusieurs écrans de rétention ou un motif obligatoire compliquent en revanche un choix déjà exprimé. L’objectif de la confirmation est d’éviter une erreur, pas d’épuiser la personne jusqu’à ce qu’elle renonce.

Prévoir un accès même après la désinstallation

Pour les applications concernées, Apple demande un point de départ dans l’application et ne considère pas la simple désactivation comme une suppression. Ses indications distinguent aussi les vérifications raisonnables des démarches inutilement compliquées auprès du support.

Google Play prévoit un parcours externe en plus de l’accès dans l’application, dans le champ de sa règle. Ce parcours permet notamment de faire une demande après avoir désinstallé le produit. Une page qui renvoie simplement vers le téléchargement ne répond pas à ce besoin.

La page doit être reconnaissable et permettre réellement d’engager la démarche. Testez-la depuis un téléphone où l’application n’est pas installée. Vérifiez l’envoi, la réception par l’équipe, la confirmation au demandeur et le traitement qui suit. Une adresse accessible ne suffit pas si personne ne s’occupe du formulaire.

Les exigences des magasins ne remplacent pas les lois applicables. Évitez les délais universels et les affirmations de conformité automatique. Pour un service réglementé ou des obligations particulières, faites examiner le processus concret par un conseil qualifié.

L’abonnement possède son propre cycle de vie

Le retour pratique de RevenueCat sur la suppression de compte explique une erreur fréquente : effacer une fiche client ne signifie pas nécessairement arrêter la facturation. Ce texte aide à comprendre le problème, mais il est ancien. Avant de reprendre ses conseils, vérifiez ce que fait aujourd’hui le fournisseur choisi.

La documentation actuelle des profils RevenueCat donne un exemple précis : supprimer une fiche client ne résilie pas automatiquement les abonnements mobiles ni ceux de Stripe Web Payments. Les abonnements RevenueCat Billing sont, eux, résiliés immédiatement. Le cahier des charges doit donc préciser le résultat attendu pour chaque mode d’achat réellement utilisé.

*Effacer les données et gérer les renouvellements sont deux vérifications distinctes. Le fournisseur de paiement détermine leur articulation.*

N’identifiez pas le canal d’achat à partir du seul téléphone actuel. Une personne peut avoir souscrit ailleurs. Le lien de gestion doit l’aider à retrouver le bon service. Une redirection techniquement valide mais sans rapport avec son achat ne résout rien.

Résilier le renouvellement, rembourser et fermer l’accès sont également des décisions différentes. Le guide des applications par abonnement couvre ce modèle plus largement. Ici, l’essentiel est que le départ ne produise ni promesse de remboursement injustifiée, ni silence sur un paiement qui continue.

Suivre les données jusqu’aux prestataires

Demandez à l’équipe une carte simple des lieux où le compte est représenté : authentification, base principale, documents, messagerie, support, notifications et prestataires concernés. Pour chacun, précisez l’identifiant, l’action prévue et le moyen de vérifier son exécution.

La disparition de l’identifiant de connexion ne prouve pas que les pièces jointes ont disparu. Le tutoriel Firebase sur les extensions fournit un exemple concret de nettoyage limité aux données configurées. Il illustre une méthode, pas une garantie d’effacement complet de tout un produit.

Pour une conversation partagée, décidez ce qui reste visible à l’autre personne et ce qui ne doit plus l’être. Examinez aussi les copies chez les prestataires et les pièces conservées dans les outils de support. Un simple remplacement du nom par « utilisateur supprimé » n’apporte pas, à lui seul, une réponse sur toutes les données personnelles présentes.

Lorsqu’une conservation est justifiée, nommez la catégorie, la raison, la durée et les accès autorisés. Une formule comme « nous gardons tout pour respecter nos obligations » ne permet ni au développeur ni à l’utilisateur de comprendre le résultat. Pensez également aux sauvegardes : une restauration ne doit pas remettre silencieusement en service les comptes supprimés.

Le traitement doit pouvoir reprendre après un échec

Une suppression peut nécessiter plusieurs tâches côté serveur. Distinguez au minimum réception de la demande, vérification, traitement et achèvement. Les noms exacts importent moins que l’impossibilité de déclarer terminé un travail encore incomplet.

Supposons que la base ait été nettoyée mais que le stockage des documents soit momentanément indisponible. La tâche restante doit être conservée et relancée sans recréer le profil. La même demande envoyée deux fois doit aboutir au même résultat attendu, sans multiplier les effets ni toucher un autre compte.

Le support a besoin d’un suivi minimal : référence sûre, état et action en attente. Garder une copie intégrale du profil uniquement pour prouver sa suppression serait contradictoire. Les accès à ce suivi et sa conservation doivent eux aussi être décidés.

La sécurité concerne le demandeur et les appareils encore connectés. N’autorisez pas la suppression d’un compte simplement parce que son adresse a été saisie dans un formulaire. Prévoyez une vérification adaptée, sans demander un mot de passe d’application à une personne qui s’est toujours connectée via un fournisseur externe.

Ce point fait partie de la vérification de sécurité de l’application, au même titre que la connexion et la récupération du compte. Examinez également les sessions sur un second appareil et les liens de notification. Pour Sign in with Apple, la documentation d’Apple traite du retrait des jetons associés. Une ancienne session ne doit pas continuer à enregistrer des données sous un compte annoncé comme supprimé.

Accepter la fonction à partir d’un dossier de test

Préparez un compte fictif avec des rendez-vous, des documents et une conversation. Connectez-le sur deux appareils et utilisez l’environnement de test du fournisseur pour les états de paiement. Puis vérifiez le résultat dans les systèmes concernés, pas uniquement sur l’écran final.

Le parcours normal doit se terminer conformément à l’information affichée. Le parcours web doit fonctionner sans réinstallation. Une coupure réseau ne doit pas produire une fausse confirmation. L’indisponibilité d’un prestataire doit laisser une tâche identifiable. Enfin, une connexion ultérieure ou une restauration d’achat ne doit pas faire réapparaître sans explication les anciennes données personnelles.

Intégrez ces scénarios au plan de tests avant publication. Distinguez une nouvelle inscription vide, voulue par la personne, de la résurrection automatique de son ancien profil. Cette différence se décide explicitement, elle ne doit pas être un effet secondaire découvert après la sortie.

Pour préparer ce travail avec Appfyl, rassemblez les modes de connexion, les emplacements des données et les canaux d’achat. Ces éléments donnent un périmètre vérifiable à une demande qui semblait se limiter à un bouton. Le résultat attendu reste simple : la personne comprend son choix et peut constater qu’il a été respecté.

Questions fréquentes