Qu'est-ce que le DevX ?

0:15 Bonjour à tous, Meetup Tech.Rocks sur l'expérience de développeur dans les entreprises. Un objectif du Meetup est justement d'en donner une définition. On va avoir un petit panel de points de vue sur la question. Aujourd'hui, on aura Mathilde Lemée qui est CTO chez Jolimoi. Je te laisse te présenter rapidement Mathilde. Merci Dimitri, moi je suis à l'origine développeuse depuis plus de 15 ans et chez Jolimoi je suis effectivement une CTO et je suis aussi une des confondresses de la boîte depuis 4 ans. D'accord, une belle croissance? Une très très belle croissance. Parfait. Bonjour Philippe, je te laisse te présenter aussi. Bonjour Dimitri, bonjour à tous. Moi, je suis très heureux d'être avec vous. Donc moi, je suis Philippe Ensarguet, je suis le Chief Technology Officer d'Orange Business Services.

1:16 Orange Business Services, c'est le bras armé pour le marché entreprise du groupe Orange. On est une société d'un peu plus de 30 000 personnes présentes sur 65 pays. Mon job en tant que CTO, globalement, ça consiste à nourrir et définir, animer la vision et la stratégie. technologique avec comme enjeu principal la transformation d'une telco compagnie vers une telco compagnie avec beaucoup de sujets en termes de convergence autour des piles technologiques. J'ai également le plaisir d'être board advisor pour certaines startups dans lesquelles Orange a investi et notamment Cycloid, un petit clin d'œil à Benjamin. Voilà, donc une belle taille d'un CTO pour une grande structure, donc intéressant. Benjamin, cofondateur de Cycloid aussi, je crois. Oui, bonjour, moi je m'appelle Benjamin, je suis le fondateur de la société Cycloid. On a développé ce qu'on appelle une plateforme DevOps et Cloud Hybrid. On travaille main dans la main avec Philippe sur plusieurs sujets. Et donc, je suis très content d'être là avec vous pour échanger sur ce sujet très important du sujet du DevEx.

2:22 Donc on va se faire un plaisir de pouvoir débattre sur ces sujets. Parfait. Je vais prendre Mathilde un peu en tête à tête pendant une dizaine de minutes et on se rejoint juste après Benjamin, Philippe. Merci beaucoup. A tout à l'heure. Mathilde, alors l'expérience de développeur, l'idée effectivement c'est de prendre un peu ton prisme, ton parcours personnel en tant que développeur pour essayer de faire une sorte de NPS, c'est quoi le NPS d'un développeur dans une entreprise? Et sans forcément te faire passer un entretien avec toute ta carrière, ce qui m'intéresse, Le reste, c'est deux aspects. C'est qu'est-ce qui te fait partir d'une entreprise en tant que développeur ou qu'est-ce qui te fait rester ou venir dans une entreprise en tant que développeuse? Je pense que ce qui te fait venir, c'est plusieurs choses qui sont importantes dans la développeur expérience. C'est déjà la mission, tu vois la mission que tu vas avoir, le poste, le secteur d'activité, le poste.

3:25 Et pour moi, il y a des choses qui sont importantes dans ça, c'est ta capacité en tant que développeur d'avoir de l'impact. C'est-à-dire, moi, j'ai fait des grands groupes, j'ai fait des startups, il y en a dans lesquelles j'ai participé, il y en a dans lesquelles j'ai confondé. Et en fait, ce qui est vraiment important pour moi, c'est la résistance. En tant que dev, tu soumets une idée. Est-ce que tu es écouté? Est-ce que tu as une réponse? Ou est-ce qu'au contraire, tu es dans une espèce de grosse machine où au final, tout est déjà fait, tout est déjà spécifié. Donc en fait, quand ça arrive à toi, développeur, tu n'as pas de possibilité d'avoir de l'impact, même si tu as des bonnes idées, tu es vraiment relégué finalement à un rôle plus d'exécutant que de participant. Ça, c'est un risque. C'est-à-dire que tu as vécu ça dans un groupe où tu n'as pas réussi à avoir d'impact au niveau d'un grand groupe, mais si ça avait lieu, ça te permet de rester. Exactement. Dans des grands groupes, c'était plus compliqué. J'ai fini par en avoir, mais c'est compliqué et c'est au niveau de l'énergie. On a une capacité d'énergie limitée. Ça demande beaucoup d'énergie pour faire changer les choses dans certains grands comptes.

4:29 Mais c'est vrai que quand j'ai eu la... possibilité de le faire, c'est hyper appréciant en fait parce que ça devient vraiment très important de se dire que tu as un impact, que tu peux avoir de l'impact sur tes utilisateurs, que tu as un vrai sens à ton travail. Et pour moi, c'est quelque chose de vraiment extrêmement important d'avoir un sens. Bien sûr que les technos, Les outils aussi ont leur importance et on pourra en discuter. Mais ça, tu vois, la possibilité de participer au projet et d'être vraiment inclus dans le projet, c'est quelque chose d'extrêmement important. important à mon sens. Après, il y a bien sûr des choses qui sont aussi importantes, c'est que tu choisis en général sur une stack qui t'intéresse parce que tu as envie de te challenger, tu as envie d'apprendre des nouveaux choses, tu ne veux pas forcément tout réapprendre, tu ne veux peut-être pas tout changer d'un coup. Donc ça, ça fait aussi partie des choses qui peuvent te faire quitter une entreprise quand tu as la sensation de t'ennuyer, de ne plus rien apprendre et qui va te faire rejoindre une autre pour une promesse au niveau des outils. Mais en fait, on garde souvent la stack technique, mais il y a d'autres choses qui sont importantes.

5:35 Je le vois très clairement parce que j'ai eu des niveaux de maturité différents dans les équipes dans lesquelles je travaillais. Il y en a où, par exemple, tu n'avais aucun test, tu n'avais pas de CICD, tu n'avais vraiment pas beaucoup d'outillage et au final, tu savais que si tu modifiais quelque chose dans le code, tu avais un risque d'avoir des problèmes, de crash et autres. Et en fait, tu n'es pas maître de ta plateforme. Et ça, ce n'est pas forcément des choses qui vont te faire venir. Par contre, ça, c'est des choses qui vont te faire partir. Parce que je pense qu'on a déjà des métiers où il faut être constamment à la recherche des nouvelles technos. Enfin, tu vois, il faut quand même beaucoup de documents pour faire un travail de recherche et autres qui est assez important. Mais en fait, le fait de ne pas pouvoir développer sereinement, de ne pas pouvoir faire ton job dans de bonnes conditions, avec des specs qui soient suffisamment détaillées, des boîtes où tout change tout le temps parce que tout est une urgence et qu'au final, toi, quand tu es développeur, tu as besoin de te poser, tu as besoin de réfléchir à ton marché. Tu as besoin d'avoir de la vision. Où est-ce qu'on en est aujourd'hui? Qu'est-ce qu'on va faire demain? Parce que ça a toujours un peu d'impact. Et ça, si tu ne les as pas, tu sais que tes archives vont être moins bonnes.

