RGPD et conformité

Hébergement en UE, registre des sous-traitants, export RGPD via l'API, gestion des demandes d'accès et de suppression (DSAR), durées de conservation et mesures de sécurité.

Coffrify est conçu pour vous aider à respecter le Règlement général sur la protection des données (RGPD) lorsque vous traitez des fichiers et des documents pour le compte de vos utilisateurs. Cette page décrit où vos données sont hébergées, comment Coffrify se positionne en tant que sous-traitant, et comment l'API vous permet d'honorer concrètement les droits des personnes : droit d'accès, droit à la portabilité et droit à l'effacement. Vous y trouverez aussi nos durées de conservation et un aperçu des mesures de sécurité organisationnelles. L'objectif est opérationnel : vous donner les points d'appui techniques et contractuels pour bâtir un traitement conforme au-dessus de Coffrify.

Hébergement et résidence des données en UE

Toutes les données que vous confiez à Coffrify (fichiers transférés, dépôts reçus via la Réception, documents de coffres, métadonnées associées) sont hébergées sur des infrastructures situées dans l'Union européenne. Le stockage, le traitement et les sauvegardes restent dans l'UE. Aucune réplication du contenu de vos transferts ou de vos coffres n'est effectuée en dehors de l'Espace économique européen dans le cadre du service standard.

Cette résidence européenne s'étend à la couche d'intelligence artificielle. Les fonctions d'IA de la plateforme s'appuient sur Mistral, un fournisseur européen, afin de conserver une chaîne de traitement souveraine. Le recours à l'IA reste cantonné aux fonctionnalités qui l'exigent et n'entraîne pas de conservation du contenu au-delà du traitement demandé.

Rôles : responsable de traitement et sous-traitant

Pour les données de vos utilisateurs finaux que vous traitez via l'API, vous agissez généralement en tant que responsable de traitement et Coffrify en tant que sous-traitant, au sens de l'article 28 du RGPD. À ce titre, Coffrify ne traite ces données que sur vos instructions, telles qu'exprimées par vos appels à l'API (créer un transfert, ouvrir un point de Réception, conserver un document dans un coffre, etc.).

Coffrify tient un registre des sous-traitants ultérieurs (les prestataires techniques mobilisés pour fournir le service, par exemple l'hébergement en UE et le fournisseur d'IA Mistral). Ce registre précise la finalité de chaque intervenant et la localisation du traitement. Il vous permet de documenter votre propre registre des activités de traitement et d'informer les personnes concernées.

Chiffrement et minimisation

Par défaut, le contenu est chiffré côté serveur en AES-256-GCM, au repos et en transit. Vous pouvez activer un chiffrement de bout en bout optionnel : dans ce mode, la clé reste chez vous et le serveur ne peut pas lire le contenu. C'est une mesure de minimisation forte pour les données les plus sensibles. Gardez toutefois à l'esprit que si vous perdez votre clé ou votre phrase secrète, personne ne peut récupérer les données : prévoyez une gestion de clés adaptée côté responsable de traitement.

