Remerciements

Je tiens à remercier la société Alciip de m'avoir donné la possibilité de faire cette

licence professionnelle et plus particulièrement Mr Pierre André Pochon et Mr Cyril Laurent
pour l’accueil qu'ils m'ont réservé, leur soutien tout au long de cette année et les bonnes
conditions de travail.

Pour leur collaboration dans ce travail, je souhaite remercier plus particulièrement :

- Céline Rachwal pour avoir pris le temps de m’expliquer le travail que l’on attendait
de moi et pour les propositions d’améliorations qu’elle m'a conseillées.

- Manuel Defferan pour ses conseils concernant l’analyse technique de l’application

et son avis sur les choix que j’ai adoptés ainsi que pour son aide dans ma démarche.

Enfin, je souhaite remercier tous les collaborateurs de la société pour leur

disponibilité, leurs conseils et l'excellente ambiance de travail.

2
 Sommaire

Remerciements............................................................................................................................2

Sommaire....................................................................................................................................3

Introduction.................................................................................................................................5
Présentation d’ALCiiP........................................................................................................5
Présentation des services.....................................................................................................7
Présentation du projet.........................................................................................................7

1 Post documentation de l’application........................................................................................7

1.1 Présentation de l’application.............................................................................................7
1.1.1 Utilisateurs.................................................................................................................7
1.1.2 Accès à l’application..................................................................................................8
1.1.3 Précisions concernant l’application...........................................................................8
1.2 Diagramme de cas d’utilisation.........................................................................................8
1.3 Présentation des fonctionnalités des clients....................................................................10
1.3.1 Projets.......................................................................................................................10
1.3.2 Demandes.................................................................................................................11
1.3.3 Webmastering...........................................................................................................11
1.3.4 Informations personnelles........................................................................................12
1.3.5 Options supplémentaires..........................................................................................12
1.4 Présentations des fonctionnalités des employés de l’entreprise......................................12
1.4.1 Accueil.....................................................................................................................12
1.4.2 Clients......................................................................................................................12
1.4.3 Projets.......................................................................................................................14
1.4.4 Tickets......................................................................................................................15
1.4.5 Prestations d’hébergement.......................................................................................16
1.4.6 Ressources humaines...............................................................................................17
1.4.7 Contacts....................................................................................................................17
1.4.8 Prestations de webmastering....................................................................................17
1.4.9 Newsletter................................................................................................................18
1.4.10 Options supplémentaires........................................................................................18
2 Analyse technique et problèmes associés..............................................................................19
2.1 Analyse de la base de données........................................................................................19
2.1.1 Modèle Conceptuel de données...............................................................................19

3
 2.1.2 Problèmes associés...................................................................................................21
2.2 Analyse des classes.........................................................................................................21
2.2.1 Diagramme de classe...............................................................................................21
2.2.2 Problèmes associés...................................................................................................23
2.3 Analyse de la hiérarchie des fichiers...............................................................................23
2.3.1 Diagramme de présentation.....................................................................................23
2.3.2 Problèmes rencontrés...............................................................................................25
2.4 Analyse de la sécurité......................................................................................................25
2.4.1 Présentation de l’accès à l’administration................................................................25
2.4.2 Présentation des problèmes de sécurité....................................................................25
3 Présentation des améliorations fournies.................................................................................26
3.1 Amélioration de la base de données................................................................................26
3.1.1 Séparation de la base de données.............................................................................26
3.1.2 Nomenclature appliquée..........................................................................................27
3.2 Amélioration des classes.................................................................................................28
3.2.1 Nomenclature des classes, des attributs et des méthodes.........................................28
3.2.2 Modification des méthodes......................................................................................28
3.2.3 Documentation des classes.......................................................................................29
3.3 Modification des fichiers................................................................................................30
3.3.1 Présentation de la hiérarchie appliquée....................................................................30
3.4 Amélioration de la sécurité de l’application...................................................................31
3.4.1 Variables passées en POST......................................................................................31
3.4.2 Sécurisation des données.........................................................................................32
3.4.3 Accès à l’application................................................................................................32
3.4.4 Interdiction d’accès..................................................................................................32
3.5 Autres améliorations.......................................................................................................32
3.5.1 Utilisation d’Ajax.....................................................................................................32
3.5.2 Utilisation d’une classe gérant les messages d’alerte..............................................33
3.5.3 Génération d’un mot de passe pour les administrateurs..........................................33
3.5.4 Amélioration du code...............................................................................................34

Conclusion................................................................................................................................35

Bibliographie.............................................................................................................................36

Glossaire...................................................................................................................................37

Table des annexes.....................................................................................................................38

Annexes.....................................................................................................................................39

Résumé......................................................................................................................................57

Introduction

Depuis la fin des années 1990, et la naissance de l’Internet que nous connaissons de
nos jours, les entreprises ont commencé à comprendre les enjeux qu’elles pouvaient tirer de

4
cette technologie. Présenter les services qu’elle propose à ses clients, communiquer, attirer
l’attention et surtout pouvoir développer de nouvelles activités sont quelques uns des
nombreux avantages qu’elles peuvent en tirer.

De nos jours, les moteurs de recherche permettent également de mieux cerner les
internautes et de connaître au mieux ce que ceux-ci recherchent. De plus, face à la
concurrence de plus en plus grande qu’elles peuvent rencontrer, arriver à se faire connaître et
devancer les autres entreprises travaillant dans le même secteur d’activité n’est pas chose
facile. Ainsi, nombreuses sont celles qui font appel à des professionnels pour réaliser des
solutions performantes leur permettant de gagner des parts de marché.

L’entreprise ALCiiP est une société de conception de solutions Internet permettant de

répondre à ces nouveaux besoins. Son objectif est de réaliser des sites Web performants,
innovants, de mettre en contact le plus rapidement possible le client et l’internaute et de
positionner au mieux les sites Web sur les moteurs de recherche dans le but de devancer la
concurrence. Elle conseille également ses clients en leur proposant des améliorations et en
leur expliquant au mieux comment faire pour avoir une solution la plus performante possible.

Dans le but d’être plus performante, l’entreprise a développé plusieurs outils

permettant de traiter les demandes de ses clients. L’un d’eux est une plateforme
centralisée* : elle permet aux clients de gérer le contenu de leur site Web, d’accéder à
diverses statistiques (nombres de personnes accédant au site par jour, moyenne sur plusieurs
mois, page d’entrée …), de gérer et de répondre rapidement aux demandes effectuées par les
internautes par le biais de formulaires ou encore d’envoyer des newsletters* aux personnes
qui ont demandé de la recevoir.

L’outil étudié lors de ce projet est un CRM* (Customer Relationship Management),

que l’on peut traduire littéralement par gestionnaire de la relation client. Il s’agit d’un
extranet permettant aux clients d’effectuer des demandes ou de voir l’avancement d’un travail
sur leurs sites, et aux employés de l’entreprise de gérer entre autre ces demandes. L’outil est
déjà en place et fonctionnel dans l’entreprise depuis plusieurs années.

L’objectif de ce projet est de réaliser l’analyse fonctionnelle et technique de

l’application, qui n’a pas été faite lors de son développement, et de participer à son
amélioration, soit en repartant de la structure existante, soit en reprenant la structure à zéro.
Le choix entre refonte ou reprise sera effectué en fonction de l’analyse technique. Le but est
d’obtenir une application « propre », c'est-à-dire mieux structurée et plus facile à reprendre en
main pour les prochaines personnes qui travailleront dessus.

• Présentation d’ALCiiP

Créée en 2002 par M. Pierre André Pochon et M. Cyril Laurent, l’entreprise ALCiiP est
une Société de Services Informatiques. Elle a quatre principaux objectifs permettant de
satisfaire au mieux ses clients : le conseil, la réalisation de solutions, le référencement et la
génération de leads*.
Le premier objectif de l’entreprise est donc de conseiller
ses clients. Avant de se lancer dans la réalisation d’une solution,
l’entreprise effectue une étude de marché afin de connaître les
concurrents et le gain potentiel que pourrait faire le client. Par
exemple, si le client souhaite proposer sur son site web des
voyages en Argentine alors que les internautes recherchent plus
fréquemment des voyages en direction du Brésil, l’entreprise ne
se lancera pas dans5 la réalisation de la solution car la demande
n’est pas assez conséquente. Cette analyse est faite sur les mots
clefs* que les internautes entrent sur les moteurs de recherche.
 Le deuxième objectif de l’entreprise est la réalisation de la
solution adaptée au client. Une fois l’étude de marché réalisée et si
celle-ci a été positive, l’entreprise peut donc commencer à réaliser la
solution du client. Dans un premier temps, un designer réalise une
maquette du site en fonction des besoins du client, puis, une fois la
maquette validée, les développeurs et les intégrateurs s’occupent de
la réalisation du site web.
Le troisième objectif concerne tout ce qui touche au
référencement. Afin d’être positionnée le mieux possible sur les
différents moteurs de recherche (Google, yahoo, …), l’entreprise
s’engage à réaliser les contenus de la solution et à la placer la
mieux possible selon les mots clefs définis par le client. Ce
référencement naturel, qui peut nécessiter plusieurs mois avant
d’être visible, peut être complété par un référencement
commercial (correspondant à l’achat de mots-clefs).

Le dernier objectif est de rentabiliser au mieux le site web du

client. Ceci est possible en tentant de mettre le plus rapidement
possible en contact le client et l’acheteur potentiel qui effectue une
demande sur le site web de ce dernier. Plus la réponse du client sera
rapide, plus il aura de chance de convertir l’acheteur potentiel en
acheteur.

L’entreprise est en plein développement. En septembre 2007, elle était implantée à

Chambéry, qui était le siège social, à Miami et à Londres. Depuis janvier 2008, elle est
implantée à Paris, qui est devenu le nouveau siège social, à Chambéry, à Miami, à Londres, à
Genève, à Dubaï (Emirat Arabes Unis) et à Chennaï (Indes) (cf. annexe 1).

Cette internationalise se confirme avec le lancement

de « leadformance », qui est une marque de l’entreprise. Le
produit que celle-ci souhaite réaliser sera commercialisé
sous ce nom.

Durant cette année, l’entreprise a également beaucoup évolué au niveau de ses

employés. Le nombre maximum de personnes travaillant simultanément sur le site de
Chambéry a été d’une vingtaine d’employés au début de l’année 2008. En août 2008, le site
de Chambéry possède quatre commerciaux, un chef de projet, une rédactrice / référenceuse,
un graphiste, un développeur, un développeur / intégrateur, un administrateur réseau, un
administrateur réseau en alternance, un secrétaire et un développeur en alternance. Certains
employés sont allés travailler en Inde, d’autres sont partis à Paris.

• Présentations des services

6
 Sur le site de Chambéry, l’entreprise est divisée en 6 principaux services :

- Produit
- Services
- Portails
- Sales
- Administratif

Dans le cadre de ce projet, j’ai intégré la partie Services de l’entreprise qui est
composée de : une chef de projet, un développeur / intégrateur, une rédactrice / référenceuse
et un graphiste.

• Présentation du projet

Le principal objectif de ce stage est de documenter et d’améliorer le CRM existant.

