L'administrateur souhaite fusionner les deux Update Sets avant de les déployer en production. Quelles sont les règles à respecter pour effectuer cette fusion, et que se passe-t-il si un même objet a été modifié dans les deux Update Sets ?

La fusion de plusieurs Update Sets est une fonctionnalité native de ServiceNow, accessible via la fonctionnalité 'Merge Update Sets'. Pour être fusionnables, les Update Sets doivent être dans un état approprié (ils ne doivent pas encore être en état 'Complete' sur l'instance cible, ou la fusion est réalisée sur l'instance source avant export). La fusion crée un nouvel Update Set consolidé regroupant les modifications des deux Update Sets d'origine. Concernant les conflits : si un même objet de configuration a été modifié dans les deux Update Sets (par exemple, une même Business Rule retouchée dans les deux branches), ServiceNow conserve uniquement la version la plus récente de cette modification dans l'Update Set fusionné. Ce comportement garantit que la dernière évolution de la configuration prévaut, évitant les doublons. Il est donc essentiel que l'équipe vérifie au préalable quels objets sont présents dans les deux Update Sets pour s'assurer que la version la plus récente est bien celle souhaitée en production. Dans ce cas précis, les deux Update Sets totalisent 85 enregistrements (47 + 38), ce qui reste sous le seuil recommandé par ServiceNow de 100 enregistrements par Update Set, limitant ainsi les risques de conflits.

Quelles sont les trois étapes obligatoires pour appliquer l'Update Set fusionné sur l'instance de production, et quel doit être l'état de l'Update Set avant son transfert ?

Avant tout transfert, l'Update Set doit obligatoirement se trouver dans l'état 'Complete'. L'état 'In progress' signifie qu'il est encore actif et en cours de modification, ce qui empêche son export. Une fois l'Update Set passé en état 'Complete' et exporté au format XML (format standard d'export ServiceNow), les trois étapes obligatoires pour l'appliquer sur l'instance de production sont : 1) Récupérer (Retrieve) l'Update Set — soit en important le fichier XML via 'All > System Update Sets > Retrieved Update Sets', soit en configurant une source distante via 'All > System Update Sets > Update Sources' pour le récupérer directement depuis l'instance source. 2) Prévisualiser (Preview) — cette étape permet de détecter les conflits potentiels entre les modifications de l'Update Set et la configuration existante en production. Il est fortement conseillé de traiter tous les conflits avant de passer à l'étape suivante. 3) Valider (Commit) — cette dernière étape applique effectivement les personnalisations sur l'instance de production. Les modifications sont alors écrites dans la table sys_update_xml, et les configurations deviennent actives. Il est important de noter qu'il est déconseillé de déplacer l'Update Set par défaut (Default Update Set) entre les instances, car il peut contenir des personnalisations non intentionnelles.

Plusieurs membres de l'équipe ont créé 120 nouveaux utilisateurs, groupes et CI directement en production. Ces éléments sont-ils couverts par les Update Sets ? Comment l'administrateur doit-il gérer ces données ?

Non, ces 120 enregistrements ne sont pas couverts par les Update Sets et n'ont pas besoin de l'être. Les Update Sets capturent uniquement les personnalisations de configuration (métadonnées) telles que les Business Rules, Access Control Rules, UI Policies, formulaires, scripts, etc. En revanche, les utilisateurs, les groupes et les Configuration Items (CI) sont des enregistrements de données métier (data records), et non des artefacts de configuration. Ils ne sont donc jamais capturés par un Update Set, quelle que soit la configuration de celui-ci. Ces éléments ont été créés directement en production, ce qui est une pratique acceptable pour les données métier, contrairement aux personnalisations de configuration qui doivent impérativement passer par le cycle développement > test > production via les Update Sets. Pour gérer d'éventuels besoins d'import massif de données similaires sur d'autres instances, l'administrateur devrait utiliser la fonctionnalité 'System Import Sets' (accessible via 'All > System Import Sets > Load Data'), qui est l'outil dédié à l'importation de données dans ServiceNow. L'administrateur doit donc informer l'équipe projet que ces 120 enregistrements sont correctement gérés indépendamment du processus de déploiement par Update Sets.

