Pourquoi le RTFM revient avec les agents IA

J’ai partagé un skill Claude Code à plusieurs contacts il y a quelques semaines. Un skill qui m’avait pris plusieurs heures à affiner : des instructions précises, une logique de délégation calibrée, un workflow d’analyse de repos GitHub que j’utilise chaque semaine. Résultat : silence. Pas d’adoption, pas de retour, pas de question.

Je n’étais pas surpris. J’aurais dû l’être.

Le RTFM n’était pas (vraiment) du mépris

Dans les forums Linux des années 2000, SuSE et Ubuntu en tête, une réponse revenait souvent aux questions basiques : Read The Fucking Manual. La formule a traversé les décennies comme le symbole de la culture geek hostile aux débutants.

C’est une lecture inexacte.

Inspiré de the IT crowd (série TV 2006-2013)

J’ai fréquenté le club Linux de la MJC de Valenciennes. La culture RTFM que j’observais de l’intérieur n’était pas du mépris envers les nouveaux venus. C’était la protection d’un parcours. Les « anciens » savaient que la réponse donnée sur un plateau s’évoporerait. Que le débutant qui avait bataillé deux heures contre son pilote de carte réseau, qui avait lu la doc, qui avait posté sur le forum et compris pourquoi ça ne fonctionnait pas, avait appris quelque chose d’irréductible à la solution elle-même. Le RTFM n’était pas un filtre d’exclusion. C’était un filtre d’investissement. On traitait les demandes d’assistance comme dans le proverbe où il vaut mieux apprendre à pêcher qu’à récupérer un poisson pour le prochain repas.

StackOverflow a changé cette équation. Lancé en 2008, le site a industrialisé la réponse pré-mâchée. La connaissance technique est devenue une commodité. On copie, on colle, on adapte. Ce modèle a fonctionné parce que le code s’exécute indépendamment de celui qui l’a écrit. Un extrait de Python posté par un inconnu en 2016 tourne encore en 2026 si le contexte technique est le même. La plateforme a reconnu en 2018, dans un billet de blog de Jay Hanlon, que ce modèle avait brisé la culture d’accueil ↗ : le RTFM avait muté en hostilité réelle. Mais le principe sous-jacent, lui, tient encore. C’est en tout cas ma conviction.

Avec l’explosion des skills Claude, des custom GPTs et des serveurs MCP (Model Context Protocol), la même tension resurgit.

L’argument du partage, formulé à sa force maximale

Le discours dominant dans les communautés AI (Discord, LinkedIn, X) est clair : partagez vos prompts, open-sourcez vos configurations, faites comme GitHub. L’argument tient en trois points.

1. Le modèle open source a fait ses preuves. Linux, Git, Python. Le partage transparent crée de la valeur collective que la rétention ne crée pas. Eric Raymond l’a formalisé dans son livre fondateur The Cathedral and the Bazaar ↗ : le bazaar (partage ouvert, itération collective) bat la cathédrale (développement fermé, contrôle centralisé). La preuve empirique est écrasante.

2. Le coût marginal du partage tend vers zéro. Copier un fichier .md ou un prompt ne coûte rien. PromptBase a tenté de structurer un marché sur ce principe. Les plateformes de partage de custom GPTs suivent la même logique : si la valeur peut être transmise pour un coût nul, pourquoi la retenir ?

3. L’injonction à la démocratie cognitive. Si les utilisateurs avancés gardent leurs outils pour eux, les inégalités entre utilisateurs basiques et experts s’amplifient. La fracture numérique s’approfondit, a minima par inertie.

Cet argument est honnête. Il mérite mieux que d’être esquivé.

Sauf que le skill n’est pas du code

La faille n’est pas dans la logique du partage. Elle est dans la nature de l’objet partagé.

Le code partagé sur GitHub s’exécute. La valeur est dans l’artefact. Un contributeur qui forke un dépôt obtient immédiatement quelque chose qui fonctionne, qu’il peut tester, modifier, déployer. Le contexte de production du code ne conditionne pas sa valeur d’usage.

Un skill ne fonctionne pas ainsi.

L’état empirique sur le partage de prompts entre utilisateurs avancés distants est mince. Il y a quelques répertoires populaires de skills (Superpowers, Matt Pocock…). Mais les études disponibles mesurent autre chose : la co-construction au sein d’un même petit groupe travaillant sur un corpus commun, la duplication massive de fichiers de configuration sans mesure d’effet, ou la sensibilité interne d’un modèle à des reformulations équivalentes. Aucune ne tranche le cas qui m’intéresse, un utilisateur avancé qui partage un artefact à un autre, dans un autre contexte d’usage. Ce qui suit est donc un argument philosophique appuyé par une expérience de terrain, et non une synthèse empirique.

