Un prospect envoie un tableur.

Cent quinze questions. Architecture, sécurité, sauvegardes, chiffrement, sous-traitants, continuité de service, protection des données.

Personne n'est surpris. Ce n'est pas le premier. Ce ne sera pas le dernier.

Et pourtant, au moment d'ouvrir le fichier, on retrouve toujours la même hésitation.

Soit on reprend tout depuis le début : on rouvre la documentation, on fouille les configurations, on relance l'équipe technique.

Soit on récupère le questionnaire du client précédent et on recopie ce qui ressemble.

La première option épuise.

La seconde rassure.

Les deux font perdre ce que l'entreprise sait.

Chaque questionnaire, on recommence

Le premier questionnaire de ce type que j'ai traité de manière structurée comptait quarante-trois questions.

Pour y répondre, il a fallu rassembler sept sources techniques et faire un aller-retour avec l'équipe qui exploitait le service. À cela s'ajoutait la rédaction proprement dite :

• comprendre ce que le prospect demandait vraiment ;
• retrouver l'information ;
• vérifier qu'elle était encore vraie ;
• décider ce que nous pouvions communiquer ;
• remettre la réponse dans le format attendu.

Entre trois et six heures de travail. Plusieurs personnes mobilisées. Aucune garantie que le prospect devienne client.

Ce n'était pas une situation exceptionnelle.

Chaque prospect envoie son propre document. Un tableur une fois, un Word la suivante, un PDF ensuite. Les référentiels changent. Les numérotations changent. Les formulations changent.

Mais les sujets, eux, reviennent.

C'est ce qui rend la situation si frustrante : on a l'impression de répondre à la même question pour la dixième fois, et de devoir pourtant la reconstruire à chaque fois.

Puis le document part.

Et tout le travail de recherche reste enfermé dans le fichier envoyé.

Copier semble être la solution raisonnable

Face à cette répétition, le réflexe est évident.

On garde les anciens questionnaires. On cherche celui qui ressemble le plus. On reprend les réponses.

Le même réflexe existe à l'intérieur de l'entreprise. Une équipe a besoin d'une règle qui appartient à une autre équipe : les champs obligatoires d'un formulaire, une politique de sauvegarde, une limite contractuelle. Elle copie le passage dans sa propre documentation, pour l'avoir sous la main.

Sur le moment, c'est efficace.

On gagne du temps. On évite de déranger les mêmes personnes. On s'appuie sur quelque chose qui a déjà été écrit, et souvent validé.

Le problème, c'est que ce gain est immédiat, alors que le coût arrive plus tard.

Et il arrive sans prévenir.

Une ancienne réponse ressemble à une connaissance

Dans l'un des questionnaires reçus, une réponse était déjà remplie.

Elle indiquait que notre certification ISO 9001 datait de 2017.

La phrase paraissait parfaitement exploitable. Elle était précise, déjà rédigée, placée en face de la bonne question.

La date correcte était 2018.

Une année d'écart. Rien de grave en apparence.

Mais cette erreur m'a fait comprendre quelque chose de plus important.

Une ancienne réponse ressemble à une connaissance. Elle a la forme d'une affirmation. Elle est bien écrite. Elle rassure.

Pourtant, elle reste muette sur l'essentiel :

• qui l'a écrite ;
• sur quoi elle repose ;
• à quelle date elle était vraie ;
• si elle décrit encore réellement le produit.

Une ancienne réponse peut venir d'un modèle, d'un autre fournisseur, d'un échange dont plus personne ne se souvient. Elle peut avoir été juste au moment de son envoi et fausse aujourd'hui.

Et avec l'IA, ce risque augmente.

Quand une IA rencontre une réponse déjà rédigée dans un document, elle la reprend volontiers. Elle n'a aucune raison de s'en méfier. La phrase est affirmative, bien placée, cohérente avec la question.

L'IA ne fait alors qu'accélérer la propagation d'une erreur que personne n'a vue.

La copie diverge sans bruit

Le même mécanisme existe entre équipes, et il est encore plus discret.

Prenons une situation très ordinaire.

Une équipe produit travaille sur la qualité des comptes rendus d'intervention. Elle s'appuie sur une règle qui appartient à une autre équipe : la liste des informations obligatoires à la clôture d'une intervention. Elle l'a lue, elle l'a reprise dans ses documents, elle avance.