Cette mission se décompose en trois principales phases :
- la post documentation de l’intranet (de mi- mai à mi-juin) ;
- la réflexion sur l’amélioration à apporter à l’intranet (de mi-juin à fin juin) ;
- l’amélioration de l’intranet (de fin juin à fin septembre) ;

La première phase a pour objectif de me familiariser avec l’ensemble des

fonctionnalités du CRM, de réaliser une présentation simple et efficace de l’application et de
commencer à répertorier les problèmes et les améliorations possibles de l’application.

La deuxième phase consiste à analyser s’il est préférable de partir de la structure de

l’intranet existant et de l’améliorer, ou si les bases sont trop fragiles et qu’il vaut mieux tout
reprendre depuis le début.

Enfin, la troisième phase consistera à apporter des solutions aux problèmes

techniques rencontrés lors de la phase d’analyse de l’application en proposant des
améliorations.

Dans le même temps, ma principale fonction en entreprise depuis le début du mois de

septembre 2007 consiste à réaliser les différents développements que souhaitent effectuer les
clients sur leur site Internet (cf. annexe 2).

1 Post documentation de l’application

1.1 Présentation de l’application
1.1.1 Utilisateurs

En s’identifiant à l’application, l’utilisateur accède à certains droits qui varient en

fonction de son type. Il existe deux principaux types d’utilisateurs : les clients, qui ont

7
principalement accès à tout ce qui concerne leur propre site Web et qui peuvent effectuer des
demandes de modification à ALCiiP, et les employés, qui ont accès à tous les projets des
clients et qui peuvent répondre à leurs besoins en leur proposant des offres de maintenance.
Les employés (ou administrateurs) ont également la possibilité de modifier toutes les
informations qui concernent les clients.

Les employés de la société n’ont cependant pas tous les mêmes droits, certaines
parties de l’application étant réservées aux administrateurs spécialisés dans un domaine.
Quatre principaux domaines sont différenciés : les administrateurs des sites web, les
administrateurs des mots clef servant au référencement sur les moteurs de recherche des sites,
les administrateurs des comptes mails des clients et enfin les administrateurs des
hébergements des sites. Certains des employés n’ont accès à aucune de ces parties de
l’application, d’autres peuvent avoir l’accès à une, plusieurs ou toutes les zones de
l’application en fonction des droits qui leurs sont attribués.

1.1.2 Accès à l’application

C’est lors de l’accès à l’application que l’utilisateur est reconnu en tant que client ou
en tant qu’administrateur. Les clients peuvent y accéder par deux moyens : soit en se rendant
sur le site de la société, www.alciip.com, où une zone d’identification, nommée espace client,
est prévue pour eux, soit en allant directement à l’adresse http://solutions.alciip.com/espace-
client/index.php (cf. annexe 3). L’identification se fait à l’aide d’un nom d’utilisateur unique
et d’un mot de passe. Les administrateurs accèdent à l’application via l’url suivante :
http://solutions.alciip.com/espace-client/admin/ (cf. annexe 4). Ils doivent, tout comme les
clients, entrer leur login et leur mot de passe pour s’identifie.

Si l’utilisateur qui souhaite accéder à l’application entre un login inexistant ou un mot

de passe incorrect, il est averti par un message d’erreur. Sur leur page d’identification, les
clients ont également la possibilité de récupérer leurs identifiants en entrant leur adresse mail
dans la zone prévue à cet effet. Un mail contenant ces informations leur est alors envoyé. Les
administrateurs n’ont pas cette possibilité car leur mot de passe est crypté et n’est donc pas
restituable par l’application.

1.1.3 Précisions concernant l’application

L’application a été développée en php5 (php objet). Elle possède ainsi déjà toutes les
classes permettant de gérer l’ensemble des informations contenu dans sa base de données.
Elle est hébergée sur un serveur interne nommé solutions.alciip.com. Elle utilise une base de
données qui est commune à deux applications : le CRM et administrations.alciip.com,
l’application qui permet la gestion centralisée des sites web des client, nommée espace-client.

1.2 Diagramme de cas d’utilisation

Les différentes actions que peuvent effectuer les clients et les employés d’ALCiiP sont
représentées sur le diagramme de cas d’utilisation ci-dessous :

8
9
 L’application suit un cheminement logique, qui correspond à la création et à la
gestion d’un projet. L’administrateur peut donc créer un nouveau client, créer les contacts qui
lui sont associés, créer un ou plusieurs projets, créer ses hébergements et enfin gérer ses
demandes. On peut résumé ce cheminement par le modèle suivant :
Client  contact  projet  tâche  hébergement  prestation de webmastering 
intervention  ticket.

1.3 Présentation des fonctionnalités des clients

En s’identifiant à l’application, l’utilisateur accède à toutes les informations qui le

concerne : ses projets, ses interventions en cours, ses informations personnelles ainsi qu’à la
possibilité d’effectuer une nouvelle demande auprès de l’entreprise.

1.3.1 Projets

Une fois identifié, le client est redirigé vers une page Web listant l’ensemble de ses
projets (cf. annexe 5). Chaque client possède un ou plusieurs projets. Un projet décrit ce
qu’attend le client de la part d’ALCiiP. Il peut s’agir de création de solutions web, de chartres
graphique, d’ajout de fonctionnalités… Pour chaque projet, l’utilisateur a la possibilité d’en
connaître le nom, la date de début, le nombre d’étapes en attente de validation et les tâches qui
le composent. Le logo du projet est également affiché. En cliquant sur la flèche violette, en
face d’un projet, il accède à la liste de toutes les tâches qui le composent.

10
 Les tâches sont classées en deux catégories : celles qui sont en attente de validation,
c'est-à-dire qui ne sont pas terminées ou qui n’ont pas été validées par le client, et les tâches
qui ont été traitées, ou qui ne nécessitent pas de validation (cf. annexe 6). Pour chaque tâche,
le client peut voir sa date de création et son intitulé. Il a également la possibilité d’afficher sa
description et son image associée en cliquant sur le lien « Plus d’informations ». Si elle n’est
pas encore validée, il a la possibilité de le faire et de laisser un commentaire précisant ce qui
ne va pas s’il ne la valide pas. Si elle est déjà validée, il peut voir quand elle l’a été et par
qui. Une zone de recherche lui permet également de voir rapidement les tâches en attente de
validation, celles qui le sont et celles qui n’ont pas été validées.

1.3.2 Demandes

Depuis le menu de l’application, l’utilisateur a accès à une zone nommée

« demande ». Cette espace lui permet d’effectuer de nouvelles demandes auprès de la société
lorsqu’il en voit l’utilité. En se rendant dans celle-ci, il a la possibilité de voir les différentes
demandes qu’il a déjà effectuées et d’en ajouter. Pour chaque demande, il a accès à son titre,
son état (nouveau, réouvert ou fermé), la personne qui a effectué la demande, la date de
dernière modification et la sous-catégorie à laquelle elle appartient (cf. annexe 7). En cliquant
sur le titre d’une demande, il a également accès à la catégorie et à la priorité de la demande,
ainsi qu’à la possibilité de la commenter en entrant un texte et un fichier joint. En dessous,
l’historique de la demande, avec les différents commentaires postés par le client et les
administrateurs, est affiché et permet de voir son évolution (cf. annexe 8). Une zone de
recherche lui permet également de trouver rapidement une demande. La recherche est
effectuée sur le titre de la demande, son statut, le nom et le prénom du demandeur et la sous-
catégorie à laquelle elle appartient. Il peut également choisir d’afficher 10, 25 ou 100 tickets
par page. Enfin, en cliquant sur le nom d’une colonne, il peut trier les demandes en fonction
de son choix, par ordre alphabétique ou non.

Si l’utilisateur souhaite ajouter une demande, il doit obligatoirement lui donner un titre
et la classer dans une catégorie et une sous-catégorie et lui affecter une priorité (cf. annexe 9).
Il peut également compléter la description de la demande et lui joindre un fichier descriptif. Si
la demande a bien été enregistrée, un mail de confirmation est envoyé au contact et à
l’administrateur responsable de la catégorie. Lorsqu’il choisit une catégorie, la liste des sous-
catégories est automatiquement mise à jour en fonction des données présentes en base et
administrées par les employés.

1.3.3 Webmastering

Depuis le menu de l’application, l’utilisateur a accès à une zone nommée

webmastering. Les prestations de webmastering correspondent aux activités de création et de
maintenance des sites web des clients. En s’y rendant, il a la possibilité de voir les
prestations de webmastering en cours (qui ne sont pas clôturées) ainsi que celles qui sont
archivées. Pour chaque prestation de webmastering, il a la possibilité de voir son nombre
d’heures, sa date de création, son type (prestation comprise ou achat), son temps restant et sa
date de fin de validité. Il a également la possibilité d’afficher l’ensemble des interventions
comprises dans une prestation et de voir leurs détails : nom du site, date de création de la
demande, personne qui a effectué la demande, date de fin de l’intervention et temps que celle-
ci a pris (si elle est terminée), éléments fournis, la description et le commentaire laissé par le
client (cf. annexe 10).

11
 1.3.4 Informations personnelles

L’utilisateur a également accès à une zone lui permettant de modifier ses informations
personnelles (cf. annexe 11). Il peut modifier sa civilité (madame, mademoiselle, monsieur),
son nom, son prénom, sa fonction, son e-mail, son téléphone fixe, son téléphone portable et
son numéro de fax. Il peut également modifier son mot de passe. Seul son nom doit
obligatoirement être complété pour qu’il puisse enregistrer ses modifications.

1.3.5 Options supplémentaires

La dernière option du menu se nomme « déconnexion ». Elle permet à l’utilisateur de

détruire sa session et de revenir sur la page d’identification. Depuis cette page, il a la
possibilité de récupérer son login et son mot de passe en cas d’oubli en entrant son adresse e-
mail. Un e-mail contenant ses informations lui est alors envoyé.

Certains clients, qui ont souscrit à l’option, peuvent avoir accès à une zone nommée
« shop ». Elle leur permet de gérer les commandes qui ont été passées sur leur site web. Après
avoir choisi une de leur boutique, ils ont la possibilité d’annuler une commande, de gérer les
frais de port, de gérer leurs factures et de générer un graphique d’évolution. Cette
fonctionnalité est amenée à disparaître, le shop n’étant plus utilisé par aucun des clients de la
société.

1.4 Présentations des fonctionnalités des employés de l’entreprise

En s’identifiant à l’application en tant que employés, l’administrateur a la possibilité

d’accéder à bien plus d’informations que le client.

Le modèle pour créer, modifier et supprimer les informations concernant les projets,
les tâches, les tickets, les prestations d’hébergement, les ressources humaines, les contacts, les
prestations de webmastering et interventions est le même que celui des clients. Pour éviter les
répétitions, il sera expliqué dans la partie client mais n’apparaîtra pas dans les autres parties.

1.4.1 Accueil

La première page sur laquelle arrive l’administrateur lorsqu’il accède à l’application

est une page d’accueil listant l’ensemble des dernières tâches qui ont été validées par les
clients, de la plus récente à la plus ancienne (cf. annexe 12). Pour chaque tâche, il a la
possibilité de connaître sa date de validation, son intitulé, le projet concerné et son état
(validée ou non validée). En cliquant sur l’intitulé d’une tâche, il accède aux détails de celle-
ci. En cliquant sur le nom du projet, il accède aux détails du projet en question.

