Pilier 03
Ce que l'utilisateur ne voit jamais, et qui doit pourtant tenir.
La route qui refuse la requête, la contrainte d'intégrité qui empêche l'incohérence, le jeton qui expire au bon moment. J'ai livré une API qui sert plus de 500 utilisateurs — et c'est en production qu'on apprend ce qu'un cours ne montre pas.
En production
Du code que j'ai écrit, exécuté chaque jour par de vrais utilisateurs.
EtudiantProConnect — stage d'ingénieure back-end, mai à août 2026.
Je pars du principe qu'un attaquant appelle mes routes directement, sans jamais passer par l'interface. Toute décision d'autorisation vit côté serveur.
Aucune révocation prévue : un jeton compromis restait valide jusqu'à expiration. J'ajouterais une liste de révocation et des jetons de rafraîchissement.
Code propriétaire — présentation détaillée possible en entretien.
Réalisations
Trois applications, une seule base de données.
Parcours d'achat, back-office de livraisons et tournées, application Android de suivi. Rôles et permissions strictement séparés.
Aucune règle de gestion dans le client. Si une contrainte compte, elle est appliquée côté serveur et garantie par la base.
Gestion de logements administratifs. Conçue et développée seule, en stage.
Cahier des charges réel, gestion du projet en autonomie complète. Architecture MVC en PHP, modélisation de la base, numérisation de cinq formulaires réglementaires, génération de PDF, hachage des mots de passe et requêtes préparées PDO sur tous les accès.
Premier contexte avec des données personnelles réelles, et où la question « qui a le droit de voir cette ligne ? » est devenue concrète.
Une contrainte dans la base vaut mieux qu'une vérification dans le code.
Schémas normalisés, choix des clés et index, intégrité référentielle, transactions, requêtes complexes. Le code peut être contourné par une nouvelle route, la base non.
Je teste d'abord les chemins d'erreur.
Le cas nominal se vérifie tout seul à l'usage. Pas les autres. Exécution automatisée à chaque envoi via GitLab CI.