Chapitre 7.2 — Retainers & revenu récurrent

⏱️ TL;DR — La première porte de sortie du plafond, et la plus rapide : arrête de vendre uniquement des projets qui commencent et finissent, vends du récurrent. Un retainer, c’est un forfait mensuel — maintenance, disponibilité, TMA, ou « X jours réservés par mois » — que le client paie qu’il l’utilise à fond ou non. Le récurrent bat le projet ponctuel sur trois axes : prévisibilité, moins de prospection, relation longue. Et le meilleur moment pour le proposer, ce n’est pas au démarrage : c’est à la fin d’un projet réussi (Partie 6), quand la confiance est au sommet.

🎯 Objectifs

Comprendre ce qu’est un retainer et ses formes concrètes.
Savoir pourquoi le récurrent est structurellement supérieur au projet ponctuel.
Proposer et vendre un retainer au bon moment, avec les bons mots.
Fixer le prix d’un retainer sans te faire piéger par la disponibilité.

C’est quoi, un retainer

Un retainer est un engagement mensuel récurrent : le client te paie chaque mois une somme fixe en échange d’un périmètre défini. Il ne rachète pas un projet à chaque fois — il s’abonne à ton service. Les formes les plus courantes chez un dev :

Maintenance & correctifs — tu gardes l’app en vie : bugs, mises à jour de dépendances, sécurité, petites urgences. Le client dort tranquille.
TMA (Tierce Maintenance Applicative) — tu es le mainteneur attitré d’une application : correctif et petites évolutions au fil de l’eau.
Évolutions continues — un flux régulier de petites features priorisées ensemble chaque mois, sans re-signer un devis à chaque fois.
« X jours réservés / mois » — tu bloques un volume (par ex. 4 jours/mois) que le client mobilise comme il veut. Il paie la réservation, pas seulement l’usage.
Disponibilité / astreinte — tu garantis un délai de réponse. Le client paie surtout ta disponibilité, ce qui est précisément ce qui a de la valeur pour lui.

Le point commun : le revenu se renouvelle sans que tu aies à re-vendre. C’est là toute la différence.

Pourquoi le récurrent bat le projet ponctuel

	Projet ponctuel	Retainer / récurrent
Revenu	en dents de scie, à re-signer	prévisible, base stable chaque mois
Prospection	permanente (fin de projet = trou)	fortement réduite (le client reste)
Relation client	transactionnelle, courte	longue, tu connais son contexte
Coût de vente	élevé à chaque mission	quasi nul une fois le retainer signé
Effet sur ton stress	anxiété de l’inter-contrat	socle qui couvre tes charges fixes

Le récurrent ne casse pas complètement le lien temps/revenu (tu vends encore ta présence), mais il stabilise le linéaire : au lieu de repartir de zéro à chaque fin de projet, tu as une base qui tombe tous les mois. Trois clients en retainer, et une bonne partie de tes charges fixes est couverte avant même de prospecter. Psychologiquement, ça change tout : tu prospectes en position de force, pas de survie.

C’est aussi la forme de récurrent la plus honnête pour un freelance : tu n’as pas promis un « revenu passif » magique. Tu travailles toujours. Mais tu as supprimé la partie la plus coûteuse et la plus angoissante du métier — retrouver un client tous les deux mois.

💡 Réflexe — Après chaque livraison réussie, pose-toi une seule question : « Qu’est-ce qui va casser, évoluer ou avoir besoin d’attention le mois prochain ? » La réponse est ton offre de retainer. Un logiciel livré n’est jamais « fini » — il vit, se dégrade, doit évoluer. Cette vie continue, c’est exactement ce que ton client est prêt à payer pour ne pas gérer lui-même.

Comment proposer un retainer (au bon moment)

Le meilleur moment n’est pas le devis initial. C’est juste après une livraison réussie (Partie 6), au pic de confiance : tu viens de prouver que tu livres, le client est content, et il réalise qu’il ne veut surtout pas gérer la suite seul.

La bonne façon de l’amener, c’est de vendre la tranquillité, pas les heures. Un exemple d’accroche, à adapter :


Maintenant que [le projet] est en prod, la vraie question, c'est
la suite : les mises à jour de sécurité, les petits bugs qui
sortent, les évolutions que tu vas vouloir.

Deux options :
 - soit on repart sur un devis à chaque fois (lent, et je ne suis
   pas toujours dispo dans la foulée) ;
 - soit on met en place un forfait mensuel : je garde l'app en
   bonne santé et je te réserve [X jours] par mois pour les
   évolutions. Tu as la priorité et un interlocuteur qui connaît
   déjà tout ton contexte.

La plupart de mes clients préfèrent la deuxième. On en parle ?

Deux principes : tu présumes le besoin (il existe : tout logiciel vit) et tu vends la priorité + la connaissance du contexte, deux choses qu’un nouveau prestataire n’aura jamais. Tu peux aussi glisser le retainer dès la propale initiale (« … puis un forfait maintenance à partir de la mise en prod »), pour que l’idée soit déjà là au moment de la livraison.

⚠️ Piège — Vendre un retainer comme « des heures dispo au cas où » sans périmètre écrit. Sans cadre, le client considère que « X jours réservés » veut dire « disponible H24 pour tout », et le forfait déborde. Écris ce qui est inclus (maintenance, X jours d’évolutions, délai de réponse) et ce qui déclenche un devis à part (nouveau gros chantier). Cadrer le scope (Partie 5.3) vaut autant pour un retainer que pour un projet.

