Rapport de stage du fin d’étude – Cadre général du projet

Figure 25:Interfaces des prix des appels vocaux 42

Figure 26:Interface des prix USSD 43

Figure 27:Interface éditer profile 43

Figure 28:Interface d’envoi SMS 44

Figure 29:interface des instants appels 44

Figure 30:Interface des instants TTS 45

Figure 31:Interface des instants TTS 46

Figure 32:Interface d’ajout d’une campagne 46

Figure 33:Interface de chargement de balance 47

Figure 34:Interface de chargement de balance 48

Figure 35:Interface des rapports des activités 48

Figure 36:Interface d’historique de paiement 49

Figure 37:Interface des traces de web 49

Figure 38:Interface détaillant les messages sortants 50

Figure 39:Interface détaillant les messages entrants 50

Figure 40:Interface détaillant les campagnes planifiées 51

Figure 41:Interface détaillant les campagnes en cours 51

Table des tableaux

Tableau 1: Description textuelle de cas d’utilisation “s’inscrire” 21

Tableau 2:Description textuelle de cas d’utilisation « Authentification” 22

Tableau 3:Description textuelle de cas d’utilisation “Editer profile” 22

Tableau 4:Description textuelle de cas d’utilisation “Recharger compte 23

Tableau 5:Description textuelle de cas d’utilisation “Gérer un service 24

Tableau 6:Description textuelle de cas d’utilisation “Consulter les tables des tarifs 24

Tableau 7:Description textuelle de cas d’utilisation “Consulter les rapports d’activités 25

Introduction générale

Dans tous les secteurs de l’industrie, les entreprises cherchent pratiquement à développer et approfondir les relations avec les clients et améliorer sa perception par les utilisateurs ainsi qu’augmenter leurs revenues.

Pour cela nous constatons que plusieurs entreprises ont recourt à la messagerie A2P (Application to Person) ou messagerie professionnel qui est une forme de service dans lequel les messages sont envoyés à partir d’une application web à un abonnée mobile.

L’entreprise peut utiliser cette forme de messagerie pour les rappels, les alertes urgents, les services bancaires et paiement, marketing mobile et mise à jour du service client (authentification et transaction).

Parmi les principales caractéristiques de la messagerie professionnel, nous pouvons citer que cette application possède une forme de communication directe, rapide et immédiate ainsi qu’elle permet d’obtenir un taux de lecture et un taux d’interaction le plus élevé puisqu’elle a la possibilité d’atteindre pratiquement tous les utilisateurs sans restriction.

C’est dans ce contexte que s’intègre mon projet de fin d’études, qui a pour objectif la mise en œuvre d’un système de messagerie avancée « CloudCaastor » adaptée pour la livraison des messages instantanés ainsi que le déploiement efficace des services à valeurs ajoutés comme les compagnes interactives entrantes ou sortantes de Voix, SMS, USSD, MMS…

Afin de proposer une solution adaptée à nos besoins nous allons tout d’abord présenter le cadre général dans lequel a été émergé le projet et étudier la plateforme existante au niveau du premier chapitre. Ensuite, nous allons définir dans le deuxième chapitre la modélisation que nous amènerons à choisir la méthodologie adaptée pour la réalisation.

Le troisième chapitre va présenter l’application avec les fonctionnalités de base en définissant l’environnement matériel et les outils logiciels utilisés.

Chapitre 1 : Cadre général du projet

Introduction

Le premier chapitre aidera à mettre le projet dans son contexte général. En premier lieu, nous allons présenter l’organisme d’accueil en précisant son secteur d’activité. En deuxième lieu, nous allons décrire brièvement le projet et l’étude de l’existant. Nous finirons avec la présentation du problématique et les objectifs à atteindre.

1 Présentation du cadre du projet et l’entreprise d’accueil

Le présent projet consiste à développer un système CloudCaastor qui s’inscrit dans le cadre du projet de fin d’études, en vue de l’obtention du diplôme national d’ingénieur en communications et réseaux de l’École Nationale d’ingénieurs de Gabes. Ce projet est réalisé au sein de la société Supranetcom Tunisie.

1.1 Présentation de l’entreprise

1.1.1 Présentation générale

Stonehenge-Telecom

Stonehenge Telecom est une société internationale américaine de télécommunications créée en1989 et fondée sur les installations des unités d’exploitation dans toute l’Europe, l’Afrique et l’Asie.

Positionnée comme un fournisseur de services d’une source unique avec des architectures technologiques et logicielles solides fondées sur des systèmes voix et données de nouvelle génération, Stonehenge s’adresse uniquement à un certain nombre de nouveaux marchés verticaux tels que les télécommunications, les services sans fil de la marque private-label/affinity, software-as-a service (SaaS), plate-forme-comme-un-Service (PaaS), IP-PBX/VoIP, technologies de commutateurs logiciels, et Tier transporteur à (C2C) de gros de terminaison d’appels.

