Conception des systèmes d'information

De Metabolisme territorial
Aller à : navigation, rechercher

Systèmes d'information

L'examen des étapes du traitement des données pour leur analyse met en lumière la complexité du processus et les implications qui en découlent. Cette complexité ne peut pas être exposée pleinement à l'utilisateur : le recours à des abstractions est nécessaire pour lui permettre de manipuler plus rapidement et facilement les données et de réduire les risques de confusion et d'altération. L'implémentation d'un Système d'Information (SI) a notamment pour but de rendre disponibles les abstractions nécessaires au bon déroulement d'un processus basé sur des données. Il permet d'interagir avec des utilisateurs humains ou avec d'autres SI pour "transformer des données brutes, hétérogènes, [...] en une information visible et compréhensible." (Flichy 2013, p.59). Il s'agit de manipuler facilement des données, c'est-à-dire pouvoir en ajouter, les modifier, les analyser, les synthétiser, les visualiser ou encore les partager. Les composantes d'un SI sont multiples et peuvent reposer en partie sur des formes d'organisations sociales. D'un point de vue technique, les SI reposent sur des composants logiciels (algorithmes, protocoles et données) et sur des composants matériels (disques durs, processeurs, canaux physiques de communication ...).

L’ingénierie des SI fait partie des sciences de conception (Assar 2015). Plutôt que décrire le monde tel qu'il est, ces sciences de l’artificiel visent à imaginer comment il pourrait être et à spécifier les artéfacts qui y amènent. La conception repose souvent sur l'empirisme et l'itération, parfois plus que sur la déduction (Flichy 2013). Les concepteurs doivent en effet procéder à des choix techniques, sur la base de leurs connaissances, de leurs ressources et de leurs intuitions, forcément limitées ou imparfaites. L'évaluation des artéfacts conçus est ainsi indispensable pour les améliorer jusqu'à ce qu'ils répondent de manière satisfaisante aux objectifs qui leur sont assignés (Assar 2015). Le développement d'un SI est un processus long qui mobilise de nombreuses personnes et compétences à l'intersection entre plusieurs disciplines (Flichy 2013). Le travail de programmation ne représente qu'une partie du processus : celle visant à l'implémentation concrète d'un travail de conceptualisation et de formalisation des besoins des utilisateurs et du domaine d'étude.

