Les contributions GitHub ne sont plus fiables pour recruter

Les contributions GitHub ne constituent plus un indicateur de recrutement fiable. Le graphe d’activité comptabilise des événements très différents sans mesurer la qualité du travail d’ingénierie, tandis que l’IA permet de produire une activité visible à moindre coût. Servez-vous de GitHub pour repérer un ou deux livrables, puis évaluez leur pertinence, leur maîtrise, leur vérification, la prise en compte des retours, leur impact et le suivi assuré dans la durée. Proposez une voie équivalente aux candidats dont les meilleurs travaux restent confidentiels.

Le carré vert n’est pas mort. Le raccourci, lui, l’est.

Pourquoi le nombre de contributions GitHub ne fonctionne-t-il plus comme raccourci pour recruter ?

Le nombre de contributions GitHub n’est plus un raccourci valable pour recruter : produire une activité visible coûte désormais moins cher, alors qu’en évaluer la valeur exige toujours autant de travail. Ce changement a amplifié un défaut qui existait déjà : le compteur mesure des actions, pas leur capacité à améliorer un projet.

Neil Alexander a bien résumé cette tension dans un billet de juin 2026 consacré à trois pull requests coécrites avec Claude. Un contributeur avait corrigé l’orthographe et la grammaire de commentaires dans le code. Ces modifications étaient correctes et inoffensives, mais Alexander les a fermées, car elles mobilisaient du temps de revue sans apporter d’amélioration notable au projet. Il soupçonnait que cette activité visait à étoffer un CV.

Ce dernier point relève d’une déduction, pas d’un fait. Le contributeur n’a pas confirmé de motivation professionnelle. Quand le billet a été repris sur Hacker News, certains commentateurs ont contesté la décision, estimé que des corrections typographiques, même mineures, conservaient une certaine utilité et rappelé que le spam de contributions précédait l’IA générative. Ces objections comptent. Un processus de recrutement équitable ne peut pas déduire une intention malhonnête d’une petite modification, ni pénaliser un candidat pour le simple recours à un assistant.

Le problème plus général de l’attention disponible, lui, est bien réel. En janvier 2026, GitHub indiquait que les mainteneurs faisaient face à un volume croissant de contributions de faible qualité, notamment des propositions qui ignoraient les règles du projet, restaient sans suivi ou avaient été produites par l’IA. En mai, GitHub a décrit le goulet d’étranglement plus précisément : produire des pull requests, des tickets, des commentaires et des rapports était devenu beaucoup plus simple, alors que le temps disponible pour les examiner restait une ressource rare. GitHub a explicitement précisé que le problème dépassait l’IA.

L’entreprise a ensuite déployé des paramètres permettant de désactiver ou restreindre les pull requests et de plafonner le nombre de pull requests ouvertes simultanément par des contributeurs sans droit d’écriture. Ces évolutions du produit ne prouvent pas que des candidats gonflent leur CV. Elles montrent toutefois que le volume de contributions peut entraîner un coût réel avant même que quiconque sache si une modification est utile.

Les données les plus solides dont dispose actuellement l’écosystème vont dans le même sens, avec d’importantes réserves. Une prépublication de juillet 2026 a étudié 294 dépôts populaires et actifs, ainsi que plus de 1,2 million de pull requests. Par rapport à un scénario contrefactuel modélisé, les auteurs ont estimé que le volume de pull requests avait augmenté de 6,80 % en 2025, tandis que le taux global de fusion avait reculé de 1,06 %. Les pull requests émanant de contributeurs ponctuels ont progressé de 5,84 %, alors que leur taux de fusion a chuté de 18,18 %.

Ces chiffres ne prouvent pas que l’IA a causé cette évolution. Les chercheurs ont utilisé l’année 2025 comme indicateur indirect de l’adoption massive de l’IA, sans observer l’usage individuel des outils, et n’ont pas pu exclure la croissance de la plateforme ni d’autres transformations de l’écosystème. Leur échantillon privilégie aussi les dépôts populaires et ouverts aux nouveaux contributeurs. La conclusion prudente est plus restreinte : dans cet échantillon, l’augmentation de l’activité visible apportait moins d’informations sur la probabilité de fusion.

