Capital intellectuel et connaissances¶

Une DSI qui ne capitalise pas perd sa mémoire à chaque départ — et avec elle, des années de décisions, de contexte et d'expertise opérationnelle.

Pourquoi la connaissance est l'actif le plus fragile de la DSI¶

Un serveur tombe, on le remplacé. Une base de données est corrompue, on restaure. Un collaborateur senior part avec dix ans de connaissance tacite sur l'architecture legacy — rien ne la restaure. La connaissance est le seul actif de la DSI qui ne se sauvegarde pas automatiquement.

Les reorganisations, les départs, les projets de migration qui changent de porteur tous les six mois : chaque événement erode un capital que personne n'a pris le temps de consolider. Les symptomes sont reconnaissables : "Pourquoi ce choix technique a été fait en 2018 ?", "Qui connait encore ce module ?", "On a déjà essaye ca, mais personne ne sait pourquoi ca n'a pas marche."

La gouvernance des connaissances n'est pas une activité documentaire supplémentaire. C'est une discipline de management qui traite la connaissance comme un actif strategique avec un cycle de vie, une valeur et un risque de depreciation.

La pyramide DIKW¶

La pyramide DIKW (Ackoff, 1989) distingue quatre niveaux d'abstraction qui structurent la progression des données brutes vers la sagesse organisationnelle. Comprendre cette hiérarchie permet d'identifier ce qui merite d'être préservé et sous quelle forme.

Données¶

Les données sont des faits bruts, non contextualisés. Elles existent sans interpretation. En contexte IT, ce sont les logs applicatifs, les métriques système, les traces d'événements.

Exemple : 2024-03-15T03:42:11Z ERROR connection_pool timeout after 30000ms

Ce log est une donnée. Sans contexte, il ne permet aucune décision.

Information¶

L'information est une donnée mise en relation avec un contexte qui lui donne du sens. Elle répond aux questions "qui", "quoi", "quand", "ou".

Exemple : après agrégation, le taux d'erreur du connection pool de la base orders est passe de 0.1% a 12% entre 03h40 et 03h55 le vendredi 15 mars — correlé avec un pic de charge de 3x le trafic normal sur l'endpoint /api/checkout.

L'information est actionnable à court terme : l'astreinte peut diagnostiquer et intervenir.

Connaissance¶

La connaissance est de l'information structurée et intégrée dans un système de comprehension. Elle répond a "comment" et "pourquoi". Elle permet d'anticiper et de generaliser.

Exemple : "Notre pool de connexions sature systematiquement lors des pics de charge sur checkout parce que les requêtes imbriquees vers le service de stock ne sont pas limitees. La solution passe par un semaphore ou un circuit breaker côté service orders, pas par l'augmentation du pool."

Cette connaissance est le fruit de l'expérience accumulee. Elle ne se lit pas dans un log — elle se construit par l'investigation, le raisonnement et la mémoire des incidents passes.

Sagesse¶

La sagesse est la capacité a appliquer la connaissance dans des contextes nouveaux, a faire les bons arbitrages sans avoir vu le problème exact auparavant.

Exemple : le DSI qui dit "ne scaler pas le pool, regardez d'abord les appels en cascade" sans avoir vu le ticket — parce qu'il a internalisé un pattern après des années d'incidents similaires.

La sagesse est la forme la plus precieuse et la plus difficile à transferer. Elle est souvent ce qui part avec les seniors.

Applications IT de la pyramide DIKW¶

Connaissances tacites et explicites¶

La distinction fondamentale de la théorie de la connaissance est due a Michael Polanyi (1966) : "We can know more than we can tell." Il existe des formes de connaissance que nous possedons et appliquons sans pouvoir les articuler complètement.

Connaissance explicite¶

La connaissance explicite est formalisable, transmissible par l'écriture, le code, les diagrammes. Elle peut être stockee, indexee et reproduite.

En contexte DSI :

• La documentation d'architecture
• Les runbooks opérationnels
• Le code source avec ses commentaires
• Les décisions d'architecture (ADR)
• Les procédures d'installation et de configuration

La connaissance explicite est accessible mais fragile sur un autre plan : elle se dégradé vite si elle n'est pas maintenue. Une procédure de déploiement écrite en 2021 pour une version deprecated est pire que pas de procédure — elle induit des actions incorrectes.

Connaissance tacite¶

La connaissance tacite est incarnee dans l'expérience et les reflexes. Elle ne s'exprime pas facilement en mots. C'est le "feeling" du dev senior qui sait d'un coup d'oeil qu'une requête SQL va poser problème, ou l'instinct de l'ingénieur infra qui entend une alerte et dit "ca ressemble a un problème réseau inter-zones, pas applicatif".

En contexte DSI, la connaissance tacite inclut :

