 |
Les Cast Codeurs PodcastAuthor: Emmanuel Bernard, Guillaume Laforge, Vincent Massol, Antonio Goncalves, Aud Language: fr Contact email: Get it Feed URL: Get it iTunes ID: Get it |
Listen Now...
LCC 338 - Le soulèvement des bots de skills
Friday, 20 March, 2026
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 < 1ms, ~1600 requêtes/s). ▪︎ 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 (< ±5%). 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é. La nouvelle spec Jakarta Query unifie JPQL (SQL/relationnel) et JDQL (NoSQL) en un seul langage avec deux profils : Core Language (portable) et Persistence Language (relationnel). Jakarta Data 1.1 introduit les requêtes dynamiques via une API fluente avec Restriction et l'annotation @Is pour des conditions plus expressives. Jakarta Data supporte désormais les repositories stateful, permettant la gestion du cycle de vie des entités (persist, merge, detach, refresh) comme en JPA classique. Jakarta NoSQL 1.1 intègre Jakarta Query via une nouvelle interface Query et supporte les projections avec des Java records. Jakarta Persistence 4.0 supporte SequencedCollection (Java 21) comme type de collection dans les entités. Une nouvelle spec Jakarta Agentic AI est en cours, visant des APIs vendor-neutral pour construire des agents IA sur les runtimes Jakarta EE, avec intégration prévue de LangChain4j et Spring AI. Cette release est encore un milestone (pas pour la prod) — l'adoption large dépendra de la maturité des outils (IDE, validation de requêtes, diagnostics). Nouveaux benchmarks Quarkus vs Spring Boot : performance complète et transparente https://quarkus.io/blog/new-benchmarks/ Quarkus est un framework Java optimisé pour les conteneurs, connu pour son faible usage mémoire et son démarrage rapide, concurrent principal de Spring Boot. Les anciens graphiques de performance sur quarkus.io étaient obsolètes, sans date, sans source, et ne montraient pas le débit (throughput). L'absence de données sur le throughput faisait croire à tort que Quarkus avait de mauvaises performances à ce niveau. Un nouveau benchmark open source a été créé, transparent et reproductible, disponible sur GitHub. Résultats : Quarkus gère 2,7x plus de transactions par seconde que Spring Boot, démarre 2,3x plus vite, avec deux fois moins de mémoire. Des experts Spring Boot externes ont contribué à rendre la comparaison plus équitable, notamment sur la configuration des pools de connexions. Les threads virtuels améliorent le débit d'environ 6000 tps supplémentaires pour tous les frameworks testés. Spring Boot 4 offre un meilleur débit que Spring Boot 3, mais au prix d'un démarrage plus lent et d'une empreinte mémoire plus élevée. En mode natif (GraalVM), le démarrage est ultra-rapide mais le throughput est divisé par deux, pour Quarkus comme pour Spring Boot. Le mode natif n'est recommandé que pour les applis démarrées/arrêtées très fréquemment ou à faible charge. Quarkus 3.32 : fondations pour la prochaine LTS https://quarkus.io/blog/quarkus-3-32-released/ Quarkus est un framework Java cloud-natif optimisé pour GraalVM et HotSpot, conçu pour les microservices et les environnements conteneurisés. Cette version marque le feature freeze pour la prochaine version LTS 3.33. Intégration de Project Leyden (AOT JVM) : le démarrage d'une application REST minimale passe de 370ms à 80ms. L'entraînement Leyden peut se déclencher au build ou via les tests d'intégration. Amélioration du graceful shutdown HTTP, avec des contributions de l'équipe Keycloak. Enregistrement automatique dans Consul via l'extension Stork pour la découverte de services. Nouvelles fonctionnalités de sécurité : DPoP nonce providers personnalisés, support de rich authorization pour OIDC. Possibilité de personnaliser l'ordre des mécanismes d'authentification et ajout de OIDCAuthenticationCompletionAction. Mise à jour du framework Google Cloud Functions en version 2.0, ainsi que Camel Quarkus et Quarkus CXF. Les utilisateurs sur LTS 3.27 sont encouragés à tester la migration vers 3.33 pour faire remonter des retours. NodeJS change sa cadence de releases https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule Node.js est le runtime JavaScript côté serveur le plus utilisé, géré par la OpenJS Foundation avec un cycle de releases actif depuis la fusion avec io.js il y a dix ans. À partir de Node.js 27 (octobre 2026), le projet passe d'une release majeure tous les six mois à une seule par an. Chaque release deviendra LTS, supprimant la distinction entre versions paires (LTS) et impaires (non-LTS). Un nouveau canal Alpha est introduit, permettant les changements semver-major pendant la phase de test précoce. Les phases deviennent : Alpha (6 mois, oct. à mars), Current (6 mois, avr. à oct.), LTS (30 mois), puis EOL. La durée totale de support reste de 36 mois, identique au modèle actuel. La numérotation des versions s'aligne sur l'année calendaire de la release Current (ex : 27.0.0 en 2027). La version Alpha est signée, taguée et testée via CITGM, mais n'est pas destinée à la production. La motivation principale : les versions impaires étaient peu adoptées, la distinction pair/impair perturbait les débutants, et réduire les lignes de release parallèles allège la charge des bénévoles. Les auteurs de bibliothèques sont encouragés à intégrer les releases Alpha dans leur CI dès que possible pour détecter les régressions en amont. Web jQuery v4 est sorti https://www.infoq.com/news/2026/02/jquery-4-release/?utm_source=twitter&utm_medium=link&utm_campaign=calendar jQuery est une bibliothèque JavaScript historique qui simplifie la manipulation du DOM, la gestion des événements et les requêtes AJAX, encore très présente dans de nombreuses bases de code. Cette version majeure sort pour les 20 ans de la bibliothèque, après presque une décennie sans version majeure. Suppression du support d'Internet Explorer 10 et antérieur, Edge Legacy et les anciennes versions iOS/Android. IE11 reste encore supporté dans jQuery 4, mais sa suppression est prévue pour jQuery 5. Le code source migre d'AMD vers les ES modules, pour une meilleure compatibilité avec les outils de build modernes. Le bundler passe de RequireJS à Rollup. Suppression des fonctions dépréciées comme jQuery.isArray, jQuery.parseJSON et jQuery.trim, désormais disponibles nativement en JavaScript. Le fichier gzippé gagne plus de 3 000 octets ; le build slim descend à environ 19,5 ko. Ajout du support des Trusted Types pour faciliter la compatibilité avec les Content Security Policy strictes. jQuery reste pertinent pour la maintenance de bases de code existantes et les projets nécessitant une faible dépendance aux frameworks. La réactivité en frontend : concepts et approches https://www.sfeir.dev/front/quest-ce-que-la-reactivite-en-frontend/ Un article qui resume comment la reactivite est implementee en front web La réactivité en frontend désigne le mécanisme qui permet de mettre à jour automatiquement l'UI quand les données changent, sans manipulation directe du DOM. Sans réactivité, les développeurs doivent mettre à jour manuellement chaque élément de l'interface, ce qui est fastidieux et source d'erreurs. Le data binding unidirectionnel (React) distingue le flux de données des callbacks d'interaction utilisateur. Le data binding bidirectionnel (Angular) synchronise automatiquement données et UI dans les deux sens. Le Virtual DOM (React, Vue) compare une représentation en mémoire avec le DOM réel avant d'appliquer uniquement les changements nécessaires. Les observables via RxJS (Angular) permettent de gérer des flux de données asynchrones et des événements complexes. Les signaux (SolidJS, Angular récent, Svelte) offrent des mises à jour granulaires et de meilleures performances que les approches précédentes. Les signaux proposent une API plus simple que les observables tout en restant très performants. La réactivité abstrait la manipulation du DOM et permet aux développeurs de se concentrer sur l'état de l'application. Data et Intelligence Artificielle Gunnar Morling a annoncé la sortie de Hardwood, un nouveau parseur Java pour les fichiers Apache Parquet, grâce aux leçons apprises par le 1BRC challenge https://www.morling.dev/blog/hardwood-new-parser-for-apache-parquet/ Hardwood : Nouveau parseur Apache Parquet open-source (Java 21+). But : Dépasser parquet-java (dépendances lourdes, lecteur mono-threadé). Points clés : Dépendances minimes, pipeline de décodage multi-threadé. APIs : RowReader (ligne) et ColumnReader (colonne, haute perf.). Optimisations : Parallélisme pages, préchargement adaptatif, moins d'allocations. Développement : Assisté par IA (Claude Code), révision humaine. Futur : "Predicate push-down", compatibilité parquet-java, écriture, CLI, intégration Iceberg. Apicurio Registry passe AI-Native — https://www.apicur.io/blog/2026/02/05/apicurio-registry-ai-natural-evolution Apicurio Registry est un registre open-source de schemas (OpenAPI, AsyncAPI, Avro, Protobuf…) gérant versioning, validation et gouvernance des APIs. Le projet étend ses capacités pour devenir une plateforme native AI, en appliquant les mêmes principes de gouvernance aux agents IA. Support du protocole A2A (Agent-to-Agent) : les agents s'enregistrent via des "Agent Cards" et se découvrent mutuellement via des endpoints standardisés. Un serveur MCP intégré permet aux LLMs d'interagir directement avec le registre (découverte de schémas, validation, création). L'intégration avec Claude Desktop est déjà documentée, permettant de gérer les artefacts en langage naturel. Deux nouveaux types d'artefacts : PROMPT_TEMPLATE (templates de prompts versionnés avec variables) et MODEL_SCHEMA (validation des entrées/sorties des agents). Les SDKs Java (LangChain4j, Quarkus) et Python (LangChain, LlamaIndex) sont disponibles. Une démo multi-agents illustre le "context chaining" : chaque agent reçoit les sorties des agents précédents dans la pipeline. La roadmap prévoit : gestion du cycle de vie des agents, recherche sémantique, intégration dans les pipelines de déploiement. L'Histoire du Deep Learning : quand les machines ont commencé à apprendre https://blog.ippon.fr/2026/02/20/lhistoire-du-deep-learning-quand-les-machines-ont-commence-a-apprendre/ un article qui retrace les avancées clées du machine learning Le deep learning est un sous-domaine du ML basé sur des réseaux de neurones empilés en couches, aujourd'hui omniprésent dans la vision, le langage et la recommandation. Le Perceptron (1957) est le premier modèle formel d'apprentissage supervisé, mais il échoue sur des problèmes non linéaires comme le XOR : une limite structurelle, pas algorithmique. La rétropropagation du gradient (années 80) permet d'entraîner des réseaux multi-couches, mais souffre du problème de "vanishing gradient" qui bloque l'apprentissage en profondeur. L'essor du deep learning dans les années 2000 est autant une révolution matérielle qu'algorithmique : les GPU, conçus pour le jeu vidéo, se révèlent parfaitement adaptés aux calculs matriciels. AlexNet (2012) marque une rupture industrielle en démontrant qu'un CNN profond entraîné sur GPU surpasse largement les méthodes classiques en reconnaissance d'images. Les LSTM (1997) résolvent les problèmes de mémoire à long terme des RNN, mais leur nature séquentielle limite fortement la parallélisation. Les Transformers ("Attention Is All You Need", 2017) révolutionnent le domaine en remplaçant la récursion par un mécanisme d'attention parallélisable, adaptable aux GPU et TPU. L'IA générative introduit une rupture conceptuelle : les modèles apprennent la distribution des données pour en produire de nouveaux exemples, et non plus simplement classifier. Les LLM offrent un socle généraliste réutilisable pour de nombreuses tâches, là où l'IA prédictive nécessitait un modèle spécifique par problème. La question de l'AGI reste ouverte et très incertaine, mais l'IA devient déjà un "acteur logiciel" capable de raisonner et d'agir de manière autonome via les agents. Ca y est, Agent to Agent Protocol (A2A) est sorti en version 1.0 https://a2a-protocol.org/latest/announcing-1.0/ Prêt pour la prod Support multi-version ( multi-protocoles (gRPC, HTTP+JSON…) Multi-tenancy : un même endpoint peut supporter et exposer plusieurs agents distincts Agent Cards signées et vérifiables cryptographiquement pour vérifier l'identité des agents Flexibilité : les clients peuvent choisir de consommer les résultats par polling, streaming, ou également webhooks Outillage Le guide complet pour créer des skills pour vos agents, par Anthropic https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf Définition et structure : Les skills sont des dossiers contenant des instructions (fichier SKILL.md obligatoire) et des scripts qui enseignent aux agents comment exécuter des tâches spécifiques ou utiliser des outils MCP de manière fiable. Fonctionnement technique : Le système repose sur la "divulgation progressive" via un en-tête YAML critique, permettant à Claude de charger le contexte de la compétence uniquement lorsque la demande de l'utilisateur le nécessite. Cycle de vie : Le guide couvre toutes les étapes de développement, de la définition des cas d'usage (automatisation, création de documents) aux protocoles de test et de distribution. il couvre aussi comment tester (brievement) et des patterns communs Apprendre a utiliser les skills pour structurer son code ia https://philippart-s.github.io/blog/2026-02-18-anthropic-skills/ Les Skills Claude sont des packages d'instructions dans un dossier enseignant à Claude comment gérer des tâches spécifiques de façon cohérente. Un skill se compose au minimum d'un fichier SKILL.md avec un frontmatter YAML et des instructions en Markdown. Le frontmatter YAML impose deux champs obligatoires : name (en kebab-case) et description (max 1024 caractères expliquant quoi faire et quand le déclencher). Les skills fonctionnent de façon identique sur Claude.ai, Claude Code et l'API sans modification. Trois catégories principales : création de documents/assets, automatisation de workflows multi-étapes, et amélioration d'intégrations MCP. Les skills s'appuient sur le principe de divulgation progressive : frontmatter toujours chargé, corps du SKILL.md si pertinent, fichiers liés à la demande. Cinq patterns courants : orchestration séquentielle, coordination multi-MCP, raffinement itératif, sélection d'outils contextuelle, intelligence métier embarquée. Les tests doivent couvrir le déclenchement (90% des requêtes pertinentes), le fonctionnel et la comparaison avec la baseline sans skill. Pour la distribution, héberger sur GitHub avec un README séparé du dossier du skill (pas de README.md dans le dossier lui-même). Un skill-creator officiel permet de générer un premier SKILL.md en 15-30 minutes à partir d'une description en langage naturel. Les skills pour les agents, c'est une façon d'automatiser des tâches répétitives https://glaforge.dev/posts/2026/02/21/easily-build-a-local-mcp-server-in-java-with-a-skill-in-gemini-cli/ Construction facile de serveurs MCP Java locaux pour Gemini CLI et autres agents. Solution au code Java répétitif : JBang + LangChain4j + un "skill" utilisé par Gemini CLI. Idée clée : Une "skill" pour Gemini CLI automatise génération et installation des serveurs. La "skill" génère un fichier Java, le compile et l'enregistre dans les paramètres de Gemini CLI. Avantages : Élimine le boilerplate, enregistrement automatique, développement rapide. Conclusion : Les "skills" d'agent automatisent les tâches répétitives et systématisent l'expérimentation. Un SKILL.md par Julien Dubois pour permettre aux agents IA de créer des projets Spring en suivant les bonnes pratiques à la JHipster https://github.com/jdubois/dr-jskill/blob/main/SKILL.md Dr JSkill est une "Agent Skill" conçue pour aider les IA (GitHub Copilot CLI, Claude Code) à générer des applications Spring Boot 4.x selon les meilleures pratiques de Julien Dubois. Permet de créer des projets full-stack modernes utilisant Java 25, PostgreSQL et Docker, avec un choix de frameworks front-end (Vue.js par défaut, React, Angular ou Vanilla JS). Intègre des scripts Node.js multiplateformes pour automatiser la génération de projets via start.spring.io sans dépendances npm externes. Préconise des choix technologiques stricts : Maven uniquement, pas de Lombok, et utilisation de Hibernate ddl-auto pour la gestion du schéma (pas de Flyway/Liquibase). Supporte nativement la compilation GraalVM (images natives) pour des démarrages ultra-rapides (
