Accord de traitement de données

À propos de ce document

En vertu de l'article 28 du Règlement général sur la protection des données (RGPD) de l'Union européenne, lorsqu'un client utilise un service pour traiter des données à caractère personnel en son nom, un accord écrit doit exister entre le client (le responsable du traitement) et le prestataire de service (le sous-traitant). Traditionnellement, cet accord est rédigé par le responsable et envoyé au sous-traitant, demandant les protections spécifiques qu'exige le programme de conformité du responsable.

Bricks publie cet accord de traitement de données dans le sens inverse. Plutôt que d'attendre que chaque client nous envoie sa propre version, nous rendons publiques et versionnées les mesures techniques et organisationnelles que la plateforme met réellement en œuvre. Les clients peuvent examiner ce qui est en place avant de s'inscrire, orienter leur délégué à la protection des données vers cette page unique lors de leur diligence raisonnable, et demander des modifications spécifiques en écrivant à support@bricks-softwares.com.

Ce document constitue l'offre standard. Lorsque le régulateur, le cadre ou le secteur d'un client impose des exigences supplémentaires (par ex. santé, services financiers, marchés publics), nous négocions un avenant par client sans frais additionnels.

Cette page n'est pas les Conditions Générales de Service de la plateforme. Les Conditions Générales régissent la relation commerciale — tarification, niveaux de service, propriété intellectuelle, responsabilité — et se trouvent à l'adresse /terms. Les deux documents sont complémentaires et signés indépendamment.

Ce que ce document est et n'est pas. Il s'agit d'une description des mesures techniques et organisationnelles que la plateforme met en œuvre et s'engage à maintenir tant que le service Bricks reste opérationnel. Il ne constitue pas un accord commercial contraignant par client ; l'accord commercial contraignant est constitué des Conditions Générales et de tout avenant par client que nous négocions lorsque le secteur ou le cadre du responsable impose des exigences supplémentaires (voir §17 ci-dessous). Cette page évolue à mesure que la plateforme évolue ; les révisions substantielles sont versionnées et notifiées conformément au §17.

1. Parties et rôles

• Sous-traitant — RainbowTop Softwares SRL, opérateur de la plateforme Bricks et de l'écosystème Bricks Softwares.
• Responsable du traitement — le client (le « locataire ») qui configure la plateforme Bricks pour traiter les données à caractère personnel de ses propres utilisateurs finaux (membres, visiteurs, partenaires). Le responsable décide quelles données personnelles sont collectées, sur quelle base juridique, et à quelle finalité ; Bricks exécute ces instructions via la plateforme.
• Personnes concernées — les utilisateurs finaux du responsable dont les données à caractère personnel sont traitées par la ou les applications du responsable s'exécutant sur Bricks.

2. Objet, nature, finalité, durée

Bricks fournit une plateforme Software-as-a-Service multi-locataire qui permet à un responsable de concevoir des schémas de données, de définir des contrôles d'accès, d'exécuter des workflows côté serveur, de déployer une application web publique ou authentifiée, et d'utiliser un assistant IA pour construire cette application. Les données personnelles traitées sont celles que le responsable configure son application pour collecter — généralement informations de compte d'utilisateur final, contenu créé par l'utilisateur, et signaux d'utilisation de la plateforme.

Le traitement dure pendant toute la durée de l'abonnement du responsable. À la résiliation, le responsable peut exporter ses données dans un format portable et Bricks supprime les stockages primaires du locataire dans les trente (30) jours ; les sauvegardes froides expirent selon leur propre calendrier glissant (voir §11).

3. Infrastructure multi-locataire

Bricks fonctionne comme une plateforme multi-locataire unique — un seul ensemble de machines physiques sert chaque client. L'isolation est appliquée à plusieurs couches pour que deux clients fonctionnant sur le même matériel ne puissent ni lire, ni modifier, ni même découvrir les données l'un de l'autre.

3.1 Schémas de base de données par locataire

Chaque locataire reçoit un schéma PostgreSQL dédié (tenant_<slug>). Toutes les tables, vues et procédures stockées du locataire vivent à l'intérieur de ce schéma. La variable de session PostgreSQL search_path, définie par requête à partir du JWT de l'utilisateur authentifié, restreint l'exécution SQL au schéma du locataire qui effectue la requête. Une requête inter-locataires n'est pas « bloquée au niveau de l'API » — elle est impossible à exprimer, car les tables concernées ne sont pas visibles à cette session.

3.2 Sécurité au niveau des lignes

À l'intérieur de chaque schéma de locataire, les politiques de sécurité au niveau des lignes (Row-Level Security, RLS) de PostgreSQL restreignent davantage les lignes qu'un utilisateur final donné peut lire ou modifier. Les politiques découlent du modèle d'accès de la plateforme : les administrateurs d'organisation voient l'ensemble du locataire, les membres voient ce que leur rôle accorde, les visiteurs anonymes ne voient que ce qui est explicitement publié. La RLS s'exécute dans le moteur de base de données lui-même, de sorte que même un serveur d'application défaillant ne peut pas la contourner.

La matérialisation effective de la RLS est elle-même vérifiée à chaque livraison. Une suite de tests au niveau plateforme (les substrate specs) itère sur chaque locataire actif en intégration continue et confirme que les politiques select / insert / update / delete dérivées des rôles existent sur chaque table qui en a besoin. Une régression qui supprimerait silencieusement une politique sur un seul locataire ne peut pas atteindre la production : la barrière de pré-déploiement refuse de livrer si la spec substrat échoue ne serait-ce que pour un locataire. Ceci s'ajoute, sans s'y substituer, à l'application par le moteur de base de données décrite ci-dessus — la spec vérifie que les politiques que le moteur applique sont bien celles que le modèle d'accès entend appliquer.

3.3 Sous-domaines dédiés par application

Chaque application publiée d'un locataire reçoit son propre sous-domaine dédié (<slug>.apps.bricks-softwares.com) et, optionnellement, un ou plusieurs domaines personnalisés vérifiés. La politique d'origine identique (Same-Origin Policy) du navigateur isole chaque application comme sa propre origine — les cookies, le stockage de session, IndexedDB et les service workers de l'application d'un locataire sont cryptographiquement empêchés d'être lus par l'application d'un autre locataire, même lorsque les deux s'exécutent dans le même navigateur. Cela s'ajoute à l'isolation côté serveur décrite ci-dessus, sans la remplacer.

3.4 Stockage d'objets par locataire

Les actifs du locataire (fichiers téléversés, images générées par l'IA, artefacts de build d'application) sont stockés sur un stockage d'objets compatible S3 (Scaleway Object Storage, région fr-par) sous un préfixe de clé par locataire. La plateforme refuse de construire des clés en dehors du préfixe du locataire appelant ; les URL de téléchargement signées sont limitées au locataire appelant uniquement.

3.5 Chiffrement

En transit : tout trafic vers *.bricks-softwares.com et vers *.apps.bricks-softwares.com est servi exclusivement en TLS 1.2+ avec des certificats émis par Let's Encrypt et renouvelés automatiquement. Les domaines personnalisés rattachés par les locataires reçoivent également leurs propres certificats TLS dès leur première vérification, via Let's Encrypt. Les écouteurs HTTP ne sont pas exposés publiquement.

