Intégrations assistance pour le modèle de responsabilité partagée

Rubrique

Cet article décrit le périmètre de la responsabilité de NinjaOne en matière d'assistance pour nos différentes intégrations, y compris les limitations et ce à quoi s'attendre si un problème est en dehors de notre périmètre d'intervention.

Environnement

• Intégrations NinjaOne
• Vers Autotask
• ConnectSecure
• Commande ConnectWise
• ConnectWise Manage
• Duo
• FreshService
• ITGlue
• Microsoft Defender
• Qualys
• Rapid7
• ServiceNow
• Splashtop
• Tenable
• RepairShopr
• WinGet
• Xero (facturation)
• Zendesk

Description

Lorsque vous vous connectez à NinjaOne via nos applications d’intégration à une plateforme tierce, votre travail se synchronise entre deux produits distincts, deux bases de code distinctes et deux services d’assistance distincts. Cette interaction fournit des outils spécialement conçus pour chaque tâche, mais cela signifie également qu’en cas de problème, vous devez déterminer d’où provient celui-ci avant de pouvoir le résoudre.

Indexer

Sélectionnez une catégorie pour en savoir plus :

• Principe fondamental
• Matrice des responsabilités
  • Responsabilité en matière de documentation
• Comment NinjaOne vous aide
• Limites de l'assistance NinjaOne
  • Configuration des plates-formes tierces
  • Workflows personnalisés, automatisations et règles métier
  • Comportement des API des plate-formes tierces et limites de débit
  • Configurations non standard, mappages de champs et personnalisations d’environnement
  • Licences et autorisations d’accès aux plates-formes tierces
  • Pannes et performances des plate-formes tierces
• Coordination et transferts entre les services d’assistance
• Comment identifier l’origine d’un problème
• Pages de statut pour les intégrations prises en charge
• Quand faire appel à l’assistance NinjaOne plutôt qu’à l’assistance tierce
• Ressources complémentaires

Principe fondamental

Considérez une intégration NinjaOne comme un pont entre deux plateformes. NinjaOne est propriétaire et responsable de notre côté du pont, de sa construction, de son entretien et du trafic que nous y faisons transiter. Les plates-formes tierces sont propriétaires de leur côté du pont. En tant que partenaire, c’est vous qui décidez quelles données traversent le pont et comment configurer le trafic à chaque extrémité.

En cas de dysfonctionnement, il est important de déterminer de quel côté du pont le problème s’est produit, car nous ne disposons des outils, de l’accès et du contexte nécessaires que pour résoudre les problèmes survenant de notre côté.

Notre engagement

Notre objectif est de ne jamais vous laisser sans chemin d’accès. Même lorsqu’un problème ne relève pas de notre périmètre, notre rôle est de vous aider à comprendre d’où il provient et comment le résoudre. Lorsque vous faites appel à l’assistance NinjaOne pour un problème d’intégration, nous allons :

• Enquêterons sur le problème pour confirmer s’il est causé par NinjaOne ou vous redirigerons vers le Tiers concerné.
• Vous expliquer clairement pourquoi un problème est en dehors de notre périmètre.
• Nous vous aiderons à formuler la bonne question et un récapitulatif à transmettre au fournisseur tiers, afin que le transfert soit productif.
• Vous fournir l’assistance si vous vous retrouvez pris entre deux fournisseurs. Nous vous aiderons à identifier le chemin d’accès approprié et veillerons à ce que toutes les étapes soient respectées.
• Prendre en charge tous les bugs d’intégration découverts et communiquer les délais de résolution.
• Veiller à ce que cet article reste précis et à jour à mesure que nos intégrations évoluent.

Commentaires sur cet article

Si vous rencontrez un cas de figure que nous n’avons pas abordé dans cet article, ou si vous estimez qu’une limite n’est pas claire ou est inexacte, nous vous encourageons à nous en faire part par l’intermédiaire de votre interlocuteur de l’assistance NinjaOne. Cet article est une ressource évolutive qui s’enrichit grâce aux retours d’expérience concrets.

Matrice des responsabilités

Le tableau suivant définit la propriété au sein des principales couches de chaque intégration développée par NinjaOne.

Responsabilité en matière de documentation

NinjaOne mettra à votre disposition de la documentation dans notre Dojo pour vous aider à configurer une intégration connectée via NinjaOne. Certaines de ces intégrations impliquent des workflows qui nécessitent que vous effectuiez des actions sur la plateforme tierce ; dans ces situations, NinjaOne fournira également de la documentation pour vous aider à réaliser ces étapes.

NinjaOne ne fournira pas de documentation concernant les plates-formes tierces si cela n’affecte pas directement l’intégration dans NinjaOne, mais nous pourrons fournir des liens externes vers certaines ressources le cas échéant. Vous devez vous reporter à la documentation propriétaire du tiers pour obtenir de l’aide sur l’utilisation de son produit.

