Stratégie de Load Testing : Retour d’expérience avec SNCF Connect & Tech et Sopra Steria

0:00 Alors on continue, on a pendant ce temps-là installé notre décor pour notre prochaine intervention. C'est comment l'approche DevOps avec Gatling a permis de faciliter et d'améliorer les campagnes de tests en charge de la SNCF pour SNCF Connect& Tech. Donc je vous demande d'accueillir et d'applaudir aussi Alexis Coiffard, qui est directeur technique de l'agence du secteur public Nantes de chez Sopra Steria. Salut Alexis! Pierre-Yves Gautier, qui est Product Manager Observability, qualité de production. Voilà, on vous remet bien. Alors, on vous laisse. Ah, on va tout prendre. De toute façon, moi, je l'emmène après. J'ai décidé. C'est celle-là. J'aime beaucoup. Et qui ai-je oublié de présenter? Paul-Henri. Évidemment, Paul-Henri. Excuse-moi. Ça va aller? Oui. OK. Bon, je vous laisse. Excusez-moi, je vais faire un truc affreux. Pardon. Alors, ça a l'air de marcher.

1:04 Bonjour à tous et très heureux de voir autant de monde dans cette salle aujourd'hui. On va vous parler aujourd'hui sans slide, sous format d'une discussion à trois, avec deux de nos clients, des stratégies de test de charge. C'est vrai que c'est un sujet qui n'est pas forcément très connu, donc on va essayer de vous faire découvrir ça sous tous ses aspects, aussi bien technique, business que managérial. Peut-être avant de commencer, faire les merci, un grand merci évidemment aux équipes de Tech.Rocks de nous accueillir aujourd'hui. On est très très heureux d'être là aujourd'hui. Et évidemment, merci, alors on n'est que trois sur scène, mais il y a aussi d'autres gens qui ont participé à la préparation de cette conférence. Merci à Carole, Antoine, Pierina qui sont dans la salle et puis d'autres. Donc peut-être pour commencer un peu, pour rentrer dans le sujet, nous c'est la toute première fois qu'on fait parler des clients. On aurait voulu savoir dans la salle qui aujourd'hui est développeur ou a été développeur par le passé, par lever de main.

2:09 Ok, donc je dirais bien deux tiers de la salle. Et qui est familier avec les tests de charge? Ok, pas mal de gens sont familiers. Et qui ont fait? régulièrement, c'est-à-dire au moins une fois par mois, Il y en a un peu moins. On va essayer de vous convaincre d'en faire un peu plus. Mais sans plus attendre, commençons cette conférence. Je vais présenter mes deux intervenants que je remercie d'être avec moi aujourd'hui. Pierre-Yves Gauthier de la SNCF, SNCF Connect, Untech. Pour être précis, et Alexis Coiffard de Sopra Steria. Peut-être on peut commencer par, est-ce que vous pouvez brièvement vous présenter très rapidement? Je ne sais pas qui veut commencer entre vous deux. Je vais bien commencer, Pierre Gautier. Je vous préviens, je suis plutôt assez impressionné. Je vous remercie aussi pour l'invitation. Je remercie Paul-Henri aussi pour l'invitation, à partager mon expérience.

3:11 Moi, je suis Product Manager chez SNCF Connect on Tech et je suis sur le périmètre de l'observabilité et de la qualité de production. Et un des produits est le test de charge. Ok, avec Gatling. Avec Gatling notamment. Et du coup Alexis, si tu peux te présenter brièvement aussi. Bonjour à toutes et à tous, je suis très content d'être là aussi avec vous, merci pour l'invitation. Moi je suis le directeur technique de l'agence secteur public Nantes pour Soprasteria et aujourd'hui je vais vous parler particulièrement d'un client, la douane française avec laquelle on fait des tests de perf avec Gatling notamment. Alors, peut-être avant de se plonger dans le... Le sujet, est-ce qu'on peut, pour ceux qui ne sont pas forcément bien au fait de ce que c'est le test de charge, décrire en quelques mots qu'est-ce que c'est le test de charge ? Le test de charge, pour moi, il y a la notion de transactionnel qui est simulé dans l'objectif de qualifier les performances d'un périmètre applicatif.

