Parlons des LLM

La discussion autour des LLM suit un schéma désormais prévisible : d'un côté, des promesses de révolution industrielle comparable à l'électricité ; de l'autre, des accusations de simple effet de mode technologique. James Bennett, développeur web de longue date, choisit une troisième voie : appliquer aux LLM les outils analytiques que l'informatique s'est elle-même donnés, et notamment l'essai de Fred Brooks, No Silver Bullet, publié en 1986.

L'argument central de Brooks, rappelé ici en détail, distingue deux types de difficultés dans le développement logiciel : les difficultés accidentelles, liées aux limitations des outils et langages du moment, et les difficultés essentielles, inhérentes à la complexité conceptuelle de tout système logiciel — spécification, conception, test, coordination humaine. Brooks démontrait mathématiquement qu'aucune avancée ne peut promettre un gain d'un ordre de grandeur en productivité tant qu'elle n'attaque pas la difficulté essentielle. Or les LLM, dans leur usage actuel, accélèrent principalement la production de code — c'est-à-dire une activité qui, selon Brooks lui-même, représente une minorité du temps réel d'un projet logiciel. Il citait dans The Mythical Man-Month que cinq sixièmes du temps sont consacrés à autre chose qu'à l'écriture de code.

Les données empiriques mobilisées par Bennett corroborent ce cadre théorique. Le rapport DORA 2025 sur l'état du développement assisté par IA, souvent cité par les partisans des LLM, révèle en réalité une augmentation de la "delivery instability" — définie comme le taux de déploiements nécessitant une intervention immédiate ou provoquant des incidents en production — plus importante que les gains de throughput observés. Les gains de "productivité" et de "qualité du code" reposent sur des auto-évaluations subjectives, que l'étude METR de début 2025 a précisément montré comme peu fiables : les développeurs estimaient que l'IA les avait accélérés de 20 % alors que les mesures objectives montraient un ralentissement.

Le rapport CircleCI 2026 apporte des chiffres plus précis encore : le taux de succès des merges sur la branche principale est tombé à son niveau le plus bas depuis cinq ans, à 70,8 %, contre un benchmark recommandé de 90 %. Le temps de récupération après une rupture de branche principale a augmenté de 13 % en un an. Pour une équipe effectuant 500 changements par jour, CircleCI chiffre la perte à l'équivalent de douze ingénieurs à temps plein absorbés par le débogage et les déploiements bloqués.

Bennett examine également l'argument de la démocratisation de la programmation. L'idée qu'un utilisateur non technique pourrait décrire un besoin en langage naturel et recevoir un logiciel fonctionnel se heurte à une contradiction interne : les partisans eux-mêmes insistent sur le fait que l'usage efficace des LLM requiert des compétences préalables solides — conception logicielle, rédaction de spécifications techniques, orchestration d'agents, compréhension des architectures. Ces prérequis sont précisément ce qui manque à l'utilisateur non technique. Le risque inverse est peut-être plus grave : recevoir un résultat qui semble fonctionner, sans que les défauts structurels — fuites de données, modèles financiers incorrects, failles de sécurité — ne soient détectables sans expertise.

La question des workflows multi-agents, souvent présentée comme la réponse aux critiques, est abordée à travers l'exemple public du rebuild de Next.js par Cloudflare, réalisé avec une chaîne de revue automatisée LLM-sur-LLM. Le résultat initial ne pouvait pas faire tourner l'application par défaut et présentait des failles de sécurité documentées, notamment parce que les tests de régression couvrant des cas limites critiques n'avaient pas été portés — le LLM ayant considéré certaines fonctionnalités comme "couvertes" à tort.

La conclusion pratique de Bennett ne plaide pas pour un rejet des LLM, mais pour une hiérarchie des priorités : les organisations qui n'ont pas encore mis en place des fondamentaux solides — version control rigoureux, suites de tests complètes, intégration continue, développement itératif en petits lots — ont peu de chances d'absorber positivement l'accélération de génération de code que les LLM apportent. Les rapports DORA et CircleCI, y compris dans leurs conclusions favorables aux LLM, le confirment : les gains sont concentrés dans les équipes qui disposaient déjà de ces fondamentaux. Adopter des LLM sans cette base revient, selon les données disponibles, à dégrader plutôt qu'à améliorer la livraison logicielle.