Sourcer sur GitHub transforme l'approche du recrutement tech. Ce compte rendu de la soirée OpenSourcer du 23 avril 2026, animée par Kathy Baptista chez Ideuzo, revient sur comment sourcer sur GitHub en lisant les traces de travail réelles des développeurs.
Le décor
Le 23 avril 2026, Nous étions une vingtaine de curieux, réunis chez Ideuzo (encroe un grand Merci à Olivier et Tanguy de nous avoir ouvert les portes), rue de Palestro à Paris pour la deuxième soirée/onférence du mettup OpenSourcer.
Au menu : Kathy, recruteuse indépendante, nous promet du concret avec « le sourcing par la preuve de travail sur GitHub ». Le titre laisse attendre une présentation technique, une liste d’astuces, des manipulations d’URL.
L’intervention a dépassé la promesse. Kathy n’a pas vendu d’outil. Elle a déconstruit une croyance.
Pourquoi sourcer sur GitHub ?
Le contexte du sourcing 2026 explique en grande partie pourquoi cette soirée comptait. Sous l’effet des grands modèles de langage, les profils LinkedIn se lissent (c'est ce que j'ai appelé l'effet Agent Smith). Les candidats utilisent les mêmes formulations, les mêmes mots-clés à la mode, les mêmes structures de bio. L’algorithme de la plateforme favorise par construction les profils actifs et bavards, ceux qui passent du temps sur LinkedIn, pas ceux qui produisent dans leur métier.
Résultat : la recherche par mots-clés remonte une cohorte étroite et homogène, pendant que la majorité reste invisible ou indifférenciable.
GitHub, à l’inverse, n’a pas été pensé pour le recrutement. Ce qu’on y voit n’est pas une vitrine, c’est une trace.
- Un commit, c’est une action datée et signée.
- Une Pull Request, c’est une proposition technique soumise à la critique.
- Une issue, c’est un problème rencontré en production qu’on signale et qu’on documente.
Aucune de ces traces n’a vocation à séduire un recruteur. Toutes disent quelque chose de précis sur ce que la personne fait au quotidien.
C’est cette différence de nature que Kathy a posée d’entrée. GitHub n’est pas un outil de sourcing, et c’est précisément ce qui en fait un avantage concurrentiel pour ceux qui savent y lire.
Les quatre niveaux de signal
Sa grille de lecture s’organise autour de quatre catégories de signal, chacune plus difficile à fabriquer que la précédente.
Le déclaratif, d’abord : ce que le candidat dit de lui. Bio LinkedIn, About GitHub, intitulé de poste, compétences listées. Le déclaratif est riche en bruit. Le candidat choisit ses mots, les ajuste à ce qu’il pense être attendu, oublie ou inflate selon les époques.
L’implicite ensuite : ce que le contexte permet de deviner. Quelqu’un qui travaille chez SensioLabs maîtrise probablement Symfony, même sans l’écrire. Quelqu’un qui passe dix ans dans une banque connaît les environnements réglementés, même sans y consacrer une ligne de profil. L’implicite n’est pas déclaré, il est inféré par la position dans un écosystème.
Le comportemental monte d’un cran : l’engagement réel dans une communauté. Une participation régulière à un meetup spécialisé, une intervention à une conférence, un suivi assidu d’un leader d’opinion sur un sujet précis. Le comportemental dit ce qu’on choisit de fréquenter, à l’écart de ce qu’on dit aimer.
Et enfin la preuve de travail, le niveau le plus solide. Pas ce que le candidat fréquente, mais ce qu’il a produit. Du code dans GitHub. Une maquette dans Dribbble. Un notebook dans Kaggle. Un design publié dans Behance. La preuve de travail ne se simule pas. Elle se construit sur des semaines ou des années, dans des outils faits pour des praticiens.
GitHub, dans cette grille, occupe la quatrième case. Et le travail du sourceur, à partir de là, consiste à apprendre à la lire.
L’anatomie de GitHub
Kathy a pris le temps de poser les fondamentaux de la plateforme, parce que c’est précisément ce que la plupart des recruteurs sautent.
GitHub repose sur trois entités :
- les utilisateurs,
- les dépôts (repos),
- les organisations.
Ces trois entités s’imbriquent. Un utilisateur possède des repos, contribue à d’autres, suit des organisations. Une organisation regroupe des membres et des projets. Un repo a son propriétaire et ses contributeurs.
Pour le sourceur, chacune des trois entités est un point d’entrée. On peut chercher un profil par son activité directe, par les repos qu’il a créés ou forkés, ou par les projets qu’il fréquente. On peut aussi remonter de l’autre sens : partir d’un projet emblématique d’une technologie, et identifier ses contributeurs.
À l’échelle, les ordres de grandeur sont parlants. Plus de 180 millions de comptes sur GitHub. Mais 80% du travail s’y fait en privé, c’est-à-dire dans des dépôts internes d’entreprise inaccessibles. Le sourcing porte donc sur les 20% restants, la part publique. Cette part suffit largement, à condition de savoir y poser la grille.
Sur la fiche d’un repo, plusieurs zones méritent l’attention :
- Le Readme, qui décrit le projet et son architecture.
- Les Topics, ces étiquettes thématiques qui permettent les recherches transversales.
- Les langages, dont GitHub n’affiche que le principal, ce qui suffit rarement à qualifier une stack.
- Et les Contributions, qui se déclinent en :
- commits,
- Pull Requests,
- issues et
- reviews.
Chacun de ces signaux mérite une lecture dédiée, parce que chacun documente un aspect différent de la pratique.
Trois démos qui retournent une croyance
Pour rendre la chose tangible, Kathy a déroulé trois démonstrations.
Aucune d’elles n’est spectaculaire prise isolément. Ensemble, elles disent ce que veut dire « lire un profil ».
La première portait sur l’analyse fine d’une Pull Request. Pas son contenu en bloc, mais ses fichiers modifiés, un par un. Sur une PR sur le projet PrestaShop, elle a montré qu’au milieu de fichiers PHP attendus se glissait un fichier .feature. Pour qui connaît les extensions, cette terminaison signe une chose précise : du développement piloté par les comportements via Cucumber. Information absente de la bio du candidat. Présente dans son geste.
Ce que dit ce fichier : la personne ne fait pas que coder, elle pratique le développement fonctionnel, ce qui implique un dialogue serré avec les équipes métier. Un signal que la recherche par mots-clés ne pouvait pas remonter.
La deuxième démo passait par les fichiers de dépendances. Dans tout projet logiciel propre, un fichier déclare les bibliothèques utilisées. composer.json pour PHP, requirements.txt pour Python, package.json pour JavaScript. Aller chercher ce fichier dans un repo, c’est lire la stack réelle plutôt que celle qui plaît au candidat.
Sur la PR évoquée, la lecture des dépendances révélait du Symfony, du Behat, du PHPUnit, du PHPStan. Quatre outils, quatre signaux convergents. Là encore, rien de tout cela n’apparaissait dans le profil public.
La troisième démo, plus connue mais rappelée comme une évidence, portait sur le hack .patch.
En ajoutant cette extension à l’URL d’un commit, GitHub renvoie une vue brute qui inclut l’adresse email utilisée pour configurer Git. Quand cette adresse n’est pas masquée par un proxy de la plateforme, on tient le contact direct.
Outiller la lecture
GitHub ne facilite pas la vie du sourceur. La recherche est limitée à 1 000 résultats par requête, à 256 caractères, à cinq opérateurs booléens. Le champ de localisation n’est pas structuré : « Paris », « 75 », « Île-de-France », « IDF » sont quatre saisies différentes pour la même réalité géographique, et la recherche native n’en regroupe aucune.
Plutôt que d’attendre que la plateforme corrige ces limites, Kathy nous explique comment elle a construit ses propres outils.
Elle nous montre une application maison qui contourne les contraintes en passant par l’API publique de GitHub, elle standardise aussi les localisations par géocodage, et découpe les requêtes longues en sous-requêtes, et agrège ainsi les profils dans un format lisible. L'obejt de la démonstration est surtout de montrer ce qu'il est posible de faire avec un peu d'imagination et la puissance du Vibe Coding.
C'est aussi, l'occasion pour kathy de nous montrer comment elle utilise les grands modèles de langage pour lire les commits et autres contributions des développeurs et ainsi comprendre ce qu'ils partagent.
Coller un fichier de code dans une conversation Claude ou ChatGPT, demander : « ce code est-il plutôt front ou back ? », « quel est le niveau d’abstraction ? », « quel est le rôle métier de ce module ? ». Le modèle traduit la matière technique en lecture exploitable par un sourceur non développeur. La technique ne remplace pas l’expertise, elle la met à disposition.
Le sourcing 360
L’enjeu final n’est pas GitHub seul. C’est le croisement.
Un profil GitHub apporte la preuve de travail. Un profil LinkedIn apporte le parcours, l’employeur, le titre, parfois la mobilité géographique. Croiser les deux donne une vue dont aucune des deux plateformes ne dispose seule.
Sur une population technique, Kathy mesure un taux de rapprochement entre 70 et 75%.
Le profil 360 ainsi reconstitué résiste mieux aux trous de l’une ou l’autre source.
Le même raisonnement vaut pour Twitter, GitLab, Bitbucket, et plus largement toute plateforme où une trace publique d’activité existe. Ce n’est pas une accumulation, c’est une triangulation.
Pour finir
L’intervention a duré près d’une heure et demie, prolongée ensuite autour d'un verre. Le fil rouge de cette soirée tient en une phrase : pendant que LinkedIn lisse ses profils sous l’effet des LLM, GitHub et d'autres plateformes restent des terrains de signaux bruts.
Le sourcing comportemental, qui était la base du métier avant LinkedIn, redevient la voie principale. La preuve de travail bat le déclaratif. Le geste bat la grammaire. Les cinq prochaines années se joueront sur cette ligne.
Merci à Kathy Baptista pour cette intervention dense, claire et concrète. Merci à Ideuzo de nous avoir ouvert ses portes. Et merci aux vingt personnes présentes pour les questions et les prolongations.
Le prochain OpenSourcer se tiendra le 29 mai au Bouillon autour d'un verre cette fois... retour des conférence le 25 juin !