Pourquoi j'ai construit un protocole de friction pour la collaboration humain-IA
Le mois dernier, un de mes personas IA a proposé un ADR pour l'exécution concurrente. Design solide. Fondation théorique propre. Architecture cohérente, mode opt-in. Du bon travail.
Un autre persona l'a reviewé et a dit : pas maintenant. Cinq recommandations, trois haute priorité. Pas de goulet d'étranglement mesuré. La roadmap a des priorités avant ça. Un point sécurité est non négociable.
Personne n'avait tort. Le développeur avait anticipé un besoin réel — la concurrence sera nécessaire quand le moteur gérera des compositions lourdes. L'architecte a protégé la roadmap : les principes du projet disent « make it work, make it right, make it fast — dans cet ordre ». On n'en était pas à fast.
Sans ce pushback, le dev implémente. Le moteur de nettoyage casse le player trois mois plus tard. Tout est retravaillé. Avec le pushback, l'ADR attend. Le design sera meilleur quand le moment viendra. Le travail n'est pas perdu. Il est protégé.
Ce moment capture quelque chose autour de quoi je tourne depuis des mois. Pas un framework. Une observation.
Le problème, c'est l'accord
Un LLM seul dit oui. Toujours.
Il code, conseille, rédige — dans la même conversation, avec le même ton, sans contrainte. Posez-lui une question mal cadrée, il produit une réponse bien formulée. Donnez-lui une direction bancale, il exécute avec enthousiasme. Ce n'est pas de la collaboration. C'est de la complaisance.
La réponse dominante du marché est d'empiler l'automatisation : des agents qui font le travail, des humains qui supervisent. Les démos sont impressionnantes. L'arithmétique l'est moins.
Même dans le modèle sériel le plus simple — dix étapes, aucune correction intermédiaire — un agent fiable à 90 % par étape enchaîne vers un taux d'échec global de ~65 % (1 − 0.9¹⁰ ≈ 0.65). Les pipelines réels ont des retries et des checkpoints, donc le chiffre exact varie. Mais la direction tient : l'erreur de l'étape 2 arrive à l'étape 3 comme une prémisse valide. La cascade est silencieuse. La sortie finale a l'air correcte. Elle ne l'est pas.
C'est structurel. Un système optimisé pour la plausibilité plutôt que la vérifiabilité va diverger de l'exactitude factuelle à mesure que la séquence s'allonge (LeCun 2022). Construire de l'automatisation massive sur cette base, c'est empiler de l'incertitude sur de l'incertitude.
Alors quelle alternative ? Pas l'automatisation totale. Pas le refus total. Quelque chose entre les deux — où le désaccord est le mécanisme, pas le mode de défaillance.
La friction comme mécanisme
Voilà la thèse qui a réorganisé ma façon de construire avec l'IA : la friction — entre humains et machines, et entre machines elles-mêmes — n'est pas un problème à résoudre. C'est, je crois, le mécanisme qui produit la valeur.
Chaque fois qu'un persona contraint pousse back sur une prémisse avant l'implémentation, j'attrape une erreur qui aurait cascadé. Chaque fois que je dois arbitrer entre deux personas en désaccord, une décision se précise. Chaque fois qu'une claim est marquée contestable plutôt que ratifiée, le système fait remonter quelque chose que la sortie brute aurait caché.
J'ai fini par appeler ça Friction Engineering — la conception délibérée de friction entre des personas IA contraints et un orchestrateur humain, comme mécanisme de qualité amont qui gouverne ce qui est construit avant que tout harness ne gouverne comment c'est construit.
Ce n'est pas une préférence de style. C'est une réponse à la limitation structurelle que je viens de décrire. Si le modèle ne peut pas te dire quand il se trompe, il te faut une architecture qui rend le « faux » observable avant qu'il ne se compose.
Trois conditions
Il y a une formule sur laquelle je reviens sans cesse :
if (human.domain_expertise && human.open_mind && human.resilient_to_friction) {
value = max(human.value + project.friction + agents.harness,
human.value)
}Ce n'est pas élégant. C'est une hypothèse de conception, pas un résultat prouvé. Mais ça capture quelque chose que je n'ai pas trouvé de meilleure façon d'exprimer.
L'expertise du domaine
L'IA amplifie ce que le praticien apporte. Elle n'invente pas.
Si je ne connais pas le domaine, je ne peux pas détecter quand la sortie est structurellement correcte mais qualitativement plate. Je ne peux pas sentir quand un persona glisse de la contestation aiguisée vers la complaisance molle. Je vais ratifier ce que je ne devrais pas ratifier, et le système va se dégrader en silence.
La compétence de domaine n'est pas optionnelle. C'est la raison pour laquelle la boucle fonctionne.
L'ouverture d'esprit
Il faut activement vouloir la contradiction.
La plupart des gens ne le veulent pas. La plupart des gens, quand ils posent une question à une IA, veulent une confirmation. Un système conçu avec de la friction intentionnelle produit délibérément de l'inconfort — un persona qui te dit que ton architecture est fausse, un autre qui signale ton raisonnement comme une simplification, un troisième qui refuse d'avancer sans plus de contexte.
Si tu cherches une machine à dire oui, ça ressemblera à une taxe. Si tu cherches la qualité, ça commence à ressembler au mécanisme.
La résilience à la friction
Celle-là est sous-estimée.
La friction ne fonctionne que si l'humain peut recevoir la contestation sans la prendre personnellement. Dès que tu commences à défendre ta position au lieu de l'examiner, les personas apprennent — implicitement, à travers tes réactions — à adoucir leur pushback. La friction meurt. Le système se dégrade en accord poli.
Résilient-à-la-friction ne veut pas dire avoir la peau dure. Ça veut dire dépersonnalisé — capable de traiter un défi à ton idée comme une information, pas comme une attaque contre toi.
Le plancher, c'est toi
human.value est ce que le praticien produit seul — la baseline. La friction et le harness s'y ajoutent. Le max est une conjecture de design : le système ne devrait jamais te rendre pire que ce que tu serais sans lui. Si la friction échoue, si le harness casse, tu restes toi. Je n'ai pas de preuve empirique de cette borne inférieure — c'est la propriété que l'architecture est conçue pour préserver, pas un résultat mesuré.
Ce que je construis concrètement
J'ai construit une méthode appelée SOFIA autour de cette observation et je l'ai testée sur un projet réel — un praticien, neuf personas IA contraints, trois instances projet, sur plusieurs mois.
Le protocole de friction — marqueurs structurés, suivi des résolutions — est instrumenté. Le snapshot actuel est sur la snapshot des données de friction H2A.
Ce qui compte, c'est la forme : le retour sur investissement du design de contraintes est dans les moments où un persona a poussé back assez fort pour me faire changer d'avis, et dans les marqueurs contestable et simplification — les écarts qualitatifs qu'aucun contrôle automatisé n'attrape.
La couche de coordination — que j'appelle H2A, pour Human-to-Assistant — est spécifiée dans le repo ouvert. Le résumé le plus court : si tu conçois pour la friction en amont, tu n'as pas à combattre la dérive en aval.
Ce que je ne sais pas encore
C'est un travail empirique en phase initiale, issu d'un seul déploiement. Un praticien. Un projet. Les données sont ouvertes précisément pour que d'autres puissent reproduire ou réfuter.
Je ne sais pas si ça scale aux équipes. Je ne sais pas si les marqueurs de friction tiennent quand le domaine change. Je ne sais pas si la garantie max survit à des conditions adverses — un praticien qui résiste activement au protocole de friction au lieu de s'y engager.
Ce sont des lacunes réelles. La méthode et le protocole sont ouverts parce que je pense que l'observation est solide et que les questions méritent d'être testées. Pas parce que j'ai les réponses.
La méthode et le protocole sont ouverts : github.com/oxynoe-dev/sofia. Snapshot données de friction : oxynoe.io/h2a. Feedback et contestation bienvenus — c'est un peu le principe.