UE4 - Gérer des données

Concevoir et exploiter des bases de données

L'Oracle

Je vous présente L'Oracle

Difficile de trouver plus approprié : l'Oracle voit l'avenir, mais ne le donne jamais directement — il faut savoir poser la bonne question pour obtenir la réponse qu'on cherche vraiment. Remplacez « avenir » par « donnée » et « poser la question » par « écrire une requête SQL » : vous avez l'idée.

Le clin d'œil est aussi technique : Oracle est aussi le nom d'un des SGBD les plus utilisés au monde. Le personnage et le moteur partagent une manière de répondre — tout est déjà dans la table, il suffit de savoir où chercher.

Qu'est-ce que l'UE4 ?

"Gérer des données", c'est l'UE des bases de données : les concevoir, les structurer, les interroger. Il ne suffit pas que la donnée existe, il faut savoir où elle est rangée et surtout savoir poser la bonne question pour la retrouver. Une requête mal écrite donne une réponse juste mais inutile ; une requête bien pensée révèle exactement ce qu'on cherchait.

Mes projets SAE

Anime Rivals — SAE 2e année

Contexte : Projet de création d'un jeu de cartes web avec gestion de données complexes (cartes, joueurs, decks, progression). Le jeu repose sur un système original avec des règles entièrement repensées.

Ce qui a été fait : Participation à la conception des données avec la réalisation du MCD. Structuration des entités principales du jeu (cartes, attributs, decks, joueurs). Mise en place de la gestion des decks et des interactions entre les données pendant une partie.

Difficultés : Concevoir un modèle de données suffisamment flexible pour permettre l'évolution du jeu (ajout de cartes, gestion des attributs) tout en garantissant la cohérence.

Ce qui a été appris : Le projet a permis de développer une vision structurée des données, la capacité à concevoir un modèle cohérent à partir d'un besoin concret, et l'anticipation des interactions entre les différentes entités. Le MCD a servi de base solide pour l'ensemble du développement.

Ressenti : Partie essentielle du projet, souvent moins visible mais indispensable au bon fonctionnement global.

Voir le projet →

Junior DEV — Gestion des conventions et remboursements

Contexte : Projet SAE sur la modélisation de données et le SQL pour gérer une Junior-Entreprise. L'application devait couvrir étudiants, entreprises, conventions, acomptes, frais, remboursements, factures et bulletins d’indemnité.

Ce qui a été fait : Conception du modèle relationnel et des tables principales : étudiants, entreprises, conventions, frais, acomptes, remboursements, factures et types de frais. J'ai structuré les relations entre étudiants, entreprises et conventions pour garantir la cohérence des données.

Difficultés : Mettre en place des contraintes SQL avancées (CHECK, clés primaires, clés étrangères) tout en conservant une structure souple pour les flux de remboursement et les liens entre les entités.

Ce qui a été appris : J'ai renforcé ma maîtrise du SQL et de la modélisation relationnelle, en particulier pour gérer des processus métiers complexes comme les conventions de stage, la facturation et les remboursements.

Ressenti : Projet très formateur sur la gestion des données réelles et l'importance des relations entre tables. C'est un bon exemple de base solide nécessaire avant de développer l'interface.

📊 SAE – Tableau de bord Power BI & Présentation orale

Contexte : Dans le cadre d’une SAE transverse, nous avons travaillé sur un jeu de données volumineux (ventes, produits, régions, périodes). L’objectif était de construire un tableau de bord interactif sous Power BI, puis de le défendre lors d’une présentation orale devant un jury composé d’enseignants et d’un professionnel du secteur.

Ce qui a été fait : J’ai pris en charge l’intégralité de la chaîne de traitement : nettoyage et transformation des données avec Power Query, modélisation en étoile (tables de faits et dimensions), création de mesures DAX personnalisées (Chiffre d’Affaires, Marge brute, Taux de conversion, Évolution mensuelle). J’ai ensuite conçu des visuels dynamiques (histogrammes, cartes géographiques, KPI, filtres croisés) en veillant à la clarté et à l’esthétique du dashboard. Enfin, j’ai préparé un support de présentation synthétique pour accompagner l’oral.

Difficultés : Le principal défi a été de choisir le type de graphique le plus pertinent pour chaque indicateur (un diagramme en bâtons n’est pas toujours la meilleure solution). Il a aussi fallu maîtriser les formules DAX les plus complexes (CALCULATE, FILTER, TIME INTELLIGENCE) pour répondre aux questions métier. Enfin, la gestion du temps de parole (10 minutes chrono) a exigé un vrai travail de synthèse pour ne pas survoler les points techniques tout en restant compréhensible.

Ce qui a été appris : La visualisation ne se limite pas à faire de « beaux graphiques » ; elle doit raconter une histoire et répondre à une problématique métier précise. J’ai compris l’importance de la phase d’exploration en amont pour éviter les erreurs de relation entre les tables. L’exercice oral m’a aussi appris à vulgariser des concepts techniques (jointures, filtres contextuels) devant un public varié, et à justifier chaque choix de conception avec des arguments concrets.

