Autopsie du crash d'une application

0:00 Alors, c'est une étrange aventure que de soigner un malade sans connaître la maladie. Et c'est justement ce que nous allons découvrir maintenant avec les causes et les solutions d'un crash d'application. C'est sous la conduite de Paul-Henri Pillet, le CEO de Gatling, que cette table ronde dynamique va être animée et qu'elle réunit Marie-Caroline Bénézet de SMCP et Jean-Yves Camier de Bedrock Streaming et, nom des moindres, Matthieu Leroux-Huet de Black Scale IT. Let's go! Et je vous accueille, en plus vous allez bénéficier de cette magnifique canapé rouge. Alors, vous savez ce que je vais faire? Parce que je vais partir. Vous savez que moi je ne peux pas rester, parce que maintenant je suis punie, il faut que j'aille de l'autre côté. On a dit, tu fais un peu potiche comme ça, donc bon. Alors je m'en vais, mais en revanche, je vous mets de l'eau, parce que je pense que ça peut être sympa, non? Par contre, il faudra vous passer la bouteille. Ok? Florizio, je m'en vais.

1:04 Pas besoin de zapette? Non, on n'a pas de zapette. Bonjour à tous. On est toujours un peu stressés en coulisses et quand on arrive sur scène, c'est pire. Bonjour à tous. Très heureux d'être là dans ce nouveau lieu pour cet Tech Rock Summit. Je ne peux pas. Ah bah si, restez. Vous voulez partir? Non, pas du tout. Moi, je peux rester si je peux être un doudou, un objet transitionnel. Je peux faire ça aussi. Non, ça va aller? Je pense qu'on est assez nombreux. Oui, moi aussi, je crois. On va parler aujourd'hui des crashes des applications. Et je suis avec trois personnes aujourd'hui qui vont se présenter. C'était important quand on a vu le sujet de ce Tech.Rocks cette année. Personnellement, moi, c'est un problème auquel je suis souvent confronté quand on parle de résilience auprès des entreprises et qu'on vend des solutions qui permettent d'adresser ces problèmes-là. C'est que souvent, il y a soit un déni. du style, on n'est pas Facebook, ça ne nous concerne pas, soit de la dissimulation, c'est-à-dire qu'on va dire non, non, tout marche bien, parce que c'est souvent vu comme un synonyme de travail mal fait.

2:11 Et la solution, c'est d'en parler. Et pour en parler, je suis accompagné de Marie-Caroline, de Jean-Yves et de Matthieu. Matthieu qui présente la particularité d'être le seul prénom non composé sur scène aujourd'hui. Marie-Caroline, si tu veux commencer par présenter. Bonjour à tous, je suis Marie-Caroline Bénézet, je suis directrice des opérations et de la transformation du groupe SMCP, qui est un groupe de mode international qui gère les marques Sandro, Mage, Claudie Pialot et Fursac. Et avant ça, j'ai travaillé pendant six ans à la SNCF, où j'ai beaucoup appris en IT et en gestion de crise, et avant ça, dix ans dans une agence d'innovation qui s'appelle Fabernovel. Moi, Jean-Yves Camier, je suis manager et responsable technique d'une équipe DevOps Core pour la société Bedrock Streaming. On est éditeur d'une solution marque blanche pour faire du streaming de vidéos. Vous connaissez peut-être Sysplay, typiquement, on est derrière. On est anciennement M6 Web, on a changé de nom il y a quelques temps.

3:14 Et donc moi je viens, ça fait 5 ans que je travaille chez Bad Rock Streaming, et avant j'étais en ESN et j'étais notamment à 550 mètres d'ici dans une ESN qui s'appelle Clever Edge pendant 7 ans. Bonjour tout le monde, je suis Matthieu, je suis ingénieur performance software depuis maintenant 16 ans. J'ai fait 10 bonnes années de prestations de services, un peu à droite à gauche, mais surtout dans les services financiers, notamment Banque de France et BPI France, chez qui j'ai animé l'activité de tests de performance et tests de charges. Et puis il y a 5 ans, j'ai lâché la prestation pour rentrer dans le software de lutte contre le blanchiment d'argent et le financement du terrorisme. Et puis après ça, entre deux, une petite aventure en licorne chez Encore Store. Il y en a certains d'entre nous qui sont représentés aujourd'hui. Et puis mes insomnies du moment, c'est de gagner du temps sur la génération des données de test. Merci à tous les trois de venir témoigner à visage découvert aujourd'hui sur ce sujet-là.

4:14 Donc on va rentrer dans le vif du sujet. Un crash, un moment de très forte charge, ça ressemble à quoi? Jean-Yves, s'il y a... Tu veux commencer ? Ça ressemble à finalement une journée comme une autre quand on est préparé. Parce que c'est quand on est dans l'univers de la télévision, de la VOD, du live. Le soir, on a des très forts pics de charge, tous les soirs. Donc on est préparé, on sait qu'on va avoir un pic de charge, on sait que ça va arriver. Après, il y a des soirs où c'est un peu plus fort que d'autres. Donc on est rodé, je dirais plutôt qu'on est rodé. C'est quoi les problèmes techniques que vous rencontrez ou que vous anticipez en tout cas? On a le problème technique une première fois. On sait qu'on va devoir travailler dessus pour le résoudre. Et donc après, on essaye de ne plus l'obtenir. Et donc on va le monitorer chaque jour pour voir ce qu'on peut faire pour l'améliorer. Et sur une architecture distribuée, on est sur des problèmes techniques qui sont multiples parce qu'on est tout le temps en train de bouger un petit peu tard pour faire en sorte que le problème n'arrive que d'un côté et puis peut-être un petit peu de l'autre.

