L'angle mort de la performance : les agents IA écrivent du code lent

Le code a passé tous les tests. Le linter était propre. Le vérificateur de types était satisfait. La revue de code l’a approuvé. La fonction était 446 fois plus lente que nécessaire.¹

Codeflash, un outil d’optimisation des performances du code, a analysé deux pull requests générées entièrement par Claude Code : 76 000 lignes à travers un module de support du langage Java et une intégration de framework React.¹ Ils ont trouvé 118 fonctions présentant des problèmes de performance significatifs. Les ralentissements allaient de 3x à 446x. Le pire cas : une fonction d’extraction de types qui reparcourait un AST entier à chaque appel au lieu de mettre en cache le parcours. Comportement correct. Performance catastrophique.

Ce constat n’est pas une anomalie. SWE-fficiency, un benchmark de 498 tâches d’optimisation à travers des dépôts comme NumPy, Pandas et SciPy, a constaté que les agents LLM les plus performants atteignaient moins de 0,15x l’accélération qu’un développeur expert obtenait sur les mêmes tâches.² Une étude séparée testant Claude 3.5, OpenAI o1 et Llama 3.2 sur 26 codes de calcul haute performance a trouvé que Claude 3.5 atteignait une accélération de 1,02x sur l’optimisation séquentielle (fonctionnellement aucune amélioration) tout en produisant du code incorrect dans 30 % des cas.³ L’analyse de Codeflash de 100 000 fonctions open source a révélé que 90 % des optimisations suggérées par l’IA sont soit incorrectes soit n’apportent aucun bénéfice mesurable, et parmi les correctes, 73 % offraient des gains inférieurs à 5 %.⁴

La performance est la dimension que les outils de codage IA ne voient pas. Chaque porte de qualité standard (linters, vérificateurs de types, suites de tests, revue de code) valide la correction. Aucune ne valide l’efficacité. Le résultat : une taxe invisible sur chaque ligne de code généré par l’IA qui passe tous les contrôles et dégrade chaque système dans lequel elle entre.

En bref

Les agents IA écrivent du code correct mais lent. Codeflash a trouvé 118 problèmes de performance sur 76 000 lignes de sortie Claude Code, avec des ralentissements de 3x à 446x.¹ Les benchmarks académiques confirment le schéma : les LLMs atteignent moins de 0,15x l’accélération d’un expert sur les tâches d’optimisation.² La cause est structurelle : les données d’entraînement récompensent la correction, et les portes de qualité standard ne mesurent pas la performance. Pour dépasser cela, il faut une infrastructure de performance : des benchmarks aux côtés des tests unitaires, de la détection de patterns basée sur l’AST dans les hooks, et le profilage comme étape standard du workflow.

Points clés

Pour les développeurs individuels. Ajoutez time ou un profileur à l’étape de vérification après chaque fonction générée par l’IA dans un chemin critique. Le ralentissement de 446x a passé tous les tests et tous les linters. La seule porte qui l’aurait détecté est un benchmark. Considérez « ça fonctionne » comme nécessaire mais pas suffisant. Posez la question « à quelle vitesse ça fonctionne ? » comme suivi standard.

Pour les chefs d’équipe. La régression de performance est la forme invisible du Good-Enough Plateau. Le code généré par l’IA qui passe tous les tests fonctionnels crée un faux sentiment de complétude. Ajoutez des benchmarks de performance au CI aux côtés des tests unitaires. Les données de Faros AI montrent que les équipes assistées par l’IA complètent 21 % de tâches en plus tout en générant 9 % de bugs en plus.⁵ Les bugs de performance ne sont pas comptés dans ces 9 % parce que personne ne les mesure.

Pour les ingénieurs plateforme. Construisez la porte manquante. Les linters vérifient le style. Les vérificateurs de types vérifient les contrats. Les suites de tests vérifient le comportement. Rien ne vérifie la complexité algorithmique ni les caractéristiques d’exécution dans le pipeline CI standard. La détection de patterns basée sur l’AST (règles Semgrep, patterns ast-grep ou hooks personnalisés) peut détecter les anti-patterns de performance les plus courants : parcours redondants, mémoïsation manquante et copies inutiles.

À quoi ressemblent 118 bugs

