-- Mes preuves --

InnotechFusion était une étude de cas d’entrainement qui posait une contrainte intéressante : concevoir une base de données V1 volontairement minimaliste, tout en produisant un schéma prévisionnel V2 capable d'accueillir la gestion de plusieurs scrutins et l'enregistrement anonyme des votes. Deux niveaux de réflexion distincts : ce dont l'application a besoin aujourd'hui, et ce qu'elle devra supporter demain sans tout reconstruire. La V1 se limitait à une table de membres avec les informations personnelles et un champ booléen d'émargement. La V2 demandait d'anticiper des relations entre scrutins, bulletins anonymisés et membres, sans jamais permettre de reconstituer le lien entre un vote et son auteur. Ce schéma prévisionnel a été livré avec le projet, documenté et versionnée dans le repository. Projet réalisé seul, de A à Z, en conditions d’examen. ShopWise était une étude de cas d’examen qui a été l'occasion de modéliser une base de données relationnelle plus dense. Trois domaines fonctionnels à couvrir : la gestion des clients, la gestion des rendez-vous avec leur cycle de vie (planifié, honoré, annulé), et le module de fidélisation avec l'historique des transactions de points. Chaque domaine a ses propres entités, ses propres relations, et ses propres contraintes d’intégrité. La règle métier centrale : des points sont attribués automatiquement au client lorsqu'un rendez-vous passe au statut "honoré". Cette logique impliquait une relation claire entre la table des rendez-vous et la table des transactions de fidélité, avec une contrainte pour éviter les doublons d'attribution. Le schéma de base de données et le script SQL de génération (structure et données de test) ont été livrés dans le repository. Le tout développé seul, de la conception jusqu'au déploiement. PMT était une étude de cas d’examen qui représentait la modélisation relationnelle la plus élaborée des trois projets. Utilisateurs, projets, rôles par projet (la relation entre un utilisateur et un projet porte elle-même un attribut : le rôle), tâches avec priorité et date d'échéance, assignations, historique des modifications. Chaque relation a dû être pensée pour que les requêtes de filtrage (tâches par statut, tâches assignées à un membre, historique d'une tâche) restent performantes même avec un volume de données croissant. La gestion de l'historique des modifications a nécessité une table dédiée, reliée aux tâches et aux utilisateurs, avec un timestamp et une description du changement. La table de jonction entre utilisateurs et projets portait le rôle comme attribut, ce qui nécessitait une modélisation soignée pour éviter la redondance. Le schéma et le script SQL ont été versionnés dans le repository dès la phase de conception. Développé seul, de bout en bout, en conditions d'examen.

-- Autocritique --

MySQL est la technologie sur laquelle la pratique est la plus régulière, mais pas forcément la plus approfondie. Modéliser une base relationnelle, écrire des scripts SQL de création, manipuler les données via Spring Data JPA : ces éléments sont maîtrisés et ont été mis en œuvre de manière fonctionnelle sur les trois projets d’examen. Ce qui est moins solide, c'est l'optimisation. Écrire une requête qui fonctionne et écrire une requête qui fonctionne bien sur un million de lignes, ce n'est pas la même chose. L'utilisation des index, la lecture d'un plan d'exécution avec EXPLAIN, l'identification des requêtes lentes : ces réflexes ne sont pas encore naturels. Dans un contexte académique où les données de test se comptent en dizaines de lignes, ça ne se voit pas. En production, ça se voit très vite. La dépendance à l'ORM est aussi un point d'attention. Spring Data JPA facilite énormément la vie, mais elle peut masquer des comportements problématiques côté SQL généré. Savoir ce que Hibernate produit réellement comme requêtes, identifier un problème de N+1 avant qu'il ne devienne un incident de production : c'est une compétence qui s'acquiert par l'expérience et par la curiosité, pas uniquement par la pratique en conditions normales. MySQL reste un pilier central du profil technique actuel, présent sur tous les projets réalisés. Le niveau permet de concevoir et livrer une base fonctionnelle. La marge de progression est réelle, elle est bien identifiée, et elle sera comblée par la pratique sur des projets à plus grande échelle.

-- Évolution --

L'optimisation des requêtes est le premier chantier. Apprendre à lire un EXPLAIN, comprendre comment MySQL utilise ses index, savoir quand une jointure devient un problème de performance : ce sont des compétences qui feront la différence sur de vrais projets en production. Ce n'est pas glamour, mais c'est fondamental. Le deuxième axe, c'est de sortir de la dépendance exclusive à l'ORM. Écrire des requêtes SQL complexes à la main, des requêtes avec des sous-requêtes, des CTEs, des window functions : c'est ce qui permettra de comprendre vraiment ce que JPA fait en arrière-plan, et de reprendre le contrôle quand il produit quelque chose d'inefficace. MySQL 8.0 offre ces outils, autant les utiliser. Dans le cadre du projet de société de développement logiciel, MySQL sera probablement la base de données par défaut sur les premières applications livrées. C'est sur ces projets réels, avec de vraies charges et de vrais utilisateurs, que la compétence progressera le plus vite. Concevoir une base qui tient dans le temps, qui supporte les évolutions fonctionnelles sans migration catastrophique, qui reste performante à mesure que les données s'accumulent : c'est l'objectif à atteindre.

-- Projets liés --