La DevX pour accélérer et engager votre équipe technique

0:04 Bonjour, je suis Aurore Malherbes, cofondatrice et CTO de Padok. Je vous retrouve tout de suite. Bonjour à tous, je suis Aurore Malherbe, CTO et cofondatrice de Padok, une startup du groupe Théodo. Nous construisons, sécurisons et opérons des infrastructures cloud et on-premise avec une équipe d'une petite soixantaine de personnes. Ça c'est pour les heures ouvrées, et pour les heures non ouvrées, je mets ça au trail et à la couture. Mais je ne suis pas là pour vous parler de ça, je suis là pour vous parler de Devix. En effet, je pense qu'une grande partie de mon rôle de CTO consiste à donner un cadre et des bonnes conditions à l'équipe technique pour qu'elle puisse développer des bons produits et s'épanouir techniquement. Et je pense que la DevX peut être un des moyens d'y parvenir.

1:07 Mais avant de rentrer dans le concret, on va revenir un peu à la théorie. Je voudrais citer William Kahn, qui est un psychologue et qui est le premier dans les années 90 à avoir théorisé ce qu'est l'engagement employé en général. Pour lui, il y a trois piliers. Le premier pilier, c'est l'engagement cognitif, c'est-à-dire je comprends la mission de mon entreprise, je comprends sa vision et je sais comment y contribuer. Deuxième pilier, l'engagement émotionnel, c'est-à-dire que je partage des valeurs avec mon entreprise, je m'entends bien avec mes collègues et c'est aussi dans cette catégorie que tombent tous les sujets de reconnaissance, que ce soit la reconnaissance verbale mais aussi par exemple la reconnaissance salariale. Le dernier pilier pour moi était moins clair. Le dernier pilier, c'est l'engagement physique et mental. Le fait de pouvoir vraiment s'engager d'un point de vue physique si on a un travail plutôt manuel ou plutôt mental si on a un travail plutôt théorique comme nous. Je me suis longtemps demandé à quoi ça correspondait dans notre milieu.

2:07 J'ai lu plusieurs interviews, notamment de William Kane. Et à un moment, il parlait du fait que cet engagement physique, il permettait aux employés de« flying around their work». Désolée pour l'accent anglais, mais l'idée, c'était de dire que c'est vraiment des gens qui vont survoler leur travail. Ils vont réussir à être engagés à un tel point que tout va paraître facile. Ça m'a fait penser à une autre lecture, un livre qui s'appelle Stealing Fire et qui parle de la notion de flow. Le flow, c'est quoi? C'est un état mental dans lequel on est vraiment en pleine possession de nos moyens et on est extrêmement performant et extrêmement satisfait de ce qu'on fait à l'instant T. L'état de flot peut être atteint à travers des drogues, je ne suis pas là pour parler de ça non plus, mais par exemple aussi peut être atteint à travers de la méditation ou d'autres techniques comme des chambres avec des bruits blancs par exemple. Pour info, l'état de flot, c'est ce qui permet aux seals américains d'apprendre l'arabe en trois mois avant d'être envoyé au Moyen-Orient. Donc c'est vraiment un état où on va être en état de surperformance.

3:09 Et ce que je me suis dit, c'est que finalement, la DevX, c'était peut-être atteindre cet état de flot. En tout cas, supprimer tous les irritants des journées de nos développeurs pour atteindre cet état de flot. Du coup, j'ai envie de vous raconter une histoire. Dans notre histoire, on a deux protagonistes. On a Alice, elle est développeuse dans une équipe de cinq personnes, l'équipe paiement. Elle a cinq ans d'expérience en Spring Boot. Elle est également honneur de la brique Stripe. C'est vraiment son expertise au sein de notre entreprise. Elle est plutôt calme. Elle aime bien lire des romans anglais et puis elle joue au hockey sur gazon le week-end. Deuxième protagoniste, Bob. Bob, il est SRE dans l'équipe plateforme, ils sont une plus petite équipe, ils sont trois. Ça fait trois ans qu'il travaille sur Kubernetes, il est certifié AWS et il est très fort en index Postgres. Bob, il est plutôt impulsif et le week-end, il se calme en faisant de l'escalade et du code name. Après Père Castor, je vous cite une autre inspiration. Grand Corps Malade, il a fait une chanson où il raconte toute une journée en détaillant heure par heure ce qu'il fait.

