Le Grand Saut Technologique

Bruno:
Il paraît que Rome ne s'est pas faite en un jour, mais chez Belive, on essaie de la reconstruire en trois ans. Quand tu reprends 20 ans d'héritage technique avec des services dupliqués sur trois continents, du Shado IT à tous les étages, du PHP plein les tuyaux et un RadarTech qui clignore dans toutes les directions, tu sais que tu pars pour un Refacto, mais pas un petit, un Refacto total. Mais alors, comment on modernise une boîte codée qui tourne sur des stacks hétérogènes ? Comment on refond un produit tout en redessinant les rôles, la culture et les pratiques ? Et surtout, combien d'incidents faut-il pour enfin y voir clair ? Pour répondre à ces questions de tectonique, je ne reçois pas le corbusier, mais il s'y connaît en reconstruction. Antoine, bonjour.

Antoine:
Bonjour.

Bruno:
Alors Antoine, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?

Antoine:
Bien sûr. Donc Antoine Jacouto, je suis actuellement CTO de Bilibre. Ça fait un petit peu plus de deux ans que je suis dans cette boîte de musique. Et puis j'ai fait pas mal de retail ces dernières années, je suis passé par VP, Vente privée, Mano Mano, Sundae qui est une fintech et plein d'autres choses, je ne vais pas revenir, en arrière ça fait 25-30 ans que je suis dans la technologie d'une façon ou d'une autre donc voilà.

Bruno:
Ok, donc tu es effectivement arrivé chez Belive il y a quelques temps ? Tu vas nous parler d'un projet de refacto qui est encore en cours chez Belive, mais qui est un refactoring de l'extrême, j'ai envie de dire, parce que ce que tu m'avais décrit, c'était quand même assez colossal. Avant de plonger sur comment est-ce qu'on fait un refactoring, la question aussi, c'est comment est-ce qu'on en arrive à la décision de faire un refactoring ? C'est quoi les constats ? C'est quoi le moment où on se dit, OK, là, en fait, ça ne marche plus, il faut refaire ?

Antoine:
Oui, alors pour ça, je vais te donner un petit peu de contexte sur ce qu'est Believe et ce qu'est Believe. Donc Believe, c'est une boîte de musique avant tout. Donc boîte de musique, ça veut dire quoi ? Ça veut dire qu'on accompagne les artistes et on les développe à chaque étape de leur carrière. Donc le but, c'est d'avoir une offre end-to-end à disposition de nos artistes et de nos labels. Offre donc traditionnelle de label management mais également une offre numérique avec des produits à valeur ajoutée on pourra en discuter un petit peu après on fait des choses assez rigolotes malgré ton introduction qui fait peur on fait des choses assez, exceptionnelles au sens premier du terme chez Bilibre. Donc Bilibre c'est boîte française créée comme tu l'as dit il y a 20 ans et qui s'est créée autour d'un coeur technologique, basé sur deux produits à l'époque avec le pari de se dire que l'écoute de musique ne se ferait plus via des CD, mais plutôt via du numérique. Donc à l'époque, c'était plutôt iTunes ou des choses comme ça, il n'y avait pas encore le streaming. Et donc ce cœur technologique était basé sur deux scopes fonctionnels qui étaient la gestion des royalties et donc le paiement des royalties artistes et la supply chain de distribution, donc distribuer la musique sur les plateformes. Aujourd'hui, on travaille avec plus de 200 plateformes. À l'époque, évidemment, il y en avait beaucoup moins. Voilà. Donc ce cœur, Ça a été construit il y a une vingtaine d'années. Ça fonctionnait très bien, on était assez précurseurs et on est toujours sur beaucoup de produits orientés musique chez Bilibre. Mais il n'empêche que l'ADN historique de Bilibre, c'est un ADN musique. Ce n'est pas un ADN tech. Donc étant précurseurs sur ces technologies, on les a développés, on les a maintenus et on n'a pas forcément cherché à rajouter de la feature ou à se dire comment est-ce qu'on pérennise finalement une architecture qu'on a développée il y a 10, 15, 20 ans. Et on s'est retrouvés en fait il y a quelques années, à peu près 3 ans, en forecastant l'état de nos produits actuels et l'évolution du business. On est arrivé à la conclusion qu'en fait on ne pourrait plus faire fonctionner notre business avec les produits qu'on a aujourd'hui et avec les SLA qu'on s'était mis en termes par exemple de paiement de royalties ou même de distribution de la musique. Moi, je suis un artiste, je distribue un album, je n'ai pas envie d'attendre deux mois avant qu'il arrive sur les plateformes, évidemment. Donc, on va dire que le facteur déclenchant de la transformation, ça a été la réalisation que la plateforme digitale telle qu'elle était il y a trois ans ne pourrait plus rendre le business dans trois ans.

Bruno:
OK. Quand on parle de refacto, parfois, on a aussi l'image de se dire que pendant qu'on fait le refactoring, on n'a plus aucune nouvelle feature qui va sortir. Donc c'est pour ça qu'on essaie parfois de faire en sorte de ne pas tout refactorer d'un coup parce qu'il faut quand même que les produits continuent à avancer. Là, quand Belif se met dans cette position de se dire on va devoir tout refaire, est-ce qu'il y a une optique de se dire on ne sort du coup plus rien pendant X années le temps de faire le refactoring ? Ou on essaie quand même de développer de nouvelles choses en même temps qu'on refait derrière ?

Antoine:
Alors, c'est toujours, c'est la question à chaque fois qu'on démarre une grosse transfo. Pour être honnête, en fait, on est arrivé à un moment où sortir une nouvelle fonctionnalité un peu structurante, on ne va pas dire on va changer les couleurs de bouton ou autre, mais une vraie fonctionnalité un peu structurante prenait tellement de temps qu'en fait, on ne s'y engageait pas. Prenait trop de temps parce que justement on a eu le poids d'une dette, technique qui est extrêmement forte donc en fait la décision de se dire est-ce qu'on arrête de la feature pour transformer ou est-ce qu'on se garde 10, 20, 15, 30% pour faire de la feature, grosso modo elle s'est pas tellement posée puisque de la feature on avait énormément de mal à en faire, en dehors du day to day alors en revanche la décision qu'on a prise c'est que quand on a commencé à faire la discovery sur comment on allait se transformer, il y a quelques scopes fonctionnel où on s'est dit, il faut tout refaire. Et donc à ce moment-là, on a dédié des équipes à tout refaire from scratch. Et donc là, on peut considérer qu'on refait complètement de la feature, puisque le but, ce n'était pas de refaire ISO en termes de fonctionnalités, mais c'était de recréer en rajoutant les features dont on avait besoin depuis X années. Donc en gros, on a fait les deux. On a transformé et à côté, démarré from scratch, de l'AriFacto et des nouvelles fonctionnalités.

Bruno:
Et le fait que par le passé vous n'arriviez plus à sortir de la future, ça, ça n'avait pas été relevé comme étant un indicateur suffisamment important qu'il y ait un truc à changer ?

