Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université de la Manouba
Institut Supérieur des Arts Multimédias

Projet qualité du logiciel

Réalisé par :
Siwar Grati
Oumaima Taghouti
Samia Bidah
Mariem Nsir

Encadré par : Mme. Sana Ben Abdallah

Année universitaire : 2021 / 2022

Table des matières
I. Présentation du site Evax : ...........................................................................................................1
1. Contexte général .............................................................................................................1
2. Etude de l’existant...........................................................................................................2
II. Questionnaire de recueil d’informations.......................................................................................3
1. Objectif ...........................................................................................................................3
2. Outil utilisé .....................................................................................................................3
3. Présentation des questions : .............................................................................................3
4. Analyse des résultats .......................................................................................................7
5. Solution proposé ........................................................................................................... 14
III. Métriques du projet ............................................................................................................... 15
1. Définition...................................................................................................................... 15
2. Outil utilisé ................................................................................................................... 15
3. Utilisation ..................................................................................................................... 15
IV. Métriques internes selon le standard 9126-3........................................................................... 19
1. Définition...................................................................................................................... 19
2. Choix des métriques à utiliser........................................................................................ 20
2.1 Métriques de fonctionnalité (Mesures de sécurité) ......................................................... 20
2.2 Métriques de maintenabilité : ........................................................................................ 23
2.3 Métriques de fiabilité : .................................................................................................. 23
2.4 Métriques d’éfficacité : ................................................................................................. 24
V. Métriques externes selon le standard 9126-2 .............................................................................. 34
1. Définition...................................................................................................................... 34
2. Choix des métriques à évaluer ....................................................................................... 34
2.1 Mesure de performance .................................................................................................. 34
2.2 Exactitude aux attentes .................................................................................................. 36
2.3 Précision ....................................................................................................................... 37
2.4 Test comportemental ..................................................................................................... 38
VI. Métriques du produit ............................................................................................................. 40
1. Définition :.................................................................................................................... 40
2. Choix des métriques à utiliser........................................................................................ 40
2.1 Métriques pour le modèle d’analyse : ............................................................................. 40
2.2 Métriques pour le modèle de conception : ...................................................................... 43
 2.3 Métriques pour le code source :...................................................................................... 47
2.4 Métriques de conception pour les WebApp ................................................................... 51
VII. Métriques de la qualité à l’utilisation selon 9126-4 standard ................................................. 55
1. Définition...................................................................................................................... 55
2. Choix des caractéristiques à utiliser ............................................................................... 56
2.1 Efficacité : ..................................................................................................................... 56
2.2 Sécurité......................................................................................................................... 60
2.3 Productivité : ................................................................................................................. 64
VIII. Questionnaire de satisfaction ................................................................................................ 73
1. Objectif ......................................................................................................................... 73
2. Analyse des résultats ..................................................................................................... 73

Liste des figures

Figure 1 : Interface Page d’accueil du site EVAX actuel......................................................................1
Figure 2: Interface Page d’inscription citoyen du site EVAX actuel .....................................................1
Figure 3: Question 1 du questionnaire de recueil .................................................................................3
Figure 4:Question 2 du questionnaire de recueil ..................................................................................4
Figure 5:Question 3 du questionnaire de recueil ..................................................................................4
Figure 6: Question 3.1 du questionnaire de recueil ..............................................................................4
Figure 7:Question 4 du questionnaire de recueil ..................................................................................5
Figure 8: Question 5 du questionnaire de recueil .................................................................................5
Figure 9:Question 6 du questionnaire de recueil .................................................................................6
Figure 10:Question 7 du questionnaire de recueil ................................................................................6
Figure 11: Question 8 du questionnaire de recueil ...............................................................................7
Figure 12:Réponses de la question 1 ...................................................................................................7
Figure 13: Réponses de la question 2.1 ...............................................................................................8
Figure 14: Réponses de la question 2.2 ................................................................................................8
Figure 15: Réponses de la question 2.3 ................................................................................................8
Figure 16:Réponses de la question 2.4.................................................................................................8
Figure 17: Réponses de la question 3...................................................................................................9
Figure 18: Réponses de la question 4...................................................................................................9
Figure 19: Réponses de la question 5................................................................................................. 10
Figure 20: Réponses de la question 6................................................................................................. 11
Figure 21: Réponses de la question 7 ................................................................................................ 12
Figure 22: Réponses de la question 8................................................................................................. 13
Figure 23: Réponses de la question 9................................................................................................. 14
Figure 24: Tableau jira v2 ................................................................................................................. 17
Figure 25: Tableau jira v1 ................................................................................................................. 17
Figure 26:Tableau jira v3 .................................................................................................................. 17
Figure 27:Timesheet tracking for jira ................................................................................................ 18
Figure 28: Tableau de bord statistique de temps par membre ............................................................. 18
Figure 29: Les six axes des métriques internes .................................................................................. 19
Figure 30:Vulnérabilités du projet Evax ............................................................................................ 22
Figure 31:security hotspot du projet Evax ......................................................................................... 22
Figure 32:code smell du projet evax .................................................................................................. 23
Figure 33: bugs du projet EVAX ....................................................................................................... 23
Figure 34: Quality gant ..................................................................................................................... 24
Figure 35: Tester site evax avec JMeter ............................................................................................. 25
Figure 36:Rapport HTML du test site evax........................................................................................ 26
Figure 37: Tableau des erreurs .......................................................................................................... 26
Figure 38: Top 5 erreurs par échantillonneur ..................................................................................... 27
Figure 39:Statistiques du test Evax .................................................................................................... 28
Figure 40:Aperçu du temps de réponse pour site evax ....................................................................... 29
Figure 41:Test jmeter pour Nouveau site ........................................................................................... 30
Figure 42:Rapport HTML du test pour nouveau site evax .................................................................. 30
Figure 43:Tableau des erreurs pour nouveau site evax ....................................................................... 31
Figure 44:Top 5 erreurs par échantillonneur pour nouveau site evax .................................................. 31
Figure 45: Statistiques du test pour nouveau site evax ....................................................................... 31
Figure 46:Aperçu du temps de réponse pour nouveau site evax ......................................................... 32
Figure 47:Résultats de test Pingdom Tools 2 (ancien site) ................................................................. 35
Figure 48:Résultats de test Pingdom Tools 1 (ancien site) ................................................................. 35
Figure 49:Résultats de test Pingdom Tools 3 (ancien site) ................................................................. 35
Figure 50:Résultats de test Pingdom Tools 4 (ancien site) ................................................................. 35
Figure 51:Résultats de test Pingdom Tools 3 (nouveau site) ............................................................. 36
Figure 52:Résultats de test Pingdom Tools 3 (nouveau site) ............................................................. 36
Figure 53:Résultats de test Pingdom Tools 1 (nouveau site) ............................................................. 36
Figure 54:Résultats de test Pingdom Tools 2 (nouveau site) .............................................................. 36
Figure 55:Résultat du test du nouveau site......................................................................................... 37
Figure 56:Test de Précision (ancien site) ........................................................................................... 37
Figure 57:Test comportemental (ancien site) .................................................................................... 39
Figure 58:Test comportemental(nouveau site) .................................................................................. 39
Figure 59:classification des métriques produit .................................................................................. 40
Figure 60:remplissage des champs pour calculer le FP ...................................................................... 42
Figure 61:Résultat du point de fontion............................................................................................... 42
Figure 62:diagramme de classe ......................................................................................................... 44
Figure 63:Le metric Data Tables ........................................................................................................ 45
Figure 64:La vue histogramme .......................................................................................................... 45
Figure 65:Diagrammes de Kiviat....................................................................................................... 46
Figure 66:Vérification des règles de conception ................................................................................ 47
Figure 67:Total/Average Lines ........................................................................................................... 48
Figure 68:Histogramme de maintenabilité ......................................................................................... 49
Figure 69:maintenabilité du fichier citoyenetranger.js ....................................................................... 49
Figure 70:maintenabilité du fichier certif.js ....................................................................................... 50
Figure 71:Erreurs estimées dans l’implémentation............................................................................. 50
Figure 72:complexité ........................................................................................................................ 51
Figure 73: Evaluation des signaux web essentiels(1) ......................................................................... 53
Figure 74:Evaluation des signaux web essentiels(2) .......................................................................... 53
Figure 75:classification des caractéristiques de qualité à l’utilisation ................................................. 55
Figure 76:Interface de cypress ........................................................................................................... 57
Figure 77:Code du test de scénario home.js ...................................................................................... 57
Figure 78:Code du test du scénario login.js ....................................................................................... 58
Figure 79:Exécution du scénario de test ............................................................................................ 58
Figure 80:Redirection vers page d’accueil après l’authentification ..................................................... 59
Figure 81:Exécution finale ................................................................................................................ 59
Figure 82:Tableau de bord Synk........................................................................................................ 60
Figure 83: Vulnérabilité de génération du mot de passe ..................................................................... 61
Figure 84 : Best practises synk (risque1) ........................................................................................... 61
Figure 85:Vulnérabilité de génération d'allocation des ressources ...................................................... 62
Figure 86:Best practises synk (risque2) ............................................................................................. 62
Figure 87: Vulnérabilité de CSRF ..................................................................................................... 63
Figure 88:Best practises synk (risque3) ............................................................................................. 63
Figure 89:Mesures de productivité globale du site evax ..................................................................... 65
Figure 90:mesures de productivité globale du nouveau site evax ..................................................... 65
Figure 91:Performance du site Evax actuel ........................................................................................ 66
Figure 92:performance du nouveau site evax ..................................................................................... 66
Figure 93:Accessibilité du site evax actuel (erreurs) .......................................................................... 68
Figure 94:Accessibilité du site evax actuel (passed audits) ................................................................ 68
Figure 95:Accessibilité du nouveau site evax(errors) ......................................................................... 69
Figure 96:Accessibilité du nouveau site evax(passed audits )............................................................. 69
Figure 97:Best practices du nouveau site evax(errors) ....................................................................... 70
Figure 98:Best practices du nouveau site evax (audits passed) ........................................................... 71
Figure 99:SEO du site evax actuel (errors) ........................................................................................ 72
Figure 100:SEO du nouveau site evax (errors)................................................................................... 72
Figure 101: Question 1 (Enquête de satisfaction) ............................................................................... 73
Figure 102:Question 2.1 (Enquête de satisfaction) ............................................................................. 74
Figure 103:Question 2.2 (Enquête de satisfaction) ............................................................................ 75
Figure 104:Question 2.3 (Enquête de satisfaction) ............................................................................. 76
Figure 105:Question 2.4 (Enquête de satisfaction) ............................................................................. 77
Figure 106:Question 3 (Enqête de satisfaction) ................................................................................. 78
Figure 107:Question 4 (Enquête de satisfaction) ................................................................................ 78
Figure 108:Question 5 (Enquête de satisfaction) ............................................................................... 79
Figure 109:Question 7 (Enqête de satisfaction).................................................................................. 80
Figure 110:Question 7 (Enqête de satisfaction) ................................................................................. 81
I. Présentation du site Evax :
1. Contexte général
Le site Evax est une plateforme qui permet de planifier les rendez-vous de vaccination
contre la Covid-19 aux citoyens en Tunisie. Il propose des rendez-vous disponibles dans
votre département afin de vous faire vacciner.

