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.

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

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 !

Depuis quelques jours, un outil open-source retient l’attention sur les réseaux sociaux. Son nom : Scrapling. Piloté par des agents IA OpenClaw, il serait capable de contourner toutes les protections anti-scraping du web. Alors, nouvelle crainte disproportionnée ? Cloudflare, en tout cas, prend le sujet très au sérieux.

En 2025, les équipes ont boosté leur fréquence de livraison en misant sur l’automatisation, des cycles plus courts et une organisation agile renouvelée. Ce basculement dépasse les aspects techniques : en 2026, il redéfinira la qualité, la coordination et les business modèles mêmes qui sous-tendent l’innovation.

Une accélération structurelle du rythme de développement

En développement logiciel, les chiffres parlent d’eux-mêmes. Prenons l’exemple du commit.  Cette étape du cycle de développement logiciel est critique. Elle permet aux développeurs de sauvegarder leurs progrès au fur et à mesure et de partager leurs changements avec d’autres membres de l’équipe.

En 2025, la principale plateforme de développement logiciel open source a enregistré 986 millions de commits ¹, soit presque un milliard de modifications poussées en un an. Dans le même temps, les développeurs ont créé plus de 230 dépôts par minute ². Ces chiffres montrent bien que le développement s’inscrit désormais dans un flux permanent où la frontière entre “en cours” et “livré” s’efface.

Une fréquence de développement plus élevée

Ce mouvement d’accélération s’accompagne d’un recul des cycles longs. Les livraisons trimestrielles, longtemps dominantes, ne constituent plus le standard dynamique du secteur. Les travaux DORA montrent que les équipes les plus performantes déploient à fréquence élevée, en petits lots, avec de meilleurs résultats de stabilité ³.

Et ce n’est pas un détail. Ce rythme réduit le coût du diagnostic, facilite le retour-arrière et rend les régressions plus rapides à isoler. La dynamique est visible dans les contributions : toujours sur la même plateforme, leader sur le marché du développement logiciel open source, les équipes ont fusionné  43,2 millions de pull-requests par mois en moyenne en 2025, soit une hausse d’environ 23 % ^4.

Les développeurs ne livreront plus jamais comme avant

Ce changement ne relève plus d’un choix méthodologique. Il s’agit d’un mouvement structurel. Cette mutation transforme radicalement la mise en production. L’exemple des feature flags est très parlant. Les feature flags jouent un rôle central dans les déploiements incrémentaux : ils permettent d’activer ou de suspendre une fonctionnalité sans risque majeur, à la manière d’un interrupteur On/Off, et sans déploiement de nouveau code.

Avec un marché en nette croissance, ils s’imposent comme une infrastructure privilégiée pour l’itération ⁵. En pratique, ils deviennent un amortisseur indispensable lorsque les équipes poussent plusieurs fois par jour.

Une automatisation accrue

L’automatisation suit la même trajectoire. Les pipelines CI/CD déclenchent tests, builds et scans de sécurité à chaque push. Dans de nombreuses organisations, la part des déploiements manuels recule nettement au profit d’exécutions automatisées ⁶. Les pull-requests se raccourcissent, gagnent en lisibilité et réduisent la fatigue de revue. Le pipeline est devenu le centre de gravité.

La progression est visible de manière très nette dans les tests : sur la même plateforme, leader du marché de l’open source, l’utilisation de l’outil permettant d’automatiser tous les workflows (créer, tester et déployer en CI/CD) a  connu une hausse d’environ 35 % ². L’automatisation est essentielle pour absorber la cadence et soutenir la continuité du delivery.

Un cycle d’innovation plus court

Ce basculement vers les petits lots entraîne des conséquences majeures sur le cycle d’innovation. La capacité à pousser des évolutions fréquentes réduit le time-to-market et accélère la boucle entre hypothèse, test et validation. Les équipes peuvent expérimenter plus tôt, ajuster plus vite, et réduire le coût de l’erreur grâce au découpage des risques.

Cette granularité soutient une innovation continue plutôt qu’un séquençage en phases séparées. Les implications business en termes d’agilité sont directes. Les organisations capables de livrer en flux gagnent un avantage de vitesse qui crée une asymétrie concurrentielle. Une nouvelle fonctionnalité peut être testée en production auprès d’un segment restreint, évaluée, puis élargie sans attendre un cycle de release.

Réactivité accrue aux besoins du marché

Le modèle même de création de valeur évolue : on ne produit plus du logiciel en blocs, mais en enrichissements successifs. Ce détail compte. Il favorise des stratégies produit plus opportunistes, plus réactives et mieux alignées sur des comportements utilisateurs changeants.

