La donnée ouverte (ou Open data) est une donnée primaire, libre de droits, accessible publiquement et gratuitement, sans condition discriminatoire. Elle est obligatoirement proposée dans un format exploitable et non propriétaire et a pour principaux objectifs d’assurer la transparence des données des administrations et entreprises (dépense de l’Etat, prix des carburants) ainsi que d’encourager la réutilisation de ces données et de faciliter la création de services innovants (plans interactifs, données météo en temps réel, retards des trains). Mais cette démarche d’ouverture et de mise à disposition du grand public de données internes aux administrations et entreprises induit de nombreux impacts dans le SI de ces dernières.
Mettre en œuvre une architecture spécifique pour assurer la « libération » des données
À l’heure d’ouvrir ses données internes au grand public, l’administration ou l’entreprise se doit de mener une réflexion sur les données qu’elle souhaite ou non « libérer », sur les impacts juridiques de cette libération ou encore sur les conditions d’utilisation de ces données (mode de publication, licence d’utilisation éventuelle).
Mais elle doit également mesurer l’impact de cette libération de données sur son système d’information et réfléchir à l’architecture qu’il faut mettre en œuvre afin de permettre :
- L’identification et l’extraction des données depuis les différents back-offices des domaines applicatifs ;
- La consolidation et le stockage en central de ces données ;
- Le traitement et le formatage de ces données pour assurer le niveau de qualité attendu ;
- La diffusion et la publication de ces données une fois traitées et remises dans un format exploitable et non propriétaire.
Réutiliser des outils existants pour extraire et traiter les données
Après identification et sélection par chaque domaine applicatif des données utiles sur son périmètre, il convient au domaine de mettre en œuvre l’ensemble des règles de gestion permettant le filtrage et l’extraction de ses données avec le niveau de qualité attendu. Ces données sont alors transportées jusqu’à un « entrepôt » de stockage centralisé où elles sont consolidées, homogénéisées, (re)nettoyées et/ou formatées avant leur publication.
Pour l’ensemble de ces actions de filtrage, d’extraction, de transformation et de chargement des données, des outils déjà présents dans le SI peuvent être utilisés :
- Mutualisation des activités de sélection et d’extraction des données avec les outils de l’architecture décisionnelle ;
- Transformation et chargement des données via les ETL de l’entreprise ;
- Utilisation des outils de MDM (Master Data Management) pour les étapes de nettoyage et de formatage des données.
Maîtriser l’historisation pour rationaliser les volumétries traitées
Dès l’étape de stockage en central des données, il est tentant de mettre en œuvre des mécanismes d’historisation des données afin de garder une trace des différents états de l’entrepôt de données. Cependant cette option, dont le besoin n’est pas toujours justifié, a un impact réel sur la volumétrie et sur les traitements.
Aussi, une seconde stratégie très répandue consiste à remplacer les données par la dernière version dans l’entrepôt et à ne conserver un historique qu’au niveau de la publication, une fois toutes les étapes de transformation terminées.
Choisir le mode de publication en fonction du niveau de fraîcheur de données
Pour la plupart des données ouvertes publiées (horaires des transports par exemple), un haut niveau de fraîcheur n’est pas nécessaire. Aussi, la méthode de publication par fichiers est privilégiée car elle n’impose que peu de contraintes bien que certaines bonnes pratiques soient fortement conseillées :
- La limitation de la taille maximale des fichiers à quelques Mo afin de faciliter leur consommation par les utilisateurs ;
- L’utilisation de formats comme xHTML, XML ou JSON plutôt que CSV car ces formats peuvent être enrichis d’attributs sans conséquence sur les consommateurs.
Cependant, dans certains cas, où le niveau de fraîcheur des données attendu est trop important, le fonctionnement par fichiers se révèle insuffisant. D’autres méthodes plus complexes et onéreuses doivent alors être considérées. Ce sera notamment le cas pour les données « temps réel » (retards de trains…) pour lesquelles on privilégie l’exposition de services de consultation des données stockées dans l’entrepôt (Web services SOAP, services REST…) ou encore pour les données nécessitant la mise en œuvre de service de visualisation avancée (géolocalisation…).
Sélectionner le mode d’hébergement de la plate-forme de publication en fonction des enjeux d’isolation et de scalabilité
La plate-forme de publication des données ouvertes étant accessible au public, elle doit être isolée du reste du SI pour des raisons de sécurité. Une nouvelle infrastructure est donc généralement à construire soit en interne, soit auprès d’un hébergeur externe.
De plus, comme il est compliqué d’anticiper le taux de consommation des données ouvertes publiées et donc le degré d’utilisation de la plate-forme, faire appel aux offreurs Cloud pour un tel hébergement est fréquent et favorise une plus grande scalabilité des plates-formes de publication.
Si l’Open data a pour vocation d’être l’un des principaux facilitateurs du développement de l’économie numérique, elle n’est pour autant pas sans conséquence sur l’architecture ou la sécurité du SI des producteurs de données. Alors, libérer les données ? Oui… mais à quel prix : l’entreprise dispose-t-elle des outils et offres nécessaires ? A-t-on bien mesuré la complexité de l’ouverture des données du SI ? Autant de questions à se poser pour considérer avec efficacité cette problématique.