6:38 Donc, tu vas devoir les reprendre. Et surtout, il faut avoir vraiment du temps et pouvoir développer sereinement. Donc, ça va être les spécifications qui sont bien faites et re-challengées. Ça va être aussi tous les outils. Typiquement, les tests. Moi, je le refais. J'avais une début de carrière où je faisais, il y avait une partie de mon job, c'était très, très longtemps, il y a 15 ans, je faisais des migrations en XSLT, donc un truc qui n'est vraiment pas sexy. Et en fait, personne n'avait aucune maîtrise de ce que ça faisait. Donc en fait, c'était six. Et comme on n'avait aucun moyen de tester, on poussait en prod, on espérait très fort. Et s'il y avait besoin, on était sûr qu'il vive pendant 4-5 heures pour débuguer directement la prod. C'est des niveaux de stress que tu t'infliges. Et au final, sur le long terme, ce n'est pas viable. Et ça, c'est une raison pour laquelle, à mon sens, tu pars. C'est que tu as besoin de faire ton job dans de bonnes conditions. Là, en fait, on va aller directement à la question 2 en transition parce que quand tu n'as pas les conditions requises pour faire ton boulot en temps ou avoir une expérience de développeur agréable, tu as deux choix.

7:43 Tu as partir. Ou changer les choses et avoir un impact et créer, toi, des nouvelles conditions. Moi, je sais qu'en tant que développeur, en certains postes, je savais que c'était des mauvaises conditions, mais justement, la volée... d'avoir un impact et de mesurer la capacité à avoir un impact. Donc, à quel moment, toi, et je sais qu'il y a un exemple auquel on a en tête sur le projet open source que tu as créé, justement d'outillage, est-ce que c'était un déclencheur comme ça, de vouloir, cette expérience-là m'intéresse, de savoir comment tu as eu la... L'idée de faire ce projet que tu peux présenter rapidement, d'où c'est parti? C'était très longtemps aussi. Mon problème dans l'entreprise, dans la casité, c'est qu'on n'avait aucun test du tout. Les tests militaires, c'est quelque chose que j'avais mené. J'avais porté le projet, d'essayer de faire comprendre aux gens pourquoi c'était intéressant, comment on le faisait, d'essayer d'accompagner l'équipe.

8:46 Et il y avait une partie qui était les tests Selenium. Et moi, j'étais un peu en train de chercher d'autres langages. Je regardais C++ et je regardais Scala. Et je regardais d'autres outils, d'autres frameworks qui brillent. Et je suis tombée sur une pépite en Groovy qui s'appelait Jeb à l'époque. Et qui permettait en fait, déjà qu'il y avait une doc qui était fabuleuse. C'est important, une très bonne doc, très agréable à lire. Tu comprends bien, c'est vraiment bien expliqué. Et c'est un outil qui permettait, c'était juste du sucre syntaxique sur Selenium. Donc, il permettait de faire du test end-to-end, de simuler un navigateur. Et c'était hyper agréable à utiliser. C'était hyper simple. Il y avait une certaine complexité derrière, mais qui était finalement bien gérée. Et vous savez que toi, en tant que développeur, c'était vraiment hyper agréable. C'était écrit. de manière fluente. Donc, en fait, tu comprenais bien ton test. Il poussait les bons patterns, notamment le page object pattern sur ce type de test. Et tout était vraiment hyper agréable. Sauf que quand j'en ai eu le souci, on parlait en interne. Je me suis fait stopper directement. Où on m'a dit non, non, mais on ne peut pas, on vit, c'est hors de question, on ne peut pas changer de langage.

9:51 C'était vraiment un grand compte et ce n'était juste pas possible. Moi, j'ai dit OK, on ne peut pas changer de langage, j'entends. Simplement, Je vois ce qui se fait, c'est compliqué. Et maintenant que tu as goûté, tu vois, une fois que tu as goûté à quelque chose qui est vraiment fluide, vraiment agréable, c'est difficile de faire autre chose. Et je me suis dit, tiens, je vais commencer à faire un petit framework maison, pas quelque chose de grand, mais juste pour offrir cette syntaxe, ce sucre syntaxique qui permet vraiment d'écrire des tests de manière clean et de bien expliquer ce que c'est aussi les pages de l'ic pattern et autres. Et c'est de là que c'est venu, en fait. C'est parce que je voulais utiliser un outil qui était super bien. J'avais un outil qui était bien, mais compliqué à utiliser. Et avec mes équipes, c'était un peu compliqué à utiliser. Et je me suis dit, en fait, on va faire quelque chose entre les deux. On va faire en Java, parce qu'à l'époque, c'était le langage de la boîte dans laquelle je travaillais était en Java. Je me suis dit, OK, je vais prendre tout ce que je peux en gros ville. Bien sûr, il y aura des limitations du langage sur lesquelles je ne pourrais pas fixer, mais je peux faire quand même beaucoup.

10:52 Et c'est là où j'ai commencé Fluid Clenium. Et après, je me suis dit, en fait, c'est vraiment cool. Et je l'ai commencé sur mon temps pour voir si déjà c'était possible. C'est ça. Donc là, on est vraiment dans cette question d'impact. En fait, tu t'es donné une chance de rester. C'était quoi? Tu avais un peu conscience de cette partie-là en disant, s'il n'y a pas ça, je m'en vais? Ou c'était vraiment l'apprentissage? Quels étaient les moteurs derrière? Je pense qu'au moment où tu dis s'il n'y a pas ce framework là, je m'en vais. Je pense que c'est mieux de s'en aller parce que c'est plus en détail. Mais c'était plus dire quelque chose qui était... intéressant pour moi, tu vois, de tester un nouveau truc, un nouveau langage, de voir comment je pouvais le porter, vu que j'étais junior. Donc, tu vois, faire de l'open source quand tu es junior, j'ai eu quelques... Quelques comités plus expérimentés qui m'ont aussi aidé, tu vois, à reprendre des poules avec West et qui ont refait les choses mieux ou qui m'ont expliqué pourquoi est-ce qu'on fait faire différemment. Et ça, c'était extrêmement intéressant. Après, typiquement, sur cette mission-là, j'en suis partie. Parce qu'en fait, je trouve que l'énergie que tu mets à essayer de changer quelque chose de très gros, qui a déjà tous ces normes sur lesquelles, au final, en vue de ton poste, même si tu montes assez vite, tu es quand même finalement limité.

12:05 En plus, c'était une boîte dans laquelle il y avait énormément de politique. Je n'ai jamais retrouvé une boîte qui avait autant de politique que celle-là. Et la politique, c'est quelque chose avec lequel je n'étais pas habituée, avec lequel je ne suis pas hyper à l'aise. Et pour moi, c'est pour ça que j'ai fait cet outil-là. Mais en fait, peu de temps après, finalement, j'ai préféré partir parce qu'en fait, je me suis rendu compte que c'était épuisant, tu vois, de devoir... Tu vois, faire de l'évangélisation non plus, essayer vraiment de trouver des outils. Quand les managements comprennent, mais si tu veux, ça ne vient pas d'eux, ils ne sont pas forcément en soutien. C'est plus, si tu veux le faire, vas-y, fais-le, mais tu ne vas pas avoir de soutien. Tu ne vas pas avoir de recrutement de l'équipe, de gens qui vont pouvoir t'aider à le faire, qui ont une vraie force. Parce que même... Oui, voilà. Donc ça, au bout d'un moment, je me suis dit, en fait, mon énergie, elle est limitée. Si à chaque fois que je mets un truc en prod, c'est pour stresser pendant trois heures, en me disant, ça va dépendre, tu vas avoir quatre heures. Il y en a qui aiment ça. Il y en a qui aiment ça. Donc, si c'est un endroit où tu as de l'impact et de l'énergie.