Au Web Mobile Congres qui s’est tenu à Barcelone en mai 2012, Stonehenge Telecom a annoncé l’acquisition de Supranetcom. Supranetcom a élargi l’offre de Stonehenge dans l’espace Telecom et a donné à Supranetcom la capacité d’offrir ses plates-formes logicielles de télécommunications à l’ensemble de nouveaux marchés.

D’où la nouvelle nomination de l’entreprise Supranetcom – A Stonehenge Company.

Supranetcom

Supranetcom est un fournisseur indépendant de logiciels et spécialisée dans les plates-formes logicielles pour la prestation des services à valeur ajoutée (VAS) et de Services financiers mobiles (MFS).

Fondée en 2003, Supranetcom est une société privée basée en France, et dont l’équipe de base principale est l’ingénierie. Elle se concentre essentiellement sur la recherche et le développement.

Les principaux clients sont les opérateurs télécoms, les opérateurs mobiles, les fournisseurs de services, les institutions financières et les entreprises.

Supranetcom a été reconnu comme Jeune Entreprise Innovante depuis 2008, et a depuis sa création inscrit quatre projets innovants au sein du Programme de recherche et de développement en France [N1].

Siégé social :

• Stonehenge Telecom (Florida, USA)

Filiales :

• Stonehenge Telecom (Paris, France)
• Stonehenge Telecom (Munich, Allemagne)
• Stonehenge Telecom (Bangkok, Thaïlande)
• Stonehenge Telecom (Alger, Algérie)
• Stonehenge Telecom (Tunis, Tunisie)

Supranetcom-Tunisie

Supranetcom-Tunisie est une société de développement et maintenance des logiciels. Il y a cinq ans que Supranetcom-Tunisie a été créée. C’est en effet le 28 mai 2013 que cette entreprise privée a été lancée.

Totalement exportatrice opérant dans le développement des solutions technologiques, elle compte trois filières principales : développement Web, développement mobile et la création des solutions de gestion.

1.1.2 Organigramme de l’entreprise

Figure 1: Organigramme de l’entreprise

1.2 Contexte et problématique

Chaque entreprise cherche à améliorer la communication avec ses clients pour capter leur attention, assurer leur loyauté et améliorer l’efficacité de leurs compagnes de marketing. Dans ce contexte, la plateforme CloudCaastor a comme objectif la satisfaction des besoins des entreprises privées ou publiques de toute industrie (télécommunication, administration, institutions financières …) qui ont besoin de mettre en place leurs propres services mobiles ou d’effectuer des campagnes de communication et d’information en proposant des services interactifs à Valeur Ajoutée(VAS) qui garantit l’acheminement des appels ,des messages et des compagnes à leur destination d’une façon simple et sécurisée.

1.3 Etude de l’existant

1.3.1 Exemples des plateformes existants

On trouve plusieurs entreprises offrant des services de messagerie A2P dont les plus connus sont :

1-Nexmo :

Nexmo est une startup française crée en 2011, qui fournit une plateforme cloud et des API permettant aux entreprises et développeurs d’intégrer des outils de communications sécurisés dans leurs services et applications. Les API de Nexmo permettent d’acheminer et recevoir facilement des SMS ou encore effectuer, gérer et acheminer des appels téléphoniques partout dans le monde.

2- CLX Communications :

CLX Communications (CLX) est une Campanie suédoise crée en 2008.Elle présente un fournisseur mondial de premier plan de services et de solutions de communication basés sur le cloud pour les entreprises et les opérateurs mobiles. Les services de communication mobile de CLX permettent aux entreprises de communiquer rapidement, de manière sécurisée avec les clients et les appareils connectés – Internet of Things (IoT). Les solutions de CLX permettent des communications critiques à l’échelle mondiale via les services de messagerie mobile (SMS), les services vocaux et les services de connectivité mobile pour l’IoT.

3 -Multimedia and Messaging Platform

Supranetcom fournit une plateforme logicielle multicanal MMP (Multimedia and Messaging Platform) qui permet un déploiement rapide et efficace de campagnes de SMS, MMS, VOIX en créant des services interactifs et en fournissant des API télécom des connecteurs SMPP, SMTP, HTTP/S et SOAP.

Cette plateforme de messagerie a une grande capacité à se connecter à plusieurs opérateurs simultanément à travers plusieurs canaux, y compris SMS / MMS, USSD sur IVR sur les réseaux fixes, mobiles et voix sur IP. Elle répond aux besoins du marché des services VAS, avec la possibilité de livrer jusqu’à un milliard de SMS et des millions de messages multimédias par mois et héberger des services de paiement pour plusieurs banques.

Elle peut être utilisé aussi par des grands fournisseurs de services avec des meilleures performances en adoptant une structure hiérarchique à plusieurs niveaux de comptes revendeurs et comptes Distributeurs.

