CAHIER DES CHARGES

Plateforme SaaS de gestion pour écoles et centres de formation

Nom de code provisoire : SchoolManager SaaS

Version 1.0
Date : Juillet 2026
Statut : Document de cadrage — Projet en phase de conception
Sommaire
TOC \h \o "1-3"
1. Présentation du projet

1.1 Contexte
De nombreux établissements privés — écoles, instituts, centres de formation professionnelle, écoles
coraniques modernisées, centres de soutien scolaire — gèrent encore aujourd'hui leur activité
administrative et pédagogique avec des outils non adaptés : tableurs Excel, groupes WhatsApp,
cahiers papier, appels téléphoniques. Cette situation entraîne une perte de temps, des erreurs de
suivi, une absence de traçabilité des paiements et une communication parents-école peu fiable.
Le projet consiste à concevoir et développer une plateforme SaaS (Software as a Service) multi-
tenant permettant à chaque établissement de disposer de son propre espace numérique pour gérer
l'ensemble de son cycle administratif et pédagogique : inscriptions, paiements, présences, notes,
communication et planning.

1.2 Nom du produit

Un nom de marque définitif reste à valider. Le présent document utilise le nom provisoire «
SchoolManager » à titre de référence.

1.3 Porteur du projet

Projet initié par un développeur / entrepreneur indépendant, avec vocation à être commercialisé
auprès d'établissements scolaires et centres de formation, principalement en Afrique francophone
dans un premier temps (tarification en FCFA).

2. Objectifs du projet

2.1 Objectifs métier

● Digitaliser la gestion administrative et pédagogique des établissements scolaires et centres
de formation.
● Réduire les pertes financières liées aux retards ou impayés de scolarité grâce à un suivi
centralisé.
● Fluidifier la communication entre l'école, les enseignants et les parents/étudiants.
● Proposer un produit accessible financièrement, avec une mise en place rapide (« plug and
play »).
● Construire un modèle économique récurrent (abonnement mensuel) générant un revenu
prévisible (MRR).

2.2 Objectifs techniques

● Développer une architecture multi-tenant robuste, sécurisée et évolutive.
● Garantir l'étanchéité des données entre les établissements clients (isolation des tenants).
● Permettre une montée en charge progressive (ajout de modules, d'écoles, d'utilisateurs)
sans refonte majeure.
● Automatiser la facturation des abonnements et la gestion des essais gratuits.
2.3 Objectifs non retenus (hors périmètre V1)
● Application mobile native (une interface web responsive est prévue pour le MVP).
● Gestion de la paie des enseignants et du personnel.
● Module de comptabilité générale complète de l'établissement.
● Marketplace de contenus pédagogiques ou cours en ligne (e-learning).

3. Périmètre du projet

3.1 Types d'établissements ciblés

● Écoles privées (primaire, collège, lycée).
● Instituts et centres de formation professionnelle.
● Écoles coraniques modernisées.
● Centres de soutien scolaire et de cours particuliers.

3.2 Découpage en phases

Le projet est découpé en trois grandes phases afin de maîtriser les coûts de développement et de
valider le marché progressivement.
Phase Contenu Objectif
Gestion des étudiants, classes, paiements, présences, Valider l'adéquation
Phase 1 — MVP notes, communication de base, multi-tenant, produit-marché avec 3 à 5
abonnement écoles pilotes
Bulletins avancés, emploi du temps visuel, notifications
Fidéliser les premiers
Phase 2 — V1.5 SMS/WhatsApp, application mobile (PWA), rapports
clients et élargir l'offre
avancés
Scalabilité commerciale et
API publique, intégrations tierces, module de
Phase 3 — V2 différenciation
comptabilité simplifié, multi-langue, marque blanche
concurrentielle

4. Acteurs et personas

4.1 Rôles applicatifs