4:14 Pas grand chose à ajouter. Il a tout dit. Oui, effectivement. Donc l'idée, c'est de voir, de mesurer votre temps de réponse, d'éventuellement aller jusqu'au crash pour voir comment votre application est capable de passer à l'échelle. Et on va le voir, pas forcément dans un contexte de mass market avec des millions et des millions d'utilisateurs. Mais ça, on va y venir un peu plus tard. Alors peut-être pour présenter la SNCF, on voit beaucoup la SNCF comme des trains, les cheminots, etc. Mais en fait, vous êtes un acteur de l'e-commerce énorme en France. Oui, tout à fait. Alors, juste pour situer, SNCF Connect en tech est dans le groupe SNCF Voyageurs, qui est lui-même dans le groupe SNCF. C'est 1000 collaborateurs, les deux. qui sont de la tech. C'est aussi ce qui est à noter. En effet, on a deux activités qui sont le e-commerce et la distribution autour de la mobilité. Et on a une partie qui est peut-être moins connue,

5:17 qui est sur la conception, tout ce qui est développement et l'opérationnel sur les solutions autour de la mobilité durable du groupe SNCF, mais pas que, sur d'autres acteurs de la mobilité durable. Tu me donnais des chiffres d'ailleurs assez impressionnants sur la SNCF. Pour 2022, c'est 14,2 millions de clients, 190 millions de billets vendus et 1 milliard de visiteurs. Exactement. Donc un gros, gros acteur du e-commerce. Et toi Alexis, en revanche, on n'est pas du tout dans un contexte d'application à un grand public. Oui, tout à fait. C'est des applications métiers principalement pour la plutôt côté douane. Nous, notre cadre, il est très, on va dire, réglementaire. La douane, depuis maintenant plusieurs années, fait face à des évolutions réglementaires, soit françaises, européennes ou même des décisions politiques, qui insuvent finalement une augmentation très importante en termes de volumétrie. Je prendrai deux exemples. Il y a le Brexit, dont vous avez tous entendu parler.

6:19 Ça veut dire qu'il a fallu développer une application qui permet de gérer et de fluidifier tout ce qui va être contrôle aux frontières pour ne pas engorger les infrastructures maritimes et ferroviaires. C'est une... application critique. Alors ça rejoint ce que tu disais tout à l'heure, ce qui est intéressant c'est que c'est une application critique mais finalement d'un point de vue volumétrie, c'est pas non plus, on n'est pas sur des chiffres de l'ordre de la SNCF, mais pour autant il faut s'assurer que ça fonctionne. Puis on a des choses beaucoup plus colossales, où là on va nous demander de traiter potentiellement jusqu'à 400 messages par seconde sur certaines typologies de déclarations que la douane peut être amenée à traiter. Un autre exemple qu'on peut prendre, c'est par exemple le paquet TVA. Vous en avez peut-être entendu parler en 2021, c'était la fin de l'exemption à la TVA sur tout ce qui était colis e-commerce qui venait de pays hors Union Européenne, d'une valeur inférieure à 150 euros. Donc c'était nouveau, la douane a dû mettre en place une nouvelle application qui permet aux opérateurs de déclarer ces éléments-là. Et donc à chaque fois, ça veut dire, nous, des tests de charges pour s'assurer qu'on est capable de tenir finalement tout ce que ça implique derrière d'un point de vue infra, etc.

7:22 Ça, c'est des choses qui sont assez amusantes, qui sont sorties dans les discussions. C'est que parfois, des choses qui sont simplement de l'ordre du réglementaire, du législatif, peuvent avoir des impacts sur les tests de charge. Et je crois même, on en parlera un peu plus en détail tout à l'heure, mais dans la définition de vos objectifs de performance, je crois que même l'Europe vous donne... Oui, c'est-à-dire que pour les projets qu'on fait qui sont européens, les exigences volumétriques, elles viennent potentiellement de l'Europe, où on nous dit qu'en nominal, on va devoir traiter tant de messages par seconde, en crête, on va devoir traiter tant de messages par seconde. Et nous, après, notre travail, c'est de construire un système qui est capable de gérer ça et de le démontrer. Et toi, du coup, Pierre-Yves, comment c'est arrivé? C'est le sujet de performance. C'est quoi les enjeux de perf de la SNCF? Les enjeux de notre côté, en effet, déjà au niveau de la performance, il y a de l'exigence de la part des utilisateurs qui est de plus en plus forte. On accepte de moins en moins le fait d'attendre, le fait qu'il y ait de l'indisponibilité, des difficultés, des erreurs qui apparaissent. Donc des enjeux qui sont de plus en plus importants sur la qualité. Et aussi des contextes d'usage qui sont en perpétuelle évolution.

