Les incidents - le moins on en a, le mieux on s'en porte !

0:09 Aujourd'hui, on va parler d'un sujet qui est parfois considéré comme non intéressant, mais qui devient souvent prépondérant dans la plupart des entreprises. On parlait tout à l'heure de problématiques data dès qu'on passe 200 engineers. Mais il y a une problématique qu'on retrouve souvent quand une entreprise grandit, c'est la gestion d'incidents, le burn-out. Les gens passent 80% de leur temps sur les incidents, 20% de projet, on a réussi à grandir. Donc ça, c'est la problématique qu'on va discuter aujourd'hui. Je vais juste me présenter rapidement. J'ai un parcours chez la Redoute transverse, c'est comment je résumerais. Je fais du software engineering, de la gestion de projet, de la gestion d'équipe IT. Aujourd'hui, je suis en charge de la Transpo Techno, où j'ai encore des équipes plutôt opérationnelles dans mon périmètre. C'est quelque chose que j'ai en tête. Je suis aussi impliqué dans quelques structures à côté. On fait du software, une plateforme de test et du e-learning en automatisation de test. Après, pareil, sur les communautés. Donc moi, je suis aujourd'hui ici parce que je suis convaincu de l'apport et le partage d'expérience pour apprendre sur les pratiques.

1:10 Et pareil, beaucoup en transversalité. Donc là, ce que j'ai listé, c'est les communautés que j'anime entre la France et le Portugal. Donc moi, je suis français, mais ça fait 7 ans que je vis au Portugal et je suis pas mal entre les deux localisations. Voilà, vous voyez qu'il y a du software, il y a du quality engineering, il y a du test, de l'architecture. Moi, je pense que c'est la transversalité qui nous permet de connecter les deux. comme on dit là-dessus. Et Quality Engineering, j'ai fait un white paper avec un collègue qui est Rémi Dehuit, que vous pouvez trouver. Et j'investis aussi personnellement du temps dans la partie recherche. Donc on essaie de croiser deux domaines. Donc c'est la chaîne logicielle, le SDLC, et le process mining. Donc c'est un thème dans la partie data science pour trouver des manières de trouver des modèles de performance dans l'ingénierie logicielle. Voilà donc un peu dans... Quelles sont mes activités et passions? Et donc j'ai retrouvé ce code aujourd'hui que je trouvais intéressant pour commencer à parler de la gestion d'incidents, qui en fait, déjà un bon point, on disait, si vous avez des incidents, c'est souvent que votre entreprise a grandi, bon, il y a des choses qui n'ont pas été faites normalement si vous en avez trop,

2:14 mais c'est quand même que votre produit est largement utilisé, et qu'en fait vous êtes en train de trouver les failles de votre produit, donc soit en termes de design en amont, soit en termes d'opération, vous pouvez avoir des instabilités en production. Et donc je vous invite à lire cet ouvrage de Richard Cook, si vous êtes intéressé, pas forcément que sur les incidents, il est hyper intéressant. Et le titre va être un peu le guiding principal aujourd'hui de ce qu'on va échanger autour des incidents. Donc vous voyez que c'est comment les systèmes complexes tombent ou faillent. Et donc pour partager aussi le niveau d'ambition qu'on cherche tous à atteindre, donc ici c'est le tableau, je ne sais pas si vous avez consulté le dernier rapport d'Aura, ils ont commencé à faire ce type de tableau en plus que les 4 métriques. Et donc vous retrouvez le fameux triptyque sur« on veut tous livrer vite en état de flow». On veut être en termes de performance opérationnelle au top niveau, donc on est au niveau des expectations, et on livre en termes de lead time et de cycle time très très rapidement. Et vous voyez que c'est 17% des respondents.

3:18 C'est des respondents. Moi, personnellement, je pense qu'il y a des gens qui sont souvent en termes de questionnaire, on a tendance à se mettre un peu au-dessus par rapport à ce qu'on est. Donc, je pense qu'en réalité, on est assez loin d'être tous dans ce 17% aujourd'hui en termes de performance. performance opérationnelle. Et donc là j'ai trouvé des chiffres, alors vous verrez la source, vous direz mais elle est hyper ancienne, elle est 2017, mais en fait c'est sur des sources worldwide de toutes les gestions incidents dans les entreprises d'IT. Et en fait ce que j'ai trouvé intéressant c'est qu'ils ont fait des nouvelles études mais les chiffres étaient parfois moins précis ou moins validés, donc j'ai préféré prendre les plus précis, mais ce qu'ils disent c'est... En 5 ans, ça fait x2 x3 ce que vous voyez ici. Et donc ça, c'est le coût des incidents. Et donc quand, c'est un peu comme la partie qualité et test, en fait ça matérialise le coût de la non qualité de ne pas savoir adresser les incidents. Et vous voyez qu'on est vraiment sur des valeurs énormes. Donc la moyenne des entreprises dans les surveys, c'est worldwide, 1200 incidents par mois. 5 majeurs, donc majeur c'est un système critique est tombé, vous ne pouvez plus servir votre service principal au client.