Figure 2: Utilisation de la plate-forme MMP

Figure 3: Structure hiérarchique de MMP

1.3.1 Critique de l’existant

Nexmo est une plateforme qui fournit seulement les API de messagerie elle ne fournit pas des services finis. Elle est destinée principalement aux développeurs.

La plateforme de clx communication diffère à la plateforme de MMP par les services fournis aux clients en effet ses principaux produits sont : les SMS, les appels audios, les Appels vidéo, la messagerie par RCS (Services de communication riche) et la messagerie personnelle. MMP fournit principalement les SMS instants, les appels instants, les TTS instants el les campagnes des SMS et de voix.

MMP est une plate-forme très puissante qui présente plusieurs fonctionnalités et caractéristiques mais elle est profondément technique et manque la simplicité et convivialité à l’utilisation. Elle est destinée principalement aux développeurs et techniciens.

1.3.2 Proposition de solution

Afin d’éviter les limites de MMP, Nous proposons la construction d’un système caractérisé par la simplicité d’utilisation « CloudCaastor » qui est une surcouche à MMP afin d’offrir les différents services de manière plus conviviale. Il inclura une interface de « Selfcare » permettant également l’accès aux différentes fonctions fournit par la plateforme.

CloudCaastor a été déjà développé auparavant mais la version existante manque d’ergonomie et de maintenabilité, Il fournit aux utilisateurs uniquement chargement de balance, modifier les données de profil et l’affichage de l’historique des transactions, l’historique d’activités et les table des prix. C’est pour cela la solution proposée pour le développement de CloudCaastor doit corriger les déficits de la version précédente.

L’application proposée est divisée en deux modules : un premier dédié au Front-End et un second pour le Back-end.

Front-Office

Une application web qui sera accessible par tous les clients qui sont déjà enregistrés et ayant l’un des compte (Business, distributeur ou Revendeur), en effet lorsque l’on parle de « Front-End », il s’agit des éléments du site que l’on voit à l’écran et avec lesquels on peut interagir.

Back-Office

Pour cela, nous avons prévu une plateforme web pour administrer l’application qui assure la gestion de l’application et de la base des données. En effet, le Back-Office, c’est la partie invisible pour les utilisateurs mais représente une grande partie du développement d’un projet web. Sans elle, le site web reste une coquille vide.

Pour une architecture modèle Vue Contrôleur (MVC), la vue présente la partie front-office (interface utilisateur) alors que le modèle et le contrôleur présentent la partie back-office.

Figure 4 : Structure de projet

1.2.3 Méthodologie adoptée

Comme tout projet informatique, il est primordial de déterminer les spécifications fonctionnelles du projet et de cerner les besoins du client.

Afin de répondre au mieux à ces objectifs nous avons adopté la méthodologie cascade pour la conception et le développement de notre solution.

C’est un type de méthode très utilisé aujourd’hui dans tous les domaines nécessitant la conception avant de produire quelque chose. Pour parvenir à un produit fini, nous passons par plusieurs phases du cadrage du projet jusqu’à la livraison finale.

Le projet à réaliser doit donc être découpé en différents phase qui ont un début et une fin bien établis. Ce type de processus est un processus séquentiel et chaque phase doit être donc complétée avant de passer à la suivante

Justification du choix

On a choisi le cycle de développement en cascade car le projet nécessite des étapes séquentielles. Dans un premier temps, nous allons faire l’état de l’art pour déterminer les besoins théoriquement en s’appuyant sur les exemples existants. Nous allons ensuite déterminer la maquette du projet et la conception des différents fonctionnalités attendues du CloudCaastor.

Dans une troisième étape, nous allons faire le développement de front-office et back-office du CloudCaastor et évaluation de la performance.

Cette méthode présente des nombreux avantages, notamment elle permet de bien s’entendre sur les attendus du système et elle est très facile à expliciter à un groupe de travail. Enfin, elle permet d’éviter les dérives en termes de planning : il est facile de visualiser que si une étape se décale, les suivantes sont impactées.

Figure 5: Développement selon méthodologie en cascade

Plan d’actions

Les différentes étapes pour ce projet sont :

– Évaluation de la plate-forme CloudCaaStor actuelle

– Conception des cas d’usage et des fonctionnalités attendues de CloudCaaStor

– Conception de la structure de base de données et conception des flux

– Développement et de mise en œuvre en plusieurs phases / livrables

– Évaluation de la performance et des tests

Conclusion

Dans ce chapitre, nous avons mis le projet dans son cadre, ensuite, nous avons conceptualisé le travail qui s’inscrit dans la proposition d’une solution pour la construction du système CloudCaastor. Dans le chapitre suivant, nous allons détailler la conception du projet.

Chapitre 2 : Modélisation et conception

Introduction