L’analyse de Codeflash de deux PRs Claude Code fournit le jeu de données public le plus granulaire sur les problèmes de performance du code généré par l’IA.¹ Les deux PRs totalisaient 76 000 lignes : 52 000 pour le support du langage Java et 24 000 pour le support du framework React. Les deux étaient fonctionnels. Les deux passaient leurs suites de tests. Les deux contenaient du code qui se dégraderait sous une charge réelle.

Les causes racines se regroupent en quatre catégories :

Algorithmes inefficaces. La catégorie dominante. Une fonction convertissant des décalages d’octets en positions de lignes utilisait un parcours O(n) au lieu d’une recherche binaire O(log n) avec une table de correspondance précalculée. Le code était lisible. Les noms de variables étaient descriptifs. La logique était correcte. La classe de complexité était fausse.

Calcul redondant. Des fonctions qui re-parsaient, reparcouraient ou recalculaient des valeurs qui auraient pu être mises en cache. La recherche de fonctions utilitaires re-parsait le même fichier source à chaque appel. Un décorateur de mémoïsation aurait réduit le surcoût de 74x à zéro après la première invocation.

Mise en cache et mémoïsation manquantes. Étroitement lié au calcul redondant mais distinct en ce que les données étaient disponibles dans un scope plus large. L’extracteur de définitions de types parcourait l’AST complet à chaque fois au lieu de construire un index au premier accès. Le pattern : l’agent écrit chaque fonction de manière isolée sans considérer comment elle sera appelée dans une boucle.

Structures de données sous-optimales. Des parcours de listes là où des ensembles ou dictionnaires fourniraient une recherche O(1). Le vérificateur d’exports itérait à travers une liste pour tester l’appartenance. Une conversion en ensemble aurait éliminé entièrement le surcoût de 9x.

Pourquoi les agents produisent du code lent

L’angle mort de la performance n’est pas un bug dans un modèle particulier. La cause est structurelle, opérant à trois niveaux : données d’entraînement, critères d’évaluation et hypothèses de workflow.

Les données d’entraînement récompensent la lisibilité

Les LLMs apprennent à partir de la distribution du code dans leurs données d’entraînement. L’implémentation la plus courante de tout algorithme est la version naïve. Le code de tutoriels privilégie la clarté. Les réponses Stack Overflow privilégient la correction. Le code open source contient des versions optimisées pour la performance, mais elles sont surpassées en nombre par les implémentations directes de plusieurs ordres de grandeur.

Le pattern s’étend au-delà de la performance. Stanford a constaté que les développeurs assistés par l’IA écrivaient du code non sécurisé plus souvent dans quatre tâches de sécurité sur cinq, et ces mêmes développeurs étaient plus susceptibles de croire que leur code était sécurisé.⁸ L’écart de confiance s’applique également à la performance : le code a l’air propre, se lit bien et produit une sortie correcte, alors le développeur lui fait confiance. Les chercheurs de SWE-fficiency ont constaté que les agents peinent à localiser les opportunités d’optimisation et à raisonner sur l’exécution à travers les fonctions.² Les LLMs font de petites modifications spécifiques aux entrées plutôt que des améliorations algorithmiques. Lorsqu’on leur demande d’optimiser, le modèle opte pour la transformation correcte la plus proche (ajouter un cache, inliner une fonction) plutôt que de reconsidérer l’approche algorithmique. Le résultat est une micro-optimisation superposée à des structures fondamentalement inefficaces.

Aucune porte d’évaluation ne mesure la performance

Les portes de qualité standard valident ce pour quoi elles sont conçues :

Chaque porte que l’industrie a standardisée opère sur la correction. Les tests de performance existent (profileurs, frameworks de benchmarking, outils de test de charge), mais ils occupent un workflow séparé que la plupart des équipes n’intègrent pas dans leur pipeline CI et que les agents IA n’invoquent jamais spontanément.

Le verification vacuum qui explique le mur de productivité de 10 % s’étend plus profondément que la correction fonctionnelle. Le vide ne concerne pas seulement « est-ce que le code fonctionne ? » mais « est-ce que le code performe ? » et aucune porte standard ne pose la deuxième question.

Les agents écrivent des fonctions, pas des systèmes

La cause la plus profonde est architecturale. Un agent IA génère du code une fonction, un fichier, une tâche à la fois. Le scope de chaque génération est l’exigence immédiate. Les problèmes de performance émergent aux frontières : quand une fonction écrite pour un seul appel est appelée dans une boucle, quand un analyseur écrit pour de petites entrées reçoit de gros fichiers, quand une recherche écrite pour la correction est sollicitée à chaque requête.

