Introduction aux Systèmes d'Information (SI)
- Comprendre ce qu'est un Système d'Information
- Identifier les cœurs de métier du SI
- Connaître les limites des moyens traditionnels de gestion de données
- Comprendre l'intérêt et les enjeux de l'opendata
- Comprendre les notions de WBS et d'OBS dans un projet SI
- Savoir définir, organiser et classer les données d'un système
- Identifier les dépendances fonctionnelles
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
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.
Les cœurs de métier 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, APIs...
- Stockage : bases relationnelles, entrepôts de données, data lakes.
- 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.
- Collecte : un capteur mesure la concentration en CO₂ toutes les heures.
- Stockage : la valeur est enregistrée dans une base de données avec l'horodatage et l'identifiant de la station.
- Traitement : on calcule la moyenne journalière et on détecte les pics anormaux.
- Diffusion : un tableau de bord affiche une alerte si le seuil dépasse 400 ppm.
- Protection : les données sont sauvegardées chaque nuit et l'accès est réservé aux agents habilités.
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.
- 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
- Agent A envoie
mesures_v1.xlsxà Agent B. - Agent B modifie et renvoie
mesures_v2_modif_final.xlsx. - Agent A a, entre-temps, continué à remplir sa propre version.
- Résultat : deux fichiers incompatibles, des données perdues, aucune traçabilité.
Une base de données évite ce problème : il n'y a qu'une seule source de vérité, accessible simultanément par tous les acteurs autorisés, avec un historique complet des modifications.
L'opendata : des données ouvertes
L'opendata est produit principalement par des acteurs publics (collectivités, ministères, agences nationales) qui ont l'obligation légale de rendre leurs données accessibles aux citoyens. Des entreprises ou associations peuvent également publier leurs données en opendata.
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
- Données de qualité de l'air par région (contexte du projet)
- Statistiques de population par commune
- Horaires et tracés des transports en commun
- Résultats électoraux, données météorologiques, dépenses publiques...
C'est précisément ce principe que vous utiliserez dans votre projet : récupérer des données réelles, les stocker dans votre base, puis les analyser via des requêtes SQL.
Organisation des projets SI : WBS et OBS
Tout projet SI, aussi petit soit-il, nécessite une organisation claire : que faut-il produire ? Qui fait quoi ? Ces deux questions sont répondues par deux outils complémentaires : le WBS et l'OBS.
WBS (Work Breakdown Structure)
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 qui seront livrés à la fin de chaque tâche.
- Niveau 1 : Projet base de données ClearData
- Niveau 2 : Modélisation
- Niveau 3 : Dictionnaire de données
- Niveau 3 : MCD (Modèle Conceptuel de Données)
- Niveau 3 : MLD (Modèle Logique de Données)
- Niveau 2 : Implémentation
- Niveau 3 : Script SQL de création
- Niveau 3 : Insertion des données
- Niveau 2 : Requêtes SQL
- Niveau 2 : Soutenance
- Niveau 2 : Modélisation
OBS (Organizational Breakdown Structure)
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.
| Tâche | Chef de projet | Modélisateur | Développeur SQL |
|---|---|---|---|
| MCD | A | R | C |
| Script SQL | C | I | R |
| Soutenance | R | R | R |
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
L'OBS définit qui fait quoi (les rôles et responsabilités).
Croisés ensemble, ils permettent d'affecter précisément chaque tâche à 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.
Organisation et classification des données
Le dictionnaire de données
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 on va manipuler. C'est aussi un outil de communication entre les différents acteurs (développeurs, métier, direction).
| Nom | Signification | Type | Taille | Contraintes |
|---|---|---|---|---|
id_agent | Identifiant unique de l'agent | Entier | - | PK, NOT NULL, AUTO_INCREMENT |
nom | Nom de famille de l'agent | Texte | 50 car. | NOT NULL |
prenom | Prénom de l'agent | Texte | 50 car. | NOT NULL |
date_embauche | Date d'entrée dans l'agence | Date | - | NOT NULL |
concentration_ppm | Concentration du gaz mesurée | Décimal | 10,4 | CHECK ≥ 0 |
date_mesure | Date de la mesure | Date | - | NOT NULL |
- Utilisez des noms explicites et en minuscules, sans accents ni espaces (ex :
date_embaucheplutôt queDateE). - Documentez toujours les contraintes métier (une concentration ne peut pas être négative, un code postal a 5 chiffres...).
- Identifiez clairement les clés primaires (PK) : ce sont les colonnes qui identifient de manière unique chaque ligne.
- Mettez à jour le dictionnaire au fur et à mesure du projet : un dictionnaire obsolète est pire qu'aucun dictionnaire.
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 :
| Type de données | Description | Exemple |
|---|---|---|
| Données de référence | Stables, peu modifiées. Servent de référentiel commun. | Liste des régions, types de gaz, codes INSEE |
| Données transactionnelles | Résultent d'actions métier, volumineuses et dynamiques. | Mesures de pollution, commandes, rapports produits |
| Méta-données | Décrivent d'autres données (contexte, provenance, format). | Auteur d'un rapport, date de création, source du jeu de données |
Cette distinction est importante pour la conception de la base : les données de référence seront dans des tables séparées, partagées par toutes les autres tables via des clés étrangères.
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.
Notation : A → B (« A détermine B »)
Autrement dit : si je connais la valeur de A, je peux en déduire la valeur de B de façon certaine et unique.
| Expression | Interprétation | Valide ? |
|---|---|---|
NumEtudiant → Nom | Chaque numéro d'étudiant correspond à un nom unique | ✅ Oui |
CodePostal → Ville | Un code postal correspond à une seule ville | ✅ Oui |
Ville → CodePostal | Une ville peut avoir plusieurs codes postaux | ❌ Non |
id_mesure → concentration_ppm | Chaque mesure a une seule valeur de concentration | ✅ Oui |
Nom → NumEtudiant | Deux étudiants peuvent avoir le même nom | ❌ Non |
Comment identifier une dépendance fonctionnelle ?
La méthode est simple : posez-vous la question en deux temps.
id_station → nom_ville ?- Formulation : "Est-ce que connaître l'identifiant d'une station me permet de savoir dans quelle ville elle se trouve ?"
- Vérification : Oui, chaque station est physiquement installée à un seul endroit.
- Conclusion : La dépendance
id_station → nom_villeest valide ✅
Dépendances fonctionnelles composées
Parfois, une seule colonne ne suffit pas à déterminer une autre. Il faut alors une combinaison de colonnes :
(id_station, date_mesure) → concentration_ppmCela signifie : "pour une station donnée à une date donnée, la concentration est unique". C'est ce couple qui forme la clé primaire de la table des mesures.
« Est-ce que connaître A permet de déterminer B de façon unique et certaine ? »
Si oui, la dépendance est valide.
Les dépendances fonctionnelles sont fondamentales pour :
- Choisir les clés primaires des tables
- Éviter les redondances (stocker la même info à plusieurs endroits)
- Préparer la normalisation de la base (1NF, 2NF, 3NF - abordées au chapitre suivant)