Le site permet au visiteur de s’inscrire aux centres de vaccination / pharmacies en

remplissant ses informations personnelles / sanitaires afin de recevoir un message de
confirmation avec la date de son rendez-vous, il permet aussi aux pharmaciens de mettre
leurs pharmacies à la disposition des citoyens afin de vacciner.

Après avoir vacciné, le citoyen aura la possibilité de télécharger son passeport de

vaccination.

Figure 1 : Interface Page d’accueil du site EVAX actuel

Figure 2: Interface Page d’inscription citoyen du site EVAX actuel

1
2. Etude de l’existant
L’étude de l’existant est une phase importante pour bien comprendre le système adopté
actuellement, dégager les problématiques, et définir les objectifs à atteindre et les vrais
besoins. Donc, cette étape va nous permettre de partir du réel perçu, pour pouvoir
concevoir et réaliser la nouvelle version en fonction des objectifs et des besoins
globalement définis.

Cette étude nous a permis de dégager les fonctionnalités les plus importants du site qui
sont représentés dans le tableau ci-dessous :

Fonctionnalités
• Inscription au centre de vaccination
• Inscription à une pharmacie
• Ajout d’une formation
• Mettre à jour les informations du citoyen
• Valider l’inscription d’un citoyen
en envoyant un SMS (admin)
• Affecter un citoyen à un centre de
vaccination (admin)

• Reporter un rendez-vous • Valider la vaccination d’un

• Annuler un rendez-vous citoyen(admin)

• Extraire un passeport vaccinal • Gestion des centres de

• Ajouter une pharmacie en tant que centre vaccination (admin)

de vaccination • Gestion des rendez vous

Nous avons ainsi pu dégager les principales limites du site dont ci-après les plus
pertinentes :
 Mal organisation des pages
 Utilisation de plusieurs couleurs
 Absence d’un système de contact
 Absence du guide d’utilisation
 Lenteur du chargement des pages
 Inexactitude des informations

2
II. Questionnaire de recueil d’informations
1. Objectif
Afin de bien comprendre le besoin de l’utilisateur et de corriger les erreurs actuelles du
site Evax nous avons implémenté le questionnaire ci-dessous qui va nous aider à analyser
et à comprendre le comportement du nouveau site grâce aux données collectées.

2. Outil utilisé

Eval & Go : Un logiciel d’enquête en ligne simple, ergonomique et puissant qui va

révolutionner la façon dont vous communiquer avec vos clients et améliorer votre
business. L’application innovante d’Eval & GO fournit aux utilisateurs une solution
complète de sondage en ligne conçu pour la création d’enquêtes, l’analyse et les rapports
pour répondre aux besoins des entreprises.

3. Présentation des questions :

▪ Question 1 :
En premier lieu nous avons posé une question de type fermé à choix unique qui
nous permettra de segmenter notre base clients, ici on a utilisé la segmentation en
fonction de l’âge (19 ou moins, de 20 à 39 ans, de 40 à 59 ans, et plus de 65 ans)

Figure 3: Question 1 du questionnaire de recueil

3
▪ Question 2 :
La question suivante est de type matrice de questions à échelles verbales, ça
concerne principalement les critères de visibilité du site qui nous permettra de
savoir les aspects qu’on doit les améliorer au niveau de la nouvelle version.
Le choix des critères ci-dessous a été fait selon les aspects qui sont pris en compte
pour l’analyse d’un site web tel que le temps de réponse, l’arborescence du site, la
qualité du contenu et la pertinence des informations etc.

Figure 4:Question 2 du questionnaire de recueil

▪ Question 3 :
La 3éme question est de type fermé conditionné ”dynamique”. Elle consiste à
connaître les problèmes rencontrés lors de l’inscription.
Dans le cas où la réponse est “oui” il passe à une autre question qui est de type
ouvert dans lequel il va préciser son problème.

Figure 5:Question 3 du questionnaire de recueil

Si La réponse de la question 3 est « Oui » la question ci-dessous s’affichera :

Figure 6: Question 3.1 du questionnaire de recueil

4
▪ Question 4 :
La quatrième question est du type question fermée à choix unique, elle consiste à
vérifier si les interlocuteurs préfèrent l'idée de réception du code d'inscription par
SMS ou non.
Cette question va nous aider à décider si on ajoutera une nouvelle fonctionnalité à
notre site tel que l'envoi du code d'inscription par mail ou autre.
Tel que l’interlocuteur va rependre par oui, s’il est d'accord avec l'idée ou non.

Figure 7:Question 4 du questionnaire de recueil

▪ Question 5 :
La cinquième question est de type échelle de note, elle consiste à déterminer le
niveau de difficulté pour les citoyens de se procéder pour extraire leurs passeports
vaccinaux.
La question se compose d’une échelle comportant une plage de valeurs en guise
d'options de réponse allons 0 (très difficile) à 5 (très facile).
Cette question va nous aider à savoir la priorité de ce besoin dans la liste des
exigences fonctionnelles de la nouvelle version.

Figure 8: Question 5 du questionnaire de recueil

5
▪ Question 6 :
La sixième question est de type choix multiple standard qui comporte les
fonctionnalités qui peuvent être ajoutées pour améliorer le site.
L’interlocuteur choisit une ou plusieurs réponses ou il peut ajouter une autre
fonctionnalité non citée. Cette question va nous aider à implémenter la
fonctionnalité la plus recommandée.

Figure 9:Question 6 du questionnaire de recueil

▪ Question 7 :
La septième question est de type échelles illustrées par des pictogrammes, et celle
sert à qualifier la satisfaction globale des utilisateurs du site.
La place de la question de satisfaction globale ne doit pas être choisie au hasard.
Pour ressortir par rapport aux autres questions, elle doit être placée de préférence
au tout début, ou à la toute fin du questionnaire.
Sa réponse constitue en quelque sorte une synthèse des réponses précédentes.

Figure 10:Question 7 du questionnaire de recueil

6
 ▪ Question 8 :
Cette question est de type ouvert, elle est optionnelle. Elle va nous permettre de
recueillir des informations, des impressions et des suggestions intéressantes qu’on
peut les prendre en considération dans le nouveau site.

Figure 11: Question 8 du questionnaire de recueil

4. Analyse des résultats
Après avoir diffusé le questionnaire, dans 4 semaines nous avons cumulé 53 réponses
pour obtenir un rapport d’analyse statistique détaillé par l’outil utilisé, ci-dessous les
résultats par question

▪ Question 1 :

Figure 12:Réponses de la question 1

 Ce tableau montre que la grande majorité des utilisateurs du site sont des personnes
dont l’âge est entre 20 et 39 et qui représentent 60.38 %, ensuite des personnes dont
l’âge entre 40 et 59 qui représentent 35.85% et aussi un groupe de personnes dont
l’âge est moins de 19 ans qui représentent 3.77%

7
▪ Question 2 :

Figure 13: Réponses de la question 2.1

Figure 14: Réponses de la question 2.2

Figure 15: Réponses de la question 2.3

Figure 16:Réponses de la question 2.4

 Les tableau ci-dessus présentent le score minimal, maximal et moyen de réponses
