ScolarPay : Guide du Projet

Développement d'une solution de gestion des frais de scolarité

**Rôle :** Vous êtes l'équipe de développement. Ce projet est notre modèle pour apprendre **LE processus professionnel** de création d'une application web de A à Z.

IST PROJECT

0. Contexte de la Mission (L'Appel du Client)

Notre Client : L'Institut Supérieur de Technologie (IST)

L'IST est une université privée gérant plusieurs centaines d'étudiants. Récemment, la directrice administrative nous a contactés pour un problème récurrent dans leur département de comptabilité.

« Notre processus de gestion des frais de scolarité est devenu un cauchemar logistique. Nous perdons du temps, des reçus se volatilisent et la satisfaction des parents diminue. Nous avons besoin d'une solution web pour passer à l'ère numérique. »
— Directrice Administrative de l'IST

**Notre Mission :** Concevoir et développer une application web fiable, sécurisée et simple d'utilisation, nommée **ScolarPay**, pour transformer ce processus manuel en un système automatisé et centralisé.

1. Votre Guide de Travail : Les 5 Phases de Développement

Phase 1 : Découverte et Cadrage (Comprendre la demande)

Cette phase définit les **limites du projet**. Elle commence par l'interview client et se termine par la rédaction du Cahier des Charges.

1.1. Guide de l'Interview Client : Poser les Bonnes Questions

La règle d'or : **N'essayez pas de poser des questions techniques.** Concentrez-vous sur la compréhension de leur métier, de leurs problèmes et de leurs objectifs.

Catégorie 1 : Contexte et Objectif (Le "Pourquoi ?")

Objectif : Comprendre la finalité du projet.

  • "Quel est le problème principal que vous essayez de résoudre avec cette application ? Quel est le but ultime ?"
  • "Décrivez-moi les plus grandes frustrations avec votre processus actuel sur papier."
  • "Imaginez que l'application est terminée. Qu'est-ce qui aura changé dans votre travail au quotidien ?"
Catégorie 2 : Comprendre les Utilisateurs (Le "Qui ?")

Objectif : Savoir exactement pour qui vous construisez l'application.

  • "Qui, précisément, va utiliser l'espace administration ? Uniquement les comptables ou aussi les secrétaires ?"
  • "Quel est le niveau de confort de ces personnes avec les outils informatiques en général ?"
  • "Doit-on s'attendre à ce que les parents utilisent l'application sur leur téléphone, leur tablette ou leur ordinateur ?"
Catégorie 3 : Processus et Fonctionnalités (Le "Quoi ?")

Objectif : Détailler le fonctionnement, y compris les cas exceptionnels.

  • "Décrivez, étape par étape, ce qui se passe quand un parent vient payer."
  • "De quelles informations avez-vous absolument besoin sur le reçu PDF (Logo, Matricule, Nom du parent) ?"
  • **Cas Particuliers :** "Que se passe-t-il si un parent paie pour plusieurs enfants ?" ou "Comment gérez-vous un paiement partiel ?"
  • "Si nous avions un délai très court, quelles seraient les trois fonctionnalités les plus cruciales pour vous ?" (Priorisation)
Catégorie 4 : Contraintes Techniques et Environnement (Le "Comment ?")

Objectif : Connaître le cadre de vie de l'application.

  • "Avez-vous déjà un hébergement web ?"
  • "Y a-t-il une charte graphique, des couleurs officielles, un logo à respecter ?"
  • "Existe-t-il déjà une base de données d'étudiants à importer, ou partons-nous de zéro ?"
  • "Y a-t-il des règles de sécurité/confidentialité des données spécifiques à l'IST ?"

**Conseil Final :** Ne proposez jamais de solution technique pendant l'interview. Votre seul rôle est de comprendre le besoin.

Puis : Rédaction du Cahier des Charges

Ce document est notre contrat. Il est notre référence pour tout le développement. L'étape cruciale ici est la rédaction des **Spécifications Fonctionnelles Détaillées**, exprimées sous forme de **User Stories** (Histoires Utilisateur).

Phase 2 : Conception de l'Expérience (Wireframes)

Passage du "Quoi" au "**À quoi ça ressemble**". Nous dessinons le "squelette" des pages en noir et blanc, en nous concentrant sur la structure et l'ergonomie (UX).

Wireframes spécifiques à créer :

  • Page de **Connexion** (Admin et Parent).
  • **Tableau de Bord Administration** (vue des 10 derniers versements).
  • **Formulaire d'Ajout de Versement** (pour l'Admin).
  • **Tableau de Bord Parent** (historique de paiement de l'enfant).

Phase 3 : Développement (Le Code)

C'est l'étape de construction du moteur (Backend) et de la façade (Frontend).

Modélisation de la Base de Données (PHP/SQL) :

  • Table **`utilisateurs`** (Admins & Parents).
  • Table **`etudiants`** (Doit inclure le champ `frais_totaux` pour le calcul du solde).
  • Table **`versements`** (avec liens aux deux tables précédentes).

Phase 4 : Tests et Déploiement

Valider que l'application répond à 100% au Cahier des Charges. Tester la sécurité (Authentification/Autorisation) et le bon fonctionnement des automatisations (PDF/Email).

Phase 5 : Maintenance et Évolution (Le Cycle de Vie)

L'application ne s'arrête pas au lancement. Cette phase garantit sa pérennité et son amélioration continue.

Actions Clés :

  • **Support Technique :** Plan de correction rapide des bugs remontés après le lancement.
  • **Maintenance Évolutive :** Mise à jour des dépendances logicielles (PHP, serveurs) pour la sécurité.
  • **Rétrospective :** Recueil du feed-back utilisateur pour planifier les améliorations de la **Version 2.0**.

2. Le Cahier des Charges (CDC) : Structure Formelle

Le CDC est le plan de l'architecte et notre contrat.

Il ne s'agit pas d'une simple liste, mais d'un document structuré qui doit être validé par le client avant tout développement.

  1. Section I : Introduction et Contexte

    Le Client, la Problématique et les Objectifs Généraux (Le "Pourquoi ?").

  2. Section II : Périmètre du Projet (Inclus / Exclu)

    Définit les limites du projet pour la version actuelle (Notre bouclier contre les dérives !).

  3. Section III : Spécifications Fonctionnelles Détaillées

    Décrit chaque fonctionnalité du point de vue de l'utilisateur (User Stories).

  4. Section IV : Spécifications Non-Fonctionnelles

    Exigences de qualité, de sécurité (hashage des mots de passe, anti-SQL injection), performance et design.

**Validation :** Le client doit valider (signer ou envoyer un email d'accord formel) cette structure avant que vous ne commenciez à coder la Phase 3.

3. Cahier des Charges Détaillé : Périmètre & User Stories

Spécifications Fonctionnelles Détaillées (User Stories)

Rôle : Administrateur de l'IST

  1. **Authentification :** En tant qu'admin, je veux pouvoir me connecter avec un email et un mot de passe pour accéder à mon espace de gestion.
  2. **Recherche Étudiant :** En tant qu'admin, je veux pouvoir rechercher un étudiant par son nom ou son matricule pour trouver rapidement le bon dossier.
  3. **Solde en Temps Réel :** En tant qu'admin, je veux voir le solde restant à payer de l'étudiant à côté de son dossier avant d'enregistrer un versement.
  4. **Enregistrement Versement :** En tant qu'admin, je veux pouvoir remplir un formulaire avec les champs suivants (Étudiant concerné, Montant, Devise, Date du paiement, Motif) pour enregistrer un nouveau versement.
  5. **Validation et Envoi :** En tant qu'admin, après avoir cliqué sur "Valider", je m'attends à ce que le système enregistre les données, génère le PDF et l'envoie à l'adresse e-mail du parent associé.

Rôle : Parent d'Étudiant

  1. **Authentification :** En tant que parent, je veux pouvoir me connecter avec mon email et un mot de passe pour consulter les informations de mon enfant.
  2. **Vue Financière :** En tant que parent, je veux voir un récapitulatif clair de mes frais (Total dû, Montant payé, **Solde restant**), pour ne pas avoir à appeler l'administration.
  3. **Consultation Historique :** En tant que parent, une fois connecté, je veux voir une liste claire de tous les versements que j'ai effectués, triés du plus récent au plus ancien.
  4. **Téléchargement Reçu :** En tant que parent, je veux pouvoir cliquer sur un bouton à côté de chaque versement pour télécharger le reçu PDF correspondant.
  5. **Autorisation :** Mesure de sécurité critique garantissant que le parent ne voit que les versements associés à son propre enfant.

Périmètre INCLUS (Ce que nous livrons)

  • Un système d'authentification à deux rôles (Admin, Parent).
  • La gestion des étudiants par l'admin.
  • **Gestion et affichage du solde étudiant en temps réel.**
  • L'enregistrement manuel des versements par l'admin (avec modifications/suppressions CRUD U/D).
  • La génération automatique de reçus PDF.
  • L'envoi automatique de ces PDF par e-mail.
  • La consultation de l'historique par les parents connectés.

Périmètre EXCLU (Version 1.0)

Ceci est notre bouclier. Cela empêche les dérives de projet.

  • Le paiement en ligne par carte de crédit ou mobile money.
  • La gestion des notes ou des absences des étudiants.
  • Un système de messagerie entre l'admin et les parents.
  • La gestion de plusieurs devises.

4. Concepts Clés & Piliers Techniques

Sécurité (Auth. & Auth.)

Cœur de l'application : Maîtriser la distinction entre **Authentification** (Qui êtes-vous ?) et **Autorisation** (Qu'avez-vous le droit de voir ?).

Pensez aux rôles : Admin (lecture/écriture complète), Parent (lecture restreinte).

Bibliothèques PHP

Évitez de réinventer la roue. Intégrer et utiliser des librairies professionnelles pour les tâches complexes : **FPDF** (PDF) et **PHPMailer** (Email).

Leçon : Savoir chercher et intégrer des solutions existantes.

Modèle de Travail Complet

Ce projet est un modèle : Comprendre -> Définir le Cahier des Charges -> Planifier l'UX (Wireframes) -> Coder (BDD, Backend, Frontend).

Méthodologie reproductible pour tout futur projet client.

5. Détails Avancés & Gestion de Projet

5.1. Spécifications Non-Fonctionnelles (Qualité)

  • **Sécurité :** Les mots de passe des utilisateurs doivent être chiffrés (hashés) dans la base de données. L'application doit être protégée contre les injections SQL.
  • **Performance :** Les pages de l'application doivent se charger en moins de 3 secondes.
  • **Compatibilité :** L'application doit fonctionner correctement sur les dernières versions des navigateurs Chrome, Firefox et Safari.
  • **Design :** L'interface doit respecter la charte graphique de l'IST (logo, couleurs principales).

5.2. Processus de Gestion des Changements

Le cahier des charges est notre contrat. Toute demande non prévue ("J'aimerais ajouter un système de messagerie") doit suivre ce processus :

  1. **Analyse d'impact :** Évaluer le temps de développement et le coût supplémentaire.
  2. **Proposition au client :** Soumettre l'impact (temps/coût) pour validation.
  3. **Mise à jour du CDC :** Si validé, le Cahier des Charges passe à la version 1.1 et le planning est ajusté.

Règle d'or : Ne jamais commencer à coder une nouvelle fonctionnalité non prévue sans validation formelle du client.

6. 🎯 Jalon 1 : Le Dossier de Design Complet

L'objectif de ce jalon est de consolider les Phases 1 (Cadrage) et 2 (Conception) en un **Dossier de Design** professionnel, preuve que nous avons un plan d'architecte validé **avant d'écrire la première ligne de code**.

Pré-requis : Simulation d'Interview Client

Chaque équipe doit soumettre une simulation d'interview pour valider la méthodologie de la Phase 1.

Livrables Requis : Le Dossier de Design

Le dossier doit être un document unique et clair, regroupant les trois livrables majeurs suivants :

I. Cahier des Charges (Phase 1)

Produire la structure complète du CDC, incluant :

II. Modélisation de la Base de Données

Fournir un schéma logique ou un Modèle Conceptuel de Données (MCD) lisible :

III. Conception d'Interface (Wireframes)

Fournir les schémas structuraux (sans couleur ni design) pour les quatre vues principales :

Critères de Validation

**Date de Soumission :** À définir par l'enseignant