Écosystème abrtÉtude de cas — projet phare full-stack

Mes projets
En ligne

L'écosystème abrt — projet phare full-stack

Plusieurs sites web personnels conçus et codés de A à Z, autour d'une infrastructure commune

PHP MySQL 8 SSO Apache Let's Encrypt Design system Ouvrir le Dashboard Me contacter

Le projet

Depuis plusieurs mois, je développe mon propre écosystème de sites web personnels, conçu et codé de A à Z. Le back-end est en PHP avec accès aux données via PDO, sur MySQL 8, hébergé sur un serveur Apache en HTTPS (certificats Let's Encrypt). Tous les sites partagent une authentification SSO commune entre sous-domaines, un design system maison baptisé « console » et un système de palettes thématiques personnalisables.

C'est mon projet phare : il m'a permis de manipuler concrètement toute la chaîne, de l'infrastructure serveur jusqu'à l'interface, en passant par la sécurité des accès et une base de données partagée entre plusieurs applications.

Mon rôle

Tout : l'administration du serveur, la base de données, le back-end PHP, le front-end, le design system et le déploiement. Un projet mené seul, de bout en bout.

L'objectif

Me confronter à une vraie chaîne full-stack : héberger, sécuriser, partager une authentification et une base entre plusieurs sites, et garder une cohérence visuelle.

L'architecture

Tous les sites vivent sous le domaine fabien-abrt.fr et s'appuient sur une couche commune : un point d'entrée HTTPS, une authentification unique partagée, une base de données et un design system mutualisés.

Accès
Visiteur
Front / HTTPS
Serveur Apache vhosts par site HTTPS Let's Encrypt
Authentification
SSO partagé cookie abrtsso · .fabien-abrt.fr permissions · profils · habilitations
Applications
Dashboard Portfolio Convertisseur Feedback Mini-jeux CyberSafe
Outils d'administration
SiteTracker Gestion utilisateurs
Données
MySQL 8 commun · sitetracker · feedback
Design system « console » (transversal) Palettes personnalisables Déploiement : git push → hook post-receive

Comment c'est fait

  • Infrastructure — serveur Apache, vhosts par site, HTTPS via certificats Let's Encrypt multi-domaines
  • Back-end — PHP avec PDO, base MySQL 8 répartie en plusieurs bases (commun, sitetracker, feedback)
  • SSO — cookie partagé sur le domaine parent, sessions communes, modèle permissions / profils / habilitations
  • Design system — une feuille de styles « console » mutualisée, mode clair/sombre et palettes personnalisables
  • Déploiement — mise en production par un simple git push déclenchant un hook côté serveur

Les sites de l'écosystème

Les briques qui composent l'écosystème (celles qui ont une fiche détaillée sont cliquables) :

Difficultés rencontrées et solutions

Les pièges les plus instructifs de la construction et de la sécurisation de l'écosystème :

  • Un ordre de chargement qui compte. Dans l'authentification, la couche de droits doit être chargée avant le démarrage du SSO, car ce dernier appelle une fonction qu'elle déclare. Les anciennes fonctions maison devaient aussi être supprimées : la nouvelle couche ne s'active que si elles n'existent plus.
  • Une protection CSRF qui ne protégeait pas. Le passage du mode observation au mode bloquant a révélé qu'ouvrir une session PHP pour le jeton écrasait les données de session. Les 5 formulaires d'authentification, dont la désactivation du second facteur, n'avaient en réalité aucune protection : ils en ont reçu une.
  • Un seul compte MySQL applicatif. L'idée d'un compte par base s'est heurtée au code : le contrôle des droits lit la liste des sites à chaque requête. Les applications ne tournent plus en root, avec un compte limité aux opérations de lecture et d'écriture.
  • Un pare-feu applicatif qui ne regardait rien. Les règles fail2ban d'Apache semblaient actives mais lisaient le journal système au lieu des fichiers d'Apache. Contrôle retenu : la commande qui liste les fichiers réellement surveillés.
  • Une mémoire limitée. Le serveur dispose de 826 Mo : l'arrêt brutal de MySQL du 18/07/2026 venait d'un nombre de processus Apache autorisé trop élevé. Il a été ramené de 150 à 20.
  • Un nettoyage trop zélé. Une commande de nettoyage de paquets a supprimé des extensions PHP indispensables et fait tomber les pages avec base de données : elles ont été réinstallées et marquées comme installées volontairement.

Résultats

  • Sauvegardes quotidiennes conservées 7 jours, avec restauration testée et copie hors du serveur.
  • Veille hebdomadaire des vulnérabilités sur les bibliothèques installées, lancée par le serveur lui-même.

Compétences BTS SIO mobilisées

Ce projet couvre une grande partie du référentiel BTS SIO, option SISR :

  • Bloc 1 Gérer le patrimoine informatique
  • Bloc 1 Mettre à disposition des utilisateurs un service informatique
  • Bloc 1 Développer la présence en ligne de l'organisation
  • Bloc 2 Concevoir une solution d'infrastructure réseau (serveur, vhosts, HTTPS)
  • Bloc 2 Exploiter, dépanner et superviser une solution applicative
  • Bloc 3 Gérer les identités et les habilitations (SSO)
  • Bloc 3 Protéger les données à caractère personnel
  • Transverse Travailler en mode projet

Pour aller plus loin

Voir aussi

D'autres études de cas de l'écosystème, proches de celle-ci :