30 jours à chercher une mission Go — les 6 étapes qui ont fait décoller mon TJM

J’ai passé un mois à chercher une mission Go en cherchant mal. Je répondais à des annonces, j’envoyais un CV qui listait des technologies, et je discutais TJM en fin d’entretien face à quelqu’un qui avait déjà une grille en tête. Les propositions tournaient toutes autour du même chiffre, et ce chiffre me paraissait bas.

Ce qui a changé les choses n’est pas une technique de négociation. C’est d’avoir compris que le taux se joue bien avant la discussion sur le taux : il se joue au moment où l’on choisit à quelles missions on répond. Voici les six étapes dans l’ordre, avec ce que chacune produit concrètement.

Étape 1 — Cibler les contextes où Go est structurant

Toutes les missions Go ne se valent pas, et l’écart de rémunération entre elles n’a presque rien à voir avec le langage.

Il y a d’un côté les missions où Go est un choix de confort : l’équipe l’a adopté parce qu’elle aime la syntaxe, et le travail consiste à produire des services applicatifs classiques. Le langage y est interchangeable, et la mission se paie comme du développement backend courant.

De l’autre, il y a les contextes où Go a été choisi pour une raison précise : un service qui doit tenir des dizaines de milliers de connexions simultanées, une passerelle où la latence se mesure en millisecondes, une brique d’infrastructure dont le coût de calcul est un poste budgétaire. Là, on ne cherche pas « un développeur Go » mais quelqu’un capable de raisonner sur la concurrence, la gestion mémoire et l’observabilité. Le vivier est plus étroit, et les taux le reflètent.

Ce que ça change en pratique : lisez les annonces en cherchant le pourquoi du langage. Une annonce qui dit « stack Go, Kubernetes, gRPC » sans jamais expliquer la contrainte est probablement une mission de la première catégorie. Une annonce qui mentionne un volume, une latence cible ou un problème de coût d’infrastructure appartient à la seconde. J’ai divisé par trois le nombre de candidatures et doublé le taux de réponse utile.

Étape 2 — Construire une preuve technique lisible en 5 minutes

Le CV d’un développeur Go ressemble à tous les autres CV de développeurs Go. Ce qui distingue, c’est un morceau de code que quelqu’un peut lire vite et qui montre comment vous pensez.

Ce qui fonctionne : un dépôt petit et fini. Un service unique, quelques centaines de lignes, avec des tests, une gestion d’erreurs explicite, un arrêt propre, et un fichier de présentation qui explique le problème résolu et les arbitrages retenus. La partie qui impressionne réellement n’est pas le code : c’est la section « ce que je n’ai pas fait et pourquoi ».

Ce qui ne fonctionne pas : un dépôt de mille fichiers commencé il y a trois ans, ou une collection d’exercices d’algorithmie. Personne ne les lit. Le lecteur dispose de cinq minutes entre deux réunions.

Si vous êtes soumis à une clause de confidentialité sur tout ce que vous avez produit — la situation la plus courante — reconstruisez une version réduite et anonymisée du problème. Ce n’est pas de la triche, c’est une démonstration.

Étape 3 — Réécrire son profil autour du problème résolu

La plupart des profils freelance décrivent des tâches : « développement de microservices en Go, mise en place de CI/CD, revue de code ». C’est exact et parfaitement interchangeable.

La formulation qui change tout décrit un problème, une action et un résultat mesuré. « Reprise d’une passerelle de paiement qui saturait à 400 requêtes par seconde ; refonte du traitement concurrent et du pool de connexions ; passage à 3 000 requêtes par seconde sur le même matériel. » Une seule ligne de ce type vaut une page de liste de technologies.

Deux règles pour que ce soit crédible. Donnez des chiffres, même approximatifs, même sans nommer le client. Et gardez la trace de ce qui n’a pas marché : en entretien, la question « qu’est-ce que vous referiez autrement ? » sépare immédiatement ceux qui ont vécu le projet de ceux qui le racontent.

Si vous construisez une activité autour de ce positionnement, notre guide sur la création d’une plateforme freelance détaille les mécanismes côté demande — comprendre comment les missions sont qualifiées en amont aide beaucoup à se positionner.

Étape 4 — Travailler trois canaux en parallèle

Un seul canal produit un flux irrégulier et une position de négociation faible. Trois canaux, travaillés en même temps, changent la dynamique — parce que la meilleure façon de négocier est d’avoir une alternative réelle.

Les intermédiaires et plateformes. C’est le volume, et c’est ce qui remplit un calendrier vide rapidement. La marge est réelle et le contexte est filtré par un tiers, mais ne les méprisez pas : ils financent le temps nécessaire pour construire les deux autres canaux.

Le réseau direct. Anciens collègues, anciens clients, personnes croisées en conférence. C’est le canal qui produit les meilleures missions et les meilleurs taux, parce que la confiance est déjà là et que personne ne prend de marge. Il demande un entretien régulier et un peu de patience.

La visibilité technique. Écrire sur un problème précis que vous avez résolu, publier le dépôt de l’étape 2, répondre sérieusement dans les espaces où vos futurs clients lisent. C’est le canal le plus lent — comptez plusieurs mois — et le seul qui finit par produire des demandes entrantes, c’est-à-dire des discussions où vous n’êtes pas en position de demandeur.

Étape 5 — Qualifier la mission avant de parler prix

C’est l’étape qui fait la différence, et celle que presque personne ne fait. Avant toute discussion tarifaire, il faut comprendre ce que la mission résout. Cinq questions suffisent, posées naturellement lors du premier échange.

Pourquoi Go sur ce projet ? La réponse vous dit immédiatement dans lequel des deux marchés de l’étape 1 vous vous trouvez.