4:23 Des coûts, alors on met 130K plus l'impact sur la brand. Vous voyez aujourd'hui, forcément si vous prenez Uber, etc. C'est tellement énorme que... Mais il y a plein d'autres entreprises où si vous avez un problème de sécurité, un problème d'incident, etc. C'est bien plus que 130 000 euros le coût direct. Donc c'est bien plus que 2 ETP dans votre équipe pour donner un équivalent. Et ce qui m'a aussi choqué, alors ça, ça ne s'est pas vraiment amélioré, c'est que 96% ont une incapacité à apprendre de leurs incidents. Et donc, ça veut dire qu'en fait, ils tournent en boucle sur ce que vous voyez au-dessus. Donc, ils se reprennent en continu les mêmes incidents. C'est les mêmes personnes qui résolvent les incidents, il y a quelques euros dans l'entreprise, et on continue à jeter de l'argent par les fenêtres pour résoudre les incidents et essuyer les plâtres. Donc ça pour moi c'est vraiment, ça matérialise pourquoi c'est important comme sujet à adresser aux entreprises. Il n'y a pas que le build, parce qu'en fait le run c'est aussi ce qui vous paye le build. Donc la première chose à s'y adresser c'est satisfaire vos clients et la partie run. Donc aujourd'hui, sur la partie gestion d'incidents, moi je ne vais pas vous parler de ce qu'il y a ici.

5:29 On fait l'hypothèse que c'est ce que la plupart des entreprises doivent mettre en place. Si vous avez passé l'étape de 0 à 200 plus engineers, c'est en place. Donc ça, je ne vais pas parler aujourd'hui de dire, il y a une gestion d'incident en place avec un incident épris, les catégoriser, on sait c'est quoi le service, on sait c'est quoi le SLA, on sait qui va le traiter, etc. Je prends aussi le postulat qu'il y a une hotline dans votre équipe, donc un 24-7, qui est un vrai sujet d'organisation aussi, mais je ne vais pas vous parler aujourd'hui de comment mettre en place un 24-7 dans une équipe software. Une matrice de priorisation qui malheureusement, dans ce que je vous parlais, n'est plus efficace. Parce qu'en fait, vous avez tellement d'incidents qu'il y a plein de P1, de P2, P3, P4, vous ne savez plus quoi traiter et puis vous êtes vraiment sous l'eau. Même avec ça, ce n'est pas suffisant. Et après j'ai pris le dernier, donc je ne sais pas si ça vous est déjà arrivé, mais j'ai pris le postulat aussi que vous avez déjà survécu, survivre à des P1, donc les P1 priorité 1. Donc vous voyez qu'il y a ici une bombe qui se passe dans les mains des autres. Normalement pour moi les incidents, il y a deux grands objets du quotidien qu'on retrouve. Donc c'est la patate chaude.

6:30 et le parapluie. C'est les deux objets que vous voyez le plus souvent dans la gestion d'incidents, en tout cas quand elle n'est pas proprement adressée. Donc aujourd'hui, on doit tous survivre à ça normalement, mais c'est malheureusement pas suffisant pour la plupart des entreprises. Alors avec Dimitri, quand on a échangé sur le sujet, on s'est dit, mais c'est quoi les questions autour des incidents qu'on aimerait adresser? On se dit, en fait, j'ai tellement d'incidents que je suis en train de me demander lesquels je dois adresser, lesquels je dois ignorer. Parce qu'en fait, on se dit, c'est impossible, je ne peux pas tout faire. Alors là, celle-là, elle est hyper intéressante. En plus, quand les entreprises grandissent, c'est quelles sont les personnes minimum à impliquer pour résoudre l'incident? Je pense qu'on s'est souvent retrouvé avec l'incident, on ne sait même pas qui pourrait nous aider à la résoudre, ou la personne est en congé, ça arrive. Et la question de fond, c'est comment je peux inverser ce train d'incidents de fond qui est en train de justement me tomber en continu comme une pluie torrentielle. Et donc pour moi, j'aime bien, aujourd'hui je suis plus dans la partie transport architecture, moi j'ai toujours une seule question, que je dis souvent trois fois avant qu'on me donne la bonne réponse, c'est c'est quoi le problème?

7:35 J'ai rarement la bonne réponse. Et donc du coup, pour moi, sur la gestion d'incidents, il y a quelque chose de fondamental, c'est comprendre pourquoi en fait on a autant d'incidents. En fait, pour moi, c'est vraiment le sujet de fond à traiter, en tout cas quand vous avez les moyens d'agir sur ça pour inverser la tendance. Et donc je revenais à la citation que j'avais de Richard Cook. En fait, oui, le software c'est de plus en plus complexe. On le voit, c'était déjà assez complexe, mais on rajoute des couches, on rajoute des layers d'interdépendance, on se connecte à 50 serveurs par partie pour faire fonctionner la plateforme. Et donc c'est de plus en plus complexe à comprendre ce qui se passe. Ça c'est la réalité, donc c'est aussi pour ça que l'observabilité est un marché en croissance, en partie. Et moi j'aime bien apprendre des autres industries. Donc vous voyez ce graphe, vous dites c'est old school ce graphe avec des yeux carrés, etc. Qu'est-ce que c'est? En fait c'est l'apprentissage de la NASA et des industries de ce type-là, mais c'est principalement la NASA, sur la gestion d'incidents et de crises, donc dans un secteur hyper critique, si vous explosez une fusée ça vous coûte plus cher que 130 000 euros.

