Les LLM sont une architecture de transition

Les grands modèles de langage impressionnent d’abord par leur gaspillage. Pour chaque token, des milliards d’opérations matricielles. Puis autant pour le suivant. Le cache KV évite de tout recalculer. Les architectures à experts n’activent qu’une fraction des poids. L’ordre de grandeur, lui, ne bouge pas. Face à ce régime, la notation de complexité n’éclaire plus grand-chose.

Ce constat est juste. Il ne mène pas où l’on croit. La limite décisive des LLM n’est pas leur coût. C’est leur rigidité.

Le procès en inefficacité vise une cible mouvante

L’argument de l’inefficacité vieillit mal parce qu’il mélange deux dynamiques distinctes.

À qualité constante, le coût unitaire d’un token recule d’année en année. Andreessen Horowitz a baptisé le phénomène LLMflation en novembre 2024 : une division par dix tous les ans, soit un facteur mille en trois ans pour une qualité équivalente à GPT-3. La pente est moins raide au niveau GPT-4, faute de recul, mais la direction ne fait pas débat. Distillation, quantification, activation parcimonieuse et silicium spécialisé font leur travail, et les modèles à poids ouverts ont transformé ce suffisamment bon à prix cassé en arme commerciale.

Ce qui explose, ce n’est pas ce coût unitaire. C’est le volume d’usage, et le prix des entraînements de frontière. Confondre les deux fausse le débat public.

Le parallèle avec le cerveau demande la même prudence. On aime opposer la force brute du modèle à l’élégance du vivant. Or cent mille milliards de synapses qui déchargent en parallèle, c’est aussi de la force brute. La différence tient à un chiffre : une vingtaine de watts. L’argument honnête porte sur l’efficacité énergétique, pas sur la nature du calcul.

Le cerveau, surtout, ne part pas de zéro. Il hérite d’une architecture sélectionnée sur des centaines de millions d’années. C’est une forme de pré-entraînement autrement plus coûteuse que quelques mois de GPU. Il lui faut ensuite une quinzaine d’années de données pour devenir opérationnel. Comparer un modèle sorti d’un run d’entraînement à un cortex adulte, c’est comparer un produit fini à un organisme qui n’a jamais cessé d’apprendre.

La vraie faiblesse : des poids figés

Voici ce qui sépare réellement les deux systèmes.

Le cerveau est une machine à apprendre en continu. Il teste, observe le résultat, le compare aux précédents, généralise, renforce physiquement les chemins les plus empruntés, élague ce qui est ancien ou faux. En boucle, sans interruption, pendant toute une vie.

Le LLM sort de l’entraînement avec des poids gelés. Il ne s’optimise pas à l’usage. Ce qu’on lui apprend dans une conversation disparaît à la fin de la conversation. Le fine-tuning et les mémoires externes, comme le fichier MEMORY.md que Claude Code entretient de lui-même, contournent le problème. Ils ne le résolvent pas. La nuance compte : pour beaucoup d’usages, un contexte de travail persistant suffit, et l’illusion d’apprentissage qu’il procure est tout à fait fonctionnelle. Mais une mémoire est une donnée relue à chaque requête, pas une compétence acquise. Le modèle est mieux informé, il n’est pas devenu meilleur. Un agent de codage rouvre votre dépôt chaque matin comme s’il ne l’avait jamais vu. Et dès qu’on modifie sérieusement les poids d’un modèle déjà entraîné, on dégrade ce qu’il savait. C’est l’oubli catastrophique. L’apprentissage continu reste un chantier ouvert.

Un système incapable d’apprendre de son propre usage n’est pas une architecture définitive. C’est, par construction, une étape intermédiaire.

Générer token après token n’interdit pas de planifier

Il est tentant d’en conclure que la réponse est simplement devinée au fil de l’eau, sans structure ni intention. C’est inexact, et l’affirmer affaiblit la critique.

Les travaux d’interprétabilité des dernières années montrent que l’état interne du modèle, avant même l’émission du premier token, encode déjà une part significative de ce qui va suivre. Dans Tracing the thoughts of a large language model (Anthropic, mars 2025), les chercheurs partaient de l’hypothèse inverse et l’ont vue démentie : sur des tâches contraintes comme la rime, on observe des circuits qui sélectionnent le mot cible plusieurs mots à l’avance, puis construisent la phrase pour y arriver. Le décodage est séquentiel. La planification ne l’est pas entièrement.

Cela ne veut pas dire que le modèle comprend au sens où nous l’entendons. Un refus, une conviction apparente, restent des directions dans un espace vectoriel qu’un bistouri logiciel sait retirer. Cela veut dire que l’image du perroquet qui tire au sort le mot suivant est dépassée. S’appuyer dessus expose l’argument à une réfutation facile.

Un retour au symbolique ne suffira pas

L’intuition naturelle, quand on vient du développement logiciel, est de remplacer ces probabilités par une base de connaissances structurée et partagée. Un système qui saurait vraiment ce qu’il manipule.

