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 vous voulez comprendre les coulisses de ce monde fascinant, vous êtes au bon endroit. Alors, mettez votre CI 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. Eh bien bonjour à tous et bienvenue dans un nouvel épisode de Nom d'un Pipeline, votre podcast favori pour parler de CI-CD. Et aujourd'hui je suis avec Tim, Tim Pétricola. Bienvenue Tim.

• Speaker #1

  Salut, merci.

• Speaker #0

  Alors Tim, il est probable que les gens qui nous écoutent ne te connaissent pas encore malheureusement. Bien fait pour eux. Est-ce que tu peux te présenter, rapidement nous dire qui tu es, quel est ton parcours, d'où tu viens, ce que tu aimes dans la vie et tout ?

• Speaker #1

  Oui bien sûr, moi c'est Tim, enchanté. Je travaille aujourd'hui en tant qu'ingénieur chez Alan, une boîte, une startup, une scale-up d'abord d'assurance mais de santé de manière un peu plus générale. Mon parcours, ça doit faire une quinzaine d'années que je fais du dev, vraiment à... plein temps à la base je suis plutôt en dev qui vient du monde enfin qui a appris sur plutôt du rubis et du rail j'ai pas mal évolué par la suite j'ai commencé vraiment chez différentes start up mais la plus grosse expérience c'était chez dry vie guetta un start up de car sharing qui existe encore où c'est là où je suis vraiment arrivé où j'ai vraiment grandi je me suis dit doucement réorienté dans dev full stack sur du sur du race pour aller plutôt vers du front end parce que je me rends compte que le gap entre l'ui et le dev est quelque chose qui m'intéresse énormément et par la suite je suis parti je suis parti de chez drivey en 2019 pour passer CTO d'une petite boîte qu'un ami avait monté qui était qui s'appelait jour qui était une app de journal intime vraiment basé enfin pour iphone vraiment basé sur se focus sur la santé mentale, aider les gens qui ont besoin d'accompagnement, mais que ce soit des dépressifs chroniques ou monsieur tout le monde qui peut bénéficier de prendre des notes régulièrement et qui a un peu un syndrome de la page blanche. Et cette boîte a été rachetée en fait par Alan en 2021. Donc c'est comme ça que je suis arrivé chez Alan, parce qu'Alan s'est énormément intéressé à la santé mentale. On est persuadé en fait que c'est un des énormes... point clé et qu'en France on n'est pas vraiment en avance sur le sujet, ça peut rester un peu tabou par moment donc il y a beaucoup de choses à faire. Et donc l'idée était de prendre un peu cette expertise de santé mentale qu'on avait créée chez JOUR et de la ramener au sein d'Alan et de voir ce qu'il y avait à faire. Et donc par la suite c'est devenu une offre d'Alan que pas mal d'entreprises ont, enfin maintenant on la propose vraiment à toutes les entreprises, qui s'appelle Alan Mind et qui est vraiment de l'accompagnement avec des sessions avec des thérapeutes vraiment en visio. et aussi différents parcours dans la Palane pour aider sur différents programmes autour de la santé, soit de la santé mentale, mais aussi plutôt de la prévention. Donc ça a dérivé un petit peu pour tout ce qui est prévention, même de mal de dos et tout, parce qu'on n'est pas juste une mutuelle qui est là pour aider, rembourser. En fait, si on peut prendre soin de la santé de nos membres, c'est bien mieux. Et en fait, au final, ça coûte moins cher à soigner par la suite. Donc voilà, et depuis que je suis chez Alan, j'ai pas mal changé. Donc là, j'ai continué à bosser sur ce produit pendant un petit bout de temps. Et là, ça doit faire bientôt deux ans que j'ai changé pour me focus totalement sur améliorer les outils pour les ingénieurs chez Alan. Donc aujourd'hui, on est à peu près une centaine d'ingénieurs dans la boîte. Et mon taf, c'est de bosser sur la developer experience avec un scope assez large, ça va de l'infra jusqu'au design system. Donc vraiment, ça prend... tout le panel d'expertise qu'on veut et on est une petite équipe à faire ça donc avec des sujets très variés et très intéressants notamment au niveau De tout ce qui est infra, backline, CI et ainsi de suite

• Speaker #0

  Mais c'est cool non c'est je réfléchissais à tout ce que tu disais et c'est ouais un truc assez cool sur Alan que tu as bien dit et je me suis rendu compte compte il ya quelques années en devant ses clients et c'est que c'est vraiment pas une mutuelle ou une complémentaire santé au sens où l'on l'entendent habituellement et comme tu l'as bien dit il ya vraiment une mission chez alan je dis je digresse complètement désolé mais il ya vraiment une mission chez alan de traiter la santé de manière autrement d'un peu le genre vous n'êtes pas ils sont pas juste venu en disant on va faire une complémentaire santé plus moderne avec une app iphone et voilà c'est vraiment le genre de gérer la santé et à l'aspect complémentaire qui est forcément nécessaire parce que tu dois rembourser des soins mais c'est pas ça en fait le but le but d'Alan c'est pas ça quoi c'est assez assez marrant parce que les gens voient vraiment les trucs comme le produit comme étant une complémentaire souvent parce que c'est ce que tu cherches sur le marché mais en fait c'est une sorte de de pas de côté en disant oui mais c'est on fait ça mais c'est pas vraiment ça le but et c'est cool parce que comme tu dis la prévention est plus intéressante etc etc et c'est vachement bien

• Speaker #1

  La complémentaire en fait c'est un peu le point d'entrée pour Alan. Alan est une entreprise de santé en fait et non une assurance. Et par contre on est arrivé sur le marché via l'assurance où il y avait vraiment une opportunité de changer les choses parce qu'on était face à des acteurs prévieux. Et maintenant en fait ça laisse la porte ouverte à plein d'autres choses super intéressantes effectivement.

• Speaker #0

  C'est cool. Du coup une boîte où il y a pas mal de trucs en pleine croissance depuis des années. Donc j'imagine tous les challenges que ça a techniquement. Je rebranche sur le côté technique très rapidement. Et ouais, d'un coup, t'es venu du rubis, donc t'aurais même pu finir chez Doctolib assez facilement, avec plein de rubis. T'aurais été dans le même domaine de la santé aussi, mais du coup, Alan, ok.

• Speaker #1

  C'était assez naturel en fait, c'est vraiment Alan, c'est vraiment parce que il y avait vraiment eu un fit avec la boîte que j'ai bossé avant, donc c'est pour ça que je suis ici. Et après, le côté culturel d'Alan est aussi super intéressant, on pourrait encore en parler pendant une heure de ça, mais c'est encore... Le sujet n'est pas vraiment le sujet dur.

• Speaker #0

  Et du coup, tu disais un truc intéressant, une centaine d'ingénieurs, etc. Toi, tu es dans une équipe qui est transverse, où tu vas du CIE au design system. Alors, tu m'expliques comment ça se passe, parce que je n'ai jamais vu une organisation comme ça. Et en général, les gens sont quand même… Plus la boîte grossit, plus les gens sont spécialisés. Mais tu as l'air de dire qu'en fait, finalement, tu es une équipe qui n'est pas si spécialisée que ça. Dans une startup de quatre personnes, ce que tu dis, c'est normal. On est bien sûr que tu fais tout. Et tu fais aussi la bouffe le midi. pour tes collègues. Mais du coup, dans une boîte qui est un peu plus grosse, en général, c'est quand même assez rare. Du coup, c'est comment au niveau Orga, dans ton équipe, le CI, tous ces trucs-là, ça se passe comment ?