8:29 On a aujourd'hui un usage qui est différent du voyage en train par rapport à ce qui existait autrefois, il y a encore cinq ans. Même chose, on a eu des contextes autour, par exemple, du Covid, où on a eu, quand il y avait des discours de Macron le soir, on a eu des moments où on a eu beaucoup d'après-ventes du fait de l'annulation des possibilités de voyage. Et on a de nouvelles fonctionnalités régulièrement, très régulièrement, qui demandent qu'elles soient qualifiées assez fréquemment. Et on a aussi certaines contraintes, c'est qu'on a des ouvertures de vente, pour Noël par exemple, où tous les trains sont mis à disposition en même temps. On n'envisage pas de faire un Paris-Nantes pour aller à Pornic sans avoir le Nantes-Pornic, par exemple, après. Donc, on a des moments où on ouvre les ventes pour une date donnée et qui fait qu'on a une forte affluence qui arrive sur le site. On peut même aborder...

9:29 Et aussi... On est de plus en plus de besoin d'évolution, d'exigence, d'agilité dans nos développements et donc à chaque fois de qualifier rapidement. On peut aborder d'ailleurs les questions qui fâchent. L'ouverture des billets pour Noël, vous avez craché. Oui. Je ne sais pas si des gens ont vécu ça. Qu'est-ce qui s'est passé exactement? Ah, oui, oui. On a craché. En fait, on avait prévu deux fois plus. Deux fois plus de charges. Et bien, on a eu trois fois plus de charges. Donc, dans ce cas-là, forcément, on a mis en place des tunnels de vente. Il y a eu de l'attente pour les utilisateurs. On a mis en place des sas, par exemple, d'attente. Et donc, il y a eu une certaine frustration des utilisateurs. On était dans un usage particulier. Toutes les équipes ont été tout de suite sur le problème. Et par la suite, on a mis en place des process pour améliorer. Cette problématique, notamment avec des référents au niveau des pilotages des tirs de charge, qui existaient déjà, mais plus côté tech.

10:36 Des postes de lead à ce niveau-là, sur tout le périmètre des différentes prics qui étaient impactés. Donc effectivement, déjà l'année dernière, qui était un record, vous aviez prévu deux fois plus pour cette année, vous avez eu trois fois plus. Ce qui était évidemment très extraordinaire. Vous êtes des clients maintenant depuis plusieurs années, depuis 2018, mais vous faisiez déjà du test de charge à ce moment-là, mais de manière un peu différente. Comment est-ce que ça se présentait chez vous? Alors, auparavant, on était sur un centre de service de tir de charge. Ça fonctionnait donc avec un plateau d'experts. Il y avait une certaine frustration du fait que ce soit des experts en termes de... Il faut trouver des personnes qui sont en expertise sur les tirs de charge, en termes de disponibilité de personnes, d'experts. D'autres frustrations, notamment sur... sur tout ce qui est, ce qui allait être la coordination, la compréhension projet, la coordination aussi avec les personnes côté projet.

11:41 Aussi, ça crée un forme de service potentiellement sur certaines périodes pour certains projets. Certains de nos projets, ça crée un goulot d'étranglement sur le chemin de leur production. La frustration aussi, et pour d'autres acteurs, ils étaient déresponsabilisés sur la problématique de performance. C'était la problématique des personnes qui qualifiaient les performances et de la production. Alexis, toi, tu as vu aussi un changement de mentalité, un changement de culture, notamment chez vos clients? Oui, tout à fait. Historiquement, la performance était généralement plutôt gérée de manière ponctuelle. C'est-à-dire qu'on avait une grosse phase de build, et puis quelques mois avant la mise en production, on se disait, tiens, ce serait bien de faire des tests de perf. Donc là, on avait un peu le même problème que vous, côté SNCF, c'est-à-dire qu'on n'a pas d'experts le moment où on a besoin de faire de la perf. Donc on faisait des campagnes de perf, ça donnait ce que ça donnait, on n'était pas très content du résultat, parce que généralement, on anticipait mal les sujets, donc finalement, la pertinence des tests qu'on menait était limitée.

