Les ingénieurs de support technique et les équipes d'opérations techniques (TechOps) se heurtent au quotidien à une rupture opérationnelle pénalisante : les retours clients, les accords de niveau de service (SLA) et les historiques de tickets résident dans Zendesk, tandis que les correctifs de code, le suivi des bogues et les discussions de développement sont hébergés sur GitHub. Lorsque ces deux environnements fonctionnent en silos, les agents de support passent des heures à naviguer d'un outil à l'autre, à chercher manuellement des issues sur GitHub, à copier des traces d'erreurs (stack traces) et à solliciter les développeurs sur Slack. Ce cloisonnement multiplie les signalements redondants et ralentit le traitement des incidents.
La plateforme Dust (dust.tt) apporte une réponse concrète grâce à une orchestration basée sur l'intelligence artificielle contextuelle. En connectant Zendesk et GitHub à Dust, les équipes peuvent concevoir des agents IA sur mesure qui comprennent simultanément les conversations du support et la base de code technique. Ces agents trient automatiquement les tickets entrants, repèrent les bogues déjà répertoriés sur GitHub, rédigent des notes d'analyse internes dans le centre de support et ouvrent des tickets d'ingénierie standardisés, sans rupture de contexte.
Ce guide détaille pas à pas la mise en place d'une architecture complète de tri et d'escalade d'incidents associant Dust, Zendesk et GitHub.
Vue d'ensemble de l'architecture : Comment Dust réunit le support et l'ingénierie
Pour bien appréhender l'intégration de Dust avec Zendesk et GitHub, il convient de distinguer les trois couches fonctionnelles de la plateforme :
| Couche architecturale | Fonctionnalités côté Zendesk | Fonctionnalités côté GitHub |
|---|---|---|
| Connections (Connaissance) | Indexe sémantiquement les tickets résolus et fermés (fenêtre de 180 jours par défaut) et les articles du Centre d'aide (Guide). | Synchronise en temps réel les issues, discussions, commentaires principaux de PR et, en option, le code source de la branche par défaut. |
| Tools (Actions) | Permet à l'agent d'exécuter Get Ticket (détails), Search Tickets (recherche syntaxique) et Draft Reply (brouillon de note interne privée). | Permet à l'agent d'interroger les dépôts, de créer des issues et de commenter des discussions ou des pull requests. |
| Surfaces (Interface et Déclencheurs) | Intègre l'application Dust dans le volet latéral de Zendesk et déclenche l'agent via des webhooks lors d'événements sur les tickets. | Reçoit des webhooks lors de changements d'état d'issues ou d'activités sur les pull requests. |
Cette structure garantit que Dust ne se contente pas de relayer des données brutes : il joue le rôle de centre d'analyse, interprète les requêtes client à la lumière des développements GitHub et applique des actions coordonnées dans les deux outils.
Étape 1 : Configurer les connexions de données (Connections)
Pour que les agents effectuent un diagnostic rigoureux, Dust doit d'abord disposer d'un accès en lecture aux connaissances du support et aux référentiels techniques.
1. Connecter Zendesk à Dust
- Dans votre espace Dust, rendez-vous dans Spaces > Connections et sélectionnez Zendesk.
- Indiquez le sous-domaine de votre instance Zendesk (
https://<sous-domaine>.zendesk.com). - Validez l'authentification OAuth avec un compte disposant des droits administrateur sur Dust et sur Zendesk (au moins sur Support et Guide).
- Accédez aux options sous Manage pour affiner la synchronisation :
- Périmètre et rétention des tickets : Par défaut, Dust synchronise les tickets résolus (Solved) et fermés (Closed) modifiés au cours des 180 derniers jours, avec une purge tournante à 120 jours. Si vos agents doivent analyser des incidents en cours, activez Sync Unresolved Tickets.
- Protection de la vie privée (Masquage PII) : Activez Hide Customer Information afin de retirer les noms et adresses e-mail des demandeurs des métadonnées indexées, tout en préservant le contenu technique du ticket.
- Filtrage par tags et champs personnalisés : Renseignez Included Tags (ex. :
tier-2oubug) pour isoler les demandes techniques. Si votre équipe utilise des champs personnalisés pour identifier le service concerné ou la sévérité, renseignez leur identifiant numérique dans Custom Field Tags ; Dust les convertira en étiquettesfieldName:valueexploitables par la recherche sémantique. - Plafond de requêtes API (TPS) : Fixez une limite de transactions par seconde si votre abonnement Zendesk impose des quotas stricts sur son API.
2. Connecter GitHub à Dust
- Dans Dust, allez dans Spaces > Connections > GitHub et cliquez sur Connect.
- Authentifiez-vous en tant qu'administrateur de l'organisation GitHub.
- Cochez les dépôts spécifiques à ouvrir à Dust (ex. : API principale, services d'infrastructure, applications front-end).
- Activez l'option Code synchronization (recommandé) : cela permet aux agents de consulter les fichiers de code de la branche par défaut en complément des discussions et issues. Le code est mis à jour toutes les 8 heures, tandis que les issues et PR sont synchronisées en quasi-temps réel.
- Sauvegardez la configuration. Dust générera automatiquement les index sémantiques basés sur les titres, contenus, labels et auteurs.
Étape 2 : Activer les outils d'action (Tools)
Les connexions apportent une mémoire passive. Pour que l'agent puisse rechercher des tickets, rédiger des analyses internes et créer des issues sur GitHub, il est nécessaire d'activer les Tools correspondants :
- Accédez à Spaces > Tools et cliquez sur Add Tools.
- Activez les Zendesk Tools :
Search Tickets: Requêtes de recherche ciblées (ex. :status:open priority:urgent tags:bug).Get Ticket: Récupération de l'historique complet des échanges, des métadonnées et des métriques de SLA.Draft Reply: Création d'une note interne privée (Private Comment), invisible pour le client, dédiée à la relecture par les agents.
- Activez les GitHub Tools :
- Définissez le mode d'authentification : Il est recommandé de choisir Workspace Credentials, ce qui assigne la création d'issues et de commentaires au robot officiel
@dust-agent(ou Personal Credentials pour agir avec les droits du compte utilisateur connecté).
- Définissez le mode d'authentification : Il est recommandé de choisir Workspace Credentials, ce qui assigne la création d'issues et de commentaires au robot officiel
Étape 3 : Créer l'agent de tri dans l'Agent Builder
Une fois les données et les outils en place, rendez-vous dans l'Agent Builder de Dust pour configurer l'agent spécialisé dans le tri d'incidents (par exemple nommé @tier2-triage).
Paramétrage de l'agent
- Modèle sous-jacent : Choisissez un modèle doté d'excellentes capacités d'analyse logique et de compréhension de code (Claude 3.5 Sonnet, GPT-4o ou Gemini 1.5 Pro).
- Connaissances associées (Knowledge) : Sélectionnez la connexion Zendesk (tickets et centre d'aide) et la connexion GitHub (dépôts et code).
- Outils assignés (Tools) : Cochez
Search Tickets,Get Ticket,Draft Replypour Zendesk, ainsi que les outils de recherche et de création d'issues GitHub. - Directives du système (Prompt) : Formulez des règles strictes régissant l'analyse technique, la vérification des doublons et la formulation des synthèses.
Tu es le copilote de support technique de niveau 2 et de tri des anomalies (Tier-2 Triage Copilot). Ta mission est d'analyser les tickets Zendesk, de les confronter à nos dépôts GitHub et d'apporter un diagnostic technique exploitable.
Lors de l'analyse d'un ticket Zendesk :
1. Extrais les messages d'erreur, les traces d'appels ou le comportement anormal, puis recherche dans le dépôt GitHub ciblé (par défaut : dust-tt/app-backend) si une issue ouverte ou récemment fermée correspond au problème.
2. Interroge les tickets Zendesk archivés pour déterminer si le problème s'est déjà manifesté et si une solution de contournement (workaround) éprouvée est documentée.
3. Si une issue GitHub existante est identifiée :
- Utilise l'outil Zendesk "Draft Reply" pour consigner une note interne privée (Private Comment).
- Inclus impérativement : (a) Le lien vers l'issue GitHub et son état actuel, (b) Un résumé de la cause racine, (c) La formulation technique recommandée ou la procédure temporaire à transmettre au client.
4. Si le bogue est inédit et reproductible :
- Utilise l'outil GitHub pour créer une nouvelle issue sur le dépôt approprié selon le format : [Triage] Brève description de l'incident. Précise l'ID du ticket Zendesk, l'environnement, les étapes de reproduction et les logs d'erreurs complets.
- Génère une note privée dans Zendesk mentionnant le numéro de l'issue GitHub nouvellement créée.
5. Ne publie jamais de réponse publique directement au client. Toutes les productions doivent impérativement prendre la forme de notes privées internes ou de réponses dans le volet latéral Dust, soumises à la validation préalable d'un collaborateur humain.
Étape 4 : Déployer l'interface et les déclencheurs Webhooks
L'agent peut être exploité selon deux modes complémentaires : à la demande dans Zendesk par les équipes de support, ou automatiquement en tâche de fond grâce à des webhooks.
Mode A : Copilote interactif dans le volet latéral de Zendesk
- Installez l'application officielle Dust depuis le Zendesk Marketplace.
- Ouvrez les paramètres de l'application Dust dans le Centre d'administration de Zendesk.
- Renseignez votre Workspace ID et une API Key générée par un administrateur Dust.
- Dans le champ Default Agent IDs, saisissez l'identifiant de votre agent
@tier2-triage. Ainsi, lorsqu'un collaborateur ouvre un ticket, cet assistant s'affiche par défaut dans le panneau latéral droit. - Assurez-vous que l'adresse e-mail de l'agent Zendesk correspond à son compte Dust. L'agent de support peut alors demander : "Ce bogue de paiement a-t-il fait l'objet d'un correctif récent ?", et recevoir immédiatement le lien vers la pull request et le diagnostic technique.
Mode B : Tri automatisé en arrière-plan via Webhook
Pour traiter immédiatement les tickets critiques dès leur enregistrement :
- Dans Dust, allez dans Spaces > Triggers et cliquez sur Add source.
- Choisissez le fournisseur natif Zendesk et connectez votre espace.
- Dans la configuration de l'agent
@tier2-triage, rendez-vous dans Triggers > Add triggers et sélectionnez la source créée. - Définissez les règles :
- Événement écouté : Ticket Created (Ticket créé) ou Ticket Updated (Ticket mis à jour).
- Conditions : Saisissez vos critères en langage naturel, par exemple :
"priority is urgent or tags contain technical-escalation". - Charge utile : Activez Include webhook payload afin que l'objet, le corps du message et les tags du ticket soient directement injectés dans l'analyse.
- Contrôle de débit : Indiquez un seuil maximal d'exécutions sur 24 heures afin de maîtriser les coûts en cas de pic d'incidents.
- Enregistrez. Dès qu'un ticket prioritaire arrive, Dust lance son investigation sur GitHub et consigne la note d'analyse interne avant même que le support n'ouvre le ticket.
Tableau comparatif : Tri intelligent Dust vs Outils de liaison classiques
| Critère d'évaluation | Outils de synchronisation point à point (ex. Git-Zen) | Tri contextuel piloté par Dust |
|---|---|---|
| Détection des doublons | Requiert une saisie manuelle de l'identifiant ou un tag rigide dans les commits. | Utilise la recherche sémantique RAG pour associer des erreurs similaires sans dépendre d'un libellé exact. |
| Analyse de la cause première | Aucune ; se borne à copier des blocs de texte d'un outil à l'autre. | Croise le code source, les résolutions antérieures et les journaux pour formuler des hypothèses de cause. |
| Assistance à la rédaction | Inexistante ; l'agent de support doit rédiger chaque réponse technique de zéro. | Produit des ébauches complètes de notes privées internes (Draft Reply) prêtes à être validées. |
| Protection des données (PII) | Risque de réplication directe de données personnelles de clients dans les dépôts techniques. | Filtre et masque les données personnelles des métadonnées avant l'indexation. |
| Impact sur les délais de résolution | Réduit uniquement les manipulations de copier-coller ; l'investigation reste longue. | Raccourcit l'analyse préliminaire et l'escalade vers l'ingénierie de plusieurs heures à quelques minutes. |
Gouvernance, modèle tarifaire et bonnes pratiques
- Maintenir la validation humaine (Human-in-the-Loop) : Limitez impérativement l'agent à l'outil
Draft Replypour les commentaires internes. Aucune réponse publique ne doit être transmise directement à un client sans l'approbation explicite d'un conseiller de support. - Cibler les déclencheurs pour préserver les quotas : Évitez de mobiliser des modèles d'IA sur des demandes courantes (réinitialisation de mot de passe, questions administratives). Réservez les webhooks aux tickets dotés de tags techniques ou d'un niveau d'urgence élevé.
- Dimensionner les abonnements et crédits : L'offre Business de Dust se décline en forfaits self-service, notamment Pro (24 €/siège/mois en facturation annuelle avec 8 000 crédits/mois) et Max (120 €/siège/mois en facturation annuelle avec 40 000 crédits/mois). Pour les grandes organisations, l'offre Enterprise propose un pool de crédits mutualisé, le provisionnement SCIM, des journaux d'audit et un SLA garanti. Calibrez vos crédits en anticipant le volume d'exécutions automatiques.
En unifiant le flux d'assistance de Zendesk et les référentiels de développement de GitHub au moyen de Dust, les équipes techniques suppriment les tâches manuelles redondantes, accélèrent l'analyse des dysfonctionnements et établissent une passerelle fluide entre le support et l'ingénierie.