Annexe au DPA : boîte noire hébergée par Filarr

Préambule

La présente annexe complète l’Accord de traitement des données (DPA) de Filarr. Elle encadre le traitement de données à caractère personnel par Filarr (édité par Mathis Belouar-Pruvot, personne physique, éditeur à titre personnel, coordonnées dans les Mentions légales, « le Sous-traitant ») pour le compte du client (« le Responsable de traitement ») lorsque celui-ci confie une ou plusieurs bases à la boîte noire hébergée par Filarr.

Pour les seules bases confiées, et tant qu’elles le restent, ces bases ne sont plus chiffrées de bout en bout : leur clé est gérée par nos serveurs, qui les déchiffrent pour servir l’API choisie par le Responsable de traitement. La présente annexe prévaut donc, pour ces bases et pour ce traitement, sur les stipulations du DPA qui décrivent un contenu chiffré et illisible par le Sous-traitant (articles 2, 3, 6 et 7 du DPA). Pour tout le reste, le DPA s’applique sans changement.

1. Définitions

• Boîte hébergée : un accès API dont la boîte noire Filarr Gate est exécutée par un service de Filarr, et non par le Responsable de traitement.
• Base confiée : une base de données Filarr que le Responsable de traitement a cochée, une à une, dans l’accord d’hébergement, et qui n’a été ni retirée ni effacée depuis.
• Service hébergé : le programme filarr-gate-host, qui exécute le code public de Filarr Gate pour chaque boîte hébergée.
• Accord d’hébergement : le texte versionné hebergement-v1 que le Responsable de traitement accepte pour chaque base confiée, en cochant la base, en cochant la mention « J’ai compris… » et en confirmant son identité.
• Reprise de la clé : le retrait d’une base, la révocation de l’accès ou le passage à une boîte noire exécutée par le Responsable de traitement lui-même. Les clés des bases concernées changent alors.
• Sommeil : l’état d’une boîte hébergée qui ne sert plus l’API, sans que rien soit effacé (article 4).
• Reçu d’effacement : le document signé par le service hébergé qui atteste l’exécution d’un effacement (article 10).

2. Rôles

2.1. Pour les données à caractère personnel contenues dans les bases confiées, et pour les autres données traitées par le service hébergé au titre de l’article 5, Filarr agit en qualité de sous-traitant au sens de l’article 28 du RGPD, pour le compte et sur instruction du Responsable de traitement.

2.2. Le Responsable de traitement est le titulaire du compte qui crée la boîte hébergée. Lorsque la boîte est facturée à une organisation, ou qu’une base confiée appartient au coffre d’une organisation, le Responsable de traitement est cette organisation, représentée par la personne qui confie la base. Lorsque le Responsable de traitement agit lui-même comme sous-traitant pour le compte d’un tiers, Filarr agit comme sous-traitant ultérieur et le Responsable de traitement répercute les présentes obligations dans son propre contrat.

2.3. Une base appartenant à un coffre ne peut être confiée que par le propriétaire ou un administrateur de ce coffre. Tout propriétaire ou administrateur du coffre peut la retirer, même s’il n’a pas créé la boîte. Les autres membres du coffre en sont informés par une mention visible sur la base et dans le coffre, et par un avis à leur prochaine ouverture du coffre. Il appartient au Responsable de traitement d’informer les personnes concernées autres que ces membres.

2.4. Filarr demeure responsable de traitement, au titre de sa politique de confidentialité, des données nécessaires à la fourniture de l’option elle-même : compte, facturation, enregistrement des accords, journal de l’accès, nombre d’appels.

3. Objet, nature et finalité

3.1. Objet : exécuter, pour le compte du Responsable de traitement, la boîte noire Filarr Gate sur les bases qu’il confie, afin de servir l’API qu’il a configurée.

3.2. Nature : réception de la clé de chaque base confiée, scellée par l’appareil du Responsable de traitement pour le service hébergé ; déchiffrement des bases confiées ; tenue d’une copie déchiffrée en mémoire ; conservation, au repos, d’un état chiffré (empreintes des clés d’application, secrets des webhooks, requêtes enregistrées, clés et états des synchronisations externes, blocs chiffrés) ; réponse aux requêtes des logiciels du Responsable de traitement ; exécution des écritures que ces logiciels demandent ; envoi des webhooks configurés ; exécution des requêtes enregistrées, du SQL et du protocole MCP ; synchronisation planifiée avec une base externe par un connecteur HTTPS ; réception de fichiers et leur chiffrement pour la boîte de dépôt du Responsable de traitement ; décompte des appels.

