Face à la croissance, comment Leboncoin a réinventé son organisation

5 min readJun 13, 2022

3 leçons issues du talk d’Hervé Lourdin (VP Engineering chez Leboncoin) à la Conf’ School of Product 2021

L’année dernière, j’ai assisté au talk d’Hervé Lourdin, VP Engineering chez Leboncoin lors de la Conf’ School of Product.

Je vous en parlais déjà dans cet article.

Six mois plus tard, je me suis repenchée sur le sujet dans le cadre de ma mission actuelle. En effet, au sein d’une équipe de coachs agiles, j’accompagne un client soumis à une forte croissance, qui a décidé de transformer son organisation en passant d’équipes applicatives à des équipes fonctionnelles.

J’ai alors voulu réécouter ce talk d’Hervé Lourdin sur la réorganisation de Leboncoin et en profiter pour vous partager trois “takeaways”.

Replay du talk d’Hervé Lourdin

1. Piloter l’organisation comme un produit

Avec la grosse croissance de Leboncoin (passé de 550 à 1400 personnes entre 2017 et 2021), l’organisation est obligée de se réinventer sans cesse.

Pour ce faire, Leboncoin ne peut plus se permettre de grosses réorganisations big bang impulsées par la direction car elles sont trop coûteuses et risquées étant donné la taille de l’entreprise.

Leboncoin utilise donc le modèle “TOO”, Travail d’Organisation Ouvert, qui vous rappelera peut-être quelques principes et pratiques agiles ! En voici quelques principes, qui me font penser que le pilotage de la transformation organisationnelle ressemble au pilotage d’un produit.

Satisfaction client : demander aux principaux intéressés, c’est à dire aux collaborateurs, de remonter leurs irritants (par exemple : le format de roadmap trimestriel n’est pas lisible)
Transparence : Les irritants sont créés directement par les utilisateurs (les collaborateurs) dans un backlog ouvert à tous (sur JIRA). “Rien n’est secret”. Les personnes qui travaillent sur un “ticket” organisationnel doivent communiquer sur l’avancement du sujet (via Confluence).
Autonomie : les collaborateurs sont libres de s’emparer ou non d’un ticket dans ce backlog et d’y contribuer.
Collaboration : Ce travail est collaboratif, avec le soutien d’un sponsor à la direction.
Itération : itérer avant d’éventuellement généraliser. Ainsi, pour améliorer le format de la roadmap, un nouveau format a été testé dans une équipe pilote avant d’être généralisé.
Découpage : on préfère les “améliorations marginales” au “gros changement drastique” qui serait trop douloureux étant donné la taille de l’organisation.

Takeaway : les changements qui découlent de cette approche collaborative et itérative n’ont pas l’effet “waouh” d’une grande réorganisation. Ils prennent plus de temps. Alors quel intérêt ?

Ils sont moins douloureux car sont plus petits, correspondent vraiment aux besoins des équipes, sont testés et adaptés et donc mieux adoptés.

*Gestalt 4*, Victor Vasarely (1970) — Un gros coin, des petits changements organiques !

2. Faire émerger l’organisation à partir de l’architecture

Une des dimensions de la croissance chez Leboncoin est la diversification des activités : de l’achat de biens de consommation (perceuse, livre) vers d’autres biens (voitures, immobilier) ou services (recherche d’emploi).

Leboncoin a donc voulu repenser son organisation pour tendre vers une organisation par ligne business verticale (biens de consommation, emploi, immobilier…). Comment passer d’une organisation découpée selon le parcours utilisateur (recherche, création d’annonce, achat, gestion des annonces) à un découpage par verticale business tout en gardant des synergies ?

Notamment, comment avoir un équilibre entre composants communs à toutes les verticales et spécifiques à l’une ou l’autre ?

L’organisation chez Leboncoin est divisée en deux types d’équipes :

feature teams : user centric, centrés sur une verticale métier.
platforms teams : developer centric, elles visent à faciliter la vie des développeurs et gèrent notamment des composants réutilisables par plusieurs équipes.

Un exemple dans la tribu Paiement : la platform team ne produit pas d’écrans mais des API au service des feature teams chargées d’optimiser l’expérience client de transaction. L’ objectif de la platform team est que ces API soient les plus faciles à utiliser et les plus lisibles pour les développeurs des features teams.

Pour gérer cette transformation, l’approche choisie est celle de la loi de Conway inversée : partir du code pour faire émerger l’organisation. Les équipes de développement créent les composants qui correspondent à la vision cible dans le code et avec la croissance organique de l’équipe, une nouvelle organisation en émergera, par nécessité.

Ainsi, un des principes régissant la réorganisation est le Grow & Split. Pour faire émerger une nouvelle équipe, on fait grossir une équipe existante jusqu’à ce qu’elle devienne trop grosse et doive se scinder. Trouver la bonne ligne de division est délicat.

Hervé Lourdin énonce trois critères :

la division doit avoir un sens fonctionnel (Boulangerie-Pâtisserie pourrait se scinder en Boulangerie et Pâtisserie, plutôt que Fabrication du pain-Vente du pain, qui n’a pas forcément de sens pour le client)
la ligne de séparation doit exister dans le code
elle est équilibrée en termes de charge de travail (autant de demandes métier pour les deux nouvelles équipes)

Takeaway : le préalable pour que cela marche est l’anticipation :

prévenir dès le début l’équipe qu’elle sera amenée à se diviser, pour la préparer psychologiquement.
comme le nombre de personnes augmente et le périmètre fonctionnel s’élargit, les responsabilités fonctionnelles et managériales augmentent, notamment pour le PO et le lead tech. Il faut rester vigilant à diviser l’équipe suffisamment tôt pour que leur charge mentale reste gérable.

3. Capital Social : favoriser les connexions au sein du réseau social qu’est l’organisation

Une équipe bien connectée est plus performante : cela constitue un avantage concurrentiel nommé capital social.

Quand on croît, comment favoriser la connexion entre individus et équipes éloignées dans l’organisation ?

Cette question est devenue cruciale chez Leboncoin en raison des difficultés à mener des projets transverses. A cause des dépendances entre équipes, les projets accumulaient les retards. Des taskforces, équipes composées de membres de différentes équipes, ont été créées afin de mener ces projets. Cela ne résolvait qu’en partie le problème car une fois le projet terminé, les taskforces se dissolvaient et personne ne restait responsable du code développé, ce qui créait de la dette technique sur le long terme.

Grâce au “TOO” évoqué plus haut, Leboncoin a mis en place le swarming (“essaim”). Exemple avec le projet “paiement en un clic” : une équipe existante est définie comme meneuse. Elle va contribuer dans le code des équipes avec lesquelles il y a des dépendances.

Premier effet positif : le projet est mené plus vite que prévu (deux mois au lieu de quatre).

Deuxième avantage : à la fin du projet, l’équipe meneuse reste responsable du code produit.

Takeaway : Dernier avantage, collatéral, mais non des moindres : les développeurs de différentes équipes travaillent ensemble donc se font davantage confiance pour travailler ensemble à l’avenir.

Pour aller plus loin :

Hervé Lourdin recommande la lecture de Team Topologies: Organizing business and technology teams for fast flow, de Matthew Skelton et Manuel Pais, dont Leboncoin s’est beaucoup inspiré pour réorganiser ses équipes.