Facturer au forfait ou à l'heure : ce que j'ai appris en freelance

Le client m'a écrit à 23h47 un dimanche : « Petit changement, rien de majeur, juste ajouter un système de filtres sur la page produits. » J'ai lu le message sur mon téléphone, dans le lit, et j'ai senti mon estomac se nouer avant même de comprendre pourquoi.

Le projet était censé être terminé depuis dix jours. Facturé au forfait, un site vitrine avec catalogue produits pour une petite entreprise de Chicoutimi. Sauf que le « petit changement » du dimanche soir, c'était le septième depuis la signature du devis. Un système de filtres, ça veut dire repenser la structure de la base de données, ajouter des composants, tester sur mobile. Ça veut dire une bonne douzaine d'heures de travail que personne n'allait payer.

J'ai fermé les yeux, posé le téléphone, et je me suis dit : plus jamais ça.

Le piège du forfait mal cadré

Mon premier réflexe, quand j'ai commencé en freelance, c'était de tout facturer au forfait. Ça sonnait rassurant pour le client, et pour moi aussi. Un prix fixe, une deadline, tout le monde sait à quoi s'attendre. Sauf que ça marche seulement si le scope est verrouillé, et en pratique, il ne l'est presque jamais.

Le problème d'un prix de projet fixé trop tôt, c'est qu'il repose sur une estimation faite avant de vraiment comprendre le besoin du client. Au moment du devis, je travaillais avec des suppositions : « je pense que ça prend une trentaine d'heures », « je pense que le client sait ce qu'il veut ». Les deux suppositions se sont écroulées à peu près en même temps, sur presque tous mes projets de la première année.

Le scope creep, c'est ce glissement progressif où chaque petite demande semble raisonnable isolément, mais où l'accumulation transforme un projet court en projet long, payé au prix du court. Le client ne triche pas nécessairement. Il découvre en cours de route ce qu'il veut vraiment, et moi je découvre en cours de route que mon devis était optimiste.

J'ai fini par comprendre trois choses qui reviennent systématiquement dans les forfaits qui dérapent :

• Le scope est décrit en une phrase vague (« site vitrine avec catalogue ») au lieu d'une liste de fonctionnalités précises
• Aucune limite de révisions n'est mentionnée dans le devis
• Le paiement final dépend de la « satisfaction » du client, un critère qui n'a pas de fin

Sur ce projet, j'ai fini par y mettre plus du double des heures prévues. Ramené à un taux horaire, je gagnais à peu près la moitié de ce que je facturais normalement. J'ai littéralement payé pour travailler.

Pourquoi l'heure pénalise l'expérience

Après ce fiasco, j'ai basculé complètement sur la facturation à l'heure. Logique de rebond classique : si le forfait me brûle, je facture chaque minute travaillée, point final.

Ça a duré quelques mois avant que je réalise le vrai problème du taux horaire : il punit la compétence.

Voici ce qui s'est passé concrètement. J'ai développé un système d'authentification pour un client, un truc que j'avais déjà fait plusieurs fois avant. Grâce à l'expérience, ça m'a pris quelques heures au lieu d'une journée entière qu'un développeur moins habitué y aurait passé. Facturé à l'heure, ça donnait une petite facture.

Le client a comparé avec un autre freelance qui lui avait proposé « le même travail » pour bien plus cher, en facturant beaucoup plus d'heures. Il est revenu vers moi en disant, presque déçu : « T'es sûr que t'as bien fait tout le travail ? C'est vite fait pour ce prix-là. »

Je me suis retrouvé à devoir justifier ma rapidité au lieu d'en être récompensé. La facturation à l'heure crée un désalignement direct entre la valeur livrée et le prix payé. Plus je deviens bon, plus je vais vite, et plus je perds de revenus par projet. C'est l'inverse de ce qu'on veut dans n'importe quel métier.

J'ai aussi remarqué un autre effet pervers : la facturation horaire encourage inconsciemment à traîner. Pas de la malhonnêteté délibérée, mais un relâchement naturel. Pourquoi optimiser un processus de deux heures à trente minutes si ça réduit ta facture ? Ce biais existe même chez les gens honnêtes, moi inclus, et je préfère l'admettre plutôt que de faire semblant que j'y suis immunisé.

Il y a aussi la charge mentale du chronométrage. Passer sa journée à noter le début et la fin de chaque tâche transforme le travail créatif en comptabilité. J'ai écrit sur ce genre de fatigue invisible dans un article sur les pièges du travail en isolement, et le time tracking constant fait clairement partie de ces frictions qui épuisent sans qu'on s'en rende compte.

Le devis qui a tout changé

Le tournant est arrivé sur un projet pour une clinique dentaire de la région. Le client voulait un site de réservation en ligne connecté à leur système de gestion de rendez-vous existant. Complexe, avec des inconnues techniques réelles, puisque l'intégration avec leur logiciel de gestion n'était documentée nulle part correctement.