Au repos : le stockage VPS sous-jacent chez notre fournisseur d'hébergement (Infomaniak, Suisse) est chiffré au niveau du disque (AES-256) par le centre de données. La base PostgreSQL managée (Scaleway, France) et le stockage S3 (Scaleway, France) sont chiffrés au repos par le fournisseur ; le secret store de la plateforme hérite du chiffrement disque d'Infomaniak.

3.6 Gestion des accès et des permissions

Les utilisateurs d'un locataire s'authentifient auprès d'un système d'identité par locataire. Le responsable (rôle org admin) assigne des rôles à son équipe et à ses utilisateurs finaux ; les politiques de permission sur les tables et les chemins de propriété traduisent ces rôles en accès au niveau des lignes. Le personnel de la plateforme ne peut pas se faire passer pour un utilisateur d'un locataire. Les accès par le personnel de la plateforme à l'infrastructure d'un locataire à des fins de support sont journalisés et limités aux opérateurs ayant une justification métier documentée.

Les outils d'exploitation au niveau plateforme (telle que la vue d'audit du stockage inter-locataires utilisée par les administrateurs pour surveiller l'empreinte sur le stockage d'objets) sont construits par-dessus le substrat RLS plutôt qu'en le contournant : ils agrègent des métadonnées qui ne nécessitent pas la lecture de lignes de locataires, et ils n'élèvent pas vers une session qui pourrait lire des données locataires. Le besoin opérationnel de voir la plateforme dans son ensemble ne donne pas à l'équipe plateforme un chemin pour contourner la frontière de données du responsable.

3.7 Sauvegarde, restauration et drapeau de maintenance

Des instantanés (snapshots) par locataire de la base de données sont pris via pg_dump dans la dorsale de stockage d'objets de la plateforme. L'instantané est lié à l'identifiant du locataire et stocké aux côtés des autres données de ce locataire, et non dans un pool de sauvegardes inter-locataires — les mêmes règles d'isolation décrites au §3.1 s'appliquent à l'instantané lui-même.

La prise d'instantané avant une opération destructive de schéma est conditionnée au mode. Sous le mode « raisonnement avancé » contre un locataire en production (le défaut de la plateforme pour les locataires en données réelles), l'IA Studio capture automatiquement un instantané avant toute opération alter_column destructive qu'elle réaliserait pour le compte du responsable — l'instantané sert de point de récupération. Sous le mode « preprod » (que l'exploitant active lorsque le locataire ne porte que des données de test), l'auto-capture est désactivée pour éviter du stockage gaspillé. Sous le mode standard, l'IA remonte une recommandation et clôt le tour en attendant l'instantané manuel de l'exploitant — le budget par tour est dimensionné pour de petites corrections, pas pour un cycle autonome capture-puis-application. Dans tous les modes, le locataire est placé derrière un court drapeau de « maintenance » pendant la mutation elle-même, de sorte que le trafic visiteur est servi par une page d'état plutôt que par un schéma à moitié modifié. La restauration depuis un instantané est elle-même une opération explicite, limitée au locataire d'origine, et consignée dans le journal opérationnel de la plateforme.

La boucle interne de vérification-avant-application de l'IA Studio, disponible sous le mode « raisonnement avancé », utilise un schéma tenant_X_sandbox distinct comme environnement de test. Les entrées du bac à sable de l'IA sont restreintes au niveau de la couche outil à des jeux de données synthétiques que l'IA génère elle-même — les données de production réelles capturées dans un instantané ne sont jamais mises à disposition de l'IA par ce chemin, même lorsque l'exploitant pourrait les charger pour une investigation forensique. Cette séparation est imposée dans le code (l'outil de restauration sandbox de l'IA refuse tout instantané dont l'objectif déclaré n'est pas sur la liste blanche des fixtures synthétiques).

La restauration vers le schéma live du locataire (ramener un locataire de production à un état capturé après un changement défavorable) est sur la feuille de route de formalisation ; jusqu'à son arrivée, la récupération live contre un identifiant d'instantané est opérateur-médiée via le support. La lignée d'instantanés elle-même — la mesure substantielle de l'article 32(1)(c) — est en place. C'est la réponse de la plateforme à l'obligation de l'article 32, paragraphe 1, point c) du RGPD — « la capacité de rétablir la disponibilité des données à caractère personnel et l'accès à celles-ci dans des délais appropriés en cas d'incident physique ou technique » — appliquée non seulement au plan de reprise après sinistre mais aussi à la classe d'incidents plus restreinte que représentent les opérations destructives de l'IA elle-même. La récupération est une primitive intégrée au design, pas un runbook a posteriori.

3.8 Gestion du changement — vérification pré-déploiement

Aucun changement de code n'atteint la production sans passer une chaîne de vérification à quatre étapes qui s'exécute comme barrière dure sur le pipeline de déploiement : tests unitaires de l'API, specs de comportement bout en bout de l'API (Webspicy), specs substrat au niveau plateforme qui vérifient la matérialisation de la RLS décrite au §3.2, et tests navigateur full-stack contre les routes authentifiées (Playwright). Chaque étape refuse de démarrer si l'étape précédente n'est pas passée, et l'étape la plus lente est verrouillée derrière la moins coûteuse, de sorte que les régressions sont attrapées au point le moins coûteux où elles sont visibles. Un changement qui affaiblirait l'une de ces garanties n'est pas livré.

4. Orchestrateur IA — protection des données à la conception

Le Studio AI de Bricks aide le responsable à concevoir des tables, à écrire de la logique de workflow, à générer du code d'application et à produire des images. L'orchestrateur est la partie de la plateforme qui dispose du plus large accès aux données durant un tour de conversation — par conception, il peut lire les schémas du locataire, modifier la source de son application et écrire des lignes dans les stockages backend. Les mesures ci-dessous décrivent comment ce pouvoir est limité.

4.1 Pas de contexte inter-locataire

Chaque conversation IA est limitée à un seul locataire. Les handles de base de données, racines de système de fichiers et surfaces d'outils de l'orchestrateur sont liés aux identifiants de ce locataire au début du tour et ne peuvent pas être échangés en cours de tour. Une requête provenant du chat du Studio du locataire A ne peut jamais, par inadvertance, modifier ou lire les données du locataire B, parce que le locataire B n'est tout simplement pas accessible depuis la session.

4.2 Flux de données vers tiers déclarés

Bricks traite chaque requête réseau externe que l'application d'un locataire amènerait le navigateur d'un visiteur à effectuer comme quelque chose que le responsable doit explicitement déclarer. Chaque flux déclaré nomme le fournisseur, la finalité, la base juridique au sens de l'article 6 du RGPD, les catégories de données personnelles transférées, la déclaration de durée de conservation, et est co-signé par un administrateur du locataire. La Content- Security-Policy de la plateforme pour l'application est générée à partir de ces déclarations — une URL de fournisseur non couverte par une déclaration signée est bloquée au niveau du navigateur. Le Studio AI est configuré pour refuser d'écrire du code qui charge une URL tierce non déclarée.

4.3 Pas de scripts, de polices ou de feuilles de style tiers dans les applications locataires

Les applications des locataires ne peuvent pas charger de JavaScript, de polices web ou de feuilles de style depuis des origines tierces. La CSP de la plateforme applique cela à l'exécution ; les outils d'édition d'application de l'IA reçoivent pour instruction de refuser ces ajouts. Les polices web proviennent d'un catalogue curé et hébergé par la plateforme, peuplé à la demande à partir de sources de polices du domaine public ; le navigateur du visiteur ne parle qu'à la plateforme.

4.4 Pas de tracking, pas de publicité, pas de profilage

La plateforme n'exécute pas d'analytique, de pixels de tracking, de publicité ou de profilage comportemental sur les applications des locataires, et l'IA est configurée pour ne pas en ajouter. Les catégories comme l'analytique, les captchas, les scripts de processeurs de paiement, les intégrations de réseaux sociaux et les CDN choisis par le locataire sont des « non » au niveau plateforme et ne peuvent pas être ajoutées par l'IA via le flux de travail régulier — il s'agit de demandes de fonctionnalité acheminées vers support@bricks-softwares.com. Les variantes d'URL « anonymes » / « sans cookie » fournies par les éditeurs sont traitées comme cosmétiques et ne contournent pas l'exigence de déclaration.

4.5 Fournisseur d'IA — ce qui quitte la plateforme, ce qui n'en sort pas

L'orchestrateur utilise l'API Claude d'Anthropic comme modèle de langage sous-jacent. Les conditions d'Anthropic pertinentes sont publiquement disponibles et le responsable peut les vérifier directement :

• Entraînement — les Conditions commerciales de service d'Anthropic s'engagent, par défaut, à ne pas entraîner les modèles génératifs d'Anthropic sur les entrées ou sorties de l'API client. Ce comportement par défaut s'applique à l'usage que Bricks fait de l'API ; la plateforme n'adhère à aucun programme qui modifierait ce comportement.
• Conservation — Anthropic conserve les entrées et sorties pendant une courte fenêtre à des fins de confiance, sécurité et détection d'abus ; les fenêtres de conservation publiées actuellement figurent sur le portail confidentialité d'Anthropic. Bricks n'active aucune fonctionnalité bêta de conservation étendue.
• Ce que Bricks configure dans l'appel API — la construction du client SDK est celle d'un client API commercial simple : clé d'API, URL de base optionnelle, délai de requête. Aucun metadata.user_id n'est attaché, aucun identifiant d'utilisateur final ne quitte la plateforme avec la requête, et aucun en-tête d'inscription à des fonctionnalités liées à l'entraînement n'est défini. Les interactions de la plateforme avec Anthropic se limitent à la même surface qu'utilise n'importe quel client de l'API commerciale.

Le périmètre de ce qu'Anthropic traite est intentionnellement étroit. Chaque tour envoie le contexte de la conversation (system prompt + messages récents de l'opérateur + résultats d'appels d'outils sur le schéma, le code source, les workflows et les rôles du locataire). Il s'agit du contenu rédigé par l'opérateur et d'informations d'ingénierie logicielle / de contexte métier que l'opérateur a choisies de partager avec l'IA pour obtenir de l'aide à la construction de son application.

