Ce article a initialement été rédigé au premier trimestre 2024, il a été mis à jour pour mieux correspondre à sa date de publication.

La question de la transparence des salaires avance en France, avec l'application de la fameuse directive européenne l'été prochain (2026) — et beaucoup de travail pour un paquet de services RH.

C'est que la mesure — même si elle ne va pas jusqu'à une transparence totale — va bouleverser les habitudes de beaucoup d'entreprises. Sans parler des pratiques clairement malveillantes — au recrutement par exemple — des moments inconfortables attendent les managers : les écarts de salaire historiques vont devenir injustifiables, les grilles de compétences et de salaires vont se multiplier, etc.

Mais cette phase inconfortable sera suivie d'un soulagement — si tant est que les entreprises jouent le jeu. La transparence salariale n'a que des effets bénéfiques pour l'organisation, et peut parfaitement s'accorder avec une considération de performance.

Un lissage des salaires est fatalement à prévoir, surtout dans les entreprises les plus opaques, mais il n'y a aucune fatalité à tomber dans un système "égalitaire" qui nierait les écarts de performance et pourrait faire fuir les talents.

Dans le premier chapitre je vous décrivais notre précédent système de rémunération, ses avantages et ses limites. Malgré tous ses avantages, c'est un système qui scale mal, et qui restait un peu trop subjectif pour être parfaitement en accord avec la nouvelle réglementation qui arrive.

Le troisième et dernier billet de cette série présentera le système final, (partiellement) utilisé actuellement chez Lonestone. Mais avant de vous en parler, je voulais faire un petit crochet pour suivre une piste qui m'a intrigué, et qui m'a fait perdre pas mal de temps : celle d'une rémunération basée sur un jugement quasi mathématique des compétences de chacun·e.

L'approche

L'idée est séduisante, car elle permet et théorie d'effacer toute subjectivité (managériale) de la rémunération des collaborateurs, qui serait entièrement liée à leur valeur pour l'entreprise, décideuse des critères et des compétences les plus critiques pour sa réussite.

Sur le papier, la mécanique est simple : on — comprendre, un mélange de personnel RH et de C-levels — liste les compétences clés pour le succès de l'entreprise (pour chaque poste), en prenant garde de ne pas se limiter aux hard skills, et on juge le niveau des collaboratrices sur ces compétences.

Avec des compétences correctement choisies, et avec assez de granularité, on peut alors jauger l'apport de chacun·e à la valeur de l'entreprise.

L'approche peut sembler naïve, mais sa simplicité apparente la rend intéressante. On se doute bien qu'objectiver les compétences, et différents niveaux pour chacune, risque d'être un casse tête. Mais avec assez de données et de temps, c'est un objectif réalisable (ou pas).

D'autant que je préfère une première version imparfaite et améliorable rapidement qu'un projet qui reste dans les cartons, et ayant entendu parler d'entreprises utilisant ce système de "matrices de compétences", je me suis lancé dans l'aventure.

Malheureusement, le chemin vers un MVP fut plus long que prévu.

Définir les compétences

Au départ tout roule : on crée une série de matrice de compétences, une par grand "métier" de l'entreprise. Chez Lonestone ça va vite : avec une grille pour les développeurs·euses et une pour les designer·euses, on a couvert 90% de la masse salariale. Pratique !

Cette matrice prend généralement la forme d'un tableau où chaque colonne représente un domaine "large", et les cases représentent une compétence précise.

Mais derrière cette version simplifiée, on a besoin de plus de détails : pour assurer l'objectivité, chaque case doit être explicite, afin que tous les collaborateurs parlent le même langage.

Prenons les compétences techniques – les hard skills – d'un développeur fullstack. À priori les plus simples à lister et à mesurer (ou pas).

On commence donc notre (longue) énumération : Algorithmie, optimisation, architure SI, sécurité, devops, écriture de documentation, expertise SEO et analytics, considération performances front, testing frontend, accessibilité, intégration (html et CSS), architecture système, state management, graphQL, database design...

Aïe, c'est que ça commence à en faire, des compétences !

Allez, admettons, tout ça semble pertinent. Au bout de longues semaines d'inévitables débats on a enfin des grilles de compétences complètes.

Maintenant il va falloir placer vos collaborateurs dessus.

Valider les compétences

Face à chaque compétence on va donc devoir placer un niveau, généralement sur une échelle de 1 à 5 :

Des niveaux assez précis pour être utilisables, mais assez flous pour s'adapter à n'importe quelle compétence. Sur le papier, ça a l'air plutôt élégant et fonctionnel.

Du moins tant que personne n'a besoin de s'en servir.

Car à présent, il va falloir décider qui "valide" les compétences de collaborateurs, et comment. En général, c'est soit :

1. Les collaborateurs eux même ;
2. Soit le management (direct manager ou un comité) ;
3. Soit un ensemble de pairs ;

Privilégier la simplicité

Laisser à chacun la liberté de se placer sur la matrice est la solution la plus simple et qui scale le mieux.

Sauf qu'on est tous mauvais pour juger de nos compétences. Ce qui est problématique quand il s'agit de mettre en place un outil destiné à décider des salaires dans l'entreprise.

Une solution serait de multiplier les guidelines, car celles présentées un peu plus haut ne sont absolument pas suffisantes : pour chaque niveau de chaque compétence, mettre des objectifs et des exemples très concrets.

Exemple de ce que ça pourrait donner pour la compétence "Recrutement" :

🎯 Faire passer un entretien, connaitre et améliorer les méthodos, vision stratégique

• Débutant - Je sais comment faire
  • Je sais qui est en charge du recrutement
  • Je connais et pourrait expliquer les différentes étapes du recrutement chez Lonestone
  • Je connais les templates des entretiens
  • J’ai aidé à l’élaboration d’un template d’entretien ou autre support, sans être la personne en charge
  • j’ai participé à quelques entretiens d’introduction ou technique (en tant que recruteur) sans être en charge
• Autonome - Je sais faire
  • J’ai été en charge de l’élaboration d’au moins un template ou autre support, et j’ai analysé son efficacité
  • j’ai fait passer des entretiens en autonomie, en rendant un rapport clair aidant à la décision
• Confirmé - Je maitrise et suis à l’aise
  • J’ai une vue d’ensemble sur les différents templates d’entretiens, leurs forces et faiblesses
  • J’ai déjà géré plus 5 entretiens en autonomie avec des profils techniques différents
  • Je sais diriger un entretien en sélectionnant les bonnes questions en fonction du profil
  • Je suis capable de d’ordonner des candidatures en sortie d’entretiens, et de participer à la décision finale
• Expert - Je suis en mesure de faire évoluer cette compétence
  • J’ai déjà géré plus de 10 entretiens en autonomie, avec différentes postes
  • J’ai du recul sur les processus de recrutement (pas uniquement chez Lonestone, mais de l’état de l’art). Je peux analyser et challenger les méthodos pour les améliorer, je participe à l’amélioration continue de nos méthodes
  • J’ai une vision des besoins de la société et sait positionner un.e candidat.e sur cette échelle, et pas uniquement sur ses compétences propres

C'est un travail qui devient très chronophage, sans garantie d'efficacité. Et c'est pire pour les hard skills : comment définir des degrés de connaissance objectifs pour une compétence comme le CSS ?

Privilégier l'objectivité

Pour garantir plus d'objectivité, on va généralement mettre à contribution les "managers".

Mais, si ils peuvent juger de la certain des softskills, ou même du "delivery", ils sont souvent désarmés pour justifier l'évolution de hardskills (et c'est normal).

Et faut-il encore que votre entreprise dispose d'une organisation où chacun·e dispose d'un·e manager direct·e ! Ce qui n'est pas le cas chez Lonestone.

Les pairs semblent donc plus adaptés, mais on se heurte à d'autres problèmes : la disponibilité et le manque de contexte/données.

C'est bien simple : sans travailler au quotidien avec l'autre collaborateur, impossible d'avoir assez d'informations pour juger d'une évolution lorsque les compétences sont aussi précises.

L'autre problème, c'est qu'avec une grille aussi longue, le temps passé à valider les compétences des autres augmente drastiquement, au risque de bâcler le travail.

Enfin, il se trouve que juger objectivement les autres — collègues ou n-1 — va nécessiter le même travail de découpage des niveaux que pour l'auto-notation.

Au final, en plus de prendre un temps fou à l'équipe, cela va vous prendre un temps monstre d'écrire et maintenir la documentation. L'élégance initiale du système est en train de prendre du plomb dans l'aile.

