« Nous ne devons pas utiliser de données en direct pour les tests. » C’est la raison pour laquelle la plupart des organisations commencent à chercher des solutions superficielles à certains défis ancrés dans leur ADN. Pendant des années, cette aversion a conduit les organisations à modifier leurs « meilleures » pratiques, luttant pour se sevrer d’habitudes profondément ancrées.
Ces organisations commencent souvent avec des fruits à portée de main et créent une capacité à remplacer les données en direct par des données masquées/obscurcies ou des alternatives synthétiques. Ils croient alors que c’est « travail fait! » Ce n’est pas le cas. Il ne résout ni ne réduit même bon nombre des principaux défis associés à l’utilisation de la production dans les tests, sans parler des problèmes systémiques qui ont conduit l’organisation à tester en utilisant les données de production en premier lieu.
Alors, pourquoi les équipes utilisent-elles des données en direct dans les tests ?
La plupart des équipes n’adoptent pas ce plan d’action étroit par choix ; l’utilisation des données de production est généralement née de la nécessité. Les données en direct copiées depuis le système de production sont considérées comme le seul moyen de comprendre le profil de nos clients, les règles commerciales dont nous avons perdu le contrôle et les données erronées que nous savons avoir en production mais que nous n’avons jamais eu le temps à remédier.
Dans le même temps, l’organisation exige que le changement (informatique) se produise maintenant. « Nos clients exigent la fonctionnalité x hier. » « Nous ne pouvons pas nous laisser distancer par nos concurrents. Ce sont toutes des préoccupations très valables.
Les données écrivent l’ADN de votre organisation – et ses risques de conformité
Pourtant, quand l’organisation s’arrête-t-elle pour faire le point et s’attaquer à la dette technique, en évaluant si le manège de sa façon de travailler et d’apporter des changements aggrave le risque que quelque chose ne tourne pas rond ?
Dans le cas des données, cela peut signifier une perte de données, un traitement incorrect des données ou un échec des migrations de données/systèmes. Il y a eu un certain nombre de cas largement rapportés au cours des dernières années où de tels problèmes se sont produits.
Devrions-nous vraiment être surpris, si notre système est antérieur à l’introduction du RGPD de l’UE, qu’il ne soit pas conforme à cette réglementation particulière ? Ou, à tout le moins, que nous aurions besoin de travailler pour démontrer que c’est le cas ?
Jusqu’où remonte votre problème de conformité ?
En termes de conformité au RGPD, posez-vous la question : avez-vous un modèle de données à jour et maintenu ? Et suivez-vous tous les flux de données dans votre organisation ? Avez-vous reculé et avez-vous rétrospectivement conçu et modifié vos systèmes pour vous assurer que vous pouviez démontrer la « sécurité des données dès la conception » ?
Plus précisément, avez-vous un dictionnaire de données ou similaire dans votre organisation qui cartographie toutes les données de votre organisation et les classe par rapport aux PII, PSI ou même PCI si vous allez au-delà du RGPD ?
Toutes ces exigences sont une tâche ardue pour les équipes de changement à saisir, et encore moins à résoudre, en plus des exigences commerciales liées à la mise en place de la prochaine fonctionnalité dans la nature.
Pouvez-vous réécrire l’ADN de votre organisation ?
Les données pénètrent dans tous les aspects d’une organisation et de ses pratiques de travail. Lorsque ces données sont des données en direct, les défis du contrôle et de la suppression ultérieure de ces données doivent être sérieusement pris en compte.
Le diagramme « nœud papillon » ci-dessous est une technique utilisée dans le travail sur les risques pour visualiser et articuler les faiblesses de contrôle complexes et causales qui existent probablement dans votre organisation.
Ce diagramme indique les types de causes antérieures et les risques d’entraînement généralement associés à l’utilisation de données en direct. La dernière « cause » avant l’événement dévastateur de non-conformité réside dans la décision d’autoriser l’utilisation de données en direct dans des environnements de non-production.
Bien que souvent décidées projet par projet, ces décisions sont généralement thématiques. Ils reflètent un modèle de comportement dans lequel la direction autorise des actions qu’elle perçoit comme sans conséquence, créant une «pente glissante» dans laquelle les risques s’accumulent au fil du temps.
Il ne faut alors qu’un seul risque supplémentaire pour échouer, provoquant un événement catastrophique. Une décision, dans un projet dans une partie de l’organisation, aurait pu permettre l’utilisation de données en direct pour accélérer la livraison d’un projet. Cette décision a été prise pour atteindre une date qui n’était pas vraiment nécessaire, alors que les contrôles d’accès étaient compromis lorsque les personnes se déplaçaient de manière transitoire autour des projets.
Figure 1 – Un diagramme en nœud papillon montrant les causes systémiques conduisant à un « événement » catastrophique de violation de données.
Avec un accès lâche à divers systèmes et une faible culture de rétention des experts en gestion des données, les méthodes de travail et le mouvement des données deviennent une boule de boue organique. Cette balle grossit avec le temps. Cela ne s’arrêtera que si vous reconnaissez ces événements de porte coulissante et prenez des mesures pour les résoudre, en les empêchant de se chevaucher.
Diagnostiquer les problèmes derrière la gestion des données à risque
Alors que peux-tu faire? Les premières étapes seraient de reconnaître le problème, peut-être utiliser le nœud papillon ci-dessus pour reconnaître ces événements qui se produisent dans votre organisation. Voir les impacts potentiels des décisions risquées aide à cristalliser leur importance pour les dirigeants, en particulier s’ils sont les principaux preneurs de risques au sein de votre organisation. Cela peut inclure le délégué à la protection des données (DPD), un rôle requis par le RGPD pour de nombreuses organisations.
Ensuite, comprenez le contexte du défi spécifique dans votre organisation et pourquoi il se produit. Cela vous permettra d’accéder à l’itinéraire du problème. N’oubliez pas que la plupart du temps, lorsqu’une équipe utilise des données en direct, les données en direct elles-mêmes sont un symptôme du problème racine.
Tout comme les problèmes individuels ont convergé au fil du temps pour créer votre grosse boule de boue, la résolution du problème doit commencer par diverger les problèmes. Vous devez séparer les défis et travailler sur des solutions. L’isolement est essentiel et doit être repris par les meilleures pratiques d’architecture (comme le couplage lâche) et les contrôles (comme RBAC).
En ce qui concerne les données et les flux de données, une grande partie du découplage des problèmes se résume à l’analyse. En termes simples, vous connaissez des inconnues et devez effectuer une analyse pour en prendre conscience. Cela implique de prendre connaissance des données au sein d’un système, de sa classification de sensibilité et de savoir si elles devraient s’y trouver. Vous devez également savoir dans quels systèmes ces données circuleront également et où ces données sont incorrectes.
Technologie Peut Aider
Ce n’est pas un problème qui peut être résolu en un jour, et il n’y a pas de solution miracle pour l’IA. Il vous a probablement fallu des années pour accumuler cette dette en spirale et, comme toute personne aux prises avec des dettes, vous devez mettre en place un plan de remboursement.
Technologie peut aider. Vous avez presque certainement de nombreuses sources d’information inexploitées où une version de la vérité existe. Cela peut inclure la production, la documentation obsolète et les nombreuses compréhensions différentes dans la tête de différentes personnes. Les outils d’analyse de données, les capacités de ML et la modélisation peuvent commencer à dresser un tableau de ces versions disparates de la vérité.
Au fur et à mesure que ces images mûrissent et grandissent, vous convergez vers une version unique de cette vérité, décrivant comment le système devrait réellement fonctionner. Vous serez surpris que la production ne fonctionne pas comme vous le pensez.
L’efficacité de l’apprentissage résout plus que les risques de conformité
À ce stade, vous disposez d’une spécification vivante, ou d’un système de gestion des données de référence, pour l’organisation. Vous disposez désormais d’un contrôle central pour une grande partie du sujet des données au sein de votre organisation, même lorsque vous avez des équipes fédérées et probablement cloisonnées. Vous prenez enfin les données au sérieux.
La réglementation à ce stade n’est pas un obstacle; c’est un accélérateur. L’approche structurée et réfléchie accélère notre capacité à livrer – aller plus lentement pour aller plus vite est vraiment vrai !
Figure 2 – Une capacité de données dédiée pour servir les équipes de développement fédérées.
La base de la livraison agile (et DevOps) est une livraison itérative de petite taille. Faire face à ce problème avec les données est à son tour essentiel si votre organisation souhaite sérieusement aller plus loin dans la mise en œuvre de l’agilité. Sinon, vous faites probablement de l’agilité dans un silo et vous heurtez inévitablement à la grosse boule de boue avec laquelle le reste de l’organisation se débat.
Un parcours évolutif intéressant consiste à faire face culturellement à ces défis et à les utiliser comme des opportunités pour transformer votre équipe / organisation en une équipe efficace et efficace dans l’apprentissage. Les données contextuelles sont devenues des connaissances qui prolifèrent au-delà des frontières de l’équipe – bien plus qu’un moyen d’éliminer les informations sensibles de la non-production.
Figure 3 – Les données contextuelles deviennent des connaissances et réduisent le chaos au sein d’une organisation.