Comment apprendre à un agent IA la manière de travailler de votre entreprise ?

Le RAG répond à « que faut-il savoir ? »

Un système de recherche documentaire fournit au modèle les informations pertinentes à une question. C’est indispensable et ce n’est pas suffisant : dès que la demande devient « traite ce dossier » plutôt que « quelle est notre procédure », la connaissance ne suffit plus, il faut une méthode.

La différence se voit sur deux formulations presque identiques. « Quelle est notre procédure pour traiter cette demande ? » appelle une recherche, une lecture, une réponse. « Traite cette demande » suppose de savoir où chercher, quelles informations vérifier, quel outil appeler, quelles règles appliquer, quel format produire, quand s’arrêter, et quand solliciter un humain.

On passe de la connaissance à la compétence opérationnelle. Le premier problème relève du Context Engineering et de la sélection de ce que le modèle voit. Le second relève d’autre chose, qui n’est pas encore vraiment outillé dans la plupart des entreprises.

Le savoir-faire ne se trouve pas toujours dans les documents

Imaginez un analyste expérimenté à qui l’on confie un dossier. Il ne commence pas par relire toute la documentation de l’entreprise. Il possède une méthode : pour ce type de dossier, vérifier d’abord A ; si A présente telle anomalie, contrôler B ; comparer ensuite C avec D ; ne jamais conclure sans E ; produire le résultat dans un format précis.

Une partie de cette méthode est documentée. Une autre n’existe que dans l’expérience de quelques personnes, et c’est précisément celle qui fait la différence entre un dossier bien traité et un dossier techniquement correct.

Donner à un agent l’accès aux documents lui donne la bibliothèque. Cela ne lui donne pas le métier.

Trois couches à distinguer

Les deux premières couches sont bien outillées : un moteur documentaire d’un côté, un protocole de connexion aux outils de l’autre, comme nous le détaillons dans le protocole par lequel l’agent atteint les outils de l’entreprise. La troisième reste souvent implicite, dispersée entre un prompt système trop long et la mémoire des équipes.

Comment récupère-t-on un savoir que personne n’a écrit ?

On ne le récupère pas en demandant aux experts de le rédiger. On le récupère en les regardant travailler sur des cas réels, et surtout sur les cas qui se sont mal passés.

La demande « documentez votre méthode » produit presque toujours le même résultat : une procédure idéale, propre, que personne ne suit exactement, et dont les exceptions ont disparu. Or ce sont précisément les exceptions qui font la valeur du savoir-faire.

Trois matériaux donnent de bien meilleurs résultats. Les dossiers litigieux, d’abord, parce qu’ils ont obligé quelqu’un à écrire le raisonnement qui avait manqué. Les échanges de validation ensuite, où l’on voit un expert expliquer à un collègue pourquoi tel élément change la décision. Les cas refusés enfin, qui disent ce qu’il ne faut pas faire, information que les procédures ne contiennent presque jamais.

Le travail consiste ensuite à passer de ces matériaux à des règles formulées, ce qui demande un aller-retour avec les experts. C’est un travail d’analyse métier, pas un travail d’IA, et c’est la raison pour laquelle il est si souvent repoussé.

Transformer une procédure en compétence exécutable

Prenons une procédure de contrôle fournisseur, trente pages dans son format métier. La transformer en compétence pour un agent ne consiste pas à verser ces trente pages dans son prompt. Il s’agit de formaliser huit éléments, et huit seulement.

La dernière ligne fait le lien avec la question de l’autonomie. Les actions interdites d’une compétence sont exactement la matière de la matrice décrite dans les actions qu’une compétence doit explicitement s’interdire.

Pourquoi ne pas tout mettre dans le prompt système ?

Parce qu’un agent d’entreprise peut avoir à maîtriser des dizaines, parfois des centaines de procédures. Tout charger en permanence coûte du contexte, coûte de l’argent, et met en concurrence des instructions qui ne concernent pas la tâche en cours.

S’y ajoute un effet moins visible et plus coûteux à long terme : les règles deviennent impossibles à maintenir. Personne ne saura plus quelle phrase, dans un prompt de six mille mots, produit tel comportement, ni laquelle on peut retirer sans casser autre chose.

L’approche modulaire consiste à n’activer que les capacités pertinentes au moment où elles servent. C’est la continuité logique du Context Engineering, avec un élargissement : la question n’est plus seulement quelles informations donner au modèle, mais quelles instructions, quels outils et quelles méthodes activer pour la tâche du moment. Anthropic décrit ce mécanisme sous le nom de progressive disclosure : l’agent découvre le contexte pertinent au fil de son exploration plutôt que de tout recevoir d’emblée.

