Transcription

• Speaker #0

  Bonjour et bienvenue dans Nom d'un Pipeline, le podcast destiné à tous ceux qui sont passionnés par le monde du développement, du CICB et du DevOps. A chaque épisode, nous allons plonger au cœur des mécanismes et subtilités des processus de développement qui façonnent notre quotidien technique. Nous allons décrypter, partager et explorer tout ce qui a trait à l'intégration et à la livraison continue. Je suis Julien Donjou, CEO de Mergify, et avec des invités experts, des visionnaires et des professionnels du terrain, je serai votre guide dans cette aventure. Que vous soyez un spécialiste cherchant à approfondir ses connaissances, ou simplement que de comprendre les coulisses de ce monde fascinant, vous êtes au bon endroit. Alors, mettez votre ciaille en pause, assurez-vous de ne pas être en plein déploiement, et préparez-vous pour ce nouvel épisode de Nom d'un Pipeline. Et bonjour à tous et bienvenue dans ce nouvel épisode de Nom d'un Pipeline. Je suis aujourd'hui avec... Salut ! Salut ! On va encore une fois parler de CI, de plein de trucs comme ça, de développeurs expérients. Tu m'as dit que c'était ton sujet, donc on va parler de ça aussi aujourd'hui, ça va être cool. Comme d'hab, j'ai envie de commencer l'épisode par demander à Romain ce que tu penses.

• Speaker #1

  Oui, Romain Brossard. J'ai commencé ma carrière il y a un peu plus d'une vingtaine d'années. J'ai fait une dizaine d'années chez des hébergeurs ancêtres de Cloud Provider. Les dix années suivantes pour faire l'e-commerce slash marketplace et depuis ces cinq dernières années je fais plutôt du SaaS. Et toutes ces années je les ai faites sur des fonctions assez techniques, souvent pour gérer la croissance des équipes et donc apporter beaucoup d'outillages et donc une expérience développeur qui permet de gérer cette croissance.

• Speaker #0

  Trop bien. Comment tu es arrivé à faire ça en fait ? C'est un parcours naturel ?

• Speaker #1

  Non, j'ai commencé à travailler au moment de la bulle internet. Et donc à cette époque-là, il y avait des énormes problèmes de recrutement, un peu comme ceux qu'on a connus en 2020-2021, mais en plus fort. Et du coup, c'était une époque assez fleurissante où on pouvait expérimenter beaucoup de choses. et donc il y avait beaucoup d'expérimentations sur le marché. J'ai commencé du coup sur un métier qu'on appellerait aujourd'hui DevOps ou SRE, mais qui n'avait pas de nom à l'époque, justement, où j'étais en charge de créer du lien entre les admin systems et les développeurs, mais à une époque où il n'y avait aucun outillage. Et donc, je ne me rappelle plus trop le titre. Oui, il n'y avait rien.

• Speaker #0

  J'ai connu... Je dois être un poil plus jeune que toi, mais j'ai connu ça aussi. Alors, je suis arrivé, j'ai commencé à travailler juste après la bulle Internet. Donc, quand j'étais étudiant, j'avais des potes qui bossaient, eux, et qui avaient arrêté la fac parce qu'il y avait tellement de boulot que n'importe qui qui avait un an de fac, on t'embouchait comme admin 6, quoi. Et oui, ça n'existait pas vraiment ce côté SRO DevOps à l'époque. Je pense que ce n'était pas un truc. Mais c'était très scindé dans mon souvenir. Tu avais les gens du réseau, les gens des serveurs et les développeurs. Enfin, c'était trois trucs rassembler.

• Speaker #1

  Et donc mon rôle chez ces hébergeurs c'était de pouvoir, avec des clients comme soit de l'Edison comme aussi du monde qui débutait, des plateformes e-commerce comme la Root mais qui débutaient à cette époque là, c'était des années 2000, mais on avait déjà cette nécessité de pouvoir itérer rapidement, de pouvoir livrer des nouvelles versions régulièrement donc c'était pas plusieurs fois par jour comme aujourd'hui c'était plutôt... plusieurs fois par mois, c'était déjà beaucoup. À une époque où les équipes de développement avaient l'habitude de faire des recettes de plusieurs mois en secondaire, c'est une autre époque. Mais donc justement, il fallait inventer cette nouvelle façon de travailler où on permet aux équipes de développement d'itérer, de pouvoir collecter du feedback rapidement parce qu'on touchait tout de suite des millions d'utilisateurs via Internet, ce qui était vraiment nouveau à l'époque. Et donc c'est comme ça que j'ai commencé. et de fil en aiguille finalement j'adore l'apprentissage, c'est comme ça que je m'épanouis, on apprend de nouvelles choses et j'ai continué à explorer, il y a beaucoup de littérature qui a commencé à apparaître sur l'université notamment et donc j'ai continué à creuser ce sillon dans différents contextes, après je suis passé effectivement plus du côté de Alors je n'étais plus dans une relation client-fournisseur comme au début, mais plus directement chez les... des gros e-commerce à la Fnac, chez FCDiscount, où là, effectivement, c'était des contextes un peu moins structurés qu'une relation client-fournisseur, mais c'est toujours les mêmes enjeux de devoir itérer beaucoup, mettre en prod très vite avec un bon niveau de qualité pour pouvoir avoir du feedback et donc offrir de plus en plus de business value au fil des déterrations. Et donc, mettre à disposition des outils... évidemment de CI et des approches CI-CD performantes pour permettre aux équipes d'avoir de l'autonomie.

• Speaker #0

  Du coup c'est quoi ton approche aujourd'hui ? Aujourd'hui tu postes chez Miracle si je n'ai pas de bêtises.

• Speaker #1

  Certes, trois ans bientôt.

• Speaker #0

  Bon anniversaire bientôt alors que c'est trois ans. Et du coup c'est quoi ton... est-ce que tu veux nous raconter un peu... Quand tu es arrivé, est-ce que tu as découvert ce qu'il y avait, l'état ? Est-ce que tu as fait un peu depuis trois ans ? Parce que j'imagine que tu es venu aussi avec ce côté approche. Tu es peut-être déjà en place chez Miracle. Je ne sais pas du tout d'où ils partent. Même si la boîte n'est pas super vieille.

