Entretien avec un expert : Nicolas Pietraru

Q : Peux-tu me parler de ton parcours dans les tests de performance ?

Mon parcours dans les tests de performance peut être considéré comme relativement classique, bien que marqué par des opportunités variées. Après avoir intégré un master en alternance à l’université, j’ai eu la chance de réaliser mon alternance au sein de Sogeti/Capgemini. Dès mon arrivée, j’ai été introduit à l’univers du test logiciel, avec la possibilité de découvrir plusieurs spécialités. J’ai exprimé mon souhait de toucher à différents aspects du métier, et cette approche m’a permis d’explorer trois grands domaines : le test manuel, l’automatisation et les tests de performance.

Cette polyvalence a débuté pendant mon alternance et s’est poursuivie après mon intégration en CDI chez Capgemini. En fonction des opportunités et des missions, j’ai pu travailler dans ces trois domaines de manière approfondie. J’ai notamment dirigé des équipes d’automaticiens, tout en gardant un lien avec le test manuel – un aspect moins captivant pour moi, mais que je considère indispensable, car il nourrit indirectement l’automatisation et les tests de performance.

L’un des moments forts de mon parcours a été la possibilité de partir à l’étranger, en Allemagne, pour travailler sur un projet de tests de performance chez Volkswagen. Cette expérience m’a particulièrement marqué, car elle touchait à des enjeux technologiques passionnants. Nous testions des applications mobiles liées à la conception des voitures de demain. Cette mission m’a permis de comprendre l’impact concret de notre travail sur des innovations majeures.

Par ailleurs, le fait d’évoluer dans une grande ESN comme Capgemini m’a offert une multitude d’opportunités. J’ai travaillé sur différents sujets, technologies, et méthodes, tout en collaborant avec des équipes internationales, que ce soit en Europe, au Maroc, ou en Inde. Ce contexte m’a enrichi sur le plan professionnel et personnel.

En résumé, intégrer une structure de cette envergure au début de ma carrière a été un formidable tremplin. Cela m’a permis d’acquérir des compétences variées, de m’adapter à des environnements diversifiés et de me préparer à relever de nouveaux défis par moi-même à l’avenir.

Q : Quelles sont les spécificités de ton travail en Nouvelle-Calédonie ?

Travailler en Nouvelle-Calédonie offre un contexte unique, marqué par des structures souvent à échelle réduite, ce qui demande une grande capacité d’adaptation. Les besoins varient en fonction des missions, des acteurs locaux et des projets en cours, et il est important de pouvoir jongler entre différentes approches.

Je me concentre principalement sur l’automatisation et les tests de performance, avec des missions qui peuvent être très fluctuantes. J’ai commencé par des missions assez courtes avant de m’engager sur des projets plus longs, comme celui sur lequel je travaille actuellement, d’une durée d’un an et demi à deux ans.

Comme en métropole, les principales missions concernent des secteurs tels que la banque et le secteur public. J’ai déjà eu des expériences similaires en métropole, notamment avec le groupe BPCE dans le secteur bancaire. Par exemple, lors d’une mission à la BNP, où j’ai travaillé pendant un an, une cellule dédiée aux tests de performance était en place. Tous les projets, qu’il s’agisse d’évolutions majeures ou de nouvelles fonctionnalités, ne partaient pas en production sans le tampon de validation des tests de performance. Ces services permettent aux grandes structures de se prémunir contre les problématiques de performance.

Cependant, ici en Nouvelle-Calédonie, la liberté dans le choix des outils est un véritable atout. On m’a demandé de définir les solutions adaptées, et je privilégie souvent des outils open source comme JMeter, que je maîtrise bien. Cet outil est idéal pour démarrer rapidement et adapter les scénarios aux besoins spécifiques de chaque mission.

Travailler dans ce contexte implique également de s’ajuster aux moyens parfois plus limités qu’ailleurs. Cela se reflète dans la manière dont les tests de performance sont conduits. En général, les campagnes de tests de charge sont ponctuelles :

