Savoir vs savoir-faire : la distinction qui tue silencieusement vos agents IA

Si 95 % des pilotes IA en entreprise échouent, ce n’est pas un problème de modèle. C’est une erreur de catégorie.

L’écart que personne ne nomme.

La plupart des conversations sur l’IA en entreprise tournent autour d’un seul mot : le savoir. On parle de bases de connaissances, de graphes de connaissances, de récupération, de RAG, de fine-tuning sur données propriétaires. L’hypothèse implicite : si un agent IA sait assez de choses sur votre métier, il fera la bonne chose.

Faux. Et la raison tient à une distinction que les philosophes posent depuis des décennies, mais que l’industrie de l’IA continue d’ignorer.

Il existe deux façons de savoir :

• Le savoir-que : la connaissance propositionnelle. Des faits, des politiques, de la documentation, des données. Paris est la capitale de la France. Notre politique de remboursement autorise les retours sous 30 jours. La facture n° 4521 est en retard.
• Le savoir-faire : la connaissance procédurale. La capacité à exécuter correctement une tâche en contexte. Faire du vélo. Conclure une vente. Traiter cette facture en retard comme cette entreprise précise attend qu’on la traite.

Gilbert Ryle a posé cette distinction comme l’opposition entre knowing that (la connaissance propositionnelle) et knowing how (la connaissance procédurale). Michael Polanyi désignait la seconde par « connaissance tacite » : ce qu’un expert sait sans pouvoir l’écrire entièrement. Peu importe le nom. Le point est le suivant : connaître les faits d’un métier n’est pas la même chose que savoir l’exercer.

Et aujourd’hui, la plupart des investissements IA en entreprise achètent le premier en espérant le second.

Pourquoi cela compte spécifiquement pour les agents.

Pour les chatbots, l’écart entre savoir et savoir-faire restait tolérable. Un chatbot qui connaît vos politiques sans savoir les appliquer reste utile : un humain lit la réponse et décide quoi faire.

Les agents changent l’équation. Un agent ne répond plus à des questions, il passe à l’action. Il envoie l’e-mail, met à jour le CRM, valide la note de frais, ouvre le ticket. L’écart entre savoir et faire cesse d’être philosophique : il devient opérationnel. Un agent riche en savoir mais pauvre en savoir-faire, c’est un collaborateur sûr de lui qui a lu le manuel sans jamais avoir fait le job. Ce n’est pas un actif. C’est une responsabilité avec un accès API.

C’est, empiriquement, ce qui se passe. L’étude MIT NANDA 2025 montre que 95 % des pilotes IA en entreprise n’ont aucun impact P&L mesurable. S&P Global rapporte que 42 % des entreprises ont abandonné la plupart de leurs initiatives IA en 2025, contre 17 % l’année précédente. L’explication standard, c’est « le contexte ». Mais « contexte » est un mot vague qui masque le vrai sujet. Le contexte manquant, ce n’est pas davantage de documents à récupérer. C’est le savoir-faire procédural, tacite et institutionnel qui dit à un agent comment cette entreprise exécute réellement cette tâche.

À quoi ressemble le savoir-faire en pratique.

Prenons un exemple concret. Un chef de projet prépare son brief hebdomadaire au comité de direction. Les documents existent. Un LLM peut les lire. Un système basé sur le savoir peut les récupérer à la demande.

Mais le travail réel exige un savoir-faire que les documents ne contiennent pas :

• Ce qui compte comme « décision clé » pour ce comité (pas la définition du manuel)
• Qui a le pouvoir de signature sur quoi, et les exceptions non écrites
• Comment formuler une alerte risque pour que le directeur financier la prenne au sérieux sans déclencher un branle-bas de combat
• Quels interlocuteurs reçoivent un pré-brief avant la réunion, et lesquels reçoivent la synthèse après
• Les conventions de format qui se sont décantées sur dix-huit mois de retours

Rien de tout cela n’est dans un document. C’est dans la tête du chef de projet. C’est dans le motif des briefs passés. C’est dans le ton du fil Slack du trimestre dernier. C’est la façon dont le travail se fait réellement ici, et c’est précisément la couche à laquelle les agents IA génériques, quelle que soit la puissance du modèle sous-jacent, ne peuvent pas accéder.

L’erreur de catégorie que commettent les dirigeants.

Quand les initiatives IA s’enlisent, le réflexe est en général d’acheter plus de la même catégorie. Plus de documents indexés. Une meilleure récupération. Un modèle plus gros. Un pipeline RAG plus sophistiqué. Parfois, du fine-tuning entre 10 000 et 35 000 dollars par modèle, plus des data scientists sur un marché du talent tendu.

Rationnel si le problème est le savoir. Mauvaise prescription si le problème est le savoir-faire.

Le savoir-faire ne vit pas dans les documents. Il vit dans les procédures, les contraintes, les exceptions, les arbitrages et les conventions propres à chaque rôle. Et il ne se généralise pas : la façon dont votre équipe conformité gère une exception n’est pas la façon dont votre équipe sales ops gère une exception, même au sein de la même entreprise. Empaqueter du savoir-faire, c’est encoder non seulement quoi faire, mais comment cette équipe, dans ce rôle, sous ces contraintes, veut que ce soit fait.

C’est un autre type d’actif qu’une base de connaissances. Il doit être :

• Procédural : décrire une séquence et ses exceptions, pas seulement des faits
• Lié au rôle : rattaché à qui fait le travail, pas seulement à ce qui est fait
• Composable : pour qu’un même savoir-faire soit réutilisé entre agents et contextes
• Auditable : pour que, lorsque l’agent agit, on puisse remonter du raisonnement jusqu’à l’instruction

Pourquoi c’est le point de départ de skilder.

Nous ne pensons pas que la stack IA actuelle soit cassée. Nous pensons qu’elle est incomplète. Les modèles sont devenus extraordinairement capables. Les standards d’appel d’outils comme MCP ont rendu la connectivité tractable. Ce qui manque, c’est la couche entre les deux : celle qui transforme une capacité générique en la manière dont cette entreprise travaille.

C’est ce que nous construisons. Nous empaquetons le savoir-faire dans ce que nous appelons des casquettes : des bundles par rôle qui capturent comment un poste précis s’exécute dans une organisation précise. Un agent enfile une casquette comme un nouvel arrivant prend ses fonctions : il hérite des procédures, des contraintes, des exceptions et des arbitrages qui définissent le travail compétent à ce poste. Un agent peut porter plusieurs casquettes et passer d’un contexte à l’autre. Une casquette peut être portée par plusieurs agents, pour que le savoir-faire se cumule au lieu de se fragmenter. Et comme les casquettes sont découplées de tout modèle particulier, le même savoir-faire fonctionne sur Claude, GPT, Gemini, ou ceux qui suivront.

Le basculement, vu d’avion, est le suivant : les entreprises ont passé trois ans à acheter du savoir pour leur IA. Elles passeront les trois prochaines à lui apprendre à travailler.

À retenir.

Si vos pilotes IA s’enlisent, la bonne question de diagnostic n’est pas « notre agent a-t-il accès à assez d’informations ? ». C’est « notre agent sait-il comment nous faisons réellement ce travail ? ».

Le savoir vous donne un stagiaire bien lu. Le savoir-faire vous donne un collaborateur formé. La différence, en production, est celle qui sépare une démo d’un déploiement.