L'organisation apprenante chez Leboncoin

0:04 Bonjour, je suis Hervé Lourdin, Engineering Director chez Leboncoin. Je vous retrouve tout de suite. Everything is in its right place. C'est le morceau qui aide Hervé Lourdin à se concentrer. Et je ne vous cache pas que de la concentration, il en faut quand il s'agit d'éplucher près de 800 000 petites annonces quotidiennes. Bonjour Hervé. Bonjour Alga. Vous êtes Engineering Director au Boncoin. C'est ça. Alors le Boncoin, on le sait, c'est 28 millions de visiteurs uniques par mois. C'est environ 32 millions de petites annonces, toutes catégories confondues. C'est ça. Mais comment l'entreprise s'est-elle adaptée à cette évolution constante? Je crois que c'est tout l'objet de votre propos, justement. L'organisation apprenante au bon coin. Et quelque chose me dit qu'on va apprendre plein de choses. Merci. En 2017, le Boncoin, c'était 550 personnes, environ 150 à l'ingénierie.

1:07 En 2020, c'est plus de 1300 personnes, dont 300 à l'ingénierie. Une chose est certaine, l'organisation d'il y a trois ans ne peut pas être celle qu'on a aujourd'hui. Et il faut constamment essayer de trouver une meilleure façon de s'organiser pour être aussi performant et pertinent qu'on le souhaite. Et les risques de partir en vrille, de faire une organisation qui ne marche pas sont nombreux. Et c'est ce... dont je me propose de vous parler aujourd'hui. Je m'appelle Hervé Lourdin, je suis Engineering Director au Boncoin, je suis en charge d'une tribu, on verra tout à l'heure ce que c'est, qui s'appelle la tribu Transaction, qui regroupe toutes les équipes qui contribuent à plus ou moins proche l'expérience de paiement qui est possible par le site du Boncoin. J'ai rejoint le Boncoin il y a un peu plus de deux ans maintenant, suite au rachat de Vite Dressing, dont j'étais le CEO et le co-CTO. Alors est-ce qu'il y a une bonne organisation pour tous? On va tuer cette question très rapidement, la réponse est non. Il n'y a pas d'organisation qui existe qui permettrait de répondre à tous les besoins et tous les maux du monde. Et au contraire, on va plutôt essayer de discuter aujourd'hui de comment on fait pour s'adapter à ce contexte contextuellement changeant.

2:14 Qu'est-ce qui s'est passé précédemment au Boncoin, dans ces enjeux de croissance du Boncoin? En 2017, il y a eu une grande réorganisation. On était dans un contexte un peu particulier. Il y avait, comme je vous l'ai dit tout à l'heure, environ 550 personnes, 130 à la technique. Et le modèle d'organisation était centré sur les stacks technologiques. Ça voulait dire qu'il y avait des équipes qui faisaient... Du web, de l'iOS, de l'Android ou du back-end, et puis qui, tant bien que mal, faisaient tout leur possible pour réaliser des fonctionnalités de haute qualité et le plus vite possible. Malheureusement, à ce moment-là de la vie du bon coin, c'était vraiment compliqué de sortir rapidement une fonctionnalité. Les cycles de livraison étaient très longs et les équipes avaient beaucoup de mal à interagir les unes avec les autres. En fait, dès lors, on voulait faire quelque chose, il fallait vite mobiliser au moins 4 ou 5 équipes, et ça devenait l'enfer de sortir quelque chose rapidement. Fort de ce constat, le COMEX a demandé à l'engineering et aux produits de trouver une solution, de se réorganiser pour délivrer plus rapidement. Ils ont trouvé, ils se sont inspirés, alors aujourd'hui on a l'impression que ce n'est pas très original, mais de ce que Spotify a fait à l'époque, et a proposé une organisation plutôt centrée sur les fonctionnalités, sur le périmètre fonctionnel, plutôt qu'une organisation centrée sur les stacks technologiques.