La phase de modélisation et conception est la première étape du processus de développement adoptée. En effet, elle formalise et détaille ce qui a été ébauché au cours de l’étude préliminaire, et permet de dégager l’étude fonctionnelle du système. Elle permet ainsi d’obtenir une idée sur ce qui réalisera l’application proposée au cours de ce projet de fin d’étude.

Tout au long de ce chapitre, nous commençons par définir les besoins fonctionnels et non fonctionnels de la solution que nous allons proposer et présenter le diagramme général de cas d’utilisation.

1 Analyse des besoins

Cette partie va servir à poser les bases du recueil des besoins du système à réaliser. Pour pouvoir clarifier les besoins des utilisateurs de notre application, nous allons présenter les besoins fonctionnels ainsi que les besoins non fonctionnels.

1.1 Les besoins fonctionnels

Mon projet consiste à développer une application de messagerie qui doit permettre aux utilisateurs authentifiés d’accéder aux différents services. Les besoins fonctionnels et les attentes vis-à-vis notre application varient d’un acteur à un autre. Pour cela, nous avons décrit pour chaque acteur les besoins fonctionnels qui lui sont associés.

Les besoins administrateur

Le rôle de l’administrateur consiste à :

Mettre à jour la base de données : modifier certains enregistrements qui se trouvent dans la base de données du site à travers des interfaces appropriées. Accepter ou refuser les demandes d’inscription

Nettoyer la base de données : supprimer les pages des utilisateurs.

Gérer les prix des différents services.

Les besoins utilisateur

Ce site permet aux utilisateurs de :

S’inscrire au site : saisir le login, le mot de passe et le nom de société, l’adresse, l’email, le pays, choisir le type de son compte, téléphone …

S’authentifier afin de pouvoir accéder au Dashboard.

Editer sa page personnelle : une page qui contient des informations personnelles telles que nom, prénom, email, adresse, téléphone…

Accéder aux différents services : envoyer les SMS, les appels, USSD, lancer des compagnes des SMS ou voix.

Consulter les tables des prix, l’historique des transactions.

Charger la balance pour profiter des services fournis

1.2 Besoins non fonctionnels

Après avoir cité les divers besoins fonctionnels et en résumé de nos entretiens avec les membres responsables du Supranetcom, plusieurs besoins non-fonctionnels de l’application ont été fixés. Les besoins non fonctionnels concernent les contraintes à prendre en considération pour mettre en place une solution adéquate aux attentes des concepteurs.

L’extensibilité : dans le cadre de ce travail, l’application devra être extensible, c’est-à-dire qu’il pourra y avoir une possibilité d’’ajouter ou de modifier de nouvelles fonctionnalités.

La fiabilité : Les interfaces de l’application doivent s’adapter à la taille des différents écrans qui doit être assuré par un thème responsif. La vitesse de chargement des interfaces doit être optimale et fonctionne d’une façon cohérente sans erreur

La sécurité : l’application devra être hautement sécurisée, les informations ne devront pas être accessibles à tout le monde, c’-à-dire que le site web est accessible par un identifiant et un mot de passe attribué à une personne physique.

L’ergonomie : On doit fournir une interface conviviale et ergonomique avec une navigation légère et fluide.

1.3 Conception

Pour faire la description des cas d’utilisation, nous allons faire recours à l’établissement des diagrammes de cas d’utilisation qui représentent les interactions entre le système et les acteurs.

1.3.1 Raffinement des cas d’utilisations de CloudCaastor

La figure 6 illustre le diagramme de cas d’utilisation du système CloudCaastor

Figure 6:Diagramme de cas d’utilisation

Figure 7:Diagramme de cas d’utilisation “Gérer un service”

Description textuelle de cas d’utilisation “s’inscrire”

La tableau 1 présente une description textuelle de l’inscription

Cas d’utilisation S’inscrire

Acteur Le client

Pré condition Le client n’a pas encore un compte

Post condition Le compte est enregistré

Description du scénario Le client accède au site de CloudCaastor, remplit le formulaire d’inscription avec précision si tous les cases sont remplies le compte sera ajouté et enregistré dans la base des données de CloudCaastor et par suite le compte sera créé au niveau de la Platform MMP.

Exception Si une case est vide un message d’erreur est affiché.

Tableau 1: Description textuelle de cas d’utilisation “s’inscrire”

Description textuelle de cas d’utilisation “s’authentifier”

La tableau 2 présente une description textuelle de l’authentification

Cas d’utilisation S’authentifier

Acteur Le client

Pré condition Le client possède un compte

Post condition Le client est identifié

Description du scénario Le client s’authentifie en saisissant son Login et mot de passe, non de société.

On vérifie tout d’abord l’existence de nom de société dans la base des données de CloudCaastor s’il existe on vérifie le login el le mot de passe au niveau de MMP

