Préambule

J’ai écris ce truc sans structure, en plusieurs fois, à divers niveaux de fatigue, complètement en freestyle.
C’est mon avis personnel, et dans la plupart des cas, les propos engagés sont ma vision des choses. C’est mon blog, merde.

Note: je suis un fervent militant de la reconnaissance du mot pasque, contraction pratique et phonétique de parce que. Y va y en avoir tout plein.

C’quoi, ce post ?

Ce post est un retour d’expérience sur la sous-traitance en tant que développeur web.

Ca peut être une bonne lecture pour un freelance qui voudrait se lancer dans la sous-traitance, ainsi qu’une bonne lecture pour une agence qui souhaiterait utiliser les services d’un sous-traitant le temps d’un projet.

Note: tous les sous-traitant ne sont pas comme moi. Et c’est tant mieux. Mais si certains des propos qui suivent s’appliquent plus particulièrement à moi, d’autres sont plutôt généraux et peuvent servir à tout un chacun.

C’est quoi, en règle générale, un sous-traitant ?

Globalement, un sous-traitant, c’est un handicapé social incapable de bosser de 9 à 18h en agence, mais qui est suffisament bon dans son métier pour trouver quand même des choses à faire.
Enfin… c’est ma définition du sous-traitant, mais j’en connais pas des masses et ils sont un peu tous comme ça.

Dans mon cas, y a deux raisons au fait que je ne sais pas bosser en agence : j’ai une santé catastrophique, et j’ai un gros problème avec les cycles jours/nuits. Je m’explique brièvement, puis je n’en parlerai plus : j’ai une insuffisance hépatique et un TDA. La première est suffisament grave pour me bousiller tout le système digestif un jour sur cinq, et le second fait que je ne sais pas rester plus de 15min assis sur ma chaise sans m’arrêter, au choix, pour : regarder les mouches, sortir prendre l’air, faire chier mon chat ou crier à tue-tête en tournant sur ma chaise. Voire le tout en même temps, accompagné de photos sur instagram ou de statuts facebook.
C’est un peu con, mais c’est comme ça. Et pour les cycles jours/nuits, je dors ±6h par nuit, mais c’est généralement de 4h30 à 10h30 du matin, réglé comme une montre suisse.

Du coup, mes expériences en agence ont toutes été folkloriques, mais j’aime coder, j’aime intégrer, je suis fait pour ce métier et je l’adore.

Alors je me vends comme une sorte de MacGyver, le brushing en moins (la classe en plus), pour dépanner les agences sur des projets plus ou moins courts et mettre mon expertise au service de ceux qui en ont besoin (j’suis un enfoiré du code, sauf qu’on me laisse pas chanter - et c’est pas plus mal).

Voilà, on arrête avec le personnel, même si y en aura encore, mais ce sera du persoffesionnel.

Travailler avec un sous-traitant

Le brief

En règle générale, puisque je bosse hors site, j’aime bien recevoir un brief le plus complet possible, puis je pose mes questions, un maximum de questions.

C’est important pasque ça me permet de cerner le projet, les besoins, et de mesurer l’ambiance dans l’équipe autour du projet. Puisque je ne serai pas dans leurs bureaux, il me faut en savoir un maximum.

Et ce pour deux raisons : la première, évidemment, c’est l’aspect financier : je dois rendre un devis et donc évaluer le nombre d’heures que je vais passer sur le projet.
Parfois, ça rate, et y a des trucs que j’oublie de demander, ou qu’on oublie de me dire, et au final, je passe plus d’heures sur le projet, et donc c’est de l’argent que je perds.
Pasque sauf cas vraiment spécial (nouvelles fonctionnalités, etc…), ça ne se fait pas de demander un rab d’heures sur un devis déjà approuvé.
La seconde raison, je l’ai oubliée. Elle était sûrement pas importante, ou c’était pour faire genre j’ai réfléchi à une grande phrase… ah, si : en tant que sous-traitant, je n’ai souvent pas accès au client final. J’y reviendrai.

Je peux éventuellement me déplacer en agence pour discuter du brief, mais j’aime bien avoir un premier brief avant de me déplacer, pour avoir eu un peu de temps (genre une bonne nuit) pour me poser les bonnes questions.

Les ressources

En fonction du projet, je reçois généralement des ressources pour travailler.
Il faut distinguer les ressources techniques et les ressources graphiques.

Ressources techniques

Elles posent rarement problème, la plupart des bons devs savent qu’un code clair et/ou bien documenté est bénéfique autant pour l’équipe que pour eux-même.

Toutefois, il est important pour moi en tant que sous-traitant d’avoir facilement accès à une personne ressource pour la technique : chaque développeur à une vision propre du code, et puisque c’est mon boulot de me fondre temporairement dans une équipe, je dois laisser de côté ma vision pour coller à celle de l’équipe. Ça ne m’empêche pas de soulever des interrogations ou soumettre des modifications, et une personne ressource accessible et réactive est une aubaine dans ce cas.
À défaut, une bonne documentation des conventions de codage en vigueur dans l’équipe, ça marche aussi, mais c’est moins marrant.