• Speaker #1

  C'est vrai que c'est assez particulier. En fait, Alan fonctionne énormément sur un concept qu'on appelle le Distributed Ownership, où l'idée, c'est qu'on ne crée pas vraiment une équipe qui a forcément un ownership fort, avec une expertise forte sur le long run. et il y a des sujets n'importe qui peut le prendre et le faire un peu à côté de ces sujets de business de tous les jours et donc ça ça a pas mal d'impact typiquement on a fini par créer en fait on a une équipe qui a cette transverse donc et c'est un peu la seule qui va de pouvoir soutenir tous les autres projets de manière diverses et variées l'organisation est assez compliqué du coup parce que effectivement tu dois un peu faire de tout avec besoin de beaucoup d'expertise différente jusqu'à pas très longtemps on était en plus que quatre dans cette équipe en fait à gérer tout ce scope là et maintenant on a doublé sur 2024 donc c'est un peu plus simple mais au niveau de ce qui est de prioriser donc entre bosser sur l'infra ou sur les ANCEM pour te prendre un peu les deux opposés de notre scope c'est un peu à notre bon vouloir et à ce qu'on considère étant le plus important c'est énormément de discussions avec tous les autres ingénieurs de la boîte se mettre en accord avec la stratégie de la boîte aussi c'est quoi dans le futur, à quoi est-ce qu'on s'attend au niveau scale parce que ça va un peu informer sur quoi tu vas vouloir bosser et après on a réussi à avoir un peu quelques membres de corps à cette équipe qu'aux une expertise forte. Typiquement moi mon expertise c'est pas du tout l'infra à la base comme tu l'as entendu mon parcours je suis plus full stack, il y a des dérivés justement sur la partie front-end des mobiles et on a un autre l'autre ingé qui lui ou son expertise est plutôt l'infra et le back-end donc en fait on est très complémentaire avec ça et après tous les quarters, suivant un peu les sujets, on va recruter un peu différentes personnes, il y a des gens qui vont peut-être venir et repartir de l'équipe plus tard pour bosser sur un sujet et passer à quelque chose d'autre. Effectivement, l'année dernière, on a migré nos apps mobiles qui sont sur Durac Native, on les a migrées sur un framework qui s'appelle Expo, on a un ingé qui nous a rejoint pour deux quarters pour nous aider sur ce sujet-là, et il est reparti faire autre chose après dans une autre équipe. Donc ça donne vraiment l'occasion de créer des équipes qui sont assez short-term. suivant les besoins, suivant les projets qu'on considère avoir le plus gros ROI à l'instant. Et typiquement, on est passé du coq à l'âne, genre en fin d'année dernière, on a bossé sur une refonte du design system, donc très, très, très front-end. En parallèle, on faisait quelques autres choses, parce que comme tu t'en doutes, il y a beaucoup de run dans ce genre d'équipe. Quand tu as de l'infra, déjà, forcément du run. Et là, en Q1, on a bossé par exemple sur... sur migrer de Deadwood Let's Beanstalk à Kovri et Kubernetes. Donc on a l'opposé sur un truc totalement infra et on a tous pu contribuer aux différentes parties en fait. Ça veut dire que moi j'ai fait de l'infra, j'ai migré sur du Kovri alors que franchement je ne connais rien du tout en Kubernetes. Mais tu es bien accompagné, tu es bien mentoré, tu as quelqu'un qui est forcément expert sur le sujet qui va t'aider à monter en compétences. et après en parallèle, c'était pas mon focus à temps plein de faire du cover, c'était plus l'idée ok je monte en compétence sur le sujet, ça va me permettre aussi à terme d'être quelqu'un de plus qui est onboardé et qui va pouvoir faire du support de notre infra, même si je suis amené par exemple à rebouger dans une équipe très produite, j'aurai une connaissance en même temps de notre infra et ça me permettra de débuguer et ça permet de ne pas se reposer que sur deux trois personnes dans une équipe et en fait qui se prennent eux toute la charge, ça fait que on essaye de faire monter en compétence. niveau on veut pas que tout le monde devienne expert tu as l'idée vraiment en fait on va viser un peu des profils t-shaped donc vraiment qui sont généralistes mais avec une petite éventuellement expertise quelque part et donc ce truc là permet vraiment vraiment de faire ça et sur comment encore une fois tu priorises c'est on a un peu tendance à le faire aussi au feeling c'est à dire que on considère que là maintenant c'est le moment de changer notre infra par exemple ok bah pourquoi déjà on considère ça mais tu vas pas forcément le comparer en bah oui mais est-ce que vraiment l'effort et l'appétit a plus de sens que de changer le design system en fait c'est des sujets qui ne sont pas comparables parce que tu n'as aucune métrique commune entre les deux à part peut-être faire un NPS au niveau de tes équipes de lèvres mais c'est pas vraiment super révélateur parce qu'en plus c'est pas les mêmes personnes qui vont être impactées Et c'est plus, on priorise, on essaye d'estimer nous ce qu'on en pense, et on se dit, ok, on a passé un quart d'heure sur plus de l'infra, le prochain quart d'heure, on pourra peut-être arriver à repasser sur notre partie sur laquelle on a mis un peu moins d'amour récemment. Mais c'est intéressant, et on est encore en train de chercher exactement notre approche, quel est notre framework et notre process pour prioriser tout ça, et ça reste un peu arbitraire au final.

• Speaker #0

  Est-ce que j'allais dire, en fait, que pour moi, quand je dis tout ça, je trouve ça assez cool. cool de fonctionner comme ça, mais je me pose plein de questions au niveau organisation. Comment tu arrives déjà, d'un point de vue concrètement, à attraper des gens pour les ramener dans un effort pendant deux quarters ? La plupart des organisations que tu vois sont quand même assez figées, ont un titre, tu as des équipes, tu as un manager, tu as un lead, c'est très figé, donc les mouvements ne sont pas aussi fluides que tu le décris. Tu ne peux pas piquer des gens, tu peux piquer des gens pendant deux trimestres, mais c'est très bizarre, tu vois, il y a ce côté où ce n'est pas des... Les gens ne vont pas builder leur organisation en général qui ressemble à un arbre plus ou moins hiérarchique. Et du coup, tu as des questions de budget quand c'est des grosses boîtes, de gestion de machins. Tu ne payes pas les ressources à Paul pour un billet Jacques. Du coup, comment tu fais pour arriver à ce... Je pense que c'est un mindset que tu fais depuis longtemps dans la boîte. Et comme tu dis, c'est la culture chez Alan de pouvoir faire ça. Mais même d'un point de vue concrètement, d'un point de vue management, comment tu fais pour avoir des gens qui changent de... boulot, tu fais une dissociation entre le manager dans une équipe et en fait la part de boss dans une autre. Et c'est ça en fait pour arriver à ce genre de truc ?

