Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

Faux repos GitHub - Pourquoi c'est un problème

Vous avez peut-être vu ça passer y'a pas longtemps, les scientifiques ne savent plus démêler le vrai du faux dans leurs propres publications. À NeurIPS 2025 , 100 citations hallucinées ont été retrouvées dans 51 papiers acceptés et à l' ICLR 2026, sur plus de 75 000 reviews analysées, 21% étaient entièrement générées par IA.

Bienvenue dans le monde du doute permanent !

Maintenant, si vous pensez que ça ne concerne que les chercheurs, détrompez-vous car de mon côté, ce que j'observe, c'est que les faux repos GitHub, c'est le même fléau côté tech, et surtout un vrai problème pour tous ceux qui relayent des projets open source comme moi.

Vous avez peut-être vu passer mon article d'hier sur WiFi DensePose , un projet à 25 000 étoiles sur Github qui promettait de détecter les postures humaines via le signal WiFi. Le code Python est détaillé, crédible en surface, il y a des tas d'issues ouvertes avec de vraies questions d'utilisateurs différents, des tas de pull requests parfaitement crédibles, une documentation hyper léchée... et le tout est adossé à un vrai papier de recherche de Carnegie Mellon .

Pour moi, ça avait l'air carrément sérieux ! Donc j'en ai fait un article.

Sauf qu'après coup, différentes personnes ont creusé plus profondément le code (Merci Nicolas), et ont trouvé des choses assez étranges partout dans le code. En fait, le truc générait des données aléatoires en se faisant passer pour du traitement de signal WiFi. C'est du vibe coding à l'état pur et quand des gens ont posé des questions dans les issues... ces dernières ont été vite supprimées. Faut dire que le piège était quasi parfait.

Et c'est tout le problème ! Car pour évaluer si un projet GitHub est légitime, je me base sur plusieurs signaux. Le code, les issues et les PRs, le nombre de stars, la reprise sur Reddit ou Hacker News, les commentaires, les articles dans la presse et quand je peux (et là c'était pas le cas car ça demande pas mal de matos que j'avais pas), je teste évidemment... Mais du coup, quand TOUS ces signaux sont fabriqués de toutes pièces, y'a plus aucun repère !

Parce que figurez-vous que les étoiles Github, ça s'achète (y'a des services entiers dédiés à ça), les issues se génèrent par IA, le code compile, les tests passent, le README est nickel, et le développeur a d'autres projets crédibles sur son profil. Vraiment tout est conçu pour que ça fasse parfaitement illusion.

Et comme ce sont souvent des projets émergents sur des technos de pointe, y'a pas grand monde qui a le matos ni le temps de vérifier par soi-même. Du coup, voilà comment moi et d'autres, on se retrouve à relayer des projets bidon sans le savoir. Et dire que j'étais à 2 doigts d'acheter le matos pour tenter l'aventure...

Les chercheurs se fient au peer review, aux citations, à la réputation du journal et moi c'est pareil avec les stars, les contributions, et le relai médiatique. Sauf que dans les deux cas, l'IA a rendu ces marqueurs de confiance complètement bidons. C'est pour ça que je fais ce parallèle car de mon point de vue, c'est le même combat.

Et le pire, c'est que c'est même pas du code malveillant. Y'a pas de backdoor, pas de malware planqué, pas de minage crypto en douce. C'est juste du code qui donne l'ILLUSION de fonctionner, ou plutôt, qui PRÉTEND fonctionner. Tout ça apparemment pour faire ce qu'on appelle du "portfolio padding"... c'est-à-dire gonfler son CV de développeur avec des faux projets open source à des milliers de stars pour impressionner les recruteurs.

Perso, j'avoue ça me dépasse.

Maintenant, comme c'est nouveau pour tout le monde, il va falloir apprendre à éviter de tomber dans le panneau. J'y ai réfléchi un peu et finalement, ça passe par une analyse plus approfondie du code et de l'historique du projet... On peut par exemple vérifier le git log parce qu'un projet à 25 000 étoiles et 3 commits en 2 semaines, c'est louche, donc méfiance. Et surtout, faut chercher des retours d'utilisation concrets et des issues techniques pointues. Après encore faut-il avoir des compétences techniques assez poussées (par exemple en traitement du signal) pour capter ce qui y est raconté... Pas simple hein ?