• La comprehension intuitive des comportements anormaux du système
• La mémoire des échecs passes et leurs patterns ("on a déjà essaye, voila pourquoi ca n'a pas marche")
• La connaissance des personnes ("pour ce problème, c'est Untel qu'il faut appeler")
• Le jugement sur les estimations ("cette estimation de 2 jours est irrealiste pour ce composant")
• La navigation dans le système legacy ("ce comportement est voulu, il compense un bug de la version 3.2")

L'asymétrie du capital tacite dans les DSI¶

Les DSI accumulent des asymétries de connaissance tacite importantes : un ou deux profils concentrent la comprehension du système dans sa globalite. Ce phenomene est parfois valorise ("on a X, il connait tout") mais il est en réalité un risque opérationnel majeur. Le bus factor — combien de personnes doivent être absentes pour paralyser un domaine — est l'indicateur de cette fragilite.

Le modèle SECI de Nonaka¶

Le modèle SECI (Nonaka et Takeuchi, 1995) décrit la création de connaissance organisationnelle comme un processus cyclique de conversion entre les formes tacite et explicite. Il reste le cadre de référence le plus opérationnel pour structurer une démarche de capitalisation.

quadrantChart
    title Modele SECI — Creation de connaissance organisationnelle
    x-axis Connaissance Tacite --> Connaissance Explicite
    y-axis Connaissance Explicite --> Connaissance Tacite
    quadrant-1 Externalisation
    quadrant-2 Combinaison
    quadrant-3 Socialisation
    quadrant-4 Internalisation
    "Post-mortem blameless": [0.25, 0.75]
    "Pair programming": [0.15, 0.25]
    "ADR rediges": [0.75, 0.75]
    "Runbooks": [0.85, 0.65]
    "Formation": [0.75, 0.3]
    "Pratique autonome": [0.85, 0.2]

Socialisation — Tacite vers Tacite¶

La socialisation est la transmission directe de connaissance tacite par observation, imitation et pratique commune. Elle ne passe pas par l'écriture.

En DSI : le pair programming, le shadowing d'un senior sur un incident, la résolution collaborative d'un problème complexe, le mob programming. Le junior apprend non pas en lisant une documentation mais en observant comment le senior formule les hypothèses, utilise ses outils, interprété les signaux.

La socialisation est efficace mais ne scale pas : elle dépend de la proximite physique ou d'interactions synchrones denses.

Externalisation — Tacite vers Explicite¶

L'externalisation est la formalisation de connaissance tacite en forme explicite. C'est la phase la plus difficile et la plus critique — celle que les organisations negligent le plus.

En DSI : les post-mortems blameless qui capturent non seulement ce qui s'est passe mais pourquoi les décisions ont été prises ainsi, les ADR (Architecture Décision Records) qui documentent le contexte et les alternatives rejetees, les sessions de "knowledge harvesting" avant un départ. La valeur d'un ADR n'est pas de documenter la décision — c'est de capturer le raisonnement qui a conduit à cette décision.

Combinaison — Explicite vers Explicite¶

La combinaison est la création de nouvelle connaissance explicite par agrégation et structuration de connaissances explicites existantes.

En DSI : la consolidation de post-mortems individuels en un guide des patterns d'incidents fréquents, la synthèse de plusieurs ADR en une charte d'architecture, la création d'un catalogue de services à partir de fiches techniques dispersees, la génération automatique de documentation depuis le code.

Internalisation — Explicite vers Tacite¶

L'internalisation est l'absorption de connaissance explicite jusqu'à ce qu'elle devienne reflexe — le passage de "je sais qu'il faut faire X" a "je fais X naturellement".

En DSI : la pratique répétée à partir de runbooks jusqu'à ne plus avoir besoin de les consulter, la formation suivie de mise en pratique autonome, les exercices de simulation d'incidents (game days) qui transforment une procédure écrite en reflexe opérationnel.

Le capital intellectuel de la DSI¶

Le capital intellectuel est l'ensemble des actifs intangibles qui créent de la valeur. On distingue trois composantes interdependantes, formalisées notamment par Sveiby (1997) et le modèle Skandia.

Capital humain¶

L'ensemble des compétences, expertises, capacités d'innovation et expériences detenues par les individus. Il quitte l'organisation avec chaque départ.

En DSI, le capital humain inclut :

• L'expertise technique spécifique (les architectes qui connaissent le système distribué dans sa globalite)
• La connaissance métier des equipiers (le dev qui comprend les règles de gestion du domaine Facturation mieux que certains métiers)
• La capacité de résolution de problèmes complexes et inedits
• Le réseau de relations internes et externes

Le capital humain ne se géré pas par la documentation seule — il se géré par les politiques de rétention, de formation, de mentorat et de partage des responsabilités.

Capital structurel¶

Ce que l'organisation possédé independamment des individus : processus, outils, bases de connaissances, méthodologies, propriété intellectuelle, culture organisationnelle.

En DSI :

