Votre code, une mine de connaissances que personne n'exploite
Voici quelque chose qui devrait mettre mal à l'aise chaque CTO et développeur senior : la compréhension la plus sophistiquée de votre métier se trouve probablement uniquement dans votre code de production.
Un article de recherche récent de l'équipe de ServiceMatch explore une idée provocante. Ils affirment que les systèmes logiciels matures ne sont pas simplement des outils qui font tourner votre activité — ce sont des représentations exécutables de tout ce que votre organisation a appris sur cette activité. Le problème ? Ces connaissances se cachent à la vue de tous, verrouillées dans des dépôts que seuls les compilateurs et (parfois) les humains consultent.
Le Mythe de la Documentation
On est tous passés par là. Un nouvel ingénieur rejoint l'équipe et se retrouve face à un mur de pages Confluence, d'ADR et de Wiki. « Ça va te mettre à niveau », dit quelqu'un avec un optimisme certain.
Non.
La documentation capture ce que quelqu'un a jugé bon d'écrire, à un moment qui date peut-être de plusieurs années. Elle passe à côté des cas limites. Elle passe à côté des discussions qui ont eu lieu en réunion et qui ont façonné les décisions. Elle passe à côté de la logique métier qui a évolué au fil de milliers de commits, chacun cherchant à résoudre un problème concret.
Selon l'argument de Peter Naur en 1985 (oui, le même qui nous a donné la forme Backus-Naur), la documentation d'un programme ne peut jamais capturer pleinement la « théorie » derrière un système. La vraie compréhension vit dans les têtes des gens. Quand ces gens partent, la théorie part avec eux.
Mais voici ce qui rend la chose intéressante.
L'IA Change la Donne
L'argument de Naur portait sur deux types de lecteurs : les compilateurs (qui exécutent le code sans le comprendre) et les humains (qui le comprennent lentement et chèrement). L'impossibilité de raviver la documentation supposait qu'aucun autre type de lecteur n'existait.
Les grands modèles de langage sont un troisième type de lecteur. Et ils sont étonnamment bons pour reconstruire les théories implicites encodées dans le code.
Le système ServiceMatch en apporte la preuve. Leur plateforme CMDB encode des connaissances en gestion de configuration d'entreprise qui rempliraient des volumes si elles étaient écrites en prose. Mais вот le problème — c'est déjà écrit, juste pas en prose. C'est dans le code.
Prenons leur logique de résolution d'identité. Plutôt qu'un essai de consultant sur « comment fonctionne l'identité des appareils », ils ont un fichier de configuration avec des pondérations : numéro de série (25), hostname (25), asset tag (25), adresse IP (20), adresse MAC (15). Plus des seuils de confiance et des règles de résolution de conflits. Chaque chiffre représente un argument que quelqu'un a gagné. Chaque type de conflit représente un incident réel qui s'est produit quelque part.
Ce n'est pas une description de la politique. C'est la politique elle-même, qui s'exécute chaque nuit contre de véritables parcours enterprise.
Ce Que Ça Signifie pour Votre Équipe
Pour les développeurs et les responsables techniques, cette recherche a des implications pratiques :
Votre code est une documentation que vous n'avez jamais maintenue — et ça a ses avantages. Contrairement aux pages Wiki poussiéreuses, le code qui tourne en production est constamment validé. Si la documentation est en désaccord avec le code, c'est la documentation qui a tort.
Les outils IA s'améliorent pour extraire ces connaissances. Nous avançons vers un monde où demander à une IA « comment on gère les conflits d'identité d'appareils » pourrait retourner non seulement de la documentation, mais le raisonnement réel encodé dans les pondérations et les seuils.
Les vraies connaissances vivent dans les cas limites. Les flux principaux sont généralement bien documentés. C'est le traitement spécial, les exceptions, les cas particuliers résolus au fil des ans qui contiennent le savoir institutionnel profond.
Le Signal d'Alerte
Il y a un corollaire inconfortable à tout cela : si votre logique métier est uniquement dans votre code, et que votre code a une mauvaise couverture de tests, des noms obscurs ou une structure chaotique, vous êtes assis sur un tas de connaissances presque impossibles à extraire.
L'équipe de ServiceMatch a découvert que leur affirmation — « le dépôt suffit » — s'effondre de manière prévisible. Le résidu tacite de Naur est réel. Certaines connaissances vivent vraiment uniquement dans les têtes des gens.
Mais la conclusion la plus forte est que plus de choses survivent dans le code qu'on ne le pensait. Le dépôt capture bien plus de théorie que la documentation ne pourrait jamais le faire — il fallait juste un nouveau type de lecteur pour l'extraire.
Quoi Faire Avec Ça
Si vous êtes une startup ou une entreprise tech en croissance, voici un cadre de réflexion :
- Faites plus confiance à votre code qu'à vos docs quand les deux ne sont pas d'accord
- Écrivez du code qui documente son raisonnement — des noms de variables explicites, des fonctions claires, des commentaires qui expliquent POURQUOI, pas juste QUOI
- Considérez la configuration comme un savoir institutionnel — ces pondérations et seuils sont des décisions qui valent le coup d'être préservées
- Commencez à explorer les outils IA qui peuvent interroger votre base de code comme source de connaissances
Le code que vous écrivez aujourd'hui est le savoir institutionnel de demain. Faites en sorte que ça compte.