Vous ne savez pas quels clients vous font gagner de l’argent : le trou noir des unit economics au niveau produit

Un fondateur me montre fièrement son tableau de bord : marge brute à 78 %, CAC payback à 11 mois, le board est content. Je lui pose une seule question : « Sur tes 40 clients, combien te coûtent plus cher qu’ils ne te rapportent ? » Silence. Il n’en a aucune idée. Personne dans l’équipe ne l’a jamais calculé, parce que personne ne sait comment.

Ce n’est pas un cas isolé. La quasi-totalité des startups SaaS pilotent leurs unit economics à la moyenne — un chiffre agrégé qui rassure et qui ment. « En moyenne rentable » veut souvent dire : quelques clients excellents financent une longue traîne de comptes qui grignotent votre marge sans que vous le voyiez. Et le jour où vous décidez de « scaler ce qui marche », vous scalez aussi, à votre insu, ce qui vous coûte.

Pourquoi la moyenne vous ment

Votre P&L consolide tout : l’hébergement cloud, les appels API vers vos fournisseurs (le modèle d’IA que vous facturez au forfait mais que vous payez au token, l’envoi d’emails, le stockage, les traitements batch), le support, la réussite client. Ces coûts sont bien réels, mais ils sont mutualisés dans une grande marmite. Résultat : vous voyez une marge brute globale, jamais une marge par client.

Le problème, c’est que la distribution de ces coûts est rarement uniforme. Dans un SaaS B2B typique, la consommation d’infrastructure suit une loi de Pareto brutale : 20 % des comptes génèrent 60 à 80 % de la charge. Un client « moyen » sur votre grille tarifaire peut, en réalité, faire tourner dix fois plus de requêtes, stocker cent fois plus de données, ou solliciter votre support trois fois par semaine. S’il paie le même prix que les autres, sa marge est négative — et il tire votre moyenne vers le bas pendant que vous croyez qu’il « contribue ».

Le cas le plus dangereux : le gros logo. Vous avez signé une PME connue, vous l’affichez sur votre page d’accueil, il vous ouvre des portes commerciales. Mais il a négocié 40 % de remise, il consomme un volume disproportionné, et son contrat inclut un SLA qui vous oblige à maintenir de la redondance coûteuse. Sur le papier, c’est votre plus gros client. Dans la réalité, c’est peut-être celui qui vous coûte le plus. Sans attribution fine, vous ne le saurez jamais — et vous en signerez d’autres comme lui.

C’est une décision d’architecture avant d’être un calcul financier

Voilà le point que la plupart des équipes finance ratent : on ne peut pas attribuer un coût qu’on ne mesure pas, et on ne peut pas mesurer une consommation que le produit n’instrumente pas. L’unit economics par client n’est pas un problème de tableur — c’est un problème de données, donc d’architecture.

Si votre facture cloud arrive en un seul montant global, sans étiquette, vous êtes aveugle. Pour savoir combien vous coûte le client X, il faut que votre infrastructure sache attribuer la consommation à X. Concrètement : tagger vos ressources par tenant, propager un identifiant client dans vos logs et vos métriques, instrumenter les appels sortants vers vos fournisseurs payants (le nombre de tokens envoyés au modèle d’IA, le volume d’emails, les Go transférés). Sans cette plomberie, l’attribution devient une reconstruction manuelle au doigt mouillé, invérifiable et impossible à maintenir.

C’est là que se joue le lien stratégie-tech. Une équipe qui a conçu son produit en multi-tenant pur, sans jamais penser à l’observabilité des coûts, découvre au moment de la série A qu’elle est incapable de répondre à une question basique d’investisseur : « quelle est votre marge sur votre cohorte de clients enterprise ? » L’information existe physiquement dans les serveurs, mais elle n’a jamais été rendue lisible. La refaire coûte alors des semaines d’ingénierie, en pleine due diligence, au pire moment.

Ne construisez pas une usine à gaz : commencez par une approximation grossière

La bonne nouvelle, c’est qu’une startup n’a pas besoin d’un système de cost allocation d’entreprise. La précision comptable au centime est un piège — elle coûte cher à construire et n’améliore aucune décision. Ce qu’il vous faut, c’est un ordre de grandeur assez fiable pour classer vos clients en trois catégories : franchement rentables, à la marge, et destructeurs de valeur.

