Our First Hire: the Dataset Anonymizer — MVP0 on Probation

----
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 by hand — is not scalable.

My response: do not bypass the problem.**automate it**.

== MVP0: the Anonymizer, First Hire on Probation

The MVP0 is not a feature. It is a**commodity expert**— an employee who does the dull, dirty work that no one 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 probation period is exactly that: we validate that it doesn't let false negatives slip through before making it permanent.

== What this MVP Unlocks (and it's not just Compliance)

Anonymization as MVP0 is not the GDPR toll booth before the highway. It is the highway itself. Here is 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 through dirty data — it searches in a space**clean by construction**. This changes everything for response quality: the LLM doesn't spend its time bypassing PII that 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 legal catastrophe waiting to happen. On clean data, it is a**reproducible method**. Each client accumulates their cleaned datasets, each client can fine-tune their business experts on their data — without ever exposing personal data.

== Why It's Marketable

It's 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. *None have an automated multi-source cleaning pipeline* — that's the market
3. *The loop: anonymization → RAG → fine-tuning is proprietary* — that's the barrier

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

== 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 context source for the LLM. Not text — a**business model**. RAG provides the content (vector similarity), Graphify provides the relations (exact structure), and the SQL schema provides 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. This is why the Anonymizer is not "P0" in the backlog — it is**MVP0**. It is the first commercial deliverable, and everything else is contingent on its success.

== Conclusion: the Invisible Work that Makes Everything Possible

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

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

It does the dirty work. It will never be mentioned in pitches. But it's the one that runs the factory.

And that's why we hire it first.

== References

* Article on spatial ontology and trust circles:link:../2026/0114_gouvernance_cercles_confiance_ontologie_spatiale_alignement_llm_post.html[Spatial Ontology as an 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]