On parle souvent de qualité du code, de couverture de tests ou d’architecture. Pourtant, l’un des plus grands risques d’un projet logiciel est souvent invisible : le savoir implicite.

Le savoir implicite, c’est tout ce que le code ne dit pas.

Pourquoi cette constante vaut-elle 17 ? Pourquoi cette boucle s’arrête-t-elle ici ? Pourquoi ce format de fichier est-il traité différemment ? Pourquoi ce test étrange ne doit-il surtout pas être supprimé ?

La réponse existe… mais uniquement dans la tête d’un développeur.

Le vrai coût de la dette technique

On réduit souvent la dette technique à un problème de conception ou de qualité du code. En réalité, une grande partie de cette dette est une dette de connaissance.

Lorsqu’un développeur quitte un projet, il emporte avec lui des centaines de décisions qui n’ont jamais été formalisées :

• les hypothèses de départ ;
• les compromis réalisés ;
• les limitations connues ;
• les raisons historiques d’un comportement.

Le projet continue de fonctionner… jusqu’au jour où quelqu’un modifie « le code bizarre » qui existait justement pour éviter un ancien problème.

Le commentaire ne suffit pas

Ajouter quelques commentaires n’est pas une solution.

Un commentaire explique ce que fait le code.

Le savoir implicite explique pourquoi il existe.

Cette différence est essentielle.

// Ne pas fusionner ces deux boucles.

Pourquoi ?

Parce qu’une ancienne version de LibreOffice produisait un ordre XML différent ?
Parce qu’un client utilisait un document non conforme ?
Parce que Word refuse ce cas particulier ?

Sans cette information, le commentaire est pratiquement inutile.

L’IA révèle un problème ancien

Les assistants de programmation ont rendu ce phénomène encore plus visible.

Une IA sait très bien reproduire un motif de code.

En revanche, elle ne peut pas deviner les décisions qui n’ont jamais été écrites.

Elle reproduit le visible.

Le savoir implicite, lui, reste caché.

Ce n’est donc pas un problème créé par l’IA : elle met simplement en lumière une faiblesse qui existait depuis toujours. Les travaux en génie logiciel soulignent d’ailleurs que la connaissance tacite reste une composante essentielle des projets et qu’elle ne peut pas être remplacée par la seule documentation technique.

Transformer l’implicite en connaissance

Chaque modification importante devrait répondre à quelques questions simples :

• Quelle décision a été prise ?
• Pourquoi cette solution plutôt qu’une autre ?
• Quelle hypothèse repose derrière ce code ?
• Qu’est-ce qui casserait si on le supprimait ?
• Existe-t-il une référence (bug, norme, spécification) ?

Ce sont souvent ces réponses qui manquent le plus quelques années plus tard.

Les projets libres ont une responsabilité particulière

Dans le logiciel libre, les contributeurs vont et viennent.

Le code reste.

Si le savoir ne reste pas avec lui, chaque nouvelle génération devra redécouvrir les mêmes problèmes.

C’est du temps perdu.

Documenter les décisions importantes n’est donc pas seulement écrire de la documentation : c’est transmettre une partie de l’intelligence collective du projet.

ODFStudio : rendre le logiciel explicable

Chez ODFStudio, nous pensons que l’avenir n’est pas seulement d’écrire du meilleur code.

Il est de rendre les décisions compréhensibles.

Un bon projet ne transmet pas uniquement des lignes de code.

Il transmet les raisons qui ont conduit à les écrire.

Car un logiciel qui ne conserve que son code finit toujours par perdre une partie de son histoire.