Le spam n’est pas nouveau. Dans son bilan du Hacktoberfest 2020, DigitalOcean a comptabilisé 621 104 pull requests, dont 9 598 marquées comme spam ou non valides et 34 595 non acceptées. Face à l’afflux de propositions de faible qualité, les organisateurs ont réservé l’événement aux projets qui choisissaient explicitement d’y participer. L’IA n’a pas créé le problème des incitations. Elle en a réduit le coût d’exploitation.

Que mesure réellement un carré vert ?

Un carré vert GitHub mesure une activité prise en compte selon les règles d’affichage de GitHub. Il ne mesure ni la difficulté, ni la justesse, ni l’utilité, ni la paternité du travail, ni la performance professionnelle. Deux graphes identiques en apparence peuvent représenter des travaux très différents, et deux ingénieurs aussi compétents l’un que l’autre peuvent présenter des graphes radicalement différents.

La documentation de GitHub sur les contributions montre clairement ce décalage. La création d’un dépôt ou d’un fork est toujours comptabilisée. Les tickets, pull requests, revues, discussions, réponses et commits ne le sont que sous certaines conditions. Une pull request n’a pas besoin d’être fusionnée pour apparaître. GitHub plafonne aussi le nombre d’événements affichés dans certaines catégories.

La visibilité des commits obéit à ses propres contraintes. L’adresse e-mail du commit doit être rattachée au compte. Le travail doit se trouver dans un dépôt autonome, généralement sur la branche par défaut ou gh-pages, et la personne doit remplir une condition supplémentaire liée à sa relation avec le dépôt. Un travail privé peut apparaître sous la forme d’un nombre, sans aucun détail vérifiable. La fusion de comptes peut faire perdre l’attribution de tickets, de pull requests et de discussions. Un rebasage peut attribuer la contribution à la fois à l’auteur initial et à la personne qui l’a effectué.

Si vous utilisez le graphe comme note de présélection, vous commettez deux types d’erreurs :

• Faux positifs : un graphe dense peut regrouper des forks, des pull requests non fusionnées, une activité automatisée, des changements superficiels ou des travaux dont vous n’avez pas examiné la valeur.
• Faux négatifs : un graphe peu fourni peut masquer des années de travail confidentiel en entreprise, des contraintes de sécurité, des adresses e-mail de commit non rattachées, un travail effectué sur des branches que GitHub ne comptabilise pas, ou simplement l’absence d’envie de travailler bénévolement en public.

Une activité plus soutenue peut tout de même vous conduire vers des preuves utiles. Mais elle ne constitue pas une preuve en soi. Ne comptez pas les étoiles, les dépôts, les commits, les séquences ininterrompues de contributions ou les pull requests fusionnées pour établir un classement des candidats. Même une faible pondération numérique confère artificiellement à cet affichage d’activités incomparables la valeur d’un critère de décision.

D’anciens travaux sur le recrutement expliquent pourquoi ce raccourci persiste. Dans une étude de 2016, neuf participants ont évalué cinq profils de développeurs. Huit d’entre eux ont utilisé le nombre ou la fréquence des commits lors de la présélection, car ces repères étaient faciles à comparer. Les participants issus de grandes entreprises étaient plus enclins à examiner ensuite le type et la qualité des contributions ; ceux de petites entreprises s’en tenaient surtout à l’étendue des travaux et à la réputation des projets. Cette étude, minuscule, n’évalue pas les résultats ultérieurs en poste, mais elle met au jour un travers bien connu : ce qui se compte le plus facilement évince les informations dont vous avez réellement besoin.

Aucune étude repérée pour cet article n’établit que le volume de contributions GitHub prédit la performance professionnelle. Un travail public peut révéler des comportements précieux. Le compteur ne vous dit pas lesquels.

Les travaux open source assistés par l’IA comptent-ils encore ?

Oui. Les travaux open source assistés par l’IA peuvent constituer de solides preuves dans un portfolio lorsque le candidat les comprend, les vérifie et en assume la responsabilité. La distinction utile oppose un travail assumé à un résultat produit sans maîtrise, et non la saisie humaine à la génération automatique.

