Architecture des données et sécurité

Le principe fondateur

Vos données ne sont pas hébergées dans l’IA. Elles résident dans une base de données dédiée, isolée par client, sur des serveurs situés dans l’Union européenne. Les modèles d’IA sont appelés ponctuellement, via API, au moment précis de l’exécution d’une tâche, avec le strict nécessaire.

Le circuit complet tient en trois blocs. Vos systèmes (e-commerce, ERP, POS, PMS, outils marketing) : vos contrats, vos identifiants, BOUCLR lit ce qui est nécessaire sur votre instruction. La plateforme BOUCLR (Union européenne) : base de données PostgreSQL sur infrastructure Hetzner, isolation stricte par client, secrets chiffrés AES-256-GCM ; c’est ici, et uniquement ici, que vos données sont stockées. Les modèles d’IA : appel au moment de l’exécution, extrait minimal et pseudonymisé quand la tâche le permet, réponse renvoyée à la plateforme, pas d’entraînement sur vos données ; le modèle ne conserve pas de base de vos données, il traite une requête, puis c’est terminé.

1. Où sont stockées les données

• Base de données unique par plateforme, cloisonnée par client. Chaque enregistrement est rattaché à un identifiant client. Toutes les requêtes applicatives sont filtrées sur cet identifiant : un utilisateur d’une entreprise ne peut techniquement accéder qu’aux données de son entreprise.
• Hébergement en Union européenne. La plateforme tourne sur une infrastructure Hetzner (opérateur européen, centres de données en Allemagne et en Finlande), derrière un proxy sécurisé. L’application n’est jamais exposée directement sur Internet.
• Base PostgreSQL en production, avec sauvegardes régulières et volumes persistants localisés sur la même infrastructure européenne.
• Suppression structurelle. Le modèle de données est construit en cascade : la suppression d’un client entraîne mécaniquement la suppression de l’intégralité des données qui lui sont rattachées.

2. Comment l’IA intervient, précisément

Des appels ponctuels, sans état. Quand un agent BOUCLR exécute une tâche (analyser des indicateurs, préparer une recommandation, rédiger un brouillon de campagne), la plateforme construit une requête, l’envoie au modèle via API, reçoit la réponse et la stocke chez elle. Le modèle ne dispose d’aucun accès permanent à la base de données : il ne voit que le contenu de la requête, au moment de la requête.

Minimisation et pseudonymisation. La plateforme applique le principe de minimisation : seuls les éléments nécessaires à la tâche sont transmis. Exemple concret, l’agent de prévention de l’attrition : le profil transmis au modèle est une synthèse pseudonymisée (récence, fréquence, montant, magasin de rattachement, canaux joignables) accompagnée d’une référence opaque. Ni le nom, ni l’email, ni le téléphone du client final ne figurent dans la requête. La correspondance entre la référence et l’identité reste dans la base BOUCLR, en Union européenne.

Pas d’entraînement sur vos données. Les fournisseurs de modèles retenus (dont Anthropic pour les modèles Claude) s’engagent contractuellement, dans le cadre de leur offre API commerciale, à ne pas utiliser les données soumises pour entraîner leurs modèles. Vos données ne nourrissent aucun modèle public et ne peuvent pas « ressortir » ailleurs.

Une clé dédiée par client. Chaque client peut disposer de sa propre clé API auprès du fournisseur de modèles. Cette clé est chiffrée (AES-256-GCM) dans la plateforme et utilisée exclusivement pour les traitements de ce client : rattachement contractuel direct, cloisonnement des appels, lisibilité des coûts.

Traçabilité complète. Chaque exécution d’agent est journalisée dans la plateforme : quel agent, quand, sur quel périmètre, avec quel résultat. Cette traçabilité permet un audit complet et alimente la transparence vis-à-vis du client. Ces journaux sont soumis aux mêmes règles d’isolation et de suppression que le reste des données.

3. Ce que voient (et ne voient pas) les tiers

• L’hébergeur (Hetzner, UE) voit l’infrastructure serveur. Il n’a pas d’accès applicatif aux données ; les secrets sont chiffrés.
• Le fournisseur de modèles IA voit le contenu de chaque requête, au moment de la requête (minimisé, pseudonymisé quand la tâche le permet). Il n’a pas d’accès à la base, pas de copie durable, pas d’entraînement sur ces données.
• Les autres clients BOUCLR ne voient rien. Isolation par identifiant client sur toutes les tables et toutes les requêtes.
• L’équipe IKKI’S DIGITAL OÜ dispose d’un accès d’exploitation et de support, nominatif et journalisé. Aucun usage en dehors du service ; les secrets clients sont illisibles sans la clé maîtresse d’environnement.

4. L’humain reste dans la boucle

