6 erreurs à éviter en tant que développeur freelance
Le métier de développeur freelance est très tendance et attractif. Aussi exagérément glorifié à mon avis.
Avant de me lancer à mon compte (il y a maintenant un an), j’ai entendu beaucoup d’avantages (liberté, flexibilité, auto-formation choisie, expérience, argent…), mais trop peu de mises en garde et de conseils pour éviter les erreurs de débutant.
Dans cet article, je souhaite partager un peu de mon expérience et de mes enseignements, pour clarifier la démarche que je vais désormais appliquer avec mes clients, mais aussi pour sensibiliser mes futurs confrères éventuels (voire certains clients) aux côtés moins attirants du métier de développeur freelance.
1. Manquer de transparence et d’empathie envers le client
Suite à une première mission réussie au forfait pour un client, ce dernier me demande un autre devis pour apporter des améliorations sur le logiciel que j’avais développé. Heureux à l’idée de travailler à nouveau avec ce client, je me suis dépêché de chiffrer un devis réaliste, pour leur envoyer dans la foulée.
Réaction du client : embarras, et impression de se faire avoir, car le devis d’amélioration était plus élevé que le devis de réalisation du logiciel !
En effet, le forfait que je leur avais proposé pour la réalisation du logiciel s’était avéré trop optimiste : j’avais au final passé beaucoup plus de temps que prévu, sans demander de rallonge sur le budget. Mais surtout, je ne les ai pas informé de cet écart. Du coup, leur réaction était légitime.
Désormais, je propose systématiquement un bilan transparent de chaque mission. Et une rétrospective par sprint, dans le cas des missions Agiles.
2. Écrire du code sans avoir validé clairement le besoin du client
Ça vous est peut-être déjà arrivé : on te briefe sur un besoin, on te dit “fais au mieux”, et tu te rues sur ton éditeur de code pour montrer à quel point tu es un développeur efficace.
Réaction du client : “Pas joli joli ce que tu nous as fait” (vous noterez le petit jeu de mots inclus).
Et là, je me suis énervé. Mais cette réaction n’était qu’à moitié légitime.
En effet, je n’aurais jamais dû coder quoi que ce soit avant qu’on se soit mis d’accord par écrit sur ce qu’attendait mon client : spécifications de la fonctionnalité et wireframes de l’interface utilisateur à intégrer. En voulant montrer à quel point je pouvais livrer vite, j’ai tapé à côté du besoin. En tant que développeur, je suis mieux placé que le client pour savoir que tout besoin à développer doit être spécifié.
3. Accepter de brader le tarif de ses services
Même si ça m’a réellement porté préjudice qu’une seule fois, j’ai fait cette erreur deux fois. On ne m’y prendra plus.
Compréhensif quant aux raisons de mon client (une startup) d’être contraint de dépenser les fonds propres des co-fondateurs de la manière la plus responsable possible avant le lancement de leur service, j’ai accepté de réduire de 20% mon tarif journalier.
Résultat : non content d’avoir bradé mon temps sur un travail difficile, mon client a rechigné de payer à temps et au taux plein la facture suivante. J’ai dû monter le ton au téléphone pour que notre accord soit respecté.
Moralité : un client qui demande une ristourne est :
- soit un client qui sous-estime la valeur de votre apport sur sa mission; (peut-être que vous n’êtes pas faits pour bosser ensemble)
- soit un client qui fera tout pour avoir le plus possible en payant le moins possible. (c.a.d. le genre de client que vous préférez éviter)
4. Proposer un devis avec un périmètre vague
On m’avait pourtant prévenu : “ne bosse jamais au forfait, c’est un piège !”
Mais dans mon grand enthousiasme (ou plutôt insouciance) de débutant, et mon gout pour le travail en mode “focus” (c.a.d. avec un minimum d’allers-retours entre le client et moi pendant le développement), je suis tombé bien profond dans ce piège avec un de mes clients…
Face à un client pressé (cf point ci-dessous), au budget serré (cf point 3), et excité à l’idée de bosser enfin avec lui, je me suis dépêché de proposer un devis au forfait pour réaliser son site. Du coup, j’ai été très vague sur le périmètre de ce que je m’engageais à fournir…
“Surprises” :
- les wireframes m’ont été fournis avec 3 semaines de retard par le client, mais on m’a demandé d’avancer au maximum sans, histoire de pouvoir tenir l’échéance;
- on m’a envoyé un rapport (non prévu) d’expert SEO sur une version intermédiaire du site que je développais, et demandé de mettre celui-ci en conformité avec les recommandations de l’expert;
- une fois les wireframes reçus, j’ai découvert des fonctionnalités qui étaient beaucoup plus complexes à intégrer que ce que j’avais imaginé en lisant les 2–3 pages du cahier des charges du client.
Au final, j’ai dû re-coder énormément de pages, à mes frais.
Je n’ai demandé aucune rallonge pour la plupart des changements demandés, car j’estimais que ça rentrait bien dans le périmètre (vague, pour rappel) du devis sur lequel on s’était mis d’accord. J’étais pris au piège de ma propre incompétence.
Si j’avais été plus précis lors de la rédaction de ce devis au forfait, j’aurais pu facturer ces changements, ou le client ne m’aurait peut-être pas demandé de les faire.
5. Se laisser presser par le client
C’est un point commun de la plupart de mes clients : “on en a besoin vite”.
En tant que professionnel concerné et compréhensif, on a envie d’être rassurant : “ne vous inquiétez pas, on va y arriver !”, puis on se donne à fond pour tenir notre engagement.
Résultats pour le freelance :
- soit vous vous retrouvez à bâcler le travail (cf points 2, 4, 6), ou votre communication avec le client (cf point 1);
- soit vous vous retrouvez à payer les pots cassés, au final (cf point précédent).
Dans les deux cas, je me suis rendu compte que l’urgence exprimée était en fait toute relative, car les clients sont aussi capables de se mettre en retard sur leur propre date butoir (cf point ci-dessus). Et vous vous rendrez parfois compte à la fin que vous avez terminé le développement avant qu’ils ne soient prêts à publier quoi que ce soit.
Moralité : rassurer son client, c’est bien. Mais aller trop vite peut causer des dégâts bien plus importants au final.
6. Tolérer l’urgence dans un projet Agile
Après toutes ces erreurs “au forfait”, je me suis finalement résigné à écouter mes confrères : ok, je vais me mettre en mode “Agile” et facturer à l’heure.
Au début de la mission, je suis aux anges, et mon client aussi :
- On bosse par sprints de 2 semaines, avec priorisation des tâches en début de sprint et livraison fonctionnelle en fin de sprint;
- J’estime et mesure le temps de développement de chaque carte sur Trello, mon client suit mon avancement en temps-réel et répond à mes questions sur les cartes correspondantes. Process au top.
Au bout de quelques sprints, on m’explique qu’il faut absolument lancer le site dans deux semaines. Pas de problème : on réduit un peu le périmètre des prochains sprints, et le client m’aide en testant le site afin de faire remonter un max de bugs avant le lancement.
Et là, on me demande d’arrêter tout ce que je fais, afin d’ajouter des fonctionnalités “essentielles” dont le client ne m’avait jamais parlé auparavant.
Le lendemain (un vendredi), on me demande d’arrêter la fonctionnalité essentielle pour corriger un “bug critique”. Puis, la même journée, on m’envoie une autre tâche “prioritaire”.
Résultats :
- Pour ne pas laisser mon client dans l’embarras, je me retrouve à faire des heures sup (y compris les soirs et week-ends), et donc à négliger mes autres engagements;
- Mon niveau de stress augmente;
- La qualité de mon code baisse;
- Le nombre de bugs augmente;
- Et ainsi la boucle se répète…
Mais, malgré ce que l’on pourrait croire, ce n’est pas la faute du client. En effet, en plein lancement de produit, le client a des milliers de raisons d’être stressé, et il est difficilement évitable que ce stress déborde sur les prestataires.
En revanche, ce genre de situation ne doit en aucun cas remettre en question l’hygiène du processus de développement ! Car en faisant cela, on empire la situation en causant d’autres problèmes.
Moralité : quel que soit le niveau de stress du client, le développeur freelance est le mieux placé pour arbitrer l’urgence des développements demandés, et pour continuer de tenir le processus de développement tel qu’il a été convenu. Le but est pouvoir garantir un développement sain et pérenne du projet, en toutes circonstances.
Conclusion
Pouvoir être développeur freelance aujourd’hui est une aubaine, et je suis extrêmement heureux de vivre cette expérience ! En revanche, il ne faut pas oublier que ce mode de travail est radicalement différent du salariat. Le (futur) freelance doit en effet se préparer à faire face à de nouveaux types de situations, afin de ne pas être victime de sa propre entreprise.
Cet effort de formulation de mes expériences m’aide à prendre du recul. Et leur publication m’engage dans une démarche d’amélioration et de transparence (notamment vis à vis de mes clients présents et futurs) qui m’est chère.
Ne ratez pas mes prochains articles !
Rabbut peut vous les envoyer par email :-)
powered.by.rabbut.com
Un grand merci à Antonin Archer, Enzo Avigo, Olivier Thomas et Camille Betinyani pour leur relecture de cet article et les améliorations qu’ils ont suggérées.
