Java : Le JDK 24 a atteint le stade de release candidate. Mark Reinhold (architecte en chef de Java) a annoncé la disponibilité de la version RC1, confirmant que la sortie officielle du JDK 24 est planifiée pour le 18 mars 2025 (JDK 24 and JDK 25: What We Know So Far – InfoQ). Cette version non-LTS embarque 24 nouvelles fonctionnalités couvrant la bibliothèque de base, le langage Java, la sécurité et la JVM. Parallèlement, les premières ébauches pour Java 25 commencent à se préciser : aucune fonctionnalité n’est finalisée pour le moment, mais Oracle a suggéré que des JEP comme les value objects (JEP 502, “Stable Values”) pourraient faire leur apparition en version préliminaire dans JDK 25 prévu pour septembre 2025 (JDK 24 and JDK 25: What We Know So Far – InfoQ). Java continue ainsi d’évoluer rapidement hors des versions LTS, avec des itérations fréquentes pour introduire des améliorations du langage et de la plateforme.
Rust : La version Rust 1.85.0 est sortie, marquant la stabilisation de l’édition Rust 2024. Il s’agit de la plus importante édition du langage à ce jour, introduisant de nombreux changements qui améliorent la sûreté et préparent le terrain pour de futures évolutions (Announcing Rust 1.85.0 and Rust 2024 | Rust Blog). Parmi ces modifications, on note un renforcement des règles unsafe (par exemple les blocs extern doivent désormais être marqués unsafe et les attributs comme no_mangle ou export_name aussi) ainsi que la réservation de nouveaux mots-clés/syntaxes (comme gen pour de futures generator blocks). En plus de l’édition 2024, Rust 1.85 apporte enfin une fonctionnalité très attendue : les closures asynchrones. Il est maintenant possible de définir une closure avec async || { }, qui renvoie un Future lorsqu’elle est appelée, de la même manière qu’une fonction async. Cette nouveauté, accompagnée de traits AsyncFn, permet d’écrire des closures async plus naturellement et de résoudre des cas d’usages qui n’étaient pas couverts par les contournements existants. L’écosystème Rust continue donc de pousser vers plus de convivialité (async partout) tout en durcissant la sécurité par défaut.
Go : La version stable Go 1.24 a été publiée par l’équipe Google. Cette mouture apporte plusieurs améliorations notables. Côté langage, Go 1.24 supporte pleinement les alias de types génériques, ce qui permet de paramétrer un alias de type comme s’il s’agissait d’un type défini (Go 1.24 is released! – The Go Programming Language). Le runtime profite de gains de performance : une nouvelle implémentation interne des maps basée sur les Swiss Tables ainsi qu’une allocation mémoire optimisée pour les petits objets réduisent la charge CPU d’environ 2–3% en moyenne. En outre, l’outil en ligne de commande gagne en fonctionnalité avec, par exemple, un mécanisme de suivi des dépendances d’outils : la commande go get -tool permet désormais d’ajouter une directive tool dans le module Go, et ces utilitaires déclarés peuvent être exécutés via go tool …. Un nouvel analyseur de tests (go vet) détecte aussi les erreurs courantes dans les fonctions de test ou fuzz. Ces évolutions offrent aux développeurs Go à la fois plus de puissance (génériques améliorés), de meilleures performances, et un outillage enrichi pour la gestion des projets.
Python : Du côté de Python, les travaux sur la future version Python 3.14 continuent de révéler des améliorations orientées performance. La cinquième pré-version alpha de Python 3.14, publiée mi-février, introduit notamment un nouvel interpréteur expérimental visant à accélérer l’exécution de certains codes (Python Release Python 3.14.0a5 | Python.org). Cet interpréteur dit “tail-calling” constitue une quatrième variante du moteur d’exécution Python et, d’après les premiers benchmarks, il pourrait exécuter certains workloads ~10 % plus rapidement (Python News Roundup: February 2025 – Real Python). Pour l’essayer, il faut recompiler l’interpréteur avec un indicateur de build spécifique, car il reste pour l’instant en opt-in. À noter qu’il ne s’agit pas d’une implémentation d’élimination d’appel terminal (pas de tail-call optimization au sens fonctionnel), mais d’une approche différente pour améliorer le throughput. Par ailleurs, les versions stables actuelles de Python ont reçu des mises à jour correctives (3.13.2 et 3.12.9) début février, corrigeant des centaines de bugs mineurs. L’écosystème Python voit aussi évoluer ses outils : par exemple Poetry 2.0, le gestionnaire de projets Python, est sorti avec une meilleure compatibilité au standard PEP 621 pour la configuration dans pyproject.toml, ce qui unifie davantage la gestion des métadonnées de package à travers les outils Python. En somme, Python poursuit sur deux axes : fiabiliser les versions stables et préparer des gains de vitesse pour la prochaine version majeure.
Frameworks
Spring (Java) : La plateforme Spring prépare sa prochaine génération. Le Spring Framework 7.0.0 a atteint son deuxième milestone (M2). Cette pré-version introduit quelques améliorations de base, par exemple une meilleure résolution des configurations CORS (Cross-Origin) grâce à des ajustements dans les méthodes equals() des classes d’annotation de méthode et de gestionnaire, ce qui fiabilise la détection des règles CORS (Java News Roundup: JDK 24-RC1, JDK Mission Control, Spring, Hibernate, Vert.x, JHipster, Gradle – InfoQ). Spring 7 affine aussi son API de contexte : la classe GenericApplicationContext intègre désormais l’annotation @Nullable (via JSpecify) sur certains paramètres, renforçant la sécurité nullaire lors de l’enregistrement de beans. En parallèle, Spring continue de maintenir ses branches 6.x : les versions 6.2.3 et 6.1.17 du Framework ont été publiées avec des correctifs, par exemple une résolution de bug où la configuration XML MVC utilisait incorrectement PathPatternParser au lieu de AntPathMatcher pour le routage, ainsi que la mise en Serializable de la classe ProblemDetails pour une meilleure utilisation distribuée. Côté data, Spring Data 2025.0.0 sort en premier milestone : point marquant, il apporte le support de la recherche par vecteurs pour MongoDB et Cassandra (via l’intégration de MongoDB Atlas Vector Search et Cassandra Vector Search). Un nouveau type de donnée Vector fait son apparition afin de manipuler plus aisément des embeddings (vecteurs de caractéristiques) au sein des entités du domaine. Cette orientation montre l’adaptation de Spring aux cas d’usage IA modernes (recherche sémantique, etc.). Spring Data 2025 M1 inclut aussi de nombreuses mises à jour de dépendances et sera embarqué dans Spring Boot lors de ses prochaines versions. Enfin, l’outil Spring Tools Suite passe en version 4.28.1 avec une meilleure prise en charge sur Windows (signature correcte de l’exécutable et correction d’un avertissement “éditeur inconnu”). L’écosystème Spring dans son ensemble est donc en ébullition, entre innovation (Spring 7, Spring Data vectorielle) et maintenance continue des versions stables.
Hibernate & Jakarta EE : Le framework d’ORM Hibernate ORM 7.0 progresse vers sa sortie majeure avec la publication de la Beta 4. Cette version bêta adopte désormais la spécification Jakarta Persistence 3.2 (ciblant Jakarta EE 11) comme base (Java News Roundup: JDK 24-RC1, JDK Mission Control, Spring, Hibernate, Vert.x, JHipster, Gradle – InfoQ). Hibernate 7.0 requiert Java 17 au minimum et améliore la validation du modèle de domaine. Un changement architectural notable est la migration depuis la librairie interne Hibernate Commons Annotations vers le nouveau module Hibernate Models pour tout le traitement de bas niveau du modèle objet. Cela indique une modernisation de l’outil en vue de Jakarta EE 11, avec une attention à la cohérence et à la maintenance à long terme. À côté de l’ORM principal, la version Hibernate Reactive 2.4.5.Final est sortie, alignée sur Hibernate ORM 6.6.7.Final, apportant des corrections de bugs pour les utilisateurs de la stack réactive (par exemple, correction d’une exception PropertyAccessException lors de persist() sur des entités one-to-one bidirectionnelles sous Panache). Ces sorties montrent l’effort de Hibernate pour couvrir à la fois le besoin en standard Java/Jakarta classique et les cas d’usages plus modernes (réactif, NoSQL via Panache). La convergence avec Jakarta EE 11 est un pas stratégique qui positionnera Hibernate 7 comme l’implémentation JPA de référence sur la nouvelle plateforme Jakarta.
Frontend JavaScript (React) : Dans l’écosystème front-end, un tournant important a eu lieu : l’équipe React a déprécié officiellement Create React App (CRA), l’outil historiquement recommandé pour créer une application React monopage. À partir du 14 février 2025, CRA est annoncé en fin de vie pour les nouveaux projets (Sunsetting Create React App – React). Les développeurs sont encouragés à se tourner soit vers un framework plus complet (Next.js, Remix, Astro, etc., suivant le cas d’usage) soit vers des outils de bundling modernes comme Vite ou Parcel. Cette décision fait suite à plusieurs constats : CRA souffrait de limitations connues qui compliquaient l’optimisation des applications en production, et il n’y a plus de mainteneurs actifs sur le projet. Plutôt que de faire évoluer CRA en un framework à part entière, la team React a choisi de le mettre en maintenance minimale. Concrètement, installer create-react-app affiche désormais un avertissement de déprecation invitant à considérer des alternatives. CRA restera fonctionnel en mode maintenance (d’ailleurs une version de compatibilité a été publiée pour supporter React 19), mais sans nouvelles features. Cette annonce marque la fin d’une époque – CRA avait été lancé en 2016 pour simplifier la configuration d’une app React – et reflète l’évolution de l’écosystème où des outils plus performants et spécialisés ont émergé. La communauté a globalement salué cette décision, beaucoup ayant déjà migré vers des stack plus modernes.
Mobile & cross-plateforme (React Native) : L’équipe de React Native a communiqué sur un changement de stratégie de publication. Avec la sortie de React Native 0.78 (mi-février), qui apporte le support de React 19, le projet adopte désormais un cycle de sorties plus fréquent en 2025, avec des itérations plus petites et moins de changements ruptures (React Native 0.78 – React 19 and more · React Native). L’objectif est de faciliter les mises à jour pour les développeurs mobiles : en réduisant les breaking changes et en livrant plus régulièrement, les correctifs de bugs et nouveautés seront disponibles plus rapidement et de manière incrémentale. Par exemple, RN 0.78 intègre certaines API de React 19 (telles que les nouvelles hooks useOptimistic, useActionState, etc.) et améliore l’intégration du React Compiler (outil de mémoïsation automatique au build) pour optimiser les performances des apps. Simplifier la procédure d’activation du compilateur et aligner rapidement React Native sur les avancées de React (web) font partie de cette démarche. Cette accélération du cycle de livraison s’inscrit dans une tendance plus large de l’écosystème JavaScript à rapprocher les outils web et mobile et à fournir aux développeurs des améliorations continues sans grosses migrations. Un React Native plus agile devrait ainsi améliorer la stabilité de la plateforme tout en la gardant à jour des innovations React.
Autres frameworks et outils : Dans l’écosystème Java, notons également la sortie de JHipster 8.9.0, outil de génération d’applications, qui met à jour ses stacks internes (Spring Boot 3.4.2, Angular 19.0.6, Node.js 22.13, TypeScript 5.7, etc.) et ajoute le support des champs de type LocalTime (heure sans date) dans son langage de domaine JDL (Java News Roundup: JDK 24-RC1, JDK Mission Control, Spring, Hibernate, Vert.x, JHipster, Gradle – InfoQ). Côté build, Gradle 8.13.0 a publié sa première release candidate : cette version introduit un utilitaire d’auto-provisionnement de JVM pour le daemon Gradle (télécharge automatiquement la bonne version de JVM si nécessaire), facilite la configuration de la version de Scala pour les projets Scala, et améliore la précision des horodatages dans les rapports de tests JUnit. Ces mises à jour montrent une attention à l’expérience développeur (moins de configuration manuelle, outillage plus intelligent). Enfin, dans l’univers .NET, le framework web ASP.NET Core (faisant partie de .NET 8) continue d’être adopté, tandis que des projets comme Blazor gagnent en maturité pour le développement d’applis web monopage en C#. Bien que cette semaine n’ait pas vu de version majeure côté .NET (après .NET 8 LTS à l’automne 2023), l’activité se concentre sur des previews de .NET 8.1 et la préparation de .NET 9 plus tard en 2025. L’ensemble des frameworks de développement, tous langages confondus, témoignent d’un effort constant pour intégrer les nouvelles tendances (support de l’IA, du cloud, des perfs) tout en simplifiant la vie des devs.
Environnements de développement (IDE & outils)
Visual Studio Code : L’éditeur VS Code continue son rythme mensuel d’améliorations. La version 1.97 (mise à jour de janvier 2025, publiée début février) apporte un lot de nouveautés appréciables. Microsoft mise notamment sur l’intégration poussée de l’IA générative via GitHub Copilot. En aperçu, VS Code peut désormais suggérer automatiquement la prochaine modification de code que le développeur pourrait vouloir effectuer, grâce à Copilot (Next Edit Suggestions) (January 2025 (version 1.97)). On voit aussi arriver la possibilité de valider automatiquement certaines suggestions AI après un délai configurable, ce qui fluidifie l’autocomplétion assistée. Côté interface, les développeurs peuvent à présent détacher et repositionner la palette de commandes où bon leur semble à l’écran, améliorant la personnalisation de l’UI. Sur la sécurité, VS Code introduit la notion de confiance par éditeur pour les extensions : on peut spécifier la confiance envers l’éditeur (publisher) d’une extension pour éviter d’installer du code potentiellement malveillant. Parmi les autres ajouts, citons la vue agrégée des logs (plusieurs sources de log combinées) et la possibilité de filtrer le panneau de sortie, ce qui facilite le débogage en focalisant sur l’essentiel. L’outil Git intégré affiche désormais des informations enrichies de blame (auteur et date des dernières modifications par ligne, avec lien direct vers GitHub). Les développeurs de notebooks (Jupyter, etc.) bénéficient de l’affichage inline des valeurs de variables au sein des cellules. Enfin, pour Python, un mode de débogage simplifié sans configuration fait son apparition, permettant de lancer un script ou module Python en debug d’un clic, sans launch.json. Toutes ces améliorations confirment VS Code dans son rôle d’IDE léger très complet, en particulier son avance en matière d’assistance AI et d’ergonomie modulaire.
Extension C# pour VS Code : Microsoft ne délaisse pas pour autant l’écosystème .NET dans VS Code. Le C# Dev Kit (extension officialisée en 2023 pour enrichir l’expérience C# sous VS Code) a reçu une mise à jour notable mi-février (C# Dev Kit Update: Enhancements to Solution-Less Workspace and More – InfoQ). Premier gros ajout : le mode “solution-less workspace”, désormais disponible en préversion. Ce mode permet de travailler sur des projets C# sans fichier de solution .sln. En pratique, cela simplifie grandement la configuration initiale et allège la structure pour des petits projets ou des microservices, tout en restant compatible avec les solutions traditionnelles. Deuxième nouveauté : l’introduction de .NET Aspire, un mécanisme d’orchestration (également en preview) pour le cloud. Cette fonctionnalité ajoute automatiquement les projets App Host et Service Defaults à une solution existante afin de la transformer en solution .NET Aspire. Cela vise à faciliter l’exécution, le débogage et le déploiement d’applications distribuées (pensez microservices ou fonctions cloud) en standardisant leur configuration. En outre, l’extension améliore sensiblement le support de Razor/Blazor pour le développement web full-stack en C#. Le Hot Reload pour les applications Blazor, bien qu’encore expérimental, gagne en fiabilité (les modifications à chaud se rafraîchissent mieux, en attendant une GA de Hot Reload). L’IntelliSense a été rendu plus robuste : par exemple, les erreurs fantômes dans le panneau de problèmes disparaissent bien une fois le code corrigé, sans nécessité de rebuild. Le débogueur C# dans VS Code s’enrichit également : il est maintenant capable de déboguer localement des applications Azure Functions et de déboguer le code frontend des projets Blazor WebAssembly directement depuis VS Code – des scenarios auparavant réservés à Visual Studio. Enfin, l’outil de tests intègre de meilleures diff des résultats et peut afficher les piles d’appel lors des échecs de tests, avec un nouveau niveau de verbosité diagnostic pour faciliter la résolution des problèmes de tests. Toutes ces évolutions, guidées par les retours des utilisateurs, visent à rendre VS Code + C# aussi productif que l’expérience Visual Studio classique, en misant sur la légèreté et la flexibilité de VS Code.
JetBrains IntelliJ IDEA : Du côté des IDE JetBrains, les versions 2025.1 sont en préparation active via le programme EAP (Early Access Program). IntelliJ IDEA, l’IDE Java de référence, a sorti sa préversion 2025.1 EAP 5 durant la semaine du 17 février. Une des avancées mises en avant est l’amélioration de l’assistant AI intégré. JetBrains élargit la palette des LLM (Large Language Models) supportés par son assistant : en plus des modèles d’OpenAI déjà utilisés, l’AI Assistant prend désormais en charge les modèles Anthropic Claude 3.5 (variantes Sonnet et Haiku via l’intégration AWS Bedrock) (IntelliJ IDEA 2025.1 EAP 5: More LLMs in JetBrains AI Assistant, Improved Gutter for VCS, and More | The IntelliJ IDEA Blog). Cela permet à l’IDE d’offrir des complétions et analyses encore plus pertinentes et rapides, en s’appuyant sur des modèles de nouvelle génération. De plus, JetBrains indique ajouter de nouveaux modèles OpenAI maison (“o1”, “o1-mini” et “o3-mini”) pour gagner en diversité et vitesse d’exécution des demandes AI. En pratique, les développeurs pourront bénéficier de suggestions de code ou de documentation assistées par différentes IA en parallèle, l’IDE choisissant le mieux adapté selon le contexte. Mis à part l’IA, IntelliJ IDEA 2025.1 EAP apporte des améliorations de l’UX de contrôle de version : par exemple, un gutter (marqueur visuel dans la marge) amélioré pour suivre les modifications de code et les différences Git de manière plus intuitive. Le débogueur gagne aussi une fonctionnalité utile permettant de mettre en pause l’évaluation des watchers pour éviter d’éventuels effets de bord lors du debugging (notamment sur les entités JPA/Hibernate où l’évaluation d’une propriété peut déclencher un chargement inattendu). Bien que ces fonctionnalités soient en phase d’évaluation, elles montrent la direction que prennent les IDE JetBrains : plus d’IA multi-fournisseurs intégrée directement dans le flux de travail, et des raffinements pour le confort des développeurs (gestion fine du debug, UI). La version stable 2025.1 d’IntelliJ IDEA est attendue pour le printemps, et devrait inclure l’ensemble de ces nouveautés, positionnant l’IDE comme un outil à la pointe notamment sur l’assistance intelligente à la programmation.
DevOps, CI/CD et Infrastructure as Code
IA et DevOps : L’année 2025 s’annonce marquée par l’injection de l’IA dans les pipelines DevOps. D’après les experts, on devrait voir émerger de plus en plus d’IA “built-in” dans les outils d’intégration et déploiement continus, et plus seulement sous forme de bots à part. En pratique, cela signifie que les plateformes CI/CD et les outils de supervision vont intégrer nativement des capacités d’analyse prédictive, d’optimisation automatique et d’assistance intelligente tout au long du cycle de vie du logiciel (2025 Predictions for DevOps and Application Development – DevOps.com). Parallèlement, Kubernetes continue de régner en tant que couche d’orchestration standard “partout”. Kubernetes est désormais considéré comme le “système d’exploitation du cloud” tant il s’est étendu à tous types de workloads, bien au-delà des microservices web initialement visés. Cette omniprésence s’accompagne toutefois d’un défi de complexité opérationnelle. En 2025, l’accent est mis sur des efforts pour simplifier la gestion de Kubernetes, via l’automatisation et aussi via… l’IA. On voit apparaître des outils d’“AIOps” spécialisés Kubernetes capables d’aider à la configuration optimale, à la détection d’anomalies ou à l’auto-remédiation des incidents sur des clusters. De plus, la pratique du GitOps (déploiement continu piloté par des déclarations Git) s’est solidifiée : les solutions comme Argo CD et Flux CD sont largement adoptées en production, renforçant la fiabilité des déploiements. En résumé, la tendance DevOps de la semaine met en lumière une convergence : automatiser toujours plus, avec de l’intelligence en prime. Les équipes se préparent à des pipelines de CI/CD augmentés par l’IA et à une orchestration cloud encore plus intégrée, ce qui devrait améliorer tant la vitesse que la stabilité des livraisons logicielles.
Infrastructure as Code (Terraform et OpenTofu) : Le monde de l’IaC évolue sur deux fronts : l’outil propriétaire de facto et son alter ego open source communautaire. HashiCorp Terraform poursuit son cycle de sorties régulières : la version 1.11.0 est imminente. La release candidate 1 de Terraform 1.11 a été publiée le 12 février, introduisant plusieurs nouveautés notables (Terraform v1.11.0-rc1 released – Release Notifications – HashiCorp Discuss). D’abord, la prise en charge des attributs “write-only” pour les ressources : certains champs sensibles ou techniques pourront être écrits depuis la config sans jamais être relus, ce qui améliore la sécurité et la cohérence dans l’état Terraform (Releases · hashicorp/terraform – GitHub). Terraform 1.11 apporte également une nouvelle commande terraform modules -json qui exporte la liste des modules utilisés au format JSON, utile pour automatiser l’inventaire des dépendances. Des améliorations ont été faites sur le backend S3 (meilleure gestion du verrouillage d’état, évitant des conflits d’accès concurrents) et sur l’installation des providers (pour accélérer la résolution des plugins). L’outil de test de modules, introduit en v1.10, reçoit aussi des améliorations, consolidant l’aspect testabilité de l’IaC. En face, la communauté open source autour de OpenTofu (le fork libre de Terraform créé en réaction au changement de licence de HashiCorp l’an dernier) gagne en traction. Un signe fort : un OpenTofu Day a été organisé en 2024 et réédité en 2025 en co-événement de KubeCon, réunissant la communauté pour discuter migrations et retours d’expérience (OpenTofu Day | LF Events – Linux Foundation Events). Cela montre que l’écosystème OpenTofu s’installe durablement. Aujourd’hui, OpenTofu est porté par la Linux Foundation et vise une compatibilité maximale avec les configurations Terraform existantes, offrant une alternative entièrement open-source. Depuis sa GA début 2024, OpenTofu a sorti plusieurs versions mineures et intègre progressivement les équivalents des features Terraform. Pour les entreprises attachées à l’open source “pur”, OpenTofu devient une option crédible, d’autant qu’il promet d’éviter les changements de licence surprises à l’avenir. En somme, l’infrastructure-as-code se trouve dans une phase intéressante où l’outil dominant innove tout en voyant émerger un shadow open source soutenu par la communauté.
CI/CD et sécurité des chaînes de build : GitHub a annoncé des changements importants concernant GitHub Actions, son service d’automatisation CI/CD, afin de renforcer la sécurité des pipelines. À partir de la mi-février, en préparation d’une nouvelle fonctionnalité en préversion publique, GitHub introduit la notion d’Actions immuables (Immutable Actions) (Notice of upcoming deprecations and breaking changes for GitHub Actions – GitHub Changelog). Concrètement, plutôt que de récupérer les actions (tasks/primitives réutilisables dans les workflows CI) par un tag ou une branche qui pourrait pointer vers du code mis à jour, les runners GitHub vont désormais par défaut utiliser une version figée de l’action lorsqu’elle est disponible. Cela empêche qu’une mise à jour non maîtrisée d’une action tierce puisse impacter vos workflows de build – une mesure clé pour la sécurité de la supply chain logicielle. GitHub a commencé à migrer les utilisateurs vers ce mode “immutable” automatiquement. Pour les utilisateurs d’Actions auto-hébergées, il est recommandé d’ajuster la configuration réseau en autorisant les domaines actions.githubusercontent.com et ghcr.io (registry container) afin de permettre le téléchargement de ces actions versionnées. Par ailleurs, GitHub va retirer la possibilité pour les workflows de modifier le statut d’une exécution de check via le token par défaut – cela évite qu’une action malveillante ne falsifie le résultat d’un job CI. Ces durcissements suivent les bonnes pratiques de plus en plus strictes en CI/CD : vérification des dépendances, exécution en environnement isolé et inaltérable, etc. Dans le même esprit, d’autres outils CI/CD adoptent des mesures comparables (par exemple, GitLab CI a introduit des signatures pour les templates de pipeline). Enfin, dans l’actualité DevOps de la semaine, on peut noter que Jenkins, l’outil CI historique, reste très utilisé mais voit son rôle évoluer. Un article de TechGig souligne qu’en 2025 Jenkins est encore présent surtout en entreprise, mais souvent en tandem avec des solutions cloud modernes (GitHub Actions, GitLab CI) selon les besoins (Is Jenkins still worth learning for DevOps in 2025? – TechGig). Jenkins continue d’être mis à jour (dernière LTS en date fin janvier) et la communauté travaille sur la simplification de son déploiement (projet Jenkins Evergreen, images Docker optimisées, etc.), preuve que l’outillage CI/CD “classique” coexiste avec les approches cloud-native. En conclusion, la sphère DevOps/CICD cette semaine est marquée par un double focus : sécuriser les chaînes d’intégration contre les attaques (supply chain security) et automatiser plus intelligemment grâce aux avancées IA, tout en maintenant un écosystème d’outils divers pour répondre à la variété des besoins des équipes de développement.
