Icon for Dreamteam

Pourquoi les copies de système et l'anonymisation des données vont-elles de pair ?

Les copies de système et l'anonymisation des données vont de pair, comme une voiture et une ceinture de sécurité. La copie de système en tant que voiture nous fait passer du système de production au système de test. L'anonymisation des données est la ceinture de sécurité : indispensable pour la sécurité et, dans la plupart des cas, prescrite par la loi.

Pourquoi les copies du système sont-elles indispensables ?

Bien que la pertinence des copies de système soit connue de la plupart des gens, la prise de conscience de la nécessité et des avantages de l'anonymisation est encore loin d'être acquise dans de nombreux cas. Une copie du système est indispensable au bon déroulement du développement. Le chaos régnerait rapidement si les développeurs étaient amenés à faire des tests sur le système de production. Il en résulterait des échecs permanents et de l'incertitude. Cela conduit à un rythme de développement lent. Personne ne veut être à l'origine d'une panne de système de plusieurs heures et donc d'une perte de revenus.

C'est pourquoi la plupart des entreprises misent sur des systèmes de développement, voire sur des systèmes d'assurance qualité. Ici, les développeurs peuvent pousser et tirer à leur guise. Un engagement trop audacieux peut susciter le mécontentement de vos collègues développeurs, tandis que le reste de l'entreprise, voire les clients, ne remarqueront pas ce drame interne. L'activité normale de l'entreprise n'est pas perturbée.

Pour pouvoir garantir que les développeurs puissent travailler sur un système aussi semblable que possible au système de production, on a généralement recours à des copies de système. Bien sûr, on pourrait aussi créer un nouveau système "sur le terrain", mais les avantages sont alors limités. En effet, chaque système grandit et évolue avec le temps. Ce qui est développé et testé sur un nouveau système ne fonctionne pas nécessairement sur un système qui s'est développé historiquement. La solution consiste donc à réaliser des copies du système qui se répètent régulièrement. Cela permet de garantir que l'environnement de développement/de qualité et l'environnement de production ne soient jamais trop différents La difficulté réside dans le fait qu'une copie de système peut être un processus long.

Et ici, nous ne parlons pas seulement du temps d'exécution pur, c'est-à-dire de la durée des étapes individuelles qui doivent être déclenchées. Nous parlons également du temps consacré par le personnel. A cela s'ajoute la question de savoir quand une copie du système peut être effectuée pour ne pas perturber l'activité commerciale. La plupart du temps, les développeurs doivent se résoudre à travailler le week-end. Si seulement il existait un produit capable d'automatiser la copie du système.

Anonymisation des données comme protection particulière pour les systèmes de test

Mais à peine la copie effectuée avec succès, le problème suivant se pose : la copie a réussi ! Toutes les données qui étaient auparavant conservées sur un système hermétiquement fermé par des personnes triées sur le volet se trouvent maintenant sur le système de test.  Comment le système de test est-il protégé ? Qui y a accès ? Qui a besoin de quelles autorisations ? Qu'en est-il de la RGPD ? Si l'on veut s'assurer que le système de test ne sera pas utilisé à des fins malveillantes, il faut répondre à de nombreuses questions. Heureusement, la réponse est toujours la même : L'anonymisation !

À qui puis-je donner accès dans mon entreprise ? À tous ceux qui le souhaitent, les données étant anonymisées.

Que se passe-t-il si des personnes non autorisées obtiennent l'accès au système de test ? Les données sont anonymisées.
Que dit le RGPD ?

" Lorsque le traitement est fondé sur une finalité autre que celle pour laquelle les données à caractère personnel ont été collectées [...], le responsable du traitement - afin de déterminer si le traitement pour une autre finalité est compatible avec celle pour laquelle les données à caractère personnel ont été initialement collectées - prend en compte, entre autres [...]
e) l'existence de garanties appropriées, qui peuvent inclure le cryptage ou la pseudonymisation".

RGPD Article 6, paragraphe 4, point e)

Il est bon de le savoir, car sinon de nombreux systèmes de test échoueraient probablement en raison de la condition suivante du RGPD :

"Le traitement n'est licite que si au moins une des conditions suivantes est remplie :
a) la personne concernée a donné son consentement au traitement des données à caractère personnel la concernant pour une ou plusieurs finalités déterminées ;"

RGPD Article 6, paragraphe 1, point a)

En effet, quelle que soit la raison pour laquelle les données ont été collectées, elles ne l'ont probablement pas été pour effectuer des tests. On pourrait peut-être demander l'autorisation à ses clients/fournisseurs, mais on récolterait probablement des regards irrités plutôt que des données.

Il est nettement plus simple de copier d'abord et d'anonymiser ensuite. Mais même une anonymisation raisonnable doit être réfléchie. La solution la plus simple serait d'insérer XXX partout. Mais on perd ainsi l'un des grands avantages de la copie de système, à savoir la proximité avec le système de production. Les contrôles de validité deviennent caducs et la clarté est perdue.

On obtient de bien meilleurs résultats en utilisant des "données réelles". Des adresses réelles, des numéros de carte de crédit avec des chiffres de contrôle valables et des noms "réels".

Nous avons maintenant un système actuel qui est certes un système de test, mais qui est aussi proche que possible du système de production. La copie et l'anonymisation vont donc de pair.

La combinaison parfaite de la copie du système et de l'anonymisation

C'est précisément pour ce cas de figure que Libelle propose deux solutions logicielles : Libelle SystemCopy (LSC) et Libelle DataMasking (LDM).

Avec Libelle SystemCopy, vous avez un partenaire de confiance à vos côtés.  Ce qui était auparavant une véritable tâche sisyphéenne devient un simple automatisme après une première configuration de LSC.

Pour l'anonymisation après la copie, nous proposons Libelle DataMasking. Grâce aux adresses réelles et aux noms authentiques, Libelle DataMasking vous permet de développer dans un environnement qui ressemble au système de production.

LSC et LDM peuvent également être utilisés de manière autonome, mais les deux programmes ne prennent toute leur dimension que dans la combinaison "Dreamteam". Dans ce cas, LDM peut être intégré très facilement dans le processus LSC. Chaque fois qu'une copie de système est effectuée avec succès avec LSC, LDM est automatiquement déclenché. Ainsi, votre environnement de test reste aussi proche de la réalité que possible sans faire de compromis sur la sécurité.

Vous souhaitez en savoir plus sur les thèmes de l'informatique ou les actualités du groupe Libelle IT ? Vous trouverez d'autres articles passionnants sur notre blog. Suivez-nous également sur LinkedIn.

Banner Libelle UserGroup
Vers tous les articles