Anthropic ne reçoit PAS de données personnelles des utilisateurs finaux des applications déployées du responsable. La plateforme est conçue structurellement pour que l'IA ne puisse pas lire l'état d'exécution de l'application déployée, les lignes de sa base de données, ni le contenu de ses utilisateurs finaux — voir §4.6 ci-dessous. En conséquence, les données personnelles des personnes concernées (les utilisateurs des applications du responsable) n'entrent jamais dans le pipeline de traitement d'Anthropic via une utilisation normale de la plateforme.

Le responsable est responsable de ne pas introduire manuellement les données personnelles des utilisateurs finaux dans le chat du Studio. Coller le nom, l'email, l'adresse ou toute autre information identifiante d'un utilisateur final dans un message du Studio contourne l'isolation de la plateforme par l'action propre du responsable ; ce contenu collé fait alors partie du contexte de conversation traité par Anthropic. L'instruction permanente de Bricks au responsable est la suivante : lorsque vous avez besoin que l'IA sache quelque chose à propos d'un enregistrement, faites-y référence de manière abstraite (« le membre avec l'ID X », « le rendez-vous pour la ligne que je m'apprête à corriger ») plutôt que de copier les données personnelles dans le chat. Le Studio AI lui-même est instruit de ne pas demander ces informations.

Anthropic est listé comme sous-traitant ultérieur au §7 ci-dessous pour les données à portée opérateur décrites ci-dessus.

4.6 Pas de scraping de page déployée

Le Studio AI est structurellement empêché de lire le HTML rendu d'une application locataire déployée ou son état visible par l'utilisateur final. C'était un choix de conception délibéré lors de la revue de la surface d'outils de l'IA : les outils qui « capturent une capture d'écran de l'application » ou « récupèrent le HTML déployé » exposeraient les données des utilisateurs finaux (contenu des personnes concernées) au pipeline de traitement par l'IA sans instruction spécifique du responsable. L'IA travaille à partir des fichiers source qu'elle édite et de ce que le responsable lui dit.

4.7 Auditabilité — déterminisme plutôt que génération

Le parti pris de Bricks comme plateforme consiste à rendre la plus grande part possible d'une application locataire déterministiquement dérivée d'artefacts structurés, plutôt que générée à chaque tour par un LLM. Les workflows, les schémas de base de données, les rôles, les permissions et les chemins de propriété — les artefacts qui déterminent ce que l'application fait effectivement à l'exécution — sont configurés par l'opérateur du locataire (souvent avec l'aide de l'IA), stockés sous forme de données structurées dans les moteurs propres de la plateforme, et lus directement par ces moteurs au moment de l'exécution. Ils ne sont pas régénérés à chaque tour par l'IA, ils ne dérivent pas, et ils ne peuvent pas déformer la représentation du système pour qui les inspecte : la structure est le système.

En conséquence, la logique côté serveur de chaque application Bricks est entièrement déterminée par ces contraintes. Le Studio AI configure les flux métier en éditant ces artefacts structurés ; l'orchestrateur valide chaque modification pour ses propriétés de cybersécurité (couverture RLS, chemins d'accès licites, déclarations de flux de données pour toute requête externe — voir §4.2), pour sa qualité (cohérence des workflows, complétude des rôles, validité du schéma), et pour la sécurité du contenu (en refusant les artefacts portant des instructions ou des sorties nuisibles qu'un LLM pourrait par ailleurs produire). Tout ce que fait une application locataire côté serveur est auditable par inspection directe de ces artefacts — aucun LLM n'intervient à l'exécution.

Le frontend d'une application locataire est, lui, du code généré par l'IA, et un ensemble de garanties différent s'y applique. Le boilerplate frontend de la plateforme impose les primitives substantielles de sécurité et de prédictibilité (CSP par application, authentification via BricksID, appels de données respectant la RLS via le SDK Bricks, fichiers de layout et de routage verrouillés) ; l'IA reçoit pour instruction de maintenir le code qu'elle génère cartographié à travers la couche sémantique de la plateforme (concepts, index de capacités, forme de l'arborescence de fichiers) afin que ce qu'elle écrit demeure lisible comme une application cohérente, plutôt que comme un assemblage opaque. La source générée complète de chaque application publiée est exportable et auditable telle quelle — le responsable peut lire chaque octet que recevra le navigateur du visiteur.