• On commence par préparer l’environnement,
• Ensuite, on exécute les tests,
• Puis on analyse les résultats,
• On met en place des correctifs si nécessaire,
• Et enfin, on valide avant le déploiement.

Travailler ici, c’est aussi une opportunité unique : on a la chance de faire ce que l’on aime dans un environnement ensoleillé. Cela ajoute une dimension très agréable au quotidien. Bien sûr, les défis restent présents, mais ils sont compensés par cette liberté de choisir les outils et par la satisfaction de contribuer à des projets variés dans un cadre aussi agréable.

Q: As-tu une préférence pour certains outils de test de charge ?

Oui, j’ai travaillé avec plusieurs outils, notamment JMeter, LoadRunner et NeoLoad. Chaque outil a ses forces et ses faiblesses, donc mon choix dépend du projet.

J’apprécie particulièrement JMeter pour sa flexibilité, notamment lorsque je dois partir de zéro et configurer rapidement des scénarios. Parfois, il est nécessaire de coupler JMeter avec des outils comme Postman ou Wireshark, surtout pour récupérer ou analyser des requêtes spécifiques.

Il m’arrive aussi de basculer entre différents outils sur un même projet. Par exemple, si je rencontre un problème de corrélation ou une difficulté à gérer une requête complexe, je peux utiliser NeoLoad pour trouver une solution, puis revenir à JMeter pour finaliser le scénario.

Q: Et concernant Postman ? Est-ce que tu l’utilises aussi pour trouver des requêtes ou tester des codes de retour ?

J’ai utilisé Postman dans un contexte spécifique. L’objectif était de vérifier que les échanges par API fonctionnaient correctement. Dans ce cas précis, on m’a fourni les requêtes nécessaires, et j’ai commencé par implémenter et tester les appels avec Postman, principalement pour m’assurer que les requêtes étaient correctes et conformes.

Ensuite, j’ai transféré ces scénarios vers JMeter pour réaliser les tests de charge.

Globalement, pour des applications web classiques comme des interfaces e-commerce, je préfère enregistrer les échanges entre le client et le serveur directement avec un outil comme Fiddler.

Cela me permet de capturer toutes les requêtes pertinentes, de nettoyer les appels inutiles (par exemple, ceux liés à Google Analytics ou autres trackers tiers) et de m’assurer que seules les actions ayant un impact réel sur l’application sont conservées. Ces actions incluent, par exemple, la consultation d’un panier, d’un solde, ou la réalisation d’une opération spécifique.

Cette méthodologie garantit que les requêtes sélectionnées pour les tests reflètent réellement les performances de l’application et évitent tout biais lié à des appels superflus ou mal filtrés.

Q : Comment fais-tu pour estimer correctement la charge afin qu’elle soit représentative ?

L’estimation de la charge repose principalement sur la volumétrie et peut être abordée de deux manières, en fonction de la maturité de l’application :

• Pour une application déjà en production :
• Je commence par collecter des données existantes. Cela inclut :
  • Les pics d’activité observés : quels moments de la journée ou de l’année enregistrent le plus grand nombre d’utilisateurs ?
  • Le type d’application : par exemple, une application interne à une entreprise sera généralement utilisée pendant les heures de bureau (8 heures par jour), tandis qu’une application grand public peut avoir des schémas d’utilisation saisonniers.
  • Le contexte métier : pour une plateforme e-commerce, les périodes comme le Black Friday ou Noël sont des moments critiques. Pour des événements spécifiques, comme une plateforme de réservation de concerts, la volumétrie dépendra du nombre de places disponibles et des tendances observées lors de la réservation d’événements similaires très prisés.

2. Pour une application en développement ou sans historique :

Dans ce cas, je me base sur des hypothèses élaborées avec les parties prenantes, en utilisant :

