Formaliser le savoir-faire du dirigeant, c’est observer des décisions réelles, écrire les règles et les exceptions qu’il applique sans y penser, puis vérifier qu’une autre personne ou un outil peut traiter les cas courants. Le jugement reste à l’expert : on formalise ce qui se répète, pas l’intuition.

Le problème apparaît souvent lorsque « personne d’autre ne sait ». Une demande client attend le retour du dirigeant. Un devis reste bloqué. Une réponse pourtant fréquente doit être reconstruite de mémoire. Cette dépendance paraît rassurante parce qu’elle protège la qualité, mais elle limite la transmission, la croissance et parfois la continuité de l’activité.
Un savoir-faire contient plusieurs couches
Derrière une décision d’expert, on trouve des connaissances, des règles, des exceptions, des signaux faibles et parfois de l’intuition. Tout ne se formalise pas, mais chaque couche peut recevoir un traitement différent :
- une connaissance stable devient une fiche de référence ;
- une règle répétable devient un contrôle ;
- une exception connue déclenche une alerte ;
- une décision sensible ou ambiguë reste soumise à l’expert.
Cette distinction évite une erreur classique : vouloir « mettre de l’IA » sur toute l’expertise d’un coup.
Comment formaliser le savoir-faire du dirigeant à partir d’une tâche réelle ?
Prenez une opération que vous faites régulièrement et, pendant une semaine, notez à chaque occurrence :
- les informations que vous consultez ;
- les questions que vous vous posez ;
- les règles que vous appliquez ;
- les exceptions rencontrées ;
- ce qui vous oblige à réfléchir ;
- ce que vous faites sans y penser.
Pour rendre cette observation exploitable, rangez-la dans un tableau simple :
| Question | Ce qu’il faut noter | Décision possible |
|---|---|---|
| Quelle information est consultée ? | Document, logiciel, email, souvenir | La centraliser ou la rendre recherchable |
| Quelle règle revient ? | Condition et résultat attendu | Créer un contrôle ou une suggestion |
| Quelle exception bloque ? | Cas rare, risque, donnée manquante | Transmettre à l’expert |
| Qu’est-ce qui change la décision ? | Seuil, contexte client, contrainte métier | Documenter le critère |
| Comment vérifier le résultat ? | Source, validation, retour client | Définir un test avant automatisation |
À la fin de la semaine, comptez les cas réellement observés : cas répétables, cas incomplets et cas qui demandent un jugement. Ce décompte, propre à votre tâche, vaut mieux que n’importe quel ratio général.
Comment savoir si la tâche se prête à un outil ?
Une première tâche est intéressante lorsqu’elle revient souvent, suit des étapes observables, utilise des sources identifiables et produit un résultat que l’on peut contrôler. Elle l’est moins si chaque cas est inédit, si les documents manquent ou si une erreur peut avoir un effet important sans contrôle humain.
Le test des dix cas réels
- Choisissez dix demandes récentes, pas dix exemples inventés.
- Rejouez la décision en notant chaque source et chaque règle.
- Repérez les informations manquantes et les contradictions.
- Vérifiez si une personne extérieure peut suivre le raisonnement.
- Décidez ce que l’outil propose, ce qu’il bloque et ce qu’il transmet.
Si les dix cas ne peuvent pas être expliqués, le projet n’est pas forcément impossible. Il faut d’abord structurer le savoir avant de développer.
Un cas réel : faire passer le savoir d’un expert dans un assistant
J’ai conçu et développé un assistant IA de conseil pour une entreprise dont le dirigeant est un professionnel de l’entretien des espaces verts. L’assistant conseille des particuliers sur l’entretien de leur jardin à partir de l’expertise de ce dirigeant. Deux enseignements de ce projet valent pour n’importe quel métier.
- Le savoir s’écrit d’abord en cas concrets. L’expert a formalisé ses conseils sous forme de scénarios : une situation reconnaissable, par exemple une pelouse grillée pendant une canicule, et la conduite à tenir. Écrire « dans telle situation, je fais ceci » est beaucoup plus facile que d’énoncer des principes généraux.
- Il faut pouvoir tester une règle sans la perdre. Au départ, pour écarter un scénario pendant ses essais, il devait le supprimer, puis le réécrire. Nous avons ajouté un état « inactif » : l’assistant ignore le scénario désactivé, et l’expert le réactive quand il est prêt.
Dans ce projet, l’expert reste dans la boucle : c’est lui qui écrit, active et corrige les règles. Mon rôle est de les rendre utilisables par l’outil et de vérifier, par des tests, que l’assistant les applique.
Quand le livrable est un assistant IA
Un assistant IA n’ajoute pas de savoir : il restitue celui qu’on lui a donné. Avant de le construire, classez chaque élément selon le comportement attendu.
| Type | Exemple | Comportement de l’assistant |
|---|---|---|
| Fait documenté | Étape d’une procédure en vigueur | Répondre en citant la source |
| Règle conditionnelle | Si une pièce manque, demander le complément | Expliquer la condition |
| Opinion ou recommandation | Option préférable selon le contexte | Présenter comme recommandation, pas comme fait |
| Décision sensible | Engagement financier ou décision sur une personne | Préparer les éléments et transmettre à l’humain |
France Num conseille aux TPE et PME de préparer un « kit de données » avant de lancer un agent conversationnel : réponses types, tarifs à jour, exemples de demandes et de résultats attendus. La CNIL recommande de partir d’un besoin concret et de définir les usages autorisés et interdits. Concrètement, trois règles suffisent pour commencer : l’assistant cite la source utilisée, signale l’information absente et renvoie les décisions sensibles à une personne. Pour la méthode de test avant mise en service, voir comment éviter qu’un assistant IA invente des réponses.
Quand cette matière existe, je peux en faire un assistant IA pour entreprise qui s’appuie sur vos seules sources validées.
Le bon livrable n’est pas toujours un logiciel
Une fois le savoir observé, choisissez le support le plus simple qui permet à une autre personne de réussir les cas courants et de transmettre les autres.

