Un recruteur me contacte sur LinkedIn. Il me dit qu'il cherche des développeurs "passionnés", et que pour lui, un bon indicateur c'est un graphique de contributions GitHub bien vert.
J'ai ri. Puis je lui ai expliqué pourquoi cette métrique est totalement inutile.
Le graphique de contributions GitHub est devenu une sorte de badge d'honneur dans la tech. Mais c'est une métrique vide qui ne mesure rien d'important et qui pousse à de mauvais comportements.
Le graphique GitHub compte vos commits publics. C'est tout. Il ne mesure pas :
Il mesure juste : "combien de fois vous avez poussé du code sur un dépôt public".
Un développeur peut avoir un graphique complètement vide et être excellent. Un autre peut avoir un graphique ultra-vert et écrire du code catastrophique.
La majorité des développeurs travaillent sur des dépôts privés. Code propriétaire, projets clients, applications internes : tout ça n'apparaît pas sur le graphique public.
J'ai passé 3 ans à développer une plateforme qui gère des millions de francs de transactions. Des centaines de commits, des milliers de lignes de code, des problèmes techniques complexes résolus. Mon graphique GitHub : complètement vide pendant cette période.
Est-ce que ça fait de moi un mauvais développeur ? Non. Ça fait de moi quelqu'un qui travaille sur du code privé, comme 90% des développeurs professionnels.
Un commit qui refactorise proprement une architecture complexe vaut plus que 100 commits qui corrigent des typos ou reformatent du code.
Mais sur le graphique, c'est pareil. Un carré vert, c'est un carré vert. Peu importe que ce soit une contribution majeure ou un changement d'une ligne dans un README.
J'ai vu des développeurs faire 10 commits par jour en découpant artificiellement leur travail. "Fix typo", "Fix another typo", "Update comment", "Fix formatting". Graphique bien vert, impact proche de zéro.
Quand on mesure quelque chose, les gens optimisent pour cette métrique. Pas pour l'objectif réel, mais pour la métrique elle-même.
Résultat : des développeurs qui créent des scripts pour faire des commits automatiques tous les jours. Des gens qui ouvrent des pull requests inutiles sur des projets open source juste pour avoir des carrés verts. Des contributions de mauvaise qualité juste pour "maintenir la streak".
C'est exactement l'inverse de ce qu'on veut. On veut des développeurs qui réfléchissent avant de coder, qui prennent le temps de bien faire les choses, qui privilégient la qualité à la quantité.
Si vous voulez vraiment évaluer un développeur, regardez :
Le code lui-même : Lisez ses pull requests. Regardez comment il structure son code, comment il gère les edge cases, comment il documente son travail. Ça prend 10 minutes et c'est infiniment plus révélateur qu'un graphique vert.
Les reviews de code : Comment il commente le code des autres. Est-ce qu'il est constructif ? Est-ce qu'il pose de bonnes questions ? Est-ce qu'il comprend les enjeux au-delà du code ?
Les discussions techniques : Comment il explique ses choix. Est-ce qu'il sait argumenter une décision d'architecture ? Est-ce qu'il comprend les trade-offs ?
L'impact réel : Qu'est-ce qu'il a construit ? Quels problèmes il a résolus ? Quelle valeur il a créée pour les utilisateurs ?
Tout ça, c'est invisible sur un graphique GitHub. Mais c'est ce qui compte vraiment.
On entend souvent : "Un bon développeur contribue à l'open source". C'est faux.
Contribuer à l'open source, c'est bien. Mais ce n'est pas une obligation, et ce n'est certainement pas un indicateur de compétence.
Certains développeurs n'ont pas le temps. Ils ont une famille, des hobbies, une vie en dehors du code. Ça ne fait pas d'eux de mauvais développeurs.
D'autres préfèrent approfondir leurs compétences différemment : lire de la documentation, expérimenter en local, apprendre de nouveaux langages. Tout ça ne génère pas de commits publics.
Et puis franchement : est-ce qu'on veut vraiment vivre dans un monde où il faut coder le soir et le week-end pour être considéré comme un "vrai" développeur ?
Le graphique GitHub encourage ce que j'appelle le "développement performatif" : coder pour montrer qu'on code, plutôt que pour créer de la valeur.
C'est comme ces gens qui postent sur LinkedIn tous les jours pour montrer qu'ils travaillent dur. Sauf que le vrai travail, il se fait en silence, loin des métriques publiques.
Les meilleurs développeurs que je connais ont des graphiques GitHub moyens ou vides. Parce qu'ils passent leur temps à résoudre de vrais problèmes, pas à optimiser des métriques de vanité.
Il y a des cas où le graphique a du sens :
Mais même dans ces cas, le graphique ne dit rien sur la qualité. Il dit juste qu'il y a de l'activité.
Si vous recrutez : arrêtez de regarder les graphiques GitHub. Lisez le code. Posez des questions techniques. Évaluez la capacité à résoudre des problèmes.
Si vous cherchez un job : ne vous stressez pas avec votre graphique. Concentrez-vous sur devenir meilleur. Construisez des choses qui ont de l'impact. Apprenez en profondeur.
Si vous êtes développeur : codez parce que vous résolvez un problème, pas parce que vous voulez un carré vert. La qualité de votre travail ne se mesure pas en commits par jour.
Le graphique GitHub, c'est comme le nombre de followers sur Twitter : ça fait plaisir à l'ego, mais ça ne mesure rien d'important.
Un bon développeur, c'est quelqu'un qui résout des problèmes. Pas quelqu'un qui a un joli graphique vert.
Besoin d'aide ?
Container queries, :has(), nesting natif, view transitions — le CSS de 2026 fait ce que JavaScript et Sass faisaient avant. Tour d'horizon des fonctionnalités qui changent la donne.
Les sites statiques appartiennent au passé. Découvrez comment les micro-interactions fluides avec Framer Motion augmentent l'engagement utilisateur et le taux de conversion.
Un site WordPress qui mettait 12 secondes à charger est passé à 1,8 seconde en corrigeant trois erreurs courantes. Voici lesquelles.