• Les études marketing réalisées par l’entreprise. Ces études permettent d’estimer les volumes attendus, comme le nombre d’utilisateurs potentiels ou le trafic anticipé.
• Les objectifs stratégiques du projet : pourquoi l’application est-elle développée et quelle attractivité est attendue ?
• Une marge de sécurité : je prends systématiquement une estimation légèrement supérieure à celle prévue, pour simuler des situations de forte charge ou des pics imprévus.

Enfin, j’adapte ces estimations en fonction du type de tests souhaités. Par exemple :

• Si l’objectif est de simuler une montée en charge progressive, j’ajuste les volumes progressivement pour observer le comportement du système.
• Si des anomalies ou des comportements inattendus apparaissent, j’affine l’analyse en augmentant ou en modifiant les scénarios de charge.

Cette approche combinée, basée à la fois sur les données existantes et les estimations projetées, garantit que les tests sont alignés avec les réalités du système et les attentes des parties prenantes.

Q: Es-tu capable de déterminer la cause d’un goulot d’étranglement ?

Oui, la détermination des goulots d’étranglement repose sur les outils et méthodes à ma disposition, ainsi que sur une analyse approfondie des données collectées. Voici comment je procède :

• Analyse initiale avec l’outil d’injection :

L’outil de test de charge (comme JMeter, NeoLoad, ou autre) me fournit des données telles que :

• Les temps de réponse des requêtes, ce qui permet d’identifier si certaines actions ou endpoints dépassent les SLA définis (par exemple, 300 ms pour une API, ou 3 secondes pour une page web).
• Les erreurs détectées dans les requêtes, comme des codes 4xx ou 5xx.
• Des informations globales sur le réseau, pour vérifier si les délais sont liés à des problèmes de connectivité ou de latence.

2. Investigation approfondie avec des outils de monitoring :

Si les temps de réponse sont en deçà des SLA ou si des erreurs apparaissent, je poursuis l’analyse en utilisant des outils d’APM comme Dynatrace, Datadog, ou d’autres systèmes similaires. Ces outils permettent de :

• Identifier les points de saturation au sein de l’architecture (serveurs front-end, back-end, bases de données, caches, etc.).
• Suivre les performances des processus, par exemple sur des environnements JVM où les paramètres comme l’utilisation de la mémoire, la gestion des threads, ou le CPU sont critiques.
• Déployer des sondes sur les serveurs ou directement dans l’application pour capturer des informations précises sur les goulots.

Exemple : Lors d’un test de charge sur une application, j’ai constaté que la JVM d’un serveur était configurée pour utiliser un maximum de 10 Go de RAM, alors que la machine disposait de 50 Go de mémoire.

Cette mauvaise configuration empêchait le serveur de tirer parti de ses ressources complètes, provoquant des ralentissements et une saturation rapide. Après ajustement de la configuration (augmentation de la heap memory), les performances se sont nettement améliorées et la charge a pu être correctement absorbée.

Q: Quelle action recommandes-tu après la détection d’un problème lors d’un test de charge ? Cela implique-t-il d’investiguer ?

Lorsqu’un problème est détecté lors d’un test de charge, la priorité est d’entamer une investigation approfondie.

Cette analyse repose sur les outils à disposition et sur les informations qu’ils permettent de collecter. Les outils de test, comme ceux d’injection, fournissent des données sur les temps de réponse des requêtes, les éventuelles erreurs, et parfois des informations globales sur le réseau.

Ces données permettent de repérer les zones où l’activité est particulièrement élevée ou les anomalies comme des décalages dans la charge.

Par exemple, si l’architecture comporte un load balancer entre plusieurs serveurs back-end, une analyse peut révéler qu’un des serveurs est saturé à 100 % pendant que l’autre reste inutilisé, indiquant une mauvaise répartition de la charge. Ces constats doivent être partagés avec les parties prenantes pour ajuster les configurations.