Six semaines plus tard, le travail part en relecture.

Quelqu'un relève un écart.

La règle a changé entre-temps. L'autre équipe a fait évoluer le produit. C'était légitime. C'était même prévu.

Mais personne ne l'a signalé.

Personne n'a menti. Personne n'a fait d'erreur grossière. La règle a simplement continué à vivre là où elle était née, pendant que sa copie restait figée ailleurs.

C'est ce qui rend ce problème si difficile à repérer : une copie qui diverge ne fait aucun bruit. Elle reste propre, bien formulée, crédible. Elle a seulement cessé d'être vraie.

Face à cela, il existe deux manières de se tromper, et elles sont symétriques.

Renvoyer vers l'original évite la copie. On consulte la règle là où elle vit. Mais si rien ne signale qu'elle a changé, on continue à s'appuyer sur ce qu'on a lu il y a six semaines.

Recopier rend autonome. La copie ne dépend plus de l'autre équipe. Mais si rien ne dit d'où elle vient, un an plus tard on dispose d'une note juste, ou fausse, dont personne ne sait sur quoi elle repose.

Chaque geste a donc sa dette :

• une référence demande de savoir quand sa source change ;
• une copie demande de dire d'où elle vient, de quand elle date et ce qui a été reformulé au passage.

Le problème n'est pas de copier ou de référencer.

Le problème est de le faire sans écrire ce que chaque geste exige.

Garder les faits, pas les documents

Pour les questionnaires, j'ai fini par changer de point de départ.

Je ne voulais plus construire une bibliothèque de réponses à copier.

Je voulais construire une mémoire de ce que nous savions réellement répondre.

Cela a commencé par une décision simple : ranger par sujet, et non par client.

Une question appelée « 14.6.l » chez un prospect et une question appelée « CL-072 » chez un autre portaient sur la même chose : les sauvegardes. Rangées par fichier client, elles restaient étrangères l'une à l'autre. Rangées par sujet, elles se rejoignaient.

La question n'était plus : « qu'avons-nous répondu à tel client ? »

Elle devenait : « que savons-nous répondre sur les sauvegardes ? »

Et pour chaque sujet, nous conservions un fait vérifié, accompagné de ce qui permet d'y faire confiance :

• son origine : une documentation officielle, une configuration vérifiée, un test, la confirmation de l'équipe compétente ;
• la date à laquelle il a été validé ;
• les limites de ce que nous pouvons annoncer.

Le questionnaire du client gardait sa valeur. Il montrait ce que le marché voulait savoir, avec ses mots et ses priorités.

Mais il ne prouvait plus rien.

La demande venait du client. La preuve venait de nous.

Nous avons aussi séparé deux choses que les anciens questionnaires mélangeaient : ce qui sert à vérifier une réponse et ce qui peut être envoyé. Le détail d'une configuration peut être indispensable au relecteur interne sans avoir sa place dans un document transmis à un prospect.

La formulation destinée au client était préparée d'un côté.

Les preuves et les réserves restaient à côté, pour celui qui devait valider.

Laisser la connaissance chez celui qui en est responsable

Le même principe vaut entre équipes.

Une règle a un propriétaire. C'est l'équipe qui la fait évoluer, qui sait pourquoi elle existe et qui en répond.

La première manière de l'utiliser consiste à la consulter là où elle vit, plutôt que d'en garder une version personnelle. On s'appuie sur elle sans prétendre la posséder.

Parfois, ce n'est pas suffisant. On a besoin de figer la version exacte sur laquelle repose une décision. On veut la reformuler pour un usage particulier. On veut qu'elle reste disponible même si l'équipe d'origine se réorganise.

Dans ce cas, on peut la copier.

Mais la copie doit garder son passé : d'où elle vient, à quelle date, et ce qui a été modifié.

La différence entre les deux tient moins au geste qu'à la responsabilité :

• quand je consulte, la connaissance continue d'appartenir à l'autre équipe ;
• quand je copie, une version autonome entre chez moi, et je deviens responsable de son usage.

Reste une tentation que tout le monde connaît.