Exception Si l’un des champs est invalide un message d’erreur sera affiché.

Tableau 2:Description textuelle de cas d’utilisation « Authentification”

Description textuelle de cas d’utilisation “Editer profile”

La tableau 3 présente une description textuelle de l’édition de profile

Cas d’utilisation Editer profile

Acteur Le client

Pré condition Le client est authentifié

Post condition Les informations sont enregistrées.

Description du scénario Le client peut consulter les informations de son compte, il peut aussi modifier ses données et l’enregistrer dans la base des données.

Exception Si une case est vide, un message d’erreur est affiché.

Tableau 3:Description textuelle de cas d’utilisation “Editer profile”

Description textuelle de cas d’utilisation “Recharger Compte”

La tableau 4 : présente une description textuelle de recharge de compte

Cas d’utilisation Recharger Compte

Acteur Le Client

Pré condition Le Client authentifié

Post condition Le montant rechargé doit être ajouté à sa balance.

Description du scénario En accédant à l’interface facturation, le client peut consulter sa balance, recharge son compte en choisissant l’un des méthodes disponibles, par la suite il saisit le montant à recharger et l’information nécessaires pour payer (Email, Adresse, Numéro de carte…) et confirme le paiement. En cas de validation la balance est actualisée et le montant total est affiché.

Exception Si les détails de paiement sont non valides un message d’erreur est affiché.

Tableau 4:Description textuelle de cas d’utilisation “Recharger compte

La tableau 5 : présente une description textuelle de modification de paramètre de compte

Cas d’utilisation Gérer un service

Acteur Le client

Pré condition Le client est authentifié

Post condition Message envoyé, compagne crée

Description du scénario Le client demande l’interface « Services »il choisit l’un des services (envoyer sms, envoyer TTS messages, envoyer des appels, créer des compagnes) puis saisit les informations nécessaires (les numéros de destination, type de message, contenu du message, nom de compagne…).

Exception Tous les cases doivent être remplies.

Tableau 5:Description textuelle de cas d’utilisation “Gérer un service

Description textuelle de cas d’utilisation “Consulter les tables tarifs”

La tableau 6 : présente une description textuelle de voir les tables des tarifs

Cas d’utilisation Consulter les tables de tarifs

Acteur Client

Pré condition Le client est authentifié

Post condition Les tables sont affichées

Description du scénario En accédant à l’interface « prix » les table prix SMS, prix voix et prix USSD s’affichent. Ces tables possèdent les prix unitaires de chaque service en fonction de pays et l’opérateur télécom.

Exception Un message d’erreur est affiché s’il y a un problème de chargement des informations.

Tableau 6:Description textuelle de cas d’utilisation “Consulter les tables des tarifs

Description textuelle de cas d’utilisation “Consulter les rapports d’activités “

La tableau 7 présente une description textuelle de voir les rapports d’activités

Cas d’utilisation Consulter les rapports d’activités

Acteur Client

Pré condition Le client est authentifié

Post condition La table de l’historique de paiement et les statistiques de volume de trafic s’affiche.

Description du scénario En demandant l’interface « Activité », le client peut consulter les détails des messages entrants, sortants et compagnes.

Exception Un message d’erreur est affiché s’il y a un problème de chargement des informations.

Tableau 7:Description textuelle de cas d’utilisation “Consulter les rapports d’activités

Description textuelle de cas d’utilisation “Consulter les rapports d’activités”

1.3.2 Diagrammes de séquences

A travers ces diagrammes, on décrit le scénario du certain cas d’utilisation

1.3.2.1 Diagramme de séquences « Inscription »

A partir de ce diagramme, on décrit le cas d’utilisation « Inscription »

Dans un premier lieu, le client accède à la page d’inscription, il entre son email et choisit le type de compte souhaité. Après avoir vérifié la validité d’email, le client sera redirigé vers un autre formulaire d’inscription où il peut saisir tous ses informations personnelles. Par suite le client sera enregistré dans la base des données et après l’appel des web services, le nouveau compte sera créé au niveau de MMP.

Par conséquent, le client reçoit les données d’authentification par email afin d’accéder à son Dashboard.

1.3.2.2 Diagramme de séquence de « Authentification »

Afin de pouvoir bénéficier de tous les fonctionnalités de CloudCaastor, il est impératif de s’authentifier. Le client saisit son login, mot de passe et le nom de société dans la page d’authentification. Si toutes les données sont valides, il sera redirigé vers son tableau de bord sinon un message d’erreur sera affiché.

Figure 8 : Diagramme de séquence d’authentification

1.3.2.3 Diagramme de séquence de Création d’une campagne de SMS

Le client étant authentifié, il peut créer une campagne de SMS en accédant à la page des campagnes puis il remplit tous les détails demandés. Par suite, la création d’une nouvelle campagne est assurée par l’appel des web services : « createSMSCampaign » et « setSMSCampaignDetails »