• Speaker #1

  Totalement. Alors déjà, on n'a pas un management, on n'a pas un côté très hiérarchique chez Alain. Et ça, c'est l'ensemble de la boîte. C'est vraiment un truc culturel. C'est-à-dire que tu n'as pas de manager. Déjà, c'est simple, tu n'as pas de manager. Tu vas avoir un lead dans ton équipe, mais qui est vraiment là pour le côté opérationnel au final. Et tu vas avoir un coach qui est plus là pour le côté… t'aider à grandir en tant qu'employé, en tant qu'ingénieur, s'assurer que tu te sens bien, que tu n'es pas en train de te mettre dans le rouge, que tu as des bonnes priorités, que tu n'es pas en train de t'ennuyer, tout ça en fait, vraiment c'est un rôle de coach. Mais il n'y a personne, tu n'as pas un manager qui va te dire quoi faire, tu n'as pas un manager qui va gérer tes augmentes, tu n'as pas tout ça. Donc en fait déjà quand tu dis, et le côté RH de ça en fait il est très distribué pour le coup, c'est un process où... Tu as des reviews tous les six mois, tu vas demander à différents collègues des reviews sur certains points. Et c'est comme ça qu'on va arriver à juger, est-ce que cette personne doit changer de niveau ou pas ? Et en fait, une fois que tu décorèles ces trois choses, c'est vachement plus simple d'avoir de la mobilité. Parce que tu changes d'équipe, ouais, fine, tu n'es pas obligé de changer de manager, tu n'as pas de manager. C'est juste que tu vas dans une équipe où le lead sur ce sujet-là, c'est quelqu'un d'autre parce que c'est lui qui a l'expertise ou c'est lui qui a potentiellement fait le framing de cette migration ou autre chose. Et ça devient beaucoup plus simple. Ensuite, ce qu'on peut voir, c'est qu'on est une organisation, chez les ingénieurs chez Alan, même au niveau du recrutement, on ne recrute pas pour un poste. On recrute des développeurs full-tac pour être ingénieur chez Alan. On ne te recrute pas pour que tu ailles faire de l'infra chez Alan. On ne te recrute pas pour que tu ailles faire du mobile ou du produit d'assurance. On ne te recrute pas pour tout ça. On te recrute pour être ingénieur chez Alan. Et un truc, c'est... Tu ne sais pas encore où tu vas bosser quand tu arrives. Ce que tu vas faire, c'est que tu vas aller faire une semaine ou deux dans plusieurs équipes au moment de ton arrivée. Et au bout de six semaines à peu près, on va regarder, OK, toi, qu'est-ce qui t'intéresse le plus ? Et où est-ce qu'il y a de l'appétit vraiment ? Dans quelle équipe on a besoin de personnes ? Ou s'il n'y en a pas une qui sort plus du lot en termes de stratégie, dans lesquelles ils ont de la place pour t'accueillir et ça t'intéresse. C'est vraiment comme ça que ça se passe. Et on va t'encourager à bouger tous les un an et demi. On veut qu'il y ait ce mouvement aujourd'hui parce qu'on considère que c'est comme ça aussi que tu challenges tout ce qui se passe. Tu as un oeil nouveau et tu fais un peu de ça. Mais il faut aussi faire gaffe à trouver ta balance, à ne pas que tu aies la friction de devoir t'unborder toutes les trois semaines sur un nouveau projet et de rien comprendre. Et en fait, au final, que des juniors en termes d'expérience sur telle couche, alors qu'il y a quand même une connaissance métier et une connaissance technique qui peut être assez forte par endroit. Mais c'est vraiment très culturel ce truc-là. Et donc en fait, nous c'est assez facile. Je te prends l'exemple du dev qu'on avait recruté pour migrer à l'Expo. C'est quelqu'un qui adore le mobile, qui bossait sur des gros produits, qui avait parfois des frustrations parce qu'il considérait qu'on pourrait avoir une stack qui était plus intéressante, qui permettait d'avoir moins de friction, d'avoir plus de velocité. Le jour où j'ai commencé à dire Ok, moi je pense qu'il faut qu'on aille vers l'Expo, est-ce que ça peut intéresser quelqu'un de venir ? J'avais déjà en tête qu'il y aurait cette personne-là évidemment. Et en fait, ce qu'on a fait, c'est qu'il a fait moi, je suis chaud On a regardé dans l'équipe où il était. OK, ça veut dire qu'il y a une place qui se libère. Il faudrait trouver quelqu'un d'autre. Mais est-ce qu'il y a moyen de faire un micmac pour qu'avec tout ce mouvement, on arrive à le remplacer pour que cette équipe ne soit pas au chômage technique parce qu'ils n'ont pas d'ingénieur pendant un quart d'heure ? Et en fait, ça a très bien marché. Mais ça fait que tous les six mois, tu as un truc de staffing où tu réorganises un peu, tu trouves la bonne combinaison entre répondre à ceux qui veulent bouger, ceux qui veulent rester. t'assurer qu'on garde la sinérité dans chaque équipe mais t'assurer qu'il y a un minimum de 109 aussi et en fait ça marche pas mal, après ceux qui s'occupent de faire ce mix and match d'ingénieurs et c'est un peu intense au moment où tu fais des changements d'équipe parce qu'il faut un peu réorganiser toute ta communauté d'ingénieurs au final mais ça marche plutôt pas mal ok,

• Speaker #0

  c'est top je pense que c'est un super système le fait que vous décorriez bien entre le côté coach, le côté manager pas lead technique, coach, le côté un peu RH etc et même le faire dans le mode peer review etc je pense que c'est assez smart et ça résout une grosse partie du problème d'avoir des organisations qui sont figées en fait sinon où tu peux, enfin changer de manager c'est compliqué et tout devient très compliqué et du coup tu fais rien et tu restes, et surtout qu'en fait tu as souvent chez les ingénieurs une sorte de frustration qui peut s'installer comme tu disais où t'es pas toi assez challengé tu peux pas non plus challenger des nouveaux trucs parce que t'as pas de regard et en fait tu finis par en général te barrer de la boîte et que tu aies un turnover de 3 ans parce que au bout de 3 ans les gens en ont marre et change carrément de boîte parce qu'il ne s'arrive pas à avoir de mobilité en interne parce que tout est trop compliqué.

• Speaker #1

  Exactement, tu vois, moi je suis passé d'un truc très produit parce que je faisais, je continuais à bosser sur de l'engineering, mais enfin sur des fonctionnalités dans notre app pour nos membres quand je suis arrivé chez Alan et du jour au lendemain, j'ai totalement changé et depuis que je suis dans cette... dans cette équipe, j'ai revu le design system, j'ai fait des grosses migrations d'infras, j'ai fait des sujets ultra variés et en fait ce qui fait que je suis challengé continuellement techniquement mais parce que j'en ai envie. Si je voulais me renfermer sur un sujet un peu plus pendant un bout de temps parce que ce n'est pas le moment pour moi, je n'ai pas trop l'énergie de, je peux aussi en fait ça donne énormément de liberté sur ce truc-là.

• Speaker #0

  C'est cool. Merci beaucoup. Du coup, toi tu parlais justement de projet etc, comment ça marche, tu m'en parlais des projets que vous avez fait niveau CI etc, parce que je sais que vous avez fait des trucs assez costauds ces derniers temps, mais ça ressemble à quoi la pipeline de CI-CD chez Alan, gros smile ?

• Speaker #1

  C'est assez simple, déjà on bosse sur un seul monorepo depuis, ça doit faire 6 mois qu'on a bougé, on avait plusieurs repos qu'on a bougé en un seul, on en avait un pour le backend, un pour le frontend, un pour l'infra, et quelques autres à côté avant. on a tout mergé en entrant le monorepos en disant qu'on aurait une code base plus simple à gérer et donc aujourd'hui ce qui se passe c'est assez simple tu pushes sur github enfin tout est sur github tu pushes quand tu merges sur main on a pas de j'ai perdu le mot alors que tu es l'expert du sujet mais on a pas de pas

• Speaker #0

  de mercs queue tu veux dire ?

