Simon Maurin - Équipes, métiers et plateformes @Leboncoin

[00:00:03] merci d'être là pour ce dernier de de conférence. aujourd'hui, je suis là pour vous parler d'équipe de métier et de plateforme et d'équipe plateforme et de plateforme métier chez le Boncoin.
[00:00:18] Je m'appelle Simon, j'ai travaillé au bon coin de 2012 à janvier dernier. Et je m'occupais du rôle de lead architecte avec cette casquette que je vais vous essayer de vous raconter cette histoire. Donc je propose qu'on commence par définir ce terme là. Donc après je pense que personne tombera de sa chaise, on est à Flocade.
[00:00:38] mais pour ça il faut qu'on voyage dans le temps et qu'on revienne en 2017. Et à ce moment-là, le boncoin fait une grosse de de son de son département. en s'inspirant euh et ben du travail de Spotify sur la question. Et donc à ce moment-là, on opte pour des équipes qu'on va vouloir le plus autonome possible. alors on est vraiment convaincu par l'approche dans la mesure où justement nous on a à ce moment-là, il y a une organisation par département technologique. il y a énormément de dépendances entre les teams et on a bien pu voir que ça avait un impact négatif exponentiel le nombre de ce nombre de dépendances sur notre capacité à délivrer. Donc on se dit on veut des équipes autonomes, pour ça on va les faire petite pizza team tout ça et pluridisciplinaire. Donc on va faire en sorte qu'elles aient toutes les capacités techniques chez nous, c'est front, mobile, backend, pour pouvoir construire leur logiciel et le déployer de façon autonome. Ces équipes donc elles vont se répartir des domaines métiers qui sont des ensembles fonctionnels cohérents dont la finalité c'est de créer de la valeur pour l'utilisateur. On va se donner une règle, c'est que pour chaque domaine métier, on ait une seule équipe qui soit responsable et bien identifiée, l'idée étant d'éviter d'avoir des coins de la code base qui soient orphelin et dont personne ait la responsabilité. Donc ce à quoi on voudrait aboutir, c'est à ce moment-là, du coup, une répartition des différents métiers de la code base qui permettent de la couvrir complètement et aux différentes équipes de bosser le plus possible en parallèle. Donc à ce moment-là, on arrive à cette organisation là, cette découpe là. Donc on on a des des product team qui vont se répartir les grosso modo les grands parcours utilisateurs qu'on a à ce moment-là. C'est-à-dire que on a une première équipe, la partie team qui va gérer le dépôt d'annonce, la gestion de la petite annonce, c'est notre métier principal. Ensuite, on a une équipe search Discovery qui va se charger de la mise en relation entre les acheteurs et les vendeurs, entre la demande et l'offre si vous voulez. Euh et ensuite, on a oh, ça a marché.
[00:03:09] 100 minutes.
[00:03:13] On est reparti. Donc je disais search donc qui va s'occuper de matcher l'offre et la demande. La partie contact qui elle va faire va gérer la mise en relation entre l'acheteur et le vendeur et la partie transaction qui elle va permettre la négociation, le paiement, le shipping et cetera. Euh ce qui est cool, c'est que ces différents domaines, euh ils se peu, ils ont peu de dépendance les uns aux autres. Ils ont généralement une dépendance sur le modèle d'avant, sur le domaine d'avant, à part la transaction qu'il y en a deux et du coup grosso modo, on voit les gains qu'on espérait assez vite. en switchant dans cette organisation là, c'est-à-dire que les équipes elles dépilent d'un coup très vite en parallèle. définition sur ce différents domaines. Et c'est cool. Et ça marche même bien.
[00:04:07] euh parce que ça nous permet de scaler de façon satisfaisante. Donc quand on fait ce ce move là, on est en 2017, ça en vert, c'est les effectifs avec l'échelle à droite, là on voit qu'on est environ une centaine quand on fait ce move là.
[00:04:24] en bleu, c'est le les effectifs total du bon coin avec l'échelle à gauche. Et donc 2018, on on passe la barre des 130 et 2019, on double. euh et 2020 on reprend un petit 15 20 % et euh ben grosso modo ce modèle là, il marche assez bien. Ce qu'on fait, c'est que quand il y a des nouvelles équipes qui arrivent, on crée des nouvelles des nouveaux domaines métiers. on investit pas mal sur plein de trucs côté B2B et ainsi de suite ou on coupe les domaines métiers qui sont existant en plus petit morceaux qu'on donne à différentes équipes. Et du coup, ça marche bien.
[00:05:03] Jusqu'au jour ça marche plus. Euh ce jour, il arrive en 2020.
[00:05:09] Euh à ce moment-là,
[00:05:13] Donc le boncoin, c'est un site de petites annonces et son ADN encore en 2020, c'est vraiment un ADN de site généraliste. C'est-à-dire que on offre des petites annonces dans plein de catégories différentes qui vont de l'immobilier à l'emploi en passant par les vacances et les biens de consommation. Mais grosso modo, on différencie assez peu ces différents ces différents marchés, l'expérience pour l'utilisateur, elle est globalement la même partout.
[00:05:45] Or, on a plein de concurrents qui eux sont spécialisés sur un de ces marchés. ou un de ces verticaux, j'utiliserai peut-être les deux mots de façon un peu interchangeable dans cette présentation. Euh et donc on on se rend compte notamment parce qu'on on est attaqué assez fortement par certains, euh qu'il faut qu'on pivote de cette position euh de spécialiste enfin de généraliste à une position de multispécialiste. Donc ça c'est c'est c'est Antoine, c'est notre CEO qui nous demande du coup à ce moment-là de faire en sorte qu'on puisse avancer sur les marchés en parallèle avec une expérience spécialisée pour chacun d'entre eux.
[00:06:23] Ça c'est les maquettes du produit à l'époque. Donc l'idée, c'est d'avoir quand même un truc qui est relativement homogène en terme de de de look and feel, mais sur lequel on peut vraiment euh par marché euh adapter l'expérience, donc par exemple en ayant des listings avec des images très très grandes quand on est sur le sur la sur la vacances, du du search en carto quand ça fait sens. Euh, la construction de la fiche de petite annonce aussi elle doit être spécifique à la à la verticale, encore une fois là, on voit d'un côté la la maquette de la petite annonce de de vacances et à côté celle de de l'emploi. On voit que la la taille de l'image, elle est beaucoup plus importante sur la sur la lock de vacances, la localisation elle arrive avant, les paramètres, ils sont pas gérés pareils, on a des trucs qui sont spécifiques au marché. par exemple, on a ici côté emploi une vidéo qui vous propose de vous présenter l'entreprise dans laquelle vous allez bien évidemment candidater. donc l'idée, c'est vraiment d'avoir des blocs qui ont un qui sont relativement harmonieux mais qu'on va pouvoir arranger de façon différente par par vertical et aussi des blocs qui sont spécifiques à un marché.
[00:07:37] comme par exemple calendrier de disponibilité pour pour la la partie vacances et ainsi de suite. Même chose sur la transaction, parce que comme on n'achète pas une paire de chaussettes de la même façon qu'une voiture. ou qu'on loue un masse dans le sud pour passer ses vacances avec Antoine. on doit pouvoir diversifier les funnels sur la partie transaction. Donc grosso modo, l'idée c'est d'avoir un cadre commun harmonieux, mais de la diversification par marché.
[00:08:11] Donc ce qu'on fait, bon c'est simple, on fait ce qu'on a toujours fait. On dit OK, maintenant la prio c'est d'être d'avoir des d'être d'avoir des comment dire, de mettre du focus sur la spécialisation par marché, on grossit beaucoup, qu'est-ce qu'on va faire? On va créer des équipes à qui on va filer cette responsabilité là.
[00:08:29] Donc on crée une product team job, une real estate, une emploi, une motors, une aussi sur la partie gestion des biens de conso que j'ai pas mis parce que ça ça débordait. mais voilà, vous comprenez l'idée. On dit bon ben, on continue d'incrémenter le modèle, le nouveau focus c'est les marchés, allez. Et ça, ça nous explose à la tronche. Alors là, c'est un petit peu c'est un petit peu direct parce que il y a il y a environ 15 secondes entre les deux slides. En vrai, ça nous met plus un an à nous exploser à la tronche, c'est-à-dire qu'au bout d'un an, on se rend compte que les équipes verticales, elles délivrent vraiment dans la douleur et vraiment vraiment vraiment un rythme dégradé par rapport aux autres. On se dit qu'il y a quelque chose qui va pas. On regarde un peu d'un peu plus près et on se rend compte que notre belle propriété là de de dépendance limitée, côté vertical en fait on l'a un petit peu explosé. Pourquoi? Bah parce que chaque verticale, elle doit modifier potentiellement le dépôt d'annonce, l'expérience de recherche, la mise en contact et la transaction. Et donc ces équipes, elles vont passer leur temps à courir derrière les autres. En plus ce qui est marrant c'est que nous on est une boîte très très agile, on fait des map à 3 mois à l'équipe et donc chacun a son propre plan. Et donc faut faut négocier avec tout le monde. optimisation locale, optimisation globale, tout ça tout ça. Euh et donc il y a quelques petits symptômes du point de vue surtout des des des verticales qui sont intéressants à observer. Bizarrement, il y a beaucoup de work in progress, donc beaucoup de tâches qui vont mettre 3 mois à traverser les différentes dépendances même sur des trucs simples quoi. Genre on a eu un exemple où on a voulu mettre le salaire sur le petite annonce d'emploi, donc au dépôt et le rendre recherchable. Et voilà, ça a pris 3 mois. Pas 3 mois de boulot actif hein, 3 mois à avoir.
[00:10:30] l'équipe emploi qui demande à la partie search, enfin la partie pardon, d'abord annonce de rajouter ça dans le modèle de données, ils attendent, ça finit par se faire, il récupère ça, ils file un nouveau ticket vis-à-vis de l'équipe search pour que ce soit inscrit dans le moteur de recherche, ils attendent, ça finit par être pris et à ce moment-là, ils peuvent faire leurs propres modifs. Et ça chip. Mais donc du coup, si sur des trucs simplissime, ça met 3 mois, vous vous doutez bien que sur les trucs compliqués, c'est compliqué. Donc euh sur les features un petit peu plus ambitieuses, on a un phénomène euh qui se développe chez toutes les verticales, il y a un système de négociation intense euh qui se crée au moment des road map.
[00:11:15] entre les équipes verticale et les équipes, on va dire parcours celles qui qui gèrent les les quatre blocs initiaux là.
[00:11:24] Euh et euh ce ce symptôme là, il est vraiment assez vicieux. Euh parce que du coup, ça crame beaucoup d'énergie euh des des des équipes. Euh ça elles essaient de sécuriser le plus possible donc elles elles vont aligner le planning des équipes, mais dès qu'il y a une partie d'une map d'une des équipes qui bouge, ce qui arrive tout le temps, ben tout décalle. Euh et du coup pour essayer de limiter le risque entre guillemets, on fait des grooming et des conceptions ultra upfront à ce moment-là, sachant que les développements ils se font parfois 3 6 9 mois plus tard et bien sûr, il y en a rien qui tombe en face des cases. Euh donc euh tout ça, ça ça a un effet vraiment délétaire à la fois sur le delivery mais aussi euh sur les relations entre équipe et sur l'exercice de map où plus personne veut aller. bon ça c'est l'exercice de map.
[00:12:16] Euh et euh si on se met dans la peau d'un développeur qui est dans une équipe marché. On se rend compte que la charge cognitive est énorme parce qu'il doit bon ben comme tous les autres développeurs connaître son propre système, mais comme la cohésion du code est affreuse, c'est-à-dire que comme il y a de la logique de son marché chez les autres. il doit aussi connaître euh et ben la la structure de la code base des autres équipes et ben en fait c'est vraiment pas facile, surtout quand tu arrives dans une boîte, parce que ça c'est des équipes qu'on vient de créer.
[00:12:51] Euh et du coup, il y a aussi une sorte d'ambiguïté de périmètre parce que qui est responsable de la logique quand c'est une équipe qui possède le marché et une autre qui possède le parcours, qui tranche quand les deux sont en désaccord.
[00:13:08] Euh et enfin bon tout ça, ça fait que on voit la code base vraiment se dégrader. Dans la mesure où quand il y a de la logique partout, on vous demande de tout comprendre et que les choses simples sont compliquées, ben vous avez tendance à dès que vous pouvez contourner. ou dupliquer. Et et c'est normal et c'est assez inquiétant.
[00:13:29] Euh et donc du coup, on comprend que ça fondamentalement ça vient du fait que notre petit mantra euh d'avoir un un domaine, une équipe. pour euh éviter la sursynchronisation, bah en fait on l'a un petit peu euh on l'a on est revenu dessus sans vraiment s'en rendre compte et du coup, on le paye. Mais du coup, le diagnostic final, c'est que on a un problème systémique. Euh il y a un mispatch entre notre stratégie entre notre stratégie qui est appuyée sur la verticalisation, donc faire de plus en plus de feature qui sont spécifiques à un marché, la façon dont on est organisé et la façon dont la code base est structurée. Et donc là je vous dis ça tranquille 4 ans après. sur le moment voilà, notre état émotionnel, il tient plus de ça quoi.
[00:14:23] Euh et c'est là qu'on on tombe sur des gens bien intentionnés. qui nous disent ne paniquez pas, lisez Team topologies, peut-être que ça peut vous aider.
[00:14:34] Ça vient de sortir à ce moment-là. Euh alors je vais faire une toute petite présentation de ce bouquin, je pense que à peu près 90 % des presque que j'ai vu ici. euh qui a lu Team topology ou est familier des concepts qui sont derrière. OK, ça fait à peu près 2 tiers de l'audience. Euh alors,
[00:14:54] dans Team topologies, on nous propose de réfléchir justement à ces questions de de flot dans les organisations qui produisent du logiciel. Et il y a grosso modo deux sets d'axiom qui structure cette réflexion. Le premier, c'est les modes d'interaction entre les équipes. je vais passer un peu vite dessus. Mais grosso modo, on distingue trois modes, la collaboration, donc ça c'est quand les équipes, elles collaborent directement l'une avec l'autre, elles échange, souvent elles ont un but en commun. Euh la la collaboration, enfin la l'interaction en mode as a service, donc là l'idée, c'est un peu à l'opposé, c'est-à-dire qu'on va synchroniser directement le moins possible, enfin du coup, on va éviter de se synchroniser directement avec une autre équipe, on va consommer des services ou des outils qu'elle propose à dispo sur étagère en en self-service. Et donc l'idée là, ça va vraiment justement d'être à l'opposé de limiter les interactions directes entre les gens dans l'une et dans l'autre. Et on a la la le troisième mode qui est la facilitation où là on a une équipe généralement d'expert qui qui va envoyer des ressources dans euh une de nos équipes euh produits généralement pour l'aider à dépasser une difficulté ponctuelle.
[00:16:11] Donc à côté de ce série d'action, on en a une autre qui est les quatre types d'équipe.
[00:16:18] Donc on a euh ce que dans le bouquin, ils appellent les stream align team, donc ce qui est nos nos équipes produits. L'idée, c'est que ce sont des équipes euh qui suivent un flot de travail qui leur permet de créer de la valeur pour l'utilisateur final et qui sont organisés sur des domaines et qui sont faites pour être le plus indépendant possible. Voilà, c'est nos équipes produits, en vrai, nous on a quasiment que ça. dans l'organ. Et ensuite les trois autres équipes, elles n'ont qu'un seul qu'une seule finalité, c'est d'aider les stream team à être le plus efficace possible et donc alors d'une façon ou d'une autre, à leur lever de la charge. Euh donc on a les team qui sont là pour qui sont des équipes de de coach d'experts et cetera, des ops, des archi, que sais-je qui ont une connaissance métier ou technique spécifique qui peut aider les équipes à produire des trucs un peu compliqués. On a les complicated subsystem team, bon là qui gère des trucs dont personne veut gérer parce que très compliqué et peu abstractable, c'est pas un mot, mais en tout cas qui demande une connaissance technique soit très spécifique et très profonde, soit métier très profonde, soit les deux en même temps. Et euh du coup, voilà, on n'a pas très très envie d'approcher de ces choses-là. Et enfin, euh il y a un quatrième type d'équipe qui est l'équipe plateforme. Et l'équipe plateforme, son but, c'est de faciliter la vie des euh stream team en lui fournissant une plateforme.
[00:17:57] Du coup, qu'est-ce qu'une plateforme? Ce qui est très marrant, c'est que il y a plein de définitions différentes. Moi j'aime bien particulièrement la mienne. Une plateforme c'est du logiciel qui aide à faire du logiciel. Début fin. Euh alors je sais pas pourquoi dans Teamologies, ils ont préféré se baser sur la définition de Vaher qui à mon avis a été payé au mot qui nous parle de Foundation of Service, services, knowledge and support which je suis désolé pour l'accent as a product delivery team. teams, donc nos nos petites team nos team peut make use of the platform to deliver product feature at higher pace with reduced coordination. Euh au moins de cette définition là, c'est qu'elle est très complète. On voit que c'est composite en fait une plateforme, c'est un tas de trucs dont la finalité c'est de lever de la de la charge y compris de la charge cognitive aux équipes produits. Un premier pattern auquel on peut penser de plateforme, c'est du coup, c'est la CD. C'est vraiment le truc standard, ça aide les copains à chipper plus vite, ils appuient sur le bouton là où ils devaient faire des choses horribles à base de SCP et cetera avant, du coup ils peuvent se concentrer, avancer sur d'autres choses et en plus être plus plus agile. Donc ça, c'est vraiment euh la la plateforme un peu euh pour le coup agnostique du métier et qu'on voit un peu partout ou qu'on aimerait voir un peu partout.
[00:19:37] Euh bien sûr, il y a d'autres plateformes auxquelles on peut penser, c'est les cloud provider. au premier au première layer, c'est-à-dire la partie ressources, réseau et cetera, c'est vraiment typiquement ça, ils proposent aussi un peu des des top qu'on pourrait mettre dans la même catégorie. Euh la question qu'on se pose à ce moment-là, c'est OK, d'accord, mais est-ce qu'on pourrait avoir une plateforme qui soit métier? Euh alors on se dit ça parce que simplement on se dit on on a fait ça, c'est c'est pas fou fou. Mais est-ce qu'il y a un monde où on pourrait demander aux équipes qui gèrent les parcours centraux de pivoter et d'un coup de faire du logiciel qui aide les copains à faire du logiciel? Donc leur dire vous êtes plus en face des des clients là, vous êtes en face des autres développeurs et votre but, c'est de leur simplifier la vie en leur fournissant du tooling qui permet de facilement construire les parcours de dépôt, le search and disco, la conversation et les transactions. Euh, la question qu'on se pose à ce moment-là, c'est OK, d'accord, mais est-ce qu'on pourrait euh avoir une plateforme qui soit métier. Euh alors on se dit ça parce que simplement on se dit on a on a fait ça, c'est c'est pas fou fou. Mais euh est-ce qu'il y a un monde où on pourrait demander aux aux équipes euh qui gèrent les parcours centro euh de pivoter et d'un coup de faire du logiciel qui aide les copains à faire du logiciel. Donc leur dire vous êtes plus en face des des clients là, vous êtes en face des autres développeurs et votre but c'est de leur simplifier la vie. en leur fournissant du tooling qui permet de facilement construire euh les parcours de dépôt, le search and disco, euh la conversation et et les transactions. Alors euh un grand copain à moi ce monsieur qui s'appelle Grégoire Hop, qui écrit des trucs quand même relativement pertinent très souvent. Euh il dit que oui, que même il appelle ça des business capability platform. Et dans la nature, en fait, on en trouve plein. Euh alors là ce des quelques petits exemples euh que j'ai choisi plus ou moins au hasard. Euh on a ici One login ou Conito qui permettent de vous aider à gérer la la gestion de compte. On a Algolia qui peut vous gérer à gérer le search, Stripe et Paddle le paiement, Miracle ou Shopify euh des marketplace. Euh du coup, je dis OK, ben du coup, ça a pas l'air ça a l'air faisable. euh et il a l'air d'avoir des trucs sur l'étagère, est-ce que on construit ou est-ce qu'on achète quelque chose qu'on met à la place de ce qu'on a construit en 15 ans. Euh sachant que voilà, ce qu'on a construit, c'est petites annonces, recherche, discussion et transactions, trucs qui font du paiement et trucs qui font de la recherche. voilà. Euh il y a deux petites problématiques à ça à ce moment-là. Un, c'est l'abstraction fit, c'est-à-dire que c'est plateformes, elles sont pensées avec un une enfin, un parti prix fort. euh qui fait que leur interface est elle est euh très spécifique. Et nous, notre système, il a évolué de façon organique pendant 15 ans, ce qui fait que si on veut intégrer euh par exemple un système de paiement externe, en vrai, c'est euh un boulot de migration et euh d'intégration qui est très très très long et très très dur. Donc la plupart, ça, ça nous retire pas mal de d'options. Le deuxième élément qui va dans le sens du du build. Euh c'est que autant sur la partie euh alors c'est un un cor domain chart. L'idée c'est d'essayer de raisonner euh sur le la valeur inhérente à vos à vos domaines métiers dans ce que vous construisez. Euh et et l'idée c'est c'est de de différencier donc sur deux axes, la partie à quel point la business logique elle est complexe, à quel point ça permet une différenciation des clients. Et du coup, on range là-dedans les différents domaines métiers dont on a besoin. Donc typiquement par exemple la gestion de compte et cetera, c'est assez générique. Euh il y a des trucs qui peuvent être un peu plus avancés comme par exemple le billing ou le paiement qui sont un peu des trucs de support. Et après, il y a les trucs qui sont vraiment ce qui vous différencie. Et nous, par exemple, on considère que notre search, par exemple, il est différenciant et c'est un peu le cœur de la machine, enfin, un des cœurs de la machine. Donc du coup, ici, euh si on veut avoir la capacité à faire du sur mesure et suivre notre stratégie, et ben on peut pas être dépendant d'un sort party. Euh et donc on on va faire. OK. Donc là, on se dit, c'est bien, on a un plan. On va transformer donc nos équipes, une partie de nos équipes produit en équipe plateforme, elles vont aider les les verticales en leur fournissant des plateformes métier. La question c'est par où on commence. Est-ce qu'on leur demande de construire la plateforme et une fois que leur plateforme, elle est construite, et ben on met. Ou est-ce qu'on leur dit bon, vous êtes des équipes plateforme sans plateforme, amusez-vous bien. Euh alors ce ce monsieur, c'est c'est Melvin Conway, donc c'est c'est le point Conway de cette présentation. Euh ça c'est un un c'est aussi un un axiome qui est un peu central dans toute la réflexion de Team Topologies. Euh c'est la loi de Conway qui est ce monsieur qui travaille ou travaillait au au MIT. Et qui a prouvé dans les années 70, je crois, euh que les organisations qui construisent des systèmes complexes, genre nous, euh elles sont contraintes de reproduire dans leur design les interfaces de communication euh entre les entre les équipes de cette org. Euh et ça c'est assez marrant parce que en fait ça on peut le mettre à l'envers. Ça ça fait qu'en gros, si vous changez pas la façon dont les équipes se comportent les unes avec les autres, vous allez avoir du mal à leur faire changer le design du système, donc l'architecture. Et donc, il y a une façon de prendre ce ce truc comme un truc actionnable dans l'autre sens, dire OK, ben du coup, on peut faire l'inverse, on peut faire en sorte de modifier le mode d'interaction des équipes entre elles. en leur expliquant où on veut aller bien évidemment, euh pour qu'elle soit plus en cline à justement construire l'archi qui fitte avec. Et donc on fait ça, donc en quoi ça consiste du coup à se dire oui oui, OK, moi. On change du jour au lendemain les équipes produits en équipe plateforme, euh on leur file des ressources dédiées, euh on leur dit bah, commencez de zéro et itérez et normalement, ça devrait bien se passer. Euh, comment ça s'est passé? Alors là, je vais vous faire un un je vais vous vous expliquer en mode un un on va dire une succession d'étapes parmi laquelle la plupart de ces équipes passent. Euh donc ces équipes qui doivent transformer leur produits quoi en plateforme.
[00:25:55] Euh la première étape, c'est la migration, assez simplement. Donc là, l'objectif, c'est vraiment euh de designer la plateforme et de refactorer l'existant. parce que on a une base de code qui a 15 ans, il y a plein de trucs, donc par où on commence. Euh la façon dont ça se passe en terme de de collab, c'est que c'est l'équipe plateforme qui lead.
[00:26:18] Et elle va chercher euh des bouts de métier dans la codebase et elle les migre chez elle euh pour en faire des fonctionnalités de la plateforme. Et elle gère un petit peu tout.
[00:26:31] Euh et généralement ici euh il y a une ou plusieurs équipes euh produit marché qui sont pilotes. euh pour aider la pour aider l'équipe plateforme à à travailler et à réfléchir. Le mode du coup d'interaction, c'est vraiment la collaboration. Là, on essaie d'avoir des gens côté équipe plateforme et côté équipe produit qui sont plus proches possible. Et donc on va utiliser du pairing, du mob et par moment même on va même se former les les les équipes. C'est-à-dire qu'on va euh mélanger des ressources, des gens, euh qui viennent d'équipes plateforme et d'équipes marchés pour un temps long, euh et leur demander de faire émerger les premières fonctionnalités de de plateforme.
[00:27:23] Euh.
[00:27:27] Du coup, le point clé à cette étape là, c'est que ces gens, ils choisissent dans les plateformes ce qui doit être harmonisé et ce qui doit être euh laissé libre. Et ça c'est c'est un ça c'est un exercice un un petit peu compliqué mais Grégoire nous dit que si on fait ça bien, il y a des chances que ça se passe bien. Euh à quoi ça ressemble? Du coup, ce qu'on fait, c'est on fait du reverse engineering sur les parcours qu'on a codé. Et donc c'est du reverse engineering, c'est pas uniquement tech, c'est vraiment même métier, fonctionnel et cetera. Donc on fait des event storming géants, euh et ensuite on map ça et on réfléchit euh aux besoins des des des différentes équipes marché, c'est-à-dire quel niveau de la latitude elles ont besoin sur quel bout de métier en en face. Euh on aboutit à un à à ça. Ça c'est un peu notre boussole, on l'a trouvé après bien évidemment. On a fait ça de façon complètement émergente et puis 3 ans après on peut dire ah oui, en fait si on avait pensé à quelque chose euh pour rationaliser le truc, ça aurait pu être ça. Euh grosso modo, on s'aperçoit que euh donc on on a tout le long des parcours qu'on doit platformiser, des plein d'endroits où les équipes euh marché, elles ont besoin de faire des choses. Mais ces choses-là, on peut les classer un peu sur deux axes. Euh soit ils sont globaux, c'est-à-dire ils ont tous besoin de faire la même chose, genre par exemple le schéma de données, ils ont tous besoin de gérer leur schéma de données. Voilà, allez savoir pourquoi. Euh ou des besoins spécifiques. Là, pour le coup, euh par exemple, euh ils peuvent avoir envie euh on en reparlera plus tard, mais d'intégrer des informations de la transaction euh dans le moteur de recherche ou dans la dans le cycle de vie de leurs objets côté euh côté bien de conso. Euh donc voilà, ça c'est le c'est le premier axe. Et il y a un deuxième axe qui est le fait que c'est alors les besoins, on va dire les changements, ils sont récurrents ou exceptionnels. Donc exceptionnel, c'est une fin, ici, on est complètement one shot, ici, on est de trois, quatre fois l'année quoi. Et et en haut, on est potentiellement toutes les semaines ou tous les jours. Et donc en fonction de ces deux axes-là, on s'aperçoit que on doit pas construire les mêmes choses. Euh et du coup que la la définition de monsieur Butcher, elle est pas bête. parce que une même plate dans une même plateforme, on va finir par avoir du code qui est fork, souvent sur le front. Euh des libs qui sont partagées quand il y a du métier qui est complexe mais qui doit changer tout le temps et de façon très spécifique au au vertical. Et une partie euh de euh et une partie de service. Parfois juste des services configurables quoi, juste un truc où on met une conf et on peut changer la couleur, on peut rajouter un hook et ça va suffire pour les les besoins du marché. Euh et parfois, euh on est obligé de faire des vraiment des des SAS quoi, on fait des des web app internes qui aident le dev à piloter euh le métier. Euh parce que grosso modo, on on a des besoins récurrents mais on a pas d'abstraction simple en mode oui non par par un tel ou reviens par là, mais on a vraiment une abstraction un peu plus compliquée euh au-dessus du métier. Un exemple, parce que ça peut paraître un petit peu ésotérique ce que je dis. Ça, c'est le search avant. Donc on a une sorte de monolithe, enfin c'est un microservice, mais c'est un micro, ouais, un microservice monolithique. Euh qui gère le schéma de données, l'agrégation de contenu, le cycle de vie des annonces, l'indexation, le du de recherche, la stratégie d'ordonnancement, le cache, les annonces luminaire, de l'alerting. Et on a des gentils gens qui gèrent à la main l'infra et la strat de failover. Ça c'est géré par la même équipe en fait en vrai donc bon ça c'est leur c'est là c'est leur bébé et ça c'est ce qu'ils font à la main parce qu'ils le font pas souvent.
[00:31:38] Et à l'issue en fait de notre plan de migration, on on le découpe comme ça. Euh donc les bouts bleus, c'est des bouts de code qui sont exécutés directement par les équipes marché. Les bouts euh orange, c'est des trucs pour lequel ils inter ils interagissent avec des services, soit vraiment des SAS internes, soit des des services sur lequel ils peuvent modifier de la de la conf. Et le gris, ça reste global. parce qu'il y a des tas de trucs qui ont pas d'intérêt à être spécialisé par vertical. Euh et donc ça ces lignes de découpe là, euh vraiment on y réfléchit beaucoup et on on utilise ce voilà, ce petit ce petit pattern là euh pour les pour les adapter. Et donc ça on pour dire que ça c'est notre voilà, c'est notre le choix d'abstraction, enfin nos choix d'abstraction parce que finalement on en propose on en propose plein, c'est ça fait un truc qui est là pour le coup plus monolithique mais modulaire.
[00:32:40] Donc une fois qu'on a fait ça euh avec notre généralement avec notre petite verticale pilote, euh on va chercher les autres et on dit " les copains, on a une plateforme qui marche, euh venez on la déploie chez vous." Et du coup, là, à ce moment-là, euh l'objectif principal, c'est la montée en compétence des des équipes marchés, des équipes produits quoi. Donc pour le coup, euh à ce moment-là, c'est l'équipe justement marché qui prend le qui prend un peu le lead et qui choisit dans sa map, quand est-ce qu'elle va faire l'inter sur la plateforme. Euh à ce moment-là, on change, on a changé notre mode de de collaboration. On est passé en facilitation, c'est-à-dire que l'équipe plateforme, elle se met à dispo euh des des équipes produits qui vont migrer. Généralement, ça se passe euh comme ça. Soit il y a des gens de l'équipe produit qui viennent dans l'équipe plateforme et qui euh pendant un, deux, trois sprints euh viennent coder la la migration chez eux et ils sont formés bien évidemment. Euh soit on c'est c'est la même chose mais dans le sens inverse, soit il y a un ambassadeur de l'équipe plateforme qui part dans l'équipe produit euh pour les aider. Mais dans les deux cas, le but c'est pas juste de faire le dev, c'est de faire monter en compétence euh les copains. Et c'est aussi un bon moment pour valider notre abstraction. Parce que on l'a codé sur généralement donc un use case, le le premier marché qu'on a adressé et du coup nous, ça nous permet une première validation, une première test euh de la de l'abstract.
[00:34:21] Euh toujours chez le search, donc cette période là, cette cette phase là, pour passer d'emploi à emploi plus Simo plus euh location de vacances plus voiture plus bien de conso, ça a pris à peu près 12 mois. Euh. 12 mois sur lequel on a principalement investi du coup sur le le système de enfin en gros la méthodologie d'onboarding des des dev. Et euh on a pu essayer de valider notre découpe qu'on a vu plus haut, la découpe a plutôt bien tenu voire très bien tenu cette phase là. Par contre, il y a eu des étapes de scaling en fait de la plateforme. parce qu'on a commencé par emploi, un dessin c'est un petit marché chez le bon coin, c'est 70000, 80000 annonces. Euh Real Estate, enfin la partie Imo, c'est déjà 2 3 millions, euh et euh bien de conso, c'est 60. Donc euh forcément, il y a il y a eu des il y a eu des adaptations pour scaler euh au niveau des des clients, mais comme on les a intégrés un petit peu au fur et à mesure, ça a pu se faire progressivement et l'abstraction a tenu. Il y a d'autres endroits en fait à ce moment-là, on voit que l'abstraction de fit pas et en fait on repasse un peu à la phase d'avant, on refait un peu le et on. Euh la phase d'après, donc là, on peut commencer à vraiment se concentrer sur la création de valeur jusqu'là, c'était un peu la migration et l'adoption. Euh et la phase suivante, et ben, les équipes marchés peuvent vraiment commencer à construire des nouvelles features au-dessus de la plateforme. Donc soit complètement de façon complètement autonome parce qu'on leur a laissé du code avec exécuter et tant qu'il en gros il s'assure que les contrats d'intertion sont tout seul. Soit parfois du coup en venant faire quelques changements dans la plateforme pour pour l'adapter. Euh dans ce cas-là, on est toujours sur une un mode de facilitation à à notre échelle, euh là, pour le coup, normalement la le transfert de connaissance s'est en fait. Euh ce qui se passe, c'est que on va souvent travailler par par pair. En gros. Donc on va avoir les gens qui sont venus faire l'inter euh et d'autres copains si si ils ont pu un petit peu partager la la connaissance, euh qui vont faire des changements dans la codebase de la plateforme.
[00:36:46] Euh et donc soit ils sont très à l'aise, ouais, on les laisse faire, euh c'est notamment dans le cas des des gens avec qui on a soiré au début pour construire les plateformes typiquement ils ont participé à les construire, donc ils sont tout à fait les guides pour direct commit dedans. Et ça c'est cool parce que ça ça va très vite. Euh soit ils sont un petit peu moins à l'aise euh et dans ce cas-là euh et ben il y a un système de review euh et on on échange sur leur sur leurs motifs. Alors, là on parle de modifications de code, ça peut faire un genre un peu pompeux et ça peut faire peur, parfois c'est juste des modifs de conf justement pour euh changer le le mode d'opération de certains services.
[00:37:26] C'est le moment par contre où on va à nouveau valider que l'abstraction tient. Parce que là euh les gens commencent à construire des choses qui n'ont pas pu être anticipées. C'est vraiment les c'est les les nouveaux produits qui arrivent. Euh dans l'exemple du du search, par exemple, euh des exemples de trucs qui ont été non anticipés dans l'usage de ce qui a été fourni dans le plateforme. Côté bien de conso, euh ils ont fusionné le cycle de transaction avec les les annonces, ça s'est bien passé mais c'était pas prévu pour.
[00:37:59] Euh côté côté immeuble de vacances, ils ont utilisé les mécanismes qu'on leur avait donné de synchronisation du moteur de recherche pour faire de la de la synchronisation d'infos entre leur système legacy et la partie qui était chez eux dans le bon coin. Pareil, on n'est pas du tout pensé pour ça, mais ça a marché. Euh et côté le de vacances, ils ont refactoré toute leur partie de gestion de réservation et cetera, ce qui était un bout un peu legacy horrible chez eux et pareil en fait ça a quasiment pas eu d'impact sur la partie utilisation de la plateforme. Donc là pour le coup, on a pu valider que ça se passait bien, c'était. Il y a une super étape 4 qui est aussi focalisée sur la création de valeur mais qui est la création de valeur poussée par l'équipe plateforme. Ça marche aussi dans ce sens-là. Euh donc ça c'est quand l'équipe plateforme va ajouter de nouvelles features.
[00:39:00] Euh le mode là de collaboration c'est de service. C'est-à-dire généralement, on ajoute de la feature sur des trucs que les verticales utilisent déjà, que les équipes marché utilisent déjà, elles vont pouvoir bénéficier du coup à moindre coût si elles le veulent de ces fonctionnalités là. Je prendrais qu'un seul exemple, il y en a il y en a plein, mais je prendrai qu'un seul exemple sur le sur le search. Assez tôt, on a investi sur toute la partie AB testing, euh essayer d'optimiser les les l'ordonnance, ce qu'on appelle l'ordonnancement des des annonces dans le moteur de recherche. C'est vraiment le cœur de métier, ça on l'a fait d'abord avec des briques technologiques entre guillemets simples, enfin, dispose sur l'étagère, je devrais plutôt dire en l'occurrence c'est la stick search chez chez nous et on a fait de la recherche syntaxique. Et mais ensuite ce qu'on a fait, c'est que l'équipe plateforme, elle a investi fortement du coup sur du machine learning pour euh optimiser au maximum le tri, pour permettre de la recherche sémantique et non pas syntaxique. On arrive à une archi euh assez complexe sur lequel il y a plusieurs layers de de modèles, sur lequel on va demander des tri à Elastic search mais on va refaire les nôtres par par-dessus et qu'on peut complètement customiser par euh par vertical. Et ça en gros, ça a permis de justement avoir un un moteur de recherche qui soit extrêmement performant et pour autant complètement diversifié et spécialisé par par vertical. Et la seule chose que ça demande au au équipes verticales, finalement, c'est dans les confs euh d'activer ces options pour euh déployer ces modèles ou les les AB testing qui permet de les faire évoluer. On arrive à une archie euh assez complexe, sur lequel il y a plusieurs layers de de modèles, sur lequel on va demander des tris à Elastic search, mais on va refaire les nôtres par par-dessus et qu'on peut euh complètement customiser par euh par verticale. Et ça en gros, ça a permis de justement avoir un moteur de de recherche qui soit euh extrêmement performant et pour autant complètement euh diversifié et spécialisé par par verticale. Et la seule chose que ça demande aux au aux équipes euh verticales, finalement, c'est euh dans les conf d'activer ces options euh pour euh déployer ces modèles ou les les ab testing qui permet de les faire évoluer. Voilà. Donc ça c'est le petit c'est le petit récap des des quatre étapes, migration, adoption, évolution, innovation. Les deux là en fait, elles sont overlaées, hein. Euh, en vrai, c'est-à-dire que on on a de la création de valeur qui vient à la fois des équipes euh verticales et à la fois de la partie euh plateforme, quand on en arrive là. Euh, est-ce que ça a marché ? Bon, si je suis là, c'est que ça a un peu quand même marché. Euh, déjà nos symptômes, grosso modo, ils ont majoritairement disparu. Euh, notre KPI initial qui était quand même genre arriver à à justement augmenter le delivery des des verticales, on a estimé, c'est du doigt mouillé, qu'on a à peu près triplé euh notre vitesse euh de livraison sur la partie future, ce qui était pas forcément le plus compliqué du monde. On partait de bas. Euh, si je prends maintenant euh pour aller au bout de l'exemple, la partie search et que je vous parle là maintenant de euh d'impact utilisateur, plutôt de création de valeur. Euh, un le KPI qui est clé sur le moteur de recherche, c'est le pourcentage de recherche menant à un contact et euh sur les 4 ans de de platformisation, on a gagné 40 %. Sur cet indicateur là et c'est enfin c'est énorme. Moi je dis bravo aux équipes parce que c'est on l'attendait même pas. Ça s'est fait bien sûr par étape, c'est ça a été justement grâce aux différentes innovations et au fait de se spécialiser, de spécialiser l'approche par marché. Euh et donc du coup, on a pu euh le bouger très fortement. Et le deuxième KPI qu'on met en face, parce qu'on a offre et demande chez le bon coin, c'est le le nombre, le pourcentage d'annonce contacté. Et ça, on a fait un + 160 %. C'est-à-dire qu'on a réussi à euh être beaucoup plus performant dans la façon dont on matchait offre et demande. Mais en plus, on a réussi à ventiler euh à beaucoup mieux ventiler les les propositions d'acheteurs ou les contacts de d'acheteurs sur notre sur notre inventaire. Donc on a aussi fortement amélioré euh la valeur pour les vendeurs.
[00:42:55] Bon. Donc ça c'est le happy case hein, forcément. Mais non, si on essaie de soulever le tapis et de voir euh les trucs un peu plus chelou en dessous.
[00:43:01] ça en manque pas. Le premier, c'est euh qu'il y a une hétérogénéité euh de niveau de maturité entre les équipes qui font de la plateforme. On peut se poser la question de savoir pourquoi, et il y a plusieurs, il y a plusieurs réponses. Euh, il y a des équipes euh qui ont été c'est c'est loin de l'initiative. Euh, il y a des équipes aussi un qui sont arrivés à un niveau de maturité intermédiaire et qui ont pas d'incentive à aller plus haut, notamment parce que par exemple, ils font euh le niveau d'abstraction qu'ils ont atteint est suffisant par rapport au nombre de demandes émanant des des des verticales, ils ont pas besoin d'aller beaucoup plus haut en complexité pour euh gérer le le delivery de façon intéressante. Et ensuite, il y a tout le groupe des équipes qui euh voudraient être plus mature et ont pas réussi à l'être. Et là, grosso modo, il y a deux solutions, enfin il y a pardon, il y a deux raisons sous-jacentes à ça. Euh, la première, donc euh ça c'est monsieur Pidson à qui j'ai piqué euh à peu près l'essentiel des schémas de cette presse, voilà. Qui a écrit un petit un petit article euh pour Martin a platform guest of done, qui est vachement intéressant. Je passe un peu là-dessus. Et ce monsieur nous dit qu'en gros, ben, les équipes plateformes, elles dépendent du nombre de clients qu'elles ont, quoi, grosso modo. Euh, et que du coup, un truc qui est clé, c'est l'habilité de ces équipes à collaborer avec les autres. Euh, et là, vraiment, et euh du coup, aussi à avoir des modifications de code, comme on l'a vu, qui vont des deux dans les deux sens. Euh, or, bah du coup, ça demande quand même un sacré changement de mindset, quand vous avez été équipe produit pendant euh 5, 10 ans, euh, vous avez vu votre domaine et ainsi de suite. De d'un coup passer dans cette euh dans ce mindset de OK, maintenant, je construis du soft pour les pour les copains et je vais aller les chercher et la culotte pour qu'on comprenne ce dont ils ont besoin. Euh, il y a des fois où on est tenté de se dire en fait, je sais ce dont ils ont besoin et je vais le coder pour eux. Euh, donc voilà, ça c'est ça c'est c'est hyper important. Alors ce qui est marrant, c'est que ça marche aussi dans l'autre sens, enfin c'est un cercle vertueux, c'est-à-dire plus les équipes plateformes par contre elles sont bonnes à collaborer, plus elles collaborent. Euh, et plus le tout est efficace et les changements de code se font avec le moins de synchronisation possible et aussi sans synchronisation côté PM Road map, tout ça. Euh, un deuxième point, c'est que c'est peut être important d'avoir des ressources dédiées. Euh, c'est des en fait, c'est des c'est des projets très ambitieux et et du coup, ben, euh, c'est difficile de les avancer en best effort. Et il y a des équipes là-dedans euh qui subissaient ou qui subissent encore toujours euh des pressions business très très importantes parce qu'elles sont un peu au cœur de la stratégie, notamment, je pense aux équipes paiement, transaction et cetera. Et du coup, euh ces équipes-là, elles se sont retrouvées souvent euh à avoir des plans, mais à pas avoir la capacité à à aller dessus. Petit tips. Euh, bon, je suis un peu biaissé sur la question, mais euh le swarming, ça aide pas mal dans ces deux cas. à la fois pour euh basculer l'empathie euh des équipes plateformes vers leur clientes, mais aussi pour faire de la mise en commun de ressources entre les équipes plateformes et leurs leurs clientes et donc découper découper un peu la porde. Euh, swarming, c'est mélanger euh des gens de plusieurs équipes euh mais de façon euh longue euh pour jusqu'à ce qu'ils attendent un objectif. Donc par exemple, la migration de la plateforme. Euh. Alors, oui. J'accélère un petit peu. On pensait construire quelque chose comme ça. On se disait, voilà, les équipes plateformes, elles vont servir les équipes produits qui vont servir les clients. En vrai, c'est faux. On a construit quelque chose comme ça. On a des équipes plateformes métier qui ont servi les clients pendant des années et qui continuent de servir le client et qui qui par contre aussi ont pivoté par rapport à à leurs copains. Euh et du coup, en fait, elles sont dans une situation un peu hybride. Au début on se disait c'est triste parce que c'est pas clair quand même. Euh mais en fait c'est pas clair mais c'est bien. Euh on s'aperçoit que les celles qui résistent le mieux, elles ont une elle arrive à avoir une sorte d'équilibre entre euh la partie produit et la partie plateforme. Entre les investissements un peu sur la user expérience et sur la developer expérience. Et souvent, derrière, il y a un trio ou un quatuor avec un tech lead qui représente la plateforme, un UX qui va avoir la voix utilisateur et le le PO et l'ingering manager qui vont être arbitres. Et ça marche très bien. En fait, on tire le le mieux comme ça. Euh alors la suite très vite, qu'est-ce qu'on va faire ? Euh les trucs qu'il faut qu'on passe maintenant, c'est euh le truc principal, c'est de comprendre que la plateforme c'est un produit comme un autre, ou un méta-produit en l'occurrence. Et du coup, il nous faut une vraie euh rigueur produit autour, il faut qu'on ait une vraie vision, une vraie road map sur les plateformes, des interviews utilisateurs, des suivis de KPI et cetera. Tout ça pour le coup, on n'est vraiment pas mature, on prend trop comme quelque chose de technique, en fait. Euh. Et du coup, la vision long terme, c'est vraiment d'avoir une sorte de self-serve. Euh, de tous les parcours de base qui soient cohérents. Pour l'instant, c'est encore instiloé. Avec des niveaux de maturité différents. Voilà, le le bon coin est au milieu d'un groupe qui s'appelle Atar et qui est en train de merger une partie de ses ses marques en en Europe. Et grosso modo, c'est la plateforme du bon coin qui est qui les accueille et l'idée, c'est d'aller au-delà de la verticale de pouvoir gérer aussi ses plateformes, une notion de marché et une notion de marque. Donc c'est ce qu'il y a c'est c'est le truc qui est juste derrière. Un petit wrap-up, du coup. Euh, pour les équipes qui voudraient euh justement pivoter et devenir des équipes qui font des plateformes métiers. Euh, quelques conseils du coup de notre propre expérience, je sais pas ce que ça vaut hein, tous les contextes sont spécifiques mais. Euh, un conseil, y aller par une approche itérative, le mindset, notamment la volonté euh de discuter avec ses clients, de comprendre leurs besoins et cetera, c'est beaucoup plus important qu'à avoir un plan. Euh, vraiment, on peut le faire de façon un peu émergente. Euh, il faut comprendre tôt que euh on on doit avoir un regard critique sur le par contre l'abstraction qu'on va mettre au-dessus de notre métier et essayer d'avoir le plus de feedback possible dessus pour pour l'adapter. Et ça, ça demande d'avoir des avis forts sur qu'est-ce qu'on harmonise avec notre plateforme et quel degré de liberté on veut laisser. Et donc ça c'est les premières questions à se poser euh avec les avec les clients internes. Euh voilà, et ensuite, euh les trucs euh le truc pas simple, accepter la tension entre produit et plateforme quand on a des plateformes métier parce que du coup ça on est forcément dans l'hybride, ça ne peut pas être pur et c'est même mieux comme ça. Et enfin, ça c'est on prêche, mais on le fait pas nous-mêmes. Avoir une démarche rigoureuse autour de ces outils là, quand ils sont critiques et stratégiques, ce serait sans doute le mieux. Paul, à la fin euh au copain Gregore. Euh voilà, qui a écrit un qui vient de sortir un bouquin en sur la partie stratégie plateforme et qui nous dit. Le platform Paradox, c'est que les plateformes permettent de mettre par terre la dichotomie perçue entre harmonisation et innovation indépendante et que c'est vachement chouette. Et c'est vrai. Voilà, il y a plein plein plein de contenu euh sur cette partie platform Engineering, c'est relativement dans l'air du temps, Team topologies, platform strategic qui vient de sortir de ce monsieur, il y a une platform Conne avec des tas de gens brillants qui parlent. Euh on trouve plein de contenu sur internet, il y a les copains d'octo aussi qui ont une équipe dédiée. Enfin voilà, euh si si le sujet vous intéresse, c'est c'est vraiment euh ouais, c'est c'est vraiment très chouette. Voilà. Merci.
[00:51:07] Je.
[00:51:24] Bonjour, merci, c'était top.
[00:51:26] Merci.
[00:51:27] Euh, une question, euh tu en as peut-être parlé un peu à la fin. Euh j'aimerais ça en savoir un peu plus sur la manière dont vous avez réussi à résoudre le problème euh de faire de la road map. D'aligner euh ces équipes parce que il y a quand même des dépendances. Ouais.
[00:51:45] Alors. Alors, c'est une très bonne question. Dans les cas où ça se passe le mieux.
[00:51:50] Euh, dans les cas où ça se passe le mieux, euh, tu as pas de synchronisation en road map, tu as pas de synchronisation au niveau des managers et des PO. Ça se fait directement au niveau des Dev. Euh, et ensuite, en fonction de la complexité euh de la feature, ça va remonter d'un niveau, soit on va faire un petit grooming, soit ça va être un truc important, il faut potentiellement coder quelque chose de nouveau dans la plateforme et ça, ça va passer en en road map. Mais ce dernier cas, en fait, il arrive assez peu, enfin si justement le niveau d'abstraction est bien choisi, en fait ce cas-là, il va être assez rare. Et donc au final, on va faire plein de Dev où justement, il y a pas de synchronisation de de road map, ils sont fait juste en direct.
[00:52:32] Et en fait, c'est une des propriétés qui est vachement intéressante justement si les si les équipes plateformes euh collaborent bien avec les équipes avec leurs équipes clientes internes. C'est qu'il y a une sorte de hausse du capital euh social de la boîte, il y a beaucoup plus de choses qui peuvent se faire sans avoir besoin justement de prévoir ou de verrouiller et directement euh de de dev à dev. qui vont plus de façon beaucoup plus euh spontanée aller justement au besoin, faire des modifs dans la code base des uns des autres.
[00:53:08] Il y a pas de conflit entre par exemple et euh les dev.
[00:53:15] Ouais. Pardon.
[00:53:18] Euh je je ma question c'est peut-être qu'il y a pas de conflit il y a des conflits peut-être qu'il y en a pas souvent mais. Si et Motors veut veulent faire un truc en Q2 et qu'il y a que il y a un conflit chez la team ou euh peu importe transaction dans une plateforme team, euh il peut y avoir un conflit de de calendrier, c'est-à-dire que la plateforme team ne peut pas faire les deux.
[00:53:39] Ouais. Alors ça ça continue de ça continue d'arriver mais du coup l'idée c'est que l'occurrence elle est beaucoup plus faible. Et euh alors, il y a il y a aussi un truc dont on n'a pas eu le temps de parler, c'est que euh la plateforme, elle fait un choix aussi de couverture fonctionnelle et nous on a essayé de faire des choix de plus petit dénominateur commun et de faire le moins de spécifique possible. Euh, ce qui fait que ça ça limite ce genre d'initiative enfin ça limite ce genre de problème parce qu'il y a des tas de fois où on dit bah en fait, au pire construisez de votre côté quoi, ou faites-vous un truc spécifique aussi.
[00:54:14] Merci. Euh j'aurais aimé savoir.
[00:54:18] Ouais.
[00:54:19] Tu t'es présenté en tant que lead architect. Quelle place finalement dans tout ce grand projet les architectes ont pris et surtout la place qu'ils n'ont pas prise.
[00:54:27] Euh c'est une bonne question. Alors, en fait, le truc c'est que ça s'est écoulé sur 4 ans, donc déjà la boîte, quand on a commencé, on était à peu près 400 à la tech, là on est sur le projet sur lequel on est actuellement, on est 1200. Donc ça ça a pas mal changé. Euh initialement l'approche, elle a été euh euh par un archi, enfin par par moi pour le coup. Il y a eu une période d'évangélisation, en fait, ça s'est fait avec. En fait, la partie, on va dire, réflexion stratégique, elle s'est fait avec le Diretech, donc le CTO et les directeurs techniques et ensuite à ce moment-là, on avait un process qui s'appelait le TeO, le travail d'organisation vert, qui était un travail de un outil de réorganisation permanente. Et donc on est passé par là. On a fait des ateliers avec grosso modo, c'était 70 personnes à peu près à ce moment-là, les les équipes qui étaient concernées. Et on a discuté des options. Euh ça a duré environ 2 mois, je pense. En temps ressenti, c'était 6 ans, mais voilà, c'était un peu intense. Euh et ensuite, on a eu un go pour commencer à tester l'approche sur des sur des use case qui étaient un peu dérisqués et à partir de ce moment-là, ça a commencé à passer dans justement à la main des équipes. Euh je pense qu'un truc qu'on aurait pu faire, c'est avoir plus un peu plus d'évangéliste euh quand même parce que du coup, il y a un autre facteur qui est important et différenciant, c'est justement la proximité de gens qui portaient la démarche, proximité des équipes. Celles qui sont assez basses, souvent, euh ben voilà, le il y avait pas ce côté euh euh coach ou évangéliste pas loin pour pour aider. Euh ça, en fait, au fur et à mesure des 4 ans, on on l'a un petit peu mieux géré parce qu'en grandissant, on a quand même pas mal formalisé nos euh nos parcours et nos rôles de contributeurs individuels chez le Boncoin. Donc là, aujourd'hui, il y a des on est un peu mieux armé, il y a plusieurs enfin il y a un groupe d'archi, il y a des staffs qui peuvent être tout à fait enfin qui portent ce genre d'approche. Euh donc voilà, on est un petit peu plus on est un petit peu plus armé parce qu'on s'est un peu mieux organisé.
[00:56:29] Bonjour, merci pour ta présentation.
[00:56:31] Merci.
[00:56:32] Euh, tu as tu viens d'apporter aussi quelques éléments de réponse, mais je me demandais combien de temps avait pris la phase d'adoption et au final, comment vous pouvez gérer sur cette phase de juste de migration les évolutions qui peuvent avoir lieu par ailleurs.
[00:56:43] Alors, c'est une très bonne question. En fait, il y a un double run, du coup, enfin. Alors, je vais parler pour le search parce que c'est le c'est le cas que je connais le mieux et puis c'est le Happy case. Euh il y a eu un double run d'abord et on a sorti une on a sorti une verticale qui était qui pesait pas beaucoup en terme de CA et qui pesait pas beaucoup en terme de volume d'annonce pour dérisquer le pour dérisquer un peu l'affaire. Euh et on est arrivé quand même avec une promesse pour le produit. C'est-à-dire que c'était le but à ce moment-là, on sur le search par exemple, on triait par date de récence des annonces et l'idée c'était d'avoir un premier pas justement vers la pertinence, l'testing et donc des meilleures perfs. Surtout sur une catégorie où le fait de pas gérer les synonymes ou les intentions et cetera, c'est un petit peu pénalisant. Parce que si tu fais pas si pour toi une nouille et une garde d'enfant c'est quelque chose de différent, ça peut être un peu voilà. Et euh du coup, euh on a commencé par ça, c'est-à-dire avoir une sorte de de wind qui était à la fois produit et à la fois tech, mais sur un truc qui était pas sur les priorités de la boîte pour avoir un petit peu de temps. Euh ensuite, on a créé un système un double système, quoi, enfin, on a mis une sorte de proxy qui tapait à gauche et à droite et puis dès qu'on a validé par contre le modèle et qu'on s'est dit c'est bon, on passe en adoption. Là, on a la première chose qu'on a fait, c'est tuer le truc pour pas avoir le double run pendant l'adoption. Euh voilà. Et et du coup, la ce qui s'est passé, c'est que l'équipe plateforme a pris les bouts des de toutes les verticales chez elle, a tué l'ancienne stack et ensuite elle les a redispatchés au fur et à mesure aux clients, en les adaptant au fur et à mesure des besoins. Je t'en prie.
[00:58:19] Merci Simon.
[00:58:21] Merci.

Transcription