3:23 Pourquoi? Parce que ça permet de donner de l'autonomie aux équipes qui réalisent les fonctionnalités et d'être plus proches des gens qui jouent au business. Ça a plutôt bien marché. Mais en fait, ce qui a, de mon point de vue, fait le succès de cette organisation, ce n'est pas tant l'organigramme qu'elle a produit que la façon dont elle l'a faite. Cette organisation a été faite de manière très participative, ouverte et de manière itérative. On a fait un premier test qui a fonctionné, puis un second, et ensuite on l'a déployé avec les différents collaborateurs de l'engineering du Boncoin. Ça a été la naissance de ce qu'on a appelé le travail d'organisation ouverte. On en reparlera juste après. Quelques temps plus tard, en 2019 pour être précis, l'entreprise a continué de croître. 4 tribus, 15 feature teams, 5 guildes focalisées sur les stacks technologiques évoqués précédemment. Et puis, fatalement, on a dû un peu ajuster des choses, parce qu'il y a des choses dont on s'est rendu compte qu'elles ne fonctionnaient pas. En tout cas, pas de manière optimum. Qu'est-ce qu'on a fait? On a changé le périmètre de responsabilité des managers. Les engineering managers avant étaient en charge des équipes techniques, elles sont devenues en charge des feature teams, et plus en charge des fameux chapteurs de l'époque.

4:26 Les leads, quant à eux, ne sont pas des chefs d'équipe, mais bel et bien des animateurs. de communautés technologiques, les fameuses guildes, et on en charge cette animation et la définition des bonnes pratiques. Enfin, une équipe core a été créée pour pouvoir gérer tous les problèmes techniques de fond, décorrélés des roadmaps business classiques. Et voilà, depuis tout fonctionne bien. Bon, pas tout à fait. En fait, quelques mois plus tard, on a commencé à sentir de nouvelles tensions, quelques fissures dans l'organisation telle qu'elle avait été pensée. C'était le retour de la croix. C'est des nouveaux enjeux. Alors, qu'est-ce que ça veut dire? Concrètement, déjà, en 2020, on est 5 tribes, 300 personnes, 1300 au global, 35 feature teams, 7 guilds. Ça vous donne un peu des chiffres. C'est quand même assez massif. Et clairement, on sait qu'on va continuer à croître, qu'on va continuer à avoir de nouveaux enjeux. Et on a senti des premières tensions. Ces premières tensions se sont caractérisées autour de l'organisation et de l'architecture logicielle. Si on regarde un petit peu quels étaient les enjeux du moment, quels sont-ils aujourd'hui, en fait la première c'est que le Boncoin c'est plus uniquement l'endroit où vous rencontrez quelqu'un pour aller acheter votre perceuse.

5:34 En fait le Boncoin c'est une société qui permet d'acheter et de vendre beaucoup de choses très différentes. Des outillages, des meubles, peu importe. Une maison, vous pouvez vendre votre maison et en acheter une autre. Vous pouvez vendre et acheter une voiture. Vous pouvez chercher un emploi. Et enfin vous pouvez réserver vos vacances. Toutes ces verticales business, comme on les appelle, sont relativement différentes, même si pour autant, c'est toujours le même métier, mettre en relation des acheteurs et des vendeurs, faire des annonces. Mais chacune de ces annonces, elles revêtent des caractéristiques différentes, c'est des segments business différents qu'on ne va pas animer de la même manière. De la même manière. Autre grand challenge, le modèle transactionnel. Ça ne vous aura peut-être pas échappé, mais maintenant, quand vous allez sur Leboncoin, sur certaines pages, sur certaines annonces, il y a un bouton« Acheter». Avant, Leboncoin, c'était essentiellement un endroit où on mettait en relation les gens. Et puis, on se débrouillait pour payer. Maintenant, c'est différent. On peut toujours faire ça, bien entendu, parce que c'est le cœur de métier de notre... notre plateforme, de mettre en relation des acheteurs et des vendeurs, mais on se propose d'être un tiers de confiance sur le paiement, et donc du coup de prendre l'argent de l'acheteur et de le relâcher au vendeur une fois que la transaction s'est passée correctement.