| Nature du savoir | Livrable utile | Test de validation |
|---|---|---|
| Suite stable d’actions | Checklist ou procédure | Une personne réalise la tâche sans aide |
| Choix entre quelques conditions connues | Arbre de décision | Dix cas historiques aboutissent à la bonne orientation |
| Geste ou manipulation difficile à décrire | Démonstration commentée ou tutoriel | L’apprenant reproduit le geste et explique les points de contrôle |
| Réponses dispersées dans des sources validées | Base documentaire recherchable | La bonne source est retrouvée pour chaque question test |
| Règle stable à appliquer dans un flux | Fonction d’un outil métier | Les cas nominaux et les exceptions prévues passent la recette |
Si plusieurs livrables conviennent, commencez par le plus facile à corriger. La formalisation reste utile même si aucun développement n’est lancé : elle sert déjà à former, à déléguer et à assurer la continuité.
Questions fréquentes
Faut-il commencer par une base documentaire parfaite ?
Non. Commencez avec une tâche limitée et des documents identifiés. Les incohérences découvertes font partie du diagnostic. En revanche, une information non validée ne doit pas être présentée comme une règle fiable.
Un outil peut-il reproduire l’intuition du dirigeant ?
Pas comme une recette certaine. Il peut faire apparaître les signaux observables qui nourrissent cette intuition, puis réserver la décision finale à l’expert.
Quelle tâche choisir en premier ?
Une tâche fréquente, coûteuse en interruptions, vérifiable et assez peu risquée. Une première réussite mesurable vaut mieux qu’un projet censé couvrir toute l’entreprise.
Comment éviter que le savoir formalisé devienne obsolète ?
Attribuez un responsable à chaque source, conservez les versions et rejouez régulièrement les cas de test. Sans responsable, une base de règles se dégrade comme n’importe quelle documentation.
Quelle tâche reste bloquée chez vous ?
Celle pour laquelle on vous répond encore « il faut demander au patron » est souvent la bonne candidate. Venez avec deux ou trois exemples récents.

