La désactivation d’une organisation sur une plateforme SaaS ne devrait pas se résumer à modifier un champ tel que active = false. Cette modification peut masquer le compte dans l’interface alors que ses utilisateurs conservent des sessions valides, qu’une intégration continue d’envoyer des données ou qu’une tâche en file d’attente poursuit la modification de ressources. Pour désactiver de manière fiable un compte d’organisation dans un SaaS PHP, il faut définir la signification de chaque état et coordonner les effets sur l’identité, les processus et les données.
L’objectif est que l’opération produise un résultat vérifiable et que, si elle échoue en cours d’exécution, elle puisse reprendre sans dupliquer les effets ni laisser des autorisations incohérentes. Cela exige de concevoir à la fois le cycle de vie et les procédures d’exécution et de récupération.
Distinguer suspension, fermeture et suppression
Ces termes désignent des décisions différentes. La suspension est généralement temporaire : elle bloque certaines opérations tout en conservant l’organisation en vue d’une éventuelle réactivation. La fermeture marque la fin de la relation opérationnelle et peut inclure la révocation des accès et l’annulation des tâches. La suppression concerne les données et doit respecter les règles de conservation, les obligations légales et les politiques du produit.
Il est préférable de ne pas utiliser un indicateur unique pour représenter ces trois situations. Un modèle explicite peut inclure des états tels que active, suspending, suspended, closing, closed et deletion_pending. Les noms exacts dépendent du produit ; l’essentiel est que chaque état ait une signification, des conditions d’entrée et des opérations autorisées.
- Suspension : empêcher les nouvelles actions métier, tout en conservant les données et en autorisant les opérations administratives nécessaires.
- Fermeture : arrêter l’activité courante, invalider les accès et mener à bien les tâches de clôture.
- Suppression : effacer ou anonymiser les données conformément à une politique définie, et non comme effet implicite d’une suspension.
Modéliser les transitions et les autorisations
Définissez une machine à états ou des règles de transition équivalentes. Par exemple, une organisation active peut être suspendue ; une demande de fermeture peut déclencher l’état closing ; et ce n’est qu’après les vérifications correspondantes qu’elle passe à l’état closed. Si la transition n’est pas autorisée, l’application doit la refuser en indiquant un motif compréhensible et pouvant être consigné.
Les vérifications d’autorisation doivent évaluer l’état de l’organisation côté serveur, en plus des rôles de l’utilisateur. Masquer des boutons dans l’interface ne révoque pas les autorisations. Dans une application PHP, centralisez cette décision dans des services métier, des middlewares ou des politiques réutilisables, au lieu de vous fier à des validations dispersées dans les contrôleurs.
Précisez ce qui est autorisé à chaque étape. Pendant l’état closing, par exemple, il peut être possible d’autoriser les exports et la consultation des factures, mais pas la création d’utilisateurs, le lancement de processus métier ni la modification des intégrations. Ce contrat évite que les différents composants interprètent « désactivée » de manière incompatible.
Révoquer les accès, les sessions et les identifiants
La fermeture doit couvrir tous les moyens d’accès associés à l’organisation : sessions Web, jetons d’API, clés de service, invitations en attente, identifiants OAuth et accès délégués. Identifiez où ils sont émis et comment les invalider. Une invitation qui n’a pas été acceptée peut également donner accès à l’avenir ; elle doit donc être annulée ou rendue inutilisable.
La révocation d’une session dépend de son mode de gestion. Si le système utilise des sessions stockées côté serveur, il peut les invalider directement ; s’il utilise des jetons autonomes, il peut être nécessaire de vérifier l’état de l’organisation à chaque requête, d’utiliser une liste de révocation ou d’appliquer une stratégie d’expiration courte. Le choix approprié dépend du niveau de risque et des exigences de performance, mais l’état de fermeture doit primer sur un jeton qui n’a pas encore expiré.
Tenez également compte des utilisateurs appartenant à plusieurs organisations. La désactivation d’une entreprise ne devrait pas bloquer automatiquement leur compte personnel ni leur accès légitime à d’autres clients. Le contrôle doit s’appliquer au contexte de l’organisation et aux autorisations effectives de chaque requête.
Arrêter les files d’attente, les webhooks et les intégrations
Une modification de l’état dans la base de données n’annule pas, à elle seule, les tâches déjà mises en file d’attente. Examinez les consommateurs de files d’attente, les tâches planifiées, les processus d’import et d’export, les synchronisations et les notifications. Avant d’exécuter une action, chaque worker devrait vérifier que l’organisation est toujours autorisée à effectuer cette opération. Le cas échéant, supprimez ou annulez les tâches en attente et consignez celles qui n’ont pas pu être arrêtées.
Pour les webhooks sortants, définissez si les événements déjà générés doivent être envoyés, annulés ou conservés à des fins d’audit. Pour les intégrations entrantes, désactivez les identifiants et rejetez les nouvelles requêtes, même si le fournisseur distant n’a pas encore reçu la notification de fermeture. Évitez de dépendre de la rapidité de déconnexion d’un tiers.
Dans les systèmes distribués, ne supposez pas que ces actions et une mise à jour de la base de données constituent une transaction atomique. Utilisez une séquence contrôlée et, le cas échéant, un modèle de boîte d’envoi transactionnelle pour publier les événements de changement d’état. Faites en sorte que les consommateurs tolèrent les messages en double grâce à des opérations idempotentes.
Rendre la désactivation reprenable et auditable
Représentez la désactivation comme une opération dotée d’un identifiant, d’une date de début, d’un acteur, d’un motif le cas échéant, d’une version du flux et de résultats pour chaque étape. Parmi les étapes possibles : bloquer les opérations, révoquer les identifiants, annuler les tâches, notifier les intégrations et effectuer les vérifications finales. Consignez les états tels que « en attente », « terminée » ou « en échec », avec des informations utiles au diagnostic, sans enregistrer de secrets ni de données personnelles inutiles.
Si une étape échoue, le système doit permettre de la relancer sans répéter d’effets préjudiciables. Par exemple, la révocation d’un identifiant déjà révoqué devrait être une opération sûre. Distinguez les erreurs transitoires, qui peuvent faire l’objet d’une nouvelle tentative, des erreurs nécessitant une intervention. Ne marquez pas la fermeture comme terminée simplement parce qu’une tâche asynchrone a été lancée.
Définissez également ce que signifie la réactivation. Une suspension peut être annulée en rétablissant les opérations autorisées, mais la réactivation d’une organisation fermée ne devrait pas recréer automatiquement les identifiants supprimés ni rétablir les tâches annulées. La politique doit préciser ce qui est restauré, ce qui nécessite une action administrative et ce qui ne peut plus être annulé.
Décider du sort des données
Avant de supprimer des données, déterminez quels enregistrements dépendent exclusivement de l’organisation, lesquels doivent être conservés pour des raisons opérationnelles ou légales et lesquels font partie d’informations partagées. Clarifiez le traitement des documents, des journaux d’audit, des factures, des sauvegardes et des données stockées chez des fournisseurs externes. La suppression du compte ne signifie pas nécessairement que toutes les copies disparaissent immédiatement ; expliquez les règles applicables sans promettre de délais que le système ne peut pas garantir.
Lorsque la suppression est asynchrone, conservez des états explicites tels que deletion_pending et deleted, et consignez le résultat pour chaque catégorie de données. En cas d’anonymisation, vérifiez que la procédure empêche une réidentification raisonnable et ne rompt pas les références qui doivent être conservées. La décision doit être conforme aux obligations et aux politiques applicables au produit.
Vérifier et tester l’opération complète
La réussite d’une désactivation doit pouvoir être démontrée par des vérifications, et pas seulement par un message de succès. Vérifiez que l’organisation ne peut plus effectuer les opérations bloquées, que les identifiants concernés ne fonctionnent plus, que les invitations sont invalidées et qu’aucune tâche incompatible n’est encore en cours d’exécution. Vérifiez également l’état des intégrations et les exceptions nécessitant un suivi.
Incluez des tests automatisés et opérationnels pour des situations représentatives :
- Des demandes répétées de suspension ou de fermeture, qui ne doivent pas dupliquer les effets.
- Un échec après la révocation des accès, mais avant l’arrêt d’une intégration.
- Une nouvelle tentative après une erreur réseau ou une réponse infructueuse d’un fournisseur.
- La réactivation d’une organisation suspendue et les limites applicables à un compte fermé.
- Des utilisateurs actifs dans plusieurs organisations et des tâches en file d’attente lancées avant le changement.
Une liste de vérification observable, associée à des métriques sur les opérations en attente et en échec, aide à détecter les fermetures bloquées. L’essentiel est de traiter la désactivation comme un processus métier doté d’états, d’autorisations et d’effets définis. Ainsi, désactiver un compte d’organisation dans un SaaS PHP ne sera plus une modification isolée, mais une transition contrôlée, récupérable et cohérente pour l’ensemble des composants.
