Je m’appelle Thibaut Assus, j’ai 30 ans, je suis freelance en développement web et ma technologie de prédilection est le Ruby on Rails. J’ai maintenant un peu d’expérience dans le domaine du freelancing et ce document a pour but de partager avec vous une partie de cette expérience.
En 2010, je ne connaissais que le travail en France. Je développais déjà à l’époque en Ruby mais mon expérience avec les clients était inexistante. Mon travail me satisfaisait moyennement. Je rencontrais le problème majeur qu’ont probablement rencontré tous les développeurs dans leur vie, quelle que soit leur technologie : il y avait un intermédiaire entre le client et moi pour établir les contrats au forfait.
Cet intermédiaire n’était pas un développeur et n’avait donc pas pleinement conscience de ce que contenait le-dit contrat. Comme le client n’était pas non plus lui-même développeur, il n’avait pas non plus conscience de ce que représentaient les fonctionnalités qu’il demandait. Par conséquent, je me retrouvais obligé de travailler dans des délais qui ne correspondaient jamais vraiment au travail à réaliser.
À cette époque, j’avais assisté à quelques évènements organisés à Paris autour du langage Ruby, mais ne m’impliquais pas particulièrement dans la communauté. J’étais dans un état d’esprit finalement assez passif.
Puis j’ai eu l’occasion de partir aux États Unis pendant un an. À Philadelphie, j’ai assisté à un évènement pendant lequel j’ai rencontré des développeurs Ruby américains. C’est à cette occasion que j’ai parlé pour la première fois à un freelance qui facturait ses clients non pas au forfait, mais à l’heure. Il s’appelle Trotter Cashion et notre échange a été pour moi un déclic fondamental dans ma manière de penser. Notre discussion peut être résumé ainsi :
Thibaut : « Mais comment fais-tu pour vendre des heures de travail au lieu de fonctionnalités ? » Trotter Cashion : « Je livre simplement du code fonctionnel. »
Quelques temps plus tard, j’ai assisté à un autre évènement qui avait lieu à New York cette fois. Je me souviens de ces deux développeurs assis derrière la table d’un bar. Ils avaient l’air serein. Un homme, apparemment intimidé, s’est approché d’eux et leur a dit :
« Bonjour, je recherche des développeurs Ruby pour travailler dans ma grosse société de finance mais je n’arrive pas à en trouver. Nous avons pourtant fait passer des entretiens, mais personne n’a l’air de vouloir venir travailler avec nous. Pouvez-vous m’aider ? »
L’un des développeurs lui a répondu :
« Et bien déjà, de combien de développeur as-tu besoin ? » « Une trentaine. » « Trente développeurs Ruby ? Et pourquoi faire ? Et combien es-tu prêt à les payer, tes développeurs ? » « $150 000 par an. » « Personne ne viendra travailler pour toi à ce salaire. Les développeurs peuvent avoir des salaires équivalents dans des petites sociétés. Pourquoi viendraient-il travailler dans une grosse société de finance pour gagner aussi peu ? »
Cette conversation m’a donné l’impression d’avoir atterri sur une autre planète. Une planète où un développeur était clairement en position de force par rapport au recruteur, et où il estimait son salaire à des sommes que je considérais à l’époque comme astronomiques. Et personne ne semblait choqué par tout cela.
C’est ce qui a été pour moi l’élément déclencheur. Je voulais être cette personne qui mettait ses pieds sur la table de son bar favori, et qui n’avait plus à se plier à des règles établies par des personnes ne connaissant rien à son métier.
Quelques jours après, j’ai commencé à travailler pour une société rencontrée à cet évènement. Lors de mon premier entretien, sans qu’ils m’aient demandé ni CV, ni lettre de motivation, ni même les études que j’avais faites, ils m’ont montré leur liste de bugs et j’ai commencé à faire du pair programming avec un des leurs. Un quart d’heure plus tard, il m’a demandé comment nous pouvions faire pour commencer à travailler ensemble. Je leur ai dit que j’étais prêt à travailler pour eux à $150K par an. Ils m’ont répondu qu’ils avaient l’habitude de travailler à la journée, et c’est donc le premier contrat de ce type que j’ai passé avec eux (et qui s’est très bien passé).
Lorsque je suis rentré en France, le dynamisme que j’avais découvert aux USA avait définitivement changé mon approche du développement web. J’avais soudain conscience que mes compétences avaient bien plus de valeur que ce que je m’imaginais, et que je pouvais apporter bien plus à des clients que ce que je faisais jusque là.
Dès mon retour à Paris, j’ai assisté à un évènement Ruby dans la capitale. Nous étions une dizaine de personnes. J’avais découvert meetup.com aux USA (un service permettant de créer des groupes et d’organiser des évènements facilement) et comme aucun groupe Ruby n’existait alors sur Paris, j’ai créé Paris.rb afin de faciliter l’organisation des évènements Ruby dans la capitale. C’était le 06 juillet 2011. Le premier évènement du meetup ayant eu lieu comptait 30 personnes. Six mois plus tard, l’évènement en comptait 150.
Côté business, j’avais créé ma boite et j’ai rappelé une société qui m’avait contacté juste avant mon départ aux États Unis. Ils avaient une v1 en Rails et désiraient à l’époque travailler sur la v2. Je leur ai demandé s’ils recherchaient toujours un développeur Ruby, ce à quoi ils m’ont répondu que vu le peu de développeurs Ruby en France, ils avaient préféré réaliser cette v2 en PHP. Cette pénurie de développeurs entraînait forcément une pénurie de missions dans cette technologie. C’est pourquoi j’ai dû accepter un travail de développeur PHP à cette époque. En parallèle, je m’occupais du meetup Paris.rb afin de retrouver une communauté Ruby.
Quatre mois plus tard, j’avais trouvé un client pour du développement Ruby, grâce au meetup.
Aujourd’hui, 2 ans plus tard, le meetup a dépassé le millier d’inscrits. Le tout dernier évènement a comptabilisé 250 personnes et a été hébergé dans les locaux de Google France. Je travaille exclusivement à l’heure, deux à trois jours par semaine pour des clients et le reste du temps je peux travailler sur mes projets personnels. La qualité de mes relations avec mes clients n’a jamais été aussi bonne.
J’ai essayé de synthétiser dans le reste de ce document une partie de mes réflexions et de mon expérience afin de vous en faire profiter.
Trop de gens encore aujourd’hui restent enfermés dans des schémas de travail inefficaces. L’exemple le plus flagrant dans le monde du développement est le contrat au forfait. Un client signe un contrat avec un prestataire dans lequel ce dernier s’engage à livrer dans une durée donnée une liste précise de fonctionnalités.
À première vue, rien de bien méchant. Mais en pratique, ce genre de contrat ne marche jamais. La plupart du temps, ni le client ni le freelance ne sortiront contents de cet arrangement. La raison en est simple : à partir du moment où le contrat est signé, leurs intérêts divergent immédiatement. Pour le client, l’objectif est d’obtenir le plus de travail possible du freelance sur les fonctionnalités demandées. Pour le freelance, l’objectif est de finir le plus rapidement possible (ce qui n’empêche pas de faire du bon travail) cette liste de fonctionnalités. Donc le freelance s’attachera à faire exactement ce qui est décrit (le travail exact pour lequel il est payé) quand le client essaiera de pousser au maximum pour avoir la finalité de ce qu’il a demandé (le programme qu’il a imaginé).
Dans un domaine changeant aussi rapidement que le web, travailler au forfait n’a aucun sens. Dans le métier, il est courant de dire que le client ne sait pas ce qu’il veut. Mais le fait de ne pas savoir n’a rien de honteux, et s’il décide de faire appel à un freelance pour développer son produit, c’est aussi pour profiter de son expérience en la matière. Expliquer au client pourquoi prévoir une liste précise de fonctionnalités à développer pendant les six prochains mois ne lui ira pas fait aussi partie intégrante du travail du prestataire de développement.
Le point clé consiste simplement à être transparent, totalement honnête avec son client. Si vous pensez que travailler au forfait se passe toujours mal, et que vous comprenez ces raisons (d’ailleurs cela vous est probablement déjà arrivé à vous, en plus des nombreux témoignages qui abondent sur le sujet), il est de votre devoir de prendre le temps et l’énergie pour expliquer cela à votre client. Et contrairement à ce que l’on a pu vous dire, il est tout à fait capable de comprendre. Il faut simplement le lui expliquer. À l’heure actuelle, en France en tout cas, les contrats au forfait sont la pratique la plus courante. Mais dans d’autres pays, les États-Unis notamment, il est courant de travailler à l’heure. Vous avez donc des exemples concrets pour appuyer votre argumentation, en plus de la simple logique.
Partir perdu d’avance, en se disant que de toute manière les clients ne comprennent rien (ce genre de discours est encore trop courant dans le monde des développeurs), marque le début d’une relation déséquilibrée et malsaine avec votre prochain employeur / client. Vous devez prendre le temps de discuter avec lui, d’entendre ses arguments, ses peurs, de le rassurer en lui expliquant clairement pourquoi vous pensez que telle façon de travailler sera tellement plus bénéfique pour lui, en plus de l’être pour vous. Si vous n’avez pas réussi à le convaincre, peut-être faut-il envisager de chercher du travail ailleurs, à moins que vous ne soyez prêt à accepter ses conditions. Mais dans tous les cas, ne le faites pas avec rancœur. Il est souvent difficile de trouver des exemples de cas où le travail à l’heure a pu être vendu. Si vous manquez d’exemples, n’hésitez-pas à citer le mien. Je suis toujours prêt à aider les gens qui ont envie de mieux satisfaire leurs clients.
Accepter un travail et passer son temps à s’en plaindre n’est pas une attitude qui vous mènera où que ce soit. Attention, cela ne veut pas dire qu’au moment où vous décidez quelque chose il vous est ensuite impossible de changer d’avis. Non, cela veut dire que si vous n’êtes plus satisfait d’un arrangement, vous devez en discuter avec la personne concernée rapidement. Inutile de laisser l’amertume s’installer, il faut casser la glace aussi tôt que possible. L’une des façons de procéder est très simple : dès que vous commencez à vous plaindre d’un aspect de votre travail à quelqu’un d’autre que la ou les personne(s) directement concernée(s), mémoriser ce reproche et réfléchissez-y : à l’origine se trouve un malaise. Si vous ressentez ce malaise, c’est que quelque chose ne va pas. Si c’est quelque chose que votre client a dit ou fait, vous devez le lui dire (évidemment de la façon la plus diplomatique possible) pour la simple et bonne raison qu’il le mérite : c’est lui qui vous paye, si votre travail pâtit de quelque chose vous devez lui donner l’opportunité de corriger le tir.
Le travail à l’heure s’oppose au travail au forfait de cette manière : un travail au forfait ne vous fait pas vraiment travailler pour un client, mais pour un cahier des charges. Vous ne vous engagez pas à développer les fonctionnalités pour votre client actuel, mais pour celui qu’il était au moment où il a réalisé ce cahier des charges. Étant donné que la totalité des développeurs que j’ai rencontrés dans ma carrière sont tous d’accord pour dire qu’un client ne sait JAMAIS vraiment ce qu’il veut, il me paraît logique de dire qu’accepter de travailler au forfait avec un client sans lui expliquer que ce n’est pas vraiment pour lui que vous allez dans ce cas travailler relève de la malhonnêteté. Car travailler au forfait, c’est accepter un contrat dont vous savez qu’il ne satisfera pas votre client.
En revanche, le travail à l’heure permet de travailler pour le client à l’instant t, et non pas pour la vision erronée qu’il avait dans le passé de son projet.
Comme vous vendez des heures de travail à votre client, vous êtes obligé de justifier le temps passé sur chaque chose afin qu’il comprenne pourquoi il vous a payé ces heures. Ce qui veut dire que sa compréhension de son projet sera bien plus complète et précise. De plus, la modularité de ce type de contrat lui est extrêmement bénéfique : puisqu’il s’agit de développer les fonctionnalités au fur et à mesure, à chaque étape il peut (et devrait) faire appel à vous pour avoir votre avis en tant que spécialiste technique sur la valeur ajoutée d’une fonctionnalité. Tout développeur sait bien que de nombreuses fonctionnalités horriblement compliquées à développer apportent souvent très peu au projet dans lesquelles elles ont été commandées. Or comme vous devez justifier les heures que vous lui facturez, il est important qu’il sache que ce qu’il vous a demandé risque de prendre énormément de temps (et donc de lui coûter très cher) pour finalement n’apporter qu’une valeur ajoutée très faible à son produit. S’il estime que cette fonctionnalité doit absolument être développée, alors il le fait en connaissance de cause.
De plus, si vous pensez que ce qu’il vous demande sort de votre domaine de compétence, vous pouvez lui suggérer d’engager un spécialiste pour ce point particulier. Il sera peut-être cher à l’heure, mais si vous lui expliquez qu’il mettra dix fois moins de temps que vous pour réaliser ce qui vous est demandé, votre client comprendra rapidement quelle solution sera non seulement la moins chère, mais également la mieux réalisée.
Vous faîtes ainsi gagner de l’argent à votre client en lui suggérant les solutions les plus adaptées à son problème, et qui vont lui coûter le moins cher à terme. Votre comportement avec lui est transparent et adulte, et il sait que vous faîtes de votre mieux pour l’aider à développer ce qu’il désire VRAIMENT : un produit bien fait (donc solide, donc qui lui coûtera moins d’argent dans le futur en maintenance et améliorations) qui lui rapporte rapidement de l’argent et qui lui coûte le moins cher possible.
Le plus important des nombreux avantages du travail à l’heure réside dans le fait que vous êtes payé exactement pour ce que vous faîtes, donc à votre juste valeur. Finies les heures de développement imprévues pour la fonctionnalité en dernière page du cahier des charges, celle que vous aviez estimée à une heure de travail, celle dont vous n’aviez pas vue telle difficulté au moment où vous avez signé votre contrat, celle qui va vous faire suer sang et eau, et pour laquelle vous ne toucherez pas un centime de plus que ce qui avait été prévu. Alors même que vous savez pertinemment qu’elle n’apportera absolument rien de plus au projet. Sauf que vous vous êtes engagé avec votre client pour la développer.
Cela ne peut pas arriver si vous travaillez à l’heure. Parce que vous aurez le temps (et le devoir) de réfléchir très sérieusement à la question. Et aussi parce qu’après avoir passé trois heures sur ce problème que vous n’aviez pas anticipé, vous irez de vous-même voir votre client pour lui expliquer que vous vous êtes trompé, et que finalement cela risque de lui coûter très cher, pour une valeur ajoutée très faible. S’il estime qu’il faut absolument que vous le fassiez quand même, alors vous pourrez le faire pour ce que cela vaut réellement. Et votre client aura également conscience de la difficulté et de la valeur de ce travail.
D’autre part, facturer des heures permet également de travailler moins. Tout simplement parce que cela vous oblige à être concentré au maximum pendant vos heures de travail sur le-dit travail, et que vous constaterez rapidement que vous ne pouvez être aussi efficace à la douzième heure qu’à la première. Or, ces heures seront facturées au même prix. Vous devez expliquer à votre client qu’il paiera donc beaucoup moins cher son projet s’il ne vous oblige pas à travailler douze heures par jour. Personnellement, je refuse sauf cas d’urgence de travailler plus de cinq heures par jour. Je sais que je ne suis plus aussi efficace au-delà et l’explique clairement à mes clients.
L’un des principes de base de ma méthode de travail est la précarité. Quand je commence à travailler avec un client, je lui propose de lui vendre cinq heures de travail. S’il hésite, je lui propose du satisfait ou remboursé. Ainsi, je lui montre ce que je suis capable de faire en seulement cinq heures. Cela lui permet d’avoir une idée claire de mon efficacité sans avoir à prendre aucun risque : s’il n’est pas satisfait il sera remboursé jusqu’au dernier centime, sans même avoir à s’expliquer. Jusqu’à maintenant, aucun de mes clients n’a jamais demandé à être remboursé.
D’autre part, je ne signe jamais de contrat d’exclusivité. Si mon client devient mécontent de mon travail, il est libre d’arrêter de travailler avec moi quand il le veut. De mon côté, c’est la même chose.
À première vue, ce type de partenariat peut sembler risqué. Mais en pratique, cela veut dire que si nous voulons continuer à travailler ensemble, il nous est indispensable de faire des efforts dans ce sens en permanence. Ce qui veut dire régler les tensions dès qu’elles apparaissent, faire constamment des efforts pour se comprendre mutuellement et donc pour comprendre comment faire pour que le projet fonctionne.
Dans les relations entre personnes, qu’elles soient personnelles ou professionnelles, maintenir un équilibre sain implique de se remettre en question régulièrement, de faire des efforts pour comprendre l’autre. Votre relation avec votre client ne peut fonctionner que de cette manière : quand vous faites tous les deux des efforts pour comprendre l’autre. Et la précarité empêche d’endormir ces efforts. La garantie que vous donnez ainsi à votre client est la garantie que vous ferez toujours votre possible pour maintenir l’équilibre indispensable à la bonne marche de son projet. Et de son côté, il s’engage à faire de même.
Pour terminer ce premier aperçu de mon système de travail, je résumerai ce document en quelques mots : système gagnant-gagnant. Le secret d’une collaboration réussie entre un freelance et son client se résume finalement à ce que tout le monde soit content, et donc que tout le monde soit gagnant. Si vous trouvez cet équilibre où vous écoutez autant les besoins du clients que les vôtres, tout ira bien.
Hello!
Est-ce qu'il serait possible d'ajouter un espace après les
#des titres pour que Github puisse interpréter le Markdown ? Merciii 💙