Une étude de 2026 sur les règles de contribution a examiné 1 000 dépôts GitHub populaires et recensé 118 politiques explicites sur l’IA. Parmi elles, 78 % autorisaient les travaux assistés par l’IA, 51 % exigeaient de les signaler et 74 % imposaient une intervention humaine. L’échantillon ne représente pas tous les dépôts, mais contredit directement l’idée selon laquelle les projets établis rejetteraient généralement l’usage de l’IA.

Les règles actuelles de plusieurs projets convergent vers des preuves observables :

• LLVM demande aux contributeurs de lire, relire et expliquer les travaux générés. Le projet qualifie une contribution d’« extractive » lorsque le coût de revue attendu dépasse le bénéfice pour le projet.
• Linux exige une validation humaine. Les signalements de bugs assistés par l’IA doivent comprendre un moyen de reproduire le problème, un correctif, des preuves de compilation ou de test et une description honnête de tout ce qui n’a pas été vérifié.
• pytest accepte l’assistance de l’IA, mais ferme les propositions entièrement automatisées lorsqu’aucun humain ne peut participer utilement à leur revue.
• OpenXLA accepte les travaux signalés comme générés par l’IA s’ils répondent à un vrai problème, à un test ou à une référence de performance, et si leur auteur les comprend.
• curl accepte les pull requests assistées par l’IA selon ses critères habituels de qualité du code, de tests et de documentation.

curl apporte aussi un contre-exemple utile. Dans son programme de primes aux vulnérabilités, le taux de signalements confirmés, historiquement supérieur à 15 %, est tombé sous les 5 % en 2025 sous l’effet de propositions massivement assistées par l’IA et motivées par la récompense. Cette évolution a contribué à la décision de mettre fin aux primes en argent. En avril 2026, le mainteneur Daniel Stenberg indiquait que le volume avait doublé et que le taux de signalements confirmés était remonté à 15–16 %, alors même que presque tous les signalements semblaient assistés par l’IA.

Il s’agit de l’expérience d’un seul projet, pas d’un taux universel. Elle montre néanmoins pourquoi la question « Avez-vous utilisé l’IA ? » est peu révélatrice en recrutement. Les incitations, la vérification, la pertinence et la responsabilité humaine déterminaient l’utilité du résultat. Votre revue de portfolio doit examiner les mêmes éléments.

Si vous souhaitez évaluer la manière dont une personne travaille avec l’IA au cours d’une épreuve en direct, cette épreuve doit être conçue à part. Notre guide sur les entretiens techniques avec IA y est consacré. Pour la revue de portfolio, ne tentez pas de détecter l’IA. Demandez au candidat d’expliquer et de défendre son livrable.

Comment évaluer le portfolio GitHub d’un développeur ?

Évaluez un ou deux livrables pertinents pour le poste à l’aide de la même grille en six critères pour chaque candidat. Un échantillon ciblé en révèle davantage que le total affiché sur le profil et reste suffisamment restreint pour permettre une revue rigoureuse.

Commencez par choisir un livrable qui offre suffisamment de contexte. Il peut s’agir d’une pull request, d’une discussion de conception, d’un signalement de bug accompagné d’un moyen de le reproduire, d’une version dont le candidat a assuré la maintenance ou d’un dépôt dont il est responsable. Privilégiez les travaux pertinents pour le poste, sans présumer que les projets célèbres fournissent de meilleures preuves. Une modification modeste peut révéler un excellent discernement technique.

Évaluez ensuite ces six critères :

Ne considérez pas une pull request fusionnée comme une preuve automatique de qualité. Les décisions de fusion reflètent le périmètre du projet, la disponibilité des mainteneurs, le calendrier et le contexte social, en plus du code. Une proposition rejetée peut tout de même constituer une preuve solide si le candidat a repéré un vrai problème, testé une approche défendable, bien réagi aux retours et sait expliquer pourquoi le projet a choisi une autre voie.

