Head of software engineering : un métier décrypté, avec Dimitri Baeli (Back Market)

Dimitri Baeli est Head of Software Engineering de Back Market Pro, la branche B2B du reconditionné, où il construit avec son équipe une plateforme dédiée aux entreprises, distincte du site grand public et pensée comme une « startup dans la startup ».

Co­fondateur de Tech.Rocks, dont le Summit 2025 se déroule les 1er et 2 décembre, passé par des postes de direction technologique chez Les Furets et Aramis Auto, il est aussi praticien du Lean et cofondateur de FlowCon, conférence consacrée au continuous delivery. Il revient pour BDM sur son rôle, ses méthodes et les défis techniques de son métier.

Pour commencer, comment expliquez-vous simplement ce que fait un Head of Software Engineering ?

La réponse la plus courte, c’est : créer les conditions du succès technologique sur un composant ou un module métier. Mon module, c’est Back Market for Business, où je dois monter un site complet, pro.backmarket.fr. Mon métier, c’est donc d’avoir les bonnes personnes, les bonnes technologies et les bonnes conditions de succès. Plus concrètement : m’assurer que j’ai les bons développeurs, la bonne architecture et la bonne compréhension des besoins du métier, en interaction avec le produit.

En quoi le contexte Back Market change-t-il votre manière de travailler ?

C’est une chance colossale de monter une startup à l’intérieur d’une startup. On n’a pas la pression de la viabilité d’une entreprise, seulement celle du projet. Le segment métier est déjà identifié, le B2B. On n’a pas à créer un marché. On se concentre donc sur la création du bon produit pour les utilisateurs, sans avoir deux épées de Damoclès au-dessus de la tête, à savoir la viabilité de l’entreprise et la création du marché. On est vraiment focalisé produit et métier.

Quels sont les principaux défis techniques que vous devez relever ?

Si on se projette dix ans en arrière, Back Market arrivait à peine à créer l’idée du reconditionné garanti. Les entreprises en sont à ce stade-là aujourd’hui : elles ont un besoin qu’elles ne connaissent pas encore, celui de se fournir en matériel reconditionné de qualité. Les enjeux sont donc de trouver comment construire une plateforme adaptée à une demande naissante.

On met un canot de sauvetage à côté du paquebot, on court, on grossit, et quand on sera assez gros, on rejoindra le paquebot.

Transformer la plateforme existante aurait été dix fois trop cher et trop complexe, avec 300 à 600 ingénieurs focalisés sur le B2C. Nous avons donc construit une petite plateforme à côté. Cela nous donne de la flexibilité, avec le risque, à terme, de créer une deuxième plateforme complète.

Nous tournons actuellement sur Shopify. Nous avons fait ce choix en nous disant que le but était qu’il disparaisse à terme : on met un canot de sauvetage à côté du paquebot, on court, on grossit, et quand on sera assez gros, on rejoindra le paquebot.

La taille réduite de votre équipe est-elle un choix stratégique ?

Non, c’est la logique de la rentabilité du modèle. On dimensionne l’équipe par rapport au chiffre d’affaires. J’ai un abaque (ndlr : une règle de calcul simplifiée ou ratio de référence) en tête : 1 développeur pour 2 millions de revenus. Cet abaque fonctionne pour Google et pour beaucoup d’entreprises.

On part de zéro, on met trois développeurs pour atteindre quelques millions, et on espère monter à 40 ou 50 développeurs quand on fera 100 millions. On aura toujours trop de choses à faire. On fait avec ce qu’on a et on grandit avec le système.

Quelle est votre manière de manager au quotidien ?

Mon rôle nécessite des compétences extrêmes en management pour en faire peu. L’idée est de surveiller les moments critiques, tout en reposant le travail sur une grande autonomie des développeurs. C’est un management intense, mais court. Il faut manager au bon moment pour avoir la bonne équipe, au bon endroit, avec la bonne autonomie. Je ne suis pas là pour gérer les développeurs « à la culotte ». Je donne un objectif, je fais confiance et j’interviens seulement lorsqu’il y a des incompréhensions.

Comment avez-vous acquis ces compétences managériales ?

Par des rôles précédents et des formations, notamment des formations de leadership auxquelles on n’a jamais envie d’aller et dont on sort transformé sans vraiment comprendre comment. Chez Les Furets, j’ai été bras droit du CTO (ndlr : Chief Technology Officer), puis CTO intérim, puis CTO, et membre du COMEX. J’ai managé des managers autant que des équipes directes. C’est ce niveau que j’essaie de garder : être impliqué dans la stratégie, le budget, les décisions structurantes. Beaucoup d’apprentissage sur le tas, mais aussi théorique.

Comment conciliez-vous vitesse d’exécution et qualité ? On vous met la pression pour aller vite ?

Je suis co-organisateur depuis 12 ans de FlowCon, une conférence sur le continuous delivery, le Lean et le Kanban. L’idée centrale, c’est de partir de l’existant et de procéder en touches d’amélioration continue. La clé pour aller vite, ce n’est pas de courir, mais de compléter l’existant plutôt que d’essayer de construire rapidement une grosse brique.

On nous demande souvent un système complet futur. Il ne faut pas partir de cette cible, mais de l’existant, et définir le prochain pas. Je garde la cible business en tête, mais je fais des petits pas, sans perdre le lien avec l’existant.

Le vrai risque, c’est de s’engager dans un projet trop gros, trop long, qui n’atterrit jamais parce que la cible bouge.