13:07 Parfait, Mathilde. En fait, j'essaie de résumer un peu ta définition du DevX. Capacité d'avoir de l'impact tout en faisant attention à la gestion de l'énergie nécessaire pour en avoir. Ce que je comprends de ton message est en fait très intéressant parce que moi, je n'avais pas ce regard-là en tant que dev de dire est-ce que mes devs ont un impact? C'est le PONSOR player du... De Spotify qui pose la question aux équipes, est-ce que vous vous sentez comme des pions ou des acteurs? Donc ton point c'est, est-ce que les gens se sentent des acteurs de l'équipe, du produit, de l'entreprise? C'est ton point principal sur le DevX. Parfait, merci beaucoup. J'ai vu qu'il y avait quelques questions. Si tu veux répondre dans le chat ou un petit peu après, on prendra des questions en fin de session. Merci beaucoup Mathilde. On se retrouve peut-être tout à l'heure. Je vous invite Philippe et Benjamin. Bonjour, bonjour. De retour en Bretagne. Et Benjamin, je ne sais pas où tu es situé.

14:09 Je suis en Ile-de-France. Je suis à côté de Paris. Parfait, parfait. Bonjour à tous les deux. On a un petit challenge d'essayer de se mettre d'accord sur ce que c'est que le DevX. Voir est-ce une bonne définition, est-ce utile d'en parler? Ce qui va m'intéresser là, effectivement, dans cette première partie, c'est d'avoir cette définition, et notamment quelle est votre définition du DevX, on essaiera de faire une petite synthèse, et je vais donner la parole à Philippe pour commencer, et Benjamin, je te... Questionnerai juste après. Ok, très bien. Pour moi, le DevX, développeur expérience, en fait, Je dirais que ça vient de la convergence de deux sujets. l'ultra fragmentation des chaînes d'outils H et deux, une ultra complexification des infrastructures sur lesquelles on est amené à produire nos services.

15:16 Donc pour moi finalement, le DevX, ça consiste surtout à se soucier de l'expérience utilisateur, de l'intégralité des équipes qui sont impliquées dans un delivery. Dans un delivery software. Donc pour moi, oui, la développeur expérience, j'ai envie de dire que c'est ni plus ni moins que l'environnement dans lequel chaque membre d'un projet peut faire son meilleur travail, peut apporter sa meilleure valeur. Et j'ai trouvé que le témoignage de Mathilde était extrêmement enrichissant. Voilà ce que je peux répondre rapidement sur le sujet. Benjamin, un point de vue aligné, différent? Déjà, ça va être un sujet qui va être proche de toute la partie user experience. Il y a pas mal de gens qui commencent à parler de DevEx versus UX. Au final, ça sert le même purpose qui va être de vraiment aider les développeurs à être...

16:17 Dans une expérience qui leur permette d'être le plus efficace possible, d'être dans de meilleures conditions de travail et de faire en sorte que derrière, ils puissent collaborer de la manière la plus simple. avec un ensemble d'acteurs. Et ça, c'est aussi un enjeu très important, c'est qu'on n'est jamais seul développeur, on est toujours dans un écosystème d'outils, de personnes, de process, d'infrastructures, de tout ce qu'on veut. Donc avoir une expérience développeur la plus efficace et de bout en bout, lui permettre de faire son travail de la manière la plus efficace possible. J'ai envie d'être un petit peu plus provocateur là-dessus. La question, c'est pourquoi maintenant? Pourquoi on s'en occupe maintenant? Et la question qui est sous-jacente, c'est est-ce que ce n'est pas là parce qu'il y a la guerre pour le recrutement des développeurs? Et que du coup, c'est plus pour les garder que pour les faire venir, qu'on met tout ça en place avec un prisme énormément d'outillage.

17:20 Est-ce que là-dessus, vous êtes aligné que le DevX, on en parle parce qu'on a besoin de garder ses développeurs? Tu peux donner mon avis si tu veux, Dimitri. Je pense que c'est une des options, mais ce n'est absolument pas la seule. Moi, quand je regarde un petit peu notre écosystème de clients aujourd'hui, ils sont confrontés à une concurrence qui est planétaire, des modèles opérationnels, des modèles de business, des services toujours plus près les uns des autres. Il y a un besoin de différenciation et un besoin de se réinventer. Donc aujourd'hui, ce qu'on me demande, les entreprises, en tout cas les entreprises avec lesquelles j'ai l'habitude d'échanger, ils ont besoin d'innover, ils ont besoin de gagner en agilité métier, ils ont besoin de s'adapter surtout au rythme cardiaque qui a explosé au niveau de notre économie. Et là-dessus, je pense qu'il y a deux termes qu'il ne faut pas avoir peur d'utiliser, c'est la notion d'efficacité et la notion de productivité.

18:24 Aujourd'hui, on est rentré dans une phase d'accélération et de compression du temps qui est absolument énorme. Et cette question d'efficacité auprès des équipes de développement, de production, je pense, n'a jamais été plus critique qu'aujourd'hui. Et quelque chose qui pour moi est vraiment très important, c'est bien de comprendre tout le panel qui a été notamment abordé par Benjamin. Quand on parle de développeur expérience, c'est la doc, c'est tes frameworks, c'est ton guide jusqu'à tes outils d'observabilité. Finalement, il ne faut pas oublier la culture, les pratiques. Et finalement, quand on regarde l'intégralité de tout cet écosystème dans une entreprise, quelle que soit sa taille et sa complexité, la somme des frictions que l'on peut avoir et qui peuvent être des facteurs de ralentissement, des facteurs de non-progrès, de non-convergence, de non-optimisation, sont relativement importants. Moi, j'ai plutôt envie de parler d'efficacité, de productivité, la rétention, tu as raison.

19:27 Alors, ok, donc rétention, oui. Alors moi je dirais non. Oui, oui, non mais c'est ça qui est... Mon avis c'est que ce n'est pas le cas. Il y a plein d'études sociologiques de pourquoi les gens partent d'une entreprise. Bien avant le sujet du DEVEX, c'est parmi les premières raisons, alors ça dépend... De quitter, mais c'est grosso modo ta relation managériale, l'atmosphère dans laquelle tu travailles, ta rémunération et la considération de ton bien-être. et notamment aujourd'hui les enjeux de remote pour pas mal de devs, d'ops ou peu importe, qui prennent ça en considération. Le dev-ex, ça peut être un accélérateur de pourquoi tu quittes une entreprise, mais je ne pense pas que c'est ce qui fait que ni tu viens ni tu pars d'ailleurs. Venir regarder, amélioration de l'efficacité. Moi, ce qui m'intéresse là, Benjamin, c'est que tu as une expérience, alors pardon, je suis du toit, mais sur le cycloïde. Il y a une double problématique pour vous, c'est que vous avez des développeurs, donc vous avez une problématique interne sur l'expérience développeur de Cycloid, mais votre plateforme participe aussi

20:41 à l'expérience de développeur chez vos clients. Ce qui m'intéresserait, c'est peut-être d'avoir un exemple autour de ce sujet-là. Oui, tout à fait. Alors, je vais juste un peu contextualiser avant de partir directement sur un cas client qui s'est discount avec lequel on bosse. En fait, moi, je viens d'un monde d'un système intégrateur, manage service provider, multi-cloud, où en fait, en tant que DevOps, on a porté du service pour des devs, des ops, des solutions architectes, enfin des end users. Et dans ce monde-là, on est dans un monde de frustration complète. Pourquoi? Parce qu'il y a une insatisfaction côté client où on peut faire ce qu'on veut, on ne va jamais suffisamment rapidement, et une insatisfaction en interne de cette frénésie technologique, de cette frénésie d'outils. et des difficultés qu'on peut avoir dans la relation avec les devs pour leur apporter de la satisfaction. On a fait un passage C-Redat et au final, on a monté cette plateforme DevOps et Cloud Hybrid. Qui est un enjeu global sur ces sujets d'Avex.

21:46 Pourquoi? Parce que si on veut faire en sorte qu'on apporte la meilleure expérience développeur pour apporter une meilleure efficacité, une meilleure productivité, moi, on va vraiment faire en sorte que quand ils s'adressent à des sujets d'infrastructure et de cloud, Ça fasse partie aussi de son expérience et cette capacité à pouvoir interagir avec un ensemble d'outils et de types d'hébergement sans avoir à se poser la question quelles sont les bonnes pratiques que je vais mettre en place, que je dois respecter, quels sont les outils que je dois utiliser. Pour rappel, rien que sur les sujets d'infrastructure, il y a 28 outils en parallèle en moyenne. Donc comment s'y retrouver même en tant que DevOps, on a du mal. Et donc, n'étant pas un tech founder, mais plutôt venant du business, je n'ai jamais compris cette frénésie technologique et cette capacité à vouloir refaire la roue 25 millions de fois. Moi, je suis pro open source. Je pense que s'il y a quelque chose qui fonctionne bien, autant le réutiliser. Et donc, de ne pas éviter de refaire la roue.

22:48 Et donc, en fait, le cas de ces discounts, il est vraiment typique dans cette volonté de faire en sorte qu'il y ait une amélioration de l'expérience développeur dans son intégralité. C'est que quand... S'il s'agit des sujets d'infrastructure et de cloud et de DevOps plus globalement, qui est une partie du sujet DevEx, Tout le monde vit la même chose. On a des devs d'un côté, des ops de l'autre, il y a une inefficacité, des silos. On se dit on va construire une équipe DevOps pour fluidifier un peu les échanges et puis au final on crée une troisième équipe. Et donc on ne règle pas forcément ce problème de fluidité de silos et donc on se dit ok, comment je peux faire pour rapporter à mes développeurs tout ce qu'ils ont besoin d'un point de vue process, outils, culture et autres sur ces sujets d'infrastructure. Et donc là, se pose la question d'une interface, d'un portail, d'un plateforme ingénierie, peu importe comment on l'appelle, pour pouvoir interagir. Et c'est vraiment ça la démarche qu'ils ont eue chez Cédiscount et de pourquoi nous aussi on a développé ça, c'est qu'aujourd'hui,

23:54 On ne peut pas répondre à des problématiques techniques d'un point de vue DevOps en disant« Non, mais tu as tout sur ton guide, tu as tout en API, débrouille-toi, il n'y a pas de problème, tu vas y arriver. Donc c'est vraiment démêler le sac de nœuds de toutes les actions, de tous les outils. Je crois qu'on a, dans la préparation, parlé de charge mentale un petit peu du développeur avec tous ces outils. Donc là, ce que je comprends, c'est démêler cette problématique-là. Il y a Olivier Mertens qui pose la question de« a-t-on gagné en maturité sur les besoins et les attentes? de développeurs parce que ce que j'entends benjamin là c'est votre outil il est là parce qu'on a compris que c'est pas le baby foot qu'il fallait amener mais une plateforme qui répond au stress du quotidien est ce que ça vous voyez vous deux peut-être benjamin puis philippe sur la L'évolution de la compréhension des attentes des développeurs. Je vais dire quelques mots et je te laisse la parole, Philippe.

24:56 Aujourd'hui, on a eu très souvent, et dans plein... des chances qu'on a avec des clients, se dire, OK, niveau développeur, on va définir le pourquoi, mais le comment, grosso modo, soit c'est déjà en place, soit tu te débrouilles. Je pense que ce n'est pas ce qui est la meilleure façon d'avoir une approche de développeur expérience la plus efficace et en tout cas la plus... La plus productive parce que rien que sur les DevOps, il y avait un outil de l'intégralité des sujets, de culture, de process, d'amélioration de l'expérience. Philippe, à ton échelle, je pense que tu vas pouvoir en parler bien mieux que moi. Oui, le point qui est fondamental aussi, c'est peut-être de se poser trois secondes et de se demander, mais qui développe? Moi, chez moi, les data centers sont du software, le réseau est du software, le storage c'est du software, les plateformes d'infrastructures sont du software, et puis évidemment tous les services qui sont on top sont du software.

26:05 J'ai un double enjeu, j'ai un double challenge. Répondre à un enjeu d'accélération et répondre en même temps à un enjeu de convergence. Et finalement, il y a maintenant de ça, j'ai envie de dire, 5-6 ans, on a vraiment pris conscience qu'on avait un pivot au niveau de l'entreprise à faire dans une culture software. Évidemment, les activités très liées au... digital très lié à l'IT, j'ai envie de dire, avait commencé à mettre sur les rails un certain nombre de sujets. Mais quand on arrive sur des services et des fonctions network ou sur des fonctions core telco, honnêtement, on vient d'un monde ultra agrégé, ultra backbox, qui est en train de se désagréger au travers de l'impulsion d'un monde de plus en plus software API et automatisé. Et finalement, à un moment donné, moi, j'ai eu besoin de trouver un prétexte pour regarder comment faire pivoter la boîte d'un point de vue culture et d'un point de vue software. Et à ce moment-là, tout simplement, on s'est rendu compte que le principal sujet qu'on avait à gérer, c'est

