Comment étalonner et structurer la rémunération des développeurs

La plupart des entreprises décident de la paie des développeurs à l’envers. Elles choisissent un chiffre qui semble abordable, publient le poste, puis découvrent l’opinion du marché une offre refusée à la fois. La solution n’est pas de payer plus partout. C’est d’avoir un système : des références auxquelles vous faites confiance, des échelles que vous pouvez défendre, une politique écrite pour le télétravail et le lieu de résidence, et des règles pour les augmentations et les contre-offres décidées avant que la pression monte. Ce guide présente ce système.

Choisissez des sources d’étalonnage que vous pouvez défendre

Il n’existe pas de chiffre unique et vrai pour ce que coûte un développeur back-end sénior. Il existe plusieurs signaux bruités, et votre travail consiste à trianguler.

Utilisez trois types de sources ensemble :

1. Des données de marché larges. Sites participatifs de niveaux et de rémunération, plateformes de rémunération et grandes enquêtes salariales annuelles. Ces données penchent vers les grandes entreprises et les répondants qui s’autosélectionnent : traitez-les comme la limite optimiste du marché plutôt que comme la médiane.
2. Votre propre pipeline. Les attentes, les acceptations et les refus de vos dix dernières conversations avec des développeurs constituent la référence locale la plus honnête que vous ayez. Notez l’attente salariale de chaque candidat, même ceux que vous ne poursuivez pas.
3. Les affichages de poste avec fourchettes publiées. Les règles de transparence salariale font que beaucoup d’affichages contiennent maintenant de vrais chiffres. Relevez les fourchettes de dix affichages qui correspondent à votre poste, au niveau et à la région, et vous obtenez un jeu de données gratuit et à jour.

Des règles de lecture pour rester honnête : notez toujours le percentile que vous regardez (un chiffre du 90e percentile cité comme « le taux du marché » empoisonne tout l’exercice), appariez sur le niveau d’expérience et non sur le titre (le sénior d’une entreprise est l’intermédiaire d’une autre), et appariez sur la région et la politique de télétravail, puisque les chiffres d’une entreprise entièrement à distance ne se transposent pas à un poste en présentiel dans une ville de taille moyenne.

À titre d’orientation approximative, un développeur full-stack sénior sur un marché nord-américain se situe souvent quelque part dans les six chiffres, dans la portion basse à moyenne, en devise locale, avec une forte variance selon la ville, le stade de l’entreprise et la spécialité. Traitez toute estimation ponctuelle que vous lisez (y compris celle-ci) comme une hypothèse de départ, pas comme une réponse.

Bâtissez des échelles par niveau, pas par négociation

Une échelle salariale est une fourchette à laquelle vous vous engagez pour un niveau avant qu’un candidat soit dans la pièce. Si deux développeurs qui font le même travail au même niveau gagnent des salaires très différents parce que l’un a négocié plus fort, vous n’avez pas d’échelles. Vous avez un registre de négociations.

Une structure qui fonctionne pour la plupart des équipes :

• Définissez 4 à 6 niveaux, du junior jusqu’au staff ou principal, chacun décrit par sa portée : exécute des tâches définies, est responsable de fonctionnalités, est responsable de systèmes, donne la direction à travers plusieurs équipes. Les définitions de portée comptent plus que les chiffres, parce que ce sont elles que vous montrez quand quelqu’un demande pourquoi il est à son niveau.
• Donnez à chaque échelle un écart d’environ 20 à 30 pour cent du bas au haut. Le bas de l’échelle correspond à une bonne recrue à ce niveau, le haut à quelqu’un sur le point d’être promu.
• Faites chevaucher les échelles adjacentes volontairement. Un sénior en haut de son échelle devrait pouvoir gagner plus qu’un staff en bas de la sienne. Cela élimine la pression de promouvoir des gens dans une portée qu’ils ne maîtrisent pas juste pour leur donner une augmentation.
• Choisissez délibérément votre position sur le marché. Payer au 50e percentile avec de bonnes actions et une vraie autonomie est une stratégie cohérente. Payer au 75e avec peu d’actions aussi. Payer « de façon concurrentielle » sans définir concurrentiel n’est pas une stratégie, c’est une humeur.

Mettez les échelles par écrit, même dans une entreprise de cinq personnes. Le document force les débats à se tenir une seule fois, dans l’abstrait, plutôt qu’à chaque offre.

