Voilà six ans que Jeremie Lebrun évolue chez BlaBlaCar, après une dizaine d’années passées en cabinet de conseil. Aujourd’hui Head of Engineering – Corporate Services, il pilote une équipe de 35 personnes chargée de tous les outils internes de l’entreprise : laptops, réseaux, outils RH, finance, CRM, automatisation, ou encore applications liées à l’activité bus. En clair, tout ce qui n’est pas directement destiné aux utilisateurs finaux mais qui permet aux 800 employés, répartis dans six pays, de travailler efficacement.

Quels critères techniques et business guident vos choix entre développer une solution en interne ou recourir à un outil tiers ?

Jeremie Lebrun : Nous ne sommes probablement pas très originaux : d’un côté, les développeurs sont une ressource rare. De l’autre, il existe sur le marché des solutions pensées par des gens plus matures que nous sur un bon nombre de sujets, et qui y ont déjà beaucoup réfléchi.

Notre principe est simple : tout ce qui est différenciant vis-à-vis de la concurrence et nous aide à avancer sur notre vision produit, nous le développons en interne. À l’inverse, tout ce qui n’est pas différenciant, nous allons le chercher « sur étagère ». Par exemple, il n’y a aucun intérêt pour nous de développer un logiciel de finance et de comptabilité. En revanche, pour nos algorithmes de modération d’échanges entre covoitureurs, nous sommes les seuls à disposer de l’expérience et du contexte business : cela reste un développement maison.

Mais entre les deux, il y a une zone grise. Les arbitrages se font alors sur des critères de maintenabilité, de couverture marché, de coût et d’impact organisationnel.

Un exemple : pour le service BlaBlaCar Bus, nous avons dû mettre en place un système de communication avec les passagers en cas de retard. Au départ, nous avons acheté une solution existante, car nous n’avions pas l’équipe disponible et nous ne savions pas encore exactement ce que nous voulions. Deux ans plus tard, les enjeux étant devenus plus spécifiques, nous avons internalisé le développement.

Comment évaluez-vous le coût réel du “build” par rapport au coût du “buy” ?

Jeremie Lebrun : Côté build, il faut calculer : quelle équipe est impliquée, pendant combien de temps, avec quelle infrastructure et quelle complexité produit. Notre expérience nous permet d’estimer la taille de l’équipe nécessaire et l’horizon de livraison. Nous essayons toujours de rester sur des technologies déjà maîtrisées, pour éviter d’ajouter une dette technique inutile.

Côté buy, il ne s’agit pas seulement de licences. Il y a toujours un coût de paramétrage, de connexion aux systèmes internes, d’administration, de sécurité et de produit. Puis il faut compter la maintenance dans le temps. Un SaaS n’élimine pas les problèmes : il apporte aussi son lot d’évolutions et de contraintes.

La dépendance à l’éditeur fait partie du choix initial. Il ne faut pas espérer avoir « le beurre et l’argent du beurre » : quand on choisit une solution SaaS, il faut accepter une part de dépendance, l’assumer et la gérer en conséquence.

Dans un contexte comme celui de BlaBlaCar, où la plateforme doit gérer une forte croissance et des pics de charge, quelles décisions build vs buy se révèlent les plus structurantes ?

Jeremie Lebrun : Nous avons une approche pragmatique : la dette technique n’est pas un gros mot. Elle peut avoir de la valeur si elle permet d’accélérer le time-to-market. L’important est de l’accepter collectivement dès le départ, comme une dette financière : on sait qu’il faudra la rembourser plus tard, mais le bénéfice immédiat peut être supérieur au coût futur.

Exemple : pour notre système d’envoi de SMS aux passagers, nous avons d’abord acheté une solution externe. Pendant deux ans, nous avons envoyé plus de 4 millions de SMS, ce qui a permis de gagner plus de 10 points de NPS. Quand nous avons internalisé, nous savions exactement ce que nous voulions faire. Le travail de codage pur restait à faire, en revanche, 80% du travail de product management avait déjà été réalisé, ce qui a rendu le développement plus rapide et plus pertinent.

Regrettez-vous certains de vos choix ?

Jeremie Lebrun : Il y a eu des cas où nous n’avions pas choisi le bon partenaire et avons dû changer. Mais globalement, ce sont des ajustements normaux dans la vie d’un projet d’ingénierie, et nous avons eu la chance de ne pas avoir à regretter un choix entre make et buy.

En quoi vos choix build vs buy influencent-ils la culture tech de BlaBlaCar et l’organisation des équipes ?

Jeremie Lebrun : Historiquement, BlaBlaCar a une forte culture tech : tout était développé en interne. L’introduction de solutions SaaS et low-code a donc demandé un vrai travail de pédagogie. Il a fallu dépassionner le débat : bien sûr, nos développeurs sont capables de tout coder, mais leur temps est précieux. Développer un outil de ticketing n’aurait aucun sens.

Cela implique aussi du change management : une squad agile qui livre toutes les deux semaines ne fonctionne pas au même rythme qu’un éditeur SaaS qui déploie une nouvelle version tous les deux mois. Il a fallu harmoniser les méthodes de travail, fluidifier la communication et aligner les attentes.

Est-ce qu’il n’y a pas aussi une question d’égo à gérer chez les développeurs ?

Jeremie Lebrun : Oui, comme partout quand on compare deux approches. Mais il existe des profils de développeurs qui aiment justement s’orienter vers l’écosystème SaaS, comme Salesforce. D’autres en ont assez de coder toujours les mêmes choses et trouvent un nouveau souffle dans l’administration ou l’intégration. Le principal est de dépassionner la question : oui, nos devs peuvent tout faire, mais parfois il est plus intelligent d’utiliser une solution déjà prête à 80 %.

Quels conseils donneriez-vous aux startups et scale-ups qui font face à ces choix ?

Jeremie Lebrun : Rester très ouverts et objectifs. Beaucoup de scale-ups veulent tout construire elles-mêmes, mais externalisent rapidement la partie « ops » (CRM, automatisation). Ce qui compte, c’est de prendre en compte le coût complet : build, maintenance, organisation, dépendance. Il n’y a pas de bon ou mauvais choix en soi, seulement de bonnes ou mauvaises analyses.

Et surtout : ne prenez pas pour acquis le côté scalable ou non-scalable de telle ou telle technologie. Chez BlaBlaCar, nous avons envoyé des millions de SMS via une solution low-code, avec succès. Mais pour que cela fonctionne, il faut que le projet soit porté par les équipes tech (architecture, tests) et pas uniquement par les équipes métier. Sinon, le risque est que la solution ne passe pas à l’échelle.

Principales conclusions

• BlaBlaCar développe en interne les fonctionnalités essentielles et différenciantes, et utilise des solutions tierces pour les processus standard.
• L’évaluation des coûts inclut non seulement le développement ou la licence, mais aussi la maintenance et l’impact organisationnel.
• La dette technique peut être un levier stratégique si elle s’accompagne d’un ROI clair.
• L’intégration de SaaS et low-code nécessite un vrai travail de change management et de communication entre équipes