ServiceDesk Plus On-Premise V16 :
Comment sécuriser la migration sans dégrader l’existant
La migration vers ServiceDesk Plus On-Premise V16 nécessite d’anticiper les dépendances, les personnalisations et les intégrations, tout en prévoyant une recette et un plan de retour arrière.
Rédigé par Christophe Dehaene
Une montée de version peut révéler des dépendances que l’on avait oubliées
Dans une instance ServiceDesk Plus utilisée depuis plusieurs années, les personnalisations finissent souvent par devenir invisibles. Un rapport s’appuie sur une valeur de site historique. Un script suppose qu’un champ peut rester vide. Une API consomme les enregistrements dans un ordre implicite. Une règle métier a été ajustée il y a longtemps et n’est plus documentée. Tout fonctionne, jusqu’au jour où une évolution du produit change l’un de ces comportements.
La V16, build 16000, mérite donc une préparation structurée. Le sujet le plus sensible est l’introduction du Base Site, mais la vigilance doit également porter sur les scripts, API, rapports, fonctions personnalisées et intégrations. L’objectif n’est pas de freiner la migration. Il est de savoir précisément ce qui doit être testé avant de toucher à la production.
Préparer la V16, c’est avant tout identifier les dépendances invisibles avant qu’elles ne deviennent des problèmes.
01
Base Site : le changement à comprendre avant tout autre test
Dans la V16, le Base Site devient le site de référence de l’application. Pour une nouvelle installation, il est créé comme site par défaut. Pour une instance existante, le site actuellement défini par défaut devient le Base Site.
IMPACT DE LA MIGRATION ET VÉRIFICATIONS À EFFECTUER
Le changement va au-delà d’un simple renommage : les enregistrements, configurations et utilisateurs sans site ou département associé sont désormais rattachés au Base Site. L’option « Not associated to any site » disparaît des cas concernés.
Sur le terrain, ce changement peut modifier les résultats des rapports, le comportement des formulaires et les filtres. Il est donc essentiel d’identifier les usages qui reposent sur l’absence de site ou sur le site par défaut, notamment dans les scripts.
02
Les personnalisations historiques sont souvent le vrai périmètre de risque
LES RISQUES LIÉS AUX PERSONNALISATIONS
Une instance standard est relativement simple à tester. Une instance enrichie au fil des années l’est beaucoup moins. Les risques apparaissent surtout là où l’organisation a ajouté sa propre logique : rapports personnalisés, scripts, fonctions, automatisations, règles métier, API ou connecteurs avec des applications tierces.
LES CHANGEMENTS TECHNIQUES EN V16
La V16 modifie aussi certains comportements techniques. Le document de version indique notamment qu’un ordre de tri par défaut est appliqué lorsqu’aucun tri n’est explicitement demandé pour certaines requêtes de plage. Des enregistrements renvoyés par les API ou affichés dans certaines listes peuvent donc apparaître dans un ordre différent. Une intégration qui dépendait implicitement de l’ordre de retour doit être vérifiée.
ANTICIPER LES RISQUES AVANT LA MIGRATION
La bonne approche consiste à établir un inventaire des dépendances avant la migration. Pour chaque personnalisation, il faut pouvoir répondre à trois questions : à quoi sert-elle, quelles données utilise-t-elle et comment vérifier qu’elle fonctionne toujours après passage en V16. Ce travail est souvent plus utile qu’une longue liste générique de tests.
03
Une recette utile reproduit les parcours critiques, pas seulement les écrans
Ouvrir quelques écrans et vérifier qu’ils s’affichent correctement ne suffit pas. Une recette de montée de version doit reproduire les parcours qui comptent réellement pour l’organisation. La demande doit être créée, affectée, escaladée, approuvée, notifiée et clôturée comme en production.
Le même principe vaut pour les autres modules. Un changement critique doit suivre son circuit d’approbation. Un actif doit être retrouvé dans l’inventaire. Une intégration doit recevoir et renvoyer les données attendues. Un rapport utilisé en comité de pilotage doit produire des résultats cohérents. Les e-mails entrants et sortants, les SLA, les automatisations et la CMDB doivent faire partie de la recette si l’organisation les utilise.
Le scénario de test doit partir des usages les plus importants, pas de la liste complète des fonctionnalités du produit. Dix parcours métier bien choisis apportent souvent plus de sécurité qu’une centaine de contrôles superficiels.
04
L’instance de test doit être suffisamment proche de la production
UN ENVIRONNEMENT DE TEST INSUFFISANT
Tester la V16 sur un environnement vide rassure peu. Ce qui doit être validé, ce sont les données, les personnalisations et les dépendances propres à l’instance réelle. L’environnement de recette doit donc reproduire autant que possible la configuration de production, tout en restant isolé.
CE QU’IL FAUT REPRODUIRE ET SÉCURISER
Il faut notamment disposer des mêmes grandes familles de données, des mêmes modèles de demandes, des principales règles d’automatisation, des scripts et des intégrations nécessaires aux tests. Les accès à des systèmes externes doivent être adaptés pour éviter qu’une instance de recette envoie de vrais messages, crée de vraies actions ou modifie des données de production.
LES BÉNÉFICES DE CETTE PRÉPARATION
Cette étape permet aussi de mesurer la durée réelle de l’opération, d’identifier les étapes manuelles et de préparer la fenêtre de changement. Une migration répétée une première fois hors production est beaucoup plus facile à piloter le jour du passage réel.
05
Le retour arrière doit être défini avant le démarrage, pas après un incident
Une sauvegarde n’est utile que si elle est exploitable. Avant la migration, l’organisation doit vérifier que la sauvegarde nécessaire est disponible, cohérente et compatible avec le scénario de restauration prévu. Le plan de changement doit également préciser le moment à partir duquel un retour arrière sera décidé.
Il est préférable de définir des critères simples : échec de démarrage, corruption de données, impossibilité de traiter un parcours critique, dysfonctionnement majeur d’une intégration ou dépassement de la fenêtre d’intervention. Sans critères décidés à l’avance, les équipes peuvent perdre du temps à hésiter alors que la fenêtre de maintenance se referme.
Le retour arrière est une mesure de maîtrise des risques, essentielle à une migration sécurisée.
Recevez votre livre blanc
Point de vigilance : ne mélangez pas migration technique et transformation fonctionnelle
La V16 apporte de nombreuses nouveautés, mais le jour de la migration n’est pas toujours le meilleur moment pour toutes les activer. Ajouter simultanément de nouveaux usages d’IA, modifier les workflows, revoir la CMDB et changer les canaux de support augmente fortement le nombre de variables à contrôler.
Pour une instance complexe, il est souvent plus sûr de séparer les étapes. D’abord stabiliser la montée de version. Ensuite activer les nouvelles fonctions selon un plan propre, avec leurs règles de gouvernance et leurs critères de succès. Cette séparation facilite le diagnostic si un problème apparaît.
Checklist avant passage en production
Identifier le build installé et vérifier la séquence de migration ManageEngine.
Recenser les scripts, API, rapports, fonctions, règles et intégrations dépendant des sites ou historiques.
Vérifier les sauvegardes et documenter le scénario de restauration.
Disposer d’une instance de test représentative de la production.
Tester les parcours métier critiques de bout en bout : e-mails, SLA, automatisations, actifs, CMDB et approbations.
Définir les critères de validation, la fenêtre d’intervention et les conditions de retour arrière.
En conclusion : une migration V16 se prépare comme un changement de production
Le passage à ServiceDesk Plus On-Premise V16 ne doit pas être traité comme une simple opération de maintenance lorsque l’instance comporte des personnalisations, des intégrations ou une organisation multisite. Le nouveau fonctionnement du Base Site suffit à justifier une analyse des dépendances, mais l’essentiel est plus large : comprendre ce qui, dans l’environnement actuel, repose sur un comportement implicite.
La meilleure première étape consiste à dresser la cartographie des personnalisations et des parcours critiques, puis à les rejouer sur une instance de test. Cette préparation réduit l’incertitude le jour de la migration et permet de profiter ensuite des nouveautés de la V16 sur une base stabilisée. Une montée de version réussie est d’abord un changement maîtrisé.
Pour aller plus loin
Si vous souhaitez évaluer les impacts d’une migration vers ServiceDesk Plus On-Premise V16 dans votre environnement, un atelier de cadrage avec By The Way permet d’identifier les dépendances, les parcours à tester et les conditions de sécurisation du passage en production.
Sources officielles
ManageEngine — ServiceDesk Plus On-Premises Release Notes, build 16000
https://www.manageengine.com/products/service-desk/on-premises/readme-new.html#16000
ManageEngine — Migration Sequence
https://www.manageengine.com/products/service-desk/on-premises/migration-sequence.html
ManageEngine — ServiceDesk Plus On-Premises Service Packs
https://www.manageengine.com/products/service-desk/on-premises/service-packs.html
ManageEngine — Documentation d’administration ServiceDesk Plus On-Premise
https://help.servicedeskplus.com/