27:14 comment peut-on augmenter, on va dire, ou en tout cas diminuer, l'écart type moyen entre des surperformers et des équipes de développement qui sont peut-être un petit peu moins expérimentées, parce que c'est aussi ça la vraie vie dans une entreprise. Tout le monde n'est pas Kelsey Hightower, tout le monde n'est pas Charity Major. Je suis désolé, je n'ai pas de nom sur des acteurs français, mais c'est la réalité, c'est la vraie vie. Et comment on fait en tenant compte de ce rythme et de cette pression pour s'assurer que, on va dire, le niveau médian de ce qu'on attend en termes de qualité, en termes de productivité, en termes de rythme, de délivrerie, est possible d'être renseigné. Et finalement... Pardon, Dimitri, reste. Vas-y, vas-y, vas-y. Non, non, non, ça me fait bondir parce que c'est ultra intéressant de se dire que si on regarde à quel point les gens peuvent avoir des impacts, comme Mathilde disait au tout début,

28:16 si c'est des juniors ou des seniors, Ce n'est vraiment pas les mêmes outils, ce n'est pas les mêmes barrières, il ne faut pas mettre des béquilles au senior, il ne faut pas demander d'aller à fond au junior sans les mains, comme tu disais Benjamin, de dire tu as tous les outils, tu as toutes les API, débrouille-toi. À un senior, tu peux lui dire ça. Et il va avoir un impact. Par contre, ce sera plus dur à reprendre derrière. Mais du coup, on est vraiment là-dessus. Donc, si je comprends bien, Philippe, c'est… Il y a de plus en plus de développeurs partout. Beaucoup qui commencent à développer finalement dans l'infra et compagnie, il faut reprendre les bases au départ, donc accompagner toutes ces personnes qui font du software, donc de nouveaux types de développeurs à accompagner, sans pour autant abandonner la performance et l'impact des seniors. Ma question, moi, c'est... Sur quel sujet, par rapport à comment on a progressé, sur quel sujet vous avez changé d'avis récemment sur l'expérience développeur?

29:18 Parce que si on en parle maintenant, c'est que c'est en train d'évoluer, c'est que c'est en mouvement et qu'on n'est pas que sur du classique. C'est quels sont les sujets là qui vous titillent ou vous n'êtes pas certain? De vos convictions, où vous avez justement changé d'avis sur une conviction, sur l'expérience développeur. Philippe. Alors, En termes de conviction par rapport à ce que tu évoques, il y a un sujet qu'on n'a pas encore abordé et qui pour moi a été clé dans la transformation que j'ai vécue et qu'on a mis en place avec les équipes. c'est qu'à partir du moment où on a... compris que le matériel software, la matière software était un asset d'entreprise, si on ne mettait pas en place une politique et une stratégie de data qui est liée à ces pratiques software, on n'allait pas y arriver. Ce que je veux dire par là, c'est que très rapidement, dans notre histoire, on s'est mis bien sûr à utiliser de la data pour pouvoir monitorer et montrer et prouver la qualité de nos services, mais quand globalement on a plusieurs

30:28 milliers de développeurs qui produisent chaque année des centaines et des centaines et des centaines de projets, en fait on a juste à disposition une masse absolument monstrueuse de données pour pouvoir justement aller au-delà de l'outillage, rentrer dans l'accompagnement et dans la création d'une pratique à dresser les cultures, parce qu'on va être capable d'avoir toutes les signatures et pour moi encore plus important, les signaux faibles. À partir du moment où on est dans une expérience développeur, je n'ai plus que mon guide, je n'ai plus que ma CIA et je n'ai plus que mon repo livraison. J'ai une expérience dans laquelle l'infrastructure sous-jacente fait sauter le verrou des silos qui sont propres aux bornes de chacun des outils. Et donc de regarder une production dans l'entièreté de son cycle de vie. Et à partir de ce moment-là, ce qui est très intéressant, c'est de regarder les signatures des signaux faibles qu'on est capable de capter et de se rendre compte que des équipes sont en difficulté.

31:29 Et c'est là... Moi, j'ai trouvé que ce travail dans lequel on a poussé cette développeur expérience a été extrêmement précieuse parce qu'on s'est mis dans une posture où l'idée a été de pouvoir apporter de l'aide. On était capable de caractériser que les équipes étaient en défaut ou en difficulté. Et concrètement, ça a été aussi extrêmement intéressant pour amener du training, du mentoring et aider ces équipes à finalement monter en compétence. Je suis toujours sur mon histoire de moyenner mon écart-type en fait. Est-ce que tu as un exemple, soit de mesures, soit de signaux faibles détectés? On regarde la théorie et en pratique, ça donne quoi? Sur les pratiques, en fait, globalement, nous, ce qu'on fait, c'est qu'on est… Chaque fois qu'on démarre un projet au travers de la software factory qu'on a mis en place, on a une enveloppe, donc on connaît globalement quand est-ce que démarre et quand est-ce que termine le projet. Quand tu regardes un taux de commit, quand tu regardes un taux de test, quand tu regardes un taux de… comment dire…

32:33 de packaging ou de build qui sont successful, globalement, tu peux considérer différents outils qui vont t'impacter sur cette opération. Et concrètement, le fait de caractériser ces indicateurs et ces métriques qui s'appuient sur différents contributions d'outils permettait de pouvoir vraiment identifier ces éléments-là. Et surtout, ce qui a été très intéressant, c'est qu'on a eu une véritable expérience sur cette dimension de data de la DevX. En fait, on s'est vraiment mis à développer des outils d'analyse qui ont complètement évolué au fur et à mesure qu'on a construit notre plateforme, parce que nous aussi, on maturait sur la compréhension de l'expérience. Et il y a aussi un dernier point qui me tient beaucoup à cœur à partager. Tu parlais des développeurs seniors et des profils plus experts. Pour moi, ces profils-là ont été des profils qui ont été absolument clés.

33:38 À la taille de l'entreprise pour laquelle je travaille, si je ne suis pas capable de mailler, de mécher l'entreprise avec des têtes de pont, des référents, des personnes qui vont être pertinents pour pouvoir faire l'écho de ce qui se passe sur le terrain, juste ça ne marche pas. Je n'ai pas une grande robe noire, je n'ai pas une grande toche, je ne suis pas là pour appliquer des choses qui descendent. Plus de 50% de ce qu'on a construit s'appuie et vient du terrain. Cette boucle de rétroaction, elle est critique et elle a été possible parce qu'on a su mailler opérationnellement l'entreprise avec ses experts et ses profils très seniors. Merci. Benjamin, qu'est-ce qu'il y a dans la plateforme, sur ces données, qui parlent ou comment vous communiquez là-dessus aux utilisateurs de votre plateforme? C'est quelque chose que vous avez pris en compte? Oui, juste avant de passer là-dessus, je pense que ça va parler aussi à pas mal de gens. Nous, enfin moi en tout cas sur ce sujet de qu'est-ce qui nous a fait changer et qu'est-ce qui nous a fait prendre en considération vraiment ce sujet d'Evex, c'est qu'au début,

34:48 Je croyais qu'en travaillant que sur le Y et en ayant une forme d'organisation de boîte où on travaille beaucoup sur la responsabilisation des collaborateurs et en plus associé avec du fuller. partout en Europe, je me suis dit grosso modo que ça allait fonctionner. Mais en fait, plus on a intégré de développeurs, ou grosso modo on double chaque année nos équipes, plus en fait on s'est rendu compte qu'avoir une expérience développeur, c'est quand même super important parce que c'est ce qui permet d'aller beaucoup plus vite. Dans cette capacité de pouvoir délivrer et d'éviter toute cette nuisance sur des questions qui ne seraient pas forcément, je dirais, les plus pertinentes. Et je pense que c'est là aussi où c'est un élément très important à prendre en considération, c'est que quand on grossit rapidement, il faut faire en sorte qu'il n'y ait pas uniquement des coutumes, mais une approche qui permet à n'importe qui de pouvoir

