Categories: Vie de développeur

Freelance – Pourquoi la facturation au forfait, c’est litigieux

J’exprime mes observations sur la facturation des freelances.

Être entrepreneur et freelance ?

Au quotidien, je passe du temps avec des entrepreneurs plus ou moins jeunes qui cherchent un freelance pour démarrer leur nouvelle startup.
Alors, j’entends ce double discours qui contient deux fausses vérités.
Dans la main droite : « Avec un Freelance, on ne construit pas une relation longue durée ». Dans la main gauche, « J’ai un bon cahier des charges, tu pourrais me faire faire des devis ? ».
Cet article se veut un guide pratique pour l’entrepreneur qui veut se lancer accompagné de freelances.

Le cahier des charges, garantie du bon déroulement du freelance ?

D’un coté le client essaye d’avoir le meilleur prix pour un cahier des charges qui, aussi méticuleux soit-il, ne sera jamais parfait. En plus, au fur et à mesure qu’on avance, le cahier des charges évolue, on entre dans une forme de guerre de scopage/descopage. Ou alors on essaye de faire passer des petites fonctionnalités à l’oeil. Qui n’a jamais vu un client essayer de faire passer en bug une petite évolution ? On est pas là pour se mentir, on l’a tous fait. On a signé un forfait pour 15K€ parce qu’on avait que 15K€, et on peut pas dépenser 200€ de plus pour ce détail.

En réalité, quand le client/chef de projet rédige le cahier des charges, il formalise, il projette une image qu’il a du résultat. Quand le développeur ou l’équipe réalise le projet, ils interprètent le cahier des charge et en développent une autre projection.

Le livrable est donc la vision du client passée par plusieurs prismes consécutifs. Et le cycle en V atterrit toujours à coté. Le client n’est jamais satisfait.

D’autre part, le Freelance essaye de marger. Il veut bosser le moins possible pour récupérer la prime. Sauf qu’au fur et à mesure qu’il avance la prime recule. C’est une approche logarithmique. Tu fais un pas, la prime recule d’un peu plus de la moitié de la distance avancée. Tu ne sais jamais quand est-ce que le projet arrivera à sa fin.

Comment bien se protéger ?

Alors pour se protéger, les prestataires ont plusieurs armes. Historiquement, on savait qu’on perdrait de l’argent sur le forfait, mais derrière, on claquait de la TMA comme des gros fous. Sur un gros compte, tu lui mets les deux poignets dans une menotte TMA de N jours par mois sur 3 ans. C’est so-années 2000.

D’autres vont faire une estimation, puis faire un calcul magique :

(Estimation * ( nombre d’intermédiaire + 1) — (acompte versé par le client)) / ( 2 si le projet n’a pas d’intégration) — (15% si on a déjà bossé avec le client une fois).

Le but étant de chiffrer le risque du projet, de mettre un chiffre dessus et de se protéger. Attends, t’es chef de projet, pas actuaire, non ?

Autre voie, on choisit le modèle de Factory. Une Factory veut industrialiser la production du logiciel. Là on part en noix déjà : le développement d’une application n’est pas une activité productive. Creuser un trou, ça prend un nombre H heures. C’est sûr. Faire un logiciel à 10K lignes de codes, c’est comme faire un puzzle avec 10K pièces. Finalement, personne ne sait dire combien de temps ça va prendre.

Un jour, un mec qui n’a jamais codé m’a dit « C’est parce que tu es junior, c’est à toi d’apprendre à faire de meilleurs chiffrages ». Enfin, je pourrais faire un article entier sur le concept de chiffrage et le fait que le code est une activité créative et pas productive et ce n’est pas le sujet ici.

Du coup, en fait, une Factory va mettre un ticket d’entrée « On peut pas marger sur un projet de moins de 25K€ », parce que « On a des coûts de structure », c’est nécessaire pour « faire du code de qualité ». Okay !

Mais au final, un Factory essaye surtout de factoriser le code. Et ça ne marche pas. Le code, il faut le maintenir une fois sur chaque client, ça va nul part.

Et l’agile au forfait ?

L’agile au forfait, au début ça m’a paru génial. Sauf qu’en fait dans la tête du client il a quand même acheté l’image de l’appli qu’il avait au début, c’est juste qu’à l’intérieur du forfait, il va avoir des livraisons intermédiaires et des démos. C’est mignon, mais au final ça change rien.

L’entrepreneur et le freelance.

Okay, assez de contexte, revenons à nos moutons.

Cet entrepreneur, c’est celui qui nous dit d’habitude « Je cherche un CTO associé, pour avoir quelqu’un de fiable dans la durée ». Il a du être touché par le mythe Hipster, Hacker, Hustler que l’on retrouve au jardin d’enfant des startups. Mais en fait, c’est relativement faux. Les Solo-entrepreneurs fonctionnent vraiment. Rien ne démontre qu’une équipe hétérogène en compétences arrive à une meilleure exécution qu’une équipe homogène. L’important c’est d’avancer, de bootstrapper, de démêler le tricot.