Faudrait peut-être que je me fasse un skill un peu poussé pour qu'une IA soit capable de faire ce taf chiant à ma place. Je vais y réfléchir.

Bref, on est tous dans la même galère, à devoir douter de tout ce qui brille sur GitHub et ailleurs et ça c'est bien emmerdant.

CyberStrikeAI : cet outil dopé à l'IA automatise les cyberattaques

Un développeur chinois a mis en ligne CyberStrikeAI, une plateforme open source qui combine IA générative et plus de 100 outils offensifs pour automatiser les cyberattaques. En parallèle, un pirate amateur russophone a compromis plus de 600 pare-feu FortiGate dans 55 pays avec l'aide de DeepSeek et Claude, le tout en à peine cinq semaines. Les hackers aussi ont visiblement droit à leur copilote.

Un arsenal offensif piloté par l'IA

CyberStrikeAI est l'œuvre d'un développeur chinois qui se fait appeler Ed1s0nZ. L'outil, écrit en Go et publié sur GitHub, intègre plus de 100 outils offensifs : nmap, Metasploit, hashcat, mimikatz et bien d'autres. Le tout est piloté par des modèles de langage comme GPT ou Claude, qui se chargent de planifier les attaques, analyser les résultats et adapter la stratégie au fil de l'attaque. Le développeur a des liens avec Knownsec 404, une équipe de recherche en sécurité rattachée au ministère de la Sécurité d'État chinois via la CNNVD.

600 pare-feu tombés en cinq semaines

L'autre affaire est tout aussi parlante. Entre le 11 janvier et le 18 février 2026, un pirate russophone a compromis plus de 600 pare-feu Fortinet FortiGate dans 55 pays. Amazon Threat Intelligence a repéré la campagne et découvert un serveur mal sécurisé contenant plus de 1 400 fichiers : identifiants volés, scripts d'exploitation, logs d'attaque. Le pirate utilisait un serveur MCP baptisé ARXON et un orchestrateur en Go appelé CHECKER2, les deux s'appuyant sur DeepSeek et Claude pour automatiser le travail. Le pirate n'a même pas eu besoin d'exploiter de faille logicielle : des mots de passe faibles et des ports de gestion ouverts sur Internet ont suffi.

L'IA compense le manque d'expérience

Le pirate derrière les FortiGate n'est pas un vétéran : ses erreurs de sécurité opérationnelle, comme un serveur ouvert à tous les vents, trahissent un manque d'expérience flagrant. Sauf que l'IA a compensé. Là où il aurait fallu des années de pratique pour mener une campagne de cette envergure, les modèles de langage ont comblé les lacunes. CrowdStrike a d'ailleurs noté une hausse de 89 % des attaques assistées par IA en 2025. Et avec des outils comme CyberStrikeAI qui mettent l'arsenal offensif à portée de n'importe qui, ça ne va pas s'arranger.

Franchement, on n'est plus dans la théorie. L'IA offensive est devenue accessible, et les dégâts sont bien réels. Le problème, c'est que les garde-fous des modèles de langage sont toujours une passoire, et que tout le monde fait semblant de ne pas le voir.

Sources : cyberinsider , thehackernews

Spank - Donnez des petites fessées à votre MacBook quand il n'est pas sage

Filer des petites claques à son MacBook pour qu'il couine... c'est le genre de projet qu'on s'attend à trouver sur GitHub d'un Otaku sauf que là, c'est du sérieux... Enfin presque.

Spank (Ah ah !), c'est un petit binaire en Go qui exploite l'accéléromètre de votre MacBook Apple Silicon via IOKit HID qui dès qu'il détecte un choc physique sur la machine, joue un petit son.

Dans Spank, y'a 4 modes au choix. D'abord le mode "pain" par défaut qui balance aléatoirement une dizaine de clips audio de protestation quand vous lui mettez une baffe. Là ça va vous plaire un peu plus car il y a également le mode --sexy, qui lui, monte en intensité au fil des claques sur une fenêtre glissante de 5 minutes, avec 60 niveaux d'escalade (ouch !).

Et pour les fans de Master Chief, il y a le mode --halo qui joue les sons de mort du jeu. Et si rien de tout ça ne vous parle, --custom /chemin/vers/vos/mp3 vous permettra de balancer vos propres fichiers audio.