4:14 On va faire exactement la même chose avec nos deux protagonistes. Je vous rassure, je ne vais pourtant pas chanter. 9H01, le Daily. Alice s'engage sur une chiture. En tant qu'utilisateur, je peux appliquer mon code de discount à mon abonnement. Et Bob s'engage sur une autre... à destination des développeurs. En tant que développeur, je peux déployer mon nouveau front-end, donc www.monnouveaufront-end.com, en staging et en production. Donc la journée commence bien, mais à 10h56 arrive le premier problème, le premier irritant en fait. L'authentification à deux facteurs sur le compte AWS a été activée il y a quelques temps. Or, Bob, il code en Terraform. Qu'est-ce que ça veut dire de coder en Terraform? Ça veut dire qu'il code pour tester. son code pour tester ses modifications, il doit l'appliquer et donc en fait finalement se connecter à un compte AWS distant pour opérer des changements ou créer des nouvelles briques AWS. Le fait que l'authentification à deux facteurs ait été activée, ça le force toutes les heures à se réauthentifier dans son terminal.

5:19 Or, ça l'irrite. Qu'est-ce qu'il fait Bob? Il fait ce que tout le monde ferait en entendant parler de Devix, c'est-à-dire je me code un outil. Donc il fait un petit script shell qui va l'authentifier à sa place avec un petit cron qui tourne toutes les heures tant qu'il est logué. Ça c'est très bien, comme vous le voyez en plus c'est un script qui est guité. Ceci étant dit, il a fait pour moi la moitié du chemin. L'autre moitié du chemin, c'est de parler de cet outil et c'est de le partager à son équipe. Nous, chez Padok, on a ce qu'on appelle un moment qui s'appelle le Yokoten. Yokoten, ça veut dire diffusion en japonais. On est assez fan de mots japonais. Ça, c'est une autre histoire. Et c'est un rendez-vous qui a lieu tous les mardis matins et on va partager des histoires. Donc, ça peut être des histoires plutôt pas drôles, des cicatrices, des post-mortem. Ça peut être des réussites, ça peut être des tips et ça peut être des démos d'outils comme la Fébom, en disant« Ah, moi, j'ai fait ça, ça me fait gagner du temps» ou tout du moins, ça me fait gagner de la charge mentale.

6:21 Et je vous conseille de l'utiliser, il est disponible ici. On passe au problème suivant, on va passer du côté d'Alice. Alors, ce n'est pas vraiment Alice qui a un problème, même si ça va devenir son problème finalement, c'est Robert qui a un problème. Robert, c'est son PO. Il est en train d'essayer de tester la feature qu'elle a fait la veille. C'est une feature qui consiste à avoir tout un funnel de partenariat. Et il vient la voir parce que ça ne marche pas. Il appuie sur le bouton et il y a l'odeur infinie. Alice, elle est plutôt calme, elle est plutôt gentille. Elle se dit, bon, OK, je suis en plein milieu de ma tâche, mais je vais aider Robert à valider. On va voir son journal d'investigation. 11H24, elle vérifie le bug. Bon, OK, il s'est bien trompé. Il ne s'est pas trompé, pardon. Il y a bien un bug et un lodeur infini. 11h30, elle retrouve le ticket de la veille parce que ce n'est pas elle qui l'a fait, c'est son collègue. Elle regarde le ticket Trello, elle regarde le code comité, elle se dit« Ok, c'est bien comité, ça a bien été déployé, donc ça devrait être en production. » C'est une feature de partenariat, donc elle pense à un bug de variate d'environnement.

7:25 Peut-être qu'on n'appelle pas les bonnes URL de nos partenaires. Elle creuse dans ce sens-là, elle creuse, elle creuse, mais elle ne trouve pas la cause. Et à 45, donc 20 minutes plus tard, elle se dit« Ah mais non! » Je sais en fait, il y a l'équipe onboarding, eux aussi ils arrivent à la fin de leur sprint, donc ils sont en train de délivrer toutes leurs futures sur la plateforme de clients. Si ça se trouve, ils ont développé une branche qui est plus ancienne que la branche qui contenait la future de partenariat et ça a écrasé le code. Donc là, elle se perd dans les répositories et tout, elle va vraiment, elle investigue. Et elle se rend compte que oui, c'est ça en fait le truc. dernier commit déployé sur l'environnement de test ne contient pas le code de la feature partenariat. Qu'est-ce qu'elle fait? Elle redéploie la version et 20 minutes après, la version est sur l'environnement de test. Elle dit à Robert« dépêche-toi de tester, tu as toute la pause déjeuner pour tester» parce qu'on n'est pas à l'abri que la team onboarding se dise« ok, je vais redéployer» et Robert revient de la voir en disant« je ne comprends pas, ça ne marche pas, je suis au milieu du parcours,

