Projet formation — BTS SIO SLAM

GSB — Gestion des frais

Application web de gestion des notes de frais pour les visiteurs médicaux du Laboratoire Galaxy Swiss Bourdin. Projet fil rouge BTS SIO développé en PHP avec architecture MVC et base de données MySQL.

Démo live
Identifiants démo — login : p.ayot  |  mot de passe : xiej3uuY0 (compte visiteur médical)
PHP 8 MySQL MVC PDO Sessions TCPDF Bootstrap 3
Captures d'écran
Accueil — tableau de bord visiteur
GSB — accueil
Saisie de la fiche de frais
GSB — fiche frais
Mes fiches de frais
GSB — mes fiches
Contexte du projet

Galaxy Swiss Bourdin (GSB) est un laboratoire pharmaceutique fictif dont les visiteurs médicaux se déplacent chez les médecins pour promouvoir les médicaments. Ils génèrent des notes de frais mensuelles (transport, hébergement, repas) que le service comptable doit valider puis rembourser.

L'application remplace un processus papier par une solution web : les visiteurs saisissent leurs frais, les comptables les valident et suivent les remboursements. C'est le projet fil rouge du BTS SIO, conçu pour couvrir les compétences du bloc « Support et mise à disposition de services informatiques ».

Architecture MVC

L'application respecte le patron de conception Modèle-Vue-Contrôleur : chaque couche a un rôle précis et ne dépend pas des autres.

Navigateur → GET /index.php?uc=gererFrais&action=saisirFrais ↓ public/index.php (aiguilleur — lit le paramètre ?uc=) ↓ Controleurs/c_gererFrais.php (logique métier, appelle le modèle) ↓ Modeles/PdoGsb.php (accès BDD via PDO — requêtes SQL) ↓ Vues/v_listeFraisForfait.php (HTML généré et renvoyé au navigateur)
Modèle

PdoGsb.php

Singleton PDO. Toutes les requêtes SQL sont centralisées ici : getFiche(), majForfait(), validerFiche(). Aucun SQL dans les contrôleurs ou vues.

Contrôleur

c_gererFrais.php

Reçoit l'action via $_GET['action'], appelle le modèle, prépare les variables pour la vue. Gère aussi la validation des données saisies.

Vue

v_listeFraisForfait.php

Fichier PHP/HTML pur. Affiche les données préparées par le contrôleur. Aucune logique métier ni accès direct à la base de données.

Sécurité

Sessions & Auth

Authentification par session_start(). Mot de passe hashé en SHA-256. Chaque page vérifie Utilitaires::estConnecte() avant d'afficher le contenu.

Fonctionnalités principales

Saisie des frais

Le visiteur renseigne ses frais forfaitaires (repas, nuitée, km) et hors-forfait (justificatifs ponctuels) pour le mois en cours.

Validation comptable

Le comptable sélectionne un visiteur et une période, consulte et ajuste les montants, puis valide la fiche (état CR → VA).

Suivi du paiement

Liste les fiches validées, saisie de la date et référence de paiement, passage à l'état « Remboursée » (VA → RB).

Génération PDF

Export de la fiche de frais en PDF via TCPDF. Cache côté serveur : le PDF n'est régénéré que si les données ont changé.

Refus hors-forfait

Le comptable peut refuser une ligne hors-forfait : elle est préfixée REFUSE et exclue du total sans être supprimée.

Indemnités km

Calcul automatique selon un barème par tranches de puissance et de kilométrage, paramétré en base de données.

Compétences BTS SIO — Annexe 8-3

Grille d'évaluation officielle de l'épreuve E5 — bloc « Support et mise à disposition de services informatiques ».

