Aller au contenu
Tous les articles

Applications métier / 8 min de lecture

Transformer le savoir du dirigeant en outil

Certaines tâches ne peuvent pas être déléguées parce qu’elles reposent sur le dirigeant. Voici comment commencer à transformer ce savoir en outil.

Illustration éditoriale : formaliser le savoir-faire du dirigeant
Sommaire de l’article

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.

Formaliser le savoir-faire du dirigeant : un objet en papier crème à demi déplié, ses lignes de pliage révélées par une lumière ambrée
Formaliser un savoir-faire revient à rendre visibles les règles qui restaient pliées dans l'expérience.

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

  1. Choisissez dix demandes récentes, pas dix exemples inventés.
  2. Rejouez la décision en notant chaque source et chaque règle.
  3. Repérez les informations manquantes et les contradictions.
  4. Vérifiez si une personne extérieure peut suivre le raisonnement.
  5. 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.

Une fiche crème éclairée d'orange à côté d'un petit classeur et d'une boîte contenant un mécanisme en papier
Une fiche ou une procédure suffit parfois là où un logiciel serait disproportionné.
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.

Présenter cette tâche à ClosiQode

De la lecture à votre projet

Parlons de votre façon
de travailler.

30 minutes pour comprendre votre fonctionnement et voir si un outil sur mesure est pertinent.

Prendre rendez-vous avec Fabien
Revenir au blog