One Shot #7 — Rudy Onfroy (Capcar) : plus de PM, plus de roadmap, 15 mises en prod par jour

Pour ce septième épisode de One Shot, le podcast de The One Studio, Alexandre Bour reçoit Rudy Onfroy, CTPO de Capcar, la plateforme d’intermédiation dans la voiture d’occasion. Une levée de fonds qui ne passe pas, une entreprise qui passe d’une centaine de personnes à une quinzaine et pivote vers un réseau d’agents indépendants, et une équipe tech qui ne garde que des développeurs. Résultat : plus de product managers, plus de QA, plus de roadmap, et 10 à 15 mises en production par jour. Un échange sur la responsabilisation des devs, la qualité, l’IA et un modèle où les agents deviennent de vrais entrepreneurs.

Écouter l’épisode

One Shot #7 : Rudy Onfroy (Capcar), le dev qui fait tout

Ce qu’il faut retenir

L’adversité comme accélérateur : faute de pouvoir lever, Capcar pivote d’un modèle 100 % salarié vers un réseau d’agents indépendants. « Je pense que cette difficulté, c’est la meilleure chose qui soit arrivée. »
Un dev qui fait tout : plus de PM, de designer ni de QA. Chaque développeur discute avec le métier, conçoit, code, teste, met en production et assure le support. On passe d’une mise en prod par semaine à 10 ou 15 par jour.
Tester soi-même, c’est apprendre à tester : « Quand tu es habitué à ce que quelqu’un teste derrière toi, tu n’apprends pas à tester correctement. » D’abord le test manuel, ensuite l’automatisation pour gagner du temps.
L’IA change l’outil, pas le métier : plus personne dans l’équipe n’écrit de code à la main, et les équipes métiers sont elles aussi sur Claude Code. « Si tu n’as pas besoin de coder, tu restes un développeur : tu apportes des solutions grâce à la technologie. »
Pas de recette miracle pour les grands groupes : leur enjeu est d’abord de ne prendre aucun risque sur l’existant, avec des pivots sur trois à cinq ans. Le rythme d’une start-up ne s’y transpose pas tel quel.
Des agents qui entreprennent : les agents recrutent, forment et accompagnent d’autres agents, et sont rémunérés sur plusieurs niveaux. Leur réseau devient un fonds de commerce revendable. Côté tech, Capcar a internalisé son CRM, son ATS et son LMS pour servir ce modèle.

À propos de The One Studio

The One Studio est un collectif passionné de tech et de product. Découvrez nos services (renfort d’équipe tech, équipes dédiées, product management, design UX/UI) ou contactez-nous. Retrouvez tous nos épisodes sur la page Média.

Transcription complète de l’épisode

Transcription de l’échange entre Alexandre Bour (fondateur de The One Studio) et Rudy Onfroy (CTPO de Capcar). Éditée pour la lisibilité.

Bienvenue sur One Shot, le podcast de The One Studio. Je suis en compagnie de Rudy Onfroy, CTPO de Capcar. Je t’ai découvert sur LinkedIn et j’ai eu envie de comprendre comment tu construisais du produit, parce que ce que vous faites est à contre-courant de ce qu’on attend d’une boîte produit aujourd’hui. Qui es-tu, et qu’est-ce qui t’a amené à être CTPO chez Capcar ?

À la base, je suis un passionné de tech. Je suis tombé dans le développement assez jeune, il y a plus de quinze ans, et j’ai trouvé ma voie avec ça. Après de longues études, je suis passé par une mutuelle, le e-commerce, l’intermédiation, la presse, puis j’ai rejoint Capcar il y a six ans et demi.

Pour ceux qui ne connaissent pas, c’est quoi Capcar ?

Une boîte d’intermédiation dans la voiture d’occasion. Si tu veux vendre ta voiture, soit tu vas chez un concessionnaire, c’est rapide mais il massacre ton prix. Soit tu passes par Le Bon Coin : tu ne sais pas la positionner en prix, ni prendre les photos, tu as cinquante personnes qui t’appellent, et des deux côtés tout le monde a peur de se faire arnaquer. Capcar, c’est le service du concessionnaire au prix de la vente entre particuliers. On vient chez toi, on prend les photos, on inspecte le véhicule, on diffuse l’annonce sur tous les sites, on répond au téléphone à ta place, on trouve le bon acheteur, qui réserve en ligne, puis on organise la transaction : vous signez les papiers et tu touches ton argent le jour même. L’agent qui se déplace est un indépendant rémunéré pour ça, et Capcar lui fournit tout l’outillage : les produits e-commerce, la diffusion, une application d’inspection, un CRM interne.

Tu es arrivé avec un profil de dev. Il a fallu construire une personne différente pour ce poste ?