3.3. Finalité : servir l’API choisie par le Responsable de traitement, et rien d’autre. Le Sous-traitant n’utilise pas ces données à d’autres fins : ni analyse, ni indexation, ni profilage, ni publicité, ni entraînement de modèles, ni communication à des tiers autres que les destinataires que le Responsable de traitement a lui-même configurés (logiciels munis d’une clé d’application, récepteurs de webhooks, bases externes).

4. Durée

4.1. Le traitement d’une base commence à l’accord d’hébergement donné pour cette base. Il dure tant que la base reste confiée.

4.2. Il prend fin à la reprise de la clé, au retrait de la base, à la révocation de l’accès, au retrait automatique de la base (article 4.4) ou à l’issue d’un sommeil (article 4.3). Le service hébergé efface alors ce qu’il tient et délivre un reçu d’effacement signé (article 10).

4.3. Sommeil. Une boîte hébergée entre en sommeil lorsque l’abonnement qui la porte est suspendu ou résilié pour impayé (à l’issue du délai de grâce de sept jours de l’abonnement), lorsque le palier du créateur passe sous Pro, lorsque l’organisation interdit l’hébergement, ou en cas d’arrêt d’urgence du service par Filarr. Pendant le sommeil :

• le service cesse de servir l’API, arrête les synchronisations et les dépôts, et vide sa mémoire ;
• la clé scellée et l’état chiffré sont conservés, pour permettre le réveil ; rien n’est effacé ;
• la boîte se réveille d’elle-même si la cause disparaît (paiement reçu, palier rétabli, interdiction levée) ;
• le Responsable de traitement peut à tout moment demander l’effacement immédiat ou reprendre la clé.

Le sommeil dure 30 jours. Si sa cause subsiste au terme de ce délai, le service efface la boîte et délivre un reçu d’effacement signé. Un sommeil causé par un arrêt d’urgence du service n’entraîne jamais, à lui seul, d’effacement.

4.4. Nouvelle version de l’accord. Si le texte de l’accord d’hébergement change, les boîtes en service continuent 30 jours ; la base porte un avis. Sans nouvel accord au 30e jour, la base est retirée de la boîte, avec reçu d’effacement.

5. Catégories de données et de personnes concernées

5.1. Le Sous-traitant ne connaît pas à l’avance les données traitées : elles sont déterminées par le Responsable de traitement, qui choisit les bases qu’il confie et leur contenu. Elles comprennent :

• toutes les lignes et toutes les colonnes des bases confiées, y compris celles qu’aucune vue ne montre ;
• tout ce qui s’y écrit tant qu’elles restent confiées, par le Responsable de traitement, par les membres du coffre ou par l’API ;
• les requêtes des logiciels du Responsable de traitement et les réponses ;
• les lignes d’une base externe branchée sur la boîte, et la clé de cette base externe ;
• les fichiers que reçoit la boîte, le temps de leur passage, avant leur chiffrement pour la boîte de dépôt ;
• les données que portent les webhooks configurés.

5.2. Les personnes concernées sont celles dont le Responsable de traitement met les données dans ses bases (par exemple ses clients, prospects, salariés, fournisseurs, ou les membres de ses coffres).

5.3. Le Sous-traitant n’a aucun moyen de savoir si une base confiée contient des catégories particulières de données (article 9 du RGPD) ou des données relatives à des condamnations (article 10). Il appartient au Responsable de traitement d’apprécier, au regard des mesures décrites en annexe 1 et de leurs limites, si la boîte hébergée convient aux données qu’il y confie, et de mener, s’il y a lieu, une analyse d’impact.

5.4. Ne sont pas concernés par ce traitement : les bases non confiées, les notes, les fichiers et les coffres du Responsable de traitement, ainsi que les clés de son compte et de ses coffres. La clé de chaque base confiée est dérivée à sens unique : elle ne permet de retrouver ni la clé du compte ni celle d’un coffre.

6. Obligations du Sous-traitant

Le Sous-traitant :

a) ne traite les données que sur instruction documentée du Responsable de traitement. Constituent ces instructions : l’accord d’hébergement, la configuration de la boîte faite depuis Réglages › Accès API (clés d’application, webhooks, requêtes enregistrées, bases externes, filtres de fichiers) et la présente annexe. Si le droit de l’Union ou d’un État membre l’oblige à un autre traitement, il en informe le Responsable de traitement avant le traitement, sauf si ce droit l’interdit. Il informe immédiatement le Responsable de traitement s’il estime qu’une instruction constitue une violation du RGPD ou d’une autre disposition applicable en matière de protection des données ;

b) veille à ce que les personnes autorisées à traiter les données s’engagent à en respecter la confidentialité. Dans le fonctionnement courant, aucune personne n’accède au contenu des bases confiées : il n’existe ni route d’administration qui lise ce contenu, ni console ;

c) met en œuvre les mesures techniques et organisationnelles décrites en annexe 1 ;

d) respecte les conditions de recours à des sous-traitants ultérieurs de l’article 7 ;

e) aide le Responsable de traitement à répondre aux demandes d’exercice des droits (article 8) ;

f) aide le Responsable de traitement à respecter ses obligations des articles 32 à 36 du RGPD, compte tenu de la nature du traitement et des informations dont il dispose : sécurité (annexe 1), notification des violations (article 9), analyse d’impact (le Sous-traitant fournit la présente annexe, la page de confiance et l’accès au code public du service) ;

g) au terme du traitement, efface les données selon l’article 10 ;

h) met à disposition les informations nécessaires pour démontrer le respect de l’article 28 du RGPD et permet les audits prévus à l’article 11 ;

i) tient un registre des traitements effectués pour le compte du Responsable de traitement (article 30, paragraphe 2, du RGPD).

7. Sous-traitants ultérieurs

7.1. Le Responsable de traitement autorise le recours aux sous-traitants ultérieurs suivants pour ce traitement :

7.2. Les conditions générales de l’article 5 du DPA s’appliquent : liste publique sur la page Sous-traitants, information préalable avant tout ajout ou remplacement, droit d’objection, obligations de protection équivalentes imposées à chaque sous-traitant ultérieur.

7.3. Ne sont pas des sous-traitants ultérieurs de Filarr les destinataires que le Responsable de traitement choisit lui-même : ses logiciels, les récepteurs de ses webhooks et les fournisseurs de ses bases externes.

8. Droits des personnes concernées

8.1. Le Sous-traitant ne dispose d’aucun outil pour rechercher ou consulter une personne dans une base confiée. Le Responsable de traitement répond donc lui-même aux demandes d’accès, de rectification, d’effacement, de limitation, de portabilité ou d’opposition, depuis ses applications Filarr : une ligne modifiée ou supprimée dans une base confiée l’est aussi dans la copie du service hébergé, à la synchronisation suivante. Il peut aussi retirer la base ou reprendre la clé à tout moment.

8.2. Si une personne concernée adresse sa demande directement au Sous-traitant au sujet d’une base confiée, le Sous-traitant la transmet sans délai injustifié au Responsable de traitement, sans y répondre sur le fond, sauf instruction contraire de celui-ci.

8.3. Le Sous-traitant fournit au Responsable de traitement, à sa demande, les informations dont il dispose sur le traitement (dates d’accord, versions du service, sommeils, reçus d’effacement), qui figurent aussi au journal de l’accès.

9. Violations de données

9.1. Le Sous-traitant notifie au Responsable de traitement toute violation de données à caractère personnel affectant une base confiée ou les autres données de l’article 5, sans délai injustifié après en avoir pris connaissance, et au plus tard 72 heures après en avoir pris connaissance.

9.2. La notification est adressée par courriel à l’adresse du compte qui a créé la boîte et, pour une boîte facturée à une organisation, aux personnes qui en gèrent la facturation. Elle décrit, dans la mesure où le Sous-traitant en dispose : la nature de la violation, les bases et la période concernées, ses conséquences probables, les mesures prises ou proposées, et un point de contact. Le Sous-traitant ne connaissant pas le contenu des bases, il ne peut pas, en général, indiquer le nombre de personnes ou d’enregistrements concernés. Les informations qui ne sont pas disponibles immédiatement sont fournies ensuite, par étapes.

