Our First Hire: The Dataset Anonymizer — MVP0 in Trial 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: not to circumvent the problem. L'**automate**.

== MVP0 : The Anonymizer, First Hired During Probation

The MVP0 is not a feature. It is a**convenience expert**— an employee who does the dirty, stupid, and nasty work, and that 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, that's it: we verify that it does not let false negatives slip through before confirming it.

== 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 does not search in dirty data — it searches in a space**clean by construction**. This changes everything for the quality of the responses: the LLM does not spend its time circumventing 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 — without ever exposing personal data.

== Why It's Marketable

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

1. *All training companies have 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* — it is the barrier

The SaaS Edster (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

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

[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**. RAG provides the content (vector similarity), Graphify provides the relationships (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. That's why the Anonymizer is not 'P0' in the backlog — it is**MVP0**. This is the first commercial deliverable, and everything else is conditioned 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's the**heart of the product**. The Anonymizer 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 cited in pitches. But it's him who runs the factory.

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 the 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]
----