La réponse courte : le forfait convient quand vous savez déjà ce que « fini » veut dire ; le TJM (régie) convient quand vous devez encore apprendre sur le marché, le produit ou l’organisation — et que pivoter fait partie du plan. Les deux modèles sont légitimes ; le mauvais choix, c’est surtout celui qui ne correspond pas à votre niveau de clarté au moment où vous signez.
Ce guide est pour vous si vous comparez des devis et que les montants ne se comparent pas : l’un par lot, l’autre à la journée, parfois sans même le même périmètre écrit.
Pourquoi le forfait rassure — et où il devient rigide
Le forfait répond à une demande légitime : « Je veux savoir ce que je paie avant de m’engager. » Sur une vitrine bien cadrée, une refonte avec maquettes validées ou un module dont les spécifications tiennent en une page, c’est souvent le bon outil. Le prestataire internalise le risque d’estimation ; vous, vous savez quoi budgétiser en trésorerie.
La rigidité apparaît quand la réalité diverge du texte : nouvelle réglementation, priorité métier qui change, retour utilisateurs qui invalide un parcours. Sans processus de changement clair, chaque demande devient une négociation émotionnelle. Ce n’est pas la « faute » du forfait : c’est le signe que le périmètre était optimiste ou que le marché n’était pas encore stabilisé.
Chez Websual, on aime les forfaits quand le client peut dire noir sur blanc : voici les écrans, voici les cas limites, voici qui valide — et quand le risque résiduel est faible. Sinon, forcer un forfait, c’est parfois payer plus tard en avenants ou en friction.
Pourquoi le TJM (régie) déplaît parfois — et où il gagne
Le TJM expose une vérité que le forfait masque : le travail reste du temps humain. En régie, vous payez les journées (ou demi-journées) effectivement consacrées au projet, avec une transparence sur l’activité si le freelance tient ses engagements de reporting.
Ce modèle offre la flexibilité de pivoter sans rouvrir un marché à chaque idée : on coupe une fonctionnalité basse priorité, on en teste une autre, on ajuste après retour terrain. C’est proche de ce qu’on attend d’une Méthode Agile réelle — pas du vocabulaire sur un slide — tant qu’il y a une backlog priorisée et un garde-fou budgétaire (enveloppe, plafond, ou sprint budgetisés).
Le risque, c’est le Scope creep sans discipline : tout est « faisable », la facture grossit, la confiance s’use. La régie n’est pas une permission d’improviser ; c’est un contrat de confiance qui exige des deux côtés une tenue de cap sur la valeur livrée par période.
Forfait ou TJM : que demander sur le papier pour comparer des devis ?
Posez les mêmes questions aux deux formats :
- Périmètre : quels écrans, quelles intégrations, quels tests, quelle mise en production ?
- Révisions : combien de tours inclus, qui tranche en cas de désaccord design ?
- Imprévus : comment une demande hors scope est-elle chiffrée et acceptée ?
- Fin de mission : accès, repo, documentation, transfert — quoi qu’il arrive ?
Sur un forfait, vous cherchez des livrables nommés et une date ou des jalons. Sur une régie, vous cherchez un TJM, une estimation de charge ou de sprint, et la façon dont le temps est justifié. Comparer deux lignes « développement » sans ce détail, c’est comparer deux monnaies différentes.
Le bon choix selon votre niveau de clarté projet
Vous tenez déjà le brief : objectifs mesurables, parcours utilisateur discuté en interne, contenus identifiés ou plan de production clair. Le forfait (éventuellement en plusieurs lots) vous donne un cadre net et un prix prévisible — le freelance peut challenger le périmètre avant signature, puis s’exécuter.
Vous savez où vous voulez aller, pas exactement comment y arriver : premiers utilisateurs, test d’offre, intégration avec un outil encore en discussion. Le TJM avec enveloppe ou sprints plafonnés évite de mentir sur un forfait « inventé ». Vous acceptez un peu plus d’incertitude sur le total en échange de réactivité et d’apprentissage.
Vous hésitez entre les deux : commencez par une phase courte cadrée (atelier + proposition structurée) au forfait ou au forfait symbolique, puis enchaînez sur le mode qui colle au livrable validé. Le pire scénario reste le contrat unique mal choisi pour faire plaisir au tableau de trésorerie.
Règle simple : si retirer une fonctionnalité ne change pas le prix du devis, vous n’êtes probablement pas sur un forfait honnête — ou le scope est déjà minimal. Si ajouter une fonctionnalité ne peut pas être estimée, vous n’êtes pas prêts pour un forfait global ; la régie ou un lot séparé mérite d’être discuté sans tabou.
Conclusion : le modèle sert le projet, pas l’inverse
Forfait et TJM ne sont pas des grades de prestige : ce sont des instruments de partage du risque. Le bon choix dépend de la maturité du besoin, de votre capacité à prioriser et de la qualité du dialogue avant signature — pas du mot sur la première ligne du devis.
Pour cadrer un produit ou une refonte avec un interlocuteur unique côté stratégie et pilotage, jetez un œil aux pages Product Owner freelance à Pau et Développeur Next.js freelance à Pau — deux facettes complémentaires du même objectif : livrer utile, sans bullshit budgétaire. Pour le cadre plus large (freelance vs agence, interlocuteurs, responsabilité), l’article Freelance web à Pau ou agence pose les bonnes questions sans caricature.