Pour le besoin de déclenchement automatique de la priorité d'un incident lors de sa création ou modification, quel mécanisme technique ServiceNow faut-il utiliser et pourquoi ? Précisez le moment d'exécution recommandé.

Le mécanisme approprié est le Business Rule. Un Business Rule est un script JavaScript côté serveur qui s'exécute lors d'opérations de base de données (insert, update, delete, display, query) sur une table spécifique. Dans ce cas, il faut configurer un Business Rule sur la table 'Incident' [incident], déclenché sur les opérations 'insert' et 'update'. Le Business Rule a accès aux objets 'current' (enregistrement en cours de modification) et 'previous' (état précédent), ce qui lui permet de lire le champ 'Service impacté' et de calculer puis écrire automatiquement la priorité correspondante. Concernant le moment d'exécution : il est recommandé d'utiliser un Business Rule de type 'before' (avant l'écriture en base de données) pour modifier la valeur du champ 'Priorité' avant que l'enregistrement ne soit sauvegardé, garantissant ainsi que la valeur correcte est persistée dès la création. Un Business Rule de type 'async' pourrait être envisagé pour des traitements moins urgents afin de ne pas bloquer l'expérience utilisateur, mais pour une mise à jour de priorité, le mode 'before' est préférable. Contrairement aux Client Scripts qui s'exécutent uniquement dans le navigateur, le Business Rule s'exécute côté serveur et s'applique quelle que soit la méthode de création de l'incident (formulaire, import, API).

Pour la règle de validation du champ 'Service impacté' (obligatoire avant toute soumission), faut-il utiliser une UI Policy ou une Data Policy ? Justifiez en tenant compte des exigences de sécurité du CHU (3 canaux d'entrée de données).

Compte tenu des exigences strictes du CHU, il faut utiliser une Data Policy plutôt qu'une UI Policy. La distinction fondamentale est la suivante : une UI Policy s'exécute uniquement côté client (dans le navigateur de l'utilisateur) et n'agit que sur l'interface utilisateur — elle ne s'applique donc pas aux données entrantes via des Import Sets ou des Web Services/API. En revanche, une Data Policy s'exécute à la fois côté client et côté serveur, ce qui garantit que la règle de validation (ici, rendre le champ 'Service impacté' obligatoire) est appliquée quelle que soit la méthode d'entrée des données : formulaire web, import batch via System Import Sets, ou appels API depuis le système de gestion hospitalière. Avec 3 canaux d'entrée de données identifiés, seule la Data Policy couvre l'intégralité des cas. Une UI Policy seule serait insuffisante et laisserait passer des enregistrements incomplets créés par import ou API. Il est toutefois possible de combiner les deux approches : une Data Policy pour la contrainte serveur universelle, et une UI Policy complémentaire pour un retour visuel immédiat à l'utilisateur dans le formulaire. Pour le masquage dynamique des 8 champs sensibles selon le profil utilisateur, une UI Policy reste appropriée car ce besoin est purement lié à l'affichage dans l'interface.

Le consultant propose d'utiliser du scripting JavaScript pour tous les besoins. L'administrateur senior recommande de privilégier la configuration native. Quelle position est alignée avec les recommandations officielles ServiceNow, et quels sont les risques concrets du scripting excessif dans ce contexte hospitalier ?

La position de l'administrateur senior est alignée avec les recommandations officielles de ServiceNow. La plateforme recommande explicitement de privilégier la configuration (sans scripting) car les configurations natives sont plus stables et plus faciles à maintenir lors des mises à niveau de la plateforme. Les scripts personnalisés JavaScript peuvent être impactés par les évolutions de l'API ou du moteur d'exécution JavaScript de ServiceNow (qui s'appuie sur le moteur Rhino côté serveur), rendant leur débogage plus complexe et pouvant provoquer des régressions lors des upgrades annuels du CHU. Les risques concrets du scripting excessif dans ce contexte sont multiples : 1) Risque de maintenance élevé — chaque mise à niveau ServiceNow peut nécessiter une revue et une adaptation des scripts personnalisés, représentant un coût humain significatif pour l'équipe IT. 2) Risque de performance — des scripts mal optimisés génèrent des allers-retours (round trips) client-serveur supplémentaires, dégradant l'expérience utilisateur pour les 45 techniciens. 3) Risque de stabilité — un script côté serveur défaillant (Business Rule) peut bloquer l'enregistrement des incidents, ce qui est critique dans un environnement hospitalier. La bonne approche est donc d'utiliser en priorité les mécanismes de configuration natifs (UI Policies, Data Policies, conditions de formulaire) et de ne recourir au scripting JavaScript (Business Rules, Client Scripts) que lorsque la configuration native ne suffit pas à couvrir le besoin métier, comme c'est le cas pour le calcul automatique de priorité.