5:25 Et puis on arrive à trouver un moment le curseur pile poil au bon endroit pour faire en sorte que ça marche. Pour les objectifs que l'on a. Tu parlais aussi pendant cette période-là de l'importance de la communication, notamment vos équipes QA qui sont en contact avec vos clients. Oui, tout ce qu'on va avoir en termes de problèmes sur la plateforme, on va avoir une équipe qui va être en charge de les remonter à nos différents clients. C'est sûr que s'ils n'étaient pas là, ça serait différent. Ce sont eux qui gèrent les incidents, ce sont les managers des incidents. Matthieu, pour toi, ça ressemble à quoi dans les différentes sociétés où tu interviens ? Alors déjà, je pense que c'est important de rappeler que ce qu'on appelle un crash, c'est à la fois une interruption soudaine de service, mais c'est aussi potentiellement une dégradation lente des conditions de service qui font qu'au final, l'applicatif n'est plus réellement disponible ou exploitable. Donc un petit ajustement là-dessus. Pour reprendre l'analogie du patient ou du cadavre, on pourrait dire qu'il y a d'une part la partie fièvre avec, comme je disais, un ralentissement de l'application, quelque chose qui se construit dans le temps.

6:34 Et ça, c'est souvent lié à la saisonnalité, soit calendaire avec des trucs du type Black Friday, réservation des billets de TGV, ce genre de choses, ou des échéances mensuelles ou trimestrielles, par exemple. Mais au final, on retrouve là-dedans plusieurs types de signaux. Dans un premier temps, le fait qu'en général, il y a des signaux avant-coureurs qui sont plutôt ignorés ou masqués des différentes consoles, soit par accoutumance aux alertes, parce qu'on a l'habitude de ne plus les traiter, ou alors on ne les comprend pas, soit tout simplement pour pouvoir faire des choses simples. Donc typiquement, les moyennes de temps de réponse restent identiques, mais les maximums, eux, sont cachés, et c'est là que les dégradations peuvent se cacher. Et puis, toujours sur la fièvre, le fait qu'il y a aussi des volumes de fréquentation nettement supérieurs à ceux qu'on attend. Je pense par exemple à l'effet JT, donc 20 heures, j'ai vu ça à la Caisse des dépôts, au moment où ils avaient ouvert leur plateforme qui permettait de... de réclamer les fonds abandonnés des défunts. Au moment où ils ont lancé cette plateforme, ça passe au JT, c'est des dizaines de milliers de personnes qui se sont ruées sur la plateforme en quelques minutes.

7:39 A l'époque, la plateforme avait tenu. Et puis pour continuer sur le deuxième type de pathologie, la partie infarctus, celle qu'on connaît un peu plus, ou en tout cas qu'on se représente un peu plus quand on parle d'une interruption de service, c'est vraiment soit le crash à proprement parler, soit l'introduction d'un défaut qui n'a pas été testé et qui cache une dégradation de performance telle que le service n'est plus du tout disponible. Et donc là, très rapidement, on peut se dire sur le plan technique, ce sont les effets dominos dont on a l'habitude, à savoir une partie de l'infrastructure qui tombe, je dis ça sous le contrôle de Jean-Yves, une partie de l'infrastructure qui tombe, le reste n'est pas suffisant pour maintenir, donc tout ça ralentit. Le load balancer dit, vous êtes mort, donc on arrête. Pendant ce temps-là, les ressuscités ont le temps de recracher, et puis on est sur un cycle perpétuel. Donc là, c'est une avalanche de signaux rouges qui rendent le traitement très difficile. Et pour finir, promis, je ne vais pas parler trop longtemps, il y a quand même d'autres choses là-dedans. Le fait qu'à l'externe, c'est des clients qui sont très frustrés, donc qui ont tendance à vouloir rafraîchir la page pour pouvoir absolument accéder au service.

8:42 Bien sûr, ça n'arrange rien, mais qui s'en soucient, moi le premier. Et puis en interne, une situation technique qui est brutale et qui se transforme assez vite en situation humaine brutale, avec des fois un management qui n'aide pas, il faut le dire. Et donc, on prend des décisions. et on entreprend des actions qui ne sont pas forcément très pertinentes, et on aggrave le problème. Donc on va dire que c'est un petit aperçu, mais bien sûr il y en a d'autres, on peut penser à un service tiers qui est KO, donc du paiement par exemple, une mise à jour Kubernetes, automatique bien sûr, on adore, et puis des incendies de data center pour ceux qui connaissent, des intrusions, des choses comme ça. Un petit aperçu. Et toi, Marie-Caroline, tu as beaucoup d'expériences vécues, d'exemples vécus, d'impact sur les processus métiers et sur le business? Oui, alors moi, je voulais donner un éclairage un peu différent, parce que je travaille dans une entreprise, donc le gros de l'activité est brick and mortar, c'est-à-dire encaissement magasin, puisqu'on a une activité qui est retail avec des clients qui viennent dans nos boutiques, mais également une activité logistique assez importante.

