1. Lecture générale
Le nouveau cahier des charges constitue une base fonctionnelle riche et structurée. Il formalise avec précision les acteurs, les règles scolaires, les opérations financières, les documents officiels, le référentiel, la sécurité et la conformité. Il peut donc servir de vision fonctionnelle cible pour Scolario.
Son niveau de couverture dépasse toutefois celui d’un produit minimal à concevoir intégralement en cinq mois. Le document réunit le cœur de la gestion scolaire et plusieurs parcours nouveaux qui génèrent des interfaces supplémentaires : facturation normalisée des enseignants, gestion commerciale de Scolario, archivage documentaire payant, application mobile multi-rôle et administration avancée de la plateforme. Leur complexité technique complète peut relever du backend ou de services tiers ; leur impact sur la mission de design concerne d’abord les parcours, les écrans, les états et les interactions à prévoir.
1.1 Frontière de la mission de design
Responsabilité principale : comprendre les besoins réels des utilisateurs et les objectifs de Scolario, puis trouver la réponse la plus juste sous la forme de parcours cohérents, de règles d’interaction compréhensibles et d’interfaces faciles à utiliser. Le travail consiste notamment à sélectionner des patterns efficaces, fonctionnels et adaptés aux acteurs concernés, à réduire les frictions et à satisfaire les objectifs business sans recourir à des mécanismes trompeurs ou manipulateurs.
Livrables remis au client : le résultat principal est constitué de fichiers de code front-end remis dans le dépôt du projet ou sous la forme d’une archive structurée. Ils sont accompagnés d’une documentation des parcours, règles d’interface, composants, états et conditions d’intégration. Quelques fichiers de design ciblés peuvent également être livrés lorsque le travail doit être documenté visuellement, notamment les mises à jour du design system existant sur Figma.
Qualité attendue : la qualité visuelle soutient la lisibilité, la confiance et l’usage ; elle n’est pas une recherche du « beau » détachée des besoins du produit.
Dépendances externes : backend, bases de données, sécurité serveur, API métier, intégrations fiscales, paiement, messagerie et exploitation technique.
L’usage de l’intelligence artificielle permet d’accélérer la recherche de solutions, la production de variantes et l’écriture du front-end. Il ne supprime pas les arbitrages produit, la validation des règles métier, la conception des états, les tests d’interface ni les cycles de correction. Des interventions ponctuelles sur des sujets techniques connexes peuvent être nécessaires pour maintenir la cohérence, mais elles ne doivent pas être assimilées à une responsabilité de développement backend.
2. Écarts structurants avec le cadrage précédent
Le tableau ci-dessous ne cherche pas à comparer chaque phrase des documents. Il isole les évolutions qui modifient directement le volume, l’ordre de travail ou les responsabilités.
| Sujet | Orientation issue du cadrage précédent | Nouveau cahier des charges | Décision attendue |
|---|---|---|---|
| Niveaux scolaires | Primaire et secondaire envisagés ensemble. | Enseignement secondaire uniquement. | Confirmer le secondaire comme seule branche de la première phase. |
| Compte élève | Aucun accès direct de l’élève dans la première version. | Aucun compte ni portail élève. | Orientation alignée, à maintenir. |
| Ordre des acteurs | Administration traitée en premier, puis autres acteurs. | Les quatre acteurs sont décrits largement, sans ordre de livraison. | Maintenir l’administration comme point de départ. |
| Contexte enseignant | Un contexte d’établissement à la fois, accessible par un sélecteur permettant de changer d’école. | Ajout d’une vue de planning unifiée entre établissements. | Challenger les deux expériences : conserver le changement de contexte comme fonctionnement principal et décider si une vue agrégée, limitée au planning et aux conflits, apporte une valeur suffisante. |
| Inscription | Formulaire administratif simple après le processus d’admission de l’école. | Pipeline avec pièces, test, entretien, frais, statuts et année préparée. | Définir un noyau simple et reporter les variantes avancées. |
| Compte parent | Activation simple d’un compte préparé par l’établissement. | Lien à usage unique, délais, notifications et contestation du rattachement. | Choisir un parcours initial compatible avec les canaux réellement disponibles. |
| Rôles et permissions | Rôles principaux prédéfinis, cumuls à encadrer prudemment. | Permissions atomiques, rôles configurables par Scolario et cumul multi-rôle. | Limiter l’interface initiale aux rôles nécessaires au parcours retenu. |
| Mobile | Périmètre à préciser, avec priorité possible au parent. | Application unique pour Parent, Enseignant et Administration. | Distinguer le responsive web d’une application mobile native. |
| Année et archives | Conservation de l’historique et désactivation simple. | États Préparée, Active, Clôturée et Archivée avec règles détaillées. | Conserver le modèle, mais limiter les interfaces de première phase. |
3. Nouveautés majeures à qualifier
Les éléments suivants apparaissent pour la première fois ou atteignent dans le nouveau document un niveau de détail qui génère de nouveaux parcours et interfaces :
- Facturation normalisée des enseignants via e-MeCeF. Pour la mission de design, le travail porte sur la compréhension du service existant, le parcours de préparation et d’émission, les états d’erreur et la présentation de la facture lorsque celle-ci est personnalisable. La connexion à l’API fiscale ou à un agrégateur reste une responsabilité technique distincte.
- Souscriptions, packs, factures et coupons commerciaux Scolario. Ces notions impliquent des interfaces commerciales nouvelles : présentation des offres, landing page, demande de démonstration, souscription, application d’un coupon et gestion des statuts. Elles doivent être cadrées comme un parcours commercial à part entière.
- Archivage documentaire parent gratuit puis payant. Le portefeuille documentaire est nouveau et son modèle économique doit être challengé. Scolario étant adopté et imposé par l’établissement, faire payer directement le parent pour conserver l’accès à des documents fournis par l’école peut créer une incohérence de valeur, de responsabilité et de continuité du service.
- sessions évaluatives multi-classes et multi-séries ;
- plans de salle, numéros de table et répartition automatique des élèves ;
- rattrapages disposant de leur propre cycle de publication ;
- programmes officiels versionnés et migration des programmes locaux ;
- Planning enseignant unifié entre plusieurs établissements. L’idée peut être utile pour visualiser les obligations de l’enseignant et détecter les chevauchements. Elle doit toutefois rester une vue transversale limitée, sans mélanger les autres données scolaires, qui restent consultées dans le contexte de chaque établissement.
- Support temporaire du super-administrateur. Pour le MVP, un contact d’assistance simple et l’accès ordinaire du super-administrateur peuvent suffire. Un système complet de tickets, sessions temporaires et protection dédiée peut être reporté tant que le volume d’établissements ne le justifie pas.
- portabilité JSON, conservation, anonymisation et purge automatisée ;
- tableau d’honneur annuel et documents individuels associés ;
- application mobile multi-rôle.
4. Complexité et recommandation par domaine
| Domaine | Valeur initiale | Complexité | Orientation proposée |
|---|---|---|---|
| Socle, accès, contexte et année active | Critique | Élevée | Conserver sous une forme minimale et stable. |
| Référentiel scolaire | Critique | Très élevée | Limiter au secondaire béninois et aux données nécessaires au parcours. |
| Inscription et rattachements | Critique | Élevée | Simplifier le pipeline initial. |
| Planning, séances et présences | Critique | Très élevée | Conserver le noyau opérationnel. |
| Évaluations, calculs et bulletins | Critique | Très élevée | Conserver un modèle fixe et réduire les variantes logistiques. |
| Finance scolaire des familles | Forte | Très élevée | Conserver frais, échéances, paiements et reçus simples. |
| Documents officiels | Forte | Élevée | Prioriser bulletin, reçu et certificat. |
| Communication | Moyenne | Élevée | Commencer par les annonces et notifications essentielles. |
| Application mobile native | Forte | Très élevée | Concevoir d’abord un web responsive, sauf décision contraire. |
| Super-administration commerciale | Moyenne | Élevée côté interfaces | Concevoir uniquement les offres et opérations commerciales retenues. |
| e-MeCeF enseignant | À confirmer | Moyenne côté parcours, forte côté intégration | Concevoir le front-end après compréhension du service ; isoler l’intégration API. |
| Archive parent payante | À challenger | Élevée | Revoir d’abord le modèle économique et la responsabilité de paiement. |
| Conformité automatisée | Nécessaire | Limitée côté interface, forte côté backend | Concevoir les écrans requis ; isoler l’automatisation technique. |
4.1 Points de vigilance
Évaluations et bulletins
Le domaine ne correspond pas à un seul écran de saisie de notes. Il faut d’abord décider ce que Scolario doit réellement prendre en charge sans chercher à remplacer les pratiques pédagogiques physiques ni les outils bureautiques utilisés pour rédiger les sujets.
Voir les questions produit et un noyau de livraison possible
Question préalable : lorsqu’une interrogation ou un devoir est réalisé en classe sur papier, « créer l’évaluation dans Scolario » doit-il signifier rédiger le sujet dans la plateforme, ou simplement enregistrer son existence, sa date, sa matière, sa classe et son barème afin de préparer la saisie des résultats ? La seconde approche paraît plus cohérente avec les pratiques du secondaire.
Noyau de livraison envisageable : annoncer ou enregistrer une évaluation physique, identifier les élèves concernés, saisir les notes après correction, publier les résultats, appliquer le modèle de calcul retenu, faire valider le résultat et générer le bulletin. Le sujet peut rester un document produit dans Word ou sur papier ; son ajout comme pièce jointe doit rester facultatif.
Travaux de maison : un enseignant peut publier une consigne, une référence de manuel, une date de remise ou une pièce jointe. Cette trace permet à l’élève et surtout au parent de savoir qu’un travail a été demandé, sans transformer Scolario en plateforme d’apprentissage entièrement numérique.
Extensions à challenger : rédaction complète des sujets dans Scolario, composition en ligne, publication systématique des corrigés, sessions partagées entre plusieurs classes ou séries, répartition en salles, numéros de table, rattrapages multiples, tableau d’honneur et gestion complète des décisions annuelles.
Pourquoi séparer : le noyau répond au suivi scolaire et au calcul des résultats. Les extensions introduisent d’autres objectifs pédagogiques ou logistiques et ajoutent des variantes, états, permissions et écrans de contrôle.
Référentiel et année académique
Le référentiel fournit les données communes dont dépendent les autres interfaces. Sans lui, il est impossible de configurer correctement une classe, un planning, une évaluation ou un bulletin.
Voir les éléments concrets à traiter
Noyau de livraison : année active, périodes, niveaux et séries du secondaire béninois, classes, matières, coefficients nécessaires, rattachements des enseignants et affectation des élèves.
Extensions : plusieurs pays ou branches, versions des programmes officiels, comparaison et migration des programmes locaux, année préparée complète, archives avancées et établissement modèle réutilisable.
Approche proposée : modéliser correctement le socle, mais n’exposer dans les interfaces initiales que les configurations réellement utilisées par les parcours des cinq mois.
Circuits financiers à distinguer et à challenger
Le cahier des charges aborde trois relations financières différentes. Elles ne doivent ni être mélangées dans une seule expérience, ni être automatiquement considérées comme trois produits à construire.
Voir les trois circuits et les questions produit
- Finance scolaire des familles vers l’école : frais d’inscription, scolarité, échéances, paiements et reçus. Cette finance est au cœur de la gestion de l’établissement et paraît pertinente pour le parcours initial.
- Facturation de l’enseignant vers l’école : le document décrit la valorisation des heures et une facture normalisée. Il faut confirmer s’il s’agit d’honoraires d’enseignants vacataires, d’un complément au salaire ou d’un besoin fiscal plus général. Le front-end peut représenter le décompte et l’émission ; la connexion fiscale reste externe.
- Facturation de Scolario vers ses clients : abonnement de l’établissement, packs et coupons. Elle relève du modèle commercial de Scolario et peut impliquer une landing page et des écrans de gestion dédiés.
Point à challenger : les forfaits facturés directement au parent créent une dépendance difficile à justifier lorsque l’école reste la source des données et peut quitter Scolario. Une alternative serait que l’établissement finance l’accès de ses parents ou que les documents officiels déjà délivrés restent accessibles sans abonnement parent autonome.
5. Arbitrages proposés
Les arbitrages ci-dessous traduisent la position de travail actuelle. Ils pourront être modifiés pendant la réunion.
| Conserver dans le parcours initial | Simplifier | Reporter | Clarifier avant engagement |
|---|---|---|---|
| Socle établissement : contexte, année active, classes, matières et utilisateurs. Vie scolaire : planning, séances et présences. Pédagogie : évaluations simples, notes, calcul et bulletin. Finance école-famille : frais, échéances, paiements et reçus. Parent : consultation des informations publiées. |
Inscription : formulaire administratif avant pipeline configurable. Rôles : permissions utiles aux acteurs retenus avant les rôles composites avancés. Évaluations : classe et matière simples avant les sessions multi-séries. Support : contact direct et accès super-admin avant un système de tickets. Planning enseignant : changement de contexte comme base, avec étude d’une vue agrégée limitée. |
Logistique d’examens : plans de salle, shuffle et numéros de table. Programmes : versionnement et migration avancée. Mobile natif : après validation du web responsive. Automatisations backend : purge, intégrations fiscales et services externes, hors mission front-end. Archive parent payante : tant que le modèle n’est pas validé. |
Commercial : offres, packs, coupons, landing page et demande de démonstration. e-MeCeF : forme du parcours, personnalisation possible de la facture et service technique retenu. Finance enseignant : nature exacte des montants facturés. Planning multi-écoles : utilité réelle et limites de la vue unifiée. Livraison : réutilisabilité de l’existant, niveau d’intégration et cycles de retours. |
6. Audit du tableau de bord existant
Le client a déjà engagé l’implémentation d’une partie du tableau de bord d’administration. Cet existant doit être considéré comme un actif du projet, mais sa contribution réelle ne peut être estimée qu’après examen.
L’audit constitue la première activité du premier jalon. Il doit aboutir à une cartographie simple :
| Catégorie | Définition | Conséquence |
|---|---|---|
| Réutilisable | Structure, composants ou parcours cohérents avec le cadrage retenu. | Conserver et prolonger. |
| À ajuster | Base exploitable nécessitant des corrections UX, visuelles, responsives ou fonctionnelles. | Intégrer les reprises au jalon concerné. |
| À reconstruire | Éléments incompatibles avec le parcours, les règles métier ou la qualité attendue. | Replanifier explicitement la reconstruction. |
| Hors périmètre | Éléments déjà développés mais non retenus dans les cinq mois. | Conserver sans reprise immédiate. |
7. Décisions à valider conjointement
Notes et décisions de séance
Écrire ici les décisions complémentaires, réserves et éléments à reformuler.