Questions–réponses potentielles (avec réponses suggérées)

1) Contexte & choix du sujet

Q. Pourquoi avoir choisi un e-commerce, et en quoi est-ce pertinent au Sénégal ?
R. La vente en ligne progresse avec l’Internet mobile et les paiements digitaux. Mon projet
vise à offrir un outil simple et fiable aux petites structures/indépendants, en intégrant les
usages locaux (Mobile Money, suivi commande, facture PDF).
Q. Quelle problématique ciblez-vous précisément ?
R. Manque de confiance, sécurité des paiements, gestion du stock/commandes et simplicité
d’usage. EazyStore répond par : parcours clair, paiements adaptés (simulés/à la livraison),
administration des ventes/stocks, factures PDF et notifications e-mail.
2) Besoins & périmètre
Q. Distinguez besoins fonctionnels vs non-fonctionnels.
R. Fonctionnels : catalogue, panier, commande, paiement, espace client, back-office admin.
Non-fonctionnels : responsive, sécurité (auth, rôles, validation), performance (pagination,
temps de réponse), compatibilité navigateurs, maintenabilité.
Q. Comment avez-vous collecté les besoins sans maquettes Figma ?
R. Observation de boutiques physiques à Dakar + benchmark de sites e-commerce ; j’ai
traduit ces constats en interfaces Bootstrap directement, en itérant jusqu’à une UX simple
(navigation, promotions, panier visible, formulaire court).
3) Modélisation UML
Q. Quels sont les acteurs et cas d’utilisation clés ?
R. Acteurs : Client et Administrateur. Côté client : s’inscrire/se connecter,
parcourir/rechercher, panier/commande, choisir paiement, suivre historique, télécharger
facture, recevoir e-mails. Côté admin : gérer produits/catégories/utilisateurs/commandes,
stats, factures, notifications.
Q. Dans le diagramme de classes, pourquoi séparer Client et Administrateur ?
R. Pour exprimer les rôles/permissions clairement : Client et Administrateur héritent
d’Utilisateur (attributs communs en protected), tandis que leurs attributs spécifiques restent en
private. Cela clarifie l’accès et la sécurité. (Remarque intégrée suite au feedback encadrant.)
Q. Quelles cardinalités avez-vous retenues ?
R. 1 Utilisateur → * plusieurs Commandes ; 1 Commande → * plusieurs LignesCommande ;
1 Produit → 1 Catégorie (ou 1..* si sous-catégories plus tard) ; 1 Commande ↔ 1 Paiement ;
1 Commande ↔ 1 Facture ; 1 Utilisateur → * Notifications.
4) Architecture & technologies
Q. Pourquoi Laravel + MySQL + Bootstrap 5 ?
R. Laravel (MVC, migrations, validation, middlewares, Mail) accélère un backend propre ;
MySQL est robuste et connu ; Bootstrap 5 garantit un responsive fiable et rapide à mettre en
œuvre. Stack accessible, documentée, adaptée à un POC évolutif.
Q. Packages et composants clés ?
R. Laravel Breeze (auth), Spatie/Permission (rôles/permissions), DomPDF (factures PDF),
Laravel Mail (notifications e-mail). Ensemble cohérent pour répondre aux besoins e-
commerce de base.
5) Base de données & intégrité
Q. Comment assurez-vous l’intégrité des données ?
R. Migrations avec contraintes (clé étrangère, on delete), types adaptés (montants décimaux,
statuts enums), index sur colonnes de jointure (FK) et de recherche ; validations serveur côté
Laravel avant insertion.
Q. Gestion du stock ?
R. Décrément du stock après confirmation de commande ; transactions DB pour éviter les
incohérences sur commandes simultanées (pattern “réserver/valider”).
6) Sécurité & rôles
Q. Quelles mesures de sécurité avez-vous mises ?
R. Auth Laravel (hash mot de passe, CSRF, validation), middlewares d’accès selon rôles
(Spatie), sanitisation des entrées, politiques d’accès sur ressources (policies). Séparation back-
office/front-office et logs d’actions sensibles.
Q. Gestion des mots de passe/e-mails ?
R. Hash sécurisé (Bcrypt/Argon2 via Laravel), flux mot de passe oublié, tokens temporaires.
Pour l’e-mail, envoi via Laravel Mail (environnement dev), modèles standard (confirmation
de commande, mise à jour statut).
7) Paiements & facturation
Q. Pourquoi paiement “simulé” et paiement à la livraison ?
R. Contraintes de coûts et d’accès aux API locales (Orange Money, Wave) durant le PFE ; le
simulé permet de valider le flux applicatif, et “à la livraison” colle aux usages locaux.
Intégration d’API réelles prévue en évolution.
Q. Génération de factures et notifications ?
R. Facture PDF générée à chaque commande validée (DomPDF) ; e-mail automatique de
confirmation + facture en pièce jointe ; e-mails sur changement de statut/paiement.
8) Tests & qualité
Q. Quels tests avez-vous réalisés ?
R. Tests fonctionnels manuels par scénarios (parcours client, CRUD admin, paiements
simulés, facture, e-mails) + vérifications de sécurité (auth, rôles, accès). À prévoir :
PHPUnit/Dusk, tests de charge, couverture plus fine.
Q. Comment avez-vous validé le responsive ?
R. Bootstrap 5, grilles et composants responsives ; tests sur Chrome/Edge et différents
breakpoints (mobile/tablette/desktop).
9) Déploiement & démonstration
Q. Pourquoi Ngrok plutôt qu’un hébergeur ? limites ?
R. Choix économique et rapide pour une démo externe : URL publique vers mon serveur
local XAMPP, utile pour retours utilisateurs. Limites : URL temporaire, performance/latence,
pas de SLA. Le code est versionné sur GitHub pour préparer un futur déploiement.
Q. Prochaine étape de mise en prod ?
R. VPS/PAAS (Nginx/Apache, PHP-FPM), SSL, base MySQL managée, queue pour e-mails,
stockage d’objets (images/factures), CI/CD, monitoring (logs, alertes), intégration API
paiements locaux (test → prod).
10) Performance & évolutivité
Q. Quelles optimisations envisagez-vous ?
R. Pagination/tri côté DB, requêtes Eloquent optimisées (eager loading), cache
config/vue/routes, indexation, CDN pour assets, compression images, files d’attente pour e-
mails, profiling (Laravel Telescope).
11) UX & accessibilité
Q. Comment avez-vous intégré les retours terrain dans l’UX ?
R. Navigation simple, produits très visibles, promo mise en avant, panier accessible,
formulaire commande court, textes clairs sur modes de paiement, feedback systématique
(toasts/alertes).
12) Limites & perspectives
Q. Principales limites actuelles ?
R. Pas d’hébergement permanent, paiements réels non intégrés, peu de tests automatisés,
analytics basiques.
Évolutions : API paiements (OM/Wave), hébergement prod, Dusk/PHPUnit,
logs/monitoring, rôles fins, filtres avancés, recommandations, SEO, i18n.
13) Questions “pièges” fréquentes
Q. Et si deux clients achètent le dernier produit en même temps ?
R. Verrous/transactions au moment de la validation de commande ; contrôle du stock en base
avant écriture ; message d’indisponibilité si épuisé.
Q. Pourquoi ne pas avoir fait d’appli mobile ?
R. Priorité au web responsive (couverture maximale, coût/temps maîtrisés). Une PWA ou une
appli mobile native peut suivre si la base web est stable.
Q. En cas d’échec d’envoi d’e-mail ?
R. Retry via file d’attente ; journalisation des statuts ; lien facture disponible dans l’espace
client même si l’e-mail n’est pas reçu.
 Prise de Notes :