• Speaker #1

  merci ok bien sur pas encore en tout cas on a pas encore de mercs queue alors ouais je pense que ce sera un des prochains sujets sur notre CI Pour l'instant on n'a pas de Verge Crew c'est quand ta paire est verte, que tous les tests sont passés, tu peux merger. Et ça arrive sur main. Quand tu es sur main, on va regarder, faire un diff, regarder suivant ce qui a été pushé comme code, si on doit déployer telle app front-end, telle app back-end ou ça. On doit avoir une quarantaine d'app différentes qu'on déploie à peu près je dirais.

• Speaker #0

  Ton diff, c'est un truc que tu fais à la main ou tu as un tooling pour faire ça ? Vous avez un truc maison ?

• Speaker #1

  Alors, pour ce qui est back-end, on le fait, c'est simple, on se base sur les répertoires changés. Très basique. Pour ce qui est front-end, on fait un diff vraiment avec Git et on regarde les packages Yarn qui ont été changés. Donc, on retrouve nos front-end sur Yarn. Ce qui donne un peu plus de granularité et permet d'avoir un peu une meilleure gestion de tes dépendances.

• Speaker #0

  Mais c'est maison, ce n'est pas un outil particulier ?

• Speaker #1

  Maison, non.

• Speaker #0

  Il n'y a pas d'outil pour ça, mais je pose la question.

• Speaker #1

  Il y en a, tu as des tools qui gèrent pas mal, soit NX, soit Rush. Pour les monorepo, oui. Pour les monorepo, en fait, ils peuvent faire ça aussi. Aujourd'hui, nous, on ne le fait pas. Ce qu'on fait, c'est qu'en gros, pour chaque app, on récupère quelle est la version qui est aujourd'hui déployée en staging. On regarde le diff, est-ce qu'il y a une différence entre cette version et le dernier commit. Et s'il y en a, on déploie. Si on n'a pas, on ne déploie pas. Et l'intérêt est purement juste des coûts, d'éviter de run du CI et des déploiements pour rien. C'est juste ça. Et donc tout ça, ça arrive en staging. Et après, on déploie notre staging en prod, pareil, de manière automatisée, mais on le fait, je crois, aujourd'hui quatre fois par jour. C'est des jobs qui sont calculés juste pour prendre la version qui est en staging de chaque app et qui la met en prod. Et on laisse aussi les ingés, bien entendu, déployer quand ils veulent de staging à prod à la main s'ils ont besoin. si ça ne calcule pas la schedule, il n'y a aucun souci là-dessus. Donc, c'est très simple et ça fonctionne pas mal. Là, on vient mettre d'autres trucs en place, typiquement pour t'aider à tester, d'avoir sur TPR, on déploie tous tes environnements front-end sur des environnements éphémères, histoire que tu puisses avoir encore plus de confiance avant de merger, ce genre de choses. Mais voilà, on reste sur un truc assez… En fait, on veut rester sur des choses simples, globalement, chez HAN, et on a eu de ce qu'on a fait.

• Speaker #0

  Du coup tes pipelines de tests, si t'as pas de tooling pour gérer ton monorepo, tu fais comment pour lancer tes boucliers en CIF, ce genre de choses ?

• Speaker #1

  Bah en fait c'est pareil, en gros on va se baser sur est-ce que tu dois lancer des trucs frontend ou backend, tu vas le faire sur les fichiers, est-ce que le dossier frontend ou le dossier backend ont été changés, très simple, très basique. Et après dedans on lance tout en fait, pour faire simple, la plupart du temps. Tout ce qui est frontend, on va lancer tous les tests frontend, tout le linting frontend, tout type script, tout ce qui est backend. on va lancer pareil tout ce qui est rapide à lancer en fait on va tout lancer et typiquement le inting et tout c'est super rapide maintenant donc ça surtout on s'embête pas sur les tests ce qui est notre truc qui prend le plus de temps aujourd'hui nos tests backend là on fait un peu de on se base on a du tooling un peu à la main qui check en fait les dépendances en python sur notre backend qui va checker en fait les imports et qui va définir un peu quels sont les tests utilisés ou non et essayer de lancer que ces tests là sur les pull requests par contre une fois que tu es sur main on lance tout moins de risques,

• Speaker #0

  on lance tout et ça marche. Oui, ce qui n'est pas plus mal en fait. Tu n'as pas de déploiement derrière.

• Speaker #1

  En fait, d'autant plus quand tu n'as pas de merchsku. Tu évites le risque, tu fais un truc qui soit incompatible avec quelqu'un d'autre et au final tu te retrouves avec un main qui est tout le temps rouge. C'est ça.

• Speaker #0

  Du coup, s'il est rouge, il faut quand même que tu résoudes le problème. Tu ne donnes pas un truc cassé. C'est cool. Tu parlais des environnements éphémères, etc. C'était partie du projet dont tu parlais avec du cube, du covery, tout ça.

• Speaker #1

  Alors pas totalement parce qu'on le fait que sur le content aujourd'hui. Donc en gros ce qui se passe, pour ça il faut que je donne un peu de contexte sur notre infra, jusqu'à il y a quelques mois on avait toutes nos apps qui étaient des images Docker qu'on buildait sur notre CI et qu'on déployait sur AWS Beanstalk. On est passé à Beanstalk il y a un peu plus de deux ans, on était chez Heroku avant mais pour des raisons de pricing principalement on est parti d'Heroku.

• Speaker #0

  C'est bon on est chez Heroku donc ça m'intéresse de savoir où est-ce qu'il faut aller après.

• Speaker #1

  Alors pas chez Beanstalk.

• Speaker #0

  Ok d'accord Justement

• Speaker #1

  Voilà Nous on a fait ça Ça marchait L'idée était d'avoir Un truc un peu le plus bas niveau Où on gère vraiment nos coûts Du coup Mais aussi on peut rebuilder Un peu l'expérience qu'on veut Dessus La réalité c'est que Minso qui est un produit d'AWS Qui est plus vraiment maintenu AWS c'est un truc très positif Qui est qu'il ne tue jamais Leurs produits Contrairement à Google Mais le revers de la médaille C'est que Quand c'est plus leur préau C'est vraiment plus leur préau Et tu vois que l'outil On arrivait très vite à ses limites Notamment on avait des temps de déploiement même après avoir tout optimisé qui parfois variait de 20 minutes à 40 minutes. Ça nous est arrivé de pouvoir déployer un environnement pendant 3 jours et AWS nous a dit bah effectivement ça vient de nous, c'est de notre faute mais on ne sait pas trop vous dire pourquoi. Et en fait c'est le genre de signaux où on est en mode bon ok il faut peut-être qu'on change le tableau. Et on avait testé Covry en fait c'est intéressant, enfin je sais que tu as eu, tu as fait Covry dans ton podcast, c'était remarquable. On avait testé Covry il y a quelques années au moment de ce switch à Beanstalk et on trouvait que leur produit était très prometteur mais un petit peu jeune à l'époque. Et donc là on a refait un benchmark de différents produits et au début d'année à 2024 on a fait le switch de Beanstalk à Covry. donc sur du Kubernetes derrière, mais pareil pour éviter d'avoir besoin de trop d'experts sur du cube, en fait c'est pour ça qu'on a mis Kovri entre nous et cube, ce qui permet d'avoir quelques personnes qui ont quand même besoin de comprendre ce qui se passe derrière, parce qu'en fait surtout Kovri en fait l'air de rien reste assez jeune, et il y a beaucoup de moments où tu as besoin de savoir comprendre ce qui se passe, et en fait de leur demander aussi d'éditer des choses dans leurs produits pour répondre à nos besoins, mais ça s'implique énormément, en fait la plupart de notre équipe n'a pas besoin de savoir comment fonctionne du Kubernetes et réagir avec, donc c'est assez cool. Et par contre on a aussi pris une décision au moment de passer à Kovri qui est pour tout ce qui est front-end, parce qu'en fait on a que des apps qui sont indépendantes, qui sont des single page apps, on s'est dit on va les déployer sur quelque chose de beaucoup plus adapté, donc on est parti vers le Cloudflare Pages qui est du serverless Edge, on appelle ça comme on veut mais qui n'est pas sur du Node, qui est sur un runtime qui appartient à Cloudflare, qui est basé sur V8 aussi. Et pour plusieurs raisons, ça c'est que 1 c'est beaucoup plus rapide ce qu'en fait tu déploies juste des aspects de plus des assets et c'est bon ils sont sur un cdn ils sont utilisables final donc pas besoin de building image de coeur pas besoin de tout ça tu en théorie tu vas pouvoir le déployer en fait proche de tes utilisateurs parce que bon aujourd'hui on est principalement nos membres sont principalement en france mais on ouvre d'autres pays et du coup en fait c'est cool d'avoir ton fontaine qui est servie depuis un CDN au final, qui va être proche de son serveur final, tu gagnes un petit peu en latence. Mais aussi en termes de coût, parce qu'en fait, une fois que tu n'as pas un serveur qui run à long terme, c'est beaucoup moins cher au final pour notre usage. Parce qu'on n'a pas 12 millions de requêtes par minute, c'est beaucoup moins cher. Et ça nous permettait justement d'aller vers des environnements éphémères, mais vraiment super simples à mettre en place, parce que c'est un truc qui est géré nativement par CloudFair. Il n'y a rien de plus à faire. Ça arrive sur des environnements qui sont très... proche de nos environnements de staging, ils tapent même sur les backends et les API de staging, donc c'est vraiment très très proche, c'est aussi hébergé sur le même infra et ça marche assez bien quoi. Et ce qui fait que depuis n'importe quel PR en moins de cinq minutes, tu as toutes tes app frontend qui sont déployées sur une URL que tu peux tester, que tu peux partager avec tes designers ton produit et ça marche assez bien.

