Comment sourcer des développeurs sur GitHub : le guide pratique

GitHub compte plus de 100 millions de comptes de développeurs, et une bonne partie des ingénieurs que vous voulez recruter y ont laissé des traces publiques de leur travail. Contrairement à un CV, ce travail n'est pas déclaratif : ce sont le code, les reviews et les discussions eux-mêmes. On a expliqué pourquoi ça compte dans lisez le code, pas le CV. Ce guide, c'est le comment : la méthode qu'on appliquait à la main avant de l'automatiser, étape par étape.

1. Décrire ce que la personne va construire, pas son titre

« Ingénieur backend senior » est un titre. GitHub n'indexe pas des titres, il indexe du code. Avant de chercher, traduisez donc le poste en ce que la personne va réellement construire, puis en signaux qu'on peut trouver dans un dépôt :

• Le langage et l'écosystème : Go, Rust, TypeScript, Python, et les principaux frameworks autour.
• Les bibliothèques : les dépendances sur lesquelles repose votre code. Quelqu'un qui a contribué à l'une d'elles la connaît de l'intérieur.
• Le problème : un registre de paiements, un carnet d'ordres temps réel, un pipeline de données, un design system. Les problèmes se lisent dans les noms de dépôts, les topics et les README.

Prenons « ingénieur backend pour notre API de paiement ». En signaux, ça donne : Go ou Java, PostgreSQL, idempotence, comptabilité en partie double, webhooks, peut-être le SDK d'un prestataire de paiement. C'est cette liste qui fait votre recherche, pas l'intitulé du poste.

2. Chercher les projets avant les personnes

L'erreur la plus courante est de commencer par la recherche d'utilisateurs de GitHub. Elle porte surtout sur les noms, les identifiants et les villes, ce qui dit très peu de choses. Commencez plutôt par le travail.

La recherche de dépôts trouve les projets proches de votre problème. Combinez les filtres :

• topic:ledger language:go pour les projets tagués avec ce sujet, dans le bon langage ;
• pushed:>2026-01-01 pour ne garder que les projets encore vivants ;
• stars:10..500 pour écarter les projets géants où des milliers de personnes contribuent, et les projets vides.

Puis, sur chaque projet pertinent, regardez les personnes :

• Insights, puis Contributors : qui a écrit le code, et quelle part.
• Les pull requests : dans la barre de recherche du dépôt, is:pr is:merged liste les contributions fusionnées. Une pull request fusionnée sur un projet qui n'est pas le sien est l'un des signaux les plus forts qui soient : un autre mainteneur a lu le code et l'a accepté.
• Les issues : ceux qui signalent des bugs précis, avec une reproduction, comprennent en général le fonctionnement interne.

Les bibliothèques que vous utilisez sont une mine d'or. Ouvrez les dépôts des dépendances de votre équipe et regardez leurs contributeurs. Ces personnes connaissent déjà une partie de votre stack mieux que la plupart des candidats que vous rencontrerez.

Les Dependents fonctionnent dans l'autre sens. Sur la page d'une bibliothèque, Insights, puis Dependency graph, puis Dependents liste les projets publics qui l'utilisent. C'est un moyen rapide de trouver des équipes et des personnes qui construisent avec les mêmes outils que vous.

3. Affiner ensuite avec la recherche d'utilisateurs

Une fois que vous savez ce que vous cherchez, la recherche d'utilisateurs devient utile pour filtrer par lieu :

• type:user location:Paris language:go renvoie les comptes qui indiquent Paris et dont les dépôts sont surtout en Go ;
• followers:>20 ou repos:>10 retirent la plupart des comptes vides.

Deux limites à garder en tête. Le champ de localisation est du texte libre : « Paris », « Paris, France », « France » et « Île-de-France » sont des chaînes différentes, essayez-en plusieurs. Et le langage est calculé sur les dépôts de la personne, pas sur ce à quoi elle contribue ailleurs : un contributeur majeur d'un gros projet Rust peut n'avoir aucun dépôt Rust à lui.

4. Lire un profil en cinq minutes

Voici l'ordre dans lequel on lit un profil, pour décider vite si quelqu'un mérite qu'on s'y attarde :

