Couper l’accès n’est pas effacer

Désactivation

La désactivation ferme la publication et fait répondre son adresse comme une ressource absente. Elle ne supprime ni les objets du stockage, ni les métadonnées, ni l’échéance. Le propriétaire peut réactiver le lien ; une publication désactivée continue d’expirer à la date prévue.

Expiration

Les durées bornées proposées sont 24 heures, 7 jours et 30 jours. Le worker recherche toutes les cinq minutes les publications arrivées à échéance, par lots de 200, et effectue un passage immédiat à chaque redémarrage. Une échéance n’est donc pas une promesse d’effacement à la seconde exacte : elle devient éligible au prochain passage disponible.

Le chemin d’expiration appelle la même procédure que la suppression demandée par l’utilisateur avec le motif expired. Une publication permanente n’a pas d’échéance automatique et reste jusqu’à suppression.

Une publication bloquée avant mise en ligne reste actuellement en quarantaine sans expiry_at et n’est donc pas reprise par ce worker. Un brouillon dont l’upload est interrompu peut également laisser des objets transitoires. Ces publications doivent être supprimées explicitement avec leur identifiant ; l’automatisation de leur nettoyage reste un écart connu.

Suppression du stockage principal

1. Le service liste tous les objets préfixés par l’identifiant du site dans l’Object Storage.
2. Il les supprime par lots de 1 000, limite du protocole S3.
3. Une erreur de lot ou un objet refusé interrompt l’opération : aucune attestation de réussite n’est retournée.
4. Le service purge ensuite le CDN configuré. En production, l’architecture déclarée utilise cdn_provider: none : aucun CDN intermédiaire n’est actif.
5. L’attestation est signée puis écrite dans le journal en mode strict.
6. Le slug, le secret d’accès, l’IP tronquée et les jetons de revendication sont neutralisés ou supprimés dans la base.

L’appel explicite DELETE /v1/sites/{id} est synchrone : il ne répond avec l’attestation qu’après ces étapes. Le code ne publie pas de délai contractuel maximum pour cet appel.

Cache et réponse après suppression

Les publications non protégées portent un cache HTTP maximal de 30 secondes ; les publications par mot de passe ou domaine email utilisent private, no-store. Aucun CDN n’est actif aujourd’hui. Un navigateur, un proxy non prévu ou un destinataire peut néanmoins avoir conservé une copie indépendamment du service.

Le hash du slug est conservé pour permettre une page HTTP 410 pendant 30 jours, puis l’adresse se comporte comme une 404. Le slug en clair est retiré des métadonnées du site ; le journal privé du propriétaire peut conserver le libellé associé à l’événement.

Métadonnées et attestation

L’effacement des fichiers ne supprime pas immédiatement tout le registre. Les métadonnées nécessaires à l’audit et l’attestation restent dans le journal append-only. La base interdit leur suppression pendant trois ans ; cette durée probatoire ne signifie pas que le contenu des fichiers y est conservé.

L’attestation déclare notamment le nombre d’objets supprimés, le volume associé, les horodatages de purge du stockage et du CDN configuré, le motif et le fournisseur CDN. Elle est récupérable lors de la suppression puis via l’API ou le tableau de bord selon les droits du propriétaire.

Sauvegardes : limite documentée

Le dépôt décrit la suppression du bucket principal et la conservation du journal, mais ne documente pas une politique vérifiée de sauvegarde ou de versioning de l’Object Storage, ni un délai de disparition dans d’éventuelles sauvegardes gérées par le fournisseur. L’attestation actuelle ne doit donc pas être interprétée comme la preuve d’une purge de sauvegardes non décrites.

Ce que l’attestation ne couvre pas

• les copies téléchargées ou capturées par les destinataires ;
• les données envoyées par le code publié à un service externe ;
• les caches, archives ou sauvegardes extérieurs au périmètre déclaré ;
• la suppression d’une donnée dans le système source du publieur.