8:41 Vu aussi combien de milliards ont été investis. Et en fait, qu'est-ce qu'on peut apprendre de ça pour le software? Ils avaient au début une approche sur la gauche technique, en se disant, on a un incident, c'est un problème. Je remplace la pièce ou j'achète une meilleure pièce. Globalement, ça se résumait à ça. Après, ils se sont dit, en fait, on a des incidents, parce qu'en fait, c'est des facteurs humains derrière ça, parce qu'on a déjà mis sous contrôle l'aspect mécanique, technique, et donc c'est des facteurs humains, et vous voyez qu'il y en a de plus en plus sur le range. Après, ils ont commencé à analyser, à faire de la recherche, etc. Mais en fait, les facteurs techniques et humains, c'est aussi la conséquence de comment nous, on a organisé le travail en tant qu'entreprise. Et après, ils se sont dit, mais en fait, ce n'est pas que l'organisation, ça devient quelque chose de beaucoup plus complexe. Et on est vraiment sur le système. Donc, j'y viendrai sur le système, comment on peut voir le système de production logicielle. Et vous voyez que sur les années 2000, Les modèles qui ont commencé à plus sortir, c'est si on veut résoudre justement la question, réverser un trend d'incident, c'est l'approche systémique qui permet d'adresser de fond et réellement inverser la tendance.

9:49 Donc voilà, ils ont mis 50 ans à apprendre ça. Nous, en logiciel, on apprend un peu plus vite, mais il y a encore beaucoup de gens qui essaient de résoudre l'incident avec la partie gauche. Et donc, moi, je suis convaincu Il y a beaucoup de choses à appliquer dans la production logicielle et dans la gestion d'incidents sur la partie droite, donc la partie systémique. Et donc je vous parlais de problématiques et d'incidents. Alors moi personnellement, je ne sais pas comment vous voyez, mais quand il y a un incident, on est sur une crise, il y a les gens qui sont tout est feu, tout est flamme, il y a quelqu'un qui a une idée, ils essaient de tout changer en live et tout, on dit moi j'ai tout de suite, personne ne change rien, tant que vous n'avez pas trouvé c'est quoi les deux problèmes. Parce qu'en fait, on dit souvent qu'un incident, j'ai trouvé, c'est parce que X a mis le mauvais paramètre. Mais c'est rarement uniquement ça qui a créé le problème. Pour moi, quand il y a un incident, vous avez souvent deux problématiques qui sont causées, qui font que l'incident se matérialise. Donc là, j'ai mis un exemple, par exemple, basique, mais vous avez une application qui gère les commandes clients, quelqu'un change le code, il n'y a pas de test, il n'est pas vu, il enlève la gestion de retries, ça ne marche plus, mais il ne s'en rend pas compte vu qu'il ne teste pas ça.

10:57 Donc il livre, vous n'avez aucun problème en prod. Sauf le jour où le système que vous appelez en synchrone malheureusement ne marche plus, et là tout votre système de facturation ou de gestion de commandes est down. C'est pour ça que c'est hyper important de comprendre au moins les deux problématiques quand vous avez un incident. Déjà pour moi, c'est un modèle qu'il faut toujours avoir en tête là-dessus. Et ensuite, si on prend un peu de recul, ça veut dire que du coup, quand vous avez un incident, vous avez un facteur chance ou malchance qui fait que votre problème s'est matérialisé. Parce qu'en fait, c'est rarement un truc binaire. technique comme on l'a vu en disant la pièce est tombée. C'est quelque chose de plus profond, de systémique, vous avez des forces en jeu et tout d'un coup ça se passe et ça crée quelque chose en cascade qui peut être... Alors ici il y a un incident mais quand vous avez des problèmes de design ça peut être 3, 4, 5, 10 incidents d'un coup ou vous avez la problématique après de ne pas savoir les gérer. Et donc si on prend encore un peu plus de recul, je vous parlais d'approche systémique. Et donc l'approche systémique dans la gestion d'incidents, ça parle d'un mot-clé qui est, en anglais, les contributing factors, donc facteurs contributifs.