Ce type d’analyse est particulièrement enrichissant dans le métier de testeur de performance, mais il comporte aussi des défis. Souvent, les problèmes identifiés nécessitent l’intervention de plusieurs équipes, comme celles du réseau, des infrastructures, ou des développeurs. Cela implique de collaborer avec tact pour expliquer les problèmes, comme une configuration incorrecte ou une erreur de développement, sans que cela soit perçu comme une critique personnelle. L’objectif n’est pas de désigner des responsables, mais de résoudre le problème de manière constructive.

Une fois l’investigation terminée, il est nécessaire de présenter une analyse claire et structurée, car c’est dans cette analyse que réside la véritable valeur ajoutée du travail réalisé. Elle doit être adaptée au besoin initial : s’agit-il de valider que l’application peut absorber une charge donnée, ou bien d’optimiser son comportement en fonction des besoins réels ?

Dans certains cas, l’objectif est simplement de vérifier que l’infrastructure peut supporter une charge définie, sans chercher une optimisation approfondie. Dans d’autres, il s’agit de dimensionner l’infrastructure pour qu’elle corresponde précisément aux besoins en charge, tout en minimisant les coûts.

Ces choix stratégiques dépendent aussi de la vision du client et de ses priorités budgétaires.

Par exemple, dans un environnement cloud, où les ressources sont allouées dynamiquement, une mauvaise configuration peut entraîner des coûts excessifs. Les tests doivent donc intégrer ces paramètres et permettre d’identifier des problèmes spécifiques, comme des accumulations de mémoire non gérées correctement, qui peuvent impacter les performances sur le long terme.

L’objectif final est d’apporter une compréhension claire des limites et des comportements de l’application pour permettre au client de prendre des décisions éclairées, qu’il s’agisse d’optimiser l’infrastructure, d’adapter les configurations, ou simplement de valider que le système répond à ses attentes.

Un exemple classique concerne des applications qui supportent très bien un grand nombre d’utilisateurs pendant une courte période, mais qui rencontrent des problèmes lorsqu’un petit nombre d’utilisateurs travaille de manière prolongée, à cause de fuites de mémoire ou d’une mauvaise gestion du garbage collector en Java. Dans ces cas, les performances se dégradent progressivement, jusqu’à l’épuisement des ressources mémoire.

Q: Quels conseils donnerais-tu pour former toute une équipe de test sur les bonnes pratiques des tests de charge, avec l’expérience que tu as ?

Former une équipe aux bonnes pratiques des tests de charge est un processus exigeant, car cela requiert de maîtriser à la fois des aspects techniques, métiers, et organisationnels. Voici mon approche, basée sur mon expérience.

La formation doit être structurée pour permettre à chaque membre de comprendre et de participer à l’ensemble des étapes d’un projet de tests de performance. L’objectif est que chaque testeur puisse gérer une campagne de bout en bout : recueillir les besoins, comprendre les problématiques métiers, concevoir et exécuter les tests, analyser les résultats et produire des rapports clairs. Cette approche globale est importante, car les tests de charge racontent une « histoire » : il faut comprendre pourquoi l’on teste, ce que l’on cherche à vérifier, et comment interpréter les résultats dans leur contexte.

Pour rendre un testeur autonome, il est nécessaire de prévoir une période de deux à trois mois à temps plein, durant laquelle il sera accompagné par un expert. Pendant cette période, la personne apprendra à observer des points spécifiques dans les analyses, à affiner ses scripts, et à poser les bonnes questions. Cela nécessite idéalement un bagage en développement ou en tests logiciels, car certains outils comme K6 demandent des compétences en Java, tandis que des outils plus graphiques comme NeoLoad, LoadRunner ou OctoPerf sont plus accessibles mais nécessitent toujours une appétence pour la technique.

Le rôle d’un testeur de performance exige de jongler entre plusieurs domaines : infrastructure, métier, et test logiciel.

Ce mélange de compétences rend cette spécialité très enrichissante. Un testeur performant acquiert avec le temps une compréhension approfondie des architectures, ce qui peut le mener à évoluer vers des rôles d’architecte logiciel ou de spécialiste en optimisation. Cependant, pour assurer une formation complète, il est également important d’aborder la dimension sécurité. Lors des tests, les configurations de sécurité doivent souvent être adaptées, comme par exemple gérer les tokens d’API qui se renouvellent automatiquement ou isoler les modules de sécurité pour tester leur comportement. Ces aspects nécessitent une rigueur et une technicité accrues.

