VISION CEO — S1 • ARTICLE 2
Trois équivalents temps plein. C’est ce que votre structure dépense chaque semaine à reconstituer ce que votre IA devrait savoir.
— 7 min de lecture —
29% de vos collaborateurs trouvent difficile ou quasi-impossible d’extraire la connaissance dont ils ont besoin de vos dépôts numériques. C’est 50% de plus que ceux qui éprouvent les mêmes difficultés à simplement demander à un collègue. Traduction : votre repository numérique est structurellement plus difficile à naviguer que les personnes qu’il est censé remplacer.
Ce paradoxe a un nom. Deloitte le formule sans ménagement : “false sense of security.” L’entreprise qui a migré ses livrables dans SharePoint, Notion ou Confluence pense avoir résolu le problème de capitalisation. Elle a résolu un problème de stockage. Ce ne sont pas le même problème — et la confusion entre les deux explique pourquoi seulement 9% des organisations se sentent réellement prêtes à adresser leur gestion de la connaissance, quand 75% déclarent que c’est critique pour leur succès dans les douze prochains mois.
La deuxième mission chez ce client arrive dix-huit mois après la première. L’associé demande à son équipe d’utiliser la base de connaissance du cabinet avant le démarrage : capitaliser sur la mission précédente, ne pas réinventer ce qui a déjà été appris. Les livrables sont là, classés, taggés, accessibles. L’équipe retrouve le rapport de clôture, la présentation finale, le plan d’implémentation. Ce qu’elle ne retrouve pas : les tensions politiques cartographiées en mois trois, les décideurs informels identifiés, les angles d’intervention qui avaient fonctionné et les deux qui avaient échoué en silence. Ces apprentissages existent. Dans les notes de réunion archivées, dans les emails de fin de semaine, dans les commentaires de slides que le rapport final a comprimés jusqu’à l’effacement. Le système a retrouvé les documents. Il n’a pas activé la connaissance.
Ce que cette situation décrit n’est pas un problème d’organisation. C’est une différence d’architecture. Retrouver un document suppose de savoir qu’il existe et comment le nommer. Activer la connaissance, c’est autre chose : c’est l’information pertinente qui arrive parce que la situation l’appelle pas parce que vous avez formulé la bonne requête. Cet article pose la distinction, nomme ce qu’elle coûte, et décrit les propriétés qui séparent un index d’une architecture de connaissance.
⸻
La fausse sécurité de la digitalisation
Il y a deux questions que personne ne pose après une migration de livrables. Première question: “Mes agents peuvent-ils activer cette connaissance sans savoir ce qu’ils cherchent ?” Deuxième question : “Cette connaissance est-elle structurée par problème client ou par format de document ?”
Ces questions n’apparaissent dans aucune checklist de déploiement SharePoint. Elles ne font partie d’aucun critère de succès d’un projet Notion. Résultat : des dépôts bien rangés, des conventions respectées, des métadonnées soignées — et des agents qui cherchent “retour d’expérience transformation managériale” et ratent le document intitulé “Post-mortem mission ACME, Friction DRH-CODIR.” Le document existe. L’agent ne sait pas qu’il l’appelle, parce que personne n’a créé le lien entre le problème et sa trace.
L’écart entre les organisations qui ont résolu ce problème et celles qui ne l’ont pas fait n’est pas subtil. Deloitte mesure 80% d’accès facile à la connaissance chez les premières, contre 51% chez les secondes, 29 points d’écart directement attribuables à une décision d’architecture, pas à la qualité de la migration ou à la plateforme choisie. McKinsey chiffre l’autre versant : les organisations avec des pratiques de knowledge management structurées réduisent le temps perdu en recherche de 35% et gagnent 20 à 25% de productivité. L’écart n’est pas entre ceux qui ont digitalisé et ceux qui ne l’ont pas fait. Il est entre ceux qui ont activé et ceux qui ont indexé.
⸻
Retrouver n’est pas activer
La distinction est opérationnelle. Le retrieval retrouve un document si vous savez qu’il existe et si vous connaissez les termes qui le désignent. L’activation contextuelle livre la connaissance pertinente au moment où la situation l’exige, sans requête explicite, sans que vous ayez identifié que la connaissance existe ou qu’elle s’applique à votre problème du moment.
Ces deux opérations n’ont pas la même valeur pour un cabinet de conseil. La première est utile quand vous savez chercher. La seconde est utile quand vous ne savez pas ou quand vous ne savez pas que vous ne savez pas. C’est précisément là que vit la majorité de la connaissance différenciante d’un cabinet : dans ce que des années de missions ont construit, et que personne ne pense à chercher parce que personne ne sait exactement où ça réside.
La conséquence est mesurée sur des données terrain. Dans un déploiement documenté sur 67 ingénieurs (Bakal, arXiv 2026), l’introduction d’une architecture de connaissance activable par opposition à un système de retrieval a libéré 2,6 heures par ingénieur et par semaine. Le NPS interne a progressé de 35 points. Ces chiffres ne mesurent pas un moteur de recherche amélioré. Ils mesurent l’élimination d’une taxe invisible : le temps que les profils expérimentés passaient à fournir manuellement ce que l’architecture ne livrait pas. Quand un agent ou un consultant junior rencontre une tâche sans contexte institutionnel, le résultat est prévisible approximations, cascades de corrections, et une charge disproportionnée sur les Partners qui doivent reconstituer manuellement ce que le système n’active pas.
Transposé à un cabinet de 50 consultants : 130 heures par semaine libérées. L’équivalent de trois équivalents temps plein actuellement consommés à reconstituer ce que la couche connaissance devrait activer.
⸻
Ce que votre architecture de connaissance doit faire — et ne fait probablement pas
Le diagnostic est simple. Posez cette question à votre système de connaissance actuel : “Quels patterns avons-nous observés sur ce type de transformation chez ce type de client ?” Ce que le système retourne est la définition exacte de ce que vos agents peuvent faire. Si la réponse est une liste de documents classés par date et par format, la fondation manque.
Trois propriétés distinguent une architecture de connaissance d’un index :
La connaissance est structurée par problème client, pas par format de document. Quand une mission similaire arrive, l’architecture active les patterns de missions antérieures pas une liste de rapports classés par type. La note de terrain “Friction DRH-CODIR dans les transformations post-fusion” est liée à toutes les missions où ce problème s’est posé, indépendamment de leur titre ou de leur date.
Les connexions entre missions, clients, secteurs sont explicites. Un agent qui prépare un brief sur une transformation dans le secteur assurance peut activer les apprentissages de missions similaires dans des secteurs adjacents sans qu’un humain ait établi le lien à la main.
La connaissance est activée sans requête explicite. Ce n’est pas une réponse à une recherche. C’est l’information pertinente qui arrive parce que le contexte la rend nécessaire.
Tesfaye et al. (Springer 2026) posent le prérequis technique de ces trois propriétés : les systèmes IA ont besoin d’une connaissance “granular, self-describing, consistent, and structurally complete.” Seulement 8% des organisations ont aujourd’hui les pratiques pour scaler l’IA — et la raison principale n’est pas le modèle ni la plateforme : c’est l’absence d’une stratégie de structuration de la connaissance.
Les quatre impasses que tout cabinet rencontre dans l’ordre, une fois que la question est ouverte. Indexer les documents sans structuration par problème : l’agent récupère le livrable entier quand il cherche une clause ou un pattern. Ne pas segmenter la connaissance par domaine métier : le bruit cross-domaine dilue les scores de pertinence, les apprentissages sectoriels restent invisibles. Externaliser les embeddings via une API tiers : la connaissance propriétaire du cabinet quitte le périmètre de contrôle — les données contractuelles et clients sont envoyées à l’extérieur pour être indexées. Ne pas gouverner l’index : les livrables modifiés ne sont pas ré-indexés, les agents naviguent sur une représentation périmée de ce que le cabinet sait.
Ce schéma ne dépend ni de la taille du cabinet ni du secteur. Il dépend d’une seule décision : est-ce que la connaissance est structurée pour être retrouvée, ou pour être activée ?
⸻
Ce que ça coûte de ne pas l’avoir résolu
MIT CISR (721 organisations) mesure une perte de 12,6 points de croissance sectorielle pour les organisations qui ont investi dans les outils IA sans résoudre la fondation de connaissance. Ce n’est pas une performance décevante. C’est une pénalité active. Chaque déploiement IA posé sur un index plutôt que sur une architecture ne produit pas un ROI différé, il amplifie le désordre existant à une vitesse supérieure, et creuse l’écart avec les concurrents qui ont commencé par les fondations.
Bain le formule comme priorité non négociable avant tout déploiement agentique : “getting core data and knowledge in order.” Pas le modèle. Pas la plateforme d’agents. La connaissance.
La bifurcation visible dans dix-huit mois se joue dans des décisions qui semblent mineures aujourd’hui : la façon dont une mission est clôturée, la structure dans laquelle un apprentissage est capturé, la décision de lier une observation à toutes les missions où elle serait pertinente. Les cabinets qui font ces choix maintenant créent un effet de composition chaque mission enrichit la base de connaissance, chaque enrichissement rend la prochaine mission plus précise. Les cabinets qui ne les font pas continuent de refacturer ce qu’ils ont déjà appris.
⸻
Dans six mois, votre concurrent n’interrogera plus ses livrables. Il activera sa connaissance de cabinet sur l’appel d’offre que vous avez tous les deux reçu ce matin. La différence entre retrouver et activer se mesure en taux de transformation, pas en investissement technologique.
⸻
Matthieu Riboulet Directeur Conseil · Delivery · Infrastructure cognitive · IA agentique | COO Fast IT Société Générale (2014–2017) · Talan Labs (2017–2024)
Prochain article : « Quand votre Partner senior part, il emporte avec lui la mémoire de 10 ans de missions » (VC-06, 2026-06-17)