• Speaker #0

  Ok, cool, je sais qu'on utilise le cycle de fer en interne pour ça, c'est super cool, ça marche très bien, ça résout exactement le problème que tu décris de déploiement de gestion de CDM même si bon après selon le peut-être à une plus grande échelle que nous donc c'est plus un problème pour vous que pour nous mais bon c'est sûr que t'es au moins tranquille et que c'est un truc spécialisé plutôt qu'avoir un flash qui est quand même y'a pas ce pot de valeur. C'est comme au début déployer sur un container du front etc mais ça rend pas de sens quoi.

• Speaker #1

  Bah on l'a fait, nous toute l'époque on était sur Beanstalk, à un moment ça m'énervait de pas pouvoir déployer un environnement frontend en fait n'importe où sur n'importe quel PR et on a utilisé enfin on l'a utilisé pendant presque un an en fait on avait setup fly pour déployer des images Docker. Donc en fait on buildait l'image Docker au lieu d'aller sur Beanstalk où c'est super dur de créer un environnement dédié à la volée ou via l'API ou autre. En fait on le faisait sur Fly. Mais ce qui fait que tu introduis encore un autre outil, une autre sorte de partie dans ton infra. Tu as forcément des discrepancies parce que c'est pas la même infra tout simplement. Et c'est pas idéal. Et en déploiement on mettait de notre app front-end qu'on teste le plus sur ces review apps, elle mettait 25 minutes à être déployée. Et aujourd'hui, depuis qu'on est sur Pages, elle en met moins de 5. Donc, c'est vraiment... La cloupe en tant qu'Eng, elle est imparable.

• Speaker #0

  C'est ça qui est important, c'est que tu veux que tes tests soient assez rapides pour que les ingénieurs puissent dire ça marche, ça marche pas, et passer à autre chose, et pas attendre 25 minutes, revenir à autre chose, changer de contexte. Ça, c'est vraiment l'enfer. À niveau développeur experience, c'est un peu une partie des trucs assez en noir où tout le monde est frustré.

• Speaker #1

  Clairement, les temps de CI et les temps de déploiement nous c'est un des trucs qui nous frustrait le plus dans le passé et où on est très content justement de toutes ces évolutions parce que ça a énormément changé récemment et ça fait du bien, ça se ressent.

• Speaker #0

  Ouais j'imagine. Et du coup vous aviez aussi changé de système de CI, c'est un projet que tu as géré avec une équipe transverse ?

• Speaker #1

  Ouais alors, ouais exactement. Donc ça c'est un... Historiquement on a toujours été chez CircleCI pour notre CI et CDI. et Circle, qui est très bien, c'est vraiment un outil que j'utilise dans mes boîtes précédentes aussi, qui est vraiment bien. Et là, en fait, on a des contrats à l'année, forcément, parce qu'on a quand même des gros volumes.

• Speaker #0

  et cette année on s'est un peu rendu compte que déjà c'est cher, quand tu payes ton contrat à chaque fois la facture fait un peu mal, tu es en ordre de grandeur, tu es sur quelques centaines de milliers par an, donc ce n'est pas négligeable. Et là on s'est rendu compte qu'avec différents changements qu'on a fait, notamment passer sur un monorepo, on a perdu certaines optimisations de CI parce qu'on ne nous a pas remis tout ça en place, nos coûts ont vraiment trop grossi et on s'est dit en milieu de contrat, est-ce qu'il ne faudrait pas juste réexplorer une alternative ? Donc c'était d'abord pour des coûts mais aussi pour une question de DX parce que sur la developer experience, avoir un énorme monorepo sur SQL-CI c'est pas évident à gérer. En gros si tu veux tu as un gros fichier de config YML, oui tu peux le splitter ou avoir une étape en premier qui va build ce fichier et tout, mais en fait ça reste, tu dois continuer à bosser avec un énorme fichier YML qui gère toutes tes pipelines, qui gère vraiment tout et c'est pas évident. et donc on a fait une explot en tout début d'année en termes de timing on a regardé combien de temps il nous restait sur nos contrats avant de devoir réacheter des crédits avant la fin de notre année on s'est dit mais en fait c'est le moment de changer en termes de developer experience il y a mieux en termes de coûts on estime que ce sera mieux ailleurs et donc on va faire ça et donc en benchmarkant un peu on a surtout regardé du côté de GitHub Actions parce qu'on sait que leur offre de CI a quand même beaucoup évolué ces dernières années qu'on utilise déjà GitHub, donc c'est toujours pareil, quand tu peux enlever un fort parti, c'est pas plus mal, tu seras mieux intégré aussi avec ta code base, avec tes pairs et tout, parce que c'est eux qui gèrent l'ensemble. Et en fait, on a regardé GitHub Action, on a tout de suite vu qu'utiliser des runners chez GitHub Action, c'était hors de question, au lieu de diminuer nos coûts, on allait juste les augmenter par rapport à Circle. Ce que fait GitHub, à la fois ils gèrent l'orchestration, ça c'est gratuit, c'est dans tous les plans en fait, et ils gèrent les machines derrière. vraiment le compute et leur compute est assez peu performant et très cher malheureusement. Et du coup on a regardé un peu ce qu'il y avait d'autre donc est-ce que tu fais ça sur du Kubernetes et tu lances des runners à la volée comme ça ou est-ce que tu utilises un autre third party ? Il y a une tonne de third parties qui se sont lancées quand même récemment sur faire du Hostile Runner pour GitHub justement pour répondre à ces problèmes de coûts et de performances. Et c'est bien, c'est excellent, mais à notre scale, il y a peut-être mieux à faire. Et c'est là qu'on a découvert Runzone, qui était assez early. Je sais que tu as eu Cyril aussi de Runzone, on ne l'a pas si longtemps sur ton podcast. Et on a beaucoup itéré avec lui, ce que j'ai testé. Et en fait, l'idée de Runzone, c'est quand tu as un nouveau job de CI qui est Qd, ça va pinguer ton compte AWS, ton compte AWS va booter une VM sur EC2 cette VM va être là le temps de ton job et elle va être qui là la fin. Ce qui fait que tu es sûr d'avoir un environnement totalement isolé, tu es sûr d'avoir des coûts qui sont assez minimaux parce que tu es vraiment sur AWS et tu peux bénéficier d'un sans spot, tu as de la granularité dans ce que tu demandes. Et donc voilà, on est passé, on a fait cette migration-là, on estimait avoir une adduction des coûts de Circle en passant à GitHub, on pensait diviser par un peu moins de deux. 40% à 50% de savings et en fait au final on en fait on a divisé par 4 ce move là et donc c'est très très cool et avec une DX qui est franchement bien meilleure après GitHub a quand même assez rarement des incidents, c'est quand même un des trucs où ils sont pas en termes de reliability c'est pas si foufou mais sur l'ensemble on s'est retrouvé énormément et ça nous a permis de faire beaucoup plus d'optim de CI Et c'est pareil du coup en terme de temps, typiquement sur main, on mettait nos jobs pour trigger, jusqu'à que ça trigger en déploiement ça mettait peut-être 15 minutes et maintenant ça en met 8 quoi. On a vraiment gagné sur tous les aspects de notre CI avec Xfce.

