💻 computer science

A Global Author-Identity Map for the World of Code:62.7M Developer Identities from 106.8M Author Strings over 5.87B Commits

Cet article présente une carte d'identité d'auteur mondiale, hautement précise et organisée, pour le World of Code (V2604), qui résout 106,8 millions de chaînes d'auteurs en 62,7 millions d'identités canoniques à travers 5,87 milliards de commits en privilégiant la prévention du « regroupement » erroné plutôt que le simple rappel, améliorant ainsi considérablement la fiabilité de l'analyse de dépôts de logiciels à grande échelle et des jointures de graphes d'auteurs académiques.

Auteurs originaux : Audris Mockus

Publié 2026-07-08

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Audris Mockus

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez l'histoire entière du développement de logiciels comme une immense et chaotique bibliothèque contenant près de 6 milliards de livres (commits de code). Dans cette bibliothèque, chaque fois que quelqu'un écrit une page, il signe de son nom. Mais voici le problème : les signatures sont un désordre total.

Une personne peut signer en tant que « Jane Doe », puis « j.doe », puis « jane.doe@work.com », et plus tard en tant que « jane@personal.org ». Pendant ce temps, mille inconnus différents pourraient tous signer leurs pages en tant que « root », « user » ou « Votre Nom ».

Si vous essayiez de compter combien d'auteurs uniques il y a en regardant simplement ces signatures, vous obtiendriez une réponse totalement erronée. Vous penseriez qu'il y a des millions de personnes de plus qu'en réalité (parce qu'une personne ressemble à dix) ou bien vous manqueriez de voir que certains « gens » sont en fait des robots ou des bots.

Ce document présente une Carte d'Identité Géante qui nettoie cette bibliothèque. Elle prend 106 millions de signatures désordonnées et les organise en 62,7 millions de vraies personnes.

Voici comment ils ont procédé, en utilisant des analogies simples :

1. Le Problème : Le Piège du « Méga-Cluster »

Les auteurs expliquent que les tentatives précédentes pour résoudre ce problème étaient comme essayer de coller des pièces de puzzle en se basant uniquement sur la couleur. Si vous dites simplement : « Si deux noms partagent une lettre commune ou un e-mail, ils doivent être la même personne », vous finissez par coller des millions de personnes sans lien entre elles en un seul bloc géant et monstrueux.

Ils appellent cela un « Méga-Cluster ». Imaginez une bibliothèque où, parce que tout le monde a utilisé le mot « Le » dans son titre, le bibliothécaire a décidé que chaque livre du bâtiment avait été écrit par la même personne. C'est ce qui s'est passé avec les anciennes cartes : ils ont accidentellement fusionné 3 millions de développeurs sans lien en un seul « super-auteur » géant.

2. La Solution : Un Pipeline de Détective en Six Étapes

Pour corriger cela, les auteurs ont construit un processus de détective en six étapes pour trier les signatures sans commettre cette erreur géante :

Étape 1 : L'indice initial : Ils commencent par lier les signatures qui partagent des éléments évidents, comme la même adresse e-mail exacte.
Étape 2 : Le filtre des « Mauvais Acteurs » : Ils ignorent les noms qui sont clairement génériques (comme « root » ou « admin ») ou qui appartiennent à des robots. Ce sont comme des « fantômes » dans la bibliothèque ; ils ne devraient pas être utilisés pour connecter de vraies personnes.
Étape 3 : La Coupe Structurelle (Le Tour de Magie) : C'est l'étape la plus importante. Ils ont regardé les connexions comme une carte de ponts. Ils ont trouvé quelques signatures « ponts » spécifiques qui maintenaient ensemble de grands groupes de personnes sans lien entre elles. Ils ont coupé ces ponts. Cela a instantanément dissous le géant « Méga-Cluster » en groupes plus petits et gérables.
Étape 4 : Le Classificateur Intelligent : Ils ont utilisé un programme informatique (entraîné sur des millions d'exemples réels) pour décider si deux noms similaires sont en fait la même personne ou juste une coïncidence (comme deux personnes nommées « John Smith »).
Étape 5 : La Récupération du Rappel : Après avoir coupé les mauvaises connexions, ils ont soigneusement réajouté certaines connexions qu'ils avaient précédemment ignorées, en utilisant une méthode différente (en regardant comment les noms sont épelés par morceaux) pour s'assurer qu'ils n'oubliaient pas trop d'amis réels.
Étape 6 : L'Étiquetage Final : Ils ont choisi la « meilleure » version de chaque nom (généralement celle avec un vrai nom et un vrai e-mail) pour qu'elle soit l'ID officiel de cette personne.

3. Pourquoi cela compte : Le « Facteur Bus » et la Productivité

Le document montre que si vous ne corrigez pas ces noms, votre calcul est faux. Ils ont mené plusieurs expériences pour montrer la différence :

Compter les Personnes : Sans corriger les noms, la bibliothèque semble contenir 66 % d'auteurs de plus qu'en réalité. C'est comme compter la même personne 10 fois parce qu'elle a signé de 10 manières différentes.
Sécurité des Équipes (Le Facteur Bus) : Imaginez un projet où vous devez savoir : « Si une personne se fait renverser par un bus, est-ce que le projet meurt ? »
- Sans corriger les noms : Le projet semble sûr car le travail est réparti sur 10 « noms » différents.
- Avec la correction des noms : Vous réalisez que ces 10 noms appartiennent en fait à une seule personne. Le projet est en réalité en grand danger.
- Le Résultat : Le document a découvert que 96 % des projets dépendent réellement d'une seule personne (un point de défaillance unique), alors que les données désordonnées faisaient croire que seulement 90 % le faisaient.
Centralité (Les personnes les plus « importantes ») : Dans les données désordonnées, les personnes les plus « importantes » dans le réseau étaient souvent des robots ou des comptes génériques (comme « root »). Une fois les noms corrigés, les personnes les plus importantes étaient de véritables développeurs humains.

4. La Vérification du « Standard d'Or »

Les auteurs n'ont pas seulement deviné ; ils ont testé leur carte contre deux « clés de correction » différentes :

Examen Humain : Un petit groupe d'humains a vérifié si la carte était correcte.
Données GitHub : Ils ont utilisé les données des comptes GitHub pour voir s'ils trouvaient tous les alias.

Ils ont constaté que leur nouvelle carte est 88 % précise (elle mélange rarement des inconnus) et 70 % complète (elle trouve la plupart des alias). Crucialement, ils ont prouvé que les anciennes cartes semblaient parfaites (95 % de précision) uniquement parce qu'elles ignoraient les géants « Méga-Clusters » où se cachaient les erreurs.

5. Connecter le Code à la Science

Enfin, le document suggère que cette carte peut servir de « clé universelle » pour connecter les développeurs de logiciels aux chercheurs académiques. Comme beaucoup de personnes écrivent à la fois du code et des articles scientifiques, cette carte pourrait aider à lier la recherche d'un développeur à ses articles de recherche. Cependant, ils préviennent que c'est très difficile car les noms sont très courants (par exemple, « John Smith » dans le code et « John Smith » dans un article) et qu'il faut être extrêmement prudent pour ne pas lier accidentellement les mauvaises personnes.

Résumé

Ce document est un guide pour nettoyer une base de données massive et désordonnée d'auteurs de logiciels. Il prouve qu'ignorer le désordre mène à des conclusions erronées sur qui travaille, quelle est leur productivité et quel est le niveau de sécurité des projets. Leur nouvelle carte est la première qui réussit à éviter le piè par lequel on tombe en collant des millions d'inconnus pour en faire une identité unique et fausse.

Résumé Technique : Une Carte Mondiale de l'Identité des Auteurs pour le Monde du Code

1. Énoncé du Problème

L'article traite du défi fondamental de la résolution de l'identité des auteurs à l'échelle mondiale des dépôts de logiciels. Dans le « Monde du Code » (WoC - World of Code), un développeur utilise souvent plusieurs chaînes de noms/e-mails (alias), tandis qu'une même chaîne (par exemple, root@localhost ou Votre Nom <vous@exemple.com>) est fréquemment réutilisée par des milliers de développeurs distincts.

La difficulté centrale réside dans l'équilibre entre le rappel (fusionner tous les alias d'une même personne) et la précision (éviter la « sur-fusion » de personnes sans lien). Les auteurs soutiennent qu'une union transitive naïve basée sur des attributs partagés (par exemple, un e-mail ou un nom commun) crée des « méga-clusters » — des clusters uniques contenant des millions d'identités sans rapport. Ces clusters corrompent silencieusement les analyses en aval (par exemple, le décompte des développeurs, la productivité, les facteurs de bus) et rendent les mesures de précision dénuées de sens si la région de confusion n'est pas mesurée. Les cartes mondiales précédentes atteignaient un rappel élevé mais souffraient de sur-fusions massives, tandis que les benchmarks axés uniquement sur le rappel ne parvenaient pas à pénaliser cette confusion.