Antoine:
Non, parce qu'en fait, si je prends la masse des produits qu'on a, on va dire que 80% chez nous, c'est ce qu'on appelle du core product. Donc, ce n'est pas des produits forcément à forte valeur ajoutée métier. Tu vois une supply chain ça nous rapporte pas d'argent en soi en revanche sans supply chain on ferme la porte, on ne peut plus faire notre métier donc c'était surtout la partie des corps productes sur lesquelles on n'arrivait plus à itérer pour ajouter la fonctionnalité à côté de ça, donc je te parle de masse je ne te parle pas de revenus etc, c'est vraiment la masse en termes de code et de produit à côté de ça on a 20% de produits qui sont de la pure innovation, où on est les seuls au monde ou quasi les seuls au monde à le faire, qui sont des produits sur lesquels on travaille avec pas mal aussi de data science, de... Comment développer l'audience de nos artistes et nos labels sur les plateformes de streaming, que ce soit en utilisant les fonctionnalités, en massifiant l'utilisation des fonctionnalités que les plateformes peuvent proposer, en déclenchant des campagnes marketing industrialisées, etc. Ça, c'est des features qui ont été créées relativement récemment, il y a peut-être six ans, et qui étaient beaucoup moins engluées dans la dette technique historique de BILIF. Donc en fait cette partie là a toujours fonctionné puisque tout simplement elle a été plus jeune.

Bruno:
Et donc comment est-ce qu'on se lance dans un projet de refactoring aussi massif ? J'imagine qu'on ne part pas juste avec sa bite et son couteau comme on dit. Il y a quand même un travail de préparation. Comment est-ce que tout ça a été structuré ?

Antoine:
Voilà, question complexe. Alors déjà, il a fallu s'accorder sur le diagnostic et le constat de l'état de nos différentes plateformes. Dans la transformation, quelles étaient les étapes les plus urgentes à faire et qu'est-ce qui était plutôt du long terme ? La première décision qui a été prise, c'était de se dire, on met tout sur le cloud. Pourquoi ? Parce qu'en fait, on était... Alors, le jeu, ce n'est pas de se dire pourquoi le cloud versus on-prem. Le jeu, c'est de se dire, on était massivement on-prem, mais sans aucune industrialisation. Et se dire, OK, comment est-ce qu'on réindustrialise ce qu'on a on-prem ? C'est faisable aujourd'hui. Franchement, même l'industrialisation physique, elle se fait. Le problème, c'est comme on n'en avait pas, il fallait tout construire. Et tout construire, ça nous aurait pris deux ans. Et donc, on avait besoin d'accélérer. Donc, la décision a été prise de migrer vers le cloud. Ça, c'est la première, on va dire, c'est le premier élément du storytelling, qui est un peu le trigger de la transformation et qui a tiré tout le reste. Après, c'est évidemment, c'est beaucoup d'organisations, c'est un vrai programme, nous c'est un programme qui aura duré deux ans en termes d'exécution, trois ans dans sa totalité, un peu plus d'ailleurs, trois ans et un quarter. Donc là, ce qu'il faut regarder, c'est déjà, est-ce qu'on a la bonne organisation, pour le faire, est-ce que les ways of working fonctionnent, est-ce qu'on a une bonne collaboration tech-tech, tech-product, product-business. Enabler, design, etc si ce n'est pas le cas comment est-ce qu'on réorganise, et surtout comment est-ce qu'on se réorganise un pour la phase de transition, qui va être le démarrage de la transformation tout en ayant aussi une organisation cible parce qu'on ne va pas se réorganiser non plus de compte en comble tous les deux ans. Avec un discours évidemment qui est entendable par les équipes, est-ce qu'on a le bon casting aussi parce que qui dit transfo dit sûrement aussi potentiel de technologie est-ce qu'on a des gens qui sont qui sont justement assez généralistes, pour pouvoir sauter d'une technologie à une autre ou est-ce qu'il faut qu'on remplume le casting avec des gens qui viennent de l'extérieur sur des technos qu'on veut implémenter, etc. Donc évidemment, le fait est qu'on n'a jamais le casting parfait. Donc on a ramené aussi des gens de l'extérieur pour nous aider. On a revu complètement l'organisation tech. On est revenu à des choses qui sont beaucoup plus proches des standards dans l'industrie, un peu... En gros Spotify-like, dans le système de Tribus, Squad, etc., avec des index produits clairement identifiés. Et surtout, on s'est mis en miroir avec l'organisation de produits, ce qui n'était pas du tout le cas dans le passé. En fait, l'organisation de produits chez Believe, elle s'est spin-off un petit peu comme l'immaculée conception, sans avoir forcément, il y a quelques années, une orientation véritablement produit, ni une description véritablement de ce que c'était le produit chez nous. Ce qui n'a pas empêché le fait que ça marche mais ça ne marche pas dans une période de transfo et à l'époque le produit d'ailleurs l'organisation produit était aussi l'organisation Ops, donc les opérationnels. Donc on a rationalisé tout ça en faisant une organisation produit pure product, mirorée avec une organisation tech et derrière avec les équipes Ops business etc et donc voilà après on pourra dibdaler sur les différents sujets mais c'est beaucoup d'organisations beaucoup de sujets humains, et beaucoup d'inconnus en fait il faut aussi se dire on démarre et on ne sait pas forcément en fait on est là aujourd'hui on veut aller là-bas ça on sait en fait ce qui est important c'est avoir le cap la route honnêtement on n'est jamais trop sûr et il.

Bruno:
Y a peut-être quelques petits détours quelques petits.

Antoine:
Il y a des détours tant qu'on ne revient pas en arrière c'est bien mais il y a forcément des tours c'est impossible de tout prévoir, après encore une fois comme on n'avait pas forcément pris soin pendant pas mal d'années de l'intégralité de nos assets il y avait aussi une perte de connaissance il y avait des scopes sur lesquels franchement on n'était pas sûr de ce qui tournait et surtout de comment ça tournait donc en plus c'est un super exercice parce que ça nous permet de réapprendre, et de comprendre ce qui tourne chez nous et comment ça tourne. Voilà. Et tout ça, ça prend du temps. Et surtout, on ne sait pas quel loup on va lever. Donc, en fait, la route, je ne la connais pas bien.

Bruno:
Pour revenir sur ces sujets d'organisation, ce qui est déjà intéressant, c'est que de ce que je comprends, il y a une refonte d'organisation globale de l'entreprise et pas uniquement de la tech. C'est-à-dire que tout le monde se met en ordre de marche pour ce travail de réécriture et de reconception au final globale de l'entreprise dans sa totalité, mais ce qui est intéressant dans ce que je sens me comprendre c'est que c'était plus comment est-ce qu'on peut tous se mettre en ordre de marche pour que cette réécriture se passe dans les meilleures conditions plus que, l'organisation précédente est aussi ce qui nous a amené dans cette situation, on peut dire entre guillemets catastrophique c'est-à-dire que plusieurs années d'écriture de code, sans architecture globale sans réécriture sans vision de maintenabilité globale donc c'était pas un changement parce que ça fonctionnait pas c'était un changement pour s'adapter à ce nouveau type de projet.

Antoine:
Ouais tout à fait parce que Believe fonctionne très bien c'est un business qui fonctionne très très bien avec des gens assez brillants en fait on sait, c'est un peu le cercle vicieux c'est à dire que il y a un moment quand tu étais frustré par l'écosystème dans lequel tu travailles parce que j'en sais rien t'es on-prem il te faut 3 semaines pour un NVM etc, tu arrives tu te débrouilles pour être le plus autonome possible et avoir le moins d'adhérence possible au reste de l'écosystème dans lequel tu es et parce qu'il faut qu'on aille vite tu vois l'industrie en plus d'un truc de la musique et surtout dans le digital ça, aujourd'hui ça change tout le temps il y a encore beaucoup d'inconnus aussi puis avec l'arrivée de l'IA c'est encore un autre sujet et donc et donc Il fallait qu'on avance, qu'on délivre, etc. Et donc, mécaniquement, l'organisation s'est auto-silotée pour justement pouvoir aussi délivrer ce qu'on attendait d'elle. Et donc, ça a rajouté de la complexité quand on a commencé à se dire maintenant, on va se transformer, on va harmoniser. L'harmonisation même des pratiques, ça a été extrêmement compliqué. C'était très compliqué d'éduquer les gens à la nécessité de le faire. Parce que ça faisait des années, ça marchait très bien dans leur scope simplement, il faut prendre ton bâton et expliquer que ça marche très bien dans ton scope mais en fait massifier ces ways of working ou ces façons de travailler, ne fonctionne pas à l'échelle ça ira à l'encontre de ça donc il faut réinventer un nouveau modèle qui soit global, qui soit scalable donc ce que tu dis est vrai.

