Nathalie a dirigé les opérations d'entrepôt à Boucherville pendant vingt ans. Elle savait une chose que le système n'a jamais sue : qu'un fournisseur précis dans la file FIFO livrait toujours en retard vers la fin du trimestre, alors son équipe retenait ces palettes en douce et avançait le lot suivant. Jamais écrit. Ça vivait dans sa tête, dans une habitude, dans la façon dont elle jetait un oeil au quai de chargement un jeudi après-midi en sachant, point. Puis l'équipe a refait le module d'inventaire, et quelqu'un a passé les exigences à un agent IA avec un prompt d'une ligne : copier la logique d'allocation actuelle. L'agent a produit une spec propre et bien structurée en à peu près quatre minutes, et il a capté la règle FIFO parfaitement. Il n'a jamais capté l'exception, parce que personne n'a demandé à Nathalie, et Nathalie a pris sa retraite en mars. La rupture de stock a frappé à la semaine trois en production. Elle a coûté plus cher que tout le module à construire.

Voici le bout pas confortable. L'IA devait être l'affaire qui capte enfin ce que les gens savent, la grande machine à documentation, et dans un sens étroit, elle livre. Le rapport State of Developer Experience 2025 d'Atlassian, une enquête auprès de 3 500 développeurs et gestionnaires, a trouvé que 99 % des développeurs sauvent maintenant du temps avec l'IA et que 68 % en sauvent plus de dix heures par semaine (Atlassian, juillet 2025). Dix heures. Une journée complète remise, chaque semaine, à des gens qui passaient avant une partie de ces heures à se parler. Fait que le savoir capté, il va où? Nulle part, en gros. La vitesse et la captation, ça s'avère deux gestes bien différents.

68 %
des développeurs sauvent maintenant plus de 10 heures par semaine avec l'IA, et pourtant le même rapport montre qu'ils perdent encore du temps à chercher de l'information qui n'a jamais été documentée

Le constat plus profond est celui qui devrait vous tenir réveillé. Des chercheurs de Microsoft et de Carnegie Mellon ont interrogé 319 travailleurs du savoir sur 936 tâches réelles, et ont trouvé que plus les gens faisaient confiance à l'IA, moins ils amenaient de pensée critique au travail, surtout sur les tâches routinières (Microsoft Research, CHI 2025). Une autre étude, sur 666 personnes, par Michael Gerlich à la SBS Swiss Business School, a trouvé une corrélation négative significative entre l'usage intensif de l'IA et les scores de pensée critique, avec le délestage cognitif comme mécanisme (Gerlich, Societies, 2025). Lisez les deux ensemble. Le même outil qui rédige la spec nous entraîne tranquillement à arrêter de poser la question qui aurait fait sortir l'exception de Nathalie au départ.

Comment l'IA peut-elle à la fois capter et effacer le savoir de l'entreprise?

Les deux en même temps, et c'est exactement pour ça que la perte se cache si bien. L'IA est excellente avec le savoir explicite : la règle documentée, le processus écrit, l'affaire qui est déjà sur une page Confluence. Elle peut résumer une spec de 200 pages, reformuler une politique, transcrire une réunion. Ce qu'elle ne peut pas faire, c'est atteindre le savoir qui n'a jamais été exprimé nulle part, le genre qu'un philosophe nommé Michael Polanyi a décrit avec une seule ligne : on en sait plus qu'on peut en dire. La raison derrière le contournement de Nathalie était tacite. Elle était réelle, elle était porteuse, et elle n'avait jamais été dite à voix haute à quiconque rédigeait des exigences.

Imaginez les deux chemins côte à côte. Dans l'ancien monde, la découverte était une conversation. Une analyste d'affaires s'assoyait avec Nathalie pendant quatre-vingt-dix minutes, posait des questions malhabiles, et quelque part vers la cinquante-cinquième minute tombait sur « ah ben, sauf pour ce fournisseur-là ». Cet accident, c'était tout le but. L'exception sortait parce qu'un humain était dans la pièce, curieux. Dans le nouveau monde, la découverte est une boîte de texte. Quelqu'un tape copier la logique actuelle, fait entrée, et l'exception n'est jamais invitée. La règle survit. La raison meurt. Personne ne remarque avant que la production le fasse.

Je veux faire attention ici, parce que la version facile de cet argument est fausse. L'IA n'est pas le méchant. Je l'utilise tous les jours, et les dix heures sont réelles. Le problème, c'est pas l'outil. C'est ce qu'on a décidé de faire du temps sauvé, ou plutôt ce qu'on a décidé d'arrêter de faire pour le sauver. On a coupé la conversation. Et la conversation, c'était là que le savoir vivait.

Qu'arrive-t-il quand on saute la découverte pour aller plus vite?

On livre une spec qui correspond au prompt et qui manque ce dont l'opération avait vraiment besoin. Cet écart est invisible au début, parce que la spec a l'air complète. Elle se lit bien. Elle passe la revue, parce que les réviseurs comparent la spec au prompt, pas à la réalité que personne n'a captée. Le trouble apparaît plus tard, en aval, en production, là où c'est le plus cher à corriger et le plus dur à retracer jusqu'à son origine.