12:01 Mais en fait, ça part du principe, comme on parlait de la NASA, c'est de se dire, en fait, si on a plus ou moins d'incidents, C'est parce qu'en fait, notre système, il influe plus ou moins sur des facteurs contributifs qui font qu'il y a des incidents qui se créent par l'organisation. Donc soit parce qu'après, on fait du mauvais design, on choisit les mauvaises pièces, les mauvaises solutions techno. On a pas la bonne on a on incentivé une culture de héros par exemple ça aussi ça vous crée en fait plus d'incidents à la fin et donc en fait ça veut dire que si vous voulez commencer à inverser le trend d'incidents de manière structurelle, en plus quand l'entreprise grossit, vous avez intérêt à adresser les sujets de fond et pas faire du superficiel parce que ça ne va pas scaler. Il faut adresser ces sujets-là. Et donc ça peut être des sujets internes, externes, des processus, des outils, des facteurs humains, dans un système de production logicielle, comme on le voyait, de plus en plus complexe et interdépendant. Et l'enjeu pour gérer et réduire les incidents de manière structurelle, c'est ça qu'il faut aller adresser. Et donc l'enjeu... pour bon nombre d'entre nous, c'est comment je peux les identifier et après comment je peux agir, les inverser, etc.

13:07 Vous êtes plus dans l'implémentation, etc. Mais aujourd'hui, je vais plus vous partager sur comment mettre en place cette connaissance de contributing factor. Alors moi, dans la vie perso et pro, j'ai trouvé qu'en fait, on peut avoir des buzzwords, des keywords, des outils, etc. Mais qu'il y a quand même plein de choses qui passent par la discipline, la pratique, et savoir faire des choses tous les jours. Avant de commencer à faire des trucs fancy, je parle par exemple, ça va peut-être parler à plus de monde, mais on parle de microservices, etc. Je pense que plein d'entreprises n'en ont pas besoin. Mais avant de faire des microservices, vous devez déjà avoir fait un bon nombre de choses de manière hyper structurée, rationalisée, industrialisée, etc. Pour commencer à faire des trucs un peu plus fancy avec l'événementiel, etc. Donc, ça c'est l'exemple technique, mais c'est pareil dans la vie. Si vous voulez perdre du poids, il faut savoir vous lever tous les jours, ne pas manger, aller courir pendant une heure, faire de la diète, etc. Donc c'est le succès à la fin, c'est le résultat de ce que vous avez fait dans le temps de manière systématique. Et dans la gestion d'incidence, c'est la même chose. Et donc j'ai compilé cette liste que moi je trouve de c'est quoi la discipline de gestion d'incidents qui vous permet d'aller trouver ces contributing factors et de les résoudre.

14:13 Et donc c'est ça qu'on va partager aujourd'hui pour se dire c'est dans cet ordre là que moi je recommande d'adresser la partie gestion d'incidents dans les organisations. Et donc le premier concept que vous voyez dans T-Fragility, Alors, il y a... Les schémas, etc. Mais en fait, il faut déjà partir d'un postulat, c'est mettre tout le monde d'accord là-dessus, en particulier si il y a tous les gens qui ne sont pas de la tech. Bon, elle a déjà demandé à un CEO, elle a demandé comment on fait pour ne plus avoir d'incident. C'était ça la question. En fait, la réponse est la même aussi. Donc, si vous ne voulez plus d'incident, on enlève le software et vous faites tout à la main. Mais il y aura aussi des problèmes, il n'y aura plus d'incident de software. Parce que même si on ne change plus le software, il y aura des problèmes en prod parce qu'il y a un cloud provider qui est dedans ou des trucs qui changent. Donc c'est impossible de ne pas avoir d'incident. Donc déjà, il faut aligner avec tout le monde que oui, alors on va essayer qu'il n'y ait pas de P1, de P2, mais en fait, c'est obligé qu'il y ait des incidents. Parce qu'en fait, vous voulez changer de software pour rester compétitif, vous voulez le livrer de plus en plus vite pour rester compétitif, et vous essayez toujours de l'améliorer avec des nouvelles stacks, des nouveaux produits qui changent votre système de production logicielle qui est déjà instable.

15:22 Donc, ce n'est pas possible de ne pas avoir d'incident. Et donc partager que l'enjeu, c'est un concept de l'anti-fragilité, vous pouvez regarder, c'est sur Nassim Taleb, il a fait un livre là-dessus. Alors il parle plus largement sur les organisations, pas sur le logiciel. Mais en fait c'est la même chose que dans la cybersécurité, ça va faire 5 ans à peu près qu'en cybersécurité on parle plus de cybersécurité, on parle de cyber resiliency, parce qu'en fait on dit, c'est la même chose, on part du postulat de on va se faire attaquer, on risque de se faire voler des choses à un moment ou à l'autre. Et en fait, l'enjeu en tant qu'entreprise, c'est je dois réussir à maintenir mon cœur vital quand je me fais attaquer et à savoir me remettre le plus rapidement possible. Et donc, c'est ce concept d'antifragilité qu'on doit réussir à adresser en termes d'organisation. Donc, vous voyez que le titre de ma présentation, ce n'est pas« The less incident, the better», c'est« The sorter, the better». On en dit aussi moins. Mais l'enjeu, c'est créer cette capacité de réaction à l'incident. Et donc, ce qu'il faut réussir à faire via l'amélioration continue, etc., c'est parler de système de production logicielle.