6:41 Bien évidemment, ça aussi c'est un grand changement dans le modèle économique, dans la façon de travailler des collaborateurs au bon coin. Et le grand challenge, c'est comment on fait pour ne pas dégrader le time to market, cette vitesse à laquelle on est capable de sortir une fonctionnalité en production, sans pour autant créer un Frankenstein pour laisser de l'autonomie à tout le monde, c'est-à-dire faire finalement un système de briques et de brocs en laissant tout le monde autonome sans aucune consistance technologique. En fait, on a essayé un petit peu de caractériser cette tension au travers de ce modèle, de ce triangle qui unit trois concepts, qui sont la stratégie business, l'organisation et l'architecture logicielle. Ces trois concepts-là, on s'aperçoit que s'ils se distendent l'un de l'autre, ils provoquent des effets de bord très négatifs pour l'organisation et pour l'engineering. En effet, si par exemple l'organisation est très éloignée de la stratégie business, on va avoir du mal à trouver les bons interlocuteurs pour pouvoir adresser le nouveau marché qu'on veut faire croître. Et donc du coup, on va s'adresser à plein de personnes à la fois, ça va être compliqué.

7:42 De la même manière, si l'organisation est très différente de la façon dont est structuré le logiciel, à chaque fois qu'on va vouloir faire une fonctionnalité, ça va impliquer plein de composants, plein d'équipes différentes. On va avoir des projets extrêmement compliqués à réaliser et avec de gros risques technologiques de régression. Enfin, si... l'architecture logicielle est très éloignée de la stratégie business, globalement, c'est un projet qui va vous coûter cher, puisqu'il y a des choses qui n'existent pas et qu'il va falloir faire. Nous, on était dans cette situation-là. On est dans une situation où globalement la stratégie était vraiment éloignée de l'architecture, il y avait des composants qui n'existaient pas, il allait falloir les inventer, et l'organisation était relativement éloignée de la structuration de notre code, de cette architecture. Ça promettait des projets très compliqués avec beaucoup de gens autour de la table à synchroniser et d'autant plus de risques. L'organisation avait commencé un petit peu à s'aligner avec la stratégie, mais ce n'était pas encore suffisant. On était confronté à un gros dilemme qui était est-ce qu'on doit finalement prioriser les développements pour ce qu'on appelle les verticales ou au contraire est-ce qu'on doit consolider ce socle horizontal par essence qui est notre architecture logicielle.

8:49 Il y a une relation intime entre l'architecture et l'organisation. Il y a quelqu'un qui, en 68, avait déjà théorisé ça, qui s'appelle Conway, Melville Conway. Il avait dit, en fait, si vous êtes une organisation qui crée des systèmes, vous êtes condamné à créer des systèmes qui reproduisent les systèmes de communication entre les groupes. Donc en gros, vous êtes condamné à produire des logiciels qui ressemblent à votre organisation, à sa structure même. Ça veut dire que si votre organisation n'est pas prête à recevoir de nouveaux challenges technologiques, elle va produire un logiciel qui n'est pas prêt à recevoir de nouveaux challenges technologiques et ça ne va pas bouger très vite et vous allez avoir beaucoup de problèmes. Donc on était confronté à ce problème-là, qui est comment faire migrer finalement un socle logiciel qui était focalisé sur le parcours utilisateur qui satisfaisait tous les segments business, et aller au contraire vers un bon coin qui serait une seule plateforme et proposerait des expériences différentes en fonction des domaines business qu'on allait adresser. Et comment aller finalement vers cette architecture, comment aller vers cette organisation, puisqu'on savait que l'organisation allait probablement inférer sur l'architecture, mais qu'il allait falloir la faire bouger, etc.

9:54 Mais en fait, de même, des gens ont théorisé quelque chose qui nous a paru extrêmement évident une fois qu'on l'a lu. qui s'appelle la manœuvre de Conway inversée. Alors finalement, ça prend cette loi de Conway, mais ça dit, renversons-la. Si finalement on est condamné à réaliser des systèmes qui ressemblent à nos organisations et à leur mode de communication, changeons notre organisation et nos modes de communication pour influencer cette architecture logicielle dans la direction où on a envie d'aller. Et c'est ce qu'on a choisi de faire. Et en conséquence de quoi, on a décidé de faire des changements organisationnels incrémentaux alignés sur l'architecture cible qu'on a présentée à tout le monde. Donc on a défini nos verticaux, on a défini nos socles, et on a essayé d'y aller pas à pas. On s'est appuyé sur un autre bouquin dont je vous conseille chaudement la lecture, et le podcast de Tech.Rocks, qui s'appelle Team Topologies. Ce livre crée des building blocks, des Legos, qui vous permettent de regarder votre organisation différemment et de jouer avec. Pour nous, ça a été assez éclairant parce que ça nous a permis finalement de dire, ah bah oui, effectivement, nous, on a des feature teams. Alors, dans la dialectique de team topology, on appelle ça des value-driven teams, des enabling teams, des gens qui facilitent la réalisation de quelque chose, des platform teams.