C'est cette asymétrie qui rend l'affaire dangereuse. Sauter la découverte vous sauve quoi, quelques jours? Peut-être une semaine d'entrevues. Le coût de l'avoir sautée atterrit des mois plus tard et arrive bien des fois plus gros, sous forme de rupture de stock, de manquement réglementaire, d'une fonction qui fait techniquement ce qui était demandé et échoue ce qui était voulu. La génération plus rapide n'enlève pas le travail d'exigences. Elle le reporte, le cache, et le laisse composer. La facture finit toujours par arriver. Elle arrive juste plus tard, avec les intérêts, adressée à quelqu'un qui n'a aucune idée pourquoi le système se comporte comme ça.

Le danger n'a jamais été que l'IA écrive de mauvaises specs. Elle en écrit de bonnes, vite, fidèles au prompt. Le danger, c'est qu'une bonne spec d'une compréhension incomplète est bien plus convaincante qu'une mauvaise, alors elle passe la revue sans accroc et explose en production.

Pourquoi le savoir tacite ne se rend jamais dans les specs rédigées par l'IA?

Parce qu'une IA ne peut rédiger qu'à partir de ce qu'on lui tend. Elle ne peut pas interviewer le superviseur qui n'est pas dans le prompt. Elle interpole à partir des patrons qu'elle a vus, et c'est précisément ça le problème, parce qu'une exception n'est par définition pas le patron. Le modèle prédit le probable. Le savoir tribal, c'est presque toujours la chose improbable qu'une équipe a apprise à la dure et n'a jamais généralisée.

Pensez à ce qu'était vraiment le savoir de Nathalie. Pas une règle. Une histoire. « Il y a trois ans, ce fournisseur-là nous a brûlés en fin de trimestre, fait qu'astheure on retient ses palettes. » C'est causal, précis, attaché à un incident particulier un jeudi particulier. On ne peut pas le déduire des données, parce que les données montrent le contournement déjà en place, qui marche, qui ressemble à des opérations normales. Le pourquoi n'est pas dans le système. Il est dans la personne. Et un prompt d'une ligne n'a aucune case pour une personne.

Quand la NASA a voulu ressusciter le moteur F-1 de la fusée Saturn V, le moteur à chambre unique à propergol liquide le plus puissant jamais lancé, les plans n'étaient pas le problème. Ils avaient survécu dans les archives. Le moteur ne pouvait quand même pas être simplement reconstruit, parce que les F-1 étaient essentiellement faits à la main, et le savoir de fabrication critique vivait dans la tête des gens qui les avaient bâtis dans les années 1960. Rocketdyne avait même essayé de le capter, en enregistrant des entrevues sur cassette avec les ingénieurs d'origine sur les pièces difficiles à produire et les trucs de fabrication (The Space Review, 2019).

Ça n'a pas suffi. En 1992, un effort de rétention du savoir de la NASA n'a pu retrouver que 76 ingénieurs F-1 retraités encore vivants. Quand les ingénieurs modernes ont finalement repris le moteur, ils ont dû démonter des unités de musée survivantes et les rétroconcevoir, en ajoutant de l'instrumentation qui n'avait jamais été notée la première fois. Les documents leur disaient ce qu'était le moteur. Ils ne pouvaient pas leur dire comment il avait vraiment été fabriqué.

C'est la preuve la plus nette que je connaisse que les documents ne sont pas le savoir. Le quoi a été préservé. Le pourquoi et le comment sont sortis par la porte avec les gens, et aucune vitesse ne pouvait les régénérer. Maintenant, faites avancer ça jusqu'à une équipe qui a laissé un agent rédiger la spec au lieu de demander à la personne. Même perte. Plus vite.

Qu'est-ce que la découverte structurée fait ressortir qu'un prompt ne peut pas?

Le raisonnement. Les cas limites. Les endroits où deux parties prenantes tiennent des hypothèses carrément contradictoires sans jamais l'avoir remarqué, parce qu'elles n'ont jamais été dans la même pièce à répondre à la même question. La découverte structurée, c'est juste le geste délibéré de demander à l'employé senior pourquoi l'exception existe, et d'écrire la réponse à côté de la règle, avant qu'il prenne sa retraite. C'est tout le truc. Ça sonne presque trop simple. C'est aussi exactement ce que le prompt d'une ligne saute.

L'intelligence des exigences, c'est comme ça qu'on appelle le fait de faire ça de façon systématique plutôt que par chance. Au lieu d'espérer qu'une analyste curieuse tombe sur l'exception à la cinquante-cinquième minute, elle mène une découverte répétable et multi-experts qui interroge le pourquoi exprès, capte le raisonnement tacite comme un livrable de premier rang, et nourrit l'IA d'un brief qui contient déjà l'exception de Nathalie. L'agent rédige encore la spec en quatre minutes. La différence, c'est à partir de quoi il rédige. C'est le même écart qu'on a cartographié dans La fuite des connaissances, où le coût du savoir éparpillé et non documenté s'accumulait déjà avant que l'IA accélère tout.

