Compétence 04 / 06 — BUT Informatique

Gérer des données
de l'information

Concevoir, gérer, administrer et exploiter les données de l'entreprise en respectant les réglementations sur la protection des données personnelles. Composantes essentielles : respecter la protection des données (RGPD), s'appuyer sur des fondements mathématiques solides, assurer la cohérence et la qualité des données.

Voir les preuves
2026
Vue d'ensemble

3 preuves,
conception,
optimisation, terrain.

Trois angles sur la gestion des données : la conception complète d'un modèle relationnel avec conformité RGPD, l'optimisation des accès à une base existante (PDO, index, cache), et la gestion de données géographiques sensibles en contexte professionnel — données internes confidentielles articulées avec des API publiques.

MyPulse — Modélisation & RGPD App Vote — Optimisation SQL Stage CENCA — Données géographiques
Preuves d'acquisition
Preuve 01 / 03 — SAE S3, Janvier 2026

MyPulse — Modélisation des données et conformité RGPD

Conception complète du modèle de données : ERD 11 entités, dictionnaire de données, roadmap MVP, et rapport juridique RGPD (cartographie des traitements, mesures techniques, CGU, politique de confidentialité).

MySQL ERD RGPD Privacy by design PDO

Contexte et ressources mobilisées

SAE S3 — produire deux livrables complémentaires : un dossier descriptif de la base (modélisation) et un rapport juridique (conformité RGPD). Cours : normalisation (1NF/2NF/3NF), RGPD, guide CNIL «Privacy by Design». Outil : draw.io pour les ERD.

Activités et implication

  • ERD 11 entités : Utilisateur, MembreCertifié, Contenu, Vote (UNIQUE sur utilisateur×contenu×catégorie), Résultats, Notification, Catégorie + 4 tables de liaison
  • Dictionnaire de données : pour chaque attribut — type SQL, contraintes (NOT NULL, UNIQUE, DEFAULT), description métier
  • Conformité RGPD : cartographie des données traitées (identification, technique, vote), minimisation, hachage bcrypt, séparation inscription/urne (anonymat des votes)
  • Livrables juridiques : mentions légales, CGU, politique de confidentialité, gestion des consentements cookies

Apprentissages clés

  • Privacy by design : la séparation inscription/urne a été décidée dès la modélisation — pas ajoutée après coup
  • ERD → SQL : passage du diagramme conceptuel au schéma physique (types, index, contraintes d'intégrité)
  • Contraintes métier en BDD : la règle «un vote unique par utilisateur par catégorie» est une contrainte UNIQUE composite — pas du code applicatif

Traces sélectionnées

Diagramme ERD complet

11 entités avec cardinalités, clés primaires/étrangères et contraintes d'intégrité.

Cartographie RGPD

Tableau des données traitées avec finalités, durées de conservation et mesures de protection associées.

Dossier descriptif BDD (PDF) Rapport juridique RGPD (PDF) Retour en haut
Preuve 02 / 03 — SAE S4 (volet données)

App Vote — Accès sécurisé et optimisé aux données

Refactoring de la couche données d'une application PHP héritée : migration vers PDO (requêtes préparées), élimination des N+1 par JOIN, indexation SQL, pagination server-side. Résultats mesurés avant/après avec EXPLAIN.

PDO MySQL JOIN Index SQL EXPLAIN Pagination

Contexte et ressources mobilisées

L'application héritée utilisait des concaténations SQL directes, sans index, avec des N+1 non détectés. Objectif : identifier et corriger avec métriques avant/après. Outils : EXPLAIN MySQL, documentation PDO, profiling PHP.

Activités et implication

  • PDO : remplacement de toutes les concaténations SQL par des requêtes préparées (bindParam) — élimination des risques d'injection SQL
  • Élimination N+1 : de 4-6 requêtes/page à 1 par JOIN — ex. candidats + comptage de votes en une seule requête
  • Indexation : EXPLAIN avant (type=ALL, rows=1500) → après CREATE INDEX (type=ref, rows=12) sur colonnes filtrées et de tri
  • Pagination : SQL LIMIT/OFFSET (12 items/page), calcul COUNT(*) total — seule la page courante est chargée

Apprentissages clés

  • Mesurer avant d'optimiser : EXPLAIN révèle les goulots réels — N+1 > indexation > cache en termes d'impact
  • PDO : sécurité et performance ne s'opposent pas — les requêtes préparées sont aussi plus efficaces (plan réutilisé)
  • Pagination SQL vs. filtrage client : charger toutes les données puis filtrer côté client est un antipattern courant

Traces sélectionnées

EXPLAIN avant / après indexation

type=ALL rows=1500 → type=ref rows=12 après CREATE INDEX — lecture sélective par index.

Refactoring N+1 → JOIN

Extrait de code : boucle initiale avec N requêtes vs. version refactorisée avec un seul JOIN et comptage.

Rapport SAE S4 (PDF) Retour en haut
Preuve 03 / 03 — Stage CENCA, 2025-2026

Stage CENCA — Données géographiques confidentielles & API publiques

Dans le cadre du développement de l'application Atlas (CENCA), gestion de données sensibles internes (sites naturels, actes notariaux) tout en intégrant des API publiques géographiques (IGN, cadastre). La confidentialité des données de l'association devait être préservée en toutes circonstances.

PostgreSQL + PostGIS API REST IGN API Cadastre Données géographiques

Contexte et ressources mobilisées

CENCA (Conservatoire d'espaces naturels de Champagne-Ardenne) — application Atlas remplaçant MS Access pour la gestion de 314 sites naturels protégés (5 150 ha), des actes notariaux et des données foncières. Données internes confidentielles ; API publiques : IGN (données géographiques nationales) et API cadastrale (données parcellaires). Stack : Node.js/PostgreSQL + PostGIS.

Activités et implication

  • Séparation des sources : données internes (sites, actes notariaux, propriétaires) stockées en base privée PostGIS — jamais transmises aux API externes
  • Intégration IGN/Cadastre : les API publiques fournissent uniquement les données de référence (géolocalisation de parcelles, contours cadastraux) pour auto-compléter les formulaires
  • PostGIS : stockage et requêtage des données géographiques (polygones de sites, coordonnées GPS) avec extensions spatiales SQL
  • Confidentialité : aucune donnée nominative ou patrimoniale (actes, propriétaires) n'est envoyée à des services tiers — seuls les identifiants cadastraux publics transitent

Apprentissages clés

  • Articuler données internes sensibles et API publiques : définir précisément ce qui peut transiter hors du système et ce qui ne le peut pas
  • PostGIS : les données géographiques nécessitent des types et requêtes spécialisés (ST_Contains, ST_Intersects) que SQL standard ne couvre pas
  • Confidentialité comme contrainte de conception : chaque flux de données doit être analysé avant d'être implémenté, pas après

Traces sélectionnées

Site naturel protégé — CENCA Champagne-Ardenne Contexte CENCA — données géographiques

314 sites naturels (5 150 ha) gérés par l'association : la nature des données (géographiques, foncières, notariales) impose une séparation stricte des flux internes et publics.

Architecture des données — rapport de stage

Schéma des flux : données internes PostGIS, appels API IGN/cadastre, séparation des périmètres de confidentialité — documenté dans le rapport de stage (PDF).

Rapport de stage (PDF) Retour en haut
← C3 — Administrer C4 / 06 C5 — Conduire →