Au lieu de choisir entre forfait ou heure, j'ai proposé un devis en deux blocs distincts.

Premier bloc : un forfait fixe et modeste pour le cadrage. Une semaine où je documente précisément le scope, teste la connexion avec leur système existant, et je livre un document de spécifications avec une estimation d'heures détaillée. Le client sait exactement ce qu'il paie, et moi je ne m'engage sur rien avant d'avoir vraiment vu les entrailles du système.

Deuxième bloc : un taux horaire avec plafond, basé sur le document de spécifications. J'estime une fourchette d'heures pour le développement, je facture à l'heure réelle, mais je m'engage à ne jamais dépasser le plafond sans repasser par une discussion formelle. Si je finis plus vite parce que je suis efficace, le client paie moins. Pas de pénalité pour ma vitesse.

Le résultat a été net. Le client a apprécié la transparence du bloc de cadrage, ça a désamorcé la méfiance habituelle envers les devis flous. Et moi, j'étais protégé sur deux fronts : le scope creep était limité par le plafond d'heures, et ma rapidité restait rentable puisque chaque heure comptait vraiment.

Ce modèle hybride, je l'utilise maintenant sur presque tous mes projets, sauf les micro-mandats de quelques heures où le forfait simple reste plus rapide à négocier pour tout le monde. Cette discipline dans le cadrage rejoint ce que j'ai documenté sur comment j'automatise mon workflow de développement : les tâches répétitives comme le cadrage gagnent à être structurées une fois, puis réutilisées, plutôt que réinventées à chaque client.

Comment je structure mes devis maintenant

Avec l'expérience, j'ai fini par documenter une checklist personnelle que j'applique avant chaque devis. Ce n'est pas de la théorie, c'est le résultat direct des projets qui ont mal tourné.

Chaque devis contient maintenant :

• Une liste de fonctionnalités numérotées, pas une description générale. « Système de filtres par catégorie, prix et disponibilité » plutôt que « catalogue produits »
• Un nombre de révisions inclus, généralement deux rondes, au-delà duquel chaque modification supplémentaire est facturée séparément
• Une clause explicite sur les changements de scope : toute fonctionnalité non listée fait l'objet d'un avenant écrit avant d'être développée
• Un plafond d'heures dès que le projet dépasse une vingtaine d'heures estimées, avec le principe du bloc hybride

Cette structure m'a évité plusieurs disputes clients dans la dernière année. Pas parce que les clients sont malhonnêtes, mais parce que la clarté élimine l'ambiguïté qui mène aux malentendus. Un client qui sait dès le départ que « le filtre de recherche avancé » n'était pas dans le devis initial ne se sent pas trahi quand je facture l'ajout séparément. C'est écrit noir sur blanc, signé, référencé.

J'ai aussi ajusté ma façon de présenter le prix. Avant, je donnais un chiffre brut, sans contexte. Maintenant, je montre la ventilation : cadrage, développement, tests, déploiement, avec des heures associées à chaque bloc. Le client voit où va son argent, et ça réduit énormément les négociations à la baisse, parce qu'il n'y a plus de mystère à contester.

Cette rigueur a un lien direct avec la façon dont j'ai trouvé mes premiers clients. J'avais écrit sur les erreurs d'acquisition qui ont failli tuer mon freelancing, et la mauvaise tarification faisait clairement partie du problème racine : accepter des projets mal cadrés par peur de perdre le client, se brûler dessus, puis avoir moins d'énergie pour prospecter correctement le mois suivant. Le cycle se répète tant qu'on ne casse pas le pattern à la source.

Ce que je ferais différemment demain

Si je devais recommencer freelance à zéro, avec ce que je sais maintenant, je ne signerais aucun projet d'une certaine ampleur sans un bloc de cadrage payé séparément. Le cadrage, c'est l'assurance qui protège tout le reste du projet. Un client qui refuse de payer pour le cadrage, c'est souvent un signal d'alarme sur sa relation future avec l'argent et le scope.

Je continuerais aussi à privilégier le modèle hybride sur les projets moyens et gros, parce qu'il aligne mes intérêts avec ceux du client au lieu de les opposer. Le forfait pur récompense la lenteur du client à faire des demandes claires. L'heure pure récompense ma lenteur d'exécution. Le mix des deux récompense la clarté des deux côtés.

L'action concrète que je propose : sur ton prochain devis, sépare explicitement le cadrage du développement, même pour un petit projet. Facture le cadrage à un tarif fixe modeste, documente le scope précisément dans ce livrable, puis présente un forfait ou un taux horaire plafonné basé sur cette documentation, pas sur une estimation à froid. Ça change tout dans la relation client, et ça t'évite les dimanches soirs à 23h47 à lire un message qui commence par « petit changement, rien de majeur ».

À lire aussi

• React et TypeScript : quand dire non malgré la hype
• Comment survivre à son DEC en informatique sans se faire détruire par les maths
• Pivoter un produit numérique : comment j'ai su qu'il fallait changer de cap