Selon les fonctionnalités attendues par un SI, ses composantes sociales, logicielles et matérielles peuvent être plus ou moins importantes. Par exemple, dans le cas d'un système d'information pour la gestion d'un réseau ferroviaire, les trois composantes sont primordiales. En revanche, un système d'information pour la comptabilité d'une petite entreprise peut reposer entièrement sur une approche logicielle sans nécessiter de matériel ou d'organisation en particulier. Une approche uniquement logicielle peut être rapidement dupliquée dans une autre organisation auprès d'autres utilisateurs, tandis que des composantes matérielles ou sociales spécifiques nécessitent plus de temps et de ressources pour être reproduites. Elles sont toutefois nécessaire pour maitriser le cycle de l'information dans son intégralité (de la réalité à l'action sur la réalité), là où les approches purement logicielles ne peuvent ni mesurer ni agir sur la réalité. Au regard de nos travaux qui se focalisent sur de l'analyse de données existantes, considérer un système d'information uniquement selon une composante logicielle nous apparaît toutefois suffisant pour apporter des réponses à notre problématique. Nous laissons ainsi les autres composantes matérielles et humaines faire l'objet d'éventuels travaux ultérieurs.

Il existe différentes méthodes de conception de la partie logicielle des SI, une des plus connue étant la méthode française MERISE (Thévenot 2001). Cette méthode pose un cadre méthodologique parfois un peu rigide, mais dont nous nous sommes inspiré dans nos travaux, notamment en séparant le modèle de structuration des données et les fonctionnalités de traitement attendus. A cela s'ajoute une réflexion sur l'interface utilisateur pour la rendre ergonomique et sur la documentation, l'objectif étant de permettre aux utilisateurs d'accéder facilement à l'ensemble des fonctionnalités offertes par le SI (Valentin et al. 2010).

Un SI s'appuie sur différentes technologies (langage de programmation, réseaux de télécommunication, SGBD, ...) et des algorithmes implémentant différentes fonctionnalités (manipulation de données, protocole de communication, ...). Il est souvent possible de mobiliser des librairies existantes (des algorithmes réutilisables dans différents projets) qui implémentent efficacement certaines fonctionnalités. Ces librairies sont souvent (pas toujours) libres de droits et mises à jour régulièrement par une communauté pour améliorer leur efficacité et fiabilité. Leur utilisation permet un gain de temps considérable dans le développement. Selon les langages de programmation, la disponibilité des librairies peut cependant varier : cela constitue ainsi un des critères du choix du langage à utiliser.

Afin d'accompagner le lecteur peu familier des SI, mais sans toutefois prétendre faire le tour de la thématiques, il nous apparaît utile de présenter plus en détails certains éléments particuliers que nous allons mobiliser dans la suite de nos travaux (en particulier §4). Il s'agit de présenter les structures de données existantes, la notion d'ontologie qui permet de conceptualiser un modèle de données et de mobiliser le paradigme de la programmation orientée-objet et de parler du concept d'entrepôts de données.

Structures de données

Les structures de données sont des concepts nécessairement mobilisés pour pouvoir les manipuler. A travers ces structures, il va être possible d'agréger des données, de leur donner du sens, de créer des liens entre elles, de les stocker ou de les partager avec d'autres utilisateurs humains ou machines. Elles permettent également l'utilisation d'algorithmes génériques pour mener à bien des analyses, algorithmes disponibles à travers des logiciels spécialisés, des librairies de programmation, ou encore des systèmes de gestion de bases de données {Ref needed}.

On parle parfois de données structurées et de données non structurées. En fait, pour exister numériquement, toute l'information enregistrée doit prendre la forme de données structurées. Lorsqu'on parle de données structurées, nous parlons ainsi plutôt de données concises, explicites et discrètes. Cela s'oppose aux données non structurées comme le texte, le son, les images, les vidéos qui sont décrites par de longues chaines de données, peuvent faire l'objet d'une interprétation[1] et se rapprochent d'une description continue de la réalité, sans jamais pouvoir l'être totalement car l'information numérique est inévitablement discrète.

Nos travaux nous ont amené à manipuler des données à travers différentes structures. Pour appuyer notre réflexion dans la conception d'un système d'information, nous avons réalisé un panorama des structures de données disponibles. Nous avons ainsi pu identifier les structures récursives, les formats de sérialisation, les tableaux, le web de données, les blockchains et les images graphiques. Dans cette partie nous détaillons ces différents concepts.

Les structure récursives

Les structure récursives organisent les données sous forme de blocs de données (des nœuds ou sommets) reliés entre eux {Ref needed}. Les liens (ou arrêtes) entre les nœuds peuvent avoir un sens (liens orientés) ou être également porteurs d'un bloc de donnée, par exemple pour spécifier la longueur du chemin. Les structures récursives les plus simple sont les listes chaînées (figure X.a) qui permettent d'ordonner les données, puis les arbres qui permettent de les hiérarchiser (figure X.b), puis les graphes qui permettent de multiples relations entre les différents nœuds (figure X.d). Entre l'arbre dans lequel les nœuds sont structurés selon une notion de parent/enfant, avec au plus un parent par enfant et le graphe qui permet tout type de lien, nous introduisons le graphe hiérarchisé (figure X.c). Ce graphe repose également sur la notion de parent/enfant, mais en autorisant plusieurs parents par enfant si cela n'enfreint pas la hiérarchie logique.

Ces structures conceptuelles ont différentes applications {Ref needed} : la gestion de file d'attente à travers des listes chainées et la gestion d'arborescences (de fichiers, de classification ...) et l'implémentation d'algorithmes de recherche efficaces pour les arbres. Quant aux derniers, ils sont le support d'un foisonnant domaine en mathématique : la théorie des graphes. Leur version hiérarchisée peut également s'utiliser pour représenter des généalogies ou l'organisation territoriales[2].

La conceptualisation d'une structure récursive est un exercice de base de programmation et de nombreuses librairies implémentent les fonctionnalités nécessaires pour créer et manipuler ce type de structure. En revanche, pour les utilisateurs ne maitrisant pas la programmation, les logiciels communs ne permettent pas de manipuler l'information de manière générique à travers ce type de structure. Ce sont plutôt des fonctionnalités ponctuelles spécifiques (l'explorateur de fichier, la hiérarchie d'un menu, des logiciels de graphes) qui vont permettre à l'utilisateur de naviguer dans une telle structure de manière abstraite, sans vraiment la manipuler en tant que telle.

Formats de sérialisation

La sérialisation consiste à organiser des données sous la forme d'une longue chaîne de caractères (sérialisation textuelle) ou de bits (binaire). L’ordonnancement des informations et l'utilisation de certains caractères (ou suite de bit) qui ont un sens spécifique sont définis selon une convention. Cela permet d'extraire un sens complexe de cette longue chaîne et de lier de manière cohérentes différentes parties. (Sumaray & Makki 2012)

Les formats de sérialisation textuelle sont lisibles par les humains, même si cela demande un peu d'effort et de connaitre la convention pour en interpréter le sens. Les données sont séparées et structurées soit à l'aide de délimiteurs (, / ; - [ } <> "retour à la ligne" ...) pour former des lignes et des colonnes comme avec le format CSV, ou soit en utilisant des balises ("<balise>Donnée</balise>", ou "{Donnée}" ) comme pour les formats XML ou JSON. Les trois formats cités sont les plus répandus en informatique et particulièrement présents pour l'échange de données sur le web (Sumaray & Makki 2012).

Les formats binaires quant à eux forment une suite de bits, ce qui rend leur lecture trop complexe pour un humain, mais ne pose pas de difficulté pour une machine. Ils sont plus adaptés pour structurer des données complexes (images, son, document bureautique) et en optimiser la taille. La plupart des extensions connues (zip, doc, png, jpg, gif, mp3, avi, ...) repose sur une telle sérialisation.

Dans la pratique, tous les fichiers que nous manipulons reposent sur des formats de sérialisation, même si cela presque tout le temps abstrait pour l'utilisateur : ce sont les différents logiciels qui permettent d'en extraire le sens et de le rendre manipulable par un utilisateur humain à travers une interface (graphique, tactile, ...). L'intérêt des formats textuels est qu'il suffit d'un éditeur de texte basique (par exemple le bloc-notes) pour les lire, ce qui peut permettre à un utilisateur d'avoir une vision sur les données elles-même. Cela est d'une grande aide pour identifier les algorithmes à utiliser dans la manipulation des données et rechercher les causes d'erreur si ceux-ci ne s’exécutent pas correctement. Ce sont toutefois des aspects qui sont surtout utiles aux développeurs plutôt qu'aux utilisateurs lambda qui ont peu de chance de manipuler des formats de sérialisation directement.

Les tableaux

Les tableaux sont un moyen efficace de structurer l'information, à la fois très familière pour les humains, mais aussi pour les machines informatique dont l'architecture est fondamentalement compatible avec cette approche. Nous pouvons distinguer plusieurs types de tableaux :

  • Les tableaux à une dimension de lecture (plus souvent appelées "enregistrements") sont composés d'une succession de lignes (très rarement de colonnes), chaque ligne formant un groupe de données dont le sens est identifié par l'intitulé de colonne.
  • Les tableaux à deux dimensions, où chaque case est mise en correspondance avec son intitulé de ligne et de colonne, formant ainsi un triplet de valeur.
  • En généralisant, nous pouvons conceptualiser des tableaux à 3,4, ... n dimensions, formant ainsi des tableaux multidimensionnels (des hypercubes), où chaque donnée est à l'intersection de n intitulés, formant ainsi un n-plet de données.

Les enregistrements et les tableaux 2D se manipulent aisément avec un logiciel tableur. Pour les tableaux de dimension supérieure, il faut faire appel à des solutions plus avancées, comme par exemple les technologies OLAP (Online Analytical Processing) ou des librairies de programmation. Il est également toujours possible de présenter un tableau à n dimensions sous la forme d'enregistrements avec n+1 colonnes (un tableau 2D de taille l x c peut se présenter sous la forme de l x c lignes et 3 colonnes).

Tableaux liés : Modèle Entité/Association

Il est possible de structurer des données sous la forme d'un ensemble de tableaux d'enregistrements liés entre eux. Pour concrétiser ce lien, il suffit que les données d'une colonne soit communes à plusieurs tableaux. On parle de clef primaire et de clef étrangère qui permettent respectivement d'identifier de manière unique un enregistrement et d'y faire référence depuis une autre série d'enregistrement. Cette approche est la traduction opérationnelle du modèle conceptuel entité-association, formalisé par Chen (1976) et qui a servi de point de départ à la conceptualisation des modèles de données dans nombreuses méthodes (Merise, UML, ...) (Dessaigne 2005).

De manière pragmatique, le modèle entité/association vise à structurer les données relatives à un domaine à travers un ensemble de tables, chacune visant à rassembler les données d'un type d'entité particulier (on parle parfois de classes d'objets) comme des clients, des produits, des villes. En fait, presque n'importe quel nom commun qui soit tangible peut constituer un type d'entité. Ces entités sont décrites par des propriétés qui peuvent être de type élémentaire (nombre, date, texte court ... nous parlerons d'attribut) ou représenter une association avec un ou plusieurs autres entités du modèle (nous parlerons de relation). . De part la grande complexité qui peut être conceptualisée à travers cette approche, elle est devenue fondamentale en informatique et est largement déployée à travers les bases de données relationnelles (BDDR). Elle est en particulier mobilisée par le forme du diagramme de classe du langage UML (Unified Modeling Language) qui un langage standard pour la formalisation des SI (Dessaigne 2005).

La mise en œuvre d'un modèle entité/association à travers une BDDR est une approche standard dans l'industrie, mature, dominant le marché du stockage de l'information et disponible dans pratiquement tous les Systèmes de Gestion de Bases de Données (SGBD) (Inmon 2005 ; Dessaigne 2005). Ces derniers vont permettre d'accéder, d'ajouter, modifier ou supprimer des données dans la base par l’intermédiaire de requêtes écrites dans un langage spécifique, souvent du SQL (Structured Query Langage). Pour écrire ces requêtes, il faut non seulement en connaître le langage (ce qui exclue d'office les utilisateurs lambdas), mais aussi connaître le modèle entité/association implémenté. Même avec quelques connaissances, ces requêtes peuvent être parfois complexes à écrire, surtout si elles portent sur plusieurs liens entre les données de différentes tables. En revanche, l’exécution de ces requêtes est très efficace et permet de manipuler des grands ensembles de données (Dessaigne 2005).