pour chaque critère dans la matrice de questions à échelle

 Pour l’évaluation on s’intéresse aux valeurs moyenne qui sont comprises entre
1.28 et 2.11 d’où ils sont très bas.

 La conclusion extraite c’est l’insatisfaction des utilisateurs par la visibilité actuelle

du site

8
 ▪ Question 3 :

Figure 17: Réponses de la question 3

 Le
tableau ci-dessus montre que la majorité des utilisateurs n’ont pas eu un problème
lors de l’inscription (77.36% ont réussi à s’inscrire et 22.64 ont eu un problème)

▪ Question 4 :
En cas de problème les réponses sur la question « quel est ce problème » sont
comme suit :

Figure 18: Réponses de la question 4

 Les problèmes des visiteurs lors de l’inscription reçus sont tous notés afin de les éviter
dans la nouvelle version

9
▪ Question 5 :

Figure 19: Réponses de la question 5

 Les réponses cumulées sur cette question sont très proches 56.6 % ont répondu par oui
et 43.4 ont répondu par non.

 On peut conclure que presque la moitié ont eu un problème et l’autre moitié ont reçu
le SMS avec succès

10
▪ Question 6 :

Figure 20: Réponses de la question 6

 D’après le tableau ci-dessus on peut constater que la moyenne de l’évaluation de
l’extraction du passeport vaccinal est d’une valeur 1.21 / 5 qui représente un score très
bas.

 La plupart des personnes ont eu des difficultés lors de l’extraction de leurs passeports
vaccinales.

11
▪ Question 7 :

Figure 21: Réponses de la question 7

 En analysant les résultats de cette question on peut constater que 77.36% sont
intéressées par l’ajout de la confirmation par email, 52.83% sont intéressées par l’ajout
du chatbot, 33.96% sont intéressées par l’ajout du guide d’utilisation et 5 autres
suggestions sont reçus.

 Nous avons bien noté les propositions cumulées afin de les étudier

12
▪ Question 8 :

Figure 22: Réponses de la question 8

 D’après le tableau et la figure ci-dessus on peut conclure que la plupart des répondants
ont sélectionné l’emoji insatisfait (en rose) ce qui explique globalement leur
insatisfaction du site actuel

13
 ▪ Question 9 :

Figure 23: Réponses de la question 9

 Pour la dernière question qui est optionnelle, nous avons pu cumulé 9 réponses qui sont
présentés ci-dessus.

5. Solution proposé
Après avoir analyser les réponses à l’enquête et afin de pallier aux défaillances du site
actuel, nous proposons de reproduire le site avec une nouvelle version qui corrige les
erreurs existantes et ajoute les fonctionnalités manquantes qui se représentent comme
suit :

- Amélioration de l’organisation du site

- Amélioration de la côté visibilité
- Ajout de la confirmation de l’inscription par mail
- Ajout du chatbot (messagerie instantanée)
- Faciliter la procédure de l’extraction du passeport vaccinal
- La réduction des nombres de liens sur le menu principal

14
III. Métriques du projet
1. Définition
Les métriques du projet sont utilisées par un chef de projet et une équipe logicielle
pour adapter le flux de travail du projet et les activités techniques.

Ces métriques peuvent suivre et surveiller l'état du processus de développement en

aidant les gestionnaires à prendre les dispositions adéquates au cours du développement
du projet.

2. Outil utilisé

Jira Software fait partie d'une gamme de produits conçus pour aider les équipes de
tous types à gérer leur travail. À l'origine, Jira a été pensé comme un outil de suivi des
bugs et des tickets. Mais aujourd'hui, c'est devenu un puissant outil de gestion du
travail pour toutes sortes de cas d'usage, de la gestion des exigences et des cas de test
au développement logiciel Agile.

3. Utilisation
Un projet est un processus unique qui consiste en un ensemble d’activités coordonnées
et maîtrisées, comportant des dates de début et de fin, entrepris dans le but d’atteindre
un objectif conforme à des exigences spécifiques, incluant des contraintes de délais, de
coûts et de ressources.

Pour cela nous avons choisi d’utiliser l’outil jira qui permet de planifier et d’optimiser
la gestion de notre projet à travers le suivi et la coordination des travaux de ses
membres, le contrôle des flux d’informations ainsi que le respect des deadlines

15
Notre méthodologie du travail c’est SCRUM donc avant de commencer nous avons
diviser les besoins fonctionnels en 4 sprints :

Sprint1 Sprint2 Sprint3 Sprint4

Création des Création des Création des Api Développement
interfaces tableaux de bords pour toutes les pages du chatbot
(Front end) Admin et (Back end) (Front-end &
Visiteur Opérateur Visiteur back-end)

Dans cette section nous allons expliquer le déroulement du premier sprint

Après avoir créé le projet dans jira et ajouté l’équipe de développement en tant que
collaborateurs, nous avons créé le premier sprint tout en ajoutant nos exigences
fonctionnelles dans le backlog produit ensuite nous avons personnalisé notre tableau
pour le diviser en 4 colonnes :

▪ La première (To do issues) pour les tickets à développer

▪ La deuxième (In progress) pour les tickets qui sont en cours de développement
▪ La troisième (Test) pour les tickets qui sont en phase de test par les autres
membres de l’équipe
▪ La quatrième (Done) pour les tickets terminés

Les figures suivantes représentent différentes étapes des tickets développés dans notre
premier sprint du projet

16
 Figure 25: Tableau jira v1

Figure 24: Tableau jira v2

Figure 26:Tableau jira v3

17
Afin d’obtenir un aperçu rapide des journaux de travail ou de la durée des projets de
notre équipe. Nous avons ajouté l’extension Timesheet tracking for Jira

Figure 27:Timesheet tracking for jira

Ça nous a permis de gérer le Rapport de feuille de temps intuitif suivant

Figure 28: Tableau de bord statistique de temps par membre

18
 IV. Métriques internes selon le standard 9126-3

1. Définition
Les mesures internes sont des métriques qui peuvent être appliquées à un produit logiciel
non exécutable au cours de ses étapes de développement (comme la demande de
proposition, la définition des exigences, la spécification de conception ou le code source)
Ces permettent aux utilisateurs de mesurer la qualité des livrables intermédiaires et ainsi
de prédire la qualité du produit final. Cela permet à l'utilisateur d'identifier les problèmes
de qualité et de lancer des actions correctives le plus tôt possible dans le cycle de vie du
développement.

La figure suivante illustre les six axes des métriques internes.

Figure 29: Les six axes des métriques internes

Métriques de fiabilité : Les mesures de fiabilité internes sont utilisées pour prédire si le
produit logiciel en question satisfera les besoins de fiabilité prescrits, au cours du
développement du produit logiciel.

Métrique d’efficience : Les mesures d'efficience sont utilisées pour prédire l’efficience du
comportement du produit logiciel pendant les tests ou l'exploitation.

Métriques de portabilité : Les mesures de portabilité internes sont utilisées pour prédire
l'effet que le produit logiciel peut avoir sur le comportement de réalisateur ou du système
pendant l'activité de portage.

19
Métrique d’utilisabilité : Les mesures de la facilité d’utilisation sont pour prédire dans quelle
mesure le logiciel en question peut être compris, appris, exploité, attrayant et conforme aux
réglementations et directives d'utilisabilité.

Métrique de maintenabilité : Les mesures de maintenabilité internes sont utilisées pour

prédire le niveau d'effort requis pour modifier le produit logiciel.

Mesures de fonctionnalité : Les mesures de fonctionnalité interne sont utilisées pour prédire
si le produit logiciel en question satisfera aux exigences fonctionnelles prescrites et aux
besoins implicites des utilisateurs.

2. Choix des métriques à utiliser

2.1 Métriques de fonctionnalité (Mesures de sécurité)
- Méthode d’application : Les mesures de sécurité internes indiquent un ensemble
d'attributs pour évaluer la capacité du produit logiciel à éviter un accès illégal au
système et / ou aux données.

- Règle d’application : X = A / B A = Nombre d'exigences de contrôlabilité d'accès

mises en œuvre correctement comme dans les spécifications. B = Nombre
d'exigences de contrôlabilité d'accès dans les spécifications.

0 <= X <= 1 Le plus proche de 1, le plus contrôlable.

• Outil utilisé

SonarQube est un logiciel open-source développé par la société SonarSource.Cet

outil permet de mesure de la qualité du code source en continu, caractérisé par :

✓ Open source, gratuit

20
 ✓ Supporte plusieurs langages de programmations (25 langages de

programmation)

✓ Disponibilité de la documentation

✓ Fournit plusieurs métriques qui permettent de mesurer la qualité d’un code

source

● QU'EST-CE QU'ON PEUT FAIRE AVEC ?

✓ Respect des règles et normes du code
✓ Documentation du code
✓ Analyse des tests unitaires (couverture du code, etc.)
✓ Duplication du code
✓ Vulnérabilités potentielles (par degré d’importance : mineure, majeure,
bloquante)
✓ Génération de rapports

• Configuration de Sonar
Afin de pouvoir utiliser l’outil Sonar, il faut le configurer selon vos besoins. J’ai
consacré un temps considérable dans cette partie pour me familiariser avec l’outil
que je n’ai jamais utilisé avant ce projet. A l’installation Sonar fournit un
conteneur web embarqué qui permet de visualiser les résultats d’analyse (les
métriques), ainsi qu’une base de données embarquée Derby pour stocker ces
résultats. L’utilisation de cette base de données n’est pas recommandée.

