Documentation CLOISON

01 · La promesse

Vos données personnelles n'atteignent jamais le modèle en clair — et nous ne les voyons pas. Ce n'est pas une politique de confidentialité, c'est une propriété d'architecture : la protection ne dépend pas de la confiance qu'on nous accorde.

Avant qu'une requête ne parte, chaque champ qui identifie une personne est remplacé par un jeton ⟦…⟧. Le modèle ne reçoit donc jamais une donnée personnelle en clair. À la réponse, les jetons sont réintégrés à leurs vraies valeurs, coréférence conservée : ce que vous obtenez reste exploitable, jamais identifiable.

Trois garanties rendent la promesse vérifiable plutôt que déclarative :

Plan de contrôle aveugle

L'opérateur — celui qui exploite l'infrastructure — ne reçoit que des compteurs k-anonymes signés, jamais de texte. Un compteur agrégé sur au moins k individus ne peut ni être lu, ni être inversé, ni reconstituer le clair. Le plan de contrôle ne dispose pas des données qu'il supervise.

Code ouvert

Moteur, proxy et vérificateur sont publiés sur github.com/coucagog/cloison-*. Vous auditez, compilez et déployez vous-même la protection. Rien n'est à croire sur parole — on ne vous demande pas de faire confiance, on vous donne les moyens de vérifier.

Journal de transparence

Chaque opération est publiée dans un journal append-only sur journal.wonkom.ai. N'importe qui peut rejouer le journal avec le binaire cloison-verify (WASM) et vérifier que ce qui a été déclaré correspond à ce qui a réellement transité.

02 · Le produit

Un proxy compatible OpenAI qui pseudonymise puis restaure. Votre interface reste inchangée — vous modifiez deux champs de configuration.

Le proxy s'intercale entre votre application et le modèle. Il se comporte comme un endpoint /v1 standard : vous gardez votre client OpenAI, vos appels, vos modèles. La différence tient à deux champs :

• Où pointer — remplacez l'URL de base par celle du proxy (localhost:8787 ou api.wonkom.ai).
• Quoi masquer — la liste des champs à pseudonymiser (email, phone, name…).

[proxy]
base_url = "http://localhost:8787/v1"   # champ 1 — où pointer

[fields]
pseudonymise = ["email", "phone", "name"]   # champ 2 — quoi masquer

Côté application, rien ne change :

import OpenAI from 'openai'

const client = new OpenAI({
  baseURL: 'http://localhost:8787/v1',  // le proxy, pas le modèle
  apiKey: process.env.OPENAI_API_KEY,
})

const res = await client.chat.completions.create({
  model: 'gpt-4o',
  messages: [{ role: 'user', content: 'Résume le dossier de {name}' }],
})

Le client envoie ses champs, le proxy masque ceux de la liste, et la réponse est restaurée avant de revenir à votre interface. Le modèle ne voit que des jetons ⟦…⟧.

03 · Les trois niveaux

Le clair reste là où le client décide. Trois niveaux de déploiement, du plus autonome au plus managé : N0 local, N1 site, N3 hébergé.

Le moteur de pseudonymisation peut s'exécuter à trois endroits. Plus il est proche de vous, moins il y a de surface à confier à un tiers — et moins le clair quitte votre réseau.

N0 · Local

Le proxy tourne sur votre poste et écoute sur localhost:8787. Le clair ne quitte jamais votre machine ; seul le jet ⟦…⟧ atteint le modèle. Zéro transfert de clair, aucun service à exposer.

N1 · Site

Le moteur s'exécute sur votre serveur, derrière votre réseau. Vous gardez la maîtrise des clés, des flux et de la politique de pseudonymisation — utile quand plusieurs applications partagent la même infrastructure.

N3 · Hébergé

Le proxy est hébergé en edge sur api.wonkom.ai. L'opérateur ne recueille que des compteurs agrégés signés — jamais vos données en clair. C'est le chemin pour pointer une interface sans rien déployer.

04 · La preuve

Trois artefacts permettent de contrôler la protection, jour après jour, sans croire sur parole.

• Code ouvert — github.com/coucagog/cloison-* : moteur, proxy et vérificateur, audités et compilés par vous.
• Journal de transparence — journal.wonkom.ai : un append-only que cloison-verify rejoue et signe.
• Rapport de conformité — un rapport signé attestant le k-anonymat des compteurs, publiable tel quel.

Vérifiez vous-même avec cloison-verify :

