Quatre voies ITSM pour les processus existants
CentaurNexus relie ServiceNow, Jira Service Management, Freshservice et Zendesk via de véritables adaptateurs. Chaque cas reste rattaché au bon tenant et au bon contexte client. Demande, statut, décision et résultat peuvent ainsi être reliés sans copier manuellement des identifiants entre interfaces.
Notifications sortantes vers Teams et Slack
Les webhooks n'envoient dans un premier temps que des notifications sortantes. Le catalogue d'événements couvre les demandes et décisions d'accès, les changements de Policy, les nouveaux incidents, les sessions révoquées et les consentements acceptés. Chaque tenant et chaque canal définit les événements qu'il reçoit réellement.
Au quotidien, cela signifie que le helpdesk voit une nouvelle demande d'accès, la sécurité reçoit le signal d'un changement de Policy, et l'exploitation est informée d'un nouvel incident ou d'une session révoquée. Le message contient le tenant concerné, le type de cas, le statut actuel et un chemin direct vers le contexte CentaurNexus correspondant. La même information fiable atteint ainsi les équipes qui en ont besoin pour leur prochaine tâche.
Le statut du système cible reste déterminant
Un ticket ITSM ou un message de chat ne constitue pas une preuve de l'effet d'un changement. Pour les processus d'écriture, CentaurNexus ne confirme le succès qu'après l'effet sur le système cible et un read-back. Le système ITSM reçoit ainsi un statut fiable, et non pas seulement l'indication qu'un appel API a été lancé.
Ne pas perdre le contexte MSP
Pour les MSP, l'accès reste limité aux tenants réellement gérés. Ticket, événement et audit conservent le bon contexte de tenant. La responsabilité et les transmissions restent ainsi traçables.
Ce qui doit figurer dans un cas ITSM
Une intégration n'est utile que si elle transmet plus qu'un simple lien. Un cas bien formé relie un résumé compréhensible au tenant, à l'utilisateur ou à l'objet concerné, à la source, au statut actuel et au rôle responsable suivant. Les données techniques brutes ne sont pas copiées sans discernement dans le ticket. L'opérateur reçoit le contexte nécessaire à sa tâche et un chemin contrôlé vers le cas CentaurNexus complet.
L'ID de ticket externe et l'ID de cas interne restent liés. Les changements de statut peuvent ainsi être rattachés sans mélanger les contextes client ou tenant. Le chemin d'audit documente quelle transmission a eu lieu, et quand.
Un workflow de helpdesk, du signalement à la résolution
Un utilisateur pourrait par exemple démarrer, dans son navigateur, une demande d'accès à un site bloqué. CentaurNexus complète le contexte utilisateur, appareil et Policy autorisé. Le système ITSM concerné en reçoit un cas structuré. Le helpdesk peut examiner le constat de départ, compléter les informations manquantes et décider de résoudre, d'approuver ou de transmettre le cas à un rôle spécialisé.
Si un changement contrôlé s'ensuit, le statut du ticket et l'exécution technique restent des états distincts. Le ticket peut indiquer que l'activation est en cours. L'état effectif n'est remonté qu'après un read-back confirmé. Si le workflow échoue, les équipes peuvent voir si la cause se situe dans le circuit de décision, l'adaptateur, l'activation ou le read-back.
Les notifications complètent le cas
Teams et Slack conviennent pour des signaux courts adressés au bon groupe. Un message peut attirer l'attention sur une nouvelle décision ou un statut modifié. La justification complète, les détails sensibles et l'action contraignante restent dans le contexte CentaurNexus ou ITSM prévu à cet effet.
Techniquement, CentaurNexus envoie vers une adresse de webhook entrant configurée par le tenant pour le service choisi. Du point de vue de CentaurNexus, le flux de données est sortant. Canal, sélection des événements et adresse cible relèvent donc de la configuration du tenant, et non d'un distributeur global inter-clients.
Responsabilité en cas de panne et de répétition
Un système ITSM injoignable ou un webhook rejeté ne doit jamais transformer à tort le cas Zscaler sous-jacent en succès ou en échec. La livraison de l'intégration possède son propre statut. La plateforme peut ainsi distinguer une action métier réussie d'une notification encore en attente.
La recette couvre aussi les répétitions. Une nouvelle tentative technique ne doit jamais créer de tickets dupliqués de façon incontrôlée ni de messages contradictoires. Affectation idempotente, ID externes et statuts de livraison visibles font donc partie du contrat d'intégration.
Systèmes ITSM différents, un seul contrat métier
ServiceNow, Jira Service Management, Freshservice et Zendesk ont des modèles d'objets, des droits et des logiques de statut différents. L'adaptateur traduit ces différences dans un cas CentaurNexus commun, sans ignorer les particularités du système cible.
Un incident peut être structuré différemment dans un système par rapport à une demande de service dans un autre. C'est pourquoi chaque client définit quel type de cas est utilisé pour quel workflow CentaurNexus. Champs obligatoires, pièces jointes, commentaires et statuts de clôture ne sont pas assimilés de façon uniforme.
Gérer secrets et adresses cibles par tenant
Les identifiants des adaptateurs ITSM et les adresses de webhook n'ont pas leur place dans une configuration de site publique ou un texte de ticket visible librement. Ils sont utilisés à l'exécution depuis le chemin de secrets prévu et restent rattachés au tenant. Les logs et messages d'erreur ne doivent jamais exposer ces valeurs.
Pour Teams et Slack, seules les destinations HTTPS autorisées sont acceptées. Un message de test vérifie le canal sans déclencher de cas métier. Les changements d'adresse cible, de sélection d'événements ou de statut actif sont gérés de façon traçable.
Protection des données lors des transmissions
Tous les détails techniques du contexte utilisateur, appareil ou flux n'ont pas leur place dans un ticket externe ou un canal de chat. Le mapping définit les champs nécessaires à l'objectif. Le contexte plus approfondi reste dans CentaurNexus et s'ouvre via un lien autorisé.
Pour les organisations internationales, région, langue et cercle de destinataires sont également vérifiés. Une notification doit atteindre le bon opérateur sans diffuser inutilement du contenu sensible dans des canaux d'équipe larges.
La responsabilité d'exploitation reste visible
L'intégration relie des systèmes, mais ne déplace jamais la responsabilité de façon invisible. L'équipe ITSM est responsable de ses formulaires, files et logique de statut. L'administrateur CentaurNexus est responsable du mapping de tenant, des rôles et de la configuration des adaptateurs. La décision métier reste avec le rôle prévu par le workflow.
Pour chaque adaptateur, des contacts techniques et métier sont définis. En cas d'incident, il reste ainsi identifiable si le problème concerne le cas CentaurNexus, l'API externe, les droits ou le canal cible.
Ce que vérifie une revue d'intégration quotidienne
L'exploitation contrôle les livraisons échouées, les transmissions ouvertes anormalement longtemps, les ID externes non rattachés et les canaux présentant des erreurs répétées. Le statut métier du cas reste séparé du statut technique de livraison.
Une courte revue évite qu'un changement réussi sur le système cible passe inaperçu à cause d'une notification manquante, ou qu'un ticket clôturé masque un effet technique encore non confirmé.
Mise en place en sept étapes
- Définir le système ITSM de référence et les types de cas concrets par tenant.
- Rattacher champs, valeurs de statut, rôles et limites de responsabilité.
- Mettre en place l'authentification et les droits nécessaires avec la portée la plus restreinte possible.
- Tester le rattachement tenant et client dans les deux sens.
- Configurer les canaux Teams ou Slack avec les événements sélectionnés.
- Valider les cas de succès, d'échec et de répétition dans des conditions contrôlées.
- Vérifier ensemble le read-back et le statut final du ticket.
L'objectif n'est pas un portail parallèle supplémentaire. CentaurNexus relie le contexte technique Zscaler à l'endroit où le support et l'exploitation pilotent déjà leurs tâches.
Questions fréquentes
Quels systèmes ITSM sont connectés ?
ServiceNow, Jira Service Management, Freshservice et Zendesk.
Les webhooks Teams et Slack sont-ils entrants ?
Non. Le périmètre décrit est pour l'instant exclusivement sortant.
Peut-on approuver directement depuis le chat ?
Non. Les webhooks décrits ici informent. Les décisions ont lieu dans le circuit CentaurNexus prévu à cet effet.
Sources et pour aller plus loin
Voir le déroulement dans son contexte
Choisissez le rôle correspondant dans le lanceur de démo. La démo utilise des données d'exemple préparées.
Ouvrir le lanceur de démo