Les avantages de la facturation au temps passé : interview de Thibaut Assus

Thibaut est un freelance spécialisé en RubyOnRails. Il est organisateur de Paris.rb et il organise des formations à destination des freelances pour les aider à mieux se vendre et à réussir dans leur domaine.

Vous pouvez écouter la version audio ou lire la version texte ci-dessous.

Thibault, peux-tu nous décrire ton parcours ?

J’ai fait ma formation d’ingénieur à l’Epita et ensuite j’ai commencé à travailler dans des agences de communications, ce qui m’a frustré !

Ensuite, j’ai voyagé aux États-Unis où j’ai travaillé à l’heure et l’expérience était très enrichissante. Je facturai 150 $/h. Tout simplement en livrant du code fonctionnel.

Depuis mon retour en France, j’utilise ce principe avec mes clients. Je facture environ 100 €/h avec une négociation à la journée.

C’est de là que vient l’idée d’un service en ligne pour simplifier la réservation de mes journées. Au début, c’était uniquement pour moi, mais ensuite j’en ai fait une offre pour les autres freelances. Ce service s’appelle FreelanceBooking.

Pourquoi ces premières expériences dans les agences t’ont-elles frustrées ?

La seule valeur ajoutée de l’agence était de faire l’intermédiaire entre le client et moi. De plus, c’était rare que les clients soient contents du résultat, car en général il ne correspondait pas à ce qu’ils voulaient.

Quels sont selon toi les principaux avantages de facturer ton travail à l’heure ?

Lorsque tu factures à l’heure, tu peux facilement enlever des fonctionnalités que le client voudrait, mais qui finalement ne se révèlent pas importantes pour le produit. Avec ce modèle, on fait du sur-mesure.

C’est un peu comme dans le tournage d’un film, ton client c’est le producteur, et toi, développeur, tu es le réalisateur. Le producteur ne s’immisce pas au micron près dans le produit. Tarantino, un réalisateur un peu connu, à la fin d’un film, coupe beaucoup de scènes qui ne sont pas utiles, il est libre.

« Forfait » est égal à « Cahier des charges » qui est égal à la « Liste de fonctionnalités ». Il y a beaucoup de fonctionnalités qui ne seront pas utiles dans l’application et même il arrive que ces fonctionnalités superflues deviennent inutilisables par la suite.

Le cahier des charges liste toutes les fonctionnalités, c’est un peu comme si tu allais voir un artiste peintre et que tu lui disais : « Écoutez ! Vous devriez mettre un coup de pinceau là ; un autre là et puis là » — le peintre au bout d’un moment en a marre et il te donne le pinceau.

Le forfait démoralise, car il faut continuellement se demander si cette nouvelle fonctionnalité entre ou pas dans le forfait ; cela a pour effet d’enlever la motivation pour le projet lorsque ça ne rentre pas.

La valeur ajoutée du freelance c’est le conseil, il n’est pas juste un exécutant, mis à disposition de ses clients. Le freelance connait son métier et il a des expériences et des conseils qui valent de l’or pour ses clients. Le freelance se doit de poser des questions à son client, du genre : est-ce que ça vaut le coup de développer cette fonctionnalité ou pas ? Soyons pragmatiques !

De plus, un des avantages qu’il y a à être au temps passé, c’est que l’on est capable d’ajouter des fonctionnalités aussi facilement qu’on peut en enlever. On est plus souple qu’avec un forfait bien figé.

D’autre part, l’estimation qu’on fait sur un ensemble de fonctionnalité bien souvent ne tient pas compte de l’existant. Il faut que la nouvelle fonctionnalité ait du sens dans l’ensemble déjà existant. Quand on a une liste de fonctionnalités, il ne faut pas hésiter à en enlever là où au forfait ce n’est pas possible. En début de projet, on peut avoir 15 fonctionnalités et réussir à faire accepter à son client que quelques fonctionnalités ne soient pas nécessaires pour le lancement du produit.