• La base de documentation technique (wikis, ADR, runbooks)
• Les bases de code et les librairies internes
• Les frameworks de gouvernance (processus de change, de revue d'architecture)
• Les outils et leur configuration (IaC, pipelines CI/CD)
• Les patterns établis et les conventions

Le capital structurel est le résultat de l'externalisation réussie du capital humain. Il peut être maintenu, versionne et transmis independamment des personnes.

Capital relationnel¶

Les relations avec les parties prenantes externes et internes qui créent de la valeur.

En DSI :

• Les relations avec les fournisseurs strategiques et leur niveau de confiance
• Les partenariats avec les directions métier (crédibilité, capacité d'influence)
• La reputation de l'équipe vis-à-vis des parties prenantes
• Les réseaux professionnels (communautés, conferences, partenaires technologiques)

Le coût de la perte de connaissances¶

La perte de connaissances a un coût réel, même s'il est rarement mesure directement. Les études sur le sujet (DeLong, 2004 ; Dalkir, 2011) identifient plusieurs catégories de coût.

Le bus factor comme indicateur de risque¶

Le bus factor (ou "truck factor") est le nombre minimal de personnes qui doivent quitter l'organisation pour qu'un domaine devienne inoperable. Un bus factor de 1 signifie qu'une seule absence suffit à paralyser le domaine.

Dans les DSI, les bus factors critiques se trouvent systematiquement sur :

• Les systèmes legacy dont la comprehension est concentree sur un ou deux profils
• Les integrations complexes avec des partenaires ou des systèmes externes
• Les procédures d'urgence qui ne sont documentees que dans la tete de l'astreinte historique
• Les secrets de configuration et d'infrastructure non versionnes

Calculer le bus factor par domaine est un exercice de cartographie du risque. Un bus factor inférieur à 3 sur un composant critique doit déclencher un plan de transfert, independamment des intentions de départ des personnes concernees.

Les départs et reorganisations¶

La mobilite interne et externe est la cause principale de perte de connaissances. Chaque départ emporte une portion de capital humain que la documentation n'a jamais capturee. Les reorganisations sont souvent encore plus destructrices : elles brisent les réseaux informels de partage, dispersent les équipes qui avaient développé une mémoire collective, et coupent les fils de continuité sans ceremonies formelles de transfert.

Une étude de DeLong (2004) estime qu'un départ senior coute entre 50% et 200% du salaire annuel en pertes de productivité liees au transfert — sans compter le capital perdu qui ne se transfere jamais.

La perte de contexte historique¶

Les décisions techniques s'accumulent et forment un corpus de choix interdependants. Chaque décision avait un contexte : une contrainte technique, une limitation temporaire, un compromis acceptable à ce moment. Quand ce contexte est perdu, les décisions paraissent arbitraires, incomprehensibles, voire incorrectes. Les nouvelles équipes les remettent en cause sans disposer de l'information pour les évaluer correctement.

Ce phenomene explique les cycles de rewrite : une équipe nouvelle qui ne comprend pas pourquoi le code est organisé ainsi décidé de tout reecrire, reproduit les mêmes erreurs, et laisse a ses successeurs un code egalement incomprehensible.

Applications DSI : les trois zones de perte critique¶

La connaissance tacite dans le code¶

Le code source contient deux types d'information : ce qu'il fait (lisible dans le code lui-même avec de bonnes pratiques de nommage) et pourquoi il le fait ainsi (rarement lisible, rarement documente).

Les zones de perte critique :

• Les workarounds de bugs tiers ("ce +1 compense un off-by-one dans la version 2.3 du SDK")
• Les optimisations dont le contexte n'est plus valide mais dont on ne sait pas si on peut les retirer
• Les flags de feature jamais nettoyes dont la semantique originale est oubliee
• Les conditions d'erreur exceptionnelles qui ne se déclenchent que dans des scenarios rares et non testés

Les décisions d'architecture non documentees¶

Les ADR (Architecture Décision Records) sont le format le plus efficace pour capturer les décisions architecturales avec leur contexte. Mais la plupart des DSI n'en ont pas, ou n'en ont que pour les décisions récentes.

Les décisions les plus critiques a documenter ne sont pas les plus récentes — ce sont les plus anciennes, celles qui conditionnent tout le reste et dont personne ne se souvient plus du contexte d'origine.

Un ADR efficace capture : le contexte (forces, contraintes, état du système à ce moment), les options envisagees, la décision retenue, et — plus important — les raisons pour lesquelles les alternatives ont été ecartees.

L'expertise opérationnelle non transferee¶

L'expertise de l'astreinte senior est souvent la plus fragile. Elle se manifeste dans :

• La capacité a diagnostiquer rapidement à partir de signaux ambigus
• La connaissance des interactions non documentees entre composants
• Le jugement sur la sévérité d'une situation ("ca peut attendre le matin" vs "on appelle maintenant")
• Les contacts humains a activer selon le type de problème

Les runbooks documentent les procédures connues. Ils ne capturent pas le raisonnement diagnostique face à une situation nouvelle. Ce gap ne se comble que par des game days, des simulations d'incidents et une rotation délibérée des astreintes pour elargir la base d'expérience.