8:28 ça ne fonctionne pas». Qu'est-ce qu'on peut faire pour régler le problème d'Alice? On peut générer des environnements à la volée. Un environnement à la volée, ça veut tout et rien dire. Il y a 25 000 définitions. Un environnement à la volée, ça peut être un environnement finalement qui n'est pas tant à la volée que ça, c'est-à-dire un environnement par feature team. On pourrait imaginer que l'équipe paiement a son environnement de test, que l'équipe onboarding a son environnement de test, et que ces deux environnements se rejoignent entre guillemets en pré-prod. Un environnement à la volée, ça peut aussi être, je push une branche qui s'appelle feed slash quelque chose, le nom de ma feature, et automatiquement j'ai un nouvel environnement qui est créé avec les bons microservices, etc. Je donne l'URL à mon product owner ou à mon QA, il teste la feature et ensuite l'environnement est détruit. Là, je vous avais un screenshot, par exemple, d'un outil qui s'appelle ArgoCD et qui facilite la création d'environnements à la volée quand vous avez des environnements qui sont kubernetes. Alors, il y a des gains qui sont indéniables.

9:30 avec les environnements à la volée. Vous ne vous marchez plus dessus pour les tests. Vous êtes obligé de standardiser vos environnements. Ça vous aide pour le jour où vous avez besoin, par exemple, de monter un environnement de démo pour un client. Et ça vous aide aussi pour le futur. Ce qu'on voit, c'est qu'avec les microservices qui prolifèrent, on a souvent des environnements locaux qui finalement sont trop lourds pour un ordinateur local d'un développeur. Et un environnement à la volée, ça va être un premier pas vers décentraliser ces environnements locaux. Finalement, avoir... des environnements locaux distants, avec quelques microservices qui tournent en local et le reste qui tourne dans un cloud provider. Donc ça c'est beau sur le papier, ceci étant dit, il y a des points d'intention. Le premier point c'est les coûts. Les coûts sont de deux natures. Il y a des coûts cloud, vous avez besoin de plus de machines, vous avez besoin de plus de serveurs, vous avez plutôt intérêt à faire attention à la destruction de ces environnements, mais vous avez aussi un coût de maintenance, un coût de création, un coût de maintenance, un coût humain finalement. Un grand sujet avec les environnements à la volée, c'est la data aussi.

10:32 On oublie très souvent de créer des bases de données qui vont être par environnement généré à la volée, avec des fixtures, et on se retrouve, ça marche très bien pendant une semaine, puis à un moment, un développeur pousse un changement, il y a une migration de schéma appliqué sur la base de données qui passe, et l'environnement ne marche plus pour personne. Ça, c'est quelque chose à prendre en compte dès la conception. Et puis enfin, qui dit environnement, dit environnement à maintenir, je vous l'ai dit, mais à débuguer quand il y a des problèmes. C'est un environnement souvent sur lequel travaillent entre 20, 50, 100 développeurs. Donc le jour où l'environnement est en carafe, vous avez 20, 50, 100 personnes qui ne peuvent pas travailler. Donc l'observabilité de cet environnement est clé. 12h05, nouveau problème. Alors en soi, ce n'est pas encore un problème. On revient dans l'équipe plateforme. On a Carole qui a fait des retours de code review à Bob. pratique, somme toute, normale. Globalement, qu'est-ce qu'elle dit à Bob? Elle dit« ton code, il est top». Je revois cette partie qui correspond au bucket et au CDN du nouveau staging.

