9 December 20257 min de lecture
La qualité des personnes qu’on vous propose se joue en grande partie avant toute proposition, par le brief que vous avez envoyé. Envoyez deux paragraphes demandant un développeur full-stack expérimenté et vous recevrez qui se trouve actuellement non affecté, décrit dans le vocabulaire de vos deux paragraphes. Ce n’est généralement pas du cynisme de la part du prestataire. C’est que vous ne lui avez rien donné à quoi comparer.
Un bon brief n’est pas plus long. Il est de nature différente d’une description de poste, et il demande environ quatre-vingt-dix minutes à rédiger, une fois pour toutes.
Un brief n’est pas une fiche de poste
Une description de poste est écrite pour attirer : elle décrit donc l’entreprise, la mission et les avantages, et garde les exigences assez larges pour ne dissuader personne. Un brief est écrit pour apparier : il décrit donc le travail avec assez de détail pour qu’un prestataire puisse écarter des candidats.
Le test consiste à savoir si votre document permettrait de rejeter un candidat. Si tout ingénieur ayant la bonne pile sur son CV passe, c’est une annonce d’emploi, et elle produira une liste constituée par disponibilité.
Ce qu’il faut y mettre
- Les quatre-vingt-dix premiers jours de travail, concrètement : les tickets ou projets réels, pas la mission au sens large
- La pile technique telle qu’elle est réellement, y compris les parties qui vous gênent et les versions sur lesquelles vous avez du retard
- Avec qui ils travaillent au quotidien, qui relit leur production, et qui les débloque
- Ce qu’ils décident seuls et ce qui nécessite une validation, car c’est cela qu’un niveau d’expérience veut dire en pratique
- Les heures de chevauchement dont vous avez besoin et ce qui s’y passe : stand-up, binômes, délai de retour en revue
- Comment vous jugerez, à quatre-vingt-dix jours, si cela a fonctionné
La dernière change la conversation plus que toute autre ligne. Les prestataires qui la lisent proposent soit quelqu’un de plausible au regard de celle-ci, soit commencent à négocier la définition, et les deux réactions sont instructives.
Dites ce qui ne va pas dans votre installation
Tout le monde omet ce point, et c’est le paragraphe le plus précieux du document. Aucun test sur le module de paiement. Un processus de déploiement qui prend quarante minutes et échoue parfois. Un front-end que deux personnes ont réécrit à moitié. Un service non documenté auquel personne ne veut toucher.
L’écrire fait deux choses. Cela permet à un prestataire de proposer quelqu’un qui a déjà traversé cela, ce qui distingue réellement les candidats. Et cela évite la version de l’histoire où une bonne recrue arrive, découvre la réalité en deuxième semaine, et décide discrètement qu’on lui a menti, l’une des causes les plus fréquentes d’un départ précoce.
Décrivez le niveau d’expérience comme un comportement
Le nombre d’années d’expérience est la spécification la plus faible qui soit et celle que tout le monde utilise. Décrivez plutôt ce que la personne doit savoir faire sans aide : prendre une demande vague d’une partie prenante non technique et la transformer en plan, ou venir seule à bout d’une intégration tierce inconnue, ou relire le travail d’un autre et dire non.
Cela compte davantage au-delà d’une frontière que localement, car le soutien informel qui porte un junior, la conversation entendue par hasard, la question rapide posée au voisin de bureau, est précisément ce qui ne survit pas à la distance. Un brief qui dit « expérimenté » vous donne un CV portant le mot « expérimenté ». Un brief qui dit « travaille sans supervision avec une API non documentée » vous donne une conversation sur le fait que le candidat l’ait déjà fait.
La régie et la livraison gérée exigent des briefs différents
Si vous ajoutez des personnes à votre propre équipe, le brief porte sur la personne : les compétences, les horaires de travail, le processus de revue qu’elle rejoindra, et la manière dont elle s’insère dans la forme de votre équipe actuelle.
Si vous confiez un résultat, le brief porte sur le travail : le périmètre, la définition du « terminé », les critères de recette, ce qui est explicitement exclu, et qui répond aux questions de votre côté et sous quel délai. Rédiger le premier quand on vise le second est une manière fiable de finir par gérer une équipe que l’on croyait avoir déléguée, et la déception est en général imputée au prestataire.
Gardez-en un document vivant
Le brief devient le document d’intégration, puis la base de la revue à quatre-vingt-dix jours, puis le point de départ du poste suivant. Gardez-le dans un endroit lisible par les deux parties, mettez-le à jour quand le travail change, et invoquez-le explicitement quand quelque chose sort du périmètre.
C’est aussi la réponse pratique aux litiges de périmètre. Les discussions sur ce qui était inclus sont ingagnables de mémoire et courtes lorsqu’il existe un document, et la version que vous avez écrite avant tout recrutement est la moins intéressée que l’une ou l’autre partie produira.