1. Télécharger sonarQube : https://www.sonarqube.org/downloads/

2. Lancer SonarQube

3. Aller dans le navigateur pour accéder à l’interface web de sonarQube :

« localhost: 9000 »

• Utilisation

21
 Après avoir installé SonarQube, il faut installer le scanner sonar pour lancer le
scan dans n’importe quel projet, pour le faire il suffit :

1. Télécharger SonarQube Scanner

2. Modifier le fichier conf/sonar-scanner.properties

3. Sonar.host.url=http://localhost:9000

4. Sonar.sourceEncoding=UTF-8

5. Dans le projet à analyser (celui indiqué dans sonar.sources) créer à la racine un

fichier sonar-project.properties pour configurer l’analyse.

Vulnérabilité :

Pour tester la mesure de vulnérabilités, nous avons analysé notre projet avec l’outil
SonarQube. La figure ci-dessus montre que notre code ne présente pas de
vulnérabilités et le rating est A, c'est-à-dire que notre projet est en bon état

Figure 30:Vulnérabilités du projet Evax

La figure suivante illustre le security hotspot, comme montre l'image nous avons obtenu 1
security hotspot, il faut les régler pour obtenir une valeur 0.

Figure 31:security hotspot du projet Evax

22
2.2 Métriques de maintenabilité :
• Mesures de changeabilité

L’onglet Issues affiche les problèmes, la durée pour les résoudre et des
informations sur chaque problème : niveau de sévérité, type, tag.

Code smell: est un indice que quelque chose s'est mal passé quelque part dans
votre code.

Comme illustré dans la figure ci-dessous, après l’analyse de notre code avec
l’outil SonarQube, nous avons conclu que notre code contient 402 codes smell
et il faut les régler afin d’obtenir un code 100% maintenable.

Figure 32:code smell du projet evax

2.3 Métriques de fiabilité

• Mesures de maturité :

Bugs : Un bogue (bug) est un défaut de conception d'un programme

informatique à l'origine d'un dysfonctionnement. En consultant la figure ci-
dessus, nous constatons que notre code ne contient pas de bugs (Rating A)

Figure 33: bugs du projet EVAX

23
 Portails de qualité

Quality Gates applique une politique de qualité dans votre organisation en répondant
à une question : mon projet est-il prêt à être publié ?

Pour répondre à cette question, vous définissez un ensemble de conditions par rapport
auxquelles les projets sont évalués.

La figure suivante illustre l’état de notre projet et les conditions. Notre projet atteint
les mesures suivantes : la maintenabilité, fiabilité et sécurité. Pour la sécurité host
sports l'état de notre projet est faible par rapport à 100%.

Figure 34: Quality gates

2.4 Métriques efficacité (comportement temporel)

Outil utilisé

L’application Apache JMeter ™ est un logiciel open source, une application

Java 100% pure conçue pour tester le comportement fonctionnel et mesurer les
performances. Il a été conçu à l'origine pour tester les applications Web, mais s'est
depuis étendu à d'autres fonctions de test. Apache JMeter peut être utilisé pour
tester les performances à la fois sur des ressources statiques et dynamiques, des
applications Web dynamiques.

24
L'extension Blazemeter Chrome crée automatiquement depuis votre navigateur sans
avoir à configurer votre proxy des scripts de performance Selenium, JMeter et
synchronisés pour des tests combinés de chargement et d'interface graphique.

Ancien site web Evax

Le test suivant sera exécuté :
● 1 seul groupe de threads simultané
● 1 seconde de durée de montée en puissance

Figure 35: Tester site evax avec JMeter

Rapport HTML :
JMeter prend en charge la génération de rapports de tableau de bord pour obtenir des
graphiques et des statistiques à partir d'un plan de test.

Ce rapport est assez riche et affiche de nombreuses métriques différentes. Mais on va

se focaliser essentiellement dans cette partie au temps de réponse et au débit. Le
résumé du rapport contient les informations suivantes :

● Heure de début et heure de fin du test

● APDEX (Application Performance Index) obtient des scores pour chaque requête et
chaque conteneur

25
● Un graphique à secteurs nommé Récapitulatif des demandes qui donne la proportion
d'échantillons réussis / échoués.

Figure 36:Rapport HTML du test site evax

Le tableau d'erreurs ci-dessous récapitule toutes les erreurs et leur proportion dans le
total des demandes.

Figure 37: Tableau des erreurs

Le tableau des 5 premières erreurs par échantillonneur suivant fournissant pour chaque
échantillonneur (hors Transaction Controller par défaut) les 5 premières erreurs

26
 Figure 38: Top 5 erreurs par échantillonneur

Le tableau Statistiques fournit des statistiques de test globales pour chaque requête
unique qui a été exécutée :
● Exécutions : nombre de hits et d'erreurs
-# Samples : nombre total d'échantillons exécutés
-KO : le nombre total d'échantillons n'a pas pu s'exécuter
-Erreurs% : pourcentage d'erreurs

● Temps de réponse (ms) : temps de réponse en millisecondes

-Moyenne : temps écoulé moyen
-Min : temps écoulé minimum
-Max : temps écoulé maximum
- 90e PCT : 90e centile,
-95ème PCT : 95ème percentile
-99ème PCT : 99ème percentile,
-Throughtput : nombre de hits par seconde

● Réseau : débit en Ko / s
-Reçu : Ko reçus par seconde
-Envoyé : Ko envoyés par seconde

27
 Figure 39:Statistiques du test Evax

A- Temps de réponse

Moyenne : Dans notre cas, le temps moyen pour l'étiquette 2 https://priorite.evax.tn/ est de
2580 millisecondes et le temps moyen total est de 362.8 millisecondes sur 174 échantillons.

Max : Si nous regardons la valeur Max pour l'étiquette 2 https://priorite.evax.tn/ alors, sur
174 échantillons, le temps de réponse le plus long de ce dernier était de 5919 millisecondes.

Min : En regardant la valeur Min, sur 174 échantillons, le temps de réponse le plus court de
l'un des échantillons était de 55 millisecondes qui est attient dans le label
https://www.evax.tn/home.xhtml#inscription-9.

28
Le temps de réponse moyen varie entre 0.1 et 1.0 seconde.Si le temps de réponse est de 0,1,
les utilisateurs ont toujours le sentiment que l'application ou le système répond instantanément
et ne ressentent aucune interruption. Pour le temps de réponse égale à 1 seconde il est défini
comme la limite maximale et si le Le temps de réponse supérieur à 1 seconde peut
interrompre l'expérience utilisateur.

On peut conclure que globalement ce site a une performance acceptable liées au temps de réponse dont
le temps de réponse moyen est 362.8 qui est considéré un temps de réponse non élevé.

Ce graphique affiche la plage de temps de réponse des transactions au cours de l'ensemble du test.

Figure 40:Aperçu du temps de réponse pour site evax

On peut résumer que globalement ce site a des performances acceptables liées au temps de réponse
dont la majorité des requêtes ayant un temps de réponse non élevé et inférieure ou égale à 500ms.

B- Débit

Dans ce test, le débit moyen du serveur Evax est de 1.11 /S sur 174 échantillons. Cela signifie que le
serveur du site Evax peut traiter moyennement 1.11 requêtes par seconde par contre le débit atteint son
maximum de 23.26 /S avec le label https://priorite.evax.tn/-5. La valeur moyenne du débit n’est pas
assez élevée, nous pouvons donc conclure que le serveur Evax n’a pas des bonnes performances.

29
 Nouveau site web Evax

Le test suivant sera exécuté :

1 seul groupe de threads simultané
1 seconde de durée de montée en puissance

Figure 41:Test jmeter pour Nouveau site

4.2.1 Rapport HTML :

Figure 42:Rapport HTML du test pour nouveau site evax

30
 Figure 43:Tableau des erreurs pour nouveau site evax

Figure 44:Top 5 erreurs par échantillonneur pour nouveau site evax

Figure 45: Statistiques du test pour nouveau site evax

31
A. Temps de réponse

Moyenne : Dans notre cas, le temps moyen pour l'étiquette 2 http://localhost:3000/Visiteur/

est de 2162 millisecondes et le temps moyen total est de 134.35 millisecondes sur 57
échantillons.

Max : Si nous regardons la valeur Max pour l'étiquette 1 http://localhost:3000/Visiteur/,

alors, sur 57 échantillons, le temps de réponse le plus long de ce dernier était de 2162
millisecondes.

Min : En regardant la valeur Min, sur 57 échantillons, le temps de réponse le plus court de
l'un des échantillons était de 2 millisecondes .

Ce graphique affiche la plage de temps de réponse des transactions au cours de l'ensemble du

test.

Figure 46:Aperçu du temps de réponse pour nouveau site evax

On peut conclure que globalement ce site a des bonnes performances liées au temps de
réponse où presque la totalité des requêtes ayant un temps de réponse non élevé et inférieure
ou égale à 500ms.

Ce nouveau site est plus proche que l’ancien site en termes de temps de réponse.

32
b. Débit