9:49 Et on a aussi une activité web de e-commerce qui est significative. Et donc en fait, les crashs peuvent arriver sur toute la chaîne de valeur, ils peuvent pénaliser plus ou moins fortement l'activité. Et ils peuvent être plus ou moins visibles de la part des clients et avoir plus ou moins d'impact en termes de revenus et de chiffre d'affaires. Pour donner quelques exemples, un crash important, ça peut être quand un matin, il n'y a aucune préparation de commande qui arrive jusqu'à l'entrepôt. Et donc, on a 200 personnes à l'entrepôt qui sont à l'arrêt et qui attendent que le système redémarre ou refonctionne pour pouvoir avoir du travail et puis être efficace dans la journée. Donc ça, c'est des crises qui, typiquement, ne se voient pas tellement du point de vue du client, parce qu'en général, on le rattrape et puis on finit par faire notre journée, mais qui sont quand même très pénalisantes, puisqu'on a des gens qui sont inactifs pendant un certain temps. Et ça, ce genre de phénomène arrive relativement fréquemment et ne se situe pas toujours au niveau des applications logistiques. C'est-à-dire qu'on a aussi une espèce de chaîne informatique qui fait qu'on peut avoir un crash très en amont sur un système qui va faire que le fichier va être mal généré, qui va faire que le fichier transmis va être non lu par le système à la logistique, etc.

11:04 Cet exemple illustre aussi le fait que quand on a un symptôme, typiquement pas de commande qui arrive à l'entrepôt, le temps de remonter la chaîne pour comprendre d'où vient le phénomène initial, on a besoin de beaucoup d'experts différents, de beaucoup de systèmes différents, et ça peut être quelque chose qui pénalise le temps qu'on va mettre pour investiguer et résoudre la panne. D'autres types de pannes, ça peut être, on en parlait tout à l'heure, Un phénomène qui fait que mes TPE magasins ne sont plus connectés à la caisse, pour différentes raisons, ça peut être une panne logicielle de la caisse, ou que sais-je, ou télécom, ou infra. Là, ce qui est assez intéressant, c'est qu'on a des mécaniques qui font qu'on va continuer de pouvoir encaisser en magasin, parce qu'évidemment, c'est le nerf de la guerre, donc ça fait très longtemps qu'on a plein de plans B et de résilience qui existent pour pouvoir continuer d'encaisser. Ce qui fait que d'un point de vue client et puis même d'un point de vue chiffre d'affaires, il n'y aura pas d'interruption. Mais en rattrapage après coup, on a un énorme travail à faire en comptabilité pour rapprocher. Donc ça, ça va être du travail très pénible de la part des équipes comptabilité, mais aussi des équipes IT qui vont devoir mouliner tout un certain nombre de fichiers.

12:10 Donc en termes de crash, c'était pour illustrer le fait qu'on peut vivre en entreprise des phénomènes très différents, relativement fréquents, qui n'ont pas tous un impact visible de la part des clients, mais qui ont tous un impact assez important dans la manière dont on va relancer l'activité, remettre en place les différents flux, perdre du temps, perdre de l'énergie, perdre de la confiance ou perdre de l'argent. Et il y a souvent quelque chose qui est oublié quand on parle de ce sujet-là, c'est que ça nécessite de la préparation. Nous, souvent, on nous contacte un mois avant le Black Friday, et on leur dit qu'ils sont pile dans les temps pour le Black Friday l'année prochaine. Et justement, à quoi ça ressemble, toute cette longue préparation qu'il y a en amont? Peut-être que tu peux nous en dire quelques mots. Alors, en fait, déjà, on n'est pas toujours préparé à tout. Donc, en toute humilité, on progresse d'une fois à l'autre. Et puis, Plus l'entreprise grandit, plus la complexité des systèmes grossit, plus la préparation est difficile et plus intellectuellement c'est très difficile à appréhender. Mais pour se préparer, moi je pense que la meilleure chose déjà c'est d'essayer d'avoir la meilleure compréhension possible du business pour bien comprendre qu'est-ce qui est la priorité à un instant T et ces priorités peuvent changer.

13:22 Si je donne un exemple, nous, nous sommes une entreprise qui est cotée en bourse et nous sommes une entreprise de briques et de mortards qui vend dans des boutiques et qui vend aussi en ligne. Et il y a des périodes de l'année qui sont très critiques pour moi, qui sont les périodes de clôture et les périodes de publication financière, puisque d'un point de vue des systèmes, il faut que tout soit prêt pour que tous les chiffres soient correctement remontés dans les systèmes, pour que la clôture soit la plus juste possible, la plus rapide possible, etc. Donc en fait, ce n'est pas forcément intuitif, mais le Black Friday n'est pas du tout le pire moment de l'année. En revanche, dans certains cas, les moments de publication sont assez critiques. Donc déjà bien connaître ça, faire en sorte que les équipes en charge des différents systèmes aient très bien conscience de ces calendriers-là. Et nous, c'est aller jusqu'à mettre en place des calendriers avec des périodes de frise. Je pense que c'est quelque chose qui est assez typique, mais qui est hyper bien respecté chez nous. Donc il y a des périodes de frise qui sont les périodes d'opérations commerciales importantes, avec les pics d'activité e-commerce et boutique. Il y a des périodes de frise qui correspondent à ces périodes de publication.

