La résiliation d’un compte SaaS avec période de grâce n’est pas une simple opération différée. Il s’agit d’un flux de cycle de vie qui doit coordonner les accès, la facturation, les tâches automatisées, les intégrations et les données. Si l’application se contente d’enregistrer une date de clôture et de la vérifier à la connexion, d’autres processus peuvent continuer à fonctionner comme si l’organisation était active.
La conception doit expliciter la signification de chaque étape, les personnes autorisées à effectuer une transition et les effets qui sont réversibles. Ainsi, annuler la demande ne revient pas à reconstruire le compte de zéro, et l’arrivée à la date limite ne dépend pas de la nouvelle connexion d’un utilisateur.
Distinguer la demande, la suspension et la clôture définitive
La demande exprime une intention : une personne autorisée demande la clôture du compte. La suspension détermine ce que l’organisation peut faire pendant le traitement de cette demande. La clôture définitive exécute les actions finales, qui peuvent inclure la révocation des identifiants, l’arrêt des processus et l’application de la politique relative aux données. Ce sont des moments distincts qu’il convient de modéliser séparément.
Le moment auquel les restrictions d’accès commencent est un choix important pour le produit. Si l’accès est maintenu jusqu’à l’expiration, il faut le communiquer clairement et contrôler l’utilisation pendant cette période. Si l’accès est restreint immédiatement, la période de grâce sert à récupérer le compte, et non à continuer à utiliser le service normalement. Il n’existe pas d’option universelle : le choix dépend du modèle commercial, des risques et des obligations du produit.
Les conséquences pour la facturation et les abonnements doivent également être définies. La résiliation du compte n’annule pas nécessairement un abonnement externe, pas plus qu’une annulation de paiement ne doit supprimer une organisation. Précisez la source de vérité pour chaque décision et évitez de déduire l’état opérationnel à partir d’un événement isolé du prestataire de paiement.
Définir les états et les transitions autorisées
Un modèle explicite permet à l’interface, à l’API et aux tâches en arrière-plan d’appliquer les mêmes règles. Un flux simple peut utiliser des états comme active, deletion_requested, suspended et closed. Si la suspension intervient en même temps que la demande, un seul état de demande et des attributs décrivant ses restrictions peuvent suffire. Évitez d’ajouter des états qui ne correspondent pas à une réelle différence opérationnelle.
Documentez les transitions valides. Par exemple, une organisation active peut demander sa résiliation ; une demande en cours peut être annulée ; et une demande dont le délai a expiré peut passer à la clôture définitive. En règle générale, une organisation clôturée ne devrait pas être rouverte au moyen de la même action d’annulation : si une récupération est proposée, elle nécessite une procédure distincte et des limites claires.
- Enregistrez qui a initié la demande, à quel moment, depuis quel canal et à quelle date la période expire.
- Vérifiez les autorisations et l’état actuel côté serveur, et pas seulement dans l’interface.
- Rejetez les transitions répétées et les demandes concurrentes, ou gérez-les explicitement.
- Enregistrez les changements d’état de façon atomique et publiez les effets secondaires à l’aide d’un mécanisme fiable, comme une boîte d’envoi transactionnelle.
Dans une application PHP, centralisez les règles de transition dans un service de domaine ou une couche équivalente. Les contrôleurs ne devraient pas modifier directement plusieurs champs en supposant que tous les consommateurs connaîtront la nouvelle sémantique. La base de données doit conserver suffisamment d’informations pour qu’un processus en attente puisse déterminer l’action à effectuer sans dépendre de l’état d’une requête web antérieure.
Limiter les accès et contenir les processus en attente
Définissez les capacités par rôle pendant la période de grâce. Un administrateur pourrait être autorisé à annuler la résiliation et à consulter les informations nécessaires à leur exportation, tandis que les membres de l’organisation pourraient être bloqués. Si un accès en lecture seule est autorisé, précisez les ressources concernées et indiquez si les API, les téléchargements et les fonctions d’administration restent disponibles. Le même contrôle doit s’appliquer à l’interface, à l’API et aux tâches automatisées.
Bloquer la connexion ne suffit pas. Les jetons d’accès, les clés API, les sessions actives et les identifiants d’intégration peuvent continuer à fonctionner. Décidez lesquels révoquer, lesquels suspendre et lesquels conserver temporairement. Si des identifiants sont révoqués, consignez cet effet afin que la réactivation ne dépende pas de secrets qui n’existent plus ; il peut être nécessaire d’exiger leur régénération.
Examinez les files d’attente et les tâches planifiées : envois, synchronisations, rapports, webhooks et tâches de facturation, par exemple. Chaque processus doit vérifier l’état actuel de l’organisation juste avant d’exécuter une opération ayant des effets externes. Les tâches déjà en file d’attente peuvent être annulées, mises en attente ou menées à terme, selon une politique explicite. Ne supposez pas qu’un changement d’état du compte retire automatiquement les messages d’une file distribuée.
L’annulation d’une tâche doit également être idempotente. Une tâche relancée après une défaillance réseau ne devrait pas dupliquer une notification ni une opération de clôture. Utilisez des identifiants d’événement, des clés d’idempotence ou des contraintes d’unicité appropriés, et consignez les résultats pour distinguer une nouvelle tentative sans risque d’une nouvelle action.
Sécuriser l’annulation de la résiliation et la réactivation
Pendant la période de grâce, annuler la demande devrait être une transition définie, et non une routine qui « annule tout » sans vérifier ce qui s’est passé. L’opération doit vérifier que le délai n’a pas expiré, mettre à jour l’état une seule fois et rétablir uniquement les capacités qui avaient été suspendues et qui restent valides.
Pour éviter les doublons, ne recréez pas systématiquement les abonnements, les webhooks, les tâches planifiées, les espaces de travail ni les identifiants. Conservez des identifiants stables et suivez l’état de chaque effet secondaire. Si un composant externe a déjà été résilié, l’application doit pouvoir le réconcilier : vérifier s’il existe toujours, le recréer de manière contrôlée ou signaler qu’une intervention manuelle est nécessaire.
Une réactivation idempotente produit le même état final, même si elle est demandée plusieurs fois. Elle peut s’appuyer sur des transactions pour les modifications locales, des opérations de mise à jour plutôt que des insertions à l’aveugle, et une stratégie de nouvelles tentatives pour les systèmes externes. Si l’opération échoue en cours d’exécution, consignez les étapes terminées et permettez de reprendre sans répéter celles qui ont déjà réussi.
Gérer les données, la traçabilité et la clôture définitive
La clôture opérationnelle et la suppression des données sont deux décisions distinctes. Définissez le sort des données de l’organisation, des sauvegardes, des journaux d’audit et des informations conservées au titre d’obligations légales ou contractuelles. Les délais et les motifs applicables dépendent du contexte et de la juridiction ; ils doivent être examinés avec les responsables de la protection de la vie privée et de la conformité. Selon la politique applicable, indiquez au client ce qui est supprimé, ce qui est conservé et pendant combien de temps.
À l’expiration de la période de grâce, un processus planifié doit repérer les demandes en attente et vérifier à nouveau leur état et leur date limite avant de clôturer le compte. En cas d’échec partiel, le système doit consigner l’étape qui a échoué et permettre de reprendre le traitement. Un indicateur closed ne prouve pas à lui seul que les identifiants ont été révoqués ou que les intégrations ont été arrêtées.
Assurez la traçabilité des demandes, des annulations, des changements d’autorisations, des exécutions finales et des erreurs. Limitez l’accès à ces journaux et évitez d’y inclure des secrets ou des données personnelles inutiles. Les alertes doivent signaler les situations qui dépassent le délai prévu, comme des organisations dont le délai a expiré mais qui sont toujours actives, ou des clôtures bloquées par des erreurs répétées.
Liste de vérification pour tester le flux
- Une personne sans autorisation ne peut ni demander ni annuler la résiliation.
- Demander la résiliation deux fois ne génère pas de dates, d’événements ou de clôtures en double.
- Les rôles disposent exactement des capacités prévues pendant la période de grâce.
- Les sessions, les jetons, les API, les files d’attente et les intégrations respectent l’état de l’organisation.
- Une annulation avant l’expiration rétablit l’accès prévu sans dupliquer les processus ni les ressources.
- Une demande arrivée à expiration n’est ni annulée par une requête tardive ni clôturée deux fois.
- Les échecs partiels et les nouvelles tentatives permettent de terminer la clôture sans répéter les effets externes.
- Les règles de conservation et de suppression des données sont vérifiées indépendamment du blocage opérationnel.
Testez également les modifications simultanées, les retards dans les files d’attente et les erreurs des prestataires externes. La cohérence de la conception ne se mesure pas uniquement au fait que l’écran affiche « compte clôturé » : les autorisations, les processus, les identifiants et les données doivent traduire la même décision, et le système doit pouvoir expliquer comment il est arrivé à cet état.