16:24 En fait, si vous regardez votre système de production logicielle avec les équipes, votre architecture logicielle, Vous devez réussir à créer des écosystèmes qui sont anti-fragiles, donc qu'ils arrivent à... S'il y a un problème, le problème reste localisé, ça évite de créer une cascade dans le reste de votre récit, etc. Et vous arrivez rapidement à le résoudre. Et l'enjeu, du coup, c'est de réussir à créer, par la connaissance que vous allez apprendre sur votre système, à créer ces écosystèmes beaucoup plus isolés à la disruption en production. Donc une fois qu'on a fait ça, qu'on est d'accord sur l'enjeu, c'est pas de ne pas avoir d'incident, c'est d'apprendre pour créer ces écosystèmes résilients, on peut passer à l'étape suivante. Et l'étape suivante, c'est, alors là, il y a beaucoup de textes, etc., mais je peux le résumer, comme je l'avais dit aussi, c'est se mettre d'accord sur le nom de l'incident. Alors si vous parlez entre la prod, le développement, le support, le business, vous mettre d'accord sur le nombre d'incidents, leur impact potentiel, quel système a été impacté, etc.

17:25 C'est déjà une première étape et ce n'est pas évident à faire parce qu'il y a plein de systèmes de métrologie, de log, etc. Donc il faut déjà... Par les disciplines, mettre en place une discipline de on log tous les incidents concept master data référentiel, vous loguez un seul endroit de la même manière et c'est la source of truth de vos incidents et vous commencez à mesurer des métadonnées associées à vos incidents. Et ce qu'il faut garder en tête, c'est que c'est hyper important sur les incidents de les stocker et de garder sur des valeurs absolues. Si on vous parlait, ah oui, en average, on était pas mal. Oui, mais vous voyez ici, et les grosses boîtes, Slack, Google, Onecom, etc., ces nombres d'incidents qu'ils ont et leur impact, la durée, ce n'est pas du tout un average. Vous voyez qu'en fait, la plupart des incidents, les critiques, etc., c'est relativement peu de temps, et vous avez tout au même endroit. Donc ça ne sert à rien. Si vous regardez en average, vous allez vous dire, on est pas mal, on est en fait au deuxième trait orange que vous avez ici, mais en fait, vous êtes nul. Parce qu'en fait, vous avez eu plein d'incidents hyper impactants pour vos clients, etc. Il ne faut pas regarder en average tout ce qui est en incident, c'est mesurer tous les incidents et commencer à regarder les valeurs absolues, qui en fait c'est ça qui va vous apprendre sur votre système.

18:33 Donc on parle souvent de MTDD, regardez pas le MTDD, regardez le TDD par incident, combien de temps on a mis pour détecter l'incident. Parce qu'en fait, plein d'organisations déjà, vous parlez de se mettre d'accord sur nos incidents, plein d'incidents ne sont pas détectés ou faits sous le manteau. Donc déjà, vous arrivez à stocker tous les incidents avec un vrai MTTD, vous allez déjà avoir la vraie performance organisationnelle. Commencez pas à faire du SLA, SRE, enfin toute la dynamique SRE tout de suite si vous n'êtes pas mature, c'est commencez déjà à mesurer les SLA, déjà pour dire, si je prends mes services, quels sont tous les SLI que je supporte et que je délivre. Et c'est toujours important d'avoir des SLI partout plutôt que quelques SLA, parce qu'encore une fois, vous voulez une approche systémique et comprendre l'ensemble du système. Donc il faut plutôt y aller petit pas sur l'ensemble du système que trop vite sur un tout petit bout. Et après, il y a un autre indicateur qui est rarement mesuré dans les incidents, et moi je le suis sur tous les incidents de l'entreprise, c'est combien de personnes individuellement ont été impliquées dans la gestion d'incidents. Combien d'équipes différentes ? Parce qu'on pouvait mesurer l'incident, le first time to resolve, etc.

19:36 La réalité, la plupart des entreprises, c'est jamais first time to resolve, c'est à part les tout petits incidents qu'on peut automatiser. Donc les vrais incidents, souvent, dès que vous passez la première ligne, ça implique 40 personnes, 3, 4, 5, 6 équipes, etc. Qui perdent la moitié de leur journée ou plus sur l'incident. Et donc ça, ça va commencer à vous donner une connaissance de, en fait, est-ce qu'on les détecte? Et en fait, en termes de performance organisationnelle, quel est l'impact? organisationnelle de cette résolution d'incident et ça va commencer à vous donner d'autres pistes que vous allez devoir creuser. Alors avant ça, il y a une troisième discipline. Je sais que je suis pénible avec la discipline, mais... Il y a une autre discipline qui est post-mortem, zéro excuse. Donc moi je disais ça, c'est 100% débrief, zéro excuse. Donc c'est tous les incidents ont un débrief dans les 5 jours maximum. Il n'y a pas d'excuses. Ah non, mais celui-là c'est un petit incident. Non, non, c'est tous les incidents ont un post-mortem. De toute façon, si c'est facile, vous le ferez rapidement. Il n'y a pas de problème. Donc du coup, il faut passer le message qu'en fait, le sujet, ce n'est pas de dire, ce n'est pas grave, en fait, on va traiter que les post-mortem des gros incidents.