Quel est l’argumentaire pour convaincre le client ?

Le plus important n’est pas de sortir un ensemble de fonctionnalité. On ne sait même pas si les fonctionnalités principales seront adoptées.

Favorisons l’adoption du produit par l’utilisateur ! Pour cela, il faut réussir à susciter un engagement des utilisateurs.

Le contexte web est plus à même de concevoir de cette façon. Avec le web, il n’a jamais été aussi facile de mettre à jour un logiciel. La plupart des applications qu’on utilise quotidiennement évoluent sans arrêt. Par conséquent, la véritable courbe d’adoption de son produit est dépendante de l’écoute de ses utilisateurs. Il faut faire évoluer son application en fonction de ces retours utilisateur. Et ainsi on peut faire des boucles itératives d’évolution de l’application.

Le client est humain, il a des envies. Des envies de belles fonctionnalités, des envies de beaucoup de fonctionnalités ! Il voudrait que son produit soit complet et que rien ne manque, c’est normal, c’est son bébé. Le développeur freelance, quant à lui, doit lui poser la question du vrai besoin derrière l’application. Le freelance doit s’intéresser au business de son client. Le but du client est d’avoir un business qui marche. Il faut élaguer les fonctionnalités pour avoir l’essentiel du produit, celles qui ont un lien certain avec le business du client.

Quand un client fait développer une application, ça doit lui rapporter de l’argent. C’est grâce à cet argent que le freelance peut justifier son travail, ses tarifs et sa méthode de facturation à l’heure. Lorsque le client embauche un freelance, il investit pour son entreprise, ce n’est pas une dépense inutile. Le freelance a un devoir de conseil.

Comment fais-tu alors pour choisir les fonctionnalités qui auront le meilleur retour sur investissement ?

J’utilise la méthode des cinq pourquoi (5 why). Je pose cinq fois des questions de façon itérative pour connaitre les raisons d’une telle fonctionnalité, pour en connaitre l’origine et pour savoir si le but est bien de répondre au besoin initial qui doit être un besoin business. Il faut comprendre les tenants et les aboutissants. Ce qui compte le plus c’est de penser comme le client, mais avec son expertise de freelance que le client n’a pas. On doit pouvoir être sûr qu’une fonctionnalité après l’autre a de la valeur. Et peut-être que tu auras une idée encore plus ingénieuse qui contiendra moins de code. Moins il y a de code, mieux c’est ! « Better code is no code at all » disait Jeff Atwood alias @codinghorror un des développeurs de Discourse. Le code c’est mal, plus tu as de code, plus tu as de bugs qui s’y cachent. Plus il y aura de fonctionnalités, plus il y aura potentiellement de bugs. On écrit des tests, donc on va maitriser ces bugs, mais plus il y a de code plus il y aura de la maintenance.

En général, je prends une journée entière avec le client pour décortiquer toutes ces fonctionnalités une après l’autre en lui appliquant les cinq pourquoi. Il faut pouvoir le conseiller, être sûr que ça a de la valeur. Je développe le même jour ces fonctionnalités qu’on a sélectionnées et on les teste ensemble. RubyOnRails est génial pour ça, c’est vite fait (ex : active admin).

Dès la première journée je lui bootstrap un produit et c’est déployé très vite, avec les fonctionnalités de base. Et bien sûr, je lui facture la journée. Je lui dis souvent que c’est du satisfait ou remboursé, mais pas toujours.

Pour les designers, vous pouvez lire un article qui vous montre que vous pouvez aussi appliquer cette approche : http://poppyjikko.com/petits-lots-graphisme-lean.

Suivez Thibaut sur Twitter : @tibastral

Écouter la version audio

La conférence Paris.rb : Happy Freelancing – Chloé Roger et Thibaut Assus
Sur le forum : Facturer au temps passé
Texte sur GitHub : Happy Freelancing