Bruno:
Sur ce démarrage aussi du projet, vous êtes vraiment lancé dans le projet en mode que tu parlais tout à l'heure de changement de techno, de ce qu'on a les bonnes personnes et autres, c'est-à-dire que vous êtes parti vraiment en mode page complètement blanche, c'est-à-dire que vraiment on ne se donne aucune restriction ou vous aviez quand même en vous disant on va quand même rester un peu dans tel contexte technologique ou ce genre de choses ?

Antoine:
Alors, on ne s'est pas donné beaucoup de restrictions, pour être tout à fait honnête. En revanche, on a restreint un petit peu le champ de bataille, on va dire. Comme je te disais au début, la première décision, c'était de se dire, on met tout sur le cloud. En gros, à l'époque, 80% des workloads étaient on-prem, 18% sur Amazon, et 2% entre l'OVH, du H2O, des machins. Et on s'est dit, bon, on va rebooter. et donc si on reboot on va chez un fournisseur qui n'est pas chez nous en l'occurrence GCP donc en fait on met on met tout sur GCP donc ça c'était la première chose. Et sur la taille du champ de bataille donc il y avait la migration, Donc, sujet plutôt technico-technique. On rifacto au fil de l'eau, on est un peu opportuniste. Et il y avait la partie modernisation. Donc, modernisation, on s'est focus sur deux tracks, qui étaient la gestion des royalties pour nos top artistes. Donc, top artiste, ça veut dire un contrat très compliqué et très différent pour chaque artiste. Donc, en termes de gestion des royalties, on a tout un flow et tout un moteur qui est extrêmement complexe. Et donc, c'est le premier sujet qu'on a commencé à attaquer lors de la transpo. Deuxième, c'était la supply chain. Notre supply chain, elle fonctionne bien, mais elle est vieille. Elle est peu observable. C'est-à-dire que quand un asset arrive dans notre supply chain, en fait, c'est très difficile de savoir à quel moment il est de cette chaîne. Et surtout pareil il y a de la complexité aujourd'hui grandissante sur la vérification des assets qu'on ingère, est-ce qu'un jour on va vouloir détecter de la musique créée par IA ou pas ou est-ce que c'est le job des DSP donc des plateformes de streaming mais en tout cas toujours est-il qu'on avait une plateforme une supply chain qui était plutôt modulaire donc très compliqué de rajouter, des modules de vérification avec une plateforme d'encodage aussi assez vieille, je pense qu'il y a encore quelques mois on tournait sur un FFMPEG de il y a 15 ans. Donc et autre sujet non des moindres lié à la supply chain c'est que Believe c'est donc une boîte française mais c'est surtout un groupe international et c'est une boîte qui progresse beaucoup via des acquisitions, et donc des boîtes qui font un métier qui est semblable à celui qu'on fait on en a deux ou trois dans le groupe et l'intérêt c'était aussi de se dire on va profiter de cette transformation pour recréer des assets qui soient non plus dédiés à Biv mais dédiés au groupe, Avec un modèle de sassification, on va dire, tu vois, on appays tout, le front, c'est comme du sass, et en fait, ça peut s'adapter aux différentes verticales, tu vois, du groupe. Et donc, voilà.

Bruno:
Ok. Et dans ce... Je trouve ça quand même assez fascinant de se dire que tu te lances dans un... En fait, ce n'était pas juste du refactoring pour cleaner le code, c'est-à-dire qu'il y a quand même aussi, on va dire, une reconception. Des services en tant que tel, c'est-à-dire c'est pas juste faire en sorte que ce soit plus moderne et mieux écrit, c'est aussi, il y a peut-être aussi même des redécoupages, des choses qui ont été regroupées, d'autres qui ont été séparées, des paradigmes un peu différents qui ont été implémentés ?

Antoine:
Ouais, en fait, à l'époque, il n'y avait pas vraiment, il n'y avait pas vraiment de vision d'archi, d'entreprise ou même de vision technologique pour être tout à fait honnête. Donc au moment de la transphose ça fait partie des premiers sujets alors c'est peut-être pas les premiers mais en tout cas dans les premiers sujets il y a eu plusieurs choses, il y a eu déjà, démarré un TechRadar, on n'avait pas de TechRadar donc en gros tu vois on voulait faire du PubSub, ça pouvait être du Rabbit, du Kafka, du PubSub de GCP et que sais-je tu vois, donc il y avait beaucoup de... ça pouvait.

Bruno:
Être différent d'une équipe à une autre.

Antoine:
Et c'était différent d'une équipe à une autre tel sujet on pouvait l'adresser de trois façons trois façons différentes, etc. Donc, on a commencé à mettre en place un techranard, ne serait-ce que déjà pour recenser tout l'existant et ensuite prendre des décisions sur qu'est-ce qu'on garde, qu'est-ce qu'on supprime et si on supprime, comment est-ce qu'on va d'averber. Donc là, on va dire que c'était pour poser le cadre des outils technologiques, langage inclus, agilité incluse, etc., etc. On a également décidé d'introduire Java en tant que deuxième langage. Historiquement, Bidif, c'est du full PHP. Nos acquisitions ne font pas de PHP en plus, donc on a beaucoup d'autres langages dans le groupe. Introduire Java pourquoi parce que et ça ça a été ça avait été discuté à l'époque beaucoup avec le métier et avec les ops c'est que on a des cas d'usage qui se prêtent parfaitement à faire une architecture événementielle et, pourquoi Java plutôt qu'autre chose en tout cas déjà pourquoi pas PHP parce que PHP et l'event c'est pas tip top en cours de consommation on est d'accord, et pourquoi Java et pas du Go ou autre parce que Java c'est quand même beaucoup plus simple de trouver de l'expertise, entre guillemets, que Go.

Bruno:
Donc, quand tu dis que ça a été un deuxième langage, c'est-à-dire que PHP reste votre techno principal, ou du coup, vous avez inversé la tendance ?

Antoine:
Non. Aujourd'hui, PHP reste notre techno principal. Il y a, les produits qu'on redéveloppe from scratch, à 90%, sont redéveloppés sous Java, parce que justement, c'est des produits qu'on développe dans le cadre d'une architecture événementielle. Le but n'est pas du tout de remplacer PHP, d'autant plus qu'on a de la vraie expertise PHP maison, donc ça n'aurait aucun intérêt de le faire. Le but, c'est simplement d'avoir le choix selon les besoins. Et ensuite, si on doit redévelopper un produit et que, ma foi, il n'y a pas de nécessité qui soit dans l'un ou l'autre du langage, en fait, l'équipe doit décider avec son expertise maison. Donc, c'est agrandir un petit peu le spectre des choix.

Bruno:
Mais tu viens quand même de dire que 90% des produits que vous redéveloppez, vous choisissez plutôt Java donc il y a quand même une la tendance semble faire que c'est Java qui va prendre le pas sur...