Figure 9 : Diagramme de séquence de création d’une campagne

1.3.2.4 Diagramme de séquence d’envoi d’un SMS

Etant authentifié, le client accède à la page « Instant SMS » un formulaire sera affiché. Pour envoyer SMS, le client doit remplir toutes les cases (destinataire, expéditeur, date, message). Le web service appelé est « sendSMS »

Figure 10:Diagramme de séquence d’envoi SMS instantané

1.3.2.5 Diagramme de séquence de chargement de balance

Pour charger son compte, le client doit remplir le formulaire de paiement qui se trouve dans la page « Paiement et facturation ». Si l’opération de paiement s’exécute avec succès la balance doit s’incrémenter.

Figure 11 : Diagramme de séquence de chargement de balance

1.3.3 Diagramme de classe

Figure 12:Diagramme de classe de CloudCaastor

Conclusion

La phase de conception qui fait l’objet du présent chapitre est nécessaire à l’implémentation de la solution. En effet, elle énonce et détaille minutieusement la solution ce qui facilitera par la suite la réalisation du travail.

Le chapitre suivant traitera, donc, la réalisation du projet et d’où nous aborderons les choix technologiques et les techniques mises en œuvre pour aboutir à un produit fini.

Chapitre 3 : Réalisation

Introduction

Après avoir conçu la solution, nous allons passer pour la réalisation. Cela revient à implémenter la conception déjà faite avec les technologies et les techniques appropriées aux besoins.

Nous commencerons par évoquer les ressources matérielles et logicielles disponibles pour la réalisation du projet, ensuite nous abordons la solution en exposant les différents écrans proposés.

1 Environnement de développement

Dans cette partie nous présentons l’environnement grâce auquel nous avons pu implémenter notre solution. Cet environnement se divise en un ensemble de ressources matérielles et logicielles aboutissant au travail effectué lors de ce projet de fin d’études.

1.1 Ressources matérielles

La principale ressource matérielle est un ordinateur ASUS K55L possédant les caractéristiques techniques suivantes :

• Processeur : Intel® Core i5-5200U CPU 2.7 GHZ
• 8 GO RAM
• Carte graphique nvidia 2 GB
• Système 64 bits
• Système d’exploitation : Windows 10

1.2 Ressources logicielles

Nous allons désormais étudier les ressources logicielles qui constituent un rôle essentiel dans la phase de développement de notre application. En effet, nous avons eu recours lors de cette étape à différents outils et technologies qui nous ont permis de gagner en productivité et de livrer une solution de qualité.

1.2.1 Langage PHP : HyperText Preprocessor

PHP est un langage informatique, utilisé principalement pour la création des sites web dynamique. Le PHP gère très bien les requêtes SQL. Ce qui est important pour manipuler les

Résultats de requêtes SQL et permettant la connexion à des bases des données telles que MySQL. Le PHP est un des langages coté serveur le plus utilisé puisqu’il a la particularité d’être exécuté directement sur le serveur qui héberge les pages et non pas sur la machine des utilisateurs.

Figure 13: Mode de fonctionnement de PHP

1.2.2 MVC : Model-Vue-Contrôleur

Le MVC est un concept d’architecture logicielle qui permet d’avoir un code plus maintenable, plus évolutif et plus structuré permettant de profiter de plusieurs mécanismes et avoir la persistance des données.

• Un modèle (Model) contenant les données qu’on veut afficher
• Une vue (View) contenant une présentation de l’interface graphique.
• Un contrôleur (Controller) contenant la logique qui concerne les actions effectuées par l’utilisateur.

Figure 14: Mode de fonctionnement du MVC

1.2.3 Symfony 3

Symfony présente un ensemble des composants PHP, développé par la société française SensioLabs. Il fournit des fonctionnalités adaptables et modulables qui sert à faciliter et accélérer le développement d’un site web en effet chaque projet est découpé en modules(bundles).

Symfony est ainsi un Framework MVC (Modèles Vues Contrôleurs) qui sépare l’interface utilisateur d’une application à partir de sa logique métier. Il le fait en superposant l’architecture de l’application en trois parties : Modèle, Vue et Contrôleur.

Le Framework Symfony facilite la persistance des objets en bases des données avec un ORM (mapping objet-relationnel) tel que Doctrine. Ainsi, il permet de gagner du temps à la disposition des modules, il permet donc d’obtenir un code évolutif et maintenable.

Symfony est aussi très sécurisé puisqu’il intègre des mesures préventives qui lutte contre les attaques et les injections SQL.

L’utilisation du Framework Symfony est caractérisée par la flexibilité puisqu’il est possible d’utiliser que certains composants. Il fournit aussi la possibilité de gérer le multilingue facilement.

Figure 15:Le logo Symfony 3

1.2.4 Doctrine

