SOFIA est une méthode pour travailler avec des personas IA spécialisées, en friction intentionnelle, pilotées par un humain qui arbitre.
OPEN SOURCE · MITSommaire
Ce livre est né d'un constat et d'un agacement. C'est une synthèse d'opinion de praticien, assumée, référencée — pas un livre blanc : un livre bleu.
Le constat : l'IA générative change le terrain. Pas un peu — en profondeur. Ceux qui l'ignorent perdront du temps. Ceux qui lui font aveuglément confiance en perdront davantage.
L'agacement : le problème des LLMs est structurel[1] — un système qui prédit le token suivant n'a pas de modèle du monde, il a une distribution de probabilités — et le discours dominant refuse de le regarder en face. Ce discours ne propose que deux postures. Remplacer les gens, ou freiner des quatre fers. Comme s'il n'y avait rien entre l'automatisation totale et le refus.
Il y a autre chose. Une troisième voie, construite sur le terrain, pas dans un pitch deck. Elle repose sur une intuition simple : la friction — entre l'humain et la machine, et entre les machines elles-mêmes — n'est pas un problème à résoudre. C'est le mécanisme qui produit la valeur.
Ce que je décris ici n'est pas une théorie. C'est une méthode testée — sur un vrai projet, avec de vraies contraintes, par quelqu'un qui travaille seul avec des moyens limités. Les résultats sont là. Les limites aussi. Les deux sont documentés.
Ce document est soumis à la méthode qu'il décrit. Il a été produit avec friction, challengé par des rôles contraints, et ses limites sont documentées ici, pas cachées. La critique est la bienvenue — c'est le mécanisme. Le repo est ouvert : github.com/oxynoe-dev/sofia
Cette méthode a été construite empiriquement — un projet, un praticien, 210+ sessions. Ce n'est pas une étude contrôlée ni un protocole validé à grande échelle. C'est une pratique documentée, sujette à l'erreur et à l'approximation. Ce qu'elle affirme, elle peut le démontrer sur son terrain. Au-delà, tout reste à prouver.
Si tu cherches une promesse de productivité magique, ce n'est pas le bon livre. Si tu cherches une méthode honnête pour aller plus loin sans perdre le contrôle, tu es au bon endroit.
Fragment I
Le problème
Un LLM seul dit oui. Toujours.
Il code, il conseille, il rédige — dans la même conversation, avec le même ton, sans contrainte. Il ne challenge rien. Pose-lui une question mal cadrée, il produira une réponse bien formulée. Donne-lui une direction bancale, il l'exécutera avec enthousiasme. Ce n'est pas de la collaboration. C'est de l'exécution servile.
Et pourtant, c'est exactement ce que le marché pousse. Plus d'automatisation. Moins d'humains dans la boucle. Des agents qui font le travail, des gens qui supervisent. Le pitch est simple, le rêve est propre, les démos sont impressionnantes.
Le problème est dans l'arithmétique que personne ne veut regarder.
10 étapes en série — fiabilité 90% par étape
Fiabilité cumulée = 35%
Un agent fiable à 90% sur une étape — c'est bon. Dix étapes en série, le taux d'erreur global monte à ~65% (1 − 0.9¹⁰ ≈ 0.65). L'erreur de l'étape 2 arrive à l'étape 3 comme une prémisse valide. L'étape 3 construit dessus. La cascade est silencieuse. Le résultat final a l'air correct. Il ne l'est pas. Ce calcul suppose des erreurs indépendantes — en pratique, la corrélation entre étapes peut aggraver le résultat.
Salesforce l'a constaté en production : au-delà d'une poignée de directives, les LLMs commencent à en ignorer certaines — le CTO d'Agentforce évoquait un seuil empirique autour de huit[12]. Cemri et al. (2025) ont analysé 1642 traces d'exécution sur 7 frameworks multi-agents : 14 modes de défaillance identifiés, répartis en problèmes de conception (41.8%), désalignement inter-agents (36.9%) et vérification des tâches (21.3%)[13]. Notre intuition est que le multi-agent sans gouvernance aggrave la fiabilité plutôt qu'il ne l'améliore.
Et la nature du mécanisme est structurelle[1]. Un système qui prédit le token suivant le plus probable n'a pas de notion de vérité. Il a une notion de vraisemblance. Ce n'est pas un bug à corriger dans la prochaine version — c'est le fonctionnement même de la technologie. Construire de l'automatisation massive sur cette base, c'est empiler de l'incertitude sur de l'incertitude.
Ce que les démos
ne montrent pas
Les démos montrent des prompts magiques qui produisent du code en 30 secondes. Ce qu'elles ne montrent pas : les années de contexte dans la tête de celui qui prompte. Le prompt n'est que la surface. La profondeur, c'est tout ce qui vient avant.
L'IA amplifie. Elle n'invente pas.
Si on lui donne du vide, elle produit du vide bien formulé. Si on lui donne des années de conviction sur un problème réel, elle construit avec. C'est un miroir — il renvoie ce qu'on lui présente. Bon cadre, bonne direction, vraie question : enrichissement. Cadre flou, direction molle, question mal posée : confusion convaincante. Et la confusion convaincante est plus dangereuse qu'un résultat clairement raté — parce qu'on ne la voit pas.
C'est ça, la condition cachée de la valeur. Le profil qui tire le mieux parti de l'IA n'est pas celui qui code plus vite. C'est le praticien qui comprend déjà son domaine — qui sait quelles questions poser, et qui utilise l'IA pour tenir la complexité à un niveau de détail qu'il n'atteignait pas seul. Un architecte logiciel avec dix ans de terrain. Un médecin qui connaît ses cas limites. Un juriste qui sait où le texte craque. L'expertise domaine est le prérequis — peu importe la durée, c'est la profondeur qui compte.
Je le constate sur mon propre terrain : 18 ans de réflexion sur un problème précis — l'IA ne part pas de zéro avec moi. Elle part de là où je suis.
Ce n'est pas "l'IA fait le travail à ma place". C'est "l'IA me permet de travailler à un niveau que je n'atteignais pas seul."
Différence qualitative, pas quantitative.
Fragment II
La thèse
Il est possible d'aller plus vite et mieux à ressources humaines constantes — pas à coût total constant, le transfert de charge vers l'infrastructure est réel (voir §V).
Pas moins de gens. Les mêmes gens, augmentés. Pas remplacés — amplifiés. Un architecte qui tient trois niveaux de complexité en parallèle parce que l'IA l'aide à ne rien lâcher. Un développeur qui explore quatre approches en une heure au lieu d'une seule. Un stratège qui teste ses hypothèses contre des contradicteurs structurés avant de les présenter.
De la croissance à taux d'emploi constant. Shneiderman le pose : haute automatisation et haut contrôle humain coexistent — c'est une question de design, pas un compromis[22].
C'est moins vendable. Ça ne fait pas de démo spectaculaire. Ça ne promet pas de diviser les coûts par dix. Mais c'est soutenable. Parce que l'humain reste dans la boucle. Parce que quand ça casse, quelqu'un comprend pourquoi. Parce que la compétence se maintient au lieu de s'éroder[5].
La friction est le mécanisme de valeur, pas un obstacle à éliminer. La friction intentionnelle et l'isolation des rôles ne sont pas un luxe méthodologique. C'est la condition de la valeur[23]. La Rosa et Beretta formalisent ce principe dans le cadre des systèmes cognitifs conjoints : la friction doit être conçue comme un élément de design scalable, adapté au rôle fonctionnel et au degré de contrôle de chaque acteur du système[28].
Sur le marché, tout le monde cherche à réduire la friction avec l'IA. Moins de prompts, plus d'autonomie, des agents qui font tout seuls. Mon approche est inverse : je génère de la friction pour faire progresser le produit. Des personas IA spécialisées. Chacune avec un périmètre, des contraintes, une posture, et un devoir de contester les autres. L'architecte dit "pas maintenant". La chercheuse dit "ta référence ne tient pas". Le stratège dit "personne ne paiera pour ça". Si tous les personas sont d'accord, ils ne servent à rien.
L'humain n'est pas retiré de la boucle — il est le seul à pouvoir résoudre ce que les agents ne résolvent pas entre eux.
Le terrain confirme déjà la théorie.
Klarna — 2024. Le CEO annonce qu'un chatbot IA remplace le travail de 700 agents de support. La presse applaudit. Un an plus tard, il admet que la qualité s'est effondrée — réponses robotiques, clients bloqués dans des boucles. Klarna relance l'embauche d'humains[9].
Même schéma chez IBM[10] et McDonald's[11]. Un signal faible, pas un pattern prouvé — mais un signal qui se répète.
Le schéma quand il apparaît : l'IA peut faire le travail → réduction des effectifs → les cas limites s'accumulent → rappel des gens. Selon Forrester (2026), cabinet d'analyse, 55% des entreprises qui ont licencié pour des raisons liées à l'IA regrettent leur décision[7]. Un tiers d'entre elles auraient réembauché entre 25% et 50% des postes supprimés[8] — chiffres à prendre avec recul, les deux sources sont commerciales.
Bainbridge avait prévu ce cycle il y a quarante ans[2]. La seule différence avec les LLMs : la vitesse. Ce qui prenait une décennie avec l'externalisation se joue en quelques mois.