11:36 Ceci étant dit, j'ai l'impression que tu l'as déployé pour un front qui serait en React. Et souviens-toi, le nouveau front, ils veulent le faire en Angular. Donc, il faut que tu vérifies que tes settings correspondent à un front Angular et que tu changes cette variable qui a React dans le nom. Bob, il est un peu énervé. Pourquoi? Parce qu'en fait, il sait que Carole a raison. Il sait qu'effectivement, c'est pour un font React et qu'il avait oublié, mais ça va être du Angular, ce nouveau font. Alors déjà, il se dit, OK, pourquoi on multiplie les technos? Mais on ne lui a pas demandé son avis et on n'est pas sûr qu'il compte dans ces cas-là. Mais en fait, surtout, il est énervé contre lui parce que qu'est-ce qu'il a fait? Il a pris du code d'un autre repository, il l'a copié, il a essayé de se souvenir ce qu'il fallait changer facilement. Il a commité ça, envoyé ça et puis il s'est dit ok ça va passer je vais vite pouvoir passer à autre chose Parce que finalement, déployer un staging ou une prod, déployer un front-end, Bob, ça ne l'amuse pas beaucoup. Ça, il l'a fait maintes et maintes fois, plus d'une dizaine de fois, on va dire, dans les six derniers mois.

12:38 Lui, en attendant, il sait que le monitorique de sa prod, il n'est pas très fin, qu'il est un peu aveugle. ou du moins malvoyant, il aimerait bien passer du temps là-dessus, plutôt que passer du temps sur quelque chose qui juge assez facile techniquement, et finalement avec pas beaucoup de valeur ajoutée pour son job au quotidien. Alors Bob, on le comprend. Et une des manières de gérer cette irritation, c'est l'inner source. L'inner source, c'est quoi? C'est de l'open source, mais à l'échelle de votre entreprise. C'est se dire, j'ai une bibliothèque de composants. Ça peut être, par exemple, dans le cadre de Bob, des composants Terraform, des composants qui vont lui permettre de déployer une base de données de tel type, de déployer un front-end de tel type, une chaîne de CICD, etc. Ça peut être un template d'API, ça peut être des composants front-end partagés. C'est vraiment quelque chose qui va être à disposition de toute l'équipe technique dans l'entreprise. Alors, les gains de ce genre d'approche. Vous allez plus vite. Donc Bob, au lieu de passer quasiment la journée sur cette future-là, il aurait pu le faire en une heure, une heure et demie et se consacrer au monitoring.

13:42 Mais un des effets cachés, on va dire, de l'inner source, c'est que ça vous force à vous mettre d'accord sur des standards de qualité, des pratiques communes au sein de votre entreprise. Donc quand vous avez une équipe de développeurs qui ne dépasse pas 10-15 personnes, on arrive encore à le faire facilement. Ensuite, quand l'équipe augmente, vous avez plusieurs moyens. Je ne dis pas que l'inner source est le seul moyen, mais ça peut être une manière de se mettre d'accord et d'avoir des standards qui finalement sont écrits dans le code. des points d'attention quand vous lancez une politique d'innersource. Finalement, le premier point d'attention, c'est qu'il va falloir définir des standards communs. Et vous le savez, j'imagine aussi bien que moi, mais que souvent aligner une équipe technique, c'est aussi tout un art. Mais là, il faut définir, rappeler sans cesse l'objectif, ce qu'on veut atteindre. Rappelez qu'il y aura des processus de maintenance, parce que c'est le deuxième point d'attention de l'innersource. C'est qu'on a fait cette erreur-là. Nous, chez Padok, il y a deux ans, on a mis un gros effort.

14:44 Pendant plus de deux ou trois semaines, on a vraiment codé, codé, codé des briques. On était super contents. On est partis en vacances de Noël. Pendant un an, on ne s'est pas occupé de ces briques. Spoiler alert, on a tout jeté au bout d'un an parce que tout était obsolète, plus maintenu, il n'y avait plus nos bonnes pratiques. Donc là, c'est vraiment important d'avoir un process et une routine. Et enfin, il faut un honneur identifié. Parce que si vous avez des standards communs, vous avez une routine de maintenance, tous vos modules qui sont utiles, vous allez les maintenir. Par contre, il y a des modules qui vont passer sous le radar. Par exemple, un module load balancer qui finalement est utilisé par personne parce que pas pratique, etc. Lui, personne ne va y toucher. Donc vous aurez quelque chose finalement de la dette technique dans votre librairie. Et c'est important d'avoir un honneur identifié pour la librairie au global. 14h30, on revient de la pause d'âge. Alice, elle est en pleine forme. Elle déploie son code en staging. Et en fait, c'est super long. Elle perd toute son énergie parce qu'elle a quasiment 40 minutes de déploiement.