En fait, derrière ce délire, il y a une détection plutôt costaud. Notamment des algorithmes qu'on retrouve en sismologie (comme STA/LTA, CUSUM, kurtosis) qui analysent les données brutes du capteur du MacBook pour distinguer une vraie claque d'un mouvement de sac à dos.

Vous pouvez également régler la sensibilité avec --min-amplitude... de 0.05 g (un effleurement suffit) à 0.50 g (là faut le déglinguer !!). Par défaut c'est calé à 0.30 et ça se combine avec les modes, genre sudo spank --sexy --min-amplitude 0.2 pour un laptop ultra-réactif dans les petits cris.

Pour l'installer :

go install github.com/taigrr/spank@latest

ET sinon y'a aussi des binaires précompilés sur la page des releases, donc pas besoin d'installer Go sur votre machine. Et ça nécessite sudo parce que macOS protège l'accès au capteur matériel via IOKit donc faut lancer comme ceci : sudo spank dans le terminal.

D'ailleurs si vous voulez que votre Mac réagisse H24, y'a également un template launchd fourni (fichier .plist à coller dans /Library/LaunchDaemons/) pour le configurer en daemon au démarrage, un peu comme quand on doit automatiser d'autres outils macOS . C'est parfait pour piéger un collègue (Le 1er avril arrive bientôt !!!)... Le gars qui pose son café un peu fort à côté de l'ordi, va rougir assez vite...

Seul bémol, attention, ça ne marche pas sur Mac Intel. Faudra du Apple Silicon M2 minimum, car le capteur accéléromètre n'existe tout simplement pas sur les anciens modèles. Le binaire fait ~4 Mo tout mouillé, y'a pas de dépendances et c'est sous licence MIT.

Voilà voilà. Tapez pas trop fort quand même ! Après je crois qu'Apple va bientôt sortir de nouveaux MacBooks, donc c'est peut-être l'occasion aussi d'en changer... ^^

Merci à Lorenper pour la fessée... euh pour le lien !

Automatisez vos repos GitHub avec .github

