Suppression automatique des comptes inactifs

Les comptes que plus personne n'utilise sont un risque : ce sont des données personnelles que vous gardez sans raison, et les règles de protection des données comme le RGPD attendent de vous que vous ne conserviez les données personnelles que le temps dont vous en avez besoin. Gate peut les nettoyer pour vous, selon les conditions que vous fixez, et prévient les personnes par e-mail avant de supprimer leur compte. Les personnes sans adresse e-mail (connexion par Telegram) ne sont jamais touchées, sauf si vous autorisez explicitement leur suppression sans avertissement.

Le dispositif repose sur quatre règles. Une règle appartient à un projet, ne fait rien tant que vous ne l'activez pas, et ne s'applique qu'aux utilisateurs finaux de ce projet.

Activer une règle que votre offre n'inclut pas est refusé avec un 403 et le code plan_required.

Dans le tableau de bord

Ouvrez Utilisateurs et connexion → Règles (/dashboard/gate?tab=rules). L'onglet affiche les quatre règles du projet sélectionné dans le sélecteur de projet. Chacune a un interrupteur et ses réglages.

• Aperçu. Avant d'activer une règle de suppression, l'onglet vous dit combien de personnes elle concernerait à l'instant. Une règle agit aussi sur les personnes qui existent déjà, pas seulement sur les nouvelles inscriptions : regardez donc le nombre d'abord.
• Confirmation. L'activation d'une règle qui supprime des comptes ou retire des rôles demande une confirmation.
• Offre. Une règle que votre offre n'inclut pas est verrouillée, avec un lien vers les offres. Si un changement d'offre a désactivé une règle, l'onglet l'indique ; vos réglages sont conservés, et la règle reste désactivée jusqu'à ce que vous la réactiviez.
• Activité. Sous les règles, la liste de ce qui a été planifié et fait dans le projet : actions en attente, effectuées, annulées et en échec, avec le motif d'une annulation. Les personnes apparaissent par leur ID d'identité ; la liste ne contient aucune adresse e-mail.

Réglages et bornes

Supprimer les comptes non confirmés

{ "delete_after_days": 14, "warn_before_days": 3 }

Seules les personnes dont l'adresse e-mail n'est toujours pas confirmée sont concernées. S'inscrire avec Telegram compte comme une confirmation : ces comptes ne sont donc jamais touchés par cette règle.

Rappeler aux personnes de confirmer leur e-mail

{ "remind_after_hours": 24 }

Un seul rappel par personne, jamais plus. Seules les personnes qui s'inscrivent après l'activation de la règle reçoivent un rappel, et pas les inscriptions vieilles de plus de 30 jours.

Retirer les rôles à l'échéance

Cette règle n'a pas de réglages (envoyez {} ou omettez params). Les échéances sont portées par les membres eux-mêmes : voir Dates limites des membres. Quand une échéance est dépassée, l'appartenance est retirée, et la personne perd le rôle et ce qu'il lui donnait. C'est la seule règle qui agit sans e-mail, parce qu'aucun compte n'est supprimé.

Tant que la règle est désactivée, ou que votre offre ne l'inclut pas, les échéances sont enregistrées mais pas appliquées : les membres gardent leur rôle après l'échéance jusqu'à ce que vous le retiriez vous-même.

Supprimer les comptes inactifs

{ "inactive_after_months": 12, "warn_before_days": 30, "include_without_address": false }

Les personnes qui se connectent avec Telegram n'ont pas d'adresse e-mail : rien ne permet donc de les prévenir. Avec include_without_address désactivé, elles ne sont jamais touchées. Activé, elles sont supprimées sans aucun avertissement une fois inactives pendant la période. N'activez cette option que si c'est ce que vous voulez annoncer à vos utilisateurs.

Ce qui compte comme activité. La date de la dernière connexion d'une personne, par n'importe quelle méthode. Les connexions n'étaient pas enregistrées avant l'existence de cette fonction : une personne sans connexion enregistrée compte donc comme active à partir du jour où elle a rejoint votre projet, sans remonter avant le début de l'enregistrement. Personne n'est supprimé à cause d'une connexion que nous n'avons pas vue : la suppression la plus précoce possible intervient une période d'inactivité après ce moment.

Qui une règle touche

Une règle n'agit que sur une personne qui remplit toutes ces conditions :

• un utilisateur final de ce projet : un compte créé avec le schéma user (les comptes Gate ordinaires) ou, pour la règle des comptes inactifs avec include_without_address, un compte Passepartout (Telegram) ;
• actif. Un compte que vous avez désactivé vous-même relève de votre décision, et on n'y touche pas ;
• membre de ce projet et d'aucun autre. Une personne qui a des comptes dans deux de vos projets n'est jamais touchée par la règle de l'un ni de l'autre, pas plus qu'un compte dont nous ne savons pas à quel projet il appartient.

Comment cela s'exécute

Vous n'exécutez rien. Les règles sont vérifiées périodiquement : les échéances de rôle en une minute environ, les comptes non confirmés toutes les quelques minutes, les comptes inactifs à peu près toutes les heures. On planifie une action pour toute personne qui correspond à une règle, et le planning est visible dans la liste Activité et via GET /v1/gate/lifecycle/actions.

