Pretto : comment arbitrer entre build et buy pour scaler efficacement

Pretto est une fintech française spécialisée dans le courtage en crédit immobilier. Depuis sa création il y a 8 ans, elle a largement bousculé les codes d’un secteur très réglementé en proposant une approche 100 % digitale. Et en 2021 une nouvelle étape a été franchie avec le lancement d’un réseau de mandataires indépendants.

Aujourd’hui, l’activité se partage entre les clients servis à distance et ceux accompagnés par les 300 mandataires affiliés. Ce développement a reposé sur un enjeu central : proposer une suite d’outils efficace, moderne et unifiée. Une question stratégique s’est donc rapidement posée : faut-il construire ces outils en interne, ou s’appuyer sur des solutions externes existantes ? Nous vous proposons de découvrir aujourd’hui l’interview de François Sevaistre, CTO de Pretto.

Dans une fintech comme Pretto, où réglementation et rapidité d’exécution sont clés, quels critères guident vos choix entre build et buy ?

François Sevaistre : On revient toujours à deux critères simples :

1. Est-ce que la brique en question est un maillon de valeur que l’on apporte directement à nos clients ?
2. Est-ce que ça impacte notre image de marque et l’expérience utilisateur ?

Quand la réponse est oui, on préfère construire.

C’était le cas de notre CRM. On voulait offrir une expérience utilisateur unifiée et moderne. Quant au mandataire, il doit pouvoir gérer ses clients, suivre ses prospects, monter ses dossiers… et tout ça dans un univers produit cohérent, avec une ergonomie simple. Si on avait acheté une solution externe type SugarCRM ou customisé davantage Salesforce, on aurait eu un coût variable croissant avec le réseau et une dépendance forte à un environnement contraint.

Nous avions déjà beaucoup customisé Salesforce, et on savait qu’on devrait de toute façon écrire du code spécifique. Dans ces conditions, mieux valait construire chez nous, dans notre logique, plutôt que d’empiler des solutions tierces.

Enfin, il y avait un enjeu financier de long terme : au début, build coûte plus cher qu’une licence SaaS, mais une fois l’investissement fait, les coûts sont lissés et diminuent au fur et à mesure que l’activité scale.

Ce choix organisationnel a eu un impact sur vos équipes tech ?

François Sevaistre : Oui, et c’est même central dans notre philosophie. Nous sommes une petite équipe tech. Nous avons toujours voulu rester resserrés, avec des développeurs responsables d’un bout entier de la stack.

Quand nous avons décidé de construire notre CRM, j’ai recruté un responsable et deux ingénieurs : ils avaient la pleine responsabilité de cette brique. Leur mission allait du design à la livraison, en passant par les choix techniques. Ce modèle responsabilisant change tout : ils ne sont pas de simples “ticket takers”, mais des ingénieurs qui comprennent les besoins, participent aux discussions avec le produit et le design, et proposent les meilleures solutions.

C’est un facteur de rétention important. Un développeur qui ne fait qu’exécuter finit par se lasser et partir. En revanche, un ingénieur qui est identifié comme responsable d’un périmètre voit son impact concret sur le business. C’est beaucoup plus valorisant.

Concrètement, comment la décision a-t-elle été prise ?

François Sevaistre : Elle s’est faite en deux temps. D’abord, fallait-il acheter ou construire ? Cette première étape a impliqué tout le monde : le business, le produit, la tech, le design… et même les futurs utilisateurs, les mandataires. Nous avons échangé avec eux pour comprendre leurs attentes et prioriser les besoins. Leur implication a renforcé la pertinence de notre choix.

Ensuite, une fois la décision de construire prise, il a fallu trancher sur la stack technique. Là, c’était un choix purement tech, avec pour ligne directrice : construire quelque chose de simple, léger et maintenable.

Trois ans plus tard, quel bilan tirez-vous ?

François Sevaistre : Le bilan est positif. Aujourd’hui, plus de 300 mandataires travaillent chaque jour avec cet outil. C’est littéralement leur gagne-pain, puisqu’ils ne sont rémunérés qu’à la commission. Il était donc vital que l’outil soit robuste, fiable et ergonomique.

Nous continuons de le faire évoluer, en intégrant par exemple des fonctionnalités basées sur l’IA. Mais nous faisons toujours attention à une chose : une fonctionnalité, aussi impressionnante soit-elle, ne sert à rien si elle n’est pas utilisée. Le vrai enjeu, c’est de placer les features au bon endroit pour que leur adoption soit naturelle.

Sur le plan financier, il est clair qu’à ce stade nous avons payé plus cher que si nous avions pris des licences Salesforce. Mais l’expérience utilisateur est bien meilleure, et l’adoption incomparable. Quand vous recrutez des courtiers qui travaillaient auparavant au papier-crayon, chaque heure gagnée sur la formation vaut de l’or.

À l’inverse, quelles briques considérez-vous comme non différenciantes et donc externalisables ?

François Sevaistre : Il y en a plusieurs.

• IA : nous n’entraînons pas notre propre LLM, ce n’est pas notre métier. Pour gérer nos prompts et leur versioning, nous utilisons Langfuse.

• Pipeline de données : nous avons Segment pour collecter et redistribuer les événements utilisateurs. Pour l’instant, on achète, mais vu le coût, on réfléchit à l’internaliser.

• Emailing : nous utilisons encore un bout de Salesforce pour router les emails vers les bons clients. C’est cher, et probablement voué à être reconstruit en interne.

En résumé, tout ce qui n’apporte pas directement de valeur différenciante à nos clients peut être acheté.

Quels conseils donneriez-vous à un CTO qui hésite entre build et buy ?

François Sevaistre : Chaque ligne de code que vous écrivez est une dette de maintenance. Donc si vous pouvez outsourcer, faites-le. Le buy est un excellent moyen de tester rapidement un use case. Si ça ne fonctionne pas, vous changez et ce n’est pas grave.

Le vrai piège, c’est de construire trop tôt. Une fois que vous avez investi en interne, vous défendez votre solution même si elle ne correspond plus aux besoins. Alors qu’avec une solution achetée, vous gardez la liberté de pivoter.

Mon conseil : commencez par acheter, validez le besoin, puis seulement construisez ce qui est réellement stratégique pour votre business.