Antoine:
Non je pense qu'on va arriver à moitié-moitié parce qu'il y a beaucoup de choses il y a quand même 20% de produits qu'on redéveloppe en scratch en PHP et il y a aussi plein de produits qu'on redéveloppe pas, qu'on refacto et qu'on garde en PHP et qu'on fait évoluer en PHP et potentiellement des spin-off de ces produits seront faits en PHP donc moi ma vision là-dessus c'est que je pense plutôt qu'on sera aux alentours de 50-50. Il n'y a aucune raison aujourd'hui de supprimer PHP Nostak. Ce serait vraiment se tirer une balle dans le pied. Donc voilà, juste ce qu'il disait, le Techranar, c'était la première la première itération sur le cadre, la définition du cadre. Et ensuite, dans un deuxième temps, on a écrit avec le leadership Tech un manifesto, où on définit Et toutes les valeurs, toutes les cultures dans lesquelles on s'introduit et tous les paradigmes techniques, technologiques qui définissent en fait la façon dont on veut faire de la technologie chez Biv. Et ça, c'est ultra important parce que c'est assez fondateur sur... Comment est-ce qu'on va envisager le développement de tel et tel futur ou tel et tel produit. Ça augmente énormément l'autonomie des équipes, puisque en fait, tu as un cadre et tu te promènes dans ce cadre de la façon dont tu veux. Juste, tu ne dépasses pas le cadre. En revanche, la façon dont tu fais les choses, tant que ça reste dans le manifesto, tu es complètement libre de le faire et tu n'as pas besoin d'aller demander à papa, maman, etc. Et on a également introduit de l'architecture d'entreprise. Alors moi je suis toujours ambivalent sur l'architecture, je dissocie toujours le métier d'architecte et l'architecture en tout cas dans la solution et dans le software mais toujours est-il qu'aujourd'hui on avait besoin d'une cohérence d'ensemble au niveau du groupe, ce qui est extrêmement important aussi pour envisager des sujets de type convergence technique, tu vois, intégration technique, aujourd'hui c'est très compliqué parce qu'on a des langages différents on a des cloud providers différents tout est différent donc poser aussi un cadre d'archi d'entreprise et avoir en tant que bras armés des archi solutions mais également des staffs ingénieurs qui peuvent aller, implémenter techniquement cette architecture d'entreprise avec les développeurs.

Bruno:
Ok donc il y a quand même aussi ce refactoring de l'organisation et du management, pour accompagner en fait cette transformation qui n'est pas juste de la récriture de code, c'est vraiment une transformation ?

Antoine:
Complètement. Et on s'est évertué ces deux ou ces 18 derniers mois, on va dire, aussi à essayer de focuser un maximum sur la contribution individuelle plutôt que la gestion et le management en termes de nombre de profils. Pour être tout à fait transparent, moi je pense qu'historiquement, on avait trop de gestionnaires chez Bilib et pas assez de douleurs. Donc aujourd'hui, petit à petit, on change le paradigme. On a créé aussi un track RH technique pour que les gens puissent continuer à évoluer sans forcément devenir manager, parce qu'il y en a qui n'ont pas envie, ce qu'on peut très bien comprendre. Il y en a, de toute façon, c'est leur seule façon de progresser. Donc ils passent par la case management, puis ils ne sont pas forcément bons.

Bruno:
Et puis tu perds la valeur de tout ce qu'ils apportaient à la tech en général.

Antoine:
Exactement. Donc maintenant, on a quand même bien redesigné la partie contribution individuelle et il y a une vraie possibilité d'évolution jusque très très haut et oui on a quand même rationalisé en tout cas dans l'organisation tech, le nombre de managers suite aux différentes petites rérogues qu'on a faites.

Bruno:
Dans ces projets là surtout quand ils sont aussi aussi massif tu as aussi une question qui revient souvent dans le monde de la texte et le bail versus bill qui du coup là un contexte un peu particulier c'est à dire qu'il ya potentiellement des choses que tu faisais avant tu dis bah en fait on a dépensé trop d'énergie à le faire donc peut-être que maintenant on va l'on va l'externaliser peut-être que ça peut être l'inverse aussi et des librairies que tu utilises depuis des mois et des mois ou des années des années que tu décides de refaire maison est ce que vous avez vu comme ça des discussions, avec des choses qui étaient avant faites maison que vous avez maintenant intégrées soit en achat, soit en open source ou des différents modèles ?

Antoine:
Alors ça c'est des discussions qu'on a très régulièrement et notamment dans notre rituel de TechRadar Hebdo donc le Builder Buy c'est des vrais sujets, généralement moi ce que je pousse aujourd'hui c'est ce qui existe déjà sur étagère, on prend sur étagère et on a fait collectivement l'erreur chez sur certains sujets, de ne pas le faire. Et là, la valeur ajoutée de développer des choses qui existent déjà et dont c'est le métier des gens. On voit aujourd'hui la limite du sujet. Donc là-dessus, j'ai envie de te dire. Jusqu'à il y a quelques mois, je pense que tout ça n'était pas forcément très organisé. Aujourd'hui, on pousse très fortement au bail, sauf sur les différents produits sur lesquels rien n'existe. Et tu vois étrangement Sur le moteur de royalties par exemple T'en as plein qui existent Que tu peux acheter, t'as plein, t'as du sas Etc, mais t'en as aucun Qui n'implémente les fonctionnalités Dont on a besoin Parce que Biv, on parlait des top Tiers artistes tout à l'heure Mais on target aussi les gens qui font De la musique pour leur plaisir Et qui veulent juste tu vois, La diffuser La diffuser etc Et tous les entre-deux, entre le top artiste et celui qui chante dans son garage. Donc on a des spécificités qui sont extrêmement larges. Et en fait, sur étagère, ça n'existe pas. Donc ça, clairement, même si tu dis comme ça de primaire... C'est quand même con de développer un moteur de royalties alors qu'il y a des offres. Oui, mais ces offres ne sont pas complètes et ne permettent pas de gérer notre business.

Bruno:
Ce moteur de royalties dont tu parles, c'est un outil qui permet à des gens d'écrire des règles disant qu'il y a X% de ce qui revient de telle plateforme qui va à tel endroit, là à l'artiste, à l'agent, à un producteur ou je ne sais quoi. Ça, c'est des règles un peu métiers de diffusion de l'argent ?

Antoine:
Oui, tout à fait. Et puis, il y a aussi les règles de récupération des royalties. Il faut te plugger. Tu as les DSP, les plateformes de streaming qui t'exposent des API. Très souvent, c'est plutôt qu'elles te poussent des fichiers Excel sur un FTP. Il y a 40 millions de façons de faire. Derrière ensuite c'est en fait selon les ayants droit oui qui tu rémunères et comment, sachant que on travaille évidemment avec toutes les devises du monde, dans tous les pays du monde, et la gestion des droits en musique c'est extrêmement compliqué, tu peux avoir les droits de diffusion de Arianna en France, en Espagne, en Italie mais pas en Allemagne par exemple donc oui il y a beaucoup de complexité derrière ces sujets là.

Bruno:
Au-delà du débat buy versus build dans ces sujets de réécriture complète il y a aussi parfois tout un travail d'archéologie qu'on fait sur tout le code existant, est-ce que du coup vous avez à certains moments d'envie entre guillemets de sell, de vendre, c'est-à-dire que tu découvres un morceau tu te dis bah tiens là en fait on a fait un truc, formidable qui marche encore très bien dix ans après peut-être le moyen de le soit de le revendre, soit de le diffuser au monde pour montrer ce qu'on arrive à faire ?

