Skip to main content
Le soft delete est le principe de supprimer un élément en simplement définissant un champ deletedAt avec une date, afin qu’il ne s’affiche plus dans la récupérations des données, mais il n’est pas en réalité complètement supprimé. C’est utile pour être plus souple dans les conditions de suppression d’un élément → même si des liens sont obligatoires, il suffit de renseigner le champ et il ne s’affichera plus.
Le soft delete est utilisé pour les éléments bas dans la hiérarchie (anomalie, rapport), desquels on ne souhaite plus voir les données.
Il s’oppose à l’archivage qui sera possible pour tous les éléments. Celui-ci veut garder une traçabilité de la donnée, et est obligatoire pour les éléments hauts dans la hiérarchie (IT, règles, etc.).Reste à déterminer précisement : hiérarchie basse et haute
Combinaisons possibles:
soft delete + archivage
hard delete + archivage Comment gérer l’affichage pour les éléments supprimés dans le drawer ?
Pas d’affichage drawer complet → ouvrir drawer mais afficher que l nom de l’élément, et dans body, afficher “cet élément a été supprimé” Comment gérer l’affichage des éléments supprimés dans les différents affichages ou ils peuvent apparaitre ?
Par exemple, imaginons que je puisse supprimer une IT, comment est-ce que celle-ci s’affiche sur le tableau anomalie si des anomalies étaient reliées ? pareil dans le drawer de l’anomalie ?
- simplement la masquer ?
- affiché mais grisé ? avec un tag particulier ? un badge rouge ?
- l’affiché normalement dans les tableaux, mais avec un tag dans les drawer ?
- limité la suppression au niveau du domaine ? Toutes les questions se posent aussi avec l’archivage.
Dans les tableaux : on masque les éléments Dans les cases des tableaux : italique + tag/couleur/dot Dans les drawers (d’un élément non supprimé) : italique + tag/couleur/dot Affichage de l’icône d’une IT supprimée ? → on ne peut pas supprimée une IT, elle s’archive avec ses éléments enfants

​
Liste des éléments

on soft delete toujours les éléments, et quand ça pose problème au niveau des “unique” (exemple utilisateur, il faut remplacer le champ par autre chose)

​
RS

Les décisions pourront être prisent dans la phase d’idéation des règles du domaine.
Chantier transverse (back & front). Pistes = hypothèses à valider.

​
1. Contexte

La décision droits B1 a posé que toute suppression = soft delete (pas de hard delete par défaut), avec corbeille optionnelle et une purge définitive (data.purge) back-office uniquement (retirée de l’app ; révisé 2026-06-25). Reste à définir comment le soft delete se comporte de façon cohérente dans toute l’application, côté back comme front.

​
2. Problème

Sans politique unifiée, le soft delete est traité au cas par cas selon les entités : comportements d’affichage incohérents, relations cassées (un élément supprimé encore référencé), risque pour la valeur probante du registre, et pas de parcours clair de restauration / purge.

​
3. Existant dans Kare

  • Suppressions bloquées par des garde-fous métier : rapport non supprimable si une anomalie est résolue (resolved > 0), intervention non supprimable si un rapport est lié, anomalie résolue non supprimable, règle utilisée non supprimable (cf. cartographie produit 2026-06-24).
  • Mécanismes proches existants : archivage de règles par site (le transfert de règles n’est pas développé — règles modifiables en place, révisé 2026-06-26).
  • Pas de modèle de soft delete générique documenté (flag supprimé, filtrage, restauration, purge).

​
4. Besoins

  • Un comportement de soft delete homogène sur toutes les entités (flag + horodatage + auteur).
  • Back : exclusion par défaut des éléments supprimés des requêtes, intégrité référentielle (que devient une relation vers un élément supprimé ?), purge contrôlée.
  • Front : masquage par défaut, éventuelle corbeille (optionnelle, B1), parcours de restauration, messages clairs.
  • Respect du cadre réglementaire : ne pas détruire la preuve (archivage > suppression pour les éléments du registre) — cf. [⚖️ Cadre réglementaire — modifications et suppressions](⚖️ Cadre réglementaire — modifications et suppressions).

​
5. Pistes (hypothèses — non validées)

  • Champ standard deletedAt + deletedBy sur les entités concernées ; filtrage transverse au niveau requête.
  • Soft delete vs archivage : clarifier la frontière (suppression = sortie de l’usage courant, restaurable ; archivage = conservation volontaire d’un historique). Possible convergence.
  • Corbeille optionnelle par organisation (B1) ; purge = data.purge back-office uniquement (hors app).
  • Cascade maîtrisée : définir, par relation, si la suppression d’un parent masque/bloque/conserve les enfants.

​
6. Questions à valider

  • Quelles entités sont soft-deletable (toutes ? exceptions juridiques) ?
  • Frontière soft delete ↔ archivage : deux mécanismes ou un seul ?
  • Corbeille : activée par défaut ou option ? portée (par entité / globale) ?
  • Comportement front : où voit-on les éléments supprimés, comment les restaurer ?
  • Intégrité : une relation pointant vers un élément supprimé — masquée, conservée, ou bloquante ?

​
7. Liens

  • [Droits et permissions](Droits et permissions) §15 (B1 soft delete, corbeille, data.purge)
  • [Droits - Capabilities](Droits - Capabilities) §20 (B1)
  • Archivage — frontière avec l’archivage
  • [⚖️ Cadre réglementaire — modifications et suppressions](⚖️ Cadre réglementaire — modifications et suppressions) — preuve / intégrité
  • [Logique de suppression des rapports](Logique de suppression des rapports) — cas spécifique rapports

​
8. Décisions

  • **Frontière soft delete ↔ archi