La lenteur logicielle n'est pas réglée

Ce qui se passe

L'argument a beaucoup circulé cette semaine, porté notamment par Dan Luu : les modèles de langage font tomber le coût du travail de performance de plusieurs ordres de grandeur, donc les optimisations qu'on ne se payait pas vont devenir courantes. Le blog typesanitizer.com publie une réponse détaillée. Son intérêt n'est pas de dire « c'est faux » — l'auteur se déclare favorable au travail de performance et en fait lui-même — mais d'attaquer la structure du raisonnement.

Le raisonnement mis à plat

L'argument, réduit à sa charpente :

1. une propriété désirable X coûtait A, au-dessus du budget B ;
2. avant les LLM, on ne visait pas X parce que A dépassait B ;
3. après les LLM, X coûte A/N avec N très grand, donc A/N passe sous B ;
4. donc les équipes vont acheter X.

L'auteur ne conteste pas l'étape 3. Il conteste l'hypothèse implicite : que B soit resté le même. Et il donne cinq raisons de penser qu'il ne l'est pas. La démonstration se place même dans l'hypothèse la plus favorable — des acteurs rationnels dotés d'une information parfaite — pour montrer que ça coince quand même.

Les cinq objections

1. La tolérance au « pas X » monte. Le travail qui se faisait de manière synchrone se fait désormais en attendant une boucle d'agent. Ce déplacement déplace aussi le seuil d'acceptabilité : l'auteur, qui travaille sur les performances de Git dans un monorepo, note que les chiffres jugés normaux aujourd'hui auraient provoqué une grimace en 2022. L'exemple le plus parlant est l'autocomplétion : on la vantait précisément pour son retour instantané, et l'on s'est habitué à attendre une suggestion de modèle.

2. Le budget était nul dès le départ. Hors des entreprises tech qui paient bien et laissent de l'autonomie, la fonction logicielle est souvent perçue comme un centre de coût — parfois sans même d'intégration continue, avec une recette entièrement manuelle. Convaincre du retour sur investissement d'un travail de performance y demande un effort qui est probablement mieux employé ailleurs. Et l'entreprise peut très bien se porter : elle tient son marché par autre chose.

3. Le budget a été réduit après les LLM. C'est le point le plus direct : là où il existait — mettons une semaine par trimestre — il a souvent été absorbé par des délais resserrés, la hiérarchie attendant que tout prenne moins de temps grâce à l'outillage.

4. Le facteur de réduction N est surestimé. Implémenter une optimisation est une chose. La livrer dans un logiciel de production très utilisé en est une autre. Installer un garde-fou anti-régression en est une troisième, et le rendre fiable, rapide et stable une quatrième. S'ajoutent les coûts que le code ne montre pas : réorganiser des données déjà stockées dans un format inadapté sans casser les chemins de lecture et d'écriture existants — en supposant qu'on les connaisse tous — ou payer le temps de calcul nécessaire pour reproduire un bug qui ne se manifeste qu'une fois sur mille en intégration continue.

5. Le budget n'était pas la vraie raison. L'auteur propose de raisonner en priorité plutôt qu'en coût. Si le travail de performance était le sixième ticket d'une liste où l'on en traitait quatre par sprint, il restait indéfiniment sur le tableau, jusqu'à être annulé faute d'être jamais pris. Si l'on passe à douze tickets par sprint, la liste ne reste pas la même : d'autres éléments remontent du backlog. Qui ne parvenait pas à défendre la performance comme priorité avant n'y parviendra pas davantage maintenant.

Le passage le plus utile : relire les exemples

L'auteur revient sur deux réalisations citées à l'appui de la thèse adverse.

pgrust, une réécriture de Postgres en Rust aux excellents résultats sur ClickBench. En regardant le modèle de coût, il constate qu'il référence explicitement ClickBench, et que le corpus d'optimisation guidée par profil contient des requêtes conceptuellement identiques à celles du benchmark, à quelques noms et une constante près. Le diagnostic est net : surajustement au banc d'essai. Sur l'idée qu'on n'écrirait pas de JIT parce que c'est trop dur, il rappelle qu'Umbra, SingleStore, Redshift et Impala en embarquent — le générateur de code d'Umbra représentant environ 40 000 lignes.

FRE, le moteur d'expressions régulières produit par une boucle d'agent. Son propre README indique qu'il est surajusté aux bancs d'essai rebar et n'a pas de bonnes performances générales. Puis vient le chiffre qui fait mal : interrogé sur la taille des deux implémentations, un LLM estime 35 000 lignes pour rust-lang/regex et 670 000 pour fre. À titre de repère, le compilateur Go et sa bibliothèque standard réunis pèsent environ 680 000 lignes.

Ce que ça change

La conclusion de l'auteur est mesurée : il ne veut pas de logiciels plus lents, et il note que l'outillage de diagnostic n'a jamais été aussi bon. Il concède même qu'une part du sentiment de dégradation pourrait être une illusion de perception — le même biais qui fait croire à chaque génération que la moralité décline.

Mais l'observation qu'il glisse au passage est difficile à écarter : les harnais de codage livrés par les grands fournisseurs de modèles sont eux-mêmes lents et gourmands au regard de leurs fonctionnalités, et le temps de mise en route d'un MCP dépasse régulièrement celui d'une compilation incrémentale sur une base C++ de plusieurs millions de lignes.

La leçon dépasse la performance. Elle vaut pour les tests, la sécurité, l'accessibilité, la documentation — tout ce qu'on remettait à plus tard « faute de temps » : un coût qui baisse ne devient pas une dépense si personne ne l'autorise. Si vous comptez sur l'outillage pour rattraper une dette, la question à poser n'est pas « combien ça coûte maintenant » mais « qui décide de la priorité, et est-ce que cette personne a changé d'avis ».