Antoine:
Écoute, euh... Euh... On s'est posé beaucoup de questions sur, pas forcément sur ce qu'on a aujourd'hui, mais sur la direction qu'on allait prendre en termes de développement et se dire, est-ce qu'il y a des choses en effet qu'on développe et qui vaudraient le coup d'être, je ne sais rien moi, mis en marque blanche ou mis en open source ou vendu de telle ou telle façon. Moi ma conviction là dessus chez Belive c'est que on est dans un secteur qui est extrêmement spécialisé donc les produits en tant que tels, si on devait les vendre on les vendrait à des boîtes comme la nôtre et il n'y en a pas tant que ça donc je ne sais pas si ça vaut le coup après voilà moi je ne suis pas dans le business donc ce n'est que, mon avis très peu éclairé après la question de se dire est-ce qu'il y a en effet des choses qu'on a développées à l'intérieur de ces produits que ce soit des algos, des fonctionnalités peu importe, est-ce qu'il y a des choses qui seraient intéressantes et qu'on pourrait en effet soit repackager et vendre, soit en effet mettre en open source, ouais la question se pose aujourd'hui, comme tu disais on est en pleine, archéologie encore aujourd'hui puisqu'on réapprend aussi certaines choses dont on avait oublié qu'elles tournaient, il y a un bel bûciement on va dire autour du sujet de l'open source. Moi, j'essaie de pousser un maximum pour qu'on arrive à sortir, quelques petites choses en open source et surtout qu'on arrive à organiser le travail de nos devs pour qu'eux puissent aussi contribuer à des briques open source qu'après tout, on utilise au quotidien. Mais on va dire qu'aujourd'hui, c'est plutôt au stade du balbutiement que d'autres choses.

Bruno:
Dans les discussions buy versus build, le buy en général c'est de l'open source ou il y a du buy au sens vraiment de l'achat pécunier ?

Antoine:
Écoute, on va dire qu'en majorité c'est pécunier, mais on fait pas mal. En fait, là où on voit le plus de l'open source, c'est sur les équipes plateformes. Assez peu dans les équipes de dev. Donc ouais, j'ai envie de te dire, en majorité c'est quand même du pécunier. Parce que le truc c'est que si on achète c'est pas juste pour éviter de développer c'est pour avoir rien à foutre.

Bruno:
T'as du support.

Antoine:
T'as du machin ça tombe tout seul.

Bruno:
Mais t'as des communautés open source il y a quand même beaucoup de supports c'est juste que tu peux pas les presser parce que t'as pas justement cette capacité financière à leur mettre dessus mais t'as quand même une maintenance, dans certaines communautés en tout cas qui peut être assez forte.

Antoine:
Ouais ouais tout à fait mais il y a des sujets Là, par exemple, aujourd'hui, on utilise un outil payant pour la gestion de notre FinOps. Je pense que, petit à petit, on va se diriger vers la solution open source. Et puis là, ça vaut le coup de passer un petit peu de temps à développer au-dessus de ces solutions-là. Parce que c'est pareil, le FinOps, la définition du FinOps, elle est très différente selon les boîtes. Et donc, il y a des spécificités aussi chez nous, ne serait-ce que parce que la partie fonctionnelle est différente. Toi tu vois on fait pas du retail c'est différent et donc nos problématiques de gestion des coûts et de comment on maintient nos environnements est différente et donc là ça vaut le coup de mettre un petit peu de capacité de développement sur des outils open source voilà donc, oui on va continuer à évoluer vers cette sphère là mais voilà quand même le gros avantage pour nous du bail c'est on s'en occupe plus ou on s'en occupe peu quoi.

Bruno:
Tu parlais aussi tout à l'heure du manifesto que vous avez écrit avec le management qui permet du coup à tous vos collaborateurs d'évoluer dans un cadre où ils ont leur maximum de liberté, ils peuvent faire ce qu'ils veulent et s'en dépasser de ce cadre-là. Tu peux nous en dire un peu plus sur ce manifesto, sur ce qu'il contient, sur comment il a été écrit et ce qu'il a du coup apporté à tout un chacun chez Belive ?