Dans ce test, le débit moyen du serveur Evax est de 1.99 /S sur 57 échantillons. Cela signifie
que le serveur du site Evax peut traiter moyennement 1.99 requêtes par seconde c’est un débit
proche de celui de l’ancien site web.

La valeur moyenne du débit n'est pas assez élevée, nous pouvons donc conclure que le
nouveau serveur evax n'est pas des bonnes performances.

33
V. Métriques externes selon le standard 9126-2
1. Définition
La qualité des logiciels externes est une mesure de la façon dont le système dans son
ensemble répond aux exigences des parties prenantes. Le système fournit-il la
fonctionnalité requise ? L'interface est-elle claire et cohérente ? Le logiciel fournit-il la
valeur commerciale attendue.

2. Choix des métriques à évaluer

La qualité du temps de chargement

➔ Performance

➔ Exactitude aux attentes

➔ Précision

➔ Test de comportement temporel

2.1 Mesure de performance

Définition

Les tests de performance (et de charge) ont pour principal objectif la validation
d'une solution logicielle et de son architecture sous-jacente liées à une utilisation
simultanée multi-utilisateurs, permettant ainsi d'éviter certains problèmes en
production. Ils permettent de garantir une qualité de service applicative dans des
conditions réelles d'utilisation.

Outil utilisé

Pingdom Tools est un outil d’analyse d’un site web. L’outil l’analyse, détecte les
problèmes et vous livre un rapport circonstancié. Tous les tests sont réalisés avec
de vrais navigateurs web, donc les résultats correspondent exactement à
l’expérience de l’utilisateur final. Les tests sont effectués à partir de serveurs
Pingdom dédiés situés aux quatre coins du monde.

34
 Résultats de test Pingdom Tools:
• Ancien site evax
Pour l’ancien site, on a une performance grade à 99 % pour une page de taille
77.8 KB pour les quatre coins et dans 1.05s à 3.86s pour 3 requêtes

Figure 48:Résultats de test Pingdom Tools 1 (ancien site) Figure 47:Résultats de test Pingdom Tools 2 (ancien site)

Figure 49:Résultats de test Pingdom Tools 3 (ancien site)

Figure 50:Résultats de test Pingdom Tools 4 (ancien site)

35
 • Notre site

Pour notre site, on a une performance grade à 73 % pour une page de taille 40.3KB
pour les quatre coins et dans 8.03s à 2.87s pour 121 requêtes

Figure 53:Résultats de test Pingdom Tools 1 (nouveau site) Figure 54:Résultats de test Pingdom Tools 2 (nouveau site)

Figure 52:Résultats de test Pingdom Tools 3 (nouveau site) Figure 51:Résultats de test Pingdom Tools 3 (nouveau site)

2.2 Exactitude aux attentes

Définition
L’exactiude aux attentes sert à produire des cas de test et comparer la sortie aux
résultats attendus raisonnables.

Les différences entre les résultats attendus réels et raisonnables sont-elles acceptables?

Outils utilisé

SmartMeter est un outil de test de performances fiable capable de gérer de lourdes

charges, de soumettre le système à des tests approfondis et de fournir des résultats
précis sans aucune distorsion. Il génère des rapports de test d’un scénario.
36
 Résultat du test
Nous avons lancé le test avec 10 utilisateurs par minute et nous avons eu des
résultats réels acceptables Les captures ci-dessous indiquent le test.

Figure 55:Résultat du test du nouveau site

2.3 Précision
Définition
La mesure de la fréquence d’une précision insuffisante que les utilisateurs finaux
rencontrent en enregistrant le nombre de résultats avec une précision insuffisante
en se basant sur un rapport.

Résultat
Ces deux figures représentent le rapport des requêtes de l’ancien site evax et de
notre site. Ils nous offrent plusieurs informations comme le temps, nb requêtes
totales, nb requêtes avec succès et nb requêtes avec échecs avec certaines
caractéristiques. Ces informations nous permettent ainsi de calculer la précision de
chaque site et les comparer.
• Ancien site evax

Figure 56:Test de Précision (ancien site)

Calcul précision : X=A/T
37
Avec T= 10min, A= nb requêtes totale - nb requêtes succès= 9 - 3 = 6
donc, X= 6 / 10 = 0.6

Notre site

• Calcul précision :
T= 10min, A = nb requêtes totales - nb requêtes succès = 9 - 4 = 5
X =A / T = (9-4) / 10 = 0,5

• Comparaison

Alors, puisque plus la valeur de présicion X est plus proche de 0 est plus mieux, on
remarque que la présicion de notre site à une valeur de présicion qui est ègale à 0.5
meilleur que l’ancien site qui est égale à 0.6.

2.4 Test comportemental

Définition

Le test de comportement temporel indique un ensemble d'attributs pour prédire le

comportement temporel du système informatique pendant le fonctionnement

38
Résultat de test :

Cette capture représente le résultat de l’ensemble des requêtes exécutées pour

chaque requête.

Ancien site evax

Figure 57:Test comportemental (ancien site)

Notre site

Figure 58:Test comportemental(nouveau site)

39
VI. Métriques du produit
1. Définition :
Les métriques du produit sont des mesures du produit logiciel à n'importe quel stade
de son développement, des exigences au système installé. Les métriques du produit
peuvent mesurer :

• La complexité de la conception du logiciel

• La taille du programme final

• Le nombre de pages de documentation produites

Les métriques produites sont classées comme suit

Figure 59:classification des métriques produit

2. Choix des métriques à utiliser

2.1 Métriques pour le modèle d’analyse :
Définition

Elles traitent de divers aspects du modèle d'analyse, tels que la fonctionnalité du

système, la taille du système.

La taille agit comme un indicateur d'un effort accru de codage, d'intégration et de

test parfois, il agit également comme un indicateur de la complexité impliquée dans
la conception du logiciel. Le point de fonction et les lignes de code sont les méthodes
couramment utilisées pour l'estimation de la taille.

40
 Calcul du Point de fonction :

Proposé par Albrecht en 79, Les Points de Fonction sont une norme standard (ISO
14143). Ils permettent de mesurer objectivement la quantité de logiciel existante ou
à produire.

Pour calculer PF, il faut déterminer à partir d'une certaine représentation du logiciel,
le nombre d'éléments des types suivants :

▪ Entrées externes : Eléments de données fournis par l'utilisateur.

Visiteur Administrateur
❖ Les informations du visiteur qui veut ❖ Les informations des opérateurs
s’inscrire (nom, prénom, CIN, date de ❖ Les informations des centres de
naissance, téléphone…) vaccination
❖ Les informations du vaccin
❖ Les informations des pharmacies
❖ Les informations des journées portes
(nom pharmacie, adresse, propriétaire
ouvertes
…)
❖ Les informations des volontaires
❖ Formulaire de contact

▪ Sorties externes : Eléments de données fourni à l'utilisateur

❖ Le code d’inscription de visiteur

❖ Attestation de vaccination

❖ Un mail d’affectation pour un rendez-vous de vaccination

❖ Rapport statistique

▪ Interrogations : Entrées Interactives exigeant une réponse.

❖ Requête de réponse aux questions des visiteurs

❖ Requête sur le code d’inscription

❖ Requête sur l’attestation de vaccin

❖ Requête sur les informations des rendez-vous

41
▪ Dépôts externes : Interfaces compréhensibles par une machine avec d'autres
systèmes.
❖ Message d’aide de chatbot.
▪ Dépôts internes : Fichiers principaux logiques dans le système.
❖ Notre base de données

Outil de calcul de point de fonction

Pour le calcul de nos valeurs de points de fonction, nous avons utilisé l'outil « Tiny
Tools » .

Figure 60:remplissage des champs pour calculer le FP

Figure 61:Résultat du point de fontion

42
À-partir de cette valeur générée, on peut estimer les charges des projets :

L’analyse de la performance :

- Productivité = nombre de points de fonctions/nombre de jours-hommes

= 97.9/60=1.6316
- Cout= nombre de K$ dépensés/nombre de points de fonction

- Réactivité = nombre de points de fonction / durée du projet

= 97.9/90 = 1.08777777778

- Qualité= nombre d’anomalies / nombre de points de fonction

2.2 Métriques pour le modèle de conception :

Définition : Elles permettent aux ingénieurs logiciels d'évaluer la qualité de la
conception et d'inclure des métriques de conception architecturale, des métriques
de conception au niveau des composants.
Le succès d'un projet logiciel dépend en grande partie de la qualité et de l'efficacité
de la conception du logiciel. Par conséquent, il est important de développer des
métriques logicielles à partir desquelles des indicateurs significatifs peuvent être
dérivés.
Afin d’analyse la structure de notre diagramme de classe, nous avons utilisées
SDMetrics comme un outil de mesure de la qualité de conception OO pour
l'UML.SDMetrics Mesure tous les attributs de conception taille, couplage,
complexité…

43
 La première version de diagramme de classe de notre site web evax, se présente comme
suit :
Outil utilisé

Figure 62:diagramme de classe

SD Metrics : C’est un outil de mesure de la qualité de conception OO pour

UML.SDMetrics analyse la structure de vos modèles UML.

Utilisation
Suite à l’installation de notre outil à partir de son site officiel :
https://www.sdmetrics.com/Downloads.html, on introduit à notre logiciel comme source
file un fichier XMI qui correspond à notre diagramme de classe.