Que se passe-t-il si ce service s’arrête une heure ? C’est la question la plus utile de toute la liste. La réponse chiffre le problème à votre place, et c’est votre client qui l’énonce.

Qui maintient ce code aujourd’hui, et depuis quand ? Une équipe partie il y a six mois signifie une reprise sans transmission — plus risqué, donc plus cher, et il faut le dire tout de suite.

Quelle est la durée envisagée et le critère de réussite ? Une mission sans critère de fin explicite dérive, et une dérive non cadrée se paie toujours du côté du prestataire.

Qui décide techniquement ? Si la réponse est floue, prévoyez du temps de réunion non facturé — ou facturez-le explicitement.

Ces questions produisent deux effets. Elles vous donnent la matière de la négociation. Et elles vous positionnent comme quelqu’un qui cherche à résoudre un problème, pas à vendre des jours — ce qui, seul, déplace déjà la discussion.

Étape 6 — Négocier le TJM sur la valeur, pas sur la grille

Un taux journalier annoncé sans contexte se compare mécaniquement à une grille interne. La seule façon d’en sortir est de le rattacher à ce qui a été dit à l’étape 5.

Concrètement : « vous m’avez indiqué qu’une heure d’indisponibilité coûte environ tel montant, et que l’équipe qui connaissait ce service est partie. Mon taux est de X. Sur une mission de trois mois, l’écart avec un profil moins cher représente quelques milliers d’euros — à comparer au coût d’un seul incident mal traité. » Ce n’est pas une astuce rhétorique : c’est un raisonnement que votre interlocuteur peut défendre en interne, ce qui est exactement ce dont il a besoin.

Trois règles que je m’applique. Annoncer un chiffre net et s’arrêter de parler — le silence qui suit est inconfortable et c’est précisément son utilité. Ne jamais baisser un taux sans retirer quelque chose du périmètre, sous peine d’enseigner que le premier prix était fantaisiste. Et accepter de perdre certaines missions : un taux qui passe systématiquement est un taux trop bas.

Sur la durée plutôt que sur le taux. Quand le budget est vraiment bloqué, négociez autre chose : un engagement de trois mois plutôt qu’un mois renouvelable, un rythme à quatre jours par semaine, une clause de revalorisation au renouvellement. Ces contreparties ne sortent pas de la même ligne budgétaire et se débloquent souvent plus facilement qu’une hausse de taux.

Ce que 30 jours m’ont appris

Le premier mois, j’ai envoyé beaucoup de candidatures et obtenu des propositions convergentes vers un même chiffre médiocre. Le mois suivant, j’en ai envoyé trois fois moins, en ne répondant qu’aux annonces qui expliquaient pourquoi le langage avait été choisi, et en posant systématiquement les cinq questions de l’étape 5 avant d’annoncer quoi que ce soit.

L’écart ne vient pas d’une meilleure argumentation en fin d’entretien. Il vient du fait que je ne parlais plus aux mêmes personnes. C’est la leçon que je retiendrais si je ne devais en garder qu’une : le TJM est une conséquence du ciblage, pas de la négociation.

Un dernier point, souvent négligé : la sécurité et la conformité sont devenues des sujets de qualification côté client. Savoir répondre calmement à une question sur la gestion des secrets ou la traçabilité des accès rassure, et nos confrères de WebGuard Agency constatent que ces exigences descendent désormais jusque dans les contrats de prestation individuels. Anticipez-les plutôt que de les découvrir à la signature.

Questions fréquentes

Quel TJM viser pour une mission Go en France ?

La fourchette dépend beaucoup plus du contexte que de l’ancienneté. Une mission de développement applicatif dans une équipe déjà structurée se situe dans la moyenne du backend expérimenté. Une mission où l’on attend de vous des choix d’architecture sur des systèmes concurrents, de l’optimisation mémoire ou de la reprise d’un service critique se négocie sensiblement au-dessus, parce que le remplaçant est difficile à trouver. Le bon réflexe n’est pas de chercher un chiffre de référence sur un baromètre, mais de qualifier la criticité et la rareté avant d’annoncer quoi que ce soit.

Faut-il un profil senior pour décrocher une mission Go ?

Pas nécessairement senior en Go, mais solide sur les systèmes. Beaucoup d’équipes acceptent un profil qui vient de Java, C# ou Rust dès lors qu’il maîtrise la concurrence, les entrées-sorties et l’observabilité, parce que la syntaxe de Go s’acquiert en quelques semaines alors que le raisonnement sur les systèmes distribués prend des années. Ce qui bloque réellement une candidature, c’est l’absence de preuve : un profil qui annonce Go sans aucun code lisible ni contexte de production concret passe difficilement le premier filtre.

Vaut-il mieux passer par une plateforme ou en direct ?

Les deux, mais pas pour les mêmes missions. Les plateformes et les intermédiaires donnent du volume et remplissent un calendrier rapidement, au prix d’une marge et d’une moindre maîtrise du contexte. Le direct paie mieux et donne de meilleures missions, mais il demande un travail de visibilité qui met des mois à produire ses effets. La configuration la plus stable consiste à remplir le calendrier via les intermédiaires pendant qu’on construit le canal direct, puis à basculer progressivement quand celui-ci commence à générer des demandes entrantes.

Comment justifier un TJM plus élevé sans perdre le client ?

En déplaçant la discussion du taux vers le coût du problème. Un taux journalier ne veut rien dire seul : il se compare au coût d’un incident, au retard d’une mise en production, ou au temps qu’une équipe interne passerait à monter en compétence. Formulé ainsi, un écart de cent euros par jour devient marginal face à ce qui est en jeu. La condition est d’avoir qualifié la mission avant, à l’étape 5 : sans compréhension du contexte, cette argumentation sonne creux et se retourne contre vous.