12:45 Et aujourd'hui, on est plus sur de la performance en continu, on essaie vraiment de mesurer de manière très régulière ces éléments-là, et on voit aussi cette évolution dans la mentalité de nos clients, c'est-à-dire qu'à l'époque, ils étaient comme nous, c'était même souvent nous qui étions à l'initialisation, dire que ce serait bien. de faire des tests de paire sur ce projet, etc. Aujourd'hui, c'est une exigence de nos marchés. C'est-à-dire qu'ils attendent de nous que, quand on a une prestation de réalisation, quand on délivre quelque chose, cette exigence transverse soit intégrée tout au long du cycle de réalisation du projet. Alors, si on veut rentrer un petit peu dans le concret, Est-ce que tu peux nous expliquer un peu comment on décide à faire du test de charge, comment on définit la stratégie? Alors chez nous, comment ça se passe? Quand je dis chez nous, c'est avec le client, avec la douane. Déjà, on gère beaucoup d'applications pour la douane. La douane fait un premier travail de choix stratégique, de dire que ces applications-là sont stratégiques, je veux qu'elles soient soumises à test de perf. Une fois que ça s'est fait, nous on a pour chacun de ces projets une phase de stratégie, de définition de la stratégie.

13:46 C'est là qu'on va venir étudier finalement quels sont les scénarios métiers qu'on a envie de mettre en place, quelle est la typologie de tir de perf qu'on a envie de réaliser, est-ce que c'est du tir nominal, de crête, endurance, etc. Et puis tout ce qui va autour, c'est-à-dire quelle est la stratégie d'alimentation de la base de données préalablement au test, comment on gère les adhérences, parce qu'aujourd'hui on a des systèmes qui sont hyper connectés, etc. Donc est-ce qu'on teste une appli, une chaîne applicative? Il y a beaucoup de questions. Ce qui est important à ce moment-là, c'est d'avoir en tête qu'il faut vraiment que toutes les parties prenantes soient autour de la table. Bien évidemment, les équipes techniques, mais on a aussi besoin des métiers, etc. Et c'est une étape qu'il ne faut pas négliger parce que c'est vraiment la définition de cette stratégie qui va permettre de garantir que les tests qui sont effectués, finalement, ils sont pertinents, ils sont représentatifs et ils vont nous apprendre des choses sur l'application. Et peut-être pour ceux qui sont dans la salle et qui ont du mal à imposer ce sujet-là chez eux, Qui décide et comment on arrive à la décision de faire des tests de charge et de choisir un outil? Comment ça se passe concrètement chez vous, chez Sopra et chez le client? Je pense qu'on n'a généralement pas de mal à faire adresser ce sujet parce que les impacts sont tout de suite facilement perceptibles.

14:54 C'est des problèmes d'image, des problèmes de perte de chiffre d'affaires, etc. Des utilisateurs qui sont mécontents. Donc le fait de... La nécessité d'en faire, on arrive assez facilement à la faire passer. Là où on a un peu plus de mal, je dirais les freins à l'adoption, finalement, ça va être... Premier sujet, ça va être le coût. Il y a pour moi une fausse croyance qui est que le test de charge, ça va coûter cher. Oui, si on va très loin dans la façon dont on teste, etc., ça peut coûter très cher. Mais il y a moyen d'y aller step by step et finalement d'avoir une approche qui permet petit à petit de commencer à tester son application, puis sa chaîne d'application, tester tout le périmètre, etc. Je pense que ça, c'est un premier élément. Et le deuxième élément sur lequel il faut travailler et anticiper, c'est la gestion de la compétence. T'en parlais un petit peu. C'est qu'aujourd'hui, nous, pour traiter ce sujet-là, finalement, ce qu'on a décidé de faire, c'est de responsabiliser les équipes vraiment de réalisation. C'est-à-dire que c'est elles qui portent toute la partie implémentation des scripts Gatling, etc. Parce qu'on a la conviction que c'est elles qui connaissent le mieux leurs applications.

