Cleanup¶

Status: TARGET

À quoi sert un Cleanup Write Service ?¶

Un Cleanup Write Service retire, neutralise ou corrige des données dont l'invalidité a été démontrée et dont le traitement a été explicitement validé.

Le mot « cleanup » ne doit jamais signifier « supprimer ce qui paraît inutile ». C'est une opération d'écriture potentiellement destructive, soumise aux mêmes garde-fous que les autres Write Services.

Audit d'incohérence
       ↓
Population précisément identifiée
       ↓
Simulation / validation
       ↓
Cleanup Write Service
       ↓
Audit après écriture

État documentaire¶

Cette page décrit la cible d'architecture de la famille Cleanup.

Elle ne prouve pas qu'un service générique de cleanup est actif dans le Runtime actuel. Toute commande concrète doit être vérifiée dans le dépôt avant utilisation.

Quand utiliser un cleanup¶

Un cleanup peut être pertinent lorsque :

des doublons techniques avérés doivent être retirés ;
une projection reconstruisible contient des lignes devenues invalides ;
des données legacy explicitement dépréciées doivent être supprimées ;
un ancien traitement a créé une population incohérente et identifiable.

Il ne doit pas servir à contourner une règle métier non comprise.

Entrées attendues¶

L'opération doit définir :

la population cible ;
la preuve d'invalidité ;
le type d'action (delete, neutralisation, correction, etc.) ;
les exclusions ;
la stratégie de sauvegarde ou rollback ;
le nombre de lignes attendu ;
les dépendances susceptibles d'être affectées.

Ce qu'un cleanup ne doit jamais faire¶

Un Cleanup Write Service ne doit jamais :

supprimer sur simple intuition ;
considérer unknown, ambiguous ou conflict comme des déchets ;
effacer une source de vérité métier parce qu'une projection est incohérente ;
casser une relation nécessaire à la reconstruction ;
purger globalement sans filtre explicite ;
masquer une dette d'architecture en supprimant les symptômes ;
être déclenché par un audit read-only.

Projection ou vérité métier ?¶

Avant tout cleanup, déterminer la nature de la donnée ciblée.

Une projection est dérivée et peut souvent être reconstruite. Une identité canonique ou une autre donnée métier source demande des garanties beaucoup plus fortes.

Quand une projection diverge de sa source, la priorité est généralement de comprendre la cause et de la reconstruire, pas de modifier la source pour qu'elle ressemble à la projection.

Sécurité opérationnelle¶

Avant exécution :

obtenir le nombre exact ou attendu d'éléments ciblés ;
inspecter un échantillon ;
vérifier les dépendances ;
disposer d'une sauvegarde ou d'une stratégie de reconstruction ;
utiliser un dry-run si l'implémentation en propose un ;
commencer par le plus petit périmètre utile.

Après exécution, réconcilier les compteurs et relancer l'audit initial.

Résultat attendu¶

Le service doit distinguer au minimum :

examined ;
eligible ;
changed ou deleted ;
skipped ;
failed ;
raisons d'exclusion et d'échec.

Une opération qui annonce uniquement « succès » sans compter ce qui a été touché est insuffisamment auditable.

Erreurs fréquentes¶

utiliser un critère trop large ;
confondre absence de donnée et donnée invalide ;
supprimer des cas ambigus au lieu de les conserver pour diagnostic ;
nettoyer une projection sans corriger la cause de sa divergence ;
oublier qu'une suppression peut casser une FK logique ou une reconstruction ;
exécuter plusieurs cleanups successifs sans audit intermédiaire.

Tests attendus¶

Tester au minimum :

périmètre exact ;
exclusion des données valides ;
idempotence lorsque possible ;
dry-run non destructif ;
compteurs réconciliables ;
reprise après erreur partielle ;
préservation des invariants métier.

Invariants¶

Un cleanup est une écriture explicite et potentiellement destructive.
Seules des données démontrées invalides sont ciblées.
Les états d'incertitude ne sont jamais assimilés à des déchets.
La source de vérité et les projections restent distinguées.
Toute opération est bornée, mesurée et vérifiée après exécution.