Commencez par identifier vos deux ou trois postes de coût variables dominants. Dans la plupart des SaaS, c’est le compute et le stockage cloud, éventuellement les appels à une API tierce facturée à l’usage, et le temps humain de support. Vous n’avez pas besoin de tout attribuer : les coûts fixes (vos salaires, vos outils) se répartissent grossièrement, ce sont les coûts variables qui font vraiment diverger la marge d’un client à l’autre.

Ensuite, trouvez un proxy de consommation par client, même imparfait. Le nombre de requêtes API, le volume de données stockées, le nombre d’utilisateurs actifs, le nombre de tickets support ouverts. Croisez ce proxy avec votre facture globale pour répartir le coût au prorata. Ce n’est pas exact, mais c’est mille fois plus utile qu’un chiffre unique. Vous verrez immédiatement apparaître les valeurs aberrantes — les clients dont la consommation explose par rapport à ce qu’ils paient.

Pour instrumenter proprement sans tout réécrire : ajoutez un identifiant tenant dans vos logs applicatifs (vous en avez sans doute déjà), taggez vos ressources cloud par environnement et par gros client, et récupérez une fois par mois les métriques d’usage dans un simple tableau. Un job mensuel qui agrège tout ça dans une table suffit pour démarrer. On automatisera plus tard, quand la question sera devenue quotidienne plutôt que trimestrielle.

Ce que vous ferez de cette information change tout

Mesurer la marge par client n’a d’intérêt que si vous en tirez des décisions. Et elles arrivent vite, une fois le voile levé.

La première : le repricing ciblé. Vous découvrez qu’une partie de vos clients consomme bien au-delà de ce que votre forfait prévoyait. Plutôt que d’augmenter tout le monde, vous pouvez faire évoluer votre pricing vers un modèle qui suit la valeur consommée — un palier d’usage, un add-on volume — pour les comptes concernés. C’est exactement le genre de décision où pricing et architecture se rejoignent : facturer à l’usage suppose de savoir mesurer l’usage, ce que l’instrumentation que vous venez de poser rend précisément possible.

La deuxième : arrêter de célébrer les mauvais clients. Ce gros logo qui vous flatte mais détruit votre marge doit être renégocié à son renouvellement, ou remonté d’un cran tarifaire. Ce segment que votre équipe commerciale adore signer parce qu’il « close vite » est peut-être celui qui vous appauvrit le plus vite. Sans les chiffres, vous n’avez aucune légitimité pour trancher ces débats. Avec eux, la conversation devient factuelle.

La troisième, souvent la plus rentable : optimiser le produit là où ça compte. Si 15 % de vos clients génèrent 70 % de votre coût compute à cause d’une fonctionnalité mal optimisée, vous savez enfin où investir votre temps d’ingénierie. L’optimisation technique cesse d’être un caprice d’ingénieur pour devenir un levier de marge chiffré.

Une nuance selon votre stade. En pre-seed, honnêtement, ne perdez pas de temps là-dessus : vous cherchez le product-market fit, pas la marge, et vos volumes sont trop faibles pour que la question ait un sens. En seed, posez l’instrumentation minimale — les tags, l’identifiant tenant dans les logs — parce que c’est mille fois plus facile à ajouter maintenant qu’après. C’est à l’approche de la série A, quand vous commencez à parler d’efficience du capital et que les investisseurs sondent vos unit economics, que le sujet devient critique. Une startup qui sait présenter sa marge par segment client envoie un signal de maturité opérationnelle qui vaut de l’argent en valorisation.

Le vrai coût de l’aveuglement

Le danger n’est pas d’avoir des clients non rentables — toute startup en a. Le danger, c’est de ne pas savoir lesquels, et donc de prendre toutes vos décisions de croissance à l’aveugle : recruter des commerciaux pour vendre à un segment qui détruit de la valeur, augmenter votre budget d’acquisition sur une cohorte qui ne se rembourse jamais, scaler une infrastructure dont vous ne maîtrisez pas l’économie.

Piloter à la moyenne, c’est accepter que quelques bons clients paient pour cacher les mauvais. Ça tient tant que la croissance masque tout. Ça craque le jour où la croissance ralentit et où il faut expliquer, chiffres à l’appui, où va vraiment l’argent.

Alors la question à se poser n’est pas « quelle est ma marge brute ? » mais « quelle est la forme de la distribution derrière cette moyenne ? ». Si vous ne pouvez pas répondre aujourd’hui, ce n’est pas un problème de finance à régler dans un tableur. C’est une brique d’observabilité à poser dans votre produit — et le meilleur moment pour la poser, c’est avant d’en avoir désespérément besoin.