9.3. Lorsqu’une faille est corrigée par un correctif de sécurité mis en service sans le délai de sept jours (annexe 1, point 6), chaque accès hébergé en reçoit l’avis à son journal, et le journal public des mises en service le mentionne. Cet avis ne remplace pas la notification de l’article 9.1 lorsqu’une violation est constatée.

10. Sort des données au terme du traitement

10.1. Au terme du traitement d’une base ou d’une boîte (article 4.2), le service hébergé efface tout ce qu’il tient pour elle : la clé scellée, les clés des bases, la copie déchiffrée, l’état de la boîte et les clés des bases externes. La clé scellée est effacée de la base de données de l’API de Filarr dès la demande d’effacement.

10.2. Le service délivre alors un reçu d’effacement signé (signature Ed25519 de la clé du service), qui indique la raison, la date de la demande et celle de l’effacement, les bases et la génération de clé tenues, ce qui a été effacé, la version et l’empreinte du code du service. Le reçu est ajouté au journal de l’accès, affiché dans les applications de Filarr et vérifiable contre la clé publique du service qu’elles embarquent. Le retrait d’une seule base donne un reçu partiel.

10.3. Restitution. Les bases confiées restent à tout moment dans le compte du Responsable de traitement, chiffrées de bout en bout comme avant : il n’y a pas de données à restituer. Lorsque le Responsable de traitement passe à une boîte noire qu’il exécute lui-même, le service lui transmet, scellé pour cette nouvelle boîte, le paquet de réglages (empreintes des clés d’application, webhooks, requêtes enregistrées). Les clés des bases externes n’en font pas partie : le Responsable de traitement doit les changer auprès de leur fournisseur.

10.4. Ce que prouve le reçu, et ce qu’il ne prouve pas. Le reçu prouve que le service a exécuté l’ordre d’effacement ; il ne peut pas prouver qu’aucune copie n’existe ailleurs. Les mécanismes de restauration propres à l’hébergeur peuvent conserver, pendant la durée qu’il fixe, des versions antérieures, chiffrées, de ces éléments. Après la reprise, les clés des bases changent : ce qui s’y écrit ensuite est de nouveau chiffré de bout en bout, sous des clés que le service hébergé n’a jamais reçues, ce qui est garanti par le chiffrement. Ce que le service a traité avant la reprise reste couvert par les seuls engagements de la présente annexe.

10.5. Le Sous-traitant conserve, en qualité de responsable de traitement, le journal de l’hébergement de l’accès (accords, versions du service, sommeils, retraits, reçus d’effacement), qui ne contient aucun contenu de base, pendant cinq ans.

11. Audits et information

11.1. Le Sous-traitant met à disposition :

• le code source du service hébergé et de Filarr Gate, publié dans le dépôt public filarr-gate, et la marche à suivre pour reconstruire une version et son empreinte ;
• le journal public des mises en service (version, étiquette, empreinte du code, date de publication, date de mise en service, et correctifs de sécurité avec leur avis) ;
• l’empreinte du code (codeHash) que chaque boîte hébergée annonce, signée par la clé du service, inscrite au journal de l’accès à chaque mise en service et comparable à celle de la version publiée ;
• la présente annexe et la page de confiance.

11.2. Revue de sécurité externe. Une revue de sécurité du service hébergé par un tiers indépendant est prévue. À la date de la présente version, elle n’a pas encore eu lieu. La page de confiance indiquera sa date lorsqu’elle aura été réalisée.

11.3. Les audits sur pièces ou sur place sont possibles dans les conditions de l’article 9 du DPA (préavis, confidentialité et sécurité des autres clients). Ils ne peuvent porter sur les installations de Cloudflare, dont le contrôle relève de ses propres conditions.

12. Transferts hors de l’Union européenne

12.1. Les copies restent dans l’Union européenne : l’état de chaque boîte hébergée et son exécution se trouvent dans des objets durables créés en juridiction UE chez Cloudflare.

12.2. Le transit peut passer hors de l’Union européenne. Une requête et sa réponse traversent le point de présence de Cloudflare le plus proche de l’appelant, où le chiffrement en transit (TLS) est terminé : si le logiciel qui appelle la boîte se trouve hors de l’Union européenne, la requête et la réponse y sont déchiffrées en transit. La terminaison du TLS dans la seule Union européenne n’est pas proposée.