Structures de données basées sur internet

L'apparition d'internet a été une révolution dans la façon nous partageons l'information. A l'origine, elle n'a pas fondamentalement changé la façon de structurer les données et a simplement permis d'y accéder à distance, ce qui est déjà un progrès conséquent. Toutefois, nous voyons émerger deux structures dont l'essence même est d'être distribuée sur internet : le web de données et la blockchain (dans un français peu usité "chaine de blocs"). Bien que reprenant des structures existantes (respectivement le modèle entité-association et les listes chaînées), cette spécificité impose des contraintes supplémentaires pour rendre la structure fonctionnelle, mais ouvre dans le même temps des possibilités nouvelles.

Web de données

Le web de données (en anglais linked data) a pour objectif de structurer des données sous la forme de bases distribuées et reliées entre elles sur internet. Pour qu'une base puisse s'intégrer avec les autres, elles doit respecter un certain nombre de conventions définies par le World Wide Web Consortium (W3C)[3] : usage d'identifiants uniques (URI - Uniform Resource Identifier) pour désigner les concepts/entités à décrire, lien explicites avec d'autres bases, utilisation de modèles ou langage normalisés (RDF, OWL, SPARQL, ...) pour la formaliser la connaissance, sa structure et les requêtes qui s'y reportent (Berners-Lee 2006). Ces convention permettent de rendre interopérables les données entre différentes bases de façon à permettre aux utilisateurs d'abstraire cette multitudes de bases et de manipuler des données comme s'il ne s'agissait que d'une seule.