Comment l'administrateur doit-il gérer les 10 350 collaborateurs d'atelier en libre-service dans ServiceNow ? Quel est leur profil d'accès par défaut et comment empêcher techniquement la création ou modification de pages d'accueil ?

Les 10 350 collaborateurs d'atelier sans rôle IT assigné correspondent au profil 'Utilisateurs Self-Service' dans ServiceNow. Ce sont des utilisateurs sans aucun rôle assigné (parfois désignés par le rôle implicite 'public'), qui disposent d'un accès très limité à la plateforme, principalement orienté vers le portail de service (Service Portal) pour soumettre des demandes via le Service Catalog. Ils ne peuvent pas accéder aux modules ITSM avancés ni aux fonctions d'administration. Pour empêcher techniquement la création ou la modification de pages d'accueil (Homepages) par cette population, l'administrateur doit configurer la propriété système 'com.glideapp.home.deprecate_homepages' en la définissant sur 'true'. Cette System Property est accessible via 'All > System Properties' et, lorsqu'elle est activée, empêche tous les utilisateurs non-administrateurs de créer ou modifier des Homepages. Cette approche est préférable à une gestion individuelle des permissions car elle s'applique de manière globale. Pour les managers (1 200 utilisateurs), l'administrateur devra configurer des rôles spécifiques limitant leur accès aux modules du Service Catalog et de suivi de leurs demandes, en utilisant les groupes ServiceNow pour regrouper les utilisateurs partageant le même objectif fonctionnel et simplifier l'attribution des rôles.

La politique de gouvernance impose que les rôles élevés (admin) ne soient utilisés qu'en cas de nécessité. Quel mécanisme ServiceNow permet de répondre à cette exigence, et comment un administrateur peut-il temporairement tester le comportement de l'interface tel qu'il est perçu par un technicien ou un manager spécifique ?

