Construire une startup rentable sans capital-risque

Cantoo n'a jamais été censé être une entreprise financée par du capital-risque. Pas parce qu'on n'aurait pas pu lever des fonds, mais parce qu'on n'en avait pas besoin. On a construit une plateforme télécom cloud, on l'a rendue rentable en moins de deux ans à 400 000 euros de revenus annuels, et on l'a vendue à 42com. Le tout sans une seule levée de fonds.

Voici comment on a fait, et surtout, les décisions qui ont rendu ça possible.

Commencer par le revenu, pas la croissance

La première décision qui a tout conditionné a été d'optimiser pour le revenu dès le premier jour. Pas la croissance utilisateur. Pas la part de marché. Le revenu.

Ça semble évident, mais ça va à l'encontre de presque tout ce que l'écosystème startup te dit. La sagesse conventionnelle, c'est : grandis vite, occupe-toi de l'argent plus tard, lève une round pour te donner du runway. On a fait l'inverse. Avant d'écrire une seule ligne de code, on a eu des conversations avec des clients potentiels, des opérateurs télécom qui avaient besoin de services voix et messaging hébergés. On a validé qu'ils paieraient pour ce qu'on prévoyait de construire. Puis on l'a construit.

Notre premier client payant était sur la plateforme dans les trois mois suivant la première ligne de code. Pas un pilote. Pas un essai gratuit. Un client payant avec un contrat signé et des factures mensuelles. Ça a complètement changé notre psychologie. On ne construisait pas un produit en espérant que quelqu'un finirait par payer. On construisait un produit parce que quelqu'un payait déjà.

Ce à quoi on a dit non

Les décisions les plus importantes chez Cantoo n'étaient pas ce qu'on a construit. C'était ce qu'on a refusé de construire.

On a dit non à un beau dashboard. Nos opérateurs voulaient un accès API et des données brutes. Une UI soignée aurait été sympa, mais elle n'aurait pas généré un seul euro de revenu supplémentaire. On a construit un panneau d'administration fonctionnel qui faisait le job et on a investi ce temps de développement dans le système de facturation.

On a dit non au support de tous les protocoles. Le monde télécom a des dizaines de protocoles et de standards. On a choisi ceux dont nos clients cibles avaient besoin, SIP pour la voix, SMPP pour les SMS, et on les a bien faits. Un de nos concurrents a essayé de tout supporter. Il n'est plus en activité.

On a dit non au recrutement. Pendant les dix-huit premiers mois, l'équipe d'ingénierie c'était juste deux personnes. Mon cofondateur et moi faisions tout : architecture, développement, opérations, négociations avec les opérateurs, support client. Recruter aurait augmenté notre burn rate et nous aurait ralentis. Chaque nouvelle personne a besoin d'onboarding, de management et d'alignement. À notre stade, la vitesse comptait plus que la capacité.

On a dit non aux bureaux. On travaillait à distance avant que ce soit à la mode. Pas de bail, pas de trajet, pas de budget machine à café. Ça nous a économisé des dizaines de milliers d'euros qui sont allés directement dans les coûts d'infrastructure et les dépôts opérateurs.

L'économie du bootstrapping

Soyons précis sur les chiffres, parce que les conseils vagues sur le bootstrapping sont inutiles sans contexte.

