Avantages et inconvénients du marketplace

Avantages et inconvénients du marketplace

E-business

E-business est une stratégie basée sur des technologies de l’information et de communication en ligne pour mettre en réseau et habiliter les processus d’affaires, commerce électronique, communication organisationnelle et collaboration dans une entreprise et avec ses clients, ses fournisseurs et tous les partis prenantes dans le but d’augmenter la valeur de l’entreprise grâce à la motivation du personnel et l’utilisation des différents actions pour concrétiser une vente, par la suite une assurance de la fidélisation client de la vente en ligne. [1] E-business met sous contrôle les différents processus internes et externes de l’entreprise y compris les relations efficaces avec les fournisseurs, les clients et les partenaires (ressource humaines, vente, achat, stock et production), afin de l’aider à travailler plus intelligemment et satisfaire le besoin des utilisateurs d’une manière plus facile.

E-commerce

E-commerce (commerce électronique) est une sous activité d’e-business qui ne se concentre que sur la procédure d’achat et non pas sur la fidélisation clientèle c’est-à-dire un ensemble des transactions commerciales entre deux entités sur des réseaux informatiques. Ces entités peuvent être des entreprises, entreprise et un particulier ou deux particuliers. Le commerce électronique s’appuie sur plusieurs technologies basé sur le marketing Internet, les systèmes de gestion des stocks, le traitement des transactions en ligne et beaucoup d’autres systèmes. Les entreprises de commerce peuvent être une partie ou même tout élément des sites d’achat en ligne pour les particuliers ou entre entreprise pour échanger les données et les services, elles peuvent même participer et être un élément de marketplace.

Relation entre marketplace, e-business & e-commerce

La réalisation de marketplace se base principalement sur l’e-business et l’e-commerce, comment ça ? La figure 02 représente la relation entre ces derniers. Pour une bonne planification des techniques technologiques et de nouvelles règles e–business qui mènent à la fidélisation des clients d’une manière différente et plus efficace ainsi une manière plus intelligente pour organiser les opérations et les ressources internes de marketplace (analyse de donnée, motivation de personnelles et la gestion des ressources humaine …etc.) Afin de mettre notre client (marchand) à l’aise et gagner sa confiance, vu que ces règles vont être présentées et publiées sur le marché, et par la suite attirent le maximum de clients. Ensuite mettre en disposition de marchand sa propre plateforme qui va être sa propre boutique en ligne en lui garantissant une puissante logistique telle que les prestataires de payement sécurisés afin de réaliser une bonne solution e-commerce qui convient à l’utilisateur finale. Et pour conclure la marketplace est l’avenir d’e-commerce car ce modèle est aujourd’hui le meilleur moyen de faire de l’e-commerce de manière rentable et avec une forte croissance.

la méthode agile scrum

La méthode scrum sert à gérer les projets d’une façon agile, utilisé pour développer un logiciel complet ou quelques parties d’un grand système avec une approche itérative incrémentale qui consiste à découper le projet en plusieurs étapes appelé « sprint » ou « itération ». Les sprints sont toujours d’une courte durée entre 2 à 4 semaines constituent d’un ensemble de besoins appelé « user story ». Scrum commence par un « Product backlog » qui sélectionnons toutes les choses qui doivent être faites dans le projet. A partir de cet ensemble nous sélectionnons les exigences priorisés qui seront développées « user story ». Ce sous ensemble des éléments forment «sprint backlog » qui sera mis à jour sur une base quotidienne. Pendant les sprints chaque jour des réunions « Daily scrum meeting » seront organisés avec tous les membres de l’équipe pour discuter le déroulement du travail et les obstacles rencontrés. Scrum se base sur une équipe de différents rôles : Product down, scrum master et team, Product down : il s’agit d’avoir une vision de ce que nous voulons construire et transmettre cette vision à l’équipe de développement. Scrum master : il guide l’équipe de développement pendant les itérations, il assure la communication efficace entre les scrums team et il gère aussi les obstacles pour l’équipe. Scrum team : il s’agit d’un ensemble de personnes travaillant ensemble pour livrer un produit utilisable à la fin de chaque sprint. [13] Nous avons choisis scrum comme méthode de gestion de notre projet pour développer notre application, car elle permet d’offrir une meilleurs visibilité par rapport aux autres méthodes, nous avons utilisé quatre itérations pour la réalisation de notre application qu’on va les définir : Itération 1 (du 13/02/2018 au 05/03/2018) {BismiLlah} est notre 1ère itération qui a duré 17 jours. On a détecté un bug bloquant qu’il s’agit d’une erreur de génération d’application, 4 bugs majeurs et 8 bugs mineurs. Quelques fonctionnalités de ce sprint Backlog :