Ce que la littérature dit néanmoins est instructif. PromptHive (Reza, Anastasopoulos et al., CHI 2025) ↗ observe que dix experts en mathématiques co-construisant des prompts pédagogiques sur un même manuel adaptent significativement 86% des prompts de leurs pairs, contre 14% seulement de réutilisation verbatim. Le résultat est lu d’ordinaire comme une preuve de friction dans la transmission. C’est l’inverse : le partage fonctionne, précisément parce que le contexte est partagé (même domaine, même corpus, même groupe). C’est exactement la condition que je nommerai plus loin régime A (échange entre pairs symétriques). Hors de cette condition, l’étude est muette. Côté open source, Jiang et Nam (MSR 2026) ↗ mesurent 28,7% de lignes dupliquées entre repositories Cursor, mais reconnaissent que leur impact réel sur la performance reste une question ouverte : la circulation des artefacts est massive, leur valeur d’usage n’est pas mesurée.

Un skill bien façonné porte la marque du parcours qui l’a produit, c’est ce qui fait œuvre plutôt que flux. Le skill que j’utilise pour analyser des repos GitHub se constitue par son usage situé : sélection de repos via X et LinkedIn, lecture du README, analyse fonctionnelle et structurelle, génération de fiches Zettelkasten, création d’issues dans les projets. Il fait, en plus, une analyse de nouveautés par rapport à ce que ma documentation dit déjà. Demander à quelqu’un de « donner son skill » revient à nier ce processus de fabrication. Transmettre le skill sans le workflow, c’est prêter un peigne à un chauve.

Transmettre le skill sans le workflow, c’est prêter un peigne à un chauve.

Richard Sennett, dans Ce que sait la main ↗ (The Craftsman, 2008), démonte l’idée que le savoir du craftsman est transmissible par instruction verbale ou documentation. Le « faire » est un mode de connaissance irréductible à sa description. Une étude de Ma, Peng et al. publiée à TOCHI 2025 (ROPE) ↗ le confirme empiriquement dans le contexte AI :

• Sur 30 novices formés en condition contrôlée, enseigner des « tricks » copiables à des utilisateurs de LLM produit un gain de performance de +1%.

• Articuler des exigences contextuelles (requirements) plutôt que des recettes produit +20%. La différence : dans le second cas, le receveur comprend pourquoi, pas seulement comment.

Il y a aussi une asymétrie d’attachement que les autres artefacts ne connaissent pas. Le consultant qui transmet un powerpoint se vit comme passeur, peu impliqué dans l’objet, conscient que son collègue devra le réécrire pour ses contraintes. L’utilisateur avancé qui partage un skill est dans un autre rapport. Il a passé des semaines à monter en compétence, il a affiné, raté, recommencé, le skill condense ce parcours. Le partager en deux lignes a quelque chose de presque dévalorisant, comme si la durée du chemin n’avait pas existé. Le receveur, lui, n’est pas non plus dans le même paradigme. Il pense qu’en récupérant l’artefact il récupère aussi l’âme de la compétence, le raccourci vers le même niveau de maîtrise. D’où l’ambiguïté : on montre sans vraiment vouloir transmettre, parce qu’on sait que la transmission ne passe pas par cet objet. Il y a, dans le partage de skills, plus de réticence que dans l’open innovation classique, pas par calcul économique mais par lucidité sur ce qui se transmet et ce qui ne se transmet pas.

Une objection plus dure mérite d’être traitée. Je détaille plus loin ces trois régimes de partage (échange entre pairs, don ouvert, monétisation par l’audience) ; l’objection est qu’ils ne sont peut-être pas trois modes parallèles, mais trois stades de maturation d’un même artefact. Linux a commencé en don ouvert dysfonctionnel dans les années 90 (RTFM, listes hostiles, fork sauvage), est devenu échange entre pairs hyperqualifiés dans les années 2000, est aujourd’hui aussi monétisation par formation et certification. Le savoir IA ne serait alors pas plus tacite que le savoir Linux d’il y a vingt-cinq ans, juste plus jeune. Dans dix ans, le RTFM IA sera devenu, comme le RTFM Linux, une plaisanterie de « vétéran » (sachant que personne n’utilise RTFM dans le monde de l’IA, parce qu’un prompt « suffit » pour obtenir la réponse).