En appui à l'émergence d'un web des données, plusieurs grandes bases de données ouvertes sont devenues compatibles avec cette technologie. Nous pouvons notamment citer les projets DBpedia et Wikidata qui visent à structurer les données disponibles sur Wikipédia (Ismayilov et al. 2018), ou des sites de données institutionnels comme l'IGN ou le portail des données ouverte de l'Union Européenne[4]. Toutefois, si le concept est séduisant, son implémentation reste complexe et demande à mobiliser des compétences spécifiques, d'un niveau supérieur à celles nécessaire à l'implémentation d'une base de données relationnelle. Ainsi, la dynamique de développement du web de données nous semble encore faible malgré l'existence de plusieurs travaux encourageant (Davis 2017 ; Ismayilov et al. 2018).

Blockchain

Plus souvent désigné sous son nom anglais, même en français, une blockchain peut être assimilée à "un très grand cahier [virtuel] que [...] tout le monde puisse lire, sur lequel chacun puisse écrire, mais qui soit impossible à modifier et indestructible" (Delahaye 2015, p.80). L'essence d'une blockchain est ainsi d'être répliquée sur internet, sur différentes instances qui communiquent et se synchronisent entre elles à travers un protocole sécurisé et prédéfini visant à permettre l'établissement d'un consensus global. La décentralisation des données est gage de confiance : aucun acteur ne peut venir modifier seul des données consensuellement validées et synchronisées sur une multitude d'instances (Waelbroeck 2017).

La première implémentation d'une blockchain remonte à 2008 comme fondement de la monnaie électronique (crypto-monnaie) bitcoin et dont le développement a eu un écho certain (Pavel 2017). En effet, puisque le fonctionnement de cette monnaie repose uniquement sur son protocole décentralisé, elle ne dépend ni des États, ni d'aucun individus en particulier et permet d'assurer l'anonymat des transactions. Nous devinons assez bien que cela ouvre un grand nombre de questionnements sociétaux (juridiques, sécuritaires, ... ) et de challenges techniques (consommation d'énergie, vitesse, ...). Pour certains d'entre eux, la réponse formelle n'est pas encore établie (Pavel 2017).

Si historiquement la blockchain a émergé avec la crypto-monnaie, elle n'en n'est pas la seule application. En fait, l'établissement d'un système de confiance robuste permet d'imaginer de nouvelles opportunités présentant de fort enjeux économiques (Delahaye 2015 ; Waelbroeck 2017) comme la création d'outils notariaux, le suivi de produits à travers une chaine d'acteurs, des systèmes de vote ... Probablement nous n'en sommes encore qu'au début d'imaginer ce qu'il est possible d'en faire.

Les images graphiques

Nous introduisions précédemment les images graphiques comme étant situées à la frontière de notre définition d'une structure de données. En effet, d'un coté, la nécessaire interprétation d'une image ne semble a priori pas favorable à la structuration des données. Toutefois, le fait qu'elles soient graphiques, c'est-à-dire qu'elles soient construites à partir d'une application mathématique, permet également de rendre explicite les données à travers la structuration des formes géométriques utilisées. Ainsi, à l'approximation visuelle près, il est souvent possible de reconstruire les données originales à partir d'un graphique trouvé dans la littérature. De notre expérience, c'est d'ailleurs souvent plus rapide (malheureusement approximatif) que de chercher à retrouver les données originales ayant servi à la construction du graphique.

Nous ne souhaitons pas discuter ici si les images graphiques doivent être considérées comme des structures de données ou non. Clairement, il y a une forme de structure explicite, mais ces images ne sont pas adaptées pour manipuler des données de manière opérationnelle. En revanche, comme nous le mentionnions précédemment (§1.1), elles sont extrêmement performantes sur un domaine d'application particulier, et c'est pourquoi nous tenons à les faire figurer dans ce panorama : agréger des données pour en permettre une interprétation cognitive globale. Ainsi, les graphiques sont généralement mobilisés à la fin de la chaine de traitement des données, lorsqu'il s'agit d'interpréter (de manière forcément cognitive) les résultats d'une analyse.

Les images graphiques sont toutefois limitées par la quantité de données qu'elles peuvent représenter, non pas tant sur le nombre de points que sur le nombre de dimensions analysées. Ainsi, la majorité des graphiques permettent de représenter 2 ou 3 dimensions simultanément. Avec un peu technique, il est possible d'arriver à 4 dimensions, voir 5 en rendant le graphique dynamique[5]. Au delà, il nous paraît difficile d'assurer sa lisibilité. Pour des études complexes, ce nombre maximum de dimensions est souvent dépassé : il n'est donc pas possible de représenter toute l'information en une seule image.

Synthèse

Nous avons présenté un panorama des différents structures de données que nous avons pu identifier dans la littérature et à travers notre expérience. Il est souvent possible de convertir des données d'une structure vers une autre, même si cela peut demander une certaine réflexion pour déterminer la manière de faire. Le choix d'une structure va dépendre de différents critères selon l'objectif visé : s'agit-il de stocker les données, de les représenter, de les manipuler via une interface (utilisateurs communs), ou via des algorithmes (utilisateurs avancés) ? Sur la base de notre expérience, nous formalisons l'adéquation ressentie de ces différents critères pour les différentes structures dans le tableau X. En plus de ces critères génériques, il convient également d'examiner spécifiquement l'adéquation entre la structure et la complexité de l'information que l'on souhaite structurer. En effet, toutes ne permettent pas d'aborder le même niveau de complexité, ni n'offrent les mêmes fonctionnalités.

Type de structure Stockage Représentation Manipulation directe

(via une interface)

Manipulation directe

(via des algorithmes)

Structures récursives + + - - + +
Enregistrements et tableaux à 2 dimensions + + + + + + + +
Tableaux simples à n (> 3) dimensions + - - - - + +
Tableaux liés (modèle entité/association) + + = - + +
Format de sérialisation textuel + + = - =
Format de sérialisation binaire + + - - - - -
Web de données + - - - - -
Blockchain + - - - - -
Images graphiques - - + + - - - -

Ontologie, modèle de données et programmation orientée objet

Notion d'ontologie

Les structures offrent différentes possibilités pour stocker et manipuler de manière opérationnelle des données. Elles vont pouvoir être utilisées dans les systèmes d'information. Toutefois, pour déterminer le type de structure adaptée à une application particulière, il est nécessaire d'expliciter l'information à manipuler. Pour cela, une approche courante consiste à définir l'ontologie de cette information. Selon les disciplines, une ontologie peut désigner différentes approches, mais avec une notion commune de la recherche du sens et de l'essence des choses. Du point de vue informatique, celui qui nous intéresse principalement pour aborder la question des données, une ontologie est la spécification d'une conceptualisation : Il s'agit de formaliser une vue abstraite et simplifiée du monde que l'on veut étudier à travers un nombre restreint de termes pour désigner les concepts mobilisés, leurs caractéristiques, leurs propriétés, et les relations qu'ils peuvent avoir entre eux (Gruber 1993).

La définition d'un ontologie permet la mise en place d'un vocabulaire commun utilisable pour partager des informations entre différentes personnes (chercheurs, gestionnaires, ...) et avec des machines (Noy & Mcguinness 2001). Une ontologie peut être implémentée sous forme de code informatique à travers notamment le modèle conceptuel de données (voir ci-après).

La pertinence d'une ontologie repose sur plusieurs points (Gruber 1993) : la clarté des concepts utilisés qui doivent être aussi objectifs que possible et notamment indépendants d'un contexte ; la cohérence de l'ontologie qui ne doit pas permettre d'inférer des raisonnements contradictoires ; l'extensibilité de l'ontologie et la possibilité d'ajouter de nouveaux concepts sans avoir à toucher aux fondements ; une déformation d'encodage minimale, c'est-à-dire limiter tant que possible la définition "forcée" d'un concept en modifiant son sens initial pour qu'il s'intègre dans l'ontologie ; un engagement ontologique minimal : chaque terme mobilisé ajoutant à la complexité de l'ontologie, il est nécessaire de peser l'usage de chacun pour s'assurer qu'il soit effectivement nécessaire pour décrire ce que l'on souhaite étudier. C'est un compromis en partie subjectif entre la quantité de vocabulaire utilisée que l'on souhaite minimiser et la complexité de la réalité que l'on souhaite décrire au maximum à l'aide de ce vocabulaire.

La définition d'une ontologie est le fruit d'un processus itératif dans lequel le vocabulaire est supposé, testé, validé, amélioré ... Dans leur guide, Noy & Mcguinness (2001) dressent différents points à aborder dans ce processus. Il s'agit notamment de déterminer les concepts clefs et leur terminologie mobilisés dans le domaine d'application pour lequel on veut définir une ontologie. Il faut ensuite définir les liens entre ces concepts, leurs propriétés et les règles qui régissent ces liens et propriétés pour garantir l'intégrité des données (par exemple des règles hiérarchiques ou d'exclusion). La réutilisation d'ontologies existantes permet également de renforcer la pertinence et le caractère partagé du vocabulaire utilisé.