1.4.2 Clients

En cliquant sur l’onglet « Clients » du menu, l’administrateur accède à la liste de tous

les clients de l’entreprise présents dans la base de données (cf. annexe 13). La raison sociale

12
de chaque client est affichée, ainsi que deux liens : l’un se nommant « afficher », permettant
d’afficher plus de détails concernant le client, l’autre se nommant « supprimer » permettant de
supprimer le client ainsi que tous les projets qui le concernent. Si l’administrateur souhaite
supprimer un client, un message apparaît à l’écran et lui demande de confirmer son choix afin
d’éviter les erreurs de manipulation. En face de chaque nom de client, un icone est présent.
En cliquant dessus, la liste des différents projets concernant le client s’affiche en dessous de
son nom. Pour chaque projet, il peut connaître son nom, le nombre de tâches en attente de
validation et l’image qui lui est associée. Quatre liens sont également présents et donnent la
possibilité à l’administrateur d’accéder aux détails du projet, de le modifier, de changer son
logo ou de le supprimer. Sur cette page, il a également la possibilité d’accéder à la création
d’un nouveau client en cliquant sur le lien présent à cet effet.

 Affichage des informations d’un client :

En cliquant sur le bouton « afficher », l’administrateur accède aux détails du client. Il peut
voir son nom, le nom et le prénom du contact principal et du contact financier qui lui sont
associés, son type (client ou prospect), son statut, son numéro de Siret, son taux de TVA, son
numéro de RCS, son numéro de téléphone, son numéro de fax, son adresse et son adresse de
facturation si celle-ci est différente (cf. annexe 14). Sur la gauche de son écran, il a accès à
plusieurs liens permettant de gérer les projets du client, de gérer ses sites web, de gérer ses
comptes mails, de gérer ses hébergements, de gérer ses contacts, de modifier ses informations,
de changer son logo, de le supprimer ou de revenir à la liste des clients.

 Création d’un nouveau client :

En cliquant sur le lien « créer un nouveau client », l’utilisateur accède à un formulaire lui
permettant de compléter toutes les informations nécessaires à la création d’un nouveau client
(cf. annexe 15). Les champs devant obligatoirement être complétés sont le nom ou la raison
sociale du nouveau client, son type ainsi que la civilité, le nom, l’identifiant et le mot de passe
du contact principal. Si l’une de ces informations n’est pas complétée, un message d’erreur
s’affichera lorsque l’administrateur cliquera sur le bouton « enregistrer ». Les autres champs
peuvent être complétés mais ne sont pas obligatoires. Ces champs sont : le statut de
l’entreprise, son numéro de Siret, son taux de TVA appliqué, son RCS, son code CIEL, un
texte le décrivant, son adresse principale (avec l’adresse, le code postal, la ville, le pays, le
numéro de téléphone et le fax), son adresse de facturation (avec l’adresse, le code postal, la
ville et le pays), les informations concernant le contact principal qui lui est associé (nom,
prénom, fonction, e-mail, téléphone fixe, téléphone portable, fax, nom d’utilisateur et mot de
passe) et les informations concernant le contact financier (idem que pour le contact principal).
A chaque fois qu’il doit entrer un identifiant ou un mot de passe, il a la possibilité de cliquer
sur un bouton « Générer » qui génère automatiquement une chaîne composée de 6 caractères
aléatoires, comprenant des chiffres de 0 à 9 et des lettres de a à z. En cliquant sur le bouton
enregistrer, si tous les champs obligatoires sont complétés, le client et le contact principal sont
créés, ainsi que le contact financier si ces informations ont été remplies.

 Modifier un client :
La modification d’un client reprend le même principe que sa création. Les mêmes
informations sont demandées. Seul le contact principal et le contact financier diffèrent. En
effet, des listes déroulantes permettent de choisir facilement et rapidement un contact à
associer au projet. Ces listes déroulantes affichent tous les contacts disponibles travaillant
chez le client que l’administrateur souhaite modifier.

 Supprimer un client :

13
L’administrateur a la possibilité de supprimer un client. Lorsqu’il clique sur l’un des liens de
suppression, un message de confirmation lui demande s’il est bien sûr de vouloir supprimer le
client en question. S’il accepte, le client, ainsi que toutes les informations qui le concernent
(projets, documents …) sont supprimées.

 Changer le logo d’un client :

En cliquant sur ce lien, l’utilisateur accède à une page lui permettant de sélectionner une
image qui sera associée au client (cf. annexe 16). En cliquant sur le bouton « parcourir », il
peut rechercher l’image sur son disque dur. Une fois celle-ci récupérée, il clique sur le bouton
« Changer le logo » pour affecter l’image au client. Aucun contrôle n’est effectué sur l’image.
L’utilisateur a donc la possibilité de mettre le fichier qu’il souhaite, qu’il s’agisse ou non
d’une image.

 Gestion des sites d’un client :

Lorsque l’administrateur clique sur le lien « Gestion des sites », l’administrateur accède au
listing des différents sites du client. Pour chaque site, il peut voir le nom de celui-ci. Si
l’administrateur détient les autorisations pour administrer les sites web, il a accès à d’autres
informations, comme l’url du site, ou la possibilité de vérifier si le suivi du positionnement du
site doit être fait, le nombre de mots clés achetés par le client pour ce site ainsi que le nombre
de formulaires qui a été posté par celui-ci. En cliquant sur le nombre de mots clés, il accède à
la liste des mots clés pour lesquels le site est référencé. Il a également la possibilité de
modifier le nom du site, son url et si le positionnement de celui-ci doit être ou non référencé,
de le supprimer ou d’en ajouter un nouveau.

 Gestion des mots clés d’un site web :

En cliquant sur le nombre de mots clés, l’utilisateur arrive sur une page qui liste l’ensemble
des mots clés pour lesquels le site est référencé. S’il a les autorisations pour gérer les mots
clés, il peut voir le positionnement du site en fonction de chaque mot clé sur les différents
moteurs de recherche (Google, Live, Yahoo, Voila, Aol et Lycos). Ces autorisations lui
permettent également d’ajouter un nouveau mot clé, de les modifier ou de les supprimer.

 Gestion des comptes email :

En cliquant sur le lien « gestion des comptes email », l’administrateur se retrouve sur une
page listant les différents comptes email disponibles pour le client qu’il a choisis, ainsi que les
demandes que celui-ci a effectuées et qui n’ont pas encore été validées (cf. annexe 17). Il a la
possibilité d’effectuer une nouvelle demande de compte. Pour cela, il doit compléter plusieurs
informations : l’email souhaité, le nom d’utilisateur et le mot de passe du contact. Il peut
également demander des alias de compte*. Si l’employé a les droits pour gérer les comptes
email, il peut également ajouter directement un nouveau compte, effectuer une demande de
suppression de compte existant ou encore envoyer les accès à un contact. Pour chaque
compte, il peut également voir l’identifiant et le mot de passe associé. Enfin, il peut modifier
un compte ou le supprimer.

1.4.3 Projets

En cliquant sur le lien « Projets » du menu, l’administrateur arrive sur une page listant
les différents projets de tous les clients de la société (cf. annexe 18).
Pour chaque projet, il a la possibilité de voir sa date de création, son intitulé, le client
auquel il appartient et si ce projet est terminé ou non. Il a également la possibilité de
rechercher un projet en entrant un mot clé dans la zone de recherche. La recherche est

14
effectuée sur le nom du projet et sur le nom du client. Il a également la possibilité de trier les
projets par date de création, par nom ou en fonction de la fin de ce projet ou en cliquant sur le
titre des colonnes. Un clic trie par ordre alphabétique, le deuxième clic sur la même colonne
trie dans le sens contraire. En cliquant sur le nom du projet ou sur le nom du client,
l’administrateur accède à leurs détails.

 Détails d’un projet :

En cliquant sur le nom d’un projet, l’administrateur accède à ses détails. Il peut consulter sa
date de création, son intitulé, son descriptif, la personne qui en est en charge ainsi que son
logo. Il a également la possibilité d’accéder à toutes les tâches du projet, à la modification de
son logo, à sa suppression ou à l’ajout d’un nouveau projet.

 Changer le logo d’un projet :

Le même principe que celui de la modification du logo du client est utilisé pour les projets.
Une zone de recherche permet à l’administrateur de rechercher une image sur son disque dur.
Une fois récupérée, l’image est copiée sur le serveur de production, et est enregistrée en base
de donnée.

 Liste et détails des tâches d’un projet :

En cliquant sur le lien « Accéder aux tâches », l’administrateur est redirigé vers une page
listant toutes les tâches du projet (cf. annexe 19). Un projet est composé d’une ou plusieurs
tâches, celles-ci permettant de mieux le définir en séparant les actions a effectuer. Les tâches
sont affichées par sous-catégorie. Pour chaque tâche, son intitulé est affiché, ainsi que sa
description et l’image qui lui est associée. Il a alors la possibilité d’ajouter une nouvelle tâche,
de les modifier ou de les supprimer. En dessous de ces informations se trouvent les
commentaires laissés par les clients lors de la validation de la tâche.

 Liste des types de tâches d’un projet :

En cliquant sur le lien « Gestion des types de tâches », l’administrateur accède à la liste des
types de tâches disponibles. Un type de tâches est composé d’un intitulé et d’un
administrateur. Sur cette page, il peut modifier rapidement le nom des types de tâches et des
responsables qui leur sont associés ou en ajouter de nouveaux.

1.4.4 Tickets

En cliquant sur le lien « Tickets » du menu, l’administrateur arrive sur une page
présentant les diverses fonctionnalités auxquelles il a accès (cf. annexe 20). Les tickets
correspondent aux demandes qui ont été émises par les clients. Il peut gérer les priorités, les
catégories et les sous-catégories de tickets, ajouter un nouveau ticket, ou les afficher en
sélectionnant ceux qu’il souhaite voir. Sur cette page, certaines statistiques sont également
affichées et permettent de connaître le nombre de tickets total présent en base de données, le
nombre de tickets ouverts et le nombre de ticket fermés.

 Gestion des priorités :

En cliquant sur le lien « priorité », l’administrateur a la possibilité d’ajouter, de supprimer ou
de rechercher une priorité. S’il souhaite en ajouter une nouvelle, il doit compléter son intitulé
et préciser si celle-ci est active ou non. Dans le listing des priorités, des checkbox* lui
permettent de cocher celles qu’il souhaite supprimer. Il n’a alors plus qu’à cliquer sur le lien
« Supprimer » pour supprimer la / les priorité(s). Si la priorité est utilisée par un ticket, un

15
message d’erreur précise qu’il est impossible de la supprimer. La zone de recherche permet de
rechercher un ticket sur son nom.

 Gestion des catégories :

La gestion des catégories permet de créer une nouvelle catégorie, d’en supprimer, de lister
celles qui existent et d’en rechercher une en fonction de son nom. Pour supprimer une
catégorie, il suffit de cocher la checkbox qui lui correspond et de cliquer sur le bouton
supprimer. Si l’administrateur souhaite en créer une nouvelle, il doit obligatoirement
compléter l’intitulé de la nouvelle catégorie et lui affecter un responsable. Il peut également
choisir s’il souhaite que cette catégorie soit active ou non.

 Gestion des sous-catégories :