# cloner le vérificateur
git clone https://github.com/coucagog/cloison-verify
cd cloison-verify

# rejouer le journal et vérifier les signatures Ed25519
wasmtime run --dir=. cloison-verify.wasm \
  --journal https://journal.wonkom.ai \
  --check k-anonymity --min-k 20

Si la commande quitte sans erreur, le journal est cohérent et les compteurs respectent le k-anonymat déclaré. C'est tout l'intérêt : la preuve ne passe pas par nous.

05 · Commencer

Deux chemins, un même objectif : que vos données n'atteignent plus jamais le modèle en clair. Choisissez selon que vous voulez tout garder chez vous ou pointer une interface existante.

Pour le chemin 01 :

# installer le binaire N0
curl -fsSL https://docs.wonkom.ai/install.sh | sh

# démarrer le proxy sur votre poste
cloison run --listen 127.0.0.1:8787
# → proxy prêt : http://localhost:8787/v1

Pour le chemin 02, reportez-vous à la section Le produit : les deux champs de configuration suffisent, et le guide complet se trouve sur docs.wonkom.ai.

Cadre & conformité

Le référentiel de protection de CLOISON part du cadre africain — celui qui s'applique à notre terrain et à nos clients — et ne considère le RGPD que comme un prolongement complémentaire, aligné a posteriori.

CLOISON traite des données à caractère personnel pour le compte de ses clients. La question de savoir quelle règle s'applique n'est donc pas décorative : elle détermine le régime déclaratoire, les bases et les obligations. Nous structurons notre conformité autour de quatre textes, du plus structurant au plus complémentaire.

Le socle africain

• Loi n° 2008-12 (Sénégal) — la loi sur la protection des données à caractère personnel, notre cadre de référence immédiat. Elle organise la collecte, le traitement et les droits des personnes, et confie le contrôle à la Commission de protection des Données Personnelles (CDP).
• Acte additionnel CEDEAO A/SA.1/01/10 — le texte communautaire de la CEDEAO sur la protection des données, applicable aussi dans l'espace UEMOA. Il harmonise les régimes nationaux et fixe les principes que chaque loi locale transpose.
• Convention de Malabo 2014 — la convention de l'Union africaine sur la cybersécurité et la protection des données à caractère personnel. Elle encadre la coopération entre autorités et la circulation transfrontière des données au sein du continent.

Le régime deux étages de la CDP

La CDP ne traite pas tous les traitements de la même façon. Le régime dépend de la sensibilité des données et de la finalité :

• Déclaration — pour les traitements ordinaires, une simple déclaration préalable suffit. Elle renseigne l'autorité sur l'existence, la finalité et les mesures du traitement.
• Autorisation préalable — pour les traitements sensibles ou à risque (données de santé, biométrie, données sur les convictions, croisements à grande échelle), une autorisation de la CDP doit être obtenue avant le traitement.

Parce que CLOISON manipule intrinsèquement des champs potentiellement sensibles, la question de savoir quel étage s'applique est un point de conception, pas une formalité : nous documentons le régime pour chaque niveau de déploiement.

Responsable de traitement ≠ sous-traitant

La distinction est structurante et elle n'est pas qu'un vocabulaire :

• Responsable de traitement — votre organisation détermine la finalité et les moyens du traitement des données personnelles. C'est elle qui décide quoi pseudonymiser, et elle reste titulaire des droits et des obligations envers les personnes.
• Sous-traitant — CLOISON traite les données pour le compte du responsable, sur instruction documentée. Le plan de contrôle aveugle limite ce que nous voyons à des compteurs agrégés signés, ce qui réduit le périmètre du traitement sous-traité à des métadonnées non réidentifiables.

Le contrat de traitement, les instructions, les mesures de sécurité et l'audit sont donc définis sur cette base — et le rapport de conformité prouve que le sous-traitant n'a jamais reçu de clair.

Le RGPD, en complément

Le RGPD européen est un prolongement pour les clients ou les marchés qui y sont exposés — un rattrapage réglementaire qui s'aligne sur notre socle, et non le cadre premier. Les principes qui se recoupent (minimisation, proportionnalité, droits des personnes, sécurité) sont satisfaits par la même architecture : pseudonymisation systématique, traitement documenté, journal vérifiable.

Concrètement : notre conformité s'établit d'abord vis-à-vis de la loi 2008-12 et de l'Acte additionnel CEDEAO, puis se décline pour les exigences RGPD lorsque le cas l'exige — sans jamais inverser cette priorité.