Construire une organisation tech qui tient dans le temps - Conversation avec Robin Leboeuf, Head of Engineering chez leboncoin

Quand Robin raconte son parcours, ce qui frappe d’abord, ce n’est pas la linéarité. C’est la cohérence qui apparaît avec le recul.

Autodidacte, entrepreneur, développeur, architecte, manager, puis Head of Engineering, il a traversé différentes échelles d’organisation et de maturité technique. Après plus de dix ans chez leboncoin, il observe son métier avec une lucidité rare : la tech n’est plus seulement un sujet de stack ou d’architecture. C’est un sujet de lisibilité, de structure et de sérénité collective.

“Leboncoin, c’est l’aboutissement de mon parcours pro. J’y ai trouvé un terrain où je peux travailler à la fois sur la complexité technique et sur l’organisation humaine autour de cette complexité.”

Un parcours construit par essais, erreurs et autonomie

Robin ne vient pas d’un parcours académique classique d’ingénieur logiciel.

Il démarre par un DUT, enchaîne avec une spécialisation, puis découvre rapidement les limites des environnements trop rigides. Sa première expérience en SSII se passe mal : mission mal cadrée, promesses non tenues, faible impact.

Très vite, il comprend qu’il devra apprendre par lui-même.

Il rejoint ensuite une petite structure où il touche à tout : matériel, relation client, développement. L’expérience est formatrice, mais le décalage avec les valeurs le pousse à partir.

C’est là qu’il tente l’aventure entrepreneuriale.

Il monte une agence web, puis une seconde. Pendant plusieurs années, il gère projets, clients, production technique. Jusqu’à une association qui tourne mal et le force à revenir au salariat.

Avec le recul, il considère cette période comme fondatrice.

“Quand tu travailles seul, tu dois comprendre tout le cycle de valeur. Tu n’as pas le luxe de te spécialiser.”

Il se définit alors comme un développeur fullstack autodidacte, formé par nécessité autant que par curiosité.

Arrivée chez leboncoin : comprendre la complexité à grande échelle

Robin rejoint leboncoin en 2015, dans une équipe CRM.

À l’époque, l’entreprise compte environ 300 personnes. La stack est hétérogène, l’organisation encore segmentée par spécialités.

Il démarre comme développeur, puis évolue vers un rôle de lead technique.

Son premier chantier n’est pas technologique, mais méthodologique.

Mettre en place des standards communs change radicalement la qualité globale d’une équipe.

En parallèle, l’entreprise amorce plusieurs transformations majeures:

• Migration vers Go
• Passage aux microservices
• Organisation en feature teams

Mais le CRM reste un système à part, vieillissant, pourtant central.

Ce paradoxe deviendra un point d’inflexion dans son parcours.

Migration Salesforce : un tournant structurant

La décision de migrer le CRM vers Salesforce dépasse largement un changement d’outil.

Il s’agit de redéfinir la manière dont les systèmes communiquent entre eux, dans un environnement déjà complexe.

Robin prend un rôle hybride développeur–architecte pour concevoir toute l’interface entre Salesforce et le reste du SI.

“Aujourd’hui, cette interface représente des dizaines de microservices. Ce n’était pas seulement un sujet technique, c’était un sujet d’alignement entre business et architecture.”

Ce projet l’amène à changer de posture :

• moins d’exécution
• plus de réflexion systémique
• plus d’anticipation des cas limites

C’est sa première expérience d’architecture transverse à grande échelle.

Architecte transverse : le défi de l’influence sans autorité

En devenant architecte transverse, Robin découvre un enjeu souvent sous-estimé.

Le pouvoir de décision ne garantit pas l’adoption.

“Tu peux proposer la meilleure solution possible. Si elle n’est pas comprise ou appropriée par les équipes, elle ne sera pas suivie.”

Cette prise de conscience l’amène à déplacer son attention. Le cœur du travail ne réside plus uniquement dans la conception de solutions, mais dans la manière de les rendre intelligibles, discutables et partageables.

Le cadrage devient alors central : ne pas se limiter aux besoins formulés, mais interroger ce qui reste implicite, explorer les angles morts, remettre en question les hypothèses et anticiper les dépendances invisibles.

Un travail en amont, souvent discret, rarement valorisé, mais décisif. C’est lui qui permet d’éviter les impasses techniques et organisationnelles à long terme, et de construire des décisions réellement appropriées par les équipes.

La fierté d’un produit ancré dans le quotidien

Robin parle de leboncoin avec attachement, mais aussi avec responsabilité.

Travailler sur un produit utilisé par des millions de personnes impose une rigueur particulière.

“Chaque évolution impacte directement les usages. On ne peut pas changer brutalement l’expérience utilisateur.”

Cette réalité façonne profondément les choix techniques. La performance, la robustesse et la fiabilité ne sont pas des objectifs abstraits, mais des exigences quotidiennes, dictées par l’échelle du produit et la diversité de ses usages.

