Un agent IA peut-il trouver les problèmes de performance en lisant le code ?

Il peut désigner des suspects probables, comme une requête dans une boucle, mais il ne peut pas savoir lequel compte pour vos données et votre trafic. Donnez-lui un profil, un journal des requêtes lentes ou une trace, et il peut se concentrer sur le code qui prend réellement du temps.

Quel profileur utiliser ?

Pour le navigateur, le panneau Performance de Chrome DevTools et Lighthouse. Pour Node.js, node --cpu-prof, qui écrit un fichier .cpuprofile que vous pouvez ouvrir dans DevTools. Pour Python, py-spy pour les processus en cours et cProfile pour un script que vous lancez vous-même.

Comment savoir si l’optimisation a fonctionné ?

Mesurez la même chose avant et après, plusieurs exécutions à chaque fois, sur la même machine. Un outil de benchmark comme hyperfine pour les commandes, ou le support de benchmark de votre framework de tests, fait les exécutions répétées pour vous. Si l’écart reste dans le bruit, ça n’a pas marché.

Pourquoi les agents proposent-ils des optimisations qui ne servent à rien ?

Sans mesures, un modèle se rabat sur des conseils généraux : mémoïser ceci, utiliser une boucle plus rapide, ajouter un cache. Ces modifications ajoutent de la complexité et ne changent souvent rien. Demandez la preuve derrière chaque suggestion et refusez tout ce qui n’est pas lié à un point chaud mesuré.

Comment empêcher les performances de se dégrader à nouveau ?

Transformez chaque correctif en contrôle : un test qui vérifie le nombre de requêtes d’une page, un budget de taille de bundle en CI ou un benchmark comparé à une référence. Le contrôle échoue avant que la régression n’atteigne les utilisateurs.

Optimiser les performances du code avec l’IA

Pour optimiser les performances du code avec l’IA, mesurez avant de rédiger le prompt : profilez le chemin lent, donnez le profil à l’agent, demandez la plus petite modification qui élimine le point chaud, et ne l’acceptez que si un benchmark montre la différence. Les agents de code comme Claude Code, Codex et Gemini CLI lisent vite un flame graph, remontent d’une fonction chaude jusqu’à ses appelants et réécrivent une requête. Privés de données, ils font comme tout le monde : ils devinent. Et les optimisations devinées sont les plus coûteuses, parce qu’elles rendent le code plus difficile à lire sans le rendre plus rapide.

Ce guide présente une méthode qui tient la route en pratique : définir l’objectif, profiler, transmettre les preuves, changer une seule chose, vérifier avec un benchmark et verrouiller le gain avec un garde-fou contre les régressions. En chemin, il aborde les problèmes à l’origine de la plupart des ralentissements dans les applications réelles : requêtes N+1, taille du bundle et caches manquants.

Partir d’un chiffre, pas d’une impression

« Le tableau de bord est lent » n’est pas une tâche. Transformez-le en quelque chose qu’un agent peut vérifier :

Ce qui est lent : un endpoint, un chargement de page, une commande CLI, un traitement par lots.
À quel point c’est lent aujourd’hui, mesuré : latence p95 d’un endpoint, time to interactive d’une page, durée d’exécution d’un script.
Ce que « assez rapide » veut dire : un objectif, comme « moins de 300 ms au p95 » ou « l’import se termine en moins d’une minute pour 100 000 lignes ».
Dans quelles conditions : volume de données, cache froid ou chaud, build de production ou serveur de dev.

Ce dernier point évite beaucoup de travail inutile. Une application React sur le serveur de dev, un service Node sans NODE_ENV=production ou un job Python sur dix lignes de données de test montreront des points chauds qui n’existent pas en production. Mesurez ce que vous livrez.

Étape 1 : profiler le chemin lent

Choisissez le profileur qui correspond à l’endroit où le temps se perd.

Dans le navigateur

Le panneau Performance de Chrome DevTools enregistre une trace : tâches longues, scripts, layout, cascades réseau. Lighthouse donne un score de laboratoire avec des pistes concrètes. La CLI Lighthouse est pratique parce qu’elle écrit un fichier que vous pouvez donner à un agent :