La gestion des sous-catégories permet d’effectuer les mêmes opérations que la gestion des
catégories. La seule différence est que lorsque l’administrateur souhaite créer une nouvelle
sous-catégorie, il doit préciser à quelle catégorie celle-ci appartient.

 Listing des tickets :

Six liens permettent d’arriver sur le listing des tickets. Ils permettent d’afficher soit tous les
tickets, soit ceux qui sont ouverts, soit les nouveaux, soit ceux qui ont été réouverts, soit ceux
qui sont fermés ou soit ceux dont l’administrateur est le gérant. En cliquant sur un de ces
liens, les tickets correspondants sont affichés. L’administrateur peut alors voir le nom du
ticket, son état (nouveau, réouvert, fermé, urgent), le demandeur, la date de dernière
modification de la sous-catégorie et le responsable ALCiiP. S’il clique sur l’un des noms de
colonnes précédentes, il trie les résultats en fonction de la colonne sur laquelle il a cliqué. En
cliquant sur le nom de la sous-catégorie, il accède à la modification de celle-ci. En cliquant
sur le nom du responsable, il accède également à sa modification. Enfin, en cliquant sur le
nom du ticket, il accède à la modification et à l’historique des demandes.

1.4.5 Prestations d’hébergement

En cliquant sur le lien « Heb » du menu, l’administrateur accède à une page listant les
différentes prestations d’hébergement des clients triées par date de création de la plus récente
à la plus ancienne (cf. annexe 21). Cette section permet de centraliser tous les noms de
domaines utilisés par les clients de l’entreprise et de pouvoir faire la situation d’un point de
vue financié. Pour chaque prestation, sont listés le nom de domaine concerné, la date de sa
création, son type et le client concerné par cette prestation. Il est possible de trier les
prestations en fonction de leur nom, de leur date de création ou de leur type de prestation. En
cliquant sur le nom du client, on accède à la liste simplifiée (nom de domaine, date de création
et type de prestation et accès à la liste détaillée) de toutes ses prestations d’hébergement. En
cliquant sur le nom de la prestation, on accède à la même liste plus détaillée, avec la
possibilité de modifier la prestation, d’afficher les factures, de voir la situation des différentes
prestations à une date données dans un fichier excel ou encore de la supprimer.

 Exporter les prestations au format XLS :

Lors du clic sur le lien « Exporter les données », une popup* s’ouvre et propose à
l’administrateur d’ouvrir ou de télécharger un fichier CSV (Excel). Lorsqu’il l’ouvre, toutes
les prestations sont répertoriées (cf. annexe 22). Pour chaque prestation sont affichés son nom
de domaine, son type, son type de nom de domaine, sa date de début, son prix, le geste

16
commercial d’ALCiiP (le nombre de mois offerts), le nom du client et si la prestation est
active ou non.

 Génération des factures :

En cliquant sur le lien « Afficher les factures », l’administrateur accède à une page web qui
liste les différents noms de domaines utilisés par les clients. Pour chaque nom de domaine, la
liste des factures qui lui correspondent est affichée en dessous. Chaque facture comprend la
date de début de facturation, la date de fin de facturation et le montant qui doit être payé par le
client. Il est possible de supprimer une facture en cliquant sur la croix rouge.

 Faire la situation pour un client :

En cliquant sur le lien calculer la situation, l’administrateur se retrouve sur une page
contenant un formulaire avec la possibilité de sélectionner une date. En cliquant sur valider, il
a la possibilité de récupérer un fichier XLS contenant l’ensemble des factures en cours à la
date qu’il a sélectionnée auparavant. Pour chaque facture sont affichés le nom de la raison
sociale du client, le nom de domaine concerné, le type de prestation, le type de nom de
domaine, la date choisie par l’administrateur, la nature de l’écart, la date de début de
facturation, la date réelle de début de facturation, la date de fin de facturation et enfin le prix
hors taxe et le prix de la prestation.

1.4.6 Ressources humaines

En cliquant sur le lien « RHs » du menu, l’administrateur arrive sur une page listant
les emplyés d’ALCiiP (cf. annexe 23). Pour chaque personne sont affichés sa civilité, son
nom, son prénom et son nom d’utilisateur.

1.4.7 Contacts

En cliquant sur le lien « contact » du menu, l’administrateur accède à la liste de tous

les contacts présents en base de données (cf. annexe 24). Chaque client possède un ou
plusieurs contact. Pour chaque contact sont affichés sa civilité, son nom, son prénom et une
case à cocher permettant de savoir s’il est actif et peut accéder à l’application ou non. En face
des contacts, si leur adresse mail a été complétée, un bouton « contacter » permet d’envoyer
rapidement un mail à la personne que l’on souhaite contacter. De plus, un bouton modifier
permet de modifier n’importe lequel d’entre eux.
La gestion des contacts est aussi accessible depuis le menu « clients », en cliquant sur
« gestion des contacts ». La liste des contacts du client est alors affichée, avec la possibilité
d’en ajouter et en face de chaque contact, de le modifier, le contacter ou le supprimer.

1.4.8 Prestations de webmastering

En cliquant sur le lien « Web » du menu, l’administrateur arrive sur une page
contenant deux tableaux (cf. annexe 25). Le premier contient les prestations encore ouvertes,
le second contient les prestations archivées. Pour chaque prestation sont affichés la raison
sociale du client qui l’a demandée, sa nature (développement, conseil ou webmastering), son
temps restant, son type de prestation (compris ou achat) et sa date de création.
L’administrateur peut les trier par nom de client, nature de prestation, type de prestation ou

17
date. Une zone de recherche permet également de rechercher des prestations sur le nom du
client et la nature de la prestation. En cliquant sur le nom du client, l’administrateur se
retrouve sur une page contenant de nouveau deux tableaux. Le premier contient les
prestations du client en cours, le deuxième contient celles qui sont archivées. Chaque
prestation est composée d’une ou plusieurs interventions. Pour chacune d’entre elle,
l’administrateur a la possibilité de voir la liste de ses interventions, d’en ajouter de nouvelles,
d’en modifier, d’en supprimer ou de voir l’historique de celles-ci. Lors du clic sur le lien
« afficher les informations », un tableau contenant l’historique des interventions qui ont été
faites sur la prestation apparaît en dessous des informations concernant la prestation. Pour
chaque intervention sont indiqués le nom du site sur lequel la modification a été faite, la date
de modification, une description, si oui ou non l’intervention a été validée et enfin le temps
qu’a duré l’intervention. Les possibilités de modifier ou de supprimer l’intervention sont aussi
présentes.

 Export XLS :
En cliquant sur le lien « historique », l’administrateur peut récupérer un fichier Excel. Cette
fonctionnalité permet à l’employé d’ALCiiP en charge de tout ce qui est administratif de
facilement pouvoir savoir ce que doit payer un client. Ce fichier contient sur sa partie gauche
les informations concernant la prestation, avec le nom du client, la date de création de la
prestation, le type de prestation, le temps total du contrat et le temps restant. A droite du
document se trouve la liste des interventions qui correspondent à la prestation. Pour chaque
intervention sont affichés le site sur lequel elle a été effectuée, le demandeur, la date
d’intervention, la description et le temps d’intervention.

1.4.9 Newsletter

En cliquant sur le lien « News » du menu, l’administrateur accède à l’envoi des lettres
d’informations aux clients (cf. annexe 26). Dans cette section, il peut sélectionner les clients
auxquels il souhaite envoyer la newsletter en les sélectionnant à partir d’une liste déroulante,
donner un nom à sa lettre, remplir le corps de celle-ci et joindre un fichier PDF. Une fois sa
lettre prête, il peut l’envoyer à toutes les personnes qu’il a sélectionnées en cliquant sur le
bouton « envoyer ».

1.4.10 Options supplémentaires

Comme le client, l’administrateur a également la possibilité de se déconnecter de

l’application en cliquant sur le lien « déconnexion » du menu. Il est alors redirigé vers la page
d’accueil de l’administration. En revanche, contrairement aux clients, ils n’ont pas la
possibilité de récupérer leurs informations d’identification, leur mot de passe étant crypté en
MD5.

Les administrateurs ont également accès à la zone shop. Dans cette section, une fois
qu’ils ont choisi un magasin d’un client, ils peuvent générer les commissions, ajouter des
commandes, valider les annulations faites par les clients, récupérer des commandes, créer un
avoir, générer un fichier, gérer les factures, ou générer des graphiques d’évolution ou
d’activité. Comme pour le client, cette section est amenée à disparaître car elle n’est plus
utilisée.

18
 L’ensemble des actions que peuvent effectuer les clients ou les employés de
l’entreprise est présentée sous forme de schéma en annexe 27.

2 Analyse technique et problèmes associés

2.1 Analyse de la base de données

La base de données utilisée par le CRM est la même que celle qui est utilisée par
administrations.alciip.com, l’administrations centralisée des sites web des clients d’ALCiiP.
Elle comporte donc certaines tables uniquement utilisées par le CRM, d’autres uniquement
utilisées par administrations.alciip.com et enfin des tables communes aux deux applications.

Le MCD de l’ensemble de ces classes a été réalisé par un employé de la société. Il

possède 81 classes, il est donc trop important pour figurer dans ce document. Le modèle
présenté ci-dessous comprend les différentes tables qui seront uniquement nécessaire à
l’utilisation du CRM.

2.1.1 Modèle Conceptuel de données

Le modèle conceptuel de données correspond à une représentation des données

présentes en base. Cette représentation est faite sous forme d’entités :

19
20
 2.1.2 Problèmes associés

La principale amélioration à fournir sur ce projet est de séparer la base de données de

l’espace client avec celle d’administrations.alciip.com. Cela permettrait de rendre
indépendantes ces 2 applications. Sur le modèle conceptuel de données ci-dessus, seules les
tables correspondant à l’espace client sont affichées, le modèle complet, qui comporte plus de
80 tables, ne pouvant être lisible. Un aperçu de ce diagramme est visible en annexe 28.

Le premier problème qui ressort de ce diagramme est la nomenclature des tables et

attributs des tables. Tout d’abord, certaines tables possèdent des clés primaires facilement
identifiables, comme « ID_sous_categorie_ticket » pour la table sous_categorie_ticket, alors
que d’autres possèdent des identifiants très vagues, comme « id » pour les tables Rh, contact
ou encore client. Ce qui peut poser certains problèmes lors de requêtes et qui montre que la
base de données n’est pas homogène.

Le second problème est que certains champs se nomment de la même manière dans
des tables différentes, mais ne sont pas de même type. Par exemple, la table categories_ticket
possède un attribut « actif » de type énuméré, alors que la table contact possède le même
attribut mais qui lui est de type tynyint.

Le troisième point correspond au fait que le shop n’est plus utilisé, et donc que les
tables dans la base de données ne servent plus à rien.

2.2 Analyse des classes

2.2.1 Diagramme de classe