Bloc de compétence (Annexe 8-3)Application dans GSB
Mettre à disposition des utilisateurs un service informatique Déploiement de l'application sur un serveur web (Nginx + PHP-FPM). Tests d'intégration des UC (saisie frais, validation, PDF). L'utilisateur accède à la démo via un navigateur sans installation.
Travailler en mode projet Réalisation structurée en UC (cas d'utilisation) : analyse du sujet, découpage en tâches (Contrôleur / Modèle / Vue), respect du cahier des charges fil rouge BTS SIO.
Développer la présence en ligne de l'organisation Interface web accessible depuis tout navigateur. Mise en forme Bootstrap responsive. Application hébergée et accessible en ligne via keryan.net/gsb/.
Gérer le patrimoine informatique Base de données structurée (tables visiteur, fichefrais, lignefraisforfait, lignefraishorsforfait, etat). Script SQL de restauration. Gestion des droits : visiteur et comptable ont des accès distincts.
Répondre aux incidents et demandes d'évolution Correction des incohérences de frais signalées (montants, dates). Ajout de fonctionnalités à la demande : refus hors-forfait, cache PDF, barème km paramétrable.
Organiser son développement professionnel Montée en compétence PHP/MySQL/MVC. Utilisation de PHPUnit pour les tests, phpDocumentor pour la documentation. Progression vers WAChangeLogUrgence (ASP.NET / Angular).
Contribution personnelle Implémentation des UC Validation fiche, Suivi paiement, Génération PDF avec cache, Refus hors-forfait, Sécurisation SHA-256, Barème kilométrique.
Format de l'épreuve E5

Partie 1 — Présentation du parcours (10 minutes max)

Présenter le portfolio : les réalisations professionnelles, les compétences mobilisées pour chacune, et l'environnement technologique. GSB doit apparaître comme une réalisation couvrant plusieurs blocs de la grille annexe 8-3.

Partie 2 — Échange avec le jury (30 minutes)

Questions sur les choix techniques, l'architecture, le rôle de chaque composant, les difficultés rencontrées. Le jury s'appuie sur la grille annexe 8-3 pour évaluer le niveau de maîtrise (Non maîtrisé → Excellente maîtrise).

⚠ Pénalités : portfolio inaccessible (−10 pts) · absence tableau de synthèse (−2 pts) · Note finale sur 20.

FAQ — Questions probables du jury
Qu'est-ce que le patron MVC et pourquoi l'utiliser dans GSB ?
MVC (Modèle-Vue-Contrôleur) est un patron d'architecture qui sépare l'application en 3 couches indépendantes :

  • Modèle (PdoGsb.php) : accès à la base de données, logique métier. Aucun HTML.
  • Vue (v_*.php) : affichage HTML. Aucune requête SQL, aucun calcul métier.
  • Contrôleur (c_*.php) : fait le lien — lit la requête HTTP, appelle le modèle, passe les données à la vue.

Pourquoi ? Maintenabilité : si on change la base de données, seul le modèle est modifié. Si on change le design, seules les vues sont touchées. Testabilité : on peut tester le modèle indépendamment de l'interface.
Qu'est-ce que PDO et pourquoi l'utiliser plutôt que mysql_ ?
PDO (PHP Data Objects) est une abstraction d'accès aux bases de données en PHP.

Avantages par rapport aux anciennes fonctions mysql_* :
  • Requêtes préparées : prepare() + bindParam() → protection contre les injections SQL
  • Portabilité : changer de SGBD (MySQL → PostgreSQL) sans réécrire le code
  • Gestion d'erreurs via exceptions (PDOException)
  • mysql_* est supprimé depuis PHP 7 — PDO est la norme actuelle

Dans GSB, PdoGsb est un singleton : une seule connexion est créée et réutilisée sur toute la page.
Comment fonctionne l'authentification dans GSB ?
L'authentification repose sur les sessions PHP :

  • L'utilisateur soumet son login et mot de passe via un formulaire POST
  • Le mot de passe est hashé en SHA-256 et comparé au hash stocké en base (hash_equals())
  • Si OK, $_SESSION['idVisiteur'] et $_SESSION['nom'] sont stockés côté serveur
  • Chaque page appelle Utilitaires::estConnecte() pour vérifier la session avant d'afficher le contenu
  • La déconnexion détruit la session avec session_destroy()

Pourquoi SHA-256 et pas password_hash() ? Exigence pédagogique du sujet BTS SIO. En production réelle, password_hash() avec bcrypt est préférable car il intègre un sel aléatoire.
Comment sont gérés les états d'une fiche de frais ?
Chaque fiche de frais passe par 3 états définis comme constantes dans config/define.php :

CR (Créée) → VA (Validée) → RB (Remboursée)
  • CR : fiche créée par le visiteur, saisie en cours ou close
  • VA : comptable a vérifié et validé les montants
  • RB : paiement effectué, date et référence renseignées

Les transitions sont irréversibles. La table etat en base stocke l'état courant de chaque fiche. Cela permet au visiteur de consulter l'avancement de son remboursement.
Comment avez-vous géré la génération de PDF ?
Utilisation de la bibliothèque TCPDF (installée via Composer) qui supporte l'UTF-8 et les caractères accentués, contrairement à FPDF.

Logique de cache (Green IT) :
  • Nom du fichier : FICHE_{matricule}_{YYYYMM}.pdf stocké dans /pdf/ (hors webroot)
  • Avant génération, on vérifie si le fichier existe et si les données n'ont pas changé (état, montants, date de dernière modification)
  • Si identique → on sert le fichier en cache directement, sans régénérer
  • Si différent → on régénère et on remplace

Le dossier /pdf/ est hors de public/ : il n'est pas accessible directement par URL, seulement via le contrôleur PHP.
Quelle est votre contribution personnelle dans ce projet ?
Le projet GSB est un sujet fil rouge fourni par le réseau CERTA. Ma contribution porte sur les développements ajoutés ou améliorés :

  • UC Validation fiche : vue, contrôleur, requêtes modèle, transition d'état CR→VA
  • UC Suivi paiement : filtres, formulaire de paiement, transition VA→RB, statistiques par mois
  • Génération PDF avec cache : intégration TCPDF, logique d'invalidation
  • Refus hors-forfait : préfixe REFUSE, exclusion du total, affichage différencié
  • Sécurisation SHA-256 : remplacement du hash MD5 initial, adaptation de l'authentification
  • Barème kilométrique : service de calcul par tranches de puissance
Quelle est la différence entre frais forfaitaires et hors-forfait ?
Frais forfaitaires : dépenses standardisées avec un montant unitaire fixe défini par l'entreprise (repas : X€, nuitée : Y€, km : barème). Le visiteur saisit une quantité, le montant est calculé automatiquement.

Frais hors-forfait : dépenses exceptionnelles avec un montant libre et un justificatif (inscription à une conférence, taxi, etc.). Le visiteur saisit le libellé et le montant exact.

Le comptable peut refuser un hors-forfait sans le supprimer : la ligne est préfixée REFUSE et exclue du total remboursé, mais reste visible dans l'historique.
Comment avez-vous testé l'application ?
Tests unitaires avec PHPUnit sur les méthodes du modèle (PdoGsb) : calcul des totaux, application du barème kilométrique, logique de refus hors-forfait, transitions d'état.

Tests fonctionnels : simulation des UC complets (saisie → validation → remboursement) avec des données de la base de démo.

Documentation générée automatiquement avec phpDocumentor via composer run docs.

Validation W3C du HTML et CSS produit par les vues.
Pourquoi PHP plutôt qu'un autre langage pour ce projet ?
PHP est le langage historique du projet fil rouge BTS SIO GSB, et c'est un choix cohérent pour plusieurs raisons :

  • Très répandu sur le marché : de nombreux projets web (WordPress, Symfony, Laravel) reposent sur PHP
  • Intégration native avec MySQL via PDO
  • Déploiement simple : un serveur Apache/Nginx + PHP-FPM suffit, pas de compilation
  • Pédagogiquement pertinent : permet d'apprendre le MVC, les sessions, PDO avant de passer à des frameworks plus complexes

Par rapport à WAChangeLogUrgence (ASP.NET Core + Angular), GSB est volontairement plus simple — c'est l'étape intermédiaire entre le HTML statique (Nolark) et l'architecture API REST découplée.