14:22 Il y a des périodes de frise qui correspondent à des... Par exemple, on a des périodes de l'année où on fait des ventes de déstockage qui sont assez importantes parce qu'elles correspondent à des pics de charges. Nous les maîtrisons, c'est-à-dire nous les choisissons. Tout ça, ce sont des moments pendant lesquels les équipes techniques savent qu'elles ne peuvent pas mettre en prod des modifications dans les systèmes, sauf exception, exception qui est gérée par un processus très spécifique avec tous les responsables de domaine interrogés et ce qui peut évidemment avoir lieu pour un hotfix ou une réparation d'un problème inattendu. Toi Jean-Yves, ce qui est ressorti de notre discussion, deux choses importantes dans la préparation, les objectifs et l'expérience. C'est surtout ça que tu as voulu remonter ? Oui, mais ça me parle ce que tu viens de dire là, quand tu parles de freeze et d'agenda, c'est vrai que ça change tout aussi. Ce temps de préparation, c'est aussi parce qu'aujourd'hui, on fait du B2B2C, donc on travaille avec des gens qui font le même métier que nous à l'origine, et ils savent ce qu'est un événement.

15:25 Et du coup, ils savent à l'avance qu'ils vont avoir un événement qui va arriver, qui sera beaucoup plus intense que les autres. Donc typiquement, je vous en donne un, l'euro 2024. On savait que ça allait arriver très longtemps à l'avance. Et on savait ce qu'on devait faire parce que tous les soirs, on a des événements plus ou moins importants. On les passe sans trop de problèmes. Mais quand on a des soirs un peu plus importants, en termes de charges, on va avoir peut-être quelques services qui vont clignoter. On sait à ce moment-là qu'on doit s'améliorer sur tel ou tel service. Et donc, vu qu'on sait que l'événement va arriver dans 6-7 mois, on a le temps de s'organiser. Et c'est là que tout va changer. On sait qu'on va faire passer en priorité typiquement un service en particulier qui va être user facing, qui va prendre énormément de trafic, qui va avoir un bottleneck derrière avec une base, avec un cache, avec un Redis. On sait qu'on va devoir y passer beaucoup de temps. Donc tout ça, oui. C'est beaucoup d'organisation et c'est majoritairement même de l'organisation.

16:28 Quand on se donne des objectifs, chaque semaine, sur une correction en particulier d'un sujet qu'on a identifié parce que tous les jours, on est confronté à ce problème-là, on avance. Matthieu, tu m'as donné cette magnifique citation de Mike Tyson. Tout le monde a un plan, je sais à ce qu'il prenne un point dans la bouche. Très belle citation aussi. Il y en a une qui ressemble un peu, qui est« Aucun plan ne résiste au premier contact avec l'ennemi». Donc ça ressemble un petit peu, c'est en gros la même idée. Oui, le sujet c'est que les incidents ça se pratique. Ce n'est pas du tout une chose qu'il faut découvrir au moment où le premier se présente. Il faut être préparé, il faut avoir, on l'a tous fait d'ailleurs, faire des exercices d'évacuation de bâtiments en cas d'alerte incendie. Donc la question c'est, est-ce que ce serait une manière responsable de gérer un bâtiment que de faire aucune alerte incendie et le jour où il y a un incendie, Qu'est-ce qui se passe? Voilà, veut-on vraiment faire ça avec sa plateforme? Je ne crois pas que ce soit une très bonne idée. Donc, à moins qu'on veuille que les gens se jettent par les fenêtres. Donc, le sujet, c'est vraiment, il faut entretenir une pratique dite de chaos engineering, le principe étant d'introduire des défauts contrôlés à des moments entendus, peut-être faire organiser ce qu'on appelle des game day

17:40 pour pouvoir développer cette pratique, s'accoutumer au risque, à qu'est-ce que c'est qu'une cellule de crise, qu'est-ce que c'est qu'une war room, pour ceux qui ont eu le plaisir d'en faire partie. Donc voilà, le chaos fait partie de la vie, et donc il faut vraiment l'intégrer à ses pratiques pour pouvoir en ressortir par le haut. Moi, je peux rebondir sur la gestion de crise parce qu'effectivement, La préparation, ça passe aussi par savoir affronter la crise. Et donc, savoir affronter la crise, c'est avoir réfléchi longtemps à l'avance à qui sont les bonnes personnes à mettre autour de la table si j'avais un phénomène majeur qui se présentait. Parce que l'expérience montre que si on n'y a pas réfléchi à l'avant, on oublie des gens. Et que quand on oublie des gens, on a le risque de surincident ou plutôt de rallonger le temps qu'on va mettre pour résoudre correctement. Donc la première question, c'est qui sont les bonnes personnes? Pour cette cellule de crise et ça peut changer, la réponse peut changer selon le type de la crise. Si elle touche tel système, il va y avoir de toute évidence des personnes responsables du système et si elle touche un autre système, ça sera probablement d'autres personnes.

