Résumé
À mesure que les organisations se développent et que leurs opérations IT gagnent en maturité, l’architecture fondamentale de leur plateforme de gestion des services informatiques (ITSM) peut faire toute la différence pour atteindre une agilité durable, une intégration efficace et un haut niveau de service.
Certaines solutions ITSM, comme HaloITSM, utilisent un modèle simplifié à table unique (stockant tous les enregistrements de service dans une seule table unifiée). À l’inverse, Ivanti Neurons for ITSM s’appuie sur une architecture orientée objet plus avancée, qui segmente les processus ITIL distincts (incidents, problèmes, changements et demandes) en entités modulaires séparées.
Ce livre blanc examine les limites de l’approche à table unique, en particulier dans les environnements d’entreprise complexes, et met en évidence les avantages d’une architecture ITSM plus structurée et évolutive.
| Fonctionnalité/capacité | Table unique | Module |
|---|---|---|
| Flexibilité des workflows | Limitée | Élevée |
| Alignement ITIL | Basique | Complet |
| Isolation des personnalisations | Faible | Élevée |
| Granularité des rapports | Modérée | Avancée |
| Complexité d’intégration | Élevée | Faible |
| Évolutivité | Modérée | Élevée |
| Performances | Modérées | Élevées |
| Sécurité | Complexe | Simplifiée |
1. Introduction
Le paysage de l’ITSM évolue rapidement, avec des exigences croissantes en matière d’automatisation, d’intégration et de prestation de services centrée sur l’utilisateur. Si la simplicité peut être un avantage pour les petites équipes ou les startups, elle devient souvent un frein à mesure que les organisations se développent. Ce document examine les compromis architecturaux entre le modèle à table unique de HaloITSM et la conception modulaire d’Ivanti Neurons.
2. Comprendre le modèle ITSM à table unique
Dans les plateformes qui utilisent une table unique, tous les enregistrements de service — qu’il s’agisse d’incidents, de demandes de service, de problèmes ou de changements — sont stockés dans une seule table « Tickets ».
Voici une illustration d’une architecture ITSM à table unique comportant six champs :
| N° d’enregistrement | Type d’enregistrement | Nom du propriétaire | Objet | Confidentiel | Priorité |
|---|---|---|---|---|---|
| 1 | Incident | Don | Erreur VPN | 2 | |
| 2 | Changement | Jamie | Correctif SQL Server | Faible | |
| 3 | Dossier RH | Harold | Ma paie est incorrecte | Oui | Urgente |
| 4 | Incident | Don | Défaillance SAP | 1 | |
| 5 | Demande | Patricia | Nouvel ordinateur | Faible |
Le premier élément que vous remarquerez est le champ intitulé « Type d’enregistrement ». Il détermine quelles données sont stockées dans l’enregistrement et constitue le champ principal pour restreindre l’accès à ce type de champ.
Sécurité
Commençons par examiner le cadre de sécurité de cette table. La définition suivante décrit les autorisations d’accès d’Harold.
Harold dispose d’un accès complet à table = « tickets » et type d’enregistrement = « Dossier RH ».
Cette règle de sécurité garantit qu’Harold peut accéder à la table des tickets et consulter uniquement les dossiers RH.
Examinons maintenant cette règle pour Don, qui travaille dans l’IT…
Don dispose d’un accès complet à table = « tickets ».
Un problème se pose, car Don, employé IT, dispose d’un accès illimité à l’ensemble de la table. Cela pourrait exposer par inadvertance à Don des données confidentielles liées à des dossiers RH.
La règle devrait être :
Don dispose d’un accès complet à table = « tickets » et type d’enregistrement NOT = « Dossier RH ».
Cette complexité augmente lorsque l’on accorde à Don un accès complet aux « incidents », mais uniquement un accès en lecture aux « changements ».
Configuration
La configuration dans un environnement à table unifiée peut également s’avérer complexe, car les champs d’une même table peuvent avoir des exigences différentes selon le type d’enregistrement.
En observant notre table, nous constatons différents types de priorité pour les types d’enregistrement concernés. Les incidents respectent la norme ITIL, avec un système numérique (1, 2, 3, 4), tandis que les changements et les demandes sont classés en priorité faible, moyenne ou élevée. Les demandes RH, quant à elles, sont classées comme faibles, élevées ou urgentes.
Comment mettre en œuvre et maintenir cette complexité ? Si un champ libre réduit l’intégrité et la standardisation des données, une table de référence avec des filtres par type d’enregistrement est préférable. Toutefois, cela présente toujours le défi de types de données mixtes, ce qui complique le reporting et la maintenance des champs/tables.
La configuration dans une table unique partagée est plus complexe, car toutes les modifications de configuration doivent tenir compte de tous les types d’enregistrement. Par exemple, le champ « Confidentiel » est obligatoire pour les dossiers RH, mais pas pour les autres types d’enregistrement. Si « Dossier RH » disposait de sa propre table, vous pourriez simplement rendre le champ obligatoire au niveau de la table. Si nous effectuons cette modification dans une table unique, ce champ devient alors obligatoire pour les incidents, les changements et les demandes, qui n’en ont pas besoin. La solution consiste à l’imposer par programmation comme champ obligatoire dans une règle métier de champ, ce qui nécessite une définition et une administration supplémentaires.
Supposons maintenant qu’une équipe juridique souhaite créer une application personnalisée pour les demandes juridiques. Dans une architecture à table unique, le type d’enregistrement devrait être « Juridique » et certains champs pourraient être réutilisés (par exemple, « Objet », « Description », « Confidentiel »). Mais l’équipe juridique a également besoin de champs obligatoires supplémentaires : « Externe » (oui/non), « Procédure judiciaire » (oui/non), etc. Ces champs doivent être ajoutés à la table des tickets, aux formulaires et au workflow. Les champs supplémentaires doivent être soigneusement planifiés afin de ne pas impacter les types d’enregistrement, les définitions de sécurité et les règles métier existants.
Performances et évolutivité
Si une architecture à table unique est efficace au départ, avec moins d’enregistrements et de champs OOTB, ses performances peuvent diminuer à mesure que le volume d’enregistrements augmente — à moins de maintenir rigoureusement l’hygiène de la base de données et l’indexation. En outre, l’ajout de champs personnalisés peut encore accentuer les baisses de performance potentielles.
De manière générale, les bonnes pratiques pour les tables de base de données consistent à :
- Éviter les champs de table inutiles.
- Normaliser les données lorsque cela est possible afin de réduire les champs redondants.
- Interroger et renvoyer uniquement les champs dont vous avez besoin.
- Indexer correctement les champs de la table afin d’optimiser les performances.
Comment un système ITSM reposant sur une approche à table unique garantit-il les performances et l’évolutivité ?
Si un modèle de données à table unique simplifie certains aspects de la gestion des services informatiques, il présente néanmoins des limites qu’il est important de comprendre.
3. Les arguments en faveur d’une architecture ITSM modulaire
Une architecture ITSM modulaire est une architecture dans laquelle chaque processus ITSM est modélisé comme un objet métier distinct et relié à d’autres objets métier (processus) ; par exemple, un incident à un problème, ou un problème à un changement. Cette approche modulaire suit étroitement les processus ITSM et garantit l’isolation des données, ce qui offre plusieurs avantages.
Workflows spécifiques aux processus
Dans une conception de workflow à tables modulaires, les SLA, les approbations et les règles métier peuvent être propres à la table (processus). Aucun filtrage spécifique n’est nécessaire pour empêcher le workflow de s’exécuter sur un enregistrement d’un autre type (processus ITSM). Par exemple : des critères d’escalade appliqués à un incident en cas de non-respect d’un SLA.
Avec cette approche, l’alignement avec les bonnes pratiques et la gouvernance ITIL est plus fluide, ce qui empêche effectivement l’exécution sur des processus non ITIL (comme les dossiers RH ou les ordres de travail des services généraux).
Sécurité renforcée
En séparant les tables par processus, vous renforcez la sécurité et réduisez le risque d’accès involontaire à des données sensibles. Ici, l’accès est accordé uniquement aux personnes explicitement autorisées, avec des mesures de sécurité supplémentaires facilement adaptables pour cibler des données et des enregistrements spécifiques.
En outre, la sécurité par table distincte garantit que le reporting et les exportations respectent les règles de sécurité standard des tables, plutôt que des règles de sécurité plus complexes au niveau des lignes.
Personnalisation améliorée
Les tables propres à chaque processus offrent une plus grande flexibilité de configuration, en garantissant que les changements apportés à un processus n’empiètent pas sur les autres (ni sur les champs largement utilisés). Des configurations de champs uniques au niveau de la table éliminent le besoin de règles métier complexes et permettent de prendre en charge des scénarios plus avancés, comme les approbations CAB pour les changements ou l’analyse des causes racines pour les problèmes.
Reporting et analytique avancés
Avec des tables alignées sur les processus qui contiennent des données structurées, le reporting granulaire, l’analyse des tendances et le suivi des KPI dans les domaines ITIL deviennent plus réalisables, et l’intégration de données associées est simplifiée. Par exemple, un rapport qui présente tous les incidents résolus par des changements.
Cela facilite également le reporting de conformité et les tableaux de bord exécutifs couvrant des objets métier de processus ou d’entreprise (par exemple, dossiers RH, ordres de travail des services généraux).
Meilleure intégration et extensibilité
L’intégration rationalisée avec les systèmes externes s’appuie sur des tables individuelles alignées sur les processus. Cette méthode simplifie non seulement l’exposition des API, mais renforce également la sécurité (car les API nécessitent un accès explicite à l’API de la table).
Cela permet une extensibilité low-code/no-code pour accélérer l’innovation, ainsi que la flexibilité nécessaire pour étendre les objets métier existants ou en créer de nouveaux.
4. Questions à poser
Une structure de données à table unique peut freiner la croissance future. Lors de l’évaluation de systèmes ITSM, il est essentiel de bien comprendre l’architecture de données sous-jacente.
Posez les questions suivantes à votre fournisseur ITSM :
- Disposez-vous de tables séparées pour vos processus ITSM, ou sont-ils tous dans la même table ?
- Dans quelle mesure est-ce difficile à maintenir et à sécuriser ?
- Quel est l’impact de l’ajout d’une nouvelle fonction, comme les demandes juridiques ?
- Dans quelle mesure est-il difficile de reproduire une fonctionnalité personnalisée dans l’outil ?
- Combien de temps faudra-t-il pour créer un objet personnalisé ?
- Dans quelle mesure est-il difficile de protéger les données contre les accès non autorisés ?
- Pouvez-vous me montrer comment ajouter de nouveaux champs et de nouveaux objets ?
- Combien de personnes sont nécessaires ?
- Quel sera le coût ?
- Pourrai-je effectuer une mise à niveau ?
5. Quelle architecture ITSM vous convient le mieux ?
Une solution ITSM à table unique, comme HaloITSM, constitue un bon point de départ pour les organisations qui souhaitent démarrer rapidement avec une expérience utilisateur simplifiée. Mais ces solutions peuvent créer des défis de croissance et de passage à l’échelle pour des opérations IT matures, au niveau de l’entreprise.
À mesure que les organisations cherchent à s’aligner sur ITIL, à automatiser des workflows complexes et à s’intégrer à l’ensemble de l’écosystème numérique, une architecture modulaire comme Ivanti Neurons for ITSM offre la flexibilité, l’évolutivité et le contrôle nécessaires à une réussite durable.