En complément de ces garanties architecturales, chaque appel d'outil de l'IA durant un tour d'un locataire est journalisé avec son nom, l'horodatage de l'appel et le résultat succès/échec ; l'historique de conversation (messages utilisateur, messages IA, pièces jointes) est stocké dans le schéma du locataire et visible par le responsable dans l'interface du Studio ; le responsable peut supprimer une conversation à tout moment.

Détection déterministe des boucles — le raisonnement de l'IA est lui-même un artefact inspectable. Lorsque le Studio AI s'attaque au même problème sur plusieurs tours, la plateforme enregistre ce qu'il a tenté de résoudre sous la forme d'un graphe de connaissance d'intentions par locataire : des liaisons structurées (quels tags se déclenchent, contre quel concept, combien de fois) en base de données, et un court récit en prose par application sous docs/intents/<slug>.md. Lorsque la même intention se déclenche trois fois contre la même liaison non résolue, la boucle est détectée déterministiquement — non comme un jugement probabiliste de type « le modèle a-t-il compris ? », mais comme un signal structurel exigeant escalade ou ramification. Le responsable peut lire à la fois les liaisons structurées et le récit en prose ; les décisions automatiques de la plateforme quant au moment d'escalader sont elles-mêmes auditables. Cela répond à l'exigence de supervision humaine de l'article 14 du règlement européen sur l'IA au niveau du substrat : la supervision s'exerce sur un artefact inspectable, et non sur une boîte noire probabiliste.

4.8 Imagerie générative et droit à l'image

Le Studio AI peut produire des images à la demande explicite du responsable via l'outil generate-image. Le service de génération d'images sous-jacent est Black Forest Labs (BFL, Allemagne). Le texte d'invite (prompt) saisi par le responsable est envoyé à BFL ; BFL renvoie une image générée que la plateforme stocke dans le préfixe d'actifs du locataire.

Périmètre de données personnelles de ce flux : BFL reçoit uniquement le texte de l'invite et renvoie une image. Les invites concernent des concepts visuels — en usage normal, elles ne contiennent pas de données personnelles d'utilisateurs finaux issues de l'application du responsable. BFL n'est donc pas listé comme sous-traitant ultérieur au §7 : il ne traite pas de données personnelles de personnes concernées (et le responsable est invité à ne pas mettre de données personnelles d'utilisateurs finaux dans les invites d'images, pour la même raison décrite au §4.5 à propos du chat du Studio en général).

Périmètre droit à l'image de ce flux : l'imagerie générative soulève une préoccupation juridique distincte de la protection des données. Les images générées peuvent dépeindre des personnes, groupes ou scènes qui ressemblent à des individus ou communautés réels identifiables, même lorsque l'invite ne nommait personne. Dans plusieurs juridictions où Bricks opère (notamment la France et la Belgique), le « droit à l'image » / les droits de la personnalité protègent les individus contre la publication non autorisée de leur ressemblance ; dans les cas où une image générée identifie clairement une personne réelle, le RGPD peut également s'appliquer à cette image en tant que donnée personnelle de l'individu identifié.

Responsabilité du responsable : il appartient au responsable de s'assurer que toute image qu'il publie via son application hébergée par Bricks respecte les droits à l'image et droits de la personnalité applicables des personnes qui pourraient y être dépeintes, intentionnellement ou incidemment. Conseils pratiques : ne pas demander à l'IA de générer des images « dans le style de [personne réelle nommée] » ou représentant des individus reconnaissables sans leur consentement ; revoir les images générées pour détecter toute ressemblance non voulue avec le personnel, les membres ou des personnalités publiques avant la publication.

Mesures de la plateforme : la plateforme refuse d'appeler BFL lorsque l'outil generate-image n'est pas activé ; les images générées sont stockées uniquement dans le préfixe du locataire demandeur ; le responsable peut supprimer tout actif généré à tout moment via l'historique de chat du Studio ou l'interface de gestion de fichiers.

5. BricksID — identité utilisateur final et transparence des données

