Sber développe GigaChain sans fork de LangChain et mise sur un paquet de compatibilité

Sber a expliqué comment il construit un écosystème open source autour de GigaChat et pourquoi il a abandonné son fork de LangChain au profit d'un paquet de compatibilité distinct. Ce virage a simplifié le développement d'agents IA au sein de l'entreprise et rendu la pile plus lisible pour les équipes externes.

Pourquoi l'approche a changé

GigaChain est né lorsque Sber a eu besoin d'un outil unique pour développer avec GigaChat, à la fois pour les équipes internes et pour les développeurs externes. Plutôt que de tout écrire de zéro, l'équipe a décidé de s'appuyer sur l'open source existant.

Elle a choisi LangChain comme base : c'était le framework le plus visible pour les systèmes d'agents, il fonctionnait avec différents modèles et n'enfermait pas les développeurs chez un seul fournisseur. Pour une grande entreprise, ce choix signifiait moins de risques, un démarrage plus rapide et un marché de spécialistes plus lisible.

Dans un premier temps, l'équipe est bel et bien passée par un fork. La raison était pratique : l'ère du prompt engineering ne faisait que démarrer, et dans LangChain de nombreux prompts étaient codés en dur en anglais. Pour GigaChat, mieux adapté au russe, cela créait des contraintes inutiles. Autre difficulté : il était compliqué de faire accepter rapidement dans le projet principal un vrai support multilingue et l'intégration de fournisseurs.

Mais cette approche est devenue trop coûteuse à maintenir assez vite.

«

Nous étions obligés de rapatrier de 100 à 200 modifications qui apparaissaient dans le projet principal littéralement chaque semaine. »

Lorsque LangChain a commencé à évoluer rapidement et à passer à une architecture modulaire, Sber a abandonné le fork et assemblé son propre paquet de compatibilité. Le scénario recommandé est désormais le suivant : le développeur installe LangChain standard et ajoute le paquet d'intégration de GigaChat.

Cette solution s'est révélée plus robuste : même après la disparition du paquet de la documentation officielle de LangChain, presque rien n'a changé pour les utilisateurs. De fait, l'équipe a conservé la compatibilité avec le standard du marché sans s'enliser dans une synchronisation sans fin du code d'autrui.

Ce que construit Sber

Autour de GigaChat, l'équipe ne développe pas un simple SDK, mais tout un écosystème ouvert. Son but n'est pas seulement de donner accès au modèle par API, mais de raccourcir le chemin vers un agent IA opérationnel. Selon l'équipe, une part importante des projets d'agents internes de Sber repose déjà sur cette pile, et les développeurs externes l'utilisent de plus en plus.

Un signal de demande : la bibliothèque Python pour travailler avec l'API GigaChat figure, selon ClickPy, parmi les 1,5 % de paquets les plus téléchargés de PyPI en téléchargements mensuels.

• Bibliothèque Python pour l'intégration avec l'API GigaChat
• paquet de compatibilité avec LangChain à la place d'un fork maison
• agent autonome ouvert GigaAgent
• documentation, exemples d'intégration et guides pratiques
• webinaires, articles et démonstrations en conférence

GigaAgent joue un rôle à part. L'équipe ne l'a pas conçu comme un projet de démonstration de laboratoire, mais l'a amélioré grâce aux retours des ingénieurs et des métiers. Lors de dizaines de conférences en 2025, les développeurs ont présenté l'agent en direct et recueilli des remarques : où il faut un REPL et des outils, où l'exécution locale est critique et où la modularité compte davantage. Les métiers, eux, ont poussé vers des cas d'usage concrets : analyse de données, préparation de présentations et travail avec des sources d'entreprise.

Ce qu'apporte l'open source

Pour Sber, l'approche ouverte règle plusieurs problèmes à la fois. D'abord, le recrutement est plus simple : si la pile est construite autour de LangChain et de bibliothèques compatibles, l'entreprise n'a pas à chercher des profils pour une plateforme interne entièrement singulière. Ensuite, la barrière pour porter vers GigaChat des solutions d'agents existantes s'abaisse. L'idée est simple : si un développeur a déjà construit un agent sur un framework populaire, il doit pouvoir l'adapter plus facilement à un modèle russe sans tout réécrire.

Il y a aussi un troisième effet : l'aide de la communauté. L'équipe cite l'exemple de LlamaIndex : au départ, Sber ne prenait pas en charge ce framework faute de ressources, mais un développeur externe a ensuite envoyé une pull request ajoutant le support de GigaChat sur la base d'une bibliothèque existante. Résultat : l'écosystème a obtenu l'intégration d'une autre pile populaire quasiment sans coût interne.

La politique de licences reste aussi simple que possible : pour ses projets, l'équipe choisit généralement MIT et surveille de près les licences et le comportement des maintainers externes.

Pour Sber, la communication autour de l'open source n'est pas une activité annexe, mais une part du produit. L'équipe répond sur GitHub, entretient la documentation, publie des articles, anime des chaînes Telegram, organise des webinaires et se rend aux conférences spécialisées. Rien qu'en 2025, elle a donné plus de 15 interventions externes. Dans ce modèle, le contenu ne sert pas aux relations publiques, mais à raccourcir le délai entre une version, les retours et l'itération suivante du produit.

Ce que cela signifie

L'histoire de GigaChain montre que, pour les piles IA d'entreprise, la compatibilité avec les principaux outils open source du marché compte aujourd'hui davantage qu'un fork maison à tout prix. Si Sber tient ce cap, GigaChat pourrait nettement consolider sa position dans le développement de systèmes d'agents en russe et dans les usages en entreprise, où la rapidité de déploiement et l'accès à une pile familière comptent souvent plus que l'exotisme technologique.