Si vous ne savez pas vous y prendre, trouvez de juste ici de l’inspiration pour la bonne entente de votre équipe.

En général, ces entrepreneurs n’ont pas encore généré de traction. Ils ne savent pas ce qu’est une landing page, ils ne comprennent pas l’intérêt d’accumuler des mails, de skyper de potentiels utilisateurs. D’abord, ils veulent trouver un développeur qui fasse le produit. Ensuite, comme ils n’ont pas d’argent, ils cherchent un associé.

Du coup, on fait notre travail d’éducation et lui explique.

Un contrat de prestation de service c’est plus engageant qu’un CDI. À tout moment, un employé en CDI peut démissionner ou commencer à faire du gras dans sa chaise de manière assez improductive. Ça n’arrive jamais avec un Freelance. Il s’est engagé à livrer, il livrera, sinon c’est un aller simple au tribunal de commerce.

Le problème c’est bien la facturation. Si tu dis à un freelance « Tiens, voilà un cahier des charges. Quand tu me livres, je te donne xx00€ », effectivement, tu ne crées pas une relation longue durée. Le freelance cherche à boucler le projet, pour enchainer sur le client suivant.

Quand tu vas voir un freelance et que tu lui dis : « Je veux que tu m’accompagnes, tu travailleras au moins N jours par mois à faire du développement et C jours par mois en Conseil, on peut se mettre d’accord sur un taux journalier de xx0€ », là tu construis une relation longue durée.

Du coup, en général, après nos échanges, il y a deux types d’entrepreneurs. Le mec continue dans sa lancée et cherche un CTO on lui conseille deux trois meetups pour rencontrer des gens.

Ou alors le gars revient nous voir en nous disant, okay, j’ai un petit budget (venant d’une subvention, d’un angel ou autre), on lui présente un freelance et le gars retourne voir ses investisseurs avec un dossier béton qui commence par « Je suis accompagné par un expert de folie sur le sujet ». Ses investisseurs lui font confiance et il débloque encore des fonds pour avancer.

En fait, il vaut mieux imaginer ta relation avec le développeur comme celle que tu as avec un avocat. Tu lui demandes pas un devis à ton avocat. Tu lui fais confiance et il te facture au temps. Parce que l’avocat t’accompagne dans la démarche, tout comme le dev. On va pas se mentir, un Dev qui accompagne un entrepreneur very early stage, il fait 60% de conseil et 40% de développements.

En tant qu’entrepreneur, lequel de ces deux chemins te paraît le plus intéressant ?

Pro Tips : Mesurer son temps
Si tu factures au temps, il faudra livrer (éventuellement) des feuilles de temps.
Perso, je m’en suis sorti avec deux tools pas trop mal.
Wakatime s’intègre à ton IDE est mesure automatiquement ton temps.
ZohoInvoice a une bonne feature pour faire les feuilles de temps.

Maîtriser son budget, le MVP.

Du coup, avec les entrepreneurs qui démarrent leur première version qui ont un petit financement, on les guide sur une approche MVP. Parce qu’au final le mec à un budget à tenir. Parfois il a 7K€, on lui conseille d’en dépenser 5 dans le développement de leur première version et 2 dans l’acquisition des premiers utilisateurs.

On va leur demander de faire une liste priorisée de fonctionnalités et un prototype (sur invision par exemple) pour bien voir où ils veulent aller. Quand ça a l’air assez réaliste, on les met en relation avec un ou plusieurs freelances qui vont avoir le discours suivant « Avec 5K€, on peut passer 1x jours à bosser et on doit pouvoir faire une version qui contient tel lot de fonctionnalités. Je te propose de signer pour 1x jours à 5K€ ». Si le client trouve que ce lot de fonctionnalités est suffisant pour amorcer de la traction, c’est au moins un MVP, voir une V1. Et ça roule tout seul. EASY. Après cette première mise en production, l’entrepreneur aura de bonnes metrics marché et pourra éventuellement débloquer des fonds, et relancer une version avec le freelance.

Vous êtes développeur-peuse freelance et vous avez envie de passser par WeLoveDevs ? Contactez-nous !

equipe@welovedevs.com
Damien Cavaillès

Recent Posts

Les pêches et les noix de coco : mieux comprendre la culture d’entreprise quand on change de poste

Changer d’entreprise, c’est excitant. Nouveau challenge, nouveaux collègues, nouveau café. Mais, bien souvent, on oublie…

7 jours ago

Le DevSecOps, une évolution nécessaire ?

Ça n’étonnera personne si nous affirmons que le monde du développement logiciel est en constante…

2 semaines ago

Travailler en tandem augmente la résilience des systèmes et le bien-être des collaborateurs !

En Allemagne, le travail en tandem à temps partiel, aussi appelé « jobsharing » est…

2 mois ago

Classement QCM saison automne : infos & règlement.

On se retrouve comme d'habitude pour le début du classement qcm saison automne ! Mais…

2 mois ago

Classement QCM saison Eté 2024 : Règlement, informations.

La saison printemps des tests techniques WeLoveDevs s'est terminée le 31 mai, et c'est Axel…

5 mois ago