LCC 338 - Le soulèvement des bots de skills

Épisode de Les Cast Codeurs Podcast par Emmanuel Bernard, Guillaume, Antonio, Arnaud, Katia · 20 mars 2026 · 1 h 57 min

Gros zoom sur les skills et leurs usages dans les coding agents, sur les benchmarks de stacks techniques MCP, mais aussi du Java 26-27, du HttpClient, du NodeJS, des scenarios nucléaires pilotés par l'IA, de la méthodologie, bref on ne s'ennuie pas !

Enregistré le 15 mars 2026

Téléchargement de l'épisode LesCastCodeurs-Episode-338.mp3 ou en vidéo sur YouTube.

News

Langages

Bruno Borges a créé un site, inspiré d'un site récent qui montrait comment CSS avait évolué, qui illustre justement comment Java a bien évolué au fil du temps, et est devenu un langage encore plus élégant https://javaevolved.github.io/

Code simplifié: main() allégé, var, blocs de texte, API String enrichie.

Pattern Matching: switch sur types, instanceof amélioré, record patterns.

Données: Records, collections immuables faciles à créer, méthodes de listes.

Concurrence: Threads virtuels, CompletableFuture, StructuredTaskScope, ScopedValue.

Erreurs & Sécurité: NPE précis, catch multiples, Optional amélioré, filtres de désérialisation.

I/O & Réseau: HttpClient moderne, E/S fichiers/console simplifiées, transferTo.

Dates & Heures: API modernisée, précise, immutables et thread-safe.

Langage: Interfaces sealed/private, import de modules, Math.clamp

Streams: Nouveaux opérateurs (takeWhile, mapMulti, Gatherers, teeing).

Outils & Perf: jshell, exécution simplifiée, jwebserver, AOT, JFR, optimisation mémoire.

10+ raisons de ne pas utiliser le HttpClient du JDK, avec un article très détaillé de Brice Dutheil https://blog.arkey.fr/2026/02/08/ten-reasons-to-not-use-jdk-httpclient/

JDK HttpClient: intégré, non-upgradable. OkHttp: plus lourd (dépendance Kotlin).

TLS/SSL: JDK: SSLContext limité, vérif hôte globale, épinglage manuel, SSLParameters rigides. OkHttp: contrôle fin (SSLSocketFactory/TrustManager), vérif hôte/épinglage dédiés, ConnectionSpec structuré.

Connexions: JDK: pas de repli, fabrique socket custom impossible (pas UDS/Named Pipes direct), pool limité (propriétés système, contrôle pauvre avant JDK 20/21). OkHttp: repli automatique, fabrique custom, pool granulaire.

Réseau: JDK: résolveur DNS par défaut, Authenticator unique. OkHttp: résolveur DNS custom, authentificateurs séparés (proxy/serveur).

Cycle Requêtes: JDK: pas d'intercepteurs ni API événements intégrés. OkHttp: addInterceptor, EventListener pour événements granulaires.

Ressources: JDK: pas d'arrêt propre avant JDK 21. OkHttp: arrêt granulaire (pool, exécuteur, cache).

Timeout: JDK: désactivé après en-têtes; le transfert du corps peut dépasser le timeout initial.

JDK 26 et JDK 27 : ce qui nous attend — https://www.infoq.com/news/2026/02/java-26-so-far/

JDK 26 est une version non-LTS prévue le 17 mars 2026, avec 10 nouvelles fonctionnalités réparties en 5 catégories

Le support HTTP/3 arrive enfin dans l'API HTTP Client standard de Java (JEP 517)

La Structured Concurrency (projet Loom) en est à sa 6e preview, avec l'ajout d'une méthode onTimeout() sur StructuredTaskScope.Joiner

Les Lazy Constants passent en 2e preview : des constantes initialisées à la demande, utiles pour optimiser le démarrage

Le G1 GC gagne en performance via une réduction des synchronisations entre threads applicatifs et threads GC (JEP 522)

Le cache d'objets AOT (JEP 516) est étendu pour fonctionner avec n'importe quel GC, y compris ZGC

L'API Applet est définitivement supprimée (JEP 504), fermant une page historique de Java

L'encodage PEM des objets cryptographiques continue sa preview avec support de chiffrement/déchiffrement de KeyPair

Pour JDK 27 (septembre 2026), l'échange de clés post-quantique hybride pour TLS 1.3 est déjà ciblé (JEP 527)

Project Valhalla progresse avec une preview des Value Classes : objets sans identité, à champs final uniquement

Librairies

Une étude de performance montre que Java est un super choix pour développer des serveurs MCP https://www.tmdevlab.com/mcp-server-performance-benchmark.html

Comparaison de performances de serveurs MCP (Model Context Protocol) en Java, Go, Node.js, Python.

Méthodologie: 3,9 millions requêtes, environnement Docker (1 cœur CPU, 1 Go RAM/serveur).

Fiabilité: 0% d'erreurs pour toutes les implémentations.

Tiers de performance:

1 (Haute): Go & Java (latence

▪︎ Go: Efficacité mémoire exceptionnelle (18 Mo vs 220 Mo pour Java).

▪︎ Java: Latence marginalement meilleure, mais 12x plus de mémoire.

2 (Moyenne): Node.js (latence ~10,7 ms, ~560 requêtes/s). Surcharge par instanciation.

3 (Faible): Python (latence ~26,5 ms, ~290 requêtes/s). Limité par GIL.

Recommandations production:

Go: Optimal forte charge, cloud-native, optimisation coûts.

Java: Latence très basse critique, infrastructure Java existante.

Node.js & Python: Adaptés charges modérées/faibles, développement/test.

Node.js et Python peuvent être optimisés pour améliorer leurs performances en production.

Et encore, en Java, le benchmark n'a pas utilisé GraalVM pour une compilation native, ce qui aurait donné des chiffres côté mémoire qui aurait concurrencé Go

Qui a la meilleure perf entre Quarkus et Spring pour faire des serveurs MCP ? https://medium.com/@egekaraosmanoglu/spring-boot-vs-quarkus-which-java-runtime-wins-the-ai-mcp-tools-performance-battle-4da9d6a248d5

Quarkus JVM: Débit et latence les plus élevés (jusqu'à 16 381 req/s, 65% plus rapide que Spring Boot), surpasse Spring Boot même avec Apache Camel.

Quarkus Native: Consommation mémoire la plus faible (118 MB), démarrage instantané, performance prédictible.

Spring Boot MVC: Bonnes performances, écosystème mature, nécessite un "warm-up" important (jusqu'à 44% de gain).

Spring Boot WebFlux: Légèrement meilleur débit et latence que MVC (~5%), mais plus de mémoire et complexité réactive.

Coût architectural:

MapStruct: Impact négligeable (Apache Camel: Réduction de débit de 8-21%, mais valeur ajoutée significative; Quarkus JVM + Camel reste > Spring Boot baseline.

Protocole MCP: Sur Quarkus JVM (avec Camel), surpasse gRPC.

Recommandations:

Débit max: Quarkus JVM.

Coût/Serverless: Quarkus Native.

Intégration d'entreprise: Quarkus JVM + Camel + MapStruct.

Meilleur choix Spring: Spring Boot WebFlux + MapStruct.

Benchmark des stacks qui implémentent MCP https://www.tmdevlab.com/mcp-server-performance-benchmark-v2.html

MCP (Model Context Protocol) est le protocole d'Anthropic pour connecter les LLMs à des outils et sources de données externes ; ce benchmark compare 15 implémentations serveur.

39,9 millions de requêtes traitées avec zéro erreur, sur des charges I/O réalistes (Redis + HTTP API) plutôt que des tâches CPU synthétiques.

Rust atteint 4 845 RPS avec seulement 10,9 Mo de RAM ; Quarkus obtient 4 739 RPS avec la meilleure latence (4,04 ms en moyenne, 8,13 ms au P95).

Go (3 616 RPS) et Spring MVC (3 540 RPS) constituent un second groupe solide.

Node.js plafonne à 423 RPS ; Bun est 2,2x plus rapide sur un code identique (876 RPS) ; Python atteint 259 RPS avec 4 workers et uvloop.

Découverte notable : un bug dans le SDK Rust rmcp v0.16 ajoutait ~40 ms de latence à toutes les réponses HTTP, limitant le débit à 1 283 RPS ; corrigé en v0.17 via la PR #683.

Les images natives GraalVM réduisent la mémoire de 27 à 81 % mais dégradent le débit de 20 à 36 % ; Quarkus-native est l'exception avec 36 Mo RAM et 3 449 RPS.

Spring MVC (bloquant) surpasse WebFlux (réactif) à 50 utilisateurs simultanés, rappelant que le modèle réactif n'est pas toujours gagnant.

Recommandations : Rust ou Quarkus pour la production haute charge, Go pour le cloud-native, Bun plutôt que Node.js en JavaScript.

Jakarta EE 12 Milestone 2 : données, cohérence et configuration https://www.infoq.com/articles/jakartaee-12-milestone-2/

Jakarta EE est la plateforme Java entreprise open-source, socle de frameworks comme Quarkus et Spring, qui standardise les APIs pour la persistance, les transactions, la sécurité, etc.

Jakarta EE 12 adopte Java 21 comme baseline (avec support Java 25) et supprime définitivement le SecurityManager déprécié.

Autres épisodes de « Les Cast Codeurs Podcast »

À propos du podcast

Les Cast Codeurs : le podcast en français de, par et pour les développeurs. Prenez connaissance des dernières nouvelles de la sphère Java et du développement en général. Plongez sur un sujet précis avec les épisodes interview. Supportez les radotages de vos hôtes : Emmanuel Bernard (ex Red Hat,…

Les Cast Codeurs Podcast

Épisodes similaires

Tous les épisodes de Les Cast Codeurs Podcast · Plus de podcasts Actualités