Points clés
- Nous sommes partis d'un véritable point de douleur client. Snyk Assist a été conçu pour permettre aux clients d'obtenir plus facilement des réponses rapides et précises sans avoir à chercher dans la documentation, le contenu de support et les systèmes de compte.
- Nous avons traité la confiance et le contrôle d'accès comme des exigences fondamentales du produit. Comme Snyk est une plateforme de sécurité, l'agent a été conçu pour rester dans les limites des permissions de l'utilisateur et pour prouver qu'il était sûr, fiable et correct avant un déploiement plus large.
- Nous l'avons conçu pour être utile, mesurable et évolutif. Un seul runtime LangGraph alimente plusieurs surfaces, tandis que les évaluations LangSmith aident l'équipe à détecter les régressions, à améliorer les réponses et à continuer de livrer en toute confiance.
Snyk est une plateforme de sécurité IA. Sa plateforme détecte et corrige les vulnérabilités dans le code, les dépendances open source, les conteneurs et la configuration cloud, et elle s'intègre dans les endroits où les développeurs travaillent déjà : l'IDE, la pull request et le pipeline.
Nous construisons des produits de sécurité pour les développeurs, ce qui signifie que nos clients posent des questions difficiles et précises. Ils veulent des réponses sur les vulnérabilités, le contexte de leur compte, les problèmes de support et le comportement du produit, souvent en plein milieu d'un travail réel. Avant Snyk Assist, ces informations étaient dispersées dans la documentation du produit, les articles de support, les notes de version, le contenu d'apprentissage et les données de compte. Trouver la bonne signifiait généralement lire plusieurs pages ou ouvrir un ticket et attendre.
Snyk Assist est un agent conversationnel construit sur LangChain et LangGraph avec une observabilité gérée dans LangSmith. Il aide les clients à trouver des réponses en langage naturel et peut agir en leur nom. Il peut rechercher des problèmes ouverts, vérifier si un paquet présente des vulnérabilités connues, ouvrir un dossier de support depuis la conversation ou enregistrer une demande de fonctionnalité lorsque le flux de travail demandé n'est pas encore pris en charge.
Il a commencé comme un outil interne pour notre propre équipe de support. En septembre 2026, nous l'avons intégré au produit Snyk principal, où chaque client payant peut y accéder.
Dans cet article, nous expliquons comment nous avons construit Snyk Assist, depuis le cas d'usage de support interne initial jusqu'à l'expérience produit destinée aux clients. Nous couvrons également l'architecture sous-jacente, notamment la manière dont nous avons géré les permissions, l'état, les garde-fous et l'évaluation lors de sa mise à l'échelle.
Le défi : un support qui ne passait pas à l'échelle et un niveau d'exigence élevé pour livrer de l'IA
Notre équipe de support traite des milliers de cas toutes les deux semaines environ. Chacun devait être lu, classé par produit, gravité et responsable, puis acheminé au bon endroit. Cela représentait un défi de passage à l'échelle à mesure que les demandes des clients augmentaient. Un agent était la solution évidente, mais comme nous développons des logiciels de sécurité, tout ce que nous mettons devant les clients doit répondre aux mêmes normes que nous attendons du reste de notre produit. Nous devions prouver trois choses : que l'agent répondait correctement, refusait ce qu'il devait refuser, et ne renvoyait jamais rien que l'utilisateur n'était déjà autorisé à voir.
« La partie difficile de la création d'agents n'est pas ce que le modèle peut faire, c'est de prouver que l'agent fonctionne réellement. Nous soumettons chaque modification à des évals dans LangSmith, et si elle ne franchit pas la barre, elle n'est pas livrée. »
—Bailey Millns, AI Engineer, Snyk
Plutôt que de lancer directement le produit, nous avons commencé par tester en interne avec notre propre équipe. Cette approche a permis de s'assurer que les erreurs initiales restaient au sein de Snyk plutôt que d'affecter les clients payants. Elle nous a également permis de tester en toute sécurité des fonctionnalités plus risquées et d'observer le comportement de l'agent avant un déploiement plus large.
Cette phase interne nous a permis d'établir notre modèle opérationnel avec LangSmith avant d'introduire des fonctionnalités destinées aux clients. Chaque trace de ces premières sessions alimentait directement nos jeux d'évaluation, nous donnant une solide compréhension des performances de l'agent au moment de son lancement dans le portail de support.
Phase 1 : outillage interne
Pendant environ un an, Snyk Assist a fonctionné comme un outil interne pour l'équipe de support client, à la fois comme outil de triage des cas et comme agent virtuel, les seuls utilisateurs étant le personnel de Snyk. Les tests internes de l'agent nous ont permis de faire émerger des cas limites qui n'apparaissaient pas dans les tests hors ligne, et la boucle de rétroaction se mesurait en heures plutôt qu'en cycles de publication.
Phase 2 : le portail de support
En avril 2026, nous avons lancé Snyk Assist auprès des clients dans notre portail de support. À ce stade, il pouvait saluer les utilisateurs par leur nom, comprendre le contexte du compte, effectuer une vérification de santé à la connexion et ouvrir un ticket à toute heure de la journée sans attendre l'intervention d'un humain.
Phase 3 : le produit principal
Le 1 septembre 2026, Snyk Assist a été intégré au produit Snyk principal, aux côtés de notre nouvelle navigation, sous forme de panneau dans la barre supérieure de chaque page, pour chaque client payant.
Nous avons conservé le même runtime d'agent à chaque phase. Seule la surface devant lui a changé.
Un runtime, plusieurs points d'entrée
Snyk Assist est un agent LangGraph unique derrière plusieurs surfaces : une application Slack, une application web et un accès API direct, tous acheminés via le même framework sécurisé.
Nous avons choisi LangChain en raison de sa vaste communauté, de son écosystème robuste et de son statut de standard du secteur pour la création d'agents.
« LangChain avait de loin la plus grande communauté et le plus grand écosystème, et devenait rapidement le standard de facto pour la création d'agents. »
—Jada Ross, Ingénieure IA, Snyk
En tant que petite équipe, nous voulions un runtime unique afin de pouvoir corriger les bugs, livrer des fonctionnalités et gérer les réponses aux incidents depuis un seul endroit. Cette simplicité nous a permis de passer rapidement à l'échelle sans fragmenter notre architecture.
De plus, l'utilisation du middleware de LangChain au lieu de développer une solution personnalisée a fourni des points d'intégration définis pour le contexte, les garde-fous et les solutions de repli des modèles. Cette configuration nous permet de mettre à jour ou de réordonner des fonctionnalités avec de simples modifications d'une ligne plutôt que par de vastes réécritures de code.
Voici les quatre décisions de conception qui ont rendu le système exploitable en production :
- Des outils sous forme de fonctions typées, enregistrés par utilisateur. Nous attachons les outils au moment de la requête en fonction des permissions dont l'utilisateur connecté dispose réellement. Cela signifie que l'agent ne peut accéder qu'aux données que l'utilisateur pouvait déjà voir. La plupart des outils sont des microservices séparés, ce qui nous permet de les dimensionner indépendamment et d'ajouter des capacités sans modifier la boucle de l'agent.
- Du middleware au lieu de la plomberie. La gestion du contexte, les garde-fous et les solutions de repli de modèle s'intègrent à des points définis du cycle de vie de l'agent au lieu d'être tissés à la main dans la boucle. Ajouter ou réordonner un comportement ne nécessite qu'une modification d'une ligne dans une liste, pas une réécriture complète.
- L'état géré par le checkpointer. L'historique des conversations est persisté dans PostgreSQL et indexé par session, de sorte que la mémoire multi-tours, la mise à l'échelle entre pods et la reprise d'une conversation fonctionnent tous sans câblage supplémentaire.
- La boucle comme plateforme interne. Comme un agent n'est qu'un modèle, des outils, un prompt, un middleware et un checkpointer, une fabrique partagée renvoie le graphe compilé et chaque équipe fournit sa propre configuration. La plupart des nouveaux flux de travail sont un changement de configuration plutôt qu'une nouvelle architecture.
« Du point de vue du développement, LangChain nous a fourni une abstraction d'agent complète, prête à l'emploi, ce qui nous a permis de nous concentrer sur l'impact et les capacités de notre agent, au lieu de réinventer l'orchestration, l'appel d'outils, le streaming et l'état. »
—Matt Jarvis, Director of AI Engineering, Snyk
Comment nous évaluons chaque changement
Chaque appel de modèle, appel d'outil et point de décision a été tracé dans LangSmith dès le premier jour du développement. Cette trace est devenue la base de notre façon de livrer.
Nous utilisons deux couches d'évaluation.
L'évaluation hors ligne exécute des ensembles de questions de test dans LangSmith. La première concerne de vraies questions avec des réponses correctes connues, marquées par un second modèle, afin de détecter rapidement si un changement de prompt ou de modèle a dégradé la qualité des réponses. La seconde est un exercice automatisé de red teaming où des personnes tentent de piéger l'agent pour qu'il ignore les instructions ou divulgue des secrets.
La CI comme porte de contrôle signifie que chaque pull request exécute l'agent réel sur ces suites de tests et bloque en cas de dépassement des seuils convenus et commités dans le dépôt.
L'évaluation en ligne note chaque exécution en production grâce à une tâche planifiée. Nous vérifions deux choses : la question portait-elle sur Snyk et la réponse y a-t-elle répondu ? Ces notes nous donnent un taux de déviation mesuré plutôt qu'une estimation. Nous catégorisons également chaque question par domaine produit, sujet, écosystème de langage et type d'erreur, offrant ainsi aux responsables produit une carte en temps réel des points où les clients rencontrent des difficultés.
La boucle de rétroaction se boucle au sein de nos agents de codage via le serveur MCP de LangSmith. Lorsque nous trouvons une mauvaise trace, nous pouvons l'examiner et la transformer en jeu de données sans quitter l'IDE.
Comme chaque étape est tracée dans LangSmith, nous pouvons tester les changements sur de vraies questions, détecter les régressions avant la livraison et transformer rapidement les mauvaises traces en nouveaux jeux de données. Cela nous offre une boucle de rétroaction plus rapide et rend la livraison beaucoup plus sereine.
L'impact : moins de tickets, des réponses plus rapides
Depuis que Snyk Assist a été mis à disposition des clients en 2026 :
- plus de 60,000 requêtes traitées
- plus de 500 comptes clients
- plus de 85 % des sessions résolues sans ticket de support, faisant économiser des centaines d'heures à l'équipe de support
- plus de 250 cas détectés automatiquement par l'agent et escaladés directement à la bonne équipe
Chaque conversation est notée et catégorisée, ce qui nous permet de voir quelles parties du produit génèrent le plus de confusion. Cela nous aide à améliorer la documentation.
Points clés à retenir et prochaines étapes
Snyk Assist a commencé comme un outil pour l'équipe de support de Snyk elle-même. Aujourd'hui, il a traité plus de 60,000 requêtes clients et résout plus de 85 % des sessions sans créer de ticket de support.Depuis septembre, Snyk Assist fait partie du produit lui-même, disponible sur chaque page aux côtés du travail que les clients sont déjà en train de faire. Nous voulons qu'il soit une partie utile de l'expérience Snyk pour chaque client.
Lien : https://docs.snyk.io/navigate-the-snyk-web-ui#snyk-assist