Monter la base de connaissances de votre maison
Pourquoi le projet ChatGPT marche six fois, puis cite une procédure abrogée
- Déposer quarante documents dans ChatGPT marche six fois, puis cite une procédure abrogée avec aplomb. Ce n'est pas un défaut d'outil.
- Le problème n'est pas que vos documents sont sales : 77 % des dirigeants estiment que 20 % au plus de leurs données sont suffisamment décrites et contextualisées, et le premier obstacle est l'absence de contexte (43 %), pas la dispersion.
- Un document n'est pas le processus. Seule la face écrite d'une routine entre dans un index ; la face exécutée est recréée à chaque fois par des gens précis (Feldman & Pentland, ASQ 2003).
- Tout écrire ne règle rien : sur des procédures rédigées par des professionnels, la réussite plafonne à 72,4 %, et vingt opérations fiables à 95 % tiennent 36 % du temps.
- Ce qui décide n'est pas le volume écrit, c'est qui participe à l'écrire (Adler & Borys, ASQ 1996). Une procédure écrite par ceux qui l'appliquent outille ; la même écrite sur eux se contourne.
- Ce qu'il faut construire n'est pas une base de connaissances, c'est une ligne entre le constat et le jugement — et c'est elle qui permet au système de dire qu'il ne sait pas.
Un vendredi de novembre, 18 h 20. Karim, directeur technique, a créé un projet dans ChatGPT et y a déposé quarante-deux documents : le manuel qualité, six mémoires techniques gagnés, des comptes rendus de revue, deux notes de méthode que personne n'avait rouvertes depuis 2021.
Il pose une question. La réponse est bonne. La deuxième aussi. La quatrième est excellente — il la montre à un collègue.
La sixième cite, avec un aplomb parfait, une procédure abrogée il y a trois ans.
Karim ne recommence pas. Il ne supprime pas le projet non plus : il reste là, ouvert dans un onglet, et plus personne ne s'en sert pour autre chose que reformuler des courriels.
Ce qui a marché, et pourquoi Karim avait raison d'essayer
Le déposer-et-interroger fonctionne mieux qu'on ne l'imagine. Sur un corpus de quelques dizaines de documents, un modèle récent retrouve le bon passage, le résume fidèlement, répond à une question de synthèse qui aurait demandé une demi-heure de lecture. Les cinq premières réponses de Karim étaient bonnes, et elles l'étaient pour de bonnes raisons.
Le meilleur résultat mesuré du domaine va d'ailleurs dans ce sens : une aide nourrie du travail des meilleurs a fait traiter aux débutants d'un centre d'assistance 34 % de dossiers en plus par heure, sans gain mesurable chez les expérimentés (Quarterly Journal of Economics, 2025 ; 5 172 agents). Le gain ne venait pas de la puissance du modèle. Il venait de l'accès au savoir de la maison.
La question n'est donc pas si ça marche. C'est pourquoi ça cesse de marcher au sixième essai.
Le problème n'est pas que vos documents sont en désordre
C'est la première explication qu'on vous vendra : vos données ne sont pas propres. Elle est fausse, ou plutôt elle est à côté.
77 % des dirigeants estiment que 20 % au plus de leurs données d'entreprise sont suffisamment décrites et contextualisées pour qu'un système les exploite. Et le premier obstacle cité n'est pas la saleté des données : c'est l'absence de métadonnées, de contexte et de relations — 43 %, devant la dispersion (Teradata / Wakefield, 1 000 responsables, six pays dont la France, 2026).
Autrement dit : vos documents sont lisibles. Ce qui manque, c'est ce qui dit lesquels valent encore, pour qui, dans quel cas — et lequel des deux, quand ils se contredisent.
Un chiffre le dit plus brutalement : 74 % des organisations s'en remettent à un effort manuel ou à l'expertise d'une personne pour gouverner leurs documents non structurés (BARC / Ohalo, 2026). La personne, c'est Michel. Le projet ChatGPT de Karim ne contenait pas Michel.
La raison de fond : un document n'est pas le processus
C'est là que se joue la vraie erreur, et elle est ancienne.
Une routine d'entreprise a deux faces. La face écrite — la procédure, le modèle, la trame — est ce qui sert à guider et à rendre des comptes. La face exécutée est recréée à chaque fois par des gens précis, dans des situations précises, et elle réécrit la première en continu (Feldman & Pentland, Administrative Science Quarterly, 2003).
Ce qui peut entrer dans un index documentaire, c'est la première face. Croire que le document est le processus n'est pas une approximation : c'est une erreur de catégorie, et elle se paie au sixième essai.
Il y a pire. Le travail invisible de coordination — rattraper ce qui ne va pas, prévenir la bonne personne, adapter quand le cas sort du cadre — est précisément ce qu'une formalisation exclut du modèle (Star & Strauss, 1999). Plus vous formalisez complètement, plus vous avez défini hors du modèle une part du travail réel — et le modèle a l'air plus complet à mesure qu'il devient moins vrai.
« Alors on écrit tout » — non, et la littérature est nette
C'est la réaction naturelle, et c'est le piège suivant.
D'abord parce que ça ne suffit pas. Sur SOP-Bench, qui donne au modèle des procédures pourtant écrites par des professionnels, la meilleure combinaison modèle-agent atteint 72,4 % de réussite. Et vingt opérations fiables chacune à 95 % tiennent 36 % du temps de bout en bout. Une procédure parfaitement rédigée laisse encore un tiers d'échec à l'exécution.
Ensuite parce que l'excès a un nom et un mécanisme. Le safety clutter — accumulation de procédures et de documents produits au nom de la maîtrise, sans y contribuer — naît de trois gestes : dupliquer (le même risque traité par deux systèmes), généraliser (une règle écrite pour un contexte appliquée à tous), sur-spécifier (un détail sans rapport avec le risque). Il s'accumule parce qu'ajouter est facile et retirer est difficile. Son coût : du temps, du cynisme, et une conformité de surface (Rae, Provan, Weber & Dekker, 2018).
Enfin parce que « combien écrire » est la mauvaise question. Une même quantité de formalisation peut outiller ou contraindre, et ce qui décide n'est pas le volume : c'est qui participe à la concevoir (Adler & Borys, ASQ, 1996). Une procédure écrite par ceux qui l'appliquent aide ; la même écrite sur eux les contourne.
Et la formalisation ne doit pas être uniforme : une tâche routinière supporte une règle d'action stricte, une tâche incertaine demande une règle d'objectif — qui, au passage, augmente d'abord l'incertitude ressentie par celui qui décide, avant de la réduire (Grote, ETH Zürich). Autant le savoir avant de commencer : ce flottement est normal, et il passe.
Ce qu'il faut construire à la place
Pas une base de connaissances. Une ligne.
D'un côté, les constats : il existe un critère, et un logiciel l'applique seul — à condition qu'il sache reprendre, escalader et s'arrêter. De l'autre, les jugements : quelqu'un en répond, et aucun niveau de capacité du modèle ne reprend cette part-là.
Tracer cette ligne est la captation du savoir. Pas un préalable à elle : le même travail. Parce que la ligne n'est pas générique — elle dit ce que correct veut dire chez vous, et ce qu'on fait des cas qui n'y entrent pas.
C'est aussi la seule chose qui rend le système utilisable : il peut dire je ne sais pas. Le projet de Karim ne le pouvait pas. C'est pour ça qu'il a cité une procédure abrogée sans hésiter.
Le précédent des années 1980 : ça a déjà échoué une fois
Une démarche fondée sur la formalisation du savoir a déjà échoué une fois. Dans les années 1980, les systèmes experts ont buté sur ce qu'on a appelé le goulot d'acquisition des connaissances : les experts livraient la surface explicite, le jugement restait inaccessible, les règles captées étaient fragiles sur les cas limites et pourrissaient à mesure que le métier évoluait.
Les modèles actuels atténuent ce problème — ils lisent du texte non structuré, tolèrent l'implicite, généralisent. Ils ne le suppriment pas. Si cet antécédent vous vient à l'esprit, la comparaison est juste, et c'est la question à poser à quiconque vous propose ce chantier.
La question à trancher ce soir
Pas par un outil, pas par un chantier documentaire. Par un processus, et par une question que vous pouvez trancher ce soir.
Sur vos douze derniers dossiers, combien seraient sortis identiques si la personne qui sait avait été en congé ce mois-là ? Si la réponse est douze sur douze, ce n'est pas votre sujet. Si elle tombe à trois, vous connaissez déjà le sujet — et vous savez aussi qui, chez vous, porte la différence.
La suite est trois de vos dossiers déjà sortis, repris au fond avec les gens qui les font. Il en sort leur règle de jugement — ce que correct veut dire chez vous, écrit pour la première fois — et ce que ce processus vous coûte aujourd'hui. Les deux vous restent, même si vous vous arrêtez là.
Le projet de Karim reste ouvert dans son onglet. Il n'avait pas tort d'essayer : il lui manquait une ligne.
Pour une question ponctuelle sur un corpus que vous connaissez, si — et c'est même un bon réflexe. Ce qui ne tient pas, c'est l'usage répété par des gens qui ne peuvent pas vérifier la réponse. Rien dans le projet ne dit quel document fait foi quand deux se contredisent, ni lequel a été abrogé, ni ce que votre maison a décidé de faire dans les cas que la procédure ne couvre pas. Le système répond quand même, et avec assurance.
Non, et c'est la dépense la plus fréquemment engagée pour rien. Le premier obstacle mesuré n'est pas la propreté mais la description : ce qui manque, c'est ce qui dit lesquels valent encore, pour qui, dans quel cas. Un chantier documentaire mené avant d'avoir écrit la ligne produit des documents plus propres et un système qui se trompe toujours.
Non. Une partie est toujours écrite — un manuel qualité, une trame, une note d'organisation. Ce qui manque est la version dont on se sert vraiment, et elle ne s'obtient pas en demandant aux gens de l'écrire : elle s'obtient en regardant des dossiers passés avec eux, et en leur demandant pourquoi celui-ci était bon et celui-là ne partirait plus.
La question la plus courante, et la littérature répond qu'elle est mal posée. Une même quantité de formalisation peut outiller ou contraindre ; ce qui décide est qui participe à la concevoir. Et elle ne doit pas être uniforme : une tâche routinière supporte une règle stricte, une tâche incertaine demande une règle d'objectif — qui augmente d'abord l'incertitude ressentie avant de la réduire. C'est un effet connu, et il vaut mieux le savoir avant de commencer qu'au premier moment de flottement.
Rien ne l'empêche totalement, et quiconque prétend le contraire vous vend quelque chose. Ce qu'on construit, c'est un chemin d'exception : le système doit savoir dire qu'il ne sait pas et envoyer le cas à un humain plutôt que combler le trou. L'ingénierie réduit ce risque et le rend visible ; elle ne l'élimine pas. C'est la raison d'être du chemin d'exception, et ce n'est pas une option de confort.
Ils n'ont pas à en sortir. La solution tourne chez vous ou sur une infrastructure souveraine, elle peut évoluer sans nous, et il n'y a pas d'abonnement à notre présence. C'est aussi la différence pratique avec un outil grand public où le corpus est déposé chez un tiers.
Si, et c'est l'objection la plus sérieuse. Les systèmes experts ont buté sur le goulot d'acquisition des connaissances : les experts livraient la surface explicite, le jugement restait inaccessible, les règles étaient fragiles sur les cas limites et pourrissaient avec le métier. Les modèles actuels atténuent ce problème — ils lisent du non structuré et tolèrent l'implicite — mais ne le suppriment pas. C'est pourquoi on ne vend pas une base de connaissances, mais une ligne et un chemin d'exception.
Apportez un travail que vos équipes font encore à la main.
Vingt minutes : si c'est faisable chez vous, et par où ça commence →Pas encore prêt à en parler ? Lisez comment nous reprenons un travail fait à la main — rien à payer, rien à engager.