Donner les clés aux devs sans se passer de spécialiste

On juge les tests de performance trop velus pour des devs, alors on les leur confisque pour refiler ça à des spécialistes. C'est une erreur grossière : ça fabrique un goulet d'étranglement et ça coupe le fil entre devs et QA.

J'approche le problème sur deux fronts. D'abord, j'outille les devs pour une réponse at-scale : self-service, support technique, support méthodologique. Appelle ça de la Developer Experience ou du Productivity Engineering. Ils gardent l'ownership et font leur premier test en moins de deux heures. La performance est leur affaire autant que la mienne, tant que la feedback loop reste courte et que l'outillage est engageant.

Ensuite, je sanctuarise mon temps pour les sujets retors, ceux qui réclament une exigence qu'on ne tient pas à temps partiel : hardware dédié, environnement millimétré, campagnes lourdes en risques. Là, un ou une spécialiste se justifie pleinement.

C'est pas une question de compétence, mais de rentabilité. Un savoir-faire de niche étalé sur des personnes qui s'en servent une fois l'an, ça rapporte rien. Concentré sur quelqu'un qui le décline partout où ça compte, ça paie.

Donner les clés du camion aux devs n'interdit pas d'avoir des spécialistes à côté. Si les tiens enchaînent les tests simples, qui va explorer les zones d'ombre ? Un bon spécialiste perf ne prend la place de personne. Son job, c'est de donner à une équipe le désir d'affûter la performance de son périmètre.