Structurez le mélange : base, prime, actions

Le mélange compte autant que le total, et les développeurs y lisent un signal sur le type d’entreprise que vous êtes.

Le salaire de base porte la charge. Les développeurs, surtout les séniors, escomptent tout le reste. Une erreur fréquente consiste à offrir une base sous l’échelle « compensée » par une prime cible. Les candidats ramènent cette offre à la base seule, la comparent à l’offre concurrente plus riche en base, et vous perdez.

Les primes en argent fonctionnent quand elles sont simples et crédibles. Une prime annuelle modeste liée à la performance de l’entreprise, ça va. Les formules élaborées de performance individuelle pour les développeurs tendent à récompenser le comptage de billets et causent habituellement plus de trouble que l’argent qu’elles orientent. Si votre prime a besoin d’un chiffrier pour être expliquée, intégrez-en la majeure partie à la base.

Les actions dépendent entièrement du stade de l’entreprise. Dans une jeune pousse en démarrage, les options sont un vrai pari et devraient être dimensionnées comme tel : des octrois en pourcentage significatifs qui pourraient compter, offerts avec un discours honnête sur la dilution et les probabilités. Dans une entreprise à un stade avancé ou privée sans horizon de sortie, méfiez-vous de présenter les actions comme de la rémunération s’il n’existe aucun chemin plausible vers la liquidité. Les candidats d’expérience évalueront ce papier illiquide près de zéro, et prétendre le contraire vous coûte votre crédibilité sur tout le reste de l’offre.

Une règle de décision utile : pour chaque composante, demandez-vous « est-ce qu’un ingénieur sénior sceptique compterait ceci comme de l’argent? » Si la réponse honnête est non, cette composante appartient au récit sur le potentiel, pas à la comparaison de rémunération.

Écrivez votre politique de télétravail et de lieu avant votre première embauche à distance

Il existe trois politiques défendables de rémunération à distance :

1. La paie selon le lieu. Vous payez le taux du marché là où l’employé habite. La moins coûteuse et défendable sur le plan du coût de la main-d’oeuvre, mais elle crée des écarts visibles entre collègues qui font un travail identique, et elle transforme un déménagement en négociation salariale.
2. Le taux national. Un taux par pays par niveau, peu importe la ville. Une bonne voie mitoyenne : simple à administrer, elle élimine l’argument d’équité à l’intérieur du pays et ne coûte que modestement plus cher que la paie par ville.
3. Le taux mondial ou unique. Un taux pour le poste, partout où vous embauchez. Le plus simple et le meilleur pour l’équité, le plus coûteux, et surtout utilisé par les entreprises qui se disputent directement les mêmes talents séniors que les grandes firmes entièrement à distance.

Chacune des trois peut fonctionner. Ce qui échoue, c’est l’absence de politique : des décisions improvisées à chaque embauche qui finissent par se savoir (elles se savent toujours) et qui ne peuvent pas être défendues quand ça arrive. Choisissez-en une, écrivez comment les déménagements sont traités, et appliquez-la sans exceptions. Les exceptions sont tout l’enjeu : une seule exception visible transforme votre politique en rumeur.

Comparez la rémunération globale, pas la base, et amenez les candidats à faire de même

Quand vous vous étalonnez ou quand un candidat pèse votre offre contre une autre, la comparaison base contre base induit en erreur dans les deux sens.

Bâtissez une vue annuelle simple de la rémunération globale pour votre propre offre et mettez-la dans la lettre d’offre : base, prime attendue à la cible, valeur annualisée des actions avec vos hypothèses énoncées, et valeur en argent des avantages inhabituels (un vrai budget de perfectionnement professionnel, une cotisation de retraite au-dessus de la norme, une assurance santé étendue dans les marchés où ce n’est pas la norme). Ne la gonflez pas avec des choses comme « collations gratuites » ou des économies théoriques d’espace de bureau : gonfler le chiffre apprend aux candidats à s’en méfier au complet.

Puis soyez honnête sur l’escompte. Un dollar de base vaut un dollar. Un dollar de prime cible vaut un peu moins. Un dollar d’actions d’entreprise privée vaut beaucoup moins, et combien moins dépend du stade et des conditions. Si votre offre ne gagne que lorsque les actions sont comptées à leur pleine valeur, vous ne gagnez pas les candidats que vous voulez, parce que les bons font exactement ce calcul.

