Les Cast Codeurs Podcast
LCC 343 - Trois IA, une seule prise électrique
Côté IA : MCP devient stateless, Claude watermarke ses textes, GPT-6 Astra défie Claude Fable, et une étude JetBrains confirme Claude Code en tête des agents de code. Côté JVM : JDK 27 généralise G1, Kotlin 2.4 stabilise les context parameters, une API JSON arrive dans le JDK, et Quarkus comme Micronaut enchaînent les versions. En bonus, trois pannes IA simultanées et un câble débranché chez Google Cloud. Enregistré le 11 septembre 2026 Téléchargement de l'épisode LesCastCodeurs-Episode-343.mp3 ou en vidéo sur YouTube . News Langages Les Types Algébriques de Données (ADTs) en Java rockthejvm.com/articles/algebraic-data-types-in-java Le problème : L'approche classique (champs nullables, hiérarchies de classes ouvertes) crée des états invalides et des erreurs à l'exécution (comme le NullPointerException ). Types Produits (ET logique) : Implémentés en Java avec les Records . Ils regroupent plusieurs champs de manière immuable et concise. Types Sommes (OU logique) : Implémentés avec les Sealed Interfaces . Elles définissent un ensemble strictement fermé de sous-types connus à la compilation. ADTs (Types Algébriques) : La combinaison des Sealed Interfaces et des Records. Ils garantissent que les états invalides sont impossibles à représenter dans le code. Pattern Matching : L'extraction des données se fait via des expressions switch exhaustives, supprimant le besoin de casts manuels et obligeant le développeur à traiter tous les cas possibles. Généralisation : Ce modèle est idéal pour créer des types comme Result , forçant le traitement explicite et sécurisé des succès et des erreurs typées. Pourquoi "Algébrique" ? Parce que les types sont combinés mathématiquement (Produits = multiplication, Sommes = addition) pour limiter strictement le nombre d'états possibles d'une donnée. JDK 27 : fonctionnalités et calendrier de sortie openjdk.org/projects/jdk/27 infoworld.com/article/4202901/jdk-27-the-new-features-of-java-27.html JDK 27 est la prochaine version majeure de Java, une version non-LTS avec seulement 6 mois de support, qui succède à JDK 26. La disponibilité générale est prévue pour le 15 septembre 2026, avec des release candidates les 6 et 20 août 2026. Le périmètre est désormais figé (feature freeze) avec neuf JEP au programme. Le ramasse-miettes G1 devient le collecteur par défaut dans tous les environnements, et plus seulement en mode serveur. Ajout d'un support de la cryptographie post-quantique pour TLS 1.3, via des échanges de clés hybrides combinant algorithmes classiques et résistants au quantique. Finalisation de l'API PEM pour encoder et décoder clés, certificats et listes de révocation au format PEM. L'API Vector poursuit son incubation pour la douzième fois, permettant d'exprimer des calculs vectoriels compilés en instructions CPU optimisées. Les en-têtes d'objets compacts, introduits en JDK 24, sont désormais activés par défaut et réduisent l'empreinte mémoire du tas. Plusieurs previews sont reconduites : constantes paresseuses (3e preview), types primitifs dans les patterns (5e preview) et concurrence structurée (7e preview). Ajout d'une fonctionnalité de rédaction in-process pour JFR, afin de masquer les données sensibles dans les enregistrements de profiling. Kotlin 2.4 : nouveautés du langage et outillage kotlinlang.org/docs/whatsnew24.html Kotlin est un langage moderne, multiplateforme (JVM, Android, iOS, JavaScript, Wasm) développé par JetBrains, souvent utilisé comme alternative à Java. Les context parameters passent en stable : ils permettent de fournir des dépendances implicites à une fonction sans les déclarer en paramètre explicite, un peu comme une injection de dépendances. Les collection literals arrivent en expérimental : on peut écrire une liste avec des crochets, comme en Python, par exemple val fruits = ["pomme", "banane"]. L'API UUID de la bibliothèque standard devient stable, pour générer et manipuler des identifiants uniques nativement. Nouvelles fonctions utilitaires comme isSorted() pour vérifier si une collection est déjà triée. Support de Java 26 côté JVM et alignement automatique des versions Java et Kotlin dans les projets Maven. Kotlin/Native, la compilation vers du code natif iOS et macOS, active par défaut un nouveau ramasse-miettes plus rapide et améliore l'export vers Swift. Kotlin/Wasm, la compilation vers WebAssembly pour faire tourner du Kotlin dans le navigateur, rend la compilation incrémentale stable. Kotlin/JS permet désormais d'exporter des value classes vers JavaScript et TypeScript. Le compilateur K1, l'ancienne génération, n'est plus supporté : seul le nouveau compilateur K2 reste disponible. JEP 540 : une API JSON simple intégrée au JDK (incubation) openjdk.org/jeps/540 Le JDK ne propose aujourd'hui aucune API JSON native, obligeant à dépendre de bibliothèques externes comme Jackson, Gson ou Jakarta JSON pour parser ou générer du JSON. Cette JEP remplace la JEP 198 de 2014 et cible JDK 28 avec le nouveau module incubateur jdk.incubator.json. L'objectif est de couvrir les besoins simples d'extraction de données sans binding de données ni API de streaming, en laissant ces cas avancés aux bibliothèques existantes. L'API s'articule autour de l'interface scellée JsonValue avec six sous-types : JsonString, JsonNumber, JsonBoolean, JsonNull, JsonObject et JsonArray. Le parsing est strict et conforme à RFC 8259 : pas de virgules finales, pas de commentaires, et les noms de membres dupliqués provoquent une erreur. Donc pas de JSON5 La navigation se fait via get et tryGet, et la conversion vers des types Java via asInt, asLong, asDouble, asString, asMap ou asList. En cas d'erreur, une JsonValueException précise le chemin exact dans le document et sa position en ligne et colonne. Le pattern matching sur les sous-types de JsonValue permet de gérer proprement l'évolution du format d'un document JSON dans le temps. La génération se fait via toString pour une sortie compacte ou Json.toDisplayString pour une sortie indentée et lisible. À terme, le JDK pourrait utiliser cette API en interne, par exemple pour remplacer les fichiers de configuration au format property par du JSON. Autres nouvelles du JDK openjdk.org/jeps/535 openjdk.org/jeps/541 le mode generationel pour Shenandoah est prévu par défaut et deprécue le non générationel en 28 fini le support de Java sur Apple Intel GraalVM 25.2 : références compressées et Graal Script Agent medium.com/graalvm/… GraalVM est une machine virtuelle polyglotte d'Oracle offrant compilation JIT avancée et compilation en image native pour accélérer les applications Java et d'autres langages. Cette version 25.2 fait partie du train de releases innovation qui livre les nouveautés plus vite, pendant que GraalVM 25.0 reste la version stable recevant les correctifs de sécurité critiques. Nouveauté phare, le Graal Script Agent transforme des demandes en langage naturel en plugins sandboxés exécutés localement, en JavaScript ou Python, avec un accès restreint aux APIs de l'application. Les références compressées sont désormais activées par défaut dans Native Image sur les systèmes 64 bits, remplaçant les adresses complètes par des valeurs 32 bits relatives au tas. Cette optimisation réduit de 39% la consommation mémoire RSS d'une application Micronaut connectée à Oracle Database, comparée à la version 25.0. Contrepartie de cette optimisation, le tas géré est désormais plafonné à 32 Go. Le garbage collector G1 est maintenant disponible sur toutes les plateformes, y compris Windows, via l'option –gc=G1. G1 apporte de meilleures performances, une latence réduite et un démarrage plus rapide, avec des images natives plus petites grâce à l'optimisation guidée par profil. Le Vector API de Java est activé par défaut pour exploiter les instructions SIMD, utile pour le machine learning et le traitement de données. Bonne intégration avec l'écosystème via Micronaut 5.1, Quarkus et WebAssembly. Shopify arrête React Native pour ses applis mobiles iOS et Android et repasse à du natif avec Swift et Kotlin shopify.engineering/back-to-native Les progrès majeurs des LLM (IA) réduisent drastiquement le coût du développement sur deux plateformes distinctes. Les bénéfices du natif pur restent supérieurs, moins de couches d'abstractions, de dépenfances externes, et plus rapide pour adopter les dernières fonctionnalités des OS Les bibliothèques open-source (Skia, FlashList, Restyle) évoluent : Skia sera forkée par William Candillon, FlashList cherche un nouveau repreneur, Restyle sera archivée fin 2026. Migration des applications (Shop, Shopify, etc.) réalisée en mode "greenfield" (reconstruction totale) assistée par IA. Utilisation du système "Helix" pour un développement itératif et contrôlé par des agents IA. Découplage de la logique métier et de l'interface via une CLI pour accélérer les tests et éviter les lenteurs des simulateurs. L'application Shop a été entièrement reconstruite en natif en 12 semaines ; les autres suivront. Librairies LangChain4j CDI est une extension CDI qui intègre LangChain4j avec CDI de Jakarta EE langchain4j.github.io/langchain4j-cdi LangChain4j CDI : Extension intégrant LangChain4j à Jakarta EE et MicroProfile. Services IA : Injection et gestion de cycle de vie via @RegisterAIService . Orchestration d'agents : 11 topologies d'agents configurables par annotations. Serveur MCP : Conversion de beans CDI en serveurs Model Context Protocol. Fonctionnalités d'entreprise : Configuration externe, tolérance aux pannes et observabilité OpenTelemetry. Installation Maven : Deux extensions disponibles selon l'environnement (build-time pour Quarkus/Helidon, portable pour WildFly/GlassFish/Liberty). Prérequis techniques : Java 17+, Jakarta EE 10, MicroProfile 6.1. Quarkus 3.36, 3.37 et 3.38 : trois releases avant Quarkus 4 quarkus.io/blog/quarkus-3-38-released quarkus.io/blog/quarkus-3-37-released quarkus.io/blog/quarkus-3-36-released Quarkus est un framework Java cloud natif optimisé pour GraalVM et HotSpot, conçu pour les microservices et les environnements conteneurisés. En 3.38 (29 juillet), l'équipe allège les nouveautés pour se concentrer sur Quarkus 4, la communauté atteint 1213 contributeurs. 3.38 introduit l'éviction basée sur le poids mémoire pour le cache Caffeine de second niveau d'Hibernate, en plus de l'éviction par comptage. 3.38 apporte l'extension Quarkus HTTP Problem qui implémente la RFC 9457 pour mapper les exceptions en réponses application/problem+json, intégrée à OpenAPI. 3.37 (24 juin) ajoute l'extension expérimentale quarkus jlink pour générer des images runtime JDK sur mesure et réduire la taille des conteneurs. 3.37 active par défaut la sérialisation Jackson sans réflexion pour de meilleures performances. et 3.39 lesdesactivent et les rement en opt-in 3.37 introduit dans REST Client RestMultiResponse pour lire codes de statut et en-têtes sur des réponses REST en streaming, avec passage à Hibernate ORM 7.4 qui exige PostgreSQL 14 minimum. 3.36 (27 mai) propose Quarkus Signals en expérimental, un système de communication typée entre composants inspiré des events CDI et de l'EventBus Vert.x. 3.36 embarque des SBOM applicatifs exposés via /.well-known/sbom, y compris en image native selon la spécification GraalVM. 3.36 ajoute l'authentification OIDC via JWT SPIFFE, facilitant l'identité de charge de travail en environnement zero trust. Micronaut Framework 5.1.0 : injection de dépendances, IA et sécurité renforcées github.com/micronaut-projects/micronaut-platform/…/v5.1.0 Micronaut est un framework JVM pour microservices et applications cloud-natives, avec injection de dépendances à la compilation et démarrage rapide. Introduction d'Open DI 1.0.0, une implémentation CDI Lite s'appuyant sur l'infrastructure d'injection de dépendances de Micronaut. Côté données, support officiel de SQLite et intégration MyBatis, avec ETags basés sur les valeurs pour le verrouillage optimiste. En sécurité, arrivée d'un module OWASP HTML Sanitizer, délégation d'authentification @RunAs et résolution de locale via OIDC. Côté IA, LangChain4j ajoute le support Chroma, la mémorisation de chat Oracle et l'authentification Google injectée pour Vertex AI, avec passage du MCP en version 2.0.0. Mises à jour majeures des dépendances : Spring Boot 4.1.0, Jetty 12.1.10, Tomcat 11.0.23, OpenTelemetry 1.64.0 et Kubernetes Java Client 27.0.0. SSL activé par défaut par service pour les clients HTTP Infrastructure Ça coûte combien de faire tourner un LLM local sur son Apple Silicon ? towardsdatascience.com/how-much-does-a-local-llm-actually-cost-to-run-i-measured-every-watt-on-apple-silicon Coût électrique des LLM locaux sur Mac Apple Silicon Un modèle 120B (MoE) coûte 5x à 10x moins cher qu'un modèle 27B (Dense). Le coût dépend du débit (tokens/seconde), pas du nombre de paramètres. Modèle dense –> Charge 100% des poids par token = lent et très énergivore. MoE (Mixture of Experts) –> N'active qu'une fraction des poids = rapide et économe. Conclusion : Pour réduire la facture électrique, choisir des modèles MoE quantifiés (haut débit). Kubernetes 1.36 (Haru) : sécurité renforcée et alignement IA infoq.com/news/2026/05/kubernetes-1-36-released Kubernetes est la plateforme open source de référence pour l'orchestration de conteneurs, portée par la CNCF. La version 1.36 nommée Haru apporte 70 améliorations : 18 passent stables, 25 en bêta et 25 en alpha, avec 106 entreprises et 491 contributeurs. Les user namespaces passent en disponibilité générale, isolant le root du conteneur de celui de l'hôte. Les Mutating Admission Policies passent en GA, remplaçant les webhooks par des règles CEL natives plus performantes. L'autorisation de l'API kubelet devient plus fine, remplaçant le droit trop large nodes/proxy. Le labeling SELinux des volumes utilise désormais mount -o context, accélérant le démarrage des pods. Plusieurs avancées ciblent les charges IA : gang scheduling en bêta, préemption consciente des groupes de pods, et allocation dynamique de ressources activée par défaut pour le partage fin des GPU. Le redimensionnement vertical des pods en place passe en bêta et activé par défaut, ajustant CPU et mémoire sans redémarrage. Suppression du plugin gitRepo, source de risque de sécurité, et du mode IPVS de kube-proxy, tous deux dépréciés de longue date. Avec la sortie de 1.36, la version 1.34 devient la plus ancienne branche encore supportée et entre en maintenance, ne recevant plus que des correctifs critiques avant sa fin de support. Terraform vs OpenTofu en 2026 : la divergence est actée ecorpit.hashnode.dev/terraform-vs-opentofu-in-2026-the-fork-has-diverged-so-which-do-you-standardize-on env0.com/insights/opentofu-in-2026-what-the-terraform-fork-became-after-three-years-of-independence Terraform est l'outil historique d'Infrastructure as Code de HashiCorp, OpenTofu en est le fork open source lancé après le changement de licence. HashiCorp est passé de la licence MPL 2.0 a la BUSL 1.1 en aout 2023, ce qui a poussé une partie de la communauté a créer OpenTofu sous la Linux Foundation. IBM a racheté HashiCorp pour 6,4 milliards de dollars, finalisé en février 2025, tandis qu'OpenTofu rejoignait le CNCF comme projet sandbox en avril 2025. OpenTofu prend de l'avance sur des fonctionnalités inédites : chiffrement du state côté client depuis la v1.7, valeurs éphémères qui gardent les secrets hors du state depuis la v1.11, et prevent_destroy dynamique en v1.12 (mai 2026). Terraform garde l'avantage sur l'orchestration managée avec Terraform Stacks, désormais en disponibilité générale, sans équivalent natif côté OpenTofu. Le coût diverge fortement : HCP Terraform facture jusqu'à 0,99 dollar par ressource gérée et par mois, alors qu'OpenTofu reste une CLI gratuite couplée au backend de son choix. Fidelity Investments a migré plus de 2000 applications et 50000 fichiers d'état vers OpenTofu, la complexité venant surtout de l'écosystème (CI/CD, gouvernance) plutôt que du binaire lui-même. OpenTofu reste compatible avec les configurations Terraform jusqu'a la version 1.6.x, mais les versions Terraform plus récentes n'offrent plus aucune garantie de compatibilité. Pour les secteurs régulés, le chiffrement natif du state par OpenTofu et sa gouvernance ouverte sont des arguments forts face aux exigences de protection des données. La recommandation qui ressort des deux articles : partir sur OpenTofu pour les projets neufs et rester sur Terraform si l'on est déjà investi dans HCP Terraform et ses fonctionnalités de gouvernance. OTel est à la peine ? matduggan.com/otel-isnt-going-well-and-i-made-a-spreadsheet-about-it Le développement d'OTel est un peu au point mort Périmètre démesuré : Volonté de supporter un nombre gigantesque de langages, bibliothèques et frameworks. Pénurie critique de mainteneurs : Les données montrent une hyper-concentration du travail ; de nombreux SDK (comme PHP ou Ruby) dépendent d'une ou deux personnes seulement. Stabilité paralysante : La règle interdisant toute modification d'une fonctionnalité déclarée « stable » crée une peur de valider les nouveautés, entraînant des mois de débats. Solutions proposées par l'auteur : Créer un niveau « Bêta » temporaire (ex: 12 mois) entre les statuts « Expérimental » et « Stable ». Faire preuve de transparence sur les différences de qualité/maintenance entre les langages (ne pas mettre Go et Ruby sur le même plan). Communiquer activement sur le besoin urgent de nouveaux mainteneurs. Assouplir la politique de stabilité en acceptant des breaking changes bien documentés. Honeycomb transforme son infrastructure Kafka honeycomb.io/blog/transforming-how-we-run-kafka-honeycomb Honeycomb est une plateforme d'observabilité dont Kafka est le coeur du pipeline d'ingestion, traitant des millions d'événements par seconde. L'entreprise a migré de Confluent Platform auto-hébergée vers Apache Kafka 4.1.1 en mode KRaft. Le nouveau cluster tourne sur AWS EKS avec Strimzi comme couche d'orchestration Kubernetes. Motivation principale : la récupération après remplacement de broker était passée de 8-12h à 48-72h avec l'ancienne stack. Confluent imposait aussi sa solution propriétaire de Tiered Storage, impossible à corriger en interne. Un incident de décembre 2025 ayant vidé un cluster a révélé une fenêtre d'opportunité pour migrer. La migration s'est faite progressivement sur six clusters, de dogfood jusqu'à la production. Les producteurs sont basculés avant les consommateurs, avec une courte fenêtre de downtime assumée entre les deux. Le stockage utilise des NVMe en instance store plutôt que de l'EBS pour minimiser la latence. interessant de voir une société reprendre en main sa compétence et de voir les contraintes de certaines fonctionalités propriétaires Cloud AWS us-west-2 : panne réseau régionale et effet domino chez les fournisseurs SaaS blog.incidenthub.cloud/aws-us-west-2-outage-jul-24-2026 AWS us-west-2 (Oregon) est une région cloud majeure hébergeant de nombreux services et fournisseurs SaaS. Le 24 juillet 2026, une panne matérielle réseau a coupé la connectivité entre la région et le Seattle Metro pendant environ 20 minutes. Particularité notable, seule la couche de connectivité externe a été touchée, le trafic interne à la région a continué de fonctionner normalement. Après la réparation matérielle, une phase distincte de reconvergence des routes a de nouveau causé une connectivité intermittente pendant plusieurs dizaines de minutes. Les clients Direct Connect via EqSe2 ont subi une coupure bien plus longue que le reste, 1h17 au total. Neuf incidents chez sept fournisseurs ont cité explicitement AWS comme cause, dont SendGrid, SparkPost et NinjaOne. Fait marquant, les temps de rétablissement des fournisseurs tiers ont largement dépassé la durée de la panne AWS elle même. NinjaOne a mis 9h29 à se rétablir totalement, avec 150000 appareils tentant de se reconnecter simultanément freinés par des mécanismes de backoff et jitter. SparkPost a mis 6h45 à absorber l'arriéré de courriels accumulé pendant la coupure, avec encore 80 à 90 minutes d