15:54 Et donc ça nous permet de les impliquer, de les responsabiliser, et puis d'avoir des gens qui sont au cœur du projet pour faire ça. Après, sur le choix du produit en tant que tel, je pense que ça c'est propre à chaque organisation, etc. Nous, Gatling nous a séduit parce qu'on est des gens qui aiment bien tout faire as code, et donc pouvoir faire de la perf as code, c'était l'élément clé pour nous sur le choix de l'outil. Alors concrètement, on rentre dans l'implémentation, la rédaction des tests, comment ça se passe? Une fois que la stratégie a été partagée et validée avec le client, comme je le disais, c'est les équipes de dev qui vont implémenter les scripts. script Gatling, qui vont réaliser les tests sur un environnement côté Sopra Steria, qui est dédié à SOS, un cluster Kubernetes dédié à la performance. Et puis ensuite, il va y avoir toute une phase d'analyse et d'optimisation en fonction de ce qui est constaté. Le choix qu'on a fait, nous, c'est donc, encore une fois, d'avoir les équipes de dev au cœur du processus, mais ils sont accompagnés d'une cellule d'experts perf, qui est finalement une équipe un peu pluridisciplinaire, où ils ont une expertise à la fois méthodologique, sur comment je déroule les tests de perf, et puis sur une expertise qui tourne aussi beaucoup autour des outils,

17:04 comment j'injecte, enfin comment je fais mes scénarios de perf, comment j'analyse ce qui s'est passé, quand j'ai besoin de creuser, parce que potentiellement je détecte un problème, et puis sur les optimisations, puisque ce que nous on observe, c'est que c'est quand même assez régulièrement les mêmes problèmes qu'on a, et donc on capitalise par cette cellule sur la façon de résoudre nos problèmes de perf. Et on arrive à la fin des tests, donc on arrive avec les rapports, les différents KPI. Qu'est-ce qu'on en fait? Comment on les analyse? Et c'est quoi les types d'améliorations qu'on peut avoir suite à des tests de charge? Alors, à chaque fois qu'on fait une campagne de tests de charge, ça donne lieu à un livrable pour notre client. Concrètement, on vient partager justement tout ça. Qu'est-ce qu'on a testé? Qu'est-ce qu'on a observé? Et quelles sont les optimisations qu'on a pu mettre en œuvre? Sur l'optimisation, nous ce qu'on observe, et c'est d'ailleurs une des raisons qui a fait qu'on a fait le choix de faire des tirs de perf en interne plutôt qu'en environnement client, c'est que c'est quasiment tout le temps les mêmes problématiques. auxquels on fait face, c'est du tuning base de données, c'est des index qui sont manquants ou qui ne sont pas du bon type, c'est de la gestion de threads en Java, parce que nous on est sur un gros pôle plutôt Java, et donc

18:11 c'est un petit peu tout le temps les mêmes optimisations finalement qu'on fait, et c'est pour ça qu'on peut facilement capitaliser dessus aussi. Merci beaucoup. Peut-être pour en venir à toi, Pierre-Yves, tu nous as décrit un peu ce changement de culture qu'il y a pu avoir autour du test de charge. Oui, le besoin de changement à ce niveau-là. Et aussi, on est passé sur un mode plus DevOps, en responsabilisant les projets par rapport à l'utilisation du test de charge. C'est passé par des besoins que complique Gatling sur le fait que ce soit un outil qui puisse être utilisé par les devs de leur côté, l'intégration, aussi un outil qui était mieux destiné parce que ça ciblait l'outil génère du HTTP. On avait un autre outil auparavant. Qui avaient des fonctionnalités qu'on n'utilisait pas, donc d'être plus fit sur le besoin. Et aussi cette notion d'usine de test, de pouvoir créer une usine de test avec les possibilités d'intégration.

19:16 De Gatling, qui nous a permis de mettre en place une usine avec, par exemple, un outil de planification. qui permet de déclencher des tirs de charge de façon automatisée, qui permet aussi derrière, on est en cloud, de pouvoir dimensionner et démarrer au besoin la plateforme, de préparer les jeux de données en amont automatiquement, d'arrêter bien sûr la plateforme à la fin du tir, déclencher le tir avec le paramétrage bien configuré, et derrière... De remonter les informations et les résultats de tir dans Datadog, de pouvoir générer des rapports de façon automatisée à partir de templates, et de faire en sorte, en fait, que l'événement en tir de charge soit minoré et devient un événement mineur. Donc minorer le test de charge, le dédramatiser pour qu'il y en ait de plus en plus. Et les chiffres que tu donnais étaient assez impressionnants. Il y a une quarantaine de projets différents qui font du Gatling.