Ce qui est capté : un prompt contre une conversation PROMPT D'UNE LIGNE « Copier la logique » Capte : la règle documentée Capte : le chemin heureux Manque : l'exception Manque : la raison du pourquoi Manque : le conflit non nommé DÉCOUVERTE STRUCTURÉE « Pourquoi ça existe? » La règle et la raison Les cas limites Les hypothèses contradictoires Le pourquoi, écrit Ça survit à la personne
Le prompt et la conversation partent de la même règle. Une seule des deux garde la raison une fois que la personne qui la portait est partie.

Capter la raison, pas juste la règle

L'IA efface le savoir de l'entreprise non par malice mais par omission. Elle enregistre fidèlement la règle documentée et laisse tomber en silence la raison tacite, parce que la personne qui détient la raison n'était jamais dans le prompt. La rédaction plus rapide des specs ne capte pas plus de savoir. Elle en capte moins, plus vite, en enlevant la conversation qui faisait sortir le pourquoi.

La solution, c'est pas de ralentir ou d'abandonner l'IA. C'est de remettre la découverte structurée devant elle, pour que l'agent rédige à partir d'un brief qui tient déjà les exceptions, les cas limites et le raisonnement que vos meilleurs employés portent. Demandez pourquoi avant qu'ils partent. Écrivez-le. Ensuite laissez l'IA aller aussi vite qu'elle veut, parce que là elle est vite et juste.

Nathalie est à la retraite, là. Quelque part, une nouvelle analyste fixe un rapport de rupture de stock, en essayant de rétroconcevoir une décision qu'elle a prise à l'instinct en 2019. Elle va y arriver un jour, à gros prix, comme la NASA est revenue au F-1. Ou quelqu'un aurait pu lui poser une question avant le mois de mars. C'est tout l'article. C'est tout le problème.

Quelles sont les questions les plus fréquentes sur l'IA et la rétention du savoir?

L'IA capte bien le savoir explicite : la règle documentée, le processus écrit, ce qui est déjà sur une page. Elle efface le savoir tacite en sautant la conversation qui l'aurait fait sortir. Quand l'exception durement apprise d'un employé senior vit seulement dans sa tête et dans ses habitudes, une IA qui rédige à partir d'un prompt d'une ligne n'a aucun moyen de poser la question. La règle est écrite. La raison derrière la règle disparaît. Les deux arrivent en même temps, et c'est pour ça que la perte passe inaperçue.
Le savoir tribal, c'est la compréhension non documentée et basée sur l'expérience qui vit dans les gens : pourquoi une exception existe, quel fournisseur est instable en fin de trimestre, ce qui a brisé la dernière fois que quelqu'un a changé un réglage. L'IA accélère sa perte parce que la rédaction plus rapide des specs raccourcit ou supprime les conversations de découverte où ce savoir sortait par accident. Une entrevue d'exigences de 90 minutes tombe parfois sur l'exception. Un prompt d'une ligne n'invite jamais la personne qui la détient.
Une IA rédige à partir de ce qu'on lui donne. Elle ne peut pas interviewer le superviseur qui n'est pas dans le prompt, et elle interpole à partir des patrons fréquents, mais une exception n'est par définition pas le patron. Le pourquoi derrière une exception est une histoire ancrée dans un incident précis, pas une donnée qu'un modèle peut prédire. Alors le modèle produit une spec propre de la règle documentée et omet en silence les conditions où la règle devrait être brisée, parce que personne ne lui a dit que ces conditions existaient.
La découverte structurée fait ressortir le raisonnement tacite, les cas limites, et les hypothèses contradictoires que différentes parties prenantes tiennent sans réaliser qu'elles ne s'entendent pas. Elle demande à l'employé senior pourquoi l'exception existe et note la réponse avant qu'il prenne sa retraite. L'intelligence des exigences mène cette découverte de façon répétable et multi-experts, et écrit le pourquoi à côté du quoi, alors le savoir survit à la personne. Un prompt capte une instruction. La découverte capte la compréhension. Voyez ce qu'est l'intelligence des exigences pour la méthode complète.
Ça peut, quand le temps sauvé vient du fait de sauter les conversations humaines qui captent le savoir. La recherche 2025 d'Atlassian a trouvé que 68 % des développeurs sauvent maintenant plus de dix heures par semaine avec l'IA, mais la même étude montre qu'ils perdent encore du temps à chercher de l'information qui n'a jamais été documentée. Des chercheurs de Microsoft et Carnegie Mellon ont trouvé que plus les travailleurs font confiance à l'IA, moins ils appliquent de pensée critique. Le temps sauvé n'est un gain que si on en réinvestit une partie dans la découverte qui capte le pourquoi.
Nicolas Payette, CEO et fondateur de Specira AI
CEO et fondateur, Specira AI

Nicolas Payette a passé 25 ans dans la livraison de logiciels d'entreprise, à mener des transformations numériques dans des entreprises comme Technology Evaluation Centers et Optimal Solutions. Il a fondé Specira AI pour régler la cause profonde de l'échec des projets : des exigences floues, pas du code lent.