/
/

Comment faire évoluer les modèles de gouvernance lors du remplacement de systèmes de gestion informatique hérités

par Team Ninja
How to Evolve Governance Models When Replacing Legacy IT Management Systems blog banner image

Points clés

  • La gouvernance héritée survit rarement intacte au remplacement d’un système : les circuits de validation, les modèles d’accès et les chemins d’escalade se rompent souvent, et les inefficacités passent d’un système à l’autre.
  • Tous les contrôles ne méritent pas d’être conservés : certaines configurations n’existent qu’en raison des limites de la plateforme. Identifiez donc les écarts avant la transition pour savoir lesquels redessiner ou abandonner.
  • Une gouvernance axée sur les résultats résiste au changement de système : définissez ce qui doit se produire, et non la façon dont une plateforme s’en charge. Les contrôles deviennent ainsi transférables et plus faciles à maintenir d’un remplacement à l’autre.
  • La couverture de conformité peut se rompre sans bruit pendant une transition : si le nouveau système ne produit pas de preuves d’audit équivalentes avant le remplacement de la plateforme héritée, l’écart n’apparaîtra qu’au moment où un audit le mettra au jour.

Lorsque les équipes informatiques remplacent des systèmes de gestion informatique hérités, la gouvernance n’est pas leur première priorité. Pourtant, les processus de validation, les structures de reporting, les contrôles d’accès et les modèles de conformité se construisent autour du fonctionnement des anciennes plateformes et des anciens systèmes. Avec le temps, ces systèmes cessent d’être de simples outils et rendent la gouvernance dépendante de leur mode de fonctionnement.

La transformation de la gouvernance informatique doit accompagner le remplacement des systèmes, et non le suivre. Si la gouvernance n’est pas actualisée pendant la transition, les équipes finissent par reconstruire les mêmes structures de contrôle dans le nouvel environnement. Elles transposent alors les anciennes inefficacités et des coûts plus élevés dans la nouvelle plateforme censée y remédier.

Transformer et faire évoluer la gouvernance informatique lors du remplacement de systèmes de gestion hérités

Un cadre de gouvernance de la gestion du changement donne aux responsables informatiques un moyen concret de repenser les contrôles et les responsabilités pendant le remplacement des systèmes hérités.

Comment les systèmes hérités façonnent la gouvernance au fil du temps

Comprendre comment les systèmes hérités façonnent la gouvernance existante est une étape indispensable avant d’entamer toute refonte. Sans cela, il est assez facile de reproduire les mêmes dépendances dans le nouvel environnement sans s’en rendre compte.

Voici quelques-unes des manières dont les plateformes héritées façonnent la gouvernance au fil du temps :

  • Des circuits de validation imposés par la logique du système : les processus de validation se construisent autour de ce que le système hérité sait faire, et non autour des besoins de l’entreprise. Lorsque les systèmes changent, ces circuits ne se transposent pas toujours proprement dans le nouveau flux de travail.
  • Des formats de reporting liés aux sorties du système hérité : les équipes s’habituent aux rapports générés par la plateforme héritée. Ces formats deviennent la norme, même lorsqu’ils ne correspondent plus à ce qui est utile ou exigé.
  • Un contrôle d’accès dicté par les limites de la plateforme : les modèles d’autorisations sont souvent façonnés par ce que le système hérité pouvait prendre en charge, plutôt que par des exigences de sécurité ou d’exploitation. Ces modèles se perpétuent tant qu’ils ne sont pas réellement revus ou remplacés.
  • Des preuves d’audit générées par des outils précis : les processus de conformité se construisent autour des sorties d’un outil donné. Lorsque cet outil est remplacé, la piste d’audit peut se rompre si ces sorties ne sont pas prises en compte lors du changement.
  • Des chemins d’escalade définis par les contraintes du système : la logique d’escalade est câblée dans la façon dont la plateforme héritée achemine les incidents. Les équipes suivent ces chemins sans se demander s’ils ont encore du sens.

Globalement, lorsque la gouvernance se construit autour d’une plateforme plutôt qu’autour des besoins de l’entreprise, elle survit rarement intacte au remplacement d’un système.

Repérer les éléments de gouvernance liés aux systèmes hérités

Avant de repenser quoi que ce soit, les équipes informatiques doivent déterminer quelles parties du cadre de gouvernance informatique existant sont essentielles et lesquelles n’existent que parce que la plateforme héritée fonctionnait d’une certaine manière.