Cette activation à la demande soulève à son tour la question de ce que l’agent conserve d’une session à l’autre, que nous traitons dans ce qu’un agent a le droit de retenir, et pour combien de temps.

Le risque : figer une mauvaise pratique

Formaliser un savoir-faire lui donne une autorité qu’il n’avait pas forcément. Tant qu’une méthode vit dans la tête de quelques personnes, elle s’ajuste en permanence, parfois sans que personne s’en aperçoive. Une fois écrite et exécutée par un agent, elle s’applique à l’identique des milliers de fois.

Cela vaut pour les bonnes pratiques et tout autant pour les mauvaises. Une habitude prise pour contourner une limite d’un ancien logiciel, une vérification devenue inutile, un biais de traitement jamais interrogé : la formalisation les rend permanents et leur donne l’apparence d’une règle validée.

Écrire une compétence est donc l’occasion de réexaminer la pratique, pas seulement de la transcrire. C’est souvent le vrai bénéfice du chantier, avant même que le premier agent ne l’exécute.

Une compétence qui ne se mesure pas dérive

Les procédures changent : une réglementation évolue, un référentiel est remplacé, un seuil est relevé. Une compétence formalisée continue pendant ce temps d’appliquer l’ancienne règle, sans se plaindre, jusqu’à ce que quelqu’un remarque un écart.

Deux dispositifs suffisent à contenir ce risque. Le premier est un jeu de cas de référence, tirés de dossiers réels dont on connaît la bonne issue, rejoué à chaque modification de la compétence. Le second est une date de revue inscrite dans la compétence elle-même, avec un propriétaire nommé : la même discipline que pour une procédure qualité, transposée à un composant qui s’exécute.

Le savoir métier devient un actif logiciel

La conséquence organisationnelle est plus intéressante que la conséquence technique. Aujourd’hui, quand un expert quitte l’entreprise, une partie de son savoir-faire part avec lui. Demain, certaines de ses méthodes pourront exister sous forme de capacités réutilisables.

Cela ne signifie pas que l’expertise humaine perd de sa valeur. Une étude publiée par Anthropic en juin 2026, portant sur environ 400 000 sessions de programmation assistée réparties sur quelque 235 000 utilisateurs, va dans le sens inverse. Ce n’est pas le métier d’origine qui sépare les résultats : sur les sessions produisant du code, les dix professions les plus représentées se tiennent en sept points. Ce qui les sépare, c’est le niveau d’expertise démontré pendant la session. Une session jugée novice atteint la réussite vérifiée 15 % du temps, contre 28 à 33 % dès le niveau intermédiaire. Et l’expertise fait accomplir davantage de travail par instruction : environ cinq actions par consigne chez les novices, douze chez les experts.

Ces chiffres portent sur la programmation et ne se transposent pas mécaniquement à un métier réglementé ou à une fonction commerciale. Ils indiquent tout de même une direction : il faut des experts pour définir les bonnes pratiques, nommer les exceptions et fixer les critères qui permettent de juger un résultat. Le rôle se déplace de celui qui exécute chaque tâche vers celui qui formalise, évalue et améliore la façon dont elle doit être exécutée. C’est aussi une des conditions de l’adoption réelle de l’IA en entreprise, qui ne se joue jamais sur le seul déploiement d’un outil.

Documenter une compétence comme un composant logiciel

Les entreprises documentent déjà leurs données, leurs API et leurs processus. Avec les agents, elles auront à documenter leurs compétences exécutables, avec les mêmes exigences que pour un composant logiciel.

Ce sont les questions que l’on pose à n’importe quelle brique de ce type : propriété, version, dépendances, périmètre, tests, historique. La cinquième renvoie directement à construire un jeu de cas de référence tiré de dossiers réels : une compétence qu’on ne sait pas évaluer est une compétence qu’on ne saura pas faire évoluer.

À retenir

Donner accès aux documents permet à un agent de connaître l’entreprise. Cela ne lui apprend pas à travailler comme elle. Pour cela, il faut capturer autre chose : les méthodes, les décisions, les exceptions, les outils, les critères de qualité et les limites d’autonomie.

Après la bataille des modèles et celle de la donnée, une question nouvelle se pose aux entreprises : comment transformer leur savoir-faire en compétences réellement utilisables par leurs agents ? C’est probablement là que se jouera une part de leur différenciation.