Cette objection a une part de vrai, et elle est plus forte qu’il n’y paraît. Linux des années 90 partageait aussi un haut degré d’individuation, chaque utilisateur avait sa distrib, ses scripts shell, son .emacs. Ce qui s’est standardisé n’est pas la configuration individuelle, ce sont les conventions de partage du contexte autour : man pages, README, dotfiles repos, awesome-lists. La même cristallisation est en cours pour le craft AI. Le format SKILL.md émerge comme convention partagée, le pattern d’URL skills.sh ↗ référence des collections communautaires, des marketplaces se déploient (claudemarketplaces.com ↗ en agrège plus de quatre mille), le même écosystème qui produit les frameworks concurrents pour structurer le vibe coding. Le craft AI ne sera donc pas éternellement intransmissible ; simplement, aujourd’hui les conventions sont immatures, et la confusion entre partager un artefact et partager le contexte de production fait croire à un transfert qui n’a pas lieu. Plus encore : depuis l’arrivée des modèles thinking, l’enjeu se déplace. Reformuler une intention en prompt, c’est précisément ce que les modèles ont appris à faire, et ils le font de mieux en mieux. L’expertise migre vers ce qui ne peut pas être absorbé par le modèle, l’architecture de solution, le contexte injecté, le harnais autour. Quand le sage montre le contexte, le fou copie le prompt. Et même le sage sait que montrer ne suffit pas.

Quand le sage montre le contexte, le fou copie le prompt.

N.B. : une autre réserve, plus prosaïque, dissuade d’importer un skill sans le lire (ce vecteur sert aussi à contaminer la machine du candide qui télécharge sans analyser, et les occurrences sont assez fréquentes pour procéder avec précaution).

Trois régimes, trois efficacités

Ce n’est pas que le partage est impossible. C’est qu’il fonctionne dans des conditions précises, que la rhétorique de l’open source tend à ignorer.

1. L’échange entre pairs (régime A) fonctionne. Quand je discute de mes configurations Claude Code avec mes contacts de niveau technique comparable, la valeur circule parce que nous partageons le même contexte de référence, les mêmes problèmes, approximativement les mêmes workflows. L’échange n’est pas une transmission verticale de sachant à ignorant. C’est une calibration mutuelle entre pairs qui peuvent réactiver la valeur de l’artefact reçu. La condition nécessaire : symétrie de contexte.

2. Le don ouvert (régime B) dysfonctionne presque toujours pour ce type de savoir. C’est ce qu’illustre l’échec relatif de PromptBase et des bibliothèques de prompts « miracles » : le coût marginal de transmission est nul, mais la valeur d’usage s’approche aussi de zéro pour le receveur qui n’a pas fait le parcours. Pourtant les posts LinkedIn qu’il faut commenter par « Prompt » ou « Claude », pour obtenir le cadeau magique perdurent aussi parce que les utilisateurs n’ont pas encore conscience du nécessaire investissement pour progresser et que ce commentaire leur coûte peu contre l’espoir de découvrir un outil supplémentaire.

3. La monétisation par l’audience (régime C) est le seul modèle qui rend le don ouvert économiquement rationnel, mais ce n’est pas du partage de savoir : c’est de la production de contenu pédagogique. Cole Medin, Nate Herk, Greg Isenberg ne partagent pas leur craft. Ils construisent une audience en produisant du contenu sur leur réalisation. La différence est importante. La leçon de Nate Herk intitulée « Master 95% of Claude Code Skills in 28 Minutes ↗ » est un bon exemple du régime C qui se prend pour le régime A. Elle promesse la maîtrise sans le parcours. C’est du contenu utile, pas du transfert de craft.

Je dois nommer ma propre position dans ce tableau. Ma réticence à publier mes skills est partiellement du perfectionnisme (pas envie d’afficher le bazar présent dans ma tête ;-)) et partiellement une illusion d’avantage concurrentiel qui ne tient pas longtemps à l’analyse. Ce sont des freins individuels, pas des arguments structurels. Je les assume sans en faire une vertu. Néanmoins l’explicitation de mon framework de développement m’autorise à m’inscrire dans le régime B, il me semble.

Ce que la spirale SECI révèle

Nonaka et Takeuchi ne se contentent pas d’opposer tacite et explicite. Leur modèle SECI découpe la transmission en quatre mouvements, chacun changeant l’échelle du savoir : socialisation (individu à individu), externalisation (individu à groupe), combinaison (groupe à organisation), internalisation (organisation à individu). Vus à travers cette grille, mes trois régimes ne sont pas équivalents, ils occupent des cases très différentes de la spirale.

