> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Politique de conservation des données par domaine > Définissez l'expurgation des corps de messages, la suppression définitive des conversations closes et les fenêtres de purge du journal d'audit par domaine — la surface de limitation de conservation GDPR art. 5(1)(e) appartenant à l'organisation # Politique de conservation des données par domaine La politique de conservation des données détermine combien de temps trois classes d'enregistrements restent intactes dans votre espace de travail avant que des balayages planifiés ne les expurge ou les supprime. Il s'agit de trois **domaines indépendants** derrière une paire de points de terminaison — l'expurgation des corps de messages, la suppression définitive des conversations closes et la purge du journal d'audit — chacun avec sa propre fenêtre et ses propres valeurs minimales et maximales autorisées. Les trois domaines sont **désactivés par défaut** : un espace de travail qui ne touche jamais cette surface n'a aucun comportement de conservation automatique. ``` GET /api/v1/compliance/data-retention PUT /api/v1/compliance/data-retention ``` Cette page décrit les contrôles de plateforme d'Orbit. **Ce n'est pas un avis juridique.** Combien de temps vous pouvez ou devez conserver les messages, conversations et preuves d'audit dépend de vos régulateurs, de vos contrats et de l'interprétation qu'en fait votre conseil. Confirmez les détails auprès d'un conseil qualifié. *** ## Les trois domaines Chaque domaine répond à une question de limitation de conservation, et vous pouvez activer n'importe quelle combinaison d'entre eux. ### Expurgation des corps de messages (`messages`) Après le nombre de jours que vous configurez, un balayage planifié remplace le corps du message et les identifiants du destinataire/expéditeur par un marqueur expurgé. Les métadonnées de facturation — statut, nombre de segments, prix, erreur opérateur — ainsi que l'accusé de livraison et la piste d'audit restent intacts, de sorte que la facturation et la recherche de litige fonctionnent toujours sur les lignes expurgées. Définissez la fenêtre à `0` pour désactiver le balayage ; toute valeur activée doit se situer dans les bornes autorisées. * Fenêtre autorisée : **7 à 3650 jours** (ou `0` pour désactiver). ### Suppression définitive des conversations closes (`conversations`) Lorsqu'il est activé, un balayage planifié supprime définitivement une ligne de conversation une fois qu'elle est **close** depuis plus longtemps que votre fenêtre. Les lignes de messages rattachées à la conversation ne sont pas supprimées avec elle, si bien que les métadonnées de facturation et d'audit survivent à la purge. Seules les conversations closes sont éligibles ; un fil ouvert n'est jamais balayé. * Fenêtre autorisée : **30 à 3650 jours**. Le plancher de 30 jours empêche la purge d'une conversation qui s'est close il y a seulement quelques heures. * Si vous activez ce domaine sans fenêtre, la valeur plateforme par défaut de **180 jours** s'applique. ### Purge du journal d'audit (`audit_logs`) Lorsqu'il est activé, un balayage planifié supprime définitivement les entrées du journal d'audit plus anciennes que votre fenêtre. Les journaux d'audit sont la piste de preuves de chaque changement de configuration dans votre espace de travail, donc ce domaine porte un plancher réglementaire. * Fenêtre autorisée : **365 à 3650 jours**. Le plancher de 365 jours protège la fenêtre d'examen SOC 2 — vous ne pouvez jamais purger des preuves d'audit de moins d'un an. * Si vous activez ce domaine sans fenêtre, la valeur plateforme par défaut de **2190 jours** (six ans) s'applique, visant l'attente de conservation de HIPAA. La suppression DSAR est distincte de cette politique basée sur l'ancienneté. Une demande de personne concernée ciblée sur un contact suit son propre flux indépendamment de ces fenêtres organisationnelles — voir [Demandes des personnes concernées](/compliance/dsar). *** ## Lire la politique résolue ```bash theme={null} curl https://api.orbit.devotel.io/api/v1/compliance/data-retention \ -H "X-API-Key: dv_live_sk_..." ``` ```json theme={null} { "data": { "messages": { "redact_body_after_days": 90 }, "conversations": { "enabled": true, "delete_closed_after_days": 180 }, "audit_logs": { "enabled": false, "delete_after_days": 2190 }, "bounds": { "messages": { "redact_body_min_days": 7, "redact_body_max_days": 3650 }, "conversations": { "delete_closed_min_days": 30, "delete_closed_max_days": 3650 }, "audit_logs": { "delete_min_days": 365, "delete_max_days": 3650 } } } } ``` La réponse renvoie toujours la valeur résolue pour chaque domaine, plus un objet `bounds` portant la fenêtre min/max autorisée pour chacun — les mêmes valeurs que le tableau de bord utilise pour borner les saisies. La lecture est ouverte à tout rôle authentifié ; un nouvel espace de travail renvoie les valeurs par défaut ci-dessus avec les trois domaines désactivés. *** ## Écrire la politique Les écritures exigent une clé API ou un rôle tableau de bord **propriétaire ou administrateur** — la conservation est un contrôle réglementaire, donc la porte reflète le reste de la surface d'écriture de conformité. Tout autre rôle reçoit `403`. L'écriture est **fusion-à-l'écriture** : chaque bloc de domaine est optionnel, et un bloc que vous omettez conserve sa valeur stockée. N'envoyez que les domaines que vous souhaitez modifier. ```bash theme={null} curl -X PUT https://api.orbit.devotel.io/api/v1/compliance/data-retention \ -H "X-API-Key: dv_live_sk_..." \ -H "Content-Type: application/json" \ -d '{ "messages": { "redact_body_after_days": 90 }, "conversations": { "enabled": true, "delete_closed_after_days": 180 } }' ``` Règles à respecter : * **Fournissez au moins un domaine** — un corps vide renvoie `422 VALIDATION_ERROR`. * **Les valeurs dans l'intervalle sont validées strictement.** Une valeur `redact_body_after_days` activée hors des bornes, ou une fenêtre hors de son min/max, renvoie `422` avec une erreur par champ. * **La résolution est permissive pour l'activation-sans-fenêtre.** Pour `conversations` et `audit_logs`, envoyer `enabled: true` sans fenêtre se résout à la valeur plateforme par défaut (180 et 2190 jours respectivement) ; les valeurs résolues sont celles qu'utilisent les balayages, et la réponse d'une écriture est la même vue résolue que `GET`. * **Chaque modification est enregistrée.** Chaque écriture atterrit dans votre journal d'audit avec les domaines modifiés et l'acteur, préservant la piste de gouvernance de la politique elle-même. *** ## Modèle d'exécution : balayages, pas suppression immédiate Le point de terminaison n'enregistre que la politique. Écrire une fenêtre de 90 jours n'**expurge** rien au moment de l'enregistrement — l'application s'exécute dans des balayages d'arrière-plan planifiés qui appliquent votre politique résolue selon leur propre cadence. Planifiez votre runbook en conséquence : * Un enregistrement plus ancien que sa fenêtre devient éligible au balayage, et est expurgé ou supprimé au prochain balayage — pas à l'instant où il franchit la fenêtre. * Resserrer une fenêtre (par exemple, de 365 jours à 90 jours) met en file les enregistrements nouvellement hors-fenêtre pour le prochain balayage. Ce n'est pas une purge synchrone. * Assouplir ou désactiver une fenêtre empêche les balayages futurs d'expurger ou de supprimer au-delà de ce que la nouvelle politique autorise ; les enregistrements déjà expurgés ou supprimés ne sont pas restaurés. Relisez la politique avec `GET` pour confirmer les valeurs résolues avant de vous y fier dans une procédure interne. *** ## GDPR art. 5(1)(e) : pourquoi la politique existe L'article 5(1)(e) du GDPR encadre la limitation de conservation : les données personnelles doivent être conservées sous une forme permettant l'identification des personnes concernées **pendant une durée n'excédant pas celle nécessaire** aux finalités pour lesquelles elles ont été collectées. Pour un opérateur CPaaS, les enregistrements qui attirent ce principe sont exactement les trois domaines de cette page — les corps de messages portent le contenu client, les conversations portent l'historique du fil, et les journaux d'audit portent la piste de l'espace de travail. La politique par domaine existe pour que vous puissiez exprimer une posture de limitation de conservation en configuration : des fenêtres courtes là où la minimisation compte (corps de messages), des fenêtres plus longues là où un plancher réglementaire l'exige (journaux d'audit), et chaque domaine atteint indépendamment parce qu'un TTL global unique ne convient jamais aux trois. Le plancher d'audit de 365 jours est un exemple de la plateforme détenant un **minimum réglementaire** pour vous — il empêche une fenêtre mal réglée de détruire des preuves SOC 2, pas une limite à l'agressivité de votre posture ailleurs. Votre conseil décide des fenêtres. La plateforme les applique et enregistre chaque modification de la politique elle-même. *** ## Interaction avec le gel juridique et l'export d'archivage Les balayages de conservation sont une machinerie de suppression, donc ils partagent l'espace avec deux contrôles de préservation : * **[Gels juridiques](/compliance/legal-hold).** Un gel sur une conversation exempte ce fil de la machinerie de conservation tant que le gel tient — le balayage l'ignore. Un gel est la posture de préservation contentieuse ; la politique de conservation est la posture de fonctionnement normal, et le gel l'emporte tant qu'il tient. Définissez la politique comme valeur par défaut de l'espace de travail et utilisez les gels pour les exceptions. * **[Export d'archivage immuable](/compliance/archival-export).** L'archivage copie les messages et enregistrements d'appels dans un paquet inviolable dans votre propre stockage WORM ou S3. Si vos obligations survivent à vos fenêtres de conservation, archivez **avant** que les balayages ne commencent à supprimer — la conservation répond à « combien de temps Orbit détient ceci », l'archivage répond à « comment je détiens ma propre copie ». * **Demandes de suppression.** La suppression DSAR s'exécute à l'échelle du contact et indépendamment de cette politique basée sur l'ancienneté ; réconciliez les demandes de suppression ouvertes avec les gels dans le cadre de votre processus DSAR plutôt que d'attendre que les fenêtres de conservation les remplissent. *** ## Votre posture de conservation reste la vôtre La politique de conservation par domaine est un **contrôle appartenant à l'organisation** : Orbit fournit les fenêtres, les balayages et la piste d'audit — ce que valent les fenêtres, et quels domaines s'appliquent à votre posture, sont vos décisions. Les trois domaines restent désactivés jusqu'à ce que vous les activiez, et chaque activation, modification et désactivation est une décision prise par vos propriétaires et administrateurs, enregistrée dans votre journal d'audit. Pour l'assemblage plus large — enregistrements de consentement, entrée DSAR, le registre, le dossier de preuves — parcourez le [guide de posture GDPR](/compliance/gdpr-posture-guide). *** ## Références associées La carte du cycle de vie inter-magasins que cette page de posture suppose — la fenêtre de chaque magasin, le comportement d'expiration et les contrôles de préservation. Exemptez une conversation des balayages de conservation pour la préservation contentieuse. Copiez les enregistrements dans un paquet inviolable avant que les balayages ne les suppriment. Assemblez la posture GDPR complète — consentement, DSAR, le registre et le dossier. Accès et suppression à l'échelle du contact, et comment les réconcilier avec les gels.