20:19 Voilà, qui tournent, mais qui ont une quarantaine de projets sur la plateforme Gatling Enterprise que nous avons chez nous. Et un millier de campagnes par an à peu près. Un millier de campagnes par an. Donc plus de 2-3 campagnes par jour. Oui, oui, oui. Tu parlais justement de la version entreprise. Pour ceux qui ne sont pas forcément au courant, Gatling, on est une solution open source et on vend une interface de pilotage. Qu'est-ce que ça a apporté pour vous, la version entreprise? Alors, déjà au niveau d'un outil qui permet de piloter, qui a intégré cette notion de pouvoir démarrer et arrêter à la demande, enfin même de popper des serveurs, ces deux injecteurs, des machines d'injection à la demande, et puis de les décommissionner derrière, de l'optimisation de coûts, et puis bien sûr toute l'API derrière qui va permettre de piloter, qui va permettre d'intégrer les tirs de charge à notre pipeline de délivrer. C'est quoi les possibilités d'optimisation? Qu'est-ce que vous avez pu optimiser finalement en faisant autant de tests?

21:21 Pourquoi c'est important d'ailleurs d'avoir autant de tests? Par rapport notamment sur le delivery, la nécessité de... d'avoir des littératifs pour les projets. Ça nous permet de qualifier toujours au mieux nos développements derrière. Et... Je me suis perdu dans les questions. On arrive un peu à la fin de cette conférence. Je vois qu'il nous reste trois minutes. On va essayer un peu de reprendre vos messages. Il y a un premier message qui m'a beaucoup marqué quand on a fait toutes nos discussions de préparation pour cette conférence. C'est que ce qui revenait assez souvent, c'était ce message de... Il faut faire confiance aux équipes de dev, il faut faire confiance au terrain, il faut faire confiance à ceux qui connaissent l'application. Pourquoi est-ce que c'est important ça finalement? Si tu veux répondre. Moi, c'est ce que je disais tout à l'heure. Je pense que pour que les tests de charge aient un sens, il faut vraiment se questionner sur la stratégie et donc mettre les bons acteurs dans la chaîne de réflexion.

22:27 Et l'équipe de dev, au même titre que l'équipe métier qui va connaître son besoin métier, l'équipe de dev, elle connaît potentiellement l'implémentation, les points de risque, les points de vigilance qu'il peut y avoir là-dessus. C'est extrêmement important, finalement, que ce soit eux qui soient aussi à la manette pour pouvoir tenir compte de ça et adapter la stratégie en conséquence. Je compléterai juste, je suis d'accord avec toi, et aussi tout le suivi de prod derrière qui va porter la solution en production et qui va être responsabilisé dessus aussi. Et faire confiance. Au terrain, mais en même temps, ça découle forcément d'une décision stratégique au niveau de l'entreprise. Si la performance est stratégique sur le périmètre applicatif, il faut que ce soit une décision de gouvernance. En effet, la stratégie, la politique de qualification des performances doit être décidée au niveau de la gouvernance. Pour que ce soit appliqué. Tu veux ajouter quelque chose? Non, je pense que tu as tout dit encore une fois.

23:31 Alors, je n'ai pas du tout le même temps, c'est pour ça que je bug sur le timer. Pour moi, il y a un peu plus de temps. Mais enfin, on va se confronter à ça. Quelque chose qui est ressorti de nos discussions aussi, c'est que finalement, quand on discute avec des gens qui font du test de charge, la première chose qu'ils nous disent, c'est qu'on se met toujours un peu trop tard à faire du test de charge. Pour moi, c'est la grosse doléance du test de perf. C'est qu'on manque d'anticipation. C'est souvent vu comme la variable d'ajustement des projets. On va faire ça, on se dit qu'on fait ça quelques mois avant la MEP, comme sur tous les projets, ça se tend. Et donc là, on va alléger la stratégie. Et finalement, on porte préjudice à la valeur et aux héroïques, ces tests de perf. C'est pour ça que nous, l'approche qu'on a, c'est vraiment d'essayer, comme tu le disais, d'avoir des points de mesure qui soient réguliers, de faire en sorte que ça fasse partie du processus d'intégration continue, etc. Pour qu'on ne puisse pas se retrouver dans cette fameuse question de... Je n'ai pas le temps, comment je fais ?

