La méthode SOFIA

Des rôles spécialisés qui pensent avec vous. Le produit émerge de leur friction.

Trois piliers

SOFIA repose sur trois idées. Elles ne fonctionnent pas l'une sans l'autre.

Contraindre — Un assistant IA sans limites dit oui à tout et ne produit rien de bon. SOFIA impose à chaque assistant un rôle strict, un périmètre, et surtout des interdits. C'est la limitation qui le rend utile.

Éprouver — Si tous les rôles sont d'accord, personne ne pense. La friction entre un architecte qui refuse de coder et un dev qui refuse d'implémenter une spec floue est un signal, pas un bug. Les désaccords forcent la clarté.

Arbitrer — La friction sans arbitre est du chaos. L'humain écoute, questionne, puis tranche. Toujours. Aucun assistant ne valide ses propres propositions. Aucun assistant ne force l'acceptation d'une décision.

TROIS PILIERS 1 Contraindre Un role strict. Un perimetre. Des interdits. la limitation rend utile 2 Eprouver Les desaccords sont des signaux. Pas des bugs. la friction force la clarte 3 Arbitrer L'humain ecoute, questionne, puis tranche. l'humain decide. toujours. sofia · trois piliers

Le modèle

Trois objets interdépendants. Le persona contraint produit des artefacts. Les artefacts créent de la friction quand ils sont éprouvés par d'autres personas. La friction produit de meilleures décisions. L'humain orchestre le cycle.

PERSONA ARTEFACT FRICTION l'humain

Piliers et concepts

Les piliers disent pourquoi, les concepts disent comment.

Pilier Concept Lien
Contraindre Persona Le persona est le véhicule de la contrainte — rôle strict, périmètre borné, interdits
Éprouver Friction La friction naît quand des personas contraints se confrontent sur un même sujet
Arbitrer Artefact L'artefact est le support de l'arbitrage — tracé, versionné, adressable. L'humain tranche sur pièce

Sept principes

# Principe En bref
1 La friction est productive Les désaccords entre rôles sont des signaux
2 L'humain arbitre Les assistants proposent, l'humain tranche
3 Chaque voix compte Un rôle inutilisé est un rôle à supprimer
4 La contrainte force la qualité Définis ce que le rôle ne fait pas avant ce qu'il fait
5 Les artefacts sont le protocole Les échanges passent par des fichiers, pas du chat
6 Tout est tracé Si ce n'est pas tracé, ça n'existe pas
7 Commence petit, itère Un rôle au démarrage. Les autres émergent du travail

Lire les principes en détail


Anatomie d'un persona

Un persona est un assistant IA contraint par un fichier d'instructions (persona.md) qui définit son identité, sa posture, son périmètre et ses interdits.

Chaque persona évolue dans son propre workspace. Il ne voit que ses fichiers. Il ne peut pas lire ou écrire chez les autres. L'isolation force les échanges formels : pour communiquer, il faut déposer un artefact.

ANATOMIE D'UN PERSONA ce qui le definit, ce qu'il produit, ce qu'il echange Persona PERSONA.MD — LE CONTRAT Identite + Posture Perimetre + Interdits Conventions Protocole session 1 persona = 1 workspace = 1 persona.md Sessions RESUME OBLIGATOIRE Produit · Decisions Notes deposees · Ouvert le pont entre conversations Livrables TYPES SELON LE ROLE specs · code · reviews notes · maquettes · ADR nommes, versionnes, adressables Bus shared/ ZONE D'ECHANGE ENTRE PERSONAS notes/ review/ features/ roadmap-*.md orga/ chaque artefact : de · pour · type · statut · date Persona B lit, reagit Persona C lit, reagit Emergence 3+ refus sur un domaine → signale le manque PO humain orchestre · filtre · contextualise · tranche

Ce qui tourne autour d'un persona

Sessions — Chaque conversation produit un résumé. C'est le pont entre les sessions : la suivante commence par lire la précédente. Format structuré, 30 lignes max.

Livrables — Chaque persona produit des livrables typés selon son rôle : specs, reviews, code, notes stratégiques, maquettes. Pas du texte générique — des artefacts nommés, adressables, versionnés.

