À propos de cet accord
En bref Le contrat que l’article 28 du RGPD impose entre un organisme et le service qui traite des données personnelles pour son compte — publié à l’avance, pour pouvoir être examiné avant l’inscription.
Un tel accord est habituellement rédigé par chaque client et envoyé à son prestataire. Nous publions le nôtre à la place, versionné, pour qu’un client et son délégué à la protection des données puissent vérifier ce qui est réellement en place avant de s’inscrire, et demander des modifications en écrivant à simon@bricks-softwares.com. Les clauses disent ce à quoi chaque partie s’engage ; les annexes décrivent le traitement, les mesures de sécurité, les sous-traitants ultérieurs et les outils que la plateforme met à disposition du responsable.
1.Parties et rôles
- Sous-traitant — RainbowTop Softwares SRL, exploitante de la plateforme Bricks (« Bricks »).
- Responsable du traitement — le client : l’organisme (le « locataire ») qui, par l’intermédiaire de ses opérateurs, configure la plateforme pour traiter les données à caractère personnel de ses propres utilisateurs finaux (membres, visiteurs, partenaires). Les opérateurs sont les personnes qui agissent sur la plateforme pour le compte de l’organisme. Le responsable décide quelles données personnelles sont collectées, sur quelle base légale et à quelle fin ; Bricks exécute ces instructions au moyen de la plateforme.
- Personnes concernées — les utilisateurs finaux du responsable dont les données personnelles sont traitées par ses applications sur Bricks.
- Là où Bricks n’est pas sous-traitant — Bricks est seul responsable du traitement des comptes BricksID et du compte propre de chaque opérateur. Pour les données relatives à l’organisme lui-même — ses opérateurs et leurs rôles, ses informations comptables et de facturation — Bricks et l’organisme sont responsables conjoints du traitement (article 26 du RGPD) ; les grandes lignes de cet accord sont publiées dans la déclaration de protection des données. Aucun de ces traitements ne relève du présent accord.
- Limites du rôle de sous-traitant — le présent accord couvre les traitements effectués au moyen de la plateforme telle qu’elle est officiellement prise en charge. Lorsqu’un problème de protection des données résulte d’une configuration d’application que la plateforme ne prend pas officiellement en charge, le responsable est seul responsable de ce traitement, et les engagements du présent accord ne s’y étendent pas.
2.Portée et primauté
En bref Cet accord fait partie du contrat formé lorsqu’un organisme accepte les conditions générales, et prévaut sur elles en matière de protection des données.
- Le présent accord et ses annexes font partie du contrat entre Bricks et le responsable conclu au titre des conditions générales, et lient les deux parties dès que le responsable les accepte.
- En matière de protection des données personnelles, le présent accord prévaut sur les conditions générales et sur tout autre accord entre les parties. Un avenant propre à un client (clause 14) prévaut sur le présent accord pour ce qu’il modifie expressément.
- L’annexe I décrit le traitement ; il dure aussi longtemps que l’abonnement du responsable.
3.Instructions
En bref Bricks ne traite les données du responsable que selon ses instructions, et le signale lorsqu’une instruction lui paraît illicite.
- Les instructions du responsable sont le présent accord, les conditions générales et ce que le responsable configure sur la plateforme : ses schémas, rôles et permissions, workflows, déclarations de flux de données, intégrations, et les demandes adressées au Studio AI. Bricks ne traite les données personnelles que sur ces instructions, y compris pour les transferts hors EEE (clause 7).
- Lorsque le droit de l’Union ou d’un État membre impose à Bricks de traiter les données autrement, Bricks en informe le responsable avant le traitement, sauf si ce droit l’interdit.
- Bricks informe immédiatement le responsable si, selon elle, une instruction constitue une violation du RGPD ou d’une autre disposition relative à la protection des données.
4.Confidentialité
En bref Seules les personnes qui en ont besoin y ont accès ; elles sont tenues à la confidentialité, et chaque accès direct aux données du responsable est enregistré avec son motif, que le responsable peut consulter.
Bricks n’accorde l’accès aux données personnelles du responsable qu’aux membres de son personnel qui en ont besoin pour fournir le service, chacun tenu par une obligation de confidentialité. Le personnel ne se connecte pas au compte d’un utilisateur.
Le personnel n’accède directement aux données d’un locataire que par deux outils, et chacun refuse de s’exécuter sans motif documenté. Chaque accès est enregistré avant de s’exécuter : qui, l’organisme concerné, le motif, le ticket, ce qui a été exécuté, s’il pouvait modifier des données, si un agent IA l’a exécuté, et s’il s’est exécuté avec les permissions d’un membre pour voir ce que ce membre voit. Les administrateurs du responsable consultent ces enregistrements dans le registre des traitements de l’organisme (annexe IV). Ils sont conservés douze mois.
La règle d’administration de la plateforme. L’administration de la plateforme — le droit d’agir dans n’importe quel organisme par les écrans propres de la plateforme — n’est détenue que par la direction technique de Bricks et son CEO, pour la direction de la plateforme. Aujourd’hui, cela désigne les fondateurs et personne d’autre. Son usage par ces écrans n’est pas enregistré dans le journal ci-dessus.
5.Sécurité
En bref Les mesures de l’annexe II sont en place, chacune avec sa méthode de vérification. Elles peuvent évoluer, jamais vers un niveau de protection inférieur.
Bricks met en œuvre les mesures techniques et organisationnelles décrites à l’annexe II afin de garantir un niveau de sécurité adapté au risque (article 32 du RGPD). Elle peut les faire évoluer avec la plateforme, à condition que le niveau global de protection ne diminue pas.
6.Sous-traitants ultérieurs
En bref Le responsable autorise les sous-traitants listés à l’annexe III, est prévenu 30 jours avant tout changement et peut s’y opposer.
- Le responsable donne à Bricks une autorisation générale de recourir aux sous-traitants ultérieurs listés à l’annexe III.
- Bricks informe par email les administrateurs du responsable, et met à jour l’annexe III, au moins 30 jours avant d’ajouter ou de remplacer un sous-traitant ultérieur. Pendant ce délai, le responsable peut s’y opposer pour des motifs raisonnables liés à la protection des données. Si les parties ne parviennent pas à lever l’objection, le responsable peut résilier le service concerné sans pénalité.
- Bricks impose contractuellement à chaque sous-traitant ultérieur des obligations de protection des données équivalentes à celles du présent accord, et demeure pleinement responsable envers le responsable de leur exécution (article 28.4 du RGPD).
- Une intégration que le responsable active lui-même (annexe III, dernier tableau) est mise en œuvre sur son instruction spécifique, et consignée comme déclaration de flux de données.
7.Transferts hors EEE
En bref Les données ne quittent l’EEE ou la Suisse que là où l’annexe III l’indique, et chaque transfert repose sur une garantie reconnue par le RGPD.
Bricks ne transfère de données personnelles vers un pays tiers que sur instruction du responsable et dans le respect du chapitre V du RGPD — une décision d’adéquation, ou les clauses contractuelles types de la Commission européenne conclues avec le sous-traitant ultérieur. Chaque transfert actuel et sa garantie figurent à l’annexe III. La Suisse bénéficie d’une décision d’adéquation.
8.Assistance au responsable
En bref Bricks fournit les outils de l’annexe IV et répond aux questions raisonnables ; c’est le responsable qui répond à ses personnes concernées.
- Demandes des personnes concernées. Compte tenu de la nature du traitement, Bricks aide le responsable à répondre aux demandes au titre des articles 12 à 22 au moyen des outils décrits à l’annexe IV, et lui transmet toute demande reçue directement qui concerne ses données.
- Sécurité, analyses d’impact, consultation préalable. Bricks fournit les informations dont le responsable a raisonnablement besoin pour remplir ses obligations au titre des articles 32 à 36 — y compris pour une analyse d’impact relative à la protection des données —, à commencer par le présent accord et ses annexes.
9.Violations de données
En bref Bricks prévient le responsable dans les meilleurs délais, et dans les 72 heures si possible, avec ce dont il a besoin pour notifier à son tour.
En cas de violation de données personnelles affectant les données du responsable, Bricks la lui notifie dans les meilleurs délais et, si possible, dans les 72 heures après en avoir pris connaissance. La notification décrit la nature de la violation, les catégories et le nombre approximatif de personnes et d’enregistrements concernés, les conséquences probables et les mesures prises ou envisagées ; les informations qui ne sont pas encore disponibles sont fournies dès qu’elles le sont. Les notifications sont adressées aux administrateurs de l’organisme enregistrés sur la plateforme.
Lorsqu’une violation résulte d’un acte ou d’une abstention d’un membre du personnel ou d’un dirigeant de Bricks sous une contrainte irrésistible au sens du droit pénal belge — notamment une menace physique imminente et sérieuse contre lui ou l’un de ses proches, quel que soit le lieu où elle s’exerce —, Bricks la traite comme une violation de données personnelles au sens des articles 33 et 34 du RGPD et la notifie comme décrit ci-dessus dès que la menace a cessé. Les conditions générales qualifient une telle contrainte de force majeure.
10.Ce dont répond le responsable
En bref Le responsable décide des finalités et répond à ses personnes concernées ; quelques pratiques gardent les données de ses utilisateurs là où elles doivent être.
- Une base légale, et les garanties qu’exige l’article 9 si son schéma contient des catégories particulières de données.
- Son registre des activités de traitement et, le cas échéant, ses analyses d’impact — la plateforme en prépare une large part (annexe IV).
- Ses propres utilisateurs finaux : identifier quelles données appartiennent à qui, décider si une exception à l’effacement s’applique, les contacter, et construire dans son application les vues en libre-service dont ils ont besoin.
- Ne pas coller de données personnelles de ses utilisateurs finaux dans le Studio AI, que ce soit dans le chat ou dans une demande d’image. Désigner un enregistrement de façon abstraite (« le membre d’ID X ») ; l’IA a pour consigne de ne pas en demander davantage.
- Droit à l’image. Vérifier que les images qu’il publie — y compris celles générées par l’IA — ne représentent pas une personne reconnaissable sans son consentement.
- Intégrations. Analyser, pour sa propre finalité, chaque intégration qu’il active ; la sélection que nous proposons ne remplace pas cette analyse.
- Ce qu’il fait des données une fois exportées : un export est un transfert vers un système qu’il choisit, pas un transfert de responsabilité.
11.Fin du traitement
En bref Le responsable peut tout exporter à tout moment ; après la résiliation, Bricks supprime le locataire dans les 30 jours.
- À tout moment, et à la résiliation, le responsable peut exporter toutes ses données dans des formats portables (annexe IV).
- À la résiliation, ou plus tôt à la demande du responsable, Bricks supprime le schéma de base de données, les fichiers et les applications publiées du locataire dans les 30 jours, sauf si le droit de l’Union ou d’un État membre en exige la conservation. La trace de la suppression elle-même est conservée.
- Les sauvegardes ne sont pas modifiées sélectivement ; elles expirent selon leur propre calendrier — 7 jours pour la base de données. Un responsable qui a besoin d’un délai plus strict peut demander un avenant (clause 14).
12.Information et audits
En bref Bricks met à disposition ce qui est nécessaire pour démontrer sa conformité, et permet des audits par le responsable ou son auditeur.
- Bricks met à la disposition du responsable les informations nécessaires pour démontrer le respect de l’article 28 du RGPD, au-delà de ce que le présent accord et la déclaration de protection des données publient déjà.
- Bricks permet la réalisation d’audits, y compris d’inspections, par le responsable ou un auditeur qu’il mandate et qui est tenu à la confidentialité, et y contribue — au plus une fois par période de douze mois sauf si une violation ou une autorité de contrôle le justifie, moyennant un préavis de 30 jours, aux frais du responsable. Bricks répond par écrit avec pièces justificatives, ou lors d’une présentation à distance avec son responsable technique ; les visites des centres de données de l’hébergeur passent par la procédure d’audit propre à celui-ci.
- Il en va de même pour un organisme public qui, dans sa première demande, identifie la procédure de marché concernée (référence, pouvoir adjudicateur, échéance).
- Bricks ne s’engage à remplir aucun questionnaire sectoriel particulier, et peut renvoyer à la documentation existante lorsqu’elle répond déjà à la question. Les demandes émanant de personnes qui ne sont ni clientes ni organisme public au sens ci-dessus peuvent rester sans réponse.
- La présente clause s’entend sans préjudice des obligations légales de Bricks, notamment envers une autorité de contrôle ou une juridiction.
13.Responsabilité
La responsabilité entre les parties est régie par les conditions générales. Le présent accord n’étend ni ne réduit ces limites, et n’affecte pas la responsabilité de chaque partie envers les personnes concernées au titre de l’article 82 du RGPD.
14.Modifications, avenants, langues
En bref Les modifications importantes sont versionnées et annoncées par email à l’avance ; les avenants sectoriels sont gratuits ; le français et l’anglais font également foi.
- Les modifications importantes sont versionnées (voir l’historique) et notifiées par email aux administrateurs de chaque locataire avant leur entrée en vigueur.
- Un responsable dont le secteur ou le cadre (santé, services financiers, marchés publics…) exige davantage peut demander un avenant propre à simon@bricks-softwares.com ; nous le négocions gratuitement.
- Le présent accord est publié en français et en anglais, les deux versions faisant également foi. Aucune autre traduction n’a de valeur juridique ; les traductions et adaptations au vocabulaire d’une autre juridiction sont disponibles sous forme d’avenants payants.
- Il est régi par le droit belge. Les juridictions de Belgique francophone sont compétentes, et l’Autorité de protection des données belge est l’autorité de contrôle chef de file.
I.Annexe I · Le traitement
En bref Ce que Bricks traite pour le compte du responsable.
| Objet | La mise à disposition d’une plateforme multi-locataires sur laquelle le responsable conçoit des schémas de données, des règles d’accès et des workflows côté serveur, publie des applications web, et se fait assister par une IA pour les construire. |
|---|---|
| Nature | Conservation, hébergement, consultation, structuration, transmission selon les workflows du responsable, sauvegarde, suppression ; et, lorsque le responsable le configure, l’envoi de données d’une étape de workflow à un modèle d’IA (un harnais, annexe II). |
| Finalité | Faire fonctionner les applications et workflows du responsable tels qu’il les configure. |
| Durée et fréquence | Continu, pendant la durée de l’abonnement, puis clause 11. |
| Personnes concernées | Les utilisateurs finaux du responsable (membres, visiteurs, partenaires) ; ses opérateurs dans la mesure où ses applications traitent des données les concernant ; les visiteurs anonymes de ses applications. |
| Données personnelles | Celles que définit le schéma du responsable — typiquement identité et coordonnées, champs de profil, contenus rédigés par l’utilisateur final, préférences. Pour les visiteurs anonymes, les métadonnées des requêtes HTTP (adresse IP, identification du navigateur) dans les journaux de la passerelle. |
| Catégories particulières | Aucune du fait de la plateforme elle-même. Si le schéma du responsable en contient, la clause 10 s’applique. |
II.Annexe II · Mesures de sécurité
En bref Ce qui protège les données du responsable, et comment chaque mesure est vérifiée.
| Mesure | Ce qu’elle fait | Comment elle est vérifiée |
|---|---|---|
| Isolation entre locataires | ||
| Un schéma de base de données par locataire | Les tables de chaque locataire vivent dans leur propre schéma PostgreSQL ; une session est restreinte au schéma du locataire demandeur, de sorte qu’une requête inter-locataires ne peut pas être formulée. | Par construction ; couvert par la suite de tests de l’API. |
| Sécurité au niveau des lignes | À l’intérieur d’un locataire, des politiques de base de données dérivées des rôles du responsable décident quelles lignes chaque utilisateur lit ou écrit. La base de données les applique : un serveur applicatif défaillant ne peut pas les contourner. | Un test de plateforme parcourt chaque locataire actif et bloque la mise en production si une politique attendue manque. |
| Une origine par application | Chaque application publiée a son propre sous-domaine (et d’éventuels domaines personnalisés vérifiés) : les navigateurs empêchent une application de lire les cookies et le stockage d’une autre. | Politique de même origine des navigateurs. |
| Un préfixe de stockage par locataire | Les fichiers sont stockés sous un préfixe propre au locataire ; la plateforme refuse de construire une clé hors de celui-ci, et les liens de téléchargement signés sont limités au locataire. | Par construction. |
| Des outils de plateforme sans porte dérobée | Les vues opérationnelles sur l’ensemble de la plateforme agrègent des métadonnées et n’ouvrent jamais de session capable de lire les lignes d’un locataire. | Construites sur la même sécurité au niveau des lignes. |
| Chiffrement | ||
| En transit | Tout le trafic en TLS 1.2 ou plus, avec des certificats renouvelés automatiquement ; aucun point d’écoute HTTP en clair exposé publiquement. | Gestion automatisée des certificats. |
| Au repos | Les disques des serveurs chez Infomaniak (Suisse) sont chiffrés ; la base de données managée et le stockage objet chez Scaleway (France) sont chiffrés par le prestataire. | Engagements des prestataires. |
| Identité et accès | ||
| BricksID | Construit sur GoTrue, un service d’identité open source largement déployé : mots de passe hachés avec bcrypt, adresse email vérifiée à l’inscription, réinitialisation du mot de passe en libre-service par lien à usage unique. | S’appuie sur une implémentation éprouvée plutôt que maison. |
| Connexion uniquement sur BricksID | Les applications connectent les personnes par l’écran propre de BricksID, sur l’origine de Bricks, selon OpenID Connect : l’application reçoit des jetons, jamais le mot de passe. L’écran nomme l’application qui demande la connexion et ne peut pas être restylé par un locataire ; le code de connexion est protégé par PKCE et renvoyé uniquement à une adresse enregistrée pour cette application. Le consentement est demandé une fois par application et peut être retiré. Les applications publiées avant ce mode de connexion peuvent conserver un formulaire de mot de passe par compatibilité ; il est en cours de retrait. | Par construction : le format d’application actuel n’a pas de connexion par mot de passe, et les adresses enregistrées de chaque application sont reprises à chaque publication. |
| Sessions | Les jetons d’accès expirent après une heure et les jetons de rafraîchissement sont renouvelés à chaque usage ; l’API refuse tout jeton sans date d’expiration valide. | Appliqué à l’entrée de l’API. |
| Accès du personnel | Le personnel ne se connecte pas aux comptes des utilisateurs. L’accès direct aux données d’un locataire passe par deux outils qui refusent de s’exécuter sans motif documenté et enregistrent chaque accès avant de l’exécuter (clause 4). Une session qui doit voir ce que voit un membre s’exécute avec les permissions de ce membre et est enregistrée comme telle. | Enregistrement en base de données : en ajout seul, conservé douze mois, consultable par les administrateurs du responsable dans le registre des traitements. Selon la règle d’administration de la plateforme (clause 4), seuls la direction technique et le CEO — aujourd’hui, les fondateurs — détiennent l’administration de la plateforme ; son usage par les écrans d’administration n’y figure pas. |
| Disponibilité et restauration | ||
| Sauvegardes de la base | Instantanés quotidiens de la base de données managée, conservés 7 jours. | Calendrier de sauvegarde du prestataire. |
| Sauvegarde avant les changements destructeurs | Les instantanés par locataire sont stockés dans le stockage de ce locataire. Dans le mode avancé du Studio AI, sur un locataire contenant des données réelles, un instantané est pris automatiquement avant un changement de schéma destructeur ; en mode standard, l’IA s’arrête et en recommande un. Pendant le changement, l’application affiche une page de maintenance. | Appliqué par les outils de schéma de l’IA. |
| Restauration | La restauration des données en production d’un locataire depuis un instantané est effectuée par le personnel de Bricks sur demande, limitée à ce locataire, et journalisée. | Procédure opérateur. |
| Gestion des changements | ||
| Chaîne de mise en production | Une mise en production passe, comme autant de barrières : tests unitaires, tests navigateur des pages authentifiées, tests d’intégration, test de sécurité au niveau des lignes sur chaque locataire, et tests de comportement de l’API. Le déploiement livre les fichiers de la version testée, pas une copie de travail. | Intégration continue. Un chemin d’urgence qui saute les tests existe pour les correctifs urgents et reste l’exception. |
| Applications et tiers | ||
| Flux de données déclarés | Toute requête externe qu’une application fait émettre au navigateur d’un visiteur doit être déclarée par le responsable — prestataire, finalité, base légale, catégories de données, conservation — et signée par un administrateur. La Content-Security-Policy de l’application est générée à partir de ces déclarations. | Le navigateur bloque ce qui n’est pas déclaré. |
| Aucun code tiers | Les applications ne peuvent pas charger de scripts, polices ou feuilles de style depuis des origines tierces ; les polices sont servies par la plateforme. Aucune mesure d’audience, pistage, publicité ou profilage n’est ajouté aux applications. | Content-Security-Policy ; le Studio AI refuse ces ajouts. |
| Le Studio AI | ||
| Un locataire par conversation | Les accès à la base, les racines de fichiers et les outils sont liés à un seul locataire au début d’un tour et ne peuvent pas changer pendant celui-ci. | Par construction. |
| Ce qui parvient au modèle de langage | Les messages de l’opérateur et les résultats des outils qui lisent la structure du locataire — schéma, code, workflows, rôles. Il ne lit pas les lignes de l’application. Deux exceptions : lire les dernières données reçues par un workflow, seulement après avoir averti l’opérateur et obtenu son accord ; et, en mode avancé, afficher une page publiée comme un visiteur anonyme, qui ne montre que du contenu public. Le modèle est celui d’Anthropic (États-Unis) ou, si le responsable le choisit, celui de Mistral chez Scaleway (France). | Restrictions au niveau des outils. L’accord demandé avant de lire les entrées d’un workflow est une instruction donnée à l’IA, pas encore imposée par le code. |
| Ni entraînement, ni identifiant | Les conditions commerciales d’Anthropic excluent par défaut l’entraînement sur les entrées et sorties de l’API ; Bricks n’active aucune rétention étendue et n’attache aucun identifiant d’utilisateur final aux requêtes. | Configuration du client. |
| Bac à sable sur données synthétiques | Lorsque l’IA teste un changement avant de l’appliquer, elle travaille dans un schéma bac à sable distinct, chargé uniquement de données synthétiques qu’elle génère ; son outil de restauration refuse tout instantané qui n’est pas un jeu synthétique. | Appliqué dans le code. |
| Une logique auditable | Le comportement côté serveur — workflows, schéma, rôles, permissions — est conservé sous forme de configuration structurée, lue directement par les moteurs de la plateforme. Un modèle de langage ne tourne dans une application que là où le responsable a ajouté un harnais (ci-dessous). Chaque appel d’outil de l’IA est journalisé, et la conversation est visible par le responsable, qui peut la supprimer. | Artefacts structurés ; exportables (annexe IV). Voir aussi transparence de l’IA. |
| L’IA dans les workflows du responsable | ||
| Déclarée avant de s’exécuter | Les applications n’ont pas d’IA propre. Le responsable peut ajouter à ses workflows un seul type d’appel à un modèle : un harnais, un artefact versionné qui déclare, avant de pouvoir s’exécuter, sa finalité, les catégories de données qu’il utilise, le fournisseur et sa juridiction, la durée de conservation chez le fournisseur, si une personne revoit le résultat, et s’il prend une décision automatisée. L’hôte que l’appel atteint et le compte qui paie le fournisseur sont lus dans sa configuration, pas déclarés. | Vérifié lors de l’application du harnais ; inscrit au registre des traitements du responsable et montré à ses membres (annexe IV). |
| Seulement vers un destinataire signé | Un appel est refusé si aucun administrateur n’a signé un flux de données couvrant l’hôte du fournisseur. Les garde-fous choisis par le responsable s’exécutent avant et après le modèle, et l’entrée est refusée au-delà de sa taille déclarée avant tout envoi. | La même barrière de sortie que pour tout appel côté serveur. |
| Enregistré ; le prompt reste privé | Chaque exécution est enregistrée chez le locataire du responsable : entrées et sorties, verdicts des garde-fous, modèle, consommation et coût. Les instructions que le responsable a écrites pour le modèle sont envoyées au fournisseur et conservées nulle part ailleurs. | Enregistrement d’exécution. |
| Le contrat de qui | Par défaut, un harnais utilise le propre compte du responsable chez le fournisseur, qui est alors un destinataire du responsable sous son propre contrat. Pour les modèles que Bricks référence, le responsable peut s’exécuter sur le compte de Bricks : Bricks est alors client du fournisseur, et le fournisseur sous-traitant ultérieur de Bricks (annexe III). | Indiqué pour chaque harnais dans le registre des traitements. |
III.Annexe III · Sous-traitants ultérieurs
En bref Qui traite les données du responsable pour le compte de Bricks, où, et sous quelle garantie. La liste est complète.
| Sous-traitant ultérieur | Service | Données | Lieu · garantie |
|---|---|---|---|
| Infomaniak Network SA | Serveurs hébergeant la plateforme ; DNS ; boîtes email de l’équipe | Les données du responsable résidant sur les serveurs ; l’email de l’équipe | Suisse · décision d’adéquation |
| Scaleway SAS | PostgreSQL managé et stockage objet ; email transactionnel pour les locataires qui utilisent l’expéditeur de la plateforme ; inférence Mistral lorsque le responsable choisit ce préréglage ; inférence pour les harnais que le responsable exécute sur le compte de Bricks | La base de données et les fichiers de la plateforme au repos ; destinataires et contenu des emails des locataires envoyés par ce biais ; pour Mistral, le même contexte que la ligne Studio AI de l’annexe II ; pour un harnais, ce que ce harnais envoie | France (fr-par) · UE |
| Anthropic | Modèle de langage du Studio AI | Comme décrit à l’annexe II, « Ce qui parvient au modèle de langage » | États-Unis · clauses contractuelles types de l’accord de traitement d’Anthropic |
| Brevo | Relais des emails de compte de la plateforme : confirmation d’inscription, réinitialisation du mot de passe, changement d’adresse, invitations, notifications de la plateforme. Pas l’email des applications des locataires. | Adresse du destinataire et contenu du message | France, infrastructure d’envoi aux États-Unis · clauses contractuelles types de l’accord de traitement de Brevo. En cours de remplacement par Scaleway ; voir les lacunes connues. |
Également utilisés, mais pas pour le compte du responsable
- Mollie (Pays-Bas) et Cabai (Belgique) — paiements et facturation pour la facturation par Bricks de l’organisme lui-même ; voir la déclaration de protection des données.
- Black Forest Labs (Allemagne) — génère des images à partir des demandes textuelles rédigées par un opérateur ; il ne reçoit aucune donnée personnelle d’utilisateurs finaux (clause 10 sur les demandes d’image).
Intégrations activées par le responsable
Connecter une application ou un workflow à un autre service — un fournisseur SMTP externe, un CRM, un agenda, un service de comptes rendus de réunion comme Leexi — fait de ce service un destinataire sur instruction du responsable (clause 6.4). Nous ne proposons une intégration qu’une fois capables de répondre aux questions qu’une analyse de protection des données lui poserait : juridiction, conservation, données traitées, sécurité, base légale habituelle. Chaque activation est consignée comme déclaration de flux de données et figure dans le registre du responsable (annexe IV).
IV.Annexe IV · Outils du responsable
En bref Ce que la plateforme met à disposition du responsable pour remplir ses propres obligations.
| Outil | Ce qu’il apporte | Où |
|---|---|---|
| Registre des activités de traitement (art. 30) | Un registre par organisme, composé à partir de ce que la plateforme sait : responsable et contact vie privée, colonnes de données personnelles de son schéma, destinataires et transferts issus de ses déclarations de flux, conservation, traitements automatisés effectués par ses workflows et appels d’IA qu’ils font, et chaque accès direct du personnel de Bricks avec son motif. Chaque section est marquée comme déduite, déclarée ou à compléter — les finalités et la sécurité, par exemple, sont à rédiger par le responsable. Il couvre les traitements sur la plateforme, pas ce que le responsable fait ailleurs. | Paramètres de l’organisme → Protection des données · PDF, et CSV par section |
| Demandes des personnes concernées | Les utilisateurs finaux déposent des demandes d’accès et d’effacement depuis leur compte ; elles parviennent à l’organisme, qui statue. Fermer un BricksID dépose une demande d’effacement auprès de chaque organisme dont la personne est membre. | Paramètres de l’organisme ; page Mes organismes de l’utilisateur final |
| Transparence envers les utilisateurs finaux | Chaque utilisateur final voit, par organisme, les workflows qui traitent ses données, les appels d’IA que ces workflows font (finalité, données, destinataire, conservation, revue humaine, décision automatisée), et la page de protection des données de l’organisme. | /account → Mes organismes |
| Déclarations de flux de données | La liste des destinataires tiers par application, avec leur base légale ; aussi téléchargeable en CSV par application. | Paramètres de l’application → Flux de données |
| Export | Le schéma de base de données en dump SQL, tous les fichiers, le code source de chaque application publiée, et la configuration (workflows, rôles, permissions, déclarations) en JSON — de quoi faire tourner le traitement ailleurs. | Paramètres de l’organisme → Export |
Autres cadres de protection des données
La plateforme est conçue autour du RGPD. Les responsables soumis à la nLPD suisse, à la LGPD brésilienne, à la PIPA coréenne ou à l’APPI japonaise peuvent s’appuyer sur les mêmes mesures — sécurité au niveau des lignes, flux de données déclarés, registre, vues de transparence pour les utilisateurs finaux — pour démontrer leur propre conformité. Il s’agit d’un constat sur l’architecture, pas d’une certification ; l’évaluation pour un usage donné reste celle du responsable.
Historique des versions
- 2.2 · 19 octobre 2026 — Clause 4 et annexe II : comment l’accès direct du personnel est enregistré, avec son motif, et où le responsable le consulte ; la règle d’administration de la plateforme : détenue uniquement par la direction technique et le CEO, aujourd’hui les fondateurs. Annexes I et II : les appels d’IA que le responsable ajoute à ses workflows (harnais) — ce qui est déclaré, comment ils sont encadrés, quel contrat s’applique. Annexe III : Scaleway sert aussi les harnais exécutés sur le compte de Bricks. Annexe IV : le registre des traitements liste les deux.
- 2.1 · 17 octobre 2026 — Grepleaks retiré des sous-traitants ultérieurs : c’est une intégration que le responsable active, pas une partie de la plateforme, qui relève des « intégrations activées par le responsable » de l’annexe III. Ajouté à l’annexe II : la connexion uniquement sur BricksID.
- 2.0 · 29 septembre 2026 — Restructuré en clauses et annexes sur le modèle des clauses contractuelles types de la Commission (2021/915). Ajouté : effet contraignant et primauté, instructions documentées, confidentialité, préavis de 30 jours et droit d’opposition pour les sous-traitants ultérieurs, transferts, assistance aux analyses d’impact, inspections. Aligné sur les conditions générales v3 : rôles (clause 1), violations sous contrainte (clause 9). Corrigé : ce qui parvient au modèle de langage, la fermeture de compte, le registre de l’article 30, la conservation des sauvegardes, un sous-traitant ultérieur manquant (Grepleaks). Retiré : la suppression automatique après inactivité et un paramètre de contact sécurité dédié, qui n’existent ni l’un ni l’autre.
- 1.0 — Première version publiée.
Pas encore signé cryptographiquement. Nos conditions générales le sont ; cet accord suivra.