Sber présente trois outils open source pour les agents d'IA et les applications JVM

Un agent d'IA a écrit du code, mais a perdu les contraintes d'architecture. Un service a mis à jour une commande, puis est tombé avant l'envoi de l'événement, et le système voisin n'a rien su. Le digest de Sber présente trois outils open source pour ce type de problèmes d'ingénierie : HG SDLC, Spring AI GigaChat et Schedulex. Ils couvrent des volets différents : la transmission du contexte entre agents, la connexion du modèle à l'application et l'exécution des tâches de fond après des pannes.

Le plus utile est de lire cette annonce à travers une question concrète : quelle part de l'infrastructure l'équipe maintient-elle elle-même aujourd'hui, et un projet prêt à l'emploi peut-il réduire ce travail ? La description publiée contient assez de détails techniques pour une première sélection. Mais les estimations d'efficacité restent des déclarations des auteurs.

HG SDLC : transmettre à l'agent la tâche avec son contexte

Imaginez une évolution classique : l'analyste a préparé les exigences, le développeur a choisi l'architecture, l'agent a modifié le code, les tests ont trouvé une erreur. Il faut maintenant renvoyer la tâche en correction de sorte que l'agent reçoive les exigences, les contraintes et les résultats de vérification. Si tout cela vit dans des discussions séparées, c'est à l'humain d'assurer la cohérence du processus.

HG SDLC propose de décrire la séquence de travail sous forme de graphe YAML. Il comporte des nœuds avec des missions pour les agents, des vérifications automatiques et des points où la décision revient à un humain. L'orchestrateur conserve le contexte, les artefacts et l'historique d'exécution, gère les transitions et permet de revenir à l'étape précédente.

Selon l'équipe, l'outil fonctionne au-dessus d'agents de codage compatibles avec l'Agent Client Protocol. Pour un lancement local, il faut Java 21, Node.js 22, PostgreSQL et un agent compatible. C'est un composant d'infrastructure distinct, qu'il faudra aussi configurer et maintenir.

Les auteurs estiment le gain d'efficacité du développement obtenu par la combinaison d'agents, de développement guidé par les spécifications et de HG SDLC à 16–30 %. Ils ne peuvent pas isoler la contribution de l'orchestrateur lui-même. Il serait donc prématuré de prendre ce chiffre pour une promesse d'accélération pour votre équipe. Le premier point à vérifier : combien de transmissions manuelles de contexte disparaissent réellement.

Spring AI GigaChat : intégrer le modèle dans une application existante

Le deuxième projet s'adresse aux équipes qui utilisent Java ou Kotlin et Spring Boot. Écrire une requête directe au modèle n'est pas difficile. Viennent ensuite l'historique de dialogue, la recherche dans les documents, les appels de fonctions, les réponses en streaming et les métriques. Maintenir tout cela dans une couche d'intégration séparée devient vite une tâche à part entière.

Spring AI GigaChat se présente comme un Spring Boot Starter et relie l'API GigaChat aux interfaces de Spring AI. L'application s'adresse au modèle via ChatClient, et les composants associés de l'écosystème aident à organiser le travail avec les documents, l'historique des messages et les outils.

Un scénario parlant : un assistant de documentation interne qui répond à un collaborateur et, si nécessaire, appelle une fonction de l'application. La logique métier reste du code Java ; l'intégration avec le modèle passe par Spring AI. Le document décrit aussi l'annotation @GigaTool pour déclarer les fonctions accessibles au modèle.

Avant la connexion, il faut vérifier la compatibilité des versions du starter, de Spring Boot et de Spring AI. Les auteurs soulignent séparément l'impact des changements d'API sur l'intégration. Une bibliothèque ouverte n'exempte pas non plus de configurer l'accès à l'API GigaChat et la confiance envers les certificats du serveur.

Schedulex : survivre à un redémarrage et préserver la cohérence des données

Le troisième outil traite le travail de fond sur la JVM. L'exemple clé : un service change le statut d'une commande et crée une tâche d'envoi d'événement dans la même transaction d'une base commune. En cas d'annulation, aucun de ces changements n'est conservé. Après un commit réussi, l'enregistrement de la tâche reste en base, même si l'application redémarre.

Schedulex propose des tâches isolées, des graphes de processus et CodeFlow, une description de processus en code ordinaire avec conditions, attentes et branches parallèles. Selon les auteurs, la reprise de CodeFlow s'appuie sur un journal des résultats des étapes et sur l'état en base. Lors d'une mise à jour de l'application, il faut vérifier la compatibilité du nouveau code avec l'historique enregistré.

La limite de la garantie est essentielle : une transaction de base de données ne rend pas atomique un appel HTTP externe. Si le destinataire a traité la requête mais que l'expéditeur n'a pas eu le temps d'enregistrer le succès, une nouvelle tentative peut créer un doublon. Les opérations externes doivent donc être idempotentes, c'est-à-dire traiter sans risque une requête répétée.

Les auteurs citent un résultat d'environ 30,7 mille exécutions par seconde, mais avec des gestionnaires vides et des tâches créées à l'avance. Ce n'est pas une prévision de performance pour un service réel.

L'étape pratique suivante consiste à choisir un scénario défaillant : perte de contexte, connexion du modèle ou redémarrage d'un processus de fond. Un test sur ce cas fournira plus d'éléments de décision qu'un chiffre global d'accélération.