Artefacts échangés — Les personas ne se parlent pas. Ils déposent des fichiers dans un bus partagé (shared/). Notes, reviews, features — chacun avec un frontmatter qui dit qui l'a écrit, pour qui, et si c'est traité.

Émergence — Un persona bien contraint détecte quand une question sort de son périmètre. Après 3 refus sur le même domaine, il signale le manque. Le persona suivant naît de cette observation, pas d'un plan initial.

Voir les personas en détail


L'orchestration

L'humain est le message bus. Rien ne circule entre personas sans lui.

ORCHESTRATION l'humain porte le contexte entre les personas PO humain Architecte specs · ADR · reviews ne code pas Dev code · tests · frictions ne decide pas l'archi Stratege positionnement · pricing pas d'acces au code UX parcours · maquettes ne valide pas la faisabilite PAS DE LIEN DIRECT PAS DE LIEN DIRECT shared/ notes · reviews · features — le bus d'echange chaque fleche passe par le PO — pas de raccourci

L'humain ouvre une session avec un persona, obtient un livrable, ferme la session. Ouvre une session avec un autre persona, transmet le livrable, recueille la réaction. Chaque transmission est un moment de filtrage, de reformulation, d'ajout de contexte.

Ce que l'humain ne délègue pas :

C'est lent. C'est le prix de la qualité. Si l'échange n'en vaut pas le coût, c'est que le sujet ne nécessitait pas plusieurs personas.


Trois couches

La méthode se structure en trois couches indépendantes. On peut changer l'une sans toucher les autres.

Core — Les invariants. Principes, personas, friction. Ce qui ne change pas quand on change d'outil. Si demain Claude Code disparaît, le core tient.

Protocol — Le contrat d'interface. Artefacts, conventions, traçabilité, instance. Fichiers, pas API. Git, pas base de données. Le protocol est ce qui rend la méthode portable — n'importe quel outil capable de lire et écrire des fichiers markdown peut implémenter SOFIA.

Runtime — L'implémentation concrète. CLAUDE.md, Claude Code, hooks, mémoire persistante. Remplaçable sans toucher au core ni au protocol. C'est la seule couche qui change si on porte SOFIA sur un autre provider.

Couche Contenu Change quand…
Core principes, personas, friction, devoirs …la méthode évolue (rare)
Protocol artefacts, conventions, traçabilité, instance …le format d'échange évolue
Runtime CLAUDE.md, hooks, sessions, mémoire …on change d'outil

Le gradient

La méthode ne se déploie pas en big bang. Elle grandit avec le projet.

Seuil Ce qui s'active
1 persona persona.md + sessions/ — la base
2+ personas shared/ — le bus d'échange (notes, reviews)
3+ personas backlogs par workspace
4+ personas features/ — les specs formalisées

On commence petit. On ajoute de la structure quand la charge mentale de l'humain l'exige.


Terrain

La méthode a été développée et validée sur le projet Katen — un moteur d'orchestration formellement vérifié pour pipelines Data & IA, construit avec 7 personas sur 210+ sessions.

Indicateur Valeur
Personas actifs 7 (architecte, dev, UX, stratégie, recherche, rédaction, graphisme)
Sessions 210+
ADR produits 62
Produit en cours Katen (v0.2, 5 semaines)

Voir les fiches personas KatenLire le livre bleu


Six devoirs de l'humain

Les personas produisent, challengent, documentent. Mais certaines responsabilités ne se délèguent pas.

  1. Vérifier les faits — Les LLMs ne comptent pas. Dates, chiffres, références : vérification humaine systématique.
  2. Arbitrer — Écouter, questionner, trancher. La décision est tracée.
  3. Relire ce qui sort — Aucun document ne sort sans relecture complète.
  4. Calibrer les personas — Ajuster les contraintes en continu.
  5. Séparer réflexion et production — Celui qui rédige n'est pas celui qui valide.
  6. Maintenir l'attention — Quand tu approuves sans lire, c'est le moment de ralentir.

Lire les devoirs en détail