Oui et non. Je suis arrivé comme VP Engineering, j’ai rapidement pris les responsabilités de CTO, puis je me suis tourné de plus en plus vers le produit. À mon arrivée, on avait une organisation classique : du Scrum, des équipes produit, des équipes techniques. Et il y a quelques années, on a eu un événement majeur : on n’a pas pu lever. On vivait de levées de fonds pour grossir jusqu’à la rentabilité, et avec la crise du financement, ça n’est pas passé. Là, il s’est passé quelque chose de plutôt magique : on a pivoté notre business model.

Qu’est-ce qui a changé ?

Historiquement, tout était fait par des salariés : des commerciaux qui géraient les vendeurs au téléphone, d’autres les acheteurs, des inspecteurs sur le terrain, des gens pour les transactions. Beaucoup d’humains à chaque étape, avec la complexité et la motivation à gérer qui vont avec. Avec ce problème de levée, on a fortement réduit la voilure : on est passés d’une centaine de personnes à une quinzaine, des services entiers ont disparu, et on est entrés en redressement judiciaire. On en a profité pour pivoter totalement. Nos forces, c’étaient la technologie, la marque et le service. Plutôt que d’apporter ce service nous-mêmes, on s’est associés à des agents indépendants, des entrepreneurs qui créent leur boîte pour vendre des voitures. On leur a donné accès à nos outils, on leur a confié progressivement nos différents rôles, et on leur a reversé une bonne partie de la commission.

Et tout le logiciel existant ?

Il fallait l’adapter à un utilisateur différent. Un utilisateur interne a un métier très borné ; un indépendant, tu ne lui donnes pas les mêmes choses. Il faut l’aider à facturer, gérer autrement le CRM, que tu ne peux plus faire dans un logiciel externe. Côté produit et tech, on a dû réduire l’équipe, et la première chose réduite, c’est l’équipe produit. On n’a gardé qu’un petit nombre de développeurs pour tout construire, avec des défis gigantesques et beaucoup moins d’argent.

Donc tu revois toute la roadmap.

On a arrêté de faire des roadmaps. L’idée était de rendre chaque développeur le plus autonome possible. On est passés d’une chaîne classique PM, designer, développeur, à un développeur capable de tout faire : discuter avec les équipes métier, élaborer les solutions, développer, tester, et même être en support auprès de nos agents pour récolter leurs retours et traiter les anomalies. Quand c’est la même personne, tu peux prendre plein de raccourcis : sauter les maquettes, aller chercher du feedback sur quelque chose qui fonctionne déjà, mettre en production et itérer à un rythme impossible avant. On est passés d’une mise en production par semaine au mieux à 10 ou 15 par jour.

Comment tu crées ce type d’environnement avec des gens qui étaient là avant ?

Si tu veux faire un pivot comme ça, il faut que chaque personne qui reste comprenne où on va, soit engagée et y croie. Ça a été assez simple : tout le monde y a cru. L’UI et l’UX, ça prend du temps quand tu as l’habitude de coder et qu’on te demande de penser parcours utilisateur et recherche. Mais le premier truc à déconstruire, c’était la QA. Quand tu es habitué à ce que quelqu’un teste derrière toi et te dise « c’est bon, tu as fait du bon taf », tu n’apprends pas à tester correctement. Quand c’est toi qui fais, qui livres, qui mets en prod, tu changes ta façon de voir : tu testes sur ta machine, sur le staging, tu regardes en prod que ça marche, tu suis les logs, tu fais le monitoring, et tu avances par petits cycles. Beaucoup de devs pensent qu’ils perdent leur temps à tester et qu’un QA, dont c’est le métier, fera mieux. Et côté QA, on te dit : « Regarde ce que je détecte quand je teste. Si j’arrête, il se passe quoi ? » En fait, le fait qu’un autre teste crée un garde-fou qui fait baisser la vigilance de celui qui livre.

Il faut alors poser des standards, du TDD, former tout le monde ?

Pas besoin de former tout le monde au TDD au début. Le truc souvent négligé, c’est de responsabiliser le développeur. Tu lui demandes : « Tu viens de construire une feature, comment tu la testes ? À quoi c’est lié dans ton système ? Où sont tes effets de bord ? » On se rend vite compte que le développeur qui a conscience de ça est le mieux placé pour tester. D’abord apprendre à tester manuellement, ensuite automatiser ce qui peut l’être pour gagner du temps. Et des développeurs responsables de toute la chaîne sont conscients de l’impact business de ce qu’ils font : s’ils cassent la prod, ce sont eux qui gèrent le support.

C’est une question de casting ?

