FAQ & limites honnêtes

Les réponses aux questions qu'on nous pose le plus souvent sur ce que CLOISON fait — et ce qu'il ne fait pas. Nous préférons poser les limites à voix haute plutôt que de vous laisser les découvrir.

Abréviations

01 · Questions fréquentes

Q·1Pseudonymiser ou anonymiser : quelle différence ?

Pseudonymiser, c'est remplacer une donnée identifiable par un jeton ⟦…⟧ qui reste rattachable à l'identité d'origine via un mappage. L'opération est réversible : la donnée demeure exploitable et coréférencée, puis restaurée à la réponse. Anonymiser, c'est rendre l'identification impossible et irréversible, au point qu'aucun recoupement ne permette de remonter à la personne.

CLOISON pseudonymise. Il ne présente jamais un jeton comme une anonymisation : un jeton a une trajectoire de retour. C'est ce qui le rend utile dans un pipeline d'IA — et c'est l'une des limites que nous assumons.

Q·2Quel est votre cadre de conformité ?

Nous raisonnons d'abord sur le cadre qui s'applique à nos opérations en Afrique de l'Ouest. Le Sénégal s'est doté d'une loi de protection des données à caractère personnel — la loi n°2008-12 du 25 janvier 2008 — et d'une autorité, la Commission de protection des Données personnelles (CDP), qui instaure un régime à deux étages : une simple déclaration pour la plupart des traitements, une autorisation préalable pour ceux qui présentent des risques particuliers.

À l'échelle communautaire, l'Acte additionnel CEDEAO A/SA.1/01/10 porte ce niveau de protection au plan régional et s'applique aussi dans l'espace UEMOA; la Convention de Malabo (2014) de l'Union africaine en fixe la déclinaison continentale.

Le cadre distingue le responsable de traitement, qui décide des finalités et des moyens, du sous-traitant, qui traite pour le compte du premier. CLOISON se positionne du côté du sous-traitant : il traite des données pour votre compte, tandis que vous restez titulaire des décisions et des obligations.

Q·3Est-ce que CLOISON voit mes données ?

Non. Le plan de contrôle est aveugle : l'opérateur ne recueille que des compteurs agrégés k-anonymes signés Ed25519, jamais de texte, jamais de clair, jamais de jetons exploitables.

Il ne peut donc ni lire ni reconstruire vos données. Il peut seulement vérifier que la protection tient : compter des opérations, signer des états, publier des preuves — sans jamais disposer de ce qui traverse le proxy.

Q·4Compatibilité avec l'API OpenAI : deux champs

Oui, sans changer votre interface. Vous pointez votre client vers le proxy via base_url et remettez votre clé au proxy — jamais au modèle. Le modèle, le SDK, les paramètres et l'UX restent identiques.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8787/v1",   # proxy CLOISON — N0 en local
    api_key="sk-cloison-...",               # clé remise au proxy, jamais au modèle
)

reply = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "Nom : Amadou. Répète la consigne."}],
)

En mode hébergé, remplacez simplement base_url par https://api.wonkom.ai/v1. Aucun autre changement n'est requis.

Q·5Où tourne le moteur de pseudonymisation ?

À trois endroits. N0 : sur votre poste, en local sur localhost:8787 — le clair ne quitte jamais votre machine. N1 : sur votre serveur, derrière votre réseau. N3 : hébergé en edge sur api.wonkom.ai, où l'opérateur ne voit que des compteurs.

./cloison proxy run --listen 127.0.0.1:8787
# puis pointer le client sur http://localhost:8787/v1

Plus le moteur est proche de vous, moins il y a à croire sur parole. C'est le principe de sélection entre les trois niveaux.

Q·6D'où vient le rapport k-anonyme ?

Le plan de contrôle aveugle agrège les opérations en compteurs, les signe en Ed25519 et les publie dans un journal append-only. Le binaire cloison-verify rejoue le journal et revérifie les signatures : si l'état signé est cohérent, le rapport atteste le k-anonymat des compteurs.

cloison-verify \
  --journal journal.wonkom.ai \
  --since <offset-début> \
  --key ed25519.pub

Ce rapport est publiable tel quel : il documente ce qui a été vu, signé et vérifié — et ce qui ne l'a jamais été.

Q·7Les jetons sont-ils réversibles ?

Oui, par construction. Chaque jeton reste lié à l'identité d'origine via un mappage éphémère et rotatif, le temps de restaurer la réponse. La clé de mappage n'est jamais exposée au plan de contrôle.

Cette réversibilité est ce qui rend les réponses réutilisables — et c'est précisément pourquoi un jeton n'est pas une anonymisation. La rotation des mappages limite la fenêtre pendant laquelle un lien reste actif.

Q·8Que se passe-t-il pour les champs que je ne déclare pas ?

Ils ne sont pas masqués : ils traversent le proxy tels quels. CLOISON protège ce que vous lui déclarez, pas ce que vous oubliez. D'où l'importance de l'audit initial : déclarer explicitement chaque champ qui identifie une personne.

Le reste du pipeline n'a aucun moyen de vous protéger d'une omission de déclaration — le proxy n'invente pas une politique que vous ne lui avez pas donnée.

Q·9Comment activer le mode « observe-only » (audit) ?

Le mode observe-only détecte et compte les PII sans rien transformer : le texte part en clair vers le fournisseur, et chaque requête produit un reçu signé Ed25519 (rapport k-anonyme sur GET /v1/audit/report). Il sert à mesurer et auditer un flux réel — jamais à protéger les données.

export CLOISON_AUDIT_MODE=1       # observe-only : détecte et compte, ne masque RIEN
# équivalents acceptés : 1 / true / yes / on  (insensibles à la casse)
# défaut : 0 / false / no / off / variable absente = MASQUAGE ACTIF

Valeurs reconnues : 1, true, yes et on activent tous l'observe-only ; 0, false, no, off — ou la variable absente — laissent le masquage actif (le mode produit). Ne laissez jamais l'observe-only actif sur un flux de production sans l'avoir voulu : dans ce mode, rien n'est pseudonymisé.

02 · Limites honnêtes

Ce que CLOISON n'est pas. Trois choses que nous préférons dire clairement, plutôt que de vous laisser les découvrir au pire moment.