Le mode d’échec Tunnel Vision de la taxonomie des défaillances d’agents décrit ce pattern au niveau fonctionnel : l’agent perfectionne un composant sans vérifier les points d’intégration. L’angle mort de la performance est le Tunnel Vision appliqué aux caractéristiques d’exécution. La fonction est parfaite en isolation. Le système se dégrade parce que les caractéristiques de performance de la fonction n’ont jamais été évaluées en contexte.

La taxe invisible

L’angle mort de la performance serait un problème mineur si le code généré par l’IA représentait une petite fraction des systèmes de production. Les chiffres actuels en font un risque systémique.

DX mesure le code écrit par l’IA à 26,9 % du code fusionné en production, et ce chiffre augmente.⁶ Faros AI (un fournisseur d’analytique DevOps) a constaté que les équipes assistées par l’IA fusionnent des PRs 154 % plus volumineuses que les niveaux pré-IA, complètent 21 % de tâches en plus et génèrent 9 % de bugs en plus par développeur.⁵ Le chiffre de 9 % compte les défauts fonctionnels. Les régressions de performance sont absentes de cette métrique parce que la plupart des équipes n’ont aucune ligne de base de performance contre laquelle régresser.

Les mathématiques de l’effet cumulatif comptent. L’essai contrôlé randomisé de METR a constaté que les développeurs expérimentés prenaient 19 % plus de temps avec les outils IA, tout en croyant que l’IA les accélérait de 20 %.⁹ Si les développeurs eux-mêmes ne peuvent pas évaluer précisément l’impact, la dette de performance s’accumule sans être détectée. Avec 26,9 % du code fusionné portant potentiellement une dette de performance et l’organisation n’ayant aucune porte de performance, la dette se cumule à chaque sprint. Le rapport DORA 2025 a constaté que l’adoption de l’IA corrèle avec une instabilité accrue de livraison même si le débit s’améliore.⁷ Le rapport n’attribue pas l’instabilité à la performance spécifiquement, mais le mécanisme correspond : plus de code, fusionné plus vite, avec des caractéristiques de performance qui n’ont jamais été mesurées.

52 % des responsables ingénierie interrogés par Codeflash ont rapporté que l’utilisation accrue de l’IA entraîne des problèmes de performance dans leurs bases de code.⁴ Le chiffre est auto-déclaré et provient d’un fournisseur (Codeflash vend des outils d’optimisation de performance), mais la direction est cohérente avec chaque jeu de données indépendant. Plus de code généré par l’IA, fusionné avec des portes de qualité standard, produit des systèmes qui fonctionnent correctement et tournent lentement.

Le mur de productivité de 10 % a une dimension performance que les données originales ne mettent pas en lumière. Si l’IA accélère la génération de code de 10 % mais que le code généré porte une dette de performance qui se manifeste des semaines ou des mois plus tard sous forme d’incidents de production, le gain net de productivité se réduit davantage. Le mur n’est pas seulement « l’IA ne rend pas les développeurs plus rapides ». Le mur inclut « l’IA rend le code plus lent d’une manière que personne ne mesure ».

À quoi ressemble la détection

La détection de performance pour le code généré par l’IA nécessite une infrastructure que la plupart des organisations n’ont pas. Les outils existent. L’intégration non.

Portes de benchmark dans le CI

La correction la plus directe : benchmarker les chemins critiques et faire échouer le build en cas de régression. Des frameworks existent pour chaque langage majeur : pytest-benchmark pour Python, JMH pour Java, criterion pour Rust, benchmark.js pour JavaScript. Le défi n’est pas l’outillage mais la pratique. Les benchmarks nécessitent des lignes de base, et les lignes de base nécessitent que quelqu’un écrive le benchmark initial avant que le code généré par l’IA ne puisse régresser par rapport à celui-ci.

L’implémentation minimale viable : identifier les 10 à 20 fonctions dans le chemin critique, écrire des benchmarks pour celles-ci et les ajouter au CI. Les 118 bugs trouvés par Codeflash étaient concentrés dans les analyseurs et les fonctions de parcours d’AST : le cœur computationnel, pas le code de liaison. Les problèmes de performance se regroupent aux mêmes endroits à chaque fois.