• Speaker #1

  Je suis arrivé chez Miracle. Effectivement, la boîte avait quand même pas loin de 10 ans d'ancienneté, je pense. Il y avait quand même des bases et des bases assez solides. Une culture engineering plutôt bonne. et avec des grosses exigences de qualité. Et en fait, je suis arrivé chez Miracle pour finalement aider à structurer la croissance des équipes d'engineering puisqu'on a recruté énormément. Et en fait, si on ne met pas en place l'outillage qu'il faut, les process qu'il faut, pour maximiser la collaboration entre les équipes produit et l'équipe engineering, rien de suffisant ça ne suffit pas en fait pour apporter davantage de business value. Il faut essayer justement de mettre de l'huile dans tout ça et trouver le bon équilibre entre... Alors je suis assez fan d'un livre qui s'appelle Team Topologies qui est une façon de représenter les organisations. tech et en particulier dans les scale-up avec ce qu'on appelle des stream-aligned teams, donc les teams qui produisent directement de la business value et de manière un peu plus transversale ce qu'on appelle les platform teams, donc plus SRI, enablement team, donc ces équipes qui vont être développeurs expérience ou product ops, enfin voilà, des équipes en support un peu transversale et complex system team qui sont des équipes qui n'apportent pas directement de la business value mais qui vont… construire des assets technologiques suffisamment importants pour avoir un ownership fort dessus. Ça va être par exemple un moteur de recherche chez un site e-commerce pour la brique de moteur de recherche qui est utilisée par plusieurs équipes qui apportent de la business value, on va avoir une équipe dédiée par là. Donc moi, on va dire mon cœur d'expertise, c'est d'orchestrer ces équipes un peu transversales justement pour apporter du soutien aux équipes qui apportent de la business value. Et l'enjeu en fait, il est de trouver le bon équilibre entre eux. entre ces équipes qui apportent de la business value et des équipes centralisées qui apportent du support. Si les équipes centralisées sont trop importantes, trop grosses, finalement, elles vont devenir un frein à l'organisation. Mais si elles sont trop petites, elles n'apportent pas assez de support aux équipes qui apportent de la business value. C'est extrêmement important de trouver le bon équilibre et de faire croître ces équipes un peu centrales en même temps que les équipes de filtreurs. Et donc, je suis arrivé effectivement en fin 2021 pour… structurer un peu ces équipes centrales et accompagner la croissance de Miracle et notamment la croissance des équipes engineering puisqu'on continue de recruter 30-50 personnes par an, on est du turnover, mais voilà aujourd'hui on n'est plus de croissance du côté produit, R&D et engineering. Et donc ma vision du job c'est de, encore une fois, garantir un bon niveau de vélocité pour ces équipes qui délivrent de la business value. Et c'est vraiment mon point cardinal, l'étoile polaire, c'est vraiment la target que je donne à toutes mes équipes. Tout ce que vous faites, vous devez le faire pour améliorer la vélocité des équipes de dev et qui produisent de la business value. Alors bien sûr tout ça peut le faire en tenant compte des contraintes de sécurité que les équipes sécu nous fixent, en tenant compte de nos dépenses cloud qui sont... croissante en permanence. Donc voilà, il faut réussir à être garant un peu de ces contraintes et de les rendre complètement invisibles pour les équipes de dev qui ne s'en occupent pas. que ce soit des contraintes transparentes quelque part, donc ça c'est le Graal, et donc leur permettre d'itérer encore une fois très rapidement, dans de bonnes conditions. Et donc il faut trouver le bon équilibre entre offrir de l'autonomie, donc avec une grosse culture d'inner source, c'est-à-dire tout ce qu'on fait en centrale, on le documente, on l'organise, pour que n'importe qui puisse contribuer dessus, on garde l'ownership. et les reviews, mais n'importe qui. Donc on a beaucoup de systèmes de reusable workflow, notamment avec GitHub Actions. Ces reusable workflows sont régulièrement enrichis par les équipes qui les utilisent, à travers un flux classique de pull requests. Et donc ce qui permet de donner de l'autonomie aux gens, mais tout en pouvant bénéficier d'un système sur étagère qui fonctionne, qui a été éprouvé, qui est testé, qui est maintenu. et donc qui permettent de les accélérer quand ils ont besoin de démarrer un nouveau sujet et qu'ils ont envie de réinventer la route. Donc ça, c'est une approche que j'ai pilotée à différents niveaux. Donc on vient de parler de la CI avec les Resolvable Workflow, mais c'est aussi vrai côté plateforme engineering pour la capacité à bootstrapper des infrastructures sans être un expert Terraform. Donc on a en place pas mal d'outils d'aide. Et tout ça appuie à différents niveaux de maturité en fonction des populations auxquelles on s'adresse, sachant qu'on va jusqu'à des outils en self-service à travers un portail de développement, donc un front assez classique, comme on l'a chez les cloud providers, qu'on a construit dans le courant de l'année pour justement apporter du self-service.

• Speaker #0

  Très bien. C'est ouais, il y a des gens qui commencent à faire ça, je commence à voir quelques projets. Il y a Backstage.

• Speaker #1

  Ouais,

• Speaker #0

  c'est ça Backstage, c'est encore très très très récent, il y a à ma connaissance peu encore de boîtes qui déploient ce genre de solutions et c'est cool parce que ça résout ce que tu dis, le côté self-service, le côté fournir du support aux équipes en fait, aux développeurs pour qu'elles puissent travailler plus vite et tout, c'est super. C'est quoi la taille de votre équipe ? Dès qu'il y a près de 300 personnes, c'est quoi la taille ?

• Speaker #1

  C'est environ 10. C'est une métrique avec mon expérience que j'ai pu challenger. Aujourd'hui, on n'a plus pas 10%, donc on est une trentaine entre des gens qui bossent sur la pure plateforme, côté cloud provider, des équipes de développeurs expérience, des équipes d'architectes. C'est à peu près une trentaine de personnes, donc c'est 10% de l'équipe totale. C'est juste des ratios, ce n'est pas gravé dans le marbre. C'est important de faire croître ce type d'équipe à bonne vitesse, encore une fois pour apporter le bon niveau de support aux équipes qui développent des pitchers. C'est une équipe avec beaucoup d'expertise, avec des gros enjeux de management. Parce qu'il faut réussir à conserver le cap, c'est-à-dire d'être au service des autres développeurs, mais en apportant en permanence des challenges technologiques et techniques assez importants. Donc c'est assez compliqué.

• Speaker #0

  Tu veux dire qu'il ne faut pas s'ennuyer en fait ?

• Speaker #1

  exactement mais faire des reusable workflow à la chaîne c'est pas non plus ce qui les intéresse donc voilà c'est pour ça qu'il faut essayer d'avoir une certaine diversité mais encore une fois tout ça il faut le manager avec une approche par l'impact donc l'approche produit elle c'est classique j'ai dans mes effectifs d'ailleurs des product managers qui vont justement essayer de comprendre les problèmes auxquels sont confrontés les équipes de dev donc pour justement essayer d'y répondre par des solutions assez classiques sauf que nos utilisateurs sont des utilisateurs interlocants.