12.3. L’API principale de Filarr ne traite, pour une boîte hébergée, que des blocs chiffrés, des clés scellées et des compteurs, dans les conditions de l’article 6 du DPA.

12.4. Cloudflare, Inc. et Stripe, Inc. sont établies aux États-Unis. Les transferts vers ces sociétés reposent sur la décision d’adéquation de la Commission européenne relative au cadre de protection des données UE–États-Unis (décision d’exécution (UE) 2023/1795 du 10 juillet 2023), pour autant que la société figure sur la liste officielle de ce cadre, et, à défaut ou en complément, sur les clauses contractuelles types de la Commission européenne (décision d’exécution (UE) 2021/914) incluses dans leurs accords de traitement des données. Pour les bases confiées, le chiffrement de bout en bout ne s’applique pas : la protection des données transférées repose sur ces garanties contractuelles et sur les mesures de l’annexe 1.

13. Dispositions finales

13.1. La présente annexe est acceptée par le Responsable de traitement lorsqu’il confie une base à la boîte hébergée. Elle reste en vigueur tant qu’une base est confiée et, pour les articles 9, 10 et 11, jusqu’à l’effacement complet.

13.2. Une version signée est disponible sur demande à contact@filarr.com.

Annexe 1 : mesures techniques et organisationnelles

1. Isolement par script

Le service hébergé est un script Worker distinct, filarr-gate-host, dans le même compte Cloudflare que l’API de Filarr. Il a ses propres objets durables et ses propres secrets. Le script de l’API ne déclare aucune liaison vers eux (ni base de données, ni stockage, ni objets durables, ni liaison de service), et réciproquement ; un test lit la configuration des deux scripts et échoue si une telle liaison apparaît.

Ce que l’isolement garantit : la clé scellée d’une boîte n’est jamais en clair dans la base de données de l’API, ni dans ses sauvegardes, son historique ou un export ; un défaut ou une compromission du code de l’API ne donne accès ni aux secrets du service, ni à ses objets durables, ni à une clé en clair.

2. Clés

• La clé de chaque base confiée est scellée par l’appareil du Responsable de traitement vers la clé publique du service (X25519), épinglée dans les applications de Filarr ; une application ne scelle jamais vers une clé absente de sa liste embarquée. Le jeton n’existe en clair que dans la mémoire de l’appareil, le temps du scellé, puis dans la mémoire du service hébergé ; il n’est jamais affiché.
• Les clés privées du service (HOST_ENC, X25519 ; HOST_SIG, Ed25519) sont des secrets du seul script du service. La clé gérée par nos serveurs est celle du service hébergé.
• Un jeton d’accès hébergé est refusé par l’API de Filarr s’il n’est pas présenté avec la signature du service.
• La clé de chaque base est propre à cette base et à une génération ; elle est dérivée à sens unique et n’ouvre ni le compte, ni un coffre, ni une autre base.
• Au repos, l’état de chaque boîte est chiffré (AES-256-GCM) sous une clé qui n’existe qu’en mémoire. La copie déchiffrée des bases ne vit qu’en mémoire.

3. Aucune journalisation du contenu

• Le service est configuré sans journaux, sans traces et sans export de journaux (bloc d’observabilité présent et entièrement désactivé, aucun Logpush, aucun consommateur de traces) ; un test refuse toute trace activée et l’absence de ce bloc.
• Le code n’écrit aucune requête, réponse, ligne, nom de fichier, adresse de webhook ou de base externe dans une sortie de console ; la seule sortie est un code d’erreur d’une liste fermée.
• Seules sont mesurées : le nombre d’appels par heure et par accès, les codes d’erreur, les durées.
• Pour les adresses *.gate.filarr.com, des règles de la zone filarr.com désactivent le pare-feu géré, le défi anti-robots et la détection JavaScript, sans journalisation des requêtes concernées ; aucun autre Worker de zone n’y est routé et aucun export de journaux ne couvre ces noms.

4. Localisation des copies

Les objets durables de chaque boîte sont créés en juridiction UE : stockage et exécution dans l’Union européenne.

5. Transit

