Vigicap
Connecteur
HaloPSA
Un seul identifiant au niveau de l'agence, pour tout le portefeuille.
Votre PSA connaît déjà la liste de vos clients : ce connecteur l'importe, puis rapporte pour chacun l'inventaire des actifs, leur identification et leur responsable technique. Il ne propose aucun niveau ReCyF. HaloPSA n'enregistre aucune mesure de sécurité sur les actifs.
01
Ce qu'il faut créer dans l'outil
L'accès se crée dans HaloPSA, pas dans Vigicap. Vigicap ne demande jamais le mot de passe d'un administrateur : il attend un identifiant d'API que vous créez, que vous voyez, et que vous pouvez révoquer sans nous.
Où le générer
HaloPSA > Configuration > Integrations > Halo API : créez une application « Client Credentials », puis, sur son onglet « Permissions », cochez uniquement « read:customers » et « read:assets ». Si la même application sert aussi à la remontée de tickets, ajoutez-y « read:tickets » et « edit:tickets ».
Rôle minimal
Application API « Client Credentials » portant exactement deux permissions, toutes deux en lecture : « read:customers » (GET /Client, la liste des clients) et « read:assets » (GET /Asset, l'inventaire). Aucune permission d'écriture, et pas le scope « all ».
Formulation reprise du modèle de rôles de l'éditeur, et vérifiée avant publication.
02
Ce qu'il faut saisir dans Vigicap
Les champs exacts du formulaire de connexion, dans l'ordre où ils apparaissent. Les valeurs marquées « secret » ne ressortent jamais vers le navigateur : elles sont chiffrées au repos et supprimées à la déconnexion.
Le formulaire commence par l'adresse de l'instance, saisie à part des champs ci-dessous. Le catalogue public ne publie pas encore si ce connecteur en demande une, ni à quoi elle ressemble — cette liste est donc exacte pour tout le reste, et muette sur ce premier champ.
- Client ID
- Client Secretsecret
- URL du serveur d'authentificationfacultatifURL
Uniquement si votre installation sépare l'authentification de l'API. Sinon, laissez vide.
03
Le routage par client
L'identifiant, lui, ne se répète pas : un seul, saisi une fois au niveau de l'agence, couvre tout le portefeuille — c'est la différence que l'on sent avec quarante clients plutôt qu'avec quatre.
Ces champs-ci se renseignent client par client : ils disent sous quel compte du PSA le ticket doit atterrir. Une valeur erronée ne fait pas échouer l'envoi — elle le fait réussir chez quelqu'un d'autre, ce pour quoi Vigicap les vérifie au moment où vous les saisissez.
- ID client Halo
Identifiant du client dans HaloPSA sous lequel créer les tickets.
ex. 42
- ID type de ticketfacultatif
Optionnel — type de ticket Halo (par défaut : type par défaut de l'instance).
ex. 1
04
Ce qu'il fait, et ce qu'il ne fait pas
Objectifs ReCyF pré-remplis
Ce connecteur n'alimente aucun objectif ReCyF, et ce n'est pas une lacune : il ne mesure pas la posture d'un client.
Lecture seule
Les lectures sont en lecture seule : Vigicap n'écrit rien dans l'outil en lisant.
Ce qui part vers l'outil
Ce connecteur ÉCRIT : il crée un ticket à partir d'une action du plan.
Ce qui en revient
L'état d'un ticket déjà créé revient : son statut, sa date de clôture, sa dernière activité. Un ticket clos devient une PROPOSITION qu'un consultant valide — jamais une action clôturée d'office. Une agence qui clôt son propre ticket ne doit pas pouvoir se noter elle-même dans le document que lit un auditeur.
Ce qui est lu, ce qui est conservé, combien de temps et avec quels droits : le même registre, connecteur par connecteur, dans l'inventaire des données.
Portées demandées
Les portées exactes demandées à l'autorisation, telles que l'éditeur les nomme.
- read:customers
- read:assets
- read:tickets
- edit:tickets
Vérification
Ce connecteur a été exécuté de bout en bout contre une instance réelle de l'outil, pas seulement testé contre une simulation.
Les marques et logos cités appartiennent à leurs titulaires respectifs et identifient les outils avec lesquels Vigicap est compatible — voir les mentions légales.