Comment NinjaOne vous aide

Lorsque vous ouvrez un dossier d’assistance concernant une intégration, NinjaOne prendra les actions suivantes en fonction du problème :

• Vérifier que le connecteur d’intégration fonctionne comme prévu. Nous pouvons confirmer que notre partie de l’intégration est opérationnelle, que le connecteur transmet bien les données et que la version de l’intégration que vous utilisez est à jour et prise en charge.
• Valider votre configuration par rapport à la configuration prête à l’emploi (OOTB). En nous basant sur notre documentation, nous passerons en revue avec vous les étapes de configuration standard afin de confirmer que la configuration côté NinjaOne correspond à notre configuration OOTB recommandée. Si nécessaire, nous mettrons à jour notre documentation pour apporter des précisions ou indiquer des étapes de dépannage.
• Nous tenterons de reproduire le problème dans un environnement de test, si celui-ci est disponible. Si un comportement semble être un bug au sein de la couche d’intégration de NinjaOne, nous tenterons de le reproduire à l’aide des paramètres OOTB et, s’il est confirmé, nous transmettrons le problème à notre équipe d’ingénierie. Veuillez noter que ce processus prendra du temps : les environnements de laboratoire ne reflètent pas toujours les configurations réelles, les données de diagnostic issues du rapport initial peuvent être incomplètes et la disponibilité des ingénieurs varie. Nous vous tiendrons informé de l’avancement et des délais tout au long du processus.
• Identifier et documenter les bogues d’intégration. Si nous identifions un défaut de notre côté de l’intégration, nous en assumons la responsabilité ; nous l’enregistrerons, communiquerons les délais prévus pour les corrections et proposerons des solutions de contournement lorsque cela est possible, jusqu’à ce que le problème soit entièrement résolu.
• Aide à la configuration de l’authentification et de la connectivité. Nous vous guiderons dans la génération des identifiants API, la configuration de la connexion dans NinjaOne et le test de la connectivité basique.
• Fournir une documentation spécifique à l’intégration et des guides de configuration. Notre Dojo contient des instructions de configuration étape par étape pour chaque intégration prise en charge, y compris des conseils sur le mappage des champs pour les configurations prêtes à l’emploi.

Limites de l’assistance NinjaOne

Les sections suivantes décrivent les domaines en dehors des compétences de l’assistance NinjaOne en matière de diagnostic, de modification ou de résolution. Dans chaque cas, la contrainte réside dans l’accès : nous ne pouvons pas consulter les outils, les données ou les systèmes nécessaires à l’analyse, car ils appartiennent à un tiers.

Configuration des plates-formes tierces

Nous ne pouvons pas accéder aux informations de votre compte sur la plateforme d’un fournisseur ; nous ne pouvons donc pas consulter les workflows, autorisations, configurations de champs ou règles personnalisées qui y sont configurés. Lorsque le comportement semble correct dans NinjaOne mais ne fonctionne pas comme prévu sur la plateforme tierce, cela signifie qu’il faut faire appel à l’équipe d’assistance de ce tiers.

Workflows personnalisés, automatisations et règles métier

De nombreux partenaires étendent leurs plateformes ITSM ou PSA à l’aide d’automatisations, de déclencheurs, de règles métier ou de scripts personnalisés. Ceux-ci échappent totalement à la visibilité et au contrôle de NinjaOne. Lorsqu’un workflow personnalisé interagit de manière inattendue avec les données envoyées par NinjaOne, le débogage de ce workflow nécessite un accès à la plateforme tierce, dont seuls vous ou l’équipe d’assistance de cette plateforme disposez.

Comportement des API des plate-formes tierces et limites de débit

Chaque plateforme tierce applique ses propres politiques d’API, notamment des limites de débit, des exigences d’authentification, des contraintes de charge utile et des calendriers de dépréciation. Lorsqu’une plateforme modifie le comportement de son API, ou lorsque votre compte atteint une limite de débit imposée par le fournisseur tiers, NinjaOne ne peut pas contourner ces contraintes. Nous adapterons notre intégration lorsque les plateformes apporteront des modifications majeures à leurs API, mais nous ne pouvons pas contrôler le calendrier ni le comportement lui-même.

Configurations non prêtes à l’emploi, mappages de champs et personnalisations de l’Environnement

NinjaOne fournit ses intégrations avec un ensemble de mappages de champs et de paramètres par défaut conçus pour fonctionner « prêts à l’emploi ». Nous prenons en charge et documentons ces configurations par défaut, et nous validons le comportement attendu auprès de l’ensemble de nos partenaires. Lorsque vous personnalisez les mappages, ajoutez des transformations de champs ou acheminez les données d’une manière qui s’écarte des valeurs par défaut documentées, la maintenance et le dépannage de ces personnalisations relèvent de votre responsabilité.

