J'aide la tech française
à corriger les problèmes
de performance logicielle
avant qu'ils ne coûtent cher.

Moi, si le cadrage est le problème. Je fais des tests de performance depuis plus de 18 ans, et j'interviens de deux façons. L'Atelier VIPerf : 4 heures, jusqu'à 5 personnes de ton équipe, 2 500 € HT, tu repars avec ta stratégie de tests de charge et son plan d'exécution. Ou en régie, à partir de 750 € HT par jour, quand il faut quelqu'un dans l'équipe sur la durée.

L'atelier ne teste pas à ta place : le groupe construit son plan, et c'est ton équipe qui l'exécute. En régie, je mets les mains dedans, cadrage comme exécution. Le transfert de compétences est inclus dans les deux cas. L'objectif reste que ton équipe sache le refaire sans moi.

Trois questions qui trient vite.

1. Demande-lui comment il fixe un critère de succès avant de lancer. S'il parle d'outil avant de parler de seuil, c'est mal parti.
2. Demande ce qu'il a décidé de ne pas tester sur sa dernière mission, et pourquoi. S'il n'a rien exclu, il n'a pas priorisé.
3. Demande ce qu'il laisse derrière lui en partant. Un rapport, ou un impact concret sur l'application et l'équipe.

Le test de performance est la discipline. Le test de charge en est un sous-ensemble : tu explores ce qui se passe sous des contraintes de charge fortes, et notamment ce que déclenche la concurrence entre utilisateurs.

Dedans, il y a toute une ribambelle d'options : endurance, stress, rupture, tests aux limites, et d'autres encore. Chacun rejoue un scénario de la vie réelle. Choisir lesquels fait déjà partie du cadrage.

Tu entendras parfois « test de performance » pour désigner un test de charge. Le mot performance ne signifie progressivement plus que charge, et les gens finissent par oublier qu'il n'y a pas que ça. Une équipe peut passer à côté de la moitié de la discipline sans avoir su qu'elle existait.

Ça vaut donc le coup de poser le vocabulaire. Le domaine est plus large que le test de charge.