• Speaker #0

  Est-ce que tu n'as pas aussi un problème parce que du coup je comprends le côté il ne faut pas qu'il s'ennuie mais est-ce que tu n'as pas un côté où il ne faut pas qu'il soit frustré parce que est-ce que tu n'as pas ce problème qui est eux vont builder des trucs, des outils, des reusable workflow, des choses comme ça, mais d'un autre côté, les développeurs n'ont pas le temps de les utiliser, pas le temps de s'adapter à un nouveau système, pas le temps d'utiliser ce nouveau truc, pas le temps d'eux, et eux sont frustrés parce que leurs utilisateurs, parce que ce n'est pas leur cœur de truc en fait. Est-ce que tu as ce problème-là ou est-ce que du coup tes devs, en fait, ils sont genre super, un nouveau truc qui va nous faciliter la vie ?

• Speaker #1

  En fait, c'est un peu l'intérêt de l'approche que j'ai citée juste avant, l'approche produit. c'est qu'on essaye de mesurer l'adoption de tout ce qu'on fait et on y va de manière très progressive et itérative nous-mêmes. On va commencer par une première itération pour avoir un peu de feedback. On a même des gens qui sont tellement pressés, donc des gens qui ne sont pas dans les équipes, qui vont contribuer dessus pour que ça aille plus vite. Donc là, on sait qu'il y a vraiment de l'attraction et il faut qu'on investisse beaucoup sur ces tracas et on y va à fond. Et puis, il y a d'autres périmètres. où c'est une ou deux personnes qui nous ont demandé telle ou telle feature, on va le faire, et on voit que finalement c'est assez peu utilisé, ça a assez peu de valeur, et donc on a une évaluation permanente des usages pour justement investir là où on constate que ça a de la valeur. Et des fois on fait des choses, on se trompe, on arrête d'investir sur ces tracts-là. Je pense que c'est important aussi d'expérimenter et de se tromper. Ce qu'il faut, c'est effectivement mettre le maximum de poids sur là où ça a le plus d'impact. C'est assez classique. Mais ces experts ont un feedback assez rapide, positif, et c'est assez motivant en général. Je ne rencontre pas trop de problèmes de ce côté-là.

• Speaker #0

  Et ça me fait penser à un truc, du coup, est-ce que tu n'as pas aussi le problème ou la peur, moi j'aurais à ta place, tu bosses avec des ingés et tu leur fais builder des solutions pour aider les développeurs, est-ce que tu n'as pas aussi la problématique du builder buy, c'est-à-dire des ingés qui vont peut-être des fois builder des trucs qui feraient mieux d'acheter parce qu'ils vont perdre du temps, mais ils ont un biais parce que c'est des ingés, ils vont se dire mais on le fera mieux et on fera ça mieux que les autres. et donc ils vont commencer à buller la rue. Peut-être qu'ils vont réussir mais comme c'est pas forcément leur cœur de métier...

• Speaker #1

  C'est une maladie très courante dans nos métiers. Effectivement, on est touché aussi par cette maladie. Ceci étant...

• Speaker #0

  Personne n'est immunisé.

• Speaker #1

  C'est effectivement difficile à manager parce que la solution du marché ne va jamais vraiment faire exactement ce qu'on veut. et donc ça veut dire faire des trade-off et ça c'est mon rôle de manager après de vendre ces trade-off parce que je sais que sur le long terme le buy est souvent plus supportable sauf si on a besoin de le customiser de tous les côtés ça veut dire que voilà et c'est l'exemple contraire qui est le portail de développement justement où on a choisi de le fabriquer et pourquoi on n'a pas pris un backstage par exemple qui est vraiment le le Il y a eu une hype autour de Backstage il y a quelques mois, qui est l'outil open sourcé par Spotify, tout simplement parce que Backstage, ça répond aux problématiques de Spotify, on n'a pas tous les mêmes problématiques que Spotify. Ça peut être open sourcé, il y a des concrètes, etc. Mais on est là sur, encore une fois, on avait des problématiques... spécifique auquel il fallait répondre avec ce portail de dev et qui n'était pas celle auquel répond Backstage. Et du coup, c'est pour ça qu'on a développé notre propre produit. Mais pourquoi on a pu le faire ? C'est aussi parce que chez Miracle, on a une culture produit très forte. On a en 2022 lancé, donc on avait un produit qu'on a prématuré pendant 10 ans qui était notre core product qui fait notre renommée. Et en 2022, on a enrichi notre suite de produits avec quatre produits en plus supplémentaires. Et ça, on a pu le lancer très rapidement parce qu'on s'est structuré d'un point de vue tech, et notamment avec un design system, pour pouvoir lancer assez rapidement des produits. Et donc, on a pu bénéficier dans mes équipes de cette approche. de devs full stack qui ont pu récupérer ce design system, ils ont pu tout strapper à un portail rapidement parce qu'on avait déjà les backends en fait, les backends existaient. Nous notre problématique, en fait, à quel problème on voulait répondre en venant au portail de devs, c'était finalement une problématique un peu marketing. On avait plein d'outils qui étaient fonctionnels, utilisables pour aider les développeurs, mais en fait on avait du mal à les faire connaître aux nouveaux arrivants. Quelqu'un qui arrivait et donc parfois il se passait six mois, un an avant que les personnes découvrent que tel ou tel outil existait chez nous et l'utilisent. Et donc le portail de dev, il avait vraiment pour but de marketer, en tout cas mettre à disposition des outils d'aide de productivité pour les développeurs. Et finalement, si on avait dû le refaire avec Backstage, ça nous aurait coûté plus cher en intégration que de bootstrapper ce portail sur un backend qui existe déjà, qui est fonctionnel, qui est testé, qui marche très bien. Donc il faut vraiment évaluer assez... C'est toujours compliqué ce choix make or buy, il faut réussir à se projeter dans le futur. ce qui est difficile parce qu'on est sur des métiers d'incertitude, justement on gère l'incertitude en permanence, et donc s'engager sur une solution, que ce soit open source ou commercial, mais donc plus sur une approche d'intégrer une solution existante, ça veut dire effectivement qu'on se commite tous sur le fait qu'on ne va pas la customiser et qu'on va en accepter les contraintes, et c'est ça qui est difficile à faire accepter. c'est un travail de manager. Mais effectivement, tu as raison, sur des profils très experts, pour eux, finalement, réinventer la roue, c'est peu d'effort. Et donc, ils vont préférer le faire pour avoir une roue sur mesure. Et c'est quelque chose qui est assez fréquent. On n'y échappe pas, même si j'essaye d'en sortir un peu dès que possible.

• Speaker #0

  Ouais, ce que tu disais au début de la conversation était aussi, je pense, se relier à ça, c'est le côté trade-off en fait, c'est que vous faites tout le temps des compromis et ça en fait partie, et c'est effectivement, des fois c'est sûrement ton rôle au niveau managérial de faire ces compromis et de les arbitrer, parce qu'il faut bien prendre une décision à un moment et prendre le risque et lever l'incertitude, ou en tout cas faire un choix d'un côté ou d'un autre, je pense que c'est le truc intéressant, mais ouais je vois bien, et puis builder c'est... C'est facile, mais après,