npm install -g lighthouse
lighthouse https://localhost:3000/dashboard \
  --only-categories=performance \
  --output=json --output-path=./lighthouse.json

Si votre agent prend en charge MCP, le serveur MCP Chrome DevTools lui permet de lancer lui-même une trace de performance et d’en lire les analyses :

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

Dans Node.js

Node intègre un profileur par échantillonnage. --cpu-prof écrit un fichier .cpuprofile à la sortie du processus, que vous pouvez ouvrir dans le panneau Performance de DevTools ou donner à un agent :

node --cpu-prof --cpu-prof-dir=./profiles server.js
# run the slow request a few times, then stop the server

L’option plus ancienne --prof écrit un journal V8 que node --prof-process transforme en rapport texte, très facile à lire pour un agent :

NODE_ENV=production node --prof server.js
node --prof-process isolate-0x*-v8.log > processed.txt

Pour les problèmes de mémoire, --heap-prof écrit un .heapprofile de la même manière.

En Python

py-spy échantillonne un processus en cours sans modifier votre code, ce qui en fait le choix sûr pour un service en production :

py-spy top --pid 12345                    # live view, like top
py-spy record -o profile.svg --pid 12345  # flame graph
py-spy record -o profile.svg -- python import_job.py

Pour un script que vous lancez vous-même, le cProfile de la bibliothèque standard donne des nombres d’appels exacts :

python -m cProfile -s cumtime import_job.py | head -40

En octobre 2026, Python 3.15 fournit aussi un paquet profiling avec un profileur statistique (python -m profiling.sampling) et garde cProfile comme alias de son profileur par traçage ; sur les versions antérieures, cProfile et py-spy sont les outils à utiliser.

Dans la base de données

Pour le temps passé en requêtes, la base de données connaît déjà la réponse : le journal des requêtes lentes, pg_stat_statements sur PostgreSQL, et EXPLAIN ANALYZE pour une requête précise. Écrire du SQL avec l’IA explique comment lire les plans de requête et choisir les index avec un agent ; ce guide ne le répète donc pas.

Étape 2 : donner les preuves à l’agent

L’agent a maintenant du concret sur quoi travailler. Transmettez le profil et le contexte, et demandez une analyse avant le code :

L’endpoint /api/orders prend environ 1,8 s au p95 en production ; l’objectif est
300 ms. En pièce jointe : processed.txt issu de node --prof-process pour 50 requêtes,
et le journal des requêtes lentes sur la même période.
Ne modifie pas encore le code. Liste les trois principaux points chauds, avec pour
chacun la preuve tirée du profil (fonction, temps propre ou temps total, nombre
d’appels), la cause probable dans notre code (fichier et ligne) et un correctif
proposé. Classe-les par impact attendu.

Quelques habitudes font fonctionner cette étape :

Donnez la sortie brute, pas votre résumé. Votre résumé contient déjà votre hypothèse.
Exigez une preuve pour chaque affirmation. « Cette fonction est lente » doit s’accompagner d’un chiffre tiré du profil.
Gardez l’agent sur le chemin chaud. Du code qui prend 2 % du temps ne mérite pas une réécriture, aussi laid soit-il.

Si l’agent dit quelque chose comme « le profil ne montre pas clairement le goulot d’étranglement », croyez-le, et capturez un meilleur profil avec plus de charge ou le build de production. C’est un bien meilleur résultat qu’une supposition affirmée avec aplomb.

Étape 3 : écrire le benchmark avant le correctif

Le benchmark est votre étape de vérification. Écrivez-le, lancez-le sur le code actuel et enregistrez la référence avant que quoi que ce soit ne change.

Pour une commande ou un script, hyperfine l’exécute de nombreuses fois et indique la moyenne et la dispersion :

hyperfine --warmup 3 'node scripts/build-report.js'

Pour une fonction, utilisez le support de benchmark de votre stack : go test -bench=. -benchmem en Go, pytest-benchmark en Python, le support de bench de votre runner de tests JavaScript. Pour un endpoint, un court test de charge avec un nombre fixe de requêtes contre un build de production.

Puis donnez la règle à l’agent :