Une ontologie a vocation a être générique (Spyns et al. 2002). Aussi, des ontologies peuvent être décrites en langage naturel. Toutefois, différents langages ont été développés spécialement pour la formalisation d’ontologies , comme OWL (Web Ontology Language) mobilisé à travers le web de données et qui permet de formaliser tout autant le vocabulaire et les propriétés, que des règles logiques entre ces différentes notions, tel que les inclusions, les contraires, les exclusions, les jonctions ... (Fléty & De Sède-Marceau 2009).

Modèles de données

Dans le processus d'implémentation d'un système d'information, l'ontologie permet de spécifier le vocabulaire, les liens et les règles qui permettent l'étude d'un domaine. Elle a un objectif de description générique et n'est pas nécessairement destinée à pouvoir être implémentée telle quelle dans un système d'information (Spyns et al. 2002). Des standards comme RDF ou ses dérivés visent à formaliser les ontologies pour les rendre opérationnelles. Toutefois, réaliser en même temps une description générique et un composant opérationnelle est un exercice complexe.

Les modèles de donnée ont quant à eux des objectifs plus opérationnels visant à décrire précisément l'information que l'on souhaite manipuler. On peut considérer trois niveaux de modèle de données, même si dans la pratique ils ne sont pas toujours explicitement distingués ou décrit comme tel. Du plus général au plus précis, nous avons : le Modèle Conceptuel de Données (MCD), le Modèle Logique (MLD) et le Modèle Physique (MPD).

