Hier, en discutant avec un ami, j'ai évoqué un phénomène : la quantité de PR d'une bibliothèque open source qu'il maintient a doublé au cours des trois derniers mois, mais le temps qu'il consacre à la revue a en fait diminué.

Ce n'est pas par paresse, mais parce qu'il ne peut tout simplement pas tout voir, et beaucoup de PR semblent être générées par IA, leur logique étant cohérente, mais il y a toujours quelque chose qui cloche.
Il a dit une phrase qui m'a beaucoup marqué : « Maintenant, ceux qui soumettent du code ne doivent pas en assumer les conséquences, mais ceux qui fusionnent le code oui. »
Cette phrase met en lumière le problème central : dans la collaboration open source, le risque est asymétrique entre contributeurs et réviseurs.
Le contributeur qui soumet une PR avec une erreur endommage la réputation du projet et le temps nécessaire pour corriger les bugs plus tard ; tandis que le réviseur, même en travaillant bénévolement jusqu'à l'épuisement, ne reçoit aucune compensation.
Cette asymétrie est amplifiée à l'ère du codage par IA : générer du code devient trop facile, mais la vérification reste très difficile.
MergeProof cherche à résoudre cette asymétrie.
Il permet aux contributeurs de déposer une caution lors de la soumission d'une PR pour signifier « Je pense que ce code ne pose pas de problème », et si le réviseur trouve une vulnérabilité, la caution devient une récompense ; si personne ne trouve de problème, l'argent est remboursé, c'est aussi simple que ça.
Mais derrière cette simplicité se cache une transformation fondamentale : la revue de code passe du « comportement altruiste basé sur la réputation » à une « action économique basée sur l'incitation ».
Vous ne pouvez pas compter sur la bonne volonté des autres pour faire la revue, vous devez simplement miser sur votre code, et naturellement, certains vérifieront pour en tirer un bénéfice.
Plus j'y pense, plus je pense que c'est peut-être la couche manquante dans la collaboration open source.
Aujourd'hui, tout le monde dit que le Web3 doit introduire des incitations économiques dans divers scénarios, mais l'approche choisie par MergeProof est très précise : elle ne crée pas un nouveau processus, elle ajoute simplement un mécanisme de jeu à l'existant.
Les contributeurs peuvent prouver leur confiance, les réviseurs peuvent monétiser leur temps, et les projets obtiennent un code de meilleure qualité, tous en bénéficient.
De plus, cela est particulièrement adapté à cette explosion de codage par IA : lorsque la quantité de code commence à croître de façon exponentielle, compter uniquement sur « l'esprit bénévole » ne suffit plus pour la revue, et l'incitation économique pourrait être la seule solution scalable.
Après un certain temps, je sens que cela pourrait changer progressivement la façon dont la collaboration logicielle fonctionne.
Au moins, cela m'a amené à me poser une question : si j'ai vraiment confiance en mon code, est-ce que j'ose miser dessus ?