🔹 Développement du frontend
Le frontend correspond à la partie visible par les utilisateurs (clients et administrateurs).
C’est l’interface avec laquelle ils interagissent.
Dans ton projet, cela inclut :
 Les pages clients (vues Blade) : accueil, catalogue produits, panier, commande,
paiement, espace personnel.
 L’interface administrateur (Dashboard) : gestion des produits, catégories,
commandes, utilisateurs, paiements.
 L’expérience utilisateur (UX/UI) : navigation fluide, design responsive (adapté PC,
tablette, smartphone), couleurs sobres, boutons visibles.
👉 Concrètement, tu as utilisé :
 Blade (Laravel) pour générer les vues,
 Bootstrap 5 pour le design et la mise en page,
 HTML/CSS/JS pour rendre l’interface claire et interactive.
Objectif : rendre l’application simple, moderne et agréable à utiliser.

🔹 Développement du backend
Le backend correspond à la partie cachée, qui gère la logique métier et la communication
avec la base de données.
Dans ton projet, cela inclut :
 La gestion des utilisateurs (inscription, connexion, rôles client/admin).
 La gestion des produits et catégories (CRUD).
 La gestion des commandes et du panier (ajout/suppression, calcul total).
 La gestion des paiements (avant ou après livraison).
 La génération de factures PDF et envoi d’emails.
 La gestion des livraisons et des livreurs.
 Le tableau de bord administrateur (statistiques, suivi des ventes).
👉 Concrètement, tu as utilisé :
 Laravel (PHP) comme Framework backend,
 MySQL comme base de données relationnelle,
 Eloquent ORM pour gérer les tables et relations,
 Middleware pour sécuriser les accès (admin vs client).
Objectif : assurer la fiabilité, la sécurité et la performance du système.

✅ En résumé :
 Frontend = la vitrine du site, ce que l’utilisateur voit et utilise.
 Backend = le moteur du site, qui exécute la logique, gère les données et communique
avec le frontend.
TEST FONCTIONNELS
Les tests fonctionnels servent à garantir que l’application fait exactement ce pour quoi elle
a été conçue, sans erreurs, en toute sécurité, et de manière fluide pour l’utilisateur.

Donc quand ton rapport dit :

« représentées par des ellipses »,
ça veut dire : chaque action (cas d’utilisation) est dessinée dans une bulle ovale.