18:42 Mais ça, c'est des questions qu'il faut se poser à l'avance. La deuxième question, c'est comment on va communiquer entre nous. Et une chose intéressante que moi, j'aime bien me souvenir, c'est la gestion du temps. Dans la communication, il y a non seulement qu'est-ce qu'on va se dire, quelles questions on va se poser, qui va être la personne la mieux placée pour répondre à la question qu'on se pose, mais aussi combien de temps on va lui laisser avant de lui reposer la même question. Parce qu'en fait, quand il y a la crise, Et ça, c'est aussi d'expérience. On va vouloir savoir toutes les deux minutes, enfin, toutes les X minutes, où est-ce qu'on en est. Parce que c'est naturel, on a un site qui est d'un, on a une application qui ne tourne pas, on a des clients qui attendent, on a des gens qui nous appellent, et on a envie de savoir où est-ce qu'on en est. Or, on sait aussi que pour que les gens travaillent sereinement, il faut aussi leur laisser un temps pour qu'ils se concentrent, pour qu'ils travaillent, qu'ils se posent les bonnes questions à eux-mêmes, qu'ils rassemblent leurs... équipes, etc. Donc, gérer le temps, c'est très important. Et ça peut être typiquement se dire, bon, je te pose des questions, tu me dis où tu en es, et je reviens te voir dans 20 minutes, ou dans 2 heures, ou dans 6 heures, ou dans 2 jours, selon le niveau de...

19:46 L'intensité de la crise. Donc ça c'est quelque chose dont je me souviens et qui est assez... J'essaye de me rappeler à chaque fois qu'on a une situation un peu tendue, c'est laisse du temps aux gens pour travailler, dis-leur dans combien de temps tu vas leur reposer la même question. Et la dernière chose c'est quels outils on a. Donc bien sûr il y a... des outils techniques, d'analyse de log, d'analyse de situation, mais il y a aussi des outils de plus de communication, comme mettre en place une main courante pour communiquer largement en interne où on en est. C'est aussi une expérience qui vient de la SNCF, qui était très bien gérée à la SNCF. Puisque, en fait, quand c'est la cata, quand il y a plein de gens qui vous posent des questions qui viennent de plein d'univers différents, les gens ne s'imaginent pas forcément que c'est le chaos. Ils pensent que leur petit truc a un problème. Ils ne se rendent pas compte que ce petit truc, je l'ai 300 fois en même temps. Donc, avoir un outil de communication qui me permet d'écrire ce qu'on a fait, ce qu'on a compris de la crise, où est-ce qu'on en est dans la résolution, qui a fait quoi. Et de le publier pour que tout le monde le voit, c'est un outil assez intéressant et que d'ailleurs les grands acteurs tech utilisent de façon publique.

20:49 Il y a des acteurs de paiement qui ont des pages où vous avez tous les incidents en cours, vous pouvez aller voir sans poser la question à personne où est-ce qu'ils en sont sur tous les types d'incidents et ça je trouve ça assez utile et ça se travaille à l'avance parce que le jour J on ne pense pas et on ne sait pas le mettre en oeuvre correctement. Ce qui est pas mal ressorti de toutes nos discussions qu'on a pu avoir en amont, c'est qu'il y a une nécessité de mettre tout le monde autour d'une même table à un moment donné. Comment on fait ça, justement? Parce que finalement, on se rend compte que ce n'est pas si évident que ça. Difficilement. Parce que justement, une cellule de crise, tout le monde a envie d'être là, et ça fait beaucoup de bruit, et les gens qui sont en train de travailler, des fois, sont un peu concentrés. ce qu'ils sont en train de faire. Donc c'est peut-être la plus grosse difficulté, c'est comment en dire suffisamment à tout le monde sans déranger les gens qui essayent de résoudre le problème. Tu disais même, il faut en permanence convaincre, et ça ne s'arrête jamais, même quand on commence à avoir des pratiques en place. Complètement. Après, pour bien travailler ensemble, il faut s'entraîner quand tout va bien.

21:53 Donc c'est important, par exemple, quand on... Il y a souvent une opposition entre le business qui va vouloir faire une évolution, lancer une nouvelle feature risquée, etc. Et puis l'IT qui va vouloir sécuriser ce qu'il fait, etc. Moi, je pense que ce travail collaboratif, il commence dès l'idée de la nouvelle fonctionnalité et les objections en termes de risque ou de... De coûts, de quantité de travail à mettre sur la table et de risques techniques de plantage après. Et ça ne doit pas s'opposer, c'est-à-dire qu'à la fin, dans une entreprise privée, tout est quand même question de productivité et de gains par rapport à un coût qu'on met en face. Donc on peut tout à fait prendre un risque collectif sur la mise en place d'une nouvelle feature parce qu'on sait qu'elle va faire gagner beaucoup. Et on a exposé à quel point elle nous mettait à risque, par exemple, d'un plantage, mais on peut quand même décider de le faire en se disant qu'on sera là pour monitorer si jamais le plantage arrive et qu'on sait faire un retour arrière ou qu'on sait contourner le moment venu.