La suppression se fait en deux étapes, dans cet ordre, et la seconde ne peut jamais avoir lieu sans la première :

1. L'e-mail d'avertissement part vers la personne. Il nomme le projet et la date de suppression.
2. La suppression a lieu à cette date, pas avant. Si la règle a été modifiée entre-temps, ou si l'avertissement est parti plus tard que prévu, la personne reçoit quand même le préavis complet, et la suppression n'a jamais lieu avant la date indiquée dans l'e-mail.

Tout est revérifié juste avant l'envoi d'un e-mail et juste avant la suppression d'un compte. Si la personne a confirmé son e-mail, s'est connectée, a été supprimée autrement ou a été désactivée, ou si la règle a été désactivée, modifiée, supprimée ou n'est plus incluse dans votre offre, l'étape planifiée est annulée et rien n'est envoyé ni supprimé. Désactiver une règle, modifier ses réglages ou la supprimer annule ce qu'elle avait planifié ; un avertissement déjà envoyé ne peut pas être retiré, et il n'est jamais envoyé deux fois à la même personne pour la même période d'inactivité.

Si l'e-mail ne peut pas être remis, il est retenté pendant 72 heures au plus. S'il n'est toujours pas parti, l'étape passe à failed et la personne est laissée telle quelle : il n'y a pas de suppression sans avertissement envoyé.

La suppression est la même que DELETE /v1/gate/identities/{id} : l'identité et ses sessions sont supprimées, avec les enregistrements qui rattachent la personne à vos projets et à vos organisations et sa ligne d'utilisateur actif du mois en cours ; vos endpoints reçoivent un webhook identity.deleted.

Certains enregistrements ne disparaissent pas avec la personne. Chacun reste jusqu'à la fin de sa propre durée de conservation, puis est supprimé :

• Les entrées du journal d'audit qui désignent la personne (une connexion, avec l'adresse IP et le user agent) : 7 jours sur Free, 30 sur Pro, 90 sur Advanced. Voir Journal d'audit.
• L'historique des webhooks et des livraisons, y compris la livraison de identity.deleted elle-même : 7 jours sur Free, 90 sur Pro, 180 sur Advanced et Contract, comme sur Offres, limites et refus.
• Le décompte des utilisateurs actifs des mois clos, c'est-à-dire ce qui a été facturé : treize mois.
• Les entrées terminées de la liste Activité, qui désignent la personne par son ID et ne contiennent aucune adresse : 90 jours.

Par prudence face aux gros arriérés, une règle planifie au plus quelques centaines de personnes par passage : activer une règle dans un projet qui compte beaucoup de vieux comptes étale donc les e-mails sur plusieurs passages, au lieu de les envoyer d'un seul coup.

Les e-mails

Les e-mails sont envoyés depuis l'adresse de Verne (noreply@vernesoft.com) et portent le nom de votre projet dans l'objet et dans le texte. Ils sont en anglais pour l'instant ; l'envoi depuis votre propre domaine, et dans la langue de vos utilisateurs, est prévu.

Si votre projet s'appelle encore « Default project », les e-mails utilisent à la place le nom de votre compte, parce que « Default project » n'apprend rien au lecteur. Définissez le nom du compte dans Paramètres, dans le tableau de bord.

Il y en a trois, un pour chaque règle qui écrit à la personne : un avertissement pour un compte non confirmé, un rappel de confirmer, et un avertissement pour un compte inactif. Chacun dit ce qui va se passer, à quelle date (UTC), et ce que la personne peut faire pour conserver son compte : confirmer son adresse e-mail, ou se connecter une fois.

API

Toutes les routes demandent une clé d'API avec le scope gate. Le projet est celui de la clé : rien dans le chemin ni dans le corps n'en désigne un. Les erreurs ont la forme habituelle { "error": { "code", "message", "request_id" } } (voir Format des erreurs).

{kind} vaut delete_unverified, remind_unverified, expire_roles ou delete_inactive. Toute autre valeur donne 404.

Lister les règles

curl https://api.vernesoft.com/v1/gate/lifecycle/rules \
  -H 'Authorization: Bearer vrn_9f8a7...'

(La vraie réponse liste les quatre valeurs de kind ; deux sont montrées.)

Créer ou modifier une règle

curl -X PUT https://api.vernesoft.com/v1/gate/lifecycle/rules/delete_unverified \
  -H 'Authorization: Bearer vrn_9f8a7...' \
  -H 'Content-Type: application/json' \
  -d '{
    "enabled": true,
    "params": { "delete_after_days": 14, "warn_before_days": 3 }
  }'

enabled est obligatoire. params peut être omis pour conserver les réglages enregistrés, ce qui permet de désactiver puis de réactiver une règle sans retaper ses réglages ; à la première écriture il est obligatoire, sauf pour expire_roles, qui n'en prend pas. Les champs inconnus sont refusés.

Désactiver une règle ou modifier ses réglages annule ce qu'elle avait planifié. Désactiver une règle n'est jamais refusé. En activer une que votre offre n'inclut pas l'est :

