Cycle de vie des données — gouvernance, qualité, rétention

Vous êtes ici : Comprendre — les fondations : la vie d’une donnée, de l’ingestion à la destruction. Le voyage complet d’une donnée dans GS-Apps — de l’ingestion à la destruction — et qui garantit quoi à chaque étape. Lecture 9 min. Audience : auditeurs, administrateurs, devs. Date : 2026-07-08 | Version : 1.0 — créée par l’audit 360 des fondations données (verdicts sourcés, chantiers ouverts nommés)

TL;DR

Question	Réponse	Détail
D’où viennent les données ?	De l’ERP SOFI (lecture seule, compte dédié en lecture) ; autres sources planifiées	§ Ingestion
La qualité est-elle surveillée ?	✅ Chaque chargement est journalisé et borné par des seuils ; 🟠 la couverture s’étend au-delà de la couche brute	§ Qualité
Combien de temps garde-t-on ?	🔴 Cadre posé, durées par couche en arbitrage — l’objectif est un historique analytique de 10 ans	§ Rétention
Et si on perd la base ?	✅ Restauration à tout point sur 7 jours + copies longue durée jusqu’à 7 ans, géo-répliquées	§ Sauvegarde
Peut-on effacer une personne (Loi 25) ?	🟠 Minimisation forte à la source ; 🔴 la destruction définitive outillée est un chantier ouvert	§ Fin de vie
Qui a le droit de lire quoi ?	✅ Isolation par compagnie (RLS) prouvée à chaque build ; manifeste d’accès par application versionné dans le code	Architecture de données

Le cycle en une image

Les six étapes du cycle. Les étapes en pointillés (rétention outillée, destruction définitive) sont des chantiers ouverts assumés — pas des angles morts.

1 · Ingestion — tracée, verrouillée, journalisée

Les données externes entrent par des extracteurs configurés par table (colonnes explicites — jamais de « tout prendre ») vers la couche bronze, un schéma par source. Trois garanties :

Chaque exécution est journalisée : début, fin, statut, nombre de lignes, sous-étapes. Un registre de contrôle par table conserve le point de reprise (watermark) et la fraîcheur.
Verrou anti-concurrence : deux synchronisations de la même source ne peuvent pas se marcher dessus (verrou en base avec récupération automatique des verrous zombies).
Lecture seule à la source : le compte utilisé vers l’ERP n’a que le droit de lire.

2 · Qualité — un registre de contrôle par table

Chaque table ingérée porte ses seuils : nombre minimal de lignes attendu, variation maximale tolérée entre deux chargements, et — pour les tables à historique gelé — une empreinte de cohérence qui alerte si le passé change. Les statuts (ok / partial / error) sont visibles dans la console d’administration, et les règles de triage sont écrites : un partial qui se répète est un incident, pas un bruit.

Couverture actuelle : la couche bronze est sous surveillance ; l’extension des contrôles aux couches raffinées (silver/gold) et l’alerte automatique de fraîcheur sont des chantiers identifiés par l’audit 360 — la détection repose encore en partie sur la revue humaine.

3 · Rétention — le cadre est posé, les durées s’arbitrent

L’objectif du programme est un historique analytique de 10 ans. Le cadre de rétention distingue les couches :

Couche	Rôle	Principe de rétention
Bronze (copie de travail)	Rejouable depuis la source	Fenêtre glissante — la source reste le dépositaire du long terme
Silver / Gold (consolidé, agrégé)	Le capital analytique	Conservation longue (l’horizon 10 ans vit ici)
Journaux techniques	Diagnostic	Courte (mois)
Journaux d’audit	Conformité	7 ans — alignés sur les copies de sauvegarde longue durée

4 · Sauvegarde et reprise

Garanties en place et vérifiées contre l’infrastructure réelle (pas seulement déclarées) :

Restauration à tout point dans le temps sur 7 jours (sauvegardes continues gérées par la plateforme).
Copies longue durée : hebdomadaires (4 semaines), mensuelles (12 mois), annuelles conservées 7 ans — l’exigence de conservation des journaux d’audit s’y adosse.
Géo-réplication des sauvegardes : les copies survivent à la perte de la région principale.
Chiffrement au repos activé ; l’accès applicatif à la base est sans mot de passe (identités managées).
Les fichiers déposés (photos, documents) ont suppression douce 7 jours + versionnage : un écrasement accidentel est récupérable.

5 · Fin de vie — Loi 25

Trois mécanismes, trois maturités :

Minimisation à la source — ✅ la plus forte des protections : les champs critiques (identifiants gouvernementaux, rémunération, mots de passe, données médicales) ne sont jamais extraits de l’ERP. L’audit 360 a vérifié colonne par colonne : la copie employés ne contient que l’identité professionnelle. Ce qu’on n’a pas ne peut pas fuir.
Désactivation logique — ✅ aucune suppression physique dans les applications : les enregistrements sont désactivés, l’historique reste cohérent.
Destruction définitive (droit à l’effacement, art. 23) — 🔴 chantier ouvert : la désactivation logique n’est pas une destruction. Le processus outillé (registre d’effacement, purge, traçabilité) est spécifié dans la feuille de route conformité ; en attendant, une demande d’effacement se traite au cas par cas avec accompagnement.

La traçabilité des accès aux renseignements personnels suit la même honnêteté : la table d’audit et les fonctions de journalisation existent, leur branchement systématique dans les applications est un chantier priorisé.

6 · La gouvernance elle-même — versionnée et testée

Ce qui rend ce cycle durable, c’est que ses règles vivent dans le code, pas dans des têtes :

Lignage as code : chaque table est déclarée dans un catalogue versionné (source, couche, mode de synchronisation) — un contrôle bloquant refuse toute table non cataloguée. Vérifié complet à l’audit : 97 tables, 97 entrées.
Accès as code : les droits de chaque application sont décrits dans un manifeste versionné ; l’isolation par compagnie (RLS) est prouvée comportementalement à chaque build (tests d’intégration sur base jetable) et re-vérifiée contre la production.
Migrations gouvernées : numérotation, idempotence, règles d’application et de retour arrière sont un standard écrit (SQL_MIGRATIONS.md), gardé par quatre contrôles d’intégration continue complémentaires.
Standards de véracité : les registres d’infrastructure et de dépendances sont réalignés sur l’état réel à chaque audit — l’écart déclaré/réel est traité comme un défaut au même titre qu’un bug.

Pour aller plus loin

Architecture de données — la carte des schémas, le médaillon, l’isolation RLS.
Compute & exécution — où tournent les traitements, et ce que coûte le couplage.
Sécurité — la défense en profondeur autour de ces données.
Modèle d’accès — qui peut lire quoi, et comment c’est délégué.
ADR-056 — Architecture médaillon — la décision de structure analytique.
Standards internes : DATA_GOVERNANCE.md, SQL_MIGRATIONS.md, DISASTER_RECOVERY.md (dépôt interne) — le détail opérationnel de chaque étape.