• Speaker #1

  Plus vite, moins cher et pas trop de maintenance, je pense que Runzl a tracé lightweight, si tu fais un peu d'AWS déjà c'est pas vraiment un problème au final.

• Speaker #0

  C'est exactement ça. Si demain je lance un nouveau produit, je resterai sur GitHub Action pour me simplifier la vie parce que c'est intégré, c'est déjà là, tu n'as pas d'autres questions. Je prendrais sûrement un third party qui gère le loosing pour moi. Donc, tu as budget, word build, tu en as des quinzaines maintenant. Et par contre, dès que tu scales et que tu es sur AWS, ce qui est facile avec Amazon, c'est assez cool. Par contre, il faut accepter d'avoir un petit peu plus de queuing de tes jobs au début parce qu'il y a un... il y a une latence qui est incompréhensible le temps de lancer ta machine EC2 donc ton job avant que dans l'UI de GitHub tu vois quelque chose commencer à apparaître t'en as pour 25 secondes quand c'est GitHub qui le manage t'es plus à 5 secondes et les fortes parties sont entre 10 et 20 secondes suivant leur autoscaling donc t'as un petit peu plus de temps de latence mais tu t'y retrouves forcément et puis t'as le droit à des machines si tu veux 128 c'est plus Tu peux avoir 128 CPU ou pas.

• Speaker #1

  C'est clair que tu as des besoins un peu custom, ce qui n'est pas forcément le cas de tout le monde, mais c'est vrai que là-dessus, tu peux utiliser AWS ou autre cloud provider, c'est quand même un gros plus. Après, le problème que j'ai avec les budgets et autres services de ce type, c'est souvent les aspects de sécurité qui ne sont pas clairs du tout. La dernière fois que j'ai regardé, par exemple, le budget, les autres n'avaient aucun certif pour faire tout ce genre de choses. Du coup, c'est un peu compliqué, si on avait regardé dans le même pour nous, de dire... Pourquoi pas ? Sur le papier, c'est facile. C'est une ligne dans ton YAML et tu divises tes coûts par deux et tu multiplies par deux tes pertes. Voilà le marketing. Mais le problème, c'est qu'en fait, tu rajoutes un certain parti qui récupère toute l'exécution de ton CI et ton code qui va avec. Avec des accès plus ou moins en écriture, en lecture, plein de trucs.

• Speaker #0

  Et puis tes secrets de GitHub.

• Speaker #1

  Tes secrets, surtout.

• Speaker #0

  Tu peux seulement donner accès à à peu près tout sur ton infra. Clairement, tu as ça qui est... Je sais que la plupart, ils travaillent. Je sais qu'ils sont en train de bosser sur leur certif, ça que tout, budget aussi, je crois, mais la plupart, c'est une progresse, ça met du temps à avoir ce certif, et voilà. Et l'autre problème, souvent, de différentes parties, c'est le parallélisme. Ils ont une limite, en général, tu n'as pas de limite forcément. Ils ont des pricings qui sont différents, tous, mais assez souvent, tu vas payer par combien de jobs en parallèle tu veux ramener. Et en fait, nous, on a... scale où chaque paire elle a besoin de entre 30 et 70 jobs en parallèle on est sans ingénieur je te laisse faire un peu le calcul font nous tous plusieurs paires par jour fait on a besoin d'un paralysé de ouf avec ça et un budget je crois que c'est par défaut tu as deux trucs de parallélisme et après tu dois payer 300 dollars pour avoir quatre tu offres je sais plus du tout les chiffres ouais c'est souvent par des dents grottes et ce genre de truc est en fait c'est un gérable comme ce qu'elle est le seul que je connais qui fasse pas ça c'est world build qui dit que le paralysme est illimité. C'est pas nous. En fait, vous payez le compute. Donc, le paralysme, c'est notre problème d'autoscaling. Nous, ce qui est notre cas, c'est que vous payez le compute et c'est tout. Et c'est un problème que tu n'as pas trop sur AWS. Ce qui n'est pas tellement vrai, parce que pareil, on a dû se battre pendant quand même pas mal de temps pour augmenter tous les quotas d'AWS pour fonctionner avec Ramzan. Parce qu'en fait, AWS, tu as des quotas derrière. Surtout, tu as des quotas de combien d'instances tu as le droit d'avoir en même temps, de combien d'infants tu as.

• Speaker #1

  Donc, 4C ou qui sont visibles et configurables ? Oui.

• Speaker #0

  Tu ne peux pas les configurer toi, tu les as de visibles dans ta console AWS, tu peux voir les quotas, tu peux voir l'utilisation de ces quotas historiques, mais tu ne peux pas les configurer, il faut passer par leur service client pour les configurer. Et tu en as un qui est très problématique, la plupart ça va, c'est juste qu'ils ne font pas des augmentes de x10 du jour au lendemain, à part si tu le justifies vraiment très très très très bien. Et il y en a un qui est un enfer, c'est en fait ils ont du rate limiting sur leurs API de ces deux. Et donc quand tu demandes une nouvelle instance, ou quand tu tues une instance, ou quand tu juste describes une instance, enfin tout ça, ça utilise tes quotas. Et ça, c'est très mal documenté. Ça, il faut passer par leur support qui doit le renvoyer à un support US. Et en fait, on a pour une semaine de back and forth chez eux pour justifier. Ils te font des allers-retours sur des questions qu'elle t'a déjà répondues et tout. Et ça, c'est ce où ça nous a mis à chaque fois qu'on a dû demander des updates, c'était un enfer. Mais une fois que tu les as, en vrai, ça marche.

• Speaker #1

  C'est bon à savoir, tu sais qu'il y a des trucs comme ça à tweaker un petit peu pour que ça fonctionne de A à Z, mais après oui t'es tranquille, t'as ton système qui fonctionne, normalement tu changes pas d'échelle, fois 10 c'est peut-être même.

