Introduction aux systèmes d'information

Pourquoi un Système d'Information ?

Toute organisation (une entreprise, un hôpital, une mairie, une école) manipule en permanence de l'information : des noms, des dates, des stocks, des résultats, des transactions. À petite échelle, un tableau Excel ou un classeur papier peut suffire. Mais dès que les volumes augmentent, que plusieurs personnes travaillent simultanément ou que des décisions stratégiques doivent s'appuyer sur des données fiables, il faut un système structuré : le Système d'Information.

Ce chapitre pose les bases conceptuelles qui justifient l'existence des bases de données : pourquoi on en a besoin, comment on les organise, et comment on structure les données qu'elles contiennent.

Définition d'un Système d'Information

Définition : Un Système d'Information (SI) est un ensemble structuré de moyens humains, matériels et logiciels permettant de collecter, stocker, traiter et diffuser l'information nécessaire au fonctionnement et au pilotage d'une organisation.

Le mot-clé ici est structuré : un SI n'est pas un simple tas de données, c'est un ensemble cohérent où chaque information a une place, un format et un rôle défini.

Le SI vise à :

• Assurer la bonne circulation de l'information entre les acteurs.
• Garantir la fiabilité, la sécurité, la disponibilité et la pertinence des données.
• Servir d'outil d'aide à la décision stratégique.

Ces trois objectifs se voient mieux sur un cas. Dans une PME de distribution, une commande saisie par un commercial décrémente le stock de l'entrepôt. Elle déclenche aussi une facture en comptabilité et apparaît le soir même dans le tableau de bord du directeur. C'est cela, le SI. Supprimer le SI ne supprime aucun de ces trois besoins : cela oblige seulement trois personnes à se transmettre la même information à la main, trois fois.

Les cinq fonctions du SI

Un système d'information repose sur cinq fonctions principales, qui forment un cycle de vie de la donnée :

• Collecte des données : saisie manuelle, capteurs, formulaires, API...
• Stockage : bases relationnelles, entrepôts de données, lacs de données.
• Traitement : calculs, tris, automatisations, croisement de données.
• Diffusion : interfaces utilisateur, tableaux de bord, exports.
• Protection : sécurité, confidentialité, sauvegardes, conformité RGPD.

Ces cinq fonctions sont interdépendantes : une donnée collectée mais mal stockée sera inutilisable ; une donnée bien stockée mais mal diffusée ne servira à personne ; une donnée non protégée peut compromettre toute l'organisation.

Limites des moyens traditionnels

Avant les SI modernes, les données étaient souvent gérées par des fichiers plats (.csv, .txt), des tableurs (Excel) ou des documents papier. Ces moyens ont les mêmes défauts, qui reviennent à chaque fois :

• Données redondantes et incohérentes
• Risque d'erreurs élevé lors des saisies manuelles
• Accès difficile ou non partagé entre collaborateurs
• Analyse manuelle, lente et limitée
• Sécurité peu fiable, absence de contrôle des accès

Une base de données évite ce problème : il n'y a qu'une seule source de vérité, que tous les acteurs autorisés consultent et modifient en même temps, chacun avec ses droits. Elle ne garde pas pour autant la mémoire de ce qui a changé : une modification remplace l'ancienne valeur. Savoir qui a changé quoi demande une trace construite exprès, par exemple une table d'historique remplie à chaque modification.

L'opendata : des données ouvertes

Définition : L'opendata désigne la mise à disposition de données accessibles à tous, dans des formats ouverts, gratuitement, et réutilisables par chacun pour tout usage, y compris commercial. Les seules conditions admises protègent la provenance et l'ouverture : citer la source, et parfois repartager sous la même licence.

Ouvert ne signifie pas prêt à l'emploi. Ce que la définition garantit, c'est le droit de réutiliser, pas le travail de préparation : un jeu opendata arrive avec ses trous, ses formats de date variables et ses libellés à uniformiser.

L'opendata est produit principalement par des acteurs publics (collectivités, ministères, agences nationales). En France, la loi pour une République numérique (7 octobre 2016) oblige les administrations à publier par défaut leurs principales bases de données. Les plus petites en sont dispensées (moins de 50 agents, et pour les collectivités moins de 3 500 habitants), et les données personnelles comme les secrets protégés restent exclus. Des entreprises ou associations publient aussi en opendata, volontairement.

Intérêts de l'opendata

• Transparence des institutions publiques
• Innovation : permet à des développeurs et chercheurs de créer de nouveaux services
• Développement de services numériques à partir de données réelles
• Participation citoyenne et contrôle démocratique

