Trouver et corriger des problèmes de performance avec des agents IA

Sans données de mesure, pas de diagnostic

Un agent à qui l'on dit seulement « l'appli est lente » devine tout autant que pour du débogage sans stack trace. Fournis-lui de vraies sorties de profiling : des mesures de temps, un export de flamegraph, des logs de requêtes en base avec les durées. Des chiffres concrets montrent où le temps est réellement perdu – pas où il semble « intuitivement » perdu.

Une hypothèse avant le correctif

Exactement comme pour le débogage : fais d'abord nommer les causes possibles, classées par impact supposé, puis teste-en une de façon ciblée. Une optimisation sans hypothèse préalable vise souvent le mauvais endroit – vite faite, mais inefficace.

Mesurer avant/après

Chaque optimisation a besoin d'un benchmark avant et après, dans les mêmes conditions. Sans chiffre de comparaison, tu ne sais pas si un changement a vraiment apporté quelque chose – seulement qu'il donne une impression de rapidité.

Micro-optimisation vs. optimisation d'architecture

Les petits changements (une boucle, une requête) sont vite mis en œuvre, mais rapportent souvent peu. Le plus grand gain se trouve généralement dans des décisions d'architecture : un problème de requêtes N+1, un recalcul inutile, un cache manquant. Un agent devrait nommer les deux catégories – et te dire laquelle aurait le plus grand impact.

Le piège : optimiser le comportement en le supprimant

Un agent peut rendre les choses « plus rapides » en coupant simplement du travail – en sautant une validation, en servant des données périmées au lieu de fraîches via un cache, en codant en dur un résultat. Ça a l'air bien sur le benchmark, mais c'est un bug de correction. Vérifie après chaque changement de performance si le résultat est toujours correct, pas seulement s'il est plus rapide.