Antoine:
Ouais, écoute, je l'ai écrit avec mon équipe directe de VP. On s'est pris un après-midi, et puis on a un peu vomi des idées, des concepts, etc. Et après, c'était l'été dernier, quand j'avais justement un peu moins de meeting, j'ai pris le temps de le formaliser en tant que manifesto. Ce qui contient, écoute, il y a trois grandes choses. La première, c'est tout ce qui a trait aux valeurs. Donc, les valeurs, c'est par exemple, tu vois, one team. C'est-à-dire que maintenant, on réfléchit en tant qu'une équipe, tu vois, avec une vision holistique et non plus simplement dans le spectre du micro fonctionnel de ma squad ou de mon infrastructure ou je ne sais quoi. On réfléchit avec l'exhaustivité de l'écosystème dans lequel on évolue. Ensuite t'as une partie aussi qui est plus orientée culture, donc culture c'est la culture du felfast tu vois par exemple et ça c'est extrêmement important chez nous moi je connais pas l'historique de Bilibre encore une fois ça fait deux ans et demi que je suis là mais il y avait peur de mal faire chez Bilibre et donc qui dit peur de mal faire, ça t'empêche de faire en fait à la fin, et donc ça c'est une des cultures qu'on porte beaucoup dans le manifesto en fait il n'y a que les gens qui font rien et qui ne se plantent pas donc en fait te planter c'est pas grave ce qu'il faut c'est que, on puisse corriger et réagir rapidement tu vois mais personne va te pointer du doigt parce que t'as fait une erreur tu vois voilà, donc ça c'est la particular et ensuite il y a la partie TENET il y en a d'autres. TENET un peu plus technologiques qui sont par exemple une approche contract first tu vois sur les API et les contrats t'as tout ce qui est. Approche data power mais là c'est pas de la data juste d'analytique, c'est comment est-ce qu'on utilise en fait la data de notre plateforme technologique, et la data ça peut être des données de production par exemple, pour mettre en place des auto-rémédiations par exemple, implémenter des coupes-circuits, tout ça pour que ta plateforme elle soit auto-hailing il faut qu'elle ait la donnée sur laquelle se baser, donc c'est pas juste de la data en mode dataware, C'est également toute la donnée et tout ce qui va avec l'observabilité et ces choses-là. Donc voilà, il y a ces valeurs, cultures, ténètes. Et de ça, ça nous a fait accoucher, entre guillemets, sur ce qu'on appelle les North Stars de la tech. Donc, on en a cinq aujourd'hui. La première, c'est le One Platform. Donc, le One Platform, ce n'est pas juste une plateforme en tant qu'infrastructure. C'est la plateforme digitale du groupe qui doit être suffisamment agnostique et modulaire pour pouvoir justement agréger tous les besoins du groupe et pas juste ceux de Biliv. Et d'avoir quelque chose un peu à productifier aussi la plateforme pour que les gens soient de plus en plus autonomes et moins besoin de monter en compétences utilisées sur certains sujets avec des couches d'abstraction qui font qu'ils peuvent globalement faire tout ce qu'ils veulent sur cette plateforme sans avoir besoin, encore une fois, de demander à papa et à maman. Deuxième Northstar, c'est One Data Core, donc un cœur data, parce que c'est pareil, les data ware, suite à différentes acquisitions, on en a plusieurs dans le groupe, et on a un moment où il faut absolument qu'on introduise une gouvernance des données qui soit groupe. C'est extrêmement critique pour le business, pouvoir faire de l'analyse et du forecast avec les différentes entités du groupe et pas simplement avec belief d'un côté, tu ne cornes de l'autre, centrique de l'autre etc. Parce que tu dois pouvoir recouper et en fait quand tu fais des forecasts, des achats de catalogues etc. C'est extrêmement important d'avoir de la donnée unifiée et gouverner de la même façon et avec des KPI avec un KPI et pas 32 qui ont le même nom et qui ne sont pas calculés de la même façon. Donc ça voilà, extrêmement important. Le troisième c'est le One Environment donc ça c'est une direction qui est plutôt dans l'expertise technologique et on va dire que ce n'est pas une cible, c'est plutôt un voyage c'est de se dire, comment est-ce qu'on construit nos stacks ? Comment est-ce qu'on développe nos applications pour que demain, on n'ait plus qu'un seul environnement, ce soit la prod. Et on supprime l'intégration, le staging, etc. Donc t'as ton local env sur ton laptop, et ensuite t'as la prod. Donc comment est-ce qu'on construit une plateforme ? En se disant, bah notre cible, c'est ça. Et je sais qu'on n'y arrivera pas à 100%, parce qu'il y a des choses aujourd'hui trop legacy qui ne s'y prêtent pas du tout, et que potentiellement, enfin tu vois, qu'on va se taper encore 10 ans, tu vois, j'ai pas de... Mais pouvoir se dire, en fait, on doit être en capacité de déployer tout de suite sur la prod, parce qu'en fait, entre les coupes-circuits. Éviter les effets dominos, le feature flag, etc., tout ça, aujourd'hui, c'est implémentable. Généraliser un petit peu le chaos engineering, etc. Donc ça, c'est... Comment est-ce qu'on se ré-expertise sur ces sujets-là ? On y va doucement, mais c'est une vraie direction qui, je pense, est extrêmement importante, et c'est un peu kiffant, tu vois. De se dire, en fait, on n'a plus que la preuve. Tu t'envisages les choses de façon différente. Voilà, quatrième, c'est One Global Digital Workplace. Donc là, c'est d'avoir, pareil, une expérience du digital workplace qui soit globale au niveau du groupe, ce qui n'est pas le cas encore aujourd'hui. Il y a des entités qui utilisent Google Workplace, d'autres qui utilisent Microsoft Office, etc. Et de fournir un vrai follow the sun, à travers le groupe et non pas de multiples petites entités à droite, à gauche. Et comment est-ce qu'on améliore le confort de nos collaborateurs au quotidien avec une offre digitale qui leur permette d'être plus productif, d'être encore une fois plus autonome aussi. Aujourd'hui, on est encore trop sollicité au webdesk, par exemple, sur des problèmes où les gens devraient pouvoir se débrouiller tout seuls, en cliquant sur un bouton, en faisant un workflow Slack ou que sais-je. Voilà, et le dernier, c'est ce qu'on appelle l'approche techno-push, qui est la cinquième North Star, et qui a, là, c'est plutôt une façon de comment est-ce que l'organisation tech interagit avec le reste du business. On parle beaucoup d'innovation chez Bilib parce qu'on fait beaucoup d'innovation, mais là où, moi, je veux que les gens comprennent bien, c'est qu'on ne vend pas de produits technologiques, nous. Et ce n'est pas la tech qui va innover. Ce qui va innover, je suis dit, c'est le métier. En revanche, pour pouvoir innover correctement et comprendre, encore une fois, dans quel cadre et dans quel écosystème il se situe, et comprendre ce qui est possible de faire, ce qu'il n'est pas possible de faire, et les capacités technologiques qu'on a chez B. Parce que très souvent, tu parles aux gens du business, enfin, tu vois, c'est des icos, quoi. Donc, tu vois, ils ne comprennent pas. Voilà. Donc, en fait, pour encadrer l'innovation, il faut éduquer, faire comprendre aux gens comment fonctionne la tech, qu'est-ce qu'on peut faire, qu'est-ce qu'on peut pas faire, et c'est d'autant plus important avec l'arrivée de la Générie aujourd'hui, où on s'imagine monts et merveilles, etc. Alors qu'en fait, on sait même pas comment ça marche en dessous, tu vois. Donc voilà, c'est toute cette...

Bruno:
C'est même pas, je trouve, encadrer l'innovation, c'est ouvrir l'innovation, parce que si effectivement les gens côté business chez vous sont des gens pour qui la tech est pas leur métier, si tu leur expliques ce qui est faisable, en fait, tu leur... Pour moi, c'est pas juste un encadrement, c'est qu'au contraire, tu leur ouvres.

Antoine:
Le chemin des possibles parce qu'il.

Bruno:
Y a des tas de trucs qu'ils ne pouvaient pas envisager peut-être parce qu'ils pensaient que ce n'était pas possible.

Antoine:
Alors il y a ça et je pense qu'il y a des trucs qu'ils n'avaient pas envisagé parce qu'en fait ils n'y avaient jamais pensé et le fait d'expliquer ce qu'il est possible de faire, peut-être que chez eux, toi, moi je ne suis pas dans le business donc moi ça me, je n'en tirerai rien mais eux ça va peut-être leur faire un petit déclic en disant ah merde, je ne savais pas qu'on pouvait faire ça mais du coup ça peut débloquer ce sujet-là etc. Et ça, c'est un exercice d'éducation au quotidien. La techno-push à côté du market pool, évidemment, pour le développement. Voilà.

Bruno:
J'imagine que du coup, il y a aussi tout un... En fait, l'ampleur de la transformation que tu évoques est quand même assez folle parce que c'est certes de la récriture de code, mais on sent qu'il y a aussi tout un ensemble de choses qui ont dû être adaptées et changées aussi dans ce contexte-là. Est-ce qu'il a fallu convaincre tout le monde de ce changement-là ? Tu nous disais, il y a deux ans, tu es arrivé pour cette transformation-là ou elle était déjà lancée ? C'est quoi la chronologie ?

Antoine:
Je suis arrivé pour cette transformation-là il y a deux ans et trois mois, mais je ne suis pas arrivé en tant que CTO à l'époque, j'étais arrivé en tant que VP Platform Engineering, et j'ai repris le rôle de CTO en mars de l'année dernière, entre mars 2024, mais j'étais arrivé oui pour cette transformation là, on m'avait bien expliqué, la nécessité de se transformer, on avait été très transparent aussi sur l'état actuel que ce soit l'organisation des équipes que ce soit l'oscillotage toute la partie dysfonctionnelle on m'a pas menti sur la marchandise donc je suis arrivé, je vais pas dire en terre inconnue c'était plutôt en terre inconnue, mais j'ai pas été surpris en fait quand je suis arrivé, je suis vraiment arrivé à régler pour ça.

Bruno:
Et donc, oui, ma question, c'est est-ce qu'il y a eu besoin de convaincre des gens, que ce soit au niveau des équipes de dev, soit au niveau de la direction, des équipes métiers ?

