Le transport lacustre est une alternative essentielle aux modes terrestre et aérien, jouant un rôle clé dans l'économie en facilitant les échanges commerciaux et la mobilité des personnes. Cependant, les agences comme les établissements SILIMU rencontrent des difficultés majeures, notamment l'absence d'un système de réservation en ligne, une gestion inefficace des flux de passagers et de marchandises, ainsi qu’un manque de traçabilité financière. Pour remédier à ces problèmes, ce mémoire propose le développement d’une plateforme intégrée de réservation et de gestion du trafic lacustre. Une approche MVP (Minimum Viable Product) a été adoptée pour permettre un déploiement rapide des fonctionnalités essentielles et une amélioration progressive grâce aux retours des utilisateurs. La conception repose sur des modèles UML (Unified Modeling Language) pour structurer les interactions du système, tandis que l’implémentation utilise Spring Boot et PostgreSQL pour la gestion des données, avec Docker pour garantir la conteneurisation et la portabilité. La plateforme comprend une application mobile pour les guichetiers et une application web destinée à l’agence et à ses clients, centralisant les informations essentielles comme la disponibilité des places, la gestion des flux financiers et le suivi des performances. De plus, elle intègre un système de notifications en temps réel pour informer les clients sur leurs réservations, la vente de billets et les campagnes marketing, ainsi que des services de paiement électronique pour faciliter les transactions effectuées lors des réservations et réduire les files d’attente. En optimisant la gestion du trafic lacustre, cette solution améliore l’efficacité des opérations, renforce la transparence financière et offre une meilleure expérience aux clients.
Sommaire
Epigraphe
Dédicace
Remerciements
Résumé
Abstract
Sommaire
Sigles et abréviations
Liste des tableaux
Liste des figures
INTRODUCTION GENERALE
Chapitre I : GENERALITES
Chapitre II : ANALYSE DE L’EXISTANT ET CONCEPTION DE LA PLATEFORME TOYHE
Chapitre III : Implémentation de la plateforme TOYHE
Conclusion générale
Annexe A Guide D’entretien
Annexe B Logo de la plateforme TOYHE
Annexe C Autres Interfaces communes à tous les utilisateurs
Annexe D Présentation du site web de la plateforme TOYHE
Bibliographie
Epigraphe
« Les ordinateurs, pour le moment, ne peuvent qu’exécuter des ordres, avec divers niveaux de sophistication. C’est donc au d éveloppeur d’’être clair : la machine fait ce que vous dîtes, pas ce que vous voulez dire. (Coder, ce n’est ni facile, ni marrant) » [1].
Citation de Walter Vannini
Dédicace
À AYUBA ALUHEBA Job, mon oncle paternel, et à son épouse EVERINE MUKOMBI, dont le soutien indéfectible et les sacrifices constants ont permis de rendre ce parcours universitaire possible. Votre bienveillance, votre générosité et votre foi en mes capacités ont été des piliers essentiels tout au long de cette aventure académique. Cette réussite est autant la vôtre que la mienne.
Que cet ouvrage soit le témoignage de ma profonde gratitude et de mon immense respect envers vous.
AMURI TCHALUMBA Héritier
Remerciements
Nous tenons tout d'abord à exprimer notre profonde gratitude à YHWH Tout-Puissant, qui nous a accordé la force, la santé et la sagesse nécessaires pour mener à bien ce mémoire.
Nous tenons à exprimer notre sincère gratitude aux autorités de l'ULPGL pour leur soutien constant et pour avoir créé un cadre propice à notre réussite. Un grand merci à notre Directeur, le MSc KAMBALE WAMUHINDO Abednego pour ses précieux conseils et son accompagnement, ainsi qu'à notre Encadrant l’Ir IKANGAMINO KISAMBA Johnson pour sa disponibilité et son soutien indéfectible tout au long de ce travail.
Nous exprimons notre gratitude à nos parents, AEMBE TCHALUMBA Freddy et NAY'ENGE ABILA Véronique, pour leur amour, leurs conseils, leurs prières et leur soutien financier, qui ont été une grande source d'inspiration. Nous remercions également nos tuteurs, mentionnés dans la dédicace, pour leur soutien constant, leur générosité, et leur foi en notre potentiel, qui ont contribué de manière significative à notre réussite.
Nous exprimons notre profonde gratitude à nos sœurs Beatrice ABALA, Aimérance OÙOÙNDA, Grâce MERVEILLE et Alphonsine MERVEILLE, ainsi qu'à nos frères Lary ABILA, Fabrice ABILA et Jean-Luc AMURI, pour leur soutien constant et leurs encouragements, qui ont été pour nous une source de persévérance. Nous remercions aussi nos oncles Alùheba ABECUMBE, Noa ABILA, Lùlinda SIBATWA et Alfani ABILA, nos tantes Theresa PENDEZA et Fatuma FAIZI, nos grands-pères Honoré ALÙHEBA, Bwimana AEMBE, Venace AEMBE, Benjamin AEMBA et Manassé LÙBÙNGA, ainsi que toute notre famille élargie, pour leur soutien moral et leurs encouragements précieux.
Nous n'oublions pas de remercier nos camarades de promotion, avec qui nous avons partagé des moments inoubliables, des défis et des réussites, en particulier Robert KULE, Prince KIRANGA, Barthélemy IKUZWE, Rosette SIFA et Gloire AHADI. Votre camaraderie et votre esprit d'équipe ont grandement enrichi notre expérience universitaire.
À toutes celles et à tous ceux, de près ou de loin, qui ont contribué à la réalisation de ce travail, je vous adresse un grand merci pour votre soutien et vos encouragements.
AMURI TCHALUMBA Héritier
Résumé
Le transport lacustre est une alternative essentielle aux modes terrestre et aérien, jouant un rôle clé dans l'économie en facilitant les échanges commerciaux et la mobilité des personnes. Cependant, les agences comme les établissements SILIMU rencontrent des difficultés majeures, notamment l'absence d'un système de réservation en ligne, une gestion inefficace des flux de passagers et de marchandises, ainsi qu’un manque de traçabilité financière. Pour remédier à ces problèmes, ce mémoire propose le développement d’une plateforme intégrée de réservation et de gestion du trafic lacustre. Une approche MVP (Minimum Viable Product) a été adoptée pour permettre un déploiement rapide des fonctionnalités essentielles et une amélioration progressive grâce aux retours des utilisateurs. La conception repose sur des modèles UML (Unified Modeling Language) pour structurer les interactions du système, tandis que l’implémentation utilise Spring Boot et PostgreSQL pour la gestion des données, avec Docker pour garantir la conteneurisation et la portabilité. La plateforme comprend une application mobile pour les guichetiers et une application web destinée à l’agence et à ses clients, centralisant les informations essentielles comme la disponibilité des places, la gestion des flux financiers et le suivi des performances. De plus, elle intègre un système de notifications en temps réel pour informer les clients sur leurs réservations, la vente de billets et les campagnes marketing, ainsi que des services de paiement électronique pour faciliter les transactions effectuées lors des réservations et réduire les files d’attente. En optimisant la gestion du trafic lacustre, cette solution améliore l’efficacité des opérations, renforce la transparence financière et offre une meilleure expérience aux clients.
Mots-clés : Application web, Application mobile, API, Web Service, Réservation en ligne.
Abstract
Lake transport is an essential alternative to land and air modes, playing a key role in the economy by facilitating commercial exchanges and the mobility of people. However, agencies such as SILIMU establishments face major difficulties, including the absence of an online booking system, inefficient management of passenger and cargo flows, as well as a lack of financial traceability. To address these issues, this thesis proposes the development of an integrated reservation and lake traffic management platform. A Minimum Viable Product (MVP) approach has been adopted to enable the rapid deployment of essential features and progressive improvements through user feedback. The design is based on UML (Unified Modeling Language) models to structure the system's interactions, while the implementation uses Spring Boot and PostgreSQL for data management, with Docker ensuring containerization and portability. The platform includes a mobile application for ticket agents and a web application for the agency and its customers, centralizing essential information such as seat availability, financial flow management, and performance tracking. Additionally, it integrates a real-time notification system to inform customers about their reservations, ticket sales, and marketing campaigns, as well as electronic payment services to facilitate transactions during reservations and reduce queues. By optimizing lake traffic management, this solution improves operational efficiency, strengthens financial transparency, and offers a better customer experience.
Keywords : Web application, Mobile application, API, Web Service, Online reservation.
Sigles et abréviations
Illustrations are not included in the reading sample
Liste des tableaux
Tableau 1 : Documentation du cas d’utilisation « CréerCompte »
Tableau 2 : documentation du cas d’utilisation « SAuthentifier »
Tableau 3 : Documentation du cas d’utilisation « RéserverBillet »
Tableau 4 : Documentation du cas d’utilisation « AjouterUtilisateur »
Tableau 5 : Documentation du cas d’utilisation « ImprimerBilletOuFicheDInventaire »
Liste des figures
Figure 1 : Canaux de paiement pris en charge par la passerelle MaxiCash
Figure 2 : Structure des messages SOAP
Figure 3 : Diagramme de cas d’utilisation d’un client potentiel et d’un client
Figure 4 : Diagramme de cas d’utilisation d’un administrateur et d’un guichetier
Figure 5 : Diagramme de cas d’utilisation d’un CSM et d’un CSP
Figure 6 : Diagramme de cas d’utilisation d’un DG et d’un CSE
Figure 7 : Diagramme de cas d’utilisation d’un DAF
Figure 8 : Diagramme de séquence du cas d’utilisation « SAuthentifier »
Figure 9 : Diagramme de séquence du cas d’utilisation « RéserverBillet »
Figure 10 : Diagramme de classes
Figure 11 : Diagramme de déploiement
Figure 12 : Page d’authentification de la plateforme TOYHE
Figure 13 : Interfaces principales de l'onglet d'accueil de la plateforme TOYHE
Figure 14 : Interfaces de réservation de billet de voyage sur la plateforme TOYHE
Figure 15 : Interface d'envoi de messages sur la plateforme TOYHE
Figure 16 : Interface affichant les horaires de voyage de l’agence sur la plateforme TOYHE
Figure 17 : Interface d'affichage de l'état des bateaux, de la disponibilité des places et de la capacité de charge sur la plateforme TOYHE
Figure 18 : Historique des commandes effectuées par réservation et vente de billets, réalisées par les agents, partenaires, clients et administrateurs de l'agence de transport
Figure 19 : Interface de suivi des ventes des guichetiers, affichant l'évolution des ventes et les revenus générés
Figure 20 : Interface de suivi des performances de l'agence de transport, montrant les réservations, les ventes de billets et les revenus générés sur une période donnée
Figure 21 : Interface de gestion des utilisateurs de la plateforme TOYHE
Figure 22 : Interface de demande de fonds par les agents de l'agence auprès du DAF
Figure 23 : Interface d'envoi de rapports au DG et de visualisation des rapports par les agents de l'agence de transport
Figure 24 : Interface d’envoi de réclamation par le client ou le partenaire de l’agence
Figure 25 : Interfaces de création de compte sur la plateforme TOYHE
Figure 26 : Interface d’envoi de campagne publicitaire par le Chargé de marketing
Figure 27 : Exemple de système de point de vente
Figure 28 : Interfaces clés pour le guichetier sur la plateforme TOYHE
Figure 29 : Interface de gestion de compte sur la plateforme TOYHE
Figure 30 : Interface d’aide et support de la plateforme TOYHE permettant aux utilisateurs d’accéder aux guides d’utilisation
Figure 31 : Interface de modification des informations de l'utilisateur sur la plateforme TOYHE
Figure 32 : Onglet « Accueil » du site TOYHE
Figure 33 : Onglet « Paiement » du site de la plateforme TOYHE
Figure 34 : Onglet « Application Mobile » du site de la plateforme TOYHE
INTRODUCTION GENERALE
0.1. Contexte
Le transport lacustre occupe une place croissante dans les réseaux de mobilité, offrant une alternative crédible au transport terrestre et aérien. Le Lac Kivu, qui relie les chefs-lieux de Goma (Nord-Kivu) et de Bukavu (Sud-Kivu) sur près de 200 km, voit transiter chaque jour des centaines de passagers et des tonnes de marchandises. Cette activité exige une planification rigoureuse des voyages, un suivi précis des recettes et une facturation transparente pour répondre à la demande croissante des populations riveraines, des voyageurs et des acteurs économiques.
L’essor des technologies de l’information et de la communication permet aujourd’hui de moderniser la prise en charge des réservations payantes, de centraliser en temps réel les données d’exploitation et d’optimiser la planification opérationnelle. Une plateforme intégrée de réservation et de gestion des voyages offre ainsi la possibilité d’améliorer à la fois l’expérience client et l’efficacité interne des compagnies lacustres.
C’est dans cette dynamique que s’inscrit la présente étude, qui vise à concevoir une solution numérique permettant d’optimiser la gestion des voyages et la prise en charge des réservations payantes au sein des agences de transport lacustre. L’analyse se base sur l’expérience des établissements SILIMU, une entreprise opérant entre Goma et Bukavu, afin de mettre en lumière les enjeux, les défis et les apports d’un tel outil dans l’amélioration de la qualité des services et de la performance opérationnelle.
0.2. Identification et formulation du problème
Malgré leurs succès, les Ets SILIMU sont confrontés à plusieurs défis liés à la gestion croissante du trafic lacustre. L'absence d'un système de réservation en ligne et d'une limitation du nombre de passagers à bord des bateaux expose l'agence à des risques de surcharge et de saturation. De plus, la gestion manuelle des billets et des informations relatives aux trafics s'avère fastidieuse et peu efficiente.
Ces défis entravent la capacité de SILIMU à offrir une expérience optimale à ses clients et à optimiser ses opérations. La mise en place d'une solution numérique innovante s'avère indispensable pour répondre aux besoins croissants de l'agence et améliorer la qualité de ses services.
0.3. Questions de recherche
Eu égard au problème précédent, les questions suivantes font l’objets de notre préoccupation :
1. Quelle est la meilleure approche pour mettre en œuvre une gestion proactive du trafic lacustre avec un système de réservation de billets en ligne ?
2. Comment gérer efficacement les informations relatives aux trafics lacustres croissants ?
Nous nous mobilisons de répondre à ce problème en nous posant les différentes questions spécifiques :
1. Quelle stratégie de développement de la plateforme adopter pour répondre aux besoins essentiels des utilisateurs cibles ?
2. Quel type de solution de paiement électronique intégrer à la plateforme pour permettre à tous les utilisateurs d'effectuer des réservations ?
0.4. Formulation des hypothèses
Les questions précédentes nous guident à reformuler les hypothèses suivantes :
1. Le développement d'une plateforme de réservation et de gestion du trafic lacustre axée sur l'efficacité, la sécurité, la réduction de la congestion, la facilité d'accès aux services et le suivi des performances de l'agence constituerait la meilleure approche.
2. La centralisation et la transmission en temps réel des informations sur la plateforme permettraient à l'agence de les exploiter efficacement.
3. L'adoption d'une approche MVP (Minimum Viable Product) pour le développement de la plateforme permettrait de valider rapidement le concept et de recueillir les commentaires des utilisateurs avant un développement complet.
4. L'intégration d'un service Web de passerelle de paiement prenant en charge divers services de paiement électronique permettrait à tous les utilisateurs d'effectuer des réservations.
0.5. Justification du choix du sujet et motivations
À travers cette recherche, nous voulons nous attaquer à une réalité qui touche quotidiennement des milliers de personnes : les difficultés liées à l’organisation des voyages sur le Lac Kivu. Ce corridor naturel, qui relie les villes de Goma et de Bukavu, est un axe vital pour le commerce, les échanges humains et le développement local. Pourtant, malgré son importance stratégique, la gestion des déplacements sur ce lac reste encore largement artisanale, exposant les usagers à des incertitudes et les opérateurs à de nombreuses inefficacités.
C’est en observant ces lacunes et en échangeant avec les acteurs du terrain que nous avons senti le besoin d’imaginer une nouvelle façon de faire. Nous avons été motivés par le désir d’apporter une contribution concrète à l’amélioration de ce secteur, en proposant une réponse innovante aux besoins exprimés par les voyageurs comme par les agences de transport. Cette volonté de repenser la mobilité sur le Lac Kivu nous a guidés dans le choix de notre sujet. Il ne s’agit pas seulement d’un exercice académique, mais d’un engagement personnel et collectif à initier une dynamique de transformation dans un domaine encore peu touché par les avancées numériques.
Nous croyons fermement que le génie informatique peut, lorsqu’il est bien orienté, produire des solutions simples, efficaces et accessibles, capables de transformer durablement le quotidien des populations. À travers ce travail, nous aspirons à ouvrir une voie, à inspirer d’autres initiatives locales, et à démontrer qu’il est possible de conjuguer innovation, utilité sociale et amélioration des conditions de vie par des moyens technologiques adaptés à notre réalité.
Notre plateforme aura le nom de TOYHE, qui tire son origine de la prononciation du mot de la langue Africaine Bembé tùyè \toj\ qui veut dire allons-nous-en ou voyageons en Français. Ce nom symbolise notre ambition de faciliter et d’organiser le mouvement des personnes et des biens sur le Lac Kivu, avec une solution pensée pour elles, avec elles.
0.6. Énoncé des objectifs de recherche
0.6.1. L’objectif général
L’objectif générale de notre travail est de développer une plateforme intégrée pour une gestion proactive du trafic lacustre avec un système de réservation de billets en ligne utilisant des services de paiement électronique.
0.6.2 Les objectifs spécifiques
Nous poursuivons comme objectifs spécifiques :
1. Réaliser un outil d’analyse permettant à l’agence SILIMU d’identifier les tendances et de prendre des décisions éclairées concernant la gestion du trafic et l’allocation des ressources.
2. Développer une application Web et une application mobile permettant la centralisation et la transmission en temps réel des informations sur la plateforme.
3. Identifier une Application Programming Interface (API) de passerelle de paiement prenant en charge les services de paiement électronique Airtel Money, MaxiCash, M-Pesa, Orange Money, PayPal, PPLE Mobile et VISA MasterCard.
4. Intégrer une option de paiement sécurisée dans la plateforme pour réduire les files d’attente aux guichets de vente de billets au niveau de port de Goma et Bukavu.
0.7. Méthodologie et délimitation du travail
0.7.1. Méthodes et Technique du travail
Dans le présent travail nous allons utiliser la méthode analytique qui nous permettra à décomposer le développement de notre plateforme en commençant par la définition des fonctionnalités et des services, puis la conception de l’architecture technique et enfin le choix des technologies et des outils de développement. Nous utiliserons également la méthode expérimentale pour développer des modules et des fonctionnalités de la plateforme, intégration des technologies et des services tiers et faire les tests et validation.
Pour montrer les points critiques fréquents, nous utiliserons la technique de l’observation qui nous permettra d’exprimer les faiblesses de certains sous services des Ets SILIMU. Nous utiliserons également la technique de questionnaire ou sondage pour récolter les différentes données en rapport avec notre travail de recherche.
0.7.2 Délimitation du Sujet
La présente étude a comme champ d’application l’agence de transport lacustre Ets SILIMU. Cette étude s’articule sur le développement d’une plateforme intégrée pour la réservation et la gestion du trafic sur le Lac Kivu et met en évidence le renforcement de la communication digitale de l’agence de transport.
Dans le temps, notre recherche se rapporte aux problèmes que surmontent les Ets SILIMU durant l’année 2024. Dans l’espace, la présente étude se limite à l’amélioration de la gestion du trafic sur le Lac Kivu. Dans la matière, nous développons une plateforme qui contient juste assez de fonctionnalités pour répondre aux besoins essentiels des utilisateurs cibles.
0.8. Subdivision du travail
Hormis l’introduction et la conclusion générale, la présente étude s’articule sur trois chapitres :
— Dans le premier chapitre portant sur les Généralités, nous présentons les notions de plateforme business, la plateforme passerelle de paiement électronique et enfin les services Web que nous avons utilisés.
— Dans le deuxième chapitre portant sur l’analyse de l’existant et la conception de la plateforme TOYHE, nous analysons le système existant, en faisons la critique et procédons à la conception du système que nous proposons dans ce travail, en nous servant du formalisme de modélisation UML.
— Dans le troisième chapitre portant sur l’implémentation de la plateforme TOYHE, nous présentons les technologies utilisées et les interfaces clés de notre plateforme.
Chapitre I : GENERALITES
1.1 Introduction Partielle
Ce chapitre présente une notion d’introduction aux plateformes business, au paiement électronique et passerelles de paiement électronique, ainsi qu’aux services web. Ces notions sont essentielles pour comprendre le sujet de la réalisation présentée dans ce document.
1.2 Plateforme Business
1.2.1 Définition
Francis Nappez, Directeur des nouvelles technologies et co-fondateur de BlaBlaCar, qui est intervenu lors d’une réunion de travail au Cigref, propose comme définition « attirer, faire rencontrer et relier les gens ou entreprises pour leur permettre de faire des transactions » [2].
Les plateformes business répondent aux enjeux des entreprises qui ne souhaitent pas s’arrêter à la seule connaissance des besoins de leurs utilisateurs finaux. Elles augmentent les interactions avec les utilisateurs, et passent ainsi d’une culture « produit » qui prend trop souvent fin au moment de la vente, à une culture « services » qui les engage sur la durée et qui les recentre sur l’usage pour le client [2].
1.2.2 Rôle d’une plateforme business
Dans un monde où le numérique est perçu comme un levier majeur d’innovation et de transformation pour les entreprises, les dirigeants doivent accompagner, sinon impulser, le mouvement. Ils doivent donc maîtriser à la fois les compétences relatives à la gestion d’une entreprise et les capacités à développer une vision stratégique liée au numérique [3].
La plateforme business répond avant tout à une problématique client dans un écosystème. La plateforme organise et hiérarchise les contenus (proposition de services ou de produits) en vue de leur présentation aux utilisateurs finaux. Elle permet de générer la transaction d'échange entre la donnée proposée (offre) et la donnée recherchée (demande). Elle permet en plus de créer de la valeur via l'analyse d’un grand nombre de données et des transactions, en un temps record, soit pour affiner les propositions, soit pour en exploiter leur traduction vers d'autres services [2].
1.2.3 Éléments clés d’une plateforme business [2]
Selon Francis Nappez, l’écosystème d’une plateforme business doit garder en tête constamment, de la conception au développement mais encore tout au long de la vie de la plateforme, quatre préoccupations majeures. Il les nomme d’ailleurs « obsessions » !
1) Attirer par l’innovation et l’effet réseau : définir quels sont les pôles d’intérêt (offre et demande) et la proposition de valeur associée ;
2) Faire correspondre, matcher : améliorer la pertinence des critères d’appariement et combler les attentes avec des offres associées ou connexes ;
3) Connecter : afin que les gens se connectent sur la plateforme, l’écosystème limite au maximum les frictions liées à l’interface et améliore l’efficience des connexions des utilisateurs. L’expérience client assure un usage simple de la plateforme ;
4) Traiter les transactions à l’échelle : l’objectif est de limiter au maximum les frictions lors des transactions et d’assurer la scalabilité rapide de la plateforme tout en assurant la sécurité.
1.3 Paiement Électronique et Plateforme de Paiement Électronique
1.3.1 Paiement électronique
a) Introduction
Le paiement est une opération qui consiste à fournir une contrepartie monétaire en échange d’un bien ou d’un service. Traditionnellement, cela se faisait au moyen de paiements physiques comme l’argent liquide ou les chèques. Cependant, avec l’avènement des technologies de l’information, de nouveaux moyens électroniques ont vu le jour, tels que les transferts électroniques de fonds ou encore la monétique [4].
b) Modèle de paiement électronique de détail [5]
En fin de compte, tous les systèmes de paiement de détail fournissent un canal de transaction entre les consommateurs et les commerçants en tant qu’utilisateurs finaux. Les cinq éléments clés définis dans le modèle sont :
1) L’utilisateur final, c’est-à-dire le consommateur et le commerçant. Le marché des paiements est un exemple classique du marché biface, où le fournisseur du paiement doit servir simultanément deux utilisateurs finaux ; le consommateur et le commerçant, et susciter leur intérêt.
2) Le canal de transaction : du point de vue du consommateur, l’achat d’un bien ou d’un service peut se faire à distance ou au point de vente. Nous appelons cette caractéristique, le « canal de la transaction », car elle décrit comment le consommateur et le commerçant interagissent.
3) Le dispositif de paiement : les dispositifs de paiement comprennent principalement les cartes, le Web et le service mobile. Les consommateurs doivent utiliser un dispositif manuel ou un compte connecté à un réseau de paiement pour effectuer un paiement électronique.
4) La technologie : les ordinateurs, les appareils mobiles et les cartes magnétiques peuvent être classés selon le type de technologie utilisé.
5) La modalité de paiement : du point de vue de l’entreprise, il y a deux types d’intermédiaires entre le commerçant et le consommateur. L’un est un exploitant, l’autre est une banque. Nous définissons cette dimension du modèle comme la modalité de paiement, qui décrit l’intermédiaire par lequel le consommateur paie le commerçant.
1.3.2 Passerelles de paiement électronique
Une passerelle de paiement est un service qui autorise les paiements par carte de crédit pour les entreprises en ligne et hors ligne. Pour les boutiques de commerce électronique, elle garantit également un flux de paiement sécurisé en chiffrant les informations financières du client avant de les transférer sur le compte du commerçant [6].
Voici quelques plateformes de passerelle de paiement électronique le plus célèbre avec une brève description et leurs caractéristiques principale :
a) PayPal
PayPal Website Payments Standard offre une solution immédiate pour accepter une large gamme de méthodes de paiement sur un site web, y compris toutes les principales cartes de crédit et de débit, les virements bancaires et les paiements PayPal. Les caractéristiques clés de Website Payments Standard sont [7] :
■ Facilité d’utilisation : Le processus de configuration de Website Payments Standard sur votre site web est simple et convivial.
■ Sécurité : Des systèmes de prévention de la fraude et de protection contre les rétrofacturations à la pointe de l’industrie sont en place pour assurer des transactions sécurisées.
■ Rentabilité : Il n’y a pas de frais d’installation, de frais mensuels ou de frais d’annulation. Les coûts des transactions sont compétitifs et bas, à partir de seulement 1,9 % + 0,30 $ par transaction.
b) Authorize.net
Authorize.net est la propriété du groupe CyberSource qui est désormais la propriété de Visa, Inc. Il s’agit d’une passerelle de paiement payante qui propose une formule avec une réduction des frais de transaction par rapport à ses concurrents. Cette passerelle de paiement propose d’accepter les paiements par carte de crédit et par chèque électronique. Les paiements sans contact sont également disponibles et l’entreprise propose une fonctionnalité avancée pour détecter les fraudes de manière optimale [8].
c) Stripe [9]
Stripe offre aux entreprises la possibilité de percevoir des paiements dans des magasins physiques ainsi qu’en ligne. Stripe Terminal permet de créer un système de point de vente entièrement personnalisé pour les transactions en présentiel. Stripe permet d’utiliser n’importe quel terminal de balayage de carte compatible avec le système Stripe. Mieux encore, Stripe vend des terminaux prêts à l’emploi, faciles à configurer et pouvant être gérés de manière centralisée.
Stripe permet aussi de créer un programme de fidélité ou des cartes-cadeaux, ces cartes étant virtuelles ou physiques.
d) MaxiCash [10]
La plate-forme d’intégration MaxiCash permet aux commerçants de s’intégrer à la plateforme MaxiCash afin de recevoir des paiements via leurs applications mobiles ou leurs sites Web. L’API utilise JSON pour interagir avec toute technologie de développement logiciel.
La passerelle MaxiCash permet de recevoir des paiements des utilisateurs MaxiCash et autres. La passerelle permet également de recevoir des paiements d’utilisateurs non MaxiCash utilisant des cartes de crédit, Mobile Money et autres.
Abb. in Leseprobe nicht enthalten
Figure 1 : Canaux de paiement pris en charge par la passerelle MaxiCash [10]
Comme cette parcelle présente plusieurs canaux de paiement, mais elle n’accepte pas une intégration pour une application en cours de développement, malheureusement. Nous allons concevoir notre plateforme TOYHE de manière à ce qu’elle soit capable de prendre MaxiCash en charge lors qu’on veut l’intégrer en production.
1.4 Les Web Services
Un web service est un ensemble de procédures déployées sur un serveur et utilisables à distance sur un poste client, pour sous-traiter la réalisation d’une opération. Les web service constituent l’élément clé des systèmes d’information des entreprises [11].
Dans ce document, nous allons présenter les web services REST et SOAP qui sont les deux principaux service web utilisés pour communiquer entre les applications.
1.4.1 Le web service REST
REST, initialement un acronyme pour REpresentational State Transfer, n’est pas un protocole ou un format, contrairement à SOAP ou HTTP (HyperText Transfert Protocole), mais un style d’architecture inspiré de l’architecture du web fortement basé sur le protocole HTTP. Il n’est pas dépendant uniquement du web et peut utiliser d’autre protocoles que HTTP [12].
a) Principe
Les principes clés de REST sont les suivant [13] :
❖ Ressources
Les interactions entre les composants du Web, à savoir les clients, les serveurs et les intermédiaires basés sur le réseau, reposent sur l’uniformité de leurs interfaces. Les données sont représentées comme des ressources accessibles par des URI (Uniform Resource Identifier). Chaque ressource a un identifiant unique et peut être manipulée via des requêtes HTTP standard (GET, POST, PUT, DELETE).
❖ Sans état (Stateless)
La contrainte sans état stipule qu’un serveur Web n’est pas tenu de conserver l’état des applications clientes. Par conséquent, il incombe à chaque client d’inclure toutes les informations contextuelles jugées pertinentes lors de chaque interaction avec le serveur Web. Les serveurs Web exigent des clients qu’ils prennent en charge la complexité de la communication de leur état d’application, permettant ainsi au serveur Web de servir un nombre beaucoup plus important de clients. Ce compromis est un facteur clé dans l’évolutivité du style architectural du Web.
❖ Interface Uniforme
Pour acquérir ces propriétés et bénéfices, un ensemble de contraintes a été intégré à REST afin de contribuer à la définition d’une interface de connecteur uniforme. Un ensemble limite d’opérations HTTP communes est utilisé pour interagir avec les ressources.
❖ Représentations multiples
Chaque ressource est tenue de supporter les opérations HTTP courantes, et REST autorise cette ressource à présenter différentes représentations, telles que texte, XML, JSON, etc. Le client REST peut requérir une représentation spécifique en utilisant le protocole HTTP (négociation de contenu).
b) Règles RESTful
Un service Web RESTful est un service conçu selon les principes REST, dont l’interface et le mécanisme d’accès sont conformes à ces principes. Les ressources sont identifiées par des URI. Un client possède suffisamment de métadonnées sur une ressource pour pouvoir la modifier ou la supprimer, à condition d’en avoir l’autorisation [14].
Verbes en REST : Les requêtes HTTP couramment utilisées dans RESTful incluent [14] :
■ GET : récupère la représentation d’une ressource du serveur vers le client.
■ POST : crée une ressource sur le serveur selon la représentation transmise par le client.
■ PUT : met à jour ou crée une référence à une ressource sur le serveur.
■ DELETE : supprime une ressource sur le serveur.
■ HEAD : recherche une ressource sans la récupérer.
c) Le protocole HTTP
■ Fonctionnement
Le protocole HTTP est un protocole de demande/réponse. Un client envoie une demande au serveur sous la forme d’une méthode de demande, d’un URI, et d’une version de protocole. Celle-ci est suivie par un message de style MIME (Multipurpose Internet Mail Extensions) contenant des modificateurs de demande, des informations de client, et éventuellement un contenu de corps sur une connexion avec un serveur. Le serveur répond par une ligne d’état, incluant la version de protocole du message et un code de succès ou d’erreur, suivi par un message de style MIME contenant des informations de serveur, des méta-informations d’entité, et éventuellement un contenu de corps d’entité [15].
■ Méthodes de requête client [16]
Une méthode de requête client est une commande ou une demande envoyée par un client Web à un serveur. Voici quelques généralisations :
■ La méthode GET est généralement utilisée pour récupérer une ressource du serveur, qui peut être le contenu d’un fichier statique ou le résultat de l’exécution d’un programme générant des données.
■ La méthode HEAD est employée pour obtenir des informations sur un document sans télécharger le document lui-même.
■ La méthode POST est utilisée pour soumettre des données fournies par l’utilisateur, souvent via des formulaires. Cela entraîne généralement une modification de l’état du serveur, comme la création d’un enregistrement dans une base de données.
■ PUT est utilisé pour envoyer un nouveau document ou remplacer un document existant sur le serveur.
■ DELETE permet de supprimer un document du serveur.
■ TRACE permet aux clients de découvrir le chemin emprunté par les requêtes à travers les proxys intermédiaires, facilitant ainsi le débogage du protocole.
■ OPTIONS indique au client les autres méthodes disponibles pour une ressource spécifique ou pour le serveur en général.
D’autres méthodes HTTP telles que LINK, CONNECT, UNLINK, et PATCH existent mais sont moins fréquemment utilisées et ont des définitions moins standardisées.
■ Le Code d’état [16]
La première ligne de la réponse d’un serveur HTTP contient la version du protocole HTTP utilisée, un code d’état numérique à trois chiffres et une phrase de statut explicative. Les codes d’état sont catégorisés de la manière suivante :
■ 100-199: Réponses informatives indiquant que la requête initiale a été reçue et est en cours de traitement.
■ 200-299: Réponses de succès signalant que l’action demandée par le client a été reçue, comprise et acceptée.
■ 300-399: Réponses de redirection indiquant que des actions supplémentaires doivent être prises pour compléter la requête.
■ 400-499: Erreurs client signifiant que la requête contient une syntaxe erronée ou ne peut être satisfaite.
■ 500-599: Erreurs serveur indiquant que le serveur a échoué à exécuter une requête apparemment valide.
La plupart des navigateurs web traitent automatiquement les codes des catégories 100, 200 et 300 sans intervention de l’utilisateur, certains codes d’erreur des catégories 400 et 500 sont habituellement présentés à l’utilisateur, comme le fameux “404 Not Found”.
d) Le format JSON
Le format de données JavaScript Object Notation, abrégé en JSON, est issu des littéraux de l’objet du langage de programmation JavaScript, ce qui en fait un sous-ensemble de ce dernier. Bien que dérivé d’un langage de programmation, JSON n’est pas lui-même un langage de programmation, mais plutôt un format d’échange de données [17].
Reconnu comme une norme pour l’échange de données, JSON est largement utilisé pour la transmission d’informations entre un navigateur et un serveur, ainsi qu’entre serveurs. Cependant, ces scénarios ne représentent pas les seules applications possibles de JSON ; limiter son utilisation à ces contextes serait réducteur. JSON est versatile et peut être employé dans diverses situations où l’échange de données est requis [17].
1.4.2 Le web service SOAP
SOAP, initialement un acronyme pour Simple Object Access Protocol, est un protocole de messagerie utilisé pour l’échange d’information structure dans le cadre des services web. Caractérisé par sa légèreté, est destiné à la transmission d’informations structurées au sein d’un environnement à la fois décentralisé et distribué. Il s’appuie sur les technologies XML (eXtensible Markup Language) afin de définir un cadre de messagerie modulable, lequel propose une structure de message échangeable à travers divers protocoles de base. Ce cadre est conçu pour maintenir son indépendance vis-à-vis de tout modèle de programmation spécifique ainsi que des sémantiques propres à chaque mise en œuvre [18].
a) Structure des messages SOAP
Un message SOAP est constitué d’une enveloppe qui englobe un en-tête facultatif ainsi qu’un corps obligatoire, tel qu’illustré par la figure 2. L’en-tête renferme des blocs d’informations qui sont essentiels pour déterminer la manière dont le message doit être traité. Tout élément pouvant être exprimé en syntaxe XML est susceptible de figurer dans le corps d’un message SOAP [19].
Abb. in Leseprobe nicht enthalten
Figure 2 : Structure des messages SOAP [20]
b) Langage de données de SOAP
Les types de données supportés par le style de codage SOAP correspondent aux types de données définis par la “Spécification XML des types de données de schéma”. Tous les types de données utilisés dans un bloc XML encodé SOAP doivent être soit directement issus de la spécification XML Schéma, soit dérivés de types préalablement établis par ladite spécification [19].
1.4.3 Comparaison entre REST et SOAP
Les architectures de services web utilisent fréquemment REST et SOAP pour échanger des données entre les applications clientes et les serveurs. Si les deux approches ont pour objectif de faciliter la communication entre les applications, elles sont différentes et ont des caractéristiques différentes.
Comme mentionné précédemment, REST est une architecture de service web qui utilise les ressources et les méthodes HTTP standard, tandis que SOAP est un protocole structuré qui établit un ensemble de règles pour l'invocation de procédures à distance entre des applications clientes et des serveurs.
En ce qui concerne la sécurité, les services REST utilisent les éléments de sécurité du protocole HTTP, tels que l'authentification et le cryptage (HTTPS). SOAP intègre des mécanismes de sécurité intrinsèques, tels que WS-Security, pour protéger les données et les communications.
II.5 Conclusion Partielle
Ce chapitre présente les concepts fondamentaux liés aux passerelles business, paiement électronique et passerelles de paiement électronique, ainsi qu’aux services web. Ces notions sont essentielles pour la réalisation de notre sujet, car il s’agit de développer une plateforme de réservation et de gestion du trafic lacustre qui communique avec un service web REST de passerelle de paiement électronique.
Le chapitre a commencé par définir les concepts fondamentaux des plateformes business, rôle d’une plateforme business. Il décrit ensuite les élément clés d’une plateforme business. Abordant ensuite le paiement électronique et les passerelles de paiement électronique, le chapitre définit aussi le modèle de paiement électronique de détail et fournit un aperçu des passerelles de paiements électronique. Enfin, le chapitre décrit les technologies de services web REST et SOAP, et conclut par une comparaison entre les deux approches.
Le chapitre suivant se concentrera sur l’analyse du système existant et la conception de la plateforme TOYHE, en utilisant des diagrammes de modélisation UML (Unified Modeling Language).
Chapitre II : ANALYSE DE L’EXISTANT ET CONCEPTION DE LA PLATEFORME TOYHE
11.1 Introduction Partielle
Dans ce chapitre, consacré à l'analyse et à la conception de notre système, nous présentons le système opérationnel utilisé par l'agence de transport Ets SILIMU, en identifiant les contraintes et en décrivant les fonctionnalités de notre solution visant à remédier à ces problèmes. Ce chapitre inclut également la création des différents diagrammes de modélisation UML.
11.2 Analyse De L’existant
11.2.1 Description du système existant
Procédure de gestion des opérations de l'agence de transport Ets SILIMU :
■ Commande des billets : l'agence de transport lacustre Ets SILIMU commande ses carnets de billets auprès d'un partenaire au Rwanda. Ces carnets sont ensuite distribués à chaque succursale.
■ Distribution des billets : après réception des carnets (50 billets par carnet), la comptabilité organise la distribution aux guichets.
■ Vente et inventaire : les guichets vendent les billets et, en fin de journée, un inventaire est réalisé pour comparer les billets restants à ceux distribués. L'argent collecté est déposé auprès de la caisse.
■ Rapport financier : la comptabilité collecte les fonds et élabore un rapport financier destiné au Directeur Général, détaillant la répartition des fonds collectés : pour des revenus journaliers supérieurs à 10 000 unités monétaires, 70 % sont déposés à la banque et 30 % restent en caisse pour couvrir les besoins opérationnels de l’agence, tandis que pour des revenus inférieurs à 5 000 unités, la répartition est équilibrée à 50 % pour le dépôt bancaire et 50 % pour la caisse.
Processus de vente de billets et d'enregistrement des marchandises à l'agence Ets SILIMU :
■ Vente des billets : les guichets vendent des billets aux clients en fonction des carnets disponibles. Le client présente une pièce d'identité (carte d'identité, carte d'électeur ou passeport) et choisit la classe souhaitée. Après paiement, le guichetier remplit le billet et le client se rend ensuite aux services de la Direction Générale de Migration (DGM) et de la Direction Générale des Recettes (DGR) pour obtenir un cachet et un timbre.
■ Enregistrement des marchandises : le convoyeur enregistre chaque marchandise qui entre dans le bateau sur une fiche d'inventaire et remet un bordereau d'expédition au propriétaire. À destination, le propriétaire présente ce bordereau pour recevoir un reçu confirmant l'arrivée de sa marchandise.
■ Contrôle à l'embarquement : avant d'embarquer, le client présente son billet aux contrôleurs de SILIMU, la DGR vérifie le timbre, et la DGM contrôle l'identité et le cachet. Le client entre ensuite dans le bateau et occupe une place disponible. Si toutes les places sont occupées, le client doit se tenir debout ou trouver une autre solution.
11.2.2 Problème du système existant
Le processus de gestion manuelle de l'agence Ets SILIMU présente plusieurs problèmes potentiels, parmi eux nous pouvons citer :
■ Risque d'erreurs humaines et de fraude : la gestion manuelle des billets et des marchandises augmente le risque d'erreurs de comptage, de distribution et de fraude, ce qui impacte la précision des rapports financiers et la sécurité.
■ Manque d'efficacité et lenteur : les procédures manuelles prennent du temps, de la commande des billets à leur distribution, jusqu'à la collecte d'argent et des cachets, ralentissant les opérations, notamment en cas de forte demande.
■ Risque de perte ou de vol : la manipulation d'argent liquide expose l'agence à des risques de vol, et l'absence d'un système automatisé complique la détection des irrégularités.
■ Difficulté de traçabilité et reporting : sans système numérique, il est difficile de suivre les ventes et les transactions, ce qui complique l'élaboration des rapports financiers fiables et l'analyse des données.
■ Dépendance à des partenaires externes : la commande de carnets auprès d'un partenaire au Rwanda expose l'agence à des retards potentiels dans l'approvisionnement.
Les processus de vente de billets et d'enregistrement des marchandises à l'agence Ets SILIMU présentent de même plusieurs problèmes potentiels :
■ Risque d'erreurs humaines et complexité : le remplissage manuel des billets et des bordereaux d'expédition peut provoquer des erreurs, rendant la gestion des passagers et des marchandises plus compliquée et sujette à confusion.
■ Absence de réservation en ligne : l'absence de système de réservation en ligne empêche les clients d'acheter leurs billets à distance, augmentant la pression sur les guichets physiques et entraînant des files d'attente.
■ Capacité limitée : le manque d'assignation des sièges à bord oblige certains clients à voyager debout, générant insatisfaction et frustration.
11.2.3 Améliorations proposées
Notre plateforme vise à répondre aux problèmes décrits précédemment et à améliorer les processus de gestions des Ets SILIMU en proposant les fonctionnalités suivantes :
— Réservation en ligne et gestion des sièges : intégrer un système de réservation en ligne permettra aux clients d'acheter des billets à distance et de choisir leurs sièges à l'avance, réduisant ainsi les files d'attente, la pression sur les guichets et les frustrations liées au manque de places.
— Suivi numérique des marchandises : mettre en place un module de suivi numérique pour l'enregistrement et le suivi des marchandises, minimisant les erreurs, pertes, et améliorant la transparence pour les propriétaires.
— Automatisation des rapports financiers : créer des rapports automatiques sur les ventes, billets, marchandises et flux financiers, facilitant la prise de décisions et renforçant la traçabilité tout en réduisant les erreurs humaines.
— Tableau de bord en temps réel : intégrer un tableau de bord pour suivre le trafic des bateaux, les places disponibles et les marchandises, permettant une gestion proactive et une meilleure réactivité.
11.3 Conception De La Plateforme TOYHE
Dans cette section, nous allons élaborer les diagrammes qui vont nous permettre de comprendre en profondeur les attentes du client et de définir avec précision les fonctionnalités de la plateforme que nous construirons par la suite.
11.3.1 Diagramme de cas d’utilisation
a) Présentation des acteurs
Nous débutons par identifier les principaux acteurs qui influencent les besoins de notre étude, car leur compréhension est essentielle pour concevoir des diagrammes précis et pertinents.
Il s’agit de :
■ Client potentiel : représente un visiteur, c'est-à-dire tout internaute qui accède à la plateforme pour consulter les informations qu'elle propose, effectuer une réservation ou utiliser les services destinés au grand public.
■ Client : est un utilisateur central qui effectue des réservations, gère ses trajets, effectue des paiements, et interagit avec l'agence pour un service fluide et personnalisé.
■ Administrateur : représente le gestionnaire principal de la plateforme, chargé de superviser les utilisateurs, de configurer les trajets, de gérer les réservations et d’assurer la sécurité des transactions et des données du système.
■ Un guichetier : représente un agent physique qui s’occupe de vendre les billets et gérer les modifications ou les annulations de réservations.
■ Directeur Général (DG) : est le leader stratégique de l'agence, responsable de la performance globale et de la satisfaction client. Il assure la cohérence des actions de tous les services et garantit la pérennité de l'entreprise.
■ Directeur Administratif et Financier (DAF) : représente le pilier financier et administratif de l’agence de transport dans toutes les opérations financières.
■ Directeur de Succursale de Goma (DSG) : permet d'assurer un suivi étroit des activités de l’agence à Goma et de soulager la charge de travail du DG au niveau administratif et opérationnel.
■ Chargé du Service Marketing (CSM) : met en place des stratégies pour attirer de nouveaux clients, fidéliser les anciens, et promouvoir les services de l’agence via des campagnes.
■ Chargé du Service d’Exploitation (CSE) : est le garant du bon déroulement des opérations quotidiennes de l’agence de transport dans la plateforme.
■ Chargé du Service du Personnel (CSP) : est le responsable de la gestion des plannings, et du suivi des performances du personnel.
■ La Passerelle de Paiement API : c’est un service externe qui permet de faire le paiement électronique dans la plateforme.
■ Le Mail API : permet d’envoyer de mail pour la notification.
■ Le SMS API : c’est un système externe qui permet d’envoyer les SMS pour la notification.
b) Présentation des diagrammes de cas d’utilisation
Les acteurs directs sont représentés à gauche sous forme de bonhomme, leurs fonctions étant détaillées dans des ellipses. Les liens entre acteurs et fonctions sont symbolisés par des lignes continues. Les relations de généralisation entre acteurs sont indiquées par des flèches orientées du plus spécifique vers le plus général.
❖ Diagramme de cas d’utilisation d’un client potentiel et d’un client
La figure 3 représente les besoins fonctionnels d’un client potentiel et d’un client :
Abb. in Leseprobe nicht enthalten
Figure 3 : Diagramme de cas d’utilisation d’un client potentiel et d’un client
Il est indiqué que tout utilisateur se connectant au système en tant que client potentiel peut effectuer les actions suivantes : créer un compte utilisateur, réserver un billet, consulter les informations de la plateforme et découvrir les services qu'elle propose. Cependant, un utilisateur authentifié en tant que client bénéficie de droits supplémentaires, lui permettant d'accéder à des fonctionnalités telles que : consulter les informations de l'agence de transport, visualiser l'historique de ses voyages et contacter l'agence.
Il est important de noter que certaines fonctionnalités dépendent d'autres, d'où la présence des relations « include » entre certains cas d'utilisation. Par exemple, la fonctionnalité changer les identifiants implique que l'utilisateur doit d'abord s'authentifier dans le système. De plus, un utilisateur avec le rôle de client hérite des fonctionnalités d'un client potentiel, ce qui est indiqué par la flèche reliant le générique au spécifique.
Enfin, des acteurs secondaires comme la Passerelle de Paiement API, la Mail API, et la SMS API permettent de gérer les paiements en ligne, ainsi que l'envoi de mails et de SMS lors d'actions telles que la réservation de billets ou la création d'un compte.
❖ Diagramme de cas d’utilisation d’un administrateur et un guichetier
Le guichetier peut imprimer et personnaliser des billets, consulter l'évolution de ses opérations et les archives, changer son mot de passe, réserver des billets et contacter un agent. Toutes ses actions nécessitent une authentification.
L'administrateur, avec plus de privilèges, peut ajouter des bateaux, suivre l'évolution de l'agence et gérer les utilisateurs (ajouter, supprimer, modifier). Ces actions exigent également une authentification.
Les API externes (Mail et SMS) permettent d'envoyer des notifications lors d'actions spécifiques, comme la gestion des utilisateurs ou la réservation de billets.
La figure 4 illustre les besoins fonctionnels d’un administrateur et d’un guichetier :
Abb. in Leseprobe nicht enthalten
Figure 4 : Diagramme de cas d’utilisation d’un administrateur et d’un guichetier
❖ Diagramme de cas d’utilisation d’un CSM et un CSP
Le CSM (Chargé du Service Marketing) est responsable de la gestion des campagnes marketing et du suivi de l'engagement client, avec des tâches comme la gestion des prix des billets et la consultation des tendances du marché. Ces actions nécessitent une authentification.
Le CSP (Chargé du Service du Personnel) se charge des relations avec les clients, de la logistique des bagages et des colis, incluant la gestion des bagagistes et la réservation de billets. Il peut ajouter, supprimer ou modifier des bagagistes.
Les API Mail et SMS envoient des notifications aux utilisateurs lors d'actions telles que la réservation ou la gestion des bagagistes.
La figure 5 présente les besoins fonctionnels d’un CSM et d’un CSP :
Abb. in Leseprobe nicht enthalten
Figure 5 : Diagramme de cas d’utilisation d’un CSM et d’un CSP
❖ Diagramme de cas d’utilisation d’un DG et un CSE
Le DG (Directeur Général) supervise les opérations de l'agence, gère les réservations et les ventes, optimise les opérations, prend des décisions stratégiques et génère des rapports. Chaque action nécessite une authentification.
Le CSE (Chargé du Service d'Exploitation) s'occupe de la gestion du département technique, de la planification des horaires des bateaux, de l'information sur les mouvements des bateaux, et des demandes de déblocages de fonds. La gestion du département technique comprend l'optimisation des ressources et la gestion des fonds.
Les API externes, comme la Mail API, facilitent les notifications pour les actions de gestion et de planification.
La figure 6 met en évidence les besoins fonctionnels d’un DG et d’un CSE :
Abb. in Leseprobe nicht enthalten
Figure 6 : Diagramme de cas d’utilisation d’un DG et d’un CSE
❖ Diagramme de cas d’utilisation d’un DAF
Le DAF (Directeur Administratif et Financier) est responsable de la gestion financière et administrative de l'agence, incluant la trésorerie, la comptabilité, les factures, et l'optimisation des finances. Il suit les coûts de maintenance, gère les paiements, surveille les revenus, analyse les tendances de vente, et évalue les performances financières. Chaque action financière repose sur le cas d'utilisation « SuivreEtGérerRevenus ».
Il peut aussi changer son mot de passe, réserver des billets, et contacter un agent, avec authentification préalable. La Mail API facilite l'envoi de notifications lors des réservations et de la communication avec un agent.
La figure 7 illustre les besoins fonctionnels d’un DAF :
Abb. in Leseprobe nicht enthalten
Figure 7 : Diagramme de cas d’utilisation d’un DAF
c) Documentation de quelques cas d’utilisation
La documentation de cas d'utilisation décrit les interactions entre un acteur et notre système pour atteindre un objectif spécifique. Elle détaille ainsi les étapes, les conditions et les résultats attendus de chaque interaction, servant à clarifier les exigences fonctionnelles de notre plateforme TOYHE.
❖ Cas d’utilisation « CréerCompte »
Tout client potentiel et client peut créer un compte dans le système afin d'avoir accès aux fonctionnalités offertes au grand public par le système.
Tableau 1 : Documentation du cas d’utilisation « CréerCompte »
Abb. in Leseprobe nicht enthalten
❖ Cas d’utilisation « SAuthentifier »
Tout utilisateur, à l'exception des clients potentiels, doit s'authentifier pour accéder à son espace privé.
Tableau 2 : documentation du cas d’utilisation « SAuthentifier »
Abb. in Leseprobe nicht enthalten
❖ Cas d’utilisation « RéserverBillet »
Tout utilisateur, à l'exception des clients potentiels, peut réserver un billet pour un trajet sur une des embarcations de l'agence Ets SILIMU.
Tableau 3 : Documentation du cas d’utilisation « RéserverBillet »
Abb. in Leseprobe nicht enthalten
❖ Cas d’utilisation « AjouterUtilisateur »
L’administrateur ajoute un nouvel utilisateur sur la plateforme pour accéder aux fonctionnalités de réservation et de gestion du trafic.
Tableau 4 : Documentation du cas d’utilisation « AjouterUtilisateur »
Abb. in Leseprobe nicht enthalten
❖ Cas d’utilisation « ImprimerBilletOuFicheDInventaire »
L’utilisateur imprime un billet de réservation ou une fiche d'inventaire pour une marchandise d’un client entrant sur le bateau.
Tableau 5 : Documentation du cas d’utilisation « ImprimerBilletOuFicheDInventaire »
Abb. in Leseprobe nicht enthalten
11.3.2 Diagramme de séquence
Le diagramme de séquence nous sert à représenter les interactions entre les objets d'un système au fil du temps. Il montre comment les messages sont échangés entre les différents composants pour réaliser une fonctionnalité spécifique, en mettant en évidence l'ordre et la chronologie des opérations. Cela permet de comprendre les flux de contrôle et de données, facilitant ainsi la conception et l'analyse des comportements du système.
a) Diagramme de séquence pour le cas d’utilisation « SAuthentifier »
L'acteur sera invité à remplir un formulaire d'authentification. Si toutes les conditions requises sont remplies, la plateforme le redirigera automatiquement vers la page d'accueil.
La figure 8 illustre le déroulement temporel des actions entre les acteurs ou objets et la
plateforme pour le cas d’utilisation « SAuthentifier » :
Abb. in Leseprobe nicht enthalten
Figure 8 : Diagramme de séquence du cas d’utilisation « SAuthentifier »
b) Diagramme de séquence du cas d’utilisation « RéserverBillet »
Une fois authentifié, l’acteur aura la possibilité de remplir le formulaire de réservation de billet. Si toutes les conditions sont remplies, la plateforme effectuera la réservation du billet de voyage.
La figure 9 illustre le déroulement temporel des actions entre les utilisateurs, les objets et la plateforme pour le cas d’utilisation « RéserverBillet » :
Abb. in Leseprobe nicht enthalten
Figure 9 : Diagramme de séquence du cas d’utilisation « RéserverBillet »
11.3.3 Diagramme de classes
Dans cette section, nous allons élaborer le diagramme de classes, un outil essentiel pour structurer la conception de notre plateforme de réservation et de gestion du trafic. Ce schéma nous permettra de définir avec précision les composants clés, leurs attributs, et leurs relations, afin de garantir une architecture solide et de répondre aux exigences fonctionnelles de manière cohérente.
La figure 10 illustre le diagramme de classes de notre plateforme TOYHE :
Abb. in Leseprobe nicht enthalten
11.3.4 Diagramme de déploiement
La figure 11 illustre l'architecture physique de notre plateforme en montrant comment les différents composants logiciels sont distribués sur l'infrastructure matérielle :
Abb. in Leseprobe nicht enthalten
Figure 11 : Diagramme de déploiement
II.5 Conclusion Partielle
Dans ce chapitre, nous avons examiné les aspects analytiques et conceptuels de notre plateforme. Lors de la phase d'analyse, nous avons étudié le système manuel actuel des Ets SILIMU, identifié ses limites et défini les fonctionnalités nécessaires à son amélioration. Nous avons également identifié les acteurs de notre plateforme et présenté les différents diagrammes de cas d'utilisation.
Au cours de la phase de conception, nous avons élaboré les diagrammes de séquence, de classes et de déploiement. Ces diagrammes nous ont permis de visualiser les interactions et la structure du système, facilitant ainsi la compréhension des fonctionnalités à implémenter.
La prochaine étape consistera à l'implémentation de notre plateforme, où nous présenterons les outils et technologies utilisés ainsi que quelques interfaces clés de celle-ci.
Chapitre III : Implémentation de la plateforme TOYHE
111.1 Introduction Partielle
Dans ce chapitre, nous détaillons la mise en œuvre technique de TOYHE, la plateforme intégrée de réservation et de gestion du trafic lacustre pour les Ets SILIMU, en mettant l’accent sur la présentation des interfaces développées et leur rôle dans l’amélioration de l’expérience utilisateur ainsi que la gestion des opérations de l’agence. Nous commencerons par une présentation des technologies utilisées, en soulignant leur contribution à la conception et au bon fonctionnement du système. Ensuite, nous introduirons les interfaces clés de la plateforme, en expliquant leur utilité et leur impact sur la gestion des réservations, des paiements et du suivi des passagers et marchandises.
111.2 Présentation Des Technologies Utilisées
Le développement de la plateforme TOYHE repose sur une combinaison de technologies modernes garantissant robustesse, performance et sécurité. Celles-ci couvrent les domaines du développement web et mobile, du stockage des données, de la communication et de l’intégration des paiements en ligne. L’adoption d’une stratégie MVP a permis une conception itérative et évolutive, facilitant l’amélioration continue du système. De plus, l’intégration des techniques ACC (Automatic Content Change) et OCD (Over-the-Air Content Delivery) assure des mises à jour dynamiques et une gestion efficace du contenu, permettant ainsi d’adapter la plateforme en fonction des besoins sans interruption de service.
111.2.1 Langages de programmation et architecture évolutive
Le développement de TOYHE repose sur trois langages principaux, choisis pour leur flexibilité et leur compatibilité avec une architecture évolutive :
■ Java : utilisé pour l’implémentation du backend avec Spring Boot, Java assure la stabilité et la scalabilité des services web [21].
■ JavaScript : utilisé pour le développement du frontend avec React, permettant une expérience utilisateur fluide et réactive [22].
■ Dart : utilisé pour le développement de l’application mobile avec Flutter, facilitant le déploiement rapide des mises à jour grâce à son architecture modulaire [23].
Grâce aux principes de MVP, l’application peut être améliorée progressivement en intégrant de nouvelles fonctionnalités sans refonte majeure. L’utilisation des techniques ACC et OCD permet de mettre à jour dynamiquement le contenu et de déployer des correctifs ou nouvelles fonctionnalités à distance, sans nécessiter une intervention manuelle des utilisateurs.
111.2.2 Développement frontend
L’interface utilisateur a été développée avec React, une bibliothèque JavaScript permettant de concevoir des interfaces modulaires et dynamiques [24]. Pour assurer une mise en page moderne et flexible, nous avons utilisé Tailwind CSS, un framework CSS utilitaire facilitant un design réactif et personnalisable [25]. En complément, Material UI, basé sur Material Design, garantit une ergonomie intuitive [26].
L’architecture frontend a été pensée pour supporter les changements dynamiques de contenu via ACC, permettant ainsi d’adapter l’interface aux évolutions du système sans nécessiter de redéploiement complet.
111.2.3 Développement mobile
L’application mobile destinée au Guichetier a été développée avec Flutter, qui permet un déploiement rapide et assure une compatibilité multiplateforme (Android et iOS) [27]. Grâce au Hot Reload de Flutter, les mises à jour peuvent être intégrées et testées en temps réel, ce qui est essentiel dans une approche MVP.
L’intégration de OCD permet de pousser des mises à jour de contenu sans nécessiter une mise à jour complète de l’application via les stores. Cela garantit aux utilisateurs un accès immédiat aux nouvelles fonctionnalités ou corrections sans interruption de service.
111.2.4 Développement backend et conteneurisation
Le backend repose sur Spring Boot, qui assure une architecture modulaire et évolutive, facilitant l’intégration future de nouveaux services [28]. Pour garantir une portabilité et une scalabilité optimales, le backend a été conteneurisé avec Docker, permettant une gestion efficace des déploiements et une isolation des services [29].
Grâce à ACC, les services backend peuvent être mis à jour dynamiquement, permettant d’introduire des améliorations et correctifs sans interruption du service.
L’envoi d’e-mails transactionnels est assuré par le module spring-boot-starter-mail, qui utilise JavaMailSender pour expédier les e-mails via un serveur SMTP [30]. Ce mécanisme permet d’automatiser l’envoi de notifications aux utilisateurs en s’appuyant sur un serveur de messagerie configuré.
111.2.5 Gestion des données
Les données sont stockées dans PostgreSQL, un système robuste garantissant une gestion avancée des transactions et une haute disponibilité [31]. Pour le stockage des fichiers (photos, vidéos, documents utilisateur), FireBase Storage a été intégré, offrant une solution scalable et sécurisée via Google Cloud [32].
L’utilisation des techniques ACC et OCD facilite la mise à jour en temps réel des données et des fichiers utilisateurs, garantissant un accès immédiat aux dernières versions des documents stockés.
111.2.6 Visualisation des données
L’affichage des statistiques et tendances des réservations est assuré par D3.js, une bibliothèque JavaScript permettant de générer des visualisations dynamiques [33]. Son intégration avec le backend via ACC permet de mettre à jour les données analytiques sans nécessiter un rafraîchissement manuel de la page.
111.2.7 Services de paiement et communication
L’API MaxiCash est utilisée pour l’intégration des paiements électroniques, assurant une sécurisation et une automatisation des transactions [10].
L’intégration d’une API d’envoi de SMS, telle que Twilio, permet de notifier les clients en temps réel sur l’état de leurs réservations et paiements. Twilio est une plateforme de communication cloud que nous avons utilisée, offrant des services d’envoi de messages, d’appels vocaux et de notifications via API, facilitant ainsi l’automatisation des interactions avec les utilisateurs [34].
Grâce à OCD, les messages transactionnels peuvent être mis à jour et adaptés dynamiquement en fonction des changements apportés à la plateforme, garantissant ainsi une communication toujours à jour.
111.3 Présentation De La Plateforme
Cette section est dédiée à la présentation des interfaces clés de la plateforme TOYHE, développée pour la réservation et la gestion du trafic lacustre de l'agence Ets SILIMU. Chaque interface a été conçue pour répondre à des besoins spécifiques, facilitant ainsi l'interaction des utilisateurs avec le système. Nous détaillerons ici les principales interfaces, en expliquant leur rôle et leur utilité pour les différents acteurs de la plateforme, qu'il s'agisse des guichetiers, des clients ou des gestionnaires de l'agence. Grâce à une navigation intuitive et un design fonctionnel, ces interfaces permettent une gestion optimale des réservations et du suivi du trafic.
111.3.1 Interfaces communes à tous les utilisateurs
Ces interfaces sont accessibles à tous les utilisateurs, à l'exception des clients potentiels. Cependant, le contenu et les fonctionnalités varient en fonction du rôle de chaque utilisateur.
La figure 12 représente l'interface de connexion à la plateforme TOYHE. L'utilisateur saisit ses informations d'authentification pour accéder à la plateforme. Le système vérifie alors si les informations saisies sont correctes et correspondent à un utilisateur existant. En cas de succès, l'utilisateur est redirigé vers sa page d'accueil.
Abb. in Leseprobe nicht enthalten
Figure 13 : Interfaces principales de l'onglet d'accueil de la plateforme TOYHE
La figure 13 illustre l'interface d'accueil de la plateforme TOYHE, où l'utilisateur peut consulter les différentes informations publiées par l'agence de transport, telles que les actualités, les mises à jour et autres annonces, ainsi que télécharger les fichiers mis à disposition. Seuls les utilisateurs ayant le rôle de Chargé de marketing ou Administrateur sont autorisés à publier de nouvelles informations et à consulter les commentaires associés à chaque publication. Les autres utilisateurs, quant à eux, peuvent uniquement visualiser les publications existantes, les aimer, les partager et ajouter leurs propres commentaires.
La figure 14 représente l'interface de réservation d'un billet de voyage sur la plateforme TOYHE. Cette interface s'adapte en fonction du type d'utilisateur. Un agent de l'agence de transport peut réserver un billet pour lui-même, sans procéder à un paiement. Un partenaire de l'agence peut réserver un ou plusieurs billets sans effectuer de paiement. Quant à un client, il peut réserver un ou plusieurs billets et procéder au paiement. La plateforme lui offre alors une interface permettant de finaliser le paiement en choisissant le canal de paiement de son choix. Toutefois, cette version utilise une passerelle de paiement MaxiCash en mode essai, empêchant la réception des paiements. La logique mise en place reste pleinement adaptable à la production. MaxiCash ne fournit pas sa passerelle aux systèmes en développement et requiert un accord préalable pour son intégration officielle.
Abb. in Leseprobe nicht enthalten
Figure 15 : Interface d'envoi de messages sur la plateforme TOYHE
La figure 15 montre l'interface de messagerie de la plateforme TOYHE. Cette interface s’adapte en fonction du type d’utilisateur. Les agents de l’agence de transport peuvent uniquement échanger entre eux, à l’exception du Chargé du service marketing et du personnel administratif, qui ont la possibilité de communiquer avec les clients selon les besoins. Le Chargé du service marketing peut répondre aux demandes d’information sur l’agence, tandis que le personnel administratif traite les réclamations liées à un service insatisfaisant ou les plaintes concernant la perte d’un colis. Pour les clients, la messagerie est principalement utilisée pour recevoir des notifications sur la confirmation de leur réservation. Ils peuvent également envoyer des messages pour obtenir des renseignements ou des clarifications sur les servrces de l’agence.
Sur la figure 16, on retrouve l'interface dédiée à l'affichage des horaires de voyage de l'agence de transport Ets SILIMU. Tous les utilisateurs peuvent consulter ces horaires. Toutefois, seuls F Administrateur et le Chargé du service d’exploitation ont la possibilité de les modifier.
Abb. in Leseprobe nicht enthalten
Figure 16 : Interface affichant les horaires de voyage de l’agence sur la plateforme TOYHE
La figure 17 représente l'interface permettant de consulter l'état des bateaux, la disponibilité des places et la capacité de charge. Tous les utilisateurs peuvent voir ces informations, mais seul l'administrateur est habilité à les modifier.
Abb. in Leseprobe nicht enthalten
Figure 17 : Interface d'affichage de l'état des bateaux, de la disponibilité des places et de la capacité de charge sur la plateforme TOYHE
IIL3.2 Interfaces communes à certains groupes d’utilisateurs
a) Interfaces partagées entre l’Administrateur, le DG, le DSG et le DAF
La figure 18 présente l'interface des commandes, qui permet à l'utilisateur de consulter les différentes commandes effectuées par les agents, partenaires, clients et administrateurs de l'agence de transport. L'interface offre la possibilité d'appliquer plusieurs filtres afin de personnaliser l'affichage des données en fonction des critères sélectionnés. De plus, l'utilisateur- peut télécharger un fichier au format PDF ou Excel, contenant la liste complète des commandes effectuées pendant une période définie par les filtres appliqués.
Abb. in Leseprobe nicht enthalten
Figure 18 : Historique des commandes effectuées par réservation et vente de billets, réalisées par les agents, partenaires, clients et administrateurs de l'agence de transport
La figure 19 montre l'interface de suivi des ventes des guichetiers. Cette interface permet de visualiser l'évolution des ventes réalisées par les guichetiers ainsi que les revenus générés au cours d'une période donnée. L'utilisateur peut consulter des données détaillées, suivre les performances des ventes en temps réel et téléchar ger un fichier PDF ou Excel contenant la liste complète des ventes effectuées durant la période sélectionnée.
Abb. in Leseprobe nicht enthalten
Figure 19 : Interface de suivi des ventes des guichetiers, affichant l'évolution des ventes et
Sur la figure 20, on retrouve l'interface de suivi des performances de l'agence de transport, permettant de visualiser les réservations, les ventes de billets et les revenus générés sur une période donnée. L'utilisateur peut sélectionner la période et le bateau pour consulter ses performances. L'interface affiche d'abord le nombre de places occupées et les recettes générées par ces ventes. Un graphique compare ensuite les places occupées pour chaque classe de bateau par rapport au nombre total de places disponibles. Elle permet aussi de voir le nombre total de réservations en ligne et de ventes physiques, en comparant le pourcentage de ces commandes par rapport au total. Les recettes générées par les deux types de commandes (en ligne et physiques) sont également indiquées. L'interface montre les dépenses liées aux commandes effectuées par les agents et partenaires, ainsi que les dépenses totales de l'agence pendant la période. Enfin, deux graphiques illustrent l'évolution des commandes en ligne par rapport à celles effectuées par les guichetiers, et l'évolution des commandes par les partenaires par rapport à celles effectuées par les agents de l'agence.
Abb. in Leseprobe nicht enthalten
Figure 20 : Interface de suivi des performances de l’agence de transport, montrant les réservations, les ventes de billets et les revenus générés sur une période donnée
b) Interface partagée entre l’administrateur et le CSP
Abb. in Leseprobe nicht enthalten
Figure 21 : Interface de gestion des utilisateurs de la plateforme TOYHE
La figure 21 présente l'interface de gestion des utilisateurs de la plateforme. Cette interface permet à l'administrateur d'ajouter de nouveaux utilisateurs, de modifier les informations des utilisateurs existants ou de supprimer un utilisateur de la plateforme. Elle permet également d'enregistrer de nouveaux bagagistes pour l'agence de transport, facilitant ainsi le suivi des cas de perte de colis ou d'incidents impliquant les bagagistes. Les informations affichées sur l'interface sont adaptées en fonction des filtres de données choisis par l'utilisateur.
c) Interfaces partagées entre les agents de l'agence de transport
La figure 22 représente l'interface de demande de fonds par' les agents de l'agence auprès du DAF. L'affichage de l'interface varie en fonction du rôle de l'utilisateur. Le DAF peut consulter toutes les demandes de fonds effectuées par les agents, avec la possibilité exclusive d'approuver ou de rejeter chaque demande. Le DG peut uniquement von les demandes soumises sans pouvoir les modifier. De leur côté, les agents peuvent suivre l'état de leurs demandes, consulter leur historique et soumettre une nouvelle demande en précisant la catégorie, le montant souhaité et, si nécessaire, enjoignant un fichier justificatif.
Abb. in Leseprobe nicht enthalten
Figure 22 : Interface de demande de fonds par les agents de l'agence auprès du DAF
La figure 23 présente l'interface d'envoi de rapports au DG et de visualisation des rapports par les agents de l'agence de transport. Les agents peuvent soumettre un rapport en renseignant un titre, une description et en joignant un fichier. Le DG, quant à lui, a accès à tous les rapports envoyés et est le seul à pouvoir les approuver, les désapprouver ou prendre une décision en conséquence.
Abb. in Leseprobe nicht enthalten
Figure 23 : Interface d'envoi de rapports au DG et de visualisation des rapports par les agents de l'agence de transport
d) Interfaces partagées entre le client et le partenaire
La figure 24 montre l'interface d’envoi de réclamation par le client ou le partenaire. L'utilisateur choisit la catégorie, décrit la réclamation, joint un fichier si nécessaire, et renseigne ses informations personnelles (nom, e-mail, téléphone).
Abb. in Leseprobe nicht enthalten
Figure 24 : Interface d’envoi de réclamation par le client ou le partenaire de l’agence
III.3.3 Interfaces spécifiques à chaque utilisateur
a) Client
La figure 25 représente l'interface de création de compte sur la plateforme TOYHE. L'utilisateur commence par sélectionner le type de compte souhaité : personnel ou entreprise. Pour un compte personnel, il doit renseigner son prénom, nom, numéro de téléphone, adresse e-mail, et définir un mot de passe, qu'il devra saisir deux fois pour confirmation. Pour un compte entreprise, les champs requis sont le nom de l'entreprise, l'année de création, le numéro de téléphone de l'entreprise, ainsi qu'un mot de passe, également saisi deux fois.
Abb. in Leseprobe nicht enthalten
Figure 25 : Interfaces de création de compte sur la plateforme TOYHE
b) Chargé du service marketing
Sur la figure 26, on retrouve l'interface d’envoi de campagne publicitaire par le Chargé de marketing. L'utilisateur sélectionne l'événement, définit le titre et la description de la campagne, précise la cible visée, choisit le canal de communication (email ou SMS) et indique l'offre spéciale associée à la campagne. En cas de campagne par email, l'utilisateur a également la possibilité de joindre un fichier à l'envoi.
Abb. in Leseprobe nicht enthalten
Figure 26 : Interface d’envoi de campagne publicitaire par le Chargé de marketing
c) Guichetier
Le guichetier utilise une application mobile qui fonctionne dans un système de point de vente (POS) pour gérer les ventes et les réservations de l'agence de transport. Ce système POS centralise à la fois les ventes effectuées en présentiel par le guichetier et les réservations en ligne réalisées par les clients, agents et partenaires de l'agence. Cela permet de contrôler et de limiter le nombre de passagers pouvant embarquer à bord d'un bateau, assurant ainsi une gestion optimale de la capacité des navires.
Le système POS permet également d'enregistrer les fiches d'inventaire des marchandises des clients de l'agence. Lorsqu'un guichetier enregistre une marchandise, le système vérifie la
capacité restante d'un bateau en termes de poids, garantissant qu'aucune surcharge n'ait lieu et qu'il reste de la place pour d'autres colis.
Une fois l’achat du billet ou l'enregistrement de marchandises effectué, le système génère un fichier PDF qui est envoyé à une imprimante thermique connectée au POS. Ce fichier peut être un billet de transport pour un client ou une fiche d'inventaire pour un colis enregistré, qui sera ensuite imprimé pour remise au client. Cette fonctionnalité assure la fluidité du processus, tout en offrant une trace papier des transactions effectuées.
Abb. in Leseprobe nicht enthalten
Figure 27 : Exemple de système de point de vente [35]
La figure 27 présente un système de point de vente (POS), utilisé pour centraliser les transactions et gérer les ventes dans divers environnements commerciaux. Dans le cas de l'agence de transport, la plateforme TOYHE peut être intégrée directement dans le POS, permettant aux guichetiers de gérer efficacement les réservations et les ventes en présentiel. Toutefois, il est important de noter que la majorité des systèmes POS sont privés et propriétaires. Cela signifie que chaque entreprise utilise un système POS personnalisé, où seule l'application spécifique à l'entreprise peut être installée. Cela limite la possibilité d'ajouter d'autres applications tierces, garantissant ainsi une meilleure sécurité et une gestion des transactions plus cohérente et simplifiée.
Abb. in Leseprobe nicht enthalten
Figure 28 : Interfaces clés pour le guichetier sur la plateforme TOYHE
Sur la figure 28, on retrouve les principales interfaces utilisées par le guichetier sur la plateforme TOYHE pour enregistrer les billets et les fiches d'inventaire des clients qui viennent en personne. Le guichetier enregistre manuellement les ventes en recevant uniquement de l'argent liquide, et imprime les billets ou fiches d'inventaire correspondants. Ces interfaces permettent de centraliser et de suivre les transactions en temps réel, assurant une gestion fluide des réservations et des marchandises dans l'agence de transport.
III.4 Conclusion Partielle
Le chapitre a commencé par une présentation détaillée des technologies utilisées pour l’implémentation de la plateforme TOYHE, développée pour la réservation et la gestion du trafic lacustre de l’agence de transport Ets SILIMU. Cette section a mis en avant les choix techniques stratégiques adoptés pour garantir- la robustesse, la performance et l’évolutivité de la plateforme. Ensuite, nous avons exploré les interfaces clés de la plateforme, en soulignant leur conception intuitive et leur capacité à faciliter la gestion efficace des réservations et du trafic lacustre.
En conclusion partielle, l’intégration des technologies modernes telles que Java, JavaScript, Flutter et PostgreSQL, associée aux techniques ACC et OCD, confère à TOYHE une grande flexibilité et évolutivité. Grâce à ces choix technologiques, la plateforme peut évoluer de manière progressive, intégrer de nouvelles fonctionnalités et effectuer des mises à jour sans interrompre le service. Cette architecture garantit ainsi une gestion dynamique du contenu et des interactions, assurant une expérience fluide pour les utilisateurs tout en optimisant la gestion du trafic et des réservations de l’agence Ets SILIMU.
Conclusion générale
Ce mémoire a permis de développer une plateforme intégrée visant à assurer une gestion proactive du trafic lacustre, avec un système de réservation de billets en ligne et l’intégration de services de paiement électronique pour l’agence de transport Ets SILIMU. La solution mise en place optimise la gestion des flux de passagers et des transactions financières, tout en réduisant les files d’attente et en améliorant la relation client. Grâce à une approche MVP, la plateforme a été conçue de manière itérative, permettant une validation rapide des fonctionnalités essentielles et une amélioration continue en fonction des retours des utilisateurs. La centralisation et la transmission en temps réel des informations offrent à l’agence un meilleur suivi de ses opérations et une optimisation des ressources.
Les hypothèses formulées au début de cette étude ont été vérifiées au cours du développement et de l’évaluation de la plateforme. D’abord, la mise en place d’une plateforme axée sur l’efficacité, la sécurité et la réduction de la congestion s’est révélée être une approche pertinente pour améliorer la gestion du transport lacustre. Ensuite, la centralisation et la transmission en temps réel des informations ont permis une exploitation plus efficace des données et une meilleure coordination des opérations. L’adoption d’une approche MVP a facilité la validation rapide du concept et l’adaptation aux besoins des utilisateurs. Enfin, l’intégration d’un service Web de passerelle de paiement prenant en charge divers services de paiement électronique s’est avérée être une fonctionnalité essentielle pour faciliter l’accès aux réservations et améliorer l’expérience utilisateur.
Bien que cette plateforme réponde aux besoins identifiés, certaines limites subsistent. Elle repose sur une connexion Internet permanente, ce qui peut poser des défis dans certaines zones à faible couverture réseau. De plus, son adaptabilité à d’autres agences de transport nécessiterait des ajustements spécifiques pour répondre aux particularités de chaque structure. La gestion des marchandises, bien que fonctionnelle, pourrait être améliorée avec un système de suivi plus automatisé et précis.
L’extension de cette plateforme pourrait inclure le développement d’une version hors ligne, permettant d’effectuer certaines opérations sans connexion Internet. Une adaptation plus flexible rendrait possible son utilisation par d’autres agences de transport. L’intégration de capteurs intelligents sur les bateaux permettrait de mesurer en temps réel le poids total embarqué et d’envoyer des alertes en cas de surcharge. L’intelligence artificielle pourrait être exploitée pour analyser les tendances des réservations, optimiser les ressources et ajuster dynamiquement les horaires. Enfin, un système de reconnaissance faciale améliorerait la sécurité en vérifiant l’identité des passagers.
Ce travail ouvre ainsi la voie à une digitalisation avancée du transport lacustre, offrant des perspectives d’amélioration continue pour répondre aux défis technologiques et opérationnels du secteur.
Annexe A Guide D’entretien
Nous sommes AMURI TCHALUMBA Héritier, étudiant de la troisième année de licence (système LMD) en science et technologies appliquées, département de génie électrique et informatique, spécialité de génie informatique ; inscrit à l’Université Libre des Pays des Grands Lacs (ULPGL/Goma). Cependant, nous sommes en train de mener notre recherche de fin du premier cycle universitaire portant sur un sujet intitulé « Développement d'une Plateforme Intégrée pour la Réservation et la Gestion du Trafic sur le Lac Kivu : cas des établissement SILIMU ». C’est dans ce cadre que nous vous soumettons ce guide d’entretien pour que vous contribuiez à sa réalisation. Néanmoins, nous vous promettons la confidentialité des informations qui nous seront fournies.
Description du sujet : nous voulons créer une plateforme révolutionnaire qui va au-delà de la simple réservation, introduisant des fonctionnalités avancées pour une gestion proactive du trafic lacustre, tout en promettant d'optimiser l'utilisation des ressources, d'améliorer l'expérience des utilisateurs et fournissant les informations aux voyageurs.
Q.1 Quel est le nom de votre agence de transport lacustre ?
R/ Etablissements SILIMU.
Q.2 Votre agence de transport lacustre possède combien de bateau et combien d’agent ?
R/ Nous avons quatre bateaux qui transportent les passagers et les marchandises et trois barges qui font le transport de marchandises. Notre agence de transport a plus de cent-trente agents navigants et administratifs.
Q.3 Quels sont les sous services offerts par votre agence de transport lacustre ?
R/ Nous offrons un service de bar et de restaurant à bord de nos bateaux ainsi que dans nos salles d’attente à Goma et Bukavu. Nos passagers peuvent également profiter d'un salon de coiffure à bord et d'un service de transport gratuit.
Q.4 Quelles sont les différentes tâches que vous aimiez qu’elles soient automatisées ?
R/ La seule opération qui nous prend suffisamment de temps est la vente des billets, car elle implique de nombreuses étapes, depuis l’obtention des carnets de billets jusqu’à l’inventaire des revenus. Nous aimerions également informatiser certaines tâches de nos services pour nous adapter aux possibilités offertes par les nouvelles technologies, notamment la facturation des biens transportés ainsi que la gestion des entrées et sorties de l’agence.
Q.5 a) Votre agence possède-t-elle mi moyen de réservation de billet qui ne demande pas la présence d’une personne physique ?
R/ Oui | | Non [V]
b) Si oui, lequel ?
R/ ___________
Q.6 Quels sont les logiciels que vous utilisiez pour modéliser vos billets et autres documents qui vous demandent une impression ?
R/ Je ne saluais quoi vous répondre, car nous commandons nos carnets de billets au Rwanda. Pour les autres documents, nous effectuons leur impression au niveau du secrétariat public et dans les imprimeries de la ville.
Q.7 Que fait votre agence pour limiter le nombre de personnes et le nombre de charge que peut prendr e un bateau ?
R/ Le bateau Emmanuel 1 a une capacité de transport de 280 personnes, Emmanuel 2 de 430 personnes, Emmanuel 3 de 700 personnes, et Emmanuel 4 de 800 personnes.
Q.8 a) Votre agence peut accepter d’utiliser un système informatique connecté sur internet qui le permet de faire la réservation de billets en ligne et la gestion de différentes opérations quotidiennes que vous effectuez ?
R/ IVI Oui | | Non
b) Si non, pourquoi ?
R/— — — — — — — — — — — —
Q.9 a) Votre agence aimerez que le système informatique permette au grand publique de réserver lerus billets en ligne, voir- le bateau qui est disponible pour un trafic à un instant dormer, les horaires du trafic de votre agence ainsi que fournir différentes informations instantanément à vos passagers ?
Abb. in Leseprobe nicht enthalten
b) Si non, pourquoi ?
R/ — — — — — — — — — — — — —
Q.10 Dites-moi les différentes opérations (fonctionnalités) que vous aimiez que le système informatique soit à mesure de réalisé :
R/ Nous souhaitons que votre système soit capable de gérer toutes les opérations, depuis l'approvisionnement des carnets de billets jusqu'à l'inventaire quotidien. Le système devrait également nous permettre de maîtriser la gestion de la relation client et du marketing, la gestion des marchandises chargées par bateau et par voyage, ainsi que la gestion du département technique.
Fait à Goma, le 30 Mars 2024
Annexe B Logo de la plateforme TOYHE
Abb. in Leseprobe nicht enthalten
Annexe C Autres Interfaces communes à tous les utilisateurs
Ces interfaces sont accessibles à tous les utilisateurs, à l'exception des clients potentiels. Cependant, le contenu et les fonctionnalités varient en fonction du rôle de chaque utilisateur.
Mon Compte
Abb. in Leseprobe nicht enthalten
Historique des Voyages
Abb. in Leseprobe nicht enthalten
Figure 29 : Interface de gestion de compte sur la plateforme TOYHE.
La figure 29 présente l'interface de gestion de compte sur la plateforme TOYHE. Cette interface permet à l'utilisateur de personnaliser et de mettre à jour certaines informations essentielles liées à son profil. Il a la possibilité de modifier sa photo de profil, son adresse e-mail, son numéro de téléphone et son adresse physique afin de s'assurer que ses données restent à jour. De plus, l'utilisateur’ peut consulter l'historique de ses voyages directement sur la plateforme, ce qui lui permet de garder une trace de ses déplacements et de gérer plus efficacement ses réservations passées.
Abb. in Leseprobe nicht enthalten
Figure 30 : Interface d’aide et support de la plateforme TOYHE permettant aux utilisateurs d’accéder aux guides d’utilisation
La figure 30 représente l'interface d’aide et support de la plateforme TOYHE. Elle permet aux utilisateurs d’accéder à des guides d’utilisation détaillés pour mieux comprendre le fonctionnement de la plateforme. Ils peuvent consulter des instructions sur les différentes fonctionnalités disponibles, facilitant ainsi leur expérience sans nécessiter d’assistance directe.
Sur la figure 31, on retrouve l'interface permettant à l'utilisateur de modifier ses informations personnelles sur la plateforme TOYHE. L'affichage s'adapte en fonction du type de compte. Un utilisateur avec un compte personnel peut mettre à jour ses informations personnelles, son adresse et ses paramètres de sécurité. Pour un compte entreprise, il est possible de modifier les informations de l'entreprise, son adresse et les paramètres de sécurité. Enfin, un utilisateur disposant d'un compte agent ne peut modifier que les paramètres de sécurité de son compte.
Abb. in Leseprobe nicht enthalten
Figure 31 : Interface de modification des informations de l'utilisateur sur la plateforme TOYHE
Annexe D Présentation du site web de la plateforme TOYHE
Cette section présente le site web de la plateforme TOYHE, une partie de l'application qui sert à informer les utilisateurs sur les services proposés, les fonctionnalités disponibles, ainsi que les objectifs et les avantages de la plateforme. Le site internet permet aux visiteurs de mieux comprendre le fonctionnement de TOYHE, d'accéder aux informations pertinentes et d'interagir avec la plateforme à travers diverses sections dédiées.
Abb. in Leseprobe nicht enthalten
Figure 32 : Onglet « Accueil » du site TOYHE
La figure 32 présente l'onglet « Accueil » du site de la plateforme TOYHE. Cette interface permet aux utilisateurs de découvrir les principales fonctionnalités de la plateforme, notamment les services offerts, les informations sur les tarifs et les options de réservation. L'onglet fournit également un accès rapide aux différentes sections de la plateforme, facilitant ainsi la navigation pour les clients et partenaires.
Abb. in Leseprobe nicht enthalten
Figure 33 : Onglet « Paiement » du site de la plateforme TOYHE
La figure 33 représente l'onglet « Paiement » du site de la plateforme TOYHE. Cet onglet affiche les différents canaux de paiement pris en charge par la plateforme, incluant les options de paiement électronique et bancaire. Il indique également la banque partenaire de la plateforme, avec laquelle les utilisateurs peuvent effectuer des retraits d'argent en espèce, garantissant ainsi des transactions pratiques et sécurisées.
Abb. in Leseprobe nicht enthalten
Figure 34 : Onglet « Application Mobile » du site de la plateforme TOYHE
La figure 34 montre l'onglet « Application Mobile » du site de la plateforme TOYHE. Cet onglet fournit des informations sur l'application mobile destinée au guichetier de l'agence de transport. L'application permet au guichetier de centraliser les ventes effectuées au niveau des guichets ainsi que les réservations effectuées par les clients, partenaires et agents. Elle joue un rôle crucial dans la gestion des places disponibles et des cargaisons dans les bateaux, en limitant leur capacité pour une meilleure organisation du transport.
Bibliographie
[1] X. de La Porte, « Coder, ce n'est ni facile, ni marrant. » Radio France, 17 Août 2017.
[En ligne]. Available: https://www.radiofrance.fr/franceculture/podcasts/la-vie- numerique/coder-ce-n-est-ni-facile-ni-marrant-7995040. [Accès le 12 Mai 2024].
[2] M. de Sury, « Nouvelles stratégies de plateforme ; plateforme business : stratégie, conception et mise en œuvre. » Cigref, Paris, 2019.
[3] Phelizon, P. Buffard et Jean-François, « Entreprise 2020 à l'ère du numérique ; enjeux et défis. » Cigref, Paris, 2020.
[4] Lauzon, T. Piette-Coudol et Yvan, « Le télépaiement sur le web pour les entreprises et les particuliers : perspectives françaises et québécoises, » Lex Electronica, Paris, 1998.
[5] Zhuo, S. Liu et Yue, « Les systèmes de paiement électroniques et mobiles, et leurs répercussions sur les consommateurs. » ACFC, Canada, Novembre 2012.
[6] C. Chaimaa, « Qu'est-ce qu'une passerelle de paiement + comparatif du top 7. » HOSTINGER, 26 Avril 2023. [En ligne]. Available: https://www.hostinger.fr/tutoriels/passerelle-de-paiement#:~:text=Une%20passerelle%20de%20paiement%20est%20un%20service%20qui ,de%20les%20transf%C3%A9rer%20sur%20le%20compte%20du%20commer%C3%A7a nt.. [Accès le 17 Juin 2024].
[7] PayPal, « MerchantOverview_interactive.indd. » 2006. [En ligne]. Available: https://www.paypalobjects.com/en_US/pdf/merchantOverview_interactive.pdf. [Accès le 17 Juin 2024].
[8] C. Hooper, « 5 meilleures passerelles de paiement. » GoCardLess, juillet 2022. [En ligne]. Available: https://gocardless.com/fr/guides/articles/meilleures-passerelles-de- paiement/. [Accès le 17 Juin 2024].
[9] JotForm, « A propos de paiement et de service Stripe. » JotForm Inc, 2024. [En ligne]. Available: https://www.jotform.com/fr/blog/a-propos-des-paiements-et-des- services-stripe/. [Accès le 17 Juin 2024].
[10] MaxiCash, « MaxiCash Integrator Doc. » 2023. [En ligne]. Available: https://developer.maxicashme.com/. [Accès le 17 Juin 2024].
[11] J. Fontanel, P. Lacomme et R. Ren, Les web services, Paris : Ellipses, 23/04/2013.
[12] A. Edouard, « Comprendre l'architecture de web service REST. » University of Côte d'Azur, Nice.
[13] S. Pathi, Pro RESTful APIs : Design, Build and Integrate with REST, JSON, XML and JAX-RS, California: Apress, 2017.
[14] Mehta, M. Kalali et B., Developing RESTful Services with JAX-RS 2.0, WebSockets, and JSON : A complete and practical guide to building RESTful Web Services with the latest Java EE7 API, Birmingham: Packt Publishing, 2013.
[15] C. Brière, « Protocole de transfert Hypertexte. » The Internet Society , Virginie, 2007.
[16] C. Wong, HTTP Pocket Reference: Hypertext Transfer Protocol, Sebastopo: O'Reilly, 2000.
[17] B. Smith, Beginning JSON, New York: Apress, 2015.
[18] Tran et T. Kiet, Introduction to web services with Java, London: BookBoon.com, 2013.
[19] D. Tidwell, J. Snell et P. Kulchenko, Programming Web Services with SOAP, Sebastopol: O'Reilly, 2001.
[20] K. Tzompanaki, « Services web. » Université de Cergy-Pontoise, Paris.
[21] Morvan, T. Richard et H. Le, Java Spring : le socle technique des applications Jakarta EE, Saint-Herblain : Éditions ENI, 12/07/2023.
[22] H. Madani, React : développez le Front End de vos applications web et mobiles avec javascript, Saint-Herblain : Éditions ENI, 10/01/2024.
[23] J. Trillard, Flutter : développez vos applications mobiles multiplateformes avec Dart, Saint-Herblain : Éditions ENI, juin 2020.
[24] React, « Describing the UI - React. » [En ligne]. Available: https://react.dev/learn/describing-the-ui. [Accès le 17 Février 2025].
[25] TailwindCss, « Créez rapidement des sites Web modernes sans jamais quitter votre HTML. » [En ligne]. Available: https://tailwindcss.com/. [Accès le 17 Février 2025].
[26] Material UI, « Material UI : la bibliothèque de composants React que vous avez toujours voulue. » 2024. [En ligne]. Available: https://mui.com/material-ui/?srsltid=AfmBOop1-2OspYu7RPiTaagaqcpuYs-dI4e-0i4z9I6X_Hp7EIFxZX_U. [Accès le 17 Février 2025].
[27] P. Moati, « Flutter pour le développement de vos applications mobiles crossplatform. » 20 Octobre 2022. [En ligne]. Available: https://www.kaliop.com/fr/flutter-pour- le-developpement-de-vos-applications-mobiles-cross-platform/. [Accès le 17 Février 2025].
[28] Spring, « Spring Boot. » 2025. [En ligne]. Available: https://spring.io/projects/spring-boot. [Accès le 2025 Février 2025].
[29] Gouigoux et Jean-Philippe, Docker : concepts fondamentaux et déploiement d'applications conçues en services, Saint-Herblain: Éditions ENI, 2022.
[30] Mrabett et E. Hassan, « Les fonctionnalités de Spring Boot. » 23 Avril 2024. [En ligne]. Available: https://www.itguidemaster.com/index.php/les-fonctionnalites-de-spring- boot/. [Accès le 17 Février 2025].
[31] PostgreSQL, « PostgreSQL : Haute disponibilité, répartition de charge et réplication. » PostgreSQL, 2025. [En ligne]. Available: https://docs.postgresql.fr/9.6/high- availability.html. [Accès le 18 Février 2025].
[32] FireBase, « Stockage cloud pour FireBase. » 2024. [En ligne]. Available: https://firebCSE.google.com/docs/storage?hl=fr. [Accès le 18 Février 2025].
[33] J. Robert, « D3.js : tout savoir sur cette bibliothèque JavaScript. » 23 Octobre 2024. [En ligne]. Available: https://datascientest.com/d3-js-tout-savoir. [Accès le 18 Février 2025].
[34] Twilio, « Twilio : l'API de communication pour SMS, appels vocaux, vidéo et authentification. » 2025. [En ligne]. Available: https://www.twilio.com/en-us. [Accès le 18 Février 2025].
[35] DHgate, « Terminal POS Android Portable | Système de Machine Mobile personnalisé avec imprimante 7 points de vente, vente en gros » 2025. [En ligne]. Available: https://fr.dhgate.com/product/arrival-wholesale-handheld-android- terminal/896599992.html?skuId=1154441031240732725. [Accès le 20 Mars 2025].
[...]
Buy now
- Quote paper
- Héritier Amuri Tchalumba (Author), 2024, Développement d’une plateforme intégrée de prise en charge des réservations payantes et de gestion des voyages sur le lac Kivu, Munich, GRIN Verlag, https://www.grin.com/document/1749605
