« Nous ne lisons pas » — vérifiez le code.
Le cœur de CLOISON est open-core : le moteur, la passerelle, le journal et le vérificateur sont publiés sous github.com/coucagog/cloison-*. Vous les décomposez, vous les compilez, vous les comparez. La vérification n'est pas une promesse — c'est une procédure.
01Composition
La suite est découpée en dépôts indépendants, chacun versionné et auditable seul. Le cœur est le moteur ; tout le reste s'articule autour de lui — la passerelle à la frontière réseau, et les briques de confiance qui rendent la protection contrôlable.
| Dépôt | Rôle | Licence |
|---|---|---|
| cloison-moteur | Moteur de pseudonymisation : remplace chaque champ identifiable par un jeton ⟦…⟧. | Permissive |
| cloison-gateway | Passerelle à la frontière : réécrit la requête en amont, restaure la réponse. | AGPL-3.0 |
| cloison-journal | Journal de transparence append-only, signé Ed25519. | Permissive |
| cloison-verify | Vérificateur WASM : rejoue le journal, contrôle les signatures. | Permissive |
| cloison-audit | Audit du k-anonymat des compteurs agrégés. | Permissive |
| cloison-controle | Contrôle de cohérence du plan de contrôle (schémas, décomptes, bornes). | Permissive |
| cloison-cli | Interface en ligne de commande : build, vérification, audit. | Permissive |
| cloison-wasm | Cible portable du moteur, exécutable hors ligne, sans clé ni infra. | Permissive |
| cloison-ner | Reconnaissance d'entités nommées (personnes, courriels, adresses, numéros). | Permissive |
| cloison-bench | Harnais de benchmark : mesure la couverture et la fuite résiduelle. | Permissive |
Chaque dépôt embarque ses propres tests ; le harnais de benchmark rejoue des flux réels pour chiffrer la couverture de la pseudonymisation et la fuite résiduelle. Vous n'êtes pas obligé de nous croire sur la couverture — vous pouvez la reproduire.
02Licences
Le choix de licence n'est pas anodin : il détermine ce que vous devez publier en retour. La passerelle est sous AGPL-3.0, la seule brique qui se tient à la frontière réseau. L'AGPL est un copyleft réseau : si vous la modifiez et la servez à des tiers, vous devez publier vos modifications. Concrètement, un fork hébergé reste ouvert — la protection ne peut pas être refermée en silence.
Les composants — moteur, journal, vérificateur, audit, CLI, outillage — sont sous une licence permissive. Ce sont des bibliothèques et des runtimes : leur réutilisation large est le but, sans imposer de copyleft sur votre propre code. C'est ce qui rend l'ensemble à la fois ouvert et intégrable.
L'AGPL de la passerelle ne se propage pas au code qui l'appelle : seule la passerelle modifiée et servie est concernée.
03Ce qui est open
Libérez-vous de la confiance aveugle : ce que vous ne pouvez pas lire, vous ne pouvez pas le vérifier. Tout ce qui permet de contrôler la protection est publié.
- Le code source complet — moteur, passerelle, journal, vérificateur, CLI.
- Le journal de transparence et ses signatures Ed25519, rejouables à l'identique.
- Le binaire WASM de vérification et son empreinte publiée.
- Les règles d'audit et les heuristiques de contrôle du plan de contrôle.
- Les schémas et formats des compteurs agrégés signés.
Résultat : vous savez exactement ce que l'opérateur voit — et ce qu'il ne verra jamais. La distinction entre les deux est lisible dans le code, pas affirmée dans une brochure.
04Ce qui n'est pas open
Deux briques restent opérées par CLOISON. Elles ne sont pas publiées, et c'est volontaire. Il s'agit de la plateforme managée N3 (le proxy hébergé en edge sur api.wonkom.ai) et du plan de contrôle (l'arithmétique d'agrégation et le cycle de vie des compteurs signés).
Pourquoi. Publier le code exposerait la gestion des clés, l'orchestration et l'état interne de l'opérateur — une surface d'attaque, pas une forme de transparence. Mais le périmètre reste borné : le plan de contrôle ne recueille que des compteurs k-anonymes signés, jamais de texte ni de clair. Cette borne-là est précisément ce que le code ouvert vous permet de vérifier.
Le traitement des données s'inscrit d'abord dans notre cadre de référence : la loi n°2008-12 du Sénégal, l'Acte additionnel CEDEAO A/SA.1/01/10 (applicable aussi dans l'espace UEMOA), la Convention de Malabo (2014) et le régime deux étages de la CDP — déclaration ou autorisation préalable — avec la distinction responsable de traitement ≠ sous-traitant. Le RGPD n'y figure qu'à titre complémentaire, en fast-follow européen, et non comme cadre principal.
05Comment auditer
Aucune confiance requise : du fork au rapport, le chemin est reproductible. Épinglez un tag, jamais une branche — les tags sont immuables, c'est ce que vous devez comparer.
-
Fork
Clonez les dépôts et épinglez un tag précis pour figer l'état audité.
git clone https://github.com/coucagog/cloison-moteur git clone https://github.com/coucagog/cloison-gateway cd cloison-moteur && git checkout v0.9.0 -
Build
Compilez depuis la source, sans binaire précompilé. Le build doit être reproductible.
cargo build --release --target wasm32-unknown-unknown # → target/wasm32-unknown-unknown/release/verify.wasm -
Comparer
Comparez l'artefact construit à l'empreinte publiée dans le journal. Toute divergence — même infime — est un signal.
cloison-verify --journal journal.jsonl --key ed25519.pub -
Faire auditer
Confiez le code et le journal à un cabinet indépendant, puis publiez le rapport. La vérification devient publique.
Sortie attendue du vérificateur — aucun chiffre n'est inventé ici, les bornes sont celles que vous fixez :
✓ journal replayed in order
✓ signatures valid (Ed25519)
✓ per-aggregate k-anonymity: ≥ k
✓ no clear-text fields in signed payloads
result: VERIFIED