20:37 Non, c'est tous les incidents vont vous permettre d'apprendre sur les contributing factors. Et je vous parlais au début que les incidents, en fait, c'est de la chance ou de la malchance. En fait, il y a plein de fois où vous avez de la chance, l'incident ne s'est pas passé. Donc du coup, il y a plein d'incidents qui sont ce qu'on appelle des« near-miss». En fait, vous avez peut-être eu un petit incident, mais en fait, vous avez eu une super chance, ça aurait pu être un truc qui aurait explosé votre plateforme. Et donc du coup, c'est pour ça que c'est hyper important d'être cette règle des 100% débriefs. Et on verra comment aller jusqu'au bout des débriefs. C'est parce qu'en fait, tous les incidents peuvent vous permettre d'apprendre et d'aller éviter des choses bien plus graves par la suite. Et autre facteur important que moi j'ai trouvé, c'est si vous voulez que ça marche, et pour les étapes d'après, il faut qu'il y ait du support exécutif. Donc si sur des incidents, alors ça dépend des tailles d'organisation, mais si le CTO, les SVP, directeur, etc. Ils n'y viennent pas au post-mortem, c'est que tout le monde s'en fout. Donc si vous voulez... Mettre ça en place, vous devez avoir fait le point 1, de faire comprendre que c'est ça qu'on veut améliorer, pour que les gens viennent à ça. Et pour moi, c'est obligé de systématiser.

21:39 Si les gens, à chaque fois qu'il faut y aller,« Non, j'ai une autre idée, je ne peux pas», ça ne va jamais marcher. Autant vous arrêter à l'étape 1 ou 2 ou 0, continuer à gérer les incidents. Donc ça, c'est hyper important là-dessus, d'avoir ce suivi, les gens présents au débrief. Idéalement, nous, ce qu'on fait tous les mois, on fait un récap, etc. Puis on partage, on valorise un peu les coûts des incidents pour dire,« Voyez un peu combien ça coûte. » Parce qu'après, si vous voulez prioriser des choses de résolution d'incidents au même niveau que des projets business, de design, de nouveau, etc. Si vous ne faites pas ça, ça ne marchera pas. Vous serez le gars de la prod qui est emmerdant avec ces petits incidents. Et donc une fois que vous avez ces trois premières disciplines en place, surtout la 2 et la 3, en fait l'enjeu, ça ne va pas être de faire des post-mortem pour documenter les routes causes. Il faut le faire, c'est important, mais votre enjeu c'est d'aller plus loin, c'est vous en tant que leader d'organisation, c'est d'aller... Rechercher et comprendre et documenter tout ce qui est les contributing factors. Parce qu'en fait c'est ça qu'il faut agir en tant qu'entreprise pour vraiment inverser la tendance de manière structurelle. Donc il faut, encore une fois c'est pour ça qu'il faut la discipline organisationnelle, parce que la discipline organisationnelle va vous faire le 1, 2, 3, 4 avec le support exécutif, des gens qui ont plus de drive, des fois plus de recul, et c'est plus facile quand on n'est pas dans l'opérationnel.

22:50 Et le 5, c'est si vous avez au moins 2-3 personnes exécutives, etc., qui vont vous aider. Parce qu'après, Ce que vous allez voir au niveau du contributing factors, ce ne sont plus les problèmes de changer la version. de Java ou changer l'outil de ticketing ou changer des serveurs. En fait, souvent, c'est des problèmes bien plus profonds d'organisation que vous ne pouvez que adresser s'il y a des gens du support exécutif qui peuvent vous aider à agir sur ces leviers. Et donc pour ça, il y a aussi une technique, un peu de piqûre de rappel continu qu'il faut créer dans l'organisation. Alors ici, je vais parler sur deux mots, il y a le côté blameless et transparency, mais si je commence sur la transparency, en fait, si l'organisation n'accède pas à la transparence, encore une fois, il faudra faire le point 1, vous n'irez jamais au bout des incidents. Parce qu'en fait, c'est la transparence qui vous crée l'espace de confiance pour justement identifier ces contributing factors. Donc si les gens ne vont pas jusqu'à dire les vrais problèmes, la root cause, vous n'irez jamais jusqu'aux contributing factors. Et donc en fait, vous n'apprendrez rien et vous continuerez à gérer l'incident en continu. Donc le premier point, c'est la transparence est obligatoire, fondamentale.