1. Les dépôts épinglés : ce que la personne a choisi de montrer. Ouvrez-en un, lisez le README, puis deux ou trois fichiers.
2. Les contributions aux projets des autres : cherchez is:pr author:son-identifiant -user:son-identifiant is:merged. Vous obtenez les pull requests fusionnées sur des dépôts qui ne sont pas les siens. C'est là que se voit la vraie collaboration.
3. Les code reviews : reviewed-by:son-identifiant montre les pull requests qu'elle a relues. Bien relire est une compétence de senior, et elle n'est presque jamais visible ailleurs.
4. Le code lui-même : des tests, une structure, des messages de commit qui expliquent pourquoi et pas seulement quoi. Pas besoin d'être ingénieur pour voir si un projet a des tests et un README clair.
5. La fraîcheur : l'activité des derniers mois. Une compétence utilisée la semaine dernière en dit plus qu'une compétence listée en 2019.

Ignorez les forks sans aucun commit de la personne : ce sont des favoris, pas du travail.

5. Savoir ce que le profil ne dit pas

Le code public est une preuve, pas un portrait complet. Trois pièges :

• Un profil vide ne prouve rien. Beaucoup d'excellents ingénieurs passent leurs meilleures années sur des codebases privées, et beaucoup n'ont ni le temps ni l'envie de faire des side projects. Certains affichent leur activité privée en cases anonymes sur le graphe de contributions, la plupart non.
• Les cases vertes se fabriquent. Un graphe de contributions très dense peut n'être fait que de micro-commits automatiques. Regardez ce qu'il y a derrière.
• Les étoiles mesurent la popularité, pas le niveau. Un projet du week-end bien marketé peut avoir plus d'étoiles qu'une bibliothèque rigoureuse dont tout le monde dépend.

Servez-vous de GitHub pour trouver des gens que vous auriez ratés et pour ouvrir la conversation sur quelque chose de réel. Gardez vos entretiens pour le reste.

6. Contacter correctement

GitHub n'est pas une messagerie, et les ingénieurs sentent tout de suite quand on les traite comme une liste. Quelques règles :

• Utilisez le contact que la personne a choisi de publier : l'email de son profil, son site personnel, ou une adresse professionnelle. N'allez pas extraire des emails des commits.
• Lisez les règles de GitHub. Ses règles d'utilisation acceptable interdisent d'utiliser les informations du site pour du spam, y compris des emails non sollicités. Un message personnel sur le travail de quelqu'un n'a rien à voir avec une campagne, et doit le rester.
• En Europe, le RGPD s'applique. Contacter quelqu'un pour un poste se fait en général sur la base de l'intérêt légitime : dites où vous l'avez trouvé, ne gardez que le nécessaire, et arrêtez au premier « non ».
• Ouvrez sur son travail. Le projet par lequel vous l'avez trouvé est la meilleure première phrase que vous aurez jamais. On y a consacré un article : le premier email auquel les ingénieurs répondent.

7. Suivre, et savoir ce que ça coûte

Bien fait, c'est long. Comptez 15 à 30 minutes par bon candidat entre la recherche de projets, la lecture du profil et un message qui ne soit pas générique. Pour un poste, ça fait un à deux jours pour une shortlist de vingt personnes.

Tenez un tableau simple par poste : identifiant, le projet qui vous a menés à la personne, ce que vous avez remarqué, la date du message, la réponse. Après deux ou trois postes, vous saurez quelles recherches marchent pour votre stack.

Ce jour ou deux, c'est exactement ce qu'Azerit automatise. Vous décrivez le poste en une phrase ; il cherche dans les projets et les contributions, classe les ingénieurs qui ont déjà construit quelque chose de proche, montre le travail derrière chaque score, trouve un email professionnel et rédige un premier message sur leur propre code. Si vous préférez le voir que le faire à la main, essayez-le sur un de vos postes.

L'antisèche

• Les projets sur votre problème : topic:<sujet> language:<langage> pushed:>2026-01-01
• Le travail fusionné dans un dépôt : is:pr is:merged dans ce dépôt
• Le travail fusionné d'une personne sur d'autres projets : is:pr author:<identifiant> -user:<identifiant> is:merged
• Ce qu'une personne relit : reviewed-by:<identifiant>
• Les développeurs d'une ville : type:user location:<ville> language:<langage>
• Les équipes qui utilisent une bibliothèque : Insights, puis Dependency graph, puis Dependents