Blog

Déc 15

Facturer à l’heure

On me demande régulièrement mes conditions de facturation. Il y a trois modes de fonctionnement possible : par forfait au projet, à la journée, ou à l’heure. J’en ai choisi un (spoiler: à l’heure). Puisque je répète souvent le même laïus, autant le publier une bonne fois pour toutes. Ca sera l’occasion d’expliquer mes motivations en détail.

Le plus intuitif semble être la facturation au projet. Le client explique son besoin, le développeur estime le temps de travail nécessaire, et établit son devis. Éventuellement, il propose une v1 et une v2, sous la forme d’un devis à tiroirs. Une fois le devis validé, il retrousse ses manches, met sa capuche (si si, tous les devs bossent en hoodie) et se met au travail.

Pourtant, régulièrement, le client arrive à moi avec une idée, et c’est à moi de l’accompagner dans sa réalisation technique. Il faut l’aider à conceptualiser les étapes, établir un cahier des charges, s’assurer de la faisabilité technique, etc. Il est quasiment impossible d’estimer réellement le temps que cela prendra.

On sait aussi comment se passe le cycle de vie d’un projet web : le client continue de réfléchir à son projet, apporte de nouvelles idées, change d’avis sur des éléments validés. Le devis initial ne répond plus aux besoins, et le dev commence à travailler « hors-forfait ». Et puis, soyons francs, c’est le jeu : dès la presta au forfait signée, le but du client est d’avoir un maximum de travail fourni pour le prix convenu, et le but du dev est d’en faire le moins possible et de facturer.

Deux alternatives se posent alors : soit le développeur facture plus cher que prévu et le client n’est pas content, soit il accepte mécaniquement de baisser son taux horaire, et il n’est pas content (Vous la sentez, la relation qui va se dégrader très vite ?).

En ce qui me concerne, la partie commerciale de mon job n’est pas celle que je trouve la plus intéressante. Parler d’argent toute la journée, ce n’est pas mon but, ce n’est pas ce que je vend ; les aller/retour « budgétaires » ont franchement tendance à me fatiguer.

J’ai pensé à interdire au client toute modification avant que son projet ne soit terminé. Problème : il sait qu’il paye pour un résultat qui n’est pas exactement celui attendu, et je sais que la durée de vie de mon travail est limitée.

Je vois énormément de gens facturer à la journée… Ca me pose souci. Qu’est-ce que mon client appelle une journée ? Je connais des gens qui bossent non-stop de 6h à 22h. D’autres qui bossent de 9h à 16h. Et d’autres qui bossent une heure par jour, à tout casser. Sur qui est-ce que je calque la durée de ma journée ? Autre problème : Je perds en flexibilité. Difficile de m’échapper 2 ou 3 heures dans l’après-midi (au hasard: pour faire mes courses de Noël) pendant une journée vendue. Et que fait-on en cas de rush temporaire, avec des journées super-chargées ? Est-ce que je prends la décision de m’impliquer au point de faire des « heures supplémentaires » non facturées, ou est-ce que je laisse l’équipe en plan pour mon confort personnel ?

En travaillant sur la base d’un tarif horaire, j’arrive à avoir la souplesse nécessaire pour répondre aux besoins de mes clients, même quand ils sont évolutifs. Chaque « petite demande » (unité de travail) fait l’objet d’une estimation du temps que ça va me demander et une fois l’intervention validée, je m’y mets. Si le client change d’avis en cours de route, je lui explique simplement les répercussions en termes de temps de travail. C’est aussi beaucoup plus pratique pour calculer ma charge de travail et faire mon planning en fonction.

Je travaille bel et bien sur des estimations. Ca demande beaucoup de transparence et une vraie relation de confiance. Quand le travail met moins de temps que prévu, la facture comportera une bonne surprise. Très souvent dans ces cas-là, mes clients augmentent le périmètre de la presta et trouvent de nouvelles choses à me faire coder pour rester dans le budget initial. Quand le travail dépasse, c’est à moi d’expliquer au client, le plus tôt possible, quel sera le surcoût, et surtout pourquoi l’estimation de base était fausse. Estimer des temps réels de réalisation, dans le vrai monde, est un exercice plutôt délicat – mais on s’y fait !

Prochaine étape: accepter les paiements en bitcoin 😀

About The Author

Leave a reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *