Mémoire de Fin d'Études

Ce mémoire de fin d’études s’inscrit dans le domaine de l’informatique, plus précisément dans le génie logiciel appliqué à la gestion des systèmes de points de vente. Il présente la réalisation d’un module back office pour un système terminal point de vente nommé MOBIPOS. Ce travail intéressera particulièrement les étudiants et professionnels souhaitant comprendre comment concevoir et développer un système de gestion commerciale multi-magasins, ainsi que les méthodes et outils utilisés dans un contexte professionnel.

La question

Le projet vise à répondre à un besoin concret : la gestion efficace des points de vente pour une entreprise multi-magasins, en particulier pour Algérie Ferries qui souhaite gérer ses magasins à bord de ses navires. Le système MOBIPOS, déjà existant pour la partie front office (gestion des ventes et encaissement), nécessite un module back office capable d’assurer les fonctions essentielles de pilotage, telles que la gestion des stocks, des utilisateurs, des magasins, la génération de rapports et la configuration du système. Ce module doit permettre une administration complète et centralisée, facilitant ainsi la gestion commerciale et opérationnelle des magasins.

Concepts de base

Pour bien comprendre ce projet, il est important de saisir quelques notions clés :

• Terminal Point de Vente (TPV) : une caisse enregistreuse informatisée connectée au système d’information du magasin, qui permet la gestion des ventes et des encaissements.
• Back Office : la partie du système qui gère l’administration, la configuration, les stocks, les rapports et le suivi des opérations, en opposition au front office qui est centré sur la vente directe.
• MOBIPOS : une solution informatique conçue pour la gestion et le contrôle des magasins, composée d’un front office (TPV) et d’un back office.
• Gestion multi-magasins : la capacité à administrer plusieurs points de vente distincts depuis une interface centralisée.
• Spécification des besoins : identification des fonctionnalités attendues, des contraintes techniques, fonctionnelles et de sécurité.
• Diagrammes UML : outils de modélisation utilisés pour représenter les cas d’utilisation, les séquences d’interactions, et la structure des données (diagrammes de classes).

Le système MOBIPOS back office doit permettre à un administrateur, qui est l’acteur principal et possède les privilèges les plus élevés, de gérer les utilisateurs, employés, catégories, produits, stocks, magasins, cartes d’embarquement, traversées, historiques de ventes, et de générer des rapports.

Approche

Le développement du module back office MOBIPOS s’est déroulé dans un cadre professionnel, au sein de la société Eurequat Algérie, sur une période de quatre mois. La méthodologie adoptée est la méthode Scrum, qui favorise un développement itératif et incrémental, permettant d’adapter rapidement le produit aux besoins et retours du client.

Les étapes principales ont été :

• Choix des outils et du langage de développement adaptés au projet.
• Rédaction d’un cahier des charges précisant les contraintes techniques, fonctionnelles et de sécurité.
• Modélisation du système à l’aide de diagrammes UML (cas d’utilisation, séquence, classes) pour structurer les besoins et la conception.
• Développement en plusieurs sprints, avec des tests unitaires, d’intégration et d’acceptation pour assurer la qualité du logiciel.
• Gestion des anomalies classées selon leur gravité (bloquante, majeure, mineure) afin de corriger les erreurs et améliorer le système.

L’architecture du module back office a été conçue pour permettre une gestion complète et modulable des fonctionnalités, en intégrant notamment la gestion des stocks, des ventes, des utilisateurs et des magasins.

Résultats

Le mémoire conclut que le module back office MOBIPOS a été réalisé avec succès, intégrant toutes les fonctionnalités demandées dans le cahier des charges. Le système développé a été testé rigoureusement et approuvé par le client, ce qui atteste de sa conformité aux attentes et de sa qualité fonctionnelle.

Les tests réalisés ont couvert différents niveaux, notamment :

• Tests unitaires : vérification des composants individuels.
• Tests d’intégration : validation des interactions entre composants.
• Tests d’acceptation : validation finale par le client.

Des anomalies ont été identifiées et corrigées, allant de problèmes bloquants (rendant le système inutilisable) à des erreurs mineures (orthographe, affichage). Le système est donc opérationnel et prêt à être déployé.

Limites et questions ouvertes

Le mémoire mentionne des perspectives d’amélioration qui n’ont pas été intégrées dans cette première version :

• La gestion des commandes et des fournisseurs, qui pourrait enrichir la gestion commerciale.
• Une amélioration du back office pour aboutir à une version standardisée, plus générique et adaptable à différents contextes.
• L’amélioration de l’interface utilisateur pour une meilleure ergonomie et un aspect visuel plus attractif.

Ces points ouvrent la voie à des développements futurs, soulignant que le projet, bien que fonctionnel, peut encore évoluer pour mieux répondre aux besoins des utilisateurs et du marché.

Glossaire

• Administrateur : utilisateur principal du back office, avec tous les droits pour gérer le système.
• Back office : partie du système dédiée à l’administration, la gestion des stocks, des rapports et des configurations.
• Front office : interface utilisée pour la gestion des ventes et l’encaissement sur le terminal point de vente.
• Point de vente (TPV) : caisse enregistreuse informatisée connectée au système d’information.
• Scrum : méthode de gestion de projet agile basée sur des cycles courts appelés sprints.
• Sprint : période de travail itérative dans la méthode Scrum, durant laquelle un ensemble de fonctionnalités est développé.
• Diagramme UML : représentation graphique des éléments et interactions d’un système logiciel.
• Tests unitaires : vérification du bon fonctionnement des plus petites unités du logiciel.
• Tests d’intégration : vérification du bon fonctionnement des interactions entre plusieurs composants.
• Tests d’acceptation : validation finale du logiciel par le client ou utilisateur.
• Anomalie bloquante : défaut empêchant l’utilisation normale du système.
• Anomalie majeure : défaut ayant un impact important, notamment réglementaire.
• Anomalie mineure : défaut sans impact réglementaire, souvent esthétique ou mineur.