Le premier (MCD), en raison de son niveau d'abstraction est finalement très proche de la définition d'une ontologie (Gruber 1993). La limite entre ontologie (surtout lorsqu'elles sont formalisées) et MCD n'est d'ailleurs pas forcément évidente, tous deux s'intéressant à décrire la sémantique d'un domaine (Spyns et al. 2002). La différence principale relève de l'intention : l'ontologie est plutôt orientée sur la recherche d'un consensus pour partager de l'information entre différents utilisateurs, tandis que le MCD est une première étape prescriptive pour construire la BDD d'un système d'information afin de respecter un cahier des charges (Pierra et al. 2005).

Il va s'agir ensuite de préciser le MCD pour constituer le MLD en formalisant les tables et les attributs. Ainsi, le MLD explicite la structure en tableaux liés présentée précédemment. Enfin, le dernier modèle, le MPD, précise en plus le typage des données (nombre, texte, ...) et vise à construire l'algorithme (souvent en SQL) qui va pouvoir être directement interprété par un SGBD pour implémenter concrètement la structure des données et la rendre opérationnelle.

Programmation orientée-objet

La constitution d'une base de données relationnelle (c'est-à-dire basée sur un modèle entité/association) et décrite de manière opérationnelle par les modèles de données est une approche classique dans l'implémentation d'un système d'information qui permet de stocker et extraire de grandes quantités de données (Dessaigne 2005). Toutefois, à ce stade de description, les interactions entre des algorithmes de traitement et une base de données reposent sur la construction de requêtes qui vont permettre d'extraire des données spécifiques des différentes tables sous forme individuelles, de listes ou de tableaux. Ces requêtes sont parfois complexes à construire, surtout lorsqu'elles interrogent des liens entre les tables. Il s'agit là d'une difficulté conceptuelle à manipuler directement des tableaux liés.

