Forfait ou régie : uniquement une question de facturation ?
Forfait, régie, estimation en jours, périmètre évolutif… Dans la pratique, beaucoup de projets tech fonctionnent avec des modèles hybrides où la question du risque et des responsabilités dépasse largement celle de la facturation.
Quand on commence à travailler en freelance, une question revient souvent :
"Tu travailles au forfait ou en régie (temps passé) ?"
Et très souvent, la discussion tourne autour :
- Du TJM
- De la rentabilité
- Ou du mode de facturation
Avec le temps, je me rends compte que le sujet est en réalité beaucoup plus nuancé.
Sur le papier, la distinction paraît assez claire.
D’un côté :
- La régie (temps passé)
- Le temps passé
- Une logique plus souple et évolutive
De l’autre :
- Le forfait
- Un périmètre défini
- Des livrables attendus
- Et un engagement plus cadré
Mais dans les projets du quotidien, les frontières sont rarement aussi nettes.
Dans mon cas, par exemple, je fonctionne souvent avec :
- Un périmètre défini
- Une liste de fonctionnalités
- Une estimation en jours
- Un TJM associé
- Et les points qui peuvent devenir critiques
Le client a donc une visibilité sur le contenu, le temps estimé et ainsi le coût projeté.
Mais malgré ce cadrage, il reste presque toujours :
- Des imprévus
- Des ajustements
- Et des zones floues
Et c’est probablement là que la réalité des projets devient plus complexe qu’une simple opposition entre forfait et régie.
Au final, je remarque lors de mes sessions d'accompagnement, que beaucoup de prestations fonctionnent finalement avec des modèles hybrides.
On cherche à cadrer le besoin au maximum, mais on garde aussi une certaine souplesse autour des évolutions, des arbitrages ou des contraintes découvertes en avançant.
Au-delà du mode de facturation, la vraie question devient alors souvent :
qui porte le risque de l’incertitude ?
Car plus un projet est flou ou mouvant, plus cette question devient importante.
J’ai d’ailleurs eu récemment un cas assez représentatif de cette difficulté.
Un prospect me contacte pour réaliser la refonte d’un backoffice existant.
Il souhaitait un devis avec un engagement fort sur le résultat, notamment parce qu’il n’était pas satisfait de la manière dont le précédent prestataire avait réalisé l’application.
Le problème, c’est que je n’avais accès qu’au code source existant.
- Aucun cahier des charges initial
- Aucun historique clair des besoins
- Aucune certitude sur :
- ce qui était censé fonctionner
- ce qui fonctionnait réellement
- ou même sur les comportements attendus
Et dans ce contexte, il m’était difficile de m’engager directement sur un résultat global.
Car reprendre une application existante ne consiste pas uniquement à relire du code.
Il faut aussi comprendre :
- Les usages
- Les règles métier
- Les attentes implicites
- Et parfois même redécouvrir le besoin initial
La solution la plus raisonnable a finalement été de proposer une première phase de cadrage :
- Reprise du besoin
- Clarification des usages
- Redéfinition des cas d’utilisation
- Analyse de l’existant
avant même d’entrer dans une phase de développement plus engageante.
Et avec le recul, je pense que ce type de situation illustre bien le fait qu’un devis n’est pas uniquement une question de prix ou de jours estimés.
C’est aussi une question de visibilité sur le projet et de capacité à en mesurer le risque réel.
Quand je fais principalement du développement, j’essaie aujourd’hui d’être particulièrement attentif au cadrage initial et à la manière dont les évolutions seront gérées pendant le projet.
À l’inverse, pour des missions d’AMOA, d’accompagnement ou de gestion de projet, je fonctionne plus facilement avec des prestations forfaitisées, même s’il existe également une part d’incertitude.
Dans ces contextes, les attentes et les livrables me semblent souvent plus simples à définir dès le départ.
Avec le temps, j’ai compris qu’un projet ne se résume pas uniquement à :
- Un tarif
- Un nombre de jours
- Ou une méthode de facturation
Il y a aussi :
- La relation client
- Le niveau de cadrage
- Les responsabilités
- La gestion des changements
- Les validations
- Et les attentes implicites autour du projet
Je pense donc que beaucoup de discussions autour du forfait et de la régie simplifient une réalité qui est souvent beaucoup plus nuancée sur le terrain.
Et dans la pratique, la majorité des projets se situent probablement quelque part entre les deux.
Aujourd’hui, je me méfie surtout des projets où le niveau d’engagement demandé dépasse largement le niveau de visibilité réel
Et vous, vous vous situez plutôt en régie, en forfait… ou quelque part entre les deux ?