L’inverse est également vrai. Une correction typographique fusionnée peut être utile au projet, tout en révélant peu de choses sur la capacité à raisonner sur des systèmes. Évaluez ce que le livrable démontre pour ce poste, pas le statut qui lui est associé.

Posez les trois mêmes questions à chaque candidat :

1. Quel problème cherchiez-vous à résoudre, et comment saviez-vous qu’il méritait de l’être ?
2. Quelle preuve démontrerait que votre modification est erronée ?
3. Qu’avez-vous changé après la revue, et que feriez-vous différemment aujourd’hui ?

Avec ces questions, il devient plus difficile de se faire passer pour l’auteur du travail. Une personne qui a copié une réponse sans la comprendre aura du mal à relier le problème, les preuves et l’historique des révisions. À l’inverse, une personne qui a utilisé l’IA de manière responsable peut expliquer clairement le même enchaînement. Un débutant peut également obtenir une bonne note sur une petite contribution, car la grille récompense le jugement et l’apprentissage plutôt que l’ampleur.

Consignez le livrable, les réponses et les preuves qui justifient chaque note. L’objectif n’est pas de transformer un travail qualitatif en fausse précision. Il s’agit d’empêcher que la réputation, la longueur d’une séquence de contributions, la marque d’un employeur ou l’enthousiasme du premier relecteur ne modifient discrètement les critères.

Que faire lorsqu’un candidat n’a aucun travail public sur GitHub ?

Offrez aux candidats qui ne disposent pas de travaux publics utiles une voie équivalente pour démontrer les mêmes compétences. Un profil GitHub doit rester facultatif, car l’absence d’activité publique n’indique pas un manque de compétences.

Demandez un livrable parmi les options suivantes :

• un travail open source public ;
• un travail professionnel confidentiel que le candidat peut décrire sans divulguer d’informations sensibles ;
• un projet universitaire, bénévole ou personnel ;
• une note d’architecture, un retour d’expérience sur un incident ou une décision technique qu’il peut présenter ;
• un court exercice équivalent fourni par votre équipe.

Autorisez les candidats à masquer les noms, les indicateurs et les informations confidentielles. Vous avez besoin du problème, de leur action précise, de la méthode de vérification, du résultat et de ce qu’ils en ont appris. Vous n’avez pas besoin du code source de leur ancien employeur.

Lorsqu’aucun livrable existant ne convient, utilisez une tâche représentative qui évalue une compétence essentielle dès l’entrée en poste. Elle doit rester courte, ne pas constituer du travail gratuit pour votre produit et ne pas porter sur un sujet que la personne pourrait raisonnablement apprendre après son arrivée. Notre guide sur la structuration des exercices de code aborde le périmètre de la tâche, les consignes aux candidats et les modalités de revue. Cet exercice constitue une voie d’accès, pas une sanction pour avoir effectué du travail confidentiel.

Utilisez une même famille de critères pour toutes les voies. Dans un projet open source public, la vérification peut prendre la forme d’un moyen de reproduire le problème et d’une revue par le mainteneur. Dans un projet confidentiel, elle peut correspondre à un plan de test et aux suites d’un incident. Dans un court exercice, il peut s’agir d’un test de régression et d’une explication. Les livrables diffèrent, pas la compétence.

Cette équivalence évite aussi de confondre temps disponible et mérite. La contribution publique favorise les personnes qui en ont l’autorisation, disposent de temps libre et peuvent montrer leur travail. Un processus équitable n’exige pas de travail public non rémunéré pour rendre une expérience confidentielle évaluable.

Comment transformer les preuves d’un portfolio en décision de recrutement défendable ?

Convertissez la revue du livrable en un dossier de preuves structuré, puis donnez-lui sa juste place. Les preuves issues du portfolio doivent répondre à une question délimitée sur le travail effectivement réalisé. Elles ne doivent ni se transformer en jugement général sur la personnalité, ni déterminer à elles seules l’embauche.

Demandez aux évaluateurs d’attribuer leurs notes séparément avant de discuter du candidat. Exigez une courte justification factuelle pour chaque critère. Lors de la mise en commun, concentrez-vous sur les écarts de note significatifs : quel détail du livrable l’un a-t-il relevé que l’autre n’a pas vu, et faut-il clarifier le repère d’évaluation ?