Doctrine est un Object-Relational-Mapping (ORM) composé d’énormes fonctionnalités tels que les requêtes SQL et les requêtes DQL (Doctrine Query Language) qui permet de créer et exécuter les requêtes via le paradigme de la programmation orienté objet.

Figure 16: Le logo Doctrine

1.2.5 Twig

Twig est un moteur de Template directement intégré dans Symfony3. Il permet de gérer l’héritage entre templates et layout, séparer les couches de présentation et couches des mètiers

Figure 17:Le logo Twig

1.2.6 MySQL

L’association PHP/MySQL est de plus en plus utilisée ces dernières années. C’est pourquoi nous avons choisi le serveur de base de données MySQL qui offre de grandes performances en flexibilité et montée en charge. Il intègre de nombreuses fonctionnalités et assure une bonne sécurité des données.

1.2.7 Les Services web

Les services web est un mécanisme de communication entre des applications distantes à traves le réseau internet indépendant de tout langage de programmation.

Il utilise le protocole HTTP comme un moyen de transport et emploie une syntaxe basée sur la notation XML.

Le fonctionnement des services web repose sur un modèle en couches. Les principales couches sont :

• Invocation vise à décrire la structure des messages échangés par les applications.
• Découverte permet la recherche et la localisation d’un service web particulier dans un annuaire de services
• Description vise à décrire les interfaces (paramètres des fonctions, types de données) des services web.

Figure 18:Mode de fonctionnement des Services Web

1.2.8 WampServer

Pour traiter les données de l’application, il était nécessaire de choisir un système de gestion de base de données qui doit être facile, performant et sécuritaire, tel que le WampServer. C’est une plateforme de développement Web de type WAMP, permettant de faire fonctionner localement (sans se connecter à un serveur externe) des scripts PHP. WampServer est un environnement qui contient deux serveurs (Apache et MySQL), un interpréteur de script (PHP), ainsi que phpMyAdmin pour l’administration Web des bases MySQL.

Figure 19:Le Logo de serveur Wamp

1.2.9 Composer

Le composer présente un gestionnaire de dépendance permettant de définir les différentes dépendances de projet. A partir d’un ensemble des commandes prédéfinis, le composer assure la création des entités et des formes , la mise à jour de base de données, la gestion des versions et modification de configuration .

2 Interfaces graphiques de l’application

2.1 Interface d’enregistrement

En premier lieu, Le client doit enregistrer dans la plateforme CloudCaastor, il accède à la page d’enregistrement ou il peut saisir son mail et choisir le type de son compte. Son email sera vérifié s’il n’existe pas déjà dans la base des données, le client sera redirigé vers une autre interface ou il peut saisir ses détails (nom, prénom, adresse, téléphone, ville, pays, code postal…). Ainsi le client sera ajouté à la base des données local.

Pour qu’il soit enregistré dans la plateforme MMP, on doit appeler les web services suivants :

« createsubaccount »

« SetSubAccountDetails »

« createRateTable »

« listBalances »

« creditBalance »

Après avoir être enregistré dans MMP, le client doit recevoir son login et mot de passe par email pour pouvoir s’authentifier.

Les figures suivantes illustrent les interfaces d’enregistrement.

Figure 20: Interface d’enregistrement

Figure 21:Deuxième interface d’enregistrement

2.2 Interface d’authentification

Pour accéder aux services offerts par CloudCaastor, le client doit s’authentifier avant de pouvoir bénéficier des fonctionnalités qui lui sont offertes. Le web service utilisé pour vérifier les données du client est « checkUserCredentials ». En cas les données sont incorrectes, un message d’erreur sera affiché. L’interface d’authentification est décrite dans la figure suivante :

Figure 22:Interface d’authentification

2.3 Tableau de bord

Une fois authentifié, la première page affichée est le tableau de bord, dans cette interface le client trouve un raccourci pour charger son compte. Cette interface doit afficher les tableaux résumant les dernières transactions, les dernières alertes, les dernières mises à jour des prix, des statistiques qui résument le Traffic des SMS, USSD, voix…

Figure 23:Interface du tableau de bord

2.4 Interfaces des prix

Le client peut consulter les prix de tous les services à partir les interfaces décrites dans les figures suivantes :

Figure 24:interfaces des prix SMS

Figure 25:Interfaces des prix des appels vocaux

Figure 26:Interface des prix USSD

2.5 Interface de profile

Le client a son propre profile qui contient ses informations, Il est possible de les éditer à partir de cette interface comme il est montré dans la figure suivante :

Figure 27:Interface éditer profile

2.6 Interface de Instant SMS

Le client peut envoyer des SMS en entrant les données nécessaires (expéditeur, destinateur, date, message). L’envoi des SMS est assuré par l’appel de web service suivant :

« SendSMS »

Figure 28:Interface d’envoi SMS

2.7 Interface de Instant appels

