Koog : des agents LLM en Kotlin idiomatique, de la JVM à iOS
Koog is a JVM (Java and Kotlin) framework for building predictable, fault-tolerant and enterprise-ready AI agents across all platforms – from backend services to Android and iOS, JVM, and even in-browser environments. Koog is based on our AI products expertise and provides proven solutions for complex LLM and AI problems
En bref
- De quoi s’agit-il ?
- JetBrains publie sous Apache-2.0 un framework d'agents pour Kotlin et Java, avec graphes de workflow, persistance d'état et intégrations Spring Boot et Ktor. La promesse multiplateforme se paie en contraintes de version et en maturité inégale des artefacts.
- À qui s’adresse-t-il ?
- Koog convient aux équipes déjà sur Kotlin ou Java qui veulent des agents typés, traçables et intégrés à Spring Boot ou Ktor, avec un besoin réel de partage de code entre serveur, Android et iOS. Il ne convient pas à qui cherche un écosystème Python mature, ni à un projet bloqué sous JDK 11 ou Kotlin ancien.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 2 jours.
- En quel langage est-il écrit ?
- Principalement Kotlin, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : des agents LLM qui restent du code Kotlin ordinaire
La plupart des bibliothèques d'agents supposent Python, un runtime séparé ou un service externe. Pour une équipe qui maintient une application Spring Boot ou un backend Ktor, cela signifie un second langage, un second système de build et une frontière réseau supplémentaire à instrumenter. Koog prend le chemin inverse : le README décrit un framework Kotlin avec une API Java, distribué comme dépendance Maven classique. L'agent est un objet construit dans le même projet que le reste du service, avec les mêmes outils de compilation et le même cycle de tests.
Le public visé est donc précis. Un développeur JVM qui doit ajouter une couche d'inférence à un produit existant, sans réécrire son architecture autour d'un orchestrateur externe. Le README cite explicitement Spring Boot et Ktor parmi les intégrations, ce qui confirme cette cible. Les cas multi-plateformes sont couverts aussi : la liste des cibles supportées inclut JVM, JS, WasmJS et iOS, avec Android mentionné dans les topics du dépôt. Autrement dit, un même code d'agent peut théoriquement tourner côté serveur et côté mobile. C'est une promesse forte, et elle impose des contraintes que je détaille plus bas.
Ce que fait réellement le moteur : exécuteurs, graphes et état
L'exemple du README montre la brique centrale : un AIAgent reçoit un promptExecutor, un systemPrompt et un llmModel. Ici, MultiLLMPromptExecutor enveloppe un OpenAILLMClient construit avec une clé lue dans la variable d'environnement OPENAI_API_KEY. Le résultat s'obtient par un appel à agent.run avec la chaîne utilisateur, et la valeur retournée est imprimée. Ce point d'entrée minimal cache une architecture plus large, décrite dans les fonctionnalités : des workflows sous forme de graphes pour les comportements complexes, un système de fonctionnalités modulaire, et une API de streaming qui gère aussi les appels d'outils parallèles.
Deux mécanismes méritent l'attention de qui évalue le framework. D'abord la persistance d'état : le README indique que l'agent peut être restauré à des points précis de son exécution, ce qui est la condition pour reprendre un workflow long après un redémarrage de service. Ensuite la compression d'historique, présentée comme un moyen de contenir la consommation de tokens dans les conversations longues. Ces deux briques répondent à des problèmes d'exploitation, pas à des problèmes de démonstration. Le changement de fournisseur en cours de conversation, avec conservation de l'historique, relève de la même logique : le fournisseur devient un détail interchangeable plutôt qu'un choix structurant.
Les fournisseurs listés sont Google, OpenAI, Anthropic, DeepSeek, OpenRouter, Ollama et Bedrock. Ollama compte, parce qu'il permet de faire tourner le modèle en local, et le dépôt dispose d'un workflow CI dédié aux tests Ollama. Côté intégration, le framework couvre MCP pour les outils et ACP pour la communication avec des clients standardisés. La traçabilité s'appuie sur OpenTelemetry, avec W&B Weave et Langfuse cités comme fournisseurs d'observabilité.
Mise en route : dépendances, JDK et version de Kotlin
L'installation passe par Maven Central. En Gradle Kotlin DSL, le README donne deux lignes à ajouter dans build.gradle.kts : implementation("ai.koog:koog-agents:1.2.0") et implementation("ai.koog:koog-agents-additions:1.2.0-beta"). La variante Groovy utilise la même coordonnée avec des guillemets simples. En Maven, les identifiants changent de suffixe : groupId ai.koog, artifactId koog-agents-jvm pour le premier artefact et koog-agents-additions-jvm pour le second, tous deux en version 1.2.0 et 1.2.0-beta respectivement. Le dépôt mavenCentral doit figurer dans la liste des repositories, quelle que soit la méthode choisie.
Les prérequis sont explicites et constituent le premier filtre. JDK 17 ou supérieur pour la JVM. Kotlin 2.3.10 ou supérieur, à déclarer explicitement dans un projet existant. Le README renvoie au fichier gradle/libs.versions.toml du dépôt pour les dépendances transitives, et cite les versions courantes : kotlinx-coroutines 1.10.2, kotlinx-serialization 1.10.0 et kotlinx-datetime 0.7.1. Ce détail a son importance : une équipe qui épingle des versions plus anciennes de ces bibliothèques devra arbitrer avant même d'écrire la première ligne d'agent.
Pour l'exécution, il suffit d'une clé d'API en variable d'environnement, OPENAI_API_KEY dans l'exemple, avec la mention que le même schéma vaut pour Anthropic, Google ou OpenRouter. Le badge Maven Central du README pointe vers l'artefact ai.koog:koog-agents, ce qui permet de vérifier la version publiée sans passer par le dépôt Git. À noter que le README ne documente pas de configuration de build pour les cibles JS, WasmJS ou iOS au-delà de la liste des cibles supportées : pour ces plateformes, il faut se tourner vers la documentation du site.
Le point faible : additions en beta et cibles non JVM sous-documentées
Le README affiche un badge Kotlin Stable et un fichier VERSIONING.md qui annonce un versionnement sémantique. Dans le même bloc d'installation, l'artefact koog-agents-additions est proposé en 1.2.0-beta, quand koog-agents est en 1.2.0. Le décalage est visible et il faut le lire comme tel : une partie du périmètre n'est pas encore au même niveau de garantie que le cœur. Le README ne précise pas ce que contient cet artefact additions, ni quelles fonctionnalités en dépendent. C'est une zone d'ombre réelle pour qui planifie une mise en production.
Deuxième réserve : le discours multiplateforme. La liste des cibles supportées mentionne JVM, JS, WasmJS et iOS, et la description du dépôt évoque Android et même le navigateur. Mais tout l'appareillage d'installation fourni dans le README concerne la JVM : Gradle avec l'artefact koog-agents, Maven avec koog-agents-jvm, prérequis JDK 17. Rien sur la configuration Gradle Multiplatform, les source sets ou les particularités iOS. La documentation en ligne est citée comme ressource, mais elle n'est pas reprise ici. Une équipe mobile devra donc valider elle-même que les cibles annoncées sont utilisables dans son contexte.
Troisième réserve, plus structurelle : le dépôt est marqué comme projet incubateur JetBrains. Le README porte le badge correspondant. Cela ne dit rien de la qualité du code, mais cela indique un engagement dont les modalités peuvent évoluer. Le support communautaire passe par un canal Slack et un projet YouTrack dédié, pas par un contrat. Pour un composant qui va porter la logique métier d'un agent en production, c'est un paramètre à intégrer dans la décision.
Face à LangChain4j : graphes compilés contre chaînes composées
L'alternative la plus directe sur la JVM est LangChain4j. La différence tient à la façon dont le flux de contrôle est représenté. Koog met en avant des workflows sous forme de graphes : le comportement de l'agent est décrit comme une structure, avec des noeuds et des transitions, et le framework peut persister l'état à des points d'exécution identifiés. LangChain4j, lui, s'organise autour de composants composés dans du code Java : chaînes, services d'IA déclaratifs, mémoire conversationnelle. On décrit un enchaînement d'appels, pas un graphe avec points de reprise.
Cette distinction a des conséquences pratiques. Un graphe se prête mieux aux workflows à branches, aux boucles de validation et à la reprise après incident, parce que la position dans le graphe est une donnée sérialisable. Une chaîne composée en Java reste plus simple à lire pour un enchaînement linéaire, et l'écosystème Java de LangChain4j est plus ancien. Koog apporte en échange un DSL typé, une API de streaming avec appels d'outils parallèles et une liste de fournisseurs qui inclut DeepSeek, OpenRouter et Bedrock en plus des acteurs habituels.
Le choix se joue aussi sur le langage. LangChain4j vise Java en priorité, avec une interopérabilité Kotlin. Koog est écrit en Kotlin et expose une API Java, avec un DSL conçu pour Kotlin. Pour une base de code Kotlin, la seconde option s'intègre plus naturellement. Pour une base Java ancienne, la première demandera moins d'adaptation. Aucun des deux n'est un choix par défaut : le critère décisif est la forme du workflow que vous devez exécuter.
Coût de maintenance et implications de la licence Apache-2.0
Le rythme de publication est documenté par les releases : 1.0.0 en mai 2026, 1.1.1 en juillet 2026, 1.2.0 en août 2026. Trois versions en quatre mois, dont une mineure, ce qui suggère un projet actif mais aussi des évolutions fréquentes à suivre. Le versionnement sémantique revendiqué dans VERSIONING.md limite la casse sur les versions majeures, mais le décalage entre koog-agents en 1.2.0 et koog-agents-additions en 1.2.0-beta montre que tous les artefacts ne progressent pas au même rythme. Une montée de version implique donc de vérifier les deux coordonnées séparément.
Le coût caché se situe dans les prérequis. Exiger JDK 17 minimum et Kotlin 2.3.10 minimum, c'est imposer une mise à jour de toolchain à toute équipe restée en arrière. Sur un projet Android, cela touche la version du plugin Kotlin et potentiellement la configuration de compilation. Sur un backend, cela peut concerner l'image de base du conteneur. Ces changements se planifient avant l'adoption, pas après.
La licence est Apache-2.0, ce qui autorise l'usage commercial, la modification et la redistribution, avec conservation des mentions de copyright et du fichier de licence. Elle inclut une clause de brevets. Je ne donne pas d'avis juridique : pour un usage en produit distribué, la revue du fichier LICENSE.txt du dépôt et l'accord des juristes de votre organisation restent nécessaires. Le framework étant un projet incubateur JetBrains, la gouvernance du projet et la politique de contribution sont encadrées par le code de conduite open source de JetBrains, et les demandes passent par YouTrack plutôt que par un contrat de support.
Conclusion éditoriale
Koog convient aux équipes déjà sur Kotlin ou Java qui veulent des agents typés, traçables et intégrés à Spring Boot ou Ktor, avec un besoin réel de partage de code entre serveur, Android et iOS. Il ne convient pas à qui cherche un écosystème Python mature, ni à un projet bloqué sous JDK 11 ou Kotlin ancien. Avant d'adopter, vérifiez trois choses concrètes : la version de Kotlin déclarée dans votre libs.versions.toml, la stabilité de koog-agents-additions puisque les exemples Gradle et Maven du README pointent vers 1.2.0-beta, et la stratégie de persistance de l'état des agents, car c'est elle qui détermine la reprise après incident.
Notes de la communauté