La revue de portfolio peut alors s’intégrer au reste du processus de recrutement sans l’accaparer. Un livrable solide peut orienter une question de suivi ciblée. Il ne doit pas compenser le manque de preuves dans des domaines essentiels au poste que le livrable ne couvre pas. Une pull request côté serveur peut révéler des aptitudes de débogage et la manière de réagir à une revue de code, sans rien dire de la communication avec les parties prenantes ni de la responsabilité opérationnelle.

Les recherches générales sur la sélection favorisent la structure plutôt que l’improvisation. Une synthèse de 2023 a estimé la validité opérationnelle corrigée à 0,42 pour les entretiens structurés, 0,33 pour les échantillons de travail et 0,19 pour les entretiens non structurés. Il s’agit d’estimations portant sur un vaste ensemble de métiers et présentant une forte variabilité, pas de garanties propres au développement logiciel. Elles étayent un principe de conception, pas une promesse concernant votre grille particulière.

Définissez les critères avant d’examiner les candidats. Posez des questions constantes. Formez les évaluateurs à l’utilisation des repères. Conservez les notes individuelles avant le compte rendu. Notre guide sur les grilles d’évaluation des entretiens structurés explique le système de notation général. La grille d’évaluation du portfolio doit l’alimenter comme une source de preuves parmi d’autres, plutôt que de faire office de véto informel en marge.

Auditez le processus après plusieurs recrutements. Vérifiez si les évaluateurs appliquent les repères de manière cohérente, si une voie fait avancer davantage de candidats que les voies équivalentes et si les notes de portfolio concordent avec les preuves recueillies lors des étapes suivantes. Ne revendiquez pas une validité prédictive que vous n’avez pas mesurée.

Comment Kit peut-il assurer la traçabilité des preuves sans prétendre vérifier la paternité du travail ?

Kit peut standardiser la traçabilité des preuves : un dépôt d’exercice privé, une échéance claire, des évaluateurs nommés, des grilles d’évaluation masquées et une décision humaine dont l’auteur est identifié. Il ne détecte pas l’IA, ne capture pas les prompts et ne prouve pas qui a écrit le code.

Lorsqu’un candidat a besoin d’un exercice équivalent, l’intégration GitHub de Kit peut créer un dépôt privé à partir de votre modèle, inviter le candidat, suivre l’échéance et ses prolongations, désigner les évaluateurs habilités, puis archiver le dépôt une fois l’exercice terminé. Les consignes destinées au candidat apparaissent dans le portail et dans les documents de l’exercice. Kit crée le dépôt, pas une pull request.

Associez l’étape d’exercice de code à une étape de revue d’équipe. Intégrez-y les six critères, demandez aux évaluateurs de noter séparément et ne discutez des preuves qu’après la validation des notes. Kit gère les revues masquées jusqu’à leur soumission, les critères pondérés, les commentaires, les seuils et une décision humaine dont l’auteur est identifié. Les critères structurés ne figurent pas directement dans l’étape d’exercice de code : l’association des deux étapes est donc essentielle.

Inscrivez la règle relative à l’IA dans les consignes destinées au candidat. Demandez aux candidats d’indiquer les outils utilisés si ce contexte facilite votre revue, sans présenter cette déclaration comme une vérification de la paternité du travail. Les preuves reposent toujours sur ce qu’ils peuvent expliquer, tester, réviser et assumer.

GitHub reste utile, car le code public et l’historique des revues peuvent rendre certains comportements d’ingénierie observables. Ce qui ne fonctionne plus, c’est de traiter l’activité cumulée comme une note. Sélectionnez un échantillon de travail, appliquez les six mêmes critères, proposez une voie équivalente pour l’expérience confidentielle et intégrez les preuves à une décision structurée.

Vous souhaitez assurer la même traçabilité des preuves pour chaque candidat à un poste d’ingénierie ? Démarrez votre essai gratuit, puis intégrez la revue du portfolio ou de l’exercice à votre processus de recrutement.