Qu'est-ce que le MRR ? Définition et Pièges
Publié le 7 mars 2026 · Jules, Founder of NoNoiseMetrics · 13min de lecture
Mis à jour le 16 avril 2026
Un fondateur ouvre son dashboard, voit 14 200 € de revenu récurrent mensuel et se sent rassuré. Le chiffre inclut deux grands contrats annuels signés le mois dernier, des frais d’onboarding de trois nouveaux comptes, et la base d’abonnements récurrents. C’est le chiffre qu’il publie dans son update hebdomadaire et qu’il commente dans la réunion mensuelle avec son cofondateur.
Il est faux. Pas parce que quelqu’un ment, mais parce que le revenu récurrent mensuel n’a pas été défini avant d’être calculé. Les paiements annuels ont été comptabilisés dans le mois de réception plutôt que normalisés mensuellement. Les frais d’onboarding sont entrés parce qu’ils passaient par Stripe. Le résultat surestime la base récurrente de 15 à 40 % selon le mois.
C’est ainsi que le MRR devient une fausse croissance, pas par fraude, mais par des définitions floues appliquées assez régulièrement pour que tout le monde finisse par croire le chiffre gonflé. Cette section couvre les pièges les plus fréquents que l’on retrouve dans presque tous les comptes Stripe sous 100k de chiffre d’affaires, comment les détecter, et comment construire un revenu récurrent mensuel propre que vous pouvez défendre devant un investisseur sans hésiter trente secondes.
Qu’est-ce que le MRR ?
MRR signifie Monthly Recurring Revenue (Revenu Récurrent Mensuel). Il mesure le revenu d’abonnement récurrent qu’une entreprise SaaS génère dans un mois donné à partir de ses abonnements actifs.
Le mot clé est récurrent. Le revenu récurrent mensuel n’est pas le chiffre d’affaires total. Ce n’est pas l’argent encaissé. Ce n’est pas les réservations. C’est spécifiquement la part récurrente du revenu, le montant attendu de se répéter le mois suivant auprès des clients actifs, normalisé sur une base mensuelle.
Le revenu récurrent mensuel est la métrique qui rend les SaaS comparables entre cohortes, périodes et modèles de facturation. L’ARR (Annual Recurring Revenue) n’est que le MRR × 12, un résumé annualisé utile, mais le revenu récurrent mensuel est la couche opérationnelle. Pour le guide complet ARR et MRR couvrant les deux métriques avec le détail du waterfall, voir le guide minimaliste des revenus récurrents.
La formule la plus simple :
MRR = somme des revenus d'abonnements récurrents actifs du mois
Pour les abonnements mensuels, la contribution est égale au prix de l’abonnement. Pour les abonnements annuels, c’est le montant annuel divisé par 12. Les frais ponctuels sont exclus.
Formule MRR : le calcul et ce qu’il faut inclure
Ce qui doit figurer dans le MRR
Les abonnements mensuels contribuent pour leur prix mensuel complet. Les abonnements annuels contribuent pour leur prix divisé par 12. Les add-ons récurrents facturés chaque mois contribuent pour leur montant mensuel.
Exemple, abonnement mensuel : Client paie 99 €/mois → contribution MRR = 99 €
Exemple, abonnement annuel : Client paie 1 188 €/an → contribution MRR = 1 188 / 12 = 99 €
Ce qui ne doit pas figurer dans le MRR
Frais de setup, frais d’onboarding, frais d’implémentation, consulting, projets de migration, remboursements, et tout revenu qui ne se répète pas automatiquement au prochain cycle de facturation.
Les pièges qui faussent la croissance MRR
Piège 1 : Compter les paiements annuels comme du MRR d’un seul mois. La distorsion la plus courante. Un client prépaye 2 400 € pour un an. Mauvais traitement : le revenu récurrent mensuel bondit de 2 400 € dans le mois du paiement. Bon traitement : le revenu récurrent mensuel augmente de 200 €/mois (2 400 / 12) à partir du mois de début. La version gonflée donne l’illusion d’un mois exceptionnel suivi de mois faibles, deux distorsions qui faussent toute métrique downstream.
Piège 2 : Mélanger les services ponctuels dans la base récurrente. L’implémentation, le développement sur mesure, le consulting et la formation sont des revenus, mais pas des revenus récurrents. Les inclure gonfle le revenu récurrent mensuel sans améliorer le moteur d’abonnements. Si les services s’arrêtent, la métrique chute, ce qui rend le MRR volatil alors que la base d’abonnements sous-jacente est stable.
Piège 3 : Pas de règle pour les abonnements en pause ou à risque. Les abonnements en période de grâce (facturation échouée mais compte non encore annulé) doivent avoir un traitement clair. Certains fondateurs les conservent dans le revenu récurrent mensuel jusqu’à l’annulation ; d’autres les excluent quand le paiement est en retard depuis plus d’un nombre défini de jours. N’importe quelle règle fonctionne, ne pas en avoir crée de l’incohérence entre les mois.
Piège 4 : Traitement flou de la facturation à l’usage. Si le produit a des composantes variables, la contribution de cet usage au revenu récurrent mensuel doit avoir une définition cohérente : est-ce le minimum garanti ? L’usage réel du mois précédent ? Une moyenne mobile ? Les fondateurs qui décident différemment chaque mois produisent un signal bruité, inutilisable pour l’analyse de tendance.
Piège 5 : Ne suivre que le MRR total sans le bridge. Un seul chiffre de revenu récurrent mensuel final cache tout le mouvement en dessous. Un business peut terminer un mois à 11 400 € par des chemins très différents : 1 500 € de nouveau MRR et 100 € de churn, ou 500 € de nouveau MRR et 200 € de churn masqués par de l’expansion. Sans le bridge ces scénarios ont l’air identiques, et le fondateur n’a aucun signal sur la partie du business qui demande de l’attention.
Piège 6 : Sommer les abonnements multi-devises sans conversion FX cohérente. Si une partie des clients paie en EUR, une autre en USD, une autre en GBP, additionner les montants bruts est dénué de sens. Définir une devise de reporting et appliquer un taux FX de fin de mois d’une source officielle (BCE pour reporting EUR, Federal Reserve pour USD). Le taux change chaque mois, la méthode reste fixe — sans cela, le revenu récurrent mensuel peut osciller de 10 à 20 % selon le taux du jour.
Votre MRR est-il vraiment propre ? Vérifiez vos données Stripe →
Le MRR bridge : le calcul que la plupart des fondateurs ignorent
Le MRR bridge décompose le mouvement entre deux périodes :
MRR final = MRR initial + Nouveau MRR + MRR d'expansion − MRR de contraction − MRR perdu (churn)
Cela rend visible : si la croissance vient de nouveaux clients ou de l’expansion des existants, si le churn s’accélère ou se stabilise, et quelle partie du moteur de revenu nécessite de l’attention. Le cadre de métriques SaaS de David Skok décrit le MRR bridge comme la vue opérationnelle fondamentale des businesses par abonnement, il transforme un chiffre unique en un ensemble de leviers que le fondateur peut réellement actionner.
Exemple concret : MRR propre en pratique
Un produit SaaS démarre le mois avec :
- 40 clients à 49 €/mois (plan Growth)
- 10 clients à 99 €/mois (plan Scale)
- 8 clients annuels à 588 €/an (plan Starter annuel)
- 3 nouveaux clients onboardés ce mois, dont 300 € de frais d’onboarding
Calcul du MRR propre :
Plans mensuels :
(40 × 49) + (10 × 99) = 1 960 + 990 = 2 950
Plans annuels normalisés :
8 × (588 / 12) = 8 × 49 = 392
MRR de base :
MRR = 2 950 + 392 = 3 342
Les 300 € de frais d’onboarding sont exclus.
MRR vs ARR : quand utiliser l’un ou l’autre
MRR et ARR mesurent le même business, l’un mensuellement, l’autre annualisé.
Utilisez le MRR pour : les revues hebdomadaires et mensuelles, le suivi du taux de croissance, l’analyse du churn et de l’expansion, la vue opérationnelle.
Utilisez l’ARR pour : communiquer l’échelle du business, les conversations avec les investisseurs, le suivi de la trajectoire de haut niveau.
La conversion est simple :
ARR = MRR propre × 12
Pour la formule ARR complète et ce qui la rend propre, le guide sur la formule ARR détaille chaque étape. Les 16 métriques SaaS d’a16z positionnent à la fois le MRR et l’ARR comme essentiels, l’ARR pour l’échelle de l’entreprise et le MRR pour la santé opérationnelle.
Taux de croissance MRR
Une fois le MRR proprement défini, suivre le taux de croissance donne la tendance :
Taux de croissance MRR = (MRR final − MRR initial) / MRR initial × 100
Pour référence : des taux de croissance MRR mensuels supérieurs à 10-15 % sont exceptionnels. Des taux de 3-7 % sont solides et durables. Des taux inférieurs à 2 % pendant deux mois consécutifs signalent généralement un problème à investiguer.
Comment suivre le MRR automatiquement
Connectez une source de facturation de confiance. Stripe pour la plupart des SaaS en phase initiale, et définissez le revenu récurrent une fois avant de construire tout suivi. Si vous voulez un framework plus large sur comment les revenue operations s’articulent en tant que fondateur solo, ce guide couvre le processus complet de la source de facturation à la boucle de décision.
NoNoiseMetrics lit directement les événements d’abonnement Stripe pour produire un revenu récurrent mensuel propre, le MRR bridge, la décomposition par plan, et la distinction entre churn volontaire et involontaire, le tout à partir d’une seule connexion Stripe.
Pour le dashboard qui devrait accueillir ces métriques, le guide du dashboard à 8 métriques couvre la mise en page complète sur un seul écran. Le rapport State of the Cloud de Bessemer offre des benchmarks de taux de croissance et de NRR par tranche d’ARR, une calibration utile une fois le suivi propre en place.
Routine d’audit MRR hebdomadaire
Même avec une définition propre, une routine hebdomadaire maintient la qualité de la donnée. Chaque lundi matin, dix minutes : ouvrir le dashboard de subscriptions Stripe, compter combien de subscriptions sont en past_due depuis plus de 7 jours et comparer avec la semaine précédente. Examiner chaque nouvelle subscription de la semaine pour confirmer que price.recurring n’est pas null. Vérifier qu’aucun coupon nouveau n’a été appliqué sans être reflété dans les calculs. Noter en une ligne le delta de la base récurrente avec une seule cause attribuable. Cette routine d’hygiène de données ne remplace pas le snapshot mensuel, mais elle intercepte les pièges avant qu’ils ne se propagent dans un rapport envoyé à des investisseurs ou cofondateurs. Trois oublis par semaine découverts trop tard deviennent un rapport faux en fin de mois, et un rapport faux entre les mains d’un investisseur coûte beaucoup plus cher que dix minutes un lundi matin. Une checklist courte partagée avec le cofondateur technique réduit le risque qu’un changement de logique passe inaperçu jusqu’au snapshot suivant.
Pourquoi la discipline de définition compte plus que l’outil
Les fondateurs qui changent d’outil tout en essayant simultanément d’affiner leurs définitions s’attirent les plus gros ennuis. D’abord fixer la définition du revenu récurrent mensuel, ensuite choisir l’outil. Si la base récurrente est calculée exactement de la même manière deux mois consécutifs, le choix entre le dashboard Stripe, une requête SQL maison ou un outil tiers devient secondaire. Sans cette discipline, chaque outil produit un chiffre différent, et aucun d’eux n’est vérifiable contre un autre. La pire variante est le mélange : un fondateur qui ouvre un outil différent chaque semaine et se demande pourquoi les chiffres ne concordent jamais, sans réaliser que six définitions différentes vivent dans six sources différentes.
Cette dérive silencieuse est plus pernicieuse qu’un piège évident, parce que personne ne peut voir au premier coup d’œil quelle source est correcte. La parade la plus simple : une fois par trimestre, ajouter une ligne de comparaison entre deux sources dans l’update hebdomadaire, en indiquant clairement quelle définition chaque source utilise. Dès que l’écart dépasse 2 %, il y a une dérive à investiguer avant qu’elle ne s’infiltre dans des supports investisseurs ou des forecasts.
En pratique, les fondateurs qui publient un revenu récurrent mensuel fiable mois après mois ne sont presque jamais ceux qui ont l’outil le plus sophistiqué. Ce sont ceux qui ont écrit une définition une fois, l’ont défendue six mois durant, et ont documenté chaque exception. L’outil vient après. Un fondateur qui tient la routine d’audit hebdomadaire pendant trois mois connaît son MRR mieux que n’importe quel consultant qui débarque avec un dashboard payant. L’ordre est toujours le même : la discipline d’abord, l’automatisation ensuite. Inverser cet ordre revient à acheter un joli graphique tout en gardant exactement les mêmes problèmes de définition.
La même logique vaut pour les revues mensuelles. Le snapshot du jour 1 du mois — toujours après 0:00 UTC, jamais en milieu de mois pendant que les events de billing tournent — produit un chiffre comparable d’un mois à l’autre. Sur ce snapshot, calculer le bridge contre le mois précédent : Nouveau MRR + Expansion − Contraction − Churn − Réactivation doit expliquer exactement la différence entre le revenu récurrent mensuel du mois passé et celui du mois en cours. Si la somme ne tombe pas juste, au moins un piège est actif et il faut le retrouver avant d’envoyer quoi que ce soit. Documenter en parallèle ce que la définition couvre exactement — quels statuts d’abonnement sont inclus, quelle méthode FX, quel seuil past-due — dans une note courte qui change au plus une fois par an. Cette discipline rend les comparaisons trimestrielles et annuelles fiables, et c’est la condition de base pour qu’un forecast SaaS construit sur cette donnée ait la moindre crédibilité.
FAQ
Qu’est-ce que le MRR en SaaS ?
Le MRR (Monthly Recurring Revenue) représente le revenu d’abonnement récurrent qu’un SaaS génère dans un mois donné, normalisé pour que les plans annuels contribuent pour leur équivalent mensuel (montant annuel divisé par 12). Les frais ponctuels sont exclus.
Comment calculer le MRR ?
La formule est : MRR = somme des revenus d’abonnements récurrents actifs du mois. Pour les plans mensuels, c’est le prix mensuel. Pour les plans annuels, c’est le prix annuel divisé par 12. Les frais ponctuels et de setup sont exclus.
Qu’est-ce que le MRR bridge ?
Le MRR bridge décompose le mouvement MRR en ses composantes : nouveau MRR (de nouveaux clients), MRR d’expansion (des upgrades), MRR de contraction (des downgrades), et MRR perdu (des annulations). Il transforme un chiffre final unique en une histoire lisible sur ce qui a piloté le changement.
Pourquoi le MRR est-il plus utile que le chiffre d’affaires total pour un SaaS ?
Le CA total mélange composantes récurrentes et non-récurrentes d’une façon qui rend la comparaison mois par mois peu fiable. Le MRR isole le moteur récurrent et rend la trajectoire du business lisible.
Qu’est-ce que le MRR d’expansion ?
Le MRR d’expansion est le revenu récurrent additionnel provenant des clients existants, via des upgrades de plan, des sièges supplémentaires ou des add-ons récurrents. C’est une composante du MRR bridge et l’un des signaux les plus importants en SaaS : un MRR d’expansion élevé signifie que les clients existants trouvent plus de valeur au fil du temps, ce qui pousse la NRR au-dessus de 100 % et réduit la dépendance à l’acquisition de nouveaux clients. Sur les SaaS matures, le MRR d’expansion peut à lui seul porter la croissance.
Arrêtez de calculer le MRR dans un tableur. MRR propre, ARR et le waterfall complet, gratuit jusqu’à 10 000 € MRR →
Free Tool
Try the MRR Dashboard Template →
Interactive calculator, no signup required.