Gérez les augmentations comme un cycle, pas comme une série d’embuscades

Les augmentations au cas par cas récompensent les personnes les plus à l’aise de demander, ce qui correspond mal aux personnes qui contribuent le plus. L’alternative est ennuyante et elle fonctionne :

• Une ou deux révisions salariales planifiées par année. Tout le monde est révisé, personne n’a à demander.
• Rafraîchissez vos références avant chaque cycle, pas une seule fois à la fondation. Les marchés de développeurs bougent vite dans les deux sens, et des échelles fixées il y a deux ans relèvent de la fiction.
• La position dans l’échelle suit la performance et la portée, et le gestionnaire peut expliquer la position de chaque personne en une phrase.
• Les promotions changent d’échelle et se décident sur une portée déjà démontrée, pas sur une portée espérée.

Budgétez aussi explicitement les corrections de marché : quand le marché bouge plus vite que votre budget au mérite, corriger l’écart pour vos meilleurs éléments en cours de cycle coûte beaucoup moins cher que les remplacer. Une vérification utile avant chaque cycle : « si cette personne démissionnait demain, qu’offririons-nous à sa remplaçante? » Si ce chiffre dépasse nettement sa paie actuelle, vous venez de trouver le prochain poste du budget de correction.

Décidez votre politique de contre-offre à l’avance

Les contre-offres se décident dans les pires conditions possibles : la surprise, la pression du temps et la douleur immédiate d’un départ. Décidez donc de la politique maintenant, pendant que personne ne démissionne.

L’argument honnête contre les contre-offres : le chiffre n’a jamais été toute la raison. Au moment où quelqu’un a passé des entrevues, obtenu une offre et remis sa démission, il est déjà parti une fois dans sa tête. Une contre-offre qui ne corrige que la paie laisse intact le problème de portée, de gestionnaire ou de trajectoire, et vous avez enseigné au reste de l’équipe que le chemin vers une augmentation passe par une offre concurrente.

L’argument étroit en leur faveur : parfois le marché a vraiment bougé, la personne veut vraiment rester, et l’écart n’est vraiment qu’une question d’argent. Si c’est vrai, c’était vrai le mois dernier aussi. D’où la vraie politique : faites la correction avant la démission. Révisez vos personnes clés contre le marché actuel à chaque cycle et corrigez les écarts de façon proactive. Les entreprises qui le font affrontent rarement des décisions de contre-offre, parce que l’offre que leurs gens obtiendraient ailleurs n’est pas une surprise.

Si vous contrez, contrez une fois, par écrit, avec tout changement de portée ou de titre inclus, et considérez une deuxième démission dans l’année comme définitive.

Mettez le chiffre dans l’affichage de poste

Après tout ce travail, servez-vous-en. Publiez l’échelle dans la description de poste. Afficher une fourchette vous amène plus de candidatures séniors (qui postulent rarement à l’aveugle), filtre les incompatibilités avant que quiconque passe une heure en entrevue, et devient de toute façon une exigence légale dans un nombre croissant de juridictions. À l’interne, des échelles transparentes transforment la rémunération d’un secret individuel en un système dans lequel les gens peuvent se situer. Vous n’avez pas à publier le salaire de chacun pour obtenir l’essentiel du bénéfice : publier la structure suffit.

Le raccourci

Tout ce qui précède s’applique encore si vous embauchez par l’entremise d’un réseau, mais la partie la plus difficile devient plus facile. Les erreurs de rémunération les plus coûteuses viennent d’un étalonnage à l’aveugle : trois mois d’entrevues avant de découvrir que votre fourchette est 20 pour cent sous le marché, ou une offre bâtie sur des données périmées qui se fait refuser sans contre-proposition. Un réseau de talents vérifiés comme turnkey.dev comprime cette phase de découverte, parce que les candidats arrivent avec des attentes de taux déjà connues et déjà validées contre le marché. Vos échelles cessent d’être une hypothèse testée une offre refusée à la fois et deviennent une vérification de cohérence contre des chiffres réels. Utilisez ce guide pour bâtir la structure dans tous les cas. Si vous voulez sauter la phase d’étalonnage à l’aveugle pour votre prochaine embauche de développeur, dites-nous le poste et nous vous montrerons des candidats vérifiés avec leurs attentes déjà en main.