Notre Premier Embauché : l'Anonymiseur de Datasets — MVP0 en Période d'Essai

Publié le 03 May 2026

temps de lecture : 12 minutes

Je n’embauche pas un LLM. J’embauche un anonymiseur. Avant de faire du RAG pgvector, avant de fine-tuner des experts CDA/FPA, avant de provisionner des workspaces clients — quelqu’un doit nettoyer les toilettes de la data. Cet employé, c’est l’expert anonymisation (MVP0, EPIC 2 de codebase-gradle). Et c’est lui qui rend le produit marketable.

1. Le Problème qui Fait Fuir tout le Monde

Toute startup IA qui manipule des données de formation se heurte au même mur :

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

Résultat : soit tu fais du RAG sur des données sales (hallucinations de PII, non-conformité RGPD, risque juridique), soit tu ne fais rien (pas de produit). La troisième voie — nettoyer à la main — n’est pas scalable.

Ma réponse : ne pas contourner le problème. L'automatiser.

2. MVP0 : l’Anonymiseur, Premier Embauché en Période d’Essai

Le MVP0 n’est pas une feature. C’est un expert de commodité — un employé qui fait le sale boulot bête et méchant, et dont personne ne veut parler dans les pitch decks.

Ce qu’il fait :

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

Il détecte les patterns les plus évidents d’abord (emails .@., tokens sk-, ghp_, IPs), puis il apprend. La période d’essai, c’est ça : on valide qu’il ne laisse pas passer de faux négatifs avant de le titulariser.

3. Ce Que ce MVP Débloque (et ce n’est pas juste la Conformité)

L’anonymisation comme MVP0 n’est pas le péage RGPD avant l’autoroute. C’est l’autoroute elle-même. Voici ce qu’elle ouvre :

3.1. Présent : Réalité Augmentée en Prompt

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

Le RAG ne cherche pas dans des données sales — il cherche dans un espace propre par construction. Ça change tout pour la qualité des réponses : le LLM ne passe pas son temps à contourner des PII qu’il reconnaît mais qu’il ne doit pas mentionner.

3.2. Futur : Fine-Tuning sur Données Saines

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)

Le fine-tuning sur données brutes est une catastrophe juridique en puissance. Sur données propres, c’est une méthode reproductible. Chaque client accumule ses datasets nettoyés, chaque client peut fine-tuner ses experts métier sur ses données — sans jamais exposer une donnée personnelle.

4. Pourquoi C’est Marketable

Ce n’est pas « un outil de conformité RGPD ». C’est une méthode reproductible qui transforme un problème universel en actif :

  1. Toute entreprise de formation a des données sales — c’est le problème

  2. Aucune n’a de pipeline automatisé de nettoyage multi-source — c’est le marché

  3. La boucle : anonymisation → RAG → fine-tuning est propriétaire — c’est la barrière

Le SaaS Edster (MVP3) ne vendra pas « un workspace Gradle ». Il vendra cette boucle fermée. Et le MVP0 est la porte d’entrée.

5. Le Format SQL comme Troisième Voie de Contexte

L’import de données structurées n’est pas qu’un format d’échange. Le schéma SQL (DDL) porte le modèle entité-relation du domaine :

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é
);

Ce DDL, une fois anonymisé (ligne 4), devient une source de contexte pour le LLM. Pas du texte — du modèle métier. Le RAG donne le contenu (similarité vectorielle), Graphify donne les relations (structure exacte), et le schéma SQL donne le Domain-Driven Design implicite : bounded contexts, agrégats, value objects. Le LLM comprend le métier parce qu’il lit son schéma.

6. La Roadmap : du MVP0 au SaaS

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

Chaque MVP dépend du précédent. Aucun ne peut être livré sans le MVP0. C’est la raison pour laquelle l’Anonymiseur n’est pas « P0 » dans le backlog — il est MVP0. C’est le premier livrable commercial, et tout le reste est conditionné à sa réussite.

7. Conclusion : le Travail Invisible qui Rend Tout Possible

Dans une startup classique, le nettoyage de données est externalisé, manuel, ou ignoré. Dans cette architecture, c’est le cœur du produit. L’Anonymiseur est le premier employé parce que sans lui, rien ne fonctionne :

  • Sans MVP0 → pas de RAG légal (MVP1)

  • Sans MVP0 → pas de fine-tuning sans fuite de données (EPIC 5)

  • Sans MVP0 → pas de SaaS crédible (MVP3)

  • Sans MVP0 → pas de réalité augmentée en prompt

  • Sans MVP0 → pas de troisième voie de contexte (SQL DDD)

Il fait le sale boulot. Il ne sera jamais cité dans les pitchs. Mais c’est lui qui fait tourner l’usine.

Et c’est pour ça qu’on l’embauche en premier.

8. Références