Ressources graphiques

Là, c’est toujours un peu plus délicat.

J’ai travaillé avec plein de graphistes. Je le suis un peu moi-même (j’ai un diplôme qui l’atteste).
J’ai travaillé avec des clampins de cambrousse, des graphistes de classe européenne, ainsi qu’avec des génies de l’animation et du jeux vidéo. Un point commun, juste un seul ?

Les calques et les groupes, on peut leur mettre des noms, alors on va laisser celui par défaut, ou mettre des trucs rien à voir, pasque c’est marrant ET que ça fait chier les intégrateurs et les devs.

C’est comme ça qu’on se retrouve avec des psd dont les calques s’appellent copie de copie de calque 234 ou truc en forme de bite (oui, c’est authentique, et non, je ne citerai pas de noms).

Malheureusement, c’est dur de parler à un graphiste sans le vexer, il faut donc passer par le responsable de projet qui va essayer d’amadouer la bête pour lui faire renommer les calques, et peut-être pondre un p’tit fichier texte où il explique ce qu’il veut.

Pasque les calques masqués, c’est bien beau, mais dans 95% des cas, ils sont justes masqués pasque ça va plus vite que de le supprimer. Du coup, je perds même plus le temps d’afficher/masquer un calque nommé copie de forme 4 pour voir que c’est la version survolée du bouton dont la forme simple est 25 calques plus bas.

Après, faut pas croire, j’adore les graphistes, et c’est souvent un méga-plaisir d’intégrer des trucs de fous, avec des gros défis techniques.

Mais on perd souvent énormément de temps à cause de ressources graphiques non-documentées qui auraient pu (dû?) l’être dès le début, et ça entretien une guéguerre graphistes/devs qui n’aura jamais de gagnant mais dont le perdant est d’abord le client, puis l’ensemble de l’équipe (qu’est-ce que c’est beau !).

Le travail

La plupart du temps, les projets qu’on me donne sont des suites de tâches qui ne dépendent de personne, et donc je travaille seul dans mon coin, généralement à des heures où personne ne m’embête à part mes chats.

Ceci dit, quand le besoin se fait sentir, je synchronise les après-midi avec l’équipe, mais c’est rare, surtout pour un profil hors-site comme le mien.

Les feedback

Avec ou sans accès aux médiums de stockages de l’équipe (j’en parle plus bas), j’ai été formé aux méthodes agiles et j’aime bien travailler sous forme de courts cycles de production/feedback : je réalise quelques tâches, j’envoie le resultat accompagné d’un petit débrief, et laisse l’équipe me faire le feedback nécéssaire pendant que je bosse sur autre chose.

Cette méthode demande parfois un peu plus de travail à l’équipe, mais c’est celle qui donne les meilleurs résultats (et évite au maximum le “ah mais t’as rien compris“ sur un projet en rush).
L’important, c’est la réactivité.

Toutefois, il est important que les feedbacks soient donnés de manière groupée : j’ai de temps en temps eu des feedbacks par 3 ou 4 personnes ressources différentes, qui se contredisaient, se mordaient le nez et leurs principes, pour finir en échange de mails sous forme de lutte de pouvoir.
Et ça, non seulement c’est chiant, mais en plus ça ne me concerne pas (et je m’en tamponne l’oreille avec une babouche).
C’est pourquoi j’aime bien avoir un seul interlocuteur, quitte à ce qu’il parle au nom de ou condense les propos de plusieurs personnes.

Les meilleurs feedbacks se font par mail, pasque ça peut être lu suffisament de fois pour être bien compris, et se complètent ensuite par téléphone.

Le client final

En tant que sous-traitant, j’ai rarement accès au client final. La plupart du temps pasque les agences communiquent rarement sur leurs pratiques de sous-traitance.

Personnellement, ça me va : je suis pas très bancable auprès du client, avec mon look d’ado attardé bloqué dans sa phase “14 ans & rebelle” (bermuda-piercings-tatouages), et surtout, je n’ai pas la bonne approche : quand un client me dit blanc et que je sais que d’un point de vue technique, ce sera noir pasque c’est comme ça, je le sais, c’est mon métier, ben moi, ça ne me vient pas à l’idée de dire gris. Je dis noir et c’est tout.
Du coup, je préfère ne jamais avoir affaire au client final.

Ça m’est arrivé deux fois et les deux fois, ça n’a causé que des emmerdes : la première pasque ça court-circuitait l’agence et que des infos se perdaient, et la seconde pasque le client était plus content de mes prestations que de celles de l’agence et que je me retrouvait dans une très sale position.

Bref, les clients finaux, pour un sous-traitant, c’est comme les vieilles tantines : on est bien content de savoir qu’elles sont en vie, on est content de voir une photo de temps en temps, mais on se sent mieux en sachant qu’elles habitent à l’autre bout du pays et qu’on les voit jamais (en plus, elles font des bisoux qui piquent et elles pincent les joues, si, si tu sais ce que c’est).

Et donc, là où j’voulais en venir, c’est que comme j’ai pas accès au client final, c’est à l’équipe qu’il incombe (je rêvais d’utiliser ce verbe) de tenir le sous-traitant le plus au courant possible.

Les mediums

Quand le projet et/ou la structure de l’équipe le permet, je préfère avoir accès aux médiums de stockage du projet, généralement le repo svn, git ou mercurial.
Ça facilite les livraisons intermédiaires, les mises à jour des ressources par l’équipe en place, et, surtout, la pérénité de mon travail au sein de l’équipe en cas de crash de mon côté (on est jamais trop parano).

Si je n’ai pas accès à ces médiums, je stocke mes données sur un repo perso, un par client (on est toujours jamais trop parano), et je fais les livraisons via des archives zip.

La livraison

La livraison finale est l’occasion d’envoyer ma facture, qui certifie, d’une certaine façon, que le travail pour lequel on m’a mandaté est terminé.

Pour ma part, ça ne m’empêche pas de faire des corrections ou du debug si besoin, pour peu que ce soit pour du code existant, et non pour rajouter des fonctionnalités (j’suis sympa mais faut pas déconner).

Facturation

Concernant la facturation, on m’a souvent taxé de psychorigide sur ce point, mais c’est important : tout mes clients sont des potes, je travaille pour eux avec plaisir, mais le principe d’un projet est simple : mon rôle, c’est de répondre à un problème, le rôle de l’agence, c’est de me payer pour ce service.
Et donc, je suis très “strict” sur les échéances de facture.
Pasque malheureusement, j’ai trop eu d’excuses du genre :

ouais, mais le client final n’a pas encore payé…

Et ben… c’est pas mon problème.

Ça m’arrive de plus en plus rarement, mais j’aime pas quand ça arrive, de la même manière que quand le client final ne paie pas l’agence, ça ne plait pas à l’agence. Faut juste retenir que le client d’un sous-traitant, c’est l’agence, pas le client final
(après 3 relectures, j’arrive pas à améliorer le précédent paragraphe ; mais quand on le relit plusieurs fois, on comprend vaguement l’idée.)

Je fais le boulot à l’heure (et parfois en rush), on me paie à l’échéance. Ou plus tôt, ça me va aussi ;)

C’est un point important et je veux pas que ce soit mal pris, et je vais détailler la principale raison de ce psychorigidisme juste en-dessous.

Crédits

Je signe mes fichiers de code. Généralement comme suit :

NOM DU PROJET
TYPE DOCUMENT /path/to/document.ext - rôle du document
by leny @ nom de l'agence
started at 0000/00/00

Si l’agence veut virer mon nom, pas de souci. Je ne mets jamais le nom de flatLand! dans les projets en sous-traitance, et je ne mentionne pas les projets sur lesquels j’ai bossé, hors de mon entourage strict (ma femme, mes chats, la figurine de Sheldon Cooper sur mon bureau).
Tout au plus je demande à l’agence l’autorisation de les citer comme client, pasque le name-dropping, c’est important, et que 90% des clients viennent par recommandation.

Comme je le disais, l’absence totale de crédit est la raison de mon intransigence psychorigide sur le paiement de mes prestations : puisque je fais un travail de tueur à gages secret, on me paie comme un tueur à gages secret (en espèces non-marquées, dans un attaché-case sobre déposé en consigne 23b à la gare de Liers, à 01h les vendredi).

Suivi du projet

Je suis assez open pour répondre à des questions sur des projets récents, mais comme mon boulot est de sauter de projets en projets pour des équipes différentes, le tout ajouté à une mémoire un peu chaotique, j’ai une durée de vie en support de projet qui dépasse rarement les 6 mois.

C’est pour ça que j’inclus un debrief lors des livraisons, à l’origine sur demande d’une très grosse agence (en terme de personnel), qui voulait garder une trace “humaine” de mon point de vue sur le travail et le projet pour y revenir facilement plus tard le cas échéant.
J’ai trouvé l’idée intéressante et utile, donc je perpétue la pratique comme une tradition.

Postambule

Voilà, en gros, ma procédure de travail en sous-traitance.
Je bosse comme ça depuis 2 ans et demie, au début comme indépendant complémentaire, puis depuis cette année comme indépendant à titre principal.

Je ne suis probablement pas l’archétype du freelance, mais ma manière de travailler et mes exigences de vraie fausse diva me permettent de faire du bon travail et de m’amuser en le faisant.

Ouah, ça, c’était une belle phrase de fin bien pathos, je la garde.