Antoine:
Alors là, pour le coup, la direction, non, parce que c'est en fait le sujet de se transformer venait de la direction. Le sponsoring, en fait, c'est pour ça que je suis venu aussi. C'est que j'ai bien vu que le sponsoring était là. Le sponsoring est toujours là. La raison pour laquelle on arrive à se transformer depuis 18 mois et qu'on est pour l'instant dans les clous de ce qu'on avait prévu c'est énormément grâce à la direction qui sponsorise totalement, la transfo chez Bivre et donc ça aussi par porosité amène les gens des différents autres secteurs du business aussi à sponsoriser cette transformation, ensuite est-ce qu'il a fallu convaincre au niveau des équipes, oui il a fallu convaincre parce que moi quand je suis arrivé il y a deux heures et demie on finissait une migration de data center. Qui courait depuis plus de trois ans je crois alors ne me pose pas la question de savoir le pourquoi du comment parce que moi je suis arrivé après la bataille puisqu'on finissait, mais si tu veux ça faisait quand même trois ans que les gens se tapaient alors c'est peut-être au fil de l'eau c'est pas du 24-7 mais une migration technico-technique d'un data center A vers un data center B donc là on finit, et quel est le sujet suivant mais littéralement, on finit au 31 décembre au 1er janvier, on démarre la transfo et c'est quoi ? C'est migrer vers JCP donc autant dire que, oui les gens n'étaient pas forcément ravis le produit encore moins parce que ça veut dire encore une fois de la bande passante, tu vois, qu'on ne fait pas au niveau de la future, donc on va dire que les premiers ouais, les premières réactions ont été, mais non mais attends, mais quand est-ce qu'on va, tu vois, développer des produits chez nous ? Moi j'en ai marre de faire des migrations de A vers B etc. Mais en fait, assez vite assez vite la promesse de la boîte à outils cloud, tu vois, et surtout la description de tout ce qu'on allait faire qui n'était pas juste une migration technico-technique d'Unprem vers GCP ça a, convaincu la grosse majorité des personnes ensuite, la vraie. Complexité pardon c'est comment on transforme parce que là chacun a son avis et c'est là où c'est plus compliqué là c'est plus compliqué et à ma foi t'as le temps de la négociation, de la discussion de l'évangélisation, du challenge de machin et puis t'as le temps en fait on fait comme ça et puis disait green comic tu vois, mais oui c'est plutôt sur ces sujets là qu'il a fallu convaincre que sur la nécessité de le faire.

Bruno:
Là a priori du coup vous êtes à peu près à mi-chemin la transformation ou sur la fin.

Antoine:
Alors pour moi la transformation c'est un kickstart donc là on est on finit la migration cloud à la fin de l'année, et donc à la fin de l'année c'est la fin de la première phase de transformation, qu'on a brandé qui s'appelle Biodissée. Et qui se finit au 31 décembre 2025 mais ça veut pas du tout dire que le sujet de la transformation en lui-même est terminé en fait c'est qu'un début, ce qui est important en revanche et c'est aussi ce que j'ai vendu au début, tu vois si je reviens à la migration on-prem, de data center à data center, ces migrations là c'est assez traumatisant et la migration vers GCP elle est aussi traumatisante c'est des sujets qui sont quand même lourds, qui n'ont pas de valeur ajoutée intrinsèque, c'est la valeur ajoutée que tu crées que tu vas pouvoir créer suite à ces actions là mais en soi ça n'apporte pas plus de valeur ajoutée que ça et c'est traumatisant en termes, de capacité et en fait la promesse c'était de se dire, on démarre une transfo on fait une première itération, on fout tout sur le cloud, et ensuite on passe en mode itératif, c'est-à-dire que, on se prend une grosse violente claque pendant un an et demi mais c'est la dernière et après en fait on continue de se transformer mais enfin j'ai envie de te dire comme tout un chacun devrait le faire, c'est-à-dire au fil de l'eau, en fonction des besoins mais sur une fondation technique qui permet de le faire, qui est encore une fois, qui est suffisamment agnostique du futur qu'on ne connaît pas et donc Donc, on doit pouvoir virer de bord et suffisamment aussi modulaire pour que si on a besoin d'accélérer sur telle et telle feature, c'est facile de la plugger ou de le ne plugger et on ne prend pas deux ans pour la faire.

Bruno:
Donc, du coup, après le temps déjà passé sur cette transfo, quels sont les apprentissages que tu en as tirés qui pourraient bénéficier à l'ensemble des auditoristes qui se lancent peut-être eux-mêmes maintenant dans des projets de transformation. C'est quoi un peu les écueils dans lesquels vous êtes tombés qui auraient pu être évités ?

Antoine:
Écoute, moi, des transfos, j'en avais fait pas mal. Il y a une chose qui est commune à toutes les transfos, c'est qu'il n'y a rien de commun. Moi, j'en avais fait pas mal. Il n'y en a pas une seule qui se ressemble. Quels sont les écueils écoute moi je pense que les écueils les plus compliqués, et ça ça a été dû au fait qu'on voulait aller assez vite que quand moi j'ai repris le rôle l'année dernière j'ai aussi changé pas mal de trucs très très vite parce qu'on avait déjà démarré depuis 3 mois, la modernisation et la migration et il y avait certaines choses qui me qui m'allaient pas dans la façon de faire ou la direction qu'on prenait, et donc je pense que les plus gros accueils qu'on a eu c'est à ce moment là quand on a pris des décisions un peu impactantes très vite sans forcément avoir eu le temps d'expliquer aux gens pourquoi on le faisait, mais ça c'était on va dire une contrainte une contrainte temporale après les accueils franchement, le pire du pire c'est toujours comment est-ce que tu fais passer l'information et comment est-ce que tu communiques et comment est-ce que tu expliques aux gens donc ça il y a plein de façons de le faire mais comment tu t'assures que c'est vraiment intégrés. Et ça, honnêtement, je pense que c'est le principal écueil de toute transformation. Et moi, je n'ai pas de baguette magique, c'est toujours le sujet le plus compliqué. C'est pas des choses que tu fais tout seul. T'as besoin d'embarquer le reste de tes équipes. Et quand j'y le reste, c'est pas 10%. T'as besoin d'une grosse majorité des équipes qui soient embarquées dans ce genre de sujet. Donc ça veut dire qu'ils doivent comprendre pourquoi on le fait. Où on va, et surtout, comme il y a beaucoup de choses qui changent dans ces périodes de transition, comment tu fais passer l'information, et surtout, comment tu la fais passer d'une façon digérable aussi, parce qu'il y en a beaucoup. Et ça, aujourd'hui, on n'est clairement pas parfait, tu vois. Mais je sais pas ce qu'on pourrait faire, tu vois, ou comment on pourrait faire mieux. C'est des sujets qui sont, ouais, c'est des sujets qui sont extrêmement compliqués, et que je vois à chaque transpo, et en fait, ce que les gens s'imaginent des fois par manque d'informations ou des fois, la faute n'appronde pas que aux leaders, c'est aussi il y a des gens qui juste vont pas chercher l'info ou ont rien à foutre de ce qui passe autour d'eux, ça existe aussi il y a un peu tous les profils, mais t'as quand même des gens, oui qui très vite, qui s'imaginent des choses qui sont complètement décoré de la réalité, et ça c'est très visible dans les périodes de transpo c'est dans ton plus visible que tu fais beaucoup de, beaucoup de checks, de mood, des équipes, des petits pulls, et tu prends les commentaires.

Bruno:
Tu parles plus d'une crainte des personnes de voir des postes supprimés et des gens licentés, ou il y a tout type de crainte qui peuvent apparaître ?

