Programmez
Le fil de programmez.com
-
JHipster v9.0.0 : bêta 2 disponible
JHipster travaille sur sa prochaine version majeure, la 9.0.0. La 1ere bêta est apparue en décembre 2025, la bêta est sortie fin janvier. Plus de 1 000 issues et pull requests seront traitées et intégrées. Les nouveautés et mises à jour seront nombreuses :
- Zoneless dans la partie Angular : possibilité d'exécuter du code Angular sans zone.js
- ajout de Vitest comme alternative à Jest
- Bootstrap 5
- Spring Boot 3.5.8 et 4.0.2
- Angular 21
- support de TypeScript entièrement refait : meilleure modularité
- support de Java 25
- Node.JS passe en 24.11.1
- Attention : retrait de Java 17 et de Node 20
Note de version : https://www.jhipster.tech/2026/01/29/jhipster-release-9.0.0-beta.2.html
Catégorie actualité:Image actualité AMP:
-
Quarkus 3.31 : Java 25, nouveau Panache Next, nouveau package Quarkus
Quarkus est disponible en version 3.31. Une des principales nouveautés est le support de Java 25. Elle apporte aussi des corrections de bugs. Quarkus introduit "quarkus", un nouveau packaging Quarkus pour Maven. Il doit apporter un véritable cycle de vie ce que les paquets jar ont du à faire.
Cette version introduit Panache Next, une nouvelle version de Panache, ainsi que Testcontainer 2, JUnit 6, mises à jour d'ORL, Reactive, Search, OpenSearch. support de Hibernate Spatial. Maven 3.9.0 est désormais la version minimale requise.
Note de version : https://quarkus.io/blog/quarkus-3-31-released/
Catégorie actualité:Image actualité AMP: -
Firefox 148 : un bouton d'arrêt d'urgence pour couper l'IA
Firefox 148, prévu pour le 24 février, proposera un fonctionnalité particulière à l'IA : la possibilité de gérer l'IA selon les préférences définies par l'utilisateur. Ces options seront regroupées dans Contrôles IA. Le principe est simple : activer ou non les différentes fonctionnalités IA du navigateur (traductions, texte alternatif dans les PDF, groupement intelligent d’onglets, aperçus de liens ou chatbot dans la barre latérale, etc.).
Une fonctioonnalité qui va peut être se retrouver rapidement dans les autres navigateurs.
Catégorie actualité:Image actualité AMP: -
AMD lance AI Developer, son programme développeur
AMD s'intéresse aussi aux développeurs. Spécifiquement à l'IA, AMD propose AI Developper. Ce site rassemblen l'ensemble des ressources pour créer, optimiser, développer les IA avec le hardware et les SDK AMD.
A l'inscription au programme, AMD offre un crédit de 100 $ pour utiliser les ressources disponibles. Une partie du contenu est accessible librement. Toutes les ressources avancées sont réservés aux membres, notamment toutes les sessions de formations, ainsi qu'un forum dédié.
Site : https://www.amd.com/fr/developer/ai-dev-program.html
On peut s'attendre à un élargissement du programme AI Developer dans les prochains mois.
Catégorie actualité:Image actualité AMP: -
Mole : un outil Terminal pour nettoyer et optimiser macOS
Un des outils références pour l'optimisation système sur macOS est l'incontourable Onxy. Avec son interface, on peut faciliter nettoyer les entrailles de son Mac, supprimer les instantanés, rebuilder l'index mail, etc. Il existe un outil aussi puissant directement accessible dans le Terminal : Mole.
Pour l'installer, c'est très simple : brew install mole ou avec :
# Optional args: -s latest for main branch code, -s 1.17.0 for specific versioncurl -fsSL https://raw.githubusercontent.com/tw93/mole/main/install.sh | bashMole utilise tous les toolkit de nettoyage dans un unique binaire. Il scanne et nettoie tous les logs, les caches, les préférences, les éléments cachés. Il permet de déinstaller, réellement, une application (le binaire et les dépendances). Il permet d'analyser finement le site, les fichiers les plus lourds, etc. Et on peut aussi faire du monitoring en temps réel des principaux éléments du Mac et de macOS.
Mole permet d'aller très loin dans le monitoring grâce aux multiples commandes. Simple et terriblement efficace.
Site : https://github.com/tw93/Mole
Catégorie actualité:Image actualité AMP: -
Cloud Native Days 2025 : une journée dédiée à l'infrastructure et à Kubernetes
Aujourd'hui, au 104 à Paris, se tient la nouvelle édition de la journée Cloud Native Days. Les thèmes sont nombreux : l’infrastructure et le Cloud, le DevOps, Kubernetes et le Cloud Native, ou encore le Platform Engineering : développeurs, ingénieurs systèmes et SRE, profils devops, architectes, mais aussi des profils produit & business ainsi que les décideurs techs (CTO, DSI, CISO, VPs...).
La journée est l'occasion d'assister à de nombreuses sessions techniques ou de nombreux REX pour comprendre comment au quotidien les infrastructures actuelles fonctionnent et les défis qu'elles posent. La sécurité est un thème fort de la journée, par exemple les risques de sécurité des GitHub Actions ou encore commencer créer et déployer un OS immutable pour Kubernetes.
C'est aussi l'occasion de rencontrer des acteurs du marché tels que Grafana, Suse, Docker, Portvorx, AWS, Google Cloud, Redis, Harness, Red Hat.
Programmez! est partenaire media de l'événement. Retrouvez nous sur notre stand.
Catégorie actualité:Image actualité AMP: -
FOSDEM 2026 résumé 1 : Reproducible Builds for Android Apps, pourquoi est-ce si important ?
Andreas Itzchak Rehberg proposait un sujet aussi intrigant qu’utile : la reproductibilité des builds (RB) pour les applications Android. Mais au-delà d’Android, on comprend très vite qu’un environnement de builds stable et capable de reproduire exactement le même comportement est quelque chose d’indispensable. Mais pour y parvenir, il faut une infrastructure RB définie et une méthodologie claire.
Pourquoi est-ce une bonne approche ? Par exemple, le RB permet d’avoir une application non altérée avec une confiance élevée car la build est garantie. D’autre part, le développeur sait que le code fonctionnera TOUJOURS de la même façon. Là encore, il s’agit d’avoir une confiance dans la build produite et d’avoir une stabilité de fonctionnement.
Une bonne RB permet aussi de détecter tout changement non prévu ou non autorisé durant le processus de build. Ce n’est pas une approche immutable, mais une bonne RB détectera ainsi tout changement qui ne devrait pas exister ou qui n’est pas autorisé. Et vous pouvez ainsi garantir que votre app soit conforme aux standards utilisés.
Andreas s’appuie sur la RB mise en avant pour IzzyOnDroid. Cette approche se définit ainsi :
- RB sur une track séparée de la branche principale et des autres builds
- utilisation de rbtlog
- toolchain open source uniquement
- conteneurs Podman avec différentes images Linux
- possibilité d’utiliser des builders différents
- les APK générés sont signés
Une bonne RB n’est pas simple à mettre en place. Les défis ne sont pas à sous-estimer. Actuellement, les équipes utilisent Java et Kotlin. Si Kotlin domine, une JDK doit être utilisée pour certains codes. Une autre complexité vient aussi des applications natives utilisant différents frameworks tels que Flutter, Node, React ou différents langages. Et il faut que la build embarque les chemins des librairies natives. Les chemins de build Windows ne peuvent pas être utilisés sur un build Linux. Et enfin, des SDK de versions différentes peuvent produire des sorties (= releases) différentes.
En plus des défis, il existe de nombreuses sources d’échecs d’une RB :
1 / les builds sales, c’est-à-dire des builds non nettoyées embarquant des assets qui ne devraient pas exister
2 / des commits différents
3 / des problèmes de builds entre Windows et Linux
4 / des problèmes liés à la signature des releases générées
5 / un système de build local ayant différents setups au lieu d’être plus spécifique
6 / utiliser une JDK qui n’est pas LTS : il faut éviter les versions intermédiaires, canary et toute version non LTSIzzyOnDroid met à disposition une documentation et des bonnes pratiques : https://izzyondroid.org/docs/reproducibleBuilds/
IzzyOnDroid propose son propre framework RB avec un rbuild_setup pour faciliter les RB. Chaque éditeur, ou développeur, peut avoir sa propre approche RB.
Catégorie actualité:Image actualité AMP: -
Notepad++ : hijacking subi en été et automne 2025
Les développeurs de Notepad++ ont communiqué sur une campagne de hijacking qui avait été détectée en juin 2025. L'attaque s'est faite en compromettant l'infrastructure hébergeant Notepad++. Les hackers ont réussi à rerouter le trafic destiné aux serveur officiels vers des serveurs illicites. L'équipe Notepad a alors facilité la communication entre l'hébergeur et l'équipe Incident-response pour analyser la compromission et fixer le problème. La réponse s'est déroulée en 2 grandes étapes.
Le serveur en cause a été compromis jusqu'au 2 septembre 2025. Une mise à jour du noyau, et du firmware, a pu fixer le problème. Si les accès illicities ont été coupés, les hackers ont pu gardés les identifiants des services utilisées par notepad. Puis un changement d'infrastructure a été réalisé le 2 décembre 2025. Depuis, aucune activité suspecte n'a été découverte. L'équipe précise que les vulnérabilités ont été corrigés. Tous les identifiants ont été renouvellés.
Notepad conseille de changer les identifiants SSH, FTP/SFTP, MySQL, vérifier les comptes Wordpress, supprimer les utilisateurs inutiles dans WordPress.
L'équipe conseille de télécharger la version 8.9.1 incluant les améliorations de sécurité.
Annonce : https://notepad-plus-plus.org/news/hijacked-incident-info-update/
Catégorie actualité:Image actualité AMP: -
Kubernetes : une faille dans RBAC ne sera pas corrigée car le comportement est conforme
Notre vulnérabilité démarre débutnovembre 2025 quand Graham Helton, chercheur en sécurité, communique à l'équipe sécurité de Kubernetes une vulnérabilité dans les autorisations dans la gestion des rôles, le RBAC. Cette faille permet de contourner la sécurité RBAC et de pouvoir exécuter un code distant non autorisé : "un contournement autorisé dans RBAC de Kubernetes des permissions nodes/proxy GET permet d'exécuter des commandes sur tous les pods d'un cluster" introduit Graham. Le problème ne vient pas réellement de Kubernetes mais de l'interaction avec certains protocoles réseaux.
Graham prévient Kubernetes puis plus rien jusqu'au mi-janvier. La réponse de l'époque sécurité de Kubernetes, publiée par Graham, confirme qu'il n'y aura de correction officielle, du moins, pas pour le moment : "Après un examen plus approfondi, nous confirmons notre décision selon laquelle ce comportement est conforme aux attentes et ne fera donc pas l'objet d'un CVE." explique l'équipe sécurité. Bien entendu, notre chercheur n'est pas d'accord.
"Nous sommes d'accord que nodes/proxy présente un risque, un patch pour restreindre ce chemin spécifique serait nécessaire pour changer les autorisations dans kubelet et the kube-apiserver pour forcer une double autorisation de get et create. Nous avons déterminé que la mise en œuvre et la coordination d'une telle logique de double autorisation sont fragiles, architecturalement incorrectes et potentiellement incomplètes." explique la réponse de Kubernetes.
La suite est intéressante : "Nous restons convaincus que la proposition KEP-2862 constitue la solution architecturale appropriée. Plutôt que de modifier l'autorisation globale des nodes-proxy, notre objectif est de la rendre obsolète pour les agents de surveillance en déployant progressivement des permissions plus fines dans la version 1.6, prévue pour mars 2026." poursuit Kubernets. La méthode actuelle ne sera pas déprécier avant plusieurs après l'introduction de la nouvelle méthode, le temps d'évaluer les risques de casses de compatibilité et donc une casse de production si la méthode actuelle nodes/proxy était spécifiquement modifiée (sous-entendu pour combler la faille).
Bref, oui la vulnérabilité existe, l'équipe sécurité ne le consteste pas mais elle explique que le comportement est conforme à ce qui est attendue et qu'aucune demande CVE ne sera faite et qu'il faut attendre une mise à jour d'architecture prévue au printemps 2026. L'autre point mis en avant est que toute correction spécifique sur la partie nodes/proxy pourrait casser la compatibilité avec les clusters actuels. L'équipe Kubernetes met en avant les changements qui seront faits dans la mise à jour d'avril 2026 en intégrant la spécifications KEP-2826. Graham, dans son dernier post, explique pourquoi la KEP-2862 ne fixe pas la faille.
Seule solution : vérifier toutes les autorisation, restreinte les accès, monitorer tous les noeuds.
Chronologie
1er novembre 2025 : rapport initial envoyé à l'équipe sécurité de Kubernetes. Puis traitement du dossier
14 décembre : l'équipe est informée du délai de non divulgation de 90 jours
7 janvier 2026 : mise à jour et relance de la requête
23 janvier : l'équipe sécurité dit qu'il n'y aura de correction de la vulnérabilité
26 janvier : Graham publie la vulnérabilité et le PoC d'exploitation
Publication complète de la vulnérabilité : https://grahamhelton.com/blog/nodes-proxy-rce
Catégorie actualité:Image actualité AMP: -
Qwen3-ASR : Alibaba ouvre ces vLLM
Alibaba, un des géants techs chinois, annonce la mise en open source des modèles Qwen-3ASR et ForcedAligner. ASR est un LLM dédié à la reconnaissance vocale. Les deux LLM servent à identifier la langue, actuellement 52 langages et accents sont supportés. La reconnaissance vocale est supportée par 30 langues et 22 dialectes chinois ainsi les accents anglais de plusieurs pays. Cela concerne les modèles ASR-1.7B et 0.6B.
Pour Alibaba, les enjeux sont de fournir des vLLM avec une taux de reconnaissance le plus fiable et fidèle possible. La version 0.6b joue sur l'optimisation du modèle et est un compromis entre précision et efficacité de la reconnaisance. Des SDK dédiés sont disponibles pour intégrer les LLM et les entraîner sur des nouvelles données.
Ces LLM s'appuient sur le modèle Qwen-3 Omni qui est un des LLM de référence d'Alibaba.
Pour démarrer. Il faut installer Qweb3-ASR avec le paquet quwen-asr disponible sur PyPi. Alababa conseille d'utiliser un environnement Python 3.12.
Tous les détails : https://github.com/QwenLM/Qwen3-ASR
Catégorie actualité:Image actualité AMP: