2026-04-22#ia #methode #friction-engineering #sofia

Friction Engineering — quand le désaccord devient le mécanisme

Je suis architecte SI depuis plus de quinze ans. Plutôt détracteur de l'IA pendant plusieurs années — les machines ne créent pas, elles digèrent et proposent une réponse statistiquement correcte. Et puis je me suis retrouvé à construire massivement avec l'IA. Pas par conversion. Par nécessité.

Ma pratique m'a poussé à structurer la démarche pour qu'une réussite locale ne reste pas une exception. L'architecture, c'est le processus de décision qui assure le maintien de la direction dans le temps. Ces décisions se prennent en friction avec leur contexte : échanges avec des pairs, challenge des ambitions métier face aux ressources disponibles, arbitrages entre ce qui est souhaitable et ce qui est faisable. Cette friction est naturelle entre humains. Avec des assistants IA, elle disparaît — il faut la concevoir.

Je propose une pratique que j'appelle Friction Engineering : la conception délibérée de friction entre des assistants IA spécialisés et un orchestrateur humain, comme mécanisme de qualité qui gouverne les décisions avant qu'elles ne deviennent une spécification et du code.

Les approches émergentes — la gouvernance structurée des prompts (Zhang & Xia, 2026) ou les frameworks multi-agents autonomes (Wu et al., 2023) — progressent sur la structuration et la coordination, mais aucune ne crée de challenge croisé entre perspectives spécialisées distinctes sous arbitrage du praticien. C'est ce vide que Friction Engineering vise à combler.

L'IA dit oui. C'est le problème.

Un LLM seul dit oui. Pas toujours, mais suffisamment souvent pour que ce soit un problème structurel plutôt qu'anecdotique.

Le problème fondamental de la collaboration humain-IA n'est pas l'erreur visible — c'est le consensus silencieux. L'IA acquiesce, le praticien valide, et personne ne challenge la décision. Buçinca et al. (2021) l'ont montré empiriquement : sans friction délibérée, les humains acceptent les sorties IA sans examen critique. La Rosa & Beretta (2025) posent la question au niveau systémique : comment étendre les modèles de friction d'une dyade humain-IA à des systèmes cognitifs joints plus complexes ? Dans un binôme humain, le désaccord productif émerge naturellement. Avec une IA, il faut le provoquer intentionnellement.

Quatre symptômes reviennent en boucle :

La dérive de scope en mono-assistant. Tu commences avec un assistant généraliste. Au bout de trois sessions, il code, conseille, rédige, arbitre — dans la même conversation, avec le même ton, sans contrainte. Pose-lui une question mal cadrée, il produit une réponse bien formulée. Donne-lui une direction bancale, il exécute avec enthousiasme. Ce n'est pas de la collaboration. C'est de la complaisance.

L'oubli de contexte. Sur les sessions longues ou multi-activités, le contexte se perd. Les hypothèses de janvier sont encore actives en avril. Les décisions prises la semaine dernière ont disparu de la fenêtre. L'assistant recommence à zéro sans le dire.

La mémoire propriétaire. Ce que l'assistant "sait" vit dans l'infrastructure du fournisseur. Change de provider, tout disparaît. La dépendance est silencieuse mais totale.

L'opacité de la pratique. Comment avoir une structure de travail transférable à un autre praticien et auditable ? Comment savoir si ce qu'on fait fonctionne, si ça se dégrade, si on peut s'améliorer ?

Ce que ça devrait être

J'ai une image en tête de ce que pourrait être une collaboration humain-IA qui tient dans la durée. Contre la dérive de scope — des assistants qui ne font pas tout mais font bien ce qu'ils font, focalisés sur leur domaine, capables de contester avec précision plutôt que d'acquiescer avec élégance. Contre l'oubli et la dépendance — un système où rien ne se perd, chaque décision tracée, chaque session historisée, la mémoire qui persiste hors du fournisseur, dans mes fichiers, dans mon repo, portable d'un provider à l'autre. Contre l'opacité — une pratique transférable, auditable, qui permet de savoir si ce qu'on fait se dégrade avant qu'il ne soit trop tard.

Rien de tout ça n'existe dans les outils actuels. Les providers vendent de la fluidité. Personne ne vend de la friction.

Friction Engineering

L'implémentation repose sur un principe : créer de la friction intentionnelle — un challenge croisé systématique entre assistants spécialisés, sous le contrôle du praticien, jusqu'à convergence. Le moyen d'assurer la qualité des décisions en amont de la production.

L'intérêt d'isoler est le challenge et l'inspection. Un persona peut challenger le travail d'un autre, toujours sous l'observation du praticien, afin de compléter la copie d'un point de vue différent.