On lit souvent la documentation d'une autre équipe. On repère une erreur. On sait quoi corriger. Cela prendrait trente secondes.

Il vaut mieux proposer la correction que la faire.

Celui qui repère une erreur ne décide pas de la place définitive de la connaissance. C'est l'équipe qui en est responsable qui juge si la correction décrit vraiment son périmètre, ou seulement le cas particulier de celui qui la propose.

C'est ce qui empêche un résultat local de devenir, en silence, une vérité générale.

Un manque visible vaut mieux qu'une phrase plausible

Ranger les faits par sujet a eu un effet que je n'attendais pas.

Cela a fait apparaître les trous.

Quand une information manquait, il n'était plus possible de la masquer derrière une ancienne formulation. Le sujet était là, la question aussi, mais aucun fait vérifié ne permettait d'y répondre.

Le manque devenait visible.

Et un manque visible peut devenir une action.

Plutôt que de remplir la case avec une phrase rassurante, on prépare une question précise pour l'équipe concernée. On indique quelles lignes du questionnaire cette réponse permettra de compléter. On sait à qui la poser, et pourquoi.

C'est sans doute le changement le plus important.

Une phrase plausible cache un risque.

Un manque explicite le transforme en travail identifiable.

Le quatrième questionnaire

Le quatrième questionnaire comptait cent quinze questions. Presque trois fois plus que le premier.

Cette fois, nous ne partions plus d'un ensemble de fichiers épars. Les sujets récurrents étaient connus, et pour chacun d'eux nous savions où se trouvaient les faits vérifiés.

Quatre-vingt-seize réponses complètes ont pu être produites directement, sans nouvelle collecte.

Le reste du document était classé :

• des réponses solides, à vérifier une dernière fois ;
• des réponses incertaines ;
• quelques questions impossibles à traiter avec les informations disponibles.

Les points encore ouverts avaient changé de nature. Nous ne cherchions plus au hasard qui savait quoi. Il restait des décisions commerciales, comme la durée d'un engagement, et quelques confirmations techniques ponctuelles.

Le travail restant était visible, attribuable et limité.

Dans mon usage, la préparation d'un questionnaire est passée de trois à six heures à environ dix minutes pour produire 80 à 90 % du document.

Ce chiffre peut tromper.

Il ne veut pas dire que 80 à 90 % des réponses sont certaines et prêtes à engager l'entreprise. Il veut dire que le document est largement préparé : les réponses connues sont en place, leurs sources sont retrouvées, les points fragiles sont signalés, les informations manquantes sont devenues des demandes précises.

La relecture humaine reste indispensable.

Mais elle porte enfin au bon endroit. Le relecteur ne passe plus son temps à fouiller d'anciens fichiers et à solliciter une nouvelle fois les mêmes personnes. Il vérifie les engagements, arbitre ce qui peut être dit et se concentre sur ce qui est nouveau ou incertain.

Ce que l'entreprise garde

Repartir de zéro et recopier semblent être deux attitudes opposées.

L'une gaspille le travail passé. L'autre le réutilise sans le vérifier.

En réalité, elles reposent sur la même confusion : prendre le document pour la connaissance.

Le document est fait pour un client, un moment, un format. Il est nécessaire. Mais il n'est pas l'endroit où une entreprise devrait garder ce qu'elle sait.

Ce qu'elle sait tient dans des faits qui gardent leur origine, leur date et leurs limites, consultés là où ils vivent ou copiés en disant d'où ils viennent.

Le premier questionnaire avait exigé une enquête.

Les suivants ont profité de tout ce que cette enquête avait appris. Une erreur de date est devenue une règle de prudence. Une confirmation obtenue auprès d'une équipe est devenue un fait réutilisable. Une question sans réponse est devenue un manque connu plutôt qu'un oubli.

Le prospect reçoit toujours son document.

L'entreprise, elle, garde enfin ce qu'elle a appris en le préparant.

---

Note sur les exemples

Les exemples de cet article s'appuient sur plus de trente ans de pratique dans l'informatique et le management d'équipes, et sur de nombreux échanges avec des pairs. Je les ai modifiés, généralisés ou recomposés : aucun ne décrit un client, un produit ou une organisation réels, ni ne reflète les données ou les positions de mon employeur. Les opinions exprimées n'engagent que moi.