LangSmith BYOC déplace le plan de données dans votre VPC sur AWS, Azure et Google Cloud
Le 3 novembre 2026, LangChain annonce que LangSmith BYOC est généralement disponible sur AWS et en bêta sur Azure et Google Cloud : les traces, évaluations et déploiements d’agents restent dans votre compte cloud pendant que LangChain exploite l’infrastructure. Les équipes sous contrainte de conformité peuvent abandonner l’auto-hébergement sans rapatrier la maintenance ni la migration de leurs données.
3 novembre 2026. LangChain annonce que LangSmith BYOC — Bring Your Own Cloud — est généralement disponible sur AWS et passe en bêta sur Azure et Google Cloud. 3 novembre 2026, même jour. Le principe tient en une phrase : vos traces, évaluations, jeux de données, prompts et déploiements d’agents restent dans votre compte cloud, sur le cloud de votre choix, pendant que LangChain opère le plan de données — orchestration, mise à l’échelle, mises à jour. 3 novembre 2026, toujours. La nouveauté est l’extension du dispositif, lancé sur AWS en août, aux deux autres grands clouds, avec pour chacun des briques d’infrastructure natives. L’essentiel : l’observabilité des agents cesse d’être un choix entre « vos données chez le fournisseur » et « tout maintenir soi-même ».
Pour une équipe plateforme qui déploie des agents en production, c’est la fin d’un arbitrage douloureux entre conformité et charge opérationnelle.
La séparation plan de contrôle / plan de données
BYOC découpe LangSmith en deux. LangChain opère le plan de contrôle, qui porte l’authentification, la configuration des organisations et des espaces de travail, les métadonnées de facturation, les clés API hachées et les actifs statiques de l’interface. Vous possédez le plan de données, qui détient tout ce qui est sensible : traces, prompts, jeux de données, expérimentations, déploiements d’agents et secrets d’espace de travail.
Cette séparation a une conséquence pratique : une organisation peut détenir plusieurs plans de données, chacun dans un compte et une région spécifiques, chaque plan portant ses propres espaces de travail. Une équipe plateforme peut ainsi faire tourner un plan de données de production et un plan de préproduction dans des comptes AWS séparés, pendant qu’une business unit standardisée sur Azure exploite son propre déploiement BYOC. Chaque équipe voit ses traces atterrir dans le compte qu’elle possède — et dont elle répond devant son RSSI.
C’est exactement ce que l’auto-hébergement ne permettait pas sans douleur. Jusqu’ici, les équipes soumises à des frontières de conformité strictes déployaient LangSmith en self-hosted : les données restaient dans leur périmètre, mais il fallait des ingénieurs plateforme dédiés pour patcher des services à état, configurer les bases de données et mener les migrations de schéma.
Ce que ça change concrètement sur chaque cloud
Le dispositif est construit à partir des briques natives de chaque fournisseur — et c’est là qu’il se distingue d’une solution « cloud-agnostique » au rabais.
Sur AWS, le plan de données tourne dans votre VPC existant, la base de données dans les sous-réseaux que vous choisissez. Les équipes sécurité peuvent attacher leurs propres security groups à chaque rôle applicatif, de sorte que le plan de données s’insère dans les politiques d’inspection d’entrée et de sortie que vous exécutez déjà.
Sur Azure, le plan de données s’exécute dans un réseau virtuel dédié avec un point de terminaison AKS privé. LangChain déploie Istio et KEDA via Helm pour le routage d’entrée et la mise à l’échelle événementielle, et la télémétrie système remonte vers Azure Monitor. Le support des LangSmith Sandboxes sur Azure est annoncé comme imminent.
Sur Google Cloud, les plans de données peuvent tourner dans n’importe quelle région au lancement, gérés depuis le plan de contrôle américain de LangSmith. Les ressources utilisent des noms scopés par namespace pour ne pas entrer en collision avec votre infrastructure existante.
Sur les trois clouds, les plans de données BYOC exposent aussi les points de terminaison Managed Deep Agents. Et le LLM Gateway du plan de données appelle les modèles de 11 fournisseurs d’office, plus tout endpoint compatible OpenAI ou Anthropic — vous choisissez donc le fournisseur de modèle en plus du cloud.
La migration depuis l’auto-hébergement, sans repartir de zéro
Le point qui décide souvent entre rester en self-hosted et basculer, c’est la migration des données. LangChain a fait l’effort de la rendre non destructive.
La migration se déroule en deux temps. Les ressources d’espace de travail partent avec un outil de migration open source (langchain-ai/langsmith-data-migration-tool) qui lit l’instance self-hosted et la laisse intacte et vivante pendant le transfert. Sur chaque cloud, il couvre les utilisateurs et rôles, les jeux de données, les expérimentations et les prompts, ainsi que la configuration des files d’annotation, les règles d’automatisation, les tableaux de bord et les ressources Fleet. Les traces, runs et retours utilisateurs migrent dans une seconde étape, opérée par LangChain avec un outillage interne — la migration de traces n’est disponible que sur AWS aujourd’hui.
Côté transparence, les modules Terraform qui sous-tendent BYOC sont publics (github.com/langchain-ai/terraform), tout comme l’outil de migration. C’est une différence de fond avec un service managé opaque : vous pouvez auditer la forme de l’infrastructure avant de la déployer dans votre compte.
Ce qu’il faut vérifier avant de signer
Le modèle n’est pas magique, et trois points méritent un examen attentif.
- Le modèle de responsabilité partagée. Vous restez responsable de la conformité du compte, des clés de chiffrement et de l’accès réseau ; LangChain opère la mise à l’échelle et les mises à jour. Lisez la matrice documentée avant d’engager le plan de données sur des charges sensibles.
- Le rôle IAM scopé. La mise en place passe par un module Terraform qui crée un rôle IAM délimité : vérifiez que les permissions accordées correspondent au strict nécessaire, pas à un rôle trop large.
- Les limites régionales de Google Cloud. Au lancement, le plan de contrôle est américain : si votre politique de résidence des données impose un plan de contrôle local, la bêta GCP n’est pas encore votre chemin.
Le reste — mises à niveau continues, fonctionnalités LangSmith livrées peu après leur sortie cloud, mise à l’échelle automatique — est le bénéfice que les clients AWS constatent depuis août et que la version multi-cloud généralise.
Verdict
BYOC vaut le déplacement pour une population précise : les équipes qui ont déjà un LangSmith self-hosted pour des raisons de conformité, ou qui refusent LangSmith Cloud parce que les traces quittent leur périmètre. Si vous êtes dans ce cas, la migration open source et la gestion opérée du plan de données suppriment l’essentiel du coût que vous portiez — la décision est nette sur AWS (GA), plus prudente sur Azure et GCP (bêta). Si vos données peuvent déjà vivre chez le fournisseur, restez sur LangSmith Cloud : le surcoût d’un plan de données BYOC ne se justifie que par une frontière de conformité, pas par le confort.