Diagramme de séquence « acheté article » La figure 20 décrit les interactions possibles entre l’acheteur et les objets de système lors d’un achat d’article: Acteur : acheteur. Résume : le noyau de notre application est l’achat d’un article, l’acheteur se connecte à son compte pour consulter les produits, puis il sélectionne un pour l’acheter, le contrôleur Ionic demande le contrôleur Node JS de calculer un pourcentage de réduction, ce dernier la transmettre à l’objet achat pour le générer. L’objet achat vérifie si cette transaction est faite pour la première fois ou ce client a déjà fait une avant pour le même article et il a annulé la procédure après le calcul et l’affichage de pourcentage. Si c’était une nouvelle transaction, il génère une réduction et l’enregistre puis l’envoyer afin d’être afficher a l’acheteur. Sinon si l’acheteur a lancé la procédure d’achat puis il a annulé après la génération de pourcentage, ensuite avant les 24h qui suivent il a refait la transaction sur le même article, alors l’objet achat affiche toujours l’ancien pourcentage généré la première fois. Sinon si c’était après les 24h alors il génère un nouveau pourcentage de réduction. Après l’affichage de pourcentage, l’acheteur remplit le formulaire d’achat avec les informations nécessaires, parmi ces derniers c’est le numéro de la carte crédit, l’objet Ionic le crypté puisque c’est une donnée trop critique donc il fait la protégé puis la transfère à l’objet contrôleur Node JS qui va la décryptée et l’envoyer au Controller pin payement afin de vérifier si cette carte est valide ou pas. Si c’était valide la procédure d’achat se termine avec succès et la quantité de cet article décrémente par un. Sinon se termine par un échec.

Architecture de fonctionnement d’application

La figure 25 résume le scénario de notre application en montrant quelques fonctionnalités avec chacun de nos utilisateurs. La figure 25 résume le scénario de notre application en montrant quelques fonctionnalités avec chacun de nos utilisateurs. Expliquant notre système en le divisant en quatre parties (plateformes distante, Application Administrateur, espace Marchand et la partie acheteur) sachant que les applications sont tous disponibles sous version Android et IOS. Commençant par la partie plateforme, là où se retrouve toutes les parties prenantes de notre système ainsi notre partie serveur. On trouve comme plateforme les boutiques d’applications AppStore et PlayStore là où nous allons mettre l’application dédié aux acheteurs en disposition, aussi la plateforme Pin payments comme prestataire responsable sur les transactions de payement en ligne en gérant tous types de cartes de crédit, nous avons aussi comme plateformes la partie Google Map là où nous avons pu enregistrer une API Key afin que nous puissions localiser les boutiques de nos marchands en récupérant leurs longitude et latitude qui vont faciliter le chemin aux acheteurs lors la récupération de leurs articles.

Passant aux espaces utilisateur, nous commençons par l’administrateur qui a comme possibilité une large analyse de données, une gérance de catalogues ainsi que les utilisateurs (Marchands et Administrateurs). Nous avons aussi l’espace Marchand qui ne peut pas être sauf si le contrat est signé en satisfaisant certains critères spécifiques tel que l’obligation de disposition d’une boutique agrée, ensuite notre nouveau fournisseur aura une application de boutique DiscountDice Version Marchand, Là où il peut gérer ses articles qui vont être visible dans le monde d’internet qui garantit une grande publicité, sachant que les articles ne vont pas être mis en ligne sans l’accord de l’administrateur, aussi il a comme fonctionnalités la gérance des ressources financières tel que la gestion de stocke et le revenu constaté avec l’entreprise DiscountDice, déchiffrement et validation des tickets de réduction présenter par les récupérateurs (acheteurs) des articles vendus en ligne, ainsi qu’un historique de validation de ces derniers. Finalement nous avons l’internaute le plus important dans notre système qui est l’acheteur, il peut exploiter nos articles après avoir eu DiscountDice de prés des stores des applications et s’inscrire et puis aura en disposition une large gamme de fonctionnalités. Tel que l’exploitation efficace des articles, la recherche rapide, la consultation des tickets de réduction stockés dans le portable et la gérance des informations privés. Passant au coeur de notre Marketplace, qui est le prix dynamique de l’article qui peut varier de 0.01£ jusqu’à un prix inférieur sur le prix vitrine de la boutique physique en respectant des règles de gestions ainsi de sécurités.

Table des matières

Introduction générale
Chapitre I Fondements théoriques
I.Introduction
II.E-business
III. E-commerce
III.1 Définition
III.2 M-commerce
IV.Marketplace
IV-1. Définition
IV-2. Acteurs dans un Marketplace
IV -3. Typologie des relations commerciales
IV-4 Les cinq piliers du marketplace
IV-5. Avantages et inconvénients du marketplace
Relation entre marketplace, e-business & e-commerce
Conclusion
Chapitre II Etat de l’art
I.Introduction
II.Comparatifs de marketplace
III. Critiques :
Suggestion
Conclusion
Chapitre III Conception de l’application
I.Introduction
II.Processus de Développement
II.1. Cycle de vie en V
II.2 Diagramme de gant
II.3 la méthode agile scrum
III Patron de conception « Design Patterns »
III.1 Patron de création « Patterns de Création »
III.2 Patron de fabrication « Design Pattern factory »
III3 Patron de conception « Pattern de conception »
IV Analyse
IV.1 Diagramme de cas d’utilisation
IV.1.2. Cas d’utilisation marchand
IV.1.3 Cas d’utilisation administrateur
IV.2 Diagramme de séquence système
V.Conception
V.1. Diagramme de séquence
V.2.Modèle physique de donnée
Conclusion
Chapitre IV Réalisation de l’application
I.Introduction
II.Environnement de logiciel
III. Environnement de développements
III.1 Plateformes
III.2 Logiciels
III.3 Technologies utilisées
IV.Pourquoi IONIC et pourquoi la programmation Hybride ?
V.Prototypes
V.1 Architecture
VI.Caractéristiques
VI.1 Caractéristiques fonctionnelles
VI.2 Caractéristiques non fonctionnelles
VII. Conclusion
Chapitre V Manuel de l’application
Démonstration des interfaces
Conclusion générale
Références biographiques

Télécharger le rapport complet