Voici le benchmark et son résultat de référence. Fais une seule modification à la fois.
Après chaque modification, lance les tests et le benchmark trois fois et donne
l’avant/après. Si une modification n’améliore pas le résultat au-delà du bruit,
annule-la et dis-le-moi, même si tu penses qu’elle devrait aider.

Deux détails comptent. Comparez sur la même machine avec les mêmes données, car les portables brident leur processeur et les caches se réchauffent. Et gardez les tests actifs à côté du benchmark : une fonction plus rapide qui renvoie une mauvaise réponse est un bug. Si le code que vous optimisez n’a pas de tests, ajoutez-en d’abord ; écrire des tests unitaires avec l’IA montre comment en obtenir de vraiment utiles d’un agent.

Où le temps part généralement

Dans les applications réelles, une poignée de problèmes explique la plupart des ralentissements. Ce sont ceux à vérifier en premier.

Les requêtes N+1

Le grand classique : charger une liste, puis lancer une requête supplémentaire par élément dans une boucle ou un template. Tout semble correct avec dix lignes en développement, puis tout s’écroule avec deux mille en production. La solution consiste à charger les données liées en une ou deux requêtes, avec l’outil que fournit votre ORM :

Stack	Chargement anticipé
Django	`select_related` (jointures), `prefetch_related` (requête séparée)
Rails	`includes`, et la gem Bullet pour détecter les N+1 en développement
SQLAlchemy	`selectinload`, `joinedload`
Prisma	`include`

Les agents réussissent bien ce correctif dès qu’ils savent où le problème se produit. Activez la journalisation des requêtes, ouvrez une fois la page lente et donnez le journal à l’agent : un même motif de requête répété avec des ID différents est la signature du problème. Demandez ensuite le correctif et un test qui vérifie le nombre de requêtes de cette page, pour que le problème ne puisse pas revenir sans qu’on le remarque.

La taille du bundle

Pour les performances front-end, le JavaScript que vous livrez est souvent le levier le plus important. Mesurez d’abord le contenu du bundle avec source-map-explorer ou webpack-bundle-analyzer (ou l’analyseur de votre bundler), puis cherchez les causes habituelles :

une grosse bibliothèque importée pour une seule fonction,
un jeu d’icônes ou un ensemble de locales complet tiré par un seul import,
des composants lourds chargés au premier affichage qui pourraient être chargés à la demande,
la même dépendance embarquée deux fois dans des versions différentes.

Donnez la sortie de l’analyseur à l’agent et demandez des modifications classées par octets économisés. Comparez ensuite la sortie du build avant et après, de la même façon que vous comparez un benchmark.

Le travail répété et la mise en cache

Un cache est la bonne réponse quand le même résultat coûteux est calculé encore et encore avec les mêmes entrées. C’est la mauvaise réponse quand le calcul pourrait tout simplement devenir peu coûteux, ou quand personne n’a décidé de ce qui se passe quand les données changent. Avant d’accepter un cache proposé par un agent, demandez-lui :

Pour ce cache : quelle est la clé, qu’est-ce qui l’invalide, quelle obsolescence
maximale acceptons-nous, combien de mémoire peut-il utiliser, et que se passe-t-il
au démarrage à froid ? Montre-moi le taux de succès mesuré ou le profil qui le justifie.

Si les réponses restent vagues, le cache deviendra un rapport de bug plus tard. Souvent, la meilleure solution se trouve plus tôt dans la chaîne : un index manquant, une requête qui récupère toutes les colonnes, une boucle qui recalcule la même valeur à chaque itération.

Les problèmes algorithmiques

Parfois, le profil montre une seule fonction avec un nombre d’appels énorme : une boucle imbriquée sur deux listes, un .find() dans un .map(), un tri dans une boucle. Remplacer une recherche linéaire par un Map ou un Set est un correctif classique pour un agent, et le benchmark vous dit immédiatement si cela a compté.

Éviter l’optimisation prématurée et spéculative

Les agents adorent optimiser. Demandez à l’un d’eux d’« améliorer les performances » d’un fichier et il mémoïsera des composants, réécrira des boucles et ajoutera des caches partout. La plupart de ces modifications ne changent rien de mesurable et rendent le code plus difficile à faire évoluer. Des règles à énoncer clairement dans les instructions de votre projet :