35:49 onboarder sur un projet, sur le développement d'une fonctionnalité, sur un écosystème, surtout quand on a une code base violente. Nous, on est en Go sur la partie backend et en Vue.js sur la partie frontend. Autant te dire que si tu ouvres le capot, On a instauré des règles, on passe un temps de développement pour un temps de test. Il y a nécessairement... On va y venir juste après. Je voulais juste revenir sur la question parce qu'on parlera après la mise en place d'une démarche d'Evox, d'Evox, c'est-à-dire d'où on part, comment on part du terrain, comment on prend cette partie-là. Mais ça m'intéressait quand même, dans votre plateforme, comment vous aidez vos... aux clients sur ces questions de données ? Vous avez un axe là-dessus? Vous avez travaillé sur ce sujet-là pour les aider eux-mêmes? Nous, tout part de la définition de pattern que tu vas retrouver sur ton guide, où on est parti du constat que les 99% des développeurs ne sont pas des experts DevOps, ne vont pas devenir des DevOps parce que ce n'est pas une histoire de...

36:53 De trois formations sur un cloud provider, mais plutôt trois ans avec un véritable intérêt sur les sujets d'infrastructure et de cloud. Et donc, on s'est dit, partant de ce... Dans cette vague de DevOps, de DevEx, à partir du moment où tu te poses des questions sur le sujet d'infra et de cloud, comment tu peux faire pour faire en sorte que ce soit quelque chose qui soit complètement fluide? Donc, on a développé des fonctionnalités pour faire en sorte que ça s'intègre nativement dans leur écosystème, dans l'approche GitHub, pour leur faciliter le travail sur les sujets d'outils et de cloud. Donc, ça se délivre sur plein de fonctionnalités qu'on a développées, mais c'est vraiment comment apporter une seule expérience et qu'il n'y ait pas une rupture nette. Ah, c'est un sujet d'infrastructure, attends, il faut que j'aille appeler mon pote DevOps qui va me faire le café. La réalité, c'est que recruter des DevOps, c'est aussi difficile que de recruter des DevSenior sur Go ou sur Vue.js. C'est la pénurie. Parfait. Donc, je propose qu'on passe 3-4 minutes assez rapidement. En fait, c'est juste pour pouvoir prendre plus de questions après que couvrir juste les questions qu'on avait prévues.

37:57 Je vais couper un peu. Donc, je vais résumer vraiment là sur... Deux interventions sur comment initier une démarche DevX et le premier pas à faire selon vous pour des personnes, sachant que mon point de vue, je ne vois pas pourquoi c'est nouveau. Donc, mettre en initiative une démarche DevX, c'est quoi et à quoi il faut faire attention et par où commencer? Philippe? Alors, moi, si je m'appuie sur l'expérience que l'on a pu avoir, moi, je pense qu'il faut vraiment y aller de manière extrêmement progressive, j'ai envie de dire, c'est très traditionnel, mais pas très original, mais se mettre vraiment dans la peau de vouloir réduire les frictions et réduire les problèmes des équipes. Je vais te donner un exemple très, très concret. Le premier truc que nous, on a voulu casser, et la construction et le setup de l'environnement de développement et des infrastructures.

38:59 Um, Benjamin l'a dit tout à l'heure, on a plusieurs dizaines d'outils qui peuvent être utilisés dans un process de développement. Ok, quand on est dans une vraie entreprise, j'ai envie de dire dans la vraie vie, quand tu es tech lead ou quand tu es en charge d'un projet, globalement, tu vas envoyer, il va falloir que tu crées ces enveloppes pour tes différents outils. Il va falloir que tu positionnes des droits pour tes différents teammates, pour les membres de ton équipe. Nous, on s'est rendu compte, And you're the one. Le compte d'un truc, c'est que ça pouvait représenter à l'échelle d'une équipe l'échange de plusieurs centaines de mails avant que les outils soient set-upés, que les droits soient positionnés, avec une véritable loterie sur qui, côté opération support, va venir activer les droits, va venir activer les profils, et cette hétérogénité-là. Et on s'est rendu compte que la phase de bootstrapping, d'amorce pour produire cette infrastructure.

40:00 Pouvait prendre en moyenne de 3 à 5 jours. 3 à 5 jours multipliés par le nombre de développeurs, multipliés par le nombre de projets, je vous laisse imaginer le montant financier que ça peut représenter. Ce n'était pas acceptable. Et en fait, le coup de poker qu'on a joué à l'époque, ça a été de dire, qualifions potentiellement ce manque à gagner en termes d'efficacité, passez-le nous en investissement et on va craquer votre truc. Et c'est ce qu'on a fait. Ce qu'on a fait, c'est vraiment d'avoir cette approche de self-care portail. J'interviens, je crée mon projet, je crée une enveloppe, je déclare mes utilisateurs, je leur donne un comportement, je vais dans un store, je choisis mes outils, suivant, suivant, terminé, l'intégralité de l'environnement STP, monter le support, le contexte projet est lié. Quand il y a un défaut, quand on clique pour faire une demande de support, tout le contexte lié au projet, aux outils qui sont liés, aux droits, aux règles, aux adresses IP, aux ports, tout ce qu'on peut imaginer, sont contextualisés. Donc voilà, on a voulu craquer ça. Le deuxième truc qu'on a voulu craquer, c'est le sujet du support et de la réactivité du support.

41:05 Avec le niveau d'automatisation qu'on avait réussi à avoir sur nos chaînes d'outils, on s'est rendu compte que globalement, on a progressivement arrêté le support niveau 0, arrêté le support niveau 1, au niveau d'automatisation et d'être contextualisé qu'on a apporté. À partir de ce moment-là, ce qu'on a voulu ajouter ensuite, ça a été le lien à la capitalisation et l'identification des pratiques. la gestion et la mise en place d'environnements de collaboration et de partage. Voilà des exemples concrets de ce qu'on a voulu chercher à craquer et qui ont été de véritables game changers au niveau de notre entreprise. Et pour moi, la principale matérialisation, vous le savez tous, quand on est dans un processus de transformation, les exécutifs généralement sont très souvent sponsors. Quand on est dans un processus de transformation, les très opérationnels sont souvent très sponsors parce que c'est eux qui le vivent. Souvent, là où on a besoin de passer du temps, c'est sur le middle, qu'il soit du middle management, du middle de tout ce qu'on veut.