L’application a été développée en PHP objet. Elle utilise donc des classes permettant
d’accéder et de gérer les différentes informations contenues dans la base de données. Les
classes permettent de décrire les propriétés d’un objet. Elle est composée d’attributs, qui
permettent de décrire les informations qu’elle contient, et de méthodes, qui permettent de
définir les interactions qu’elle peut effectuer avec d’autres classes, ou avec elle-même. Par
exemple, un classe « voiture » pourrait contenir comme attributs la couleur, le modèle, la
plaque d’immatriculation … et une méthode nommée « appartientA » qui permettrait de
communiquer avec une classe « personne » afin d’obtenir les informations concernant son
propriétaire. Le diagramme ci-dessous présente donc les différentes classes de la base de
données étudiée et les interactions que celles-ci peuvent avoir entre elles.

Sur ce diagramme, les classes dont la couleur de fond est bleue héritent de la classe
« Classe », alors que les classes dont la couleur de fond est verte héritent de la classe
« user » :

21
22
 2.2.2 Problèmes associés

Le diagramme de classe ci-dessus présente les différentes classes qui sont utilisées par
le CRM. On peut y apercevoir plusieurs anomalies qui peuvent avoir plus ou moins
d’importance.

La première chose qui apparaît en regardant ce diagramme est qu’une grande majorité
des classes possède quatre méthodes identiques : « getAll », « save », « remove » et « load ».
La première méthode, « getAll », permet de récupérer tous les enregistrements de la table. Un
argument peut lui être passé pour filtrer les résultats. La seconde, « save », permet soit
d’insérer un nouvel enregistrement dans la table si il n’existe pas, soit de le mettre à jour s’il
s’agit d’un enregistrement existant. La troisième, « remove », permet de supprimer un
enregistrement de la table. Enfin, la dernière, « load », permet de récupérer un enregistrement
en lui passant l’identifiant de celui-ci. Ces méthodes sont donc toujours identiques et on
retrouve le même résultat. Les classes ne sont donc pas optimisées.

La deuxième chose que l’on peut facilement identifier est que les types de données ne
sont pas toujours identiques d’une classe à l’autre pour une même variable. Par exemple, la
classe Categorie_ticket possède une variable nommée actif de type énuméré, alors que la
même variable actif qui a la même utilité dans la classe Prestation est de type string. Les types
de données ne sont donc pas uniformes.

La troisième chose que l’on peut voir est qu’aucune nomenclature n’a été appliquée
lors de la création des classes. Certaines classes possèdent des noms commençant pas des
lettres majuscules, d’autres commençant par des lettres minuscules. On peut observer le
même problème avec les noms des attributs et des méthodes. Ceci montre encore la non
uniformisation des classes.

Enfin, le dernier point que l’on peut observer est que certaines tables possèdent des
noms d’identifiants très vagues. Par exemple, les identifiants des tables Rh, Contact, Client,
projet, tâche et document se nomment « id ». Cela ne favorise pas l’exploitation des données
lorsque l’on souhaite faire une requête avec des jointures*.

2.3 Analyse de la hiérarchie des fichiers

2.3.1 Diagramme de présentation

Le diagramme ci-dessous représente la hiérarchisation des fichiers de l’application.

Chaque nom correspond à un nom de répertoire de l’application, et chaque flèche signifie que
le répertoire pointé par celle-ci est un sous répertoire de celui dont elle part. Le répertoire
situé le plus à gauche, nommé « espace_client », est donc le répertoire parent de tous les
autres. Chaque dossier représenté sur le schéma peut contenir zéro, un ou plusieurs fichiers.

23
24
 2.3.2 Problèmes rencontrés

Le premier problème constaté en ce qui concerne la hiérarchisation des fichiers et des

dossiers est que ceux-ci ne sont pas tous placés au bon emplacement. Par exemple, les classes
devraient toutes être présentes dans le dossier « espace_client/Library/Classes/ ». Hors,
certaines classes ne sont pas dans ce répertoire, par exemple la classe « Commentaire_ticket »
est placée dans le dossier « espace_client/admin/ demande/classes/ ».

Un autre problème visible sur ce schéma est que certains dossiers sont présents en
double, parfois même en triple. On peut voir par exemple que le dossier nommé php_mailer
contenu dans hébergement, et le dossier nommée phpmailer contenu dans webmastering
possèdent les mêmes fichiers et ne pourraient donc être qu’un seul et même dossier. Idem
pour le répertoire php_writeexcel qui lui est présent dans les dossiers clients, hébergement et
webmastering.

Enfin, certains dossiers sont inutiles, comme les dossiers « modifier » et « nouvelles »
qui sont présents dans le dossier « ressources_humaines ». Ces deux dossiers contiennent
chacun un fichier nommé index.php permettant d’ajouter ou de modifier les informations des
contacts. Hors, dans les autres répertoires, ce genre de séparation n’existe pas.

La hiérarchie des fichiers et des dossiers montre bien que l’application n’a pas été
développée d’un trait par une seule et même personne, mais que plusieurs développeurs ont
apporté leur contribution à celle-ci. Ces personnes ont participé malgré elles à la non
uniformisation de l’application.

2.4 Analyse de la sécurité

2.4.1 Présentation de l’accès à l’administration

L’accès à l’administration se fait via la classe nommée « manager.php ». Tous les

fichiers de l’application appellent cette classe dans un premier temps afin de vérifier si une
session est ouverte. Si c’est le cas, la page est accessible par l’utilisateur. Sinon, l’utilisateur
est redirigé vers la page d’accueil et doit s’identifier pour accéder à l’administration.

Le fichier appelé en début de toutes les pages appelle toutes les classes nécessaires à la
gestion des données. Elle est appelée par le CRM, ainsi que par solutions.alciip.com. Ainsi, le
premier problème qui apparaît est qu’il est impossible pour un utilisateur de s’identifier
simultanément aux deux applications, les variables de session ne permettant pas de faire cela.

L’autre problème suscité par cette classe est qu’elle fait appel à toutes les classes de
l’application, alors qu’elles ne sont jamais toutes nécessaires. Cela peut être lourd à charger.

2.4.2 Présentation des problèmes de sécurité

Il existe deux principaux moyens de faire passer des variables d’une page à une autre
en développement web : la méthode GET et la méthode POST. La méthode GET utilise l’url
de la page pour passer des données au serveur. La méthode POST, quand à elle, cache ces
données. Le premier problème de l’application est qu’il y a beaucoup plus d’informations

25
passées à l’aide de la méthode GET que de la méthode POST. Ainsi, lorsqu’un client clique
sur le bouton Projets du menu, puis sur la flèche verte, l’administrateur est redirigé à l’url
suivante : http://solutions.alciip.com/espace-client/vos_projets/details/?projet=x, x
correspondant au nom du projet courant. En modifiant la valeur x, le client peut accéder à des
données auxquelles il ne devrait jamais avoir accès. Une fois cela effectué, il a la possibilité
de voir et de modifier des données d’un autre client. Ceci est le principal problème de
sécurité. De plus, il n’existe aucun moyen de déterminer quel client aurait pu effectuer une
action de ce genre.

Un second problème qui peut être soulevé est le formatage des données avant leur
insertion dans la base. En effet, pour prévenir tout risque, notamment de cross site scripting,
qui correspond au passage par l’utilisateur de données non autorisés, seule une méthode
nommée « addSlashes », qui ajoute des antislash avant les guillemets et les simple côte, ne
suffit pas à prévenir ce genre d’attaques.

Un autre problème est qu’un client peut très facilement accéder à la zone réservée aux
administrateurs en modifiant l’url. En effet, une fois identifié en tant que client, il lui suffit
d’ouvrir l’url http://solutions.alciip.com/espace-client/admin/ pour entrer dans une zone qui
lui est interdite. Une fois dans cette zone, il a accès aux mêmes fonctionnalités que
l’administrateur et peut alors modifier toutes les informations qu’il veut concernant n’importe
quel client. Cette faille de sécurité est très importante et nécessite d’être très vite réglée.

3 Présentation des améliorations fournies

3.1 Amélioration de la base de données

Suite à l’analyse fonctionnelle et technique que j’ai effectuée, j’ai décidé de repartir de
la structure existante de l’application car celle-ci permet de résoudre les problèmes vus dans
la partie précédente. Le graphisme, les fonctionnalités, les classes et la base de données ont
donc été conservés. Cependant, de nombreuses modifications ont dû être apportées dans le but
d’obtenir un CRM plus sécurisé et plus facile à reprendre en main pour la prochaine personne
qui souhaitera le modifier.

Afin de développer ces nouvelles fonctionnalités sans toucher à l’application qui est en
production, j’ai recopié l’intégralité des fichiers sur mon serveur de développement et
dupliqué la base de données dans une base de développement. Cela permet de travailler en
local en toute sécurité.

3.1.1 Séparation de la base de données

Le principal objectif de ce projet est d’obtenir une application indépendante qui

pourrait être hébergée sur un nouveau serveur de l’entreprise. Comme dit précédemment, le
CRM et l’application de gestion des contenus utilisent la même base de données, ce qui lie ces
deux applications. La première étape que j’ai à réaliser est donc de déterminer les tables de la
base de données qui sont nécessaire au bon fonctionnement du CRM.

Après avoir parcouru l’intégralité des fichiers de l’application, j’ai pu avoir un aperçu
des tables indispensables. Je les ai conservées et j’ai supprimé les autres tables qui n’avaient

26
plus d’utilité pour le CRM. Le nombre de tables est ainsi passé de 108 à 39, soit 69 tables en
moins. De plus, j’ai supprimé toutes les tables de la partie « shop », celle-ci n’étant plus
utilisée. Avec 7 tables en moins, on obtient une application dont la base de données ne
possède plus que 32 tables, soit au final 76 tables de moins que l’application de départ.

J’ai également décidé de supprimer une dernière table nommée « session ». En effet, je
compte utiliser les variables de session pour garantir la sécurité de l’application, donc je ne
ferai plus appel à cette table. La base de données de l’application ne possède au final plus que
31 tables.

Une fois cette séparation de la base effectuée, au vu des problème qui ont été soulevés
lors de l’analyse technique, je dois regarder comment uniformiser au mieux les données.

3.1.2 Nomenclature appliquée

Comme on peut le constater sur le modèle conceptuel de données présenté dans la

partie analyse fonctionnelle, les données ne sont pas du tout uniformes. Les noms de certaines
tables sont au singulier, d’autres sont au pluriel. Le type d’une variable identique à deux
tables est différent. Pour pallier cela, j’ai décidé d’adopter une nomenclature claire et facile à
respecter.

Pour ce qui est du nom des tables, j’ai décidé de tous les mettre au singulier et en
minuscule. Si le nom est composé de plusieurs mots, ces mots doivent être séparés pas des
underscore.

En ce qui concerne la nomenclature utilisée pour le nom des champs d’une table, seuls
ceux correspondant à la clé primaire d’une table, c'est-à-dire au champ unique qui permet de
différencier un enregistrement parmi les autres, possèdent des majuscules. Ceux-ci doivent
obligatoirement commencer par le préfixe « ID_ », et se terminer par le nom de la table en
minuscule. Par exemple, l’identifiant de la table projet est « ID_projet ». Cette table est en
relation avec les tables « clients » et « rh ». Elle possède donc également un champ nommé
« ID_client » et « ID_projet ».