24:32 Il faut vraiment traiter le sujet dans l'anticipation. On en parlait aussi, ne serait-ce que sur la partie optimisation. Généralement, quand on détecte un problème, ce n'est pas forcément trivial à résoudre. L'action de créer un index, etc., ça ne prend pas longtemps. Mais l'analyse, pour arriver à cette conclusion-là, elle peut être un peu plus chronophage. Donc c'est vraiment des sujets qu'on a envie de traiter dans l'anticipation parce que ce n'est pas quand ça pète en prod qu'on est content et que là, on est forcément sous pression pour résoudre nos problèmes. L'analyse, effectivement, en amont. Et nous, on a... même beaucoup d'utilisateurs qui, sans forcément faire d'optimisation, au moins sont prêts à un crash, c'est-à-dire qu'ils savent exactement ce qui va se passer, comment l'application va crasher. Et toi, Pierre-Yves, tu me disais, j'aurais aimé traiter ça beaucoup plus tôt aussi. Oui, enfin, être... En tout cas, concilier l'observabilité et le tir de charge, j'aurais aimé pouvoir l'appliquer plutôt s'il y avait quelque chose que j'aurais souhaité faire. C'est ça. Je fais ce qu'on fait aujourd'hui. J'aurais aimé pouvoir intervenir dessus plus tôt. En tout cas, c'est une doléance personnelle.

25:36 Une dernière petite question avant qu'on passe aux questions. Tu me disais, Alexis, justement, qu'un truc qui est assez important, finalement, pour des sociétés comme vous, de prestations de services, c'est que du dev, tout le monde peut en faire, mais quand on fait du test de charge, ça apporte quelque chose de supplémentaire en termes de valeur pour le client. Oui, pour le client et même pour les collaborateurs, je trouve que c'est comme ça qu'on a choisi d'aborder le test de charge aussi. C'est de se dire, en responsabilisant nos équipes, on leur donne aussi l'occasion de développer une expertise. Et cette expertise, pour eux, elle est intéressante, elle est facile à valoriser. Et pour nos clients, c'est pareil. C'est-à-dire que ça a de la valeur. On disait tout à l'heure, il y a une époque où il fallait vraiment aller chercher des profils spécialisés pour être capable de faire du test de perf. Notre objectif, tu le disais, c'est un peu dédramatiser, démocratiser cette pratique. Et au même titre que l'accessibilité demain ou la sécurité, Pour moi, c'est un sujet sur lequel on ne peut pas faire l'impasse. Il va falloir que les gens montent en compétence dessus. Un grand merci à tous les deux.

26:37 Et peut-être avant qu'on passe aux questions de la salle, Pareil, en lever de main, à qui on a donné un peu envie de se dire, c'est peut-être un sujet qu'on va creuser un peu plus. Est-ce qu'il y a des gens qui vont mettre ce sujet sur la table? Quelques mains qui se lèvent. Merci beaucoup. Passons aux questions. S'il y a des questions, évidemment. On va applaudir quand même déjà. Ah, t'es le chef. Ok, je vous en prie. Bonjour, déjà merci pour le rétexte, c'est cool. Moi j'avais une question qui portait plus sur l'analyse du problème, on en revenait. Est-ce que vous couplez vos stratégies de test de charge à des stratégies observabilité monitoring type Dynatrace, New Relic, tous les concurrents du marché pour aider les équipes à fixer le problème relevé par le test de charge? Nous, oui, on est intégrés à Datadog et on les encourage fortement à utiliser le profiling sur Datadog qui permet de façon macro sur les traitements d'identifier les problématiques de performance et les coûts de traitement.

27:55 Est-ce qu'il y a d'autres questions ? Là-haut, tout en haut. Oui, pardon, je ne m'entends pas. Oui, oui. Merci pour la présentation. J'ai quelques questions par rapport aux problèmes auxquels j'ai pu faire face quand je veux mettre en place des tests de charge. Déjà, c'est l'environnement, parce qu'on les fait rarement en prod. On les fait dans un autre environnement qui n'est pas équivalent. Du moins, moi, je n'ai jamais eu d'environnement équivalent à la prod. Donc, il y a toujours des sujets. Oui, mais là, tu vois des trucs. En fait, en prod, ça n'arrivera pas. Et l'autre sujet, c'est les scénarios pour être sur des vrais scénarios de prod. Parce qu'on va avoir tendance à booster sur un API, mais qui, en même temps, ne prennent pas en compte la charge courante de la prod sur d'autres scénarios. On a eu exactement ces cas-là. Typiquement, l'environnement cible, c'est toujours une question. Typiquement, chez notre client, il n'y a pas d'environnement dédié à la perf. On faisait ça en pré-prod. Pour le coup, c'était des environnements isoprod. Mais on avait un autre problème que ça amenait, c'était la concomitance des tirs de perf en pré-prod.