42:08 Et pour moi, ce qui a été un véritable gain et un facteur d'observation de succès, c'est que finalement, toute cette population middle, on a réussi à la convertir et à la faire pivoter parce qu'ils se sont rendus compte le volant d'efficacité que l'on pouvait apporter et d'autonomie qu'on pouvait apporter aux équipes. Et quand on travaille dans une entreprise aussi grande, finalement, le fait de savoir mixer et construire des équipes pour pouvoir délivrer en fonction de la localisation des projets, nous laisse penser que si on n'a pas globalement à l'échelle de l'entreprise une expérience qui est convergente dans l'utilisation et la consommation des outils, c'est un facteur qui très rapidement pose des problèmes de productivité et d'efficacité dans l'amorce des projets. Voilà ce que je peux te partager, Dimitri. Parfait, parfait, parfait. Benjamin, sur cette question-là de par où commencer, comment on fait? Alors de notre côté, en fait, quand on s'est rendu compte qu'on mettait beaucoup plus de temps à onboarder les gens, c'est là où on a commencé à se dire, OK, il y a...

43:18 On manque d'efficacité, on manque de reproductibilité, d'onboarding. Comment on peut faire pour les accélérer plus rapidement? On est full remote, donc en fait, on a pris un workshop. On s'est dit, on est parti 5 jours tous ensemble. En fait, c'est ce qu'on fait tous les quarters. Et on a vraiment streamliné tous les process qu'on avait d'un point de vue dev. Deux, j'arrive sur mes outils, j'arrive sur mes environnements et autres. Il y a eu deux sujets qui sont ressortis significativement. Le premier sujet, c'est la capacité de reproduire notre backend de manière externalisée. Donc en fait, on est arrivé à un stade où quand on lance notre backend sur nos machines, et on n'a pas des machines pour faire le jeu, ça couche la machine. Donc on s'est dit, OK, maintenant, il faut qu'on vraiment déporte ces environnements de backend. Et le deuxième sujet, c'était, on a énormément de documentation. Partout et donc comment on peut faire pour faire en sorte d'avoir une meilleure expérience et donc en fait ce qu'on a

44:22 donc ça c'était vraiment un problème orienté d'Evex et donc on s'est dit ok ces environnements de back-end il faut les externaliser. Donc, on a pris un cloud et en fait, on a défini des templates qu'on a mis en self-service dans notre portail, dans notre plateforme. Qui peuvent adresser de manière très simple, sur lequel ils peuvent provisionner les outils et le portail, comment dire, et le backend associé. Et en quelques approches, ils peuvent consommer deux éléments, soit un backend externalisé, soit ce qu'on appelle aussi des feature env, c'est-à-dire que quand tu développes plusieurs fonctionnalités en parallèle, tu veux commencer à pouvoir les tester, tu veux commencer à pouvoir avoir vraiment une approche aussi en termes d'A-B testing. Et donc, on a aussi cette capacité de pouvoir... Lancer des nouvelles features de manière simple et sans avoir à impacter et à perdre du temps.

45:23 On était arrivé à 20 minutes de construire un backend. Donc, en fait, on s'est dit de builder. On a construit ce workshop et on a travaillé sur ce que... Je vais être méchant, Philippe. Je ne veux pas te laisser parler. On reviendra juste après. On va clore un peu la session pour pouvoir prendre des questions, justement pour pouvoir aller un petit peu sur d'autres axes parce qu'il y a tellement de sujets qui se mélangent mais en fait sur cette partie là dont on a parlé il y a le truc qui m'a marqué le plus c'est cette vraie différence entre junior senior de laisser tout le monde contribuer tant sur l'outillage donc là sur l'onboarding j'ai l'impression que c'est beaucoup orienté sur Quel que soit notre niveau, dès qu'on démarre, on est junior sur le système. Du coup, il faut qu'on puisse aller vite, qu'on puisse onboard. Mais ça, c'est intéressant dans ce domaine-là. Alors, je voulais vous remercier énormément pour cette session, pour ce petit débat qu'on a eu entre nous, et prendre cette 8 minutes avec...

46:32 Les participants, on essayait de faire venir David sur scène. Alors, David, tu as juste à lever la main. Je crois qu'il y a une fonctionnalité quelque part pour pouvoir demander à venir sur scène. Et comme ça, on pourra te faire monter. Et je vais poser une question entre-temps sur... Alors, l'incrémental, on a fait... Ah bah donc, c'est bon. David, tu peux juste activer ta caméra pour monter sur scène. On va te faire poser la question sur la partie remontée terrain. Il faut que David, juste activer ta caméra, ça te fera venir sur scène. C'est l'ergonomie de Remo qui est presque bien. Et le micro. Mais bon, pour répondre, avez-vous des conseils, des pratiques à partager pour collecter des retours? Moi, en étant full remote, je n'ai jamais trouvé de meilleure pratique que de faire des workshops.

47:36 Ça permet déjà de passer du temps ensemble et de mettre autour de la table des pratiques et des manières de faire et des points d'amélioration. Ça peut être plusieurs jours, ça peut être... Moi, en tout cas, c'est mon avis personnel. Je peux également répondre. Moi, je pense qu'il y a un truc qu'il ne faut pas oublier, c'est qu'à partir du moment où on va vers du DevX, on se rapproche très fortement des patterns de plateforme engineering. N'oublions pas, les amis, du coup, c'est un produit. Notre produit doit vivre. Il doit avoir des... Comment dire? Il a besoin de product owners. Et en gros, tous les outils que moi, j'ai pu intégrer dans ma plateforme DevX jusque-là, eh bien, avaient un product owner, des product owners très, très techniques sur des produits très techniques. Mais chacun faisait vivre son périmètre. Et donc, avec une animation, c'est là, avec cette notion de core team, cette notion d'extended team pour pouvoir mailler le terrain, se nourrir des retours, et puis derrière, gérer la roadmap, si j'ai envie de dire, en termes de...

48:46 de mise en œuvre et d'évolution des services qu'on peut être amené à faire. Ce que nous construisons, c'est un produit. Et il faut accepter de le manager en tant que tel. Si on n'est pas prêt à le considérer comme un produit, il ne faut surtout pas le construire et il faut le consommer. Moi, c'est mon conseil. Très bien, en effet, ça me rappelle Patrick Chanzon qui fait un talk au Summit sur le fait que le CTO est là pour construire une plateforme et c'est peut-être un peu aussi lui-même le CTO, ce product owner de la plateforme. Dimitri, si tu me permets, et si je peux partager un retour, c'est toi le maître, moi je sais ce que tu me dis, mais juste très rapidement un retour d'expérience. Finalement, vous savez, on lit tous dans la littérature que... Ce qui est important pour transformer une entreprise, c'est la culture. On lit ça partout. Quand vous êtes dans une entreprise à plusieurs milliers de salariés, posez-leur à chacun la question, c'est quoi la culture? Et vous allez comprendre la difficulté dans laquelle vous êtes pour pouvoir engager un pivot.