Chaque décision est pesée, chaque évolution pensée pour s’inscrire dans la durée, sans fragiliser l’existant.

La taille du trafic impose un niveau de maturité technique rarement négociable.

Recruter en Go, puis revenir à l’essentiel

Face à la tension sur le marché des développeurs Go, l’entreprise adopte une approche pragmatique.

Plutôt que de restreindre le recrutement à une expertise étroite sur le langage Go, l’équipe privilégie des fondamentaux plus durables : la capacité à raisonner sur des problématiques backend, à apprendre rapidement et à s’inscrire dans une culture d’ingénierie exigeante.

La maîtrise de Go devient alors une conséquence plutôt qu’un prérequis. Un programme interne accompagne les nouvelles recrues dans leur montée en compétence, en s’appuyant sur des bases solides et un environnement propice à l’apprentissage.

La capacité d’apprentissage devient plus déterminante que l’expertise initiale.

Passer du technique au management

La transition vers le management ne se fait pas par rupture, mais par continuité.

Robin décrit un intérêt profond pour les dynamiques humaines.

Lorsque son équipe se retrouve sans manager, il propose de prendre ce rôle tout en conservant un ancrage technique fort. Ce positionnement hybride lui permet d’explorer progressivement le rôle, de développer ses compétences managériales sans rompre immédiatement avec la pratique quotidienne du code.

Au fil du temps, l’équilibre évolue. Les responsabilités organisationnelles prennent davantage de place, et le périmètre s’élargit. Ce glissement progressif lui permet de construire une posture de manager en continuité avec son identité d’ingénieur, sans renier ce qui fonde sa légitimité auprès des équipes.

Developer Experience : un levier stratégique

Aujourd’hui, le rôle de Robin consiste avant tout à créer les conditions dans lesquelles les équipes techniques peuvent travailler efficacement et durablement. Il s’agit moins d’optimiser à la marge que de structurer un environnement lisible, où les outils, les processus et les systèmes forment un ensemble cohérent.

Documentation, outillage, observabilité, chaînes de déploiement, gestion des incidents ou encore compréhension globale des architectures : l’efficacité au service de la sérénité

“Une bonne Developer Experience, c’est quand les équipes savent où regarder, quoi faire, et n’ont pas de surprises.”

Avant toute amélioration, un travail de clarification est nécessaire :

• Ownership
• Rationalisation des outils
• Harmonisation des pratiques

À l’échelle de dizaines d’équipes et de centaines de services, ce chantier demande méthode et patience.

Mesurer l’expérience développeur

Pour appréhender la Developer Experience, Robin distingue deux dimensions complémentaires, qu’il juge indissociables.

D’un côté, des indicateurs objectifs permettent de mesurer le fonctionnement des équipes dans le temps : fréquence de déploiement, temps de résolution des incidents, taux d’erreurs en production. Ces métriques offrent une lecture factuelle de la performance des systèmes et des processus.

De l’autre, des données plus perceptuelles viennent compléter cette analyse. Elles traduisent le vécu des développeurs au quotidien : le sentiment de friction, l’accessibilité de la documentation, la capacité à comprendre et à naviguer dans des systèmes parfois complexes.

L’enjeu est d’aligner ces deux réalités pour construire une vision fiable.

IA : pragmatisme avant tout

Sur le sujet de l’IA, Robin adopte une posture nuancée.

L’expérimentation est encouragée, sans céder aux promesses simplistes.

La génération de code, souvent mise en avant, ne constitue qu’une partie du sujet. Les enjeux de maintenance, de compréhension des systèmes, de debugging ou encore de transmission de la connaissance demeurent centraux, et ne disparaissent pas avec l’automatisation.

Dans cette perspective, l’IA s’impose moins comme une solution miracle que comme un outil supplémentaire, à intégrer avec discernement au sein des pratiques existantes.

Juniors et IA : un regard optimiste

Contrairement à certaines inquiétudes, Robin pense que les jeunes développeurs pourraient tirer un avantage de l’IA.

Cette exposition précoce favorise le développement de nouveaux réflexes : une capacité accrue à raisonner en abstraction, à superviser plutôt qu’à exécuter, et à penser les systèmes dans leur ensemble. Autant de compétences qui relèvent déjà d’une forme de maturité architecturale.

Le véritable défi se situe davantage du côté des profils intermédiaires, pour lesquels l’adaptation implique souvent de remettre en question des habitudes bien ancrées et des modes de travail éprouvés.

2026 : clarifier, stabiliser, avancer

Le crew Developer Experience reste encore en phase de structuration.

Son périmètre est parfois mal compris, mais Robin reste confiant.

Une fois les fondations stabilisées :

• Les responsabilités seront plus claires
• Les équipes avanceront plus vite
• Les frictions diminueront

Et contrairement à beaucoup d’organisations, la réponse ne passe pas par l’augmentation des effectifs.

“Je n’ai pas besoin de plus de monde. J’ai besoin d’alignement et de stabilité.”

‍