Calculer le salaire

Imaginons que les problèmes précédents soient résolus, parce que vous disposez d'un service RH hyper compétent ou d'un middle management très bien formé. On dispose alors de matrices valides, et de processus permettant de comparer les collaborateurs les uns par rapport aux autres.

Comment calculer un salaire à partir de là ? Quels poids donner à chaque compétence, en fonction du métier ? À chaque niveau ?

On peut imaginer :

• Un salaire plancher, et des augmentations pour chaque niveau validé dans chaque compétence ;
• Des compétences avec des poids plus importants en fonction du poste ("développement React" comptera plus que "Recrutement" pour un développeur) ;
• Des postes (Junior 1, Junior 2, Confirmé 1...), avec une liste de compétences et de niveaux à valider et un salaire associés ;
• Etc.

J'ai pu constater les effets pervers de certaines de ces méthodes, avec une "chasse à la compétence" qui se met en place, mais je ne peux pas vous en dire plus car finalement... on a décidé de ne pas utiliser cette méthode chez Lonestone !

Trop d'information tue l'information

À ce stade de la mise en oeuvre, les nuages à s'amoncellent au dessus de notre joli système. C'est le moment où on se lève de son bureau, on regarde les platanes par la fenêtre et on sirote une tisane pour prendre un peu de recul sur tout ça.

Est-ce qu'on serait pas en train de doucement se rapprocher d'un bon gros over engineering des chaumières ?

Soyons honnêtes, il y a une certaine satisfaction à créer des systèmes comme celui-ci : c'est élégant, c'est granulaire, ça couvre tout un tas de cas, ça permet d'objectiver le salaire avec des "maths". En théorie, c'est une base utilisable pour créer d'autres systèmes plus macro (comme des fiches de postes).

Ça peut même avoir des effets de bord sympathiques, comme faciliter la gestion du planning en faisant remonter les compétences aux équipes commerciales.

Mais cette granularité extrême plombe tout le système :

• C'est une galère à mettre en place et à maintenir ;
• Plus il y a de détails, plus il y a de chances qu'on se plante dans les petites lignes (ex. les niveaux d'une compétence) ;
• Juger ses propres compétences devient pénible au point de devenir impossible ;
• Juger de celles des autres avec une telle granularité l'est tout autant.

Pas une solution pour objectiver

Et puis, alors que cette granularité était sensée nous garantir une grande objectivité, c'est tout l'inverse qui se produit, car la validation des niveaux de chacun refait surgir les mêmes problématiques qu'au départ :

• Si on laisse les collaborateurs faire on risque d'aller au devant d'inégalités dû à des biais (personnalité, genre) ;
• Si on demande à des managers, ça a de forte chance de très mal fonctionner, par incapacité ou copinage ;

Des effets de bord indésirables

On sirote une gorgée de tisane (froide, on a trop regardé les platanes), et puis on comprend qu'en plus ce genre de systèmes peut aussi avoir des effets pervers sur la culture : remplir la grille de compétences devient l'objectif, plutôt qu'apporter de la valeur.

On peut admettre que si la grille est bien foutue, en théorie les compétences et la valeur pour l'entreprise sont alignées. Sauf que la grande complexité du système :

1. Rend la lecture difficile: être sur que le contenu des grilles et la valeur de l'entreprise sont alignés est un casse tête
2. Transforme le ré-alignement en gageure: personne ne voudra refaire un tel boulot, les grilles risquent d'être gravées dans le marbre et d'être un boulet au pied des dirigeants / managers.

La suite

On apprend en faisant : il est certainement évident aux plus expérimenté·es d'entre vous que ce genre de système était difficilement applicable. Il a fallu qu'on se casse les dents dessus pour avancer.

Il est temps de passer la tisane au micro-onde et de plancher sur la solution suivante.

Sources et remerciements

Merci à Thomas Réaubourg pour son travail sur ce sujet, c'est lui qui a lancé ce chantier de matrice en interne.

Quelques sources pour aller plus loin

• Le management d’une équipe UX par le profil en T, par Guillaume Abel
• Compétences UX et modèle en T, par Raphaël Yharrassarry 

🐦 vous pouvez me suivre sur Twitter , Bluesky ou Linkedin
🚀 mon dernier jeu est sorti ! Vous pouvez jouer à Neoproxima dès maintenant