Version 2026-10-16.4 · SHA-256 a697aa08ae46dae8101c6d10602208bb894990fbf918beb42cb4d90c24fbabc6
Version 2026-10-16.4
Exploitant : Yanis SIDI BOULENOUAR EI, entrepreneur individuel, SIREN 937734622, SIRET 93773462200015, 23 rue de Sauve, 30900 Nîmes, France. KREDIA Finance est le nom commercial du logiciel, non une personne morale distincte.
TVA intracommunautaire : FR81937734622. Contact : yanis@krediafinance.fr. Téléphone : 07 66 29 30 11.
Conservation restitution et suppression
Principes et état réel
Les données sont conservées pour une finalité définie, en distinguant activité, sortie, archive probatoire et sauvegarde. Le journal indépendant, sa réplication hors VM et le contrôle de reprise ont été activés en exploitation le 16 octobre 2026, après sauvegardes vérifiées. Les nettoyages automatiques restent sous gel transitoire documenté pendant la clôture contractuelle. La levée du gel et l’ordonnancement de la rotation sont contrôlés avant ouverture des souscriptions ; l’activation technique ne constitue pas une approbation des textes.
| Catégorie | Durée ou critère | Exécution et limites |
|---|---|---|
| Dossiers, pièces, prévisionnels, scénarios et commentaires | Pendant contrat puis 90 jours après la fin de l’accès payé | Lecture seule et export ; à expiration, purge active. La maintenance est exécutée au démarrage du worker puis environ chaque heure ; les traitements peuvent retarder son passage |
| Livrables PDF/DOCX | Dernière version générée courante pendant vie du dossier et sortie | Régénérations tracées ; pas d’archive illimitée de toutes les versions |
| Conversations et documents IA applicatifs | Vie du dossier et période de sortie | Relations de suppression en cascade à la purge du dossier ; rétention fournisseur indépendante |
| Compte et organisation | Relation puis besoin d’identification et de preuve légitime | La purge de dossier ne supprime pas automatiquement utilisateurs et memberships : clôture/anonymisation à organiser, sans annoncer qu’elle existe déjà |
| Sessions et jetons | Cookie 8 h ; réinitialisation 1 h ; jetons à usage unique selon leur échéance | Invalidations applicatives ; nettoyage des sessions expirées depuis six mois calendaires, sans promesse d’effacement physique à chaque seconde |
| Traces applicatives de sécurité hors dossier | Six mois calendaires, sauf gel justifié | Nettoyage borné et journalisé ; les activités du dossier et événements de quota/probatoires suivent leur finalité propre |
| Journaux d’infrastructure | Volume borné et revue selon besoin de sécurité | La rotation Docker trois fichiers de 10 Mo ne garantit pas un âge maximal ; pas de promesse contraire pour journald ou journaux fournisseur |
| Factures et pièces comptables | Dix ans lorsqu’obligation comptable applicable, à compter de clôture selon la catégorie | Archive restreinte, indépendante de suppression des dossiers ; obligations fiscales et situations particulières à valider |
| Preuves de commande et d’acceptation | Cinq ans après fin de contrat pour les seules preuves nécessaires, sous réserve des prescriptions et litiges applicables | Versions et empreintes, accès restreint ; revue à échéance, sans conservation de tous les dossiers ni promesse de purge automatisée de toute preuve |
| Demandes de support résolues ou closes | Douze mois calendaires après clôture, sauf dossier probatoire justifié | Nettoyage borné ; onboarding et demandes encore ouvertes exclus |
| E-mails applicatifs envoyés ou en échec définitif | Trente jours après dernier traitement | File en attente exclue ; boîte IONOS et journaux du relais Brevo distincts, selon finalités et paramètres effectivement vérifiés |
| Sauvegardes locales et Object Storage | Trente jours glissants, au moins deux points de reprise récents vérifiés | Gel justifié prioritaire ; contrôle d’intégrité et réplication avant rotation ; expiration des versions de contenu, pas simple marqueur de suppression |
La conservation de dix ans des pièces comptables ne justifie pas de garder dix ans l’ensemble des FEC, pièces personnelles, conversations ou exports déposés par un cabinet. Les identités résiduelles ne sont conservées que pour une appartenance active ou une preuve nécessaire ; leur revue reste distincte de la purge du contenu des dossiers.
Paramètres opérationnels et exceptions
Le fichier opérationnel retention_policy.json version 2026-10-16.1 précise ces critères. L’ancienne proposition 2026-10-14.4 reste archivée ; elle n’est pas présentée comme une approbation contractuelle. Les six et douze mois sont calendaires, pas respectivement 183 et 365 jours. Un gel global ou d’organisation documenté bloque les nettoyages concernés ; un registre d’exceptions protège les sauvegardes nécessaires.
Ces durées sont des choix proportionnés, pas des obligations légales universelles. Les nettoyages nécessitent configuration explicite, journal indépendant disponible, sauvegarde vérifiée et contrôle des exceptions. Les factures, preuves contractuelles, quotas, activités de dossiers actifs et comptes partagés ne font pas l’objet d’un effacement temporel indistinct. Toute conservation probatoire supplémentaire doit être documentée et restreinte.
La rotation refuse d’effacer des sauvegardes si deux points récents vérifiés ne sont pas disponibles, si la réplication n’est pas confirmée ou si un gel s’applique. Elle est contrôlée en QA avant activation. Une suppression de version requiert son identifiant exact et son empreinte de concurrence ; les autres objets et le code de retour arrière sont exclus.
Sortie et purge
Après résiliation à échéance payée, les 90 jours sont ancrés à la fin d’accès enregistré, pas à la date d’un clic de résiliation. Les lectures/exports restent soumis aux permissions ; lancement, modifications et calcul sont interdits. À la fin, les états passent en expiration et la maintenance purgera les données actives autorisées ; échecs et statut de purge sont tracés, réexécution idempotente. Les comptes, documents comptables, journal de quota et preuves nécessaires sont séparés ; leur conservation résiduelle doit être revue.
L’Admin peut exporter son organisation par les paramètres/RGPD et télécharger les livrables disponibles. Le fichier exporté est sous sa responsabilité après téléchargement. Une suppression d’un dossier ne rembourse pas le quota consommé. Demande individuelle : qualifier avec le responsable de traitement, contrôler l’identité et les droits proportionnellement, appliquer l’instruction validée et expliquer les conservations légales.
Sauvegardes et restauration
La purge active n’efface pas immédiatement les anciennes sauvegardes ou copies fournisseur. Les suppressions validées sont inscrites avant effacement dans un journal chiffré indépendant de la base sauvegardée, avec accusé de réplication hors de la VM. Ce journal contient des identifiants opaques et dates, pas les montants financiers, noms ou conversations. Il reste nécessaire tant que des copies restaurables peuvent contenir les données supprimées ; son sort est revu après extinction de cette fenêtre et des éventuels gels.
Au démarrage, web et worker réappliquent les identifiants effectivement supprimés, de manière idempotente, avant ouverture des traitements. Un journal absent, altéré, divergent ou non répliqué bloque cette reprise. Une sauvegarde antérieure au premier point de référence de confidentialité reste isolée pour rapprochement manuel ; elle n’est ni détruite arbitrairement ni remise directement en service. Les nouvelles données légitimes et les autres organisations ne sont pas supprimées par une règle générale de rattrapage.
Le journal courant ne doit jamais être remplacé par une ancienne copie contenue dans une sauvegarde de base. Sa récupération et les clés nécessaires suivent une procédure indépendante ; au plus deux répliques courantes complètes sont conservées, chacune contenant la chaîne des suppressions. La restauration PostgreSQL isolée, la réapplication et l’idempotence ont été exécutées sur données fictives. Cela ne constitue pas une attestation d’effacement des sauvegardes de production ni des copies des fournisseurs.
Sources : https://www.cnil.fr/fr/passer-laction/les-durees-de-conservation-des-donnees et https://entreprendre.service-public.gouv.fr/vosdroits/F23208.
Limites d’exploitation
Le worker exécute la maintenance à son démarrage puis environ toutes les heures, par lots bornés. Aucune extension pg_cron ni purge temporelle générale de toutes les tables n’est annoncée. Les erreurs de suppression et de réplication sont bloquantes pour le traitement concerné, pas transformées en réussite.
Les journaux Docker utilisent une rotation de volume (trois fichiers de 10 Mo par conteneur), pas une durée garantie. La configuration journald examinée ne fixe pas de durée maximale propre à KREDIA. La lecture de la politique de cycle de vie Oracle renvoie BucketNotFound/404 : cela ne prouve ni l’absence de politique ni l’absence du bucket. La rotation applicative préparée contrôle les versions réelles des objets et ne suppose pas qu’une règle Oracle de cycle de vie est active.
Une archive de déploiement contenant la base est une sauvegarde de données, pas une raison de conservation illimitée ; le code de rollback est conservé séparément des données. Le seul journal de purge contenu dans un ancien snapshot ne suffit pas à empêcher leur réapparition. Le contrôle de reprise est actif ; le gel de nettoyage et la rotation doivent être traités avant ouverture sur données clients réelles. Sources : https://www.cnil.fr/fr/passer-laction/les-durees-de-conservation-des-donnees ; https://www.cnil.fr/fr/la-cnil-publie-une-recommandation-relative-aux-mesures-de-journalisation ; https://entreprendre.service-public.gouv.fr/vosdroits/F10029.
Contact commun et version
Les versions applicables sont celles approuvées et mises à disposition dans KREDIA. Les projets accessibles dans l’administration ne valent pas acceptation. Contact : yanis@krediafinance.fr.