Sommaire de l’article
Dans un bureau d'études, le savoir circule rarement par les canaux officiels. On apprend en observant un senior annoter un plan, en écoutant un chef de projet raconter un chantier qui a failli mal tourner, en entendant "ici on ne fait jamais comme ça" sans vraiment savoir pourquoi. Cette transmission, invisible, informelle et continue, est la mémoire collective du bureau. Elle est souvent ce qu'il a de plus précieux.
Et pourtant, dès qu'on cherche à la préserver, on commet presque toujours la même erreur : on la traite comme un problème de stockage. On crée un wiki, on structure un serveur, on demande aux ingénieurs de "documenter". L'intention est bonne. Le résultat est décevant. Non pas parce que l'outil est mauvais, mais parce que la mémoire collective ne fonctionne pas comme un disque dur. Elle ne se stocke pas : elle se vit, elle se transmet, elle s'entretient. Comprendre pourquoi, c'est la première étape pour trouver ce qui marche vraiment.
Le besoin d'organisation
Pendant longtemps, la question de la mémoire en bureau d'études s'est résumée à un problème de classement. On archivait les plans, les notes de calcul, les comptes rendus de réunion. La est née de ce besoin simple : retrouver le bon fichier, au bon moment, sans fouiller pendant une heure dans un serveur mal organisé.
Mais classer des documents, ce n'est pas la même chose que de conserver du savoir. Un plan d'exécution archivé indique ce qui a été fait. Il ne dit pas pourquoi ce choix a été fait plutôt qu'un autre, ni ce qui a failli mal tourner, ni ce qu'on ferait différemment aujourd'hui. L'essentiel, c’est-à-dire le raisonnement, le contexte, l'expérience accumulée, reste dans la tête des ingénieurs. Et quand ils partent, il part avec eux.
Niklas Luhmann était un sociologue allemand. Au cours de sa carrière, il a produit plus de 70 ouvrages ; une productivité intellectuelle qui a longtemps laissé ses contemporains perplexes. Son secret ? Un système de fiches manuscrites qu'il appelait son Zettelkasten, littéralement "boîte à fiches" dans sa langue maternelle. Plus de 90 000 fiches, reliées entre elles par un système de renvois qu'il avait lui-même conçu. Luhmann ne classait pas ses fiches par thème : il les connectait par des associations d'idées, créant un réseau de pensée vivant. Il décrivait d'ailleurs son système comme un véritable interlocuteur, capable de lui renvoyer des idées qu'il avait oubliées avoir eues. Mais ce modèle recèle un paradoxe fondamental : le Zettelkasten est une pratique profondément personnelle. Vouloir le collectiviser, c'est déjà trahir son principe.
C'est pourtant exactement ce que les entreprises ont tenté de faire. Les wikis internes (Notion, Obsidian, SharePoint, etc.) sont nés de cette intuition : construire un Zettelkasten collectif, un espace où chacun contribue et où les savoirs se relient. La réalité, en entreprise, est presque toujours la même. Au lancement, quelques volontaires enthousiastes alimentent le wiki avec soin. Puis le quotidien reprend ses droits, les projets s'enchaînent, et la mise à jour devient la première chose que l'on reporte. Dix-huit mois plus tard, le wiki est officiellement "à refaire". Le problème n'est pas technique : un wiki suppose que tout le monde adopte spontanément la rigueur que Luhmann s'imposait seul, sans temps dédié, sans formation, sans motivation autre que "c'est notre politique interne". Ce n'est pas un problème d'outil. C'est un problème de comportement collectif.
Derrière cette éternelle quête d’organisation se cachent des besoins parfaitement légitimes. Le premier est économique. Ne pas répéter les mêmes erreurs a un prix direct : une erreur de conception déjà vécue sur un chantier similaire, c'est au minimum une heure de reprise, parfois une semaine, parfois un litige. Le second besoin est humain : il est donc plus difficile à chiffrer. Chaque départ d'un ingénieur expérimenté est une hémorragie silencieuse. Ce qu'il emporte ne figure dans aucun document : sa façon de lire un cahier des charges, son instinct face à une configuration ambiguë, sa connaissance des angles morts des logiciels qu'il utilise depuis dix ans.
La mémoire collective
On confond souvent gestion des données, gestion de l'information et gestion du savoir. Ce sont pourtant trois niveaux bien distincts. Les données sont brutes (un relevé de mesure, une référence de produit, un chiffre dans un tableur). Les informations sont des données structurées et contextualisées (une note de calcul, un rapport de chantier). Les savoirs, eux, sont différents : ce sont des informations intégrées, digérées et transformées en capacité d'action. On ne les stocke pas, on les incarne.
Le philosophe Michael Polanyi a formulé cette limite avec une phrase restée célèbre : "We can know more than we can tell". Nous savons toujours plus que ce que nous sommes capables d'exprimer. Un ingénieur expérimenté ne peut pas écrire dans une fiche la totalité de ce qu'il sait parce qu'une grande partie de ce savoir est tacite, logée dans ses réflexes, ses habitudes de lecture, sa façon d'anticiper les problèmes avant qu'ils ne se posent.
Mais il y a une dimension supplémentaire, souvent négligée. Le sociologue Maurice Halbwachs a montré dès les années 1920 que la mémoire n'est pas qu'une affaire individuelle : nous nous souvenons toujours à travers les autres. Nos souvenirs sont structurés par les groupes auxquels nous appartenons : la famille, les amis, les collègues. Une équipe qui travaille ensemble depuis plusieurs années développe une mémoire partagée: un stock de références communes, d'expériences fondatrices, de façons de faire implicites que personne n'a jamais écrites nulle part. "On ne fait jamais comme ça ici", "sur ce type de projet, il faut toujours vérifier ce point-là"; ces formules condensent des années d'apprentissage collectif. Elles circulent à l'oral, dans les échanges informels, dans les réunions de chantier. Elles ne survivent pas à une réorganisation, à un déménagement ou à une vague de départs. Et jusqu'ici aucun outil ne les capture, parce qu'elles n'ont jamais été formulées assez explicitement pour être écrites.
Ce que Halbwachs éclaire, c'est précisément l'angle mort des outils de knowledge management : ils traitent la mémoire comme un stock individuel à externaliser, alors qu'elle est fondamentalement un processus social. Un wiki peut stocker des informations : il ne peut pas reproduire la dynamique de groupe qui leur donne du sens. La mémoire collective s'entretient par la répétition sociale: les débriefs, les rituels d'équipe, les récits partagés. C'est ce processus qu'il faut soutenir, pas contourner.
Structurer sans unifier
La question devient alors : peut-on concevoir un outil qui soutienne ce processus social plutôt que de chercher à le remplacer ? C'est là que l'intelligence artificielle introduit quelque chose de réellement nouveau, non pas comme un wiki amélioré, mais comme un médiateur capable de structurer sans normaliser.
Les outils précédents imposaient tous un format en entrée : remplir un champ, choisir une catégorie, respecter un template. Ils demandaient aux ingénieurs d'interrompre leur travail pour alimenter un système rigide, un effort cognitif supplémentaire qui explique en grande partie leur échec. L'IA peut au contraire travailler sur des contenus produits naturellement, dans le cours ordinaire du travail : une note griffonnée, un échange de mails, un compte rendu de réunion enregistré. Elle en extrait de la structure sans avoir exigé cette structure au moment de la production. On ne demande plus aux ingénieurs d'adapter leur façon de penser à l'outil ; on demande à l'outil de s'adapter à leur façon de travailler.
Surtout, l'IA peut restituer le savoir sous une forme contextuelle et personnalisée : une synthèse pour le directeur de projet, un détail de calcul pour le chargé d'études, une liste de précédents similaires pour un jeune ingénieur qui démarre. C'est une différence fondamentale avec le taylorisme cognitif des outils standardisés, qui lissent les différences d'approche et appauvrissent la pensée collective en la normalisant. L'IA ne remplace pas la diversité des façons de penser : elle la rend plus accessible.
Mais, et c'est essentiel, elle ne remplace pas non plus les rituels qui font vraiment circuler le savoir : le débrief de fin de projet mené avec rigueur, le parrainage entre un senior et un junior, la culture du récit plutôt que de la procédure. Ce que Halbwachs nous apprend, c'est que la mémoire collective a besoin d'un groupe vivant pour exister. L'IA peut alléger la charge documentaire, libérer du temps, rendre cherchable ce qui était enfoui, mais c'est pour que ces moments humains de transmission aient davantage de place, pas pour les rendre inutiles.
Pour approfondir la question de la transmission des savoirs dans les BET, découvrez notre article sur ce qu'il reste de votre expertise si vos ingénieurs partent demain.
Ce que ça change, concrètement
La mémoire collective d'un bureau d'études ne se résoudra jamais par un meilleur outil de stockage. Elle se construit dans les interactions, les histoires partagées, les rituels d'équipe ; tout ce que Halbwachs avait compris un siècle avant l'invention du wiki. Les GED, les Zettelkasten collectifs, les CMS ont tous buté sur le même obstacle : ils traitaient un problème humain comme un problème technique.
C'est précisément de ce constat qu'est née notre approche. Nous avons conçu un outil qui ne cherche pas à remplacer la transmission humaine, mais à en lever les principaux freins : capturer le savoir là où il se produit naturellement. Pour pouvoir le structurer sans l'appauvrir puis le restituer à chaque collaborateur sous la forme qui lui est utile lorsqu'il en a besoin. Pas un wiki de plus. Un assistant qui s'efface pour que les ingénieurs passent moins de temps à chercher et plus de temps à transmettre.
👉 Si vous souhaitez explorer ce que cette approche pourrait apporter à votre bureau d'études, échangeons sur vos enjeux et concevons ensemble une solution adaptée à votre organisation.
Écrit par Sarah Ghidalia
