Introduction
Cette semaine, j’ai présenté mes activités professionnelles à un stagiaire de seconde. Classique, me direz-vous : je suis bien d’accord. Néanmoins, je me dis que ce que je lui apprends alors, vous l’ignorez peut-être, vous aussi. Dans le doute, je reprends pour vous.
Pour le contexte, je travaille dans une DSI (Direction des Systèmes d’Information), et j’y suis en charge de l’un des systèmes d’information (SI). Mon boulot a cela de particulier que je gère et j’utilise ce SI (contrairement à certains de mes collègues qui gèrent mais n’utilisent pas leurs applications).
L’importance des données
Pour commencer, un SI, c’est quoi ? C’est, en gros tout ce qu’il faut pour servir de l’information. C’est, ensemble, un ou plusieurs logiciels, le matériel sur lequel ils tournent, les humains qui l’administrent et… l’information (les données). Pour arriver à son objectif, il collecte des informations, les traite si besoin, les stocke si besoin, et les diffuse.
Dans le système que je gère, une partie du traitement réalisée par l’humain (ou sous son contrôle étroit). Je ne parle pas de la saisie, que j’assimile à la collecte, mais bien du traitement. Je présente souvent mon travail par la finalité de ce SI (car je l’utilise), ce qui correspond à la diffusion de l’information. La réalité, c’est que la très grande majorité de mon temps est dédié à la collecte et au traitement.
Beaucoup de ces traitements sont automatisables (et j’en automatise beaucoup). La raison principale pour laquelle on a toujours besoin de quelqu’un, et on en aura peut-être besoin longtemps, c’est que le besoin exprimé par les utilisateurs (moi inclus) concerna toujours l’information diffusée. À partir de cette seule partie finale du travail, il faut concevoir et mettre en place tout le reste du système. Et n’oublions pas les procédures de maintenance.
Pour faire une analogie avec un autre domaine, c’est comme pour le train : vous, utilisateur, souhaitez aller d’un point A à un point B, le plus rapidement possible. Acquérir le foncier, réaliser les ouvrages, mettre en place l’infrastructure ferroviaire et les gares, exploiter le réseau, acheter et maintenir le matériel roulant, le conduire : vous ne le demandez même pas. OK, ce n’est pas vous qui demandez ; mais même l’autorité en charge des transports ne demandera finalement qu’une fréquence de passage entre tels et tels lieux (et une accessibilité, un confort, etc.).
L’exemple de la cartographie interractive
Revenons à nos SI. Voilà une illustration de la vie de tous les jours pour un certain nombre d’entre vous : si vous avez l’habitude d’utiliser des cartes interactives, par exemple celle proposée par votre moteur de recherche, vous y voyez de nombreuses choses, en particulier des traits, des aplats et des symboles de différentes couleurs. Mais quelles données sont derrière tout ça ? Quelle est leur complexité ?
Dans OpenStreetMap, nous avons accès à ces données et pouvons les consulter (et les modifier). Si vous ne l’avez pas encore remarqué, il existe un outil « Interroger les objets » (c’est une flèche avec un point d’interrogation, en bas des outils proposés à droite de l’écran).
Pour vous en rendre compte par vous-même, vous pouvez utiliser cet outil et observer tous les objets derrière la carte, ainsi que les données associées à chacun d’entre eux. Vous trouverez des objets administratifs, les zonages notamment (commune, canton, etc.), ainsi que les voies, le mobilier urbain, les bâtiments, les boutiques et administrations.
Chacun de ces objets a des attributs qui dépendent notamment de son type. Le revêtement peut être précisé pour une voie mais il ne le sera jamais pour une commune. Les liens entre les objets sont également indiqués : les nœuds partagés entre plusieurs chemins, les relations entre objets (par exemple, entre une rue et les numéros de cette rue). Cet ensemble est vraiment complexe, d’où l’intérêt d’avoir quelqu’un derrière tout ça.
Je vous invite à parcourir OpenStreetMap à la recherche d’un escalier ; observez alors les informations le concernant. Si vous n’en avez pas dans la carte à proximité ou que vous avez des difficultés avec la navigation dans la carte, en voici un exemple d’escalier sur OpenStreetMap (pour les connexions limitées, vous pouvez consulter les fiches xml associées [1]).
L’objet représentant un escalier (« steps » signifie « marches » en anglais) est connecté de chaque côté à un autre élément (souvent de type chemin piéton). Cette connexion se fait par le biais d’un nœud, qu’il partage à son extrémité avec cet élément. C’est indispensable pour calculer des itinéraires. Car l’information que c’est un escalier, si elle vous peut être utile pour se repérer sur une carte, peut aussi être exploitée de manière non graphique dans des calculs. C’est d’ailleurs utilisé comme ça dans les calculs d’itinéraire qui tiennent compte de l’accessibilité, qui devraient bientôt être généralisés (et s’ils ne le sont pas encore, c’est parce que les données ne sont pas disponibles partout).
Je vous invite, si vous en avez la curiosité, à parcourir le modèle de données [2] du standard CNIG d’accessibilité du cheminement en voirie, partie 3.2 (à partir de la page 17) de la dernière version du standard à cette date. Les escaliers y sont représentés par un type spécifique de « tronçon de cheminement ». Ils sont situés entre 2 nœuds, lesquels sont alors également les extrémités d’autres cheminement, potentiellement de type circulation (ou bien un autre escalier, une rampe, etc.). Ça vous rappelle quelque chose ? En effet, le modèle de données est proche de celui d’OpenStreetMap : il y a d’ailleurs un outil qui convertit les données d’OpenStreetMap vers ce standard.
En conclusion
J’ai illustré ici l’importance des données dans le monde des SI, qu’on ne perçoit pas toujours en tant qu’utilisateur. Et pourtant, si le mot « système » est important dans « Systèmes d’Information », il ne faut pas oublier le mot « information » !
Nous n’avons fait qu’effleurer le sujet des données. Il reste tant de choses à dire toutes les conditions pour qu’elle soit utilisable. Ainsi, les prochains billets de la thématique des données pourront porter sur leur besoin :
- de structuration (et donc au préalable de modélisation),
- de qualité, ce qui va avec son évaluation et sa qualification,
- de documentation, au travers des métadonnées,
- de standardisation (qui doit prendre en compte l’ensemble des points précédents), préalable à une diffusion, en open data ou non,
- de confidentialité et de gestion des privilèges.
Comme vous le voyez, le sujet est vaste !
J’espère que la lecture de ce billet vous a été plaisante et enrichissante. N’hésitez pas à me faire des retours ! Pour notre prochain billet, nous pourrons aborder une nouvelle thématique et introduire un peu de code.
namori
PS : Je suis désolé si vous vous attendiez à ce que je parle de vol de données personnelles, ou encore du coût d’acquisition des données… Je n’ai pas trouvé meilleur titre, même s’il manque certainement de précision !
Notes
| [1] | Les fiches XML suivantes représentent les éléments de cet exemple :
Vous retrouverez bien le nœud référence 3696172618 dans l’escalier et dans le deuxième objet de type way (signifiant « chemin » en anglais). |
| [2] | Le modèle de données, c’est la représentation qui permet de concevoir la structure dans laquelle on va pouvoir sauvegarder les données, les traiter et les diffuser. La structure des données est souvent appelée elle-même modèle de données. Les données de chaque type peuvent par exemple être réuni dans une table et des relations peuvent être faites entre des objets de plusieurs tables, si le modèle le prévoit. Ce modèle est adapté aux bases de données dites structurées relationnelles. Les modèles sont cruciaux pour les bases de données non structurées, car la structure de la base de données est alors moins explicite et sa compréhension est parfois très délicate sans documentation. |