Le dossier .github est un petit répertoire magique que vous avez sûrement déjà croisé à la racine de vos dépôts préférés. Il est là, non pas pour faire joli ou pour planquer vos secrets de fabrication (pour ça, y'a les secrets GitHub, hein), mais plutôt pour centraliser plusieurs fichiers de configuration reconnus nativement par la plateforme.

C'est un peu le centre de commande de votre repo. Et le truc qui est fort, c'est que si vous avez une organisation avec 50 projets, vous pouvez même créer un dépôt public spécial nommé .github qui servira à fournir des fichiers de santé communautaire et des templates par défaut pour tous les dépôts de votre organisation qui n'ont pas déjà leurs propres fichiers équivalents.

Et comme ça, dès qu'un dépôt a quoi que ce soit dans son propre .github/ISSUE_TEMPLATE/, il ne prendra plus les templates par défaut de l'orga.

Pratique pour les grosses flemmasses comme vous quoi !

Les templates d'Issues et de PR pour structurer les échanges

On a tous reçu une issue qui dit juste "ça marche pas". C'est relou, ça fait perdre du temps et on a envie de répondre par un gif de chat qui boude.

Alors pour éviter ça, créez un dossier .github/ISSUE_TEMPLATE/. Vous pouvez y coller des fichiers Markdown ou YAML pour encourager les gens à donner les infos de base (version de l'OS, étapes pour reproduire, etc.). Et faites pareil pour les Pull Requests avec un fichier PULL_REQUEST_TEMPLATE.md (à la racine, dans docs/, ou dans .github/, selon votre tambouille).

En gros, ça vous permet de guider vos contributeurs pour qu'ils ne fassent pas n'importe quoi.

GitHub Actions pour détecter les régressions

C'est LE grand classique !

Dans .github/workflows/, vous balancez vos fichiers YAML pour automatiser vos tests, votre linting ou vos déploiements. Bien sûr, pour vraiment ne pas "casser la prod", il faudra coupler ça à des règles de protection de branche (status checks requis) pour bloquer les merges si les tests échouent.

D'ailleurs, si vous voulez tester vos actions sans attendre la file d'attente des runners GitHub, je vous avais parlé de Wrkflw pour tester ça en local . C'est un outil tiers bien pratique pour valider vos workflows sur votre machine.

Les fichiers de "Santé Communautaire"

Si vous voulez que votre projet open source ressemble à autre chose qu'un champ de bataille au petit matin, il faut poser des règles.

GitHub reconnaît automatiquement des fichiers comme CODE_OF_CONDUCT.md, CONTRIBUTING.md ou même FUNDING.yml pour gratter quelques pièces pour votre café ;). Ce sont des fichiers qui aident à dire aux gens comment se comporter et comment vous aider efficacement sans avoir à surveiller votre voisin.

Guider Copilot avec des instructions sur mesure

C'est la petite nouveauté qui vous permet d'ajouter un fichier .github/copilot-instructions.md avec à l'intérieur, une liste de vos standards de code, vos libs préférées ou vos conventions de nommage.

Comme ça, hop, Copilot tiendra compte de ces instructions pour ses suggestions (même s'il garde parfois son petit caractère, hihi). Et vous pouvez même aller plus loin avec des fichiers NAME.instructions.md dans .github/instructions/ qui ciblent des dossiers specifiques via des patterns glob... à condition de mettre un frontmatter applyTo: au début, sinon Copilot les ignorera gentiment...

C'est parfait pour garder un code propre.

CODEOWNERS et Dependabot

Enfin, pour les projets qui commencent à prendre de l'ampleur, le fichier CODEOWNERS (placé dans .github/, ou à la racine, ou dans docs/... GitHub prend celui de .github/ en premier s'il y en a plusieurs) permet de définir qui est responsable de quelle partie du code. Dès qu'une PR touche à un fichier sensible, GitHub demande automatiquement la review aux bonnes personnes.

Et n'oubliez pas .github/dependabot.yml pour que l'outil vous ouvre des pull requests dès qu'une dépendance est à la bourre.

On automatise le bien relou pour ne garder que du criss de fun !

Voilà les amis, si vous aimez bidouiller vos dépôts pour qu'ils tournent tout seuls ou presque et garder un semblant d'organisation, ce dossier .github sera votre meilleur poto !

Source

gh-aw - GitHub lâche des agents IA dans vos pipelines

Bonne nouvelle pour tous les dev qui n'ont pas peur de l'IA : GitHub vient de sortir gh-aw, une extension CLI qui permet d’écrire des workflows agentiques… en markdown. Au chiotte le YAML à rallonge pour vos pipelines CI/CD, vous rédigez vos instructions en langage naturel et c'est une IA (Copilot, Claude ou Codex au choix) qui se charge de les exécuter dans GitHub Actions.

En gros, vous décrivez ce que vous voulez dans un fichier .md, genre"em>fais-moi un rapport quotidien des issues ouvertes" ou "refactorise les fonctions trop longues", et l'agent s'en occupe. Il analyse le contexte de votre dépôt, prend des décisions et livre le résultat sous forme de pull request. Par contre, attention, si votre prompt dans le fichier .md est trop vague genre "améliore le code ", l'agent risque de partir dans tous les sens et vous pondre une PR de 200 fichiers. Faut être précis dans vos instructions, sinon c'est la loterie.

Côté sécurité, ils ont pas rigolé parce que lâcher une IA en roue libre sur votre code, ça pourrait vite tourner au cauchemar (J'en avais d'ailleurs parlé avec les backdoors planquées dans les fichiers de config ). Ici, tout est sandboxé avec des permissions en lecture seule par défaut sur le runner. Les opérations d’écriture passent par des "safe-outputs" préapprouvés, y'a de l'isolation réseau, du pinning SHA sur chaque dépendance npm/pip… Bref, ils ont pas fait les choses à moitié, côté garde-fous.

Côté moteurs IA, vous avez le choix entre GitHub Copilot, Claude d'Anthropic (via l'API, faut un compte payant), OpenAI Codex ou même votre propre processeur custom. Claude pour du refactoring ça peut être pas mal je pense parce que la fenêtre de contexte est capable d'avaler un dépôt entier, mais pour du triage d'issues, Copilot suffira largement. Comme d'hab, ça dépend de vos besoins (et de votre portefeuille).

❌