Cette voie a déjà été explorée en profondeur. C’est l’IA symbolique, les systèmes experts, le projet Cyc et ses décennies d’encodage manuel du savoir humain. Elle a perdu face aux approches statistiques, et pas par accident. Richard Sutton en a tiré une leçon désagréable mais robuste, The Bitter Lesson : à chaque génération, la méthode qui exploite la puissance de calcul disponible finit par battre celle qui encode l’expertise à la main.

La leçon vient d’ailleurs de se répéter sous nos yeux. Les modèles de raisonnement, de o1 à DeepSeek-R1, ne dépensent plus le calcul seulement au pré-entraînement mais au moment de la réponse, en explorant plusieurs pistes avant de trancher, et cette délibération interne a été apprise par renforcement, pas dictée. C’est la Bitter Lesson appliquée une seconde fois, cette fois à l’inférence.

L’ironie veut que la plus grande base de connaissances partagée jamais construite, Wikipédia, perde ses lecteurs humains au moment même où elle est la source la plus citée par les modèles qu’elle a nourris. Quiconque propose aujourd’hui un retour à la base de connaissances doit répondre à cet argument. Sinon, la proposition est classée d’emblée : déjà tentée, déjà échouée.

Le bon clivage n’est pas statistique contre symbolique. C’est la vérifiabilité.

Là où l’intuition mérite d’être reprise, c’est sur l’articulation entre le probabiliste et le déterministe. Mais pas dans le sens qu’on imagine.

On se représente volontiers un hybride où le LLM discute avec l’humain, formalise une demande, et la transmet à un moteur qui, lui, saurait ce qu’il fait. Le problème est que ce moteur n’existe pas. Produire un programme non trivial à partir d’une spécification est le rêve de la synthèse de programmes et des méthodes formelles depuis cinquante ans. Il n’a jamais passé l’échelle industrielle. Le LLM est précisément ce qui manquait pour combler l’écart entre la spécification et l’implémentation.

L’hybride existe donc déjà, mais dans l’autre sens. La partie déterministe n’est pas en aval. Elle est dans la boucle, et elle ne génère rien : elle vérifie. Le modèle propose. Le compilateur, le typeur, la suite de tests et le prouveur formel tranchent. Le modèle recommence. C’est ce que font les agents de codage actuels. C’est aussi ce qui a permis à AlphaProof, adossé au vérificateur Lean, de décrocher une médaille d’argent aux Olympiades de mathématiques.

D’où le renversement. Le code n’est pas le domaine où les LLM sont le plus faibles. C’est celui où ils sont le plus fiables, parce que c’est le seul où la sortie est vérifiable mécaniquement et immédiatement. Une hallucination dans du code se paie en erreur de compilation ou en test rouge. Une hallucination dans une note de synthèse ou un conseil juridique passe inaperçue et se propage. C’est aussi pour cela que le métier de développeur est le premier touché : pas parce que le code est simple, mais parce qu’il se vérifie.

La bonne question n’est donc pas « LLM ou système structuré ». Elle est : qui vérifie ?

Là où un vérificateur mécanique existe, le probabiliste devient exploitable, parce que ses erreurs sont interceptées. Là où il n’en existe pas, on est livré aux probabilités sans filet. C’est là que le risque se concentre. Et le vérificateur ne se limite pas à la machine : quand plus personne ne lit le code qu’il déploie, le filet a beau exister, on l’a retiré soi-même.

L’embarqué n’a pas besoin de se réentraîner chaque semaine

Reste la question du déploiement. Les petits modèles locaux sur téléphone ont du sens : latence, coût, confidentialité, souveraineté des données. Ils arrivent. Apple loge vingt milliards de paramètres en mémoire flash et n’en active qu’une fraction à chaque requête. Pour qui veut garder ses données chez soi, l’inférence locale est devenue une option sérieuse, même en la payant trois fois.

En revanche, l’idée de les réentraîner fréquemment pour suivre l’actualité est un faux chemin. L’actualité ne se met pas à jour dans les poids. Elle se récupère au moment de la requête, par recherche ou indexation documentaire. Le modèle embarqué a vocation à rester petit, stable, et à raisonner sur des sources externes fraîches. Séparer le moteur de raisonnement du stock de faits est d’ailleurs la seule manière de rendre l’ensemble auditable. Ce n’est pas un détail quand on parle de souveraineté.

Ce que cela autorise, et ce que cela n’autorise pas

Les LLM ne sont pas une impasse. Le procès en inefficacité vieillira mal. Mais ce sont des systèmes figés par construction, incapables d’apprendre de leur propre usage, et dont la fiabilité dépend entièrement de l’existence d’un vérificateur externe.

C’est suffisant pour transformer l’industrie logicielle. Ce n’est pas suffisant pour être l’architecture définitive. Transition vers quoi ? Vers un système qui garde le vérificateur dans la boucle, qui dépense son calcul à chercher plutôt qu’à stocker, qui raisonne sur des représentations du monde plutôt que sur des suites de mots, et qui, surtout, apprend de ses propres erreurs au lieu de les répéter jusqu’au prochain entraînement. Les pistes existent, modèles du monde chez LeCun, apprentissage continu ailleurs. Mais personne, aujourd’hui, ne sait assembler l’étape d’après.