Rôle Description
Administre la plateforme globale : gestion des tenants (écoles), des
Super Admin (éditeur SaaS) abonnements, de la facturation, du support et des statistiques
globales.
Administrateur de l'établissement : configure l'école, gère les classes,
Admin École
étudiants, enseignants, paiements et documents.
Consulte ses classes, saisit les notes, marque les présences, publie
Enseignant
devoirs et annonces.
Consulte les notes, absences, emploi du temps et paiements ; reçoit
Étudiant / Parent
des notifications.
Comptable / Caissier (optionnel Rôle dédié à l'encaissement des paiements et à l'édition des reçus,
V1.5) sans accès aux notes.
4.2 Parcours utilisateurs clés
1. Un établissement s'inscrit sur la plateforme et démarre un essai gratuit de 14 jours.
2. L'Admin École configure les classes, importe ou saisit les étudiants et affecte les enseignants.
3. Les enseignants saisissent les présences et les notes au fil du trimestre.
4. Les parents/étudiants consultent en continu les informations et reçoivent des notifications
(retard de paiement, absence, nouvelle note).
5. À la fin de l'essai gratuit, l'établissement choisit un plan payant pour continuer à utiliser la
plateforme.
5. Spécifications fonctionnelles détaillées

5.1 Module — Admin École

5.1.1 Tableau de bord
● Vue synthétique : nombre d'étudiants actifs, taux de présence global, montant encaissé vs
attendu sur le mois, nombre d'impayés.
● Graphiques d'évolution des encaissements et des inscriptions.
● Alertes sur les retards de paiement et les taux d'absence anormaux.

5.1.2 Gestion des classes / filières / niveaux

● Création, modification, archivage de classes et de niveaux (ex. CP1, 6ème A, Formation
Bureautique).
● Association d'un ou plusieurs enseignants à une classe.
● Définition des matières enseignées par classe.

5.1.3 Gestion des étudiants

● Fiche étudiant : identité, coordonnées, contact parent, classe, historique scolaire.
● Inscription individuelle ou import en masse (fichier CSV/Excel).
● Gestion des documents administratifs (acte de naissance, bulletin précédent, photo, etc.).
● Statut de l'étudiant : actif, suspendu, transféré, diplômé.

5.1.4 Gestion des enseignants

● Fiche enseignant : identité, matières enseignées, classes affectées, coordonnées.
● Attribution des droits d'accès (rôle Enseignant).

5.1.5 Gestion des paiements

● Définition de la grille tarifaire par classe/niveau (frais d'inscription, mensualités, frais
annexes).
● Enregistrement des paiements (espèces, mobile money, virement) avec date et mode de
règlement.
● Génération automatique d'un reçu de paiement en PDF.
● Suivi des échéanciers et détection automatique des retards de paiement.
● Relances automatiques (email/notification) en cas d'impayé.

5.1.6 Documents administratifs

● Génération de certificats de scolarité, attestations, conventions.
● Stockage sécurisé des documents par étudiant.

5.2 Module — Enseignant

● Consultation de la liste de ses classes et des étudiants associés.
● Saisie des notes par matière, par évaluation (devoir, composition, examen) avec coefficients
et barèmes.
● Appel et marquage des présences/absences par séance, avec justification possible.
 ● Publication de devoirs, supports de cours et annonces visibles par les étudiants/parents de la
classe.

5.3 Module — Étudiant / Parent

● Consultation des notes et du bulletin (une fois publié par l'administration).
● Consultation de l'historique des présences/absences.
● Consultation de l'emploi du temps de la classe.
● Consultation du solde de scolarité : montants payés, montants restants, échéances à venir.
● Réception de notifications (email et/ou SMS selon plan) : nouvelle note, absence, échéance
de paiement, annonce de l'école.

5.4 Module — Notes et bulletins

● Paramétrage des périodes d'évaluation (trimestres, semestres, sessions).
● Saisie des notes avec calcul automatique des moyennes pondérées.
● Génération du bulletin de notes en PDF, avec en-tête personnalisé (logo de l'école).
● Validation et publication du bulletin par l'Admin École avant diffusion aux familles.

5.5 Module — Présences

● Appel numérique par séance avec statuts : présent, absent, retard, absence justifiée.
● Calcul automatique du taux de présence par étudiant et par classe.
● Export des feuilles de présence en PDF/Excel.

5.6 Module — Communication

● Messagerie ou fil d'annonces par classe ou par établissement.
● Notifications automatiques déclenchées par événements (absence, note, paiement en
retard).
● Historique des communications consultable par les parents.

5.7 Module — Planning des cours

● Création de l'emploi du temps par classe (jour, horaire, matière, enseignant, salle).
● Détection des conflits d'horaires (même enseignant ou salle sur deux créneaux).
● Vue calendrier consultable par tous les rôles concernés.
6. Spécificités SaaS et multi-tenant

6.1 Architecture multi-tenant

● Chaque établissement (tenant) dispose d'un espace de données isolé (base dédiée ou
schéma/discriminant selon le volume, à trancher en phase de conception technique).
● Sous-domaine ou espace applicatif propre à chaque école (ex.
[Link]).
● Personnalisation minimale par tenant : logo, couleur, nom de l'établissement sur les
documents générés.

6.2 Gestion des abonnements

● Essai gratuit de 14 jours sans engagement, avec accès à toutes les fonctionnalités du plan
choisi.
● Facturation mensuelle récurrente par établissement.
● Limitation des fonctionnalités et des volumes selon le plan souscrit (voir section 8).
● Notification automatique avant expiration de l'essai ou en cas d'échec de paiement de
l'abonnement.
● Suspension progressive de l'accès en cas de non-paiement (accès en lecture seule puis
blocage).