28:59 C'est-à-dire que personne n'avait une visibilité globale sur tel jour, il y a l'application A qui tire en même temps que l'application B, et finalement, ça faussait nos résultats. Et d'un autre côté, ce qu'on observait, nous, c'était que la conclusion, à chaque fois, le problème est applicatif. 99% des problèmes qu'on détecte, ils sont vraiment sur la façon dont on a développé ou dont on a configuré un... Et c'est ça qui nous a amené à nous dire, on va prendre le parti de ne pas faire ça en environnement client et d'avoir un cluster Kubernetes qui est dédié à ça, qu'on est capable de monter à la volée. Alors c'est un parti pris, il y a des biais, mais je pense que ce qu'il faut se dire aussi, c'est qu'il n'y a pas besoin d'être... iso-iso à la prod pour apprendre des choses via le test de charge. C'est ça où des fois il y a une certaine dichotomie dans la façon de penser, c'est que si vous y arrivez à être vraiment iso-prod, tant mieux, parce que vous serez en théorie 100% couvrant. Mais déjà avec ce que nous on fait, on apprend plein de choses sur les applications, ça nous permet d'essayer plein de bugs potentiels ou d'optimisation potentielle,

30:00 Et on est très content de pouvoir faire ça tout au long de la phase de réalisation du projet. Tu veux dire, en gros, c'est déjà sur un dimensionnement qui n'est pas forcément le même, et sur une simulation qui n'est pas tout à fait à l'image de la prod, déjà de maîtriser cette partie-là, avant d'aller explorer et de se rapprocher plus, et d'avoir des tirs aussi qui sont plus coûteux, à implémenter et à mettre en place. Sur la partie infra, effectivement, on n'est pas ISO 100% à de la production. Par contre, sur la partie scénario métier, là, on essaye vraiment d'être ISO. Et c'est là où la réflexion de la stratégie de perf elle est extrêmement importante de se dire ok je vais avoir des utilisateurs qui vont faire ça sur mon application en même temps que je vais avoir des flux qui arrivent de tel point etc et d'avoir quelque chose qui est représentatif et là il y a pas mal de jus de cerveau à avoir d'où l'intérêt d'avoir aussi toutes les parties prenantes Et peut-être pour apporter aussi quelques explications supplémentaires, Gatling a été créé par mon associé Stéphane.

31:01 Et à l'époque, ce n'était pas du tout dans l'idée de créer une société. Il a vraiment créé ce framework pour ses besoins pros. Et l'idée, c'était qu'il en avait marre d'attendre qu'il y ait des environnements de prod ISO qui soient dispo, d'avoir les serveurs, etc. Et en fait, il s'est dit qu'il vaut mieux avoir un outil qui est plus facile d'utilisation, qu'on peut déployer un peu n'importe où, quitte à le faire sur des environnements qui ne sont pas ISO, parce que de toute façon, ce qu'on va être capable de voir, c'est d'une version... à l'autre de mon application, est-ce qu'il y a une régression de performance ? Et je n'aurai pas les temps de réponse qui seront proches de la réalité. Par contre, je pourrais voir si mes temps de réponse se dégradent d'un commit à un autre, par exemple. Je suis désolée, malheureusement, le temps file, file, file. Mais ce qui est top, c'est qu'on a une pause. Et donc, vous pourrez poser votre question pendant la pause. Ça va être merveilleux. Je suis désolée. On n'a pas cinq minutes en plus. Ben voilà, tu vois, t'es même à moins. Parce que pour moi, c'était 15h30, 16h05. Ah oui, mais non, en fait, ça bouge. C'est toujours comme ça.

32:01 On a un planning au cordeau. Je suis désolée, mais... Si vous avez d'autres questions, de toute façon, on sera là à côté. Donc, n'hésitez pas à venir nous voir pendant la pause. Oui, parfaitement. Voilà. Et Pierre-Yves, c'était super. C'était super. Parce qu'au départ, vous disiez, je suis toujours un peu, voilà, c'était super. Et je tenais aussi, Alexis, à faire un petit message personnel. On a eu un petit sujet de logo à un moment donné, parce que vous êtes tellement en fusion avec Pierre-Yves qu'on avait mis la SNCF partout. Donc là, on a corrigé en mettant Sopra, Sopra, Steria, pour que ce soit bien clair pour tout le monde. Merci beaucoup à tous les trois. Merci.