Par Rédaction IP73 dans Développement
le 29 octobre 2026
L’écosystème des développeurs sur GitHub a connu une accélération spectaculaire en 2026. Les contributions de code ont atteint 17,9 milliards de pushes au cours des douze derniers mois, un chiffre qui dépasse la somme des années 2024 et 2025 confondues, selon les données publiées par GitHub. Ce bond n’est pas le fruit d’une simple croissance démographique, mais d’une transformation profonde des méthodes de travail. Les agents d’intelligence artificielle sont passés du statut de curiosité à celui d’outil de travail intégré, modifiant fondamentalement le rythme de production.
Les métriques montrent bien cette mutation. Parmi les nouveaux dépôts créés cette année, ceux qui incluent une configuration d’agent enregistrent en moyenne huit fois plus de commits que les dépôts équivalents qui n’utilisent pas ce type de configuration. C’est une donnée qui sonne fort : construire avec un agent dès le départ, c’est opérer à une vitesse différente.
L’intégration des agents réinvente le cycle de développement
L’adoption des agents est palpable dans les processus quotidiens. Au mois de septembre, plus de 40 % des demandes de tirage (pull requests) sont initiées en directive d’un agent. Rappelons que ce chiffre n’était qu’à 17 % en mars. L’agent n’est plus là pour suggérer une ligne de code ; il est en train de dicter la première action, laissant au développeur le rôle d’affinage et de validation finale.
Les contributeurs ne se contentent pas d’un seul modèle d’IA. En septembre, 61 % des utilisateurs de GitHub Copilot utilisaient plus d’un modèle, jonglant entre des modèles généralistes, des modèles de raisonnement profond et des modèles rapides et légers. Cette flexibilité est nécessaire pour aborder des problèmes aussi variés que le bulletin de crues en Népal, monté sur GitHub Pages, ou le développement de logiciels pour les sondes spatiales de la NASA.
On constate également une diversification impressionnante des domaines concernés. Pour la première fois, GitHub publie une ventilation par industrie, et les dépôts dans des secteurs comme l’agriculture, la construction, la santé et l’extraction minière ont tous vu leur volume croître plusieurs fois depuis 2022. Le travail est partout.
Une machine à vitesse record
Au-delà de la nouveauté apportée par l’IA, la cadence brute du développement est en hausse fulgurante. Les commits à travers tous les types de dépôts, qu’ils soient publics ou privés, ont grimpé à 34,3 milliards sur la période, soit plus du triple par rapport à deux ans auparavant. Les pull requests fusionnées ont également triplé, atteignant 1,3 milliard sur la même période, soit une moyenne de 3,5 millions par jour.
Pour soutenir cette vélocité, les mécanismes d’automatisation sont devenus des piliers. GitHub Actions a exécuté un travail 1 440 fois par seconde cette année, ce qui représente 124 millions d’exécutions par jour, soit plus du triple de l’année précédente. De plus, pour maintenir la sécurité en ligne, plus de 30 millions de demandes de Dependabot ont été fusionnées afin de mettre à jour les dépendances et limiter l’exposition aux vulnérabilités connues, doublant la cadence de 2025.
Ce rythme n’est pas uniforme. L’activité a démarré en janvier, mais a pris une envolée marquée autour de juin, lorsque, selon l’analyse des flux, une convergence de facteurs est apparue : l’amélioration des modèles sous-jacents, l’affinement des outils autour de ces modèles, et la capacité des agents à fonctionner de manière persistante, orchestrant des tâches sur plusieurs jours et utilisant intensivement le cloud.
La persistance des acteurs et les enjeux futurs
Ce mouvement massif n’est pas uniquement porté par les nouveaux projets. La persistance des contributeurs est notable. Les développeurs qui ont contribué au cours des douze derniers mois sont, en moyenne, sur GitHub depuis 36 mois. Par ailleurs, ceux qui ont ouvert une pull request en août ont plus de 75 % de chances d’avoir poussé du code en septembre. L’engagement se traduit aussi par une exploration plus large ; le développeur moyen travaille désormais sur 10 % de dépôts en plus qu’il ne le faisait un an auparavant.
L’impact sur l’open source est quantifié par une explosion des contributions publiques, qui ont atteint 2,5 milliards en 2026, soit plus du double de l’année précédente (1,12 milliard). Derrière ces chiffres, des contributeurs comme @kinlane, qui a généré plus d’un million de contributions en utilisant des flux de travail agentiques pour maintenir à jour un catalogue API, ou @kim-em, qui a maintenu la bibliothèque mathlib avec plus de 178 000 contributions, témoignent de cette nouvelle culture de contribution autonome.
Les projections de croissance de GitHub, initialement fixées sur cinq ans, sont désormais en phase de révision ; les modèles prévisionnels internes ne parviennent plus à converger sur l’évolution future, signalant une accélération imprévue de la courbe. Il faut observer comment les entreprises vont intégrer cette dynamique. Si l’open source montre une telle résilience et cette capacité d’auto-maintenance assistée par agents, la question demeure de savoir si ces gains de vélocité se traduiront par une réduction équivalente des coûts opérationnels dans les environnements d’entreprise, ou si le coût de l’orchestration de ces agents va simplement se répercuter en interne.
Par Rédaction IP73 dans Sécurité
le 29 octobre 2026
L’émergence de CVE-2026-97229, une vulnérabilité d’overflow ou de wraparound d’entier au sein des éditions Community et Enterprise de GitLab, est désormais officiellement cataloguée par la CISA comme étant exploitée activement. Cette faille, d’une gravité maximale (CVSS 10.0), permet à un utilisateur sans aucune authentification d’exécuter du code arbitraire directement sur le serveur GitLab, simplement en soumettant une expression régulière spécialement conçue dans une configuration CI/CD.
Les informations détaillées sur cette découverte proviennent de GitLab lui-même, qui a publié des correctifs critiques le 12 octobre 2026. L’impact est net : une validation insuffisante des expressions régulières dans le compilateur CI/CD est la cause racine. Les versions concernées sont toutes celles antérieures à 19.2.8, 19.3.5 ou 19.4.2, selon la branche.
Alpine Linux, qui utilise GitLab pour gérer son propre projet, a d’ailleurs récemment été visé, comme le rapporte The Hacker News. Bien qu’ils n’aient trouvé aucune preuve de succès de l’attaque, le fait que des acteurs malveillants tentent de tirer parti de cette lacune, même après que des correctifs aient été mis à disposition, témoigne de l’urgence de la situation. Il est difficile de ne pas y voir une attaque visant l’infrastructure source elle-même.
Ce qui est touché et la gravité réelle
La portée de cette faille est vaste, car elle ne requiert ni accès, ni privilège, pour déclencher l’exécution de code. C’est le scénario le plus redouté en cybersécurité. Les données techniques confirment que l’injection passe par une mauvaise gestion des types d’entiers lors du traitement des expressions régulières. De plus, le fait que la CISA l’ait hissée dans son catalogue KEV signifie que les agences fédérales américaines ont une échéance très courte, fixée au 1er novembre 2026, pour se conformer aux mesures de mitigation.
Ce n’est pas une question d’erreur de configuration utilisateur, c’est une défaillance fondamentale de la validation des entrées au niveau du moteur de compilation. On voit d’ailleurs que GitLab a déjà publié des détections de menaces pour aider les instances auto-hébergées à identifier les tentatives d’exploitation de CVE-2026-97229.
Que faire maintenant
La réponse n’est pas négociable. La recommandation affichée par GitLab est claire : migrer immédiatement vers les versions corrigées. Pour les utilisateurs qui gèrent eux-mêmes leur instance (auto-hébergement, self-managed), l’application des patchs est la seule voie viable pour éliminer le risque d’exécution de code non autorisé. Ceux qui ne disposent pas de la capacité d’appliquer ces correctifs doivent évaluer l’exposition de chaque actif sur Internet et, si aucune mitigation n’est disponible, envisager de cesser l’utilisation du produit, suivant les directives de la CISA.
Le maintien d’une bonne hygiène de sécurité passe par cette mise à jour rapide. Au-delà de cet incident, la présence de multiples failles critiques récemment corrigées par GitLab, comme celles concernant le Cross-site Scripting (CVE-2026-92883) ou les problèmes d’autorisation, confirme que ce type de plateforme complexe est une cible permanente.
NVIDIA a rendu disponible Nemotron 3.5 Transcribe, un modèle de transcription open-weight qui transforme l’enregistrement audio en texte exploitable, en intégrant la reconnaissance vocale, l’attribution des locuteurs, la traduction et la réponse aux questions audio en un seul point de contrôle. Ce modèle gère la transcription de 40 langues, traduit 31 d’entre elles vers ou depuis l’anglais, et identifie les locuteurs dans 13 langues. Il peut traiter des enregistrements allant jusqu’à une heure et étiqueter jusqu’à huit intervenants.
Le besoin de transcrire ne se limite plus à capturer les mots. Les réunions multilingues, les dictées médicales ou les appels rapides exigent des formats de sortie spécifiques : une traduction, des étiquettes de locuteur, ou une orthographe médicale précise. Nemotron 3.5 permet aux développeurs de guider ce résultat grâce à des instructions en langage naturel. On peut demander au modèle, par exemple : « Transcrivez cet enregistrement et étiquetez chaque orateur », ou « Traduisez cet audio en anglais ».
Ce modèle se distingue par ses performances mesurées. Sur le classement Open ASR de Hugging Face, il est le premier modèle open-weight pour l’anglais, affichant un taux d’erreur de mots (WER) moyen de 5,33 %. De plus, selon Artificial Analysis, il atteint un AA-WER de 2,8 % avec environ quatre milliards de paramètres actifs, ce qui le place sur la frontière de Pareto de l’exactitude par rapport aux paramètres utilisés.
L’adaptation par le pipeline Granary v2
Au-delà de la reconnaissance brute, NVIDIA a déployé Granary v2. Ce pipeline de données multilingues, disponible sur Hugging Face et ModelScope, permet une adaptation poussée du modèle. En utilisant les outils de réglage fin NeMo Speech, les développeurs peuvent définir la forme écrite exacte souhaitée. Une étude de cas médicale a montré que le taux d’erreur de mots a été réduit de 45,8 % en réglant le modèle sur des données spécifiques.
Le modèle permet également d’intégrer des connaissances contextuelles avant l’entraînement. Dans un contexte de santé, par exemple, un développeur peut spécifier : « Transcrivez cette discussion médicale dans sa langue originale. Termes possibles : HbA1c, metformin. Utilisez ces termes uniquement si l’audio les soutient. Préservez l’orthographe médicale standard. »
Performances sur les benchmarks spécialisés
En ce qui concerne l’attribution des locuteurs, Nemotron 3.5 se classe premier parmi les modèles open-weight sur le benchmark DAI-ASR-I18N de David AI. Il est également en tête sur le classement de VoiceArena pour la comparaison des systèmes. Pour les enregistrements longs, le modèle gère des sessions allant jusqu’à une heure.
Le modèle peut produire différents résultats à partir d’un même fichier – transcription, traduction ou réponse à une question sur le contenu. Cependant, comme pour tout système de traitement du langage, il est nécessaire de vérifier manuellement les noms propres et les changements de locuteurs avant toute intégration en production.
GitHub Copilot Fusion est désormais disponible. Au lieu de choisir un modèle spécifique pour chaque tâche de codage, les développeurs peuvent sélectionner Copilot Fusion et laisser l’outil router et orchestrer intelligemment les modèles nécessaires. Ce système combine l’orchestration de Project HydraFusion avec la sélection fine des modèles de Copilot, visant à équilibrer performance et efficacité des coûts.
En sélectionnant Copilot Fusion, l’utilisateur ne choisit pas un modèle unique. Il opte pour un système qui gère le routage pour chaque requête. Il n’est plus nécessaire de basculer manuellement entre les modèles ou de décider quel modèle convient à chaque étape. Pour chaque prompt, Copilot Fusion détermine quels modèles utiliser et comment ils doivent collaborer, laissant à l’utilisateur le choix du niveau d’effort requis.
Ce système propose trois niveaux d’effort : Fusion Standard, qui privilégie les modèles polyvalents pour le codage quotidien ; Fusion High, axé sur les modèles capables pour les tâches plus complexes ; et Fusion Max, qui utilise les modèles les plus performants pour les raisonnements les plus exigeants.
Les workflows d’exécution sont également modulables. Le mode « Single » utilise un seul modèle pour résoudre la tâche. Le mode « Cascade » permet à un modèle efficace de rédiger une ébauche, puis un contrôle qualité décide de l’accepter ou de l’escalader vers un modèle plus puissant. Enfin, le mode « Critique » implique qu’un modèle rédige une première réponse, tandis qu’un autre la révise avant que le premier ne la modifie.
Les résultats en termes d’efficacité sont notables. Selon GitHub, Copilot Fusion Max a obtenu un score de 60 dans l’Artificial Analysis Coding Agent Index, se rapprochant de Claude Code avec Opus 5.5 Max, qui est à deux points. Ce résultat est atteint avec des coûts API environ deux fois inférieurs par tâche, utilisant la moitié des jetons et nécessitant environ 40 % de temps en moins.
L’optimisation des dépenses est déjà observée sur le terrain. Hari Pokhrel, ingénieur logiciel principal chez AT&T, a souligné que « Copilot Fusion Standard a amélioré l’efficacité des jetons chez AT&T en sélectionnant automatiquement le bon modèle pour la tâche, réduisant les dépenses inutiles et préservant la capacité pour des travaux de plus haute valeur » (Hari Pokhrel, AT&T). Avant, les développeurs avaient tendance à sur-utiliser les modèles puissants pour des tâches simples, ce que Copilot Fusion élimine en gérant cette friction.
L’administration de ce système est fine. Les administrateurs peuvent définir quels modèles Copilot Fusion est autorisé à utiliser au sein de leur organisation. Ils peuvent même désactiver certains modèles pour Fusion sans retirer leur disponibilité pour tous les autres utilisateurs.
La facturation s’applique pour chaque modèle utilisé par Copilot Fusion, au tarif standard de ce modèle. Néanmoins, pour une période limitée, les utilisateurs abonnés à Copilot bénéficient d’une réduction de 30 % sur ces coûts.
Copilot Fusion est accessible dans Visual Studio Code, l’application GitHub Copilot, le CLI de GitHub et les IDE JetBrains. Il suffit de mettre à jour son client, de sélectionner Copilot Fusion dans le sélecteur de modèle et de choisir un niveau d’effort pour commencer à tester cette gestion automatisée des modèles.
Deux failles critiques dans PHP, CVE-2026-109618 et CVE-2026-109619, sont désormais cataloguées par la CISA comme étant activement exploitées, ce qui impose une réaction immédiate aux administrateurs système. Ces vulnérabilités permettent une exécution de code à distance (RCE) sans nécessiter d’authentification préalable. Palo Alto Networks, par exemple, a relevé la présence de plus de 22,6 millions d’instances potentiellement exposées à ces problèmes.
Le cœur du problème réside dans la gestion des erreurs liées à la mémoire en PHP. Concernant CVE-2026-109618, le mécanisme de sortie d’erreur en cas de dépassement de mémoire (OOM) via longjmp() laisse la mémoire de la requête dans un état non initialisé. Cela permet, selon les analyses de GitHub, à un attaquant de déclencher cet état pour exécuter des commandes. Un mécanisme similaire, au sujet de CVE-2026-109619, est au rendez-vous : un état global de la mémoire peut pointer vers des régions récemment libérées, permettant à des requêtes ultérieures de lire ou d’utiliser cet état obsolète.
Ces failles, toutes deux notées au CVSS 9,2, ne sont pas de simples problèmes de déni de service ; elles ouvrent la porte à une prise de contrôle complète du serveur. Des acteurs malveillants ont déjà réussi à chaîner ces failles PHP2Shell avec des vulnérabilités d’escalade de privilèges du noyau Linux, permettant d’atteindre le statut root, comme l’a rapporté Dream Research.
Ce qui est touché et la gravité réelle
Ce qui est touché, ce sont les applications hébergées sur des serveurs utilisant PHP, et plus spécifiquement les interfaces de gestion exposées à l’extérieur. Bien que les bonnes pratiques dictent de ne pas exposer ces interfaces à l’Internet, le fait qu’elles puissent l’être rend la portée globale. Palo Alto Networks indique que, même si seule une infime fraction de leur base installée dispose d’interfaces de gestion accessibles publiquement, c’est dans ces cas précis que le risque est maximal.
Le constat de la CISA est sans appel : le statut « exploitée activement » signifie que les outils d’attaque circulent déjà. On doit considérer que toute installation vulnérable est, en ce moment, un risque actif. Les failles sont validées sur des configurations standards, ce qui signifie que la porte est ouverte dès que la configuration de sécurité de base est contournée.
Que faire maintenant
L’unique mitigation complète, selon le rapport de GitHub, est de mettre à jour immédiatement vers une version de PHP qui contient le correctif. C’est une instruction claire, mais la mise à jour n’est pas toujours possible dans un environnement contraint. Dans ce cas extrême, une suggestion est de régler administrativement la limite de mémoire (memory_limit=-1) pour supprimer les limites prévisibles qui facilitent le déclenchement contrôlé de l’OOM, bien que ce ne soit qu’un pansement. De plus, il est conseillé d’appliquer des contrôles en amont : limiter la taille des requêtes multipart, réduire la profondeur d’imbrication des champs, et bloquer ces requêtes au niveau de la couche frontale avant qu’elles n’atteignent PHP.
Il est impératif de retirer tout accès Internet public aux interfaces de gestion. Si votre organisation utilise des solutions de sécurité comme Cortex XDR, les équipes de chasse aux menaces proposent des requêtes XQL pour surveiller les signes d’exploitation en cours.
Les agences fédérales américaines ont une échéance fixée au 29 octobre 2026 pour appliquer les mesures requises. Il faudra surveiller attentivement les prochaines annonces concernant les versions corrigées spécifiques à chaque SAPI, car la susceptibilité varie selon l’environnement d’exécution.
Des attaquants exploitent activement deux vulnérabilités critiques dans les services VPN des pare-feu Cisco ASA et FTD. Ces failles permettent à des acteurs externes de faire planter les dispositifs par déni de service (DoS) sans nécessiter aucune authentification préalable. Cisco a publié des correctifs pour ces problèmes, qui ciblent le service SSL VPN d’accès à distance.
La première faille, référencée sous le CVE-2026-20349, est apparue en août. Elle résulte d’une insuffisance de contrôle d’erreurs lors du traitement des requêtes HTTP. En envoyant une requête HTTP spécialement conçue, un attaquant peut forcer le redémarrage inattendu de l’appareil. Selon les données CISA KEV, cette faille est exploitée activement et affiche un score CVSS de 8,6. Plus récemment, Cisco a corrigé le CVE-2026-76418. Celle-ci est plus spécifique : elle tire son origine d’erreurs logiques affectant les groupes de tunnels configurés avec une authentification secondaire. L’exploitation nécessite que le pare-feu soit vulnérable, que le service SSL VPN soit accessible et que la configuration spécifique soit en place. Là encore, un attaquant peut provoquer un arrêt du service.
Ce qui est touché et la gravité réelle
Il faut bien comprendre que ces failles ne sont pas de simples problèmes de logique applicative. Elles mettent en jeu directement la disponibilité du service. Pour le CVE-2026-20349, l’exploitation est purement à distance et ne requiert aucune identification valide. De même, pour le CVE-2026-76418, Cisco précise qu’« un succès de connexion VPN n’est pas nécessaire pour atteindre le chemin de traitement affecté », ce qui souligne le caractère critique de ces portes d’entrée non sécurisées. Ces failles sont donc des vecteurs directs de paralysie pour les infrastructures.
Cisco a confirmé que ses offres en cloud – Secure Access et Secure Firewall Management Center – ne sont pas concernées par ces failles, ce qui permet de délimiter le champ d’action des équipes de sécurité. Néanmoins, l’impact sur un périmètre réseau est maximal : le service VPN, souvent la passerelle principale vers les employés distants, est mis hors service.
Que faire maintenant
La recommandation de Cisco est claire et non négociable : les clients doivent migrer immédiatement vers les versions logicielles corrigées. Contrairement à d’autres failles, aucune solution de contournement n’est disponible pour ces deux CVE. Les seuls moyens mentionnés par le fournisseur pour réduire l’exposition sont temporaires et conditionnels aux paramètres des groupes de tunnels, comme désactiver la liste des groupes de tunnels ou supprimer l’authentification secondaire, mais l’éditeur avertit que cela affaiblit la sécurité du VPN distant.
L’action requise passe par la mise à jour vers les versions spécifiées dans les avis de sécurité. Par exemple, pour l’ASA, les versions 9.16.4.103 ou ultérieures sont mentionnées comme incluant le correctif. Surveiller l’évolution de ces vulnérabilités reste de mise, car l’existence d’une seconde faille DoS dans les mois qui suivent rappelle une exposition continue des équipements de sécurité.
L’Agence américaine de cybersécurité et d’infrastructure (CISA) a ajouté deux failles de sécurité à son catalogue des vulnérabilités activement exploitées (KEV Catalog) le 28 octobre 2026. Il s’agit de CVE-2026-41709, affectant Broadcom VMware ESX, et de CVE-2026-46300, touchant le noyau Linux. Ces ajouts ne sont pas de simples mises en garde ; ils confirment que des acteurs malveillants utilisent déjà ces faiblesses en production.
La vulnérabilité dans VMware ESX, qualifiée de manque de journalisation (insufficient logging), permet à un administrateur malveillant d’exécuter certaines opérations sans qu’elles soient enregistrées. CISA confirme que cette faille, CVE-2026-41709, est activement exploitée. D’ailleurs, The Hacker News rapporte que CrowdStrike avait révélé que des acteurs liés à la Chine, nommés Warp Panda, avaient déjà militarisé cette vulnérabilité contre des entités du secteur juridique américain. Broadcom avait d’ailleurs publié un avis de sécurité en juillet 2026 concernant cette faille, mais l’intégration au KEV Catalog marque le passage de la théorie à l’action menée par les attaquants.
Les enjeux techniques des failles ajoutées
Au-delà de l’incident ESX, l’ajout de CVE-2026-46300 soulève des préoccupations bien différentes, touchant au cœur du système d’exploitation Linux. Cette faille concerne un problème dans la gestion des fragments de paquets (skb) au niveau du noyau. En substance, le mécanisme de coalescence des fragments ne préserve pas un marqueur essentiel, ce qui peut conduire à ce que le protocole ESP déchiffre des fragments stockés dans le cache de pages de manière inopinée. Les données techniques indiquent que cette vulnérabilité peut être enchaînée avec CVE-2026-109618 et CVE-2026-109619 pour implanter des webshells PHP et exécuter des commandes avec les droits root.
Les exigences de CISA, renforcées par la Directive Opérationnelle Contraignante (BOD) 26-04, sont claires pour les agences fédérales américaines : elles doivent prioriser la correction de ces failles exposées publiquement. Pour CVE-2026-41709, l’échéance pour ces entités est fixée au 11 novembre 2026. Bien que la vulnérabilité ESX ait été signalée par des chercheurs, l’exploitation observée impose un changement radical dans la gestion des actifs.
Que faire maintenant
Pour les organisations qui ne sont pas sous la juridiction fédérale américaine, l’appel à l’action est tout de même pressant. CISA encourage toutes les entités à adopter une gestion des vulnérabilités basée sur le risque. Il ne suffit plus de suivre les cycles de patchs planifiés ; il faut évaluer activement l’exposition de chaque actif. En ce qui concerne VMware ESX, les utilisateurs doivent appliquer les correctifs fournis par Broadcom, tout en se conformant aux directives de CISA concernant la traçabilité post-exploitation. Pour le noyau Linux, la mise à jour des versions concernées est la voie principale, mais il faut surveiller attentivement les chaînes d’exploitation potentielles mentionnées.
La responsabilité incombe aux équipes opérationnelles de déterminer non seulement si elles possèdent ces systèmes, mais surtout si ces systèmes sont accessibles depuis l’extérieur. Surveiller les mises à jour des fournisseurs et se préparer à une réévaluation complète des surfaces d’attaque exposées semble être la seule réponse viable face à cette vague de vulnérabilités validées par l’usage réel.