15:47 Ça, c'est un souci qu'on retrouve souvent. La chaîne de CICD, finalement, on la crée au début, quand on lance son infra, et puis après, on n'y pense plus. On n'en prend plus soin, on ne s'en occupe plus. Pourtant, elle va être un gros irritant quand vous arrivez à une équipe de plus de 15, 20, 25 développeurs. Là, je vais vous donner quelques tips. Ils sont très liés au cloud, ils sont très liés à Docker, ils sont très liés à GitLab, GitHub, mais ça peut vous permettre de trouver des sources d'inspiration si vous êtes sur des technos différentes. La première chose, c'est repenser le flux. Généralement, l'image, que ce soit l'image Docker ou l'image de votre VM, vous allez la reconstruire à chaque environnement de test. En fait, ça vous coûte du temps pour rien et puis ce n'est pas... 13 isoprod. Donc une bonne pratique, c'est de la construire une fois, de la mettre dans un environnement à part et de gérer les variables d'environnement ensuite par environnement. Vous pouvez également paralyser les jobs de test et de build. Généralement, on build et on test. Vous pouvez tester et builder. Effectivement, si les tests fail, vous allez builder pour rien, mais si les tests réussissent, vous allez gagner du temps.

16:52 Deuxième chose, toute technologie quasiment a des solutions de cache. Il faut utiliser ce cache et il faut utiliser ce cache à tous les étages. Vous pouvez par exemple utiliser le cache Docker, vous pouvez utiliser le cache GitLab CI, mais petit tips de geek qui m'a bien amusé, c'est que vous pouvez vous amuser à relire tous vos Docker files. Par exemple, ce n'est pas la même chose de faire une instruction de run pour installer des packages, puis une instruction de copie. En fait, vous feriez mieux de faire l'instruction de copie, puis l'instruction de run, parce que si les packages n'ont pas changé, alors l'image de copie va reprendre le dernier build. Et enfin, il y a un moment où il faut que vous acceptiez que votre chaîne de CICD, c'est une grosse partie de votre infra et qu'il va falloir par exemple augmenter la taille de vos runners, avoir plus de ressources, plus de CPU, plus de RAM pour qu'elle soit plus performante parce que finalement, elle est utilisée par plus de gens. Alors, quand on fait ça, il y a toujours un coût, que ce soit un coût financier ou un coût environnemental. C'est quelque chose que vous pouvez gérer en éteignant vos environnements la nuit avec du serverless, du cloud function, des Azure functions.

17:59 Voilà pour la suite. pour les optimisations de la chaîne de CI. Sur un projet, on a réussi, vraiment avec ces trois techniques, à passer le job de build de plus long de 1h11 à 26 minutes et à réduire quasiment d'un tiers le temps moyen de déploiement. 15h36, branle-bas de combat, un cidoir en production. Un incident, ça me toute facile. Finalement, un disque qui est plein, on refait quelques modifications de code Terraform, on applique, on enchaîne. Mais Bob se dit, ok, on va commencer le post-mortem parce que moi, il y a un truc qui mérite, c'est que ça, on a de l'alerte. On a de l'alerte dessus. Je disais, on est malvoyant sur notre infrastructure, mais quand même, ça, on est censé le voir. Pourquoi on ne l'a pas vu? Bob commence le post-mortem et il fait le pareto des alertes, toutes les alertes qu'il y a eu sur les quatre derniers jours. Déjà, ce qu'il constate, c'est qu'il n'y en a plus d'une centaine. Il commence à comprendre pourquoi l'alerte est passée à la trappe. Il se rend compte qu'il y en a notamment 62 ou 64 qui sont exactement la même alerte.