L’outil SDMetrics nous affiche les résultats suivant :

• Le metric Data Tables :

Ce tableau affiche pour chaque classe une liste des métriques prenons comme
exemple :
❖ NumAttr: définit le nombre d'attributs dans une classe, cette métrique
appartienne à la catégorie Taille, on a par exemple 11 attributs dans la classe
pharmacies alors que 2 attributs dans la classe vaccin.
44
 ❖ NOC: définit Le nombre d'enfants d’une classe cette métrique appartiennent à la
catégorie Héritage on a par exemple la classe personne contienne 3 enfants
admin, visiteur et opérateur.
❖ EC_Attr: définit Le nombre de fois que la classe est utilisée en externe comme
type d'attribut cette métrique appartienne à la catégorie accouplement (export),
on a par exemple la classe pharmacies est utilisé deux fois comme type d’attribut
externe alors que la classe vaccins est 4 fois utilisé comme type d’attribut externe.

Figure 63:Le metric Data Tables

• La vue histogramme nous permet de parcourir rapidement les histogrammes et les

graphiques de distribution cumulée pour toutes les métriques, pour avoir une idée des
distributions des métriques et identifier visuellement les valeurs aberrantes possibles.

Figure 64:La vue histogramme

 La vue histogramme définit la répartition de nombre d'attributs dans la classe.

• Diagrammes de Kiviat :

45
 Le diagramme montre les valeurs de mesure de toutes les métriques pour l'élément
sélectionné. Chaque axe du graphique représente une métrique, comme indiqué dans le
graphique.

Figure 65:Diagrammes de Kiviat

La ligne épaisse relie les valeurs métriques de l'élément sélectionné pour chaque métrique sur
les axes. Si l'élément a de nombreuses grandes valeurs, la zone délimitée par la ligne épaisse
sera grande. Ainsi, la taille de la zone fermée sert d'indicateur de la criticité de l'élément.

Comme présenté dans la figure précédente de Diagramme de Kiviat de notre diagramme montre
que deux métriques sont mesurées au niveau de la classe pharmacies NumAttr et EC_Attr.

• Vérification des règles de conception :

Le vérificateur de règles de conception répertorie toutes les violations détectées des

règles de conception. Donc nous pouvons trier rapidement la liste par élément violant,
règle violée, gravité ou catégorie de la règle violée.

46
 Figure 66:Vérification des règles de conception

Parmi les règles qu’on n’a pas respectées dans la première version de notre diagramme de
classe :

- Les noms de classe doivent commencer par une majuscule.

- La classe définit une propriété du même nom qu'un attribut hérité : cette erreur est générée
pour les deux classe admin et operateur pour l’attribut rôle.

2.3 Métriques pour le code source :

Définition :
Les métriques du code source sont des composants essentiels du processus de mesure du
logiciel. Ils sont extraits du code source du logiciel, et leurs valeurs nous permettent de
tirer des conclusions sur les attributs de qualité mesurés par les métriques.

Outil utilisé :

PLATO : Outil pour mesurer cette métrique Ts-plato : permet de visualiser quelques
métriques des sources JavaScript / TypeScript des composants sur un rapport avec Plato.

Cet outil est installé localement dans le projet à partir de la commande :

47
 Et puis on a ajouté le code suivant de partie ” scripts” au niveau de fichier package.json

La Commande d’Exécution :

Et finalement pour consulter le rapport généré, on ouvre le dossier report et puis

index.html dans le navigateur.

En premier temps le rapport nous affiche le Nombre des lignes totales de notre projet
tel que la partie front-end est composé de 8782 sloc et le nombre de lignes moyen du
nôtre projet est 81 sloc.

Figure 67:Total/Average Lines

• Histogramme de maintenabilité :

La difficulté avec laquelle un système logiciel peut être modifié est connue sous le nom
de maintenabilité. La maintenabilité d'un système logiciel est déterminée par les
propriétés de son code source.

48
 Les types de maintenance logicielle :

- Les bogues sont découverts et doivent être corrigés.

- Le système doit être adapté aux changements de l'environnement dans lequel
il fonctionne

Figure 68:Histogramme de maintenabilité

 Le taux de maintenabilité de notre code varie entre 60.41 et 100, il existe des
fichiers qui comportent un score de maintenance maximal de valeur 100 comme le
fichier CitoyenEtranger.js.

Figure 69:maintenabilité du fichier citoyenetranger.js

Alors que le fichier Certif.js présente le score de maintenance le plus faible dont la
valeur est 60.41, cela est causé par les erreurs qui sont estimés à 0.71

49
 Figure 70:maintenabilité du fichier certif.js

• Histogramme des Erreurs estimées dans l’implémentation :

Lors de l’implémentation d’un code, différents types d’erreurs peuvent survenir.

Il y a les erreurs syntaxiques : elles sont détectées par le compilateur car elles ne
respectent pas la syntaxe prévue par le langage, ce sont les erreurs de déclaration, de
notations des instructions (points-virgules.).

Les erreurs sémantiques : ces erreurs ne sont pas détectées par le compilateur ! Elles
correspondent à des erreurs logiques dans la signification de la suite des instructions (ce
que fait le programme).

Figure 71:Erreurs estimées dans l’implémentation

 Grâce à cet histogramme, on peut constater que le taux d’erreur est faible, puisque le
taux d’erreur estimé à l’implémentation varie n’a pas dépassé 3. Donc on a réussi à
minimiser nos erreurs.

50
Ts-plato fournit aussi le nombre de lignes par composant, on prend par exemple le
composant index.js qui a 82 Sloc, le composant CitoyenActions.js a 151 Sloc et le
composant maj_inscription.js a 337 Sloc.

Figure 72:complexité

2.4 Métriques de conception pour les WebApp

Définition :

Un ensemble des métriques utiles pour les applications Web, fournit des réponses
quantitatives aux plusieurs questions comme :

1. L'interface utilisateur favorise-t-elle la convivialité ?

2. Le contenu est-il conçu de manière à transmettre le plus d’informations avec le
moindre effort ?

3. La navigation est-elle efficace et simple ?

4. Les composants sont-ils conçus de manière à réduire la complexité des procédures et

à améliorer l'exactitude, la fiabilité et les performances ?

Les métriques esthétiques :

Les métriques de cette catégorie sont utiles pour évaluer l'impact de la conception
esthétique.

51
Nous avons utilisé Google PageSpeed comme outil pour mesurer cette métrique.

Google PageSpeed : analyse l’URL et fournit un rapport détaillé, prenant en compte les
3 trois Core Web Vitals, c’est-à-dire : Le First Contentful Paint FCP, Largest Contentful
Paint LCP, First Input Delay FID et Cumulative Layout Shift CLS qui évalue son
interactivité et sa stabilité visuelle.

First Contentful Paint (FCP) : mesure le temps écoulé entre le début du chargement de
la page et le moment où une partie du contenu de la page est affichée à l'écran. Pour
cette métrique, le « contenu » fait référence au texte, aux images. Pour offrir une bonne
expérience utilisateur, les sites doivent s'efforcer d'avoir une première peinture de
contenu de 1,8 seconde ou moins.

Largest Contentful Paint (LCP) : indique le temps de rendu de la plus grande image ou du plus
grand bloc de texte visible dans la fenêtre, par rapport au moment où la page a commencé à se
charger. Pour offrir une bonne expérience utilisateur, les sites doivent s'efforcer d'avoir la
plus grande peinture de contenu de 2,5 secondes ou moins.

First Input Delay (FID) : mesure le temps écoulé entre le moment où un utilisateur
interagit pour la première fois avec une page jusqu'au moment où le navigateur est
réellement en mesure de commencer à traiter les gestionnaires d'événements en réponse
à cette interaction. Pour offrir une bonne expérience utilisateur, les sites doivent s'efforcer
d'avoir un délai de première entrée de 100 millisecondes ou moins.

Cumulative Layout Shift (CLS) : ne mesure de la plus grande rafale de scores de changement
de mise en page pour chaque changement de mise en page inattendu qui se produit pendant toute
la durée de vie d'une page. Pour offrir une bonne expérience utilisateur, les sites doivent
s'efforcer d'avoir un score CLS de 0,1 ou moins.

52
 Figure 73: Evaluation des signaux web essentiels(1)

Le site evax présente une évaluation moyenne pour ECP et CLS alors que les deux
mesures LCP et FID nt une évaluation satisfaisante.

Figure 74:Evaluation des signaux web essentiels(2)

53
Parmi les règles à respecter pour améliorer la performance d’une page :

- Les ressources textuelles doivent être servies avec une compression pour minimiser le
nombre total d'octets du réseau.

- Réduire l'impact des URL bloquant le rendu en insérant les ressources critiques, en
différant les ressources non critiques et en supprimant tout ce qui n'est pas utilisé, on
peut utiliser Chrome DevTools pour identifier les CSS et JS non critiques.

- Réduisez les règles inutilisées des feuilles de style.

54
VII. Métriques de la qualité à l’utilisation selon 9126-4 standard
1. Définition
La qualité à l'utilisation mesure le degré d'excellence, et peut être utilisée pour valider
la mesure dans laquelle le logiciel répond aux besoins de l'utilisateur dans son
environnement de travail.

