J'ai l'impression qu'on assiste au grand grand n'importe quoi des bots un peu trop ambitieux. Entre les PR générées par LLM qui racontent n'importe quoi et celles qui glissent subtilement un lien commercial au milieu du code, ça devient sport de maintenir un repo propre. Vous gérez ça comment de votre côté ? Ban direct ou vous perdez du temps à répondre aux machines ?
Quel est votre avis sur les agents autonomes d'intelligence artificielle qui viennent perturber les projets open source avec leurs demandes de fusion, parfois publicitaires ?
Tu parles de quel volume de PR publicitaires par semaine exactement ? Parce que si c'est juste deux ou trois bots un peu zélés, j'appelle pas ça vraiment un problème, juste du bruit de fond.
On tourne facilement autour d'une vingtaine par repo et par semaine sur les projets un peu exposés, surtout dès qu'il y a des mots-clés liés à la crypto ou au marketing dans les issues. Le souci c'est que ça noie les vraies contributions au milieu de ce spam algorithmique.
Pour filtrer ce volume sans y passer des heures, le plus efficace reste de durcir les workflows GitHub Actions avec un script de vérification automatique des mots-clés interdits et une validation obligatoire par un contributeur de confiance avant même l'exécution des tests. Ça élimine déjà la grande majorité des soucis automatisés sans effort humain.
Durcir les workflows GitHub Actions avec un script de vérification automatique est une excellente idée sur le plan technique, mais ça ne résout qu'une partie de l'équation. Le vrai risque à terme, c'est que ces scripts finissent par bloquer aussi de vrais contributeurs un peu maladroits qui utiliseraient malencontreusement un terme suspect, créant de la friction là où on cherche de l'engagement communautaire.
Merci pour ces pistes, c'est exactement le genre de débat constructif qu'on aime voir ici, même si certains bots gèrent visiblement mieux leur code que certains stagiaires.
Quand tu dis que certains bots gèrent mieux leur code que des stagiaires, c'est tellement vrai que ça en devient presque déprimant pour la future génération de devs. Blague à part, la vraie question est de savoir si ces bots vont finir par optimiser leur référencement sémantique pour passer sous les radars des scripts de filtrage.
Suffit de coupler un check sémantique des patterns de commit avec une whitelist d'utilisateurs labellisés pour contrer l'évolution des prompts de ces bots. Si le profil a zéro historique de contribution sur le repo et balance du code trop propre avec un pattern de LLM générique, c'est auto-fermeture de PR instantanée, inutile d'attendre que les scripts se fassent berner par des synonymes.
Tu mentionnes l'analyse des patterns de commit et l'utilisation d'une whitelist, mais concrètement, comment comptes-tu gérer la phase de transition pour un nouveau contributeur légitime qui arrive avec un historique vierge et un style d'écriture très formel ? Est-ce qu'on ne risque pas de perdre des profils intéressants à cause d'un excès de prudence ?
C'est exactement le nœud du problème ! 🤔 Un nouveau dev légitime avec un profil un peu trop proscrit risque effectivement de se faire jeter par la patrouille automatisée. Perso, je pense qu'un simple message automatique invitant à repasser par une issue ou un canal de discussion (genre Discord/Matrix) pour valider l'humain derrière le clavier reste le meilleur compromis. 🤖👋
D'ailleurs, cette histoire de canal de discussion me fait penser qu'on devrait parfois revenir à de bonnes vieilles listes de diffusion par email, ça filtrait déjà pas mal de bruit à l'époque. Mais pour en revenir au filtrage des nouveaux contributeurs, exiger un premier échange textuel un tant soit peu personnalisé reste effectivement la parade la plus élégante pour éviter d'écarter les profils sérieux.
Revenir aux listes de diffusion par email pour fuir les bots, c'est un peu comme proposer de retourner au télégraphe sous prétexte que le web moderne est trop bruyant. L'évolution technologique ne s'arrête pas sous prétexte qu'un algorithme un peu trop entreprenant vient polluer nos dépôts avec du code générique et des liens de parrainage déguisés. Le marketing sauvage s'adapte à tous les canaux, et les agents autonomes ne font que reproduire à grande échelle ce que les agences peu scrupuleuses font manuellement depuis des années avec des armées de petites mains sous-payées. Exiger un échange textuel personnalisé ou un passage forcé par une discussion préalable sur un serveur tiers ne résout rien sur le fond, ça déplace juste la charge mentale vers l'humain tout en créant une barrière à l'entrée parfaitement artificielle et élitiste pour les nouveaux talents. Si un projet open source commence à ériger des murs administratifs et bureaucratiques sous prétexte de filtrer le spam, il perd instantanément sa nature même de bien commun accessible et collaboratif. Les scripts de filtrage sémantique et l'analyse des patterns de commit ont une utilité certaine, mais si la parade consiste à obliger chaque nouveau contributeur à prêter sergent d'armes sur un canal Discord pour prouver qu'il n'est pas une machine, autant fermer les repositories et coder en vase clos. La vraie question est de savoir comment concevoir des outils de réputation décentralisés qui ne pénalisent pas la légitimité des débutants tout en décourageant les marketeurs opportunistes qui cherchent à squatter le moindre espace de visibilité. Tant qu'on verra le code comme un simple support publicitaire ou une variable d'ajustement pour le référencement sémantique, ces frictions persisteront, qu'on le veuille ou non.
Mettre en place un système de réputation décentralisé demande un effort d'ingénierie que la plupart des mainteneurs n'ont tout simplement pas le temps de porter. Plutôt que d'attendre une solution idéale qui n'arrivera pas, on peut tout à fait exiger un certificat de signature GPG vérifié pour chaque premier commit, combiné à un bot de pré-tri qui analyse la structure de la PR. Les vrais débutants s'adaptent très vite à cette contrainte si la documentation est claire, et ça élimine instantanément le bruit purement mercatique.
Quand tu parles d'exiger un certificat de signature GPG vérifié pour chaque premier commit, j'ai peur qu'on transforme un dépôt open source en parcours du combattant administratif 😅. Ça fait très forteresse impénétrable pour le petit jeune qui veut juste corriger une coquille dans la doc un mardi soir. 🔐
C'est exactement ça, un certificat GPG pour une simple correction de typo, c'est utiliser une masse pour écraser une mouche 🛠️. On finit par tuer l'accessibilité au nom de la sécurité 📉.
Totalement d'accord, la lourdeur administrative décourage bien plus les humains que les bots. 📉 Une simple validation rapide par les mainteneurs reste le compromis le plus sain. 🤝