Notre investissement initial était proche de zéro en cash, juste notre temps et notre équipement existant. Les coûts majeurs étaient l'infrastructure (serveurs, cluster Kubernetes, outils de monitoring), l'interconnexion opérateur (dépôts exigés par les opérateurs télécom pour commencer à router du trafic) et la conformité réglementaire (frais de licence pour opérer en tant qu'opérateur télécom au Royaume-Uni, en France et en Allemagne).

Les dépôts opérateurs étaient le plus gros coût initial. Les opérateurs télécom exigent des dépôts avant de router du trafic via ta plateforme. Ce n'est pas optionnel. Sans ça, tu n'as pas de produit. On les a financés avec nos économies personnelles et les premiers revenus.

Le revenu venait des frais par minute et par message facturés à nos clients opérateurs. Les marges en télécom wholesale sont fines, typiquement 5-15 % selon la route et le volume. Mais elles sont prévisibles. Une fois qu'un opérateur s'intègre à ta plateforme, il ne change pas facilement. Les coûts de changement sont suffisamment élevés pour que la rétention client soit intégrée au business model.

Au douzième mois, on couvrait tous les coûts opérationnels. Au dix-huitième mois, on était rentables. Au vingt-quatrième mois, on atteignait 400 000 euros de revenus annuels. Pas des chiffres de venture. Mais de l'argent réel qui nous appartenait entièrement.

Comment les contraintes nous ont aidés

La vision conventionnelle, c'est que les contraintes limitent ce que tu peux construire. J'ai trouvé l'inverse. Les contraintes nous ont forcés à nous concentrer, et c'est la concentration qui nous a rendus performants.

Sans capital-risque, on ne pouvait pas se permettre de construire des fonctionnalités de façon spéculative. Chaque fonctionnalité devait justifier son existence en termes d'impact sur le revenu. Ça voulait dire qu'on n'a jamais rien construit qui ne servait pas directement un client payant ou ne réduisait pas nos coûts opérationnels.

Sans grande équipe, on ne pouvait pas se permettre de dette technique. Il n'y avait personne à qui refiler du code mal écrit. Tout ce qu'on construisait, on devait le maintenir nous-mêmes. Ça créait une incitation naturelle à garder les choses simples et bien documentées.

Sans budget marketing, on devait compter sur la qualité de notre produit et nos relations opérateurs pour grandir. Nos opérateurs nous recommandaient à d'autres opérateurs parce que la plateforme fonctionnait de façon fiable et que la tarification était transparente. Le bouche-à-oreille est lent, mais c'est aussi gratuit et à haute confiance.

La décision de vendre

L'acquisition par 42com n'était pas motivée par le désespoir. On était rentables et en croissance. Mais 42com offrait quelque chose qu'on ne pouvait pas construire seuls : l'échelle.

En tant que fournisseur télécom wholesale, 42com avait des relations opérateurs et des volumes de trafic qui nous auraient pris des années à développer indépendamment. Joindre nos forces signifiait que notre technologie pouvait servir un marché bien plus large tout en bénéficiant de leur infrastructure commerciale.

La négociation a été simple parce que nos chiffres étaient propres. Les entreprises rentables avec des revenus prévisibles sont faciles à valoriser. On n'avait pas besoin de convaincre qui que ce soit du potentiel futur ou de la taille du marché. Le business parlait de lui-même.

J'ai mené l'intégration technique complète post-acquisition, fusionnant notre plateforme dans l'infrastructure de 42com. C'est là que l'architecture propre a encore payé. Parce que nos systèmes étaient bien documentés et modulaires, l'intégration a pris des mois, pas des années.

Ce que je referais

Si je lançais une autre entreprise bootstrappée demain, je garderais le même playbook.

Valide avec de l'argent, pas des sondages. Ne demande pas aux gens s'ils paieraient pour ton produit. Trouve quelqu'un qui va réellement payer avant de le construire.

Optimise le revenu par ingénieur. La métrique qui compte le plus dans une entreprise bootstrappée, c'est combien de revenus chaque membre de l'équipe génère. Garde l'équipe petite et la production élevée.

Choisis un marché avec du revenu récurrent. Le télécom a marché parce que les opérateurs paient mensuellement pour un service continu. Les ventes one-shot sont plus dures à bootstrapper parce que ton revenu repart à zéro chaque mois.

Dis non plus souvent que tu dis oui. Chaque fonctionnalité que tu construis a des coûts de maintenance continus. Dans une entreprise bootstrappée, tu ne peux pas te permettre de maintenir des fonctionnalités qui ne génèrent pas de revenus.

Garde tes coûts visibles. Je suivais chaque euro dépensé, chaque mois. Pas parce que je suis radin, mais parce que comprendre ta structure de coûts est le seul moyen de savoir quand tu es vraiment rentable plutôt que de juste te sentir rentable.

Ce que je ferais différemment

Deux choses.

J'aurais investi dans la vente plus tôt. On s'est appuyés trop longtemps sur l'intérêt entrant et les recommandations d'opérateurs. Un effort commercial à temps partiel à partir du sixième mois environ aurait accéléré notre croissance sans augmenter significativement les coûts.

J'aurais construit un meilleur monitoring dès le premier jour. On a ajouté un monitoring complet a posteriori, et c'était douloureux. En télécom, où l'uptime est primordial, le monitoring devrait être la première chose que tu construis, pas une réflexion après coup.

La leçon plus large

Le bootstrapping n'est pas pour tout le monde. Si tu construis un produit qui nécessite un investissement initial massif, une marketplace qui a besoin de liquidité des deux côtés, ou une entreprise hardware avec des coûts de fabrication, le capital-risque a du sens.

Mais pour du logiciel B2B avec des unit economics claires et des clients prêts à payer, le bootstrapping mérite une considération sérieuse. Tu gardes le contrôle. Tu gardes l'equity. Tu construis de la discipline. Et si ça marche, le résultat t'appartient entièrement.

Cantoo a prouvé, au moins pour moi, qu'on peut construire quelque chose de réel sans la permission des investisseurs. Les contraintes ne sont pas une limitation. Elles sont la stratégie.