UE5 - DSCG - 202324 - Thème5 - Architecture technique + annexes (1).pdf

UE5 - MSI – DSCG – Thème 5 – Architecture technique UE 5 – MANAGEMENT DES SYSTÈMES D’INFORMATION Thème 5 – Architecture et sécurité des systèmes d’information Architecture technique...

UE5 - MSI – DSCG – Thème 5 – Architecture technique UE 5 – MANAGEMENT DES SYSTÈMES D’INFORMATION Thème 5 – Architecture et sécurité des systèmes d’information Architecture technique I. Les composants des architectures II. Les architectures de réseau techniques A. Organisation des réseaux locaux A. Architecture du SI 1) Le réseau local 1. Cartographie du SI 2) L'architecture client-serveur 2. Architecture matérielle 3) Architecture SOA 3. Architecture logicielle 4) Logiciel médiateur 5) Les serveurs 6) SE et virtualisation B. Structures types de déploiement 1) Le système transactionnel 2) Le système décisionnel 3) Le portail 4) L'informatique en nuage 5) La Blockchain Sens et portée de l'étude Compétences visées Notions et contenus Être capable d’identifier les Caractériser l’architecture Les principales architectures principales architectures technique d’une techniques (client-serveur, techniques organisation. médiateur (middleware), transactionnel, intégration, Accompagner une démarche portail) de choix et de déploiement d’une architecture technique. Aurore VERDIS page 1 UE5 - MSI – DSCG – Thème 5 – Architecture technique I. Les composants des architectures techniques A. Architecture du SI 1) Cartographie du SI Le CIGREF, association créée en 1970 qui réunit un réseau de grandes entreprises et d'administrations publiques françaises dans l'objectif de réussir à intégrer et maîtriser le numérique, propose un modèle de l'architecture du SI en 4 couches : L'architecture métier : définition des processus métiers ; L'architecture fonctionnelle : déclinaison des processus métiers en besoins fonctionnels ; L'architecture applicative : ensemble des applications ou logiciels qui répondent aux besoins fonctionnels ; L'architecture technique : ensemble des moyens techniques mis en place nécessaire au fonctionnement des applications. Cela englobe notamment les solutions techniques d'accès (smartphone, ordinateur de bureau, tablettes, serveurs, etc.) et également les intergiciels ou logiciels médiateurs (en anglais, middleware) utiles pour l'interopérabilité des applications. Pour aller plus loin : ANSSI - Cartographie (consulté le 30/10/2023) - Annexe 1 CIGREF - Cartographie (consulté le 30/10/2023) - Annexe 2 Aurore VERDIS page 2 UE5 - MSI – DSCG – Thème 5 – Architecture technique 2) Architecture matérielle L'architecture matérielle peut être représentée selon le modèle de Von Neumann. Toutes les solutions techniques d'accès (STA) disposent de la même architecture matérielle avec des références de tailles et de performances différentes. - un dispositif d'entrée-sortie pour répondre au besoin de collecte et de diffusion de l'information ; - une mémoire pour le stockage des données : - une unité arithmétique et logique pour répondre au besoin de traitement de l'information ; - un dispositif de séquençage, l'unité de contrôle, pour ordonner le flux de données vers l'unité de traitement. Pour aller plus loin : Interstices - Le modèle de Von Neumann (consulté le 30/10/2023) - Annexe 3 Aurore VERDIS page 3 UE5 - MSI – DSCG – Thème 5 – Architecture technique 3) Architecture logicielle Un logiciel est un ensemble cohérent de programmes qui répond à des besoins fonctionnels. Un programme informatique est un ensemble d'instructions composées de chaînes de 0 et 1 exécuté par un ordinateur. Langages de programmation : Java, le langage C, le C#, le PHP ou encore le Python. L'architecture logicielle ou software architecture, décrit les éléments d'un ou plusieurs systèmes informatiques, leurs interrelations et leurs interactions. L'architecture logicielle ou software design, est une construction schématique des différents éléments qui constituent une application. Modèle en couche : - la couche présentation représentée par l'interface utilisateur qui permet de contrôler la saisie des données, - la couche de traitement comprenant les programmes qui répondent aux besoins métiers, - la couche d'accès aux données permet l'accès aux données contenues dans une base de données commune pour l'ensemble des utilisateurs. Pour aller plus loin : Le MAG IT - Guide architectures applicatives (consulté le 30/10/2023) Aurore VERDIS page 4 UE5 - MSI – DSCG – Thème 5 – Architecture technique II. Les architectures de réseau A. Organisation des réseaux locaux 1) Le réseau local L'architecture technique est une organisation logique de la circulation de l'information dans l'entreprise sur laquelle doivent reposer les applications. Cette organisation logique est concrétisée par l'utilisation de matériels informatiques, de systèmes d'exploitation, de logiciels médiateurs ou intergiciels (en anglais, middleware) et de réseaux de télécommunication pour faciliter la circulation des données entre tous ces éléments. Un réseau local (LAN : local area network) est un ensemble d'équipements interconnectés dont objectif est d'échanger des données sur une zone géographique limitée, de l'ordre du kilomètre. Le modèle OSI (Open Systems lnterconnection) normalise la communication sur les réseaux. Le réseau comporte des STA : un ou plusieurs serveurs, des stations de travail, des périphériques et un système de liaison par câbles ou ondes électromagnétiques. Pour aller plus loin : FRAME IP - Modèle OSI (consulté le 30/10/2023) CISCO - Modèles TCP/IP et OSI (consulté le 30/10/2023) - Annexe 4 Aurore VERDIS page 5 UE5 - MSI – DSCG – Thème 5 – Architecture technique 2) L'architecture client-serveur Dans une architecture client-serveur, une application cliente effectue une requête (demande) de service auprès du serveur pour initier une session de communication puis, une application serveur répond à la demande de service. L'architecture matérielle d'une machine cliente et d'un serveur est identique mais un serveur disposera de composants plus performants et redondants afin d'assurer une continuité de service et pouvoir répondre à de multiples requêtes des utilisateurs. - une architecture pair à pair (en anglais, peer-to-peer) ou les deux machines face à face ont à la fois le rôle de client mais également de serveur ; - une architecture 1-tier ou ordinateur central (en anglais, mainframe) se caractérise par une prise en charge par un serveur unique de l'intégralité des traitements et de l'affichage qui peut être reproduit sur des terminaux passifs ; - une architecture 2-tiers qui représente la notion de client-serveur avec une machine cliente qui exécute de requêtes en direction d'une machine serveur contenant les services attendus ; - une architecture 3-tiers qui respecte la décomposition des couches applicatives par l'utilisation d'une machine cliente pour la couche présentation, un serveur d'applications (appelé également middleware) pour la partie traitements et un serveur de données qui assure le stockage et la cohérence des données pour un meilleur accès de la part de la couche applicative ; - une architecture n-tiers permet de multiplier le nombre de serveurs à chaque couche de l'architecture logicielle pour répartir la charge de traitement. Pour aller plus loin : GEONOV - Client-Serveur (consulté le 30/10/2023) Aurore VERDIS page 6 UE5 - MSI – DSCG – Thème 5 – Architecture technique 3) Architecture SOA L'architecture SOA (Service Oriented Architecture ou en français, Architecture Orientée Services) est une architecture basée sur un ensemble de services simples. L'un des objectifs de cette architecture est de décomposer une fonctionnalité attendue en de multiples fonctions appelées services. Un schéma global doit présenter les interactions possibles entre ses services. L'un des protocoles utilisés pour l'invocation d'un service par le poste client est le SOAP (Simple Object Access Protocol). Pour déterminer un composant service il doit répondre à trois caractéristiques IRA (Interesting, Reusable et Atomic) : - Intéressant : le service doit être intéressant pour répondre à la fonctionnalité attendue mais également pour d'autres services ; - Réutilisable : le service doit pouvoir être réutilisé dans des contextes différents et non pas lié à un seul processus ; - Atomique : le service doit être indivisible et le plus élémentaire possible. Exemple : Dans le cadre d'une architecture SOA pour un PGI, il peut être intéressant de disposer d'un service exclusivement spécialisé dans la préparation d'un fichier journal. Celui-ci pourra être utilisé pour la traçabilité des actions réalisées par un utilisateur. Pour aller plus loin : Urbanisation SI - SOA (consulté le 30/10/2023) LeMagIT - SOA (consulté le 30/10/2023) – Annexe 5 Aurore VERDIS page 7 UE5 - MSI – DSCG – Thème 5 – Architecture technique 4) Logiciel médiateur Un logiciel médiateur (middleware) est un logiciel qui permet le fonctionnement de plusieurs ordinateurs en coordination, en attribuant à chacun une tâche spécifique, comme les échanges avec les utilisateurs, l'accès aux bases de données ou aux réseaux. Journal officiel du 16/03/1999 Le terme middleware, traduit en français par logiciel médiateur ou intergiciel, provient de la contraction entre les mots middle (milieu) et software (logiciel). Il s'agit d'un logiciel permettant la mise en relation de deux applications informatiques. Son but premier est de faciliter les échanges d'informations entre ces deux applications, qui peuvent alors interagir et coopérer. Avec le middleware, il n'est pas nécessaire que les deux applications se trouvent sur un même réseau pour pouvoir communiquer. De la même manière, ces applications n'ont pas non plus l'obligation de partager le même système d'exploitation, ni le même protocole réseau. Exemple : - Le logiciel médiateur ODBC (Open DataBase Connectivity), développé par Microsoft pour les systèmes d'exploitation Windows, permet de manipuler plusieurs bases de données qui peuvent être disposées sur des systèmes de gestion de bases de données (SGBD) différents. - Trois middlewares ou intergiciels majeurs : CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model) et RMI (Remote Method Invocation). Pour aller plus loin : JDN - Middleware (consulté le 30/10/2023) Aurore VERDIS page 8 UE5 - MSI – DSCG – Thème 5 – Architecture technique 5) Les serveurs Les serveurs peuvent mettre à disposition une grande variété de services en fonction des besoins des utilisateurs : - serveur de messagerie électronique ; - serveur web pour l'hébergement d'application web ; - serveur de fichier ; - serveur d'annuaire pour l'identification des utilisateurs et la reconnaissance de leurs droits sur le réseau ; - serveur de base de données : stockage et organisation des données, mécanismes d'accès et de sécurité ; - serveur DHCP ; - serveur DNS ; - serveur proxy ; - etc. Pour aller plus loin : Culture informatique - Serveurs (consulté le 30/10/2023) Aurore VERDIS page 9 UE5 - MSI – DSCG – Thème 5 – Architecture technique 6) SE et virtualisation Un système d'exploitation ou Operating System (OS), est un logiciel qui pilote les dispositifs matériels (processeurs, mémoire, périphériques) et reçoit des instructions de l'utilisateur ou d'autres applications. Ces logiciels doivent être adaptés au système d'exploitation. La virtualisation est l’ensemble des techniques matérielles et/ou logicielles qui permettent de faire fonctionner sur une seule machine plusieurs systèmes d’exploitation et/ou plusieurs applications, séparément les uns des autres, comme s’ils fonctionnaient sur des machines physiques distinctes. La virtualisation système consiste à positionner un logiciel, appelé hyperviseur : - architecture reposant sur un hyperviseur de type 1 : l'hyperviseur est un système d'exploitation léger qui va servir de relais entre les appels en ressources matérielles des systèmes d'exploitation virtualisés pour chaque machine virtuelle et le matériel de la machine hôte sur laquelle est installé l'hyperviseur. Exemple : VMware vSphere (propriétaire), Microsoft Hyper-V Server (propriétaire) ou encore Citrix Xen Server (libre). - architecture reposant sur un hyperviseur de type : un logiciel émulateur est installé sur le système d'exploitation de la machine hôte qui servira de relais entre les systèmes d'exploitation des machines virtuelles et le système d'exploitation de la machine hôte. Exemple : Oracle VM VirtualBox (libre), Microsoft VirtualPC (propriétaire) et VMware Workstation (propriétaire). La virtualisation applicative permet d'isoler des applications sur un même système d'exploitation. Dans cette architecture les applications vont faire seulement appel à des ressources logicielles du système d'exploitation hôte. Les avantages sont de bénéficier de la portabilité des applications vers des systèmes d'exploitation différents et de bénéficier du principe d'images ainsi que de celui de sauvegardes liées à la virtualisation. Exemple : Docker avec son principe de conteneurisation ou d'isolation des applications. Pour aller plus loin : Le monde informatique - Virtualisation serveurs (consulté le 30/10/2023) – Annexe 6 ULB - La virtualisation (en pdf) ITSocial - Virtualisation (consulté le 30/10/2023) Aurore VERDIS page 10 UE5 - MSI – DSCG – Thème 5 – Architecture technique B. Structures types de déploiement 1) Le système transactionnel Un système transactionnel s'utilise dans les contextes où des transactions - financières, administratives, commerciales, etc. - entre deux ou plusieurs parties doivent être traitées en temps réel, et où il est impératif que chaque transaction entraîne toutes les mises à jour de base de données nécessaires. Par exemple, dans le cas d'un service automatisé de réservation de billets d'avion, il est indispensable que la réservation d'un client effectuée sur site Internet provoque tous les enregistrements utiles ; de plus, dans ces applications transactionnelles, le système doit être capable de traiter correctement de nombreuses demandes simultanées. Un système transactionnel doit donc mettre en œuvre des stratégies particulièrement poussées de traitement des pointes de charge, des incidents possibles, des demandes simultanées d'écriture, tout en prenant toutes les mesures possibles pour préserver à tout moment la cohérence de la base de données. Modèle même de l'application "cruciale" pour l'entreprise, le système transactionnel doit également mettre en œuvre les meilleures parades possibles en cas de désastre informatique, avec en tout premier lieu des procédures prédéfinies de rollback, c'est-à-dire de retour en arrière, à un état connu et cohérent de la base de données, avec annulation des dernières transactions. Un système transactionnel doit garantir la fiabilité d'une transaction en vérifiant ses propriétés ACID (Atomicité, cohérence, isolation et durabilité) : - Atomicité : la transaction se fait au complet ou pas du tout : si une partie d'une transaction ne peut être faite, il faut effacer toute trace de la transaction et remettre les données dans l'état où elles étaient avant la transaction. - Cohérence : la cohérence assure que les modifications apportées à la base de données suite à une transaction sont en respect avec les contraintes d'intégrité du schéma relationnel. Il ne faut pas que l'intégrité des données soit mise en doute. Dans le cas contraire, la transaction doit être refusée. - Isolation : les transactions ne doivent pas être dépendantes les unes des autres. Ainsi, une requête réalisée pour une transaction ne doit pas interférer sur les données d'une autre transaction. - Durabilité : les transactions sont enregistrées de façon définitive. En cas de panne du serveur de base de données pendant une transaction, le fichier journal doit permettre de finaliser les modifications de la base en rapport avec cette transaction. Exemple : Le progiciel de gestion intégré est exemple d'outil transactionnel qui apporte une réponse standard (enregistrement de facture, suivis de stocks, gestion des immobilisations, etc.) et qui demande un paramétrage spécifique par rapport aux besoins liés au métier de l'entreprise. Pour aller plus loin : ARXIV - Gestion transactionnelle (consulté le 30/10/2023) - Annexe 7 Flag system - GDS (consulté le 30/10/2023) Aurore VERDIS page 11 UE5 - MSI – DSCG – Thème 5 – Architecture technique 2) Le système décisionnel Le système décisionnel ou informatique décisionnelle (en anglais, business intelligence) permet d'agréger une quantité importante de données générées par le système transactionnel afin de bénéficier d'informations stratégiques compréhensibles et utiles aux décideurs. Il réalise pour cela une analyse intelligente des informations sélectionnées pour leur valeur stratégique : - le reporting qui permet d'éditer des rapports réguliers sur l'évolution d'indicateurs calculés à partir des données agrégées : tableaux de bord, analyses multidimensionnelles type OLAP (OnLine Analytical Processing ou en français, Traitement Analytique en Ligne) qui donnent la possibilité d'analyser des informations suivant plusieurs axes ; - l'analyse des données qui s'inscrit dans l'analyse statistique pour déterminer des corrélations et réaliser des analyses descriptives et prédictives (Datamining) ; - l'exploitation de données directement par le décideur via des interfaces qui facilitent la visualisation de données stratégiques. - l'ETL (extraction et traitement des données) est un logiciel médiateur qui permet d'extraire des données du système transactionnel, qui peut être composé de sources d'information très différentes, pour alimenter le modèle de données du data warehouse ; - le data warehouse (en français, entrepôt de données) est une base de données construite à partir des données du système transactionnel est qui peut être utilisée par les applications décisionnelles ; - le data mart (en français, magasin de données) est une extraction des données du data warehouse pour créer un sous-ensemble homogène de données (généralement en référence à un métier ou un domaine précis) exploitable plus facilement par l'application décisionnelle. Pour aller plus loin : JDN - Data lake (consulté le 30/10/2023) - Annexe 8 COMPTA ONLINE - Jedatviz (consulté le 30/10/2023) Aurore VERDIS page 12 UE5 - MSI – DSCG – Thème 5 – Architecture technique 3) Le portail Un portail est « un site conçu pour être le point d'entrée sur internet et proposant aux utilisateurs de services thématiques et personnalisés. » (Définition du dictionnaire Larousse) Un portail intranet peut être mis en place pour accéder à des services et contenus disponibles sur le réseau local d'une entreprise via une authentification unique de type SSO (Single Sign-On). Il est constitué d'une interface utilisateur personnalisée suivant ses besoins. Un portail extranet peut également être paramétré pour faciliter l'accès des partenaires (clients, fournisseurs, etc.) à des ressources situées sur le réseau intranet de l'entreprise via une authentification. Le portail captif est utilisé par les organisations pour permettre aux utilisateurs d'accéder à des pages web hébergées sur internet après une authentification obligatoire. Le portail captif fournit un historique des connexions pour assurer une traçabilité rendue obligatoire par la législation. Pour aller plus loin : Ordre des experts-comptables - Conseil national (consulté le 30/10/2023) Aurore VERDIS page 13 UE5 - MSI – DSCG – Thème 5 – Architecture technique 4) L'informatique en nuage Cloud computing = 5 caractéristiques essentielles, 3 niveaux de services, 4 modèles de déploiement. Selon le NIST (National Institute for Standards and Technology), le cloud computing doit posséder 5 caractéristiques essentielles : - Le service doit être en libre-service à la demande - Il doit être accessible sur l’ensemble d’un réseau - Il doit y avoir une mutualisation des ressources - Il doit être rapidement élastique (adaptation rapide à une variation du besoin) - Le service doit être mesurable (mesure et affichage de paramètres de consommation) Le NIST distingue 3 niveaux de service : - Le logiciel en tant que service (Software as a Service - SaaS) : par exemple une banque "loue" un logiciel de comptabilité, en ligne, à la demande, chez un prestataire externe ; - La plateforme en tant que service (PaaS) : une solution externe qui propose une suite logicielle et les outils d’intégration et de suivi ; Par exemple, un serveur web (Linux+Apache+MySQL+Php) ; - L’infrastructure en tant que service (IaaS) : la totalité de l’infrastructure (ressources matérielles) est externe. Par exemple, capacité de stockage et capacité de calcul à la demande sur un réseau. Et 4 modèles de déploiement : - Le nuage privé (au sein d’une même organisation) - Le nuage communautaire (réservé à une communauté) - Le nuage public (ouvert au grand public) - Le nuage hybride (composition de deux ou plusieurs types de nuages) Pour aller plus loin : Wavestone - Cloud computing : les cas d’usage de demain (consulté le 30/10/2023) Lesnumeriques - Le cloud en France (consulté le 30/10/2023) - Annexe 9 Aurore VERDIS page 14 UE5 - MSI – DSCG – Thème 5 – Architecture technique 5) La Blockchain La blockchain est une technologie de stockage et de transmission d’informations, transparente, sécurisée, et fonctionnant sans organe central de contrôle. Elle constitue une base de données qui contient l’historique de tous les échanges effectués entre ses utilisateurs depuis sa création, sécurisée et distribuée : elle est partagée par ses différents utilisateurs, sans intermédiaire, ce qui permet à chacun de vérifier la validité de la chaîne. Il existe des blockchains publiques, ouvertes à tous, et des blockchains privées, dont l’accès et l’utilisation sont limitées à un certain nombre d’acteurs. Une blockchain publique peut donc être assimilée à un grand livre comptable public, anonyme et infalsifiable. Comme l’écrit le mathématicien Jean-Paul Delahaye, il faut s’imaginer « un très grand cahier, que tout le monde peut lire librement et gratuitement, sur lequel tout le monde peut écrire, mais qui est impossible à effacer et indestructible." (CNIL) Pour aller plus loin : JDN - Blockchain (consulté le 30/10/2023) CNIL - Blockchain (consulté le 30/10/2023) - Annexe 10 Aurore VERDIS page 15 Data lake (ou lac de données) : la solution reine du big data Le Journal du Net 15/05/18 Taillé pour le big data, un lac de données, ou data lake, est dessiné pour casser les silos des systèmes d'information d'entreprise. C'est aussi un moyen de gagner en agilité. SOMMAIRE Définition de data lake Différence avec un datawarehouse Atouts d'un data lake Usages d'un data lake Solutions techniques du data lake Socle technique d'un data lake L'émergence du concept de data lake s'est accélérée grâce avec la convergence du besoin de plateformes fédératrices dans les entreprises et de nouveaux moyens techniques économiques apportés par les technologies de big data. Cet article de référence a été réalisé avec l'aide de l'expert Vincent Heuschling. Qu’est-ce qu’un data lake ? (définition) Concept lié à la mouvance du big data, le lac de données (ou data lake en anglais) désigne un espace de stockage global des informations présentes au sein d'une organisation. Il s’agit de le faire avec suffisamment de flexibilité pour interagir avec les données, qu’elles soient brutes ou très raffinées. L’une des clés de cette flexibilité est l’absence de schéma strict imposé aux flux entrants. Cette faculté permet d’insérer toutes les données, quelles que soient leur nature et leur origine. Au-delà du stockage, l’un des enjeux du data lake est de pouvoir très facilement traiter et transformer l’information afin d’accélérer les cycles d’innovation, et ainsi être un support aux différentes initiatives data. En quoi est-ce différent d'un datawarehouse ? La tentation est très souvent forte d’apparenter le data lake à un classique datawarehouse, mais les différences entre les deux sont importantes, et ceci sur plusieurs plans. Le data lake a vocation à absorber des flux de données bruts et à les rendre utilisables en les transformant pour satisfaire différents besoins d’analyse. Ceci reste finalement extrêmement classique et n’apporte rien de nouveau à ce que le trio "ETL - datawarehouse - datamart" pouvait faire. Cette nouvelle approche est cependant différente en ce sens qu’elle permet de charger les données et de les transformer ensuite pour les rendre exploitables. Les initiatives autour de la data sont très souvent limitées par les difficultés inhérentes aux phases de collecte et d’ingestion dans les systèmes. Sur ce point, le fait de pouvoir charger les données sur une plateforme dans un état quasiment brut, et d’itérer rapidement pour les utiliser est un avantage indéniable. On parle souvent d’ailleurs d’une démarche d’ELT (Extract-Load-Transform) plutôt que d’ETL (Extract-Transform-Load) à laquelle nous étions habitués. Là où un datawarehouse pousse les données de leurs origines vers leurs consommateurs selon un chemin relativement fixe où chaque datamart est sensé satisfaire un besoin, on a ici une bien plus grande flexibilité. C’est en effet à chaque consommateur de matérialiser son besoin et d’extraire les différentes données sources puis de les combiner pour en faire du sens. L'analyse de données devient opérationnelle Un autre facteur différenciant le data lake vis-à-vis de son ancêtre réside dans le coté opérationnel qui peut lui être associé. La capacité d’ingestion de flux en temps réel et de réaction aux données autorise des applications a interagir directement dessus. On dépasse ici l’aspect Business Intelligence du datawarehouse, la création de valeur n’étant plus uniquement dans l’utilisation des données à des fins de reporting. Quels sont les atouts d'un data lake ? Le fait de ne pas imposer de schéma strict aux données lors de leur ingestion présente un évident risque de qualité et de fiabilité. Dans les faits, on constate que les données restent finalement non structurées assez peu longtemps, puisqu’elles passent rapidement dans un pipeline qui va permettre de normaliser les sources et de les cataloguer pour obtenir des meta-données. La gouvernance apparaît alors comme l’un des enjeux majeurs du bon fonctionnement d’un data lake. La structuration des données dans un datawarehouse impose aux analystes d’utiliser les données au travers du formalisme rigide conçu à l’origine de celui-ci. La transformation au chargement des données, si elle est structurante, est aussi destructrice des détails, du fait des agrégations nécessaires. L’approche de "Schema On Read" qui n’applique une structure aux données que lorsqu’elles sont utilisées permet de garder tout le potentiel des données d’origine intact. Cet aspect nécessite par contre des compétences et des outils bien plus techniques qu’auparavant afin d’exploiter les données. Le machine learning pour constituer des modèles prédictifs Le data lake est très souvent basé sur des technologies qui permettent le traitement in-situ des données. Le fait de disposer de puissance de calcul directement associée au stockage permet de raffiner un flux de données, et ainsi de facilement en créer les déclinaisons métier attendues. La richesse des outillages intégrés permettent à des analystes, des data-scientistes, ou des développeurs de tirer parti des données et de rapidement construire des scénarios analytiques ou des applications. On y associe aussi très souvent des processus de machine learning qui ont vocation à exploiter toutes les données pour constituer des modèles prédictifs. La capacité de ceux-ci à être appliqués aux flux entrants apporte une dimension très proactive à ce type de plateforme vis-à-vis de la donnée. Quels sont les usages du data lake ? D’une manière générale, de nombreux data lake voient le jour par des projets de remplacement et d’amélioration des infrastructures data existantes. Les organisations sont motivées par le besoin d’améliorer leur utilisation des données, de centraliser toutes les sources en un seul point et d’accélérer les cycles d’innovation. Les secteurs du marketing et des médias ont été évidement les premiers à saisir cette opportunité, bien avant que le terme de data lake ne popularise cette pratique. Le data lake permet par exemple de collecter et analyser les données d'interactions clients Dans une démarche de DMP, Data Management Platform, le data lake permet de collecter toutes les données issues des interactions avec les clients, de raffiner celles-ci pour offrir une vision à 360° sur les clients. Très souvent, ces projets ont vocation à appliquer sur ces données des algorithmes de segmentation, ou de prédiction pour anticiper les comportements des consommateurs. Ils mettent aussi en avant les capacités à assembler et valoriser une grande variété de données. Cependant, ces chantiers étaient encore très centrés sur les données du digital, des ventes et leur usage marketing. On a vu plus récemment des projets dans le secteur industriel ayant pour objet de collecter toutes les sources de données liées à des environnements de fabrication, mais aussi à l’usage fait des produits, pour au final fiabiliser et optimiser ceux-ci. La capacité de collecte massive et les volumes d’informations produites à l’ère de l’Internet of Things amènent de nouveaux champs d’application pour ces outils, permettant d’appréhender des masses importantes de données, et de systématiser l’utilisation de machine learning à grande échelle. Quid des solutions techniques clés dans ce domaine ? Si Hadoop apparaît comme une évidence pour construire un data lake d’ampleur, il serait assez réducteur de penser qu’il soit l’unique solution à implémenter. Absorber d’importants volumes d’informations, et les traiter est un emploi sur mesure pour le petit éléphant jaune. Les sponsors d’Hadoop ne s’y trompent pas et leurs communications sont très orientées sur les bonnes pratiques pour implémenter la plate-forme data globale de l'entreprise. Néanmoins, les challenges à relever sont non seulement dans le stockage et le traitement des données, mais aussi dans les besoins périphériques comme la visualisation, la data-science, la gouvernance des données, et les capacités de traitement en temps réel. De ce fait aujourd’hui, on trouve des possibilités, avec Kafka, Storm ou Spark-Streaming, d’apporter des traitements à la volée sur les informations collectées avant même de les engranger dans le data lake. En plus d’amasser et de traiter des données en masse, il est assez tentant de donner une dimension opérationnelle à ces data lake. Cette extension de l’usage nécessite alors de pouvoir utiliser les données avec des applications modifiant celles-ci. Sans rejoindre les usages des SGBDR classiques, on peut stocker les profils utilisateurs et avoir des applications qui interagissent avec ces profils pour améliorer l’expérience des usagers pendant leurs consultations des sites web. En complément d’Hadoop, une base NoSQL comme Cassandra permet d’utiliser les données de manière interactive, et d’apporter consistance et haute disponibilité. Quel socle choisir lors de la mise en œuvre d'un data lake ? Dans la construction d’un data lake, le cloud est assurément la meilleure option, car elle permet de provisionner à la demande les ressources pour faire croître l’infrastructure au fur et à mesure des besoins. L'élasticité est aussi un facteur d’accélération de l’innovation autour des données, et permet par exemple de traiter ponctuellement en marge de la production un historique de données pour valider un nouvel algorithme. Le coût d’une telle approche est sans commune mesure avec ce qu’il faudrait mettre en place dans un déploiement "on-premise" pour arriver au même résultat. L’intérêt de bâtir un data lake dans le cloud n’est pas qu’économique, il faut aussi tenir compte de la richesse de composants qu’on trouve dans les offres de fournisseurs comme Google Cloud Platform ou Microsoft Azure. Ceux-ci permettent avec leurs offres PaaS d’offrir des composants très riches pour développer des applications, et des API interagissant avec la donnée. Face à l’ampleur du chantier que représente un data lake, le Cloud permet d’avoir une approche graduelle, et de faire appel à un service managé pour produire et exploiter cet environnement. L’expert : Vincent Heuschling est le fondateur et CEO d'Affini-Tech. Il intervient chez ses clients pour imaginer leurs stratégies big data, réaliser leurs premières expériences et construire leurs plateformes. Ingénieur de formation, il a été responsable informatique, consultant, puis commercial, avant de revenir à la technique et d'entreprendre dans le secteur des big data. Le cloud, un marché d'envergure à capter pour la France et l'Europe Par Patrick Randall (@patricknrandall) Publié le 24/05/21 à 11h00 Richard Newstead - Le marché européen du cloud a progressé de 27 % par an entre 2017 et 2019. D'ici à 2030, la croissance du marché européen du cloud devrait monter en flèche. Pour en profiter de manière souveraine tout en laissant les entreprises accéder aux meilleures technologies, la France et l'Europe préparent le terrain. Les données des entreprises, administrations publiques et particuliers prennent plus de valeur que jamais, et les acteurs concernés — du côté de l'offre comme de la demande — le comprennent tout autant avec la question de la souveraineté au centre. C'est en somme ce qu'on peut conclure de récentes études et annonces en lien avec l'informatique dans le nuage. Pour rappel, le marché mondial du cloud est composé de nombreux fournisseurs de services comme l'IaaS (infrastructure en tant que service), le PaaS (plateforme en tant que service), le SaaS (logiciel en tant que service), ainsi que les clouds publics, privés et hybrides. En termes de services d'infrastructures, le marché est largement dominé par Amazon (AWS), Microsoft (Azure) et Google (Google Cloud) sur le cloud public (où les données sont stockées sur les serveurs des fournisseurs), mais les chinois Alibaba, Tencent et Baidu occupent une place de plus en plus importante, selon Synergy Research Group. Sur le cloud privé (où les données sont stockées sur des serveurs internes), on retrouve des acteurs comme IBM, Rackspace ou NTT. En Europe, le marché du cloud monte en flèche D'autres segments incluent aussi le SaaS BtoB (Microsoft, Salesforce, Adobe), les logiciels et systèmes de stockage (Dell EMC, Cisco, HPE) et les centres de données (Digital Realty, Equinix, CyrusOne). Tous sont donc largement dominés par des entreprises étasuniennes. En 2021, elles vont profiter d'un marché mondial du cloud public de plus de 332 milliards de dollars, contre 270 milliards en 2020, selon les derniers chiffres de Gartner. Le spécialiste des études de marché estime même qu'il pèsera presque 400 milliards de dollars en 2022. Selon IDC, l'écosystème du cloud dans son ensemble, au-delà du simple cloud public, pèsera plus de 1000 milliards de dollars en 2024. Cette domination d'outre-Atlantique constitue un enjeu majeur pour l'Europe. Le marché du cloud sur le Vieux Continent a déjà enregistré une croissance de 27 % par an entre 2017 et 2019, selon une étude de KPMG. Mais alors que l'ensemble de la société se numérise et que la pandémie accélère le recours des entreprises, administrations publiques et particuliers aux services infonuagiques, il devrait atteindre pas moins de 300 à 500 milliards d'euros à l'horizon 2027-2030, contre 53 milliards d'euros en 2020. Aujourd'hui, les mêmes acteurs étasuniens se retrouvent sur le marché européen. AWS, Azure et Google Cloud y captent 70 % du marché de l'IaaS, avec une forte domination d'Amazon. Et si leur part de marché s'étendait de manière significative d'ici à 2027-2030, l’Europe perdrait entre 20 et 50 % de l’impact économique estimé du marché du cloud computing. Mais “les spécialistes du cloud et les opérateurs télécoms européens gagnent progressivement de l’importance sur leurs marchés nationaux respectifs”, affirme le cabinet-conseil. “Ainsi, OVHcloud et Deutsche Telekom se classent troisième et quatrième dans leur pays sur les marchés infrastructures et plateformes”, rappelle l'étude. Une “profonde incompatibilité des réglementations américaines” avec le RGPD Tout l'enjeu se trouve justement là pour les États du Vieux Continent : comment permettre aux acteurs européens de capter ce marché en forte croissance tout en favorisant un cloud souverain et en permettant aux entreprises, administrations publiques et particuliers d'accéder aux meilleures technologies ? KPMG rappelle que depuis 2016 l'Union européenne et les États-Unis ont mis en place différentes réglementations de données : RGPD côté européen, Cloud Act outre-Atlantique (qui, depuis 2018, permet aux autorités du pays de saisir des données à l'étranger lorsqu'elles transitent par des fournisseurs étasuniens), et bouclier de protection (Privacy Shield) des données UE-États-Unis. En 2020, toutefois, la Cour de justice de l'UE a invalidé le Privacy Shield, ce qui a “mis en évidence la profonde incompatibilité des réglementations américaines avec les principes du RGPD, qui semblent irréconciliables”, note KPMG. Cette fracture expose aujourd'hui les entreprises qui choisissent de transférer des données personnelles européennes sur des serveurs d'entreprises non- européennes à des risques judiciaires et industriels. Pour débloquer la situation et permettre à l'Europe d'effectivement capter ce marché, plusieurs options sont cependant envisageables. KPMG en distingue cinq (qui peuvent se complémenter)… Privilégier l'interopérabilité entre les services cloud ou mettre en place une “fédération des acteurs autour d’écosystèmes cloud sectoriels communs”. Un scénario qui rappelle fortement Gaia-X, projet lancé officiellement en juin 2020 par la France et l'Allemagne. Paris et Berlin entendaient alors créer (avec la participation d'entreprises comme OVHcloud, Scaleway ou Orange) une entité de gouvernance capable d'édicter de grands principes de sécurité, d'interopérabilité et de portabilité des données. En somme, Gaia- X marquait le début d'une nouvelle stratégie de développement d'un cloud souverain européen. Mettre l'accent sur la montée en puissance des acteurs européens. Ce scénario serait permis par l’émergence de nouveaux segments de marché comme l'edge computing, l’intelligence artificielle dans le secteur industriel ou les offres souveraines, selon KPMG. Rappelons par ailleurs qu'en février  2021, l'Académie des technologies, établissement public administratif qui émet des propositions et recommandations auprès des pouvoirs publics, suggérait de se concentrer d'abord sur le développement d'un cloud BtoB européen et moins sur les services grand public. L'établissement recommandait aussi de favoriser la liberté de circulation des données professionnelles et de continuer à s'appuyer sur Gaia-X. Instaurer une Autorité de régulation du cloud, accompagnée d'une réglementation plus stricte des pratiques commerciales, d'une “interopérabilité forcée” entre les opérateurs et d'une “réglementation accrue” de l’innovation basée ou dérivée du cloud, continue KPMG. Une “européanisation des opérations” des grands acteurs non-européens du cloud, c'est-à-dire amener Amazon, Microsoft ou Google à transférer le contrôle de leurs activités cloud européennes à des partenaires locaux, comme c'est le cas en Chine. Une “séparation fonctionnelle ou structurelle” des activités cloud des géants non européens du marché de leurs autres activités, avec la création d’entités légales distinctes. Une proposition qui résonne avec les discussions antimonopolistiques aux États-Unis pour tenter de contrôler le pouvoir des grandes entreprises technologiques. Le plan pragmatique de la France Le gouvernement français semble en tout cas avoir entendu ces différents appels à la mise en place d'un cloud souverain et pragmatique. Aujourd'hui, peut-être marqué par l'échec encore retentissant du projet Andromède lancé en 2011, il semble d'ailleurs vouloir mettre toutes les chances de son côté en se dotant d'une feuille de route privilégiant le réalisme aux grandes annonces. Bercy a dévoilé le 17 mai 2021 une stratégie nationale censée encourager le développement d'offres cloud souveraines tout en permettant aux entreprises et administrations françaises, en pleine transformation numérique, d'accéder aux technologies d'AWS, Microsoft Azure, Google Cloud, ou encore d'Alibaba Cloud ou Tencent Cloud. Le plan dispose de trois axes. D'abord, un label “cloud de confiance”, qui repose sur le visa SecNumCloud délivré par l’Agence nationale de la sécurité des systèmes d'information (Anssi), pourra être octroyé à certains fournisseurs de services. Une labellisation qui doit mener à la mise en place d'une sécurisation à la fois juridique et technique pour les entreprises et administrations françaises. La certification permettra aussi “de nouvelles combinaisons comme la création d’entreprises alliant actionnariat européen et technologies étrangères sous licence”, a souligné Bercy. Le ministre de l'Économie, Bruno Le Maire, a clarifié que le label ne sera accordé qu’aux entreprises “européennes et possédées par des Européens”, et disposant “de serveurs opérés en France”. Il a aussi ajouté que le procédé vise à garantir une “indépendance totale par rapport aux lois extraterritoriales américaines”, en référence au Cloud Act étasunien. Ensuite, le gouvernement entend se préparer à la croissance du marché national et européen du cloud en montrant l'exemple au travers de l'adoption d'une politique de “cloud au centre”. Une décision qui signifie simplement que “tout nouveau projet numérique au sein de l'État” se fera à travers le cloud pour accélérer la transformation numérique des administrations. Enfin, Bercy soutiendra financièrement différents projets industriels de développement de technologies cloud en France. Cette action “vise notamment les technologies critiques telles que les solutions PaaS pour le déploiement de l’intelligence artificielle et du big data, ou encore les suites logicielles de travail collaboratif”, a noté Bercy. Il pourra s'agir autant de grandes entreprises que des PME, start-up ou organismes de recherche. La feuille de route de la France semble donc vouloir adopter le scénario le plus pragmatique pour la mise en place d'un cloud européen. Toutefois, si l'annonce a été bien perçue par les acteurs étasuniens du marché, qui pourront a priori continuer à proposer les couches logicielles, des questions demeurent pour certains intervenants européens. Jean-Marie Cavada, ancien député européen et président d'IDFrights, institut qui travaille sur des questions de défense des droits numériques, estime par exemple qu'il reste encore deux obstacles à surmonter : le pouvoir de l'extraterritorialité du Cloud Act américain sur le label “cloud de confiance” et le futur de l'invalidation du Privacy Shield par la Cour de justice de l'UE. Nul doute que le gouvernement français et l'UE devront apporter des réponses à ces questions à moyen terme. Blockchain et RGPD : quelles solutions pour un usage responsable en présence de données personnelles ? 24 septembre 2018 La Blockchain est une technologie au potentiel de développement fort qui suscite de nombreuses questions, dont parfois celle de sa compatibilité au RGPD. C’est pourquoi la CNIL s’est saisie de ce sujet et propose des solutions concrètes aux acteurs qui souhaitent l’utiliser dans le contexte d’un traitement de données personnelles. Qu’est-ce que la Blockchain ? La Blockchain est une base de données dans laquelle les données sont stockées et distribuées sur un grand nombre d'ordinateurs et dans laquelle toutes les écritures effectuées dans ce registre, appelées « transactions », sont visibles de l'ensemble des utilisateurs, depuis sa création. La Blockchain n’est pas, par elle- même, un traitement de données ayant une finalité à part entière : il s’agit d’une technologie, qui peut servir de support à des traitements variés. A noter : Le terme « Blockchain » est parfois accompagné d'une expression désignant une famille de technologies plus large : celle des registres distribués, ou DLT pour « distributed ledger technology ». Si la CNIL s’intéresse au développement de ces registres, qui incluent les Blockchains mais ne s’y limitent pas, elle a néanmoins choisi de concentrer son analyse sur la seule technologie Blockchain, dans la mesure où les solutions DLT qui ne sont pas des Blockchains sont encore trop récentes et rares pour permettre une analyse générique. Quelles sont les caractéristiques et les différents types de Blockchain ? La Blockchain peut se définir au travers des propriétés suivantes : transparence : tous les participants peuvent visualiser l’ensemble des données inscrites ; partage et décentralisation : plusieurs exemplaires de la Blockchain existent simultanément sur différents ordinateurs ; irréversibilité : une fois qu’une donnée est inscrite, elle ne peut pas être modifiée ou supprimée ; désintermédiation : toute décision se fait par consensus entre les participants, sans arbitre centralisé. En pratique, plusieurs sortes de Blockchain coexistent, mettant en œuvre des niveaux de permission différents pour les différentes catégories de participants. La CNIL utilise la classification suivante : les Blockchains publiques sont accessibles à n’importe qui dans le monde. Toute personne peut effectuer une transaction, participer au processus de validation des blocs ou obtenir une copie de la Blockchain ; les Blockchains à permission ont des règles définissant quelles personnes peuvent participer au processus d’approbation ou même effectuer des transactions. Elles peuvent, selon les cas, être accessibles à tous ou être en accès limité ; les Blockchains dites « privées » sont sous le contrôle d’un acteur qui assure seul le contrôle de la participation et de la validation. Selon certains experts, ces usages ne respectent pas les propriétés classiques de la Blockchain, notamment la décentralisation et la validation distribuée. En tout état de cause, elles ne posent pas de question particulière de conformité au RGPD, il s’agit de simples bases de données distribuées « classiques ». Quels sont les différents acteurs qui interagissent sur la Blockchain ? La CNIL distingue trois types d’acteurs dans une Blockchain : les « accédants », qui ont un droit de lecture et d’obtention d’une copie de la chaîne ; les « participants », qui ont un droit d’écriture (la création d’une transaction qu’ils soumettent à validation) ; les « mineurs », qui valident une transaction et créent les blocs en appliquant les règles de la Blockchain afin qu’ils soient « acceptés » par la communauté. Quelles interactions entre RGPD et Blockchain ? Lorsque la Blockchain concerne des données personnelles, le RGPD s’applique. L’architecture et les caractéristiques propres des Blockchains vont toutefois avoir des conséquences sur la manière dont sont conservées et traitées les données personnelles. L’impact de la Blockchain sur les droits des personnes (droit à la vie privée et droit à la protection de leurs données personnelles) appelle donc une analyse spécifique. Toutefois, cette innovation et la protection des droits fondamentaux des personnes ne sont pas deux objectifs antagonistes. En effet, le RGPD n’a pas pour objectif de réguler des technologies mais les usages qui en sont faits par les acteurs dans un contexte impliquant des données personnelles. C’est pourquoi la CNIL s’est saisie de ce sujet et, dans le but de contribuer aux réflexions en cours sur ces technologies et leur développement, propose une grille d’analyse et de premières recommandations aux acteurs qui souhaitent y recourir lorsqu’ils mettent en œuvre un traitement de données personnelles. Quels sont les usages qui impliquent, directement ou indirectement des données personnelles ? Une solution technologique au soutien du principe de responsabilisation (accountability) ? Quels sont les points de vigilance ? Quelles solutions ? Quel plan d’action pour la CNIL ? Document reference Pour approfondir Premiers éléments d'analyse de la CNIL sur la blockchain [ PDF-205.85 Ko]