Il existe cependant quelques exceptions à cette règle. La table « client » possède deux
champs référant à la table contact, l’un pour désigner le contact principal du client, l’autre
pour désigner son contact financier. Comme il est interdit de nommer deux champs
identiquement, j’ai appelé le premier « ID_contact_principal » et le second
« ID_contact_financier ». Cela permet de facilement comprendre que les champs font
référence à la table contact, et cela permet également de les différencier.

Une autre exception concerne la table site. En effet, celle-ci fait référence à une table
qui n’existe pas dans la base de données, nommée « site_edk ». Comme il s’agit d’un
identifiant, j’ai nommé ce champ « ID_site_edk » pour bien comprendre qu’il s’agit d’une clé
étrangère (identifiants d’une autre table).

Pour terminer avec le nom des champs, j’ai choisi d’écrire tous les autres champs ne
correspondant pas à la règle précédente en minuscule et au singulier. S’ils sont composés de
plusieurs mots, ceux-ci seront séparés par des underscore.

27
 Enfin, pour ce qui est des types des différents champs, j’ai également décidé de
prévoir au mieux les différents types possibles.

Tout d’abord, les identifiants des tables doivent tous être de type « int » (entier) et de
longueur 11.

Ensuite, si cela est possible, les champs dont on sait qu’ils ne peuvent contenir que des
valeurs connues doivent être de type énuméré, afin de limiter au maximum les risques
d’insertion d’une valeur incorrecte par l’utilisateur. Ceci est également un gage de sécurité
pour l’application. Par exemple, la table « commentaire_ticket » possède un champ nommé
type_posteur. On sait que les deux seuls types d’utilisateurs de l’application sont « contact »
ou « rh ». On utilise donc une variable de type énuméré pour ce champ.
Pour ce qui est des champs de types date, le type timestamp est déjà utilisé dans
l’application. Ce type correspond au nombre de secondes qui se sont écoulées depuis le 1 er
janvier 1970. Cela permet d’obtenir facilement des dates à la seconde près, qu’il est très facile
de traiter grâce aux fonctions qu’offre PHP. Ces champs sont donc de type « int » (entier) et
de longueur 11, cette longueur étant largement suffisante car elle permet d’obtenir une date
jusqu'au 16/11/5138.

Pour les autres champs, le développeur a le choix de mettre ce qu’il souhaite en

essayant de rester le plus proche possible de la réalité. Par exemple, s’il doit ajouter un champ
« telephone », il utilisera un type « string » (chaîne de caractère) de longueur 20, afin de
prévoir le cas des numéros de téléphones étrangers qui peuvent être plus longs que les
numéros français, et de prévoir les préfixes comme « +33 ».

Le model conceptuel de données de la nouvelle base est visible en annexe 29.

3.2 Amélioration des classes

3.2.1 Nomenclature des classes, des attributs et des méthodes

La nomenclature des noms des classes correspond à celle utilisée pour les noms des
tables de la base de données. Ils doivent tous être en minuscule, au singulier, et les noms
composés sont séparés par des underscore. Ces noms doivent être exactement les mêmes que
ceux des tables.

La nomenclature correspondant au nom des attributs est exactement la même que celle
utilisée par les noms des champs des tables de la base. Les identifiants ont leurs préfixes en
majuscules, le reste est tout en minuscules. Ces noms doivent être exactement les mêmes que
ceux des champs des tables.

Enfin, les noms des méthodes sont tous en minuscules. S’il s’agit d’un nom composé, les
mots sont séparés par des underscore.

3.2.2 Modification des méthodes

La principale modification que j’ai effectuée sur les classes concerne l’héritage de
celles-ci. En effet, comme on peut le voir sur le diagramme de classe, beaucoup d’entre elles

28
possèdent 4 méthodes : « load() », « getAll() », « save() » et « remove() ». J’ai donc réalisé
une classe, nommée « methods », dont toutes les autres classes ont hérité, c'est-à-dire qu’elles
peuvent toutes utiliser les méthodes de cette nouvelle classe. Dans cette classe, j’ai
redéveloppé ces 4 méthodes de manière à ce qu’elles soient utilisables par n’importe laquelle
des classes qui en hérite. Ainsi, au lieu d’avoir les 4 méthodes dans toutes les classes, ces
méthodes ne se trouvent plus que dans la classe développée. Le jour où elles devront être
changées, il suffira au développeur de les modifier à un endroit pour que la modification
affecte l’ensemble de l’application. Cette nouvelle classe possède également les méthodes
« get() » et « set() » qui permettent respectivement de récupérer et d’attribuer une valeur à une
variable d’un objet. Par exemple, en faisant « $voitureset(‘couleur’, ‘rouge’) ; », on attribue
à la voiture la couleur rouge. En faisant « $couleur = $voitureget(‘couleur’) ; », on récupère
la couleur de la voiture. La variable $couleur sera donc égale à ‘rouge’.

Une autre modification concernant les classes se situe dans l’utilisation d’une fonction
permettant d’appeler automatiquement les classes que l’on souhaite lorsqu’on instancie un
objet. Cette méthode se nomme « __autoload() » et se trouve dans le fichier
« conf/functions.php ». Avant, il était nécessaire d’appeler toutes les classes une par une dans
le fichier d’initialisation. Avec cette fonction, il n’est plus nécessaire de les appeler. Elle est
donc très pratique et permet de réduire le nombre de lignes de codes.

J’ai également supprimé certaines méthodes des classes, qui pour la plupart n’étaient
pas indispensables. Seules celles qui étaient correctement développées et indispensables ont
été récupérées.

3.2.3 Documentation des classes

Toutes les classes ont été documentées en anglais à l’aide d’un outil nommé
phpDocumentor. Cet outil permet de générer une documentation très pratique en utilisant les
commentaires que j’ai ajoutés. Plusieurs types de commentaires ont étés ajoutés.

Le premier permet de décrire la classe. Le commentaire ressemble à cela :

« My description » correspond donc à la description de la classe. Le « @package » est un

code utilisé par php Documentor pour connaître à quel package, c'est-à-dire à quel groupe de
classe appartient la classe. Dans notre cas, la classe appartient au package « class ».

Le second type de commentaires permet de décrire les attributs :

Ce commentaire permet de définir l’attribut « $note_interne ». « Comment » correspond à la

description de l’attribut. « @var » est un code permettant à phpDocumentor de savoir quel est

29
le type de la variable en question. Elle peut être de type « string » (chaîne de caractère),
« int » (entier), « enum » (énuméré)…

Le dernier type de commentaire permet de décrire les méthodes des classes :

La première phrase de ce commentaire permet de décrire ce que fait la fonction. « @param »

est un code permettant de définir les différents paramètres qui sont attribués à la fonction. On
retrouve le type de la variable ainsi qu’un texte précisant ce à quoi elle correspond.
« @return » permet de définir les variables que retourne la fonction. On retrouve également à
la suite le type de la variable de retour ainsi que ce qu’elle contient.

Une fois tous les commentaires ajoutés, je peux générer la documentation à l’aide de
phpDocumentor. Il suffit pour cela de préciser les répertoires que celui-ci doit analyser, puis
de choisir un répertoire dans lequel les fichiers seront générés. Une fois la génération
effectuée, on obtient une page web affichant le nom de tous les fichiers et de toutes les classes
analysées (cf. annexe 30). A partir de cette page web, il est possible de cliquer sur n’importe
quel fichier ou n’importe quelle classe. En cliquant par exemple sur le nom d’une classe,
toutes les informations entrées en commentaires dans celle-ci sont affichées (cf annexe 31).
On y retrouve le nom de la classe, la source de celle-ci, sa définition, sa classe héritée, ses
variables, ses méthodes, les méthodes dont elle hérite de la classe mère et ses classes filles. Il
est alors possible de cliquer sur n’importe quelle variable pour obtenir son nom, sa définition,
la ligne à laquelle elle est définie, son type d’accès (publique, protégé ou privé) et son type.
En cliquant sur le nom d’une méthode, l’utilisateur accède à son nom, la ligne à laquelle elle
est définie, sa définition, le type de valeur(s) qu’elle retourne, son accès et le(s) paramètre(s)
dont elle a besoin.

J’ai utilisé phpDocumentor pour commenter mes classes car il génère une
documentation très claire et très complète, dans laquelle n’importe qui peut trouver les
informations qu’il souhaite très rapidement, et également parce que celui-ci est très simple
d’utilisation et de manipulation.

3.3 Modification des fichiers

3.3.1 Présentation de la hiérarchie appliquée

Le principal problème que j’ai pu constater lorsque j’ai fait l’analyse de la hiérarchie
des fichiers est que certains dossiers apparaissaient plusieurs fois, alors que ceux-ci pourraient
tous être dans un seul et même répertoire. Par exemple, les dossiers nommés « classe » et
« ressource » ne devraient pas exister pour chaque sous-répertoire de « admin ». J’ai donc
décidé de créer un répertoire, nommé « conf », dans lequel j’ai inclu plusieurs fichiers : un
fichier « class_global.php », comportant toutes les variables globales, c'est-à-dire les variables
que l’on ne définit qu’une seule fois et qui sont utilisable par l’ensemble de l’application, un
fichier de configuration pour le serveur de développement, « connexion_DEV.php », un
fichier de configuration pour le serveur de production, « connexion_PRODUCTION.php »,

30
un fichier comportant l’ensemble des fonctions PHP utilisées par l’application,
« functions.php », et un fichier appelé par toutes les pages web, nommé « init.php », qui inclut
le fichier « class_global », le fichier de configuration correspondant au serveur sur lequel
l’application est exécutée (production ou développement) et le fichier contenant les diffentes
fonctions utilisées.

Ensuite, j’ai remarqué que les classes utilisées ne se situaient pas toutes dans le même
répertoire. La plupart se situaient dans le répertoire « Library », mais certaines se situaient par
exemple dans le répertoire « admin/demande/ ». Cela pose des problèmes, tout d’abord parce
qu’il est plus difficile de savoir où se situe la classe, et cela n’est pas logique. J’ai donc créé
un répertoire nommé « class » dans lequel j’ai mis toutes les classes nécessaires au bon
fonctionnement de l’application. Cela facilitera la tâche de la prochaine personne qui
souhaitera travailler dessus, qui pourra ainsi trouver les classes très facilement.

Une autre modification que j’ai apportée au niveau des fichiers est la séparation de
l’affichage des données et de leur traitement. En effet, dans l’ancienne version du CRM, le
traitement des données était effectué sur la même page que leur affichage. J’ai préféré créer,
pour chaque groupe d’actions, une page PHP qui a pour rôle d’effectuer les différents
traitements demandés par l’utilisateur. J’ai donc créé, par exemple, pour tout ce qui concerne
les projets, c'est-à-dire leur création, leur suppression, leur modification ou encore le
changement de logo, un fichier nommé « projets.action.php » qui traite la demande de
l’utilisateur et le renvoie sur la bonne page avec un message de confirmation ou d’erreur. Cela
permet de facilement se retrouver dans les fichiers, et lorsque l’on souhaite modifier un
traitement, on sait qu’il faut aller le chercher dans les fichiers d’actions.

