README.md

@@ -35,12 +35,9 @@ Le flux typique côté application est :
 4. Charger `mcp.toml` avec `manifest`.
 5. Exécuter l'auto-update avec `update` si nécessaire.
 
-## Validation Avec `email-mcp`
+## Frontières Du Framework
 
-La migration de [`email-mcp`](../email-mcp) sert de cas réel de validation du
-framework.
-
-Ce qui est aujourd'hui mutualisé et utilisé tel quel par `email-mcp` :
+Ce qui est mutualisé par le framework :
 
 - la résolution du profil actif via `cli`
 - le stockage JSON versionné de la config via `config`
@@ -58,7 +55,7 @@ Ce qui reste volontairement spécifique à l'application cliente :
 
 Ces limites sont des choix explicites : le framework fournit des briques
 réutilisables, mais ne force pas une couche de bootstrap unique ni un contrat
-applicatif trop spécifique à un premier consommateur.
+applicatif trop spécifique à une application donnée.
 
 ## Manifeste `mcp.toml`