6.3 Rôles et permissions

● Système de rôles et permissions granulaire (ex. via Spatie Permission) : chaque rôle n'accède
qu'aux modules et actions qui le concernent.
● Le Super Admin de la plateforme n'a pas accès aux données pédagogiques des écoles
(respect de la confidentialité), sauf pour le support technique sur autorisation.

7. Exigences non fonctionnelles

7.1 Sécurité et confidentialité des données

● Chiffrement des mots de passe et des données sensibles.
● Connexion sécurisée en HTTPS sur l'ensemble de la plateforme.
● Isolation stricte des données entre tenants (aucune fuite d'informations d'une école à une
autre).
● Sauvegardes régulières et automatisées des données (quotidiennes).
● Journal d'audit des actions sensibles (paiements, modifications de notes).

7.2 Performance et disponibilité

● Temps de réponse cible inférieur à 2 secondes pour les pages principales.
● Disponibilité cible de 99% en dehors des fenêtres de maintenance planifiées.
● Hébergement permettant une montée en charge horizontale à mesure que le nombre
d'écoles augmente.
7.3 Ergonomie et accessibilité
● Interface simple, pensée pour des utilisateurs peu familiers du numérique (personnel
administratif, enseignants, parents).
● Interface responsive, utilisable sur ordinateur, tablette et smartphone via le navigateur.
● Support prioritaire du français, avec possibilité d'ajouter d'autres langues (arabe, anglais) en
V2.

7.4 Conformité et protection des données personnelles

● Respect des principes de protection des données personnelles des élèves et des familles
(minimisation des données collectées, durée de conservation définie).
● Mise à disposition de conditions générales d'utilisation et d'une politique de confidentialité
claires pour chaque établissement client.
8. Modèle économique et plans tarifaires

8.1 Structure des plans

La tarification est mensuelle, par établissement, en Franc CFA (FCFA), et dépend du nombre d'élèves,
d'utilisateurs et des modules activés. Les montants ci-dessous sont indicatifs et devront être validés
après étude de marché plus fine.
Plan Prix indicatif / mois Limites Modules inclus
Toutes les
fonctionnalités du plan
Essai gratuit 0 FCFA (14 jours) Jusqu'à 50 étudiants
Standard, à titre de
découverte
Étudiants, classes,
Jusqu'à 150 étudiants, 5
Basic 10 000 – 20 000 FCFA paiements, présences,
comptes enseignants
notes
Toutes les
Jusqu'à 500 étudiants, fonctionnalités Basic +
Standard 25 000 – 40 000 FCFA comptes enseignants communication
illimités avancée, exports,
bulletins personnalisés
Toutes fonctionnalités +
Sur mesure / Volumes et utilisateurs accompagnement
Sur devis
Établissements multi-sites illimités dédié, marque blanche
(V2)

8.2 Frais additionnels