Enfin, certaines pages d’affichage possèdent de nombreuses lignes d’initialisation.

Dans ce cas, j’ai créé des pages PHP, nommées par exemple « index.initialisation.php », qui
sont appelées par les pages nécessaire, dans ce cas par la page « index.php », afin de réduire
fortement ces lignes d’initialisation. Le code est ainsi plus clair pour le développeur.

3.4 Amélioration de la sécurité de l’application

3.4.1 Variables passées en POST

Comme nous l’avons vu lors de l’analyse de la sécurité, la plupart des pages web de
l’application utilisent des variables passées à l’aide de la méthode GET, ce qui entraîne une
grosse faille de sécurité dans l’application. Pour pallier ce problème, j’ai proposé une solution
permettant de passer les variables à l’aide de la méthode POST sur toutes les pages. Le
principal problème auquel j’ai dû faire face est que l’utilisation des variables avec la méthode
POST n’est possible en principe que lorsque l’utilisateur de l’application valide un formulaire.
Or, ce n’est pas toujours le cas, l’utilisateur pouvant par exemple cliquer sur un lien nommé
« retour à mon projet » qui nécessite de savoir quel projet il faut afficher.

J’ai donc adopté le principe suivant à l’aide de javascript, il est possible de créer des
éléments sans avoir à recharger la page web. Lorsqu’un utilisateur clique sur un lien, j’ai fait
en sorte de créer un formulaire à l’aide du langage javascript. Ce formulaire comporte l’action
qu’il doit effectuer, c'est-à-dire la page sur laquelle il doit rediriger l’utilisateur, ainsi que les
variables qu’il doit envoyer en POST. Cela permet de cacher les variables, qui ne sont donc
plus visibles dans l’url de la page.

31
J’ai donc créé une fonction javascript nommée « poster » à laquelle on peut attribuer 5
paramètres : l’url de la page à atteindre, le nom de la première variable, la valeur de la
première variable, le nom de la seconde variable et la valeur de la seconde variable. Seules 2
variables peuvent être passées en paramètres, 2 étant le nombre maximum de variables dont
on puisse avoir besoin.

3.4.2 Sécurisation des données

Le second problème de sécurité soulevé dans la partie analyse de la sécurité concerne le

formatage des données avant leur insertion. Afin d’être sur qu’en aucun cas un utilisateur,
volontairement ou nom, ne tente d’exécuter une requête SQL, j’ai créé une fonction qui
analyse toutes les requêtes avant de les exécuter. En langage SQL, 4 mots clefs permettent
d’accéder ou de gérer des données : « SELECT », « INSERT », « UPDATE » et « DELETE ».
La fonction que j’ai créée, nommée « protected_item », contrôle qu’aucun de ces mots clefs
n’apparaissent dans la requête. Si c’est le cas, elle remplace le mot trouvé par une chaîne vide.
Ainsi, si l’utilisateur a entré dans un champ « SELECT * FROM clients », la requête qui sera
exécutée sera : « * FROM clients ». Ce qui protège la base de données des utilisateurs qui ne
doivent pas y avoir accès.

3.4.3 Accès à l’application

Lorsqu’un utilisateur s’identifie, si son nom d’utilisateur et son mot de passe sont
corrects, une session est créée. Cette session comprend deux variables : le type d’utilisateur
qui vient de s’identifier, qui peut être ‘contact’ ou ‘rh’, et l’identifiant de cette personne. Les
variables de session sont accessibles sur n’importe quelle page de l’application. Cela permet à
n’importe quel moment de récupérer toutes les informations concernant l’utilisateur.

3.4.4 Interdiction d’accès

Enfin, pour pallier le dernier problème de sécurité, à savoir la possibilité pour les
utilisateurs d’accéder à la partie administration de l’application en modifiant leur url, j’ai
ajouté dans le fichier « init.php » un contrôle. Sachant que toute la partie réservée aux
administrateurs se trouve dans un dossier nommée « admin », et qu’aucun dossier ne se
nomme ainsi dans la zone réservée aux utilisateurs, je contrôle que l’utilisateur ne tente pas
d’accéder à une page dont l’url contient « admin ». Si c’est le cas, sa session est détruite et il
est redirigé vers la page d’identification.

3.5 Autres améliorations

3.5.1 Utilisation d’Ajax

L’utilisation des fichiers d’actions nécessite l’utilisation d’Ajax. En effet, afin de

passer les différentes variables nécessaires pour que le fichier d’actions puisse effectuer les
traitements, il y avait deux solutions. La première consistait à les passer dans l’url et à les
récupérer sur le fichier. J’ai vite abandonné cette solution qui faisait ressortir le problème de

32
sécurité des variables passées à l’aide de la méthode GET. Il a donc fallu trouver une autre
solution et c’est ainsi que j’ai décidé d’utiliser Ajax.

Cela permet en effet d’envoyer les variables sans que celles-ci ne soit visibles dans
l’url. De plus, cette technologie est très utile car elle permet d’effectuer les traitements sans
avoir besoin de recharger la page. Ainsi, par exemple, si une administrateur souhaite ajouter
un contact, il entre les informations dans le formulaire puis clique sur le bouton de validation.
Lors de son clic, le fichier d’actions est appelé et effectue le traitement. Puis le résultat de
celui-ci est affiché sur la page contenant le formulaire.

L’utilisation d’Ajax est très simple. Il suffit d’ajouter le bouton de validation suivant
pour le formulaire :
« <input name = "submit" type = "submit" value="Enregistrer" onClick = "ajax_request
('./clients.action.php','div_affichage_message','1','0'); return false;" /> ». Ce bouton appelle la
fonction javascript « ajax_request » qui permet d’envoyer les variables en POST à la page
passée en paramètre.

L’utilisation d’Ajax pose cependant un problème. En effet, les zones permettant de

rechercher un fichier sur son ordinateur, nommé « FILES », doivent obligatoirement envoyer
les informations concernant ce fichier au serveur. Or, l’utilisation d’ajax ne le permet pas. J’ai
donc rechercher une solution et adopté la suivante. Lorsque l’utilisateur souhaite ajouter un
fichier, il le recherche dans la zone prévue à cet effet. Ensuite, il clique sur un premier lien
« Préparer le fichier ». Ce lien valide le formulaire, upload le fichier sur le serveur et recharge
la page en conservant toutes les informations concernant le fichier. Un nouveau lien
« enregistrer » apparaît alors. L’utilisateur n’a plus qu’à cliquer dessus. Le traitement est
appelé à l’aide d’ Ajax et tout se passe correctement.

3.5.2 Utilisation d’une classe gérant les messages d’alerte

Une autre modification que j’ai apportée à l’application est la création d’une classe
permettant de générer facilement les messages d’erreur. Cette classe, nommée
« dialog_message_manager », permet d’afficher trois sortes de messages d’erreur : les
messages de validation (cf. annexe 32), les messages d’erreur (cf. annexe 33) et les messages
d’avertissement (cf. annexe 34) en fonction du résultat du traitement que l’utilisateur a
demandé. Pour la mise en forme, j’ai récupéré le style des messages utilisé par
administrations.alciip.com en le modifiant et en l’adaptant au mieux au CRM.

3.5.3 Génération d’un mot de passe pour les administrateurs

Dans la version existante du CRM, les administrateurs ne pouvaient jamais récupérer

leur mot de passe, celui-ci étant crypté à l’aide de la méthode MD5. J’ai ajouté sur la page
d’identification des administrateurs la possibilité de récupérer leurs informations en entrant
leur adresse mail. Lorsqu’ils entrent leur adresse mail, un nouveau mot de passe de 8
caractères aléatoires est généré. Leur ancien mot de passe est remplacé par ce nouveau, qui est
crypté en MD5 avant d’être enregistré en base. Une fois cela fait, le mot de passe non crypté
est envoyé par mail à l’administrateur, qui peut de nouveau s’identifier à l’application.

33
 3.5.4 Amélioration du code

Dans le but de mettre en place toutes les modifications que j’ai pu apporter à
l’application, j’ai repris toutes les pages web une par une en les adaptant et surtout en les
améliorant. J’ai enlevé tout le code inutilement commenté, ajouter des commentaires en
anglais et amélioré au mieux le code existant, en modifiant les anciennes fonctions PHP qui
sont utilisées et en effectuant les retraits. Cela permettra aux prochaines personnes travaillant
sur l’application d’effectuer des modifications sur un code clair et facilement compréhensible.

34
 Conclusion

L’objectif de ce travail était d’obtenir une application indépendante, plus facilement

modifiable pour les prochains développeurs qui travailleront dessus, plus sécurisé et de
fournir une documentation fonctionnelle celle-ci.

Dans un premier temps, la rédaction de cette documentation m’a permis de mieux

appréhender l’application et de me familiariser avec les différentes fonctionnalités de celle-ci.
Elle ma également permis de commencer à prendre conscience des nombreux problèmes et
anomalies qu’elle possède et de commencer ma réflexion sur les différents moyens à mettre
en œuvre pour l’améliorer.

Une fois cette documentation réalisée, j’ai pu effectuer l’analyse technique du CRM,
en étudiant la base de données, les différentes classes et le code des différents fichiers qui le
compose. Cette phase d’analyse m’a permise de mieux comprendre comment fonctionne cette
application et m’a également permis de découvrir de nouvelles anomalies. J’ai ainsi pu
réfléchir aux solutions techniques les mieux adaptées aux résolutions de ces problèmes.

La phase suivante a été consacrée à effectuer un choix entre reprendre le code et les
classes existantes, ou repartir de zéro et développer une nouvelle application. J’ai choisis de
reprendre la structure existante car celle-ci permettait de répondre à tous les besoins
rencontrés.

La dernière phase fut donc consacrée au développement des améliorations à fournir à

l’application. Les données de la base de données et des classes ont été uniformisées, la
hiérarchie des fichiers a été modifiée pour être mieux adaptée à l’application, la sécurité à été
grandement renforcé afin de prévenir tout risque lié à des utilisateurs mal intentionné et le
code à été repris afin d’être plus lisible et de suivre l’évolution du langage PHP. Seule cette
dernière phase n’est pas encore totalement aboutie.

J’ai déjà pu effectuer de nombreux tests unitaires sur le serveur de développement de

l’entreprise. Les prochaines étapes consistent à terminer de développer l’application,
d’effectuer tous les tests nécessaires et d’effectuer une mise en production. Une fois cela fait,
il faudra vérifier que l’application fonctionne correctement sur le nouvel environnement. Si ce
n’est pas le cas, il faudra effectuer les dernières modifications pour terminer le projet.

Le travail quotidien effectué en entreprise m’a permis de mieux comprendre le

fonctionnement des sociétés de services et de travailler avec des temps impartis, ou encore de
devoir effectuer des estimations de temps pour des interventions et de devoir les tenir au
mieux.

Enfin, j’ai eu la chance d’arriver dans une entreprise en plein développement. Cela
m’a permis de découvrir la vie d’une entreprise et les choix stratégique que celle-ci peut
effectuer pour évoluer au mieux.

35
 Bibliographie

Sites Web les plus fréquentés :

- http://www.php.net
 Site Web contenant toutes les informations nécessaires au développeur PHP.