Pour répondre à l'exigence de limitation d'utilisation des rôles élevés, ServiceNow propose la fonctionnalité 'Élever les rôles' (Elevate Roles), accessible depuis le menu utilisateur (en cliquant sur l'avatar ou le nom de l'utilisateur connecté en haut à droite de l'interface). Cette fonctionnalité permet d'obtenir des privilèges élevés de manière temporaire et contrôlée, uniquement lorsque c'est nécessaire, ce qui est conforme aux bonnes pratiques de sécurité. La session élevée est tracée dans l'audit log de la plateforme. Pour tester le comportement de l'interface tel que perçu par un utilisateur spécifique (par exemple, un technicien terrain ou un manager), l'administrateur dispose de la fonctionnalité 'Impersonate User', également accessible via le menu utilisateur. Cette fonctionnalité, réservée aux administrateurs, permet de se connecter en tant qu'un autre utilisateur et de voir exactement ce que cet utilisateur voit, sans connaître son mot de passe. C'est un outil indispensable pour valider les configurations d'accès, les UI Policies et les personnalisations de formulaire pour chaque profil. Pour accéder à cette option dans le menu utilisateur, l'administrateur clique sur son avatar en haut à droite, où sont disponibles : 'Élever les rôles', 'Impersonate User' et 'Déconnexion'.

Pour les 6 applets mobiles Now Mobile à personnaliser pour les techniciens terrain, quel outil ServiceNow doit utiliser l'administrateur ? Par ailleurs, comment la plateforme facilite-t-elle la collaboration en temps réel entre techniciens travaillant simultanément sur un même incident ?

Pour créer, gérer et modifier les 6 applets mobiles destinées aux techniciens terrain, l'administrateur doit utiliser Mobile Studio. C'est l'outil intégré à ServiceNow permettant de configurer les écrans, les actions et les données affichées dans Now Mobile sans nécessiter de développement natif. Mobile Studio offre une interface visuelle pour personnaliser les applets selon les processus métier spécifiques de l'industrie. Il est important de noter que Now Mobile est disponible sur les deux systèmes d'exploitation mobiles identifiés dans le déploiement : Apple iOS et Google Android, couvrant ainsi l'ensemble des techniciens terrain. En revanche, Now Support (l'autre application mobile ServiceNow) est dédiée à l'interaction avec le support client ServiceNow et n'est pas personnalisable — elle ne doit pas être confondue avec Now Mobile. Concernant la collaboration en temps réel entre techniciens sur un même incident : ServiceNow propose deux fonctionnalités complémentaires. La fonctionnalité 'User Presence' permet de voir en temps réel si d'autres utilisateurs consultent ou travaillent sur le même enregistrement, grâce à des indicateurs visuels (avatars colorés) directement sur le formulaire de l'incident, évitant les conflits de modification simultanée. La fonctionnalité 'Connect Chat' (messagerie instantanée intégrée) permet aux techniciens de communiquer en temps réel directement depuis la plateforme, en liant les échanges au contexte de l'enregistrement incident pour une collaboration contextuelle efficace.

Quelles règles de gouvernance l'équipe technique doit-elle mettre en place pour les Update Sets afin de respecter les bonnes pratiques ServiceNow, notamment concernant l'Update Set par défaut et la taille des Update Sets ?

L'équipe technique doit établir les règles de gouvernance suivantes, toutes fondées sur les bonnes pratiques officielles ServiceNow : 1) Interdire le travail dans l'Update Set par défaut (Default Update Set) — il est fortement déconseillé de déplacer l'Update Set par défaut entre les instances, car il peut contenir des personnalisations non intentionnelles ou non testées qui risquent de déstabiliser l'environnement cible. Chaque administrateur doit créer un Update Set dédié et explicitement nommé avant de commencer toute modification, en naviguant via 'All > System Update Sets > Local Update Sets' pour en créer un nouveau et le définir comme 'Current' (actif). 2) Limiter la taille des Update Sets — ServiceNow recommande de limiter chaque Update Set à un maximum de 100 enregistrements afin de minimiser les risques de conflits lors de la migration et de simplifier la revue des modifications. Des Update Sets trop volumineux rendent difficile l'identification des changements individuels et augmentent les risques en cas de rollback nécessaire. 3) Nommer les Update Sets de façon explicite et cohérente selon une convention de nommage établie (ex : [PROJET]-[FONCTIONNALITÉ]-[DATE]). 4) Utiliser la possibilité de fusion (Merge Update Sets) pour regrouper des modifications liées développées en parallèle par les 4 administrateurs, avant de promouvoir vers la recette ou la production. Les modifications individuelles capturées sont stockées dans la table sys_update_xml, et les métadonnées de l'Update Set dans la table sys_update_set. 5) Rappeler que les Update Sets conservent un historique de versions, permettant si nécessaire de revenir à un état antérieur d'une personnalisation.

Dans le cadre du projet Service Catalog, quels artefacts créés par l'équipe seront capturés par les Update Sets et lesquels ne le seront pas ? Donnez des exemples concrets liés au contexte de la société de gestion d'actifs.

