Un proxy entre votre interface et le modèle : rien d'autre ne change.

Un proxy léger, en amont de vos appels.

Le proxy se glisse entre votre interface IA et le fournisseur. Toute requête le traverse avant de sortir de votre réseau — et rien, jamais, ne part en clair.

CLOISON est un composant unique, sans infrastructure à provisionner. Il parle le protocole OpenAI : votre interface existante n'a besoin que de deux champs pour s'y brancher. Aucun code à réécrire, aucun SDK à changer — seul l'endpoint et la clé diffèrent.

Base URL : http://localhost:8787/v1        # N0 : le moteur chez vous
Clé      : mn_<jeton_local>.<clé_amont>   # jeton local + clé amont

En N0, le clair ne quitte jamais votre poste.

Deux propriétés, et ce ne sont pas des clauses contractuelles — ce sont des faits auditables.

En N0, le moteur tourne chez vous, sur localhost:8787. La requête part déjà pseudonymisée ; le clair, lui, ne traverse jamais le réseau. Et le cloud, quel qu'il soit, n'est jamais le lieu où se joue votre confidentialité.

• Le clair ne quitte jamais votre poste. Le coffre — la table jeton ↔ valeur — vit dans un vault chiffré AES-256-GCM sur votre machine.
• Le cloud n'est qu'un plan de contrôle aveugle. L'opérateur ne recueille que des compteurs k-anonymes signés, jamais de texte (invariant I9).
• Le modèle ne reçoit que des sentinelles ⟦…⟧. Jamais une donnée personnelle en clair — ni à l'aller, ni au retour.

Pseudonymisation → jetons → modèle → restauration.

À l'aller, chaque champ qui identifie une personne devient un jeton. Au retour, les jetons redeviennent les vraies valeurs — et la coréférence est conservée.

1. Votre interface envoie la requête via la Base URL et la clé composite. Rien ne change de votre côté.
2. Pseudonymisation : chaque PII est remplacée par un jeton ⟦…⟧ avant que la requête ne quitte votre réseau.
3. Le modèle ne reçoit que des jetons — jamais la donnée personnelle en clair.
4. Restauration : à la réponse, les jetons redeviennent les vraies valeurs, et la coréférence est conservée.

curl -s http://localhost:8787/v1/chat/completions \
  -H "Authorization: Bearer mn_<jeton>.<clé_amont>" \
  -H "Content-Type: application/json" \
  -d '{"model":"x","messages":[{"role":"user","content":
       "Contact: Aminata Diop, user@example.com, tel +221 77 123 45 67"}]}'
# → la réponse contient « Aminata Diop, user@example.com, +221 77 123 45 67 »
#   (restaurés) et aucune sentinelle ⟦…⟧ résiduelle.

Ce que l'opérateur peut lire, à chaque niveau.

Le cloisonnement n'est pas une métaphore. Le moteur peut s'exécuter à quatre endroits — et chacun change ce que l'opérateur peut, ou ne peut pas, lire.

Plus le moteur est proche de vous, moins il y a à croire sur parole. Le niveau délimite précisément le périmètre de la promesse : il n'est pas un argument marketing, c'est une borne.

« Faites-moi confiance » n'est pas une méthode.

Trois artefacts vérifiables permettent de contrôler, jour après jour, que la protection tient. Et le cadre d'abord : CLOISON se déploie d'abord dans un droit qui n'est pas le RGPD.

Cadre souverain — an 1 : Sénégal & UEMOA

Qualifications directionnelles — à confirmer avec un juriste sénégalais. Notre cadre de référence est celui où CLOISON se déploie d'abord ; nous ne faisons pas l'inverse.

Code ouvert

La passerelle et tous les composants vérifiables sont publiés. Vous auditez, compilez et rejouez le journal vous-même : rien à croire sur parole — la protection est inspectable.

git clone https://github.com/coucagog/cloison-proxy
cargo build --release
./cloison-proxy --version

Journal de transparence

Chaque fenêtre d'audit est publiée en append-only. Le binaire cloison-verify rejoue le journal et vérifie les signatures — dans votre navigateur, sans qu'aucune donnée ne quitte la page.

./cloison-verify --journal https://journal.wonkom.ai --window <id>

Rapport k-anonyme signé

Un rapport signé par tenant atteste ce qui a été vu — et ce qui ne l'a jamais été. Présentable tel quel à votre autorité de protection des données (CDP au Sénégal, DPO en Europe) ou à un auditeur.