Stress test agentique : la boucle ne s'arrête pas à plan et execute

La semaine dernière, j'ai publié une vidéo de plus de deux heures sur la méthode Killer SaaS : comment remplacer n'importe quel SaaS, même complexe, avec du code de qualité. L'idée n'est pas de vibe coder une petite application, mais de produire du code propre et sécurisé.

Vous avez été nombreux à la regarder. Et dans cette vidéo, je disais déjà une chose importante : beaucoup d'entre vous restent sur les phases plan et execute. Vous planifiez, vous exécutez, vous avancez, et vous pensez que c'est fini.

Ce n'est pas fini. Le développement agentique touche plus de choses que ça.

Même si vous allez au bout de la méthode et que vous livrez un SaaS en production, ce n'est pas terminé. Ce n'est pas parce que votre application fonctionne pour vous qu'elle fonctionnera pour plusieurs utilisateurs.

Une requête traverse cinq étages

Le principe est celui de la chaîne : sa résistance est celle du maillon le plus faible.

Une requête traverse plusieurs étages, et il suffit qu'un seul pose problème pour que tout le temps de réponse en soit affecté. Peu importe que les quatre autres soient rapides. Si le pool de connexions met cinq secondes, votre requête met cinq secondes.

Les points de saturation à connaître :

• le pool de connexions
• les requêtes lentes
• les API externes
• le démarrage à froid

Chacun peut devenir le goulot d'étranglement.

La courbe que tout développeur devrait avoir en tête

Voilà ce qui se passe en général. Vous testez votre application. Vous vous connectez, vous êtes tout seul dessus, vous regardez la latence, et vous concluez que tout va bien. Ça répond, c'est fonctionnel.

Ça marche à 10 utilisateurs. À 20. À 30.

Et d'un seul coup, peut-être à 50, vous avez une grosse dégradation et un pic de réponses très lentes.

C'est exactement ce qu'un développeur doit détecter avant ses utilisateurs.

k6, et les trois chiffres à savoir lire

Les scénarios de test de charge s'écrivent en JavaScript. C'est facile à faire produire par une IA, et ça permet de lancer plusieurs centaines d'utilisateurs virtuels en parallèle.

Pour lire les résultats, trois notions suffisent.

VU, pour utilisateur virtuel. 200 VU correspondent à 200 personnes qui naviguent simultanément. k6 produit ces simulations d'utilisateurs.

p95. C'est la métrique importante : 95 visiteurs sur 100 ont été servis plus rapidement que cette valeur. Si votre p95 est à 1,5 seconde, 95 visiteurs sur 100 ont des temps de réponse acceptables. Si votre p95 est à 4 secondes, 95 visiteurs sur 100 attendent 3 à 4 secondes. Ce n'est pas bon.

Le seuil. C'est la limite que vous déclarez avant de tirer. Sans seuil, vous produisez un graphique, pas un test.

Les deux skills

Le workflow repose sur deux skills que je donne dans le kit : celui qui rédige et exécute les tests de charge, et celui qui exploite les erreurs de production.

Le premier a un comportement utile : si vous n'avez jamais implémenté de scénario de test, il vous aide à l'implémenter. Si le scénario existe déjà, il vous dit ce qui a été exécuté et vous demande si vous voulez lancer le test de charge.

Ces skills ont des règles fixes, et ce sont elles qui comptent :

• on inclut toujours une page témoin sans base de données ;
• l'agent ne fixe jamais les seuils tout seul ;
• l'agent ne ferme jamais une issue tout seul.

En pratique, la demande ressemble à ça :

Lance un test de charge en production avec 200 utilisateurs virtuels.

Et l'agent s'occupe du reste.

Ce que le test a trouvé

Sur mon SaaS de formation, le tir a fait remonter une erreur de connexion à la base : le nombre maximum de connexions de session était atteint.

Le détail qui compte : cette erreur ne se déclenche pas à 200 utilisateurs. Elle apparaît dès une vingtaine.

Ce n'est pas le genre de problème que vous voyez du premier coup. Mais si j'avais annoncé ce SaaS à ma communauté sans faire ce test, beaucoup de personnes seraient tombées sur cette erreur. Et leur conclusion aurait été simple : ce SaaS ne marche pas.

Concrètement, en production, l'utilisateur arrive sur le site et reçoit une erreur 500.

Croiser le test avec les logs de production

C'est le deuxième volet, et c'est ce qui rend le verdict fiable.

Vous lancez le test de charge, puis vous comparez avec ce que le traceur d'erreurs a réellement enregistré pendant la même période. Sans ce croisement, vous ne mesurez que des temps de réponse.

Un exemple de ce que ça évite. Dans les erreurs, j'ai vu passer une URL en .php. J'ai demandé à mon agent si c'était lié au stress test. Réponse : ce ne sont pas mes requêtes. Et c'est logique, puisque le site utilise next-intl et que toutes les URLs passent par la langue, du type /fr/.... C'était donc quelqu'un qui scanne le site, pas mon test.

Sans l'agent pour trancher, j'aurais pu passer du temps à chercher un bug qui n'existait pas.

Le verdict

Après correction, nouveau tir. Zéro erreur, cette fois réellement vérifié.

La différence avec le test précédent est là. Le premier tir n'avait pas de traceur branché : je regardais les temps de réponse sans vraiment vérifier ce qui se passait côté serveur. Le second tir a les deux mesures, et c'est seulement à ce moment que le « zéro erreur » veut dire quelque chose.

Ce qu'il faut retenir

La boucle agentique ne s'arrête pas à plan et execute. Après le déploiement, il reste au moins trois chantiers : l'audit de sécurité, l'exploitation des logs de production, et le stress test.

Ce dernier n'est plus un projet à part entière. Avec un skill bien écrit, c'est une phrase à taper, et un agent qui construit le scénario, tire, dépouille et vous rend un verdict.

À condition de ne pas le laisser choisir ses propres seuils.