La formation doit aussi inclure des cas pratiques sur des scénarios complexes, comme :

• Gérer des données partagées entre plusieurs injecteurs : Lors de tests à grande échelle, il peut être nécessaire d’utiliser plusieurs machines pour simuler une charge importante. Cela implique de répartir efficacement les données entre les nœuds et de gérer les échanges dans les deux sens.
• Concevoir des scripts sophistiqués : Par exemple, ajuster la fréquence des requêtes pour des serveurs ayant des capacités différentes, ou gérer des tokens API sans surcharger le serveur d’autorisation.
•  

Enfin, il est nécessaire d’utiliser des outils adaptés aux besoins de l’équipe et des projets. Les outils payants comme NeoLoad ou LoadRunner offrent souvent des fonctionnalités avancées qui simplifient la gestion des cas complexes, en particulier lorsqu’il s’agit de synchronisation ou de répartition des charges. Cependant, il est tout aussi important d’apprendre à exploiter au mieux les outils open-source comme JMeter ou Gatling, qui nécessitent plus de configuration, mais permettent une grande flexibilité.

Former une équipe sur les tests de charge ne se limite pas à transmettre des compétences techniques. Cela implique de développer une culture de la collaboration et du pragmatisme, car les tests de performance touchent à des domaines transverses et nécessitent une interaction fréquente avec d’autres équipes (développeurs, réseau, infrastructure, etc.). C’est en combinant une expertise technique solide, une compréhension métier claire et une communication efficace que l’on peut bâtir une équipe capable d’exceller dans les tests de charge.

Q: Comment vois-tu l’avenir du métier de testeur de performance avec les nouvelles technologies qui émergent ?

Le métier de testeur de performance évolue dans un environnement en constante mutation, à la fois en raison des nouvelles technologies et des attentes croissantes des utilisateurs.

D’un côté, la performance doit toujours répondre à une exigence de timing précis : ni trop rapide, ni trop lente. Par exemple, une page web qui s’affiche instantanément peut créer une confusion chez l’utilisateur, donnant l’impression que rien ne s’est passé, alors qu’un délai trop long risque de frustrer les utilisateurs et de nuire à l’expérience client. Ce paradoxe illustre bien les enjeux actuels : fournir une réponse adaptée au contexte et à l’objectif du service. Dans des cas spécifiques, comme les services publics, l’utilisateur peut tolérer un délai plus long, car le besoin est impératif, mais pour des services commerciaux, le temps de réponse peut avoir un impact direct sur le chiffre d’affaires.

Ce qui est fascinant, c’est que l’avenir du métier ne se limite pas à perfectionner les outils ou à accélérer les tests. L’un des enjeux majeurs sera de s’adapter à l’évolution des interfaces d’accès à l’information.

Aujourd’hui, nous utilisons principalement des sites web, mais demain, ces interfaces pourraient être remplacées par d’autres formats, comme des agents conversationnels ou des systèmes intégrés à des objets connectés.

Cette évolution impliquera de nouveaux types de tests et de méthodologies.

En parallèle, les tests de performance deviendront de plus en plus fréquents et réguliers, en partie grâce à l’automatisation et aux capacités des outils modernes. L’intelligence artificielle jouera un rôle, en particulier dans l’analyse des résultats. Déjà, avec des approches de machine learning, il est possible de former des modèles pour analyser des courbes de temps de réponse et détecter des anomalies. Ces modèles, qui s’appuient sur des exemples préalablement classés comme acceptables ou non, permettent de gagner du temps dans l’analyse initiale et d’identifier plus rapidement les goulots d’étranglement.

Q: Quels outils recommandes-tu d’explorer, pour des débutants comme pour des profils plus expérimentés ?

