Our First Hire: the Dataset Anonymizer — MVP0 in Probation Period

----
----
Données brutes client (SPG, cours, évaluations)
  ├→ Noms de stagiaires en clair dans les PDF
  ├→ Emails dans les métadonnées JSON
  ├→ IP de connexion dans les logs pgvector
  ├→ Identifiants dans les nœuds Graphify
  └→ Références OF pilote dans les schémas SQL
----

Result: either you do RAG on dirty data (PII hallucinations, GDPR non-compliance, legal risk), or you do nothing (no product). The third way — cleaning manually — is not scalable.

My answer: do not circumvent the problem. L'**automate**.

== MVP0: The Anonymizer, First Hired During the Probation Period

The MVP0 is not a feature. It's a**convenience expert**— an employee who does the dirty, mean, stupid work, and whom nobody wants to talk about in pitch decks.

What it does :

[source]
----
ENTRÉE : Données brutes multi-sources
  ├→ AsciiDoc (SPG_A2SP.adoc) → noms, dates, OF pilote
  ├→ JSON (catalogue formations) → emails, téléphones
  ├→ YAML (config workspace) → tokens OAuth2
  ├→ SQL (schémas DDL) → IP, adresses
  ├→ pgvector (métadonnées embeddings) → identifiants
  ├→ ONNX (outputs classification) → noms propres
  └→ Graphify (graph.json) → nœuds avec PII

SORTIE : Datasets propres, format standardisé
  ├→ [ANONYMIZED] remplace les PII détectées
  ├→ Classification RGPD (niveau 0→4)
  ├→ Rapport d'audit (quoi a été nettoyé)
  └→ Dataset prêt pour RAG ET fine-tuning
----

It detects the most obvious patterns first (emails`.*@.*`, tokens`sk-*`, `ghp_*`, IPs), then it learns. The trial period is that: we validate that it does not let false negatives pass before making it permanent.

== What this MVP unlocks (and it's not just compliance)

Anonymization as MVP0 is not the GDPR toll before the highway. It's the highway itself. Here's what it opens:

=== Present : Augmented Reality in Prompt

[source]
----
DONNÉES BRUTES CLIENT
    ↓
Anonymiseur MVP0 → datasets propres
    ↓
RAG pgvector (MVP1) → top-K documents similaires (filtrés, anonymisés)
    ↓
LLM (deepseek-v4-pro) → réponse augmentée, zéro PII
----

RAG doesn’t search in dirty data — it searches in a space**clean by construction**. This changes everything for answer quality: the LLM doesn't spend its time trying to avoid PII it recognizes but must not mention.

=== Future : Fine-Tuning on Healthy Data

[source]
----
MVP0 → datasets propres accumulés (session après session)
    ↓
Fine-tuning expert métier (CDA, FPA) sur données zéro PII
    ↓
Modèle fine-tuné exposé via Ollama (sans fuite de données)
----

Fine-tuning on raw data is a potential legal disaster. On clean data, it's a**reproducible method**. Each client accumulates its cleaned datasets, each client can fine-tune its business experts on its data — never exposing personal data.

== Why It's Marketable

It is not « a GDPR compliance tool ». It is a**reproducible method that transforms a universal problem into an asset** :

1. *Every training company has dirty data* — that's the problem
2. *There is no automated multi-source cleaning pipeline* — that's the market
3. *The loop: anonymization → RAG → fine-tuning is proprietary* — that's the barrier

Edster SaaS (MVP3) will not sell 'a Gradle workspace'. It will sell this closed loop. And MVP0 is the entry point.

== The SQL Format as the Third Way of Context

Importing structured data is not just an exchange format. The SQL schema (DDL) carries the**entity-relationship model of the domain** :

[source]
----
CREATE TABLE formation (
  id UUID PRIMARY KEY,
  titre VARCHAR NOT NULL,
  referentiel RNCP REFERENCES rncp(id),
  organisme OF REFERENCES of_pilote(id)  -- ← va être anonymisé
);
----

This DDL, once anonymized (line 4), becomes a source of context for the LLM. Not text — of**business model**. The RAG gives the content (vector similarity), Graphify gives the relationships (exact structure), and the SQL schema gives the**implicit Domain-Driven Design**bounded contexts, aggregates, value objects. The LLM understands the business because it reads its schema.

== The Roadmap: from MVP0 to SaaS

[source]
----
MVP0 — Anonymiseur (ce que cet article décrit)
  Sortie : datasets propres, reproductible

MVP1 — RAG pgvector (dépend de MVP0)
  Realité augmentée en prompt sur données nettoyées

MVP2 — Graphify + ONNX + SQL DDD (dépend de MVP1)
  Vecteur composite de contexte (règles + similarité + relations exactes)

MVP3 — SaaS Edster (dépend de MVP0-2)
  Provisionnement workspace client complet
----

Each MVP depends on the previous one. None can be delivered without MVP0. That's why the Anonymizer is not 'P0' in the backlog — it is**MVP0**. This is the first commercial deliverable, and everything else depends on its success.

== Conclusion: The Invisible Work That Makes Everything Possible

In a traditional startup, data cleaning is outsourced, manual, or ignored. In this architecture, it's the**heart of the product**. The Anonymiser is the first employee because without him, nothing works :

* Without MVP0 → no legal RAG (MVP1)
* Without MVP0 → no fine-tuning without data leak (EPIC 5)
* Without MVP0 → no credible SaaS (MVP3)
* Without MVP0 → no augmented reality in prompt
* Without MVP0 → no third context path (SQL DDD)

He does the dirty work. He will never be mentioned in the pitches. But he's the one who keeps the factory running.

And that's why we hire them first.

== References

* Article on spatial ontology and trust circles :link:../2026/0114_gouvernance_cercles_confiance_ontologie_spatiale_alignement_llm_post.html[The Spatial Ontology as Alignment Mechanism]
* Article on Eager/Lazy agent governance:link:../2026/0108_gouvernance_agent_opencode_eager_lazy_post.html[Governing an AI Agent with AsciiDoc]
* Article on the Hot/Warm/Cold mechanism:link:../2026/0110_mecanisme_backup_contexte_agent_post.html[Sliding Window and Cold Wave]
* Article on the comparison of the three LLMs :link:../2026/0112_comparaison_kimi_glm_deepseek_long_contexte_plugin_gradle_opencode_post.html[DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1]
----