Antoine:
Les jobs supprimés, pas tellement, c'est plutôt les jobs qui changent. Les responsabilités des jobs qui changent aussi. Tu connais bien le métier de software engineer. Aujourd'hui on ne demande pas juste de coder il faut que tu gères tes tests de qualité il faut que tu fasses quand même du secure coding, il faut que tu gères tous tes déploiements il faut que tu gères tes rollback, idéalement tu gères ton observabilité et même ta production en tout cas tu dois avoir, en tout cas tu es responsable de ça après est-ce que c'est toi qui le fais, pas forcément t'as les enneblants, t'es des ENCO, mais t'es quand même responsable de ça, et ça c'était pas gagné chez Billy Wistericons parce que ça ne fonctionnait pas comme ça c'était encore une fois assez siloté il y avait certaines équipes, il n'y avait que le lead dev qui allait le mettre en proc par exemple, des choses comme ça donc nous on essaye on a tout réaplané mais mécaniquement tu vas en redonnant de l'autonomie aux gens tu leur donnes aussi des responsabilités et quand tu leur donnes responsabilités c'est pour eux des contraintes, donc tout ça il faut bien l'expliquer et puis voilà en 2025 encore une fois, en ingénieur dans la tech c'est pas le même métier qu'il y a 20 ans donc c'est plutôt des craintes liées à l'évolution du périmètre, que je vais perdre mon job parce que dans les faits, on a plutôt rajouté des jobs donc non, et puis il y a eu, pour être tout à fait honnête il y a eu une très grosse crainte quand on a introduit Java en tant que deuxième langage, et c'est là où c'est assez ingénieur. Tu as beau expliquer 40 fois qu'en fait on ne remplace pas PHP parce que déjà ce serait stupide, pendant 6 mois tous les gens étaient persuadés qu'on remplace à PHP tu as une atmosphère un peu délétère et tu as beau le dire, tu as beau le penser il y a un moment tu ne sais plus donc c'est souvent. Des sujets de communication et après c'est aussi lié à la culture de la boîte, je pense que chat et chaud des craintes au foie il y a peut-être eu dans le passé, des promesses non tenues et c'est difficile pour les gens de se dire en fait on transforme et on transforme fortement tu vois chez Biv, mais ils n'arrivent pas à intégrer le fait qu'on transforme aussi l'état d'esprit et les façons de travailler tu vois en se dirigeant vers ce qu'on pense c'est quelque chose de beaucoup mieux après moi je dis pas que j'ai la science infuse, et on s'est planté et on peut se planter tu vois mais je pense que quand même globalement, on se dirige vers une cible qui est quand même beaucoup plus plaisante que celle vers laquelle on se dirigeait enfin tu vois il y a trois ans.

Bruno:
J'aurais aussi tendance à croire que les équipes tech sont plutôt hyper enthousiastes à l'idée de bosser sur les sujets de refactoring, parce que ça veut dire refaire les choses au propre, se remettre à l'état de l'art, comme on dit. Il y a aussi quand même une part de plaisir dans ces projets-là pour des devs, non ?

Antoine:
Ah mais carrément, carrément. Tu as tout à fait raison Et c'est le cas et c'est ce qu'on voit Là où on essaye de faire attention C'est justement de donner, Des sujets cools A l'ensemble de l'organisation Qu'on n'est pas des équipes, Qui font que d'amélioration des trucs hyper cools Qui démarrent from scratch Donc en plus ils n'ont pas tout le poil historique, Et d'autres qui se tapent tout le legacy Qui font quasiment que du run Donc on essaye de mixer les sujets comme ça c'est pas toujours, évident et après t'as des gens qui eux non monter en compétences moderniser etc ça les intéresse pas plus que ça aussi c'est pareil ça existe faut pas imaginer que voilà mais moi, s'il y a un truc pour revenir à ta question tout à l'heure en parlant avec toi ça me le rappelle mais sur tu sais quoi les conseils et les pitfalls d'une transfo, et un truc c'est il faut absolument focuser tous ses efforts sur les promoteurs et le ventre mot et laisser tomber les détracteurs en fait transformer un détracteur ça coûte beaucoup trop de temps. Se focusser sur les promoteurs tu te focus pour ne pas les perdre parce que c'est jamais gagné donc il faut continuer à les avoir avec toi et c'est le ventre mou qu'il faut tourner petit à petit et en faire des promoteurs de la transforme ça je pense que c'est quelque chose qui est extrêmement important parce que très souvent tu vas dire ah mais lui il est complètement contre je vais essayer d'aller lui expliquer mais en fait tu vas passer des heures et des heures pour.

Bruno:
Un résultat pas forcément.

Antoine:
Pour un résultat qui au mieux est ventre mou et au pire généralement ce qui se passe la personne reste détracteur, tu vois, donc en fait il faut se focusser sur les gens qui sont plutôt orientés positifs que négatifs Donc aujourd'hui.

Bruno:
De ce que tu vois, cette transformation elle est a priori bien partie pour se terminer en date et en heure, mais c'est quelque chose qui c'est un changement de mindset qui devrait perdurer suffisamment longtemps pour, rester une nouvelle façon de faire.

Antoine:
Tout à fait, c'est le but donc en gros, là on finit à la migration fin d'année, et à partir de là non à partir d'aujourd'hui je pense qu'on a globalement 18 mois donc on va caler sur fin 2026 pour revenir à un niveau qui, est un niveau standard de l'industrie aujourd'hui, je pense que fin 2026 on aura, quelque chose dont on peut être fier mais on sera loin d'avoir terminé, voilà, encore une fois c'est ce que tu dis, c'est que moi à partir de début de 1996 ce que je veux c'est qu'on arrête les gros programmes, en tout cas, je ne parle pas de programmes de convergence qui sont d'autres choses mais sur, le day to day de la tech et du produit, qu'on arrête les gros programmes et qu'on passe dans l'itératif du cadencement de développement de produits etc etc.

Bruno:
Pour terminer j'aurais deux dernières questions pour toi qui sont les questions rituelles de ce podcast la première c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeuristes ?

Antoine:
Écoute, il y a un bouquin, je pense que tout le monde connaît déjà et la majorité l'ont lu, mais le bouquin Reinventing Organization, qui m'a complètement ouvert les yeux sur l'univers du travail, l'organisation au travail. Moi je trouve que c'est un bouquin absolument formidable, fondateur que tout le monde devrait lire, c'est hyper facile à lire c'est hyper intéressant, les recettes qu'il y a dedans ne sont pas forcément des recettes qui sont applicables, notamment tout ce qui concerne l'entreprise libérée etc mais c'est passionnant.

Bruno:
On mettra bien évidemment un lien en description dernière question, la plus importante de ce podcast, Antoine est-ce que tu es plutôt espace ou tabulation ?

Antoine:
En tant que développeur OpenBSD, moi je suis tabulation.

Bruno:
Très bien, merci beaucoup Antoine.

Antoine:
Merci à toi.

Bruno:
Et merci à tous d'avoir suivi cette discussion. J'espère qu'on vous a donné des billes pour se lancer dans des projets de refactoring qui sont effectivement, des projets toujours un petit peu intéressants. On aurait pu évoquer aussi l'approche Marie Kondo. Je ne sais pas si tu connaissais cette émission sur Netflix, un truc de rangement.

Antoine:
Non.

Bruno:
C'est Marie Kondo, donc c'est une experte du rangement qui vient chez toi et qui prend tous les objets tout ce que t'as chez toi et qui te demande si ça t'apporte du bonheur ou pas et si tu réponds non elle le jette pour te laisser excusez moi tu vois ce qui te garde du bonheur qui est aussi une façon de faire du refactoring peut-être un peu extrême mais qui peut être intéressante.

Antoine:
Tu vas regarder ça.

Bruno:
Donc voilà j'espère que vous avez donné en tout cas quelques billes pour faire des projets de refactoring aussi massifs soient-ils comme ce qu'ils ont pu faire avec Antoine chez Believe, moi comme toujours je vous remercie de partager ce podcast autour de vous n'hésitez pas à aller faire un tour sur le Tipeee si vous voulez soutenir ce podcast. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine. Et d'ici là, codez bien.