Interroger l'opendata depuis un programme

La plupart des plateformes opendata proposent des API (interfaces de programmation), qui permettent d'interroger les données directement depuis un programme. data.gouv.fr décrit chaque jeu de données par une API, et son API tabulaire rend directement en JSON les lignes des fichiers CSV publiés, prêtes à être importées dans une base.

C'est précisément le principe d'une base alimentée par l'extérieur : récupérer des données réelles, les stocker, puis les analyser par des requêtes SQL.

Réutiliser un jeu de données, c'est accepter sa licence. La Licence Ouverte, celle de data.gouv.fr, demande de citer la source et la date de dernière mise à jour ; l'ODbL, autre licence courante, demande en plus de publier sous la même licence une base qui en dérive, si on la diffuse.

Organisation des projets SI : WBS et OBS

Tout projet SI, aussi petit soit-il, demande une organisation claire. Que faut-il produire ? Qui fait quoi ? Deux outils complémentaires répondent à ces deux questions : le WBS et l'OBS.

WBS (Work Breakdown Structure)

Définition : Le WBS (structure de décomposition du travail) découpe hiérarchiquement tout ce que le travail doit produire, en livrables de plus en plus fins. Il facilite la planification, l'estimation des charges et l'affectation des ressources.

Le WBS répond à la question : « Qu'est-ce qui doit être produit ? » Il ne liste pas des actions, mais des livrables : des éléments concrets et mesurables, dont on peut constater qu'ils sont terminés.

Regarder ce que contient chaque ligne plutôt que la profondeur de l'arbre : aucune ne décrit une action. « Dictionnaire de données » est un livrable, « rédiger le dictionnaire » serait une activité. C'est cette différence qui rend un WBS utilisable : un livrable se constate terminé, une activité s'étire sans qu'on sache jamais où elle en est.

Le premier mot ne suffit pas toujours à trancher. « Insertion des données » ne commence pas par un verbe et décrit pourtant une action. Le test qui tranche est celui du constat : peut-on dire, à une date donnée, que c'est fini ? « Base peuplée des relevés » se constate, « insertion des données » non.

OBS (Organizational Breakdown Structure)

Définition : L'OBS (structure de décomposition organisationnelle) représente les rôles et responsabilités dans un projet, sous forme hiérarchique. Elle permet d'identifier les acteurs et d'établir des matrices de responsabilité (ex : matrice RACI).

L'OBS répond à la question : « Qui est impliqué et à quel titre ? » Elle ne liste pas des personnes par leur nom, mais par leur rôle dans le projet.

Légende :

• R (Responsible) : la personne qui réalise la tâche
• A (Accountable) : la personne qui valide et porte la responsabilité finale
• C (Consulted) : la personne qui est consultée pour son expertise
• I (Informed) : la personne qui est simplement informée de l'avancement

Lire cette matrice ligne par ligne, et non colonne par colonne. Sur la ligne MCD, le modélisateur réalise et le chef de projet valide : ce sont deux rôles distincts, et c'est ce découplage qui permet de refuser un livrable sans refaire le travail. La ligne Guide d'utilisation porte en revanche trois R et aucun A : elle signale une tâche que tout le monde réalise et que personne ne valide. La règle d'or ci-dessous dit pourquoi c'est un défaut, et comment le réparer : désigner un seul A.

À retenir. Le WBS décompose ce qui doit être produit (les livrables).
L'OBS définit qui fait quoi (les rôles et responsabilités).
Croisés, ils permettent d'affecter précisément chaque livrable à chaque membre de l'équipe.

Règle d'or de la RACI : chaque tâche doit avoir exactement un seul Accountable. S'il y en a plusieurs, personne n'est vraiment responsable ; s'il n'y en a aucun, personne ne peut déclarer la tâche finie. Plusieurs R sur une même ligne, en revanche, ne posent aucun problème.

Organisation et classification des données

Le dictionnaire de données

Définition : Un dictionnaire de données centralise la description de toutes les données du système : nom, type, taille, signification et contraintes éventuelles. Il garantit une compréhension partagée et une gestion rigoureuse des informations entre tous les membres du projet.

Le dictionnaire de données est le document de référence du projet : avant d'écrire la moindre ligne de SQL, il faut savoir exactement quelles données seront manipulées. C'est aussi un outil de communication entre les différents acteurs (développeurs, métier, direction).