Les Update Sets capturent uniquement les personnalisations de configuration (métadonnées de la plateforme), pas les enregistrements de données métier. Dans le contexte de ce projet Service Catalog : CAPTURÉ dans les Update Sets — les Catalog Items eux-mêmes (leur définition, leur structure), les variables associées aux Catalog Items (champs à choix multiple, texte sur une seule ligne, listes déroulantes qui sont des types de variables du Service Catalog), les Business Rules créées pour automatiser la logique de traitement, les UI Policies et Client Scripts configurés sur les formulaires de demande, les workflows d'approbation créés via Flow Designer ou le Workflow Editor, les Access Control Rules définissant qui peut voir quels Catalog Items, les Script Includes éventuellement développés. NON CAPTURÉ dans les Update Sets — les utilisateurs créés pour les tests de recette (les utilisateurs sont des data records), les groupes d'approbateurs créés (les groupes sont des enregistrements de données), les demandes de test soumises dans l'environnement de recette (enregistrements de données), les Configuration Items (CI) référencés dans les demandes, les pages d'accueil (Homepages) et tableaux de bord (Dashboards) créés pour le suivi. Pour transporter des données de configuration comme les groupes entre instances, l'équipe devra utiliser des Import Sets (via 'All > System Import Sets > Load Data') ou les recréer manuellement. L'équipe doit donc bien distinguer ce qui relève de la 'configuration' (transportable via Update Sets) de ce qui relève des 'données' (à gérer séparément).

Un administrateur a exporté un Update Set contenant 35 personnalisations de Catalog Items et tente de l'importer en recette. Décrivez précisément le processus technique d'importation et d'application de cet Update Set sur l'instance de recette, en précisant le chemin de navigation et les étapes à respecter.

Le processus technique complet pour importer et appliquer l'Update Set sur l'instance de recette se déroule en trois phases obligatoires : PHASE 1 — Importation du fichier XML : L'administrateur se connecte à l'instance de recette et navigue via 'All > System Update Sets > Retrieved Update Sets'. C'est dans cette section que l'on charge le fichier XML exporté depuis l'instance de développement. L'Update Set exporté est toujours au format XML, ce format structuré permettant d'encapsuler toutes les personnalisations (Catalog Items, variables, Business Rules, etc.) dans un fichier lisible et transportable. L'administrateur utilise l'option d'import pour charger ce fichier XML. Alternative : si une connexion directe entre instances est configurée, l'administrateur peut naviguer vers 'All > System Update Sets > Update Sources' pour récupérer l'Update Set directement depuis l'instance source sans passer par un fichier intermédiaire, à condition qu'une source distante avec l'URL et les credentials de l'instance de développement soit déjà configurée. PHASE 2 — Prévisualisation (Preview) : Une fois l'Update Set chargé dans les 'Retrieved Update Sets', l'administrateur lance la prévisualisation. Cette étape analyse l'Update Set et détecte les conflits potentiels entre les 35 personnalisations et la configuration existante en recette. Il est impératif de traiter tous les conflits identifiés avant de passer à l'étape suivante. PHASE 3 — Validation (Commit) : Après résolution des conflits, l'administrateur procède au Commit, qui applique effectivement les personnalisations sur l'instance de recette. L'Update Set doit être en état 'Complete' pour avoir été exportable depuis le développement. Le processus est identique pour le déploiement ultérieur vers la production.

Quelles fonctionnalités natives de navigation ServiceNow le responsable de la plateforme doit-il faire connaître aux 4 500 agents pour réduire les appels au support ? Décrivez précisément comment retrouver un enregistrement récemment consulté et comment naviguer rapidement vers une application ou un module.

Le responsable doit mettre en avant les fonctionnalités natives suivantes : 1) L'onglet 'History' (Historique) dans l'Application Navigator — situé dans le panneau de navigation gauche de l'interface, cet onglet affiche par défaut les 30 dernières entrées consultées par l'utilisateur au cours de sa session. C'est la méthode la plus rapide pour retrouver un enregistrement récemment visité sans avoir à naviguer dans les listes. L'Application Navigator est le panneau de navigation situé à gauche de l'interface qui contient également les onglets 'Favorites' et la liste des applications et modules. 2) Le Navigation Filter — la barre de filtre en haut de l'Application Navigator permet de rechercher rapidement des applications et des modules par mot-clé. Il suffit de saisir quelques lettres pour affiner dynamiquement la liste des modules disponibles, sans avoir à parcourir manuellement toute l'arborescence des applications. 3) Les Favoris (icône étoile) — chaque application ou module peut être ajouté aux favoris en cliquant sur l'icône en forme d'étoile qui apparaît au survol dans l'Application Navigator, permettant un accès permanent aux modules les plus utilisés. 4) Le Global Search — accessible via la barre de recherche en haut de l'interface, il permet de rechercher des enregistrements à travers l'ensemble de l'instance en une seule requête, couvrant plusieurs tables selon les groupes de recherche configurés. 5) Pour la première connexion à l'interface Next Experience UI, un Onboarding Component est automatiquement présenté aux utilisateurs pour les guider à travers les principales fonctionnalités de la nouvelle navigation — le responsable doit s'assurer que ce composant est actif et que les agents sont invités à le compléter lors de leur première connexion.