Le vrai risque, c’est de s’engager dans un projet trop gros, trop long, qui n’atterrit jamais parce que la cible bouge. La question n’est pas « à quelle vitesse je construis une cible fixe ? », mais « à quelle vitesse je m’adapte à une cible mouvante ? ».

On me demande sans cesse « pour quand ce sera prêt ? ». Ce n’est pas comme ça que ça fonctionne. La semaine suivante, on me repose la même question pour une évolution du même projet. Je réponds que l’on avance par petits pas. C’est passionnant, mais inconfortable pour beaucoup. Je suis perçu comme toujours en retard… ce n’est pas totalement faux (rires). Mais les projets avancent, les problèmes sont résolus, la production tourne. J’atteins mal les cibles, mais la production tourne (rires).

Est-ce aussi votre rôle d’incarner la culture tech dans l’entreprise ?

Oui, de façon colossale, mais pas en tant que garant. Plutôt en tant qu’éducateur. Chez Tech.Rocks, on échange entre tech leads et on réalise qu’on a tous les mêmes problèmes, alors qu’on pense souvent être seuls. Nos dirigeants ne connaissent pas la tech : il ne s’agit pas d’être garant, mais d’expliquer. Et d’insister sur l’importance, pour les techs, d’avoir un avis business, plutôt que de se contenter de justifier des retards.

Il y a un livre fabuleux, A Seat at the Table de Mark Schwartz, qui explique que la question « pourquoi ce projet n’est pas livré ? » est la mauvaise question. La vraie, c’est : « comment la tech peut aider à atteindre d’autres objectifs ? » Je me vois donc davantage comme un contributeur business que comme un garant de la tech.

L’IA crée aujourd’hui un décalage entre dirigeants et équipes. Est-ce comparable ?

Oui, mais de façon plus logique : les patrons ne connaissent pas et posent des questions. Avec le cloud ou les langages, cela ne se passait pas ainsi. Avec l’IA, le questionnement revient à la bonne hauteur, et c’est intéressant.

Il y a le risque qu’on impose d’en faire « parce que ça vend », mais ce n’est pas la blockchain. Ici, on a une transformation drastique de tout notre domaine grâce à de nouveaux modèles. On doit expliquer quelque chose dont on ne comprend pas encore complètement l’impact. C’est passionnant. Et on observe de tout : des techs qui refusent car « ça ne marche pas encore », des patrons qui en veulent alors que ce n’est pas adapté. C’est une phase rigolote.

Avez-vous fait des erreurs dans votre carrière et que vous ont-elles appris ?

Comme tout le monde. La vraie question, c’est : quand est-ce que je n’ai pas fait d’erreur ? Je fais du golf, un sport dédié à la gestion de l’erreur. C’est mon concept : je fais des erreurs parce qu’on n’a pas assez de développeurs et qu’on gère des systèmes imparfaits en production.

La vraie question, c’est : est-ce que j’ai fait des erreurs irréversibles ? C’est ce qui m’empêche de dormir. Les erreurs réversibles, ou les erreurs volontaires pour apprendre, ça va. Les vraies erreurs, ce sont les irréversibles. J’essaie de les limiter en me demandant si un choix est réversible.

Refuser d’apprendre est la plus grosse des erreurs. Chercher la faute ou justifier, c’est refuser l’erreur, et c’est dangereux.

On apprend toujours de ses erreurs, sauf quand on répète la même. Refuser d’apprendre est la plus grosse des erreurs. Chercher la faute ou justifier, c’est refuser l’erreur, et c’est dangereux.

Il y a une dualité entre les perfectionnistes, qui refusent l’erreur et veulent réussir du premier coup, et ceux qui construisent sur l’essai-échec. Deux modèles mentaux acceptables. Je suis clairement dans le camp de ceux qui apprennent en faisant des erreurs. Travailler avec des perfectionnistes est plus dur… pour eux surtout (rires). Moi, j’aime bien : j’ai un juge de paix pour savoir si c’est bon ou pas.

Quels sont les grands chantiers que vous voyez arriver dans les prochaines années ?

Pour Back Market Pro, la grande question est : est-ce que je rejoins la plateforme Back Market un jour ? La réponse n’est pas encore donnée. Soit j’ai une nouvelle plateforme et c’est très bien, soit je dois rejoindre. À partir de quel niveau de chiffre d’affaires sur Shopify cela devient-il indécent ? Petite parenthèse : Shopify est un système incroyable, je ne lui connais pas de limite pour l’instant. Bonne surprise.

Et dans mon métier, le grand chantier, c’est l’intégration d’un nouveau type de travailleurs : les travailleurs virtuels. J’ai l’impression d’avoir une armée infinie à apprendre à utiliser. Les agents, les modèles… bientôt des groupes, des équipes d’agents. Nous allons devoir éduquer des équipes automatisées. C’est déjà notre métier depuis longtemps : faire des process, des systèmes, de l’automatisation. Il y a 20 ans, on parlait déjà de modèles d’agents, de workflow, d’automatisation. Les concepts ne sont pas nouveaux, mais ils deviennent réels et pertinents.

Comment intégrer une équipe virtuelle dans mon métier ? C’est passionnant.

Dimitri Baeli, Head of Software Engineering

Dimitri Baeli est Head of Software Engineering de Back Market Pro, où il pilote la plateforme B2B de l’entreprise. Il est cofondateur de Tech Rocks, ancien CTO des Furets et ancien CPO d’Aramis Auto. Il a également cofondé FlowCon, conférence dédiée au continuous delivery.