23:52 Et la transparence, ça se crée par la confiance, la culture. Ce n'est pas juste dire, ici on est transparent, c'est la valeur de l'entreprise. Ça doit être partagé. Il faut que les gens n'aient pas peur de dire ce qui s'est vraiment passé là-dessus. Et le deuxième point, c'est la partie blameless. Alors blameless, il faut aller sur l'aspect comportement humain là-dessus. Alors moi, il y a deux trucs que j'ai en tête quand je parle de blameless. Le premier, c'est en fait, on a tous peur en tant qu'humain, dès qu'il y a eu un problème d'incident, vous pouvez dire ce que vous voulez, quelqu'un aura peur à un moment de dire, merde, en fait, on s'est filandé, c'est X qui a mal fait le truc, etc. Mais si je le dis, il ne va plus être mon pote, ou moi, je peux avoir un problème sur mon bonus, etc. Donc, il y a toujours ce sentiment de peur qui tourne autour des incidents, et vous ne pouvez pas le négliger. C'est obligatoire. C'est un comportement humain. Et le deuxième, un peu provoque, il n'y a pas de blameless rétrospective. Vous entendez souvent parler en disant, on fait des blameless rétro, c'est super, etc. Donc, on peut pour moi, oui, faire dans l'état d'esprit des blameless rétro. Mais en fait, je pense que le nom, il faudrait le renommer. Alors, je ne sais pas si c'est blame over. En fait, il y a plein d'études sur le comportement humain qui a été fait, qui disent que tout humain va sentir de la blame quand quelqu'un s'est foiré et que ça l'a impacté.

24:57 Directement ou indirectement. Vous ne pouvez pas dire blâme. Parce qu'en fait, vous n'arrivez pas à dire, ah non, mais moi, je ne ressens pas le blame. Donc en fait, ce que vous devez réussir à créer avec vos équipes, c'est, je dois réussir à où les gens arrivent à passer au-dessus du blame. Donc, c'est-à-dire que c'est une nuance, mais en fait, c'est hyper important. C'est que les gens ne peuvent pas refouler ce qu'ils ont ressenti. Et donc, il faut réussir à créer l'écosystème où les gens vont savoir se dire les choses au-delà de leur premier ressenti. Et donc en adressant ça, moi ce que j'ai trouvé, c'est du bon sens, mais la transparence, ne commencez pas à envoyer les messages au codire de débrief, etc. Si les trucs sont à moitié faits, etc. Les entreprises, des fois, je disais, il vaut mieux adresser tout le système, aller progressivement qu'aller trop vite. Commencez déjà par, de tout l'IT, tout l'engineering, tous les incidents post-mortem, quand il y a un problème, tout le monde reçoit. On sait qu'il y a un incident, on est dessus, MTTD, enfin pas MTTD d'ailleurs, TTD, les indicateurs, combien de gens sont impactés. Et les gens voient, ah oui merde, putain, les incidents, bordel, ça commence 1, 2, 3, on s'en prend plein la journée. Les gens se disent, on est nul en fait. Bah oui, oui. Donc c'est vrai que si on les cache, personne ne le voit, c'est toujours les mêmes 3 de la prod qui stoppent les incidents.

25:59 Donc, commencez par déjà mettre quelque chose de systématique en place. On parlait de systématique, déjà si vous commencez à logger tous les incidents, les communiquer de manière systématique, vous allez voir, rien que ça, ça va déjà commencer à changer la perception. Et après, remonter l'organisation. Donc, commencer à communiquer peut-être plus avec le produit, s'il n'est pas l'engineering, etc. Et après, à la fin, il faut remonter au COMEX, pas pour tous les incidents probablement, en tout cas en com quand il y a un problème, mais P1, P2, COMEX, vous êtes au courant, P3, P4, vous faites comme vous faites le monde qui les reporte en disant voilà. combien nous coûtent les incidents. Mais il faut garder cette visibilité complète et transparente pour que les gens puissent agir par la suite. Et après, il y a une pratique que j'ai trouvée qui fait la différence. En fait, on avait mis ça en place, mais on avait du mal à aller comprendre ce qui s'était réellement passé dans les root cause, contributing factors, etc. Et en fait, j'avais le problème, c'était à chaque fois... Le développeur, le tech lead, le managing manager, etc. J'ai pas le temps, j'ai eu ça, j'ai le daily, j'ai le truc, j'ai la roadmap.

27:01 En fait, je me suis dit, mais merde, c'est vrai que nous, en termes d'organisation, on dit, on veut gérer les incidences et structurelles, mais je me suis demandé, dans Accelerate, vous avez la gestion de factory, il dit à chaque fois, comment est-ce que vous faites la planification des ressources? C'est vrai que je me suis dit, putain, je veux gérer les incidences, ça va coûter, je sais pas, 3, 4, 10, je sais pas combien d'ETP à la fin, et en fait, j'ai staffé personne. Et du coup, moi ce que j'ai trouvé efficace, c'est de staffer des gens dédiés à savoir faire cette analyse forensics. Parce que la deuxième fois, je me suis rendu compte que les développeurs, souvent, ils ne sont pas très bons, développeurs ou autres, plus largement, pas très bons à faire de l'analyse scientifique, de découper un corps et comprendre ce qui s'est passé, etc. Mais c'est normal, ce n'est pas leur métier. Comme si vous demandez à un médecin sur le terrain de faire une autopsie, il ne sait pas le faire. Donc du coup, nous ce qu'on a trouvé qui a fait la différence, c'est qu'on a staffé, au fur et à mesure du temps, une équipe d'incident analystes. Dont le taf c'est de structurer, donc une fois qu'on a mis toute cette méthode aussi, on avait beaucoup d'incidents, donc ça nous a fait ça, et qui sont dédiés justement à... à aller creuser tous ces routes causes, à aller coordonner avec les gens, à aller comprendre ce qui s'est passé.