Voici les domaines à examiner pour détecter les dépendances héritées :

  • Hiérarchies de validation et points de décision : cartographiez le fonctionnement actuel des validations et repérez les étapes dictées par la logique du système plutôt que par une politique. Ce sont celles qui risquent le plus d’être reconstruites inutilement dans le nouvel environnement et qui doivent être remplacées.
  • Modèles d’autorisations et d’accès : examinez la façon dont les accès sont actuellement accordés et restreints. Par exemple, si les modèles d’autorisations reflètent les limites de la plateforme et répondent à peine aux exigences de sécurité, ils doivent être repensés plutôt que migrés.
  • Exigences de conformité et d’audit : identifiez les contrôles de conformité qui dépendent des sorties du système hérité. Ils doivent bénéficier d’une couverture équivalente dans la nouvelle plateforme avant la mise hors service de l’ancienne.
  • Attentes et sorties de reporting : documentez les rapports produits et leurs utilisateurs, tout en déterminant s’ils sont réellement nécessaires.
  • Processus de traitement des exceptions : examinez la façon dont les exceptions sont aujourd’hui gérées et approuvées. Les processus qui reposent sur les flux de travail du système hérité ne se transposent pas forcément proprement et doivent être reconstruits de façon délibérée.

Distinguer les contrôles réellement nécessaires des implémentations propres à une plateforme donne aux équipes informatiques une vision plus claire de ce qui doit être conservé et de ce qui peut être simplifié ou abandonné.

Passer d’un contrôle fondé sur les outils à une gouvernance axée sur les résultats

Une gouvernance fondée sur les outils se rompt à chaque changement de plateforme. Une gouvernance axée sur les résultats définit ce qui doit se produire et reste cohérente, quel que soit le système utilisé pour y parvenir.

Voici des exemples concrets de ce que cela implique :

  • Garantir que les validations ont lieu, quelle que soit la plateforme : l’exigence est que les validations se produisent et soient documentées. Le système qui prend en charge ce processus est secondaire, du moment que le résultat est cohérent et vérifiable.
  • Valider les résultats de conformité plutôt que l’activité du système : les contrôles de conformité doivent confirmer que les contrôles requis fonctionnent, ce qui rend la conformité transférable et cohérente d’une plateforme à l’autre.
  • Mesurer la performance du service plutôt que l’usage des outils : les indicateurs de performance doivent refléter la qualité de la prestation de service, sans se focaliser sur l’utilisation des outils.
  • Faire appliquer la responsabilité sur l’ensemble des flux de travail : la responsabilité doit être rattachée aux rôles et aux missions, et non à la façon dont un système hérité acheminait le travail.

Une gouvernance définie autour des résultats plutôt que des outils est plus facile à maintenir, plus facile à auditer et bien moins susceptible de se rompre lorsque les systèmes sous-jacents changent.

Définir les structures de propriété et de responsabilité pendant la modernisation technologique

La gouvernance peut se déliter si la propriété n’est pas définie pendant la modernisation technologique. Le travail risque d’être dupliqué à certains endroits et complètement oublié à d’autres si les responsabilités ne sont pas explicitement réattribuées.

Voici les bonnes pratiques pour définir la propriété et la responsabilité pendant une transformation de la gouvernance informatique :

  • Attribuer la propriété par service ou par domaine : chaque domaine de service a besoin d’un responsable nommément désigné, chargé des résultats de gouvernance.
  • Définir la responsabilité à partir des résultats : la responsabilité doit être rattachée aux livrables, et non à la façon dont le système hérité attribuait les tâches. Elle reste ainsi claire même lorsque les flux de travail évoluent autour d’elle.
  • Aligner les rôles sur les flux de travail actualisés : à mesure que les processus sont repensés, les rôles doivent être revus et mis à jour pour refléter la circulation réelle du travail dans le nouvel environnement. Des rôles calqués sur les anciens flux de travail ne s’intégreront pas correctement dans un système modernisé.
  • Établir une propriété claire des escalades : déterminez qui est responsable des escalades dans le nouvel environnement avant la fin de la transition. Les chemins d’escalade qui reposaient sur l’acheminement du système hérité doivent être reconstruits de façon délibérée, et non supposés se reporter d’eux-mêmes.

