Quand une expertise devient un objet transmissible, modifiable et déployable à la demande, les cadres classiques de la propriété intellectuelle, de la gestion des talents et de la gouvernance IT se trouvent bousculés. DSI et DRH peinent encore à mesurer ce que ce changement de nature implique. La gouvernance de ces artefacts s’impose pourtant comme une priorité opérationnelle et juridique.
Les fichiers de compétences (skill.md, souvent en Markdown, parfois en JSON ou YAML) est un document texte qui encode, sous forme d’instructions lisibles par un modèle de langage, un ensemble de règles, de méthodes, de contraintes et de comportements attendus dans un contexte professionnel défini. Il est injecté dans le contexte système d’un agent IA avant toute interaction, et gouverne ainsi la manière dont l’agent traite les requêtes, formule ses réponses et prend ses décisions. Inventé par Anthropic, ce concept de thésaurus des compétences est plus ancien.Le principe d’injecter des instructions dans le contexte système d’un modèle de langage est antérieur à l’invention d’Anthropic. OpenAI l’a formalisé dès InstructGPT en 2022 sous la forme du prompt système. Les frameworks d’agents comme LangChain, AutoGPT ou CrewAI ont tous leur propre version de fichiers de configuration comportementale. Ces instructions, qui encodent un savoir-faire professionnel pour le rendre exécutable par un agent IA, s’imposent aujourd’hui dans les déploiements d’IA générative en entreprise. En quelques centaines de lignes, le fichier peut concentrer ce qu’un professionnel a mis des années à construire. Il peut être copié, modifié, transmis à n’importe quelle instance d’un système IA sans contrainte logistique. Ce qui était incorporé devient portable. Ce qui était personnel devient organisationnel. Ce qui était diffus devient exécutable. Ce qui était implicite est explicitement exprimé et formalisé.
De la compétence à l’artefact : ce que la formalisation transforme
« Nous pouvons savoir plus que nous ne pouvons dire », écrivait Michael Polanyi, philosophe des sciences, en 1966. Cette formule fonde le paradoxe fondamental du management de la connaissance à l’ère de l’IA : toute compétence professionnelle avancée repose sur une couche de jugement implicite, la capacité à distinguer quand appliquer la règle, quand l’adapter, quand y déroger. Cette couche de connaissance implicite, de savoir non exprimé, n’est pas verbalisable en totalité. Elle s’acquiert par l’expérience, par l’erreur, par l’exposition répétée à des cas limites, en somme, par l’expérience.
Le fichier skill capture la règle. Il ne capture pas le jugement qui sait quand y contrevenir. C’est là sa limite constitutive. Paradoxalement, cette même limite produit sa valeur pratique. En couvrant la grande majorité des cas traités par la règle explicite, il libère l’expert pour les situations qui exigent un arbitrage. Mais cette limite produit également un risque bien documenté par les sciences de gestion : l’illusion de complétude. L’organisation qui croit avoir capturé une compétence dans un fichier a produit une approximation opérationnelle, utile, mais partielle. La confusion entre les deux peut conduire à des décisions de recrutement prématurées ou à une dépendance technique mal calibrée.
La formalisation transforme en outre la nature de la relation entre l’expert et son savoir. Tant que la compétence reste tacite, elle est indissociable de son porteur. Une fois formalisée, elle existe de manière autonome. Ce découplage est précisément ce qui intéresse les entreprises, et ce qui préoccupe, légitimement, les professionnels dont le capital de compétences est ainsi extrait.
Un objet qui s’exécute, pas un document qui s’archive
La différence décisive entre un fichier skill et une procédure interne classique tient à sa nature exécutoire. Une procédure documentaire décrit ce qu’il faut faire et attend d’être lue. Un fichier skill injecté dans le contexte d’un agent IA produit directement un comportement. Cette distinction a des conséquences immédiates pour les DSI et les CTO.
Une modification apportée à un fichier skill change le comportement de l’agent à l’instant T, pour tous les utilisateurs qui y sont rattachés, sans délai de formation ni période de transition. Un ajout d’une ligne peut élargir le périmètre d’action de l’agent. Une suppression peut en retirer une contrainte de conformité. Une reformulation ambiguë peut introduire un comportement indésirable à grande échelle avant que quiconque ne s’en aperçoive.
Les entreprises qui déploient des agents IA en production sans traçabilité de leurs fichiers skill prennent un risque comparable à celui d’un déploiement de code sans gestion de version. La différence est que le code est généralement perçu comme un actif technique soumis à gouvernance. Le fichier skill, rédigé en langage naturel, ressemble à une note interne, et échappe, pour l’instant, aux processus de contrôle qui s’appliqueraient à un artefact technique de même criticité.
La question de propriété que personne ne pose encore
Qui est l’auteur d’un fichier skill ? Dans la plupart des organisations qui ont commencé à en produire, la réponse est empirique : celui qui l’a rédigé est souvent un expert métier ayant travaillé avec un outil d’IA sur ses propres cas d’usage. Qui en est propriétaire ? La question n’est presque jamais posée, et les réponses varient selon les juridictions et les contrats de travail.
En droit français, la propriété intellectuelle des œuvres créées dans le cadre d’un contrat de travail est transférée par défaut à l’employeur pour les logiciels. Les œuvres de l’esprit restent la propriété de l’auteur, sauf clause contraire et explicite. Un fichier skill occupe un no-mans-land juridique, car sa structure est fonctionnelle, proche du code, son contenu est rédactionnel, proche d’une méthodologie de conseil. Les contrats de travail actuels ne prévoient pas ce cas.
La question devient plus aiguë au moment du départ d’un collaborateur. Si un expert quitte l’entreprise en emportant le fichier skill qu’il a construit, l’organisation conserve éventuellement une copie, mais perd le contexte d’interprétation. L’inverse est tout aussi problématique. Le collaborateur qui a formalisé sa méthode dans un fichier skill au service de son employeur cède son capital intellectuel sans compensation contractuelle explicite. Ces tensions commencent à émerger dans les premières discussions de départ impliquant des professionnels fortement engagés dans des déploiements d’IA générative.
Gouverner les fichiers skill comme on gouverne le code
La gouvernance des fichiers skill dans les organisations est, pour l’instant, embryonnaire. Quelques grands comptes ont commencé à appliquer des pratiques issues du développement logiciel : gestion de version, revue avant validation, documentation des modifications, restriction des droits d’écriture. Ces pratiques restent l’exception.
Pour les DSI qui définissent leur stratégie d’IA générative pour 2026, les fichiers skill méritent d’être traités comme une couche à part entière du stack de gouvernance IA, au même titre que les politiques de gestion des données, les règles d’accès aux modèles ou les processus de validation des sorties. Cela implique de tenir un registre des fichiers skill actifs, d’associer à chaque fichier un propriétaire métier identifié, de soumettre toute modification à une validation formelle, et de maintenir un historique d’audit permettant de corréler un changement de comportement de l’agent à une modification précise du fichier.
L’enjeu de sécurité est réel. Un fichier skill exfiltré par un acteur malveillant ou un prestataire sortant livre non seulement une méthode opératoire, mais les règles précises qui gouvernent le comportement d’un système en production, y compris ses limites et ses exceptions. Dans des contextes sensibles tels que la réponse à incident, l’analyse de risques ou la qualification de conformité réglementaire, cette information a une valeur stratégique qui justifie un niveau de protection équivalent à celui appliqué aux données critiques.
Le fichier skill est une invention récente, mais il touche à une question ancienne : à qui appartient ce qu’on sait faire, et que se passe-t-il quand ce savoir change de forme ? L’organisation qui ne s’est pas encore dotée d’une politique formalisée sur la création, la validation, la protection et la transmission de ses fichiers de compétences IA n’a pas seulement un problème de gouvernance technique. Elle a un problème de gouvernance tout court, celui d’une organisation qui laisse ses standards opérationnels se définir sans auteur identifié, sans version contrôlée, et sans décision approuvée.
