0

Et si vous amélioriez la qualité de vos environnements de test tout en réduisant les coûts ?

La problématique de la mise à la disposition des environnements de test n’est pas nouvelle, mais elle s’aggrave d’années en années pour les raisons suivantes :

  • La volumétrie des environnements de production  ne cesse de croître, les infrastructures de test ne sont pas extensibles et la stabilisation des coûts devient une exigence. Le cas le plus courant est la réplication de l’environnement de production avec un clonage du SGBD
  • Quand le nombre d’applications ou de projets augmente,  les demandes d’environnements de test progressent en même temps  alors que le temps imparti aux équipes IT est limité
  • De plus en plus de données à caractères sensibles sont exposées  et répliquées plusieurs fois, accessible à des catégories d’utilisateurs qui ne devraient pas y avoir accès

Pour faire face à ces défis, les entreprises choisissent de se limiter à un nombre restreint d’environnement de test car les infrastructures ne sont pas prévues pour recevoir  autant de copies voulues. De plus,  elles s’accommodent d’un délai  significatif entre la formulation de la demande et la mise à disposition (souvent plusieurs jours, parfois plusieurs semaines). Il est assez rare de voir un processus de copie partielle développé avec des scripts « spécifiques » pour des raisons liées à la difficulté de respecter l’intégrité référentielle et aux performances de transfert nécessaires.

Pour les données sensibles, on observe que dans le meilleur des cas, des scripts spécifiques sont développés et maintenus « manuellement » pour anonymiser et masquer  certains champs et que dans le cas le plus courant, rien n’est masqué car les responsables pensent que les clauses de confidentialité passées avec les salariés et les prestataires sont suffisantes pour se mettre à l’abri des fuites de données. Néanmoins, de plus en plus d’interlocuteurs sont conscients que les environnements de test sont concernés par ces aspects de sécurité et ne répondent pas aux exigences, notamment formulées par des organismes tels que la CNIL.

Ces approches  « traditionnelles » sont insuffisantes et se traduisent souvent par une frustration des équipes chargées des test de recettes fonctionnelles : il faut toujours plus de temps pour mettre à disposition un environnement, et la qualité des données se dégradant rapidement après une campagne de test, il faut souvent rafraichir le même système de test avec des données source. Il est difficile également de satisfaire toutes les demandes de mise à disposition et un arbitrage est souvent nécessaire car l’espace de stockage dédié aux environnements de test ne permet pas de répliquer  indéfiniment une base de données source qui fait assez souvent plusieurs centaines de Gigaoctets et de moins en moins rarement plusieurs Téraoctets.

La multiplication des technologies SGBD (Oracle, Teradata, MySQL…) ne facilite pas non plus une standardisation des processus de réplication et de mise à disposition.

D’autre part, lorsque  la confidentialité des données est « déléguée »  à quelques scripts SQL appliqués lors de l’étape « post-clone », on s’aperçoit  que les algorithmes de masquage sont très limités et ne permettent pas de conserver un panel  fonctionnel aussi riche que la source pour les testeurs. De plus, le développement des scripts nécessite une période de mise au point significative et donc prévoir  de passer du temps à maintenir ces scripts pour les adapter dès qu’une nouvelle version ou que de nouvelle données sensibles apparaissent. La réutilisation des scripts est également plus compliquée lorsque plusieurs  technologies SGBD sont présentes.

Le cycle complet de test et de recette est ainsi pénalisé et  il n’est pas difficile d’évaluer le nombre de jours hommes perdus dans ces processus manuels et itératifs « traditionnels » versus une solution « industrielle »  à condition de couvrir à minima les aspects suivants :

  • Créer un environnement de test  à parti d’un « Subset » en ne prenant qu’une partie de l’environnement source (par exemples prendre  10 % de la volumétrie)
  • Respecter l’intégrité des données au moment de l’extraction et du chargement
  • Détecter la présence des données à masquer et offrir une panoplie riche et complète de fonctions d’anonymisation, réutilisables et centralisées
  • Automatiser facilement ces processus de rafraichissement et/ou anonymisation
  • S’affranchir de la technologie SGBD
  • Garantir des performances à la hauteur de déplacement massif de données
  • Mutualiser facilement la plate-forme : toutes les applications de l’entreprise
    pourront bénéficier des capacités de Subset et d’Anonymisation
  • Montée en compétence rapide des utilisateurs
  • Intégration facile dans le SI

Et vous, quels aspects souhaitez-vous couvrir ?

Share
This entry was posted in Gestion du Cycle de Vie des Données Applicatives (ILM), Protection des Données. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>