Bruno:
Ce qu'elle est un monolithe, c'est un peu comme jouer à Tetris niveau 99. Au début, les pièces s'assemblent et s'emboîtes nickel, tout est fluide. Puis les blocs arrivent de plus en plus vite, les lignes s'accumulent, et soudain tu dois gérer 150 joueurs qui posent leurs briques en même temps sur la même grille. Mais alors, comment garder une architecture lisible quand tout le monde veut placer sa pièce ? Est-ce qu'un monolithe peut vraiment encaisser la vitesse sans exploser ? Et surtout, est-ce qu'on peut finir par gagner ou est-ce que c'est juste toujours le jeu qui gagne ? Pour répondre à ces questions de ligne, je ne reçois pas Alexei Pajitnov, mais il s'y connaît en puzzle logiciel. Quentin, bonjour.
Quentin:
Bonjour Bruno.
Bruno:
Alors Quentin, est-ce que tu peux te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Quentin:
Moi je m'appelle Quentin Demez, j'ai 35 ans, je suis cofondateur et CTO chez Penny Lane.
Bruno:
Ok, donc tu étais déjà venu sur le podcast il y a quelques années pour nous parler un petit peu de Penny Lane. Mais donc depuis les choses ont un peu changé notamment Penny Lane qui a pris une ampleur quand même assez, colossale et donc la question c'était comment est-ce qu'on fait évoluer une telle architecture et notamment j'avais découvert que vous étiez sur un monolithe, à l'époque et est-ce que vous êtes encore et toujours sur ce fameux monolithe ? Alors, est-ce que tu peux nous parler du coup un peu de cette croissance qu'a connue PennyLine pour qu'on voit un peu l'évolution d'échelle et qu'on puisse après creuser comment est-ce que tu fais pour faire évoluer un monologue dans ces conditions ?
Quentin:
Alors, nous, PennyLine, la première ligne de code, elle date d'il y a 6 ans à peu près. J'étais tout seul, le seul CTO sans équipe, et en 6 ans on accompagne aujourd'hui pas très loin de 500 000 entreprises sur notre logiciel, et j'ai un peu perdu le compte de la taille de l'équipe de développeurs mais je dirais qu'on est aux alentours de 250, là l'année 2025 c'est une année où on grandit assez vite et la promo de septembre c'est toujours une grosse promo les gens qui repoussent le démarrage de leur nouveau job jusqu'à après l'été on a aujourd'hui 28 nouveaux ingénieurs qui commencent.
Bruno:
Ok parce qu'on est effectivement le lundi 8 septembre donc t'as 25 personnes qui arrivent le même jour pour commencer.
Quentin:
Au niveau de la boîte c'est plus que ça mais dans mon département oui c'est ça.
Bruno:
Donc c'est 10% de l'équipe qui arrivent quasiment le même jour.
Quentin:
C'est un.
Bruno:
Onboarding un peu conseil en.
Quentin:
Camagéry. Absolument.
Bruno:
Donc effectivement, 250 ingénieurs, j'imagine, réparés sur plein de technos différents, plein de métiers différents.
Quentin:
Pas du tout. Alors, on a le département tech qui est quand même divisé en deux. On a vraiment de la stack data d'une part et la stack, le reste, le web, d'autre part. Et là, c'est essentiellement ou même à 99%, du Ruby on Rails, du React et on fait du mobile, donc on fait du React Native.
Bruno:
OK. Donc exclusivement Ruby React. C'est effectivement très léger comme stack et côté data parce que ça je m'ai lu que ça a pas mal changé.
Quentin:
Il n'y a pas de comptaine, des technos Amazon et puis voilà.
Bruno:
Est-ce que les équipes en interne poussent pour passer sur du micro ou du macro-service ? Est-ce qu'il y a une volonté de changer ou le monolithe est bien vécu en interne ?
Quentin:
Le monolithe est bien vécu, ce n'est pas pour autant que certains ne posent pas la question. On affiche une volonté forte de conserver et d'investir dans ce monolithe. Donc c'est souvent d'ailleurs les nouveaux qui disent mais pourquoi vous ne faites pas du micro-service ? Et une fois qu'on leur a expliqué, ils constatent que ça fonctionne et la question ne revient pas tellement.
Bruno:
Ok. Et c'est vraiment un vrai monolithique ? C'est carrément un seul repo pour tout le monde ?
Quentin:
C'est un seul repo pour l'application web. On a un repo spécifique pour l'application mobile. Mais c'est un seul repo pour l'application web en Ruby on Rails avec des centaines de modèles, des centaines de contrôleurs, des milliers ou dizaines de milliers de fichiers sur lesquels tous les développeurs qui bossent sur l'application web contribuent à cet unique endroit.
Bruno:
Tu me disais effectivement en préparation c'est 35 000 fichiers sur la code base qui est effectivement colossale.
Quentin:
Voilà, mais pour donner un peu de contexte c'est ma deuxième aventure entrepreneuriale et la première boîte que j'ai montée il y a longtemps maintenant a été rachetée par Booking.com en 2015, quand on a rejoint Booking.com, il y avait à peu près 1000 ingénieurs et qui travaillaient sur un monolithe Perle depuis 20 ans. Et quand on voit le succès de Booking.com, on peut uniquement se dire que ça a l'air de marcher. Donc on vient de ce contexte-là.
Bruno:
Après, le service peut fonctionner, mais peut-être qu'il y a une certaine latence, une lenteur en tout cas pour délivrer de la feature parce que peut-être que tu as une code base qui est un peu vieillissante ou compliquée à faire évoluer.
Quentin:
C'est hyper intéressant, j'ai plein de choses à dire là-dessus. Dans le fond, je pense que quel que soit le paradigme que l'on a choisi, au-delà d'une certaine taille d'équipe, ce n'est pas quelque chose qui fonctionne tout seul, sans entretien, sans investissement. Quel que soit le paradigme microservices ou monolithe, il faut dédier du temps pour être capable de continuer à sortir des fonctionnalités rapidement. Dans le fond, je ne peux pas dire que le monolithe est meilleur que le microservice. Le monolithe, c'est celui que je connais. Je sais qu'elles sont ses forcées, ses faiblesses, et je sais ce qu'il faut mettre en place pour gérer ses faiblesses. Du coup, c'est ça que j'ai choisi. Il y a des gens qui sont des magiciens du microservice et qui ont des boîtes en microservice qui fonctionnent hyper bien. Il y en a d'autres qui se tôlent, et c'est la même chose. C'est une situation assez symétrique. Il se trouve que moi, je connais le monolithe. Donc, ce n'est pas là-dessus que j'avais envie de prendre des risques en changeant mon paradigme. J'ai d'autres sujets sur lesquels je voulais prendre des risques typiquement le business model prendre des risques là où il y a de la récompense au bout c'est la bonne stratégie à mon sens.
Bruno:
J'entends que le monolithe c'est le modèle que tu connais du.
Quentin:
Coup c'est.
Bruno:
Ta zone de confort on peut dire de cette manière mais j'imagine qu'avec 250 personnes dans ton équipe tu codes plus beaucoup à mon avis tu ne bouges pas beaucoup de codes en prod tous les jours, donc tu aurais pu laisser cette décision à ton équipe et tu aurais pu avoir une équipe qui décide de est-ce que c'est toi qui est quand même un souffle, cette volonté de continuer sur du monolithe et si oui c'est quoi pour toi les avantages principaux du monolithe.
Quentin:
Alors déjà je suis assez hands on comme CTO c'est quelque chose qui me drive beaucoup dans lequel je trouve beaucoup de, satisfaction personnelle et je trouve que c'est à la fois une composante essentielle de mon leadership et ça me permet d'être au contact, des ingénieurs terrain qui ship des features tous les jours donc je passe encore une bonne partie de mon code les mains dedans et sur le monolithe je ship à peu près un commit par jour en prod donc je reste assez actif et c'est ça qui me permet de voir aussi est ce que ça fonctionne de manière satisfaisante est ce qu'il faut qu'on est ce qu'on a des problèmes à résoudre sur lesquels il faut qu'on staff du monde pour comment on dirait les américains engineers de chez l'or le vêtent, Et ce n'est pas parce qu'on a un monolithe qu'on ne peut pas être organisé de manière intelligente pour que ça fonctionne. C'était quoi la deuxième partie de ta question ?
Bruno:
C'est quoi pour toi les avantages du monolithe qui fait que tu continues à promouvoir cette solution ?
Quentin:
Ce que je peux citer en premier, c'est la cohérence du style. C'est-à-dire qu'on met les outils en place une fois pour toutes et ils s'appliquent à tout le monolithe. Les linter, les règles dans l'IDE la suite de CI, etc tout le monde a le même référentiel et ça rend le fait de changer d'équipe ou changer de scope produit hyper simple, parce qu'on ne change pas les outils du quotidien, on change juste à peu près schématiquement dans quel dossier on travaille, et deuxièmement, c'est au moment de la mise en prod on n'a pas besoin d'orchestrer n différents services à mettre en prod A avant B, avant C, avant D A, bah zut, je dois riverter Z, du coup il faut que je refasse toute la chaîne de riverter dans l'autre sens, je mets en prod une image de coeur, on n'en parle plus.
Bruno:
Mais du coup sur les sujets d'intégration quand tu as 250 personnes qui bossent sur le même environnement comment tu coordonnes ne serait-ce qu'effectivement tu as toute ton intégration pour t'assurer que tes tests fonctionnent bien et que tu ne sois pas parasité par ce que chacun peut pousser à différents instants.
Quentin:
On utilise le GitFlow classique où chacun ouvre sa boule request sur GitHub et quand les tests sont verts et il y a les approvals nécessaires peuvent merger sur Master, et donc le fait que la suite de tests soit verte nous donne la confiance sur le fait qu'on peut ship en production et on a de la continuous delivery qui met en prod toutes les 15 minutes toute la journée.
Bruno:
D'accord tu pushes en prod toutes les 15 minutes c'est énorme comme système.
Quentin:
? Alors oui et non mais une autre manière de voir les choses c'est si on met en prod toutes les semaines on met 1000 commits en prod alors là le risque est démesuré quand je mets en prod toutes les 15 minutes, quand j'ai un problème je regarde le div des 15 dernières minutes il y a 10 commits, et c'est très facile de trouver exactement quel était le problème de riverter et 15 minutes plus tard c'est résolu alors que si je vais en prod le lundi matin, voilà c'est une énorme prise de risque à chaque fois je préfère étaler ses risques tout au long de la semaine, et fournir un service qui est up et fonctionnel sur tout le périmètre produit à mes clients à 99% c'est jamais les mêmes 99% c'est un équilibre, c'est une stabilité dynamique je dirais mais du coup on arrive à mettre en prod les yeux fermés.
Bruno:
Est-ce que tu penses que ce choix du monolithe t'oblige à une certaine organisation d'équipe ou au final tu as fait des choix d'organisation d'équipe qui sont décorrélés de cette organisation du code ?
Quentin:
J'ai pas l'impression qu'on ait fait des choix d'organisation d'équipe particuliers, On a des feature team avec un PM, un manager et à la louche 5 ingénieurs et un designer. Ils bossent sur leur périmètre, il y a certaines parties de leurs codes qui leur sont très propres, certaines où ils ont besoin de se brancher ou s'interfacer avec d'autres équipes, d'autres fonctionnalités développées par d'autres gens. Et donc là il faut avoir les bonnes API en interne, c'est pas des API HTTP, c'est des appels de fonctions et ça tourne.
Bruno:
Ok il y a quand même du coup aussi un, enfin tu vois tu nous parlais tout à l'heure de cette cohérence est-ce que tu as une équipe d'hyper experts qui vont justement s'assurer que la cohérence est maintenue entre chacun j'imagine qu'il y a quand même, des pratiques de dev assez clean qui font que vous avez peut-être différents modules ou GM je ne sais pas comment c'est Oui.
Quentin:
Grosso modo, mais c'est un work in progress.
Bruno:
OK. Et donc, vous avez une équipe qui supervise tout ça au quotidien, qui diffuse des bonnes pratiques ?
Quentin:
Non. C'est une responsabilité qui est distribuée.
Bruno:
Sur les 250 ingénieurs ?
Quentin:
Sur les 250 ingénieurs. Alors, c'est pareil, ça, c'est work in progress. Ça fonctionne jusqu'à ce que ça fonctionne moins. Mais par exemple, sur les pratiques de code, on a des... On appelle ça des fellowships qui se manifestent. On peut rejoindre une fellowship à tout moment et sortir d'une fellowship à tout moment, et il y a la fellowship qui réfléchit comment est-ce qu'on écrit dans le jargon rubis des factories pour les tests, c'est quoi un peu les guidelines pour ça, mettre à jour la documentation pour expliquer aux gens comment il faut faire, mettre à jour des règles automatiques de l'inter, et puis demain ce sera des promptes pour l'IA pour faire la review automatiquement, pour expliquer aux gens, c'est ça notre nouveau standard ? Et les standards, c'est les choses qui évoluent. Par contre, quand on a 500 modèles dans notre base de données, on ne peut pas revenir reprendre les 500 factories à chaque fois que quelqu'un trouve une meilleure idée pour le nouveau standard. Donc on est aussi dans une phase où on se dit que l'objectif, quand on met en place des best practices, ce n'est pas de remettre les 2 millions de lignes de code au dernier standard. L'objectif, c'est de s'assurer que tout ce qu'on produit à période de maintenant, il est conforme à ce nouveau standard. Puisque ce qui existe déjà en fait ça marche si il est là c'est qu'il marche, si on va essayer de le mettre au nouveau standard on va introduire une perturbation on risque de créer du bug l'impact de l'utilisateur sans créer de valeur pour le client donc on va dépenser du temps, risquer d'introduire des bugs et créer zéro valeur pour l'utilisateur, donc c'est plutôt si jamais on va retravailler ce module un jour là on se posera la question comment est-ce qu'on peut le rapprocher du dernier standard, mais il se trouve du coup parfois qu'une équipe va travailler dans un bootcode qui a 4 ans et là il est sur 14 générations de standard de retard et il y a un peu de travail pour le mettre au bout du jour.
Bruno:
Alors du coup certes j'entends que tu évites de produire des perturbations parce que si effectivement tu dois mettre à jour 35 000 fichiers dès que tu changes de standard effectivement chaque modification prend un an à peu près de travail, mais en le faisant comme ça de manière on va dire incrémentale, tu prends le risque aussi d'avoir peut-être 8 standards différents présents dans ta code base.
Quentin:
Oui c'est un peu la malédiction des standards, ce sur quoi il faut être hyper clair c'est les mécanismes de transmission de connaissances notamment aux nouveaux pour que ce soit très facile de savoir quel est le nouveau standard, quel est le standard qui est à jour, qui est d'actualité pour s'assurer que le contenu qu'on produit, c'est ça la règle le contenu qu'on produit doit être au dernier standard.
Bruno:
Ok Il y a j'imagine aussi qu'avec 250 personnes qui travaillent donc ils ont chacun leur on va dire leur zone de code un peu ou ils ont quand même beaucoup de... Tu nous dis que t'es organisé par Feature Team c'est ça ?
Quentin:
Oui.
Bruno:
Chacun a un peu sa Feature et son sa sous-partie du repo ?
Quentin:
Oui alors pour faire schématiquement chacun a ses contrôleurs, chaque équipe a ses contrôleurs, les modèles certains sont utilisés par une seule équipe, certains sont très partagés il y a tout le spectre entre les deux, il y en a qui sont utilisés par 30 équipes, il y en a qui sont utilisés par 2 équipes, il y en a qui n'ont qu'une seule équipe. Tout comme la base de données, elle est partagée par tout le monde aujourd'hui. Donc il y a, dans l'ensemble des fichiers, il y a un spectre, et ça ne doit pas être très dur de trouver les statistiques via Git, pour savoir lesquelles sont très partagées, lesquelles ne sont pas du tout partagées.
Bruno:
Ok. Et il y a des... Parce que ma question m'a échappé en même temps, c'était sur... Oui, comment est-ce que, du coup, quand une équipe doit, de manière ponctuelle, travailler sur une zone d'une autre équipe, est-ce qu'ils passent le ballon à l'autre ? Ou comme tu as une espèce de continuité du code partout, chacun peut aller mettre le nez partout et toucher ce qu'il a à toucher ?
Quentin:
Il n'y a pas de règles. Ça dépend un peu de l'ampleur de la tâche. Mais en pratique, chacun est capable d'aller mettre son nez et faire des modifications dans le scope de n'importe qui. Il y a un mix de règles avec les codowners de GitHub, qui si on vient modifier un fichier clé au sein d'une autre équipe si cette équipe l'a flaguée comme un fichier clé elle va être pingée pour une code review obligatoire donc le request ne pourrait pas être mergé si cette équipe avait donné son go, et s'il n'y en a pas de manière obligatoire c'est quand même une bonne pratique de collaboration d'aller demander son avis à quelqu'un de l'équipe hello j'ai modifié ça je pense qu'il n'y a pas d'impact est-ce que tu peux juste me dire go, parfois la personne va dire go parfois elle ne va pas répondre parce qu'elle est sous l'eau ou l'organisation, il y a toujours un peu des petits dysfonctionnements. Parfois, elle va dire, attention, tu fais ça, mais on a ce projet d'évolution, donc c'est pas ici qu'il faut que tu mettes des modifications, c'est plutôt dans tel nouveau modèle, parce que le modèle que tu es en train de modifier, on est en train de le déprécate, on va le jeter à la poubelle dans trois mois.
Bruno:
Ok. Et comment tu fais aussi pour éviter que les jeux, enfin, plusieurs équipes se retrouvent à faire la même chose dans des contextes plus ou moins différents ? Alors, pas normalement de la même façon, certes, mais à des endroits différents.
Quentin:
Faire la même chose, normalement, c'est garanti par le fait que les équipes aient des scopes produits différents. euh... Il y a peu d'équipes qui doivent créer des nouveaux outils techniques qui vont servir à tout le monde parce qu'on a 6 ans on a une certaine maturité maintenant donc il y a peu de nouvelles choses à créer d'un point de vue purement outils techniques, et s'il y en a on les confie plutôt à ce qu'on appelle les fellowships, ça peut arriver que deux équipes viennent travailler sur le même modèle le modèle c'est vraiment l'exemple du fichier très partagé, vont travailler sur le même modèle pour faire quelque chose de similaire en même temps mais normalement ça a été quand même identifié au niveau produit donc au niveau produit on a une trentaine de squads donc une trentaine de PM et l'information circule encore suffisamment bien pour qu'il ne se marche pas sur les pieds.
Bruno:
Sur aussi la montée en puissance de Penny Lane en termes de besoins de ressources est-ce que ce monolithe a un coût particulier, comment tu fais progresser, juste en termes de hosting ton, hébergement ?
Quentin:
Alors, je ne suis pas sûr que nous, l'hébergement soit coûteux en fonction du nombre de lignes de code. Nous, il est coûteux en fonction du trafic et donc directement en fonction du nombre de clients. Mais qu'on ait 5 devs ou 500 devs sur ce sujet, oui, il y aura plus de lignes de code. Demain, il y en aura 5 millions. Peut-être que le monolithe Rails, une fois qu'il sera démarré, il va consommer un peu plus de RAM pour stocker tous les objets les contrôleurs, les machins etc mais on n'a pas l'air de constater pour l'instant, de corrélation forte l'utilisation des ressources reste relativement fixe c'est vraiment une fonction du trafic et donc indirectement du nombre de clients.
Bruno:
Ok et en termes de je le dis avec autant de bienveillance que possible parce que tu as fait le choix du coup du Ruby on Rails qui était une techno, très à la mode à un moment qu'il est un peu moins maintenant ça pourrait aussi être une, raison en fait d'essayer de s'orienter vers du micro-series parce que ça permet d'injecter d'autres technos peut-être plus modernes ou sur le cas c'est plus facile de trouver des ressources, le choix du rubis il est aussi il est enterriné, Advitam Eternam.
Quentin:
On ne dit jamais Advitam Eternam il y a beaucoup d'exemples de boîtes de Rubin Rails qui ont bougé un petit bout, typiquement la couche authentification d'autorisation vers un micro-service en go parce que ça va beaucoup plus vite et comme c'est sur le chemin critique d'absolument toutes les requêtes HTTP, c'est intéressant de venir gagner 20 ou 30 millisecondes sur toutes les requêtes HTTP. Mais nous, c'est notre conviction que plus on arrive à rester monolangage, alors s'il y a une très bonne raison d'aller faire, si on changeait de business et qu'on allait faire quelque chose de hyper sensible à la latence, on arrêterait de faire du Ruby on Rails probablement. Mais dans notre secteur, On fait un produit SaaS, relativement classique, finalement. C'est quelque chose qui est prouvé avec les GitHub, les Airbnb, etc. C'est quelque chose dont on connaît, encore une fois, les forces, les faiblesses. On connaît bien l'écosystème, on connaît bien les librairies. Et donc, c'est quelque chose qui, pour nous, est complètement dérisqué. Et avec lequel on a les résultats que l'on souhaite.
Bruno:
Oui, et puis effectivement, tu as une expertise, tu as une équipe aujourd'hui qui est hyper solide. Donc, tu gagnes un temps fou, j'imagine pour résoudre le moins de problèmes parce qu'en fait ils sont déjà dans un périmètre connu et.
Quentin:
Tout est déjà, c'est un grand mot mais tout est déjà formalisé, comment est-ce qu'on écrit des tests comment est-ce qu'on fait tourner la suite de tests on a des gens qui savent optimiser la suite de tests pour qu'elle aille plus vite on a des gens qui savent faire du, tracing en local en prod pour voir les problèmes de performance on sait, à peu près résoudre tous les problèmes qui vont nous arriver avec ce langage et ce framework, donc c'est pas exclu qu'on utilise des nouvelles technos mais il faut les utiliser pour les bonnes raisons et la raison du recrutement on n'a pas constaté que c'en était une on a réussi à grossir jusqu'à 250 devs Ruby on Rails. Sans trop de soucis sur le recrutement quelque chose que une observation que je peux partager c'est qu'on recrute quand même, des développeurs front-end uniquement donc ils ne font pas de Ruby on Rails parce qu'on constate que les développeurs full stack, dans la majorité des cas c'est les gens qui viennent du back-end qui font du front-end, et à un moment on a eu besoin de vraiment apporter plus de structures sur le front-end on était un peu la ramasse en termes de standards de code qualité etc et donc on a décidé de recruter et typiquement dans une équipe on a à chaque fois un développeur front-end dédié qui fait que du front-end quand on ouvre ses postes, sur des job boards etc on se fait on se proçoit une avalanche de candidatures externes, Ce qui n'est pas du tout le cas sur le Ruby on Rails, mais en fait, finalement, trier toutes les candidataires externes qu'on reçoit et faire passer les entretiens à ne serait-ce que 5% de ces gens, ça nous consomme beaucoup plus de ressources de trouver l'aiguille dans la botte de foin, la perle rare, que d'aller chasser des devs Ruby on Rails expérimentés dans d'autres boîtes de notre écosystème. Et nous, on est à peu près 50% de développeurs en France et 50% dans le reste de l'Union Européenne, donc il y a un écosystème relativement vaste.
Bruno:
Et puis preuve que t'es pas fermé à DeTechno c'est que ton équipe Data est plutôt, orientée Python donc t'as quand même laissé rentrer DeTechno c'est pas pur Ruby and Rails pour tout le monde Parce.
Quentin:
Qu'il y a une très bonne raison c'est là qu'est l'écosystème donc.
Bruno:
On va.
Quentin:
Pas leur demander de faire les bindings Ruby pour toutes les librairies qui vont avoir la chance et on n'arriverait pas à trouver des gens qui.
Bruno:
Savent le faire Et puis pour le coup ça te rajouterait de la compétition technique de tous les problèmes qui peuvent venir avec C'est ça.
Quentin:
Dans le fond les interfaces entre les équipes Web et les équipes data sont relativement limitées donc on arrive à s'en sortir de l'interface majeure, c'est que c'est nous les producteurs de données et eux qui sont branchés en aval de la base de données, et ils nous exposent un certain nombre d'endpoints HTTP pour qu'on aille chercher des résultats, d'algorithmes de machine learning, des prévisions, des classifications et tout le tralala, mais autant notre application web, elle doit avoir 3 ou 4 000 endpoints API, autant quand cette application web communique avec les API mises en place par la stack data s'il y a 20 endpoints API côté Python c'est un maximum, c'est une toute petite partie de la surface produit, émergée entre guillemets ok.
Bruno:
T'évoquais aussi tout à l'heure qu'un des avantages du monolithe, c'est que tes équipes, enfin que tes devs peuvent changer d'équipe de manière assez facile, parce qu'en fait, c'est même une grande technique et donc il n'y a pas de formation nécessaire. L'avantage de la feature team, c'est que tu as quand même aussi des personnes qui ont une connaissance métier, qui ont une certaine expertise, donc qui vont aussi apporter, pas uniquement leur expertise technique, mais aussi leur jus de cerveau, aussi à créer des features et à la faire évoluer dans le bon sens. Est-ce que ça c'est pas parce que tu vois je me dis que quand t'es dans un environnement monolithique du coup t'as la même techno pour tout le monde tout le monde a les mêmes règles de code tout le monde a la même façon de coder donc tu peux plus facilement avoir des gens qui vont s'intéresser au métier, et aux problèmes qu'ils essayent de résoudre mais ça rend du coup aussi leur changement d'équipe plus compliqué parce qu'ils sont très orientés sur un métier ces changements d'équipe ça arrive de manière régulière t'as peut-être même des règles qui disent que tu dois rester un maximum de temps dans une équipe.
Quentin:
Alors on ne met pas de maximum de temps sur le fond c'est ce que j'observe sur cette communauté Rubin Rails, c'est souvent des devs qui sont très portés sur le produit et nous on en est très friands on fait un produit qui est compliqué, certes on a le product manager et le designer qui sont là pour se pencher sur, les besoins du marché l'étude concurrentielle etc mais quand on implémente on n'est pas juste là pour dépiler du ticket implémenter ce qui a été spécifié la spécification est généralement, pas détaillé dans les moindres détails et du coup c'est aussi à chaque dev de consulter, de réfléchir de proposer pour avoir quelque chose qui selon lui collera le mieux aux besoins du client, sur le fait de changer d'équipe euh... Il y a un juste milieu. Moi, j'encourage les gens à être mobiles. Je pense que ça apporte beaucoup de travailler avec des managers, des PM sur des scopes produits ou avec des collègues différents. Typiquement, nous, on a vraiment deux utilisateurs. On a les experts comptables et leurs collaborateurs et les dirigeants. Schématiquement, l'expert comptable et ses collaborateurs, ils sont dans notre logiciel 8 heures par jour. Le dirigeant, il s'en sert 10 minutes deux fois par jour. Donc, ils ont un besoin très différent. Il y a les power users qui veulent une information dense. Un logiciel avec lequel ils sont productifs avec les raccourcis clavier etc, le dirigeant en fait on est à la limite du B2C, c'est des petites boîtes nos clients, il veut quelque chose qui soit intuitif quelque chose avec les mêmes fonctionnalités sur son mobile souvent. Mais le côté hyper productif c'est pas forcément son critère numéro un et du coup de se promener et de voir ses besoins différents on a aussi des équipes qui sont vraiment dans une phase d'exploration et d'autres qui sont vraiment dans une phase de stabilisation, on est capable de proposer de la variété en interne Je trouve que c'est une de nos richesses. Quand quelqu'un s'ennuie quelque part, on lui dit, va là-bas, il y a des challenges, c'est le Far West, on ouvre un nouveau marché, on fait un nouveau produit, on a besoin de ton expertise. Et au contraire, on a les gens qui construisent de l'expertise métier sur la comptabilité, sur la TVA, hyper profonde, et qui sont tout aussi précieux. Et ces gens-là, il faut les déplacer avec parcimonie. Il faut les déplacer, ça s'anticipe pour s'assurer qu'avant, ils aient transmis quelque chose à quelqu'un d'autre. La force aussi c'est qu'il reste dans les parages je préfère quelqu'un qui change d'équipe plutôt quelqu'un qui démissionne quand il change d'équipe ça crée un vide et quelqu'un va venir prendre cette place la nature horreur du vide mais cette personne qui prend cette place aura des questions et la personne qui vient libérer la place est encore dans les parages finalement.
Bruno:
Comment tu fais pour moi c'est quelque chose que je rencontre en ce moment dans certaines expériences dans des contextes qui ont du monolithe, c'est que tu peux te retrouver avec un avec quand même du code spaghetti comme on dit surtout quand il est ancien et toi tu m'as dit ça a commencé il y a 6 ans donc ça commence à dater quand même mine de rien, comment tu fais pour t'assurer que justement t'as pas une production de code pas forcément anarchique mais qui peut en tout cas petit à petit accumuler de la dette et que tu vas traîner au fil du temps ?
Quentin:
Accumuler de la dette, ce n'est pas une fatalité. La dette, c'est un moyen d'arriver à une fin. Et typiquement, c'est ce que je disais à l'instant, on a des équipes qui sont identifiées et qui ont littéralement une étiquette, une couleur d'équipe, qui sont en phase d'exploration. Et donc là, c'est OK d'accumuler de la dette, parce que si jamais on n'atteint pas le product market fit, on jette tout. Et puis, bon débarras. Et d'autres équipes qui, elles, ont atteint le product market fit, sont dans un endroit hyper clé du business où elles reçoivent, un million de page views par jour et elles, elles sont plutôt dans un mode où on vient résorber la tech debt, réduire les problèmes de friction, de friction de UX pour nos utilisateurs, améliorer les performances améliorer la stabilité pour tous les types d'entreprises que l'on gère, les petites, les grosses, les moyennes, donc il y a un moment pour accumuler la tech debt il y a un moment pour la résoudre, et on ne fait pas une fixette sur le fait de ne pas être endetté, ça fait partie du jeu la dette il faut savoir, c'est un outil comme un autre il faut le manier avec précaution, et puis dans le fond j'ai pas vraiment compris pourquoi avoir un système en microservice permettait d'avoir du code moins vieux ou pas de dette.
Bruno:
C'est surtout sur l'aspect code spaghetti parce que l'avantage du microservice c'est qu'en soit t'as des code base qui sont plus réduites donc t'as moins de chance d'avoir, des choses qui sont pas au bon endroit des codes qui sont pas suffisamment indépendants un peu entrelacés c'est vrai ça parce que finalement tu risques plus de reproduire, t'as plus de chance en microservice de reproduire les trucs à droite et à gauche, parce que forcément parfois des différences microservices ont besoin de faire la même chose et du coup ils le recréent mais tu vois comme t'as une code base qui est plus petite t'as moins de gens qui bossent dessus t'as moins de chance d'avoir des choses qui sont on va dire mal rangées quoi.
Quentin:
Oui alors à mon avis c'est comme tout il faut une gouvernance sérieuse sinon on risque d'avoir, pour moi le micro-service on a déplacé des appels de fonction à des appels réseau, et en fait si le service A il appelle B, C et que B, C il appelle chacun X, R, X, Z et tout le tralala on a le spaghetti code juste on le voit pas, mais il est là aussi et c'est ce que je disais un peu tout au début je pense qu'il n'y a pas de système magique parfait, dans les deux cas il faut une gouvernance sérieuse, il faut un plan il faut une stratégie, il faut investir parce que sinon si on laisse la nature faire son cours, on arrive dans l'assiette de spaghetti par les deux chemins.
Bruno:
Mais tu vois tu nous parles de gouvernance sérieuse de ce que je comprends toi ton système en fait il est plutôt de dire ta feature t'explores tu testes alors j'imagine que tu laisses pas les gens faire du code dégueulasse pour autant mais, il y a quand même une volonté d'exploration et puis une fois que t'as atteint ton market fit et que ton truc est stable tu vas commencer à cligner donc tu vois t'as quand même aussi une démarche où tu laisses les gens un peu explorer et tester de manière contrôlée, Mais du coup, c'est quoi cette gouvernance que tu as en place pour ce fameux contrôle, pour que ça respecte, je ne sais pas, un ensemble de critères qualité définis par une grande instance ?
Quentin:
Ça repose sur les managers, et ça repose sur la responsabilité individuelle de chaque dev. Il y a des grandes règles, même quand on est dans la phase d'exploration, il faut quand même écrire des tests. Parce qu'à partir du moment où il y a des utilisateurs, il faut des tests. mais. Est-ce que le data model doit être parfait de toute façon le data model parfait c'est une cible en mouvement et donc en fait, on peut pas se permettre de passer 6 mois à réfléchir à quel va être le data model parfait si jamais on atteint la réussite et la scale c'est plutôt on chip puis on y terre, c'est quelque chose qui est quand même relativement c'est un ownership qui est distribué donc ça nous arrive de tomber sur des endroits où on a une mauvaise surprise, dans une équipe il y a un binôme qui a fait un peu n'importe quoi, et on leur tape gentiment sur les doigts et on leur montre en fait t'avais pas bien lu la documentation, c'est pas comme ça qu'il faut faire d'ailleurs regarde t'as des problèmes de performance t'as des problèmes de stabilité etc. et les gens, Ils sont plutôt intelligents, ils jouent le jeu, ils disent ok, ça je vais refactorer, je vais utiliser tel composant en fontaine qui est commun, qui est testé, qui est battle testé, et sur le back-end, mon design de base de données, j'ai mis 90 colonnes, en fait je vais faire les choses un peu différemment. Mais on n'a pas de mauvaise surprise, parce que je pense qu'on a assez dieux différents qui regardent les différentes contributions de chacun, qui parfois mettent un commentaire mais qui n'est pas blocking sur la review, qui disent juste attention je vois que tu fais un truc un peu de gré, soit t'as le temps et tu t'en occupes maintenant soit tu t'en occupes plus tard, soit tu dis je m'en fiche mais tu prends tes responsabilités voilà.
Bruno:
Mais donc toutes ces, enfin j'imagine que t'as des rôles de leadev des rôles un peu seniors qui vont justement avoir un peu ce rôle de validateur, tous ces gens là en fait sont chacune dans leur squad et ont aussi un travail de délivrer quotidien où t'as des personnes dont c'est le rôle à 100% du temps de s'assurer que tout le monde produit du code comme une seule et même personne ?
Quentin:
On n'a personne dont c'est le rôle explicite à 100% du temps de faire ce que tu viens de dire, on a dans le dans le plan de carrière des contributeurs individuels un certain nombre de niveaux, junior confirmé senior on a senior 1, senior 2 et staff engineer qui est le dernier niveau aujourd'hui chez nous, et tous ces gens là ont des expectations de delivery au sein de leur squad et ce qu'on Ce qu'on se dit, c'est que plus ils sont hauts, plus ils ont un certain niveau de vélocité, et donc plus ils ont du temps à côté pour soit shipper plus, parce que c'est dans une équipe où il y a plus besoin de shipper, soit contribuer dans les fellowships à aider à définir les guidelines, à les mettre en place, à coacher les gens, à faire des reviews de pull requests... Et du coup, c'est eux qui, s'ils sont arrivés au niveau de seniors, l'attente au niveau du comité de promotion, c'est que ce soit des gens proactifs, qui connaissent bien les règles et les derniers standards, et qu'ils soient proactifs pour les faire à peu près respecter, en tout cas pour les faire rentrer dans le crâne de tout le monde. Que les gens la respectent ou non encore une fois chacun prend ses responsabilités si quelqu'un fait n'importe quoi, clairement la poulerie ça va se faire refuser, mais si quelqu'un dit, il y a une bonne raison pour dire là on a un projet urgent, il y a un client on le signe la semaine prochaine et il faut qu'on chie, en fait on va se donner les moyens de faire réussir cette chose là pour le client, et on va quand même mettre les choses au net derrière et là on a un petit peu de perte en ligne mais globalement ça fonctionne.
Bruno:
Question peut-être plutôt anecdotique qu'autre chose, mais donc tu nous parles de ces staff engineers qui vont apporter des guidelines. Toi, en tant que CTO, tu shippes encore pas mal de codes en production. À quel point est-ce que parfois, toi aussi, t'es rappelé à l'ordre sur ce que tu shippes par des staff engineers ou est-ce que comme t'es le CTO, même si tu fais un truc parfois un peu à côté, ça devient la norme parce que c'est toi le boss au final ?
Quentin:
C'est une très bonne question. C'est d'ailleurs pour ça que je fais plus de contributions dans des équipes produits. Je fais que des contributions sur des sujets de qualité, performance, etc. Parce que dans l'équipe produit, quand je dis que j'ai une idée, tout le monde l'apprend comme parole d'évangile, alors que je peux tout à fait raconter n'importe quoi. Donc ça, j'en fais plus. Dans mes contributions du quotidien, ça m'arrive de faire des changements dans le scope de certaines équipes, et c'est même un développeur tout simplement confirmé qui vient faire la review, et j'adore quand quelqu'un vient me faire un commentaire ou vient recaler ma pull request, parce que mon plan de test, il n'a pas géré tel cas, Parce que pour moi, j'ai l'impression d'être plutôt un bon développeur, mais pas toujours d'être un modèle de rigueur sur toutes les choses. Parfois, je suis aussi content de résoudre le problème tout de suite. J'ai quand même plus un ADN de petite start-up que de boîte de 250 devs, c'est quelque chose sur lequel je progresse, je change parce que je suis dans un environnement plus grand, mais je suis très attaché à ce sujet de vélocité, et d'avoir quelqu'un qui me rappelle à l'ordre pour me dire, il faut que tu respectes les règles, j'adore parce que ça crée ce climat de responsabilité et de confiance.
Bruno:
Est-ce que ce n'est pas aussi une bonne nouvelle que tu ne sois pas le meilleur dev de l'équipe ?
Quentin:
Oui, bien sûr.
Bruno:
Autre sujet, on a aussi un changement drastique qui a lieu dans notre métier en ce moment, avec toutes les IA génératives qui chamboulent un peu la manière dont les choses sont faites. Est-ce que le monolithe, dans ce contexte-là, je ne sais pas si vous utilisez, ou si tu forces l'usage déjà d'un, je sais pas de cursor je sais pas ce que vous avez en interne mais est-ce que ce monolithe a un avantage ou un inconvénient pour les IA génératives.
Quentin:
Donc on recommande à nos devs d'essayer cursor on a encore des gens qui sont sur IMAX, NeoVim et tout le travail là mais il y en a un certain nombre qui sont sur cursor et qui sont satisfaits moi le premier, la difficulté avec un monolithe c'est le contexte Windows on n'arrive pas à mettre les 35 000 fichiers dans le contexte Windows de Cursor pour qu'il nous fasse une suggestion, et ça viendra peut-être un jour mais on n'y est pas encore d'un autre côté, dans un contexte de microservices à partir du moment où le microservice il appelle autre chose, peut-être que cette autre chose devrait aussi être dans le contexte, du côté microservices je n'ai pas trop réfléchi parce que comme ce n'est pas mon domaine je m'en fiche un peu, donc on voit à mon avis comme tout le monde qu'il y a certaines tâches, certaines choses sur lesquelles les LLM sont très bons certaines choses sur lesquelles il y a encore un peu de marge de progression.
Bruno:
Mais tu vois, tu t'évoquais tout à l'heure aussi ces nouveaux standards que vous pouvez t'amener à créer, à mettre en place, et du coup à ne pas répliquer sur l'historique. Est-ce que du coup des outils comme ça peuvent justement te permettre de faire un déploiement d'un nouveau standard sur tout l'historique de la code base ?
Quentin:
Encore une fois, le sujet, c'est évidemment une question de coût, le fait de remettre la Côte d'Essentienne à un nouveau standard, mais c'est une question de venir perturber. On va introduire plein de changements, et ces changements, on ne sait pas si cette partie-là, si elle a 4 ans, s'il était aussi bien testé que ce qu'on teste aujourd'hui, et tout le tralala. Donc on pourrait si on distillait la chose sur un an en faisant 50 fichiers par semaine quand j'étais chez Booking.com ils ont un logiciel de template HTML qu'ils avaient développé en interne avant qu'il y ait les logiciels les fonctionnalités mainstream de template HTML, et ça gérait pas correctement le fait d'échapper les balises HTML et tout le tralala et du coup ils avaient un bot qui toutes les semaines je crois qu'ils disaient qu'ils avaient 800 000 templates qui n'étaient pas avec la bonne sanitisation, ils avaient toutes les semaines un bot qui allait, automatiquement ajouter le fait d'échapper les caractères dans tous les templates et du coup quand tu te promenais sur le site tout en temps tu voyais des balises HTML parce qu'ils avaient échappé deux fois ou que sais-je et il fallait signaler au bon bonhomme pour qu'incrémentalement on converge mais c'était peut-être un plan sur 10 ans donc dans le fond, aujourd'hui on ne constate pas que c'est un de nos top 10 problèmes le fait qu'il y ait ces différents standards dans la code base à partir du moment où on a réussi à avoir une source de vérité dans la documentation qui dit c'est ça le standard du moment. Et créer ce réflexe auprès des gens d'aller le consulter ou communiquer quand il a changé le fait que certaines parties soient plus vieilles c'est pas très grave, aussi parce que la cadence d'évolution de ces standards s'est quand même tassée ça a beaucoup évolué les 3-4 premières années ça s'est quand même tassé et plus ça va moins on en a de ce code des 4 premières années parce que c'est des features que les équipes viennent reprendre. Et quand elles le reprennent au bout de 4 ans, notre compréhension du besoin client a beaucoup évolué et souvent on repart sur une implémentation quasiment from scratch, on ne garde peut-être que la partie donnée dans la base de données, mais tout le reste, on le recrée et on migue les clients vers le nouveau système et on jette l'ancien.
Bruno:
Pour rester un peu sur le sujet d'IA est-ce que tu constates toi c'est quoi tes constats sur la qualité du code qui est généré est-ce que tu sais quelle est la proportion du code qui est shippé, qui est issu de ces outils-là. C'est quoi ton Tatech là-dessus ?
Quentin:
J'ai un point de vue hyper biaisé sur le sujet, parce que comme je ne fais pas de développement de produits, je ne fais pas d'endpoints de contrôleurs, de nouveaux modèles, je ne fais pas vraiment de crude au quotidien. Et là, je veux tout à fait bien entendre que ça apporte de la valeur, c'est un peu le next generation scaffold du MVC. Moi je suis beaucoup plus sur les modifications spécifiques de librairies qu'on utilise ou même de Rails, d'optimisation de requêtes SQL de paramètres post-grés etc, sur lesquels c'est à mon sens très spécifique et plus réplicable donc le LLM moi m'apporte personnellement moins de valeur, ça m'est arrivé cela dit quand j'ai fait des scripts qui viennent appeler des APIs Amazon, quand on écrit les tests il faut mettre tous les mocs de réponse et de type etc où il faut se palucher la documentation ou alors faire tourner le code en local 50 fois pour bien comprendre toutes les structures de données nested, le LEM apporte de la valeur parce qu'il nous sort l'output direct une fois de temps en temps l'output est complètement halluciné ça ne correspond pas du tout à la vraie structure donc un peu perdu mais une fois de temps on est quand même content d'avoir gagné une heure sur le sujet.
Bruno:
Et le gain sur ton équipe t'estime aujourd'hui que c'est indispensable qu'ils utilisent Cursor ou au final c'est bien pour certains mais pas pour tout le monde ?
Quentin:
Plutôt la deuxième option Je pense que j'ai des gens qui sont satisfaits de leur productivité sur la partie écrire du code. Et en fait, ce n'est pas ça qui est le plus time-consuming dans le développement au quotidien. C'est vraiment la phase de conception, la phase de compréhension du besoin produit. Et donc, écrire du code deux fois plus vite, si écrire du code, c'est que 15% de la quantité de travail, on gagne 7% de productivité. Ce n'est pas mal, mais ce n'est pas non plus incroyable. Donc il y a des gens, et puis on a aussi une hétérogénéité de savoir-faire dans l'utilisation de l'IA, des gens qui sont très à l'aise, des gens qui savent travailler de manière insynchrone, ils promptent, ils donnent le contexte, ils vont prendre leur café, ou ils vont prompter autre chose dans un autre contexte, dans une autre instance, et des gens qui sont très linéaires dans la manière de fonctionner, souvent un peu les vieux de la vieille, dont je commence doucement à faire partie, et du coup qui sont contents, ils se mettent dans leur tâche, on fait le machin, on fait tourner les tests, on y taire, et le LLM, comme il faut attendre 45 secondes, en fait c'est pas la bonne vitesse d'itération, on se déconcentre on va dire le journal et après on revient 45 minutes plus tard en disant ah c'est bon il a fini.
Bruno:
Et vis-à-vis des personnes les plus juniors de l'équipe est-ce que tu penses que ces gens là ne devraient pas utiliser l'LM ou est-ce qu'au contraire c'est un bon outil de progression.
Quentin:
Moi je pense que c'est un bon outil pour apprendre c'est un bon outil, il y en a plein qui viennent poser des questions dans le chat de GPT alors il fut un temps et peut-être encore aujourd'hui ça me fait parfois un peu grincer les dents parce que, si ChatGPT dit la bonne réponse 9 fois sur 10, il y a quand même 1 fois sur 10 ils apprennent des âneries il faut toujours challenger ce qu'on lit mais, je trouve que ça permet de progresser quand même tout seul pour poser une question. Comment tu ferais un algo qui fait ci ? Fais-moi une code review sur ça. Présente-moi tel concept. C'est quoi les ressources qu'il faut aller consulter ? Je pense que pour un junior, c'est plutôt un net avantage pour apprendre. Pas forcément pour produire. C'est pas le code du LLM qui va se retrouver dans le commit au final. Mais pour avoir un premier jet qui permet quand même de cerner à peu près le problème. 9 fois sur 10 ou 8 fois sur 10, c'est jamais parfait.
Bruno:
Pour terminer, je ne sais pas trop comment formuler ma question, mais en fait, de ce que je comprends, de ce que tu racontes, tu as une partie de ton équipe qui va par moment définir des nouveaux standards. Tu sens avoir une équipe quand même assez conséquente, plus de 200 devs, ça commence à être pas mal, qui globalement respecte plutôt bien les standards, travaille de manière propre. Donc la première partie de ma question ce serait comment tu fais pour parce que tu nous disais que la responsabilité elle est partagée auprès de tout le monde comment tu fais pour que cette responsabilité elle soit vraiment partagée et pas diluée et que du coup au final plus personne s'en occupe et tu nous parles aussi du, on explore, on teste et puis quand c'est un peu sec on commence à cleaner et à refactorer, comment tu fais pour t'assurer que ton équipe elle a bien elle continue à avoir du temps pour cleaner derrière mais qu'il n'y a pas quelqu'un derrière qui vient constamment leur dire maintenant il faut shipper ça, il faut shipper ça, tu vois, pour garder le temps, pour remettre au propre. Ce que tu nous décris, moi ça me semble presque un monde réré, en fait on se dit c'est top, mais donc comment tu fais pour maintenir tout ça ?
Quentin:
Alors sur la première partie de ta question, sur le côté de la responsabilité, elle est partagée mais elle est, sur les standards de code de la stratégie de test, en fait il n'y a pas 100 personnes dans la fellowship. Il y en a une poignée. On a un sujet en ce moment, typiquement, on constate que ce serait bien que dans chaque fellowship, il y a un chef, un leader, qui prenne la responsabilité de trancher, qui sorte une roadmap, etc. Parce que parfois, quand c'est trop... Même au sein de cinq personnes, s'il n'y a pas une personne qui est affichée comme responsable, parfois, pendant deux mois, il ne se passe rien. Et on se dit qu'on passe peut-être à côté de quelque chose. Donc c'est ouvert à chacun, jusqu'à une certaine taille, de rejoindre ce genre de fellowship. Il y en a moult. Mais c'est justement, on ne veut pas qu'il y ait 15 personnes, parce qu'on sait que les réunions à 15, on ne produit rien. Si on descend en dessous de 2-3 personnes, on va faire des appels à candidats, voilà. Et puis, il y a des gens qui font pendant un an la fellowship testing, après, un an après, pendant un an, ils font la fellowship base de données. Donc, c'est aussi l'opportunité d'apprendre. Mais ce que je recommande aux nouveaux qui rejoignent Penny Lane, c'est pendant les 6-12 premiers mois au moins, se concentrer sur le scope de son équipe pour maîtriser le périmètre produit, maîtriser la manière, les standards actuels tels qu'ils sont avant même de commencer à penser à contribuer aux standards. On a des gens incroyables qui au bout de 3 mois font des contributions incroyables aux standards, mais c'est l'exception. Il y en a beaucoup, il leur faut 6-12 mois pour rentrer dans le périmètre produit et tout le travail avant de commencer à prendre des responsabilités ailleurs. Donc jusqu'à présent, on arrive à avoir sur nos sujets importants une poignée de personnes qui viennent définir ses règles et faire avancer, le standard.
Bruno:
Mais vous n'avez pas encore des personnes dont c'est spécifiquement le rôle et qui sont objectivées dessus et compagnie. C'est vraiment un truc que chacun porte de son propre chef.
Quentin:
Tout à fait. Après, sur notre population, on a deux staff engineers aujourd'hui. Ils sont chacun dans une demi-douzaine de fellowship.
Bruno:
Forcément.
Quentin:
Pour revenir sur ta deuxième question, j'ai déjà oublié.
Bruno:
Comment tu fais pour t'assurer que tu as bien le temps qu'il faut pour remettre au propre derrière ?
Quentin:
Alors, je dirais plusieurs choses. Je pense qu'il y a une culture produit forte, de de comprendre ces enjeux. On met beaucoup en avant dans nos objectifs côté tech et produit, le fait de fournir un logiciel de qualité pour nos clients. Quand on a 500 000 clients, on ne peut pas se permettre de faire n'importe quoi. Et du coup, le fait de passer du temps sur des éléments d'aide technique, c'est une composante de la qualité la qualité c'est pas juste réparer le bug quand il arrive c'est aussi éviter que les nouveaux bugs arrivent et tout ça donc les, on a même un arrangement fort c'est à dire qu'au sein d'une équipe si on définit un objectif de backlog de bugs et quand ce backlog quand le backlog actuel est au dessus de l'objectif l'équipe redirige plus de ressources vers la résolution des bugs, et du coup mécaniquement le product manager va voir sa vélocité et se réduire s'il a trop de bugs dans son backlog donc il a un incentive à investir en continu de la bande passante pour, qu'il n'y ait pas trop de bugs, pour qu'il puisse shipper de manière prévisible des nouvelles features, En plus de ce système d'incentive un peu bête et méchant, il y a quand même un aliment de culture. On travaille ensemble sur ces problèmes de qualité. On voit aussi que les clients, ils nous mettent un score, un NPS pourri si on a des problèmes de qualité. Du coup, les product managers veulent que les clients soient satisfaits, donc ils investissent dans la qualité via ce moyen. Je pense qu'il y a aussi une question de bon goût. Finalement, quand on est dev et qu'on bosse sur un système où il y a beaucoup de techniques, on n'avance pas. À chaque fois qu'on ship quelque chose, on fait un pas en avant, deux pas en arrière. C'est hyper désagréable donc au contraire c'est presque les premiers à dire, là on a shippé un premier truc est-ce qu'on peut passer deux semaines à se poser, à regarder où est-ce qu'il faut qu'on investisse un peu de temps pour remettre les choses au propre.
Bruno:
Donc ça veut dire que ton équipe produit, j'imagine que vous avez aussi un ou une CPO Lui son objectif c'est pas de shipper de la feature c'est de produire de la qualité au final.
Quentin:
L'objectif c'est d'avoir des clients qui sont satisfaits donc ils sont satisfaits parfois avec des nouvelles fonctionnalités parfois avec de la stabilité mais autant quand on était il y a 6 ans, nouveau sur le marché et nos clientèles c'était des early adopters ils pouvaient tolérer que les choses fonctionnent pas ils savent qu'ils travaillent avec une start-up, et ça fait partie du jeu maintenant quand on travaille avec des grosses boîtes des gros cabinets comptables, eux ça les amuse pas du tout quand on a un downtime, un bug, un problème donc le curseur s'est déplacé pas tout à fait de l'autre côté, on est toujours attaché à avoir de la vélocité, mais quand même plus de l'autre côté ?
Bruno:
Question anecdotique qui n'est pas forcément dans le sujet parce qu'effectivement vous avez ces power users qui sont des experts comptables, qui ont quand même ces périodes de clôture un peu précises est-ce que ça veut dire qu'il y a quand même certains trucs où vous essayez de ne pas shipper pendant ces périodes là aux alentours de décembre, janvier, février et puis mai, juin, juillet, pour essayer de minimiser les risques pour ces gens là qui utilisent j'imagine massivement votre outil à ce moment là.
Quentin:
Alors oui et non c'est à dire qu'il y a certaines fonctionnalités aussi qui ne sont utilisés que pendant cette période fiscale qui est de janvier à fin mai et donc, si on est en train de travailler sur quelque chose en janvier soit on le shippe en janvier, soit il faut attendre 12 mois pour avoir du signal donc en fait parfois on a quand même envie de shipper on sait que ça va être un peu, hasardeux, il faut être hyper réactif sur le pont pour répondre aux clients qui ont un problème les bons systèmes d'observabilité de monitoring, mais parfois on peut juste pas se permettre d'attendre 12 mois pour avoir du retour client mais il y a des moments, où on fait plus attention rien que tous les mois au moment des échéances de TVA on évite de toucher au système de TVA parce que c'est là où il va y avoir un gros volume et donc c'est on peut vite perdre des copains et perdre des clients, et lors de quelques événements typiquement il va y avoir la semaine prochaine le congrès national de l'ordre des experts comptables on a un stand pendant deux jours, et on s'affiche comme un acteur innovant de la profession comptable on évite que le site soit down pendant ce moment là donc les modifications, les changements de version de rail les upgrades de base de données etc on décale.
Bruno:
Absolument ok, top, merci beaucoup Quentin pour cet échange, j'aurais deux dernières questions pour toi qui sont les questions à rituel du podcast la première c'est est-ce qu'il y a un contenu que tu voudrais partager avec l'ensemble des auditeuristes.
Quentin:
Oui la documentation Postgre.
Bruno:
Ok pourquoi spécifiquement la doc de Postgre ? Tu trouves qu'elle n'est pas suffisamment maîtrisée ?
Quentin:
Je trouve qu'elle est très très riche. Je ne sais pas, elle fait à mon avis des centaines ou des milliers de pages. Donc c'est difficile de la lire comme un roman le soir, même si ça peut aider pour s'endormir. Mais je trouve que c'est une techno de dingo. Nous, on a construit notre boîte dessus. On a encore 100% de nos données et 100% de nos 500 000 boîtes qui sont dans une seule base de données Postgre dans le cloud. Et avant de se poser des questions il faut que je charge, il faut que je fasse du MongoDB distribué, tout le tralala en fait les gars, et les femmes, utilisez Postgre après plus ça va, plus il faut lire la doc, mettre les index ah il y a tel problème, il faut que j'organise ma donnée différemment etc, mais ça vous mène, quand même relativement loin une boîte avec 500 000 clients c'est déjà pas mal.
Bruno:
Oui j'ai reçu quelques experts notamment une grande experte de Postgre Laetitia Avraud qui est venue sur ce podcast et effectivement c'est un outil qui a une capacité de résistance avant d'en arriver au bout, soit il faut faire les choses très mal et du coup au bout d'un moment ça marche plus, soit c'est que t'es un niveau tu fais partie des GAFAM et là t'as besoin d'aller taper ailleurs.
Quentin:
Oui nous on en est à un stade où on commence à avoir pas mal d'expertise acquise en interne sur cette techno, mais on n'a pas vu le bout et on a encore plein de leviers pour continuer à avoir un logiciel de bonne performance at scale, donc je trouve que c'est la techno, qui vous élimine déjà 50% ou 80% des problèmes au début de la boîte.
Bruno:
Clairement top et pour terminer la question la plus importante de ce podcast, est-ce que tu es plutôt espace ou tabulation ? Plutôt espace plutôt espace, très bien, merci beaucoup Quentin merci Bruno, et merci à tous d'avoir suivi cet épisode jusqu'au bout, voilà, comme quoi on n'a pas toujours besoin de suivre les tendances et de faire du microservice dans tous les sens le monolithe a aussi de grands avantages et de beaux jours devant lui, donc j'espère que ça vous a décomplexé si vous êtes sur un monolithe si vous êtes sur un monolithe un peu plus difficile où ça ne se passe pas toujours très bien j'espère que les conseils de Quentin vous aideront à voir la lumière au bout du tunnel et que c'est. Possible d'y arriver et que ce n'est pas parce que c'est un monolithe que les choses ne fonctionnent pas. En tout cas, moi, je vous remercie toujours de partager ce podcast autour de vous. N'hésitez pas à aller checker dans les liens en description de le Tipeee si vous voulez contribuer à ce podcast et l'aider à grandir. Je vous remercie beaucoup, je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine et d'ici là, codez bien !