{
  "error": {
    "code": "plan_required",
    "message": "The Free plan does not include this rule. Move to Pro to use it.",
    "request_id": "req_..."
  }
}

Supprimer une règle

curl -X DELETE https://api.vernesoft.com/v1/gate/lifecycle/rules/delete_unverified \
  -H 'Authorization: Bearer vrn_9f8a7...'

Renvoie 204 No Content, y compris quand la règle n'existait pas. Ce qu'elle avait planifié est annulé ; l'historique de ce qu'elle a fait reste dans la liste des actions.

Prévisualiser une règle

Demande combien de personnes une règle avec ces réglages concernerait à l'instant. L'appel n'écrit rien et fonctionne que la règle soit activée ou non : vous pouvez donc regarder avant de l'activer.

curl -X POST https://api.vernesoft.com/v1/gate/lifecycle/rules/delete_inactive/preview \
  -H 'Authorization: Bearer vrn_9f8a7...' \
  -H 'Content-Type: application/json' \
  -d '{ "params": { "inactive_after_months": 12, "warn_before_days": 30, "include_without_address": false } }'

matching_now compte les personnes qui seraient planifiées d'un coup : pour les deux règles de suppression, celles qui recevraient l'e-mail d'avertissement maintenant (ou, avec include_without_address, seraient supprimées sans e-mail) ; pour expire_roles, les membres dont l'échéance est déjà dépassée. capped vaut true quand le décompte s'est arrêté à 1 000. Pour remind_unverified, le nombre n'a pas de sens, parce que cette règle ne regarde que les inscriptions faites après son activation.

Lister l'activité

curl 'https://api.vernesoft.com/v1/gate/lifecycle/actions?status=pending&limit=20' \
  -H 'Authorization: Bearer vrn_9f8a7...'

{
  "data": [
    {
      "id": "0f4b8c1e-5d1a-4a55-9d0e-6b0f4f3c2a10",
      "kind": "delete_unverified",
      "step": "warn",
      "identity_id": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
      "status": "pending",
      "basis_at": "2026-09-24T08:12:00Z",
      "due_at": "2026-10-05T08:12:00Z",
      "reason": null,
      "created_at": "2026-10-08T09:31:00Z",
      "finished_at": null
    }
  ],
  "has_more": false,
  "next_cursor": null
}

Du plus ancien au plus récent. Chaque élément :

La liste désigne les personnes par leur ID d'identité et ne contient aucune adresse e-mail. Lisez le profil avec GET /v1/gate/identities/{id} tant que le compte existe. L'historique est conservé 90 jours.

Le webhook identity.deleted

Quand une règle supprime un compte, vos endpoints reçoivent identity.deleted comme pour n'importe quelle suppression, avec un champ supplémentaire dans data.payload :

{
  "event_id":   "a1b2c3d4-...",
  "event_type": "identity.deleted",
  "tenant_id":  "550e8400-...",
  "created_at": "2026-10-22T08:14:00Z",
  "data": {
    "identity_id": "f47ac10b-...",
    "payload": { "reason": "inactive_account_expired" }
  }
}

Une suppression que vous faites vous-même par l'API n'a pas de reason. Voir Webhooks.

Dates limites des membres

expires_at est un champ d'un membre d'organisation. Il est enregistré quelle que soit votre offre ; ce qui agit dessus, c'est la règle expire_roles décrite plus haut.

Vous le définissez à l'ajout d'un membre, ou plus tard :

curl -X POST https://api.vernesoft.com/v1/gate/organizations/{org_id}/members \
  -H 'Authorization: Bearer vrn_9f8a7...' \
  -H 'Content-Type: application/json' \
  -d '{
    "identity_id": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
    "role_id": "7c1d9d0a-3d5e-4c58-8a76-2d3f6b1d0e11",
    "expires_at": "2027-01-31T23:59:59Z"
  }'

• expires_at est une date dans le futur, à 10 ans au plus. Une date passée est refusée avec un 400, et non appliquée : une faute de frappe retirerait sinon une personne.
• Omettre expires_at dans un PATCH conserve l'échéance ; null l'efface.
• Les membres sont renvoyés avec expires_at (null pour aucune échéance) quand vous les ajoutez, les modifiez et les listez.
• Le tableau de bord n'a pas encore d'écran pour les membres d'organisation : les échéances se définissent donc par l'API.

Quand votre offre change

Si vous passez à une offre qui n'inclut pas une règle que vous aviez activée, la règle est désactivée, pas supprimée. Ses réglages sont conservés, ce qu'elle avait planifié est annulé, et personne n'est supprimé par elle. Nous écrivons une fois à l'adresse du compte, en nommant les projets et les règles qui se sont arrêtés. Pour expire_roles, cela signifie que les échéances de rôle cessent d'être appliquées : les personnes gardent leur rôle et l'accès qui va avec après l'échéance, jusqu'à ce que vous le retiriez.

Remonter d'offre ne réactive pas une règle. Ouvrez Utilisateurs et connexion → Règles, ou envoyez un PUT avec "enabled": true.

Voir Offres, limites et refus pour ce que comprend chaque offre.