• Speaker #0

  Non et puis au pire c'est un bon problème à avoir. Et encore une fois, à Doulas c'est pareil, ils font ça, c'est un peu des safety nets pour eux, pour être sûr que du jour au lendemain t'es pas quelqu'un qui fasse de l'abus, mais en fait quand ils voient que ton usage augmente petit à petit, si demain on change d'échelle, ils nous l'augmenteront, c'est juste qu'il faut repasser par... process de pourquoi, leur dire de telle heure à telle heure, regardez à quel point on a tué notre height limit, quel est l'impact sur le business, et en fait, ça se fait.

• Speaker #1

  On veut juste vous donner plus d'argent, et du coup,

• Speaker #0

  ils disent oui. C'est vraiment ça.

• Speaker #1

  Je pense que si tu justifies comme ça tes requêtes en disant, mais en fait, à la fin, on fera plus de business. En général, les Américains ne sont pas trop regardants, ils font, ça marche. Ça marche. Ok, c'est cool. Du coup, autre question sur le côté CI, mais vos... vous avez une équipe du coin peu transverses qui est responsable par l'impression que la réponse va être oui tout se passe bien mais du coup vos dettes sont tous hyper impliqué au jeu au niveau 6 à une niveau t je prends un truc un mono ripo et comment tu gères les flacques et est dans le parti de coq et pas la tiède ou genre de choses c'est tout le monde se sent responsable et alors à l'anarchie globale de tout le code parce que ça me nourrit peau et que vous avez une organisation très horizontale et tout je sens que c'est la réponse que tu vas me faire

• Speaker #0

  plus ou moins c'est pas assez simple dans l'idée c'est ça dans l'idée c'est un peu tout le monde est responsable après tu vas tu as un flaky test tu vas d'abord pinguer soit la dernière personne qui a touché soit tu vas te baser sur le code d'honneur on utilise vachement les fichiers de code d'honneur de github pour savoir quelle partie du code appartient à quel groupe à quelle équipe enfin qui l'a implémenté ou est ce qu'il y a un support long terme dessus pour donc tu vas te baser sur ça pour essayer de le rediriger après Une autre chose, c'est qu'on a un NG qui est on-call tous les jours, pas toujours le même, mais que dans les horaires de travail, on n'a pas vraiment de vrai on-call qui va se faire pinguer à minuit ou autre. C'est plus quelqu'un qui, chaque jour, est responsable de regarder si il a fait, qu'est-ce qui s'est passé. On a de l'alerting qui va pinguer la personne qui a commité, qui va pinguer le bon on-call, parce qu'on a un NG on-call, mais on a aussi un infra, on a aussi d'autres équipes, donc chaque équipe a un peu un on-call. Et si on arrive à router directement à ces personnes-là, on leur route directement pour qu'ils se fassent au moins pinguer. Après, ils ne sont pas toujours réactifs parce que tu peux être en train aussi de faire autre chose ou de gérer un autre problème. Et tu n'as pas envie de bloquer ta CI parce que quelqu'un n'était pas forcément réactif. Donc là, ça va être un peu du bon vouloir et de la bonne volonté de chaque ingénieur de dire, je vais regarder ce qui s'est passé. Pire des cas, si ce n'est pas un flaky test, si c'est un commit vraiment qui introduit une erreur, on va juste le re-hurt. S'il n'a pas encore été déployé, de toute façon, il n'y a pas trop de risques. Si c'est quelque chose de fléquis, on a ensuite quelques ingénieurs qui aiment aller fixer ces choses-là. Parfois, tu vas voir des noms qui ressortent, ce n'est pas leur responsabilité, ils vont aller regarder. On a régulièrement des problèmes avec PyTest, parce que c'est notre plus gros truc, notre suite de tests Python. Lui, il est passionné à regarder ce qui se passe, c'est fléquis, il va rechecker, il va rerun dans le même ordre, regarder ce qui impacte quoi et petit à petit, il les fixe. Et l'idée c'est d'aller vers de moins en moins de flatness et on y arrive pas mal. On a fait pas mal de changements.

• Speaker #1

  Vous avez un outil d'observabilité, de monitoring, de tracking des tests comme ça ? Ou c'est…

• Speaker #0

  Au niveau des tests, on l'avait avec CircleCI. C'est un truc qui était pas trop mal mais en vrai, enfin, tu étais vite limité. Ça donnait un peu une overview mais voilà. Et maintenant qu'on est sur GitHub, ce qu'on fait, on utilise Datadog. Ok. On utilise Datadog pour… Et Datadog s'entête super bien avec les CI et tu peux voir chaque pipeline, chaque job, quel est son failure rate, quelle est sa vitesse, tout ça. Donc, ça permet vraiment de pas mal optimiser. On ne l'a pas avec la grande priorité des tests, par contre. Ce n'est pas chaque test individuel. On ne sait pas quel est le test le plus fléquible, parce que ça, c'est une autre offre de Datadog qui, aujourd'hui, on considère que nous, le ROI n'y est pas. Je crois que ça doit être 3 000 euros par mois en plus, tu vois, ou un truc dans le genre. Et on sait que ça sert un peu de croix aujourd'hui. par rapport à notre nombre de fléquis tassé si tout était fléchi bas je pense que ça devrait la peine d'aller pour ça mais on le fait ok non c'est cool je pensais d'avoir un tout mine comme ça si tu veux arriver à suivre parce que c'est pas forcément évident de voir d'avoir

• Speaker #1

  un cycle de vie de ces problèmes là donc c'est pas mal de pas mal de changements du coup entre six cas qu'il ya et github action et c'est et vous avez d'autres plans d'autres chantiers à venir ? Vous êtes content, c'est fini ?

• Speaker #0

  Alors, sur tout ce qui est infra, pipeline et tout, non. On a fait trois. Notre début d'année était quand même passer tous nos back-ends de Beanstalk à Covery, toutes nos front-ends de Beanstalk à Pages et toute notre CI de Circle à GitHub 0.1.1. Je pense qu'on est pas mal pour un bout de temps. On a plein d'autres chantiers mais qui ne sont pas forcément liés à ça. Là, on va plus... c'est plus des problèmes d'entrée sur du scale. On a gagné des assez gros contrats avec des entités gouvernementales, des ministères et tout, donc ça va nous faire beaucoup plus de volume. Donc, on est juste en train de bosser plutôt sur du scale et être sûr de pouvoir gérer tout ça. Et sur de la developer experience, c'est un peu plus pur, donc même au niveau de vitesse de tes outils en local, de ton limiter, par exemple, ou d'organisation de la code base, tout simplement. Quelles sont les prochaines solutions de la code base pour être sûr qu'elles soient dans un état un peu plus... modernes, un peu plus simples à gérer, un peu moins de legacy, comment est-ce que tu finis certaines migrations de code pur qui ont été commencées il y a quelques temps. C'est plus ça nos chantiers à venir.

• Speaker #1

  Ok. Gestion de la dette technique, de l'autorécponible, ce genre de choses.

• Speaker #0

  Exactement. Et qui est un peu lié à un peu de la globalisation aussi, parce qu'en gros, on est aujourd'hui dans trois pays. La santé est un business qui est très différent selon les pays, comme tu peux t'en douter. Tu as beaucoup de spécificités. Aujourd'hui, c'est France, Espagne et Belgique. Et donc, quand on a ouvert ces pays, on les a un peu lancés dans le même repo, mais en forquant un peu l'app, la database et tout, pour s'adapter aux contraintes du pays vraiment existant. Parce que le système de remboursement ne fonctionne pas de toute la même manière, par exemple. Et là, on essaye de reprendre une approche un peu plus globale, en essayant de, OK, qu'est-ce qu'on peut centraliser, globaliser, et en fait, se simplifier la vie pour éviter d'avoir des choses qui sont faites trois fois, de voir... 3 DB à gérer, par exemple, ce genre de choses. Donc, il y a pas mal de sujets de globalisation qui sont aussi super intéressants parce qu'au final, c'est de la developer experience et comment tu réorganises ton code et tes modèles pour que ça fonctionne.