• Speaker #1

  il faut le retenir. C'est la maintenance. Et le problème un peu des outils experts qui sont construits en interne, c'est que souvent, ils ont été construits par une, voire deux personnes au mieux. Évidemment, il y a quelqu'un qui a fait quelques reviews. Mais du coup, ça devient vite compliqué pour la maintenance parce qu'on a du mal à gérer les plus de travaux. Si on a vraiment sur… le même expert deux outils qui ont besoin d'être enrichi au même moment voilà c'est des problématiques de concurrence assez classique c'est pour ça que quand on voit quand on fait du mail déjà peut s'assurer que on le fasse pas faire par un expert mais par un pool de personnes pour qu'on ait suffisamment de bande passante pour faire la maintenance après derrière et c'est ça c'est il ya quelques signaux comme ça il faut se baquer en fait pour être certain de avec quoi on s'engage sur une solution de build versus du buy.

• Speaker #0

  Ce que tu dis est vrai, ça me fait penser à un autre truc, parce que tu me dirais que c'était d'accord, mais en fait, comme tu dis, il ne faut pas le faire par une personne, mais par plusieurs, et je pense que c'est même pire que ça, parce que le problème que tu as avec les trucs custom comme ça que tu fais, c'est que tu peux avoir tendance à partir dans une très mauvaise direction. Je vais prendre un exemple bête, mais en fait, tu penses que la manière dont tu travailles, je ne pense à rien, avec tes branches, tes machins, tes trucs, c'est la bonne façon de faire. Donc, tu ne trouves pas d'outils sur le marché open source ou commercial, comme tu disais, qui sont adaptés à ton truc en disant, en fait, tous les autres bossent bizarrement, personne ne peut faire comme moi parce que c'est moi qui ai raison. Donc, tu construis des trucs autour de ça pour en fait, au bout de quelques temps, mois, années, te rendre compte qu'en fait, ton truc de base, tu n'étais pas bon et que tu as construit tout un écosystème autour de ça qui en fait n'est pas bon et que tout... l'industrie a pris une direction différente de la tienne et a fait tout un jeu de compromis qui est bien mieux que le tien parce que tu t'es trompé et tu as continué à creuser ton habit hole, ton trou à toi et c'est super dangereux de faire ce genre de truc. Donc être tout seul, comme tu dis, avec un expert c'est pire. Si au moins tu as un collectif de collègues qui te dit attends mais j'ai vu que peut-être qu'on se trompe etc c'est bien,

• Speaker #1

  mais en vrai il faut être assez humilant effectivement quand l'industrie fait une autre direction que la sienne. des fois c'est c'est des jeux de lobby et l'industrie n'a pas forcément raison et donc on peut avoir raison de prendre un chemin orthogonal mais c'est quand même un signal faut le regarder près c'est évident ça

• Speaker #0

  c'est clair ça me faisait penser à ça du coup c'est quoi tu parlais du portail je trouve ça super intéressant du coup vous avez fait le choix de build ça peut se comprendre effectivement en plus je pense qu'il n'y a pas encore des On parlait de backstage, il n'y a pas non plus des tonnes de projets open source ou commerciaux, il y en a quelques-uns, j'ai vu ces derniers mois, mais ce n'est pas non plus une offre pléthorique, c'est assez récent, donc ça peut être aussi un choix nécessaire et peut-être même temporaire, parce que peut-être que le reste du monde rattrapera un peu ce que vous avez fait, et puis tu peux toujours revenir sur ta décision au bout d'un moment et dire finalement on n'a plus besoin de ce qu'on a fait, ça c'est cool. Est-ce qu'il y a d'autres trucs comme ça que vous avez buildé qui sont assez... assez sympa et que vous êtes fiers de vous.

• Speaker #1

  Donc, on fait du SaaS. C'est du SaaS Enterprise. Ça veut dire qu'on s'adresse à des gros clients. On n'a pas 10 000 clients, on a plutôt 500. Mais avec une grosse complexité pour chaque client, un mélange d'infrastructures. mutualisés, régionalisés, parce qu'on a des clients partout dans le monde et on a des enjeux de temps de latence, donc on a besoin d'avoir des clusters régionaux. Et pour des questions historiquement plutôt techniques, et avec le temps c'est devenu des questions un peu réglementaires, on a des data stores dédiés par client. Comme ça, ça simplifie énormément les appels d'offres, le client sait que ses données sont isolées sur un data store dédié. ça facilite les cycles de ventes. Mais du coup on a une complexité d'infrastructure à gérer quand on a un nouveau client à déployer, quand on a un nouveau, ce qu'on appelle un tenant, dans le monde du SaaS c'est vraiment l'environnement d'un client donné. Et donc sur un tenant, chez nous on a une partie des applications qui ont un workload mutualisé. On va avoir un cluster qui va traiter 50 clients en parallèle et par contre qui va arroser 50 DB différents. On a un système de messaging asynchrone, il y a tout un tas de... C'est une cinquantaine d'applications pour notre produit. Et donc, le déploiement d'un environnement, que ce soit pour un client, que ce soit pour un pre-sale, que ce soit pour un développeur qui est en train de développer, C'est complètement industrialisé chez nous. Quand je suis arrivé il y a deux ans et demi, trois ans, c'était un enchevêtrement de ScriptShell et de JobDankFins qui faisaient le job. On déployait plus de 2000 environnements, donc on devait en déployer une centaine par mois. Ça faisait quand même le job. Le problème, c'est que du Shell et de BankFins au niveau maintenance, C'est dur à tester en fait, c'est dur à tester donc dès qu'on le touche, on risque de casser. Et donc j'ai remplacé tout ça par une approche opérateur, opérateur Kubernetes. Donc on a un contrôleur en fait avec un appareil de configuration qui va réconcilier à la fois l'infrastructure, les configurations d'applications, les déploiements et qui bien sûr est API-D. et donc qui permet de gérer tout le cycle de vie de ces tenants, la création, la destruction, la gestion de la fin de vie d'un tenant où on doit faire des backups, les envoyer aux clients, etc. Et donc tout ça c'est API-sé, ces API ont été mis à disposition à travers notre portail de dev justement pour avoir un front-end un peu sympa pour les équipes qui ne manipulent pas trop Curl ou Postman. Voilà et donc ce contrôleur en fait nous a permis de... finalement donc écrit en go, de mettre en place finalement un processus complètement testé, testable, ce qui n'était pas le cas avant et donc maintenant on peut le faire évoluer vraiment en sécurité et donc cette approche le control plane sas on l'a pas inventé, il a été documenté par AWS mais voilà ça nous a apporté un bon niveau de solidité de maturité sur les équipes plateforme parce qu'aujourd'hui on est capable justement de augmenter le niveau de qualité de ce qu'on délivre d'offrir aussi

