Sourcer sur GitHub : compte rendu meetup OpenSourcer

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.

Compte-rendu par Kathy Baptista & Pierre-André Fortin

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/confé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, suit et en utilise d’autres, est membre d’organisations. Une organisation regroupe des membres et des projets. Un repo a son propriétaire et 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, ou des repos personnels qui n’ont pas vocation à être exposés. 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 code source : le code entier du projet
• Le Readme, qui décrit le projet et son architecture. 
• Les éléments de popularité : Watchs, Forks, Stars, pour identifier à quel point le projet est suivi et utilisé
• 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 : 
  1. commits, 
  2. Pull Requests, 
  3. issues et 
  4. 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 démonstration portait sur l’analyse fine d’une Pull Request. Pas son contenu en bloc, mais ses fichiers modifiés, un par un. C’est l’essence même de la preuve de travail.

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, c’est le fichier signature de Gherkin, le langage utilisé pour écrire des scénarios de tests en langage naturel dans le cadre du BDD (Behavior Driven Development).

C’est une approche où les tests sont écrits en collaboration avec les équipes métier avant le code. C'est le signal d’une vraie culture produit/qualité et d’une collaboration dev/produit/métier poussée.

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 du projet dans lequel a été faite la PR.

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 ou celle qui est remontée par GitHub.

Sur la PR évoquée, la lecture des dépendances révélait du Symfony, du Behat, du PHPUnit, du PHPStan, du Rector et plusieurs extensions PHPStan spécialisées. 

Sur le papier, une liste d’outils. Mais ce qui est intéressant, ce n’est pas la liste en elle-même. C'est ce qu'elle révèle sur la façon dont une équipe travaille au quotidien. 

Dans sa traduction : un projet PHP mature, avec des tests unitaires et fonctionnels en place. Une équipe qui teste, qui automatise la qualité, qui modernise sa base de code, et une collaboration forte entre les devs et les équipes métier.

Ce sont des indices, pas des certitudes. Mais pour un profil qui y a contribué, ça dit quelque chose sur l'environnement dans lequel il a travaillé.

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 contributions, notamment les issues et les PR des développeurs et ainsi comprendre ce qu'ils font. Les issues permettent d’autant plus d’élargir le spectre des profils que l’on peut trouver, avec comme postulat : quelqu’un qui ouvre une issue, c’est quelqu’un qui utilise la solution.

Coller le contenu d’une issue ou d’une PR dans Claude ou ChatGPT, et demander :

• La traduction métier de ce qui a été indiqué ou fait
• La stack et l’environnement technique
• Le domaine métier dans lequel évolue le profil
• Son rôle probable
• Le niveau technique probable et pourquoi

Le but n’est pas d’évaluer techniquement, mais de comprendre à qui on a affaire. 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.

Et parfois ces traces révèlent une toute autre réalité que le titre de poste déclaré.

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 !