11:02 Et ça, ça nous parlait pas mal. Et c'est ce qu'on a décidé de faire. En fait, on a implémenté des équipes plateformes pour être au service des équipes focalisées sur l'utilisateur. Donc les équipes plateformes, elles avaient un nouveau rôle, elles étaient en charge d'une meilleure expérience de développement, de developer experience. A contrario, les feature teams focalisées sur les lignes business étaient focalisées sur la user experience, celle de nos clients, de nos utilisateurs. Et en fait, on a utilisé des équipes qu'on a appelées des enabling teams pour venir aider ces équipes business à changer leur façon de faire. à changer leur socle technologique pour pouvoir mieux répondre et adresser les enjeux métiers de la location de vacances, de l'achat de voitures, de l'achat de biens de consommation ou de paiement en ligne. La deuxième chose qui est très compliquée à faire quand on est soumis à un grand volume de croissance, c'est de se dire, tiens, ça y est, on est en train de faire quelque chose qui fonctionne bien. Le paiement en ligne fonctionne bien, j'aimerais faire plus de choses. Une seule équipe, ce n'est pas suffisant. En fait, on est très tenté d'en mettre une seconde. Mais pour mettre une seconde équipe, de la même manière qu'on l'a vu précédemment, il y a une relation entre le socle logiciel et l'organisation. Et si ce socle logiciel n'est pas prêt à recevoir une nouvelle équipe, vous n'y arriverez pas, les équipes s'entrechoqueront régulièrement quand elles tenteront de faire une fonctionnalité.

12:09 Et c'est ce qui nous est arrivé. Et on l'a payé le prix fort, on n'a pas réussi à faire notre deuxième équipe correctement. Donc un premier retour d'expérience aussi que je vais vous donner là-dessus, c'est travailler à identifier quelle équipe vous voulez créer, assurez-vous avec l'équipe existante que le socle technique est prêt à être scindé en plusieurs sous-éléments, et à ce moment-là, vous pourrez faire naître votre équipe. Sans avoir préparé le terrain technique à être scindé en deux ou plusieurs, ça ne sert à rien d'ajouter une nouvelle équipe. Là, on a vu les relations intimes entre l'organisation et l'architecture. Mais quand on est soumis au volume de croissance, d'embauche, de création de nouvelles équipes que j'évoquais précédemment, en fait, ça ne suffit pas. Avoir une organisation lisible et évolutive, c'est bien, mais il faut aussi que cette organisation soit en capacité à évoluer régulièrement et que ça soit finalement quelque chose de très courant pour elle. Que le changement ne soit pas coûteux, qu'il ne fasse pas mal à la société. chaque fois qu'on veut faire évoluer une organisation. On a appelé ça l'organisation apprenante. Alors, on ne prétend pas en être une, on prétend essayer de tendre vers être une organisation apprenante.

13:11 Un des éléments forts de l'organisation apprenante au bon coin, c'est le travail d'organisation ouverte. Je l'ai mentionné tout à l'heure. Qu'est-ce que c'est? En fait, c'est assez simple. Le travail d'organisation ouverte, c'est la capacité à tout moment, quand dans l'organisation, on voit un problème d'organisation, de le reporter, le mettre dans une boîte à idées, entre guillemets, un backlog, dans lequel on va lister tous les problèmes d'organisation dont on pense qu'il faudrait travailler, les résoudre. Si on trouve suffisamment de personnes intéressées à travailler sur ce problème, on mobilise une équipe et puis on commence à itérer, expérimenter, contribuer à ce projet pour changer notre organisation. A titre d'exemple, sur la dernière année, Voici quelques projets qu'on a fait. On a fait un bilan du télétravail pendant le confinement pour voir quelles étaient les bonnes pratiques. J'imagine que beaucoup d'autres entreprises l'ont fait. On a testé des modèles d'organisation pour les projets multi-équipes. On va en parler juste après. On a créé un dictionnaire d'organisation, de vocabulaire d'organisation pour que toute personne nous rejoignant comprenne à peu près quel est ce jargon qu'on emploie au quotidien.