• Speaker #0

  de l'environnement à la demande, on l'offrait déjà mais avec davantage de qualité et on se projette aujourd'hui sur la possibilité d'offrir des environnements de travail à la demande à nos clients également, nos clients qui veulent faire de l'intégration continue aujourd'hui ils ont un environnement de sandbox pour tester leur intégration mais c'est un environnement statique c'est à dire que on ne peut pas le rincer, le redémarrer etc. On leur sourdit, ils peuvent éventuellement faire une demande de support pour recréer un nouveau mais voilà il n'y a pas vraiment de self service. Donc l'étape suivante, c'est effectivement de mettre à disposition cet API de nos clients pour leur permettre d'avoir ces environnements à la demande, pour entrer dans des logiques d'intégration continue assez classiques qu'on connaît bien dans nos métiers. Donc ça, effectivement, ça a été un challenge parce que quand je suis arrivé il y a deux ans et demi, et que j'ai commencé à expliquer à mes équipes que je voulais... dans cette direction. J'ai eu un peu de scepticisme des équipes, ça leur semblait un peu ambitieux.

• Speaker #1

  Scepticisme ? Non, non,

• Speaker #0

  non. L'application qu'eux avaient mis en place justement du Shell et du Genk Team, c'était un peu à bout de bras, etc. C'est qu'il y avait un vrai besoin fonctionnel, en fait, c'était nécessaire. Scepticisme sur le fait que c'est ambitieux. Et on y est arrivé. parce qu'on y a consacré les ressources dédiées aussi pour y arriver. Je pense que ça a été un enseignement. Quand je suis arrivé, j'avais des équipes qui étaient un peu au four au moulin, qui faisaient un peu de tout. Et donc, j'ai essayé de mettre un peu de focus aussi sur chaque équipe, ce qui n'a pas été simple en termes de management, parce que je reviens sur cette équipe d'experts. Les experts, en général, aiment bien toucher à tout. Quand on les cantonne à un domaine plus restreint, il y a un peu de frustration. Donc, voilà, il y a des choses qui conduisent au changement. Mais là… l'autre com c'est qu'on a réussi à sortir ce control plane en fait aujourd'hui ça tourne,

• Speaker #1

  ça on run et pour moi c'est une vraie victoire ce que tu décris c'est intéressant et ça me fait penser en fait c'est une approche tu parlais d'approche produit mais en fait de la manière dont tu le décris et des problèmes que ça résout en fait ça fait partie du produit finalement c'est même pas un truc qui est finalement un produit interne pour les devs parce que tu permets par exemple, comme tu dis, management des tenants, ce genre de choses, de fournir des environnements pour faire de l'intégration continue, c'est la vision à long terme. D'aller là-dessus, c'est en fait une fonctionnalité de ton produit final que tu vends dans le client Ripple.

• Speaker #0

  En fait, la frontière peut être assez subtile, mais ça, en fait, il y a un livre blanc qui a été fait par AWS sur cette approche qui sépare le control plane. Ce sont tous les outils pour mettre à disposition le produit et le sécuriser. Et l'application plane ou data plane, ça dépend du vocabulaire, mais qui est le produit en tant que tel. Et donc, les deux marchent ensemble. En fait, si on prend AWS, que tout le monde connaît, la console et les API pour manager S3, ça va être le contrôle plane. Et en fait... toute l'application qui fait que S3 fonctionne, c'est finalement le produit. Donc là, c'est un peu pareil. Ce qu'on a construit, nous, et pour l'instant, c'est seulement en interne, c'est ce control plane qui permet de piloter l'œil et les produits. Et donc, ça n'empêche pas de le mettre à disposition des clients avec des parcours en fonction des droits, avec plus ou moins de possibilités. Mais c'est quand même assez séparé du produit qu'apporte la business value. Là, on est vraiment... sûrement sur des couches de management en fait pour orienter sécurité infrastructure oui mais c'est plus la valeur que tu as à la fin et à la fin moi ce qui m'intéresse aussi c'est de réussir à apporter aussi de la business value et de contribuer justement à

• Speaker #1

  faire que le produit est adopté par les clients ouais clairement ça c'est vachement bien de pouvoir aller jusqu'à fournir de l'intégration continue comme ça à tes clients ils doivent être contents s'ils font du l'intégration continue, ils vont être contents. Parce que souvent, quand tu commences à parler à l'extérieur de ton application, de ton écosystème, et tu te retrouves vite avec plus rien, et tu te débrouilles, ce n'est pas très rigolo. Et ça me fait penser à une question, du coup, à quoi ça ressemble, vous, aujourd'hui, votre intégration continue, justement ? C'est quoi le... J'imagine que tu as plein de services, tu as peut-être plusieurs projets, c'est organisé, j'imagine, par des équipes, par projet, etc. Mais tout le monde est un peu différent, mais en termes de... Et de techno, et de fonctionnement, et de politique, entre guillemets, c'est quoi le Golden Pipe ?

• Speaker #0

  L'histoire commence dans notre portail de dev où si tu as une nouvelle application Java principalement, tu as des formulaires qui permettent de se rappeler le custom. L'ecostem, c'est quoi ? Ça va être un repo

• Speaker #2

  GitHub avec des reusable workflows GitHub Actions,

• Speaker #0

  donc des reusable workflows de CI et de déploiement. Reusable workflow pour gérer le code scanning aussi sur la partie sécurité. On a des workflows spécifiques distincts de la CI. Parce qu'on est certifié SOC 2, donc on a un certain niveau de reporting à fournir. Et du coup, voilà, ça c'est une petite contrainte technique. Mais le fait qu'on soit certifié SOC 2 nous oblige à avoir une CI très processée, très standardisée pour pouvoir vraiment, pour les auditeurs, être certains de… d'obtenir vraiment les traces dont ils ont besoin, pour nous permettre de garantir aux auditeurs qu'ils obtiennent les traces dont ils ont besoin. Donc ça c'est... et en fait nos GitHub Actions de déploiement s'interface avec Argo CD ou Argo Workflow, donc deux produits complémentaires qui permettent...

• Speaker #2

  Donc on a...