Pas seulement. Dans le bon environnement, un dev peut s’épanouir et apprendre. Recruter uniquement des devs qui ont connu ce genre d’organisation, c’est quasi impossible : il y en a très peu sur le marché. Il faut prendre des gens compétents sur plusieurs dimensions et les aider à progresser sur les autres, avec le bon coaching et la bonne équipe.

Comment as-tu fait accepter qu’il fallait garder les devs ?

C’était ma réflexion. Ce qui fait perdre du temps, ce sont les interactions. Quand tu as des choix durs à faire, tu regardes ce dont tu as vraiment besoin pour avancer. Si je n’ai que des PM, je ne peux rien livrer. Si je n’ai que des QA, je ne peux rien livrer. Combien de temps pour leur apprendre à coder ? Très longtemps. Avec des devs, combien de temps pour leur transmettre des compétences produit, business, QA, monitoring, infrastructure ? Le constat, c’est que c’est plus rapide. Il y a aussi un côté personnel : je savais le faire moi-même, donc je savais que c’était possible. Et j’ai construit, de manière un peu égoïste, l’organisation dans laquelle j’aime travailler.

Tu continues à coder ?

On est neuf dans l’équipe tech, que des devs. Je passe la moitié de mon temps en réunions et en points individuels, et l’autre moitié je produis. C’est possible parce qu’ils sont autonomes : je n’ai pas besoin de donner des specs ultra détaillées. On a une problématique business, vas-y, fonce, va discuter avec les gens. L’ownership est sur une seule personne, mais pour faire les bons choix, elle va chercher les bonnes infos au bon moment : l’avis de l’équipe sur un sujet d’architecture, les experts métier sur un sujet métier. Et c’est vrai aussi avec nos clients principaux, nos agents : un réseau de plusieurs centaines d’agents indépendants partout en France, avec qui tout le monde au siège échange en direct, sans proxy qui édulcore l’information.

Le Covid, la fin de l’argent magique : ça a pesé sur le changement de modèle ?

Il y a l’envie de changer et la capacité à changer. Quand tu es dos au mur, tu n’as pas le choix. Tu fais ton pivot, tu vas à fond, tu ne vas pas doucement pour voir si ça marche. Le changement est rapide, immédiat, imposé par l’environnement.

La pression a fait le diamant ?

Je pense que cette difficulté, c’est la meilleure chose qui soit arrivée. Il y a eu des moments pas simples : perdre la moitié de ses collègues du jour au lendemain, et devoir l’annoncer. Mais c’est dans l’adversité que tu construis des choses qui marchent. Quand tu as dix euros, tu vas les claquer ; quand tu as un euro, tu vas le mettre au bon endroit. Et quand ça va mieux, tu le gardes. Chez nous, l’amélioration continue, ce n’est pas une rétrospective toutes les deux semaines qui tourne au bureau des pleurs : c’est quotidien. Avec quinze mises en prod par jour, tu vois la conséquence de ton travail le soir même. J’ai encore des développeurs qui me disent qu’on va trop vite. Ma réponse est toujours la même : on ne va jamais assez vite.

Et l’IA dans tout ça ?

On vit un nouveau bouleversement, et je pense que notre organisation est la plus adaptée. Grâce à l’IA, il ne manque plus personne dans l’équipe tech. Ils sont tous très bons en algo, et pourtant plus aucun d’entre eux n’écrit une seule ligne de code. Il reste l’architecture, le produit, et des manières de faire qu’on reconstruit tous les jours. On pousse ça à l’extrême : toute l’équipe tech est sur Claude Code, et nos équipes métiers aussi. Des applications internes se créent, des process s’automatisent : on a mis les bons outils dans les mains de tout le monde.

Les devs sont morts ?

Je n’irais pas jusque-là. Ceux qui sont en danger, ce sont ceux qui n’utiliseront pas l’IA pour démultiplier ce qu’ils font et faire le travail de cinq personnes. Et ce n’est pas que les développeurs : au siège de Capcar, c’est 100 % des gens qui vont devoir évoluer. Les profils business vont devoir développer des compétences techniques, et les profils tech et produit se rapprocher du métier. Si le métier de dev, c’était de coder, il change totalement. Si c’était d’apporter des solutions grâce à la technologie, il ne change pas. Il y a quelques années, quelqu’un qui faisait du no-code pouvait être développeur. Aujourd’hui, tu as l’IA : si tu n’as pas besoin de coder, tu restes un développeur. Il faut quand même comprendre l’architecture, le fonctionnement d’une base de données, savoir lire le code. Mais tu n’as pas forcément à relire chaque ligne produite par l’IA, qui peut aussi t’aider à tester et à repérer les points de vigilance.

C’est réplicable dans un grand groupe, avec beaucoup de complexité métier et d’interlocuteurs ?