• Speaker #1

  Vous avez des équipes tech dans ces pays-là ou c'est seulement toujours centralisé sur la cliente ?

• Speaker #0

  Alors on a des devs qui sont en Belgique et en Espagne, mais ils ne bossent pas forcément sur la Belgique ou l'Espagne. C'est comme ce qu'on disait tout à l'heure, des ingénieurs sont des ingénieurs, et en fait tu as des ingé à Lyon qui vont bosser pour des produits espagnols, tu as des ingé à Bruxelles qui vont bosser sur des produits espagnols, c'est très touchant.

• Speaker #1

  Il n'y a pas d'équipe localisée particulièrement sur un pays ?

• Speaker #0

  Il n'y a pas d'équipe localisée, on a des bureaux à différents endroits, mais notre approche c'est que tu peux être remote friendly. on peut vraiment bosser sur la même time zone dans des pays où c'est gérable d'un point de vue contractuel et donc en fait non il n'y a pas de contraintes de localisation c'est cool top,

• Speaker #1

  en tout cas sacré chantier au pluriel que vous avez effectué ces derniers mois je comprends que cette année c'est un peu plus calme jusqu'au design system dans Figma ou je ne sais pas un moment pour faire autre chose ça va pas du tout.

• Speaker #0

  C'est vrai que quand tu passes de ta console AWS à regarder les couleurs dans Figma, tu as des petits changements de contexte et il faut que tu fasses les deux donc tu vois, il faut arriver à recourir à ça.

• Speaker #1

  Il ne faut pas se gourer, changer les couleurs des boutons du CI et puis je ne sais pas ça que je devais faire, je ne sais pas C'est compliqué. Ok, cool. Je pense qu'on a fait un bon tour de toute votre infra et tout. Est-ce que tu penses qu'il y a un dernier point qu'on n'a pas abordé et qui serait super intéressant et dont vous êtes super fiers de ce que vous avez fait chez Alan ou même ce que tu as fait avec tu-même ?

• Speaker #0

  faire avant non pas particulièrement je suis très fier de tous les sujets qu'on arrive à gérer une rémunération qui permet de les faire fin qui est assez particulière en faut voir tu as tout ce qu'on disait en termes de l'organisation de switch et d'équipe et tout c'est quand même assez différent de ce qu'on voit souvent et ça fonctionne pas mal et je suis déjà assez fier qu'on arrive à faire tout ça sur cette organisation là donc je trouve ça cool et je pense qu'on a fait le tour des gros des gros sujets qu'on a chez Alan, c'est une bonne vue de ensemble sur ce qui se passe dans notre équipe.

• Speaker #1

  Je pense que c'est votre organisation et là, en fait, c'est super inspirant. Est-ce qu'il y a des docs, d'ailleurs, là-dessus ? Vous avez partagé un peu votre façon de travailler ?

• Speaker #0

  Énormément. On a un blog, je crois, je peux te l'envoyer dans la foulée, on pourra le mettre en lien. On a un blog, notamment notre blog technique, qui a beaucoup, beaucoup de contextes, à la fois sur nos choix techniques, mais aussi sur notre orga. Même sur, enfin, tu vois, on a une grille de salaire qui est transparente avec des niveaux et tout. Tout ça, c'est documenté. On a pas mal d'articles sur comment on fonctionne, parce que tout est asynchrone et tout passe par l'écrit chez Alam. Toute décision est écrite et publique. C'est-à-dire, on utilise GitHub. Même les équipes non tech utilisent tout GitHub pour prendre des décisions sur n'importe quoi. Mais même, est-ce qu'on fait une levée de fonds, ça va passer par GitHub, en fait. C'est des fondateurs qui vont parler sur GitHub, tu vois, au final. C'est assez intéressant. Et sur notre blog tech, on a pas mal d'infos sur tout ça, sur notre fonctionnement.

• Speaker #1

  donc c'est assez démenté je vais mettre les liens et je vais aller lire parce que ça m'intéresse du coup, je trouve ça assez curieux et assez cool, ça rend pas mal des orgueils que j'ai pu voir dans d'autres boîtes qui ont un peu ce côté très ouvert et qui est pas toujours, pas partout quoi donc c'est super cool pas partout et qui est du rascale,

• Speaker #0

  moi j'y croyais pas c'est marrant, Alan est une boîte que je suis du point de l'oeil depuis on va dire, depuis que c'est né en 2016 parce que je croyais que justement sur la partie culturelle et valeur, c'est très intéressant mais j'ai eu beaucoup de boîtes essayer de faire ça et... pas y arriver à scale. Je connais par exemple Buffer qui était sur la transparence totale et en fait qui est un peu revenu en arrière à un moment parce qu'ils n'arrivaient pas à le faire fonctionner. Je suis assez étonné que chez Adam on arrive à le faire alors qu'on est plus de 500 aujourd'hui. Mais c'est que c'est tellement intrinsèque et tellement ancré dans nos cultures, dans nos valeurs, dans le recrutement aussi du coup ça fait que tu fais vachement plus gaffe à quel profil tu recrutes parce qu'il faut que ça fitte. C'est pas forcément évident mais vraiment dans les deux sens. Et c'est vraiment tellement des valeurs qui sont fortes pour les cofondateurs. on arrive à le faire fonctionner.

• Speaker #1

  C'est dur quand tu scales, d'autant plus si tu scales vite parce que tu te trouves dans une situation quand tu scales très vite où en fait les deux tiers des gens de ta boîte ont moins d'un an ou deux de présence donc en fait tes valeurs ont tendance à se diluer très vite, ta culture à très vite se diluer et à se perdre parce que tu scales très très vite. Quand tu onboardes une nouvelle personne tous les ans avec tes 500, il n'y a pas de débat mais quand tu commences à augmenter des centaines, à onboarder des centaines de personnes tous les ans et que du coup la plupart des gens ne sont pas là depuis très longtemps c'est compliqué de partager tout ça donc ça je pense c'est un vrai challenge bien joué je me sens pas responsable pour le coup c'est un peu de collectif pour tout le monde merci beaucoup Tim en tout cas c'était super cool d'échanger avec toi et d'apprendre tout ça sur Alan on a fait un peu de tambouille interne plus de social et de trucs comme ça c'est super intéressant et je pense que ça a un impact directement sur comment ça fonctionne niveau technique aussi donc c'est vraiment intéressant d'en parler donc écoute merci beaucoup à toi pour cet épisode c'est super intéressant et puis au plaisir

• Speaker #0

  Merci beaucoup à toi Julien et je te dis à bientôt.

• Speaker #1

  Et voilà, c'était la fin de cet épisode. Un grand merci à vous de nous avoir écouté aujourd'hui dans cette exploration du monde fascinant du DevOps. Si le podcast vous a plu, n'hésitez pas à le partager, voire à me laisser un avis, voire à me laisser 5 étoiles sur votre plateforme de podcast préférée. Ça m'aiderait énormément et ça fait toujours plaisir. Restez connectés pour encore plus de découvertes, d'astuces, de témoignages inspirants dans les prochains épisodes. Et d'ici là, gardez vos pipelines fluides et votre CI bien adapté. A très bientôt pour une nouvelle aventure au cœur du CI-CD.