Le LLM écrit, le code fonctionne, personne ne comprend : pourquoi

Le code fonctionne, les tests sont au vert, tout le système est stable. Cela veut-il dire que la qualité est au rendez-vous ? Pas tout à fait. Il existe en fait une troisième dimension que personne ne suit : la compréhensibilité du code pour un humain.

Quand le code fonctionne mais reste incompréhensible

Un LLM écrit du code comme une machine le comprend. Les variables ont des noms logiques, la syntaxe est irréprochable, l'algorithme fonctionne. Mais pour un humain, lire ce code est un supplice. La logique est nouée, il y a des commentaires, mais ils n'aident pas à saisir l'essentiel.

Le modèle génère une documentation qui peut être volumineuse et décrire chaque paramètre, chaque fonction, chaque exception. Et pourtant, elle est totalement inutile pour répondre à la question principale : pourquoi tout cela a-t-il été écrit ?

Le problème n'est pas que le LLM ait été mal entraîné. Le problème, c'est que l'humain et le modèle pensent littéralement avec des mécanismes différents. Quand leurs savoirs se heurtent, on obtient exactement ceci : un code qui fonctionne parfaitement mais reste une boîte noire pour celui qui le lit.

Deux architectures de la compréhension

L'humain pense en structures : début, développement, fin. Un but, le chemin pour l'atteindre, un résultat. Pour lui, la complexité est un stress, une douleur. Plus la logique est embrouillée, plus la charge cognitive est lourde et plus le code est difficile à maintenir.

Un LLM fonctionne tout autrement. Le modèle prédit le token suivant à partir de probabilités. Ce n'est pas une structure, juste une suite d'étapes probabilistes. Pour le modèle, il n'y a pas de différence de principe entre un algorithme simple et un algorithme complexe : l'un comme l'autre n'est qu'une chaîne de tokens. Et surtout, la complexité ne lui fait pas mal. Ce ne sont que des données.

• L'humain cherche du sens et des régularités ; le modèle prédit des tokens
• L'humain s'embrouille devant un excès de détails sans le contexte de l'objectif
• Le modèle ne « comprend » pas au sens humain : il prédit
• Pour l'humain, la simplicité est un bienfait ; le modèle ne la remarque tout simplement pas

La documentation comme piège

Un modèle peut rédiger une documentation abondante : décrire chaque paramètre, chaque type de retour, chaque exception. Le code sera entièrement documenté. Et l'humain ne comprendra toujours pas pourquoi l'architecture a été choisie ainsi.

Car la documentation répond à la question « qu'est-ce que c'est », pas à la question « pourquoi ». On peut lire cinquante pages de description et rester complètement perdu quant à l'intention. Connaître tous les détails ne donne pas la compréhension de l'ensemble.

Personne ne remarque la perte de contrôle

Le plus effrayant dans cette histoire, c'est que personne ne remarque quand le contrôle est perdu. Le code fonctionne. Les tests passent. Le système est stable. Puis il faut soudain modifier quelque chose, ajouter une fonctionnalité, corriger un bug. Et l'on découvre que personne, pas même l'auteur du code, ne sait expliquer comment il fonctionne vraiment.

Dans le duo « humain + LLM », voici ce qui se passe : l'humain clique sur « approuver », le modèle considère sa tâche terminée (les tests sont au vert, après tout !), et pendant ce temps la compréhension s'érode lentement, imperceptiblement. Il n'y a pas de moment « stop, les ennuis commencent ». La perte de contrôle survient sans bruit, comme le crépuscule.

« Le code fonctionne, les tests sont au vert, donc tout va bien », pense l'humain en cliquant sur approuver.

Et il ne remarque pas que, ce faisant, la possibilité de modifier quoi que ce soit lui échappe.

Ce que cela signifie pour nous

Il faut de nouvelles métriques de qualité du code. Pas seulement « ça marche » et « les tests passent ». Il faut se demander : un humain peut-il le comprendre ? Peut-il le maintenir ? Peut-il le faire évoluer ? Sinon, chaque ligne de code deviendra un éclat qui fonctionne, mais dont le but est perdu.

Ce n'est ni un reproche aux développeurs ni une critique des LLM. C'est simplement la conséquence du fait que l'humain et le modèle parlent des langages de compréhension différents. L'un voit l'arbre entier, l'autre des branches isolées. Et quand ils travaillent ensemble, il reste entre eux un fossé où le sens disparaît.