Il faut le voir autrement. Dans une grande structure, le premier enjeu est de ne prendre aucun risque sur ce que tu as déjà, qui te fait vivre. Tu vises quelques points de croissance par an, et les pivots se font sur trois, quatre, cinq ans. Tu n’as pas besoin de bouger aussi vite, tu as besoin de sécuriser. Ça va changer, peut-être beaucoup, mais pas comme dans une start-up qui se lance. Et peut-être que Capcar, dans dix ou quinze ans, cherchera moins d’agilité qu’aujourd’hui.

Parle-nous du modèle multi-niveaux.

Ce n’est pas un modèle à la Uber avec des indépendants qui exécutent. Nos agents ont remplacé progressivement les équipes commerciales et l’organisation des transactions, et ils sont devenus recruteurs. Un agent en recrute d’autres, les coache, les forme, et touche des commissions sur ce qu’ils vendent, sur plusieurs niveaux : c’est le multi-level marketing. Les intérêts convergent : le parrain donne son temps, et une fois ses filleuls efficaces, il en tire des revenus sur le long terme. Avec un grand réseau d’agents, on a autant de recruteurs et de coachs potentiels, et autant de personnes qui communiquent sur les réseaux. Ce sont des entrepreneurs qui travaillent avec Capcar et dans Capcar.

La mission de Capcar a donc changé ?

Avant, on accompagnait les acheteurs et les vendeurs dans leurs projets automobiles. Maintenant, la mission est d’aider des gens à entreprendre dans l’automobile, et ce sont eux qui accompagnent acheteurs et vendeurs. Nos agents viennent d’horizons très variés : anciens commerciaux, anciens militaires, gens de la concession, et même de l’informatique, passionnés d’auto. Certains sont devenus parrains de grands réseaux et gagnent très bien leur vie. Un réseau constitué devient un fonds de commerce : un agent qui part à la retraite peut le revendre à un autre agent. On ne construit pas une boîte pour que le siège gagne beaucoup d’argent, mais pour les aider à entreprendre.

Comment construire un produit qui sert à la fois la marque et des entrepreneurs aux stratégies différentes ?

La tech fait gagner du temps, mais elle sert aussi à poser des contraintes. Un véhicule sera inspecté de la même manière quel que soit l’agent, et diffusé de la même manière sur tous les sites. Pour le reste, ils ont une vraie liberté : certains font quatre-vingts heures par semaine, d’autres quinze. Certains misent sur le volume, d’autres sur peu de véhicules vendus très vite. En échangeant avec le réseau, on développe ce dont ils ont besoin et on aligne tout le monde : mieux ça marche pour eux, mieux ça marche pour nous.

Et pour lancer une nouvelle ligne de business ?

Cette année, on a lancé une plateforme de reprise destinée aux professionnels, pour les véhicules qu’on ne traitait pas : trop anciens, trop kilométrés, parfois qui ne roulent pas. Nouveau site, plateforme de diffusion, système d’enchères, le tout relié à nos outils. On savait qu’il y avait une demande, par les remontées des agents et par l’analyse du marché. Nos agents vont voir les garagistes et les professionnels pour les inscrire, et à chaque vente, l’agent, son parrain et le parrain du parrain sont rémunérés. On a aussi internalisé beaucoup d’outils : on avait HubSpot, on a développé notre CRM ; nos agents recrutent, on a développé notre ATS, avec l’onboarding et la création de comptes automatisés ; on avait un LMS externe, on a tout redéveloppé cette année, intégré à nos données.

On termine par le tac au tac. Roadmap stricte ou improvisation totale ?

Il n’y a jamais d’improvisation totale. Le but n’est pas de suivre un plan défini il y a trois mois, mais de saisir l’opportunité la plus importante maintenant. On partage une vision, pas une roadmap millimétrée.

Data ou intuition ?

Data, sans aucun doute. L’intuition est trompeuse ; on est très itératifs, on livre pour mesurer.

Audace ou prudence ?

L’audace, en sachant être prudent par moments.

Freestyle ou routine ?

Freestyle. La routine, tu t’ennuies et tu perds en créativité. Je fonctionne au contexte : qu’est-ce qui est le plus important à faire là, maintenant ?

Ville ou nature ?

Nature. La ville, de temps en temps, pour venir voir les collègues à Paris. Nos équipes métier viennent beaucoup au siège, et j’ai des développeurs aux quatre coins de la France et jusqu’à Madagascar.

Il faudra faire une V2 pour expliquer comment fonctionne une équipe de dev complètement décentralisée, sans PO.

J’ai la réponse : un super projet, Capcar, une super organisation, toute la liberté nécessaire et les bonnes responsabilités.

Merci Rudy.