Détection de patterns basée sur l’AST

L’analyse statique peut détecter les patterns les plus flagrants sans exécuter le code. Semgrep et ast-grep supportent des règles personnalisées qui détectent :

• Les compréhensions de listes ou boucles à l’intérieur d’autres boucles où la collection interne ne change pas (candidat à la mise en cache)
• Les vérifications .index() ou in sur des listes qui pourraient être des ensembles
• Les opérations d’E/S fichier ou appels réseau dans des boucles sans traitement par lots
• Les appels de fonction répétés avec les mêmes arguments (candidat à la mémoïsation)

Ces règles ne remplacent pas le profilage. Elles détectent les patterns qui représentent la majorité des 118 bugs : calcul redondant, mise en cache manquante, structures de données inadaptées.

Sensibilisation à la performance basée sur les hooks

Pour les utilisateurs de Claude Code, un hook PreToolUse peut injecter la sensibilisation à la performance dans le workflow de l’agent. L’approche est parallèle au pattern de porte de preuve utilisé pour la correction :

check_performance_patterns() {
    local file_path="$1"
    local ext="${file_path##*.}"

    case "$ext" in
        py)
            # Detect nested loops with repeated computation
            if grep -Pn 'for .+ in .+:\n.*for .+ in .+:' "$file_path" 2>/dev/null; then
                echo "WARNING: Nested loops detected in $file_path"
                echo "Verify inner loop does not recompute invariant values."
            fi
            # Detect list membership checks that should be sets
            if grep -n '\bin\b.*\[' "$file_path" 2>/dev/null | grep -v '#'; then
                echo "WARNING: List membership check in $file_path"
                echo "Consider converting to a set for O(1) lookup."
            fi
            ;;
        js|ts)
            # Detect Array.includes or indexOf in loops
            if grep -n '\.includes\|\.indexOf' "$file_path" 2>/dev/null; then
                echo "NOTE: Array search detected in $file_path"
                echo "If called in a loop, consider a Set or Map."
            fi
            ;;
    esac
}

Le hook n’est pas un profileur. Il sensibilise. L’objectif est le même que toute autre porte de qualité : rendre l’invisible visible pour que le développeur (ou l’agent dans une itération ultérieure) puisse y remédier avant que le code ne soit livré.

L’infrastructure manquante

Le pattern à travers chaque point de données est le même que celui qui explique le mur de productivité de 10 % et les sept modes de défaillance : l’IA amplifie toute infrastructure existante, y compris l’absence d’infrastructure.

Les organisations avec des benchmarks de performance dans le CI détecteront les régressions de performance générées par l’IA de la même manière qu’elles détectent celles générées par les humains. Les organisations sans eux accumuleront une dette de performance de manière invisible. La conclusion d’« amplificateur » de DORA s’applique directement : l’IA ne crée pas l’angle mort de la performance. L’IA le met à l’échelle.⁷

Trois investissements minimaux comblent l’écart :

1. Benchmarker les chemins critiques avant que l’IA ne génère du code autour d’eux. Le benchmark est la ligne de base. Sans lui, aucune régression n’est détectable. Identifiez les 10 à 20 fonctions qui représentent la majorité du temps de calcul et écrivez d’abord des benchmarks pour celles-ci.

2. Ajouter du linting de performance basé sur l’AST au pipeline CI. Des règles Semgrep ou ast-grep qui signalent les quatre anti-patterns dominants (calcul redondant, mise en cache manquante, structures de données inadaptées, complexité inutile). Les règles sont légères et composables avec les étapes de linting existantes.

3. Injecter la sensibilisation à la performance dans les workflows des agents. Pour Claude Code : un hook qui signale les patterns liés à la performance dans les fichiers modifiés. Pour les autres outils : un prompt qui inclut « vérifier la complexité algorithmique » comme instruction standard. L’objectif n’est pas l’optimisation automatisée mais la sensibilisation : faire émerger la question « est-ce assez rapide ? » dans un workflow qui actuellement ne la pose pas.

L’angle mort n’est pas l’IA. L’angle mort est l’absence d’infrastructure de performance. Chaque porte de qualité standard que l’industrie a construite valide la correction. Aucune ne valide l’efficacité. L’écart existait avant l’IA. L’IA en a fait un problème touchant 26,9 % du code de production.

Sources