Pour les débutants comme pour les experts, il existe une variété d’outils et de méthodologies qui permettent d’évoluer dans les tests de performance. Le choix des outils dépend souvent du niveau d’expérience, mais également des objectifs de montée en compétence et des besoins des projets.

Pour ceux qui débutent, il est souvent judicieux de commencer par des outils graphiques et conviviaux comme NeoLoad ou LoadRunner. Ces outils permettent de rapidement construire des scripts, d’exécuter des tests, et d’obtenir des résultats sans avoir à entrer immédiatement dans des détails techniques complexes. Ils offrent une courbe d’apprentissage relativement douce, ce qui permet aux nouveaux de se concentrer d’abord sur les fondamentaux : comprendre les concepts de performance, les indicateurs clés, et l’importance des scénarios réalistes.

Ces outils sont excellents pour apprendre les bases, mais ils peuvent aussi masquer certains aspects techniques, ce qui limite l’apprentissage en profondeur.

Une fois que cette première étape est franchie, je recommande vivement de se tourner vers des outils plus techniques, comme JMeter ou K6. Ces outils open-source nécessitent plus d’efforts pour être maîtrisés, mais ils offrent une opportunité d’apprendre à un niveau beaucoup plus profond. En travaillant avec eux, on est obligé de comprendre les protocoles, les architectures, et les mécanismes sous-jacents qui impactent les performances. Ce processus, parfois exigeant, est incroyablement formateur. Il développe non seulement une meilleure compréhension des outils eux-mêmes, mais aussi des systèmes testés, ce qui est essentiel pour progresser en tant que testeur de performance.

Pour les testeurs plus expérimentés, il est important de se concentrer sur l’intégration des outils de tests de performance avec des systèmes de supervision et de visualisation en temps réel, comme Grafana couplé à Prometheus ou InfluxDB. Ces outils permettent de surveiller les métriques serveur en parallèle des exécutions, de générer des tableaux de bord personnalisés, et de mieux comprendre comment les performances de l’infrastructure réagissent à la charge. Être capable de visualiser en temps réel ce qui se passe sur les serveurs pendant une campagne de tests est non seulement satisfaisant, mais aussi essentiel pour mener des analyses précises et convaincantes.

De manière générale, il est important d’adopter une mentalité exploratoire. Les outils plus avancés et techniques demandent souvent plus de temps et d’efforts, mais c’est ce processus qui fait la différence entre quelqu’un qui exécute des tests et quelqu’un qui comprend réellement ce qu’il fait.

Par exemple, avec NeoLoad, il est possible de créer rapidement des scénarios performants grâce à son interface intuitive. Cependant, si on ne sait pas pourquoi ou comment cela fonctionne en arrière-plan, cela limite la capacité à résoudre les problèmes ou à ajuster les scénarios pour des cas spécifiques.

En revanche, des outils comme JMeter ou K6, qui demandent une configuration plus manuelle, obligent à s’immerger dans la technique, ce qui enrichit considérablement les compétences à long terme.

Pour les seniors, je recommande de se pencher sur des méthodologies plus avancées et émergentes, comme l’intégration des tests de performance dans des pipelines DevOps ou l’exploration des capacités des intelligences artificielles. Les modèles de machine learning, par exemple, peuvent être utilisés pour analyser des courbes de temps de réponse et identifier automatiquement des anomalies ou des tendances. Ces approches, bien que plus complexes, permettent de passer moins de temps sur les analyses répétitives et de se concentrer sur les tâches à plus forte valeur ajoutée, comme l’optimisation des architectures ou la collaboration stratégique avec d’autres équipes.

En résumé, il faut progresser par étapes : commencer par des outils accessibles, puis explorer des solutions plus techniques pour approfondir ses compétences, et enfin se tourner vers des méthodologies avancées et des outils d’intégration pour rester à la pointe. Le chemin peut être exigeant, mais chaque difficulté surmontée contribue à bâtir une expertise durable et une véritable compréhension du métier.