La sécurité des données n’est pas qu’une affaire de chiffrement : c’est aussi une affaire de contrôle. BOUCLR fonctionne selon quatre modes d’exécution, choisis par le client, du mode manuel (BOUCLR propose, votre équipe exécute) au mode automatique (BOUCLR exécute, votre équipe supervise). Dans tous les cas, les seuils et règles métier sont définis par des humains, l’agent propose et l’humain valide au niveau choisi. Aucune action sortante vers vos clients finaux n’échappe au cadre que vous avez fixé.

5. Synthèse des mesures de sécurité

• Chiffrement des secrets : AES-256-GCM (chiffrement authentifié) pour toutes les clés API et identifiants de connexion des clients ; clé maîtresse par environnement, hors du code source ; stockage en clair techniquement impossible.
• Chiffrement en transit : TLS de bout en bout, certificats automatiques, proxy sécurisé en amont, application jamais exposée directement.
• Isolation : cloisonnement logique par client sur l’ensemble du modèle de données, contrôles d’accès applicatifs systématiques.
• Accès : RBAC à trois niveaux, habilitations nominatives par entreprise, interdiction d’auto-escalade des droits.
• Authentification : SSO OAuth (Google, Microsoft) avec portées minimales et sans conservation de jetons ; mots de passe hachés le cas échéant ; sessions signées, httpOnly, durée limitée.
• Exploitation : conteneurisation, environnements séparés (préproduction / production), sauvegardes régulières, rotation des journaux, revue de sécurité avant mise en production.
• Fin de contrat : restitution des données dans un format structuré sur demande, puis suppression complète en cascade.

6. Résilience, sauvegardes et continuité

La protection des données, c’est aussi la garantie de ne pas les perdre et de pouvoir reprendre vite en cas d’incident (panne, attaque, erreur). Le dispositif repose sur plusieurs couches indépendantes.

• Sauvegardes chiffrées hors-site : la base est sauvegardée régulièrement vers un stockage objet situé dans un autre lieu que les serveurs applicatifs (Union européenne). Ces sauvegardes sont indépendantes de l’infrastructure de production.
• Restauration testée : la procédure de restauration complète est vérifiée, pour que la remise en service ne soit pas une hypothèse mais une capacité prouvée.
• Copie indépendante : une copie des sauvegardes est conservée sur un second serveur, dans un autre centre de données, hors d’atteinte d’une compromission du serveur principal.
• Réplication temps réel : une copie vivante de la base est maintenue en continu sur un second serveur (autre centre de données), prête à prendre le relais. Les fichiers déposés dans la plateforme sont également répliqués à intervalle court.
• Bascule éprouvée : le dispositif de reprise n’est pas théorique, il est mesuré et éprouvé par des exercices réels de bascule vers le serveur de secours, menés en conditions de production.
• Protection réseau : le trafic public passe par un service de protection réseau (filtrage, atténuation des attaques par déni de service).
• Détection et réaction : l’état des serveurs est surveillé en continu ; une alerte est déclenchée en cas d’incident, et une procédure de reprise documentée permet d’agir sans délai.
• Violation de données : en cas d’incident touchant des données personnelles, les clients concernés sont notifiés sans délai injustifié, dans le respect du délai de 72 heures prévu par le RGPD.

7. Questions fréquentes

• Mes données servent-elles à entraîner une IA ? Non. Les fournisseurs de modèles utilisés via API s’engagent à ne pas entraîner leurs modèles sur les données soumises. Vos données restent vos données.
• Mes données sont-elles stockées chez le fournisseur d’IA ? Non. Le stockage est assuré par la plateforme BOUCLR, en Union européenne. Le modèle reçoit une requête ponctuelle et renvoie une réponse ; il ne constitue aucune base de vos données.
• Un autre client de BOUCLR peut-il voir mes données ? Non. Chaque donnée est rattachée à votre identifiant client et chaque requête applicative est filtrée sur cet identifiant. Le cloisonnement est structurel, pas déclaratif.
• Où sont physiquement les serveurs ? Dans l’Union européenne, sur l’infrastructure Hetzner (Allemagne / Finlande), derrière un proxy de protection réseau.
• Qui détient les accès à mes systèmes (e-commerce, marketing, ERP, POS) ? Vous. BOUCLR utilise les identifiants que vous fournissez, les stocke chiffrés en AES-256-GCM, et s’en sert exclusivement pour les services souscrits. Vous pouvez les révoquer à tout moment depuis vos propres outils.
• Que se passe-t-il si nous arrêtons ? Vos données vous sont restituées dans un format structuré sur demande, puis supprimées intégralement de la plateforme, sauvegardes comprises à leur cycle normal de purge.
• Une action peut-elle partir vers mes clients sans validation ? Seulement si vous avez choisi le mode automatique pour ce type d’action, dans le cadre et les seuils que vous avez définis. Par défaut, l’agent propose et votre équipe valide.