Les requêtes et les réponses traversent le point de présence de Cloudflare le plus proche de l’appelant, qui peut être hors de l’Union européenne. Le chiffrement en transit (TLS) est terminé par la zone filarr.com, gérée par le même compte Cloudflare que l’API de Filarr : ces requêtes et réponses ne sont pas chiffrées de bout en bout.

6. Mise en service du code

• Une version du service n’entre en service que par la chaîne d’intégration, depuis une étiquette signée du dépôt public filarr-gate ; aucun déploiement depuis un poste de travail ; le jeton de déploiement n’existe que dans la chaîne.
• Un journal public liste chaque version publiée et mise en service : version, étiquette, empreinte du code, date de publication (celle de la réception de l’étiquette par la chaîne), date de mise en service.
• Sept jours au moins séparent la publication d’une version de sa mise en service ; la chaîne refuse une mise en service plus tôt.
• Seule exception : le correctif de sécurité, réservé à la correction d’une faille qui met en jeu la confidentialité ou l’intégrité des bases confiées, de leurs clés, des jetons ou de l’isolement, décrite dans un avis de sécurité du dépôt public. Il est déclenché par le responsable de la sécurité de Filarr, seul détenteur de la clé de signature réservée à ce rôle, et part de la dernière version en service. Le journal public le mentionne au moment de la mise en service (« correctif de sécurité, délai de sept jours levé », identifiant et gravité de l’avis) ; chaque accès hébergé en reçoit l’avis ; le détail de la faille est publié dans l’avis au plus tard 30 jours après ; la page de confiance tient le compte des exceptions utilisées par an.
• Compte Cloudflare : membres réduits au minimum, double authentification exigée, aucun jeton capable de déployer hors de la chaîne d’intégration, journal d’audit du compte relu à chaque mise en service.

7. Absence d’attestation à distance

Chaque boîte annonce la version et l’empreinte de son code, signées par la clé du service ; chacun peut les comparer à celles de la version publiée. Cette comparaison vérifie ce que le service annonce. Cloudflare Workers n’offre pas d’attestation à distance : personne, Filarr compris, ne peut prouver que le code qui tourne est le code annoncé. Ce point est encadré par la chaîne de mise en service, le journal public et les engagements de Filarr.

8. Accès et gestion

Il n’existe ni interface de gestion web sur le service, ni route d’administration qui lise le contenu, ni console. La boîte se règle uniquement depuis les applications de Filarr, par des requêtes signées par la clé d’identité du créateur de l’accès, chacune acceptée une seule fois. Aucune personne n’accède au contenu dans le fonctionnement courant.

9. Accord, transparence et contrôle

• Accord exprès, base par base, avec confirmation d’identité ; enregistrement de la version, de la langue et de l’empreinte du texte accepté, de son auteur, de sa date et de l’appareil.
• Mention « API hébergée par Filarr · pas chiffrée de bout en bout » sur chaque base confiée, pour tous ceux qui la voient ; avis aux membres d’un coffre ; événement au fil d’activité du coffre.
• Une organisation peut interdire l’hébergement à ses membres et à ses coffres.
• Retrait d’une base, révocation ou reprise de la clé à tout moment ; changement des clés des bases ; reçu d’effacement signé.

10. Ce que ces mesures ne protègent pas

• L’isolement par script ne fait pas barrière à un administrateur du compte Cloudflare de Filarr : celui-ci peut mettre en service du code et changer la configuration de la zone. Ce qui l’encadre est la mise en service par la seule chaîne d’intégration, le journal public, la revue externe prévue et les engagements de Filarr, et non une barrière technique.
• Les requêtes et les réponses ne sont pas chiffrées de bout en bout en transit ; une interception par le compte qui gère la zone ne laisserait aucune trace publique, le certificat étant légitimement le sien.
• Les données sont déchiffrées en mémoire sur les machines de Cloudflare ; à l’égard de Cloudflare, en tant qu’hébergeur, leur protection repose sur ses engagements contractuels et non sur le chiffrement.
• Les règles de zone ne couvrent pas les journaux internes de Cloudflare.
• Le reçu d’effacement prouve l’exécution de l’ordre par le service, non l’absence de toute copie ailleurs.
• Ce que le service a traité avant la reprise de la clé reste couvert par les seuls engagements.