L'isolation est le mécanisme central. Chaque assistant est contraint par un persona — un rôle, un scope produit, des relations explicites avec les autres. Il ne voit que son périmètre. Il conteste mieux parce qu'il conteste moins large. Le contexte projet et le contexte persona s'emboîtent — l'un est inclus dans l'autre. Jamais oublié.

La friction gouverne les décisions en amont. En aval, il faut aussi encadrer l'exécution — c'est une deuxième boucle.

Sur la partie aval, pour la production, on peut utiliser un certain nombre de techniques provenant du développement logiciel — TDD, hooks, CI. Bockeler (2026) formalise cette boucle sous le nom de harness engineering : des guides (feedforward) et des sensors (feedback), computationnels ou inférentiels, qui encadrent l'exécution de l'agent. Elle note cependant que le behaviour harness — s'assurer que le système fait ce qu'il faut — reste un problème ouvert. Friction Engineering complète ce tableau : la boucle amont (friction entre perspectives spécialisées) vise précisément à clarifier les décisions de conception avant que le harness aval prenne le relais.

Je développe une méthode autour de cette observation — SOFIA, A method for orchestrating specialized AI personas through intentional friction — qui permet de répondre à ces différents enjeux. Dans SOFIA, le praticien est l'orchestrateur : c'est lui qui active les personas, route les artefacts, et arbitre les frictions. Voici comment.

L'implémentation ici s'appuie sur le provider Claude et sur une structure de fichier en markdown sourcée dans git pour l'historique. La méthode elle-même est agnostique du fournisseur.

Un assistant qui ne déborde pas

Un assistant généraliste, au bout de trois sessions, code, conseille, rédige, arbitre — dans la même conversation, avec le même ton, sans contrainte. Un LLM a une fenêtre de contexte finie. Plus le contexte est large, plus le signal est dilué. L'agent sait un peu de tout mais ne conteste rien avec précision.