Le développement de l'informatique a toutefois permis l'émergence d'un paradigme permettant d'éviter de manipuler directement des tableaux : la programmation orientée-objet. Il s'agit de remplacer conceptuellement la manipulation des données à travers des tableaux par la manipulation de "paquets" (d'objets) de données (O'Neil 2008). Ces objets de données disposent de propriétés qui peuvent être des liens avec d'autres objets. Cette approche permet d'abstraire la complexité des jointures et des héritages entre différents tableaux, et permet un accès direct d'un concept à l'autre. A cela s'ajoute la possibilité d'associer des algorithmes à ces objets (des méthodes), permettant de leur implémenter des fonctionnalités propres qui vont permettre d'abstraire encore plus certains traitements.

La programmation orientée-objet offre un cadre plus intuitif pour le développement d'algorithmes et de réduire la complexité conceptuelle de la manipulation de l'information. Elle permet notamment de contourner plusieurs difficultés, qui peuvent entre autres survenir dans des études géographiques (Fonseca et al. 2002) : le partitionnement horizontal ou vertical des tableaux données, les changements de vue / de projection des données, le processus de zoom qui doit être discrétisé pour correspondre à différents niveaux de résolution. De plus, le paradigme orienté objet est fondamentalement compatible avec le modèle entité/association (Fonseca et al. 2002) et ne demande donc pas un travail supplémentaire de formalisation pour être implémenté. Les types d'entité d'un MEA ou les concepts d'une ontologie peuvent devenir simplement des classes d'objets caractérisés par leurs propriétés : des attributs littéraux ou des liens avec d'autres objets.

La POO et les BDDR restent cependant deux approches techniques distinctes. Au sein d'un SI peuvent donc cohabiter un modèle objet et un modèle de données distincts, charge aux concepteurs d'implémenter la logique des liens entre les deux modèles. Pourtant, au regard de leur compatibilité, il semble pertinent de vouloir manipuler une BDDR à travers la POO sur la base d'un modèle commun. Pour cela il est possible de mobiliser les techniques de mapping objet-relationnel (en anglais object-relational mapping - ORM) qui sont précisément destinées à cela. Elle prennent souvent la forme d'une librairie implémentant l'abstraction permettant la synchronisation entre les objets manipulés par les algorithmes et les données de la base. Cette solution nous permet de bénéficier à la fois des techniques de stockage performants des BDDR et de l'intuitivité offerte par la POO pour le développement d'algorithmes, même s'il n'est pas possible d'ignorer complètement les liens avec une BDD. En effet la construction des requêtes pour sélectionner les données ne peuvent souvent pas être totalement abstraites via la POO, ce sont surtout les requêtes de mise à jour qui peuvent l'être. L'usage d'un ORM pose aussi des problématiques spécifiques appelées décalage d'impédance ou impedance mismatch en anglais (O'Neil 2008) : à quel moment synchroniser les données, comment gérer le multi-accès, ... Toutefois, dans nos travaux, ces problématiques techniques ne sont pas particulièrement significatives au point d'être l'objet d'une attention particulière.

Entrepôts de données

Nous avons présenté des techniques qui permettent de structurer, stocker et exploiter une grande quantité de données complexes à travers un modèle de données à implémenter au sein d'un Systèmes de Gestion de Bases de Données (SGBD). Le développement de ces systèmes à partir des années 1970 ont ainsi permis de faciliter et d'accélérer les traitement de données pour les organisations, en permettant de rassembler en un lieu unique des données autrefois éparpillées dans différents fichiers (Inmon 2005). Toutefois, les capacités de calcul augmentant, la quantité de données manipulée a fait de même, menant à la multiplication des bases de données au sein des organisation. Cette multiplication, souvent menée de manière itérative sans vision à long terme, manque parfois de crédibilité. Ainsi, Inmon (2005) met en avant les problématiques qui résultent cette multiplication "naturelle" des bases de données : existence de données similaires, multiples définitions des périmètres d'étude, perte d'information suite à l'intégration de données extérieures, variabilité dans l'implémentation de méthode de traitements ... Tous ces facteurs peuvent amener des analyses similaires à des conclusions différentes, rendant ainsi instable la prise de décision à partir des résultats de ces analyses.

Pour rendre plus cohérentes les analyses entre elles et fiabiliser le processus de prise de décisions, Inmon propose en 1991 la mise en place d'"entrepôts de données" (EDD, ou base de données décisionnelle ; en anglais, data warehouse). Le principe est assez simple : il s'agit d'une base de données centralisée qui rassemble une synthèse transversale et standardisée des données situées dans les différentes bases opérationnelles existantes de l'entreprise, sans toutefois les remplacer. A la différence d'une BDD classique, les données stockées dans un EDD n'ont pas vocation à être modifiées ou supprimées (éventuellement, elle peuvent être synthétisées à nouveau pour l'archivage). L'EDD constitue ainsi une référence unique dans l'organisation sur lesquelles les analyses peuvent se baser pour répondre à des interrogations transversales. Cela simplifie grandement la recherche de données, réduit le risque d'incohérences et facilite la réitération des analyses dans d'autres contextes (temporels, géographiques, ...). En d'autres termes, cela permet une réduction des coûts liées à ces opérations.

L'implémentation d'un EDD repose sur la définition d'une ontologie puis d'un modèle conceptuel de données pour chacune des typologies d'information que l'on souhaite stocker (les "sujets"). Elle nécessite de définir également le niveau de détail que l'on souhaite conserver lors de l'agrégation de l'information (la "granularité"), ainsi que les standards à retenir (par exemple pour les identifiants, les dates, les localisations géographiques ...). Un EDD est souvent implémenté de manière itérative, en commençant à le rendre opérationnel pour un sujet en particulier, puis en l'étoffant au fur et à mesure avec d'autres sujets. A partir d'un certain niveau de développement, la taille et l'accès à l'EDD deviennent problématiques. S'en suit alors généralement la création de magasins de données qui vont extraire une partie des données de l'EDD selon un domaine métier particulier (finance, relation client, ...), afin de faciliter l'accès et l'usage de ces données dans le travail d'analyse.

L'alimentation en données d'un EDD est réalisée à travers des modules "extracto-chargeurs". L'objectif de ces modules et (1) extraire des données sources hétérogènes, généralement une base de donnée ou un tableur (2) réaliser des opérations sur ces données (conversion, nettoyage, synthèse selon une granularité donnée, ...), (3) charger les données transformées dans l'EDD. En anglais, on parle de techniques Extract / Transform / Load (ETL). Les ETL sont des éléments cruciaux pour le fonctionnement d'un EDD et leur conception peut représenter 80 % du temps de développement (Thomsen & Bach Pedersen 2009). Ils contribuent à assurer l'intégrité des données. La période de chargement doit être définie, et des précautions prises pour éviter de charger plusieurs fois des données identiques. Le respect de la granularité et du format des données de l'EDD est aussi assurée par ces modules.

Dans les cas les plus simples, les données sources prennent la forme d'enregistrements, et l'opération à mener consiste à mettre en correspondance les différents champs (ou noms de colonnes) avec le modèle de données de l'EDD, ce qu'on appelle parfois le mapping des données. Si les champs sont parfaitement équivalents, le travail de mise en correspondance peut être facilement réalisé avec une interface graphique (GUI - Graphic User Interface). Dans les cas les plus complexes, les données doivent être préparées pour correspondre au modèle de données avant de pouvoir être chargées dans l'EDD. L'usage d'une GUI peut alors ne pas être adapté pour répondre à la spécificité de toutes les opérations de préparation à mener. Le plus simple est souvent de mettre au point les ETL en développant directement les algorithmes adaptés, ouvrant ainsi la possibilité d'implémenter n'importe quelle approche tant qu'elle est conceptuellement formalisée (Assar 2015). De toutes manières, si préparation des données il doit y avoir, la tâche est souvent confiée aux personnes qui ont des compétences en termes de développement informatique et qui peuvent donc se passer d'une GUI (Thomsen & Bach Pedersen 2009).



Références

• Assar, S., 2015, Méthodes de recherche empirique en ingénierie des SI. Principes et applications, Revue des Sciences et Technologies de l'Information - Série ISI : Ingénierie des Systèmes d'Information, 20, pp. 11-33. Lavoisier. DOI : 10.3166/isi.20.6.11-33
• Berners-Lee, T., 2006, Linked Data (mis à jour en 2010). [En ligne] URL : https://www.w3.org/DesignIssues/LinkedData.html. Consulté le 19 avril 2018.
• Chen, P., 1976, The entity-relationship model - toward a unified view of data, ACM Transactions on Database Systems (TODS), 1, pp. 9-36. DOI : 10.1145/320434.320440
• Davis, C., 2017, Using Linked Data to facilitate translations between product and industry classifications. ISIE-ISSST 2017 Conference: Science in Support of Sustainable and Resilient Communities. [En ligne] URL : http://programme.exordo.com/isie2017/delegates/presentation/716/. Consulté le 19 avril 2018.
• Delahaye, J., 2015, Les blockchains, clefs d'un nouveau monde, Pour la Science, 449, pp. 80-85. [En ligne] URL : https://www.pourlascience.fr/sd/informatique/les-blockchains-clefs-daposun-nouveau-monde-8354.php. Consulté le 19 avril 2018.
• Dessaigne, N., 2005, Le modèle DOAN (DOcument ANnotation Model) Modélisation de l'information complexe appliquée à la plateforme Arisem Kaliwatch Server.. [En ligne] URL : https://tel.archives-ouvertes.fr/tel-00465962. Consulté le 19 avril 2018.
• Fléty, Y., De Sède-Marceau, M., 2009, Vers une géo-ontologie pour les Systèmes Énergétiques Territoriaux (SET), XVIe rencontres de Rochebrune sur les systèmes complexes naturels et artificiels : ontologie et dynamique des systèmes complexes, pp. 1-12. [En ligne] URL : https://hal.archives-ouvertes.fr/hal-00767229. Consulté le 19 avril 2018.
• Flichy, P., 2013, Rendre visible l'information, Réseaux, pp. 55-89. [En ligne] URL : http://www.cairn.info/revue-reseaux-2013-2-page-55.htm. Consulté le 19 avril 2018.
• Fonseca, F., Egenhofer, M., Davis, C., Câmara, G., 2002, Semantic granularity in ontology-driven geographic information systems, Annals of mathematics and artificial intelligence, 36, pp. 121-151. Springer. DOI : 10.1023/a:1015808104769
• Gruber, T., 1993, A translation approach to portable ontology specifications, Knowledge acquisition, 5, pp. 199-220. Elsevier. DOI : 10.1006/knac.1993.1008
• Inmon, W., 2005, Building the Data Warehouse. Wiley, 576 p.. [En ligne] URL : http://homes.dcc.ufba.br/~mauricio052/Material_Artigo/Building_The_Data_Warehouse_(2005)_Fourth_Edition-Inmon-Wiley.pdf. Consulté le 19 avril 2018.
• Ismayilov, A., Kontokostas, D., Auer, S., Lehmann, J., Hellmann, S., 2018, Wikidata through the Eyes of DBpedia, Semantic Web, 9, pp. 493-503. IOS Press. DOI : 10.3233/sw-170277
• Noy, N., Mcguinness, D., 2001, Ontology Development 101: A Guide to Creating Your First Ontology. [En ligne] URL : http://www-ksl.stanford.edu/people/dlm/papers/ontology-tutorial-noy-mcguinness.pdf. Consulté le 19 avril 2018.
• O'Neil, E., 2008, Object/Relational Mapping 2008: Hibernate and the Entity Data Model (Edm), SIGMOD '08, pp. 1351-1356. ACM. DOI : 10.1145/1376616.1376773
• Pavel, I., 2017, La blockchain - Les défis de son implémentation, pp. 20-24. [En ligne] URL : https://www.cairn.info/revue-realites-industrielles-2017-3-page-20.htm. Consulté le 19 avril 2018.
• Pierra, G., Dehainsala, H., Ameur, Y., Bellatreche, L., 2005, Bases de données à base ontologique. Principe et mise en oeuvre, Ingénierie des Systèmes d'Information, 10, pp. 91-115
• Spyns, P., Meersman, R., Jarrar, M., 2002, Data Modelling Versus Ontology Engineering, SIGMOD Rec., 31, pp. 12-17. ACM. DOI : 10.1145/637411.637413
• Sumaray, A., Makki, S., 2012, A Comparison of Data Serialization Formats for Optimal Efficiency on a Mobile Platform, ICUIMC '12, pp. 48:1-48:6. ACM. DOI : 10.1145/2184751.2184810
• Thévenot, J., 2001, Évolution des perspectives de la conception des SI : analyse longitudinale des enjeux et des réponses méthodologiques, Systèmes d'Information et Management, 6, pp. 117-132. DOI : 10.9876/sim.v6i2.103
• Thomsen, C., Bach Pedersen, T., 2009, Pygrametl: A Powerful Programming Framework for Extract-transform-load Programmers, DOLAP '09, pp. 49-56. ACM. DOI : 10.1145/1651291.1651301
• Valentin, A., Lancry, A., Lemarchand, C., 2010, La construction des échantillons dans la conception ergonomique de produits logiciels pour le grand public. Quel quantitatif pour les études qualitatives ?, Le travail humain, 73, pp. 261-290. Presses Universitaires de France. DOI : 10.3917/th.733.0261
• Waelbroeck, P., 2017, Les enjeux économiques de la blockchain, pp. 10-19. Annales des Mines - Réalités industrielles. [En ligne] URL : https://www.cairn.info/revue-realites-industrielles-2017-3-page-10.htm. Consulté le 19 avril 2018.


Notes de bas de pages

  1. Pour illustrer cela, prenons une photographie numérique du nombre 42 : les données codant l'image ne contiennent pas le nombre en lui-même, mais uniquement les pixels de l'image. C'est la lecture et l'interprétation de la photographie par une intelligence qui permettra de lire le nombre 42.
  2. Le découpage administratifs des territoires en a créé quelques uns à cheval sur d'autres : des communautés de communes sur deux départements, des territoires transfrontaliers, ... C'est pourquoi le modèle d'un arbre, bien qu'a priori bonne première approximation, ne convient pas tout à fait pour décrire l'organisation territoriale.
  3. Organisme international de standardisation à but non lucratif chargé de promouvoir la compatibilité des technologies du web.
  4. IGN : http://data.ign.fr/endpoint.html et EU Open Data Portal : https://data.europa.eu/euodp/en/sparql
  5. L'outil Gapminder propose dans ses outils un exemple de graphique dynamique représentant les pays du monde en 5D : https://www.gapminder.org/tools/
Faits relatifs à « Conception des systèmes d'information »
CiteRefCallRef needed +
KeyRefflichy2013 +, assar2015 +, thevenot2001 +, valentin2010 +, sumaray2012 +, chen1976 +, dessaigne2005 +, inmon2005 +, bernerslee2006 +, ismayilov2018 +, davis2017 +, delahaye2015 +, waelbroeck2017 +, pavel2017 +, gruber1993 +, noy2001 +, spyns2002 +, flety2009 +, pierra2005 +, oneil2008 +, fonseca2002 + et thomsen2009 +
PageLabelConception des systèmes d'information +