● Frais de mise en place / personnalisation initiale (import de données existantes,
paramétrage, formation de l'équipe administrative).
● Option SMS pour les notifications (facturée à l'usage, en fonction du volume envoyé).

8.3 Modalités de paiement des abonnements

● Paiement par mobile money (Orange Money, Wave, etc.) et/ou carte bancaire selon les
intégrations retenues.
● Facture mensuelle automatique envoyée à l'Admin École.
● Politique de remboursement et de résiliation à définir dans les conditions générales de
vente.

9. Architecture et stack technique proposées

9.1 Stack applicative

Composant Choix proposé
Framework backend Laravel 11 / 12
Frontend Blade + Livewire, ou [Link] + React (à trancher selon l'équipe)
Back-office / admin Filament
Gestion des rôles et permissions Spatie Laravel-Permission
Facturation / abonnements Laravel Cashier + prestataire de paiement local (mobile money)
 Notifications Laravel Notifications (email, et SMS via passerelle tierce)
Génération de PDF DomPDF ou Snappy (bulletins, reçus, certificats)
Base de données MySQL / PostgreSQL
Hébergement VPS ou cloud (à définir selon budget et volumétrie)

9.2 Aperçu du modèle de données (entités principales)

● Tenant (École) : nom, sous-domaine, plan, statut d'abonnement, coordonnées.
● Utilisateur : nom, rôle, tenant associé, identifiants de connexion.
● Classe / Filière / Niveau : nom, niveau, enseignant(s) référent(s).
● Étudiant : identité, classe, statut, contacts parents.
● Enseignant : identité, matières, classes affectées.
● Paiement : étudiant, montant, date, mode de paiement, statut (payé/en attente/en retard).
● Note / Évaluation : étudiant, matière, période, note, coefficient.
● Présence : étudiant, séance, statut (présent/absent/retard/justifié).
● Annonce / Message : auteur, classe ou établissement cible, contenu, date.
● Créneau d'emploi du temps : classe, matière, enseignant, jour, horaire, salle.
10. Livrables attendus

10.1 Livrables de la phase MVP

● Application web fonctionnelle multi-tenant, déployée en environnement de production.
● Back-office Super Admin pour la gestion des tenants et des abonnements.
● Interfaces Admin École, Enseignant et Étudiant/Parent opérationnelles.
● Génération de reçus de paiement et de bulletins en PDF.
● Documentation utilisateur de base (guide de prise en main).

10.2 Livrables documentaires

● Présent cahier des charges.
● Spécifications techniques détaillées (dictionnaire de données, schéma de base de données).
● Maquettes / wireframes des interfaces principales.
● Plan de tests et recette fonctionnelle.

11. Contraintes, hypothèses et risques

11.1 Contraintes
● Budget de développement limité (projet démarré en solo ou en petite équipe).
● Nécessité de proposer une tarification adaptée au pouvoir d'achat des établissements ciblés.
● Connectivité internet parfois instable dans certaines zones : l'application doit rester
utilisable en conditions de réseau limité.

11.2 Hypothèses
● Les établissements pilotes acceptent de migrer leurs données existantes (souvent sous
Excel) vers la plateforme.
● Un accompagnement/formation initial sera nécessaire pour l'adoption par le personnel
administratif.

11.3 Risques identifiés

Risque Impact Mesure de mitigation
Faible adoption par les écoles peu Accompagnement personnalisé, formation,
Élevé
digitalisées interface très simplifiée
Résistance au changement du Phase pilote gratuite, support réactif, import assisté
Moyen
personnel administratif des données
Complexité de l'intégration des Étude préalable des passerelles disponibles (Orange
Moyen
paiements mobiles locaux Money, Wave, etc.)
Fuite ou mélange de données Tests rigoureux d'isolation multi-tenant avant mise
Élevé
entre établissements en production
Impayés des abonnements par les Relances automatiques, suspension progressive de
Moyen
écoles clientes l'accès
12. Critères de succès
● Nombre d'établissements actifs sur la plateforme après 6 mois de commercialisation.
● Taux de conversion des essais gratuits en abonnements payants.
● Taux de rétention mensuel des établissements clients (churn rate).
● Réduction mesurable du taux d'impayés de scolarité chez les écoles utilisatrices.
● Satisfaction des utilisateurs (Admin École, enseignants, parents) mesurée par enquête.

13. Glossaire
Terme Définition
Software as a Service : logiciel accessible en ligne par abonnement, sans
SaaS
installation locale.
Architecture permettant à plusieurs clients (tenants) d'utiliser la même
Multi-tenant
application tout en gardant leurs données isolées.
Minimum Viable Product : version minimale mais fonctionnelle du produit,
MVP
permettant de tester le marché.
Taux d'attrition : proportion de clients qui résilient leur abonnement sur une
Churn
période donnée.
Monthly Recurring Revenue : revenu mensuel récurrent généré par les
MRR
abonnements.

Fin du document — Ce cahier des charges est un document de cadrage initial destiné à être affiné avec les
parties prenantes (équipe technique, établissements pilotes) avant le démarrage du développement.