19:01 L'alerte, c'est« cube pod crash looping». Je ne vais pas vous expliquer ce que c'est, quoique si, je vais le faire, parce qu'on est quand même à une conf de CTO. C'est un pod qui redémarre. Ce n'est pas normal, c'est un comportement qui est géré par Kubernetes, mais ceci dit, on préférait que ça n'arrive pas. Bob, il se dit, OK, j'ai plein d'alertes. Je comprends pourquoi je ne les ai pas vues, mais en fait, je n'ai pas le temps de cliner ces alertes. Je n'ai pas le temps de faire en sorte qu'il y ait moins d'alertes qui arrivent sur mon... sur mon chain stack. Et là, qu'est-ce qu'il fait? Il planifie une journée Kaizen. Une journée Kaizen, c'est une journée où toute une équipe, donc là, ça va être l'équipe plateforme en l'occurrence, mais ça pourrait être l'équipe paiement, ne va pas produire. Alors, dit comme ça, ça fait un peu peur, mais en fait, c'est des journées qui sont géniales. On en a fait une, par exemple, le 30 septembre dernier, et c'était exactement l'objet de l'histoire que je vous raconte. L'objectif, c'était de réduire les alertes. Donc, toute une équipe de... SRE était dédié à ça.

20:02 Et la première chose, c'est de définir un potentiel d'amélioration. Un potentiel d'amélioration, c'est un écart entre notre situation réelle et où on veut arriver. Un truc qui est primordial, c'est de ne pas dire je veux zéro alerte ou pas plus de deux alertes par jour, parce que c'est certes motivant, mais en fait c'est décourageant au fil de la journée parce qu'on sait qu'on ne va pas y arriver, il y a trop d'alertes pour y arriver. Donc déjà c'est souvent un bon potentiel d'amélioration, c'est réduire de 30%, diviser par deux, diviser par trois. Donc c'est quelque chose qui est ambitieux, qui va faire la différence dans votre quotidien à partir du lendemain, mais c'est quelque chose qui est atteignable. Une fois qu'on a fait ça, et ça généralement on le prépare en amont de la journée, on arrive avec toutes les données comme l'a fait Bob au début du post-mortem, on analyse la méthode actuelle. Et la méthode actuelle, c'est le moment où on peut se perdre dans la tech, creuser et comprendre ce qui se passe. L'objectif, c'est vraiment de se dire, ok, cette alerte que j'ai 64 fois, déjà, en fait, elle correspond à quoi? Donc là, on peut reprendre vraiment l'énoncé de l'alerte, s'assurer qu'on la comprend.

21:03 Ensuite, faire un pareto et par exemple se dire, moi, le type de pod qui trigger le plus cette alerte, il s'appelle Calico. Je vais vraiment aller comprendre ce qu'il fait. Et ce que vous voyez, c'est qu'on est arrivé au bout d'une demi-journée à un diagramme comme ça, où on est vraiment allé de librairie en librairie, de log en code, en ligne de code, pour comprendre pourquoi le pod Calico démarrait en même temps que le pod CubeProxy. C'est une requête, mais il n'y avait pas de route IP tables. Je vais m'arrêter là parce que je pourrais vous en parler des heures, mais l'idée c'était vraiment de comprendre le fonctionnement interne de notre système. Déjà on est sûr, on y reviendra, mais qu'on va prendre une solution qui est adaptée. Et puis en plus, ça crée de la connaissance. Alors de la connaissance qu'on réutilise rarement, à part à une conférence comme ici, on a rarement l'occasion de discuter du démarrage du pod Calico. Mais en fait, le fait d'avoir creusé, de mieux comprendre notre système, ça nous permet de mieux l'utiliser ensuite. Une fois qu'on a tout compris dans notre scope, on passe à la troisième partie de la journée Kaizen, c'est générer des idées nouvelles.

22:10 Donc là, c'est de se dire, OK, qu'est-ce qu'on peut essayer? Il y a plein de choses qu'on peut essayer. Il y a plein de choses qui sont du quick and dirty, du fixe. Parfois, c'est ce qu'on fait. Là, en l'occurrence, c'est ce qu'on a fait. C'était de se dire, on a obligé notre pod à ne pas démarrer tant que le nœud, tant que l'IP tables n'était pas complètement seté sur le nœud. On sait que c'est du quick and dirty parce que le jour où tout crache, on ne pensera pas à faire la manip manuelle qu'on a fait pour faire ça. Ceci étant dit, la solution la plus propre, en fait, elle consiste à modifier la librairie Go qui va gérer les appels. Et donc ça, ça nécessite un process open source. On n'est pas maître du temps. Donc on a décidé de le faire. Là, dans notre backlog, on le suit, mais c'est du plus long terme. Donc la journée Kaizen, elle peut finalement continuer après la journée. Mais l'objectif, c'est quand même de trouver un moyen de réduire nos alertes de 30%. Une fois qu'on a fait ça, on a fait finalement le plus gros de la journée. Les étapes 4 et 5, c'est définir un plan d'implémentation, l'implémenter.