Le modèle de qualité à l’utilisation est composé de quatre caractéristiques qui se

rapportent au résultat de l'interaction lorsqu'un produit est utilisé dans un contexte
particulier. Ces caractéristiques sont comme suit :

Figure 75:classification des caractéristiques de qualité à l’utilisation

L'efficacité correspond à la « capacité du produit logiciel à permettre aux utilisateurs d'atteindre

des objectifs spécifiés avec exactitude et exhaustivité dans un contexte d'utilisation spécifique
».

La productivité correspond à la « capacité du produit logiciel à permettre aux utilisateurs

d'employer des quantités appropriées de ressources en relation avec l'efficacité accomplie dans
un contexte d'utilisation donné ».

La sécurité correspond à la « capacité du produit logiciel à atteindre des niveaux acceptables

de risque de danger pour les personnes, L'activité, le logiciel, la propriété ou L'environnement
dans un contexte d'utilisation spécifique ».

La satisfaction correspond à la « capacité du produit logiciel à satisfaire les utilisateurs dans

un contexte d'utilisation spécifique ».

55
2. Choix des caractéristiques à utiliser
Dans cette section nous allons présenter les caractéristiques de la qualité à l’utilisation
qu’on a pu les réaliser.

2.1 Efficacité :
Pour tester l’efficacité de notre logiciel nous avons utilisé Cypress qui permet de
tester le rendu et les actions utilisateurs de l'application à l'aide de scénarios.

Cypress : est un outil pour les développeurs, les lead-developers et les testeurs. Il
permet de créer des scénarios de tests, puis de les jouer sur différents navigateurs
de différentes versions. Cet outil permet donc de tester des applications / services
Web.
Les étapes qu’on a suivi pour appliquer ces tests sont comme suit :

Installation :
Pour installer Cypress sur notre projet, nous avons juste d’exécuter à la racine de notre
projet cette commande :

Utilisation

Une fois l’installation terminée, on va ajouter une commande dans le

champ scripts du package.json.

Pour pouvoir directement utiliser la commande :

56
 Cette commande va nous permettre de démarrer l’interface d’exécution de tests de
Cypress. Comme vous pouvez le voir sur la photo ci-dessous, des fichiers de tests
sont affichés sur l’interface de Cypress.

Figure 76:Interface de cypress

• Le premier test appelé « homepage.js » c’était le chargement de la page d’accueil

pour le visiteur

Figure 77:Code du test de scénario home.js

57
 • Le deuxième appelé « login.js » c’est pour tester le scénario de connexion pour
l’administrateur.

Figure 78:Code du test du scénario login.js

En exécutant le test on obtient le résultat suivant :

Figure 79:Exécution du scénario de test

58
Figure 80:Redirection vers page d’accueil après l’authentification

Figure 81:Exécution finale

59
 On peut valider maintenant l’efficacité du scénario de connexion

2.2 Sécurité
Définition
Les mesures de sécurité évaluent le niveau de risque de préjudice pour les personnes,
les entreprises, les logiciels, les biens ou l'environnement dans un contexte
d'utilisation spécifique. Elle comprend la santé et la sécurité de l'utilisateur et des
personnes concernées par l'utilisation, ainsi que les conséquences physiques ou
économiques involontaires.
Outil utilisé

Synk est une plateforme qui aide les développeurs à identifier les vulnérabilités et
les violations de licence dans leurs bases de code open source, conteneurs et
applications Kubernetes. En connectant leur référentiel de code, que ce soit
GitHub, GitLab ou Bitbucket, les clients de Snyk ont accès à une base de données
de vulnérabilités géante, qui permet à Snyk de décrire le problème, d'indiquer où se
trouve la faille dans le code et même de suggérer un correctif.

Utilisation
Pour commencer nous avons accéder à la plateforme, nous avons fait la liaison
avec Github en choisissant le repo sur lequel nous allons travailler pour obtenir le
tableau de bord suivant :

Figure 82:Tableau de bord Synk

60
En accédant à code analysis, on obtient un rapport contenant les vulnérabilités de
notre application avec un niveau de sévérité (élevé, moyenne ou faible) ainsi un
score de priorité pour rendre la hiérarchisation des problèmes aussi rapide et facile
que possible, garantissant que les problèmes les plus risqués ont le score le plus
élevé.

Risque 1

Ci-dessus l’exemple d’affichage de la première vulnérabilité :

Figure 83: Vulnérabilité de génération du mot de passe

 Le code ci-dessus présente un risque de sévérité élevé et d’un score de

806/1000
 Le problème indiqué ici est appelé « Hardcoded secret » qui concerne la
génération automatique des mots de passe, mais ces mots de passe sont
particulièrement dangereux car ils constituent des cibles faciles pour les exploits
de devinette de mots de passe.

Cet outil permet aussi de proposer une solution pour chaque risque en cliquant
sur détails et on obtient l’interface suivante

Figure 84 : Best practises synk (risque1)

61
Risque 2

La deuxième vulnérabilité que l’outil a indiquée est comme suit :

Figure 85:Vulnérabilité de génération d'allocation des ressources

 Le code ci-dessus présente un risque de sévérité Moyenne et d’un score de
597/1000

 Le problème indiqué ici est appelé « Allocation Of ressources without limits

Throttling », ce risque apparaît lorsque on alloue une ressource réutilisable ou un
groupe de ressources au nom d'un acteur sans imposer de restrictions sur le
nombre de ressources pouvant être allouées, en violation de la politique de
sécurité prévue pour cet acteur.

 Pour résoudre ce risque l’outil a proposé la solution suivante

Figure 86:Best practises synk (risque2)

62
Risque 3

Le troisième risque affiché se présente comme suit :

Figure 87: Vulnérabilité de CSRF

 Le code ci-dessus présente un risque de sévérité Moyenne et d’un score de

552/1000

 Le problème indiqué ici est appelé « Cross-site Request Forgery(CSRF) »,qui

est une attaque qui oblige un utilisateur final à exécuter des actions indésirables
sur une application Web dans laquelle il est actuellement authentifié. Avec un peu
d'aide d'ingénierie sociale (comme l'envoi d'un lien par e-mail ou par chat), un
attaquant peut amener les utilisateurs d'une application Web à exécuter les actions
de son choix. Si la victime est un utilisateur normal, une attaque CSRF réussie
peut forcer l'utilisateur à effectuer des demandes de changement d'état comme le
transfert de fonds, la modification de son adresse e-mail, etc. Si la victime est un
compte administratif, CSRF peut compromettre l'intégralité de l'application Web.

 Afin de résoudre ce risque la solution proposée par SYNK est la suivante

Figure 88:Best practises synk (risque3)

63
2.3 Productivité :
Pour mesurer la productivité de notre application nous avons utilisé l’outil Google
lighthouse

Google lighthouse est un outil open source et automatisé permettant d'améliorer la

qualité des pages Web. Vous pouvez l'exécuter sur n'importe quelle page Web, publique
ou nécessitant une authentification. Il propose des audits de performances,
d'accessibilité, d'applications Web progressives, de référencement, etc.

Lighthouse se classe dans 5 catégories principales :

▪ Performance : C'est à quel point la page est rapide , elle mesure la

performance globale. Les mesures importantes étant les premières peintures
significatives et contentes, le temps d'interaction et l'indice de vitesse.

▪ Accessibilité : Ceci mesure le degré d'accessibilité de votre page. Il effectue

diverses vérifications sur les éléments de la page, comme le contraste des
couleurs et les attributs de l'étiquette Aria.

▪ Best practices : C'est la fiabilité de votre page, elle mesure à quel point les
bonnes pratiques définies par le W3C ou les standards de Google sont
utilisées et respectées. Par exemple, il vérifiera si votre page est servie
via HTTPS et si des erreurs sont présentes dans la console.

▪ SEO : Cela mesure à quel point votre page est optimisée et standardisée pour
les moteurs de recherche. Il vérifie, par exemple, si le document contient
des balises méta et des titres sémantiques.

▪ Progressive web App : Cela mesure si votre site Web peut être installé. Il doit
réussir l'audit sur la base de la liste de contrôle PWA de base . Ce n'est
normalement pas requis pour la plupart des sites

64
▪ Etude comparative pour les mesure de la productivité de l’ancien site Evax et
du nouveau site
En utilisant cet outil sur la page d’accueil du site evax actuel on a obtenu le
résultat suivant :

Figure 89:Mesures de productivité globale du site evax

En utilisant le même outil sur la page d’accueil du nouveau site on a obtenu le

résultat suivant :

Figure 90:mesures de productivité globale du nouveau site evax

65
a. Performance

On commence par analyser la performance qui représente seulement 43% et qui est
une moyenne des scores métriques. Ces scores métriques apparaissent lorsque
Lighthouse a fini de collecter les mesures de performance (évaluées en
millisecondes) et qu’il a converti chaque valeur métrique de 0 à 100.

Figure 91:Performance du site Evax actuel

Figure 92:performance du nouveau site evax

66
Les métriques mesurées pour la performance sont comme suivies :

• Le first Contentful Paint (FCP) qui calcule le temps nécessaire au navigateur pour

afficher le premier élément de contenu DOM lors du chargement d’une page de votre

