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.
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 1, 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 2. 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.
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é 3.
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.
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 5. En pratique, ils deviennent un amortisseur indispensable lorsque les équipes poussent plusieurs fois par jour.
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 6. 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 % 2. L’automatisation est essentielle pour absorber la cadence et soutenir la continuité du delivery.
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.
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é 3. 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.
* Tug Grall est Solutions Engineer chez GitHub
Sources
(1) GitHub, article Octoverse 2025 « What 986 million code pushes say about the developer workflow in 2025 » (2025) – The GitHub Blog
(2) The GitHub Blog – Plus de 230 dépôts créés par minute : GitHub Octoverse 2025 (2025)
(3) Fréquence de déploiement élevée et performance (DORA) : Accelerate State of DevOps Report 2024 –
(4) GitHub Octoverse 2025 – statistiques globales de dépôts (2025). The GitHub Blog
(5) Feature Flag Management Market Research Report 2033 –
(6) CD Foundation – State of CI/CD 2024 –
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 !
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.
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.
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.
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.
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 !
Dans un article publié le 18 février 2026, le média britannique The Register revient sur l'exaspération de nombreux modérateurs open source confrontés au fait de devoir vérifier et corriger des demandes de modification de code boostées par IA. Une gronde qui pousse bon nombre de projets à adopter des mesures de précaution.
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).
À 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.
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.
Satya Nadella, le CEO de Microsoft, a révélé pour la première fois que M365 Copilot compte 15 millions d’utilisateurs annuels. Ce volume exclut les fonctions de chat Copilot plus limitées, accessibles sans licence complète. La base d’utilisateurs exposée à l’IA Microsoft est donc plus large.
Le service coûte 30 $ par mois et par utilisateur (28 € en France pour l’offre « Grande entreprise »). Ce tarif s’ajoute aux licences Microsoft 365 existantes. Si le taux d’activation reste élevé sur l’année, Microsoft peut générer plusieurs milliards de dollars de revenus récurrents. L’éditeur présente Copilot comme une brique stratégique pour rentabiliser ses investissements massifs dans l’IA. Ces dépenses d’infrastructure visent à soutenir ses propres produits sur le long terme.
Microsoft souligne une forte pénétration de Copilot dans les grandes entreprises. Près de 70% des sociétés du Fortune 500 l’utilisent déjà ou ont lancé des déploiements. Cependant, plusieurs analyses nuancent ce constat. L’usage effectif reste souvent concentré sur des groupes pilotes. Les fonctionnalités IA demeurent parfois sous-exploitées par rapport au parc de licences acheté.
Microsoft généralise Copilot dans GitHub, Power Platform, Azure OpenAI et LinkedIn. L’éditeur crée ainsi un continuum d’assistants IA, du développeur au décideur métier.
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
L'article Andreessen Horowitz franchit un nouveau cap avec 15 milliards de dollars levés est apparu en premier sur Fredzone.
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
L'article Nvidia ambitionne de dominer l’écosystème robotique avec une stratégie inspirée d’Android est apparu en premier sur Fredzone.
« Signal Intelligence Platform
A sleek, modern web-based front-end for signal intelligence tools.
Unified interface for pager decoding, 433MHz sensors, ADS-B aircraft tracking, satellite monitoring, WiFi reconnaissance, and Bluetooth scanning.»
via https://korben.info/intercept-sigint-dashboard-rtl-sdr.html
— Permalink
Une liste organisée de projets, outils et bibliothèques open-source géniaux pour travailler avec les données publiques ouvertes (OGD) suisses. Le but de ce projet est de mettre en valeur les contributions de haute qualité des développeurs individuels et des créateurs indépendants qui manquent souvent sur d'autres listes.
The original GitHub repo does not exists anymore, but I think the Wayback Machine and some git forks out there can help you to find the code and/or knock command binary... 😇
The name comes from the D&D 5e spell for freeing locked items.
EDIT : Quelques autres ressources à ce sujet partagées sur un autre Shaarli : https://liens.vincent-bonnefille.fr/?LGo04Q#goto_FairesauterlesDRM
Has My Secret Leaked is a new product developed by GitGuardian to discover potential public leaks of your secrets:
ggshield hmsl
Has My Secret Leaked currently monitors GitHub public repositories (Commits, Gists and Issues).
Connexion