49:50 Moi, j'ai pris un contre-pied total par rapport à ça. Je me suis appuyé sur des choses très pragmatiques, très opérationnelles. Et je suis parti d'outils qui, à un moment donné, ont pensé abstraits pour pouvoir aller travailler. ce qui avait la vraie valeur pour transformer les pratiques, le mindset et la culture est venu après. Moi, c'est vraiment mon histoire et c'est vraiment le parcours par lequel je suis passé. Et en fait, on n'a pas réussi à faire venir David et on est désolé, c'est la plateforme. Parce que du coup, il appuie justement là où pour moi ça fait mal, c'est... Comment vous vous nourrissez des problématiques? Est-ce que le terrain a la parole? Just in time. Vas-y, David, tu parleras bien mieux que moi. Oui, désolé pour les problèmes logistiques. C'est moi qui impose de faire venir des personnes sur scène, parce que ça complexifie un peu le système aussi. Mais on en parlait un petit peu dans le chat, ta question pour moi est vraiment cœur, c'est comment on fait remonter du...

50:51 Du terrain. Comment tu perçois ça? C'était en réaction, je pense, à ce que disait Philippe sur les métriques de développement qui peuvent donner des indicateurs sur le bon fonctionnement ou non d'une équipe de dev. Mais je me disais, au-delà de ces métriques-là, après, c'est quoi les origines du problème? Comment on arrive à avoir... Ces infos-là, au final, est-ce que ce travail d'analyser les routes causes, est-ce que ce n'est pas ça le principal à faire pour améliorer la DVX, plutôt que de se focaliser sur les métriques? C'était ma question. Pour moi, tu as complètement raison. Ton propos est totalement valide, David. D'ailleurs, ce qui est intéressant, les métriques sont la caractérisation finalement d'une action technique. Mais il y a plein d'autres choses qui sont... Tout à l'heure, on a dit qu'il y avait la culture d'entreprise qui était là-dedans, le mindset, les pratiques, les pratiques qu'on veut pousser.

51:56 Et ça, honnêtement, si on s'arrête aux métriques, on ne le voit pas, on ne le perçoit pas. Donc, on n'est pas capable de capter finalement des frictions qui sont palliées finalement à ce qui est directement produit. On ne peut pas prendre ça comme une matière première. C'est pour ça que moi, j'ai toujours refusé à utiliser ces métriques comme étant la seule source dans laquelle finalement on se nourrissait. C'était des triggers. À partir du moment où on avait ces signaux faibles qui claquaient, c'était le moment de se dire, peut-être qu'il faut qu'on aille discuter avec eux et comprendre ce qui se passe. C'est plutôt ça le sens de ce qu'on a. L'idée, c'est d'avoir des questions à poser à ces personnes-là et pas juste leur dire qu'est-ce qui ne va pas. Benjamin, il y a un moyen pour les développeurs ou les personnes qui utilisent votre plateforme, justement, de poster ou de remonter des problématiques de ce type-là? Comment ça se passerait avec vos clients? Alors nous, en fait, il y a bien évidemment l'approche KPI qu'on a évoquée, qui permet en fait de...

52:58 Dans toute la plateforme, de savoir... qui est utilisé, de savoir combien de fois c'est utilisé. On a aussi une approche qui permet d'intégrer des commentaires sur des screenshots, ce qui te permet d'avoir de la visualisation sur« tiens, il y a un problème, il faut que je le notifie à quelqu'un». Mais là, on est vraiment dans une approche purement plateforme, outils, approches et autres, sur les rétrospectives au-delà de l'équipe dev. Moi, je pense, et c'est déjà des sujets qu'on avait déjà échangés, mais le DevEx, l'amélioration du DevEx ne peut pas venir des équipes de dev. C'est assez dur à dire. Mais je le pense profondément. Pourquoi? Parce qu'ils ne vont pas être intéressés de la meilleure, ils ne vont pas être intéressés de la même façon que va être intéressée une organisation dans sa globalité. Pourquoi? Et y compris chez Cycloid, ce qu'adore faire Medev, c'est de développer de l'expertise sur Go, développer de l'expertise sur Vue.js, développer des trucs que personne n'arrive à développer.

54:04 C'est ça qu'ils aiment faire. Moi, mon rôle et le rôle des leaders avec lesquels je bosse, c'est de faire en sorte que pour faire ça, ils aient la meilleure expérience possible. On doit reproduire, et ça c'est quelque chose, je ne suis pas fan d'Apple, mais je vais en parler. Je pense qu'il faut reproduire l'expérience d'Apple. Quand tu rentres dans le monde Apple, tu ne te poses pas la question. question comment tu vas faire à tout c'était déjà dans ce monde et déjà dans ce cadre et ben pourquoi on il ya des succès interplanétaire sur des sujets type apple et que au monde du dev on présente une approche qui est qui est très très orienté tech et qui au final on se dit non mais avec du code tu vas te débrouiller non je suis moi personnellement je suis pas du tout d'accord avec ça on a du temps imparti et on s'était bien dit qu'on n'était pas obligé d'être d'accord donc david benjamin vous pourrez vous parler après je suis plutôt dans le camp de david d'essayer de d'accord

55:08 il veut élargir au delà des équipes de dev ouais je suis tout à fait d'accord c'était prendre le terrain sur le terrain non c'était vraiment demander aux devs de dire de quoi ils ont besoin que eux peuvent justement définir et dire les outils, si j'ai bien compris, David. Mais je ne vais pas relancer le débat. Non, mais on est bien d'accord. Je suis en train d'ouvrir la porte. Ah oui, oui, complètement, complètement. C'est l'enjeu. En fait, l'enjeu, c'est ça, c'est d'avoir une approche globale de l'expérience des développeurs sans forcément être sur des... Tu as ton micro qui est ouvert. Du coup, je vais vous conclure assez rapidement sur le DevX. Je pense qu'on a brossé pas mal d'axes, pas mal d'éléments sur justement cette capacité des développeurs à avoir de l'impact. Pour moi, Mathilde a marqué des points là-dessus. De se dire qu'on a une multitude d'outils, on a une charge mentale assez forte des développeurs. Je ne vais pas complètement tout résumer, mais on a brossé pas mal d'éléments sur le DevX.

56:11 Je vous remercie beaucoup, Philippe, Benjamin, pour votre visite. Mathilde aussi. Le public, pour sa participation, on a un summit le 8 et 9 décembre pour le Tech.Rocks. Vous pouvez déjà prendre des places. On aura peut-être un sujet sur le thème. Le meet-up continue sur les tables. Je ne sais pas, Benjamin, Philippe, si vous avez quelques minutes pour passer. Moi, je vais être obligé de partir un petit peu en courant. Mais continuez de développer, faites des retours à Noémie. Sur le sujet, c'est un sujet dont on aura à reparler parce que le Tech.Rocks est vraiment aussi autour de ces pratiques-là. Donc, comment les CTO doivent s'occuper de la développeur expérience de leurs développeurs, c'est aussi une question qu'on pourrait poser dans l'autre sens. Merci à tous. Surtout à eux de s'inquiéter sur ce sujet, je pense. Oui, il faut qu'ils gèrent tout, les pauvres. Il faut surtout qu'ils gèrent ça.

57:13 C'est la préoccupation de tout le monde de se dire, comment je fais pour que mes développeurs soient le plus efficace possible. Philippe, merci pour ta présentation. Merci Dimitri pour ton animation. C'était parfait, super. C'était chouette d'être avec vous. A bientôt, à bientôt. Merci. Merci à vous. Au revoir.