Le client peut envoyer des appels en entrant les données nécessaires (expéditeur, destinateur, date, message). L’envoi des appels est assuré par l’appel de web service suivant :

« SendVoice »

Figure 29:interface des instants appels

2.8 Interface de Instant TTS (Transfer to speech)

Le client peut envoyer des instants TTS en entrant les données nécessaires (expéditeur, destinateur, date, message). L’envoi des TTS est assuré par l’appel de web service suivant :

« SendTTS »

Figure 30:Interface des instants TTS

2.9 Interfaces des campagnes

Figure 31:Interface des instants TTS

Nous trouvons dans cette interface la liste des campagnes en cours, le client peut supprimer ou modifier une campagne, on trouve aussi un bouton « ajouter » qui fait la redirection vers une autre interface à partir du quelle le client peut créer une nouvelle campagne en entrant les données nécessaires (nom de campagne, expéditeur, destinataire, date de début, date de fin, statuts, type message.

Figure 32:Interface d’ajout d’une campagne

2.10 Interface chargement de balance

Figure 33:Interface de chargement de balance

Cette interface contient un tableau qui résume les dernières transactions effectuées, nous trouvons le montant actuel et un bouton qui fait une redirection à la page de paiement ou le client peut saisir toutes les informations de paiement (numéro de la carte, la date, montant, code de vérification …)

Figure 34:Interface de chargement de balance

2.11 Interfaces des Rapports

Le client peut consulter son historique de paiement, les traces de web et les rapports des activités comme il est illustré dans les figures suivantes :

Figure 35:Interface des rapports des activités

Figure 36:Interface d’historique de paiement

Figure 37:Interface des traces de web

2.12 Interfaces de suivi d’activité

A partir de cette interface, le client peut consulter toutes ses activités (messages entrants, messages sortants, les compagnes en cours et les compagnes planifiés) comme illustré dans les figures suivantes

Figure 38:Interface détaillant les messages sortants

Figure 39:Interface détaillant les messages entrants

Figure 40:Interface détaillant les campagnes planifiées

Figure 41:Interface détaillant les campagnes en cours

2.15 Documentation and API

Le client peut accéder à la documentation fournie par la plateforme MMP en accédant à la page « Documentation and API ».

3 Test et performance

On peut déterminer la performance d’un site web à partir de temps de chargement des pages en effet, elle devrait être la plus courte possible.

Le Framework Symfony dispose deux types de cache au niveau de client et au niveau de serveur ce qui accélère le chargement des données.

Notre application est basée sur les web services, pour tester les API fourni par MMP, nous avons utilisé le logiciel Postman, nous pouvons aussi observer les résultats au niveau la plateforme MMP.

Conclusion

Au cours de ce chapitre, nous avons décrit l’environnement matériel et logiciel du projet. Nous avons a ensuite présenté les interfaces les plus significatives de l’application

Conclusion générale

Tout le long de ce rapport, nous avons présenté le travail effectué au sein de l’entreprise Supranetcom dans le cadre de projet de fin d’études qui consiste à développer un système convivial « CloudCaastor » qui a pour objectif de permettre aux utilisateurs de profiter des services offerts par la plateforme de messagerie MMP.

En premier lieu, nous avons présenté le cadre général du projet et l’organisme d’accueil. En deuxième lieu, nous avons effectué une étude sur la plateforme actuelle MMP, découvrir les plateformes concurrentes dans le marché de messagerie A2P afin de déterminer les diverses fonctionnalités de CloudCaastor. En troisième lieu, nous avons présenté une étude de spécification des besoins du projet et une analyse des fonctionnalités du système. Enfin, nous avons étudié la conception du système et nous avons consacré le dernier chapitre pour la réalisation et l’implémentation de l’application.

Durant la période du stage, ce travail nous a permis de mieux s’intégrer au sein de l’entreprise, nous a offert une grande opportunité d’enrichir nos connaissances et apprendre de travailler avec un nouveau Framework « Symfony » et améliorer nos connaissances au niveau de conception.

Ce projet a exigé un effort aussi bien au niveau de l’étude théorique qu’au niveau de la conception pour aboutir finalement à une solution ergonomique, flexible et répondant au besoin de l’entreprise.

Netographie

[1] http://www.supranetcom.com/product-and-services/caastor/

[2] http://supranetcom.com/wp-content/uploads/2011/01/MMP_ProductBrief_r1.0.pdf

[3] https://thehub.smsglobal.com/a2p-sms-market

[4] https://www.telesign.com/blog/post/current-trends-in-application-to-person-a2p-messaging/

[5] https://symfony.com/what-is-symfony

[6] https://www.novaway.fr/notre-expertise/symfony

[7] https://fr.wikipedia.org/wiki/Composer_(logiciel)

[8] https://www.commentcamarche.com/contents/1244-web-services