L’échange entre pairs (régime A) est de la socialisation à l’état pur : tacite à tacite, sans qu’un mot ait besoin d’être écrit. C’est pour ça qu’il fonctionne, le modèle SECI le prédit.

Le don ouvert (régime B) se présente comme de l’externalisation (le tacite articulé en artefact explicite), mais c’est précisément le mouvement que Nonaka et Takeuchi qualifient de plus difficile de toute la spirale. Un skill posté sans son contexte de production n’a fait que la moitié du chemin : l’artefact est explicite, mais le travail d’articulation qui devrait l’accompagner (pourquoi cette architecture, quelles erreurs elle corrige) n’a pas eu lieu. Le don ouvert produit des objets qui ressemblent à de l’externalisation réussie sans en avoir fait le travail.

La monétisation par l’audience (régime C) n’est ni l’un ni l’autre. C’est de la combinaison : du contenu explicite recombiné en contenu explicite, une leçon vidéo qui réorganise des connaissances déjà écrites ailleurs. Rien de nouveau n’est créé, tout est mis en forme différemment. Ça a de la valeur (la mise en forme est un travail réel), mais ce n’est pas du transfert de craft.

Le quadrant qui manque à ma typologie est l’internalisation : l’explicite qui s’incorpore en tacite par la pratique répétée. C’est exactement ce qui fait défaut au receveur d’un don ouvert. Il a l’artefact (l’explicite), mais pas la répétition qui le transformerait en réflexe. Le RTFM, en repoussant la réponse immédiate, forçait ce passage.

Vers des communs de pratique

La conclusion n’est pas que le partage est vain. C’est que l’unité pertinente n’est pas l’information mais la compétence incarnée.

Wikipedia fonctionne parce que l’unité de valeur est le fait vérifiable, agrégeable, consultable hors contexte. Un commun du savoir IA opérationnel ne peut pas fonctionner sur ce modèle. Les bases de prompts sont des inventaires de savoirs inertes tant qu’elles ne s’accompagnent pas du contexte qui les active.

Étienne Wenger, dans Communities of Practice ↗ (1998), distingue les communs de ressource (partager un objet) des communs de pratique (partager une pratique). La MJC de Valenciennes était un commun de pratique : les « anciens » ne donnaient pas des solutions, ils apprentissaient par l’exemple, le côte à côte, la correction en situation. Le RTFM, paradoxalement, était un garde-fou pour maintenir ce régime plutôt que de glisser vers le don de solutions.

Ce modèle a une traduction concrète dans le contexte d’utilisation massive des LLM. Ce n’est pas le skill qu’il faut partager, c’est le contexte de production du skill : les décisions d’architecture, les erreurs de parcours, les renoncements. Le skill sans son journal de bord est un objet sans mode d’emploi (le mien est public ↗, pour ce que ça vaut). La valeur est dans le journal de bord, c’est le même mécanisme qui explique pourquoi la reddition cognitive guette celui qui reçoit la réponse sans le parcours. On comprend mieux pourquoi le « clic droit, envoyer vers » n’est pas la bonne approche.

En formation, j’en vois les conséquences pratiques. Enseigner le craft IA ne peut pas se faire par transmission de prompts. Ça exige de recréer des espaces de socialisation du savoir tacite : apprendre par la socialisation (faire ensemble), pas par l’externalisation brute (partager un .md). C’est la même distinction que celle entre regarder une veille et construire une compétence : le contexte de production ne s’observe pas, il se pratique.

Ce que j’en retiens

Le RTFM n’est pas mort, il s’est déplacé.

La résistance au partage de skills AI n’est pas de l’égoïsme ni du corporatisme. C’est l’intuition correcte que transmettre un artefact sans le contexte qui le rend opérationnel ne sert pas le receveur. Le savoir inerte ne se transforme pas en savoir actif par le seul fait de changer de main.

La question à poser n’est pas « dois-je partager mon skill ? » mais « dans quel régime ce partage s’inscrit-il, et quelles conditions le rendent utile ? ». Si ces conditions ne sont pas réunies, le refus de partager n’est pas de la rétention mais de la lucidité.

P.S. : Merci à Anthony R. pour m’avoir inspiré ce sujet, n’arrivant pas moi-même les mots sur la résistance psychologique qui existait à transmettre un skill, un artefact par un simple « clic droit, envoyer vers… ».