Enfin, cette continuité impacte la structuration des éditeurs. Elle pousse à investir dans des chaînes d’outillage plus robustes, dans des pratiques d’observabilité avancées et dans une orchestration plus fine des expérimentations. L’innovation ne repose plus seulement sur l’idée : elle dépend du système qui permet de la déployer, de la mesurer et de la retraiter rapidement.

2025 a marqué une transition nette vers des workflows plus fragmentés, plus rapides, plus automatisés. En 2026, ce mouvement devrait perdurer voire s’amplifier. L’IA est passée d’un “nice to have” à une partie intégrante du travail de la plupart des développeurs.

De ce fait, les équipes ont commencé à éliminer les outils qui ajoutent de la friction pour ne conserver que ceux qui améliorent réellement la productivité ³. Mais le rapprochement entre documentation, pipelines et code laisse penser que cette continuité pourrait encore s’intensifier. En 2026, ce nouveau rythme va contribuer à amplifier l’agilité des entreprises et accélérer l’innovation.

Photo : © DR

The post { Tribune Expert } – En 2026, l’accélération du développement  logiciel va propulser l’innovation appeared first on Silicon.fr.

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

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.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/gh-aw-github-agents-ia-pipelines/gh-aw-github-agents-ia-pipelines-1.mp4">lien vers la vidéo</a>.

À l’heure du codage par IA, il est d’autant plus important de s’assurer que les contributeurs comprennent ce qu’ils proposent.

Un des ateliers de la FOSDEM 2026 a abordé cet aspect. Le contexte : une réflexion au sujet de la charge qui pèse sur les mainteneurs de projets open source.

Référence y est faite dans une discussion sur GitHub. Avec une question : que pourrait faire la plate-forme pour motiver les contributeurs à passer du temps sur les explications (descriptions de problèmes et de features) plutôt que sur la soumission de code ?

Là n’est cependant pas le thème principal de cette discussion. À travers elle, GitHub fait plutôt part de ses perspectives concernant la gestion des PR.

À court terme, il propose aux mainteneurs des options pour les désactiver complètement, les restreindre aux collaborateurs et les supprimer depuis l’UI.

Sur le long terme, GitHub envisage une solution « intermédiaire » permettant de conditionner l’ouverture de PR au respect de critères. Il songe aussi à exploiter l’IA pour évaluer le respect des standards/guidelines des projets.

Pour les guidelines, la source de vérité pourrait être le fichier CONTRIBUTING.md.

GitHub invité à envisager la désactivation automatique de Copilot

Beaucoup de projets veulent partager du code sans créer un entonnoir de contributions publiques, confirme un participant qui approuve les perspectives à court terme. Les mesures de contournement actuelles – des bots qui ferment les PR – ajoutent du bruit et sont peu intuitives, précise-t-il. Et de suggérer, concernant la vision à plus long terme, de pouvoir faire la différence entre contributeurs passagers et contributeurs externes de confiance sans avoir à donner d’accès collaborateur complet.

On suggère aussi à GitHub de quoi restreindre les contributeurs « nouveaux » – par exemple, dont la première interaction remonte à moins de 48 heures – à un seul PR. Ou encore d’obliger la liaison de tout PR à un ticket ou à une discussion.

Sur le volet IA, on suggère à GitHub un système de seuils configurables au niveau du dépôt ou de l’organisation. Et la désactivation automatique de Copilot sur les repos dont la politique interdirait l’usage.

Illustration générée par IA

The post GitHub cherche à alléger la charge du code généré par IA appeared first on Silicon.fr.

Autre chiffre communiqué. la croissannce de GitHub Copilot auprès des développeurs. Les abonnements Copilot Pro+ pour développeurs individuels ont bondi de 77 % en un trimestre. La plateforme comptabilise désormais plus de 4,7 millions d’abonnés payants à Copilot, soit une croissance de 75 % sur un an.

The post Microsoft 365 Copilot atteint 15 millions d’utilisateurs appeared first on Silicon.fr.

Le fonds d’investissement Andreessen Horowitz (a16z) vient d’annoncer une levée colossale dépassant légèrement 15 milliards de dollars. Un montant qui représente plus de 18 % de l’ensemble du capital-risque distribué aux États-Unis durant l’année 2025, selon les déclarations de Ben Horowitz, cofondateur de la firme. Cette nouvelle injection propulse a16z au-delà de 90 milliards de ... Lire plus

Le géant des processeurs graphiques déploie une offensive majeure dans la robotique généraliste au CES 2026. Son approche vise à reproduire le succès d’Android dans la téléphonie mobile en s’imposant comme plateforme incontournable pour les machines intelligentes. L’entreprise californienne dévoile simultanément des modèles fondamentaux, des environnements de simulation avancés et du matériel optimisé pour la ... Lire plus