23:15 Et puis la partie 6, c'est s'assurer qu'on a atteint notre objectif ou tout du moins réduit nos alertes et la journée se finit là-dessus. Du coup, en conclusion, pour moi, la DevX, c'est quoi? En fait, la DevX, c'est un triptyque. Premier volet du triptyque, c'est de chercher les irritants. Et les irritants, il faut les chercher du côté des outils techniques. Pourquoi? Parce qu'en fait, c'est souvent des outils techniques qui vont introduire des points de friction dans votre process. Et c'est soit des points de friction que vous allez subir, une CI trop longue, vous n'avez pas le choix que de déployer avec cette CI, soit c'est des points de friction que vous allez contourner. Par exemple, trop de logs dans votre chain stack d'alerting, vous le contournez, c'est simple, vous ne le regardez plus. Mais finalement, il y a un moment où ça se retourne contre vous. Donc l'idée, c'est vraiment de reprendre le flux de production et se dire, OK, où est-ce que j'en ai marre? Rémi Luchiani, qui est quelqu'un qui travaille chez Théodo et qui est très fort pour animer ces fameuses journées Kaizen dont je vous parlais juste avant, vous excuserez mon langage, mais il dit, en fait, on cherche ce qui nous fait chier.

24:20 Et c'est vraiment ça. Petit tip, s'il y a vraiment trois endroits où vous allez trouver des irritants à relever, on en a parlé, c'est la chaîne de CI, les environnements de test, les environnements locaux. et toutes les tâches répétitives. Par exemple, si vous devez patcher vos serveurs tous les mois, quand il y a 10-15 serveurs, souvent, on a tendance à se dire, est-ce que j'automatise vraiment le truc? Non, finalement, ça se fait vite à la main. Ce n'est pas parce que ça se fait vite que finalement, ce n'est pas un irritant et que vous n'avez pas plus de plaisir à coder un script qui va le faire à votre place, qui s'avérera plus efficace et généralement de meilleure qualité. Deuxième volet du triptyque, il faut un espace dédié. Tout ça, ça demande du temps. Et du temps, vous pouvez... Vous pouvez en prendre à plusieurs niveaux. Certaines de nos équipes, elles ont ce qu'on va appeler un buffer d'amélioration. Donc c'est entre 5 et 10% du sprint, où c'est vraiment des petites tâches, mais qui vont me permettre d'écrire ce fameux script sur la MFAWS, qui vont me permettre d'écrire ce fameux script, par exemple, pour la répétition du patch, ou de commencer à investiguer sur pourquoi ma CI est très longue.

25:22 Donc c'est une petite routine, c'est comme se laver les mains, finalement, tous les jours. Ensuite, vous avez les journées Kaizen. Donc là, c'est se dire, OK, je prends une journée et je vais régler ce problème, encore une fois, technique. Et puis après, vous avez ce qu'on va appeler les breaks. Donc c'est deux, trois jours, un sprint, deux sprints, où vous allez par exemple créer le socle de toutes vos briques sur étagère, créer le socle de l'inner source chez vous. Et enfin, il faut clarifier l'ownership. Il faut des responsables. Le Yoko Ten, par exemple, il vous faut un responsable que le Yoko Ten arrive et lieu, parce que sinon ça peut péricliter. Et il faut que chaque personne se sente responsable de partager ses apprentissages. L'inner source, il faut des responsables de briques. Il faut un responsable de l'inner source au global. Et les journées Kaizen, c'est pareil. Il vous faut à la fois quelqu'un qui soit responsable d'une journée spécifique, qui la prépare. Mais je vous parlais de Rémi Nuciani, aussi quelqu'un qui soit responsable que ça arrive régulièrement. Parce qu'en fait, vous allez avoir des équipes qui vont les faire tous les mois, vous allez avoir des équipes qui vont le faire tous les trois mois, et vous allez avoir des équipes qui vont le faire très épisodiquement.

26:27 Pourquoi? Parce que le delivery prendra... toujours le pas sur la DevX, mais je pense que c'est votre rôle de CTO de remettre parfois le focus à cet endroit. Merci à tous. Si vous avez des questions, je serai ravie d'y répondre.