• Speaker #0

  tout ce qu'on a est versionné dans Git. On a des manifestes Helm pour nos applications, quels que soient les langages, qui permettent de décrire les déploiements Kubernetes cibles. Et donc, nos GitHub Actions vont comiter des manifestes pour pouvoir taguer les bonnes versions. Et ErgoCity va automatiquement déployer ça sur... pour nos clusters cubes. Pour cette étape de déploiement, on a différents automates en complément. On a un Gitbot en self-service qui permet de lancer des déploiements aussi sur une PR avec des commentaires. On a un Gitbot qui écoute les webhooks GitHub et qui, en fonction des commentaires qu'on va mettre dans la PR, va déclencher des actions, dont des actions de déploiement sur des environnements donnés. On peut mettre le nom de l'environnement, etc. Donc ça va permettre à des testeurs d'aller sur cet environnement tester. Et on a aussi, donc ça c'est aussi pour des contraintes SOC 2 surtout, une IHM de déploiement, donc pour les environnements clients en fait. C'est-à-dire que tant qu'on est en environnement de dev pour les tests, là ça se fait effectivement plutôt... plutôt directement avec un GitBot qui va sur chaque PR faire les déploiements au fil de l'eau. Et dès qu'on a une version réalisable, on va avoir une IHM qui permet aux développeurs de faire la promotion d'environnement et de déployer aussi dans chaque région dans le monde des versions des applications au service. avec le bon niveau de traçabilité sur qui a fait quoi, à quelle heure, quand, dont on a besoin les auditeurs dans le cadre de la certification. Aujourd'hui, tous nos produits sont développés en Java et TypeScript, du React, Front. Après, moi mes équipes vont plutôt travailler en go. Typiquement, on fournit un proxy d'authentification devant l'ensemble de nos produits pour avoir une authentification homogène quel que soit le produit avec un SSO. Quand on a un client qui souscrit à plusieurs produits, de la manière d'Aptassian, quand on bascule d'un produit à l'autre, l'authentification est complètement silencieuse. Effectivement, cette gateway, on l'a faite en Go parce que c'était plus adapté pour nous, plus économique en ressources. Le faire en Java n'aurait pas forcément été pertinent, même si on en a fait par le passé en Java. On a des services comme ça, core platform, d'authentification, de crypto, qui sont en Go. Mais l'essentiel de nos développements métiers, on va dire business, sont en Java et TypeScript. Alors, et bien sûr, j'avais oublié le prince de balle cette année. 2023-2024. On a évidemment des équipes data conséquentes, donc eux font plutôt du piton. Et donc effectivement on met de plus en plus à jour aussi notre outillage pour les accélérer, je vais dire, même si là on est sur des écosystèmes qui sont beaucoup moins matures, balbutiants, avec des profils, notamment des profils data scientist, qui sont des profils très orientés recherche opérationnelle. Et donc voilà, il faut qu'on arrive à les aider à justement mettre en prod Bravo avec le plus de sécurité possible, le plus de fiabilité possible. Voilà donc là il y a un vrai enjeu assez nouveau, très intéressant, passionnant. Et encore une fois, moi qui adore apprendre, je suis dans un écosystème là où il y a beaucoup de choses à découvrir.

• Speaker #1

  Oui parce que les data scientists, se mettre en prod en général, ils viennent avec un notebook Jupyter et ils font voilà. C'est ça qu'il faut mettre en preuve, c'est compliqué.

• Speaker #0

  Oui, et puis c'est toujours pareil. On ne peut pas mettre un SRI derrière un Data Scientist. Donc ça veut dire qu'il faut leur donner de l'autonomie et mettre les outils qu'il faut. Donc voilà, on est vraiment dans une logique de construire une chaîne industrielle qui leur permet d'aller au-delà du notebook Jupiter.

• Speaker #1

  Et les déploiements que vous faites, c'est des déploiements qui sont toujours par tenant ?

• Speaker #0

  Quand on a une version qui est réalisée, c'est par stage. On a des environnements d'intégration pour nos clients, qui sont livrés 2-3 jours avant la prod pour permettre aux clients d'identifier des problèmes d'intégration que nous, on n'aurait pas vu en QF. Voilà, c'est pour ça qu'on les livre en amont. Et ensuite on a un stage qui a tendance à disparaître, c'est historique de pré-prod. C'est parce qu'on avait des clients un peu à l'ancienne qui voulaient une pré-prod, qui soit la copie de la prod sur laquelle ils fassent des tests, mais ça on le vend,

• Speaker #2

  donc on le maintient.

• Speaker #0

  Et le stage de pré-prod qu'on va réaliser, c'est ça, soit le lendemain, soit deux jours après. le stade d'intégration. Mais ça, on est sur des versions stables, réalisées. Donc, c'est vraiment… Et donc, en prod, on va faire un progressive rollout sur l'ensemble des clusters qu'on a dans le monde. Mais c'est une histoire de demi-heure, encore d'heure au plus. Mais voilà, ce n'est pas plus étalé que ça. Sachant qu'on a, voilà, encore une fois, des clusters multi-tenant qui vont gérer une cinquantaine de clients. à peu près à chaque fois en fonction des régions donc voilà chaque cluster est livré l'un après l'autre de manière séquentielle oui du coup tu ne fais pas forcément 200 déploiements dans la journée tu fais plus un système de relis alors là c'est sur un microservice donné mais on a plein de microservices les équipes peuvent déployer Deux équipes avec un microservice qui contribue au même produit peuvent déployer en même temps leurs deux microservices. On est obligé aussi de mettre en place la gestion de la concurrence,

• Speaker #2

  ce type de choses.

• Speaker #0

  Mais par construction, nos applications sont conçues pour pouvoir se déployer en concurrence.

• Speaker #1

  Vous avez quand même tout automatisé, vous avez tout le tout. qui est prévu pour eux tous donc toute façon même depuis un peu le début comme tu disais il y avait déjà du Jenkins et etc donc c'est quand même dans cette direction là depuis le début donc ça va là dessus vous êtes plutôt plutôt opérationnel et côté CI du coup c'est un peu chaque équipe fait comme elle veut ?

• Speaker #0

  On a une CI GENERING pour les microservices qui est vraiment standardisée avec des commutateurs on off pour des tables de la CI voilà Par exemple, on peut ajouter un channel Slack dans un workflow et activer le fait qu'on envoie les erreurs sur le channel Slack. Ça c'est optionnel. On a quand même plein d'autres options, comme ça c'est customisable. Il y a des possibilités d'avoir un rapport de couverture de tête, de mémoire, des choses comme ça qui sont pareil customisables. On essaye de faire, encore une fois, c'est l'approche Golden Pass, tu as le truc qui fonctionne, que tu plugues, que tu peux un peu customiser. Et puis, l'avantage d'être avec GitHub Action, c'est que sur ton propre repo, tu sources et tu peux en rajouter en plus pour toi d'autres jobs, donc tu peux customiser ta CI sans problème. Et après on a encore, c'est historique, ça date de beaucoup d'entreprises, on a trois monolithes sur lesquels on a une CI aux petits oignons spécifiques parce qu'il y a plusieurs équipes qui contribuent sur ces monolithes. Donc comme il y a de la concurrence, moins d'ownership, on est obligé d'avoir des jeux de tests plus conséquents, donc se baquer davantage. Et du coup là on a une... une CI très particulière pour ces monolithes et du coup est gérée directement par les équipes qui ont l'honorship. Ce n'est pas mon équipe qui... Alors évidemment on aide à craquer les problèmes mais on ne fait pas la maintenance de ces workflows. On peut contribuer sur des PR etc. Par contre ce qu'on fournit c'est pour l'ensemble des microservices, on a fourni une CI générique sur la base de Résilible en Clos.