BricksID est la couche d'identité de la plateforme pour les personnes concernées : les utilisateurs finaux des applications déployées du responsable. Un BricksID est un compte unique appartenant à une personne — pas à un locataire — qu'elle peut utiliser pour s'authentifier sur toute application hébergée par Bricks dont le responsable l'a invitée ou dont la surface est publique. Authentification, profil, notifications et vues de transparence des données vivent toutes sous /account/* pour l'utilisateur final.

5.1 Pourquoi cela existe

La plupart des plateformes multi-locataires soit (a) cloisonnent l'identité par locataire, obligeant l'utilisateur final à créer un compte par application visitée, soit (b) fédèrent vers un fournisseur d'identité d'entreprise unique, ce qui donne à ce fournisseur une carte complète des applications que l'utilisateur consulte. Aucune des deux options ne convient à la position que prend Bricks : les utilisateurs finaux doivent posséder leur identité, voir ce qu'il advient de leurs données, et exercer leurs droits sans passer d'abord par le service de support du locataire.

5.2 GoTrue — pourquoi nous nous appuyons sur une couche d'authentification existante

BricksID est construit sur GoTrue, le service d'identité open-source développé aux côtés de Supabase Auth. Bricks n'a pas développé sa propre pile d'authentification : choisir GoTrue signifie que la plateforme hérite d'implémentations bien auditées et largement déployées des parties de l'identité qui sont faciles à mettre dangereusement de travers si elles sont écrites de zéro. Concrètement :

• Les mots de passe sont stockés sous forme hachée via bcrypt avec un sel par mot de passe. Le mot de passe en clair n'est jamais stocké, jamais journalisé et jamais accessible au personnel de la plateforme après le moment de la soumission.
• La vérification de l'email à l'inscription est appliquée par défaut — un compte d'application Bricks ne peut pas fonctionner contre les données du responsable tant que l'utilisateur n'a pas prouvé qu'il contrôle l'adresse email avec laquelle il s'est inscrit.
• Réinitialisation de mot de passe en libre-service via des liens email à usage unique et limités dans le temps. L'utilisateur contrôle son cycle de vie d'identifiant sans avoir à demander à un admin du responsable de réinitialiser quoi que ce soit pour lui.
• Connexion par magic-link (sans mot de passe par email) est prise en charge, permettant aux utilisateurs d'éviter entièrement la réutilisation de mot de passe s'ils le préfèrent.
• Sessions basées sur JWT avec rotation de refresh-token : les access tokens sont à courte durée de vie (1 heure), les refresh tokens sont renouvelés à chaque utilisation, de sorte qu'un access token compromis a un faible rayon d'impact et un refresh token compromis devient détectable. L'API de la plateforme rejette tout jeton ne portant pas une revendication exp (expiration) valide — les jetons forgés ou rejoués sans expiration sont refusés à la frontière de l'API elle-même, et non après avoir déjà été utilisés. Les erreurs d'authentification sont remontées via une couche d'erreurs structurées et typées (un code d'erreur stable accompagné d'un message descriptif), de sorte qu'un client mal configuré ne peut pas dériver vers une acceptation silencieuse d'une session expirée ou mal formée.
• Suppression de compte en libre-service : l'utilisateur peut supprimer son BricksID depuis l'interface de compte sans passer par aucun locataire. La suppression cascade selon la procédure d'effacement RGPD décrite au §10 ci-dessous.
• L'intégration de fournisseurs OAuth pour l'authentification tierce, ainsi que la prise en charge de serveurs d'identité fédérée permettant à un utilisateur final de s'authentifier auprès de Bricks via son propre fournisseur d'identité, sont sur la feuille de route ; jusque-là, BricksID s'authentifie avec email + mot de passe ou magic-links.

5.3 Identité inter-locataire, données limitées au responsable

Un BricksID par personne, plusieurs applications. L'identité elle-même (email, mot de passe haché, métadonnées de compte) appartient à l'infrastructure de la plateforme Bricks ; les données que l'utilisateur crée ou qui sont créées en son nom dans l'application d'un locataire particulier appartiennent au schéma de ce locataire. Un utilisateur révoquant son BricksID ne supprime pas les enregistrements du locataire le concernant — c'est un flux d'effacement séparé par application, limité au responsable qui détient ces données (§10).

Perspective de plus long terme — protocole de mandat d'accès. RainbowTop Softwares étudie le développement d'un protocole de mandat d'accès permettant à l'utilisateur final de détenir et gérer pleinement ses propres données, et de les rendre accessibles aux applications uniquement par mandat explicite et révocable. Ce projet n'est pas développé à ce jour ; il reste ouvert à tout partenariat de recherche, à tout financement public ou privé, ou à toute opération d'investissement souhaitant en accélérer la concrétisation, et s'inscrit dans la trajectoire de souveraineté de la donnée que Bricks revendique.

5.4 Transparence utilisateur final sur /account — qui traite mes données

Les utilisateurs finaux ont une visibilité directe au niveau plateforme sur la façon dont leurs données personnelles sont traitées, sans avoir à déposer une demande d'accès. L'interface /account/* expose :

• Mes données — une vue structurée de chaque champ stocké sur le compte de l'utilisateur au niveau plateforme (profil, historique de connexion, sessions actives).
• Mes applications — chaque application hébergée par Bricks à laquelle l'utilisateur s'est authentifié, avec le nom du locataire (responsable) et l'email de contact pour chacune. Chaque ligne d'application est le point d'entrée des vues données-par-application et traitement-par- application ci-dessous.
• Mon traitement de données (par application) — la liste des workflows configurés par le responsable sur cette application, avec une description en langage simple de ce que chacun fait. C'est la surface pratique du §5.5 ci-dessous : la liste des workflows EST la vue qu'a l'utilisateur des activités de traitement du responsable, structurée et interrogeable plutôt qu'enfouie dans un PDF.
• Exporter et supprimer : un export de données par application et une demande d'effacement par application, tous deux acheminés directement vers l'instance du responsable.

5.5 Les workflows comme registre effectif des activités de traitement (article 30) au niveau de l'application

En vertu de l'article 30 du RGPD, les responsables doivent tenir un registre des activités de traitement — une liste structurée de quelles données personnelles ils traitent, pourquoi, sur quelle base juridique et qui les reçoit. Pour la plupart des responsables, c'est un document séparé maintenu par un DPO et rarement visible aux personnes concernées dont les données sont traitées.

Sur Bricks, les workflows du responsable dans son locataire constituent une cartographie structurée des traitements applicatifs et fournissent ainsi un point de départ substantiel à la tenue du registre prévu par l'article 30 du RGPD. Chaque workflow porte des métadonnées explicites : nom, description, condition de déclenchement (manuel, webhook, planifié, changement de table), tables qu'il lit, tables qu'il écrit, et systèmes externes qu'il appelle (lorsqu'ils sont couverts par une déclaration de flux de données signée — voir §4.2). Le responsable ne peut pas configurer un workflow qui traite des données personnelles sans que ce traitement apparaisse dans ces métadonnées. Cet audit applicatif réduit substantiellement la charge de conformité du responsable à l'égard de l'article 30 : la grande majorité des activités de traitement réellement exécutées par l'application est documentée par la simple action de la construire. Pour les utilisateurs finaux, le même socle de métadonnées pilote la vue de transparence sur /account (§5.4).

L'audit applicatif n'est cependant pas, à lui seul, un registre des activités de traitement au sens de l'article 30. Il documente exclusivement les traitements automatisés exécutés par la plateforme ; il ne couvre pas les traitements manuels ou hors application que le responsable peut conduire par ailleurs (suivi en bureautique, échanges par courrier électronique, traitements en cabinet, etc.), ni les traitements non routiniers qu'il pourrait organiser en marge de son application Bricks. Le responsable demeure seul juge de la complétude de son registre et doit, le cas échéant, compléter la cartographie issue de Bricks par les traitements opérés en dehors de la plateforme. Lorsque le responsable est tenu de publier ou de tenir un registre au titre de l'article 30(1) ou (2), la cartographie Bricks couvre déjà la plupart des traitements applicatifs effectifs et constitue donc une base concrète à laquelle ajouter ce qui se déroule en dehors de la plateforme.

Combiné avec les déclarations de flux de données du §4.2 (qui documentent les destinataires tiers de données par application), ce socle donne aux utilisateurs finaux une réponse unifiée à « qui traite mes données et comment » pour la part applicative : la liste de workflows du responsable pour ce qui se passe côté serveur, les déclarations de flux de données pour ce qui traverse vers des tiers, toutes deux interrogeables via la propre vue compte de l'utilisateur sans la permission de quiconque et sans délai.

6. Catégories de personnes concernées et de données personnelles

Le responsable décide exactement quelles données personnelles son application traite. Catégories typiques observées sur la plateforme :

• Opérateurs du locataire (le personnel du responsable) : nom, email, rôle, identifiants d'authentification (hachés), journaux d'utilisation de la plateforme.
• Utilisateurs finaux (les utilisateurs de l'application du responsable) : identifiants d'authentification (hachés), champs de profil définis par le schéma du responsable, contenu créé par l'utilisateur, préférences.
• Visiteurs anonymes : métadonnées de requête HTTP (IP, User-Agent) au niveau du proxy en bordure, conservées dans les journaux d'accès pour une fenêtre glissante de 30 jours à des fins de sécurité et d'enquête d'abus ; jamais associées à une identité authentifiée sauf si le visiteur se connecte.

Les données sensibles ou de catégorie particulière (santé, religion, opinion politique, etc.) ne sont pas traitées par Bricks lui-même ; si le schéma de l'application du responsable inclut ces données, le responsable est responsable des garanties supplémentaires qu'exige l'article 9.

7. Sous-traitants ultérieurs

Bricks utilise les sous-traitants ultérieurs suivants pour le traitement de données personnelles au nom du responsable. Les clients sont notifiés des changements à cette liste par email et sur cette page (incrément de version). La liste est intentionnellement courte et divulguée en totalité.

Black Forest Labs (Allemagne), le fournisseur de génération d'images invoqué par l'outil generate-image du Studio AI, n'est intentionnellement pas listé ici. La plateforme n'envoie pas de données personnelles de personnes concernées à BFL — uniquement les invites textuelles que le responsable a rédigées et les octets d'image résultants. Les considérations de droit à l'image pertinentes à ce flux sont documentées au §4.8 ci-dessus.

Les sous-traitants ultérieurs situés hors de l'UE/EEE traitent les données sous Clauses Contractuelles Types de l'UE le cas échéant, plus des garanties supplémentaires que nous avons documentées dans le contrat fournisseur correspondant.

8. Intégrité cryptographique des documents de la plateforme

Les Conditions Générales de Vente publiées par la plateforme sont cryptographiquement signées en utilisant Ed25519 au sein de la plateforme. La clé de signature, le format de payload signé (identifiant de commit, SHA-256 du contenu, émetteur, identifiant de clé, type, horodatage de publication, étiquette de version) et les colonnes de base de données qui enregistrent la signature de chaque commit sont décrits dans la documentation d'exploitation de la plateforme. La vérification est disponible directement via l'endpoint terms-verify de la plateforme à l'adresse /terms/verify.

Le présent Accord de traitement de données n'est pas encore intégré à cette infrastructure de signature. Son extension au présent document, ainsi qu'à la Déclaration de protection des données et aux éventuels autres documents publiés par RainbowTop Softwares qui portent un poids juridique ou de conformité, est planifiée et fait partie de la même trajectoire de vérifiabilité indépendante. À ce jour, le contenu du présent Accord est versionné par incrément manuel (étiquette de version dans l'en-tête) et notifié conformément au §17 ; il n'est pas signé cryptographiquement.

Vérification indépendante — publication en cours. La feuille de route de la plateforme inclut la publication des clés publiques de vérification, d'un vérificateur de référence hors ligne et de l'historique des commits signés dans un dépôt open-source séparé (OpenBricks) sous une licence permissive. Une fois cette publication en place, toute tierce partie — un client, un auditeur ou un tribunal — pourra vérifier une copie téléchargée des Conditions Générales par rapport à l'historique de clés publiées de la plateforme sans dépendre de la disponibilité de bricks-softwares.com ; l'extension de cette vérifiabilité au présent Accord interviendra dans le cadre du chantier global de signature des documents juridiques évoqué ci-dessus.

9. Notification de violation de données

En cas de violation de données personnelles affectant les données d'un responsable, Bricks notifiera le responsable sans retard injustifié et, lorsque cela est faisable, dans les soixante-douze (72) heures suivant la prise de connaissance de la violation. La notification décrira la nature de la violation, les catégories et le nombre approximatif de personnes concernées, les conséquences probables, et les mesures prises ou proposées pour y remédier. L'adresse email de notification par locataire est l'email de l'org admin enregistré ; les responsables peuvent configurer un contact de sécurité dédié via les paramètres de la plateforme.

10. Droits des personnes concernées — ce que nous fournissons, ce que le responsable construit

Le responsable est responsable, au titre des articles 12 à 22 du RGPD, de répondre aux demandes d'accès, de rectification, d'effacement, de limitation, de portabilité et d'opposition des personnes concernées. Bricks soutient cette responsabilité par un ensemble délibérément étroit de capacités au niveau plateforme et est explicite sur ce que le responsable doit construire lui-même.

10.1 Ce que la plateforme fournit directement

• Effacement en libre-service par l'utilisateur final de son compte BricksID — sur /account/* comme décrit au §5. Cascade en un effacement par application qui supprime les lignes de la personne concernée de chaque schéma de locataire, tout en préservant le journal transactionnel auditable de l'effacement lui-même.
• Export de données par locataire — le responsable peut exporter tout le contenu de son schéma, son préfixe de stockage d'objets et la source de ses applications publiées depuis le Studio à tout moment, dans des formats portables standard. Voir §12.
• Registre des activités de traitement (article 30) par application — généré à partir des déclarations de flux de données du §4.2 et téléchargeable au format CSV par le responsable.
• Vue de transparence pour l'utilisateur final — l'interface utilisateur /account/* permet aux personnes concernées de voir quels workflows traitent leurs données via la surface de transparence du §5.5.
• Assistance raisonnable via support@bricks-softwares.com sur les questions au niveau plateforme à propos de ce qui précède.

10.2 Ce que le responsable doit construire ou opérer lui-même

Plusieurs obligations des articles 12 à 22 nécessitent une connaissance du contexte de traitement spécifique du responsable que la plateforme ne peut pas avoir. Bricks est explicite sur le fait de ne pas remplir celles-ci au nom du responsable :

• Identification des personnes concernées. La plateforme ne maintient pas de logique de mappage déterminant à quelle personne concernée appartient quelle ligne dans un schéma de locataire au-delà de ce que le schéma du responsable encode lui-même. Le responsable conçoit la relation entre son identité d'authentification et ses données spécifiques au métier. Si une demande d'effacement ou d'accès nécessite de consulter des enregistrements à travers plusieurs tables qui ne partagent pas d'identifiant évident, le responsable construit cette consultation dans le Studio (un workflow, une vue de base de données, un écran d'application) — pas Bricks.
• Discrimination des finalités. La plateforme ne suit pas pour quelle finalité une donnée personnelle particulière a été collectée ; cela fait partie de l'obligation de registre du traitement du responsable et est encodé dans la conception de schéma, les workflows et les déclarations de flux de données du responsable. Bricks ne détermine pas au nom du responsable si une demande donnée peut être refusée au titre de l'article 17(3)(b) (obligation légale), 17(3)(c) (intérêt public), 17(3)(d) (archivage) ou d'une autre exception de l'article 17.
• Contact proactif avec les personnes concernées. Bricks ne contacte pas les utilisateurs finaux du responsable en son nom — ni pour les notifier d'une suppression, ni pour les informer d'un changement de droits, ni pour confirmer un effacement. Le responsable détient la relation avec l'utilisateur final et opère ce canal lui-même.
• Construction des mécanismes d'accès / rectification / portabilité dans l'application elle-même. Là où un utilisateur final attend une vue en libre-service de « mes données dans cette application » ou « télécharger mes données depuis cette application », le responsable construit cette surface dans le Studio — typiquement un workflow + une page dans l'application. Le Studio AI peut aider à concevoir ces surfaces mais ne connaît pas les besoins spécifiques en données personnelles de chaque population d'utilisateurs finaux ; la décision de conception revient au responsable.

Cette frontière est l'allocation responsable / sous-traitant du RGPD appliquée strictement : le responsable décide qui sont les personnes concernées, ce dont elles ont besoin et comment les servir ; le sous-traitant fournit les mécanismes de la plateforme (stockage, schéma, moteur de workflow, surface d'édition du Studio) et les quelques fonctionnalités utilisateur final transversales qui relèvent réellement du niveau plateforme (compte BricksID, export brut, registre de l'article 30).

11. Conservation et suppression

Bricks n'exécute pas d'application automatisée de politique de conservation aujourd'hui. Le modèle de conservation de la plateforme a deux états : résiliation explicite par le responsable, et droit réservé de la plateforme de supprimer après une inactivité prolongée. Les politiques de conservation automatisées (conservation limitée dans le temps par catégorie de données, calendriers par locataire, etc.) sont un élément de la feuille de route ; jusqu'à leur livraison, les règles ci-dessous sont celles que la plateforme exploite réellement.

11.1 Résiliation par le responsable (demande explicite)

• Le responsable peut exporter toutes les données de son schéma de locataire, tous les fichiers de son préfixe de stockage d'objets et la source complète de ses applications publiées, dans des formats portables standard (dump SQL, fichiers à leurs chemins de stockage originaux, source d'application sous forme d'archive tar). Voir §12.
• Le responsable peut demander la suppression. Bricks supprime les stockages primaires du locataire dans les trente (30) jours suivant la demande. Les sauvegardes froides expirent selon leur propre calendrier glissant (actuellement quatre-vingt-dix jours) et ne sont pas purgées sélectivement ; les responsables ayant besoin d'un délai plus strict doivent demander l'avenant par client décrit au §17.

11.2 Conservation basée sur l'inactivité (à l'initiative de la plateforme)

Bricks se réserve le droit de supprimer les données d'un locataire après une période d'inactivité prolongée pour limiter l'exposition de la plateforme à des données pour lesquelles elle n'a plus de finalité documentée. Aujourd'hui, cela fonctionne comme suit :

• 3 mois d'inactivité — définis comme aucune connexion, aucun build d'application, aucune exécution de workflow, aucune activité de chat du Studio par aucun utilisateur du locataire — déclenchent une notification à tous les administrateurs du locataire enregistrés. La notification offre une option d'export et demande au responsable soit de se connecter (ce qui réinitialise le compteur d'inactivité), soit de demander explicitement la conservation au-delà de la fenêtre standard.
• Absence de réponse après la notification conduit à la suppression complète des stockages primaires du locataire selon le calendrier documenté au §11.1. La piste d'audit de la suppression elle-même est conservée.

Devoir du responsable durant la suppression basée sur l'inactivité. Le responsable est le responsable du traitement pour les données de ses utilisateurs finaux. Il incombe au responsable de s'assurer que ses personnes concernées ont eu l'occasion d'obtenir toute donnée personnelle sur laquelle elles détiennent des droits (articles 15, 20) avant que la suppression ne soit exécutée. Bricks ne contacte pas les utilisateurs finaux du responsable en son nom, n'identifie pas quel utilisateur final appartient à quels enregistrements (voir §10.2) et ne retarde pas la suppression pour donner aux utilisateurs finaux un préavis individuel. Le responsable décide s'il faut communiquer la suppression imminente à ses utilisateurs finaux, et le cas échéant comment.

12. Exports de données et portabilité

Un export de données du locataire est disponible depuis le Studio à tout moment et contient :

• le schéma PostgreSQL du responsable sous forme de dump SQL portable ;
• le stockage de fichiers du préfixe S3 du responsable (actifs téléversés, images générées par l'IA, artefacts de build d'application) sous forme d'arborescence de répertoires ;
• la source de chaque application publiée sous forme d'archive tar de fichiers ;
• les métadonnées de configuration qui pilotent la vue de la plateforme sur le locataire (workflows, rôles, permissions, déclarations de flux de données) sous forme de JSON structuré.

Ensemble, ces éléments permettent au responsable de récupérer ses données et de réinstancier l'opération de traitement ailleurs — le droit de portabilité de l'article 20 du RGPD au niveau responsable. Les métadonnées de workflow structurées sont les mêmes métadonnées qui pilotent le §5.5 ; un locataire exporté reste interrogeable pour « quels workflows ont traité quelles données » sans dépendre de la poursuite de l'exploitation de Bricks.

Une fois les données sorties de la plateforme via un export, tout ce qui en est fait relève de la seule responsabilité du responsable. Bricks n'a aucune visibilité ni aucun contrôle sur la façon dont les données exportées sont stockées, sur qui peut y accéder, sur quels traitements supplémentaires sont appliqués ou sur où elles sont transmises. Les obligations du responsable en tant que responsable du traitement au titre du RGPD continuent de s'appliquer à la copie exportée de la même manière qu'à l'original sur la plateforme ; l'export est un transfert de données vers un système choisi par le responsable, pas un transfert de responsabilité.

13. Interopérabilité et sous-traitants ultérieurs activés par choix via les intégrations

Au-delà des sous-traitants ultérieurs nommés du §7, la plateforme offre une surface d'intégration qui permet à un responsable de connecter son application ou ses workflows à des services tiers supplémentaires. Les exemples incluent l'envoi d'email via un fournisseur SMTP externe, l'appel d'une API CRM depuis un workflow, l'extraction de données depuis un service de calendrier ou l'activation d'une capacité spécifique du Studio AI qui utilise un fournisseur que nous avons vérifié séparément.

Chaque intégration que le responsable active introduit généralement un nouveau sous-traitant ultérieur pour les données qui y transitent. Activer une intégration est donc une décision du responsable avec des conséquences en matière de protection des données :

• Bricks effectue une sélection. Nous ne listons pas une intégration tant que nous n'avons pas de réponse défendable aux questions qu'une revue de protection des données poserait à notre sujet — juridiction du fournisseur, comportement de conservation, catégories de données traitées, posture de sécurité, adéquation de la base juridique pour le cas d'usage typique. La liste sélectionnée reflète notre jugement sur ce qu'il est raisonnable de mettre à disposition ; elle ne se substitue pas à l'analyse propre du responsable.
• La responsabilité du responsable au titre du RGPD est de conduire cette analyse pour la finalité spécifique qu'il entend faire servir à l'intégration. Une analyse d'impact relative à la protection des données (AIPD) peut être requise au titre de l'article 35 selon le cas d'usage et les catégories de personnes concernées affectées. C'est l'obligation du responsable, pas celle de Bricks. Choisir une intégration sans cette analyse revient à opérer sans évaluation de base juridique au titre de l'article 6 — le même type d'écart de conformité que les déclarations de flux de données du §4.2 sont conçues pour faire ressortir.
• Le Studio AI peut conseiller sur les bonnes pratiques — proposer un fournisseur moins intrusif, indiquer où une déclaration est requise, suggérer une alternative auto-hébergée lorsqu'il en existe une — mais l'IA ne connaît pas les besoins spécifiques en protection des données des utilisateurs finaux du responsable, le contexte réglementaire du responsable ou son appétit pour le risque. Le conseil de l'IA est informatif ; l'analyse du responsable est déterminante.
• Lorsque le responsable active une intégration qui introduit un nouveau sous-traitant ultérieur, ce sous-traitant ultérieur est enregistré comme une déclaration de flux de données (§4.2). La liste complète des flux déclarés par application est interrogeable par le responsable et exportée dans le registre de l'article 30 décrit au §10.1.

14. Compatibilité avec d'autres cadres de protection des données

La plateforme est conçue autour du modèle responsable / sous-traitant du RGPD et de l'interprétation qu'en fait l'Autorité belge de protection des données. Plusieurs autres cadres de protection des données partagent suffisamment de structure avec le RGPD pour que les mesures techniques et organisationnelles décrites dans ce document constituent également un point de départ crédible pour la conformité — bien que l'évaluation finale relève toujours du responsable pour son cas d'usage spécifique.

Les cadres que nous connaissons aujourd'hui suffisamment pour revendiquer une compatibilité de base :

• nLPD suisse (FADP révisée) (Loi fédérale sur la protection des données, révisée le 1er septembre 2023). L'hébergement de la plateforme chez Infomaniak en Suisse rend le droit suisse applicable à la couche au repos quoi qu'il en soit ; l'allocation responsable / sous-traitant, la taxonomie de base juridique, le délai de notification de violation et la surface de droits des personnes concernées du §10 correspondent étroitement aux exigences de la nLPD.
• LGPD brésilienne (Lei Geral de Proteção de Dados, loi 13.709/2018). L'allocation des « agentes de tratamento », les droits du « titular dos dados » et les attentes de l'ANPD sur les registres de traitement et les équivalents d'AIPD peuvent être traités avec les mêmes mécanismes de plateforme — workflows comme registre du traitement (§5.5), déclarations de flux de données (§4.2), export équivalent à l'article 30 (§10.1).
• PIPA sud-coréenne (Personal Information Protection Act, dernière révision majeure 2023). Les exigences de notification, de consentement par finalité et de transfert transfrontalier de la PIPA s'alignent sur la granularité de consentement et de base juridique que nous exposons dans les déclarations de flux de données.
• APPI japonaise (Act on the Protection of Personal Information, dernière révision majeure 2022). Les obligations de l'« exploitant d'entreprise traitant des informations personnelles » et les règles de divulgation des transferts transfrontaliers de l'APPI peuvent être servies avec les mêmes déclarations par application et le registre équivalent à l'article 30.

Compatibilité de base n'est pas certification. Aucun des éléments ci-dessus n'est une certification, un audit ou une reconnaissance formelle. Ce sont des déclarations honnêtes selon lesquelles l'architecture de la plateforme a une forme suffisamment proche du RGPD pour qu'un responsable soumis à l'un de ces cadres soit peu susceptible de rencontrer des obstacles au niveau plateforme à sa conformité, et puisse utiliser les mêmes mesures techniques (RLS, déclarations de flux de données par application, workflows-comme-registre, transparence /account) pour démontrer sa propre posture sous son propre cadre. Les adaptations sectorielles (dossiers de santé, services financiers, exigences de marchés publics) et les juridictions hors de cette liste sont traitées comme avenants par client payants — voir §17 pour le mécanisme d'avenant et §13 pour le modèle de responsabilité intégration par intégration.

15. Droit d'audit et demandes de renseignements sécurité

RainbowTop Softwares répond aux demandes raisonnables relatives à la posture de sécurité, de conformité et de protection des données de la plateforme Bricks, en complément des informations déjà publiées dans le présent Accord, dans la Déclaration de protection des données, et dans les mesures techniques et organisationnelles mentionnées ci-dessus.

Nous nous engageons à répondre, dans un délai raisonnable et à un niveau de détail raisonnable, aux demandes relevant de l'une des deux catégories suivantes :

• Clients existants — un responsable de traitement disposant d'un abonnement ou d'un engagement de conseil actif, dont la demande est proportionnée au périmètre réel d'utilisation de la plateforme, et acheminée par le contact commercial désigné chez RainbowTop Softwares. Le responsable peut exercer ce droit au plus une fois par période de douze mois.
• Pouvoirs publics dans le cadre d'une procédure de marché public — toute autorité publique, pouvoir adjudicateur ou acheteur institutionnel qui, dès sa première prise de contact, identifie le marché public, l'accord-cadre ou la procédure de mise en concurrence pour lequel les informations d'audit sont demandées, accompagné du numéro de référence, de l'entité adjudicatrice, et de la date limite de la procédure.

En dehors de ces deux cas, RainbowTop Softwares se réserve le droit de ne pas répondre, notamment lorsque le demandeur n'est pas client de la plateforme et n'a pas déclaré de contexte de marché public dans les conditions ci-dessus, lorsqu'il existe un doute raisonnable quant au fait que la demande émane, ou est mandatée par, un client réellement opérationnel de la plateforme, ou lorsque l'ampleur ou le volume de la demande est manifestement disproportionné par rapport à l'empreinte réelle du demandeur sur la plateforme et n'a pas été remontée par un contact commercial chez RainbowTop Softwares.

RainbowTop Softwares ne s'engage pas, par la présente clause, à compléter un questionnaire, cadre ou modèle sectoriel spécifique. Lorsqu'un client ou un pouvoir public éligible soumet un tel modèle, RainbowTop Softwares apprécie de bonne foi s'il peut être traité de manière proportionnée à partir de la documentation existante de la plateforme, et se réserve le droit de renvoyer le demandeur vers cette documentation lorsqu'elle traite déjà la substance de la demande.

Pour les demandes éligibles, RainbowTop Softwares répond soit par écrit avec documentation à l'appui, soit en planifiant une présentation à distance par vidéo avec le responsable technique de la plateforme. Les visites physiques aux centres de données du fournisseur d'hébergement sont coordonnées via le processus d'audit client standard de ce fournisseur.

La présente clause est sans préjudice des obligations d'information imposées à RainbowTop Softwares par la loi applicable, en particulier le RGPD, le Code de droit économique belge, ou toute décision exécutoire d'une autorité de contrôle ou d'une juridiction compétente.

16. Responsabilité et limites

La responsabilité entre les parties est régie par les Conditions Générales de Service commerciales. Le présent Accord de traitement de données n'étend ni ne réduit ces limites.

17. Modifications et avenants par client

Les clients dont le cadre ou le secteur exige des modifications à ce qui précède peuvent écrire à support@bricks-softwares.com en indiquant les exigences spécifiques qu'ils ont besoin de voir traitées. Nous négocions les avenants sans frais.

Les changements substantiels à ce document sont versionnés (étiquette de version dans l'en-tête) et notifiés par email à l'org admin de chaque locataire actif.

18. Contact

RainbowTop Softwares SRL — opérateur de la plateforme Bricks.
Demandes relatives à la vie privée et à la protection des données : support@bricks-softwares.com.

Ce document est publié en français et en anglais, les deux versions faisant également foi. Bricks opère en Belgique sous la supervision de l'Autorité belge de protection des données (Autorité de protection des données — Gegevensbeschermingsautoriteit), et la juridiction de Bricks est en Belgique francophone ; les deux versions linguistiques sont maintenues synchronisées à mesure que les changements substantiels sont publiés. Aucune autre traduction n'a de valeur juridique. Les traductions dans d'autres langues, et les adaptations de ce document au vocabulaire ou aux exigences sectorielles d'autres juridictions, sont disponibles sous forme d'avenants par client payants — voir §17.