- http://fr.wikipedia.org
 Encyclopédie libre.

- http://phpsec.org
 Site Web abordant le thème de la sécurité des sites.

- http://www.developpez.com
 Forum des développeurs (tout langage de programmation confondu).

Documentation PDF :

- Document abordant le thème du développement en PHP fournit par un développeur

indien (en anglais).

- Document abordant le thème de la sécurité en PHP fournit par un développeur indien

(en anglais).

Réunions d’informations :

- Mr De Ferran Manuel, administrateur réseau, Mlle Rachwal Céline, chef de projet, à

ALCiiP, le 20 mars 2008 : présentation du projet, des tâches à réaliser et des deadlines.

- Mr De Ferran Manuel, administrateur réseau, à ALCiiP, le 20 juin 2008 : présentation

de l’avancement du projet, des idées d’améliorations et des objectifs à réaliser

- Mlle Rachwal Céline, chef de projet, à ALCiiP, le 20 août 2008 : avancement du

développement, présentation du cahier des charges et suggestion d’amélioration

36
 Glossaire

Alias de compte :
Un compte mail possède une seule adresse, par exemple j.sancey@alciip.com. Un alias de
compte mail correspond à une adresse synonyme de cette adresse principale et qui renvoi le
courrier électronique sur cette première adresse. Par exemple, jsancey@alciip.com est un alias
de compte mail.

Checkbox :
Une checkbox, traduit littéralement par « case à cocher » en français, permet à l’utilisateur
d’effectuer rapidement et simplement un ou plusieurs choix lorsqu’il remplit un formulaire en
cochant la case situé en face de la proposition qu’il a choisit.

CRM :
Un CRM, traduit littéralement par « Gestionnaire de la relation client », est un extranet qui
permet une communication entre le client et l’entreprise, et une communication interne au
sein de l’entreprise pour ce qui est de la facturation des clients.

Jointure :
Les bases de données possèdent plusieurs tables. Certaines requêtes ne concerne qu’une seule
table, d’autres peuvent en concerner plusieurs. Lorsqu’une requête concerne plusieurs tables,
on dit qu’une jointure est effectuée entre celles-ci.

Lead :
Lorsqu’un formulaire de contact est remplit par un internaute sur le site d’un des clients de
l’entreprise, celui-ci reçoit un email contenant les informations entrées par le client potentiel.
Il s’agit d’un lead. Il ne s’agit que d’une piste commerciale.

Mot-clef :
Mots sur lequel un client souhaite que son site soit référencé sur les moteurs de recherche. Ces
mots décrivent l’activité ou le secteur d’activité du client.

Newsletter :
Email envoyé à une liste de destinataires contenant les nouvelles que souhaite communiquer
le client. Les destinataires on en général fait savoir leur volonté d’être ajouté à la liste en
inscrivant leur adresse mail dans une zone prévu à cet effet sur le site du client.

Plateforme centralisée :
Chez ALCiiP, extranet permettant au client d’accéder à la gestion de leur site web, de leurs
formulaires de contact, de leurs statistiques ou encore de leurs newsletters. Il s’agit d’une
plateforme centralisée car tous les clients accèdent à leur administration via la même url.

Popup :
Fenêtre du navigateur, généralement plus petite que la fenêtre principale, qui s’ouvre par-
dessus cette dernière pour afficher certaines informations.

37
 Table des annexes

1. Structure internationale d’ALCiiP................................................................................39

2. Présentation de mon travail quotidien chez ALCiiP.....................................................39
3. Zone d’identfication pour les clients.............................................................................40
4. Zone d’identification pour les employés d’ALCiiP......................................................40
5. Listing des projets d’un client.......................................................................................40
6. Listing des tâches d’un projet.......................................................................................41
7. Listing des demandes effectuées par un client..............................................................41
8. Détails d’une demande..................................................................................................42
9. Ajout d’une demande par le client................................................................................42
10. Listing des prestations de webmastering......................................................................43
11. Modification des informations personnelles.................................................................43
12. Page d’accueil de l’application pour les employés de l’entreprise...............................44
13. Listing des clients de l’entreprise.................................................................................44
14. Détails des informations concernant un client..............................................................45
15. Ajout d’un nouveau client.............................................................................................46
16. Modification du logo d’un client..................................................................................48
17. Listing des comptes mails d’un client...........................................................................48
18. Listing des projets des clients de l’entreprise...............................................................49
19. Listing et détails des tâches d’un projet........................................................................49
20. Listing des demandes effectuées par un client..............................................................50
21. Listing des prestations d’hébergement des clients........................................................50
22. Export des prestations d’hébergement sous forme de fichier Excel.............................50
23. Listing des employés de l’entreprise.............................................................................51
24. Listing des différents contacts des clients de l’entreprise.............................................51
25. Listing des prestations de webmastering des clients.....................................................52
26. Présentation de la fonctionnalité d’envoi de lettres d’information...............................52
27. Aperçu du MCD de la base de données espace client..................................................53
28. MCD de la nouvelle base de données...........................................................................54
29. Page d’accueil de la documentation réalisée à l’aide de phpDocumentor....................55
30. Détail de la classe client de la documentation..............................................................55
31. Présentation d’un message de validation......................................................................56
32. Présentation d’un message d’erreur..............................................................................56
33. Présentation d’un message d’alerte...............................................................................56

38
 Annexes

1. Structure internationale d’ALCiiP

Présentation de la structure internationale d’ALCiiP

2. Présentation de mon travail quotidien chez ALCiiP

Durant cette année, ma principale mission en entreprise a été de maintenir à jour les
différents sites web des clients. Chez ALCiiP, pour la mission qui m’a été confiée, il y a deux
sortes de sites web : les sites web contenant des anciennes administrations, indépendant, et
ceux qui utilise l’administration centralisée.

Les sites web utilisant l’ancienne administration sont tous indépendant les uns des
autres, et possèdent chacun leur propre base de données. Il m’était demandé en général
d’ajouter de nouvelles fonctionnalités, de modifier celle qui ne fonctionnait plus, de mettre à
jour des données, de modifier des pages web…

Pour les sites utilisant l’administration centralisée, une seule et même base de données
est utilisées : l’espace client. Pour récupérer les informations contenues dans cette base sur les
différents sites, il a fallut créer des web services. J’ai donc participé à la création de ces web
services. Une fois cela mis en place, j’ai été chargé entre autre de créer des nouveaux clients,
leur associé des contacts, créer leurs sites web, créer les différents menu permettant de gérer
le contenu de leurs sites, mettre en place les systèmes permettant de générer les statistiques,
exporter leur données aux format excel,… Aucune administration n’était prévue pour cela, les
modifications étaient donc directement effectuées depuis navicat. Une administration sera
bientôt mise en place.

39
 Un autre travail que j’ai eu a effectué a été de préparé les sites web a être migrés sur
un nouveau serveur. En effet, les performances d’un des serveurs de l’entreprise commencait
a être de moins en moins bonne. Il a donc été choisit de migrer ses sites sur un nouveau
serveur. J’ai donc du récupérer les sites web qui étaient en production pour les tester sur le
serveur de développement. Comme le changement de configuration du serveur impacte sur la
plupart des sites, il y avait de nombreuses modifications à faire pour que ceux-ci soit prêt à
être migré. Une fois prêts, l’administrateur réseau était chargé de faire le reste du travail, c'est-
à-dire mettre le site sur le nouveau serveur.

3. Zone d’identification pour les clients

Accès à l’application depuis le site d’ALCiiP (à gauche) ou directement depuis l’url (à droite)

4. Zone d’identification pour les employés d’ALCiiP

Accès à l’application pour les employés d’ALCiiP

5. Listing des projets d’un client

40
 Liste des différents projets d’un client

6. Listing des tâches d’un projet

Liste des tâches d’un projet

7. Listing des demandes effectuées par un client

Liste des demandes émises par le client

41
8. Détails d’une demande

Détail et historique d’une demande

9. Ajout d’une demande par le client

Formulaire permettant au client d’effectuer une nouvelle demande

42
10. Listing des prestations de webmastering

Liste des prestations de webmastering en cours et archivées pour le client

11. Modification des informations personnelles

Formulaire permettant au client de modifier ses informations

43
12. Page d’accueil de l’application pour les employés de l’entreprise

Liste des dernières tâches qui ont été validées par le client

13. Listing des clients de l’entreprise

Liste de tous les clients de l’entreprise

44
14. Détails des informations concernant un client

Informations complètes concernant le client

45
15. Ajout d’un nouveau client

46
Formulaire permettant aux employés d’ALCiiP d’ajouter de nouveaux clients

47
16. Modification du logo d’un client

Formulaire permettant de modifier le logo d’un client

17. Listing des comptes mails d’un client

Liste et détails des comptes mail et demande de compte mail pour un client

48
18. Listing des projets des clients de l’entreprise

Listes de tous les projets

19. Listing et détails des tâches d’un projet

Détail des tâches d’un projet

49
20. Listing des demandes effectuées par un client

Demandes de modification effectuée par un client

21. Listing des prestations d’hébergement des clients

Liste des différentes prestations d’hébergement d’un client

22. Export des prestations d’hébergement sous forme de fichier excel

Fichier excel contenant les informations des différents webmastering de tous les clients

50
23. Listing des employés de l’entreprise

Liste de tous les employés de l’entreprise

24. Listing des différents contacts des clients de l’entreprise

Liste de tous les contacts des clients de l’entreprise

51
25. Listing des prestations de webmastering des clients

26. Présentation de la fonctionnalité d’envoi de lettres d’information

Formulaire permettant l’envoi de lettres d’information aux clients

52
27. Aperçu du MCD de la base de données espace client

Apercu du Model Conceptuel de Données de la base espace client

53
28. MCD de la nouvelle base de données

Model Conceptuel de Données de la base espace client final

54
29. Page d’accueil de la documentation réalisée à l’aide de phpDocumentor

Page d’accueil de la documentation générée à l’aide de PhpDocumentor

30. Détail de la classe client de la documentation

Détails de la classe client

55
31. Présentation d’un message de validation

Message de validation suite à une action qui s’est correctement déroulée

32. Présentation d’un message d’erreur

Message d’erreur affiché suite à une action incorrecte

33. Présentation d’un message d’alerte

Message d’alerte suite à une action qui ne s’est pas terminée correctement

56
 Résumé

Entreprise en pleine croissance, ALCiiP à pour principal objectif de réaliser des

solutions web performantes et à la pointe de la technologie. Pour cela, elle a constamment
besoin d’améliorer ses propres outils de gestion et d’administration de clients.

Le CRM qu’elle a développé lui permet une gestion totale de ses clients et de leurs
projets. Il permet également de gérer les contacts, les demandes des clients, les prestations que
ceux-ci ont choisis, leurs hébergements, leurs sites web et les mots clefs permettant le
référencement de ces derniers.

La mission qui m’a été confiée durant cette année a été de documenter et d’améliorer
cet outil, en le rendant indépendant, plus stable, plus uniforme et plus sécurisé. Conjointement
à cela, j’ai eu comme objectif d’effectuer les opérations de maintenance des sites web des
clients.

Mots clefs :

- Gestionnaire de relations client

- Analyse technique de l’application
- Amélioration de l’application

57