Comment le responsable de la plateforme peut-il utiliser les fonctionnalités natives ServiceNow pour communiquer sur les maintenances planifiées et les évolutions auprès des 4 820 agents lors de leur connexion ? Quelles options de personnalisation d'interface sont disponibles pour les agents eux-mêmes ?

Pour la communication institutionnelle lors de la connexion : ServiceNow permet de configurer la page d'accueil (Homepage ou Login Page) pour afficher des messages personnalisés aux utilisateurs lors de leur connexion à la plateforme. Cette fonctionnalité permet aux administrateurs système de communiquer des informations importantes comme les maintenances planifiées, les évolutions de la plateforme ou les procédures d'urgence. Ces messages sont configurables depuis les paramètres d'administration de la page de connexion et peuvent être ciblés selon les populations d'utilisateurs. Pour des communications plus ponctuelles et contextuelles, Connect Chat (l'outil de messagerie instantanée intégré à ServiceNow) peut être utilisé pour des annonces au sein d'équipes ou de groupes spécifiques, lié au contexte des enregistrements. Concernant la personnalisation de l'interface par les agents eux-mêmes : chaque utilisateur peut personnaliser son interface via le menu 'System Settings', accessible en cliquant sur l'icône d'engrenage en haut à droite de l'interface. Ce panneau permet de modifier des préférences personnelles telles que le thème visuel, la langue d'affichage, les notifications et l'affichage des listes. Il est important de noter que ces préférences sont propres à chaque utilisateur et ne sont pas partagées. Pour les 4 500 agents utilisateurs finaux, le responsable devra s'assurer que la propriété 'com.glideapp.home.deprecate_homepages' est correctement configurée pour encadrer la création de pages d'accueil personnalisées et éviter une prolifération non contrôlée de configurations utilisateur.

La DSI envisage d'activer plusieurs plugins sur l'instance de production. Quels sont les risques spécifiques liés à l'activation de plugins dans ServiceNow, et quelle stratégie l'administrateur doit-il adopter pour sécuriser ces activations ?

L'activation de plugins dans ServiceNow comporte un risque majeur et irréversible : une fois qu'un plugin est activé sur une instance, il est généralement impossible de le désactiver ou de le désinstaller. Cette contrainte est fondamentale et distingue les plugins des simples personnalisations de configuration. L'activation d'un plugin peut modifier de façon permanente le schéma de la base de données (ajout de tables, de champs), installer des données de référence et des configurations qui ne peuvent pas être simplement supprimées sans risquer de déstabiliser l'ensemble de la plateforme. Les risques concrets pour la métropole sont : 1) Impact irréversible sur le schéma de données de production, 2) Consommation de ressources système pouvant affecter les performances pour les 4 820 utilisateurs, 3) Dépendances créées entre plugins pouvant compliquer les futures mises à niveau, 4) Introduction de fonctionnalités non souhaitées ou de données de démonstration difficiles à supprimer. La stratégie recommandée est la suivante : toujours tester l'activation d'un plugin sur une instance non-production (développement ou recette) avant toute activation en production. Il faut documenter précisément les modifications apportées par le plugin (nouvelles tables, nouvelles applications, nouvelles règles), évaluer l'impact sur les personnalisations existantes et former les administrateurs aux nouvelles fonctionnalités avant le déploiement. Si plusieurs plugins doivent être activés simultanément, le plugin CICD Spoke (Continuous Integration and Continuous Delivery) peut permettre d'automatiser et d'orchestrer ces déploiements dans une démarche structurée. L'administrateur doit également vérifier la compatibilité des plugins avec la version actuelle de ServiceNow déployée sur les instances de la métropole.