22:57 Donc je pense que c'est en prenant les risques ensemble. qu'on est quand même meilleur après pour l'assumer ensemble et donc gérer ensemble si jamais le plantage arrive. Ce qui m'a beaucoup marqué dans nos discussions, c'est que tu dis qu'il faut jouer avec les limites finalement. Tu ne veux pas relativiser, mais tu dis en fait que c'est normal. Tu disais même que si on n'a jamais de crash, c'est que soit on n'est pas optimisé, soit on n'est pas performant. Et on retrouvait cette idée aussi chez toi, où tu parlais de blameless culture, justement, implémentée. Oui, alors la blameless culture, c'est vraiment un sujet très important. Le problème, c'est que les comportements des équipes ne sont pas innés. Ils sont acquis, et acquis en général de manière fine, par ce que les équipes captent de ce que désirent réellement les dirigeants au fond. Donc les équipes sont le fruit de leur environnement, donc c'est à vous et nous, leaders techniques, leaders managériaux, leaders produits, métiers, tout ce que vous voulez, de leur donner les bonnes clés pour pouvoir agir comme il faut.

24:00 Le problème c'est que quand on blâme des gens, on les renvoie à leur passé d'enfant qui s'est fait prendre la main dans le sac pour quelque chose, qui a fait une bêtise ou une maladresse, ce qui n'est pas la même chose, et donc on les renvoie vers cette idée de la prochaine fois pour ne pas me faire prendre, il faudrait que je dissimule. Et donc ça crée évidemment des mauvais comportements qui sont nuisibles à la correction des incidents qui peuvent se présenter, à la fois en manque d'informations sur le plan organisationnel, mais aussi sur le plan technique. On peut très bien mal comprendre un incident, je l'ai déjà vu faire, ça a agacé. considérablement les incidents, une équipe qui veut mettre sous le tapis quelque chose parce qu'ils ne veulent pas se faire gronder. Et en fait, ça aurait été beaucoup plus simple qu'il soit clair dès le début sur pas forcément qui a fait quoi, parce qu'aller chercher l'irresponsable, c'est vraiment la mauvaise manière d'attraper le sujet, mais plutôt de se dire quelle est la cause sous-jacente qu'on suspecte, la vraie. Avec une culture sans blâme, on a vraiment des alertes immédiates, des alertes pertinentes. Et puis, ça permet de... Comment dire ? Ça permet d'avoir des seniors qui reprennent, au lieu de reprendre les rênes sur des incidents qui font de la vraie formation auprès des juniors.

25:08 Et puis on développe au final, parce que c'est ça la finalité, avoir un esprit de corps qui permet d'évacuer l'individualisme, d'évacuer l'arrivisme et de se dire ensemble on arrive à un même but. Tout à l'heure, on faisait l'analogie avec le rugby. C'est vraiment celui-là ou n'importe quel autre sport co. C'est un objectif commun qui est poursuivi. Et ce n'est pas des histoires d'exploitation de la plateforme ou de monter le dernier modèle d'IA à la mode. C'est la poursuite d'un objectif business. Tout ça, ce n'est jamais que des outils. On arrive au bout de cette table ronde. On avait plein d'autres éléments, mais on va laisser la place aux questions. On a fini avec la partie autopsie, on va pouvoir passer à la partie plus consultation. Donc, Si vous voulez parler de vos problèmes, comme vous l'avez compris, c'est vraiment le message qu'on voulait faire passer, c'est que déjà, ça passe par en parler et intégrer ça complètement dans le quotidien des entreprises et des équipes de DEF. On n'a pas trop parlé de la partie prévention, mais au moins le patient est bien pris en charge après.

26:14 Merci à tous. Doudou, pas doudou. Comme vous voulez. Non, mais je pense que là, vous êtes bien, là. Est-ce qu'il y a des questions? Il y en a une devant, là. Sur la partie analyse, qu'est-ce que vous mettez en place pour automatiser la détection, l'analyse, la correction? En revanche, il faut des réponses quand même. Je réfléchis. On parle de quoi comme analyse? Au moment d'un crash, sur quoi? Aujourd'hui, il n'y a pas 36 000 solutions, c'est le monitoring qui nous aide.

27:18 Donc on va avoir un monitoring applicatif et un monitoring infra. Les deux vont être généralement très corrélés, puisqu'on fait du Kubernetes, donc on a beaucoup d'infra pour rentrer sur les clusters, et après chaque application a son APM. Et donc, voilà, les deux corrélés. Ensuite, en termes de... De résolution d'incidents automatisés, ça peut arriver que ça fonctionne, parce qu'on est sur Kubernetes, des fois ça marche, ça scale plutôt pas mal, et puis des fois il y a des crashes qui sont quand même assez durs de revenir en arrière, et il faut quand même quelques interventions, donc typiquement sur Kubernetes, on peut arriver, quand on scale beaucoup trop fort, à complètement saturer les API de Kubernetes et derrière on va avoir des problèmes au niveau de TCD qui va saturer, qui va avoir du mal à travailler avec l'ensemble de la stack et du coup ça va être compliqué. Même au niveau d'ailleurs de la partie Prometheus, de la partie monitoring infrastructure, on peut avoir des problèmes côté monitoring parce que trop