• Speaker #1

  du coup c'est ton équipe qui maintient le...

• Speaker #0

  on a un site de release sur Series Development Flow, ils sont tagués, avec un système de permémo, de majeur, mineur, etc. et effectivement quand il y a des breaking change, du coup on fournit un guide de migration On utilise, alors ça dépend des écosystèmes, soit Renovate, soit Dependabot, pour ouvrir des pairs automatiquement quand on fait des mises à jour majeures de ces workflows, parce que sinon on fait un tag majeur classique V1, et puis même si on a des mineurs derrière, ça embarque la V1.

• Speaker #1

  Bref,

• Speaker #0

  et du coup on utilise soit Renovate, soit Dependabot pour ouvrir des pairs dans les repos. consomment ces Railsable Workflow pour qu'ils soient notifiés qu'il y a une nouvelle version, qu'il faut mettre à jour, etc. Donc pour un peu limiter la charge collective de mise à jour quand on a fait les travaux de maintenance. Donc voilà, on en fait la maintenance. Et là aussi, on essaie d'avoir une approche produit en ce moment, mais mon équipe de développeurs expérience est en train de faire le tour des équipes de dev. des sessions d'interview d'une heure avec soit des seniors dans chaque équipe, soit des gens qui sont intéressés par la CI et la vélocité pour comprendre un peu leurs problèmes et comment on peut améliorer ça. Évidemment, il y a des problèmes de performance de la CI, de la durée de temps d'exécution. Ça, c'est un problème très classique. Je dirais que quelque part, on n'a pas besoin de rejeter les gens sur les temps de détente.

• Speaker #1

  Voilà, ça va jamais assez vite.

• Speaker #0

  Ça, c'est des travaux qu'on traite en continu, mais des fois, il y a des nouveaux besoins qui popent pour des questions de compliance, pour des questions de nouveaux patterns d'organisation entre les QA, les products, les devs. Et donc, ils ont besoin de remonter la donnée d'une manière différente. Ils ont besoin de donner davantage d'autonomie aux products, aux QA pour pouvoir développer les deployings environnementaux. Donc, il peut y avoir des besoins qui popent comme ça, ou en tout cas des problèmes d'autres qui popent. et nous on va y répondre avec des solutions. Vraiment toujours ce côté itératif et cette approche produit y compris sur la CIR. Ok,

• Speaker #1

  super. J'aime beaucoup le côté approche produit où tu vas jusqu'à faire finalement des interviews des utilisateurs qui sont les développeurs d'à côté parce que c'est le meilleur moyen de répondre et de ne pas bosser dans le vent et de ne pas faire des choses qui sont...

• Speaker #0

  Après on peut se permettre de le faire parce qu'on a à peu près 300 utilisateurs. C'est vrai qu'il faut avoir un échantillon statistique suffisamment important parce que sinon c'est plutôt répondre à des besoins d'individus un peu disparates. Là on arrive du coup à avoir des tendances en fait, on voit ce qui pourrait avoir de l'impact. Et donc c'est intéressant d'avoir cette... et puis surtout qu'on a un feedback immédiat. Ça c'est l'avantage d'avoir les utilisateurs sous la main, c'est super intéressant.

• Speaker #1

  Oui, tu n'as pas à courir après, tu peux les choper directement par le col. Du coup, c'est quoi les gros chantiers pour 2025, à ton avis ? Ceux que vous avez peut-être commencé, envisagé ?

• Speaker #0

  Alors, il y a des gros chantiers de fond sur la partie plateforme, parce qu'on utilise énormément Terraform pour bootstrapper les ressources cloud. Et on va progressivement basculer sur une approche contrôleurs avec crossplane notamment donc en gros terraform On pousse l'infra, crossplane, c'est la configuration YAML qu'on va pousser dans Kube, et c'est Kube qui va tirer l'infra dont il a besoin. C'est conceptuellement un peu différent, mais ça permet de gérer juste un déploiement Kube pour l'application et l'infra, et après tout se déploie tout seul. Donc ça c'est sur le papier, on n'a plus qu'à faire.

• Speaker #1

  C'est magique comme ça,

• Speaker #0

  c'est comme ça, c'est parfait. C'est un gros spasmo qu'on vient d'engager côté plateforme. On avait beaucoup de... Donc aujourd'hui, comme on a une database par client, sachant qu'il faut de la haute dispo, en fait, on a deux databases par client. Là, ça fait un millier de serveurs postgres. On est en train de complètement les basculer dans Kubernetes également. Pareil, avec une approche opérateur qui permet à Kubernetes de gérer le stockage de manière alignée avec le binaire postgres. Ça s'appelle CNPG. Donc ça, c'est un chantier qui est en cours, c'est un gros chantier, ça va nous permettre vraiment d'avoir une plateforme.

• Speaker #1

  C'est un truc qui existe déjà.

• Speaker #0

  Typiquement, on a le choix de ne pas développer nous-mêmes un contrôleur. On a regardé un peu ce qui existait. Zalendo, on avait fait un et il l'a open sourcé. On ne l'a pas retenu, on a pris Cloud Native PD parce que ça nous semblait être le projet open source qui avait le plus de perspectives d'avenir. Pour l'instant, il y a une courbe d'adoption qui est assez forte, on se dit qu'on ne s'est pas trompé, mais ça va nous permettre d'avoir une seule stack des postes en cube. À partir du moment où on sait déployer l'ensemble de notre stack dans cube, après c'est complètement portable. Ça peut être aussi bien sur un poste local avec un mini cube, sur Alicloud si on veut aller en Chine, ça permet vraiment de simplifier la paix,

• Speaker #2

  vraiment,

• Speaker #0

  quand on a plus de cubes. Donc ça c'est un chantier important, donc ça c'est vraiment sur la partie core platform. Sur la partie, on va dire plus purement développeur expérience, CI, CDI, on va continuer à investir sur notre portail de dev et donner du self-service. C'est des choses assez simples,

• Speaker #2

  mais c'est de la création.

• Speaker #0

  En fait, on va profiter de données. qui donnait une self-service mais c'est aussi mettre un peu de cadre. Typiquement aujourd'hui, les développeurs sont autonomes pour créer des topics Kafka mais ça passe par des PR dans du code Terraform. Donc on a essayé de faire en sorte que ce soit juste une ou deux lignes à tweaker. Ils ne savent pas trop ce qu'ils font mais ils y arrivent, ils arrivent à avoir une self-service pour avoir leur community. Ça fonctionne, ça remplit. on va dire, globalement le besoin. Le problème, c'est qu'on n'a pas de… Alors, les PR sont relues, mais on n'a pas suffisamment de garantie sur le respect des règles de nommage des topiques Kafka,

• Speaker #2

  par exemple.