site

• Le Speed Index (SI), chargé de calculer la vitesse à laquelle le contenu est affiché

visuellement pendant le chargement de la page

• Le Largest Contentful Paint (LCP) représentant le temps de chargement pour

afficher le contenu principal pour l’utilisateur

• Le Time To Interactive (TTI), qui évalue la rapidité d’interaction

• Le Total Blocking Time (TBI), qui mesure le temps total pendant lequel une page est

bloquée pour répondre aux entrées de l’utilisateur

• Le Cumulative Layout Shift (CLS), qui permet de mesurer les décalages de mise en

page inattendus que peuvent rencontrer les utilisateurs sur un site

 Le score de performance est une donnée intéressante à suivre dans la durée pour
mesurer l’impact des actions que vous entreprenez pour optimiser votre vitesse de
chargement.

 D’après les résultats de cette étude, on peut constater que le nouveau site EVAX est
plus performant que l’ancien.

b. Accessibilité
Dans cette section, nous évaluons l’accessibilité qui va nous examiner dans quelle
mesure le site Web ou l’application Web progressive peut être utilisé(e) par
des personnes ayant un handicap. Il contrôle de manière approfondie que les
éléments importants tels que les boutons ou les liens sont correctement décrits, ou
encore que les images et les graphiques disposent d’une fonction de « voix off » pour
permettre également aux personnes aveugles de comprendre les contenus via le
message vocal

67
 Figure 93:Accessibilité du site evax actuel (erreurs)

Au niveau du site Evax actuel l’outil nous affiche les règles non respectées tel que :
« Background and foreground colors do not have a sufficient contrast ratio » cette phrase
signale le texte dont les couleurs d'arrière-plan et de premier plan n'ont pas un rapport de
contraste suffisamment élevé
« Heading elements are not in a sequentially-descending order »: Cette phrase signale les pages
dont les titres sautent un ou plusieurs niveaux .

Appart ça l’outil a aussi affiché les audits passés (respectés) :

Figure 94:Accessibilité du site evax actuel (passed audits)

68
Pour le nouveau site nous avons essayé d’éviter les erreurs d’accessibilité rencontrés mais on
a eu d’autres erreurs tel que :

Figure 95:Accessibilité du nouveau site evax(errors)

« Image elements do not have [alt] attributes » : Cette phrase signale les <img> éléments qui
n'ont pas d'<alt> attributs :

« Links do not have a discernible name » : Cette phrase signale les liens qui n'ont pas de noms
discernables

Et pour les règles respectées ça nous affiche quelques-unes tel que :

Figure 96:Accessibilité du nouveau site evax(passed audits )

69
c. Bonnes pratiques

Dans cette partie nous analysons les bonnes pratiques qui présentent principalement
les aspects liés à la sécurité des sites web ou des PWA. L’outil contrôle ici l’utilisation
de technologies de chiffrement telles que TLS, la sécurité des sources des ressources
intégrées au site web, ou si les bibliothèques JavaScript peuvent être classées comme
sécurisées. Lighthouse vérifie également que les bases de données connectées sont
bien sécurisées, en signalant les commandes non sécurisées ou l’utilisation d’API
anciennes.

Au niveau du site Evax actuel on a obtenu un score de 80% qui est un score moyen
(jaune)

Figure 97:Best practices du nouveau site evax(errors)

Parmi les erreurs que l’outil a générées dans cette partie on a

« Links to cross origin destinations are unsafe »

Cette phrase signale les liens dangereux vers des destinations d'origine croisée
« Includes front-end JavaScript libraries with known security vulnerabilities »
Cette phrase signale les bibliothèques JavaScript frontales présentant des
vulnérabilités de sécurité connues

70
 D’autre part dans le nouveau site Evax qu’on a développé on a obtenu le score 93%
qui est un bon score (vert)

Figure 98:Best practices du nouveau site evax (audits passed)

La bonne pratique qui n’a pas été respecté c’est celle-ci :

« Browser errors were logged to the console »
Cette phrase signale toutes les erreurs de navigateur enregistrées dans la console.

d. SEO
Google Lighthouse utilise différents tests pour analyser dans quelle mesure l’application
ou le site Web est bien pris en compte par différents moteurs de recherche. Cependant,
ces tests sont très limités. Lighthouse affiche les résultats d’analyse sur une échelle de 0 à
100 points.

71
Ici pour le site Evax actuel nous avons obtenu le score de 90% qui est considéré bon (vert)

Figure 99:SEO du site evax actuel (errors)

Pour le nouveau site on a obtenu comme score SEO 91% qui est aussi considéré bon (vert)

Figure 100:SEO du nouveau site evax (errors)

72
VIII. Questionnaire de satisfaction
1. Objectif
Après la création du nouveau site web Evax, nous avons créé un questionnaire de
satisfaction pour mesurer et évaluer la satisfaction des utilisateurs. Nous avons
utilisé encore une fois l’outil Eval & Go.

2. Analyse des résultats

Au total 41 réponses ont pu être récoltées pendant la semaine d’enquête.

• Question 1

Figure 101: Question 1 (Enquête de satisfaction)

43.9% des échantillons ont visités notre site pour effectuer l’inscription pour
vacciner, 21.95% ont visité le nouveau site dont l’objectif est d’extraire le
passeport vaccinal, tandis que 17.07% ont accédé pour consulter les statistiques
des personnes inscrites dans le site par rapport aux personnes déjà vacciner, et
le reste des visiteurs qui représentent 17.07% ont visité le site afin de demander
l’aide.

73
 • Question 2 :
Pour la deuxième question nous avons choisi 6 critères pour évaluer la
satisfaction des clients du nouveau site evax.

Rapidité d'affichage des pages :

Figure 102:Question 2.1 (Enquête de satisfaction)

 La majorité des personnes parmi les échantillons ont trouvé la rapidité d’affichage des
pages très satisfaisante, ils ont donné la valeur de 5/5, alors que la minorité des
personnes ont évalué ce critère avec la valeur de 2/5.
La moyenne des réponses à comme valeur 3.8/5 donc ce critère est évalué satisfaisant.

74
 La taille, couleur et le style de police :

Figure 103:Question 2.2 (Enquête de satisfaction)

 La majorité des personnes parmi les échantillons ont trouvé la taille, couleur et le style
de police très satisfaisante, ils ont donné la valeur de 5/5, alors que la minorité des
personnes ont évalué ce critère avec la valeur de 3/5.
La moyenne des réponses à comme valeur 4.2/5 donc ce critère est évalué très
satisfaisant.

75
 Organisation des pages :

Figure 104:Question 2.3 (Enquête de satisfaction)

 La majorité des personnes parmi les échantillons ont trouvé l’organisation des
pages très satisfaisante, ils ont donné la valeur de 5/5, alors que la minorité des
personnes ont évalué ce critère avec la valeur de 3/5.
La moyenne des réponses à comme valeur 4.2/5 donc ce critère est évalué très
satisfaisant.

76
 Exactitude des informations :

Figure 105:Question 2.4 (Enquête de satisfaction)

 La majorité des personnes parmi les échantillons ont trouvé l’exactitude des
informations très satisfaisante, ils ont donné la valeur de 5/5, alors que la minorité des
personnes ont évalué ce critère avec la valeur de 2/5.
La moyenne des réponses à comme valeur 4.05/5 donc ce critère est évalué très
satisfaisant.

77
• Question 3

Figure 106:Question 3 (Enqête de satisfaction)

 90.24% des échantillons qui sont satisfait par la nouvelle méthode de réception du
code d’inscription par mail, tandis que 9.7% ne sont pas satisfait par cette méthode
de réception.
• Question 4 :

Figure 107:Question 4 (Enquête de satisfaction)

78
 Parmi 41 personnes 18 qui ont trouvé la nouvelle fonctionnalité chatbot très
satisfaisante, ils ont donné la valeur de 5/5, ainsi que 18 personnes ont trouvé le
chatbot comme une idée satisfaisante, ils ont donné la valeur de 4/5 alors que la
minorité des personnes ont évalué cette fonctionnalité avec la valeur de 3/5.
La moyenne des réponses à comme valeur 4.32/5, donc cette fonctionnalité est
évaluée très satisfaisant.

• Question 5 :

Figure 108:Question 5 (Enquête de satisfaction)

 La majorité des personnes parmi les échantillons ont trouvé l’extraction de passeport
vaccinal très satisfaisant, ils ont donné la valeur de 10/10, alors que la minorité des
personnes ont évalué cette fonctionnalité avec la valeur de 5/10.

79
 • Question 6

Figure 109:Question 7 (Enqête de satisfaction)

 Parmi 41 des personnes, 20 qui ont donné une note 5/5 pour le nouveau site, tandis
que 15 des personnes ont donné une note de 4/5, alors que la minorité des personnes
ont donné une note 3/5 pour le nouveau site.
La moyenne des réponses à comme valeur 4.34/5, donc le nouveau site est évalué très
satisfaisant.

80
Question 7

Finalement nous avons demandé aux échantillons d’indiquer leurs recommandations et/ou
suggestions pour notre site web et nous avons reçu les réponses suivantes comme montre
l’image ci-dessous

Figure 110:Question 7 (Enqête de satisfaction)

81