14:16 On a changé la façon dont on faisait nos reportings et dont on les communiquait à l'intérieur de l'échelle produit et technique. Gérer des environnements différemment, on a influencé la construction de nos roadmaps pour mieux y intégrer les chantiers techniques, et ça, Ce n'est pas le management qui l'a décidé, c'est les collaborateurs qui ont décidé de contribuer à ces projets et de les créer. Ça marche plutôt bien, c'est généralement un peu plus lent qu'un projet qui est pur top-down, donc décidé par le management. Mais globalement, ça ancre quelque chose de solide dans l'organisation, c'est que tout usager de l'organisation, tout collaborateur est en capacité lui aussi d'être un acteur de changement sans pour autant qu'il soit décidé uniquement par le management. Deuxième point qui... Il m'apparaît vraiment crucial, quand on veut avoir une organisation capable d'évoluer, de changer, de travailler à cette échelle, c'est le capital social. Alors le capital social, ce n'est pas moi qui ai inventé ça, il y a plein de gens très intelligents qui ont phosphoré sur ce concept et qui nous a beaucoup parlé. Et j'ai retenu cette définition de Ronald Burt qui dit finalement le capital social, c'est cet avantage que certaines structures ont

15:24 dans la façon dont elles vont interagir les unes avec les autres et probablement qu'une équipe ou une organisation qui performe mieux que les autres, c'est une organisation qui est mieux connectée aux autres que les autres. Donc en fait, la valeur, ce capital social tient dans les pratiques et les usages et la structuration sociale de notre organisation pour mieux communiquer, pour être mieux connecté. Et on s'est aperçu qu'il y avait des pratiques diverses et variées qui pouvaient nous permettre d'enrichir notre capital social. Donc comment mieux interconnecter des groupes les uns avec les autres? Donc là, on voit un de ces schémas de réseaux sociaux, parce que finalement, une entreprise, c'est un réseau social, qui est une somme d'équipes interconnectées les unes aux autres. Parfois, elles ne sont pas correctement interconnectées, et il y a des choses à faire pour mieux les interconnecter, pour qu'elles travaillent mieux ensemble, avec un plus grand niveau de confiance, et qu'elles se pollinisent les unes avec les autres de leurs bonnes pratiques. La première pratique dont je vais vous parler, c'est celle du swarming. Le swarming, c'est quoi? C'est ce concept de dire, lorsque j'ai un projet qui va impliquer plusieurs équipes dans mon entreprise, ça va être très compliqué de se créer des points de rendez-vous pour réaliser cette fonctionnalité.

16:30 Puisque là, on va se dire que l'équipe A va réaliser ça de telle semaine à telle semaine, et normalement l'équipe B va arriver à ce moment-là, ils vont pouvoir intégrer le résultat de leur travail, et puis l'équipe C arrivera après. Vous vous rendez compte qu'il y a beaucoup de risques liés à ces points de rencontre, et l'organisation d'une telle roadmap est un cauchemar. Le concept du swarming est de dire finalement on va créer un essaim de collaborateurs qui viennent de ces différentes équipes, pas l'intégralité, qui vont réaliser ensemble la fonctionnalité et qui se disloqueront à la fin du projet pour revenir dans leurs équipes. En fait, le résultat attendu de ça, c'est plus rapide, probablement, mais aussi surtout un enrichissement du capital confiance dans les relations que vont tisser les gens les uns avec les autres. Plutôt que d'avoir servi un produit et essayé de l'avoir intégré à la fin, ils vont l'avoir réalisé ensemble et manipulé une code base ensemble. Ils vont ressortir de cette expérience avec plus de confiance, plus de connaissances des uns des autres, et ça facilitera probablement les projets à venir une fois que l'essence sera disloquée. On a expérimenté ça dans le cadre du travail d'organisation ouverte et on s'est aperçu qu'on avait été beaucoup plus vite et qu'on avait réussi à faire des projets qui auraient été vraiment beaucoup plus compliqués à manager sans faire de swarming.