Fixer le prix d’un retainer

Trois repères, pas une formule magique :

Pars de la valeur, pas des heures. Ce que tu factures, c’est la tranquillité et la priorité, pas seulement le temps passé. Un mois calme où tu n’interviens presque pas ne veut pas dire que le client n’a rien reçu : il a reçu de la disponibilité garantie, et ça a un prix.
Facture la réservation. Si tu bloques 4 jours/mois pour ce client, ces jours ne sont plus vendables ailleurs, même s’il ne les consomme pas. Le forfait doit couvrir cette capacité réservée, pas l’usage réel.
Un léger surcoût sur le TJM implicite est normal, pas un rabais. L’erreur classique est de « brader » parce que c’est récurrent. Non : le client paie pour ta priorité et ta connaissance de son système — c’est plus cher à obtenir ailleurs, pas moins. Le récurrent est un premium de tranquillité, côté client comme côté toi. Sur une base de 500–600 €/j, un forfait de quelques jours réservés se chiffre en conséquence, disponibilité comprise.

Prévois une clause de révision (le forfait se réévalue tous les 6–12 mois) et un engagement minimal (par ex. 3 mois) pour que ça vaille le coup de mettre en place. Un retainer sans durée minimale n’est qu’un projet déguisé.

🚀 Sur ton plan 12 mois — C’est le premier vrai levier que notre dev active. Sur les projets qu’il a livrés au T2, il propose systématiquement un forfait maintenance à la mise en prod. Objectif du T3 : deux à trois clients en retainer, de quoi couvrir une bonne part de ses charges fixes chaque mois avant de prospecter. Ce socle stable est ce qui va lui donner la sérénité — et le temps mental — pour commencer à construire un produit (Partie 8) sans la pression de l’inter-contrat.

✏️ Exercices

Exercice 1 — Convertis un client livré. Prends un vrai client à qui tu as livré un projet. Écris, en 4–5 lignes, l’offre de retainer que tu lui proposerais : ce qui est inclus, le volume réservé, le délai de réponse, le prix mensuel.

✅ Solution

Une bonne offre est spécifique et bornée. Mauvais : « je reste dispo si besoin, on verra ». Bon : « maintenance (sécurité, mises à jour, bugs) + 3 jours d’évolutions par mois + réponse sous 48 h ouvrées, hors gros chantiers qui font l’objet d’un devis à part, engagement 3 mois révisable ». Le client sait exactement ce qu’il achète, toi exactement ce que tu t’engages à donner. Si tu n’arrives pas à écrire le périmètre en 5 lignes, c’est qu’il n’est pas assez clair — et un périmètre flou finit toujours par déborder à tes dépens.

Exercice 2 — Le pitch de fin de projet. Reformule l’accroche de retainer avec tes mots, pour un de tes clients réels. Une contrainte : vends la tranquillité et la priorité, jamais « des heures au cas où ».

✅ Solution

La clé est le glissement de vocabulaire : de « veux-tu m’acheter des heures ? » (le client compare au coût) vers « veux-tu que je garde ça en bonne santé et que tu aies la priorité ? » (le client compare au risque de tout gérer seul). Nomme les vraies craintes du client — un bug en prod un vendredi soir, une faille de sécurité, une évolution urgente sans personne de dispo. Le retainer est l’assurance contre ces scénarios. On ne vend pas du temps, on vend l’absence de problème.

🧠 Quiz de révision

1. Qu’est-ce qu’un retainer, en une phrase ?

Un forfait mensuel récurrent par lequel le client s’abonne à ton service (maintenance, TMA, X jours réservés, disponibilité) au lieu de racheter un projet à chaque fois. Le revenu se renouvelle sans avoir à re-vendre.

2. Sur quels axes le récurrent bat-il le projet ponctuel ?

Sur la prévisibilité (base stable chaque mois), la prospection (fortement réduite, le client reste) et la relation (longue, tu connais son contexte). Bonus : ton coût de vente tombe à quasi zéro une fois le retainer signé, et tu prospectes ensuite en position de force.

3. Quel est le meilleur moment pour proposer un retainer ?

Juste après une livraison réussie, au pic de confiance. Tu viens de prouver que tu livres, le client est satisfait et réalise qu’il ne veut pas gérer la suite seul. On peut aussi planter l’idée dès la propale initiale pour qu’elle soit déjà là à la mise en prod.

4. Pourquoi ne faut-il pas brader un retainer ?

Parce que le client paie ta priorité, ta disponibilité réservée et ta connaissance de son système — trois choses plus chères à obtenir ailleurs, pas moins. Le récurrent est un premium de tranquillité, pas un rabais de fidélité. Facturer la capacité réservée, même les mois calmes, est légitime.

5. Quel est le principal piège d’un retainer, et comment l’éviter ?

Le débordement : sans périmètre écrit, « X jours réservés » devient « dispo H24 pour tout ». On l’évite en écrivant ce qui est inclus, le volume, le délai de réponse, ce qui déclenche un devis à part, et en posant un engagement minimal avec clause de révision.

Chapitre suivant : Productiser & déléguer — standardiser ce que tu répètes, puis le faire faire.