Par tradition les systèmes opérationnels (ou transactionnels) qui sont une des sources de données principales pour l’alimentation des systèmes d’information (voir figure4.7), sont séparés au sens physique-
technique, ils sont par tradition hébergés sur des plate-formes informatiques ou serveurs physiques diffé- rents. En effet depuis des décennies les systèmes opérationnels exigent des qualités techniques différentes de celles des systèmes d’information. Ce sont principalement les aspects non fonctionnels de chacun qui sont traités de façon distincte.
Dans le cadre des systèmes opérationnels-transactionnels, les contraintes non fonctionnelles essentielles à traiter sont les suivantes :
— Haute disponibilité ; — Fiabilité ; — Temps réel ; — Sécurité- sensibilité ; — Volumétrie ; — Sauvegarde ; — Évolutive-montée en charge ; — Performance ; — Cryptage.
Les systèmes opérationnels nécessitent de focaliser leur puissance de calcul sur les opérations transactionnelles. Ces dernières gourmandes en disponibilité et rapidité d’exécution (temps réel) ne tolèrent pas la présence de données organisées de façon particulière, redondantes et surtout nécessitant des traitements de transformations très coûteux (les processus E.T.L, par exemple), pouvant pénaliser les performances des systèmes opérationnels.
Les systèmes d’information, lors de leur mise en place, étaient peu assujettis à des contraintes non fonctionnelles aussi fortes, ils ne nécessitaient donc pas les mêmes propriétés techniques que les systèmes opérants en terme de plate-forme technique.
C’est donc une séparation physique (et souvent une rupture technologique aussi) qui a été imposée aux systèmes d’information et les a "éloigné"» des systèmes opérationnels.
Les architectes d’information ont alors proposé non pas une cohabitation mais un éloignement de l’endroit où la donnée était produite pour construire les systèmes d’information.
Les notions d’ingestion, réplication, propagation, intégration sont alors apparues pour caractériser le flux entre l’endroit où la donnée était produite et celui où elle allait être utilisée.
Cependant la démocratisation d’accès à l’information avec de plus en plus d’utilisateurs des systèmes d’information et des données émises de plus en plus importantes et de formats très variés, imposent une évolution aux systèmes d’information actuels où désormais certaines des contraintes non fonctionnelles des systèmes opérationnels deviennent les leurs (voir chapitre 3). Notamment autour des paramètres suivants :
— L’augmentation de la "masse" de ces données disponibles, devient de plus en plus importante, et une solution basique comme augmenter simplement la capacité de stockage ne suffit plus à répondre à cette problématique.
— La notion de coût, les problématiques de réplication, d’ingestion, de gouvernance (copies multiples de données qui entraînent une baisse de la qualité des données, par exemple) mais aussi de limitation de capacité de stockage sont des paramètres qui sont désormais étudiés.
A ces nouvelles contraintes non fonctionnelles s’ajoute la notion de données sensibles, ne pouvant être aisément accessibles voire même déplaçables ou copiables.
Ces contraintes ont donc des impacts très forts sur la conception des systèmes d’information et peut limiter les choix de solutions possibles.
Dans le cadre des lacs de données, il semble que, unanimement du côté industriel et de la littérature scientifique, la séparation technique des systèmes émetteurs de données (dont le système opérant) et des lacs de données ait été adoptée comme postulat, et pratique usuelle de conception d’architecture. Une duplication, systématique, de toutes les données que l’on veut analyser et explorer est la stratégie d’organisation technique mise en œuvre dans les lacs de données. Le lac de données étant associé à la notion de réceptacle physique unique.
Le postulat est poussé très loin car ce réceptacle unique est toujours considéré par certains [17][22][75] comme étant une plate-forme Apache Hadoop. Ce qui simplifie ainsi la solution d’architecture ou de plate-forme technique pour les lacs de données.
En effet il y a une totale abstraction des paramètres d’architecture technique dans le choix des architectures applicatives des lacs de données qui sont tournés essentiellement autour des solutions incluant la technologie Apache Hadoop.
Russom [66] est le premier à envisager une hybridation de plusieurs technologies, Apache Hadoop restant tout de même la référence, ainsi que la duplication des données vers le lac de données.
Or nous pensons que la notion de gravité de la donnée n’est pas envisagée, voire même non prise en compte, dans la définition des architectures applicatives des lac de donnée et que l’approche de duplication et copie systématique de toutes les sources de donnée ne doit pas être l’approche de
référence.
Nous proposons d’étudier l’influence que peut apporter le gravité des données, si elle est prise en compte dans la conception des architectures des lacs de données.
Sur cette voie, nous nous sommes donc attachés à définir quels paramètres non fonctionnels sont pertinents dans les lacs de données et peuvent influencer la relation donnée-traitement.
Trois ont retenu notre attention : le volume (masse), le coût et la sensibilité :
— La « masse » de ces données disponibles devient de plus en plus importante, et une solution basique comme augmenter simplement la capacité de stockage ne suffit plus à répondre à cette problématique ;
— Le coût, lié aux problématiques de réplication, d’acquisition, de sécurité mais aussi d’extension de capacité de stockage doit être désormais évalué lors de la conception des architectures des lacs de données ;
— La sensibilité des données qui entraîne une gestion spécifique. S’il n’existe pas de définition légale pour les données dites sensibles, les nouvelles réglementations sur la donnée personnelle RGPD par exemple ou bien la cybersecurité, ou la Loi de Programmation Militaire étendent celle déjà délivrée par la CNIL. Chaque organisation peut, en plus de ces obligations de réglementation avoir sa propre classification de données dites sensibles.
Afin d’englober toutes ces notions autour de la sensibilité, nous définirons qu’une donnée est dite sensible au regard du degré de sécurité criticité/précaution que nécessitent son utilisation et son traitement. Cela va donc dépendre de l’évaluation par le propriétaire de ces données. Chacun est libre d’établir sa propre gradation. Cependant, quelques données sont naturellement plus sensibles que d’autres : les données clients, les données comptables et financières de l’entreprise, les données issues de la R&D etc.
Le niveau de sensibilité de ces données peut conduire à des accès limités, voire interdits rendant ainsi la donnée non déplaçable ou non duplicable. Les nouvelles régulations et diverses lois de conformité rendent en effet ces déplacements de données plus "lourds" car s’y ajoute aussi en plus de la sécurité, parfois l’anonymisation, l’encryptage mais aussi la traçabilité des déplacements et accès. Il est essentiel que chaque entreprise établisse la cartographie de ces données et en évalue le degré de criticité, pour en évaluer la réelle contrainte sur leurs déplacements.
Ces trois paramètres (volume, coûts, sensibilité) constituent des contraintes qui peuvent avoir des impacts très forts sur la conception des composants des systèmes d’information et peuvent réduire les choix d’architecture possibles voire remettre en cause un choix existant. Ces contraintes sont liées à
la donnée elle-même et nous proposons d’enrichir la vision des travaux de recherche précédents [3] et d’étendre le concept de gravité de la donnée en le fondant sur les paramètres masse-volume, sensibilité et coût.
Dans la section suivante nous étudions l’influence de la gravité des données sur les architectures des lacs de données.