• Speaker #0

  Et quand on a 3, 4, 500, ça devient n'importe quoi. Et du coup, l'avantage de mettre en place un formulaire de self-service, ça permet aussi de, finalement, comme tu le fais avec un linter, de mettre en place des règles de gouvernance un peu plus… technico-fonctionnel pour un peu mieux cadrer ce qui est déployé en production. Donc ça, c'est aussi un vrai avantage d'avoir un outil central. Il ne faut pas que ça devienne un frein non plus, encore une fois, il faut trouver la bonne balance entre vélocité et autonomie. Mais voilà, ça permet de cadrer un peu mieux les règles, c'est un peu pompeux, mais d'urbanisme ou d'empower-price architecture qui permettent de s'assurer que l'ensemble des équipes travaillent à peu près pareil. Du coup, quand tu mobilises des gens sur un problème, ils arrivent dans un environnement qu'ils maîtrisent déjà et ils vont pouvoir être le plus efficients pour débugger.

• Speaker #1

  Sur la partie Kafka, ça me fait penser à l'épisode 12 de Londra Pipeline avec Stéphane de Conductor, qui en fait résout exactement avec Conductor, je ne sais pas si tu les connais, ce problème de Kafka en fait. En gros, il expliquait que tu peux facilement te tirer une balle dans le pied. Les développeurs peuvent se tirer une balle dans le pied avec Kafka parce que... tu as beaucoup de contrôle qui est fait côté dev et pas côté Kafka finalement et que du coup eux bossent sur ce genre de solution de maîtrise de Kafka pour éviter ce genre de problème donc c'est un problème qui apparemment revient souvent donc si tu veux le pas de Victor je t'enverrai un lien je t'inviterai à jeter un oeil parce que c'est vraiment leur produit autour de Kafka c'est vraiment ça et ça rejoint du coup la problématique que tu décrivais donc ça c'est rigolo de voir qu'il y a souvent un lien entre les intervenants sur le podcast Cool, en tout cas c'est des beaux chantiers, et ce qui est assez marrant c'est de voir, comme tu parlais du tout début en fait, maintenant que vous allez, il y a vraiment une progression assez hallucinante pendant finalement 2 ans et demi, 3 ans, tu commences avec des scripts Bash et tu commences à atteindre des problématiques à haute valeur, plus haute valeur que de réécrire du Bash dans un autre langage, et ça devient plus intéressant, et du coup je pense à tes experts, ils doivent être plus contents au niveau challenge, c'est des sujets vachement intéressants et qui ont beaucoup de valeur, et finalement... à long terme pour le produit et tout le monde, mais tu as aussi beaucoup de valeur en interne sur aider tes développeurs.

• Speaker #2

  Je te l'ai perdu.

• Speaker #1

  Je suis là, je te vois. Tu m'as perdu ?

• Speaker #0

  Alors, c'est bon, c'est revenu ?

• Speaker #1

  ok ouais ouais non c'est pareil je t'ai pas perdu j'ai fait comme moi j'ai fait un off ok non bah nickel bah écoute moi j'ai plus d'autres questions j'ai l'impression qu'on a parlé de tout de CI2CD de vos projets etc est ce que tu penses qu'il y a un dernier point qu'on devrait aborder avant

• Speaker #0

  de conclure écoute non non c'est assez clair peut-être un point que j'ai pas assez assez développer donc ce portail de développement c'est un peu la partie émergée de l'iceberg. Il y a toute une plateforme derrière qui était en partie préexistante, d'autres parties qu'on a construites comme ce control plane. Et en fait pour moi, ça c'est une plateforme, c'est aussi une plateforme d'expérimentation dans le sens où A la fois on respecte les bonnes pratiques miracle de développement, mais aussi sur cette plateforme, comme on est sur l'intégration, on a repris vraiment les mêmes patterns que l'ensemble de nos produits. Si on veut tester une nouvelle techno, un nouveau type d'intégration, combat, etc. En fait là on a du coup un vrai écosystème qui est en prod avec des vrais utilisateurs qui va nous permettre d'expérimenter certaines pratiques. et du coup de faire une religion sur est-ce que c'est une bonne idée, c'est pas une bonne idée. Et en fait cette plateforme d'expérimentation apporte en tant que telle aussi de la valeur d'un point de vue de l'envoyer en vénérant parce qu'on est une espèce de bac à sable mais avec des vrais utilisateurs et ça c'est toujours, encore une fois,

• Speaker #2

  pour moi c'est un peu le plus important en fait.

• Speaker #0

  d'avoir du feedback d'utilisateurs en permanence pour être certain que ce qu'on fait a de l'impact. Et du coup, ce qui se voit, c'est le portail de dev, mais en gros, cette plateforme, dans sa globalité, apporte une valeur un peu aussi orthogonale qu'est la possibilité pour les équipes tech d'expérimenter des pratiques d'architecture, des nouvelles technos. des nouveaux types d'intégration. Voilà, ça, c'est un point important pour moi et c'est un peu un bénéfice secondaire, en fait, de ce qu'on a construit.

• Speaker #1

  Excellent. J'allais te poser la question de savoir si vous aviez un blog technique parce que quand tu me parles de tout ça, je me dis, il y a tellement de trucs intéressants que vous pourriez raconter. Et je vois que vous en avez un. Exactement. C'est un article.tech. Ça a l'air d'être votre blog technique. Il y a quelques articles, effectivement. Parce que je me dis, vous avez tellement de trucs à raconter autour de tout ça. Il y a quelques articles sur le site.

• Speaker #0

  Oui, on sort quelques articles par mois. Et c'est partagé effectivement entre le produit, le design et l'engineering. Des fois, des sujets un peu transverses. Donc, on essaie d'aborder différentes parties de la tech. J'ai fait un article spécifique sur la naissance de notre portail de dev justement, donc si vous êtes intéressés par cette approche, il y a un article détaillé.

• Speaker #1

  C'est ce que je vois. Je me suis abonné, donc vous avez un nouveau lecteur, ce sera moi. Voilà, top. Merci beaucoup Romain, c'était excellent. Moi j'ai appris plein de choses, je trouve que vous avez une approche absolument géniale de développeur d'expérience finalement en interne. Il y a beaucoup de trucs à apprendre et c'est super de voir la taille où vous êtes et tout le chemin parcouru, ce qu'il vous reste à faire. Merci. Félicitations. Ça a l'air bien.

• Speaker #0

  En tout cas, moi, je m'éclate. Je n'ai pas l'impression d'être le seul à m'éclater.

• Speaker #1

  Ça se voit.

• Speaker #0

  Évidemment, tout le monde est en recrute.

• Speaker #1

  Tout le monde est en recrute chez Miracle. Yes, c'est vrai. Petite précision, ça a l'air cool. Donc, si vous voulez chez Miracle, n'hésitez pas. On mettra les liens dans la description du podcast, donc il n'y a pas de soucis.

• Speaker #0

  Merci beaucoup pour cet épisode, ça a été vraiment sympa.