17:33 Donc aujourd'hui, on continue à expérimenter et de plus en plus de projets cherchent à implémenter ce modèle d'orga. Le deuxième point sur lequel on travaille qui renforce le capital social, c'est le mouvement des collaborateurs entre les équipes. En fait, le modèle d'organisation de Future Team tend à dire qu'une équipe, une Future Team, doit rester longtemps ensemble pour qu'elle tisse des relations fortes et qu'elle soit performante. C'est vrai. Mais pour autant, on s'appelle... Je me suis aperçu que c'est important aussi qu'à un moment donné, les équipes se mélangent pour partager leurs bonnes pratiques, pour avoir des nouvelles façons de regarder le logiciel qu'elles construisent, et pour pouvoir s'enrichir les unes et les autres, et éviter de faire des équipes trop uniformes, qui ne communiquent pas. Aujourd'hui, un des gros chantiers qu'on a ouvert, c'est de favoriser ces échanges entre les équipes. On est en train de faire en sorte que cela soit de moins en moins un problème de dire« j'ai envie de changer d'équipe, j'aimerais aller dans une autre». Que ce ne soit pas vécu comme une trahison, que ce ne soit pas un problème dans l'entreprise où le chef dit« non, je ne peux pas me permettre de perdre un collaborateur». On imagine même faire des mouvements entre nos filiales.

18:35 Il y a eu plusieurs rachats dans le groupe du Boncoin. Aujourd'hui, on cherche à favoriser ces mouvements entre les équipes, mais aussi entre les filiales, de manière à avoir cet effet de pollinisation entre les équipes de nos pratiques diverses et variées. En conclusion, je voudrais juste insister sur le fait que notre tour d'expérience, c'est qu'il n'y a pas de bonne organisation, il n'y a pas une organisation qui marche mieux que les autres ou une recette magique qui s'appliquerait à toutes les entreprises qui font du logiciel. On s'est rendu compte qu'il y avait des façons plus élégantes de les structurer, de communiquer, qui marchaient mieux. À un instant donné, une organisation qui marchait bien en 2017, à la taille à laquelle on était, est bonne, mais ce n'est pas celle qui fonctionnera en 2020 avec la taille qu'on a et les enjeux qu'on a. Donc en fait, l'organisation n'est qu'une question de contexte et certains outils permettent juste de créer plus de résilience face à ces enjeux-là. Et les deux éléments clés sont la technique, bien évidemment, l'organisation culturelle et l'organisation sociale. dans laquelle on va inscrire ça et comment on fera en sorte que tous les collaborateurs travaillent ensemble. Je vous remercie. Et moi aussi, je vous remercie Hervé.

19:37 J'ai appris plein de choses sur l'organisation apprenante du Boncoin, de gros enjeux en perspective. Quel retour d'expérience vous pouvez faire rapidement de cette nouvelle phase que vous êtes en train de traverser, ce côté de faciliter justement la circulation, la fameuse pollinisation des différentes fonctions dans l'entreprise? On est très content de ça parce que les collaborateurs s'y retrouvent plus. Ils deviennent de plus en plus à. acteurs justement de ces changements d'organisation qui sont souvent l'apanage du management. Là aujourd'hui, bien évidemment, le management est acteur de ces changements, c'est lui qui les impulse souvent, mais le faire seul, ça ne marche pas. Et là maintenant, les collaborateurs sont beaucoup plus partie prenante de ça. Et on est vraiment content de ça. Et puis vous avez été aussi fortement inspiré par Matthew Skelton. Exactement. Vous avez été Team Topologies. Oui, c'est ça. Parce que vous avez animé un podcast aussi pour Tech.Rocks. Oui, j'ai eu l'occasion de discuter avec Matthew Skelton. C'était vraiment un échange assez riche et on a pu justement tirer parti de ces expériences à lui aussi pour voir comment les décliner chez nous. Vous savez quoi? Nous aussi, on va pouvoir profiter de ces expériences parce qu'il va venir sur le Tech.Rocks avec nous. D'ici deux heures, il sera lui aussi en keynote inspirante pour pouvoir que vous profitiez tous de ce fameux Team Topologist, cette fameuse brique qu'il a pu construire pour développer les organisations.

20:47 Merci infiniment, Hervé, de nous avoir transmis votre savoir aujourd'hui. A bientôt. Merci Elsa.