Cette page s'adresse à l'intégrateur qui met en service MyZapp chez un client. Elle enchaîne les étapes d'un projet, du cadrage à la bascule en production, et renvoie pour chacune vers la page qui la détaille.
Cadrer
- Trois instances : une de développement, où se construit le paramétrage, une de recette, où le client le valide, et la production. Le paramétrage passe de l'une à la suivante par un GOLIVE, toujours tiré par l'instance qui reçoit : la recette lit le développement, la production lit la recette (voir « Préparer l'instance source d'un GOLIVE »).
- Licences : chaque instance a sa propre identité et ses propres licences. Un module sans licence sur une instance n'y reçoit rien (voir « Gérer les licences de l'instance »).
- Suivi du projet : le module Projets peut porter le projet lui-même, avec ses tâches, ses jalons et son équipe (voir « Piloter un projet » et « Suivre un projet »).
Ce qui passe par le GOLIVE, et ce qui n'y passe pas
Avant de planifier, rangez chaque besoin dans l'une de ces quatre familles :
- le paramétrage (processus, formulaires, catalogue, référentiel des tickets, modèles, menus, bases de connaissances, types d'objet de la CMDB, règles du CRM…) : il se construit en développement et se promeut par GOLIVE, sur sélection ;
- ce qui est propre à chaque instance (adresses, connexions, secrets, licences, agents) : il ne voyage jamais, et se règle sur chaque instance ;
- les données métier (tickets, demandes, comptes et opportunités du CRM, actifs…) : elles ne passent pas par le GOLIVE, mais par la reprise de données ;
- les traces d'exécution (journaux, historiques) : elles restent où elles ont été produites.
Les comptes, les groupes et leurs membres, et les droits ne voyagent pas non plus : un élément promu désigne seulement le groupe ou le compte qu'il attend, et la cible le retrouve chez elle.
Construire en développement
- Créez les groupes et réglez les droits sur chaque instance, sous les mêmes codes : ils ne sont pas promus. Les menus, eux, le sont.
- Construisez le paramétrage : service desk, catalogue, formulaires, processus, contenus.
- Chargez au besoin les données de démonstration pour essayer le paramétrage sur des cas réalistes (voir « Charger les données de démonstration »). Ne les chargez pas en production.
Préparer la reprise de données
Les données de l'ancien outil se reprennent par les imports des modules, par exemple :
- les tickets : import d'un fichier JSON, chaque ticket devenant un nouveau ticket (voir « Importer et exporter des tickets ») ;
- les comptes et contacts du CRM : import CSV ou Excel avec détection des doublons (voir « Doublons, fusion, import et export »).
Les comptes des utilisateurs doivent exister avant les données qui les citent : un ticket dont le demandeur est introuvable est ignoré. Créez-les d'abord, à la main ou par la synchronisation d'un annuaire (Active Directory, Microsoft 365 ou Google Workspace).
Répétez la reprise en recette, sur des données réelles, jusqu'à obtenir un compte rendu sans rejet.
Recetter
- Sur la recette, déclarez le développement comme source (voir « Déclarer la source d'un GOLIVE »).
- Choisissez les éléments, prévisualisez, réglez les écarts bloquants, puis appliquez (voir « Choisir et prévisualiser un GOLIVE » et « Appliquer un GOLIVE et consulter l'historique »).
- Réactivez, après vérification, les déclencheurs de la liste À réactiver : ils arrivent désactivés.
- Faites valider le paramétrage et la reprise de données par le client. Une correction se fait en développement, puis repasse par un nouveau GOLIVE : ne corrigez pas directement en recette ce qui doit partir en production.
Un GOLIVE réussi se défait depuis son historique, en entier ou en partie, si la recette révèle un problème.
Basculer en production
- Sur la production, déclarez la recette comme source, puis appliquez le GOLIVE validé.
- Réglez ce qui est propre à la production : connexions, boîtes mail, secrets, licences.
- Importez la documentation livrée avec la version (voir « Mettre à jour la documentation »).
- Faites la reprise de données définitive, puis réactivez les déclencheurs de la liste À réactiver.
- Contrôlez l'instance (voir « Surveiller l'instance ») et conservez l'historique des GOLIVE comme trace de la bascule.
Après la mise en service
Les évolutions suivent le même chemin : développement, GOLIVE vers la recette, validation, GOLIVE vers la production. L'option Modifié depuis le de la page GOLIVE ne montre que ce qui a changé dans la source depuis une date.
Pour former les utilisateurs du client, l'Académie propose des parcours (voir « Concevoir un parcours de l'Académie »).