Chaque persona est défini par un fichier chargé au boot de la session. Trois couches d'isolation : son rôle et ses compétences (ce qu'il sait faire), son scope produit (les fichiers qu'il peut lire, les artefacts qu'il produit, ce sur quoi il n'intervient pas), et ses relations (avec quels autres personas il interagit, et comment).

Un persona ne débordera pas de son activité et saura dire si la tâche n'est pas de son ressort. Il pourra challenger le travail d'un autre persona au regard de sa perspective — ou même les propositions du praticien. Ces challenges sont appelés frictions.

Mira — persona architecte — a produit cinq fois des livrables pédagogiques : guide utilisateur, onboarding, quick start, mode manuel, grammaire de dérivation. Chaque fois, faute de persona dédié. Le résultat était structurellement correct mais pas pédagogiquement optimisé — une grammaire de dérivation est un artefact pédagogique, pas architectural. Elle doit rendre adoptable un processus, pas le spécifier.

L'isolation a rendu le signal visible : 3+ déflexions sur le même domaine, seuil atteint. Le constat a conduit à identifier un axe non couvert dans la structure — et à envisager un persona dédié à la pédagogie. Sans l'isolation, Mira aurait continué à absorber ce rôle par gravité, et personne ne l'aurait vu.

Une mémoire qui ne s'efface pas

Sur des sessions de design, la perte de contexte est frustrante. Sur des projets longs, c'est structurellement dangereux. Les hypothèses de janvier sont encore actives en avril. Les décisions prises la semaine dernière ont disparu de la fenêtre. L'assistant recommence à zéro sans le dire.

Un fichier de contexte par persona, versionné dans git, rechargé à chaque session. Pas la mémoire du fournisseur — la tienne. En markdown, dans un repo, inspectable et portable.

Voici à quoi ressemble un fichier de contexte :

---
persona: winston
produit: oxynoe
---
# Contexte Rédacteur — Oxynoe

## Périmètre
Contenu éditorial : articles (fragments), veille (regards),
livre bleu (mise en voix), posts de lancement.

## Documents clés
| Fichier | Rôle |
|---------|------|
| fragments/ | Articles courts — sources .md |
| regards/   | Veille périodique — sources .md |

## Flux inter-instances
- Reçoit de Produits : claims validées (Léa)
- Reçoit de Méthodes : contenu méthode accessible (Pédagogue)

À chaque clôture de session, un résumé structuré est produit — ce qui a été fait, les décisions prises, les frictions soulevées, ce qui reste ouvert :

---
persona: mira
date: 2026-04-16
session: "2233"
---
## Produit
- Annotation H2A sur 25 reviews — 114 lignes de friction annotées
- Suppression de 35 doublons cross-instances

## Décisions
- Source de vérité reviews = produits/shared/review/ [PO]
- Sessions immutables — pas de reconstruction [mira] → ratifié

## Friction orchestrateur
- ~ [contestable] circuit court sur suppression hors périmètre
  — [PO] → ratifié
- ~ [contestable] Mira propose de ne pas ajouter le tag initiative
  — [PO] → révisé

## Ouvert
- 24 reviews avec résolutions à qualifier

Les personas n'oublient jamais ce qui s'est passé dans les sessions précédentes. Le persona suivant commence là où le précédent s'est arrêté. L'orchestrateur peut remonter dans l'historique git pour retrouver n'importe quelle décision.

Des décisions qui ne se prennent pas en silence

Les décisions prises silencieusement sont le mode de défaillance le plus courant. Un persona propose, l'orchestrateur valide, le suivant exécute. La chaîne est fluide — et c'est précisément le problème. La fluidité n'est pas de la qualité. C'est de l'absence de friction.

Toutes les décisions sont soumises au praticien et tracées. Chaque friction est qualifiée par un marqueur — [sound], [contestable], [simplification], [blind_spot], [refuted] — et résolue explicitement : ratifiée, révisée, contestée, ou rejetée. Ce mécanisme s'inspire du protocole d'intelligibilité de Mestha et al. (2025) — PXP — qui structure l'interaction itérative humain-IA autour de prédictions et d'explications mutuelles. Les quatre résolutions du protocole (ratifié, révisé, contesté, rejeté) sont une adaptation des gestes PXP, appliqués au niveau friction plutôt qu'au niveau message.

Le marqueur dit ce qui a été contesté. La résolution dit ce qu'on en a fait. Voici une friction résolue, tirée d'une session d'architecture :

~ [contestable] Mira propose de ne pas ajouter le tag initiative
  (redondant avec frontmatter) — [PO] → révisé
  Le PO corrige : le script d'audit parse en batch, pas le contenu.
  Le tag est ajouté.

Mira avait un raisonnement valable — éviter la redondance. Le praticien a vu ce qu'elle ne pouvait pas voir : le besoin du pipeline d'analyse en aval. La friction a fait émerger une contrainte invisible. Sans elle, le tag n'aurait pas été ajouté, et le dashboard aurait été aveugle.

Autre exemple. Un persona développeur propose un ADR pour l'exécution concurrente du moteur de rendu. Design solide. Architecture cohérente. Un persona architecte le review et dit : pas maintenant. Pas de goulet d'étranglement mesuré. La roadmap dit « make it work avant make it fast ». Un point sécurité n'est pas traité. L'ADR attend. Le design sera meilleur quand le moment viendra. Sans ce pushback, le dev aurait implémenté — et le risque était que le moteur de nettoyage casse le player quelques mois plus tard, forçant un retravail complet.

Sans résolution, la friction est un inventaire de désaccords — elle ne gouverne rien.

Une méthode qui se transmet

Comment permettre à un autre praticien, dans un autre domaine, de s'approprier la manière de travailler ? En ambition, j'aimerais que cette méthode puisse être utilisée à l'échelle par des équipes pluridisciplinaires.

Le protocole formel — H2A (Human-to-Assistant) — sépare les modalités de travail communes (sessions, frictions, artefacts) de ce qui est spécifique à chaque praticien via les canvas. Le transfert part d'une base simple : persona, artefact, session. Trois briques. La friction comme élément constitutif de la mise en lumière des décisions. La gestion du contexte autour des sessions et des artefacts.

Le modèle en pratique :

persona (rôle + contraintes)
    ↓ produit
artefact (frontmatter + contenu)
    ↓ circule via
session (résumé structuré + frictions qualifiées)
    ↓ arbitré par
praticien (valide, révise, rejette)

La méthode est aujourd'hui utilisée par quatre praticiens sur des domaines différents. C'est de l'adoption précoce — les retours sont encourageants mais le recul reste limité. Le transfert fonctionne parce que la base est simple. Un praticien qui n'a jamais entendu parler de friction en tire un bénéfice immédiat — son dispositif ne dérive plus.

Un cockpit pour observer sa propre pratique

Plusieurs praticiens utilisent la méthode. Comment les conseiller sur leur pratique sans lire les dizaines de sessions et d'artefacts de leur instance ? Comment détecter un persona trop coulant, repérer un scope qui dérive, identifier l'usure avant qu'elle ne s'installe ?

L'usure est le mode de défaillance le plus contre-intuitif, parce qu'il ressemble à du succès. Les surfaces de friction se polissent mutuellement. L'orchestrateur rejette la contestation, les personas adoucissent leur pushback. Le système se dégrade en accord poli. Les sessions tournent, les marqueurs apparaissent, les résolutions sont loguées — mais la contestation n'a plus de dents.

Le protocole H2A structure formellement la manière dont les personas enregistrent leurs sessions et leurs artefacts — ce qui permet d'auditer une instance, de la recalibrer et de conseiller le praticien sur sa pratique. Un pipeline d'analyse lit les sessions, extrait les frictions, et produit un dashboard avec cinq vues :

Vue	Question
Map	À quoi ressemble l'organisation ? Topologie, personas, trajectoire

Mirror	Suis-je en bonne santé comme orchestrateur ? KPIs, radars, flux
Lens	Que s'est-il passé dans le temps ? Séries temporelles, distributions

Probe	L'instance est-elle conforme structurellement ? Checks pass/warn/fail
Legend	Comment lire tout ça ? Documentation embarquée

L'usure est détectable par instrumentation : un ratio croissant de [sound] et de ratified, une disparition progressive des [contestable] et des [blind_spot]. Chaque persona reçoit des tags de mode de défaillance — slip (friction sans arbitrage), wear (surfaces polies), crush (un côté impose), asymmetry (friction à sens unique). La détection requiert que quelqu'un regarde. Et c'est le paradoxe : plus le système tourne bien, moins l'orchestrateur est vigilant.

Exemple concret. Un audit post-sprint a révélé que Mira — persona architecte — avait absorbé quatre rôles en plus du sien pendant trois jours de publication : dev, ops, release manager, graphiste. Pendant ce sprint, elle n'a produit aucun ADR — elle a codé à la place de spécifier. Et 3 mécanismes de friction sur 3 avaient été court-circuités. L'audit a rendu visible ce que la pression de publication avait rendu invisible. Le persona n'avait pas débordé par incompétence — il avait débordé par gravité, parce que personne d'autre ne portait ces rôles.

Le snapshot actuel de mes trois instances est accessible en open-data : oxynoe.io/h2a.

Ce que ça change

L'isolation permet le focus. Chaque assistant conteste mieux parce qu'il conteste moins large. La séparation des responsabilités n'est pas un organigramme — c'est du context engineering appliqué à la friction.

Les décisions sont visibles, pas déléguées. Accélération de la qualité et de la maintenabilité. Les décisions peuvent ensuite, dans un contexte de dev logiciel, être utilisées pour encadrer le développement via le harness.

La méthode est transférable et réplicable. Plusieurs instances hors de mes travaux le suggèrent, avec les réserves d'un recul encore limité.

L'audit d'instance permet de recadrer. La structure et les personas peuvent être ajustés sur la base de données observables, pas d'impressions.

Ce qui reste à construire

Friction Engineering est un travail empirique en phase initiale. Un praticien principal, neuf personas, trois instances projet, 400+ sessions sur plusieurs mois.

Deux chantiers ouverts :

Scalabilité aux équipes pluridisciplinaires. Mon intuition : chaque praticien de l'équipe pourra avoir son instance et ses personas afin d'atteindre ses objectifs et augmenter sa vitesse et la qualité de ses rendus — nous pourrons faire ce que nous n'avions pas le temps de faire avant. Mais c'est une intuition, pas un résultat.

Formalisation. Un article exhaustif sur la position prise dans cette entrée de blog, ainsi qu'un second analysant l'ensemble des métriques et constats pratiques que moi et les différents praticiens avons rencontrés.

Les données, le protocole et l'instrumentation sont ouverts parce que ces questions méritent d'être testées au-delà d'un seul projet. Feedback et contestation bienvenus — c'est un peu le principe.

Pour aller plus loin

Pour appliquer la méthode, un référentiel documentaire est disponible, ainsi qu'un ensemble d'outils — des canvas pour adapter la méthode à sa propre pratique et le formalisme du protocole :

Méthode SOFIA : oxynoe.io/sofia (v0.3.7)
Repo méthode : github.com/oxynoe-dev/sofia
Données de friction (open-data) : oxynoe.io/h2a

Références

Buçinca, Z., Malaya, M. B. & Gajos, K. Z. (2021). "To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI in AI-assisted Decision-making". Proc. ACM Hum.-Comput. Interact. (CSCW).
La Rosa, B. & Beretta, A. (2025). "Frictional AI in Joint Cognitive Systems". HHAI 2025 Workshop, Pisa (CEUR Vol. 4074).
Mestha, R. et al. (2025). "Intelligibility Protocol" (PXP).
Bockeler, B. (2026). "Harness Engineering for Coding Agent Users". martinfowler.com.
Zhang, W. & Xia, J. (2026). "Structured-Prompt-Driven Development". martinfowler.com.
Wu, Q. et al. (2023). "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation". arXiv:2308.08155.

← Tous les fragments