Export RGPD (droit d'accès et portabilité)

Pour répondre à une demande d'accès ou de portabilité, l'API expose un point d'export dédié. Il rassemble les données rattachées à votre compte dans un format structuré et réutilisable, que vous pouvez ensuite transmettre à la personne concernée. L'appel nécessite le scope gdpr:export : n'accordez ce scope qu'aux clés qui en ont réellement besoin.

POST/v1/gdpr/exportDéclenche un export RGPD des données rattachées au compte. Scope requis : gdpr:export.

import { Coffrify } from '@coffrify/sdk';
 
const coffrify = new Coffrify({ apiKey: process.env.COFFRIFY_API_KEY });
 
const job = await coffrify.gdpr.export({
  // portée optionnelle selon votre cas (ex. limiter à un sujet)
  subject_email: 'personne@example.com',
}, {
  idempotencyKey: 'gdpr-export-2026-06-10-001',
});
 
console.log(job.id, job.status);

L'export étant une opération d'écriture, fournissez systématiquement un en-tête Idempotency-Key (8 à 255 caractères) pour qu'un rejeu accidentel ne relance pas le traitement. En cas de rejeu d'une requête identique, la réponse porte l'en-tête X-Coffrify-Idempotent-Replay: true. Si vous réutilisez la même clé avec un corps différent, l'API renvoie une erreur 409.

Demandes de suppression et d'accès (DSAR)

Une demande d'exercice de droits (DSAR, pour Data Subject Access Request) couvre principalement l'accès, la portabilité et l'effacement. Côté accès et portabilité, appuyez-vous sur l'export ci-dessus. Côté effacement, la suppression d'une ressource via l'API (par exemple un transfert ou un dépôt reçu) rend son contenu inaccessible et déclenche son retrait selon nos durées de conservation décrites plus bas.

Identifier la personne et le périmètre : retrouvez les ressources concernées (transferts, dépôts de Réception, fichiers de coffres) à partir de vos propres identifiants applicatifs ou des métadonnées que vous y avez stockées.
Accès / portabilité : déclenchez POST /v1/gdpr/export puis transmettez le résultat à la personne dans un format réutilisable.
Effacement : supprimez les ressources visées via leurs points de suppression respectifs ; le contenu devient inaccessible immédiatement.
Tracer la demande : conservez la preuve de traitement de la demande (date, périmètre, action) dans votre propre registre.

Durées de conservation

Le contenu des transferts est éphémère par conception. Vous maîtrisez sa durée de vie à la création grâce aux paramètres d'expiration et de plafond de téléchargements ; passé l'expiration, le contenu n'est plus accessible et est retiré. Pour les données réceptionnées et les documents de coffres, la conservation suit votre usage : tant que la ressource existe dans votre espace, elle est conservée ; sa suppression entraîne son retrait.

Donnée	Durée par défaut	Contrôle
Transfert (contenu)	Selon expiration choisie	`expires_in_hours`, `max_downloads`
Dépôt de Réception	Tant que conservé dans l'espace	Suppression du dépôt
Document de coffre	Tant que conservé dans le coffre	Suppression du fichier ou du coffre
Environnement sandbox	24 h, puis purge automatique	Isolé, hors facturation

L'environnement sandbox (clés cof_sandbox_…) est particulièrement utile pour la conformité : il est isolé, éphémère (24 h) et assorti de garde-fous (10 Mo par fichier, 10 fichiers, 25 transferts par 24 h, 5 téléchargements). Utilisez-le pour tester vos flux RGPD sans manipuler de données réelles ni impacter la facturation.

Mesures de sécurité organisationnelles

Au-delà du chiffrement, la conformité repose sur des mesures organisationnelles que vous pilotez via la gestion fine des accès. Émettez des clés au moindre privilège, en n'accordant que les scopes nécessaires à chaque intégration. Préférez des clés restreintes (cof_rk_live_…) pour les usages limités, et réservez les opérations sensibles comme l'export RGPD à des clés dotées du seul scope gdpr:export.

Cloisonnement des environnements : cof_live_… en production, cof_test_… pour vos tests, cof_sandbox_… pour l'expérimentation isolée.
Moindre privilège : scopes ciblés (transfers:read, intake:write, webhooks:manage, gdpr:export…) plutôt que des clés trop larges.
Rotation des secrets : faites tourner régulièrement vos clés via le scope api_keys:manage et révoquez celles qui ne servent plus.
Webhooks signés : vérifiez la signature des webhooks à l'aide du secret whsec_… (montré une seule fois) pour garantir l'intégrité des notifications.
Traçabilité : conservez le request_id renvoyé dans les erreurs et journalisez vos appels pour vos audits.

Pour les clés publiables de Réception (préfixe cip_, sûres pour le navigateur), gardez à l'esprit qu'elles n'autorisent que le dépôt. La lecture et la récupération des dépôts passent par une clé secrète serveur dotée du scope intake:read : ne l'exposez jamais côté client. Cette séparation limite la surface d'exposition des données réceptionnées.