2. Méthodologie

Les auteurs présentent un pipeline de construction en six étapes conçu pour produire une carte d'identité exempte de méga-clusters. Le processus est piloté par une séquence d'opérations de « filtrage » (gating) et de « découpe » (cutting) afin d'éliminer la sur-fusion avant de tenter de récupérer le rappel.

Génération de Liens : Des candidats aux liens « même personne » sont générés sur la base de correspondances exactes d'e-mails, de noms ou de handles rares partagés. La fermeture transitive de ces liens forme un graphe d'union brut.
Filtrage par Valeur : Les identités possédant des attributs non identifiants (noms génériques, e-mails de substitution, comptes de bots) sont neutralisées pour qu'elles ne puissent pas agir comme des ponts de fusion. Cela est fait via une analyse de la dispersion des noms et des vérifications de fréquence ou de listes noires.
Filtrage Structurel (L'étape critique) : Pour dissoudre le méga-cluster restant, les auteurs calculent la centralité d'intermédiarité échantillonnée (sampled betweenness centrality) sur le graphe d'union exact. Ils identifient et coupent un petit ensemble d'identités « ponts » à intermédiarité élevée (environ 2 000 ID) qui soudent des communautés autrement disjointes. Crucialement, 98 % de ces ponts sont « propres au niveau des attributs », ce qui signifie qu'ils ne peuvent pas être éliminés par de simples règles basées sur la valeur.
Classification des Liens : Un classificateur logistique, entraîné sur 2,6 millions d'étiquettes d'ID GitHub libres, évalue les paires candidates au sein des composants restants. Il élimine les soudures d'homonymes résiduelles (par exemple, différentes personnes nommées « John Smith ») que la coupe structurelle avait isolées.
Récupération du Rappel : Une fois le méga-cluster dissous, le pipeline étend en toute sécurité le rappel. Il active une couche de « shingle » dormante (liens basés sur des jetons de noms/e-mails partagés) ainsi que les assertions noreply de GitHub. Ces liens sont évalués par le classificateur et admis selon des seuils ajustés (par exemple, $\tau=0,9$ pour l'expansion par paire, $\tau=0,8$ pour l'expansion au niveau de la carte).
Sélection de Représentants et Classification : Un représentant canonique est sélectionné pour chaque cluster selon des règles de qualité (favorisant les vrais noms et les e-mails non génériques). Une classification par identité est assignée (bonne, mauvaise par attribut, locale, bot, partielle). Enfin, une couche de résolution intra-projet résout les ID de faible qualité qui sont ambigus globalement mais univoques au sein d'un projet spécifique.

3. Contributions Clés et Artefacts

L'article publie WoC V2604, une carte d'identité d'auteur curatée couvrant 5,87 milliards de commits et 106,8 millions de chaînes d'auteurs, regroupées en 62,7 millions d'identités canoniques. La publication inclut quatre artefacts co-versionnés :

a2AFull (Carte Globale des Alias) : Associe les chaînes brutes aux ID canoniques. Elle est exempte de méga-clusters ; le plus grand cluster contient 6 910 ID (une seule identité noreply de GitHub), contre un méga-cluster de 3 millions d'ID dans la carte précédente.
A2clsFull (Classification par Identité) : Étiquette chaque ID avec une classe de qualité :
- Good (Bonne) : Nom et e-mail réels.
- Bad-by-attribute (Mauvaise par attribut) : Noms génériques ou attributs partagés/de substitution.
- Local (Locale) : Adresses machine-locales avec de vrais noms d'utilisateurs.
- Bot (Robot) : Comptes automatisés.
- Partial (Partielle) : Bons attributs mais composante manquante (nom ou e-mail).
P2aAFull (Résolution Intra-Projet) : Résout 5,3 millions d'ID ambigus au sein du projet spécifique où ils apparaissent, récupérant 47,8 % du pool de commits de faible qualité laissé non résolu par la carte globale.
c2AFull (Table de Commit-à-Identité) : Étiquette chaque commit avec son auteur résolu et un tag de provenance (g pour global, B pour bot, p pour intra-projet, s pour soi-même/non résolu), permettant aux utilisateurs de filtrer par qualité de résolution.

4. Résultats et Validation

Les auteurs valident la carte contre deux vérités de terrain indépendantes : un ensemble d'or évalué par des humains (ALFAA, centré sur OpenStack) et un benchmark de rappel à grande échelle (GitHub via les étiquettes de handles).

Compromis Précision vs Rappel : La carte publiée atteint un Rappel de 0,70 et une Précision de 0,88 sur l'ensemble d'or humain.
Regroupement (Clumping) vs Division (Splitting) : L'article introduit une distinction entre la division (échec de la fusion des alias) et le regroupement (fusion de parfaits inconnus).
- La version précédente de la carte WoC (V3) rapportait une précision de 0,95, mais celle-ci s'est effondrée à 0,52 lorsque son méga-cluster de 3 millions d'ID a été compté comme une seule erreur.
- La nouvelle carte réduit le plus grand cluster de 3 006 318 à 6 910, éliminant ainsi efficacement le « regroupement non mesuré » qui affligeait les benchmarks précédents.
Couverture des Commits : La carte résout 73,5 % de tous les commits en identités multiples. Lorsqu'elle est restreinte aux commits humains, la couverture atteint 98,17 % (carte globale + couche intra-projet).

5. Impact en Aval

L'article démontre que le choix de la méthode d'identité modifie fondamentalement les analyses de développeurs. Les auteurs comparent trois archétypes : Sous-fusion (chaînes brutes), Sur-fusion (union naïve) et Calibrée (cette carte).

Population de Développeurs : Les chaînes brutes gonflent le nombre de développeurs de 66,6 % (104M contre 62,7M).
Productivité : La sous-fusion sous-estime la production des développeurs prolifiques (le p90 des commits chute de 34 % dans les données brutes).
Réseaux de Collaboration : Les données brutes créent des liens spécieux où les alias d'une seule personne se lient à eux-mêmes. La gestion des alias supprime 32 % des arêtes dans le réseau de co-projet et révèle que 36,3 % des projets apparaissant comme multi-développeurs sont en réalité des développeurs uniques utilisant plusieurs identités.
Centralité : Dans les réseaux bruts, les nœuds de haute centralité sont souvent des bots ou des ID de substitution (ex: root, CI bots). La carte calibrée déplace ces classements vers de vrais développeurs, bien que les bots restent un défi pour les mesures de centralité.
Résilience des Équipes : Les données brutes créent un « faux sentiment de sécurité » concernant les facteurs de bus. La fusion des identités révèle que 96,48 % des projets dépendent d'un seul développeur indispensable (contre 90,15 % dans les données brutes), et 12 millions de projets précédemment jugés collaboratifs s'effondrent en un point de défaillance unique.

6. Signification et Impact Global

L'article soutient que le regroupement (clumping) est la contrainte limitante pour la résolution d'identité à l'échelle mondiale**, et non le rappel. La signification de ce travail réside dans :

Changement Méthodologique : Passer de benchmarks axés uniquement sur le rappel à une évaluation conjointe de la division et du regroupement, en mesurant explicitement la taille du plus grand cluster.
Intégrité des Données : Fournir un substrat « exempt de méga-clusters » qui empêche la corruption silencieuse des agrégats par auteur.
Liaison Trans-corpus : La carte sert de clé de jointure nécessaire pour lier les auteurs de logiciels aux dossiers académiques (ex: Semantic Scholar, OpenAlex). Les auteurs démontrent que sans la liberté vis-à-vis des méga-clusters, lier les identités logicielles aux articles académiques entraîne des faux positifs catastrophiques (ex: lier 3 millions de personnes à un seul article). Une étude pilote utilisant l'ancrage DOI a réussi à lier 7 246 auteurs canoniques avec une haute précision (1,05 ID académique par auteur), prouvant l'utilité de la carte comme fondation pour la résolution d'entités trans-domaines.

Les auteurs concluent que les choix de conception (filtrage, coupe de la topologie, classification, récupération du rappel) ont été imposés par les échements mesurés des alternatives plus simples, et que les artefacts résultants permettent des analyses corrigées des biais à une échelle auparavant inatteignable.