Cette personnalisation va au-delà des modifications évidentes telles que les mappages de champs. Les modifications apportées aux listes de contrôle d’accès (ACL), aux autorisations basées sur les rôles, aux périmètres d’accès des utilisateurs de l’API ou aux politiques de sécurité au niveau de la plateforme dans l’environnement tiers peuvent empêcher, de manière silencieuse, le bon fonctionnement des comportements d’intégration « prêts à l’emploi », même lorsque tout est correct du côté de NinjaOne. Ces modifications nous sont souvent invisibles et ne sont parfois visibles que par l’administrateur ou l’équipe qui les a créées.

Cette limite existe car notre validation s’effectue uniquement dans des environnements « out-of-the-box ». Lorsque les valeurs par défaut fonctionnent dans des milliers de déploiements chez nos partenaires, un problème isolé à un environnement particulier est imputable à cet environnement, et non à l’intégration. Les modifications apportées aux ACL, aux autorisations ou aux politiques de sécurité de la plateforme peuvent perturber silencieusement le comportement attendu, même si vous pensez que votre configuration n’a pas changé. Le diagnostic de ces modifications incombe à l’administrateur de votre plateforme ou à l’équipe d’assistance tierce.

Licences et autorisations d’accès aux plate-formes tierces

Si votre intégration cesse de fonctionner en raison d’un identifiant API révoqué, d’un compte utilisateur désactivé, d’un accès d’abonnement insuffisant ou d’une modification des autorisations effectuée sur la plateforme tierce, il s’agit de modifications au niveau du compte qui relèvent de votre gestion ou du support du fournisseur tiers.

Pannes et performances des plate-formes tierces

Si vous rencontrez une interruption de service ou une baisse de performances sur la plate-forme tierce, NinjaOne ne peut pas remédier à la situation. Nous vous recommandons d’ajouter aux favoris les pages d’état de vos plate-formes intégrées, indiquées dans la section de cet article intitulée « Pages d’état pour les intégrations prises en charge », afin de pouvoir rapidement écarter cette cause lors du dépannage.

Assistance et transferts entre les services d’assistance

Le support NinjaOne opère au sein de l’environnement NinjaOne, et notre accès au support est strictement limité à cet environnement. Le tableau suivant décrit ce que nous pouvons ou ne pouvons pas faire en votre nom lorsque vous rencontrez des problèmes en dehors de l’environnement NinjaOne.

Comment identifier l’origine d’un problème

Avant d’ouvrir un dossier d’assistance, que ce soit avec NinjaOne ou avec un fournisseur, suivez les étapes suivantes pour déterminer à qui incombe la responsabilité du problème, afin de pouvoir contacter rapidement l’équipe compétente.

1. Vérifiez l’état de la plateforme: rendez-vous sur la page d’état de votre plateforme intégrée. Si un incident est en cours, il devrait y figurer.
2. Vérifiez la version de l’intégration sur la plateforme tierce: NinjaOne installe généralement une intégration sous la forme d’une application client au sein de la plateforme tierce. Accédez aux paramètres de l’application ou du connecteur sur cette plateforme pour confirmer les paramètres et vérifier que vous utilisez bien la version actuelle. Les intégrations obsolètes peuvent entraîner des comportements inattendus, et c’est l’un des premiers éléments que notre équipe d’assistance voudra vérifier.
3. Testez le problème avec les valeurs par défaut: si vous avez mis en place des personnalisations (mappages de champs personnalisés, workflows modifiés ou autres), désactivez-les temporairement et effectuez un test en utilisant les valeurs par défaut. Si le problème disparaît, la personnalisation en est probablement la cause.
4. Vérifiez les journaux d’activité d’intégration de NinjaOne: NinjaOne fournit des journaux d’activité et d’erreurs pour chaque intégration. Si les journaux indiquent que les données sortantes provenant de NinjaOne ont bien été transmises, le problème se situe probablement du côté du destinataire. Ces informations constitueront la base de votre résumé de diagnostic si vous devez faire appel à un tiers.
5. Vérifiez les journaux d’audit ou d’activité de la plateforme tierce: la plupart des plateformes tiennent à jour un journal d’activité ou d’audit de l’API. Si NinjaOne indique que l’envoi des données s’est déroulé avec succès, mais que la plateforme tierce ne fait état d’aucune réception ou signale des erreurs à la réception, cela constitue un indice fort permettant de cibler la source du problème.

Pages de statut pour les intégrations prises en charge

Utilisez le tableau suivant comme guide pour accéder aux pages de statut des différents fournisseurs.

Quand faire appel à l'assistance NinjaOne ou à l'assistance des tiers ?

Utilisez le tableau suivant comme guide pour déterminer quand contacter l'assistance NinjaOne ou un prestataire tiers.

Ressources complémentaires

Consultez la section « Intégrations / Applications tierces : catalogue de ressources » pour en savoir plus sur nos intégrations.