Lire la colonne Contraintes en premier : c'est elle qui porte les règles du métier, les autres ne décrivant que du stockage. Le CHECK ≥ 0 de concentration_ppm dit qu'une concentration négative n'a aucun sens physique, et cette case deviendra telle quelle une contrainte SQL. Une case Contraintes vide est presque toujours un oubli, rarement une absence de règle.

Catégorisation des données

Toutes les données ne jouent pas le même rôle dans un SI. On distingue trois grandes catégories :

Dans la PME de distribution évoquée plus haut, la liste des fournisseurs est une donnée de référence, chaque bon de livraison une donnée transactionnelle, et la date d'import du catalogue fournisseur une méta-donnée. Les trois ne se mettent pas à jour au même rythme, ne se sauvegardent pas de la même façon, et ne se suppriment pas dans les mêmes conditions.

Cette distinction commande la conception de la base : les données de référence iront dans des tables séparées, partagées par toutes les autres via des clés étrangères.

Ce que coûte une donnée de référence recopiée se chiffre avant d'avoir à le payer, et le volume des données transactionnelles se prévoit de la même façon.

Dépendances fonctionnelles

Les dépendances fonctionnelles sont la notion la plus abstraite de ce chapitre, mais aussi l'une des plus fondamentales : elles sont à la base de toute modélisation relationnelle correcte.

Définition : Une dépendance fonctionnelle relie deux attributs, ou deux groupes d'attributs : A détermine B si à chaque valeur de A correspond une et une seule valeur de B. Notation : A → B (« A détermine B »)

Autrement dit : connaître la valeur de A suffit à en déduire celle de B, de façon certaine et unique.

Ce tableau se lit vite, et c'est son défaut : il demande de croire sur parole. Une dépendance fonctionnelle ne se décrète pas, et des lignes ne suffisent pas à la prouver : elles peuvent seulement la réfuter. Le geste qui la met à l'épreuve tient pourtant en un mouvement : regrouper les lignes par la partie gauche, puis regarder si la partie droite reste constante dans chaque groupe.

Les deux boutons portent la même paire d'attributs, dans les deux sens, et un seul tient. ville → codeInsee est réfutée, et ce ne sont pas des mots : Saint-Denis est une commune de Seine-Saint-Denis et une commune de La Réunion. Une seule contradiction suffit. codeInsee → ville tient sur ces lignes, mais ce ne sont pas elles qui la rendent vraie : c'est la règle de l'INSEE, qui donne un code à chaque commune, et à une seule.

Le code postal, qui ressemble tant au code INSEE, ne détermine pas la commune : 33650 dessert La Brède, Martillac et cinq autres communes. Quatre lignes où il semblerait tenir n'auraient rien prouvé.

Comment identifier une dépendance fonctionnelle ?

Le test tient en trois temps : formuler la question, la confronter au métier, conclure.

La deuxième étape est la seule qui décide, et elle ne se tranche pas sur les données : elle se tranche avec le métier. Si l'agence déplaçait ses stations d'une ville à l'autre, la même dépendance deviendrait fausse sans qu'aucune ligne du tableau n'ait changé.

Dépendances fonctionnelles composées

Parfois, une seule colonne ne suffit pas à déterminer une autre. Il faut alors une combinaison de colonnes :

La figure suivante le montre sur des relevés. Trois dépendances sont déclarées : deux fausses, une vraie.

La station seule ne suffit pas, la date seule non plus. Le couple, lui, n'est contredit par aucune ligne, mais sur quatre lignes il ne pouvait guère l'être : chaque couple n'y apparaît qu'une fois. Ce qui en fait la clé primaire, c'est la règle du relevé, une seule mesure par station et par jour.

Noter au passage la troisième colonne, nom_ville. Elle dépend bien du couple, mais une partie du couple suffit : la station seule la détermine. Cette dépendance à une partie de la clé annonce la deuxième forme normale du chapitre sur la normalisation.

À retenir. Pour vérifier une dépendance fonctionnelle A → B, se poser la question :
« Est-ce que connaître A permet de déterminer B de façon unique et certaine ? »
C'est le métier qui répond. Les données, elles, ne peuvent que réfuter : une seule ligne contraire suffit, et aucun nombre de lignes conformes ne prouve rien.

La clé suit ce que représente une ligne, et c'est quand ce sens change que l'erreur se glisse.

Ressources complémentaires

• Systèmes d'information, Wikipédia
• data.gouv.fr, Portail opendata français
• Introduction aux systèmes d'information (vidéo)
• Licence Ouverte 2.0, data.gouv.fr