28:05 Et ces personnes-là, au fur et à mesure du temps dans l'organisation, ont une vision hyper transverse et commencent à pouvoir identifier beaucoup mieux les contributing factors. Et c'est pour ça qu'il faut toujours maintenir le support exécutif, parce qu'il y a plein de contributing factors, et les assises d'analyse ne vont pas le savoir. Il n'y a que les gens qui sont vraiment avec la connaissance de l'organisation tous les jours qui vont pouvoir redire, oui, mais il se passe ça parce que je fais des liens entre les équipes, etc. Et ça, c'est que certaines personnes qui peuvent réussir à le faire à ce niveau-là. Et du coup, ces personnes peuvent vraiment être dédiées au problem management. Donc ça veut dire que pour résoudre l'incident, il faut aussi staffer. Ça coûte de l'argent. Ça coûtera toujours beaucoup moins cher que les au moins 130 cas par incident qu'on a vus. Et la dernière étape à partir de ça, quand vous êtes à cette étape-là, vous pouvez commencer à agir sur les contributing factors que vous découvrez. C'est là que le travail devient intéressant, vous pouvez commencer vraiment à inverser la tendance. Donc là, ce que vous voyez ici, c'est ce qu'on construit dans la communauté de Quality Engineering qui est Unite. Mais donc, on a un framework qui s'appelle MAMOS, qui est l'approche systémique, logicielle.

29:05 Je vous parlais, c'est quand on se dit l'approche systémique, c'est... Adresser l'ensemble du périmètre logiciel. Nous on l'a découpé en 5, vous pouvez le découper en 7, en 3, comme vous voulez, etc. Nous on l'a découpé en 5 avec les méthodes, l'architecture, le management, l'organisation, les skills. Et du coup quand on cherche des contributing factors, on va les chercher dans une de ces parts de pizza. Et c'est ce qui va nous dire après où est-ce qu'il faut agir, etc. En se disant est-ce que j'ai un problème de méthode et d'organisation, est-ce que j'ai un problème d'archi et de compétences. Du coup ça vous aide à cadrer votre réflexion là-dessus. Encore une fois, le système production logiciel, c'est quelque chose de déjà suffisamment interdépendant, complexe de base. Donc, changer des choses de manière très précautionneuse, parce que le temps que vous êtes en train de changer, il y a déjà je ne sais pas combien de changements de software qui sont arrivés. Donc, il faut vraiment y aller step by step et vaut mieux, je disais, bien comprendre le problème avant d'agir. En tout cas, moi ce que j'ai vu, c'est 80% c'est comprendre le problème, 20% c'est agir en moyenne pour vraiment traiter les problématiques. Et après, bon, là, c'était des exemples, mais je vous parlais de SCAE, etc. Je pense qu'on crame trop souvent les étapes. On parlait de discipline organisationnelle.

30:07 On essaie trop de faire le truc shiny tout de suite, alors qu'en fait, il y a 60-80% de la base à faire avant, qui est moins intéressante des fois, ou en tout cas moins shiny. Mais on ne peut pas faire l'étape d'après si on n'a pas fait ses fondations. Et l'enjeu, en fait, c'est que ce n'est jamais terminé vraiment. Parce qu'en fait, une fois que vous l'avez mis en place sur un périmètre d'équipe d'engineering, etc., il y a des gens qui sont partis. Votre entreprise a de la chance à la grandir, vous avez de nouvelles équipes qui sont arrivées, etc. Et donc l'enjeu, c'est de réussir d'un point de vue macro, ou dire, est-ce que sur l'ensemble de mon organisation, à quelle étape je suis de maturité ici, et toujours aller sur le niveau 7 au maximum, parce qu'en fait c'est un travail continu d'amélioration, ça ne va jamais être niveau 7, j'arrête, c'est bon, je vais terminer, je suis tranquille pendant deux ans. En fait, il faut vachement maintenir, et il y a des coûts continus. Les incident analysts, le support exécutif, si vous arrêtez au bout d'un moment le support exécutif, il va passer six mois, il n'y a plus rien. C'est ce qui va se passer. Donc c'est un effort continu pour justement répondre aux questions initiales de comment j'inverse mon trend d'incident. Alors oui, en fait, c'est une approche systémique, investissement à moyen long terme, mais c'est ça qui va vous éviter des bulks d'incidents à la chaîne.

31:16 Après, je vous recommande des communautés. Il y a la salle de QUnit si vous voulez la rejoindre. Il y a Tech.Rocks. Normalement, tout le monde ici fait partie de Tech.Rocks. Sinon, c'est le moment d'y rentrer. Et puis encore une fois, je disais, c'est la transversalité pour moi qui permet de connecter les dots dans le software. Donc j'en ai mis une. d'autres ici intéressantes en fonction des centres d'intérêt, plateforme engineering ou modern testing. Voilà, je suis dispo maintenant, merci pour votre écoute.