Une propriété clairement définie pendant la transition maintient la gouvernance opérationnelle lorsque l’environnement rencontre des problèmes ou de l’instabilité.

Standardiser les principes de gouvernance entre les systèmes

Une gouvernance incohérente crée des lacunes difficiles à repérer et encore plus difficiles à combler. Il est donc essentiel de standardiser les principes de gouvernance sur tous les systèmes, ce qui vous aide à préserver le modèle de contrôle pendant que l’environnement change autour de lui.

Voici les principaux domaines à standardiser :

  • Définitions des politiques et critères d’application : une politique doit avoir la même signification et s’appliquer de la même façon, quel que soit le système dans lequel s’exécute un flux de travail.
  • Modèles de contrôle d’accès : appliquez les mêmes standards de contrôle d’accès à tous les systèmes concernés par la transition. Des modèles d’autorisations différents fonctionnant en parallèle créent de la confusion et augmentent le risque de lacunes dans la couverture.
  • Indicateurs et formats de reporting : définissez un ensemble cohérent d’indicateurs et de formats de reporting valables pour tous les systèmes. Vous éviterez ainsi que différentes plateformes produisent des chiffres différents pour une même mesure.
  • Méthodes de validation de la conformité : les contrôles de conformité doivent produire des résultats équivalents, quel que soit le système évalué. Si les méthodes de validation varient selon la plateforme, les preuves d’audit deviennent difficiles à comparer et à défendre.

C’est la standardisation pendant la transition qui empêche le modèle de gouvernance de se désagréger à mesure que des systèmes sont ajoutés, remplacés ou mis hors service.

Aligner les modèles de conformité et d’audit sur les nouveaux systèmes

La modernisation technologique introduit un risque de conformité bien particulier, facile à négliger. Un nouveau système ne produit pas forcément les preuves d’audit de la même manière que l’ancien. Si cet écart n’est pas identifié et comblé avant la mise hors service du système hérité, la couverture de conformité se rompt sans que personne ne s’en aperçoive, jusqu’à ce qu’un audit le découvre plus tard.

Voici les étapes pour aligner les modèles de conformité et d’audit sur les nouveaux systèmes :

  • Identifier les preuves d’audit requises : documentez les preuves nécessaires à chaque exigence de conformité et leur source actuelle. Vous obtenez ainsi une liste claire des sorties que le nouveau système devra reproduire ou remplacer.
  • S’assurer que les nouveaux systèmes peuvent générer des sorties équivalentes : vérifiez que la nouvelle plateforme est capable de produire les mêmes types de preuves d’audit avant d’éteindre le système hérité. Si ce n’est pas le cas, un plan doit être prévu pour combler cet écart.
  • Mettre à jour la documentation et les descriptions de contrôles : la documentation de conformité qui fait référence aux processus du système hérité doit être actualisée pour refléter le fonctionnement des contrôles dans le nouvel environnement. Une documentation obsolète est un constat d’audit fréquent lors des transitions de systèmes.
  • Valider l’exactitude du reporting : vérifiez que les rapports générés par le nouveau système sont exacts et complets avant de les utiliser à des fins de conformité. Les erreurs des premiers rapports sont plus faciles à détecter et à corriger avant qu’elles n’intègrent le dossier d’audit.

L’alignement de la conformité est bien plus difficile à traiter une fois la transition terminée. Ce travail doit être mené en parallèle du remplacement des systèmes pour éviter des lacunes difficiles à combler après coup.

Adopter une approche progressive des changements de gouvernance

Un cadre de gouvernance de la gestion du changement donne les meilleurs résultats lorsque les évolutions de gouvernance sont introduites progressivement plutôt que d’un seul coup. Vouloir basculer vers un nouveau modèle de gouvernance en même temps que vers un nouveau système augmente le risque de voir les deux échouer ensemble.