Compétences mobilisées :

  • • AC 4.04.01 – Optimiser les modèles de données (choix du schéma en étoile, optimisation des relations).
  • • AC 4.04.03 – Organiser la restitution de données (création d’un dashboard interactif adapté aux besoins décisionnels).
  • • AC 4.04.04 – Assurer la confidentialité des données (anonymisation des données sensibles avant traitement).
  • • AC 6.01.02 – Présenter oralement un travail technique en adoptant un vocabulaire adapté au public (jury mixte).

Ressenti : C’était la première fois que je voyais des données « prendre vie » de manière aussi parlante. Pouvoir interagir avec les filtres et observer les tendances en temps réel procure une vraie satisfaction. L’oral, bien que stressant, a été une excellente expérience pour prendre confiance et structurer ma pensée. Je suis fier du dashboard final et des retours positifs du jury sur la clarté des visuels.

Expériences professionnelles

Stage SNCF — Conception et modélisation de la base Ripley

Contexte : Stage SNCF Voyageurs — Projet Ripley. La base de données du projet a été conçue selon la méthode Merise complète (MCD, MCT, MLD, MPD), avec validation de chaque étape par l'équipe DBA avant de poursuivre. Exploration parallèle d'un schéma timeseries.

Ce qui a été fait : Conception selon la méthode Merise complète. J'ai aussi exploré en parallèle un schéma alternatif en paradigme timeseries, dont la principale difficulté était l'absence quasi-totale de ressources méthodologiques formalisées sur internet comparé aux bases relationnelles. La conception a impliqué de nombreux échanges avec l'équipe DBA : pas parce que je ne savais pas modéliser, mais parce que les DBA ne travaillent pas tous sur les mêmes projets ni les mêmes moteurs — leurs opinions divergeaient parfois, et trouver le bon compromis entre leurs besoins respectifs faisait partie du travail. Le choix du moteur PostgreSQL a été déterminant : sa commande COPY FROM a structuré toute la stratégie d'insertion des données.

Difficultés : Découverte du MCT (Modèle Conceptuel de Traitement) : notion Merise non enseignée à l'IUT. Trouver une méthodologie pour la conception timeseries. Concilier les opinions divergentes des DBA sur certains choix de modélisation. Gérer le stockage de valeurs mixtes (numériques et textuelles) pour les métriques BD sans alourdir le schéma.

Ce qui a été appris : Une base industrielle orientée volumétrie n'est pas une base académique : la complétude du modèle passe au second plan derrière la capacité à ingérer de grandes quantités de données rapidement. Le MPD n'est pas neutre : choisir PostgreSQL pour sa commande COPY FROM a structuré toute la stratégie d'insertion. L'intérêt de la validation par étapes (chaque modèle validé avant de passer au suivant). Que les 12 modèles de Merise existent et que certains ont du sens en contexte pro.

AC validés : AC 4.04.01 (optimiser les modèles de données), AC 4.04.02 (assurer la confidentialité des données), AC 4.04.03 (organiser la restitution de données).

Ressenti : C'est la partie du stage dont je suis le plus fier. Concevoir une base de données pour une équipe d'experts DBA, faire valider ses choix par des professionnels qui ont 20 ans d'expérience — et que ça tienne — c'est une vraie fierté.

Interface SQL Junior DEV

Simulateur graphique de l'interface de gestion basée sur le script projet_junior_dev.sql.

Requête SQL

Requêtes rapides

Note : cette interface est un prototype visuel. La connexion réelle au script SQL nécessite un serveur ou une API SQL côté backend.

Résultats

Exécutez une requête pour afficher les résultats.

Tables présentes

  • SAE_ETUDIANT
  • SAE_ENTREPRISE
  • SAE_FICHE_CONVENTION
  • SAE_FACTURE
  • SAE_FRAIS
  • SAE_FICHE_REMB_FRAIS
  • SAE_ACOMPTE
  • SAE_TYPE_FRAIS
  • PARTICIPER

Relations clés

  • SAE_ETUDIANT ↔ SAE_FICHE_CONVENTION
  • SAE_ENTREPRISE ↔ SAE_FICHE_CONVENTION
  • SAE_FICHE_CONVENTION ↔ SAE_FACTURE
  • SAE_FICHE_CONVENTION ↔ SAE_FRAIS
  • SAE_FRAIS ↔ SAE_FICHE_REMB_FRAIS
  • SAE_ETUDIANT ↔ SAE_ACOMPTE
L'Oracle

« Tu es venu me demander une réponse que tu connais déjà. Elle était là, dans la table, avant même que tu n'écrives ta clause WHERE. La seule question, c'est : as-tu fait le bon JOIN pour la voir ? »

— L'Oracle