## Travail sur les performances
- Pas d’optimisation sans un profil ou un benchmark qui montre le problème.
- Une modification par commit, avec les chiffres avant/après dans le message.
- La lisibilité prime sur les micro-optimisations hors des chemins chauds mesurés.
- N’ajoute pas de caches, de workers ni de nouvelles dépendances sans demander.

Il en va de même pour les suggestions de l’agent pendant un travail sans rapport. S’il annonce « au passage, j’ai aussi optimisé… », demandez les chiffres ou demandez-lui d’annuler. Quand quelque chose casse après une optimisation, déboguer du code avec l’IA explique comment circonscrire le problème sans deviner.

Étape 4 : protéger le gain

Les performances se dégradent en silence, une modification raisonnable à la fois. Transformez chaque correctif en un contrôle qui échoue bruyamment :

Tests sur le nombre de requêtes. Vérifiez que la page des commandes exécute au plus un nombre fixe de requêtes. La plupart des frameworks ont un utilitaire pour cela, comme assertNumQueries dans Django.
Budgets de bundle. Des outils comme size-limit font échouer le build quand un bundle dépasse une taille fixée.
Lighthouse en CI. Lancez la CLI Lighthouse sur un build de prévisualisation et échouez en dessous d’un seuil de score sur les pages qui comptent.
Benchmarks comparés à une référence. Stockez la référence et comparez ; en Go, benchstat compare deux exécutions de benchmark et vous dit si l’écart est significatif.

Les agents écrivent bien ces garde-fous, et cela vaut la peine d’en demander un dans la même tâche que le correctif : « corrige le N+1 et ajoute un test qui l’aurait détecté ».

Le faire dans AgentVera

AgentVera est une application de bureau qui fait tourner côte à côte des CLI d’agents de code comme Claude Code, Codex et Gemini CLI. Plusieurs de ses fonctionnalités s’intègrent à cette boucle :

Un navigateur que l’agent pilote. Le navigateur d’agent est un profil Chrome séparé que les agents utilisent via Playwright MCP, avec DevTools et la console intégrés : l’agent peut ouvrir lui-même la page lente et vous pouvez le regarder faire.
Envoyer les preuves d’un raccourci. Envoyer à l’agent (⌘⇧L) transmet à un agent la sortie du terminal, une sélection de l’éditeur, un diff ou la console du navigateur. La sortie du profileur dans le terminal part vers l’agent sans copier-coller ; une sortie très longue est coupée à 12 000 caractères, alors envoyez le haut du rapport ou enregistrez-le dans un fichier.
Les plans de requête à côté du code. Le gestionnaire de base de données (Pro) ouvre PostgreSQL, MySQL et SQLite avec un éditeur SQL qui affiche les plans EXPLAIN, et les agents peuvent interroger la base via son outil intégré.
Les benchmarks comme critères d’acceptation. Écrivez « les tests passent et le benchmark est au moins 30 % plus rapide que la référence » dans votre message, et Verify le contrôle à la fin du tour avec un vérificateur qui lance des commandes mais ne peut pas modifier de fichiers.
Annuler une optimisation qui n’a rien rapporté. Les checkpoints prennent un instantané de chaque tour : annuler une expérience se fait en un clic.
Essayer deux approches à la fois. Dans la grille de l’espace de travail, lancez deux agents dans des worktrees séparés, par exemple l’un sur le cache et l’autre sur la requête, et gardez celui qui obtient les meilleurs chiffres.

Pour conclure

Optimiser les performances du code avec l’IA demande la même discipline que sans elle, en plus rapide : un objectif clair, un profil, les preuves transmises, une modification à la fois, un benchmark comme preuve et un garde-fou pour conserver le gain. L’agent fait la lecture et la réécriture ; les chiffres tranchent. Si votre ralentissement est arrivé avec une mise à jour de dépendance, la méthode de mettre à jour ses dépendances avec l’IA vous aide à isoler le paquet responsable.

Pour essayer cette méthode sur votre propre projet, téléchargez AgentVera.