Voici des stratégies efficaces pour une transition de gouvernance par étapes :

  • Faire fonctionner en parallèle les modèles de gouvernance hérité et nouveau : maintenez les contrôles existants actifs pendant l’introduction et la validation des nouveaux. Cela évite l’apparition de lacunes pendant la transition et laisse aux équipes le temps de s’adapter avant la mise hors service de l’ancien modèle.
  • Faire évoluer progressivement les structures de validation et de reporting : modifiez les circuits de validation et les formats de reporting de façon incrémentale plutôt que de les remplacer tous en même temps. Chaque mise à jour doit être validée avant l’introduction de la suivante.
  • Valider l’efficacité des contrôles à chaque étape : confirmez que les contrôles fonctionnent comme prévu avant de passer à la phase suivante. Les problèmes détectés tôt dans un déploiement progressif restent circonscrits et sont plus faciles à corriger que ceux découverts après une bascule complète.
  • Ajuster en fonction des retours opérationnels : recueillez les retours des équipes qui utilisent le nouveau modèle de gouvernance et servez-vous-en pour affiner l’approche avant de l’étendre. Une gouvernance qui fonctionne en théorie mais crée des frictions en pratique doit être ajustée avant de devenir la norme.

Un changement de gouvernance par étapes permet aux entreprises de se moderniser sans mettre en péril la continuité de service pendant la transition.

Éviter de recréer les schémas de gouvernance hérités

Il est facile de reproduire les schémas de gouvernance hérités dans un nouveau système sans s’en rendre compte. Sous la pression d’une transition, le réflexe des équipes est de reconstruire ce qu’elles connaissent déjà plutôt que de se demander si cela a encore du sens.

Voici les signaux d’alerte indiquant que des schémas hérités sont en train d’être recréés :

  • La reconstruction de chaînes de validation complexes : si le nouveau système se retrouve avec autant d’étapes de validation que l’ancien, il vaut la peine de se demander si chaque étape est réellement nécessaire ou simplement reprise par habitude.
  • Le maintien de couches de contrôle superflues : les contrôles ajoutés pour contourner les limites du système hérité n’ont pas besoin d’exister dans un environnement moderne. Si un contrôle ne peut être rattaché à une exigence actuelle, il doit être examiné en vue d’une suppression.
  • La reproduction de formats de reporting obsolètes : les rapports construits autour des sorties du système hérité ne reflètent peut-être plus ce qui est utile. Les reconstruire dans le nouveau système sans réexaminer leur finalité revient à conserver les anciennes inefficacités sous un nouvel emballage.
  • La préservation de chemins d’escalade inefficaces : les chemins d’escalade façonnés par l’acheminement du système hérité ajoutent souvent des étapes qui ralentissent la résolution. La transition est le bon moment pour les simplifier, pas pour les reproduire.

La modernisation de la gouvernance ne consiste pas à transférer les contrôles existants dans un nouveau système. Elle consiste à concevoir des contrôles qui correspondent aux besoins réels et actuels de l’entreprise.

Une transformation de la gouvernance informatique qui ne laisse rien de côté

Remplacer un système hérité sans actualiser la gouvernance conduit les entreprises à exploiter des plateformes modernes sous des contrôles obsolètes. La dépendance ne disparaît pas d’elle-même. Elle doit être identifiée, repensée et validée dans le cadre de la transition.

C’est pourquoi les entreprises doivent basculer vers une gouvernance axée sur les résultats. De plus, définir clairement la propriété et adopter une standardisation des contrôles pendant la modernisation technologique leur permettra de sortir du processus avec un modèle meilleur et actualisé, adapté aux exigences des environnements informatiques actuels.

Sujets connexes :

FAQs

Les équipes risquent de se rabattre sur ce qu’elles connaissent déjà. Résultat : la nouvelle plateforme fera tourner des chaînes de validation et des modèles d’autorisations proches de ceux de la précédente, avec les mêmes inefficacités.

Demandez-vous si le contrôle existerait encore si la plateforme était remplacée. Si la réponse est non, ou si personne ne sait expliquer l’exigence précise à laquelle il répond, il s’agit d’un vestige du système hérité.

Parce que basculer vers un nouveau modèle de gouvernance en même temps que vers un nouveau système peut faire échouer les deux ensemble. Maintenir les contrôles existants actifs pendant la validation des nouveaux évite l’apparition de lacunes avant que le remplacement ne fonctionne correctement.

Le nouveau système peut gérer la journalisation, le reporting et la production de preuves différemment de l’ancien. Si personne n’a vérifié que des sorties équivalentes existent dans la nouvelle plateforme, l’écart ressemble à une activité de transition normale, jusqu’au jour où un auditeur réclame des preuves qui ne sont plus produites.

You might also like

Prêt à simplifier les aspects les plus complexes de l'informatique et de la sécurité ?