E-Commerce et CRM Salesforce : Guide Pratique
E-Commerce et CRM Salesforce : Guide Pratique
DEDICACE
A
LA FAMILLE HAPI
REMERCIEMENT
Nos sincères remerciements s’adressent :
SOMMAIRE
DEDICACE........................................................................................................................................ I
REMERCIEMENT........................................................................................................................... II
SOMMAIRE.................................................................................................................................... III
LISTE DES FIGURES.................................................................................................................... IV
LISTE DES TABLEAUX................................................................................................................. V
ABREVIATIONS............................................................................................................................ VI
GLOSSAIRE.................................................................................................................................. VII
RESUME...................................................................................................................................... VIII
ABSTRACT.................................................................................................................................... IX
INTRODUCTION GENERALE....................................................................................................... 1
DOSSIER D’INSERTION................................................................................................................. 2
CAHIER DES CHARGES.............................................................................................................. 10
DOSSIER D’ANALYSE................................................................................................................. 21
DOSSIER DE CONCEPTION........................................................................................................ 50
DOSSIER DE REALISATION....................................................................................................... 61
GUIDE D’UTILISATION............................................................................................................... 71
CONCLUSION GENERALE.......................................................................................................... 86
WEBOGRAPHIE........................................................................................................................... XII
ANNEXES.................................................................................................................................... XIII
TABLE DES MATIERES............................................................................................................ XIV
Rédigé par TIEMENI Hapi | 2ème année Génie Logiciel | ISMAT III
MISE EN PLACE D’UN SITE DE E-COMMERCE ET COUPLAGE AVEC
UN CRM : CAS DE SALESFORCE
ABREVIATIONS
UML : Unified Modeling Language
GLOSSAIRE
Salesforce : plateforme cloud de gestion des relations clients, qui permet d’unifier la vue de vos
clients pour les différents services au sein de votre entreprise.
Web to Case : fonctionnalité qui permet aux clients d’effectuer des réclamations depuis le web via
le site d’une entreprise.
Chat to Case : fonctionnalité qui permet aux clients d’effectuer des réclamations depuis le chat
web.
Chat Web : canal de communication sécurisé entre le client et l’agent du service commercial.
Règle d’attribution : outil qui permet d’acheminer automatiquement les requêtes vers les files
d’attente ou les utilisateurs concernés.
ORM : programme informatique qui se place en interface entre un programme applicatif et une
base de données orientée objet.
Serveur de base de données : sert à stocker, extraire et gérer les données dans une base de
données.
Rédigé par TIEMENI Hapi | 2ème année Génie Logiciel | ISMAT VII
MISE EN PLACE D’UN SITE DE E-COMMERCE ET COUPLAGE AVEC
UN CRM : CAS DE SALESFORCE
RESUME
Le rapport de stage est un document dans lequel l’étudiant décrit les tâches effectuées en
entreprise dans le cadre de son stage. Le nôtre s’est déroulé sur une période de trois mois au sein
de GATEWAY SFDC, une jeune entreprise dont l’activité principale est le développement de
solutions informatiques visant à résoudre les problèmes préalablement identifiés par des clients
externes. Durant notre stage, il nous a été demandé de concevoir une plateforme de e-commerce et
de le coupler avec l’outil de gestion CRM 1: Salesforce. De manière plus précise, la plateforme
devra permettre d’une part aux personnes (clients) de trouver rapidement les articles qu’il souhaite,
effectuer une commande, faire livrer une fois la commande prête. D’autre part, les données clients
transmis aux CRM permettront aux commerciaux de maximiser les ventes. Pour faciliter les tâches
d’implémentation, l’ensemble des fonctionnalités du systèmes seront accessibles à partir d’une API
2
web que nous développerons. Ce rapport présentera l’ensemble des étapes comprises dans
l’élaboration de ce projet.
Mots Clés :
- E-commerce
- Salesforce
- CRM
- API
1
CRM : Customer Relationship Management (Gestion de la Relation Client)
2
API : Application Programming Interface (Interface de Programmation d’Application).
Rédigé par TIEMENI Hapi | 2ème année Génie Logiciel | ISMAT VIII
MISE EN PLACE D’UN SITE DE E-COMMERCE ET COUPLAGE AVEC
UN CRM : CAS DE SALESFORCE
ABSTRACT
The intership report is a document in which the student describes the tasks performed in the
company as part of the internship. Our intership took place over a period of three month within
GATEWAY SFDC, a young company whose main activity is the development of IT solutions
aimed at solving problems previously identified by external customers requiring their help to
provide a solution. During our internship, we were asked to design an e-commerce platform and to
couple it with the CRM management tool : Salesforce. More precisely, the platform should allow
people (customers) to quickly find the items they want, place an order, have it delivered once the
order is ready, etc. On the other hand, the customer data transmitted to the CRM will allow sales
representatives to maximize sales To facilitate implementation tasks, all system features will be
accessible from a web API that we will develop. This report will summarize all the steps of the
project.
Key words :
- E-commerce
- Salesforce
- CRM
- API
INTRODUCTION GENERALE
A l’ère des TIC, on note non seulement la création de nombreux domaines d’activités mais
surtout l’amélioration des conditions de vies des Hommes. L’amélioration de ces conditions de vie
passe par la résolution d’un certain nombre de problèmes. La résolution d’une partie de ces
problèmes est la mission de Gateway SFDC, une jeune entreprise de services numériques dans
laquelle nous avons effectué notre stage et dont la mission première est de réaliser grâce au CRM
Salesforce des processus et applications pour solutionner des problèmes qui, préalablement, ont été
identifiés. Par conséquent, en tant que stagiaires académiques, il nous a été confié comme tâche de
mettre en place un site de e-commerce de vente de chaussures de sports et d’y intégrer Salesforce
pour la gestion du service client. Après avoir présenté la structure d’accueil dans un dossier
d’insertion, nous débuterons la tâche qui nous incombe par l’élaboration d’un cahier de charge qui
spécifiera les objectifs à atteindre ; suivra ensuite un dossier d’analyse dans lequel une étude
préalable et une critique de l’existant seront effectués. Nous poursuivrons avec le dossier de
réalisation qui présentera de bout en bout les lignes du processus de conception, puis le dossier de
réalisation qui présentera les outils utilisés pour réaliser la solution et enfin un guide d’utilisation
présentant le processus d’installation du produit développé, ainsi que quelques-unes des
fonctionnalités essentielles.
DOSSIER D’INSERTION
RESUME
Le dossier d’insertion décrit le déroulement de l’accueil et de l’intégration des stagiaires dans
la structure d’accueil, présente l’ensemble des informations recueillies pendant la période
d’insertion aussi bien sur l’entreprise que sur la tâche à accomplir pendant la période de stage.
APERCU
INTRODUCTION
ACCUEIL ET INTEGRATION
PRESENTATION DE L’ENTREPRISE
RESSOURCES LOGICIELLES ET MATERIELLES
ORGANIGRAMME
SITUATION GEOGRAPHIQUE CONCLUSION
INTRODUCTION
Le cycle de formation BTS a ISMAT inclue pour les étudiants de 2ème année un stage
académique d’une durée de 03 mois. Ce stage académique inclue une phase d’insertion qui s’étend
sur les 02 premières semaines dudit stage. Pendant celle-ci, l’étudiant prend contact avec le
personnel de la structure d’accueil et s’informe sur la structure et son fonctionnement, et
éventuellement sur son encadreur professionnel. L’entreprise dans laquelle nous avons effectué
notre stage est Gateway SFDC, nouvellement crée, elle opère principalement dans le domaine des
TIC. Dans ce dossier d’insertion, nous présenterons la structure Gateway SFDC, puis la manière
dont nous y avons été accueillis.
I. ACCUEIL ET INTEGRATION
1. Accueil
Nous sommes le 14 Juillet 2021 lorsque nous nous présentons au bâtiment général de
GATEWAY SFDC pour le début de notre stage. Nous sommes reçus par son Président Directeur
Général Monsieur MAMANE Jules César. Après quelques minutes de discussion portant
principalement sur la présence et nos attributions futures, nous avons été dirigés vers notre
encadreur professionnel, Monsieur OMRAAM NGUIFFO Boris Michael, Développeur Salesforce
au sein de la structure. Celui-ci nous a très vite mis dans le bain et nous a confirmé sa disponibilité
pour tous besoin qui pourra se poser. Par la suite, il nous conduit vers notre futur espace de travail
et présenter aux autres stagiaires. Il est 17h quand nous quittons les bureaux pour cette première
journée.
2. Intégration
Tout au long de notre phase d’insertion qui a duré exactement deux semaines, il a été question
pour nous de nous adapter et de nous familiariser avec notre structure d’accueil, en se rapprochant
de la haute hiérarchie et toutes les personnes au sein de la structure devant intervenir de près ou de
loin à la réalisation de notre projet. Pendant ces deux semaines nous avons peu à peu découvert
l’outil principal utilisé au sein de la structure : Salesforce3. Il a été question aussi pour nous de
discuter des sujets qui préoccupent l’entreprise et qui cadrent avec notre formation académique :
sujets qui feront l’objet de notre thème de stage.
1. Historique
GATEWAY SFDC est une entreprise basée au Cameroun, constitué d’une équipe aux
compétences diverses et spécialisées dans divers domaines tels que : le développement
3
Salesforce : solution de gestion de relation client basée sur le cloud.
La mission première de l’entreprise est de donner aux organisations et aux individus des
solutions informatiques innovantes afin de rendre ces dernières plus productives.
2. Missions
GATEWAY SFDC est une entreprise de services numériques qui s’est donné pour missions
d’accompagner les personnes et les entreprises en vues de la réalisation de leurs objectifs à court,
moyen et long terme. Pour ce faire, ils ont pour objectifs :
Apporter aux entreprises de tous les secteurs d’activités, une envie, un besoin d’améliorer
leurs standards en termes de qualité de service en se basant sur les normes internationales ;
Accompagner les entreprises dans leur croissance via des techniques basées sur
l’optimisation, les interactions avec les clients et une rentabilité permanente dans le temps ;
Apporter un appui technique qualitatif indéniable par des formations pour
l’accompagnement des vendeurs, des commerciaux et toutes personnes ayant des contacts
fréquents avec la clientèle ;
Former des développeurs compétents intégrateurs de nouvelles technologies Salesforce.
1. Ressources matérielles
Les ressources matérielles représentent l’ensemble des équipements informatique utilisés pour
le traitement automatique, l’envoi, la réception et/ou la restitution des informations.
2. Ressources logicielles
mmes utilisés pour le traitement
Les ressources logicielles représentent l’ensemble des progra
des informations.
IV. ORGANIGRAMME
La société est statutairement administrée par deux organes : la direction et le conseil
d’administration. La direction générale est composée des services rattachés qui sont :
- Directions techniques
- Direction marketing
- Ressource humaine
V. SITUATION GEOGRAPHIQUE
La Direction Générale de GATEWAY SFDC est située à la POSTE CENTRALE de la ville de
YAOUNDE, en face de la grande cathédrale. Elle peut être facilement localisée à travers le schéma
ci-contre :
CONCLUSION
Arrivée au terme de notre semaine d’insertion, nous pouvons dire de manière certaine que
l’accueil qui nous a été réservé a joué un très grand rôle dans notre mise en condition et ce pendant
toute la période de stage. Nous avons également noté une grande disponibilité de l’ensemble du
personnel et une très bonne collaboration entre stagiaires. Aussi, grâce aux différentes ressources
mises à notre disposition et au climat serein qui règne dans cette entreprise, nous pensons pouvoir
mener à bien et à terme notre projet qui porte sur le thème « Mise en d’un site de e-commerce et
couplage avec un CRM : cas de Salesforce ». Il sera donc question pour nous au cours des
prochains jours de mobiliser davantage nos efforts physiques, matériels et intellectuels afin de le
concrétiser.
RESUME
Le cahier des charges est un document qui présente une étude détaillée du projet. Il décrit
précisément les besoins auxquels les intervenants doivent répondre (objectifs, besoins, contraintes,
etc.). Cette partie permet à l’étudiant de mieux pendre connaissance de son thème qui est dans
notre cas « Mise en place d’un site de e-commerce et couplage avec un CRM : Cas de
Salesforce ».
APERCU
INTRODUCTION
INTRODUCTION
Le cahier des charges est un document contractuel mettant en accord les deux principaux
intervenants dans un projet, à savoir le maître d’ouvrage et le maître d’œuvre. Il est à la fois un
outil de communication et de description du projet pour éviter la production de résultats
inadéquats. Ce document décrit de manière détaillée le projet, ses objectifs, les méthodes de
réalisation et les ressources à utiliser.
1. Contexte et justification
Un des phénomènes remarqués à travers le monde depuis quelques années est l’expansion du
commerce électronique. En effet, bien qu’ayant vu le jour il y’a fort longtemps dans les années 90,
ce n’est que récemment que le e-commerce s’est réellement vu être adopté par la masse populaire
au point de devenir indispensable pour les entreprises du domaine. Avec un taux d’évolution
annuel d’environ 4%, le commerce électronique représente la meilleure opportunité pour une
entreprise d’accroitre sa visibilité.
Dans le but de s’ériger en leader en ce qui concerne la vente de tennis pour hommes et
femmes, SNKRS comme toutes autres entreprises ayant les mêmes objectifs, se doit de s’arrimer
aux nouvelles normes concernant le domaine du commerce ; cela passe par l’adoption d’une
boutique délocalisée.
Conscients que, bien qu’étant efficace, leur magasin physique présente des limites tant au
niveau de l’acquisition de nouveaux prospects, qu’au niveau de la vente et de la relation avec la
clientèle, ils ont émis un besoin d’évolution que Gateway SFDC en tant que fournisseur de solution
s’est donné pour mission de satisfaire.
2. Acteurs du projet
Concepteur et réalisateur du
projet
1. Objectif global
L’objectif global est de mettre en place un système fiable et sécurisé permettant d’une part
d’assurer la disponibilité des produits et d’autre part de couvrir dans son entièreté le processus
d’acquisition d’un produit : de l’ajout au panier, jusqu’à la livraison en passant par la validation de
la commande ; et de fournir au service client les informations nécessaires leur permettant de gérer
correctement les relations avec les clients.
2. Objectifs spécifiques
- Permettre aux clients d’accéder aux différents produits en un clic ou en faisant une simple
recherche
- Permettre de régler les commandes de façon numérique
- Servir d’interface entre le client et le commercial pour la gestion du SAV
- Notifier les clients par e-mail sur l’état de leur commande
- Permettre aux clients d’émettre des réclamations
L’administrateur
Le client
Le visiteur
Le service client (coté Salesforce)
Le responsable du service client
2. Besoins fonctionnels
Pour l’administrateur
o S’authentifier ;
o Enregistrer les produits ;
o Modifier les produits ;
o Afficher les produits ;
o Supprimer un produit ;
o Consulter les statistiques ;
o Générer les rapports et les tableaux de bords
Fiabilité
L’application doit fonctionner de façon cohérente, sans erreur et doit être satisfaisante
Rapidité
Les opérations effectuées par l’application doivent s’effectuer de manière rapide
Convivialité
L’application doit être adaptée à l’utilisateur ; elle doit également être intuitive (qu’il n’ait
besoin d’aucune formation afin de pouvoir l’utiliser)
Sécurité
La confidentialité des données personnelles des utilisateurs devra également être respectée
par notre solution
Aptitude à la maintenance et la réutilisation
Le système doit être conforme à une architecture standard et claire permettant sa
maintenance et sa réutilisation.
1. Ressources logicielles
Tableau 4: Ressources logicielles
2. Ressources matérielles
Tableau 5: Ressources matérielles
3. Ressources humaines
Tableau 6: Ressources Humaines
Sources :
- [Link] : prix
du système d’exploitation.
- [Link] prix du logiciel PowerAMC.
- [Link] ; prix de la suite office.
- [Link] montant du salaire d’un analyste programmeur ;
- [Link] ; valeur salariale d’un développeur.
4. Estimation financière
Tableau 7: Estimation financière du projet
[Link] LIVRABLES
A la fin des délais fixés pour le développement de cette solution, les éléments qui feront
office de livrables seront :
CONCLUSION
L’élaboration d’un cahier des charges est une étape importante dans la conception d’une
solution informatique. Ce document nous a permis de mieux cadrer notre projet et de connaître de
manière exacte la route à suivre et les tâches à effectuer dans les délais prescrits.
DOSSIER D’ANALYSE
RESUME
L’analyse est une étape importante dans tout projet informatique, quelle que soit sa taille. Dans
cette section, nous parlerons de la méthode d’analyse choisie et des diagrammes qui matérialisent
la structure de notre projet.
APERCU
INTRODUCTION
DESCRIPTION DE L’EXISTANT
LE PROCESSUS CRM
PRESENTATION DU LANGAGE UML ET DE LA METHODE 2TUP
DIAGRAMMES DE LA BRANCHE FONCTIONNELLE
CONCLUSION
INTRODUCTION
L’analyse est un examen méthodique permettant de distinguer les différentes parties d’un
problème, et d’en déterminer les solutions en suivant une méthodologie définie. L’analyse de
notre projet sera basée sur le langage UML, selon le processus 2TUP. A travers ces derniers, nous
ressortirons les diagrammes intervenants dans la phase d’analyse, à savoir : les diagrammes de
cas d’utilisation, diagrammes d’activités, et les diagrammes de séquences.
I. DESCRIPTION DE L’EXISTANT
1. Description
L’ensemble des étapes décrites ci-dessous son propre à SNKRS, le client pour lequel le projet
est réalisé.
SNKRS dispose actuellement d’un magasin physique, où des articles sont rangés à la vue des
clients. Ils disposent de plusieurs variétés d’articles mais les échantillons ne sont pas tous visibles,
certains sont stockés dans l’arrière-boutique et ne sont sorties que si un client en fait la demande
ou alors si un espace se libère dans les vitrines.
Une fois la boutique ouverte et les premiers clients arrivés, les responsables de ventes de SNKRS
ont à faire à deux types de clients : ceux qui savent exactement ce qu’ils cherchent et les autres.
En cas de problème futur avec l’article acheté, le client peut soit contacter le service client
grâce au numéro de la boutique, soit se rendre directement surplace. Les informations concernant
les réclamations des clients sont consignées sur support papier et traités une fois que les ressources
nécessaires seront transmises par le service commercial au service client.
2. Critique
Les points négatifs importants identifiés lors de l’étude de l’existant sont les suivants :
- La totalité des produits ne sont pas couverts par l’espace que fournit le magasin, ce qui
engendre du travail supplémentaire lorsque ceux-ci font l’objets d’une demande ;
- Perte de temps dans la recherche de produits ;
- Non automatisation du service client pouvant engendrer des pertes de données ;
- Le service client n’a aucune visibilité sur les interactions du client avec le service
commercial ;
3. Solution
Les solutions que nous proposons aux différentes critiques observées sont les suivantes :
1. Définition et rôles
CRM (Customer Relationship Management) est une série de plateforme qui gèrent les relations
et interactions avec les clients, les clients potentiels et contacts ; automatise le flux de travail ;
fournit des données analytiques sur les entreprises ; et les aide à prendre des décisions éclairées
basées sur des données de façon à favoriser sa réussite.
En bref, la définition du CRM correspond à tout ce que l’entreprise accomplit pour interagir
avec ses clients actuels et potentiels et optimiser ces relations. Un outil CRM vous permet de faire
le suivi des coordonnées, de l’historique d’achat, des communications et bien plus.
Si vous avez des clients, vous avez un CRM, qu’il s’agisse d’une feuille de calcul numérique,
de notes écrites à la main, d’une liste de contacts ou d’une puissante plateforme.
Le meilleur outil CRM pour les entreprises offre aujourd’hui plus que de simples fonctions de
gestion de la relation client. Ces systèmes peuvent également vous aider à vous tenir informé des
activités de vos contacts importants, y compris de vos utilisateurs de services, collègues,
fournisseurs et investisseurs. Les plateforme CRM intégrées peuvent aussi automatiser les tâches
banales, libérant par le fait même votre horaire pour que vous puissiez vous consacrez à votre plus
grande priorité : votre relation avec vos clients et contacts.
2. Objectifs
Prévoir les ventes et ainsi permettre de préparer adéquatement la mise en place des
fournitures, de la dotation et des achats ;
Optimiser les parcours et le service client à mesure que les clients potentiels franchissent
les étapes du pipeline ;
Garder un œil sur la satisfaction à l’égard du service fournit et déterminer, grâce aux
données, comment l’améliorer ;
Tirer profit des évènements récents en ligne et sur les réseaux sociaux pour promouvoir
votre marque ;
Rejoindre les clients par l’entremise des différents canaux de marketing pour les guider
dans votre entonnoir ;
Recueillir des données de tous les appareils et plateforme que vos clients utilisent ;
Gagner du temps grâce à l’automatisation des tâches.
1. Le langage UML
La version d’UML utilisée ici compte neuf (09) diagrammes et est subdivisée en deux grands types
de vues :
Les vues statiques qui représentent le système physiquement et incluent cinq (05)
diagrammes.
Diagramme de cas d’utilisation ;
Diagramme de classes ;
Diagramme d’objets
Diagramme de composants ;
Diagramme de déploiement.
Les vues dynamiques qui représentent les interactions effectuées dans le système et le
fonctionnement dynamique des différents acteurs du système. Elles incluent quatre (04)
diagrammes :
Diagramme d’activité ;
UML étant un langage formel et normalisé, il est un bon support de communication dans
l’élaboration d’une solution informatique ; sa polyvalence et sa souplesse font de lui un langage
universel. Toutefois, pour développer des solutions, il est nécessaire de lui associer une méthode
générique qui s’attache à ses diagrammes. On note par exemple la méthode UP (Unified Process
ou processus unifié) ou encore R-UP (Rational Unified Process), 2TUP, AUP, …
2. Le processus 2TUP
2TUP (Two Tracks Unified Process) a pour but d’apporter une réponse aux contraintes de
changements fonctionnels et techniques qui s’imposent aux systèmes d’information, il propose un
cycle de développement qui dissocie les aspects techniques des aspects fonctionnels. Il part du
principe selon lequel : toute évolution imposée au système d’information peut se décomposer et se
traiter parallèlement suivant un axe technique. Il distingue ainsi des branches (fonctionnelle et
technique) dont les résultats sont fusionnés pour réaliser le système. Il faut noter que le processus
2TUP commence d’abord par une étude préliminaire. Dans cette dernière, il s’agit d’identifier les
acteurs qui vont interagir avec le système, les messages qu’échangent les acteurs et le système,
puis à produire un cahier de charges et enfin à modéliser le contexte. A l’issue des évolutions du
modèle fonctionnel et de l’architecture technique, la réalisation du système consiste à fusionner les
résultats
des deux branches à savoir : la branche fonctionnelle et la branche technique. Cette fusion conduit
à l’obtention d’un processus de développement en forme Y, comme illustré ci-dessous :
Diagramme de composants.
La branche de réalisation : c’est le point de réunion des deux branches ; elle permet de
mener une conception application et enfin la livraison d’une solution adaptée aux besoins
des utilisateurs. Le diagramme que nous utiliserons dans cette branche est le diagramme
de déploiement.
a. Présentation
Le diagramme de cas d’utilisation permet d’identifier les fonctionnalités fournies par le système,
les utilisateurs qui interagissent avec le système et les interactions entre ces derniers. Les cas
d’utilisation sont utilisés pour définir un « haut niveau du système ». Les objectifs principaux des
cas d’utilisation sont :
b. Formalisme
Un diagramme de cas d’utilisation est constitué de : des acteurs, des cas d’utilisation et des relations
entre eux.
Il est possible de mettre en relation des acteurs pour traduire l’héritage, ou de mettre en relation
des cas d’utilisation pour traduire l’extension, l’inclusion, ou la généralisation.
- Héritage entre acteurs : il est possible qu’un acteur A ait un accès défini à certaines
fonctionnalités, et un autre acteur B ait accès à d’autres fonctionnalités en plus de celle de
l’acteur A. Dans ce cas, il est possible de définir un héritage entre les deux acteurs
considérés. Dans le diagramme des cas d’utilisation, cette relation est symbolisée par une
flèche dont le sommet est vide.
- Relation d’extension : la relation d’extension permet l’extension éventuelle d’un cas
d’utilisation par un autre. L’application des extensions se fait suivant un scénario, ce qui
implique que le cas d’utilisation de base peut être sollicité sans être étendu. Dans le
diagramme des cas d’utilisation, cette relation est symbolisée par une flèche pointillée
munie du stéréotype « extend ».
- Relation d’héritage ou généralisation : la relation de généralisation permet de traduire le
fait qu’un cas d’utilisation soit un cas particulier d’un autre. Dans le diagramme des cas
d’utilisation, cette relation est symbolisée par une flèche dont le sommet est vide.
- Relation d’inclusion : la relation d’inclusion sert à enrichir un cas d’utilisation par un
autre. Le cas d’utilisation inclus existe uniquement dans ce but, car il ne répond pas à un
objectif primaire. Dans le diagramme des cas d’utilisation, cette relation est symbolisée par
une flèche pointillée munie du stéréotype « include »
La réalisation d’un cas d’utilisation passe par l’exécution préalable d’un certain nombre
d’actions. Cette suite d’action définit un scénario. Plusieurs scénarios peuvent donc être liés au
même cas d’utilisation. Un cas d’utilisation apparait donc comme une abstraction de plusieurs
scénarios d’exécution.
Scénario alternatif
1. Détection d’une erreur à l’étape 5 du
scénario nominal et retour à l’étape 2
2. Diagramme de séquences
Les diagrammes de séquences sont des représentations graphiques des interactions entre les acteurs
et le système selon un ordre chronologique dans la formulation UML. Le diagramme de séquences
permet de décrire les interactions entre les objets au sein d’un diagramme de cas d’utilisation.
a. Formalisme
Le diagramme de séquence énumère les objets horizontalement et le temps verticalement. Il
modélise l’exécutable des différents modèles en fonction du temps. Dans ce diagramme, les objets
et les acteurs sont énumérer en colonnes avec leurs lignes de vies verticales indiquant la durée de
vie de l’objet.
Créer un compte
Effectuer un paiement
3. Diagramme d’activité
Le diagramme d’activité permet de mettre un accent sur les traitements. Il est adapté à la
modélisation des flots de contrôle et de flots de données. Il permet ainsi de représenter
graphiquement le déroulement d’un cas d’utilisation. Le diagramme d’activité illustre la
description textuelle des cas d’utilisation. Sa représentation sous forme d’organigramme le rend
plus compréhensible. Il se focalise sur les activités telles que les voient les acteurs qui collaborent
avec le système dans le cadre d’un processus métier.
a. Formalisme
Le tableau suivant présente les éléments du diagramme d’activité :
S’authentifier
Valider un panier
CONCLUSION
Le dossier d’analyse ainsi rédigé nous a permis d’avoir un aperçu détaillé du système à mettre
en place. Toujours en exploitant le langage de modélisation UML et le processus associé 2TUP,
nous poursuivrons par le dossier de conception dans lequel nous représenterons les diagrammes de
la branche technique à savoir : le diagramme de classe et le diagramme de composant.
DOSSIER DE CONCEPTION
RESUME
Le dossier de conception vient concrétiser les résultats obtenus lors de l’analyse. En effet, nous
ne le verrons plus seulement du point de vue des utilisateurs, mais aussi du point de vue des
développeurs.
APERCU
INTRODUCTION
CONCLUSION
INTRODUCTION
Après la phase d’analyse vient la phase de conception. Il est question ici, après avoir passé du
temps à comprendre le système, de le modéliser. Dans la partie analyse, nous nous sommes surtout
intéressés aux besoins des utilisateurs ; maintenant, nous réfléchirons à l’architecture logicielle de
celui-ci.
1. Diagramme de classe
a. Présentation
Le diagramme de classe est considéré comme le plus important de la modélisation orientée
objet. Contrairement au diagramme de cas d’utilisation qui montre le système du point de vue des
acteurs, lui il montre la structure interne. Il permet de fournir une représentation abstraite des
objets du système qui vont interagir pour réaliser les cas d’utilisation. Le diagramme de classe est
en vue statique, car on ne tient pas compte du facteur dans le comportement du système.
b. Formalisme
Les éléments constitutifs du diagramme de classe sont : les classes, leurs relations (association,
composition, …) et les multiplicités.
2. Diagramme de composant
a. Présentation
Le diagramme de composant décrit l’organisation du système du point de vue des éléments
logiciels, les fichiers sources, les exécutables, les scripts, les fichiers de commande, etc… il permet
de mettre en évidence les dépendances.
b. Formalisme
Les éléments constitutifs du diagramme de composant sont :
Les API REST imitent la façon dont le web lui-même marche dans les échanges entre un client
et un serveur. Une API REST est :
Sans état ;
Cacheable (avec cache = mémoire) ;
Orienté client-serveur ;
Avec une interface uniforme ;
Avec un système de couche ;
Un code à la demande (optionnel) ;
Le principe du client-serveur définit les deux entités qui interagissent dans une API REST : un
client et un serveur, les mêmes entités qui communiquent sur le web. Un client envoie une requête,
et le serveur renvoie une réponse. Ce dernier doit avoir le plus d’informations possible sur le client,
car il est important qu’ils soient capables de travailler indépendamment l’un de l’autre.
Le fait d’être « sans état » signifie que le serveur n’a aucune idée de l’état du client entre deux
requêtes. Du point de vue du serveur, chaque requête est une entité distincte des autres. Ensuite, le
cache, pour les API REST, met en jeu le même principe que pour le reste d’Internet : un client doit
être capable de garder en mémoire des informations sans avoir constamment besoin de demander
tout au serveur. Ce sont les concepts de base à comprendre sur REST, nous verrons les autres
lorsque vos projets deviendront plus complexes.
Les réponses du serveur pour les API REST peuvent être délivrées dans de multiples formats.
JSON (Javascript Object Notation) est souvent utilisé, mais XML, CSV, ou même RSS sont aussi
valables.
2. Formalisme de REST
REST se base sur les URI (Uniform Resource Identifier) afin d’identifier une ressource. Ainsi
une application se doit de construire des URI (et donc ses URL) de manière précise, en tenant
compte des contraintes REST.
La seconde règle d’une architecture REST est d’utiliser les verbes HTTP existants plutôt que
d’inclure l’opération dans l’URI de la ressource. Ainsi, généralement pour une ressource, il y’a 04
opérations possibles (CRUD) :
Créer (create) ;
Afficher (read) ;
Mettre à jour (update) ;
Supprimer (delete) ;
Il est important d’avoir à l’esprit que la réponse envoyée n’est pas une ressource, c’est la
représentation d’une ressource. Ainsi, une ressource peut avoir plusieurs représentations dans des
formats divers : HTML, XML, CSV, JSON, etc.
C’est au client de définir quel format de réponse il souhaite recevoir via l’entête Accept. Il est
possible de définir plusieurs formats.
Les liens d’une ressource vers une autre a tous une chose en commun : ils indiquent la présence
d’une relation. Il est cependant possible de la décrire afin d’améliorer la compréhension du
système. Pour expliciter cette description et indiquer la nature de la relation, l’attribut rel doit être
spécifier sur tous les liens. Ainsi l’IANA donne une liste de relation parmi lesquelles :
Contents ;
Edit ;
Next ;
Last ;
Payment ;
Etc.
Un paramètre comme jeton d’authentification
C’est un des sujets les plus souvent abordé quand on parle de REST : comment authentifier une
requête ? la requête est très simple et est massivement utilisée par des APIs renommées (Google,
Yahoo, etc.) : le jeton d’authentification.
Chaque requête est envoyée avec un jeton (token) passé en paramètre $_GET de la requête. Ce
jeton temporaire est obtenu en envoyant une première requête d’authentification puis en le
combinant avec nos requêtes.
CONCLUSION
Le dossier de conception nous a permis de ressortir les données et les composants nécessaires
pour la création de notre base de données et l’implémentation de notre application. Les différents
éléments modélisés dans cette partie nous ont permis d’avoir une vue globale sur les différents
modules de notre application, dès lors, l’étape suivante de notre projet sera la rédaction du dossier
de réalisation tenant compte des différents éléments modélisés plus haut
DOSSIER DE REALISATION
RESUME
Le dossier de réalisation d’un projet marque le terme de ces étapes d’analyse et conception.
Dans cette partie, nous parlerons des technologies choisies pour développer la solution, de la
présentation des architectures logiques et techniques, ainsi que du diagramme de déploiement.
APERCU
INTRODUCTION
CONCLUSION
INTRODUCTION
L’analyse et la conception sont les phases les plus importantes dans le développement d’un
système. Elles nous permettent de comprendre le(s) problème(s) et d’en imaginer les solutions.
Toutefois, elles sont abstraites et ne permettent pas d’avoir un aperçu concret. L’implémentation
est l’une des dernières phases dans l’élaboration d’un système. C’est lors de cette phase que le
système prend réellement vie, que les idées pensées aux phases précédentes sont concrétisées. Ce
dossier de réalisation révèlera quels ont été les moyens employés pour implémenter et déployer
l’application.
1. Matériels
2. Logiciels
Tableau 17: Logiciels requis pour l'environnement de déploiement.
a. Présentation
Un modèle physique de données est la représentation graphique d’une base de données. Il
consiste en la définition des données à l’intérieur de la structure physique de l’ordinateur : c’est-à-
dire le résultat de la décision qui a été prise en fonction des objets et des contraintes techniques. Il
permet de mieux comprendre les relations entre les tables et d’avoir un point de vue global sur la
base de données.
Dans cette approche, les couches communiquent entre elles et chacune propose un ensemble
de service. Les services d’une couche sont mis à la disposition de la couche supérieure. On
empêche donc qu’une couche invoque les services d’une autre plus basse que la couche
immédiatement
inférieure ou plus haute que celle immédiatement supérieure. Le rôle de chaque couche étant bien
définis, les fonctionnalités de l’une peuvent évoluer sans impliquer des changements dans les
autres.
2. Diagramme de déploiement
a. Présentation
Le diagramme de déploiement est une vue qui sert à représenter l’utilisation de l’infrastructure
physique par le système et la manière dont les composants du système sont repartis ainsi que les
relations entre eux. Le diagramme de déploiement se rapproche de la réalité physique puisqu’il
identifie les éléments matériels, leur disposition physique et la disposition des composants sur ces
éléments matériels. Le diagramme de déploiement permet donc de représenter l’architecture
physique d’un système.
b. Formalisme
Les éléments constitutifs du diagramme de déploiement sont :
CONCLUSION
Dans ce dossier de réalisation, nous nous sommes servis des outils, des concepts et des
modèles produits plus haut pour donner « vie » à notre application. La solution ainsi terminée, son
utilisation requière un guide d’utilisation ; c’est à cela que nous consacrerons la dernière partie de
notre projet.
GUIDE D’UTILISATION
RESUME
L’utilisation d’un site web ne requiert aucune installation préalable, si ce n’est cette d’un
navigateur web. Nous présenterons dans les lignes qui suivent, quelques fonctionnalités
essentielles du système.
APERCU
INTRODUCTION
I. SPECIFICATIONS
II. MANUEL D’UTILISATION
CONCLUSION
INTRODUCTION
Le guide d’utilisation ou manuel d’utilisation est un document de communication technique
qui a pour but de venir en aide aux sujets qui utilisent un système.
I. SPECIFICATIONS
Le système se décline en 02 applications distinctes partageant le même service de données. Ces
applications sont :
- Le client web qui est l’espace disponible pour les utilisateurs lambda, désireux de profiter
du service offert par cette dernière.
- L’application Salesforce qui est l’espace Salesforce destiné aux agents du service client.
1. Processus client
Les étapes ci-dessous présentent le processus de recherche et d’ajout d’un produit, puis du
paiement et de l’émission d’une requête via le chat web :
Etape 1 : Authentification
Connexion
Inscription
L’utilisateur peut s’inscrire sur le site via l’interface
ci-contre en les informations nécessaires.
A la suite de son inscription, celui est désormais
identifiable sur le site.
A l’ouverture du site, l’utilisateur a accès à l’ensemble des produits listés sous forme de
catalogue. Il peut facilement naviguer entre eux, les filtrés ou décider de les afficher par catégories.
Il peut obtenir plus d’informations sur un produit en effectuant un clic sur ce dernier.
Lorsqu’un utilisateur clic sur un produit, celui-ci obtient obtiens une page présentant les
informations sur le produit (plus d’image, description, notes, …).
Lorsque l’utilisateur sur le bouton « Paiement », il lui est présenté un formulaire qu’il devra
remplir en indiquant ses informations bancaires (les autres informations sont pré rempli si
l’utilisateur est connecté). Ensuite l’utilisateur clic sur le bouton « Continuer », si le paiement ne
rencontre aucun problème, l’utilisateur est redirigé vers la page du panier avec une notification de
succès et peut continuer ses achats s’il le désire.
A tout moment lors son parcours du site, s’il le souhaite l(‘utilisateur peut contacter le service
client tant pour de simple question que pour des problèmes en rapport avec un article acheté. Ici,
nous avons deux cas de figure :
Agent disponible
Lorsqu’‘un agent est disponible, un clic sur le
bouton « Chatter avec un expert »
déclenche l(‘envoie d(‘une demande de chat.
Une fois la demande accepter par un agent,
les deux parties peuvent communiquer en vue
Figure 32: Demande de chat de la résolution d’un problème rencontré par
Authentification
L’accès à l’organisation coté Salesforce est protégé. L’agent devra donc entrer ses identifiants
afin de pouvoir effectuer ses différentes tâches. La page de connexion Salesforce se présente tel
que sur la figure ci-dessous :
Une fois connecté à l’application, l’agent accède à la console de service 5 ce qui lui offre une
visibilité complète des requêtes clients : celle qui lui sont assigner, celles traité et à traiter. Il a
également accès à omni-Channel 6 où il a une visibilité sur les demandes de chat dès qu’elles sont
transmissent.
5
Console de service : interface dédiée à la gestion des requêtes clients
6
Omni-channel :
Nous avons présenté précédemment l’envoie l’émission d’une requête lorsqu’aucun agent
n’était disponible. Coté Salesforce, une fois la requête reçue, elle se présente comme suit :
Toujours coté Salesforce, les demandes de chat sont affichées dans la fenêtre omni-Channel
des agents. Une fois accepté par l’un d’entre eux, l’agent peut démarrer la conversation et y mettre
fin une fois le client satisfait.
La fenêtre de chat ouverte présente à sa droite, des composants contenant des informations
supplémentaires sur un client si celui est répertorié dans la base de données. Cette disposition des
éléments permet aux agents de se consacrer uniquement à la résolution de requêtes clients et non à
la recherche d’informations sur ceux-ci.
CONCLUSION
Les fonctionnalités présentées dans cette partie sont celle déjà implémentées et
fonctionnelles, le système n’étant pas complètement implémenté. Nous avons mis l’accent sur
deux cas d’utilisation à savoir : parcours du catalogue, gestion d’un panier, validation d’une
commande, émission de réclamation et traitement des requêtes clients.
CONCLUSION GENERALE
Durant notre stage académique, la principale tâche qui nous incombait était celle de mettre
en place un site de commerce électronique pour le compte de SNKRS et de le coupler avec
Salesforce pour la gestion des retours clients. Cette tâche était organisée en plusieurs étapes ayant
chacune un rôle bien précis. Nous avons d‘emblée dans un rapport d’insertion présenté le
fonctionnement de Gateway SFDC, ensuite nous avons étudié et critiqué l’existant dans un dossier
d’analyse. Dans la partie consacrée à la conception, nous avons défini la structure globale du
projet, puis ont suivi le dossier de réalisation et le guide d’utilisateur. Au jour d‘aujourd’hui, le
projet n’est pas totalement implémenté à 100%, et nous envisageons comme perspective de le
terminer avant la data prévue pour le lancement. Ce stage nous a permis de mettre en pratique les
notions reçues tout au long de l’année académique, d’améliorer nos compétences en ce qui
concerne le développement d’applications web, notamment en ajoutant à nos acquis des
connaissances en programmation Node JS et React JS, mais également en renforçant nos
compétences dans des langages de programmation dans lesquels nous en avions déjà. La
réalisation d’un projet d’une telle envergure nous a permis d’acquérir de l’expérience
professionnelles et nous a permis et nous a permis d’avoir une idée claire de ce qu’est la vie active
et professionnelles.
WEBOGRAPHIE
Tous ces sites ont été consulté durant la période allant du 17 Juillet 2021 au 14 Septembre 2021 :
Rédigé par TIEMENI Hapi | 2ème année Génie Logiciel | ISMAT XII
MISE EN PLACE D’UN SITE DE E-COMMERCE ET COUPLAGE AVEC
UN CRM : CAS DE SALESFORCE
ANNEXES
Rédigé par TIEMENI Hapi | 2ème année Génie Logiciel | ISMAT XIII
MISE EN PLACE D’UN SITE DE E-COMMERCE ET COUPLAGE AVEC
UN CRM : CAS DE SALESFORCE
Rédigé par TIEMENI Hapi | 2ème année Génie Logiciel | ISMAT XIV
MISE EN PLACE D’UN SITE DE E-COMMERCE ET COUPLAGE AVEC
UN CRM : CAS DE SALESFORCE
2. Acteurs du projet.................................................................................................................. 12
II. OBJECTIFS DU PROJET....................................................................................................... 13
1. Objectif global..................................................................................................................... 13
2. Objectifs spécifiques............................................................................................................ 13
III. CAPTURE DES BESOINS FONCTIONNELS DU FUTUR SYSTÈME..........................14
1. Les acteurs du futur système................................................................................................ 14
2. Besoins fonctionnels............................................................................................................ 14
IV. CAPTURE DES BESOINS NON FONCTIONNELS DU SYSTÈME..............................15
V. ESTIMATION DU COUT DU PROJET.................................................................................16
1. Ressources logicielles.......................................................................................................... 16
2. Ressources matérielles......................................................................................................... 17
3. Ressources humaines........................................................................................................... 17
4. Estimation financière........................................................................................................... 18
VI. PLANIFICATION DU PROJET......................................................................................... 18
VII. LES LIVRABLES............................................................................................................... 19
CONCLUSION................................................................................................................................ 20
DOSSIER D’ANALYSE................................................................................................................. 21
RESUME......................................................................................................................................... 21
INTRODUCTION........................................................................................................................... 22
I. DESCRIPTION DE L’EXISTANT......................................................................................... 23
1. Description........................................................................................................................... 23
2. Critique................................................................................................................................ 24
3. Solution................................................................................................................................ 24
II. LE PROCESSUS CRM........................................................................................................... 25
1. Définition et rôles................................................................................................................ 25
2. Objectifs............................................................................................................................... 25
III. PRESENTATION DU LANGAGE UML ET DE LA METHODE 2TUP.........................26
1. Le langage UML.................................................................................................................. 26
2. Le processus 2TUP.............................................................................................................. 27
IV. DIAGRAMMES DE LA BRANCHE FONCTIONNELLE................................................29
1. Diagramme de cas d’utilisation...........................................................................................29
a. Présentation....................................................................................................................... 29
b. Formalisme.................................................................................................................... 29
c. Diagramme de cas d’utilisation du système étudié...........................................................31
i. Diagramme global de cas d’utilisation..........................................................................31
ii. Quelques diagrammes de cas d’utilisation spécifique...............................................31
iii. Descriptions textuelles de quelques cas d’utilisations...............................................34
2. Diagramme de séquences..................................................................................................... 38
a. Formalisme....................................................................................................................... 38
b. Quelques diagrammes de séquence du système étudié..................................................39
3. Diagramme d’activité.......................................................................................................... 43
a. Formalisme....................................................................................................................... 43
b. Quelques diagrammes d’activités du système...............................................................44
CONCLUSION................................................................................................................................ 49
DOSSIER DE CONCEPTION........................................................................................................ 50
RESUME......................................................................................................................................... 50
INTRODUCTION........................................................................................................................... 51
I. STRUCTURE STATIQUE DU SYSTÈME............................................................................52
1. Diagramme de classe........................................................................................................... 52
a. Présentation....................................................................................................................... 52
b. Formalisme.................................................................................................................... 52
c. Diagramme de classe du système...................................................................................... 54
2. Diagramme de composant................................................................................................... 54
a. Présentation....................................................................................................................... 54
b. Formalisme.................................................................................................................... 54
c. Diagramme de composant du système..............................................................................56
II. PRESENTATION DE L’ARCHITECTURE REST................................................................56
1. Les critères REST................................................................................................................ 57
2. Formalisme de REST........................................................................................................... 57
CONCLUSION................................................................................................................................ 60
DOSSIER DE REALISATION....................................................................................................... 61
RESUME......................................................................................................................................... 61
INTRODUCTION........................................................................................................................... 62
I. OUTILS ET TECHNOLOGIES UTILISES............................................................................63
Rédigé par TIEMENI Hapi | 2ème année Génie Logiciel | ISMAT XVI
MISE EN PLACE D’UN SITE DE E-COMMERCE ET COUPLAGE AVEC
UN CRM : CAS DE SALESFORCE
1. Matériels.............................................................................................................................. 63
2. Logiciels.............................................................................................................................. 63
3. Langage de programmation et Framework..........................................................................63
II. PHASE D’IMPLEMENTATION............................................................................................ 64
1. Modèle physique de données............................................................................................... 64
a. Présentation....................................................................................................................... 64
b. Modèle physique de données......................................................................................... 65
2. Aspect sécurité de l’application........................................................................................... 65
a. Sécurité des connexions.................................................................................................... 65
b. Sécurité du service web................................................................................................. 66
c. Validité des sessions......................................................................................................... 66
d. Sécurité des mots de passe............................................................................................ 66
III. DEPLOIEMENT DE L’APPLICATION............................................................................66
1. Architecture physique de l’application................................................................................66
a. La couche présentation (premier niveau)..........................................................................67
b. La couche métier (deuxième niveau).............................................................................67
a. La couche d’accès aux données (troisième niveau)..........................................................67
2. Diagramme de déploiement................................................................................................. 68
a. Présentation....................................................................................................................... 68
b. Formalisme.................................................................................................................... 68
c. Diagramme de déploiement du système étudié.................................................................69
CONCLUSION................................................................................................................................ 70
GUIDE D’UTILISATION............................................................................................................... 71
RESUME......................................................................................................................................... 71
INTRODUCTION........................................................................................................................... 72
I. SPECIFICATIONS.................................................................................................................. 73
II. MANUEL D’UTILISATION.................................................................................................. 73
1. Processus client.................................................................................................................... 73
2. Processus de l‘agent commercial......................................................................................... 81
CONCLUSION................................................................................................................................ 85
CONCLUSION GENERALE.......................................................................................................... 86
WEBOGRAPHIE........................................................................................................................... XII
Rédigé par TIEMENI Hapi | 2ème année Génie Logiciel | ISMAT XVII
MISE EN PLACE D’UN SITE DE E-COMMERCE ET COUPLAGE AVEC
UN CRM : CAS DE SALESFORCE
ANNEXES.................................................................................................................................... XIII
TABLE DES MATIERES............................................................................................................ XIV
Rédigé par TIEMENI Hapi | 2ème année Génie Logiciel | ISMAT XVII