Pourquoi nous ne vendons pas de retainers

Les retainers ressemblent à de la prévisibilité : montant fixe, périmètre fixe, jour du mois fixe. En pratique, ils couvrent un risque dont aucune des deux parties ne parle ouvertement - personne ne sait exactement ce qui vaudra la peine d'être fait le mois prochain.

Ce que les retainers produisent en pratique

Constat sur deux décennies de projets logiciels :

Les heures sont « consommées » jusqu'au plafond, même quand ne rien faire aurait été la meilleure décision.
Les discussions de priorisation disparaissent, puisque la facture part de toute façon.
Les nouveaux sujets hors retainer sonnent comme de la vente additionnelle - alors que ce sont souvent les plus importants.
L'arrêt devient une décision politique, pas opérationnelle.

Notre modèle : horaire selon le besoin

Trois règles simples :

Seul le temps facturé est du temps livré. Pas de base fixe, pas d'« heures qui expirent ».
Priorisation hebdomadaire ou mensuelle. Ce qui a le plus de levier passe en premier. Ce qui n'apporte plus rien tombe.
Documentation transparente. Chaque heure se rattache à un commit, une décision, une passation claire.

C'est plus exigeant qu'un retainer. Cela force les deux parties à planifier le mois. En échange, la confiance reste intacte - personne ne paie jamais d'heures pour rien.

Pour qui ça convient - et pour qui non

Bon ajustement :

PME avec DSI interne qui achètent de l'expertise ponctuellement
Projets à effort variable (sprints, releases, migrations)
Clients qui veulent contrôler la valeur réellement produite

Moins adapté :

Achats devant garder un montant annuel fixe au budget
Projets où la priorisation mensuelle est organisationnellement impossible

Ce que ça change pour le premier échange

Au premier échange, nous donnons une fourchette d'effort réaliste - en jours, pas en forfaits. Les deux parties peuvent planifier sans être enfermées dans un modèle rigide. Si le projet évolue, on ajuste la priorisation, pas la facture.

Ce n'est pas une prise de position contre les retainers en soi. C'est une prise de position pour la transparence et la priorisation, qui marchent mieux dans nos projets qu'un forfait.

Ce que les retainers produisent en pratique

Constat sur deux décennies de projets logiciels :

Les heures sont « consommées » jusqu'au plafond, même quand ne rien faire aurait été la meilleure décision.

Les discussions de priorisation disparaissent, puisque la facture part de toute façon.

Les nouveaux sujets hors retainer sonnent comme de la vente additionnelle - alors que ce sont souvent les plus importants.

L'arrêt devient une décision politique, pas opérationnelle.

Notre modèle : horaire selon le besoin

Trois règles simples :

Seul le temps facturé est du temps livré. Pas de base fixe, pas d'« heures qui expirent ».

Priorisation hebdomadaire ou mensuelle. Ce qui a le plus de levier passe en premier. Ce qui n'apporte plus rien tombe.

Documentation transparente. Chaque heure se rattache à un commit, une décision, une passation claire.

C'est plus exigeant qu'un retainer. Cela force les deux parties à planifier le mois. En échange, la confiance reste intacte - personne ne paie jamais d'heures pour rien.

Pour qui ça convient - et pour qui non

Bon ajustement :

PME avec DSI interne qui achètent de l'expertise ponctuellement

Projets à effort variable (sprints, releases, migrations)

Clients qui veulent contrôler la valeur réellement produite

Moins adapté :

Achats devant garder un montant annuel fixe au budget

Projets où la priorisation mensuelle est organisationnellement impossible

Ce que ça change pour le premier échange

Ce n'est pas une prise de position contre les retainers en soi. C'est une prise de position pour la transparence et la priorisation, qui marchent mieux dans nos projets qu'un forfait.