28:21 trop de trafic et derrière ça peut engendrer des problèmes de par exemple d'applications qui vont plus pouvoir scaler parce que sur tes HPA, tes horizontal pod autoscaler, tu vas avoir une métrique qui dépend de Prometheus. Et donc en fait on retombe sur le sujet des dominos C'est plein de choses qui sont ensemble et qui fonctionnent bien. Et à un moment, effectivement, il peut y avoir un potard qui n'est pas bien réglé et ça peut tomber. Donc oui, on a ces outils-là qui nous aident, mais ce n'est pas tout le temps parfait. J'aimerais ajouter un volet à cette réponse-là. Je pense qu'on vit une époque où il y a de nouveaux outils qui sont en train d'émerger, ou en tout cas de nouvelles perspectives. On est assez gourmand, assez friand de ces nouvelles possibilités. On se dit que ça va résoudre tout un tas de problèmes qu'on avait dans le passé et qui vont être solutionnés de manière automatique. Peut-être. En attendant, beaucoup des problèmes que j'ai vécu venaient de manière générale d'un manque de collaboration, d'un manque de configuration basique des outils de monitoring, avec juste simplement des outils qui sont capables de crier sur des alertes

29:22 par défaut, mais avec aucun destinataire, ou des personnes qui ne les regardent pas. Et derrière ça, aussi de manière générale, une incompréhension générale du système. Il y a même des organisations qui ne donnent pas accès à l'ensemble de leurs équipes aux outils de monitoring. J'ai un client pour qui j'ai travaillé récemment, que je ne vais pas citer naturellement, mais chez qui j'ai pu accéder aux données de monitoring nécessaires pour mes tests uniquement parce qu'il y avait une faille de sécurité dedans. Et quand ils l'ont découverte, évidemment, ils l'ont patchée, donc je n'ai plus accédé aux informations. Donc je dirais qu'il y a la partie modernité, les nouveaux outils, EBPF, tous ces outils de profiling super, avec sans aucun overhead, qui font des choses fantastiques, super. Mais il y a des basiques, c'est-à-dire est-ce que nous, en tant qu'organisation, on est capable de décider d'un objectif et de s'y tenir? Ça malheureusement, encore une fois, de mon expérience perso, en 15 ans, j'ai rencontré un client qui avait fait vraiment le travail de se poser et de se dire quels sont nos objectifs en termes de performance et si jamais on les dépasse, qu'est-ce qu'on fait?

30:24 Dépasse au sens si on dépasse les seuils de déclenchement d'alerte. Est-ce qu'on débranche ci? Est-ce qu'on débranche ça? Voilà, donc les nouveaux outils super, mais les fondamentaux à soigner aussi. Et peut-être pour rebondir sur la question de l'automatisation, on en parlait un peu ce midi et on se disait que le plus important c'est d'y aller étape par étape. Souvent l'automatisation ça arrive plutôt après. Effectivement, nous ça nous arrive d'intervenir dans des sociétés où déjà il n'y a pas d'APM en place, donc c'est la première chose qu'on met en place. Après pour les tests de charge, puisque c'est notre expertise, on commence petit, on commence à les mettre en place, on commence à les faire manuellement et l'automatisation arrive bien après finalement, il va arriver assez naturellement une fois que c'est en place, une fois qu'on a cette culture qui s'est installée et que les gens commencent à comprendre comment utiliser tout ce reporting, toute cette donnée qui va être créée au-dessus des applications. Juste pour me dire très rapidement sur ce que tu dis, je pense que ça parle aussi de cette idée qu'on pense que les défauts de performance sont visibles qu'à très gros volumes. On va dire 4 défauts sur 5 sont identifiables avec juste un acte.

31:25 On a envoyé une commande, on a un outil de monitoring derrière qui est capable de faire le travail. Et tous ces défauts-là, on peut les identifier. Bien sûr, il y a des problématiques liées au scaling derrière qu'il faut traiter, mais il ne faut pas s'enfermer dans la croyance que la performance et la charge en particulier, c'est quelque chose qui n'existe qu'à très fort volume, qu'avec des environnements isoprods extrêmement coûteux, on peut commencer avec de très petits moyens. Ce qui est vrai à très fort volume n'est pas forcément vrai à petit, mais vous allez débusquer des choses qui sont vraies dans tous les cas. Donc je pense que c'est important de tacler ces sujets-là. Commencez par scaler pour un, branchez vos solutions de monitoring pour pouvoir voir ce qui se passe sous le capot, et quand vraiment vous aurez solutionné tous ces problèmes-là à un utilisateur ou à une requête, alors ça vaut le coup de rentrer dans la partie automatisation. Et je rajoute un dernier élément, c'est qu'on vit aussi une époque où tout automatisé c'est super, tout le monde va vous parler de continuous deployment, continuous testing, mais une activité qui est profondément exploratoire, c'est justement le test de performance, c'est justement le tuning, et ces choses-là ne peuvent pas se passer de manière naturelle et complète dans une CI-CD.

32:26 La machine ne va pas faire le travail de tuning à votre place. Vous allez me dire, oui, il y a de nouveaux outils qui... Oui, voilà. Donc il faut commencer en faisant vraiment le travail. Ne remplacez pas votre travail par des outils tant que vous n'avez pas un degré de compréhension minimum sur le sujet. Les tests automatisés ne peuvent pas remplacer les tests exploratoires complètement. Ce n'est pas possible. Donc il faut continuer d'avoir cet espace pour des tests manuels. Moi, je rajouterais à très forte charge les outils. Au final, ce n'est pas ce qui va nous aider. C'est plutôt des patterns qu'on va retrouver dans les applications. Donc à très forte charge. De la Graceful Degradation ou du Circuit Breaker, ça sauve une application, ça sauve une plateforme, vraiment. On a fait une question en cinq minutes. On a le temps pour une deuxième question. Vous êtes trois aussi, c'est pour ça. Il y a des éclairages complémentaires. Y a-t-il une autre question? Oui, Dimitri, Back Market. À quel moment vous déclarez un incident? On a le blameless pour dire qu'on en parle, mais à quel moment on déclare qu'on a un incident versus un bug dont on ne parle pas forcément?

33:31 Je vois beaucoup d'équipes qui ont peur de déclarer un incident parce que c'est une charge de post-mortem, d'analyse et tout ça. Donc, vous savez quel est le degré, quelles sont vos clés pour dire là, c'est un incident ou c'est un crash versus c'est un bug. Alors réponse facile mais partielle à ta question qui est dans un premier temps est-ce qu'on a dépassé les seuils d'alerting? Je reviens à ce que je disais tout à l'heure, souvent les seuils ne sont pas définis donc il faut commencer par là. Le deuxième truc c'est, tu dis les gens ont peur de déclarer des incidents, on rentre dans le sujet de la blameless culture, c'est-à-dire à la fois il y a une charge de post-mortem mais est-ce qu'on a le droit de se tromper quand on a déclaré un incident? Tout à l'heure, tu parlais du blâme. Là, c'est même une question de charge de travail. Tu peux ne pas être blâmé. Par exemple, tout le monde te félicite d'avoir déclaré, mais après, c'est toi qui te payes la paperasse, les interviews et tout ça. Oui, je pense qu'on porte sa responsabilité. On est complètement propriétaire de son sujet. Donc oui, on ouvre un sujet. On a ce courage-là de se dire, je pense... qu'il y a un problème. Moi, à titre personnel, je l'ai fait chez Encore Store et ce n'était pas un vrai problème de prod, c'était un problème lié au monitoring.

34:36 Et personne ne m'a sauté dessus en me disant« t'as fait un mauvais boulot». Au contraire, on m'a encouragé à continuer à ouvrir des incidents, bien sûr, on m'a encouragé à animer les post-mortem. Donc voilà, il faut porter sa responsabilité. Mais après, la question que tu posais, c'était comment est-ce qu'on qualifie un incident de prod versus un bug? Je dirais que la question, c'est celle de l'impact client. Est-ce qu'il y a un impact sur le business? Et donc là aussi, dans la perf, on se laisse facilement enfermer dans des indicateurs purement techniques. C'est une grosse erreur. Il faut absolument monitorer le chiffre d'affaires sur le temps. Une société qui a une plateforme qui tourne où tout est vert, mais on n'a pas vendu un euro de toute la journée, c'est un problème. Donc je dirais, il ne faut pas se cacher dans la dimension technique des choses et au contraire travailler avec le métier là-dessus. C'est vrai que je n'en ai pas parlé, mais chez nous, typiquement, sur l'aspect métier, on a aussi une plateforme de monitoring qui, du coup, lorsqu'on a un problème sur la plateforme qui est vraiment un problème qui est détecté par les utilisateurs, on le voit. Vous allez avoir du buffering quand vous regardez une vidéo ou ce genre de trucs.

35:36 Vous allez avoir une chute brutale du nombre de personnes en train de regarder les vidéos. Et donc à ce moment-là, ce sont des incidents qui existent. Et donc là, c'est le manager d'un incident qui va déclarer un incident et ensuite qui va chercher la route cause. Marie-Caroline, vous vouliez ajouter quelque chose, non ? Oui, je voulais rajouter que l'angle business était assez important pour décider ce qu'était un incident ou pas, parce qu'à la fin, c'est ça qui décide, je pense. Mais il y a aussi quelque chose que je me disais, c'est que ça va dépendre aussi de la trajectoire que tu prends en tant que produit et les évolutions vers lesquelles tu vas. Parce qu'à un moment donné, quelque chose qui a un signal faible, un incident qui a un signal faible à un moment donné, s'il porte sur la partie que tu es en train de renouveler complètement et sur lesquelles tu te poses beaucoup de questions pour l'avenir, il va plus t'intéresser que les autres. En fait, il y a plein de dimensions qui peuvent te permettre de décider si tu veux passer du temps sur un incident ou pas. Et j'illustre ça avec une chose très simple qui est l'élément le plus critique de votre plateforme, ce n'est pas l'élément central métier qui est vraiment au milieu de votre business, c'est votre solution de monitoring.

36:42 J'ai vu beaucoup de clients qui considèrent que la solution de monitoring n'est pas critique au business et donc ils provisionnent ça sur des environnements qui ne sont pas redondés. Sauf que le jour où votre plateforme de monitoring tombe, comment vous êtes capable de dire que votre plateforme fonctionne? Donc les plateformes de monitoring, c'est ça l'élément le plus critique de votre business. On se quittera là-dessus, si vous êtes bien d'accord tous les quatre. Merci infiniment de cette table ronde. Merci Pierre-Henri d'avoir animé ça avec brio.