UFR des sciences

ANNUAIRE EN LIGNE POUR LES ANCIENS ETUDIANTS DIPLOMES

MIAGE DE L’UNIVERSITE DE PICARDIE JULES VERNE

Rapport technique sur le projet thématique réalisé

Code du module : D605

Intitulé du module : Etude de cas thématique
Nom de l’enseignant : Laurent Josse
Nom de l’apprenant : Mbuta Ikoko Dodi Alphonse
 Sommaire

Actuellement, pour de nombreuses organisations ou entreprises, un site et/ou une application web
passe pour un outil important les aidant à atteindre leurs partenaires d’affaires ou clients. Dans ce
cadre, certaines d’entre mettent alors sur pied des sites web dits informationnels ou institutionnels qui,
au besoin, intègrent des annuaires en ligne reprenant le profil académique et/ou professionnel de leur
personnel clé ou stratégique. C’est souvent le cas avec des entreprises de consulting ou des
organisations et institutions universitaires.

Dans le cadre de ce module de cours, le D605, s’intitulant « Projet thématique », il nous a été
demandé de construire un annuaire en ligne pour les anciens. Ce dernier devrait au fait reprendre des
informations sur chaque ancien étudiant diplômé MIAGE d’Amiens (Université de Picardie Jules
Verne), principalement sa formation académique (filière MIAGE suivie) et son profil professionnel,
en plus de leur permettre tous de rester digitalement en contact permanant entre eux et avec l’alma
mater. C’est aussi un annuaire en ligne qui se veut pour mission celle de pouvoir faciliter la carrière
et/ou l’insertion professionnelle des nouveaux diplômés MIAGE d’Amiens mais également, de
manière occasionnelle, la levée de fonds pour une recherche de qualité au sein du département
informatique ou de l’ensemble de l’UFR des sciences de l’Université de Picardie Jules Verne.

Supposé gérer des informations à caractère personnel ou privé de chaque ancien étudiant diplômé
MIAGE d’Amiens, l’annuaire en ligne à construire devrait en plus respecter les lois et règlements
européens applicables en la matière, tels que repris par la CNIL, la « Datainspektionen » et/ou le
bureau de la Commission européenne en charge du GDPR. En référence à la directive Web de l’UE de
2016 (cf. OJ L 327, 2016), il devrait également se conformer à la nouvelle loi en vigueur en Suède
depuis le 01 janvier 2019 qui réglemente l’accessibilité des sites Web dans le pays car c’est un
annuaire en ligne qui est aussi également sensé offrir un accès à un plus grand nombre d’utilisateurs
ou internautes-visiteurs.

Enfin, cet annuaire en ligne serait construit avec l’aide d’un système de gestion de contenu (CMS) et
des technologies ou langages liées au Web, à l’instar de HTML, CSS, JavaScript/Jquery, Bootstrap et
C# .NET.

Mots clés : Les domaines du développement des sites et/ou applications web (Web design), Outils
fondamentaux pour le développement des sites et/ou applications web, Système de gestion de contenu

ii
(CMS), GDPR, Directives ou accessibilité Web (WCAG) et Projet et processus de développement des
sites et/ou applications web CMS Episerver

iii
 Table des matières
Sommaire ........................................................................................................................................ ii
Table des matières ........................................................................................................................ iv
Liste des tableaux .......................................................................................................................... vi
Liste des figures............................................................................................................................ vii
INTRODUCTION ......................................................................................................................... 1
Contexte et description du projet ................................................................................................. 1
Objectifs et finalité de notre projet .............................................................................................. 1
Canevas du rapport ...................................................................................................................... 3
Chapitre 1 Concepts théoriques associés ..................................................................................... 5
1.1 Les domaines du développement des applications et/ou sites web, quid ? ..................... 5
1.1.1 Rappel sur la définition du mot Web .......................................................................... 5
1.1.2 Les domaines du développement Web : le font-end et le back-end............................ 6
1.1.3 Les technologies clés pour le développement de sites et/ou applications web. .......... 8
1.1.4 La conception graphique et les critères d’accessibilité Web (WCAG) .................... 13
1.2 Les systèmes de gestion de contenu .............................................................................. 17
1.2.1 Définitions et fonctionnalités .................................................................................... 17
1.2.2 Types de CMS .......................................................................................................... 17
1.2.3 Architecture d’un système de gestion de contenu ..................................................... 19
1.3 Un mot sur les projets informatiques ou TI dans leur ensemble ................................... 20
1.3.1 Définitions et types de projets informatiques ........................................................... 20
1.3.2 Modes d’approvisionnement et éléments de pilotage opérationnel au sein d’un
projet informatique ............................................................................................................... 21
1.3.3 Les processus et/ou procédés de développement pour les sites ou applications web 22
Chapitre 2 Méthodes et outils utilisés ........................................................................................ 31
2.1 Présentation de l’annuaire en ligne à construire pour « les anciens étudiants diplômés
MIAGE d’Amiens » .................................................................................................................. 31
2.1.1 Rappel sur la définition d’un annuaire en ligne ........................................................ 31
2.1.2 Description de l’annuaire en ligne des anciens étudiants diplômés MIAGE d’Amiens
32
2.1.3 Procédé, environnement intégré, langages et autres technologies associées adoptés
pour le développement de l’annuaire en ligne ....................................................................... 33
2.1.4 Considérations fonctionnelles et techniques du WCMS choisi : le « EpiServer CMS
». 36

iv
 2.1.5 La documentation du projet ...................................................................................... 41
Chapitre 3 Résultats obtenus ...................................................................................................... 43
3.1 Collecte et analyse de besoins exprimés par le client ................................................... 43
3.1.1 Raffinement de différents besoins exprimés ............................................................. 43
3.1.2 La scénarisation et les users stories .......................................................................... 44
3.2 L’architecture et/ou la structure de l’information de l’annuaire en ligne (plan du site ou
site map) et le codage. ............................................................................................................... 47
3.2.1 L’architecture informationnelle ................................................................................ 47
3.2.2 Le codage .................................................................................................................. 49
3.2.3 Le contenu définitif de l’annuaire en ligne. .............................................................. 50
3.3 L’esthétique de différentes pages ou interfaces web créées. ......................................... 53
3.3.1 La charte typographique et l’intégration du contenu définitif au niveau des pages ou
interfaces web construites ..................................................................................................... 54
3.3.2 Le responsive ............................................................................................................ 59
3.3.3 Tests d’utilisabilité et d’accessibilité sur les différentes pages ou interfaces web
créées pour l’annuaire en ligne .............................................................................................. 60
Chapitre 4 Discussions et critiques ............................................................................................ 66
4.1 Par rapport à la réalisation de notre projet dans son ensemble ..................................... 66
4.2 Par rapport au codage et aux différents tests réalisés .................................................... 67
4.3 Par rapport à la vérification et à la validation finale de différentes pages ou interfaces
web créées et de leur contenu .................................................................................................... 69
Conclusion .................................................................................................................................... 71
Annexe A Plan de développement de l’annuaire ...................................................................... 73
Annexe B Code source de l’annuaire construit ......................................................................... 74
Bibliographie ................................................................................................................................ 75

v
 Liste des tableaux
Tableau 1 – Différentes outils et technologies choisis ou adpotés pour notre projet. .................. 35
Tableau 2 – Première monture des users stories obtenues grâce à la scénarisation de différentes
exigences fonctionnelles et non fonctionnelles ...................................................................... 46
Tableau 3 – Quelques critères WCAG 2.1 utilisés ........................................................................ 62
Tableau 4 – Propositions Nombre de violations WCAG 2.1 après les tests automatiques de
différentes pages ou interfaces web créées ........................................................................... 63
Tableau 5 – Propositions de correction sur les différentes violations trouvées (Ici, sur la page
d’accueil). .............................................................................................................................. 65

vi
 Liste des figures
Figure 1 - Différents navigateurs web modernes et leurs différentes versions stables (source :
Can I Use, https://caniuse.com/#search=css, 2019). .............................................................. 6
Figure 2 - Une portion d’un exemple de code HTML. .................................................................... 9
Figure 3 - Une portion d’un exemple de code ou de fonction Javascript/Jquery utilisant aussi
AJAX (« doSearch »). ............................................................................................................ 11
Figure 4 - Outil d’inspection de pages web (à droite de cette page web) ..................................... 13
Figure 5 – Couleur bleu du logo de l’UPJV sous trois différentes notations ou écritures (RGB,
HEX et HSL) .......................................................................................................................... 15
Figure 5 – Cercle chromatique de Johannes Itten (source : Chambeau Athony,
https://www.cours-de-peinture.net/technique-de-melange-en-peinture-acrylique/, 2019) ... 15
Figure 7 – Le cycle de vie du logiciel et la place naturelle d’un procédéde développement logiciel
(source : Luc Lavoie, 2007, cité par Mbuta Ikoko, 2011) ..................................................... 22
Figure 8 - Scrum framework et ses principales parties [Sutherland Jeff et Schwaber Ken (2017,
reprise par Mbuta Ikoko, 2018), source : https://www.scrum.org/resources/what-is-scrum).
............................................................................................................................................... 26
Figure 9 – The Five Planes (source: Garrett Jesse, 2011). .......................................................... 28
Figure 10 - Vue d’ensemble du système et du site Web ou solution personnalisé......................... 36
Figure 11 - L’architecture d’EpiServer (source ffh :
https://www.episerver.com/learn/tech/technical-resources/architecture/) ........................... 38
Figure 12 – Environnement de développement versus environnement de production pour
EpiServer CMS ...................................................................................................................... 38
Figure 13 – Environnement de développement versus environnement de production pour
EpiServer CMS ...................................................................................................................... 39
Figure 14 – Environnement de développement MS Visual Studio avec les options « Add »
possibles grâce à l’Episerver CMS Visual Studio Extension installé ................................... 40
Figure 15 – Exemple d’une user storie de notre projet transcrite sur TFS. ................................... 46
Figure 16 - Sitemap reprenant les pages de notre site ................................................................... 48
Figure 17 - Un des prototypes fabriqués à l’aide d’un papier fonctionnel (ici, c’est le prototype de
la page principale « Annuaire des anciens »). ....................................................................... 48
Figure 18 – Ecran représentant le code et les différents objets et propriétés de notre annuaire
structurés en MVC sous le MS Visual Studio ........................................................................ 49
Figure 19 - L’interface de rédaction et de personnalisation WYSIWYG du CMS EpiServer ...... 50
Figure 20 – Une partie de la page web principale « Blog » et son contenu définitif rédigé par le
web redacteur après codage.................................................................................................. 53

vii
Figure 21 – La page principale « accueil » de l’annuaire et l’en-tête (header), avec un logo et
une barre de navigation. ....................................................................................................... 54
Figure 22 – Une partie de la page d’accueil, avec des cartes avec images matricielles remplies
ayant plusieurs couleurs, et le pied de page de l’annuaire (footer), avec des liens jugés
essentiels et incountounables. ............................................................................................... 55
Figure 23 – Exemple d’un article ou post intégral du blog (ici, avec des liens icones sur les trois
réseautage sociaux phares, et pour l’impression, le mailing et le fil RSS). .......................... 56
Figure 24 – Une partie de la sous page de la liste des anciens étudiants diplômés filtrée par
promotion 2017, grâce au choix de l’onglet qui se trouve dans la sous navigation à gauche.
............................................................................................................................................... 57
Figure 25 – Une partie de la page de présentation du profil complet d’un ancien étudiant
diplômé MIAGE d’Amiens..................................................................................................... 58
Figure 26 – La page Contact de l’annuaire en ligne construit. .................................................... 58
Figure 27 - Affichage responsive de la page principale « Annuaire des anciens » sous le format
Desktop (ici, avec le device HP Z Book 1200px). ................................................................. 59
Figure 28 - Affichage responsive de la page principale « Annuaire des anciens » sous les formats
Mobile/tablette (ici, avec le device iPad : 768 px x 1024 px) et Mobile/smartphone (ici, avec
le device iPhone X : 375 px x 812 px). .................................................................................. 60
Figure 29 – Violations WCAG 2.1 trouvées sur la page d’accueil de notre annuaire en ligne avec
Total validator. ...................................................................................................................... 63

viii
 INTRODUCTION
Contexte et description du projet
Pour de nombreuses organisations ou entreprises, leurs sites et/ou applications web passent aujourd’hui
pour des outils importants qui les aident à atteindre leurs différents clients ou partenaires d’affaires. Ils
arrivent aussi à aider les parties prenantes internes (acteurs dirigeants et employés) de ces organisations à
communiquer, échanger et/ou partager, mais aussi également à mettre à la disposition de leur public et de
leurs différents clients ou partenaires d’affaires des informations pertinentes, digestes, intéressantes et
mémorables concernant leurs différentes activités et services offerts. Certaines de ces organisations ou
entreprises ne s’arrêtent pas là mais vont un peu plus loin. Elles intègrent au sein de leurs sites web des
annuaires en ligne qui reprennent le profil académique et professionnel de leur personnel clé ou
stratégique. C’est souvent le cas avec des entreprises de consulting ou des organisations et institutions
universitaires.
Concernant les organisations et institutions universitaires, elles intègrent des annuaires en ligne au niveau
de leurs sites web pour pouvoir mettre en valeur le profil académique et professionnel de leur personnel
académique ou administratif clé, mais aussi parfois celui de leurs anciens étudiants notables afin de
pouvoir servir au final de reférence marketing communicative et attirante. Les différentes associations ou
réseaux d’almuni (anciens étudiants) de ces organisations et/ou institutions universitaires font aussi
presque pareil.
En France, plusieurs associations ou réseaux d’almuni existent au sein des organisations et/ou institutions
universitaires et, suivant leurs besoins de communication ou autre, possèdent donc des annuaires en ligne
qui reprennent respectivement le profil académique et professionnel de leurs membres qui ne sont d’autres
que des anciens étudiants diplômés, et cela, pour aussi leur permettre de rester digitalement en contact
entre eux et avec leur alma mater, parfois également pour créer des opportunités d’affaires entre eux. Il
s’agit en effet d’une simple donne communicationnelle qui n’est pas nouveau dans l’actuelle société de
l’information, appelée désormais la société de la connaissance ou du savoir.
Tous ces annuaires en ligne ont souvent pour principal but de créer alors une identité virtuelle et de
pouvoir augmenter la visibilité des organisations ou entreprises et de leurs activités respectives.
Pour ce faire, la communauté ou le réseau d’anciens étudiants diplômés MIAGE d’Amiens de l’Université
de Picardie Jules Verne ne compte pas rester à la traîne de cette donne communicationnelle vu le caractère
international et de haut-niveau de la formation suivie, la formation MIAGE. Elle compte donc aussi
construire ou mettre sur pied un annuaire en ligne même si elle fait déjà partie de la fédération nationale
des étudiants et diplômés de MIAGE, connue sous le nom de « MIAGE connection », et qui dispose d’un
annuaire global pour tous les anciens étudiants diplômés MIAGE de France.
Objectifs et finalité de notre projet
1° Objectif général
L’objectif général de notre projet thématique, dans le cadre du module de cours D605, est de pouvoir
construire un annuaire en ligne pour les anciens étudiants diplômés MIAGE1 d’Amiens, c.à.d. du
département informatique de l’Université de Picardie Jules Verne qui fait donc partie de l’UFR des
sciences de l’Université.

1
Le diplôme ou le master de méthodes informatiques appliquées à la gestion des entreprises (MIAGE) est un
diplôme universitaire français de niveau bac+5, alliant une double compétence en informatique et en gestion, déstiné
à former des cadres supérieurs d’entreprises experts en ingénierie et management des systèmes d’information. Les
formations MIAGE sont dispensées dans vingt universités francaises et a pour vocation de former des professionnels
de niveau cadre à l’ingénierie des systèmes d’information au sein des organisations.

1
C’est un annuaire en ligne qui devrait reprendre des informations sur la filière académique suivie et le
profil professionnel actuel de chaque ancien étudiant diplômé MIAGE d’Amiens, en plus de leur
permettre de rester digitalement en contact permanant entre eux et avec leur alma mater. C’est aussi un
annuaire en ligne qui se donne pour mission celle de pouvoir faciliter la carrière et/ou l’insertion
professionnelle des nouveaux diplômés MIAGE d’Amiens mais aussi également, de manière
occasionnelle, la levée de fonds pour une recherche de qualité au sein du département informatique ou de
l’ensemble de l’UFR des sciences de l’Université de Picardie Jules Verne.
2° Objectifs concrets et vérifiables
Le but principal de ce travail est de:
 construire un annuaire en ligne pour les anciens étudiants diplômés MIAGE d’Amiens, avec
l’aide d’un système de gestion de contenu (CMS) et des technologies ou langages web liés, à
l’instar de HTML, CSS, JavaScript/Jquery, Bootstrap, C# .NET, etc.
La solution à construire pourrait également être étendue par l’ajout ou la configuration des
modules, plugins, ou composants, etc.
 créer des interfaces utilisateurs web conviviales, c.à.d. simples d’utilisation par les différents
utilisateurs ou internautes-visiteurs (user-friendly suivant le propos de Nielsen Jakob, 1994) ;
 disposer des informations de bonne qualité, c.àd. qui sont pertinentes, digestes, intéressantes et
mémorables pour les utilisateurs ou internautes-visiteurs de l’annuaire en ligne ;
 appliquer une logique communicationnelle visuelle sur une base typographique acceptable ;
 etc.
En plus, le fait que la solution qui va être construite au cours de ce projet va technologiquement être assise
sur un système de gestion de contenu, les informations qui vont être rendues disponibles devraient alors
être protégées et gérées en faisant respecter les lois et règlements européens relatifs à la protection de
données à caractère personnel ou privé, telles que reprises par la CNIL, par la « Datainspektionen » et/ou
par le bureau de la Commission européenne en charge du GDPR. Sensée également offrir un accès à un
plus grand nombre d’utilisateurs ou internautes-visiteurs, l’annuaire en ligne qui va être construit devrait
également se conformer à la nouvelle loi en vigueur en Suède depuis le 01 janvier 2019 qui, en référence à
la directive Web de l’UE de 2016 (cf. OJ L 327, 2016), réglemente l’accessibilité des sites web (WCAG)
dans sa version 2.1.
3° Limites du projet
Le projet thématique TI (ou web) que nous allons réaliser ne va pas chercher à s’assurer de l’existence de
cette communauté ou réseau d’anciens étudiants diplômés MIAGE d’Amiens, moins non plus de chercher
à décrire de manière formelle l’organisation et le fonctionnement de cette dernière. A la place, il va plutôt
chercher de se focaliser sur le développement c.à.d. sur la construction d’une version beta de l’annuaire en
ligne démandée pour le compte de ladite communauté ou réseau, et cela, avec l’aide d’un système de
gestion de contenu puis à partir des sources d’informations qui vont être mises à notre disposition ou
simplement celles qui vont être trouvées sur Internet à propos.
Toutefois, nous faisons noter que le développement des sites et/ou applications web ne disposant presque
pas à ce jour d’un processus ou procédé ad hoc connu. Les développeurs web s’appuient ou continuent de
s’appuyer sur des procédés prédictifs et agiles connus du monde de Génie logiciel. D’autres préfèrent
plutôt travailler suivant une approche intégrant ou unifiant plusieurs de ces processus et/ou procédés
connus pour enfin arriver à construire, créer ou fabriquer un site et/ou une application web fiable,
fonctionnelle ou conviviale. Derrière cette logique de travail évoquée et pour ne pas inventer une nouvelle
roue, nous allons donc tenter aussi d’intégrer ou d’unifier au moins deux processus ou procédés de
développement logiciel connus et adaptés pour la construction, la création ou la fabrication de notre
annuaire en ligne. Au fait, ca devrait être un exercice qui va nous aider de cerner correctement, par la
théorie et par la pratique, la pertinence réelle de cette logique intégratrice de processus ou procédés de
développement logiciel dans le cas qui nous concerne, c.à.d. celui d’un projet de développement web qui

2
recommande aussi logiquement une forte interaction ou collaboration entre les différentes parties
prenantes impliquées.
Faisons également noter que nous n’allons pas publier et/ou héberger en ligne notre solution car c’est juste
un projet thématique. Néanmoins le code source et la possibilité de son exécutíon en local seront rendus
disponibles.
Canevas du rapport
Le rapport technique qui est présenté ici contient les différentes informations théoriques et pratiques qui
ont servies pour la construction, la création ou la fabrication de l’annuaire en ligne nous demandé. Il s’agit
d’un rapport technique écrit dans le cadre du module de cours D605, intitulé « projet thématique », et
comporte 4 chapitres en dehors de l’introduction et de la conclusion.
Ainsi, hormis ce point introductif, le chapitre 1, dans les limites évoquées de notre projet thématique, va se
focaliser sur une revue de la littérature synthèse liée au développement des sites et/ou applications web au
sein des organisations. Les deux domaines accompagnant actuellement le développement web vont donc
être présentés, mais aussi quelques outils et technologies clés qui y sont liés, suivi de la présentation de
systèmes de gestion de contenu. En rapport avec les systèmes de gestion de contenu, nous allons profiter
pour parler aussi de la protection de données à caractère personnel ou privé. Cette protection de données à
caractère personnel ou privé va être évoquée de manière globale dans un contexte de comment un site
et/ou une application web construit devrait respecter les lois et règlements européens liés, c.à.d. les lois et
règlements européens relatifs la protection de données à caractère personnel ou privé et qui sont issus ou
repris par la CNIL, la « Datainspektionen » ou le bureau de la Commission européenne en charge du
GDPR. En plus, une ligne va également être écrite par rapport à la directive Web de l’UE de 2016 (cf. OJ
L 327, 2016) ; une directive qui insiste sur l’accessibilité de sites et/ou applications web construits et
destinés à être accéssibles à un large public. C’est donc un chapitre qui va donner suffisamment aux
différents lecteurs de notre rapport des éléments de compréhension pour pouvoir interpréter par la suite
correctement son contenu et celui de l’annuaire en ligne construit. Il se termine, ce premier chapitre, par la
présentation condensée de quelques processus ou procédés de développement logiciel connus du Génie
logiciel et utilisés dans le cadre d’un projet TI web, à l’instar par exemple du procédé agile Scrum et du
cadre théorique et pratique de Garrett James qui sont basés sur les interactions et/ou sur les expériences
profondes et positives des utilisateurs (UCD).
Le chapitre 2 va décrire la méthodologie que nous avons adoptée pour construire, créer ou fabriquer
l’annuaire en ligne qui nous a été démandé, et cela, à travers la présentation d’un processus ou procédé de
développement logiciel théorique et pratique qui se veut intégré ou unifié. Les outils et les technologies
choisis et qui vont être utilisés pour cette activité vont aussi être présentés. Ainsi, comme dit Masamba
N’kazi (1998, cité par Mbuta Ikoko, 2011), notre méthodologie adoptée est stratégique mais aussi fonction
de la thématique étudiée, des ressources disponibles et de l’expérience antérieure ou actuelle dans le
domaine. En se servant également de notre expérience modeste en management des projets TI/SI et en
architecture et dévelopement des systèmes informatiques, les éléments du procédé agile Scrum et du cadre
de référence proposé par Garrett James vont alors être intégrés ensemble pour servir des grandes lignes de
notre méthodologie.
Quant au chapitre 3, il va plutôt présenter les résultats de la construction, création ou fabrication de
l’annuaire en ligne demandé, et cela, en fonction de la méthodologie adoptée et des outils et technologies
utilisés. Quelques pages et/ou interfaces web créées seront illustrées, accompagnées des quelques
commentaires synthèses. Au fait, il va être seulement question de clarifier ces résultats obtenus par rapport
à la collecte et analyse des besoins exprimés, aux différents modèles concues (exigences, extra-
fonctionnel, de conception, etc.), au codage, mais la structure, le contenu et la convivialité de l’annuaire
en ligne construit, créé ou fabriqué.
Le chapitre 4 va être un chapitre qui va globalement nous fournir quelques lignes de discussions et
critiques sur l’ensemble du projet TI web réalisé mais aussi sur l’annuaire construit, créé ou fabriqué. Les
violations trouvées sur les différentes pages ou interfaces web créées pour notre annuaire vont être

3
présentées comme un example de séries de tests réalisés pour pouvoir être en conformité avec les
directives web de l’UE ou les recommandations WCAG 2.1 destinées à être appliquées à tout site ou
application web destiné à un plus grand nombre d’utilisateurs possible.
Les dernières lignes de ce rapport vont concerner notre conclusion et une la proposition de quelques
tâches futures pour pouvoir améliorer davantage l’annuaire en ligne construit, créé ou fabriqué pour les
anciens étudiants diplômés MIAGE d’Amiens dans le cas où le projet devrait devenir effectif pour sa mise
en ligne.

4
 Chapitre 1
Concepts théoriques associés

Ce chapitre présente quelques concepts théoriques associés et pertinents pour le développement d’une
application et/ou d’un site au sein des organisations.
1.1 Les domaines du développement des applications et/ou sites web, quid ?
1.1.1 Rappel sur la définition du mot Web
Le World Wide Web (WWW), aussi appelé « protocole ou service Web », est défini dans la littérature TI
comme étant un programme de balayage ou de recherche d’information (référence au navigateur Web ou
Web browser) qui contient « un ensemble de pages ou documents reliés entre eux par des liens et
accessibles par l’Internet » (Berners Lee RFC 1630-, 1994, cité par Comer Douglas, 2006 et relayé par
Mbuta Ikoko, 2007). Cet ensemble dispose des noms uniques qui sont identifiables sur les différentes
pages ou documents qui sont même couramment appelés « pages ou documents Web ».
En parlant du Web, nous devons aussi comprendre qu’il est un service2 ou un protocole Internet de base au
niveau de la couche application qui s’occupe de la navigation entre les pages Web, comme c’est fut le cas
avec le GOPHER. Il s’exécute sous le mode « hypertexte non crypté » (HTTP : HyperText Transfert
Protocol) ou « crypté » (HTTPS : HyperText Transfert Protocol Secure). Il existe aussi également d’autres
services ou protocoles Internet de base de niveau application qui sont associés au protocole HTTP pour
rendre encore plus fonctionnel le service ou protocole Web, c.à.d. le Web. Parmi ces services ou
protocoles, nous pouvons citer ici les services ou protocoles de transfert de fichiers (FTP/TFTP : File
Transfert Protocol/ Trivial File Transfert Protocol), de connexion et/ou gestion à distance des utilisateurs
et des bureaux (TELNET : Terminal Network, SSH : Secure Shell, NIS : Network Information Service,
rlogin, rsh, etc.), de configuration des annuaires distribués (DNS/DNSSEC : Domain Name
System/Domain Name System Security Extensions et DHCP), de sécurisation des échanges (SSL : Secure
Sockets Layer ou TLS : Transport Layer Security), d’accès aux fichiers distants ou d’hébergement de sites
Web (le Web hosting avec NFS : Network File System ou SMB : Server Message Block), de conception
des sites Web ou le Web design (HTML : HyperText Markup Language qui est basé sur le SGML :
Standard Generalized Markup Language et qui, selon Koch Daniel et al. (2000), constitue la clé d’une
page Web), de messagerie électronique (Web mail avec SMTP : Simple Mail Transfert Protocol, POP :
Post Office Protocol, IMAP : Internet Message Access Protocol et MIME : Multipurpose Internet Mail
eXtensions) et de forums, newsgroups ou dialogue en temps réel (NNTP : Network News Transfer
Protocol ou IRC : Internet Relay Chat).
En termes de la série de définitions fournie pour le mot Web, nous faisons également noter que la maîtrise
de tous les différents services ou protocoles Internet de base de niveau application cités ci-dessus constitue
une des premières étapes pour la compréhension correcte de l’univers Web ou de l’Internet dans son
ensemble, mais aussi phytyet articulièrement comme l’une des étapes importantes avant de pouvoir

2
En informatique, tout comme en télématique, un service désigne l’ensemble de programmes qui forme une
application œuvrant pour effectuer un traitement transactionnel ou différé sur des informations ou pour manipuler
des données qui partage un mode de communication donné. Dans la pratique, ce sont des éléments de structuration
des informations ou des données qui permettent de fournir ou de réaliser un service informatique. Ces éléments
forment à leur tour ce que l’on appelle « protocole », c.à.d. une sorte de format de données, de dialogue, de règles
et/ou de processus définis pour un échange, un partage ou une communication, etc. Le protocole ne représente donc
pas un programme informatique mais plutôt un cahier des charges pour un ensemble de programmes informatiques.
Actuellement, les différents services Internet sont fournis via des plateformes ou infrastructures technologiques
construites au sein des organisations et font donc partie dans leur ensemble des services dits « en réseau ».

5
réellement se lancer comme professionnel dans la création de Web services3 et/ou de sites web pour les
organisations.
1.1.2 Les domaines du développement Web : le font-end et le back-end
Le développement Web, connu aussi sous le label anglais de « Web design », consiste en un certain
nombre de composants qui interagissent pour coder de pages web ou en une technologie de codage de
pages web. Il a aujourd’hui pour principal objetif la conception de sites web pour des réseaux publics ou
privés dits ouverts, fermés et/ou virtuels (Internet, Extranet, Intranet ou VPN). C’est un domaine qui est
vaste et en rapide évolution et qui comporte à son sein des nombreuses techniques et branches de
l’informatique qui sont divisées en deux principaux sous-domaines : (1) le front-end et (2) le back-end.
 Le Front-end – c’est le sous-domaine qui s’occupe de l’exécution de code du coté client. Ici, le
code qui est écrit par un Web developer4 fournit une interface d’utilisation et permet à l’utilisateur
ou internaute-visiteur de communiquer avec le site web créé. Il s’agit donc d’un sous-domaine qui
inclut la conception de pages web, leur mise en page et les flux d’information liés. Le Web
developer devrait alors se pencher beaucoup plus sur le code HTML, les éléments graphiques et
les divers langages de script, tels que le CSS, le Javascript/Jquery et le Bootstrap, mais aussi sur le
fonctionnement de pages web à créer pour les différents navigateurs web utilisés par les
utilisateurs ou internautes-visiteurs (le cas des navigateurs Chrome, Opera, Internet Explorer,
Safari, Mozila, etc.).

Figure 1 - Différents navigateurs web modernes et leurs différentes versions stables (source : Can I Use,
https://caniuse.com/#search=css, 2019).
Les différents navigateurs web repris sur la figure ci-dessus, appelés voire des « navigateurs web
modernes », tentent donc aujourd’hui de faciliter un affichage convivial de contenus des
différentes pages web à créer, mais aussi l’inspection de différents codes HTML, CSS et/ou
JavaScript liés aux pages web créées.
En un mot, le Front-end est le sous-domaine du développement Web qui agit sous la forme d’une
couche logicielle entre un navigateur web et les différentes fonctions sous-jacentes du serveur,
c’est-à-dire avec la partie back-end.
 Le Back-end – c’est un sous-domaine qui est caractérisé par le fait que le code est exécuté du
côté serveur, contrairement au front-end. Ainsi, avant l’exécution du code frontal (HTML, CSS et
JS, etc.), le code, pour le côté serveur, est exécuté en premier. Le back-end représente aussi le
nom et l’endroit où les applications et les bibliothèques logicielles de conception et de

3
Un Web service est un cadre d’architecture (Architecture Framework) pour la conversation entre deux ordinatrice,
l’un client et l’autre serveur, communiquant ou partageant des informations sur le web et parlant dans un vocabulaire
commun avec un fort ensemble de protocoles. Pour Printz Jacques (2012, cité par Mbuta Ikoko, 2018), il est plutôt à
présenter comme étant une technologie C/S améliorée qui permet aux différentes applications informatiques actuelles
de pouvoir communiquer entre elles, et cela, même si elles sont implémentées sur des différentes plates-formes ou
avec des langages de programmation différents.
4
Selon l’encyclopédie en ligne Wikipédia, un web developper est un programmeur spécialisé dans le développement
d’applications World Wide Web ou exécutées sur un serveur HTTP, ou qui y est spécifiquement engagé. C’est donc
quelqu’un qui devrait avoir un petit bourdonnement des les deux domaines, même s’il ne souhaite se concentrer que
sur l’un ou l’autre domaine. Il peut travailler comme salarié ou comme freelance et se charge alors du développement
du produit souhaité en répondant clairement aux besoins exprimés par un client dans un cahier des charges.

6
 personnalisation de sites web sont stockées. Plusieurs technologies et langages de programmation,
côté serveur, et SGBD relationnelles ou objets sont associés à ce sous-domaine. Donc, la partie
back-end d’un site Web est donc liée à un SGBD et, ensemble, ils diffusent et présentent le
contenu aux périphériques et aux utilisateurs finaux (partie front-end).
Dans la pratique, les deux principaux sous-domaines qui viennent d’être évoques sont souvent exploités
et/ou mis ensemble par les développeurs Web, et cela, sous la terminologie de « Full stack ». En effet, ils
sont exploités et/ou mis ensemble en vue de pouvoir créer, construire ou fabriquer aujourd’hui un site
Web dynamique et intégré répondant aux besoins de ses utilisateurs ou de l’organisation commanditaire
(le client).
Toutefois, pour une question d’élégance, profitons de ces lignes pour faire un petit rappel synthèse sur les
sites ou les pages web qui sont souvent créées par les développeurs web pour répondre aux besoins de
leurs utilisateurs. Au fait, ils sont généralement de deux types : les sites web statiques et les sites web
dynamiques. En plus, séparés par le passé, les deux types de sites web cohabitent aujourd’hui et sont
même intégrés en un seul, allant du site web statique au site web dynamique. Pour Mbuta Ikoko (2010), il
est même aujourd’hui devenu difficile d’imaginer, de construire ou de mettre sur pied un site web statique
et de l’héberger avec l’aide d’un serveur web ou un site d’hébergement disponible sur Internet (cf. notion
de Web hosting). Le mieux à faire c’est plutôt de l’améliorer par des fonctionnalités dynamiques qui sont
offertes actuellement par la majorité de langages de programmation ou de script, à l’instar de
JavaScript/Jquery, PHP, C# .Net et JAVA, mais aussi par des bases de données relationnelles ou objets et
leurs systèmes de gestion qui accompagnent ces différents langages (le cas par exemple de MS SQL
Server, PostgreSQL, MySQL, Oracle, DB2, SQLite, Mongo DB/NoSQL, etc.). Ensuite, l’héberger.
D’ailleurs, comme nous allons le voir au point 1.2, ce sont des systèmes de gestion de contenu qui
assurent actuellement en grande partie la création et la gestion de données ou contenus de différents sites
ou pages web créés.
Les sites web statiques sont faciles à concevoir ou à construire. Ils sont naturellement constitués des pages
web « dites statiques » et qui sont construites uniquement avec à l’aide des langages normalisés HTML et
CSS, mais aussi parfois avec du JavaScript/Jquery (lire Valade Janet, 2003 ; Nebra Mathieu, 2009 et
Rigaux Philippe, 2009, cités par Mbuta Ikoko, 2010). Ces pages Web statiques créées peuvent contenir
parfois des objets multimédias animés. Elles sont demandées par des internautes-visiteurs (utilisant des
clients ou machines clientes web) en indiquant leurs URL5 sur un navigateur web, et cela, dans le but
simplement de leur visualisation. Le protocole HTTP, qui joue ce rôle et qui est associé non seulement aux
pages web statiques mais aussi aux pages web dynamiques, aide ici tout client web à retourner des
témoins de connexion (cookies, une sorte de fichier texte que les clients web stockent) via le serveur web.
Quant aux sites web dynamiques, ils sont plus complexes et parfois difficiles à concevoir ou à construire,
même si certaines ressources utilisées sont liées directement aux multiples utilitaires et/ou plugins
disponibles sur le marché des TIC. A la différence des sites web statiques, les sites web dynamiques sont
très évolués et leurs différentes pages ou interfaces web créées sont dynamiques. Ils contiennent aussi des
objets multimédias animés (texte, son, image et vidéo) mais qui sont également dynamiques. Tout ceci
veut tout simplement dire que les différentes pages web dynamiques créées et leur contenu peuvent être
complétés ou modifiés de manière participative et collaborative par les internautes-visiteurs suivant leurs
besoins, sans parfois demander l’intervention d’un web developer. Elles sont donc actuellement présentes,
ces différentes pages web dynamiques, sur la majorité de sites web disponibles sur le réseau Internet et
que Agrebi Meriem et Chandon Jean-Louis (2009, cité par Mbuta Ikoko, 2018) classifient en sites web
informationnels, institutionnels, e-commerce, de marque, communautaires et de services.

5
Une URL (Uniform Resource Locator) « fait référence au sous-ensemble d’URI (Uniform Resource Identifier) qui,
en plus d’identifier une ressource, permet de localiser la ressource en décrivant son mécanisme d’accès principal (par
exemple, son emplacement de réseau) » (RFC 3986, cité par Mbuta Ikoko, 2010). Elle explique alors comment
accéder à cette ressource en fournissant une méthode ou un protocole explicite comme le HTTP ou FTP. En plus,
comme sous ensemble d’une URI, toutes les URL sont donc des URI, mais toutes les URI ne sont pas des URL.

7
En terme de communication web, nous disons aussi qu’un serveur web, dans le cas des sites web statiques,
est considéré comme un server ou un canal unidirectionnel (cf. le Web 1.0). Il a seulement la
responsabilité technique d’envoyer les différentes descriptions ou contenus de différentes pages web
statiques demandées par des clients web ou internautes-visiteurs. Dans un site web dynamique, qui
représente aujourd’hui l’incarnation du Web 2.0 ou d’une version supérieure (3.0 ou 4.0), la
communication du serveur web est bidirectionnelle ou multicanale qui est alors bénéfique pour toutes les
organisations et devrait également « être transparente et visible de manière globale et persistante dans le
temps » (MacAfee Andrew, 2009, cité par Mbuta Ikoko, 2010). Derrière cette communication
bidirectionnelle ou multicanale, il y a également aujourd’hui la possibilité de créer des espaces d’échanges
et de partages des informations ou des connaissances entre leurs différents internautes-visiteurs connectés
(lire Kaplan Andreas et Haenlein Michael, 2012). Il s’agit d’une possibilité qui a donc donné lieu à
l’intégration des autres services ou applications web complémentaires au niveau de ces sites web ; des
services ou applications tels que les blogues, les micro-blogues, les wikis, les réseautages sociaux en
ligne6 et les applications web composites (mashups). L’encyclopédie en ligne Wikipédia, les sites web
d’intermédiation commerciale ou de vente en ligne [Blocket.se, Amazon, Alibaba Group (alibaba,
aliexpress et taobao), Leboncoin, etc.], les plateformes de recherche d’informations (Google, Baidou,
Yahoo, Pages jaunes, etc.) et les médiaux sociaux ou professionnels (Facebook, Twitter, LinkedIn,
MySpace, YouTube, WhatsApp, Flickr, Meetup, Académia, etc, etc.) sont donc à compter parmi les sites
web dynamiques 2.0 ou de versions supérieures. C’est aussi le cas pour les forums ou blogues de
discussion spécialisés (Stack Overflow, Code Project, Answers.com, Developpez.com, CodePen, etc.) et
les sites de presse ou d’informations générales (SvT nyheter, Omni nyhetstjänst, France 24, Media Congo,
Actu30, etc.). Notons en plus que certains sites web dynamiques, 2.0 ou de versions supérieures citées ci-
dessus utilisent du flux RSS (Really Simple Syndication) pour la syndication de leur contenu.
1.1.3 Les technologies clés pour le développement de sites et/ou applications web.
Les langages HTML, CSS et JavaScript ont toujours été considérés comme des outils fondamentaux ou
clés pour le développement des sites web mais aussi pour la mise en page de différents pages web ou
interfaces web souvent créées pour pouvoir répondre aux divers besoins des internautes-visiteurs. Dans les
lignes qui suivent, nous faisons une présentation synthèse de ces trois langages de programmation web
évoqués et des outils servant comme éditeurs de codes liés.
a) Le HTML et les balises sémantiques
Le langage HTML, de l’anglais « Hypertext Markup Language », est un langage informatique de
marquage ou de balisage pour l’hypertexte. Il forme aujourd’hui la base de tout contenu Web et, à propos,
permet à n’importe quel navigateur web de lire le code écrit, mais aussi de le convertir en une vue
typographique pour permettre à un internaute-visiteur de lire ou de voir à son tour ledit contenu et
d’interagir avec. Toutefois, lors de l’écriture d’un code HTML par un développeur web, on utilise des
éléments HTML appelés « balises ». Ces dernières servent pour structurer, afficher ou présenter une
information, mais aussi pour pouvoir lier des pages web créées et constituant un site ou une application
web. Dans le cadre d’une structuration, les balises HTML indiquent l’endroit où les différents éléments
que contiennent une page ou interface web créée (textes, sons, images, vidéos, etc.) devraient être placés
(lire sur le site éducationnel en ligne W3schools : https://www.w3schools.com/tags/ref_byfunc.asp).

6
Notons ici de manière particulière que les réseautages sociaux en ligne (de l’anglais, Social Networking Sites ou
SNS) constituent une partie des médias sociaux (social media). Sur ce fait, pour Ellison Nicole et Thierry Annike
(2011), ils peuvent alors être définis « comme des plates-formes de communication en réseau au sein desquelles les
différents participants a) possèdent des profils associés à des identifiants uniques qui sont créés par la combinaison
de contenus fournis par les utilisateurs, des amis et des données système ; b) peuvent exposer publiquement des
relations susceptibles d’être visualisées et consultées par d’autres ; et c) peuvent accéder à des contenus incluant des
contenus générés par des utilisateurs ».

8
 Figure 2 - Une portion d’un exemple de code HTML.
b) Les CSS et les classes sémantiques liées
Les feuilles de style en cascade, de l’anglais « Cascading Style Sheets » (CSS), représentent une sorte de
langage informatique qui fait que les pages web créées pour un site web avec du code HTML aient une
bonne allure sur n’importe quel navigateur Web. En d’autres mots, elles permettent de contrôler
l’apparence et d’ajouter facilement du style (polices, couleurs, espacement, etc.) à des pages web créées
avec du code HTML. Ici, le HTML est considéré comme étant le langage de balisage par excellence qui
contrôle la structure de sites web tandis que les CSS, un langage contrôlant la présentation de différentes
pages Web créées pour des sites web.
Le code CSS est généralement enregistré dans le même fichier HTML de la page web créée mais il peut
aussi se retrouver dans un fichier ou document séparé ayant pour l’extension « .css ». Le deuxième choix
est souvent celui qui est recommandé professionnellement car il constitue probablement le moyen le plus
efficace pour appliquer par exemple les différents styles définis de manière globale sur l’ensemble de
pages créées pour un site web construit.
Actuellement, plusieurs versions CSS sont actives et/ou en cours de développement mais la version CSS 3
est la version la plus pratique actuelle. Cette dernière paraît stable depuis un temps et poursuit voire son
développement continu en parallèle avec la version 2.1 et récemment avec aussi également la version 4
qui utilise sa couche comme base de développement.
En matière de syntaxe, notons que le code CSS ne s’écrit pas comme le code HTML, moins non plus
comme le code d’un langage de script, à l’instar de JavaScript, etc. Les CSS étant un langage dit « de
feuilles de style en cascade », la syntaxe de son code est alors différent des autres langages du web ; cela
signifie que le code CCS dispose de ses propres éléments et règles de mise en forme, et cela, dans le but
d’identifier d’abord en premier le contenu d’une page web créée en HTML et ensuite d’appliquer un style
spécifique (lire Powell Thomas, 20107). L’identification du contenu d’une page web créée se fait sur des
balises HTML sémantiques mais aussi sur celles de présentation, ou encore avec l’aide des classes ou
autres attributs associés aux différentes balises en question.
Toutefois, parmi les éléments propres aux CSS, nous pouvons citer des sélecteurs (sélecteur d’éléments ou
de groupe d’éléments, sélecteur de classes, sélecteur d’ID, sélecteur de descendants, etc.), des options de

7
Le livre de Powell Thoams contient des bons exemples de HTML5 et de CSS 3, qui sont les versions utilisées dans
le cadre de notre cas thématique. Il peut être completé en consultant les autres exemples repris sur le site
éducationnel en ligne « W3schools : https://www.w3schools.com/ ».

9
formatage (margin, object-fit, padding, border, background, etc), des unités de mesure (pixels, em, VW) et
le bloc de déclaration (qui est toujours entre accolades et ayant au moins une instruction de formatage).
Ces différents éléments CSS permettent alors de faire des mises en pages sur des pages Web qui peuvent
être créées avec du HTML ou d’ajouter des backgrounds, des styles de textes, d’en-tête, de liens ou de
navigations personnalisés, des images et des layouts, etc.
Enfin, ne souhaitant pas s’éterniser sur d’autres éléments de considération avancée, nous concluons
globalement ce point en disant qu’avec les feuilles de styles en cascade (CSS), les balises sémantiques
particulièrement n’ont pas besoin de maintenance car elles fonctionnent généralement mieux. Elles sont
même devenues plus faciles à utiliser pour créer des sites web responsives8 et plus faciles aussi à
déboguer, puis lisibles et conviviales. Elles arrivent également à éliminer le risque de régression (lors de
leur mise à jour) et à fournir des points d’ancrage pour des tests fonctionnels automatisés, mais aussi
également des crochets pour le langage JavaScript. Les classes visuelles9, qui sont utilisées dans certains
cas, ne valent presque plus la peine car les styles sur les différentes classes sémantiques utilisées est
facilement détectables et produisent même une petite empreinte HTML. D’ailleurs, Andrew Rachel (2007)
nous présente plus de 100 astuces et conseils pour obtenir la majorité de fonctionnalités CSS souhaitées
aujourd’hui dans une page web. Dans le lot de cette présentation, il ne faut pas également passer à côté de
la pratique de préprocesseurs, à l’instar de Less et de Saas, qui sont utilisés aujourd’hui par la grande
majorité de développeurs web pour générer dynamiquement du code CSS. Sans rompre avec le principe
présenté de la syntaxe CSS, ces balises vont donc toujours continuer à accompagner et à optimiser
davantage les différentes fonctions ou classes sémantiques et variables (ré) utilisées dans certains
contextes.
c) Le Javascript et/ou le Jquery
JavaScript, comme son nom l’indique, est aujourd’hui le langage de script par excellence. Interprété, il est
aussi adapté à la fois à la programmation orientée objet et à la programmation fonctionnelle. JavaScript est
principalement utilisé dans le développement de sites ou pages web pour pouvoir gérer les fonctions et/ou
comportements de différents éléments HTML qui y sont repris et que l’on souhaite rendre dynamique et
interactif sur un navigateur Web lorsqu’un internaute-utilisateur fait quelque chose. Il s’agit des
comportements qui sont visibles ou que l’on retrouve le plus souvent du côté client d’une application ou
site Web.
Créé en 1995 par Brendan Eich et standardisé en 1997 par Ecma International sous le nom
d’ECMAScript, JavaScript dispose à ce jour des frameworks et/ou bibliothèques logicielles qui sont très
stables et qui comprennent plusieurs éléments prédéfinis (c’est-à-dire des éléments de données avec des
propriétés ou méthodes particulières). Ces derniers permettent ainsi à JavaScript de lire des clics et des
mouvements de la souris sur un contenu précis d’une page ou navigateur Web ou de lire des défilements
ou des actions sur les touches du clavier, effectués alors par des internautes-visiteurs. Son code est écrit
directement sur la même page Web (fichier HTML), à l’intérieur de la balise <script>, ou dans autre un
fichier externe ayant pour extension « .js », et peut parfois contenir certains éléments HTML et CSS. Et,
comme c’est le cas pour les CSS, le JavaScript utilise aussi les balises, attributs ou classes HTML comme

8
La notion de responsive devrait être comprise ici comme étant un design réactif ou comme un des moyens utilisés
pour faire des mises en page Web adaptées à la taille du device utilisé par un internaute. Elle constitue aujourd’hui
une grande partie de la création de sites web compatibles avec des appareils mobiles. En plus, compte tenu de la
finalité d’une page web à créer, le responsive web design pousse ainsi aujourd’hui tout Web developer à chercher à
adapter son site web (statique ou dynamique) au contenu, à le concevoir sur la base des différents navigateurs web et
à développer une bibliothèque de motifs, mais aussi à rendre cette bibliothèque universellement utilisable et à garder
la performance à l’esprit. Pour y parvenir correctement, Marcotte Ethan (2010 et 2011), évoque l’usage de trois
technologies importantes qui sont : les Fluid grid, les Fluid images et les Media queries. Et, c’est le framework
Bootstrap qui renferme ces trois différentes technologies mais aussi d’autres, puis aide à la création d’un bon design
réactif. Il passe même aujourd’hui pour un des framework les plus populaires en rapport avec ce type de design.
9
L’on devrait noter également que les classes atomiques, comportementales et utilitaires sont toutes des formes de
classes dites non sémantiques comme les classes visuelles. Elles ne valent donc pas aussi ici.

10
des sélecteurs. Son code est interprété et aucune compilation n’est alors requise (parfois pas avant
l’exécution ou l’événement sur la page web concernée) mais il s’exécute en appelant des fonctionnalités
qui devraient faire réagir dynamiquement les différents balises ou attributs HTML contenus dans la page
Web concernée.
Parmi les frameworks et/ou bibliothèques logicielles Javascript les plus populaires aujourd’hui, nous
pouvons citer le Jquery, le Dojo toolkit, le React, l’AngularJS/Angular, l’Ember,js et le Vue.js. Ces
différentes bibliothèques les plus populaires, particulièrement le Jquery, facilitent la création de sites Web
dynamiques, mais aussi la recherche et la manipulation du contenu d’une page Web, et cela, avec l’aide
des différents balises ou attributs HTML qui sont couplés parfois à certains éléments CSS.
Avec JavaScript, il y a aussi la possibilité de créer et de gérer par exemple des animations pour du contenu
ou des éléments HTML sélectionnés, et cela, de différentes manières avec tous ces différents frameworks
et/ou bibliothèques logicielles Javascript les plus populaires cités. Concernant par exemple la bibliothèque
Jquery, Duckett Jone (2014) est encore allé plus loin. Pour lui, cette bibliothèque libre et la plus populaire
de JavaScript, créée en 2006 par Resig John, facilite le développement Web côté client en simplifiant
certains types de fonctions par une écriture du code plus facilement. Il permet notamment aux
développeurs Web d’utiliser AJAX (Asynchronous Javascript And XML) pour récupérer en temps réel
des données côté serveur ou de capturer des événements de gestion d’événements, mais aussi de modifier
tous les éléments DOM (Document Object Model) utilisés10.

Figure 3 - Une portion d’un exemple de code ou de fonction Javascript/Jquery utilisant aussi AJAX (« doSearch »).
Pour conclure, nous retenons qu’en dehors des langages HTML et CSS, les sites ou applications web
dynamiques à créer aujourd’hui, et dont leurs pages responsives sont affichables sur n’importe quel
navigateur web moderne, utilisent aussi le langage Javascript et/ou Jquery. L’on doit également retenir
que d’autres langages web normalisés (de script ou de programmation objets) sont également utilisés. A
propos, Mbuta Ikoko (2007, 2010 et 2018) nous cite par exemple le Perl ou Python (avec le système CGI :
Common Gateway Interface), le PHP (Hypertext Preprocessor), le JSP (JavaServer Pages), le Type Script
et le C# .NET (issu d’Active Server Pages créé par Microsoft vers la fin des années 1990, ASP en sigle, et
qui continue encore à être utilisé pour développer des applications web sur la nouvelle plateforme
ASP.NET). Il y a aussi également l’existence des plusieurs normes ou spécifications qui concernent alors

10
Le DOM est défini comme étant une interface de programmation (API : Application Programming Interface) pour
les documents HTML et XML (W3C : https://www.w3.org/TR/WD-DOM/introduction.html). Il fournit une structure
logique du document orientée objet et chaque élément lié est transformé en un objet possédant ses propres méthodes,
propriétés et valeurs. Il crée donc une représentation arborescente structurée de ce document qui peut être manipulée.

11
tous ces différents langages utilisés pour créer des applications et/ou sites web, le cas par exemple des
normes ou spécifications de W3C évoqués antérieurement. Dans le lot, il y a aussi la norme ISO/CEI
23270 ou ECMAScript pour Javascript. Cette dernière norme est directement ou indirectement liée aux
frameworks ou bibliothèques logicielles dediées plus au développement web côté Front-End, à l’instar
d’Angular, de Node.JS, d’ASP, d’Ajax, de jQuery, de Bootstrap, et de Symphony, etc.
d) Environnement de développement intégré pour le développement web et d’autres outils
web servant pour l’inspection ou la validation des pages web mais aussi pour
l’application de styles.
Pour créer une page web avec du code HTML et/ou pour pouvoir appliquer un style CSS sur la page web
créée avec du code HTML, mais aussi la faire interagir au clic d’un internaute-visiteur par exemple grâce
aux scripts Javascript ou JQuery, il existe à ce jour des éditeurs de texte qui accompagnent nos
développeurs web. Certains de ces éditeurs de texte sont considérées comme de « classiques » (Bloc-
Notes, Notepad, Visual Web Developer Express, Visual Studio .Net, Visual Studio code, Medit, Vim,
Emacs, Eclipse, Coda, jEdit, PHPEdit, Sublime Text, Atom, PHPStorm, NetBeans, TextWrangler,
Smultron, WebStorm, etc.) et d’autres de « WYSIWYG : What You See Is What You Get , ce que vous
voyez est ce que vous obtenez » 11 (Macromedia DreamWeaver, Amaya, Adobe GoLive, MS FrontPage,
TinyMCE, etc.).
Les éditeurs WYSIWYG sont souvent des éditeurs sous une licence fermée. Leur grand avantage ce qu’ils
permettent « de rédiger le contenu d’un site web directement sans avoir à taper la moindre ligne de code
HTML, CSS ou Javascript, etc. Au fait, ils fonctionnent un peu comme un logiciel de traitement de texte »
(Nebra Mathieu, 2009, cité par Mbuta Ikoko, 2010). La plupart des éditeurs WYSIWYG sont aussi
intégrés ou font aujourd’hui partie intégrante des différents systèmes de gestion de contenu, SGC en sigle,
actuellement disponible sur le marché des TIC (lire davantage le point 1.2 ou 3.4). Quant aux éditeurs
classiques, la plupart sont plutôt intégrés aux différents systèmes d’exploitation des ordinateurs ou des
appareils mobiles. C’est le cas avec le Bloc-Notes, le Notepad, ou le TextWrangler, etc. Les autres par
contre sont sous licence ouverte, libre ou fermée, puis téléchargeable et installable par un Web developer
suivant ses besoins et ses préférences professionnels. Le NetBeans, l’Eclipse, le Sublime Text, l’Atom et
le MS Visual Studio font partie de ce lot.
D’ailleurs, le MS Visual Studio, qui est un IDE Microsoft sous licence libre et qui a un éditeur classique,
possède aussi un framework gratuit basé sur le .NET de Microsoft Inc. Il s’agit de l’ASP.NET. Ce dernier
étant le successeur d’ASP (Active Server Pages) depuis 2002, il continue son cours de développement par
la firme Microsoft Inc pour pouvoir permettre aux développeurs Web de développer davantage les
capacités de création d’applications et/ou sites web dynamiques plus efficaces côté serveur. Il prend aussi
également en charge un certain nombre des modèles de programmation ou d’architecture pour la création
d’applications et/ou sites web dynamiques, à l’instar de Web Forms, d’ASP.NET MVC – Model View
Controller – , d’ASP.NET Web Pages, etc. Ces différents modèles d’architecture fonctionnent grâce à un
filtre (moteur ou fichier dll) branché sur le service web IIS (Internet Information Services) via son
interface de programmation, ISAPI (Internet Server Application Programming Interface). ASP.NET
fournit également aujourd’hui plusieurs autres possibilités (le cas des abstractions précieuses et utiles,
telles que la liaison de données, la navigation, la gestion des états et la mise en cache des données) pour
pouvoir faire exécuter un code écrit de manière commode sur un serveur au lieu de le faire sur un
périphérique client. Le code à exécuter est écrit soit en C #, Visual Basic, JScript, ou TypeScript, etc.
A part le lot de différents modèles de programmation ou d’architecture ou conceptuelle évoqués ci-dessus
en rapport avec l’ASP.NET, nous avons aussi le modèle MVP (Model View Presenter) et le modèle
MVVM (Model View View Model) qui sont aussi utilisés sous l’IDE MS Visual Studio, mais plus pour

11
Dans le développement web, WYSIWYG signifie principalement que ce qui est modifié a la même apparence lors
de la publication que lors de la modification. C’est un principe dont l’origine remonte dans les domaines de la
sérigraphie et de l’impression offset.

12
des applications WPF (Windows Presentation Foundation) qui semblent désormais remplacer les
applications WinForms. Quant au modèle MVC, bien qu’il est un modèle qui date (introduit dans le
monde de développement logiciel par Trygve Reenskaug en 1979 comme une solution aux problèmes des
utilisateurs qui contrôlent de grandes quantités de données), il est depuis une décennie le modèle de
programmation ou d’architecture conceptuelle le plus populaire et couramment donc utilisé par la grande
majorité de développeurs web ou systèmes pour ainsi coder mais aussi pour pouvoir séparer la logique
d’entreprise, l’interface utilisateur et le contrôleur afin de traiter par la suite correctement les demandes.
C’est donc un modèle qui augmente la réutilisabilité et la maintenance des composants logiciels.
En plus, à part les éditeurs de texte, dont la plupart sont considérés comme des IDE pour des applications
web, il y existe aussi également des outils dits « d’inspection de pages web ». Ces derniers sont
aujourd’hui disponibles dans presque tous les navigateurs web modernes cités voire précédemment et
permettent aux développeurs web et aux internautes-visiteurs de voir comment le code HTML, CSS et/ou
JavaScript est structuré sur une page web créée (voir figure 4).

Figure 4 - Outil d’inspection de pages web (à droite de cette page web)

Ici, disons que le développeur web ou l’internaute-visiteur devrait tout juste marquer sur un texte, une
vidéo, un son ou une image (le cas pour la page web illustrée) se trouvant sur une page web affichée par
un navigateur pour voir alors par exemple les types de balises, les classes ou les attributs HTML et CSS
liés et/ou utilisés. Certains navigateurs web modernes, qui offrent cette inspection des pages web créées et
affichées, prennent directement en charge le code JavaScript. D’autres par contre non car exigeant d’abord
l’activation de la bibliothèque JavaScript (une chose que tout développeur web devrait avoir à l’esprit).
1.1.4 La conception graphique et les critères d’accessibilité Web (WCAG)
a) La conception graphique
Bohman Jan et Hallberg Åke (1988), qui se situent dans la période post-modernisme et dans celle de la
fusion des médias, définissent la conception graphique comme « une forme d’art fonctionnel qui a pour
tâche de transmettre un message de la manière la plus efficace possible ». En d’autres termes, la
conception graphique passe pour une sorte de langage créatif et esthétique qui est aujourd’hui utilisé par
plusieurs concepteurs dans plusieurs domaines de la société actuelle du savoir, dont les domaines du Web
et/ou de la communication visuelle, etc.

13
Toutefois, avec le développement rapide et continue observés aujourd’hui dans les deux domaines connus
du Web, c.à.d. le Back-end et le Front-end dont les manifestations de la matérialisation ont même
commencé depuis le début des années 2000 avec la fusion des médias, la conception graphique pour le
Web a donc fini aujourd’hui par trouver sa place. Elle tente alors désormais, sous la forme d’une
communication visuelle12, de faciliter la compréhension par un utilisateur du message ou de l’information
qu’un site web construit veut ainsi transmettre, et cela, en concevant ou en créant des pages ou interfaces
web pour ce site de manière à ce que le message en question devienne plus clair d’un point de vue socio-
culturel, technologique, économique, juridique, écologique et/ou psychologique, etc. ; ce qui réduit même
le besoin d’écrire un long texte ou facilite même l’accès et la lecture aisée de pages web conçues ou
créées.
Pour Sundström Tommy (2005), un web développeur devrait plutôt savoir que pour accéder à la page
web, l’utilisateur passe par quatre portes : la porte qui devrait lui permettre d’aimer ce qu’il voit et celle
l’aidant à lire ce qui est écrit mais aussi la porte pour l’aider à trouver réellement ce qu’il cherche et celle
qui va servir de support pour qu’il puisse utiliser tout ce qu’il va trouver sur le site web dynamique
construit. Cette logique de quatres portes de Sundström, qui pourrait même trouver son soubassement dans
le mythique modèle TAM de Teece ou dans le modèle classique à succès de DeLone et McLean, s’impose
en partie actuellement dans la conception graphique pour le Web. Elle permet au fait à une conception
graphique dans le cadre du Web de donner davantage aux développeurs web et autres parties prenantes
impliquées des éléments pour pouvoir créer des pages web acceptables par des utilisateurs ou internautes-
visiteurs.
Pour ce faire, la conception graphique pour le Web devrait également montrer dans sa pratique la manière
dont le contenu choisi ou proposé par les parties prenantes impliquées dans la construction d’un site web
dynamique devrait par exemple être agencé sur une page web créé pour pouvoir transmettre un message
et/ou influencer des comportements cibles. Parmi les éléments qui peuvent constituer un contenu choisi ou
proposé, nous citons par exemple les images, les vidéos, les sons et les textes. Ces éléments sont des
formes ou objets multimédias qui possèdent chacun des propriétés typographiques différentes qui peuvent
être des simples dispositions de police et taille des caractères, de couleurs ou de contrastes, etc. devant
alors créer l’ensemble d’une page web ou interface utilisateur dans un site web construit. Pour Mbuta
Ikoko (2011), « il est aujourd’hui souhaitable que les objets multimédias qui vont contenir les différentes
pages web à créer pour un site web dynamique fonctionnent comme un tout dans un tout, de manière à ce
qu’il n’y ait plus trop d’objets différents, car en soi ils s’affectent ou s’influencent les uns sur les autres sur
une surface spécifique ».
Au fait, dans la pratique, ce qui caractérise en grande partie la conception graphique pour le Web, c’est
l’application de l’esthéthique ou de l’ergonomie sur les pages web créées pour un site, c.à.d. l’aspect
communication visuelle sur une série des pages web créées ou sur l’ensemble du site web dynamique
construit. Comme dit ci-dessus, cette application de l’esthétique ou de l’ergonomie se fait par l’usage des
polices et tailles de caractères (textes ou lettres), des couleurs et/ou des effets sur des images, vidéos, sons
et textes contenus dans la page web créée. Sous-entendu, il y a au moment de l’application de cette
esthétique ou ergonomie la mise en page et la définition de la structure informationnelle sur la série des
pages web créées et qui fait même d’elles des pages web par défaut ou partielles dans un site web, etc. (la
littérature pratique parle de design de templates) De ce fait, les trois principes de la typographie et de la
mise en page ne devraient donc pas être omis. Il s’agit entre autre, pour la typographie, de la symétrie, de
l’asymétrie et du contraste et, pour la mise en page, de la proximité, de la répétition, de l’alignement, de
la sobriété et du contraste.
Concernant les couleurs qui sont utilisées dans cette conception graphique pour le Web, elles ont plusieurs
significations et symboliques (lire Pettersson Run et al, 2004). Ainsi, il faut noter que les différents

12
La communication visuelle est un concept collectif utilisé dans la communication pour décrire la communication
qu'un émetteur peut utiliser pour transmettre un message à un destinataire. Elle se sert dans la plupart de temps des
images, des textes et des couleurs liées.

14
résultats souvent obtenus par les développeurs web (UX), après la définition et l’application de couleurs
dans un site web donné, proviennent de leur mélange (couleurs primaires, secondaires et tertiaires) avec
l’aide par exemple des logiciels de création graphique ou de retouche d’images matricielles (Adobe
Photoshop CC, Adobe XD, CorelDRAW Graphics Suite, Paint.Net, MS Paint, GIMP, InDesign CC,
OmniGraffle, Sketch, Figma, Pixlr, etc.). Ces résultats sont parfois transposables ou pris en charge par le
langage de feuilles de styles (CSS) et/ou par les préprocesseurs CSS, c.à.d. le LESS ou le SASS. Les
différentes couleurs, qui servent de mélange, peuvent parfois être écrits ou appliquées soit en notation
hexadécimale, RGB (Rouge, Green, Blue, c.à.d. Rouge, Vert, Bleu ou RVB) ou HSL/HSV (Hue,
Saturation, Lightness/Value, c.à.d. Teinte, Saturation, Luminosité/Valeur ou TSL/V) (voire figure 5).

Figure 5 – Couleur bleu du logo de l’UPJV sous trois différentes notations ou écritures (RGB, HEX et HSL)
Pour définir, choisir ou mélanger les différentes couleurs à appliquer sur certains contenus multimédias de
pages web créées, les développeurs web (UX) se servent voire plus du cercle chromatique de Johannes
Itten (voir figure 5) qui est aujourd’hui présenté sous plusieurs forme au niveau de différents logiciels de
conception graphique ou de retouche d’images matricielles utilisés.

Figure 6 – Cercle chromatique de Johannes Itten (source : Chambeau Athony, https://www.cours-de-

peinture.net/technique-de-melange-en-peinture-acrylique/, 2019)
Pour terminer, retenons simplement que la conception graphique pour le Web représente aujourd’hui l’une
des meilleures techniques, dites complémentaires, pour pouvoir développer des sites et/ou des applications
web dynamiques esthétiques ou ergonomiques. Elle est intégrée complètement dans le processus ou
procédé de développement web et tourne actuellement en grande partie, d’un point de vue de
communication visuelle, autour de la typographie. Donc, pour arriver à transmettre un message
compréhensible ou à faciliter la compréhension des utilisateurs ou internautes-visiteurs d’un site et/ou
d’une application web dynamique construite ou à construire, elle combine alors des polices ou tailles de
caractères, des couleurs et des effets sur des textes, des sons, des images et des vidéos, avec l’aide parfois
des feuilles de styles (CSS/Less/Sass) ou des différents logiciels de conception graphique ou de retouche
d’images matricielles. Elle donne aussi aux développeurs ou créateurs de contenus web la possibilité de
séparer la présentation visuelle de ces derniers sur une page web créée et qui devrait être acceptée par les
utilisateurs. Oui, par des utilisateurs qui sont actuellement intégrés dans le processus de développement
web du début à la fin comme nous allons le voir dans notre partie empirique.

15
La conception graphique pour le Web, c’est aussi également une sorte de design ou de conception qui
accompagne aujourd’hui la convivialité et/ou l’utilisabilité d’un site et/ou d’une application web construit
ou en cours de construction, car les différents éléments visuels utilisés pour faciliter par exemple le
contrôle et la compréhension des utilisateurs ou des internautes-visiteurs influent sur leur perception quant
à la convivialité et/ou l’utilisabilité. En plus, faisant également partie des meilleures techniques
complémentaires de conception web, elle est alors récente dans les deux domaines du Web et tente de se
répandre à travers le monde depuis plus d’une décennie, et cela, grâce à l’utilisation accrue des différents
outils, applications et/ou services TI multimédias par les acteurs de l’actuelle société de l’information,
appelée aussi aujourd’hui la société du savoir ou de la connaissance qui est déjà même en trait de nous
faire vivre une quatrième révolution industrielle dite non énergétique, le 4.0
b) Les directives ou critères d’accessibilité Web (WCAG).
Les directives ou critères d’accessibilité du contenu Web (WCAG, de l’anglais « Web Content
Accessibility Guidelines » ou du suédois « Webbtillgänglighetsdirektivet » eller « Riktlinjer för
tillgänglighet på webben ») sont des directives élaborées à l’initiative de World Wide Web Consortium
(W3C) qui est un organe de collaboration internationale bien connue et important qui élabore alors des
normes et des standards pour le Web
En effet, ces directives traitent de l’accessibilité des sites ou applications web déstinées à un plus grand
nombre d’utilisateurs ou internautes-visiteurs. Elles sont aussi utilisées ou considérées comme une source
d’inspiration pour les développeurs et les créateurs de contenu Web mais aussi également dans certains
cas comme étant les fondements de la législation ou des exigences13 qui permettent donc de s’assurer ou
de déterminer si un site web est accessible ou non aux personnes avec handicap. Actuellement, plusieurs
versions de WCAG existent et la version à jour est la version 2.1, publiée depuis juillet 2018 par le W3C.
En 2016, comme dit, l’UE avait publié sur son journal officiel une directive Web à propos (cf. OJ L 327,
2016). Et, pour être conforme avec cette directive EU et la dernière version de WCAG14, la Suède a
promulgué et fait entrer en vigueur une nouvelle loi depuis le 01 janvier 2019 qui réglemente désormais
l’accessibilité de différents sites et/ou applications web des organismes publics du pays.
Rappelonségalement ici que les directives ou critères WCAG reposent dans leur ensemble sur quatre
principes (perceptible, utilisable, compréhensible et robustesse) et sur trois niveaux différents de
conformité (A, AA et AAA). Elles ne sont qu’une mise à jour augmentée de la version 2.0. Le niveau AA
est le niveau d’accessibilité auquel devraient satisfaire depuis 2016 tous les sites et/ou applications web et
mobiles destinés à un plus grand nombre d’utilisateurs possible au sein de l’UE. On compte près de 50
critères de niveau AA qui incluent donc le niveau A qui est le niveau minimal ou de base de la conformité.
Le niveau AAA est le plus haut niveau d’accessibilité Web. Au total, plus de 60 critères sont reprises pour
les trois niveaux. Et, pour rendre les sites et/ou application web ou mobiles accessibles ou conformes à ces
différents critères, plusieurs composants différents doivent fonctionner ensemble. Nous pouvons citer par
exemple :
 Le contenu - informations sur une page ou application web, y compris des informations naturelles
telles que du texte, des images et des sons, mais également un code ou un balisage définissant la
structure et la présentation de ladite page ;
 Les navigateurs, lecteurs multimédias et autres « agents utilisateurs » ;

13
Une exigence est une représentation documentée d’une condition ou d’une capacité dont un produit-logiciel (ou un
composant de produit-logiciel) doit posséder pour remplir un contrat, se conformer à une norme ou tout autre
document imposé formellement ou tout simplement dont un utilisateur a besoin pour résoudre un problème ou
atteindre un objectif.
14
La version 2.1 de WCAG contient logiquement tous les critères des versions antérieures mais aussi des ajouts ou
extensions qui concernent principalement les utilisateurs ayant des troubles d’apprentissage ou des troubles cognitifs,
les malvoyants et les utilisateurs d’appareils mobiles tels que les téléphones intelligents ou les tablettes. C’est donc
une version rétrocompatible avec la version 2.0, c’est-à-dire qu’un site Web répondant aux exigences de la version
2.1 devrait également répondre aux exigences de la version 2.0.

16
  La technologie d’assistance, dans certains cas - lecteurs d’écran, claviers alternatifs,
commutateurs, programmes de numérisation, etc. ;
 Les connaissances des utilisateurs, expérience et, dans certains cas, stratégies adaptatives utilisant
le web ;
 Les développeurs - concepteurs, rédacteurs, y compris les contributeurs de contenus pour
personnes avec handicap ;
 Les outils de création - logiciels de création de sites web ou CMS ;
 Les outils d’évaluation - de la disponibilité web, les validateurs HTML, les validateurs CSS, etc.
Pour terminer, faisons noter de manière globale que les directives ou critères d’accessibilité du contenu
Web sont aujourd’hui élaborées pour qu’un plus grand nombre de personnes puisse accéder au contenu
autorisé sur le Web, mais aussi pour éviter un certain type de problème affectant un type spécifique
d’utilisateurs, particulièrement les handicapés, les malvoyants ou les personnes atteintes de dyslexie, etc.).
Elles représentent donc une amélioration très avantageuse si elles devraient être comparées à la loi
fédérale américaine de 1973 qui, portant sur l’accessibilité aux personnes handicapées, a été amendée en
1998 (22 critères) et a comme nom la « section 518 ».En plus, cette directive de l’union européenne
devrait devenir une loi et entre en vigeur au niveau de l’ensemble de l’espace européen au mois de
septembre 2020.
1.2 Les systèmes de gestion de contenu
1.2.1 Définitions et fonctionnalités
Les systèmes de gestion de contenu (de l’anglais CMS : Content Mangement System), qui est l’une des
capacités TI ou numériques de gestion des différents contenus informationnels des entreprises (Enterprises
Content Management ou ECM en anglais), offrent aujourd’hui aux organisations 2.0 la possibilité de
créer, d’archiver (stocker), de rechercher, de contrôler et/ou de publier davantage des informations à partir
d’un environnement de gestion fiable, intégré et flexible, c.à.d. fonctionnel qui peut être tourné vers
l’extérieur ou le web 2.0. Pour Barker Deane (2016), ces systèmes de gestion de contenu sont des
« interfaces logicielles communes qui ont été créées à l’origine pour gérer seulement des contenus non
structurés des organisations avant de les voir s’étendre aujourd’hui à toutes les formes d’informations ou
de contenus associées aux organisations ou entreprises actuelles ». Ils peuvent donc « héberger tout type
d’informations, de contenus ou de fichiers, allant des simples documents textes aux jeux de données, en
passant par la vidéo, le son et les images » (Barker Deane, 2016).
Toutefois, l’idée principale qui a été et qui est encore aujourd’hui derrière la création ces interfaces
logicielles communes est de pouvoir arriver à séparer le contenu (textes, sons, images, vidéos, rubriques,
etc.) du contenant (mise en page ou forme). Ici, tout contenu séparé est alors géré comme un composant
avant de pouvoir être manipulé et réutilisé indépendamment de sa mise en forme. En plus, la majorité de
différents CMS évoqués ci-dessus permettent également à ces organisations ou entreprises de connaître et
d’analyser facilement leurs groupes cibles, mais également de les rechercher à travers les différentes pages
web consultées et de rassembler leurs informations pour des offres marketing et/ou améliorations de
produits par des feedbacks. Dans ces conditions, ils sont donc tout simplement, ces différents CMS cités,
des outils logiciels capables de pouvoir organiser de manière différente la présentation de différents
contenus créés pour des besoins marketing et de communication interne ou externe des organisations ou
entreprises.
1.2.2 Types de CMS
Au niveau du marché des TIC, les CMS existent sous trois types, à savoir (1) les systèmes de gestion de
contenu des actifs numériques ; (2) les systèmes de gestion de contenu métier ; et (3) les systèmes de
gestion de contenu Web. Dans un certain nombre de contextes informatiques, ces trois types cités sont
donc utilisés à des fins différentes où le facteur commun reste tout de même la gestion de contenus
informationnels des entreprises (ECM).

17
  Les systèmes de gestion de contenu des actifs numériques (Digital Asset Management System
ou DAMS15 en anglais).
Les DAMS sont principalement utilisés par les équipes marketing et opérationnelles des entreprises
pour gérer la présence de leur marque en ligne tout en offrant de puissantes fonctionnalités
d’importation et d’exportation, ou celles de traitement optimisé et/ou de conversion automatique des
fichiers.
 Les systèmes de gestion de contenu métier (Business Content Management System ou BCMS
en anglais).
Ils sont utilisés pour aider les entreprises ou organisations à gérer plusieurs types de contenu tout en
fournissant des fonctionnalités d’accès, de synchronisation, d’édition et de partage de fichiers sur une
plateforme collaborative préconfigurée. Au fait, les BCMS tiennent aussi compte des directives de
conformité et de gouvernance des organisations ou entreprises et peuvent même s’intégrer aux
systèmes de gestion d’actifs numériques (DAMS) ou aux systèmes de gestion de contenu Web
(WCMS) via des API spécifiques (Web ou non) pour ainsi fournir des fonctionnalités de
collaboration intégrées. Les fonctionnalités de collaboration intégrées qu’ils fournissent permettent à
un ensemble varié d’utilisateurs de travailler alors ensemble sur plusieurs types de fichiers ou
contenus structurés ou non structurés, et cela, au sein et/ou en dehors d’une organisation. Parmi les
BCMS leaders actuellement sur le marché, nous avons le MS SharePoint, le DropBox Business, le
Google Drive, le Box, le Microsoft OneDrive for Business, le OpenText Hightail, le Sharefile (Citrix)
et le Quip.
 Les systèmes de gestion de contenu Web (Web Content Management System ou WCMS en
anglais).
Ils sont utilisés pour permettre plus spécialement l’accès à des données complexes et à des services
interactifs sur le Web. Ils proposent aussi des modèles16 frontaux par défaut sous forme des sites web. Ces
modèles frontaux dits par défaut permettent aux utilisateurs de se concentrer plus sur la gestion du contenu
web (ajouter, modifier et publier du contenu puis administrer un site web) et non sur la structure
conceptuelle ou l’architecture de l’information17 d’un site web dans son ensemble. Cet aspect des choses a
même rendu plus populaires aujourd’hui les WCMS auprès des différents blogueurs et/ou créateurs de
contenus web qui n’ont pas suffisamment des connaissances techniques sur le développement web. Dans
cette condition, les WCMS peuvent être considérés aujourd’hui comme la réponse aux problèmes de
cohérence, de navigation, de duplication et de contrôle de données ou contenus liés à la gourmandise de
différents services web qui sont créés et/ou utilisés par la majorité des organisations ou des entreprises. Ils
servent alors principalement pour le stockage de contenu ou de modèles des sites web et passent aussi

15
Parmi les DAMS leaders et présents sur le marché, nous avons Libris, Brandfolder, Widen Collective, Canto,
Image relay, WireDrive, IntelligenceBank, Daminion, Bynder et Cumulus.
16
Un modèle doit être compris ici comme étant une abstraction, c.à.d. comme « une simplification d’un système qui
est suffisante pour comprendre le système modélisé et répondre aux questions que l’on se pose sur lui. Un système
peut être décrit par différents modèles liés les uns aux autres » (Combemale Benoît, 2008). Parmi ces différents
modèles décrivant un système, nous avons les modèles d’exigences, d’analyse, de test système, extra-fonctionnel, de
conception, ou de template (lire Jézéquel Jean-Marc et al, 2006).
17
L’architecture informationnelle désigne la classification, le balisage et la structuration de l’information dans le
domaine informatique. Dans le cadre de cération des sites web statiques ou dynamiques, elle joue un rôle important
car elle se réfère à la conception d’un site web structuré. Pour les concepteurs de sites web, cela implique tout
d’abord de nommer chacun des sujets ou des produits que l’on souhaite publier et de les classer dans des catégories
sémantiques. Ces catégories constituent à leur tour les principales composantes d’une hiérarchie de sites web, c.à.d.
d’une hierarchie qui permet aux utilisateurs de s’y retrouver plus facilement et aux opérateurs de sites de travailler
avec eux. Elle est encore très importante lorsqu’elle divise un site en catégories et sous-catégories, et organise les
chemins d’accès de chacune de ses pages, de sorte que les visiteurs atteignent intuitivement les informations
souhaitées en quelques clics seulement.

18
pour un outil par excellence de création, de configuration, de personnalisation et de gestion de ces
derniers. Les WCMS vedettes actuellement sur le marché des TIC sont le WordPress, le Drupal, le
HubSpot, le Sitefinity, le Joomla, l’EpiServer CMS, le Sitecore Experience Platform, le Pantheon,
l’Agility, le Contentful, l’Ingeniux CMS, le Mura, l’Adobe Experience Manager et le Kentico. Ces
derniers n’offrent pas seulement à leurs utilisateurs la gestion de contenus mais aussi des services, tels que
celui d’indexation, de visualisation, de contrôle des versions, de gestion et droits des utilisateurs, de chaîne
de validation de flux de travail (workflow), de support des métadonnées, de syndication (flux RSS) et
d’intégration des sources de données externes.
1.2.3 Architecture d’un système de gestion de contenu
En rapport avec les trois types de CMS qui viennent d’être décrits et que l’on retrouve aujourd’hui sur le
marché des TI, trois architectures existent. Pour Barker Deane (2016), les frontières entre ces trois
architectures sont parfois floues, et une implémentation ou un déploiement de CMS emploie souvent plus
d’une architecture. Ci-dessous, nous présentons de manière synthèse les quelques lignes fournies par
Barker en rapport avec les trois architectures possibles pour un CMS.
 architecture couplée (coupled CMS architecture). Appelée aussi architecture traditionnelle, cette
dernière est l’architecture la plus courante pour la diffusion de contenu Web. Un CMS couplé
récupère le contenu du référentiel, le formate et le diffuse en temps réel depuis le même système
que celui auquel le consommateur de contenu a accès. La gestion du contenu et la diffusion sont
les deux côtés du même système; les éditeurs gèrent le contenu dans le même système à partir
duquel le contenu est livré. L’avantage est que l’aspect en temps réel de la livraison permet une
personnalisation en fonction du contexte du consommateur.
 architecture découplée (decoupled CMS architecture). Dans cette architecture, un référentiel de
contenu manipule et formate le contenu en un artefact quelconque (souvent un fichier HTML
statique), puis déplace cet artefact vers un environnement de remise séparé. Le consommateur
accède à cet environnement de livraison et peut ne jamais entrer en contact direct avec le
référentiel. Il y a quelques années, il s’agissait d’un modèle de livraison commun et présentait des
avantages en termes d’évolutivité, de tolérance aux pannes et (parfois) de coût. Cependant, il a
peu à peu perdu du terrain à mesure que l’immédiateté des architectures couplées prenait de la
valeur.
 architecture sans tête (Headless CMS architecture). Dans cette architecture, l’environnement de
diffusion est séparé (comme avec découplé), mais cet environnement contacte le référentiel en
temps réel pour récupérer le contenu. L’environnement de diffusion peut être un site Web, une
application mobile ou un processus en arrière-plan, le tout utilisant le référentiel de contenu
comme une base de données centrale. Le terme vient de l’idée que la livraison est la «tête» au-
dessus de la pile de gestion. Retirez cette tête et vous avez un CMS «sans tête», c.à.d. un
référentiel de contenu backend permettant de publier le contenu sur toute application ou couche
d’affichage à l’aide d’une API.
Le CMS EpiServer se retrouve également dans le cas de cette frontière floue entre les trois architectures
présentées. Ainsi, il a une architecture qui fournit un code côté client permettant aux appels Ajax de se
rendre au référentiel, ce qui est une forme de sans tête. Traditionnellement, un CMS couplé, son
architecture possède aujourd’hui des fonctionnalités suffisamment étendues du découplé et/ou du sans
tête. Ces fonctionnalités architecturales étendues font alors de EpiServer un CMS intégré, flexible et
fonctionnel, c.à.d. complet et facilitant la collaboration et le suivi de gestion de contenus entre différents
utilisateurs, etc.
Pour terminer, disons que les CMS, comme un des outils ou capacités TI implémentables pour pouvoir
gérer le contenu de toutes organisations actuelles, particulièment les organisations 2.0, ils sont donc à
mesure de gérer alors aussi des multiples problèmes ou risques qui peuvent être causées par les autres
capacités TI implémentés ou utilisées, particulièrement les capacités TI sociales émergentes d’un point de
vue sécurité des informations (protection, confidentialité, intégrité, disponibilité, sûreté, ...) ; surtout celles
créées de manière non structurée et qui, avec leur accroissement rapide ou génération continue, pourraient

19
créer une certaine manque de confiance entre les différentes parties prenantes. En plus, ils ne gèrent pas
seulement ce contenu généré ou produit par les différentes parties prenantes et les autres multiples
problèmes ou risques liés mais ils accompagnent aussi également leur communication, c.à.d. leur partage
et/ou échange responsable entre les différentes parties prenantes, et cela, dans le but de créer de la valeur
ou d’atteindre différents objectifs stratégiques, tactiques ou opérationnels définis.
1.3 Un mot sur les projets informatiques ou TI dans leur ensemble
1.3.1 Définitions et types de projets informatiques
Les projets informatiques dans leur ensemble sont réalisés pour construire, créer ou fabriquer des
produits-logiciels pour le compte des organisations, entreprises ou individus. Ils sont souvent réalisés en
interne ou à l’externe des organisations, et cela, pour des raisons de productivité ou performance
organisationnelle mais aussi en fonction de la disponibilité des acteurs TI compétents. En ces termes,
ils soutiennent donc l’ensemble «... l’évolution des systèmes d’information existants dans les
organisations ou entreprises. Ils font partie des projets systèmes d’information » (Morley Chantal, 2012).
Il existe globalement deux types de projets informatiques : « les projets d’exploitation informatique et/ou
TI » et « les projets de développement et/ou maintenance logiciels ». Ces deux types sont gérés soit en
partenariat ou de facon mixte et tournent sur cinq dimensions fondamentales, à savoir (1) la mission,
(2) les activités critiques à réaliser, (3) les compétences et connaissances de membres à affecter,
(4) la relation avec le reste des unités d’affaires de l’organisation ou entreprise concernée, et (5)
la gouvernance (lire Manon Guillemette et Paré Guy, 2007, cité par Mbuta Ikoko, 2011 et 2018).
Ces cinq dimensions sont liées entre elles et font face à la gestion des difficultés techniques
d’analyse, de conception et de réalisation, mais aussi à celle de mise en oeuvre des logiciels souhaités
par le client ou par les bénéficiaires finaux, c.à.d. par les utilisateurs18. Ici, même dans des conditions où
un projet informatique type devrait s’appuyer sur une équipe compétente et sur des architectures
informatiques et/ou des réseaux de communications sophistiqués et opérationnels du client ou existants sur
le marché. D’ailleurs, derrière cet aspect des choses, certaines propriétés de risques apparaissent
également ; le cas par exemple de la gestion et sécurité de données (protection, confidentialité, intégrité,
disponibilité, sûreté, ...) et de la qualité des services et/ou produit-logiciel à offrir (disponibilité des
services, pérennité, relation avec les utilisateurs, ...).
Toutefois, pour pouvoir gérer correctement ces différentes difficultés ou risques, les parties prenantes qui
vont être impliquées au projet doivent tout d’abord établir et organiser une politique de gestion adaptée
puis définir par la suite des objectifs à réaliser ou atteindre (cf. ISO/CEI 9000 : 2005). Dans le lot des
objectifs à définir, il ya trois qui sont majeurs et qui devraient coûte que coûte être atteints. Il s’agit
des objectifs liés (1) au respect des besoins exprimées par le client ou des exigences du produit-logiciel
élaborées par toutes les parties prenantes impliquées ; (2) au respect des coûts et (3) au respect des délais.
Ces trois objectifs majeurs ne sont souvent atteints qu’avec la volonté des différentes parties prenantes
du projet et avec l’aide des différentes autres ressources ou capacités organisationnelles mises àla
disposition (financières, matérielles, informationnelles, etc.). Quant à la politique de gestion, cette
dernière fait simplement appel à la gouvernance du projet pour pouvoir parvenir au but ou à la finalité
(souvent la fabrication ou la fourniture d’un produit-logiciel). Cette politique est souvent reprise dans la
charte du projet informatique en cours d’exécution. La charte du projet informatique est tout simplement
un document synthèse de l’engagement que prend l’organisation parrainant le projet (le sponsor du
projet, le client) ou ayant signé le contrat avec l’organisation fournisseur ou fabricant du produit-logiciel
(partenaire TI). En référence aux bonnes pratiques de gestion globale de projet, reprises dans le PMBoK

18
Au fait, si nous suivons Frederick Brooks (2001, cité par Mbuta Ikoko, 2011), qui a aussi évoqué cet aspect des
choses, nous dirons qu’un projet informatique est souvent un projet difficile par sa nature (fabrication du produit-
logiciel) et paraît également complexe d’un point de vue de pilotage et/ou de gestion (des coûts, des délais, du
temps, des ressources et des communications, etc.). De ce point de vue, il comporte « une part importante
d’incertitudes ou de risques liés et qui font suite aux particularités dues surtout au produit-logiciel à fabriquer»
(Frederick Brooks2001, cité par Mbuta Ikoko, 2011).

20
de 2012, le contenu de cette charte ne peut être défini en l’absence d’une certaine compréhension claire
sur la manière dont sera planifié, organisé, dirigé (pilotage) et contrôlé toutes les ressources affectées
au projet pour pouvoir atteindre le but et les objectifs définis.
1.3.2 Modes d’approvisionnement et éléments de pilotage opérationnel au sein d’un projet
informatique
Ayant déjà évoqué les lignes globales de partenariat dans un projet informatique, profitons pour faire noter
que la littérature TI parle de l’existence des quatre modes d’approvisionnement informatique ou TI
possibles au sein d’une organisationou entreprise. Il s’agit au fait des modes d’approvisionnements à
l’interne, en partenariat, en impartition et en récupération. Un des ces quatre modes
d’approvisionnement TI peut être décidé dans une organisation ou entreprise selon qu’il s’agit d’une
vision informatique de développement logiciel à forte ou à faible transformation organisationnelle
ou selon la valeur stratégique de l’informatique au sein de l’entreprise. Concernant les acteurs à
impliquer ou à affecter dans un projet, ils doivent tout simplement appréhender leur projet
informatique sous une logique « mixte » et chercher à œuvrer comme étant une structure organisationnelle
temporaire orientée vers l’accomplissement d’un objectif donné (souvent c’est la fabrication ou la
fourniture d’un produit-logicielà un client) (Mbuta Ikoko, 2011). Suivant cette logique mixte, les
acteurs TI de l’organisation TI partenaire, qui seront affectés au projet informatique, devraient donc
partager les responsabilités (sur les éventuels risques et bénéfices évoqués précedemment) avec les acteurs
TI et métiers de l’organisation cliente, et cela, en plus de l’obligation de transférer leurs expertises aux
acteurs TI et métiers de de l’organisation cliente. Ensemble, ils doivent mettre dans leur têtes que le projet
en cours de réalisation n’est qu’une organisation temporaire qui a une finalité ou un but à atteindre, –
la fabrication d’un produit-logiciel –, mais aussi des objectifs bien définis à partir de cette finalité ou but.
Le projet informatique de développement logiciel étant un processus19 de modélisation unique et
complexe, la personne qui va être désignée parmi les parties prenantes comme le répondant auprès du
sponsor devrait alors disposer d’un bon profil et adopter un bon style de collaboration ou rôle de gestion
pour la réussite ou le succès. Pour Vital Roy et al. (2007, cité par Mbuta Ikoko, 2009), qui se basent
sur les travaux d’Aaron Shenhar (2001), de Gottschalk Peter et Karlsen Jan (2005, qui ont utilisés la
typologie des six rôles de gestion de Mintzberg Henry, 1994) et de Quinn Robert (1988, qui parle
des divers rôles de gestion pour la recherche de performance dans des contextes organisationnels
spécifiques), « le bon style ou rôle de gestion à adopter ou à jouer par le chef d’un projet informatique de
développement logiciel pourrait être soit celui d’un producteur, directeur, coordonnateur ou contrôleur.
Cette série des styles ou des rôles de gestion à jouer ferait même directement appel à un profil de
type « leader transactionnel».
Il peut aussi avoir le profil de « leader transformationnel ». Dans ce cas, la série des styles ou rôles de
gestion à adopter ou à jouer devrait être soit celui d’un agent de liaison, d’un innovateur, d’un mentor ou
d’un facilitateur. Si la personne désignée est une ressource externe à l’organisation cliente ou à
l’entreprise commanditaire, elle devrait alors chercher à ajouter le style ou le rôle de «spokesman» au
deux profils cités sinon celui de «resources allocator » si elle est une ressource interne. à l’entreprise
commanditaire. Au niveau de PMBoK, il est même recommandé à cette ressource désignée d’utiliser
fortement les lignes directrices de management par objectifs qui, selon notre contexte, «doivent être
propre au développement informatique et à la recherche d’un niveau de qualité acceptable » (Lavoie
Luc, 2009, cité par Mbuta Ikoko, 2011). Il s’agit au fait d’un management de réalisation ou
par processus orientés produit-logiciel mais qui ne doit surtout ne pas s’écarter des 4 principales fonctions
ou processus classique, à savoir la planification, l’organisation, la direction et le contrôle. C’est
également un management qui, via la fonction «contrôle», devrait permettre de mettre sur pied une
démarche qualité basée sur l’amélioration continue des exigences élaborées et, par principe d’unicité que

19
De manière générale, un processus « représente un ensemble d’activités effectuées par une ou plusieurs personnes
dans le but de créér un produit, avec un coût et des moyens matériels. Il est souvent constitué de sous-processus ou
tâches selon une décomposition hiérarchique dont l’activité est l’élément du plus bas niveau » (Mbuta Ikoko, 2011).

21
dispose tout projet, d’intégrer des processus ou des activités spécifiques définies par la transformation ou
déclinaison des différents objectifs fixés. Pour définir ou élaborer, mais aussi maîtriser, assurer et
améliorer par exemple de manière continue les différentes exigences élaborées, puis les processus
intégrés ou les activités spécifiques définies, la démarche qualité ou agile est recommandée aujourd’hui à
tout prix. Comme nous allons le présenter plus loin dans ce rapport, c’est en effet une démarche qui est
adoptée et utilisée actuellement par plusieurs communautés TI ou développeurs des logiciels à travers le
monde.
1.3.3 Les processus et/ou procédés de développement pour les sites ou applications web
a) Les différents procédés de développement logiciel ou du Génie logiciel
Les différents processus utilisés aujourd’hui pour développer des applications ou sites web ne sont entre
autre que les différents processus déjà connus et utilisés pour d’autres types de développement logiciel
(applications ou systèmes informatiques classiques, etc.), mais avec des légères différences. En plus, tel
qu’il est observé depuis un moment dans la littérature, il n’existe presque pas à ce jour des processus
théoriques et pratiques spécifiques et/ou qui ont été formellement proposés ou adoptés par les acteurs du
domaine pour pouvoir développer des applications ou sites web pour des organisations actuelles. A
propos, certains auteurs du domaine parlent voire tout simplement de l’absence d’une preuve réelle d’un
nouveau paradigme qui émerge ni de la nécessité des nouveaux concepts ou théories dans la recherche, en
dehors des quelques retours d’expérience en rapport avec l’expérience utilisateur, l’interfaçage
d’utilisation et/ou le responsive design (lire Kautz Karlheinz et al, 2007 ; Sommerville Ian, 2007 ; Benyon
David, 2014, etc.). Pour Mbuta Ikoko et Kesangala Ozeme (2008), « un processus ad hoc sous attendu
pour le développement des sites ou applications web dynamiques a déjà commencé depuis à faire son
chemin mais il n’est pas encore dans sa phase terminale. Ce dernier semble même être basé en grande
partie sur les recommandations fournies par Scott Isensee, Karel Vredenburg et Carol Righi en 2001, en
rapport avec le développement logiciel centré utilisateurs et utilisant une approche intégrant les histoires,
les scénarios et les modèles pour pouvoir développer un produit-logiciel fiable, fonctionnel et/ou
convivial » (Ivinza Lepapa, Mbuta Ikoko et Kesangala Ozeme, 2008).
Toutefois, face à l’absence d’une série des preuves réelles, l’usage de différents processus ou procédés
connus du Génie logiciel, dont l’IEEE a proposé un modèle global, s’impose donc à tous les développeurs
web (voir figure 7).

Figure 7 – Le cycle de vie du logiciel et la place naturelle d’un procédé20de développement logiciel (source : Luc
Lavoie, 2007, cité par Mbuta Ikoko, 2011)

20
Un procédé est défini comme étant « un ensemble des moyens et des méthodes qui permettent d’accomplir une
activité (tout en préservant leurs dépendances intrinsèques) » (La norme NF X 50-125, cité par Mbuta Ikoko, 2003).

22
Le modèle global ou le cycle de vie du logiciel de l’IEEE, repris sur cette figure, renferme 4 groupes de
processus répartis en processus, sous-processus et/ou activités dites « de gestion de projet » et
« techniques ». Les 4 groupes de processus sont (1) l’Avant-projet, (2) le Développement, (3) la
Maintenance et exploitation (4) et le Retrait.
En rapport avec le groupe de processus « Développement », connu plus dans la littérature de Génie
logiciel sous le nom de « cycle de développement logiciel », ce dernier, en dehors des activités de gestion
de projet et des activités techniques reprises dans la figure ci-dessus (étude préalable, vérification et
validation, gestion de la configuration, planification du projet, pilotage et suivi du projet, etc.), possède
aussi d’autres activités techniques appelées « activités techniques clés ». Ces autres activités techniques
dites clés sont l’analyse, la conception, l’implémentation et les tests et installation et représentent le
procédé de développement logiciel. Elles tournent généralement autour de deux grands courants de
développement logiciel connu dans le domaine du Génie logiciel, à savoir (1) le courant des procédés
prédictifs ou classiques de développement logiciel, avec des procédés tels que la Cascade (Waterfall), le
V, le W, par Incréments et la Spirale ; et (2) le courant des procédés synthétiques ou agiles de
développement logiciel, avec des procédés tels que le RUP : Rational Unified Process, le 2TUP : Two
Tracks Unified Process, le RAD : Rapid Application Development, le XP : eXtreme Programming et le
Scrum, etc.
Pour Lavoie Luc (2007, cité par Mbuta Ikoko, 2011), les activités techniques clés, qui viennent d’être
citées ci-dessus, aident en effet tout projet TI et l’équipe constituée de pouvoir arriver à construire, créer
ou fabriquer un produit-logiciel fonctionnel, convivial et/ou ergonomique. Ensemble avec les autres
activités techniques et celles de gestion de projet TI, elles passent alors pour un ensemble homogène
d’actions concourant à un même objectif, c.à.d. à la création, construction ou fabrication d’un produit-
logiciel de grande qualité. Pour ce faire, elles nécessitent des compétences qui doivent analyser les
différentes responsabilités opérationnelles attendues et qui devraient réaliser ou faire-faire les différents
travaux ou tâches liées. En définissant même ici les travaux ou tâches liées dans un projet TI et/ou de
développement logiciel, on définit logiquement le quoi faire (lire Vauquier Dominique, 2003, cité par
Mbuta Ikoko, 2011).
Un autre élément à faire retenir ici ce qu’avec les différents procédés prédictifs cités ci-dessus,
particulièrement le procédé en cascade, les différentes activités techniques clés évoquées sont planifiées et
exécutées sous forme des phases ou des flux séquentiels où chaque phase devrait être complétée avant que
la phase suivante ne puisse commencer. C’est un procédé qui ne fonctionne que pour des projets TI avec
un minimum de changements et une faible complexité. Dans l’ensemble, presque tous les différents
procédés prédictifs ne conviennent pas pour faire face à l’évolution des exigences et les problèmes de
changement ou d’intégration ne sont souvent observés qu’au dernier stade. Quant aux différents procédés
agiles ou synthétiques, ils ont été développés pour gérer les problèmes des conditions changeantes pendant
un projet TI et/ou de développement logiciel. Ils sont donc basés sur une philosophie de développement
logiciel de qualité globale qui se fait de manière itérative, progressive ou incrémentale en fonction des
objectifs, interactions ou exigences centrées utilisateurs. Pour Ivinza Lepapa, Mbuta Ikoko et Kesangala
Ozeme (2008), qui citent le Manifeste Agile, cette philosophie a quatre valeurs clés définies qui sont :
- les individus et les interactions sur les processus et les outils
- Logiciel de travail sur une documentation complète
- Collaboration client sur négociation de contrat
- Répondre au changement au sujet d'un plan
En plus, les objectifs, interactions ou exigences de différents procédés agiles ou synthétiques, en termes
des besoins exprimés par le client, ne sont pas définis de manière définitive dans leur ensemble. Ils sont
évolutifs, c.à.d. améliorés ou changés au fur et à mesure que le projet avance, et cela, grâce aux feedbacks
des parties prenantes concernées sur les différents prototypes fabriqués ou sur le produit-logiciel finalisé ;
un produit-logiciel finalisé qui est même mesuré sur la base de sa facilité d’utilisation, de sa flexibilité et
de sa facilité d’apprentissage (lire Petter Stacie, Delone William and McLean Ephraim, 2008). Ceux-ci
exigent toutefois aux des parties prenantes concernées de ne pas seulement s’occuper de leur propre
communication et de la mise sur pied des différents processus, sous-processus et prototypes (qui se

23
rattachent au développement itératif du produit-logiciel souhaité et attendu par des utilisateurs finaux),
mais aussi de la gestion des coûts, des délais, du temps et des ressources complémentaires comme c’est
également le cas avec les procédés prédictifs.
Chaque procédé de développement logiciel cité précédemment, que ca soit a ses propres avantages et ses
faiblesses, que ca soit pour le procédé de type prédictif ou pour un procédé de type agile. Ces propres
avantages et faiblesses sont souvent conditionnés par le choix et l’usage qui y est fait au sein d’une
organisation ou entreprise par les acteurs de la fonction TI et/ou par les des organisations ou entreprises TI
sous-traitantes21. Il n’y a donc pas une vision hégémonique qui devrait être fournie par rapport aux deux
grands courants inspirateurs de développement logiciel évoqués même si dans un rapport enquête de Hotle
Matthew et Wilson Nathan, publié en 2016 et portant sur l’évaluation de la pratique de différents
procédés, particulièrement la pratique du procédé prédictif en cascade (cf. « The End of the Waterfall as
We Know It »), le cabinet Gartner Inc. propose l’exclusion progressive de certains procédés classiques ou
prédictifs car jugés trop rigides et lourds. D’ailleurs, le même cabinet avait déjà recommandé depuis 2012
aux organisations ou entreprises de ne plus utiliser le procédé prédictif en cascade car ne faisant presque
pas face aux procédés synthétiques ou agile en termes de qualité, de communication, d’efficacité, de
flexibilité et de satisfaction du client. Pour certains acteurs du domaine, ce fut une tentative de proposition
de positionnement ou de préférence de sa part qui, à ce jour, ne fait pas toujours de l’unanimité auprès de
différents communautés de développeurs de logiciels. A la place, il y a plutôt emergence d’un usage
hybrides des procédés, c.à.d. une intégration de procédés agiles et prédictifs selon le contexte du projet TI
b) La notion de fonctionnalités attendues par les utilisateurs
Face aux deux grands courants connus du cycle de développement logiciel, il existe une notion importante
qui se trouve liée à n’importe quel procédé de développement logiciel choisi ou utilisé au niveau des
organisations 2.0 ou dans un projet de développement logiciel. Il s’agit en effet de la notion des
fonctionnalités logicielles ou d’exigences fonctionnelles attendues sur tout produit-logiciel à construire, à
créer ou à fabriquer.
Au fait, cette notion de fonctionnalités logicielles est appliquée dans un processus de développement
logiciel lors de l’analyse des besoins exprimés par un client ou directement par des utilisateurs finaux du
produit-logiciel à fabriquer. Elle permet, cette notion, à ce que des développeurs puissent arriver à faire
coexister dans leur pratique de développement adoptée les différents avantages de plusieurs procédés
connus et/ou cités ci-dessus, et cela, sans pour autant donner plus d’importance à l’un ou à l’autre. C’est
aussi une notion qui oblige tout développeur de logiciels à pouvoir réaliser une série de tâches
indépendantes, dites tâches de collecte, de rédaction, de compréhension et d’évaluation de différentes
expressions ou besoins métiers du client ou des utilisateurs, avant de pouvoir entamer concrètement les
tâches ou activités techniques clés du processus développement logiciel. Cette série de tâches
indépendantes transforme donc les différentes expressions ou besoins métiers exprimés par le client ou par
les utilisateurs en un véritable modèle d’exigences, puis par la suite à d’autres modèles, tels que ceux
d’analyse, de test système, extra-fonctionnel, de conception et de template (lire Jézéquel Jean-Marc et al,
2006).
Liée à la notion d’ingénierie des exigences22 et à celle d’ingénierie des modèles, mais aussi également à la
notion de vérification et de validation du produit-logiciel fabriqué, la notion de fonctionnalités logicielles
n’est donc pas seulement une notion importante mais elle est aussi actuellement une notion unificatrice.

21
La notion de choix et d’usage d’un procédé de développement logiciel par une fonction TI au sein d’une
organisation est aujourd’hui très précieuse car elle permet à l’ensemble d’acteurs de cette fonction de pouvoir aussi
focaliser plus leur attention sur l’ensemble du cycle de l’utilisation du produit-logiciel à fabriquer, c.à.d. de la prise
de conscience initiale des utilisateurs à l’utilisation productive pour l’organisation.
22
L’ingénierie des exigences détermine les qualités de différents procédés de développement logiciel et de produits à
fabriquer. Elle permet et encadre aussi la communication entre les différents acteurs d’un projet TI. Pour Lavoie Luc
(2007, cité par Mbuta Ikoko, 2011), son importance augmente avec la taille du problème à résoudre ou du produit-
logiciel à fabriquer.

24
Pour Beynon-Davies Paul (2009, cité par Mbuta Ikoko, 2011), c’est une notion qui comprend en plus les
critères « qualité » du système à construire, de l’information à produire, à partager ou à stocker et du
service à offrir. Elle est donc à considérer comme le socle de tout processus de développement logiciel
actuel. En ce terme, elle devrait alors être désormais définie comme étant un processus de raffinement
souple (c.à.d. prompt à réagir aux exigences fonctionnelles changeantes ou mouvantes) et/ou itératif qui,
malgré son indépendance connue, est associé aux différentes activités techniques clés du cycle de
développement logiciel. Pour Messager Rota (2007), en tant que processus de raffinement souple mais
aussi itératif, il devrait souvent être réalisé avec l’aide des langages munis d’une sémantique formelle [le
cas de UML qui « permet la modélisation de tout système ou application informatique indépendamment
de toute démarche ou de plate-forme » (Roques Pascal, 2009)].
Dans le cadre de développement des sites ou applications web, cette notion de fonctionnalités logicielles
vise également à déterminer, organiser, communiquer et gérer les besoins inclus ou non dans un cahier des
charges et qui sont souvent changeants ou dynamiques. Elle garantit dans ce cas les liens de traçabilité
attendus entre les différents modèles à concevoir et/ou à rendre opérationnels, c.à.d. à transformer lors des
différentes activités techniques clés devant aboutir à la fabrication de prototypes ou du site ou application
web finale, mais aussi sur les besoins continus des utilisateurs finaux servant ainsi d’amélioration du site
web construit, en cours de construction ou sous-test et prêt à être mis en production (lire à propos « Le
génie logiciel et l’IDM : une approche unificatrice par les modèles » de Jézéquel Jean-Marc et al, 2006 ;
« Ingénierie Dirigée par les Modèles (IDM) – État de l’art » de Combemale Benoît, 2008 ; « Architecture
à 4+1 niveaux » de Kruchten Philippe, 1995 ; etc.).
A l’égard de ce précédent paragraphe, et grâce aux différents processus et/ou procédés de développement
logiciel évoqués précédemment et qui représentent à ce jour la seule source d’inspiration théorique et
pratique pour les développeurs web. Le processus ad hoc de développement web qui faisait son chemin
semble être arrivé presqu’aujourd’hui dans sa phase finale de constitution. Malgré l’avancée observée, il
existe encore un certain nombre des problèmes persistants qui sont liés à des caractéristiques qui sont
propres aux domaines du web (lire Murugesan San et al, 2001 ; ou Kautz Karlheinz et al, 2007 ; Garrett
Jesse, 2011, etc.). Parmi ces problèmes persistants, nous citons :
- un délai court et une concurrence féroce sur le marché,
- des mises à jour continues,
- un développement technique rapide,
- un grand intérêt pour les interfaces,
- une difficulté lors de l’identification ou élaboration des exigences,
- des tests qui sont axés sur la convivialité et sur l’utilisabilité,
- une équipe de développement multidisciplinaire, et
- un large public d’utilisateurs
Avec les différents problèmes persistants cités, le processus ad hoc de développement web en constitution
semble présenter de plus en plus un penchant pour le courant de procédés synthétiques ou agiles. Et, parmi
les procédés agiles qui sont observés dans plusieurs projets web exécutés actuellement, c’est pratiquement
le procédé Scrum qui revient souvent et qui semble être le mieux adapté, mais aussi le cadre théorique et
pratique proposé en 2010 par Garrett Jesse James et appelé « The fives planes ».
c) Quelques procédés ou processus agiles ou spécifiques utilisés actuellement pour développer
des applications ou sites web 2.0 au sein des organisations 2.0
 Le cadre Scrum
La littérature présente le procédé Scrum comme un cadre agile ou synthétique qui est centré sur les
besoins et/ou exigences évolutives ou changeant des utilisateurs par rapport à un produit-logiciel à
construire, particulièrement sur les histoires des utilisateurs (users stories) ou cas d’utilisation du produit-
logiciel par les utilisateurs. Cet aspect des choses procure à ce cadre agile un grand avantage face aux
autres cadres et/ou procédés, agiles tout comme prédictifs, concernant la qualité du produit-logiciel à
construire.

25
Toutefois, par définition, le Scrum devrait simplement être compris comme un procédé agile ou
synthétique qui a trois principales catégories d’acteurs (Product Owner, Scrum Master et Development
Team) formant ensemble une équipe de projet appelée « Scrum Team » et dont ces trois principales
catégories d’acteurs possèdent différents types d’expertise. Les trois principales catégories d’acteurs
travaillent sur des artefacts (Product Backlog, Sprint Backlog et Increment) et sur des événements itératifs
liés à ces artefacts (Sprint, Sprint planning, Daily Scrum, Sprint Review et Sprint Retrospective) afin
d’aboutir à un but commun. En d’autre mot, elles ont pour mission de mettre sur pied des processus, des
sous-processus et des prototypes qui se rattachent au développement itératif d’un produit-logiciel souhaité
par un client ou ses utilisateurs finaux. Dans ce même ordre d’idées, les trois principales catégories
d’acteurs, c.à.d. le Scrum Team, le Product Owner et le Development Team devraient aussi s’occuper et
promouvoir davantage leur propre communication et soutenir ensemble tous les événements ou activités
itératives définies (Sprint, Sprint planning, Daily Scrum, Sprint Review et Sprint Retrospective).

Figure 8 - Scrum framework et ses principales parties [Sutherland Jeff et Schwaber Ken (2017, reprise par Mbuta
Ikoko, 2018), source : https://www.scrum.org/resources/what-is-scrum).
Le cadre ou procédé agile Scrum est donc bâti sur des événements itératifs mais aussi sur des incréments à
définir et/ou à produire de manière progressive par les trois principales catégories d’acteurs déjà citées. Et,
pour une itération définie et déclenchée, elle doit conventionnellement durer entre deux ou quatre
semaines et être à mesure de spécifier le contexte d’utilisation de nouvelles fonctionnalités qui sont
supposées être développées et utilisées une fois finalisées, mais aussi produire des solutions simples pour
ces nouvelles fonctionnalités attendues et enfin évaluer également ces nouvelles fonctionnalités par
rapport aux besoins ou exigences exprimées par les utilisateurs finaux, et cela, par l’entremise du Product-
owner. D’ailleurs, avec le cadre ou procédé agile Scrum, les clients ou les utilisateurs finaux ne savent
presque pas toujours exactement ce qu’ils veulent. C’est plus avec le temps ou lors de certains livrables
clés du produit que leur vision concrète du produit-logiciel se matérialise.
Le Scrum, c’est aussi également « une approche empirique ou expérimentale agile de fabrication du
logiciel qui met à profit une interaction intense et continue entre l’équipe de développement, le scrum
master et le product-owner, c.à.d. le client » (Lavoie Luc, 2007, cité par Mbuta Ikoko, 2011). En rapport
avec les bonnes ou meilleures pratiques Scrum par exemple, nous noterons que le but de chaque itération
ou sprint défini est de pouvoir permettre à l’équipe de développement (Development Team) de produire au
final une application et/ou un site web évolutif et fonctionnel ou de créer des incréments dits « terminés
(Creating « Done » increments) qui sont souvent présentés de manière continue au client (product-owner
ou propriétaire du produit) lors de leur réalisation, et cela, suivant un contexte donné afin de s’assurer
qu’elle répond ou qu’ils répondent aux différents besoins continus exprimés par les utilisateurs (histoires
des utilisateurs) et/ou aux exigences fonctionnelles de base élaborées (histoires des utilisateurs mises en
valeur).
Suivant toujours les bonnes et/ou meilleures pratiques Scrum, c’est le product owner qui représente le
client au sein d’un projet ou les utilisateurs finaux du produit-logiciel souhaité mais aussi leurs intérêts. Il
devrait ainsi maximiser la valeur de l’application et/ou du site web en construction tout en raffinant ou
rendant alors simple et claire les différents besoins continus exprimés ou histoires des utilisateurs. Ici, face

26
aux besoins exprimés par des utilisateurs, qui sont souvent évolutifs ou continus et clarifiés par un
product-owner, des nouvelles itérations pourront avoir lieu sur ces dernières et durer entre 2 ou 4 semaines
comme à l’accoutumée. Nous noterons aussi qu’avec le démarrage ou le déclenchement d’une nouvelle
itération, l’on est supposé d’abord résumer le travail de l’itération précédente et ajouter des nouvelles
fonctionnalités attendues ou à développer (cf. Sprint Review et Sprint Retrospective). Au fait, la nouvelle
itération démarrée devrait ainsi être à mesure de spécifier le contexte d’utilisation de nouvelles
fonctionnalités attendues, de produire des solutions liées et, au final, de les évaluer pour une autre
amélioration future ou pas.
En définitive, pour Cohn Mike (2010, cité par Mbuta Ikoko, 2018), le cadre Scrum « est un procédé agile
qui passe pour une approche la plus éprouvée, documentée et supportée par une très grande communauté
de développeurs des systèmes ». Il est centré sur les utilisateurs du système à fabriquer (UCD23: User
Centered Design) et aide donc aujourd’hui plusieurs équipes de développement à pouvoir fournir aux
utilisateurs des applications et/ou sites web flexibles et de qualité fiable à partir des besoins, histoires ou
cas d’utilisation exprimés, et cela, de manière rapide et conviviale. Le procédé Scrum intègre au fait dans
sa pratique la notion de fonctionnalités logicielles attendues par les utilisateurs finaux qui constitue
même actuellement le socle du management de la qualité qui, comme précisé par la norme ISO 9000 :
2000, cité par Mbuta Ikoko et RIZWAN Shan, 2010), «... est axé sur la définition des objectifs qualité et
sur la spécification des processus opérationnels et des ressources afférentes pour atteindre les objectifs
qualité ». C’est donc un procédé et/ou un processus qui devrait ainsi aider tout projet TI de développement
des applications et/ou sites web à gagner encore davantage en efficacité et en efficience et à accroître la
satisfaction de différentes parties prenantes, particulièrement la partie cliente (le sponsor et les utilisateurs
finaux du produit-logiciel à construire). Il va alors très bien avec la tendance actuelle de développement
web, à savoir la conception web dynamique graphique. Toutefois, ensemble avec les autres procédés
agiles de développement logiciel, il est également aujourd’hui sur le point d’enterrer totalement certaines
approches prédictives qui avaient fait leur beau temps dans le passé. Pour Mbuta Ikoko et Mekuate Gisèle
(2018), sa beauté résiderait dans la simplicité empirique de sa mise en œuvre qui met surtout l’accent sur
la confiance, la transparence, l’inspection et l’adaptation par un travail d’équipe efficace et une
amélioration continue. En plus, il est aussi un procédé qui est piloté en cogestion ou de manière
fonctionnelle par ses trois principales catégories d’acteurs, à savoir le Scrum master, le Product-owner et
le Development Team. Toutes ces trois principales catégories d’acteurs sont donc obligées d’unir et
d’harmoniser leurs efforts pour pouvoir ainsi atteindre le but défini ; plus souvent celui de pouvoir créer,
construire ou fabriquer une application et/ou un site web fonctionnel, flexible et/ou de qualité fiable.
 The fives planes
Dans le cas de développement d’un site et/ou application web, les utilisateurs s’attendent à interagir pas
seulement avec les développeurs mais aussi encore davantage avec les différentes pages ou interfaces web
qui vont être créées, et cela, comme si ces dernières formaient un tout unifié (cf. notion d’expérience
utilisateur avec Norman Donald, 1986 et 2013). En plus, avec les différentes caractéristiques qui sont
propres aux deux domaines du développement web, c.à.d. le Front-end et le Back-end, la base théorique et
la base pratique actuelle de développement web ne devraient plus être principalement limitée aux besoins
exprimés par le client ou utilisateurs, moins non plus à la notion d’exigences fonctionnelles, mais elles
devraient aussi avoir un regard sur les interactions de surface de ces utilisateurs car une expérience
utilisateur réussie implique bien plus que ce que les utilisateurs d’un site web construit peuvent voir ou
bénéficier. La combinaison plutôt de tous ces différents éléments multidisciplinaires devraient alors

23
UCD est une philosophie de conception dans laquelle les besoins, les désirs et les limitations de l’utilisateur final
se situent à toutes les étapes du processus de conception et du cycle de vie du développement. Pour Sanders
Elizabeth et Stappers Pieter Jan (2008), cette philosophie de conception inclut en son sein plusieurs autres
philosophies, telle que la philosophie de participation active des utilisateurs à un processus de conception
(Participatory Design) qui est alors une tradition chère aux scandinaves, particulièrement aux acteurs TI suédois.
C’est ce que Gulliksen Jan et Lantz Ann (2001) ont aussi décrit dans leur article intitulé : « Design versus Design -
from the Shaping of Product to the Creation of User Experiences ».

27
permettent de disposer d’une structure ou architecture de l’information de qualité et d’un contenu ou
information fiable et flexible. Ici, les développeurs web devraient même garder à l’esprit que lorsqu’ils
construisent, créent ou fabriquent un site web et/ou des nouvelles fonctionnalités pour un site web déjà
construit, c’est la convivialité qui doit être mise au devant de la scène car c’est une sorte de mesure dans
laquelle les utilisateurs finaux arrivent aujourd’hui à accepter ou peuvent se servir pour atteindre leurs
objectifs de manière efficace et satisfaisante.
Dans ces conditions, le cadre Scrum qui s’adapte actuellement mieux au développement web devrait
désormais être associé avec au moins un ou deux autres processus ou cadres existants pour y parvenir.
C’est ce que Vickoff Jean-Pierre (2017), dans l’une de ses chroniques dans le Journal du Net (Au secours
de Scrum), a aussi confirmé en disant : « aux côtés de Scrum, il est aujourd’hui nécessaire de recourir à un
framework complémentaire de développement sur la base de principes de qualité globale pour garantir la
qualité technique du code et de la production » ; une production ou productivité qui est attendue par le
product-owner et/ou par les utilisateurs finaux d’un site et/ou application web en cours de construction, de
création ou de fabrication. Ainsi, dans le lot des frameworks complémentaires qui peuvent être
recommandés pour s’associer avec le cadre Scrum, il y a le « The Five Planes ».
Le « The Five Planes », est un cadre théorique et pratique dont l’origine remonte avec un premier article
de Garrett Jesse James publié en 2000 qui répose en partie sur des nombreux principes d’interactions
humaines en rapport avec la majorité de systèmes qui existent actuellement24. Il comprend cinq phases [(1)
la stratégie (strategy plane), (2) la portée (scope plane), (3) la structure (structure plane), (4) le contenu
(skeleton plane) et (5) l’esthétique (surface plane)] et met « l’accent sur une architecture informationnelle
rigoureuse pour un site web à construire » (Garrett Jesse, 2011), mais aussi sur la collaboration et/ou la
communication entre les différentes prenantes d’un projet car « une mauvaise architecture de
l’information peut être irritant pour les internautes qui ne vont pas trouver des informations qu’ils
recherchent et vont décider d’aller visiter d’autres sites web (une perte de compétitivité pour
l’organisation) » (Morville Peter et Rosenfeld Louis, 2006, cité par Mbuta Ikoko, 2011). Il met aussi
également l’accent sur la communication entre les différentes prenantes d’un projet TI web surtout dans le
cas où l’on doit considérer la collaboration et/ou la communication comme étant « l’un des problèmes
clés à résoudre pour parvenir à une conception centrée sur les utilisateurs qui fonctionne alors bien »
(Gulliksen Jan et Lantz Ann, 2001).

Figure 9 – The Five Planes (source: Garrett Jesse, 2011).

24
Parmi ces nombreux principes, nous avons par exemple les 10 principes heuristiques de conception et d’évaluation
d’interfaces utilisateurs de Nielsen Jakob (1994), qui sont voire les plus utilisés aujourd’hui dans les domaines de
développement web [la Visibilité de l’état du système, la Correspondance du système avec le monde réel, la Liberté
de navigation et contrôle du système par l’utilisateur, la Cohérence et le respect des standards, la Prévention des
erreurs, le Reconnaître plutôt que se souvenir, la Flexibilité et efficacité de l’utilisation, l’Esthétique et design
minimaliste, la Facilitation d’identification et la gestion des erreurs, l’Aide et documentation pour l’utilisateur s’il
les souhaite], mais aussi les 8 principes de Bastien Christian et Scapin Dominique (1993, cité par Mbuta Ikoko,
2003) [le Guidage, la Charge de travail, le Contrôle explicité, l’Adaptabilité, la Gestion des erreurs, l’Homogénéité
ou cohérence, la Signifiance des codes et dénomination et la Compatibilité] et/ou les 12 principes de Benyon David
(2005, cité dans Benyon David, 2014) [la Visibilité, la Cohérence, la Familiarité, l’Affordance, la Navigation, le
Contrôle, le Retour d'information, la Récupération, les Contraintes, la flexibilité, le Style et la convivialité].

28
Concernant particulièrement les 5 phases de ce cadre théorique et pratique de Garrett, les deux premières
phases (stratégie et portée) ont trait au point de vue des développeurs sous la forme d’un processus de
mise en œuvre de stratégie et/ou de planification opérationnelle du projet, c.à.d. en termes de réalisation
d’activités liées au processus d’avant projet et de quelques-unes liées au processus de développement. Par
contre, les trois autres phases restantes (structure, contenu et esthétique) concernent la réalisation d’un
travail plus concret par rapport à un développement itératif ou incrémental dans lequel les différents
outputs devraient plutôt tenir plus compte de différents points de vue des utilisateurs ou internautes-
visiteurs de notre site en cours de construction. Parmi les activités techniques du projet intégrées de
manière naturelle à ce travail plus concret à réaliser, nous citons l’analyse, la conception,
l’implémentation, les tests et installation, la vérification et validation, la documentation et la formation.
Comme dit également précédemment, le « The Five Planes » est tout simplement un cadre théorique et
pratique proposé en 2010 par Garrett Jesse James. Il sert alors de support au processus de développement
web en rapport avec la base d’expériences profondes et positives des utilisateurs (UCD). En plus, malgré
la ressemblance proche et visible qui peut être observée entre ce cadre et le procédé prédictif en cascade
(Waterfall), il s’agit plutôt d’un cadre qui, ensemble avec quatre de ses cinq phases, repose sur une culture
de développement agile qui rassure les utilisateurs finaux par rapport au produit-logiciel qui devrait être
construit au final. C’est donc un cadre qui, en dehors d’être centrée sur les expériences profondes et
positives des utilisateurs (UCD), a alors une culture agile « semi-itérative », « adaptative » et/ou
« incrémentale » 25 (voir figure 8).
D’ailleurs, si nous l’associons à la pensée de Constantine Larry et Lockwood Lucy (1999), qui parlent
également des expériences profondes et positives des utilisateurs en évoquant la conception centrée sur les
utilisateurs (UCD), nous pouvons dire qu’il est un cadre systématique qui utilise des modèles abstraits
pour pouvoir concevoir le système le plus petit et le plus simple qui prend en charge entièrement et
directement toutes les tâches que les utilisateurs devraient accomplir. Pour Norman Donald (1986), dont la
pensée a été actualisée en 2013, les différentes expériences des utilisateurs qui s’y rattachent ici portent
plutôt sur ce que les utilisateurs ressentent lors de leurs interactions avec le produit-logiciel fabriqué ou en
cours d’amélioration. Ainsi, les pages ou interfaces web qui sont créées pour un site web quelconque
devraient suivre dans ces conditions les différentes conventions web existantes mais aussi être
fonctionnelles, esthétiques et faciles d’utilisation, c.à.d. ergonomiques, conviviales et responsives afin de
pouvoir répondre aux besoins exacts exprimés en continu par les utilisateurs, et cela, sans tracas ni soucis
ou encore sans aucune frustration.
Pour finir, disons de manière globale que les cinq phases que forment le cadre théorique et pratique de
Garrett Jesse James sont réalisées en s’appuyant les unes sur les autres en combinant les éléments du
modèle en cascade avec la philosophie itérative du prototypage, c.à.d. de manière itérative, incrémentale
ou adaptative comme déjà dit ci-dessus. Elles constituent, ensemble les différentes activités techniques
liées évoquées, les fondamentaux souhaités pour pouvoir obtenir des bénéfices nets qui sont attendus par
des utilisateurs ou internautes visiteurs d’un site et/ou d’une application web en cours de construction ou
construit et en cours d’amélioration continue. Elles façonnent donc de manière concrète l’expérience
profonde et positive des utilisateurs ; une expérience utilisateur qui, selon Garrett Jesse James (2011), est
influencée par les propriétés physiques et visuelles qu’un site et/ou une application web peut avoir.
D’ailleurs, grâce à ce cadre théorique et pratique proposé par Garrett Jesse James, les deux domaines du
web sont en trait d’expérimenter actuellement une pratique intégrée de développement logiciel qui semble
être déjà arrivée dans sa phase finale de constitution. Il s’agit d’une pratique intégrée qui n’est pas du tout
nouvelle car son voyage actuel a commencé depuis la fin de la première moitié des années 2000 grâce aux

25
Pour renforcer notre logique de raisonnement en rapport avec ce cadre, évoquons ici Vickoff Jean-Pierre (2009, cité
par Mbuta Ikoko, 2010) qui parle des bonnes et meilleures pratiques sur l’ensemble de cadres agiles. Ce dernier
insiste sur la semi-itérative ou l’incrémentale en disant qu’elle est aujourd’hui indispensable à la plupart des projets
car elle préserve en début de projet une réflexion minimum sur les contraintes du projet, l’expression globale des
exigences, les impacts organisationnels attendus et l’architecture du produit-logiciel à créér, ainsi que sur
l’estimation initiale et la planification des itérations (sprints sous Scrum).

29
écrits par exemple de Gulliksen Jan, Lantz Ann et Boivie Inger (1998), de Constantine Larry et Lockwood
Lucy (1999) et, plus tard, de Karel Vredenburg, Scott Isensee et Carol Righi (2003), dont une partie de
tout ceci puise plutôt leur inspiration de l’ouvrage mythique de Norman Donald et Draper Stephen (1986)
et de la pensée clé de Nielsen Jakob (1994) par rapport à l’interaction humaine et/ou à la convivialité dans
un système (lisibilité, facilité d’utilisation ou navigation aisée, etc.). Elle intègre donc en effet les histoires
des utilisateurs, les scénarios possibles et les modèles.
d) Les tests utilisateurs dans un projet de développement web 2.0
Lors de la création, construction ou fabrication d’un site ou d’une application web, des séries de tests
(tests unitaires, fonctionnels, d’intégration, de performance, systèmes, etc.) sont effectuées par les
parties prenantes concernées. Elles sont effectuées, ces séries de tests, comme étant l’une des activités
techniques clés en parallèle ou ensemble avec les autres activités techniques clés mais aussi avec les
activités techniques dites de vérification et de validation.
Toutefois, dans ce lot de séries des tests, les tests utilisateurs visent alors à évaluer si le produit-
logiciel ou le site web fabriqué ou en cours de fabrication répond aux critères de convivialité, c.à.d.
d’interface et de facilité d’utilisation. Ils sont souvent difficiles à réaliser par une seule personne, car
une personne ne pourra jamais trouver tous les problèmes d’utilisation dans une interface utilisateur.
C’est également une activité technique qui devrait souvent commencer avec la fabrication de
prototypes et devraient se poursuivre durant l’exécution de toutes les autres activités techniques liées
au développement. Dans la littérature, les tests utilisateurs sont souvent effectués de deux manières :
formative pour fournir une rétroaction pouvant être utilisée pour améliorer la conception et
sommative pour évaluer si les objectifs ou exigences des utilisateurs et de l’organisation ont été
atteints ou respectées. Les deux manières de procéder ont chacune leurs avantages ou importances car
plus les problèmes sont résolus rapidement, moins il est coûteux de les résoudre.
Avec la pratique actuelle de tests logiciels, ce sont des experts en tests logiciels qui s’occupent de
toutes les activités liées aux tests mais aussi celles de vérification et validation des logiciels. Malgré
cela, ils arrivent parfois qu’ils trouvent des problèmes qui ne préoccupent presque pas les utilisateurs
du produit-logiciel ou du site web fabriqué ou en cours de fabrication. Pour Ivinza Lepapa (2001, cité
par Mbuta Ikoko, 2003), les 10 principes heuristiques de conception d’interfaces utilisateurs proposés
par Nielsen Jakob en 1994 devraient dans ce cas être pris en compte comme critères d’utilisabilité des
logiciels pour cette série des tests, c.à.d. pour les tests utilisateurs du produit-logiciel à construire ou à
mettre en œuvre au sein d’une organisation. Cette recommandation a été aussi faite par Benyon David
(2014) qui parle pour son compte de 12 principes heuristiques repartis en trois catégories
(learnability, effectiveness and accommodation). Pour lui, les tests sur les critères d’utilisabilité liés
aux différents principes heuristiques de Nielsen Jacob sont importants et devraient même être testés
par les utilisateurs concernées car « rien ne peut remplacer l’implication de personnes réelles dans
l’évaluation d’un logiciel en cours de fabrication » (Benyon David, 2014).
Les critères heuristiques d’utilisabilité sont voire connus aujourd’hui dans la littérature agile sous le
nom de critères INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable). Il
s’agit d’un nom qui a été proposé en 2003 par Walk Bill pour juger la qualité claire d’une ou des
users stories ; des users stories qui expriment de manière correcte les différents besoins exprimés pour
un produit-logiciel, et cela, d’un point de vue utilisateur et qui, si elles sont encore bien formulées,
tentent aussi de répondre à des critères heuristiques d’utilisabilité qui sont définis au niveau d’un
« Product backlog » dans un projet Scrum. Désormais, dans les différentes activités d’un projet TI ou
de développement web, qui sont même définies aujourd’hui par les différentes parties prenantes,
particulièrement les activités techniques clés d’analyse, de conception et de tests mais aussi celles de
vérification et validation, il est donc important d’inclure les utilisateurs qui sont alors à la base des
users stories dès son début pour pouvoir enfin obtenir une image réelle des problèmes de convivialité
qui pourront exister sur un produit-logiciel ou un site web en cours de fabrication.

30
 Chapitre 2
Méthodes et outils utilisés

Nous présentons dans ce deuxième chapitre les méthodes, les outils et/ou les technologies adoptées,
choisies et utilisées pour construire l’annuaire en ligne demandé, et cela, à travers la présentation d’un
processus ou procédé de développement logiciel théorique et pratique qui se veut intégré ou unifié.
2.1 Présentation de l’annuaire en ligne à construire pour « les anciens étudiants
diplômés MIAGE d’Amiens »
2.1.1 Rappel sur la définition d’un annuaire en ligne
Pour rappel, un annuaire en ligne, au modèle d’un carnet d’adresse ou répertoire téléphonique que nous
manipulons presqu’actuelleement tous les jours sur nos smartphones, est tout simplement une base de
données relationnelle ou objet organisée et optimisée hiérarchiquement pour lecture. Elle est consultable à
travers un support donné qui permet de manière pratique à l’usager de rechercher ou de retrouver
facilement des ressources informationnelles définies. Pour Rizcallah Marcel (2000), un annuaire en ligne
n’est pas qu’une base de données permettant de rechercher ou de retrouver facilement des ressources
informationnelles définies. Il offre aussi d’autres services associés à un réseau local ou étendu
d’entreprise, tels que les services liés à un site web informationnel ou institutionnel, au business
intelligence26, etc.
En ces termes, un annuaire en ligne serait donc d’autant plus utile qu’il doit être simple à utiliser, surtout
lorsqu’on recherche une ressource informationnelle importante ou bien précise. Et, comme il vient d’être
évoqué ci-dessus, nous pouvons alors avoir plusieurs types d’annuaires (annuaire papier ou carnet
d’adresse et autres annuaires classiques connus mais non repris ici : pages jaunes, pages blanches, MS
Active Directory, etc.). Toutefois, « leur point commun est qu’ils sont tous destinés à faciliter la
localisation d’une personne ou d’une entreprise à partir de différents critères comme le nom, le code
postal, voire la fonction pour les personnes ou encore le type de service rendu pour les entreprises »
(Rizcallah Marcel, 2000).
Un annuaire en ligne, en dehors d’être associé à un réseau local ou étendu d’une entreprise, le cas d’un
Intranet, Extranet ou Internet par exemple, a aussi également la même vocation que les différents
annuaires cités ci-dessus. Il pourra alors être défini globalement comme étant un site et/ou une application
web représentant virtuellement une communauté des personnes poursuivant un but et qui sont devenus
membres après une inscription volontaire ou une cooptation. Avec cette définition globale, il devra ainsi
reprendre par exemple des informations ou des profils de ces personnes, et cela, dans le but de leur offrir
une identité virtuelle, mais aussi de leur permettre de rester en contact digitalement (parce que partageant
les mêmes objectifs) et, pourquoi pas, de créer des opportunités d’affaires entre elles. C’est donc une
communauté sociale qui est réelle et qui décide par la suite de se faire prolonger de manière virtuelle ou
vice-versa. Assimilé ici à une sorte de réseautage social, c’est voire dans ce cadre que Cardon Dominque
(2011, cité dans Wikipédia, 2019) parle de l’usage social d’une technologie existante par les hommes,
s’expliquant en grande partie par la sociabilité humaine, c.à.d. par leur capacité ou celle de leur
communauté à évoluer en société et à pénétrer au sein de nouveaux réseaux sociaux.

26
Le Business Intelligence, BI en sigle, est tout simplement une informatique dite décisionnelle (DSS : Décision
Support System) qui est à l’usage des décideurs ou acteurs dirigeants d’entreprises. Selon l’encyclopédie en ligne
Wikipédia, « il désigne les moyens, les outils et les méthodes qui permettent de collecter, consolider, modéliser et
restituer les données, matérielles ou immatérielles, d'une entreprise en vue d'offrir une aide à la décision et de
permettre à un décideur d’avoir une vue d’ensemble de l’activité traitée ».

31
Concluons en disant en plus qu’un annuaire en ligne, à la différence d’un annuaire papier, est dynamique,
flexible, sécurisé et personnalisable (Rizcallah Marcel, 2000). Il sert à localiser n’importe quoi c.à.d.
n’importe quel contenu informationnel stocké ou hébergé. Pour cela, il offre aussi également en général un
espace de noms compréhensibles par des utilisateurs qui, d’un point sécuritaire, peuvent avoir des rôles et
des profils différents. Consultable sur Internet par tous, il est aussi en plus sollicité beaucoup plus en
lecture qu’en écriture et ne peut gérer des transactions complexes.
2.1.2 Description de l’annuaire en ligne des anciens étudiants diplômés MIAGE d’Amiens
En tant d’abord une communauté sociale qui se veut réelle, l’annuaire en ligne des anciens étudiants
diplômés MIAGE d’Amiens qui devrait être construit ici est la matérialisation d’une série des besoins
exprimés par la communauté ou le réseau MIAGE d’Amiens qui est actuellement éparpillée à travers le
monde. Il s’agit d’une communauté qui fait partie de la fédération nationale des étudiants et diplômés de
MIAGE, connue sous le nom de « MIAGE connection ». Cette fédération nationale est tout simplement
« une association loi de 1901 regroupant les bureaux des étudiants, les Juniors Entreprises, les associations
d’anciens et les élus de différents conseil, au niveau national » (Wikipédia, 2019). Cette fédération
nationale a pour principaux objectifs :
- de participer à la promotion du diplôme MIAGE ;
- de représenter les étudiants et défendre leurs intérêts au niveau national ;
- de créer un réseau solide et durable entre étudiants et autres acteurs de la MIAGE ; et
- d’aider et participer au développement des associations membres ;
En ce terme, l’annuaire en ligne que nous allons construire ici serait plutôt pour des anciens étudiants
diplômés MIAGE d’Amiens. Il devrait alors être un site ou une application web qui devrait permettre à
tout ancien étudiant diplômé MIAGE d’Amiens de faire partie d’un réseau social formel et fiable, mais
aussi de continuer de garder des liens solides entre eux et avec leur alma mater, l’UPJV, particulièrement
avec leur unité de formation et de recherche, à savoir l’UFR des Sciences ou le Département informatique
d’Amiens. Pour y figurer, tout ancien étudiant diplômé MIAGE d’Amiens devrait être membre ou
s’inscrire comme membre du réseau d’anciens étudiants et diplômés MIAGE d'Amiens ; un réseau social
et professionnel totalement gratuit pour nous tous.
C’est donc un annauire qui va alors reprendre leurs différents profils académiques et professionnels, en
plus de leur permettre de rester digitalement en contact permanant entre eux et avec leur alma mater.
D’ailleurs, suivant les besoins exprimés sous-forme d’exigences textuelles par notre client (représenté ici
par le tuteur du module D605), l’annuaire en ligne des anciens diplômés MIAGE d’Amiens, devrait donc
être à mesure de :
- gérer les différentes promotions et données propres à chaque ancien étudiant diplômé MIAGE
d’Amiens (poste actuel, salaire... (étude préalable à réaliser sur la détention de données
personnelles : CNIL) ;
- offrir un service de Newsletter aux différents membres inscrits ;
- proposer des offres d’emploi ou des liens sur les emplois disponibles dans les organisations
partenaires ou dans celles où les anciens étudiants MIAGE de l’UPJV travaillent et/ou
dirigent ou occupent des postes stratégiques ;
- mettre à la disposition des organisations partenaires, agences de recrutement, etc. un
Cvthèque et des liens sur les profils Linkedin, Facebook et Twitter d’anciens étudiants
diplômés MIAGE de l’UPJV inscrits, mais aussi sur le fil d’actualité RSS (en remplacement de
News-letters) en rapport avec l’annuaire en ligne et le réseau des anciens ;
Les besoins exprimés ici par notre client, après leur compréhension et l’assurance de leur coherence par
rapport à l’ensemble de l’annuaire en ligne à construire, ont été réformulés à un gabarit d’exigences
(fonctionnelles ou non fonctionnelles, c.à.d. de convivialité, de performance, de fiabilité, de maintenabilité

32
et d’évolutivité) (voir Plan de développement de l’annuaire en ligne ou PDL – Plan de Développement
Logiciel en annexe). Toutes ces exigences ont fait l’objet d’un raffinage objectif et clair pour pouvoir
éliminer les quelques ambiguïtés, incohérences, redondances et incomplétudes qui semblent exister au
niveau de besoins exprimés par notre client. Dans l’ensemble, il n’y a en pas eu beaucoup.
En résumé, tel que nous avons conclut dans notre PDL, notre annuaire devrait donc être un annuaire en
ligne qui va miser sur le responsive et sur l’interactivité des utilisateurs. Il devrait aussi offrir à son
administrateur un module BI ou statistique et une fonction CRUD (Create, Read, Update and Delete) pour
gérer les différentes informations qui seront stockées et gérées par un SGBD relationnel. Une fonction de
recherche et/ou de filtrage des différentes informations de profil renseignées et rendues disponibles sur
chaque ancien étudiant diplômé MIAGE de l’UPJV inscrit dans l’annuaire devrait aussi en plus être
implémentée. Quant aux différentes informations recherchées et/ou filtrées sur ce profil renseigné et celles
qui s’afficheront sur toutes les pages ou interfaces web à créer, elles pourront également être téléchargées
ou imprimées par n’importe quel utilisateur ou internaute-visiteur de cet annuaire en ligne à construire.
2.1.3 Procédé, environnement intégré, langages et autres technologies associées adoptés pour
le développement de l’annuaire en ligne
Face aux grandes lignes présentées dans le précédent point, représentant les principaux besoins exprimés
par le client, la méthode adoptée ici pour construire, créer ou fabriquer l’annuaire en ligne démandé, c.à.d.
un annuaire dynamique, flexible, sécurisé, personnalisable et/ou convivial, est tout simplement un procédé
théorique et/ou une pratique de développement logiciel dit intégré. Ci-dessous, nous présentons les lignes
clés de ce procédé théorique et pratique intégré mais aussi l’environnement et les outils techniques choisis
pour réussir correctement la construction de cet annuaire en ligne.
a) Procédé de développement adopté
Pour Gulliksen Jan, Lantz Ann et Boivie Inger (1998), le procédé de développement logiciel à adopter
dans le cadre de développement web devrait être une pratique qui préconise des techniques et des
démarches de conception logicielle de type « qualité globale de production », c.à.d. des techniques et des
démarches qui sont dépendantes du type de produit-logiciel ou site web à fabriquer.
Dans le cas de notre projet thématique, le procédé de développement logiciel adopté est un procédé
théorique et pratique qui se veut intégré et/ou unifié. Il renferme les grandes lignes du cadre Scrum et du
cadre théorique et pratique de Garrett Jesse James, par sa focalisation sur les besoins et la satisfaction des
utilisateurs. En ce terme, il est alors itératif et/ou incrémental et présente donc un intérêt pour la
convivialité. C’est un procédé qui va insister ici « sur l’importance des informations à publier et sur une
conception de qualité fiable et flexible, à partir des expériences profondes et positives des utilisateurs »
(Garrett Jesse James, 2011). Il va aussi s’appuyer sur le modèle classique de succès des SI de DeLone et
McLean de 1992 ou celui révisé en 2003 qui aide en partie la logique de quatres portes de Sundström
(2005) que nous avons évoqués au chapitre 2. En rappel, le modèle de succès des SI de DeLone et
McLean a toujours été considéré comme l’un des modèles d’acceptation, d’utilisation et/ou
d’appropriation de référence qui « permet à tout système d’information implémenté d’obtenir l’effet et les
résultats souhaités par ses utilisateurs de la meilleure façon possible » (Petter Stacie, Delone William et
McLean Ephraim, 2008). A propos, des entretiens qualitatifs et quantitatifs vont être réalisés ou menés
lors de l’application de ce procédé adopté, et cela, auprès d’un échantillon cible des utilisateurs ou auprès
des parties prenantes concernées de notre projet. Ces entretiens devraient permettre à l’équipe de
développement (Development Team) de collecter et d’analyser de facon claire les principaux besoins
exprimés par les utilisateurs ou par leurs représentants (le Product owner dans le cas du cadre Scrum),
mais aussi des besoins complémentaires.
Basées sur l’agilité et sur les expériences profondes et positives des utilisateurs (UCD), le procédé de
développement logiciel adopté va également définir en plus des itérations et/ou des incréments qui ne
devront durer qu’entre une ou deux semaines au maximum (en nombre d’heures de travail, voir le PDL en
annexe). Le but de ces itérations et/ou incréments à définir serait de produire en définitif un annuaire en
ligne fonctionnel et de bonne qualité. Lors de l’exécution de chaque itération et/ou incrément, c.à.d. du

33
sprint défini, des prototypes seront fabriqués par le Development Team, soit manuellement avec des
papiers fonctionnels27 ou sur un logiciel de conception graphique ou de retouche d’images matricielles
ayant des papiers fonctionnels. Les prototypes fabriqués seraient ensuite présentés aux autres parties
prenantes concernées, c.à.d. au client (Product owner) ou aux utilisateurs impliqués, sur la base duquel ils
pourront alors porter leurs amendements sur des failles trouvées ou exprimer des nouveaux besoins ou
encore formuler des nouvelles exigences avant de démarrer le codage dans un langage de programmation
web (une sorte de première évaluation qui sera continue par des séries d’autres tests utilisateurs, la
vérification et la validation finale).
Le procédé de développement théorique et pratique intégré adopté devrait aussi également passer, comme
évoqué partiellement au point 2.3 du chapitre 2, pour une combinaison de forces et de compétences des
différentes parties prenantes du projet. En ces termes, il va permettre aux différentes parties prenantes du
projet, via une collaboration étroite ou une bonne communication, de réussir la construction, création ou
fabrication de notre annuaire en ligne qui doit être convivial, responsive et disposer d’un contenu
pertinent, digeste, intéressant et mémorable pour n’importe quel utilisateur ou internaute-visiteur. En
somme, avec son penchant vers l’agilité, c.à.d. vers le cadre Scrum, les différentes parties prenantes
impliquées au projet devraient donc être à mesure de visualiser et définir ensemble les différentes
prévisions (charges, délais, …) ; de re-planifier ensemble le calendrier suivant les variables ou feedbacks
retenus et de suivre ensemble l’avancement de tous ces élements repris dans le temps et dans l’espace ;
mais aussi de comprendre tout ce qu’ils auront à faire, quand le faire et comment le faire. D’ailleurs, le
plan de développement logiciel (PDL), rédigé avant le démarage de ce projet et qui se trouve en annexe
de ce présent rapport, présente déjà cette portée du projet mais aussi la stratégie pour sa réalisation ou
exécution.
Notons en plus que malgré la portée et la stratégie connues du projet, qui vont être redéfinies à partir de la
collecte et de l’analyse des principaux besoins exprimés par le client, d’autres entretiens qualificatifs mais
aussi des communications quotidiennes devraient avoir lieu avec le client et/ou les utilisateurs du futur
annuaire en ligne, puis avec le Scrum master tout au long de l’exécution du projet (Daily Scrum ou stand
up). Ces autres entretiens qualificatifs et ces communications quotidiennes devraient dans la pratique
devoir améliorer davantage les différents modèles d’exigences, d’analyse, de tests, extra fonctionnel et de
conception qui vont être produits, mais aussi le codage à réaliser par le Development Team. Quant au
modèle d’exigences produit, avec un oeil critique du Scrum master, il devra renfermer des exigences
raffinées et tracables par leurs métaphores pour servir réellement comme des critères lors du codage mais
aussi lors des séries de tests et évaluations de l’annuaire en cours de construction, création ou fabrication
(cf. modèle de test, lire Jézéquel Jean-Marc et al, 2006, cité par Mbuta Ikoko, 2011). Avant l’étape du
codage, les modèles d’exigences et d’analyse produits devraient pouvoir être associés avec un autre
modèle, appelé « modèle extra fonctionnel », représenté dans notre procédé de développement logiciel
adopté sous forme des users stories ayant pour formule mythique : « En tant que <utilisateur>, je souhaite
<faire quelque chose> afin de <atteindre un objectif> ». Profitons pour rappeler ici que les users stories,
qui ne sont que les reflets de différentes exigences raffinées et tracables, seront donc considérées comme
des lignes faisant partie de notre cahier des charges ou PDL révisé de manière continue pour ce projet.
En rapport avec les grandes lignes reprises ci-dessus, pour le codage et/ou la programmation informatique
de l’annuaire en ligne, nous vous présenter dans le point qui suit, sous forme d’un tableau synthèse,
l’environnement de développement intégré choisi et les autres outils et technologies associés à utiliser.

27
Les papiers fonctionnels, de l’anglais « Wireframes », sont un outil qui est utilisé dans la conception web pour
présenter la disposition structurelle d’un site. Il permet au web développeur, ensemble avec le client, de créer ou de
déssiner une représentation simple de tous les composants ou contenus qui doivent se retrouver sur une page web,
mais aussi la manière dont tous ces composants ou contenus vont être reliés avec ceux des autres pages web du site
web. Ici, il est donc possible de spécifier également certaines fonctions devant figurer sur les différentes parties de la
page web (lire Garret Jesse, 2011). L’avantage de cet outil, lors de cette étape d’analyse et de conception de notre
annuaire en ligne, ce qu’il réunit trois éléments importants qui sont : la conception de l’interface, le fonctionnement
de la navigation et la conception de l’information.

34
 b) Environnement intégré et autres outils et technologies de développement associés choisis
Système d’exploitation Microsoft Windows 10 Enterprise

IDE Microsoft Visual Studio Enterprise 2019

Framework de l’IDE Microsoft .Net 4.7

Pattern de l’IDE et du CMS Microsoft ASP.NET MVC 5

CMS ou WCMS EpiServer 11.3.4

SGBD MS SQL Server 2012 ou MS SQL Server 2016 Express

LocalDb (avec SQL Server Management Studio et
SqlLocalDb.MSI)

Utilitaire de capture d’écran ScreenHunter 7 free

Navigateur d’inspection et de visualisation Chrome 74, Microsoft Edge, Internet Explorer 11 et Firefox

Utilitaire de validation automatique Total validator Basic 11.7.0

d’accessibilité WCAG

Langage de balisage HTML 5.2

Langage de style CSS 2.1 et 3 avec le préprocesseur Less

Langage de script et autres Javascript (Jquery 3.3.1),

Autres frameworks et bibliothèques Bootstrap 3.4.0 et Font-awesone 4.7.0 (en liens sur une page
logicielles HTML et non en téléchargement et installation sur un
répertoire local)

Gestion de versions Git sur le TFS (Team Foundation Server)28 avec MS Azure
SDK.

Tableau 1 – Différentes outils et technologies choisis ou adpotés pour notre projet.

Ici, l’IDE choisi, le MS Visual Studio, et les différentes autres technologies qui vont l’accompagner vont
donc nous aider à coder et à afficher selon les souhaits du client ou des futurs utilisateurs les différentes
pages ou interfaces web qui vont être définies et créées ensemble.
Pour le choix fait par rapport au CMS ou WCMS qui va être utilisé pour mettre sur pied notre annuaire en
ligne, nous disons seulement que plusieurs critères de choix existent à ce jour (facilité d’utilisation et
d’appropriation, personnalisation éditoriale et/ou du back-office, gestion de version, coût, base de données
et gestion d’export, aperçu, budget, flux de travail ou capacité à monter en charge, multiliinguisme, droits
d’accès, etc.). Ces différents critères ont été hiérarchisés ou priorisés par nous avec l’aide de la méthode
MoSCoW29, d’un point de vue développeur et d’un point de vue éditeur ou créateur de contenu travaillant

28
Le TFS est une plate-forme Microsoft de stockage et de gestion des versions de code source qui prend en charge
les procédés de développement prédictifs et agiles. Il peut être utilisé localement ou dans le cloud (Microsoft Azure)
et fournit à ce jour les outils nécessaires pour rationaliser l’ensembl
3e du processus de développement (planification, génération de rapports, documentation wiki, trasncription et
gestion des exigences scénarisées, tests, etc.).
29
MoSCoW est une méthode ou technique de priorisation proposée par Dai Clegg. Elle est utilisée dans des projets
agiles pilotés avec des procédés tels que le RAD, le XP, le Scrum ou le Kanban, etc. pour permettre de hiérarchiser

35
sur un CMS pour s’assurer que notre choix est donc correct. D’ailleurs, ayant une expérience modeste sur
WordPress et EpiServer, nous avons donc identifié nos critères par priorité sur ces deux CMS et nous
pensons qu’ils ont été correctement pondéré en fonction de la nature du notre projet même si d’autres
approches pourront montrer que certains critères non priorisés peuvent être plus importants que d’autres.
Le choix qui est fait par nous pour ce projet est donc celui du CMS EpiServer (voir tableau 1).
Dans le point va suivre, nous présentons quelques considérations fonctionnelles et techniques de ce CMS
choisi où le lecteur pourrait alors comprendre davantage le pourquoi de notre choix dans le cadre de ce
projet.
2.1.4 Considérations fonctionnelles et techniques du WCMS choisi : le « EpiServer CMS ».
a) Présentation sommaire de EpiServer
L’Episerver CMS est présenté dans le marché des TI comme étant un système de gestion de contenu pour
le web (WCMS en anglais). Il est développé depuis 1997 par la société suédoise EPiServer AB et utilise la
plateforme serveur IIS (Internet Information Services) et la technologie .NET (ASP .NET) de Microsoft
depuis 2002 pour sa mise en œuvre. Le Episerver CMS figure aussi aujourd’hui dans la catégorie de
WCMS leader mondial et le plus utilisé par des grandes organisations qui utilisent les technologies
Microsoft ou qui sont soucieuses de la sécurité de leur contenu. Plus de 30 000 grandes organisations ou
entreprises sont comptées dans 30 pays à travers le monde comme étant les utilisateurs du CMS EpiServer
(https://www.episerver.com/solutions/our-customers/by-industry/). Ces denières l’utilisent pour pouvoir
créer, diffuser et optimiser leurs expériences web, mais aussi pour pouvoir gérer et sécuriser leur contenu
diffusé séparément du code source.
L’EpiServer CMS peut aussi être considéré comme le concurrent direct des CMS leaders mondiaux les
plus connus de tous les communs de mortels, à l’instar de Drupal, de WordPress et de Joomla. Ensemble,
ils permettent ainsi à toutes les organisations ou entreprises les utilisant de faire évoluer leur site et/ou
contenu web sans avoir à recourir systématiquement à un Web développeur.

Figure 10 - Vue d’ensemble du système et du site Web ou solution personnalisé.

Hormis le fait qu’il aide particulièrement les grandes organisations, mais aussi naturellement les
différentes PME et les individus à faire évoluer leur site et/ou contenu informationnel web puis à
optimiser leurs expériences web sans avoir à recourir systématiquement à un Web développeur (facilité
d’utilisation), le CMS Episerver et son Framework API REST EpiServer prennent aussi également en
charge la gestion de version, l’aperçu, le flux de travail, les droits d’accès, etc.
Au dessus de ce Framework et/ou API, comme repris sur la figure ci-dessus, il y a également la possibilité
pour un Web développeur de pouvoir personnaliser ce CMS offert. Cette personnalisation est possible
grâce aux différentes fonctionnalités ou modules complémentaires (Add-ons) offerts. Ici, l’aide des
acteurs métiers de différentes formes d’organisations évoquées ci-dessus sont donc capitales en rapport
avec la définition ou l’élaboration des spécificités métiers. En plus, comme repris sur la figure ci-dessus,
cette personnalisation est divisée en 5 groupes [Contenu, Droits d’accès, intégration à d’autres systèmes

les différents critères et/ou fonctions définis, mais aussi pour hiérarchiser le contenu d’un backlog et des user stories.
MoSCoW signifie: « (M)ust have », « (S)hould have », « (C)ould have » et « (W)ill not have this time ».

36
(Sharepoint, etc.), les fonctionnalités du web site ou de la solution à personnaliser et le design web]. Parmi
les différentes fonctionnalités ou modules complémentaires (Add-ons) qui peuvent accompagner cette
personnalisation, nous citons par exemple :
- sa fonction intégrée pour les tests A/B automatiques, la génération de leads et la collaboration
de projets ;
- son intelligence artificielle qui rend également un site web plus intelligent au fil du temps ;
- son moteur de recherche intrégré free (Search), ou en abonnement (Find Episerver), donnant
aux internautes visiteurs un meilleur outil pour trouver tout ce qu’ils cherchent et aux
administrateurs de groupes des utilisateurs la possibilité d’influencer et d’améliorer la liste
des résultats de recherche ;
- la capture et l’analyse de données intégrées ;
- sa palette d’offres qui permet d’optimiser rapidement des campagnes et des mots clés (SEO),
mais aussi de faire facilement des analyses d’audience sur ces derniers avec des outils tels que
le Google Analytics, Google AdWords Google Tag Manager30, etc ;
- ROI plus élevé, conversions plus rapides et avance améliorée ;
- Son interface WYSIWYG intituitive et fonctionnelle pour les rédacteurs ou éditeurs web et qui
inclue l’éditeur TinyMCE ;
- sa facilité d’intégration ou extension à des systèmes externes, simplement avec l’aide d’un API
de service qui est développée aussi par la même firme. Cette API est basée sur le style
architectural REST et aide tout utilisateur configuré à connecter plus rapidement aux
différents services offerts et systèmes externes ;
- du cryptage globale de son contenu et de la gestion des utilisateurs qui le rendent encore très
sûr comme CMS à utiliser dans l’environnement Web, et cela, malgre des failles sécuritaires
mineures ;
En effet, le EpiServer CMS est aimé et utilisé par une grande majorité de créateurs de contenu web car il
leur permet donc de créer un contenu professionnel bien structuré, de lister le contrôle d’accès flexibles
pour l’application d'autorisations au contenu, de localiser le contenu dans plusieurs langues, mais aussi de
contrôler le flux de travail de publication et plusieurs versions et de gérer le contenu sans utiliser de code.
En plus, le style architectural REST pour le web service de EpiServer est intégré au niveau de son
architecture globale à 4 couches (cf. figure 13) qui associe à son tour les trois architectures connues pour
presque tous les CMS phares disponsibles sur le marché des TIC (architecture couplée, architecture
découplé et architecture sans tête), et qui a pour origine le modèle architectural classique, appelé « 3
tiers ». Pour rappel, un modèle architectural « 3 tiers » est un modèle logique d’architecture applicative
qui vise à séparer très nettement trois couches logicielles au sein d’une même application ou système à
modéliser ou présenter cette application comme un empilement de la présentation des données (couche
présentation), de traitement métier des données (couche métier ou application) et d’accès aux données
persistantes (couche accès aux données ou persistance).

30
Selon l’encyclopédie en ligne Wikipedia, le Google Tag Manager (GTM) est un outil gratuit de gestion de balises
qui permet de n'inclure qu'un seul script JavaScript sur son site et de gérer l'intégralité de la configuration sur le back
office de l’outil. Ainsi, un utilisateur pourra, par exemple, facilement inclure Google Analytics sur l'ensemble de ses
pages, un script de conversion Google AdWords sur un page de remerciement après l'achat et, par exemple, un
deuxième script de mesure d'audience.

37
 Figure 11 - L’architecture d’EpiServer (source ffh : https://www.episerver.com/learn/tech/technical-
resources/architecture/)
b) Installation, configuration et déploiement du CMS Episerver
Le CMS EpiServer s’installe facilement sur l’IDE MS Visual Studio. Une connaissance de cet
environnement de développement Microsoft, mais aussi celle du langage C# et du Framework .Net sont
donc requises.
Un guide complet pour les développeurs EpiServer CMS certifiés ou pas peut être téléchargé ou lu en
ligne sur l’url suivant : https://world.episerver.com/documentation/developer-guides/CMS/getting-started/.
Il y a également un guide pour les utilisateurs-administrateurs ou utilisateurs-rédacteurs (createurs ou
éditeurs du contenu web).

Figure 12 – Environnement de développement versus environnement de production pour EpiServer CMS

Comme dit précédemment, les points forts d’EpiServer CMS résident dans sa personnalisation mais aussi
dans son architecture intégrée actuellement. Pour ce faire, il y a même un module EpiServer servant
d’extension au MS Visual Studio de Microsoft, le « Episerver CMS Visual Studio Extension ». Cette
dernière donne alors la possibilité au Web développeur de créer un projet ou des éléments d’un projet ou
d’une solution EpiServer, et cela, avec les trois principaux modèles d’architecture de programmation
EpiServer disponibles ou fournis, à savoir le Alloy (MVC), le Alloy (WebForms) et le Empty. Avec le
choix du modèle Alloy (MVC) ou du modèle Alloy (WebForms), un site web démo EpiServer est donc
créé, « Alloy AB », dont le code est même maintenant en open source sur le GitHub de Microsoft :
https://github.com/episerver/alloy-mvc-template/. Lors de choix d’un modèle donné pour pouvoir créer un
projet EpiServer, l’on doit tâcher de ne pas omettre de cocher soit le module EpiServer Search (moteur de
rechreche intégrée au système de gestion de contenu Episerver mais non prise en charge par le service

38
DXC31) soit le module EpiServer Find (moteur avec des fonctionnalités de recherche avancées mais qui
nécessite une licence supplémentaire. Il inclut voire les packages de service DXC).
Actuellemnt, le déploiement en production d’un projet ou d’une solution EpiServer créée se fait soit sur
site ou dans le cloud (avec le MS Azure). Pour la gestion du contenu web à créer par un rédacteur web, il
utilise le MS SQL Server pour son stockage et sa gestion variée.

Figure 13 – Environnement de développement versus environnement de production pour EpiServer CMS

Donc, le minimum réquis pour l’installation de la version par exemple 11 ou supérieure d’Episerver en
environnement de développement est de pouvoir disposer d’une machine avec le MS Windows (10, Server
2012 ou supérieur), le MS Visual Studio (à partir de 2015) et le MS .NET Framework (à partir de 6.6.1)
installés. La machine dédiée au développement devrait aussi avoir le MS IIS (à partir de 8.0), le MS SQL
Server (à partir de 2012) et un navigateur web moderne (MS IE, Mozilla Firefox ou Google, Safari for
Windows, etc.). Une fois le MS Visual Studio et l’extension Episerver CMS Visual Studio installés mais
aussi configurés correctement, l’on peut choisir une solution vide ou démo (à personnaliser) pour démarrer
le développement ou l’intégration. Il n’y a rien de compliquer à cela car la logique reste identique aux
applications ASP .Net, surtout pour les packages et cela, par l’utilisation de l’option « Add-Ons » ou
NuGet offert ou disponible sur le MS Visual Studio. C’est une personnalisation identitique à une
exception ce que le choix est fait ici à partir de « Episerver CMS Visual Studio Extension » installé et qui
donne la possibilité aux utilisateurs spécifies (administrateurs ou web développeurs) de créer un Block
Controller (MVC), un Block Razor View (MVC), un Block Template, un Block Type, un Block View, un
Custom Property, une Page Controller (MVC), une Page Razor View (MVC), une Page Template, une
Page Type et un Media Type. L’extension aide également à créer un module d’Initialization (avec ou sans
HTTP events), un Scheduled job, un User Control ou un Visitor Group Criterion.

31
L’Episerver Digital Experience Cloud service (service DXC) est l’offre en nuage d’Episerver basée sur la
technologie en nuage de Microsoft (https://world.episerver.com/digital-experience-cloud-service/).

39
 Figure 14 – Environnement de développement MS Visual Studio avec les options « Add » possibles grâce à
l’Episerver CMS Visual Studio Extension installé

Avec l’installation de l’extension EpiServer, le style architectural REST API unifié d’EpiServer (couplé,
découplé et sans tête) est également créé, installé et/ou configure. C’est un style qui offre le niveau
d’abstraction le plus élevé pour toute solution web EpiServer qui peut être construite, créée ou fabriquée.
En plus, à part installer et configurer EpiServer et les modules ou fonctions complémentaires, il est aussi
également possible de modifier certaines modules ou fonctions existant dans un projet ou solution web ou
simplement de créer ses propres modules et fonctions, puis pourquoi pas les proposer par la suite comme
un package aux autres [cf. Epi Nuget (https://nuget.episerver.com/) ou Microsoft – Nuget gallery
(https://www.nuget.org/profiles/Microsoft)], c.à.d. à la grande communauté Episerver qui compte
aujourd’hui plusieurs milliers de développeurs et partenaires (près de 40 000 développeurs impliqués et
1000 partenaires, lire sur le site de Episerver). Le même site de EPiServer indique aussi que l’équipe de
services gérés de EPiServer peut également aider ses clients ou ses partenaires certifiés (développeurs
et/ou intégrateurs) à planifier le déploiement afin d’assurer pleinement la performance et la robustesse du
produit. C’est une équipe qui est proactive pour tout changement à apporter à la plate-forme de livraison et
tient compte de l’évolution du trafic. Des services de sécurité intégrés sont également disponibles ainsi
qu’une assistance de 24h /24. Toutefois, une des faiblesses qui est même souvent présentées par les
détracteurs du CMS EpiServer ce que son service clients ou marketing ne semble pas spécifier clairement
le prix du produit, mais souhaite à la place négocier puis donner une proposition de prix à l’achecteur
potentiel manifesté.

c) Utilisation et contenu informationnelle multimédia géré par Episerver CMS

L’EpiServer CMS gère de nombreux types de contenu. La forme la plus simple est le texte brut. Ce
dernier peut se faire accompagner des images, vidéos, sons et autres liens multimédias gérés en interne du
CMS ou avec l’aide par exemple d’un système de gestion d’images, à l’instar de « ImageVault ». Selon la
documentation officielle, ImageVault défini comme un système de gestion des actifs multimédias
indépendant de la plate-forme utilisée. Il offre tout le nécessaire pour stocker, rechercher et utiliser en
toute sécurité des médias numériques utilisés par un créateur de contenus. Il peut devenir donc le hub de
tous les les médias numériques utilisés dans le CMS EpiServer si l’administrateur ou les rédacteurs web
EpiServer décident à ce qu’il soit connecté au CMS EpiServer. Concernant donc le contenu à gérer et/ou à

40
utiliser par le CMS EpiServer, quelle que soit la manière dont il est livré, ce denier dépend plus des
fonctionnalités éditoriales et administratives qui sont parmi les problèmes d’expériences complexes
qu’Episerver a résolu et amélioré depuis sa création. Aujourd’hui, les rédacteurs web ont voire la liberté
de spécifier les facteurs d’intégration évoqués déjà en partie et d’avoir une idée précise de la manière dont
ils pourraient affecter la présentation ou la prévisualisation de leur contenu, c.à.d. une présentation ou une
prévisualisation du contenu qui peut être soit en mode WYSIWYG, ce que Episerver appelle « édition sur
page », ou en mode HTML.
L’EpiServer CMS est donc un CMS intuitif et facile à utiliser. Il repose en grande partie sur une
arborescence permettant aux utilisateurs enregistrés et configurés de gérer le contenu, les médias et les
pages. Il est similaire au système de dossiers du système d'exploitation Windows. Cette arborescence est
utilisée à la fois pour gérer les pages de contenu et leur navigation dans le CMS, mais également pour
créer et suivre la structure des URL sur la page. Pour éditer le contenu et la structure des pages, les
utilisateurs éditeurs, c.à.d. les rédacteurs web peuvent également utiliser des blocs et/ou d’autres
ressources développés par les utilisateurs développeurs. Dans le EpiServer CMS, les blocs « sont
essentiellement de composants réutilisables créés pour présenter du contenu ».
De manière générale, les utilisateurs qui interagissent avec le EpiServer CMS mais aussi avec l’ensemble
de son contenu sont les utilisateurs visiteurs (utilisateur anonyme ou enregistré avec accès à la vue de
manière directe), administrateurs (utilisateur enregistré avec accès à la vue Admin pour contrôler par
exemple les droits d’accès des utilisateurs, les paramètres du système et du site, les langues, les onglets,
les catégories) et développeurs (qui définit les types de contenu et les modèles, intègre les systèmes
externes, étend et personnalise les fonctionnalités). Ces différents utilisateurs ont donc un accès, mais
aussi des rôles virtuels bien définis à des zones de travail précises. Il s’agit d’un accès aux autres zones de
travail qui sont contrôlées par l’appartenance aux rôles virtuels de : (1) Tout le monde (accès à la vue
Live, c’est-à-dire au site visiteur), (2) de CmsEditors (accès à CMS Edit et à ses rapports), (3) de
VisitorGroupAdmins (accès aux groupes de visiteurs de la CMS) et (4) de CmsAdmins (accès à toutes les
zones de travail du système de gestion de contenu). Le CMS Episerver utilise donc une politique
d’authentification et d’autorisation multi-user via ASP.NET Membership, ASP.NET Identity ou SQL
Membership, avec l’aide d’un formulaire.
Globalement, le CMS EpiServer qui vient d’être choisi dans le cadre de notre projet pour pouvoir
construire ou mettre sur pied un annuaire en ligne passe pour un CMS ou WCMS robuste, et cela, grâce à
son ouverture ou personnalisation extensible. Il possède une architecture découplée qui reste en phase
avec les attentes des développeurs modernes et le développement des nouvelles fonctionnalités liées se
poursuit. Quant aux rédacteurs et/ou éditeurs web, qui sont donc aujourd’hui au coeur de la création de
contenus web, ils bénéficient d’une interface intuitive et fonctionnelle mais aussi d’un moyen de visualiser
les données qui sont stockées sur le SGBD MS SQL utilisé. En plus, un autre élément important à faire
savoir ce qu’une licence gratuite et valide est fournie à tout développeur et/ou intégrateur EpiServer, et
cela, après une souscription en ligne sur le site EpiServer. Cette licence est utilisée au niveau de
l’environnement de développement et indique voire que la version de votre CMS et le site ou l’application
web construite n’est pas une version commerciale.
2.1.5 La documentation du projet
Le processus de développement logiciel adopté a l’obligation d’être bien planifié et documenté. Ainsi,
l’organisation et l’affectation des ressources nécessaires pour notre projet, la planification de tâches et la
répartition de tâches planifiées aux différentes ressources affectées à notre projet, ou l’attribution de
créneaux horaires individuels à ces ressources, etc. se trouvent déjà repris dans le plan de développement
logiciel (PDL) rédigé avant le démarrage de ce projet. Lors de la réalisation de différentes tâches ou
activités du projet via notre procédé adopté, tous les documents qui sont ou seront générés avant le début
ou pendant le projet seront conservés, ensemble avec le code source. Parmi ces documents, nous avons
déjà cité le PDL (qui comprend les devis et le calendrier, etc.), mais aussi les rapports, les mémos, les
messages électroniques, les normes et les autres documents de travail.

41
Un outil va être utilisé pour pouvoir rédiger une partie de la série de descriptions techniques de notre
projet, à savoir les sprints les backlogs et leurs users stories, mais aussi la description, l’effort, la priorité,
ou la ressource humaine affecté à chaque backlog, user storie, etc. Cet outil est le TFS de Microsoft. Ainsi,
pendant toute l’activité de développement, le contenu en question sera mis à jour et amélioré au fur et à
mesure

42
 Chapitre 3
Résultats obtenus

Ce chapitre présente dans un premier temps les résultats de la collecte et d’analyse de besoins exprimés
par le client, mais aussi leur transformation en exigences fonctionnelles et/ou non fonctionnelles (modèle
d’exigences). Ensuite, dans un deuxième temps, il présente la définition de différentes pages ou interfaces
web de l’annuaire en ligne et la conception proprement dite de l’architecture informationnelle et des
différents prototypes liées aux différentes pages ou interfaces web définies. Ces dernières sont codées par
la suite. Codées grâce à l’IDE et aux technologies et langages associées choisis, quelques pages ou
interfaces web de la première version (beta) de cet annuaire en ligne sont donc illustrées sous forme
d’images obtenues d’un point de vue contenu et esthéthique de conception graphique.
3.1 Collecte et analyse de besoins exprimés par le client
3.1.1 Raffinement de différents besoins exprimés
Avec notre procédé de développement logiciel intégré ou unifié défini et adopté, il y a logiquement une
étape de collecte et analyse des besoins exprimés par le client et/ou par les utilisateurs cibles. Il s’agit
d’une étape qui est réalisée par une série d’entretiens qualitatifs et quantitatifs dans le but de cerner
correctement la portée et/ou le but du projet web à réaliser. Toutefois, pour rester honnête envers nous-
mêmes, la série d’entretiens n’a pas eu lieu dans le cadre de ce projet car les principaux besoins exprimés
par notre client, c.à.d. par le tuteur de ce module de cours semblaient être clairs (voir point 2.1) et ont servi
pour la partie étude préalale du projet. En plus, le fait que le procédé de développement logiciel intégré ou
unifié défini et adopté par nous renferme des valeurs agiles Scrum, nous avons alors décidé de faire
l’analyse des besoins exprimés sans attendre que tous les besoins n’aient été collectés et définis en détail.
Au fait, nous sommes très sûr que le feed-back que nous allons recevoir après la présentation de premiers
prototypes qui seront fabriqués vont nous permettre d’améliorer et de faire évoluer ensemble avec le client
et/ou avec les utilisateurs finaux les principaux besoins et les différentes exigences que nous aurons à
élaborer. D’ailleurs, le plan de travail repris dans le PDL rédigé avant le démarrage effectif de ce projet
passe pour notre plan global qui a donc connu des améloirations au cours de la réalisation de ce projet.
Sous ce principe agile et/ou Scrum décidé, le PDL rédigé est le résultat non définitif de notre collecte et
analyse des besoins exprimés par notre client. Toutefois, nous avons eu à compléter ce résultat non
définitif et les principaux besoins exprimés au fur et à mesure de l’évolution du projet, et cela, grâce à une
série des questions complémentaires après des feedback obtenus sur des pages ou interfaces web
construites.
Les quelques questions complémentaires dont nous nous sommes posées sont reprises ci-dessous. Il s’agit
par exemple de :
- Quelle est la mission ou l’objet réel de l’annuaire en ligne qui devrait être construit ?
- Quelles sont les ressources matérielles, technologiques, humaines et financières disponibles ou à
rendre disponible ?
- Quelles sont les informations dont nous retenons comme faisant partie du contenu de l’annuaire
en ligne et quelle charte typographique utilisée pour les afficher en respectant certaines
réglementations en vigueur ?
- Pour des informations retenues mais aussi celles à rédiger, comment préférons-nous quelles soient
présentées, classées et/ou catégorisées au niveau de l’annuaire en ligne (ici pour aboutir à une
bonne définition de l’architecture informationnelle et/ou de la structure du site ou SiteMap)?
- Qui seront les différents utilisateurs de cet annuaire en ligne ou combien de catégorie
d’utilisateurs devrions-nous avoir pour cet annuaire en ligne ? Auront-ils un vocabulaire
spécifique ? Auront-ils certaines préférences ?

43
 - Comment les différents utilisateurs retenus devront-ils utiliser l’annuaire mais aussi l’alimenter?
- Pouvons-nous réellement attribuer un compte utilisateur aux différents diplômés MIAGE de
l’UFR des sciences d’Amiens qui vont s’inscrire dans l’annuaire pour leur permettre de mettre à
jour leurs informations de profil, mais aussi pour leur permettre de participer aux différents
échanges, commentaires et partages d’expérience ou de souvenirs entre anciens ?
- Comment la fonction de recherche et de filtrage devrait-elle fonctionner?
- Etc.
Nous avons répondu nous-même à ces différentes questions complémentaires, en se plaçant ici dans la
peau des utilisateurs de l’annuaire à construire, à créer ou à fabriquer. Par retour d’expérience, les
différentes réponses ont été obtenues après des réflexions et/ou remue-méninges (brainstorming), mais
aussi par des consultations observatrices et comparatives des sites web de l’UPJV, de MIAGE d’Amiens
(UPJV), de la fédération nationale des étudiants et diplômés de MIAGE et par des lectures d’autres
sources trouvées sur Internet après une recherche Google. Les réponses et les principaux besoins exprimés
par notre client se trouvent également en partie condensé dans le PDL rédigé avant le démarrage effectif
de ce projet TI thématique.
3.1.2 La scénarisation et les users stories
Comme énoncé au point 2.1 du présent rapport, nous les avons par la suite compilés sous forme d’un
gabarit d’exigences fonctionnelles et non fonctionnelles brutes. Ces exigences brutes ont ainsi été tracées
et raffinées pour produire au final une liste ou un modèle d’exigences vérifié et validé par toutes les
parties prenantes du projet (de manière virtuelle car les autres parties prenantes n’existent pas). Il s’agit
d’une liste ou d’un modèle d’exigences qui représente donc notre cahier des charges ou ou PDL révisé.
La scénarisation des exigences fonctionnelles32 et non fonctionnelles tracées et raffinées ont donné lieu
aux différents users stories (Concrete requirements of our solution ou modèle extra-fonctionnel). Ces
derniers ont servi par la suite pour la conception et le codage. Le tableau ci-dessous reprend quelques
users stories obtenues à partir de la scénarisation des exigences fonctionnelles et non fonctionnelles
tracées et raffinées.

Libéllé Besoins compilés en exigences fonctionnelles Source Priorité

et non fonctionnelles

Stratégie/Portée Installation et configuration de l’IDE MS Development Team 1

Visual Studio 2019 (développeur web)

Stratégie/Portée Installation et configuration de Episerver Development Team 1

(extension Visual studio), de Find et des autres (développeur web)
modules Episerver

Contenu En tant qu’un utilisateur, je souhaite lire des Product-owner 2

informations pertinentes, digestes, (Client/Utilisateurs)
intéressantes et mémorables et et facilement

32
Les exigences fonctionnelles décrivent ce qu’un utilisateur peut faire avec le produit-logiciel ou avec les données
du produit-logiciel qui va être construit. Le processus de leur définition est un processus qui est itératif par nature car
il est assis sur des besoins exprimés par des utilisateurs qui sont alors souvent des besoins évolutifs au cours du
temps car fonction également de nombreux paramètres. Quant à leur liste ou modèle, elle permet tout simplement de
savoir ce que le produit-logiciel ne devrait pas faire après sa fabrication. Elle est donc le support pendant le
processus de développement ou le cahier réel des charges du développeur.

44
 accessibles sur les différentes pages à
construire

Contenu En tant qu’un utilisateur, je souhaite lire des Product-owner 2

informations sur le nom, compétence, parcours (Client/Utilisateurs)
et profession de chaque membre inscrit et
facilement accessibles sur les différentes pages
à construire

Esthétique En tant qu’un utilisateur, je souhaite voir Product-owner 2

maintenir une certaine équilibre et identité (Client/Utilisateurs)
visuelle sur le site lors de la navigation entre
les pages et/ou consultation

Esthétique / structure En tant qu’un utilisateur, je souhaite voir Product-owner 2

l’annuaire conserver un design simple, (Client/Utilisateurs)
compréhensible et élégant sur chaque appareil
utilisé

Stratégie / Contenu L’annuaire doit être à mesurer de structurer, de Development Team 2

stocker et de sécuriser toutes les données (développeur web)

Structure L’annuaire doit avoir des liens fonctionnels et Product-Owner 1

des éléments cliquables (client/utilisateurs)
Development Team
(développeur web)

Contenu L’annuaire doit mettre en évidence des champs Product-owner 1

de recherche visible pour chercher et/ou filtrer (Client/Utilisateurs)
des informations images et une navigation et Development
structurée et accessible Team (développeur
web)

Contenu En tant qu’un utilisateur, je souhaite voir sur Product-owner 1

l’annuaire des images inspirantes (Client/Utilisateurs)
et

Stratégie / Portée En tant qu’un utilisateur, je souhaite être Product-owner 1

informé sur le fil d’actualités (liens RSS) une (Client/Utilisateurs)
fois inscrit et

45
Contenu L’annuaire respecter les lois sur les données Product-owner 1
personnelles et/ou sur le GDPR (Client/Utilisateurs)
et Development
Team (développeur
web)

... ... ... ...

Tableau 2 – Première monture des users stories obtenues grâce à la scénarisation de différentes exigences
fonctionnelles et non fonctionnelles
Les points de suspension sur la dernière ligne de ce tableau indiquent le caractère non limitatif des users
stories dans un projet web. Ceci explique que d’autres users stories sont ajoutées au fur et à mesure que
nous évoluons dans la conception, dans le codage et dans les séries de tests utilisateurs, mais aussi par
rapport aux critères ou exigences qui venaient d’être élaborées ou qui seront élaborées, c.à.d. tracées et
raffinées en fonction de nouveaux besoins. Toutefois, toutes les users stories de notre projet sont reprises
comme des historiques de versions codées au niveau du Git utilisé dans MS TFS. Et, pour toute user storie
qui sert pour la conception et le codage de l’annuaire en ligne en construction (dont une partie est reprise
dans le tableau ci-dessus), un identifiant (numéro de la user storie) est attribué automatique après sa
transcription dans le MS TFS (dev azure, voir figure 15). Elle est aussi affectée à la ressource qui l’a
transcrite et également à celle qui devra procéder à sa résolution ou réalisation.

Figure 15 – Exemple d’une user storie de notre projet transcrite sur TFS.
Dans la plupart de cas, c’est le Product-owner qui est à l’origine d’une user storie, mais le Scrum master et
le Development team développeur web ou testeur, etc. Il y a également l’effort à déployer par la ressource
(en heure) qui réalise la user storie qui est renseigné. Cet effort à déployer sur la user storie est souvent
défini par les membres de Development Team (développeur web, testeur, graphiste, etc.) en commun
accord avec le Product-Owner et le Scrum Master lors d’un sprint planering. Le niveau de priorité de
réalisation de chaque user storie est aussi également défini ici sur une échelle de 1, 2, 3 et 4 (suivant la
méthode ou la technique MoScoW). Ainsi, dans une itération ou sprint (sprint 1 pour ce résultat illustré),

46
une user storie avec la priorité 1 est alors codée avant la user storie ayant la priorité 2, 3 ou 4 et ainsi de
suite. Ici, le suivi et le contrôle de cette transcription et celle des autres renseignements recommandés sur
le MS TFS, suivant la philosophie Scrum de notre procédé de développement logiciel intégré adopté, sont
assurés par le Scrum Master qui assure aussi le rôle de rédacteur de ce rapport technique et des autres
informations, mais aussi des cas et des critères de tests (Acceptance criteria). Les critères de tests pour une
user storie sont rédigés à l’intérieur d’une user storie, à partir d’un traçage qui est fait avec le modèle
d’exigences produit et le cas de test lié. Sous un oeil conceptuel pratique d’UML, nous pouvons remarquer
que chaque user storie transcrit dans le MS TFS Azure dev contient quelques lignes que l’on peut aussi
retrouver dans un cas d’utilisation (Use Case). Dans la logique IDM, ces différentes users stories, définies
lors de l’analyse et transcrites dans le MS TFS Azure dev, représentent une sorte de modèle extra-
fonctionnel fusionné avec le modèle des exigences. Elles constituent donc le point de départ de tout le
codage qui va suivre.
Pour finir, au régard de ces quelques éléments présentés, nous dirons que cette étape d’analyse est tout
simplement une analyse orientée objet qui est piloté par des modèles et des users stories dont l’intérêt est
de ressortir au final des scénarios qui doivent servir pour d’autres éléments de conception et du codage de
notre annuaire en ligne en construction. C’est voire dans ce cadre que nous avons alors opté pour les users
stories car c’est une autre bonne facon de construire, de créer ou de fabriquer un produit-logiciel, un peu
comme avec les cas d’utilisation sous UML (lire Scott Isensee, Karel Vredenburg et Carol Righi, 2001).
Ainsi, les users stories définies ici, comme notre modèle extra-fonctionnel, nous aident donc à comprendre
encore parfaitement les dépendances existantes entre les objectifs de la structure de notre client (Business
requirements), les besoins immédiats des utilisateurs immédiats et futurs (Immediate requirements of the
immediate and future users) et les besoins des autres parties prenantes (Stakeholders requirements), mais
aussi pour répondre réellement au comportement futur de notre solution informatique envisagée et à
l’amélioration du code. Dans la littérature du Géniel logiciel, elles sont présentées comme un support
direct et le plus prisé par les développeurs pour la conception et le codage qui sont faits sous un procédé
agile, à l’instar de Scrum (cf. notre modèle de conception ou design pattern au point 4.2). Leur description
et la partie servant de discussion par les parties prenantes, au niveau MS TFS Azure dev, sont dans ce cas
constitués d’un ensemble structuré et cohérent d’exigences et/ou de critères les accompagnant. Rédigées
dans un langage naturel, comme voire explicité au niveau du chapitre 2 et 3, elles passent donc également
comme l’un des nos supports de communication pour le projet.
3.2 L’architecture et/ou la structure de l’information de l’annuaire en ligne (plan du
site ou site map) et le codage.
3.2.1 L’architecture informationnelle
L’activité de structuration de l’information « repose sur la compréhension totale et synthèse de la finalité
du produit-logiciel à construire et sur des besoins raffinés des utilisateurs » (Pour Garrett Jesse, 2011).
Pour ce faire, en fonction des objectifs définis dans le cadre de ce projet TI thématique et de différentes
exigences fonctionnelles tracées et qui sont scénarisées en users stories, une architecture ou structure
informationnelle adaptée est alors définie pour notre annuaire en ligne. Cette architecture ou structure
informationnelle définie est donc la base de notre modèle de conception et devrait faciliter, une fois le
codage finalisé, un accès intuitif à l’ensemble de données et du contenu définitif qui va être retenu pour
cet annuaire en ligne.
Ci-dessous, nous vous présentons l’architecture informationnelle (structure Map) de notre annuaire en
ligne en construction :

47
 Accueil

Annuaire A propos
Blog Contact
des anciens de nous

... ...

... ...

Figure 16 - Sitemap reprenant les pages de notre site

Les différentes principales pages définies dans le cadre de cette architecture informationnelle sont la page
d’accueil, la page A propos de nous, la page Blog, la page Contact et les différentes autres pages ou sous-
pages qui dépendent de ces principales pages. Pour les rendre alors plus explicites avant leur codage
informatique sous le MS Visual Studio et différentes technologies associées, nous avons d’abord fabriqué
leurs prototypes avec l’aide des papiers fonctionnels. Ensuite, les prototypes fabriqués ont été présentées à
notre client (aux utilisateurs) pour amendements et/ou améliorations.

Figure 17 - Un des prototypes fabriqués à l’aide d’un papier fonctionnel (ici, c’est le prototype de la page
principale « Annuaire des anciens »).
D’ailleurs, c’est en liant la conception de l’interface, le fonctionnement de la navigation et la conception
de l’information ensemble dans ces prototypes papiers que nous avons pu construire correctement une
structure claire pour notre annuaire, puis créé une présentation visuelle. Ces prototypes ont été donc
fabriqués à la main et non avec un logiciel qui utilise par exemple des papiers graphiques virtuels, à
l’instar par exemple d’InDesign CC ou d’OminiGraffle, etc. Toutefois, grâce à ces prototypes fabriqués à
la main, des chemins logiques clairs et cohérents sont donc établis pour notre annuaire en ligne en
construction. Ils sont établis ici vers les différentes pages évoquées ci-dessus, c.à.d vers des pages et leurs
contenus que nous devions imaginer, mais aussi organiser et catégoriser ensemble avec le client et/ou les
différents utilisateurs (cf. notion de discrimination du contenu, lire Garrett Jesse, 2011). Ces prototypes
supportent et représentent donc concrètement l’ensemble des pages web qui vont être créées par la suite
lors du codage.

48
Notons toutefois que lors cette imagination, organisation et catégorisation de différents contenus, qui
constituent notre représentation de données et de traitements, nous avons donc placé dans notre tête l’idée
de l’usage de différentes conventions ou standards qui existent à ce jour en rapport avec le Web, et cela,
pour ne pas inventer la roue. Nous nous sommes particulièrement servis des quelques critères
d’accessibilité Web (le WCAG) afin de pouvoir fabriquer les différents prototypes de notre annuaire en
ligne qui, après leur codage ou programmation informatique, devraient être rééllement des pages ou
interfaces web accessibles aux utilisateurs ou internautes-visiteurs. Une attention particulière est
également retenue sur le principe de symétrie mais aussi sur ceux de proximité, de similarité et de
cliquabilité, cela, grâce à notre retour d’expérience antérieure sur ce type de développement. Comme
résultats, la mise en page de contenus des différentes pages web définies est rendue possible, c.à.d.
comment devrait être la navigation (nav) entre les différentes pages web à créer (compréhensible),
comment l’en-tête (header) et/ou le pied de page devraient être disposés sur toutes ces pages web
(définition d’un layout principal), mais aussi comment un contenu quelconque (texte, son, image et vidéo)
devrait être placé sur une page et comment il devrait être recherché par l’internaute-visiteur une fois
notre annuaire finalisé et mis en ligne. Cette mise en page a donné lieu à une catégorisation de différentes
pages web et contenus de notre annuaire. Ainsi, nous avons des pages standard, par défaut, partiel, etc.
contenant des textes, images et vidéos spécifiques normalisés.
3.2.2 Le codage
De manière pratique, ce sont les critères d’acceptation issues de la liste ou de notre modèle d’exigences,
puis les différentes users stories s’en sont suivies (modèle extra-fonctionnel) et transcrites dans le MS
TFS, qui ont réellement permis de définir la structure et/ou l’architecture informationnelle présentée ci-
dessus et de fabriquer les différents prototypes. Donc, notre modèle global d’analyse qui est issu de notre
modèle d’exigences et de notre modèle extra-fonctionnel, mais aussi notre modèle de conception (design
pattern) qui vient d’être obtenu confirment la portée et la stratégie qui ont été définies dans le PDL pour ce
projet TI thématique : celui de construire un annuaire à partir d’un modèle de conception qui est piloté par
les utilisateurs avec notre concours, précisément par leurs différentes interactions, échanges ou feedbacks
et en s’inspirant des conventions web liées.
Ci-dessous, nous présentons par exemple l’écran de la matérialisation informatique de notre modèle de
conception sous MS Visual Studio, avec l’aide du codage C#, HTML, CSS, Javascript et autres
technologies associées.

Figure 18 – Ecran représentant le code et les différents objets et propriétés de notre annuaire structurés en MVC
sous le MS Visual Studio

49
Il s’agit d’un modèle MVC obtenu grâce au style REST API unifié d’EpiServer qui accompagne le CMS
Visual Studio Extension installé dans l’IDE utilisé pour le codage de notre annuaire (Il s’agit de MS
Visual Studio .Net choisi). Avec ce modèle matérialisé, nous travaillons donc avec les contenus ou
données définies sous-forme d’objets et de propriétés spécifiques à un domaine, le cas de données des
anciens étudiants, leurs filières suivies, etc., sans avoir à se préoccuper des tables et des colonnes de la
base de données MS SQL sous-jacentes où ces données vont être stockées. D’ailleurs, c’est aussi grâce au
CMS Visual Studio Extension installé dans l’IDE utilisé que nous avons également ci-dessous la partie
non contraignante de personnalisation de notre annuaire par les différents utilisateurs (administrateurs,
rédacteurs web, etc.).

Figure 19 - L’interface de rédaction et de personnalisation WYSIWYG du CMS EpiServer

Le côté design web graphique de l’annuaire en ligne construit, en rapport avec le contenu (texte, image et
vidéo), l’esthétique ou l’ergonomie et la responsive n’a pas été omis. C’est ce que nous allons même vous
présenter dans les autres points qui vont suivre. Toutefois, lors du codage HTML, CSS, JavaScript/Jquery,
Bootstrap et C#, grâce à la fusion de deux premiers modèles (modèle d’exigences et modèle extra-
fonctionnel), en terme de priorité retenue ou décidée par le client, et au modèle de conception obtenu,
nous avons eu une véritable image cible de l’annuaire en ligne à fabriquer. Nous ne nous sommes donc
pas simplement camper sur des hypothèses car nous savions désormais ce que les utilisateurs finals
attendent de nous.
3.2.3 Le contenu définitif de l’annuaire en ligne.
Le contenu d’un site et/ou d’une application web est très important car c’est ce que l’utilisateur ou
l’internaute-visiteur recherche en premier lieu avant même de le voir, de l’aimer et de le lire (cf.
Sundström Tommy, 2005). Lors de l’étape conceptuelle, en nous pechant sur cette question, le type de
différents contenus de l’annuaire en ligne a également été défini. Il s’agit d’un contenu multimédia (textes,
images et vidéos) qui répond donc aux principes de la communication visuelle dans leur ensemble.
Pour rappel, plusieurs manières pratiques existent pour se pencher sur cette question. Nous concernant,
nous avons utilisé la manière la plus prisée actuellement par des web développeurs ; surtout ceux qui font
leur modélisation et leur codage informatique sous le design pattern MVC offert par le .Net ou le CMS
EpiServer. Avec cette manière la plus prisée, qui n’est rien d’autre que l’usage des papiers fonctionnels,
nous avons même réussi d’intégrer, aux fins d’une conception visuelle concrète, l’architecture ou la

50
structure de l’information de notre annuaire sur les différentes pages web définies de notre annuaire en
ligne.
Toutefois, lors de la même étape, dans le but de pouvoir définir le contenu définitif de l’annuaire en ligne,
et lors de l’étape du codage informatique, nous retenons que la page :
- « Accueil », définie lors de la structuration de l’information comme étant la page principale de
notre annuaire en ligne, contient alors des informations multimédias qui se distinguent de celles
des autres pages web de l’annuaire par le fait qu’elle représente de manière claire et forte à
l’internaute-visiteur l’ensemble de la solution web sur laquelle il se trouve. A partir d’elle,
accessible par le nom de domaine imaginé selon le contexte (http://www.almunimiageamiens.fr),
les autres pages sont aussi accessibles, et cela, grâce aux différents liens hypertextes (chemins
logiques clairs et cohérents qui ont été établis) qui s’y trouvent sur les différentes informations ou
contenus multimédias définis. Ces informations ou contenus sont donc celles de message de
bienvenu (l’image illustrant une promotion MIAGE lors de la remise des diplômes et le texte de
côté), mais aussi celles de la présentation en chiffres de l’UPJV (l’Alma mater) et de l’entité
MIAGE Amiens de l’UPJV. Des images fusionnées y sont associées représentant le logo de
l’UPJV et celui de MIAGE Amiens ensemble, etc. Il y a également trois cartes avec des images
matricielles remplies qui sont utilisées sur cette page d’accueil. Elles sont utilisées pour mettre en
valeur les différents services ou activités que le réseau d’anciens étudiants diplômés MIAGE
d’Amiens compte offrir aux nouveaux diplômés, aux étudiants finalistes MIAGE d’Amiens et à
l’alma mater (à savoir les services de mentorat, de proposition de sujets de recherche et de
transfert ou partage d’expertise entre les anciens et nouveaux diplômés, puis les étudiants
finalistes MIAGE d’Amiens).
- « Annuaire-des-anciens », elle a une rubrique introductive suivi d’un champ ou formulaire de
recherche par filtrage écrit en HTML, CSS et Javascript/Jquery pour faciliter, après la saisie d’un
texte sous un critère donné, la recherche d’un ancien étudiant diplômé MIAGE d’Amiens et
l’affichage synthèse de son profil académique et professionnel (nom, photo et texte introductif).
Avec un un clic sur un des profils affiché, il y a la redirection sur une page entière reprenant cette
fois-ci le profil académique et professionnel complet de l’ancien étudiant diplômé MIAGE
séléctionné. Donc une liste globale de tous les anciens étudiants diplômés MIAGE inscrits dans
l’annuaire se trouve alors en dessus de ce champ de recherche. Entre le champ de recherche et la
liste globale se trouve une option de filtrage qui est aussi écrit en HTML, CSS et
Javascript/Jquery. Cette option donne la possibilité aux internautes-visiteurs de filtrer les anciens
étudiants diplômés MIAGE d’Amiens par domaines de compétences.
Avec un clic sur un des onglets de la sous navigation qui se trouve à gauche, il y a un filtrage
hiérarchique qui est effectué sur la liste affichée ; une sorte de filtrage des pages par promotion
(année) et par filière de formation (INE, OSIE, SIN, etc.). Quant à la page de présentation du
profil complet d’un ancien étudiant diplômé MIAGE d’Amiens sélectionné, elle peut être
imprimée sur une imprimante ou sous un format .pdf. Elle donne aussi la possibilité aux différents
internautes-visiteurs de se rediriger, via un clic de leur part, vers le profil Linkedin, Facebook ou
Twitter de l’ancien étudiant diplômé MIAGE d’Amiens sélectionné, mais aussi sur la page
d’abonnement au fil d’actualité RSS de l’annuaire en ligne (en remplacement de News-letters).
- « A propos de nous », elle présente aux internautes-visiteurs des informations dites importantes
pour notre annuaire en ligne. Elle a une sous page à deux onglets qui reprend des informations et
les différents évènements organisés ou à organiser par le réseau des anciens (informations
&events). Il y a aussi une sous page sur la navigation affichée à droite de cette page qui nous
présente l’équipe de coordination du réseau (leur photo, leur profil et leurs coordonnées de
contact). Il y a également une sous page réservée pour les différents services offerts par le réseau
des anciens MIAGE d’Amiens (Impliquez-vous), présentés partiellement sous forme des cartes
matricielles remplies sur la page d’accueil, mais également une autre sous page indiquant la
possibilté de faire un don. Cette dernière n’est pas affichée au niveau de la page d’accueil pour
répondre au principe de communication visuelle en terme d’informations phares à afficher sur une
page d’accueil (lire Sundström Tommy, 2005). Quant à la sous-page Impliquez-vous évoquée ci-

51
 dessus, elle donne la possibilité par un clic d’aller sur les détails de chaque services offerts par le
réseau des anciens, à l’iinstar de mentoring, de proposition de sujets de recherche et de transfert
ou partage d’expertise.
L’onglet ou la sous-page « contacter nous » sur cette page principale (A propos de nous) nous
rédirige directement sur la page principale « Contact ». Des séries d’autres sous-pages sont
également disponibles sur presque tout sous-page de cette page principale « A propos de nous ».
- « Blog », cette dernière offre une interaction ou un échange entre les membres du réseau sur un
article ou un post (thème ou tag) ouvert aux commentaires, c.à.d. entre les anciens étudiants
diplômés MIAGE d’Amiens. La page partielle pour les commentaires à faire sur un article rédigé
peut être totalement masquée ou seuls les commentaires désactivés. Cette page partielle pour
commentaires se trouve sur une sous-page qui dépend hiérarchiquement de la page principale et
qui reprend entièrement un article ou un post rédigé et publié. Les commentaires ne sont alors
activés ou visibles aux différents internautes-visisteurs qu’après un contrôle d’éthique et du
réglement lié par l’utilisateur administrateur gérant cette partie de l’annuaire en ligne. A part le
contenu textuel de l’article ou du post rédigé sur la sous-page dépendant hiérarchiquement de la
page principale, c.à.d. de la page « blog », il y a toujours une image associée et illustrant ce
contenu textuel. C’est donc un contenu multimédia sur cette sous-page et, comme c’est le cas pour
la sous-page presque similaire de cette page principale « Anuuaire des anciens », il peut aussi être
imprimé sur une imprimante ou sous un format .pdf. La sous-page donne également la possibilité
aux différents internautes-visiteurs de partager, via un clic de leur part, le contenu du post ou de
l’article sur le profil Linkedin, Facebook ou Twitter de l’ancien étudiant diplômé MIAGE
d’Amiens sélectionné, mais aussi de se rédiriger sur la page d’abonnement au fil d’actualité RSS
de l’annuaire en ligne (en remplacement de la demande de News-letters faite au départ par le
client). Les différents articles ou posts du blog sont donc classés hiérarchiquement comme c’est le
cas avec la liste des anciens. Ils sont classés par année et par mois sur la page de navigation se
trouvant à droite. Quant aux commentaires sur les pages partielles, une option de consentement,
sous forme de bouton radio à cocher obligatoirement, est mise à la disposition des différents
internautes-visisteurs avant leur envoi.
- « Contacter nous », elle contient des indications de renseignement sur un formulaire qui offre aux
différents internautes-visiteurs de l’annuaire en ligne d’entrer en contact avec l’équipe de
coordination ou avec un membre du réseau via la même équipe de coordiantion. A part les
différents champs guidant les différents internautes-visiteurs, il y a aussi des champs avec des
options requises sous forme des boutons radio.
Un logo attractif est repris sur chaque page ou interface web à créer ou créée. Il représente ainsi l’identité
visuelle du réseau des anciens mais aussi la page d’en-tête (header) de l’annuaire en ligne construit et en
cours de finalisation. Il est donc associé avec la barre de navigation horizontale pointant sur les principales
pages ou interfaces web définies (accueil, annuaire des anciens, à propos de nous, blog et contact), mais
aussi avec un champ de recherche et une icone de redirection vers le site web de MIAGE Amiens. Quant
au pied de page, qui est aussi repris sur sur chaque page ou interface web à créer ou créée, il est l’endroit
où chaque utilisateur ou internaute-visiteur peut retrouver des liens utiles de l’annuaire en ligne en cours
de finalisation.
Dans l’ensemble, tous les contenus dont nous supposons définitifs sur toutes ces pages web décrites ci-
dessus sont rédigés en langue francaise par un rédacteur web et leur flux est pris facilement en charge. Ils
peuvent même être imprimés, avec l’aide d’une imprimante installée ou sous le format .pdf.

52
Figure 20 – Une partie de la page web principale « Blog » et son contenu définitif rédigé par le web redacteur après
codage.
La figure ci-dessus illustre une des pages ou interfaces web créée et codée informatiquement, mais aussi
son contenu supposé définitif de la version de l’annauire en ligne qui vient d’être construit. Il s’agit d’une
page web qui est donc accessible à tous les internautes-visiteurs et son contenu définitif est mis à la
disposition de ces derniers en respectant voire les lois et réglèments européens sur les données à caractère
personnel mais aussi sur les critères WCAG. C’est aussi un contenu pertinent, digeste, intéressant et
mémorable, également organisé et catégorisé suivant une architecture ou une structuration de
l’information qui est durable, stable, plate et hierarchique. Son indexation par le moteur de recherche
intégré EpiServer et celle des autres pages ou interfaces web créees sont aussi également opérationnels.
Ainsi, il pourra être retrouvé, ce contenu, par tout utilisateur cible de l’annuaire en ligne suivant les rôles
attribués par l’administrateur du CMS. Logiquement, c’est aussi également un contenu qui devrait être
accessible et facilement retrouvable par des moteurs de recherche et des robots d’exploration existants
actuellement sur le Web (Google, Yahoo, ...) (cf. notion de SEO).
Autre chose qui est sûre ici ce que toutes les pages ou interfaces web créées s’intègrent parfaitement au
cadre Scrum et au cadre théorique et pratique de Garett Jesse. Elles sont donc le réflet exact de différents
prototypes fabriqués et qui ont servis pour leur codage informatique.
3.3 L’esthétique de différentes pages ou interfaces web créées.
L’aspect esthétique et/ou l’aspect particulier de la communication visuelle de notre annuaire en ligne
reposent de manière pratique sur l’interaction de surface pour aboutir à une expérience utilisateur réussie.
Il s’agit d’un aspect qui est classiquement basé sur la convivialité souhaitée par et/ou aux différents
utilisateurs ou internautes-visiteurs, à partir de l’usage des polices et tailles de caractères (textes ou
lettres), des couleurs ou des effets sur des textes, sons, images et vidéos contenus dans une page web
créée. Il est ainsi couplé, comme déjà mentionné au chapitre 2 de ce rapport, avec les techniques
responsives liées aux différents devices utilisés ou à utiliser par les différents utilisateurs ou internautes-
visiteurs (desktops, mobiles tablettes ou mobiles smartphones, etc.) et avec la disponibilité ou accessibilité
Web dans son ensemble.
Toutefois, pour arriver à obtenir réellement cet aspect particulier de la communication visuelle sur notre
annuaire, nous nous placons ici dans la peau des utilisateurs ou internautes-visiteurs, mais aussi dans la
possibilité de nous exprimer nous-même sur nos propres sentiments en tant développeur. Ci-dessus, les

53
quelques éléments liés pris en compte et/ou affectés lors de la conception et du codage de l’annuaire en
ligne et les différents résultats obtenus.
3.3.1 La charte typographique et l’intégration du contenu définitif au niveau des pages ou
interfaces web construites
La langue optée pour rédiger le contenu définitif de notre annuaire est la langue francaise (configurée ou
intégrée voire au niveau du fichier _root.cshtml et dans l’interface d’administration Episerver). Mais, cela
n’exclut pas qu’une citation dans une autre langue, le cas de la langue suédoise ou de la langue anglaise,
soit reprise dans une des pages web créées car les anciens étudiants diplômés MIAGE d’Amiens sont
originaires de plusieurs pays. Ils parlent différentes langues en dehors de la langue francaise et ont des
cultures différentes qui cohabitent dans le cadre de la bonne marche du réseau des anciens.
Toutefois, pour le choix typographique, les principales couleurs appliquées sur les différents contenus de
nos différentes pages ou interfaces web créées sont la couleur blue, la couleur blanche et la couleur noire.
Ce choix est fait selon la logique communicationnelle visuelle adoptée dans le cadre de notre projet, et
celle de l’alma mater (UPJV). Derrière la même logique communicationnelle visuelle, une sorte
d’affichage érgonomique sémi-plate sur un fond de couleur blanche est ajouté sur chaque page ou
interface web créée et/ou à créer dans le futur sur notre annuaire en ligne. Les caractères sur les différents
textes utilisés ont pour : (1) font-family : Helvetica Neue, Helvetica, Arial, sans-serif, ... ; (2) font-size :
3.5em, 2.5em, 1.5em, 1em, ... ; (3) line-height : 1.5em, 1.3em, 1em, ... ; etc. Le fichier CSS complet de
configuration de ces différentes valeurs typographiques est le fichier « style.css ». Suivant les
recommandations de Sundström Tommy (2005), nous avons décidé ici que certains contenus retenus sur
les différentes pages ou interfaces web créées héritent tout simplement les valeurs typographiques par
défaut de la bibliothèque Bootstrap utilisée.
A part cette application typographique, nous allons aussi observer la définition et l’application
typographique sur les images, les buttons ou les icones utilisées, etc. Un autre élément à dire ce qu’au
niveau de notre code CSS et voire Bootstrap, nous avons également codifié les différentes couleurs
utilisées soit en écriture héxadécimales (0 à 9 et A à F) ou en écriture RGB (00 à FF qui correspond à 0-
255 dans l'échelle RVB).
La figure ci-dessous présente alors une partie des résultats obtenus par rapport à cette logique
communicationnelle visuelle globalement adoptée, particulièrement en termes de charte typographique.

Figure 21 – La page principale « accueil » de l’annuaire et l’en-tête (header), avec un logo et une barre de
navigation.

54
La couleur blanche appliquée alors sur le fond de chaque page ou interface web créée de l’annuaire en
ligne « symbolise globalement l’innocence, la neige et le froid » (Petterson Run et al, 2004). Dans notre
cas, elle indique aussi aux internautes-visiteurs de notre annuaire en ligne la pureté, la propreté et la
perfection d’esprit que l’on retrouve auprès de tout ancien étudiant diplômé MIAGE d’Amiens. Nous
l’avons également appliquée sur chaque page ou interface web créée de l’annuaire en ligne pour qu’elle
joue aussi également le rôle de zone de repos visuel pour des internautes-visiteurs pendant leurs
différentes consultations de pages ou interfaces web de l’annuaire en ligne construit et en cours de
finalisation.
La couleur bleue est généralement définie dans la conception graphique pour le Web comme étant une
couleur universelle (lire Petterson Run et al, 2004). Visible ici sur la page d’accueil illustrée (précisément
au niveau du logo de l’annuaire en ligne et du logo de l’UPJV placé comme lien, mais aussi sur certains
autres éléments de ladite page : boutons « rechercher », « lire plus » et de rédirection sur le site MIAGE
d’Amiens), elle est aussi appliquée sur la majorité de pages ou interfaces web créées, et cela, dans le but
d’apporter et/ou de faire ressortir la confiance, la loyauté, la paix, la sécurité et l’harmonie entre les
anciens étudiants diplômés MIAGE d’Amiens. Si l’on doit à nouveau se référer à Petterson Run et al.
(2004), c’est aussi également une couleur qui symbolise la dignité et la représentativité (rayonnement) des
anciens étudiants diplômés MIAGE Amiens dans la majorité d’organisations ou entreprises de leurs pays
respectifs. En plus, elle représente voire également la force actuelle des nouvelles technologies et/ou de
l’informatique qui est alors le socle de la formation MIAGE et mais aussi la réponse actuelle au niveau de
la société des hommes ou de l’information.
Quant à la couleur rouge, elle est utilisée pour attirer plus l’attention des internautes-visiteurs de
l’annuaire en ligne construit sur certaines informations phares. Elle symbolise aussi la dynamique, la
détermination et la ténacité qui sont recommandées aux humains de manière générale, avec un plus fort
potentiel d’action.
La couleur noire, par contre, bénéficie même toujours d’une typographie large et unique dans n’importe
quelle solution web actuellement. Elle symbole dans notre cas l’élégance, la formalité, la rigueur, la
distinction, la compétence, l’intelligence et le style de vie que doivent faire montre tous les anciens
étudiants diplômés MIAGE d’Amiens.

Figure 22 – Une partie de la page d’accueil, avec des cartes avec images matricielles remplies ayant plusieurs
couleurs, et le pied de page de l’annuaire (footer), avec des liens jugés essentiels et incountounables.

55
Il y a une partie de la page d’accueil illustrée qui n’est pas visible sur la figure 20. Sur la figure 21 ci-
dessus, qui reprend la partie qui était non visible mais aussi sur d’autres pages ou interfaces web de
l’annuaire, il est observé l’utilisation discrète des autres couleurs, telles que les couleurs orange (active et
énergique), violette (fierté et dignité), verte (paix et harmonie d’un point de vue nature) et jaune
(bonheur). La raison d’être de cette utilisation discrète ce que ces couleurs sont en partie obligatoires et
naturelles sur certaines images, vidéos ou textes retenus, mais aussi beaucoup plus sur les polices de
différents caractères de ces derniers.
Comme décrite au niveau du point 4.3 de ce rapport, des cartes avec images matricielles remplies ou dites
géantes sont utilisées. Elles sont donc par exemple utilisées sur la page d’accueil de notre solution pour
mettre en valeur les différents services ou activités que le réseau d’anciens étudiants diplômés d’Amiens
compte offrir aux étudiants finalistes et nouveaux diplômés MIAGE d’Amiens en rapport avec leur stage
ou insertion professionnelle, particulièrement les services ou activités de mentorat, de proposition de
sujets de recherche et de transfert ou partage d’expertise entre les anciens et les nouveaux diplômés, et par
ricochet aux étudiants finalistes MIAGE d’Amiens.
L’application de la symétrie est également de rigueur sur les différentes pages ou interfaces web créées,
mais aussi sur ces différentes cartes avec images matricielles remplies et reprises ci-dessus. Sans paraître
monotone, une petite dose progressive d’asymétrie est aussi appliquée sur l’ensemble homogène de
différentes pages ou interfaces web créés, cela en vue d’attirer le regard des utilisateurs ou internautes-
visiteurs sur un endroit stratégique de l’annuaire en ligne où nous souhaitons réellement que leur attention
ou leurs yeurs convergent, car une chose est sûre ce que la symétrie représente toujours un sorte
exceptionnelle d’imagination réussie, de mise en d’ordre et d’harmonie d’un point de vue visuel (le cas de
la couleur rouge déjà évoquée précédemment). Derrière le principe typographique de symétrie apppliqué
ici se cache aussi les principes de proximité, de simularité et de cliquabilité.
Les icones pour imprimante et pour la messagégie électronique, mais aussi pour les trois réseautages
sociaux phares, à savoir le Linkedin, le Facebook et le Twitter, sont mises en œuvre au niveau de certaines
pages ou interfaces web construites. Ces différentes icones sont réellement placées au niveau de la sous-
page de la page principale « Blog », qui est au fait la sous-page qui reprend de manière intégrale un article
ou un post rédigé et publié dans la partie blog de l’annuaire en ligne construit (voir figure 23).

Figure 23 – Exemple d’un article ou post intégral du blog (ici, avec des liens icones sur les trois réseautage sociaux
phares, et pour l’impression, le mailing et le fil RSS).

56
Elles sont aussi placées, ces différentes icones, au niveau de la sous-page de la page principale
(« Annuaire des anciens »), qui reprend à son tour le profil complet d’un ancien étudiant diplômé MIAGE
d’Amiens sélectionné (voir figure 25). Les liens des icones Linkedin, Facebook et Twitter pointent vers
leurs sites web officiels et les différents articles rédigés et publiés ou les différents profils complets des
anciens étudiants diplômés MIAGE d’Amiens peuvent alors être partagés. Quant aux icones ou boutons
« mail » et « print », elles jouent leurs rôles respectifs. La bibiothèque « Font Awesone » est utilisée pour
obteni toutes ces différentes icones à l’exception de l’icone RSS qui est dessinée sur MS Paint.Net. Il y a
aussi d’autres icones ou boutons qui sont déssinés avec l’aide du même logiciel pour le même annuaire en
ligne, le cas des icones ou boutons « rechercher », « contact » et « don ».
Le filtrage hiérachique, décrite au point 4.3., est matérialisé au niveau la sous-page (promotion-année, voir
figure 24), mais aussi au niveau de la sous-page filière et de leur page principale « Annuaire des anciens ».

Figure 24 – Une partie de la sous page de la liste des anciens étudiants diplômés filtrée par promotion 2017, grâce
au choix de l’onglet qui se trouve dans la sous navigation à gauche.
Le champ de recherche qui s’y trouve alors sur ces trois différentes pages sert aussi de filtre mais,
seulement pour pouvoir filtrer les noms et/ou les autres informations synthèse sur les anciens étudiants
diplômés MIAGE d’Amiens affichés sous-forme des listes (générale, par promotion-année et par filière).
Ce filtrage est codé sous Jquery et il est indépendant du moteur de recherche intégré Episerver (search)
personnalisé. Avec un clic sur le nom ou sur les autres informations de systhèse d’un ancien étudiant
diplômé MIAGE d’Amiens selectionné, l’internaute-visiteur est rédirigé vers la sous-page qui reprend le
profil ou le CV complet de ce dernier (voir figure 25)

57
Figure 25 – Une partie de la page de présentation du profil complet d’un ancien étudiant diplômé MIAGE d’Amiens
Pour terminer cette série d’illustrations, notons aussi également que la page « Contact » que nous
reprenons ci dessous présente la prise en compte des différentes lois et/ou réglèments européens en rapport
avec la protection de données à caractère personnel ou le GDPR.

Figure 26 – La page Contact de l’annuaire en ligne construit.

Dans le formulaire qui est repris sur cette page de contact, à part le nom, le prénom et l’email, qui sont
réquis avant l’envoi de tout message à l’équipe de coordinnation, il y a aussi deux zones de boutons radio
(checkbox) qui sont également requises ou obligatoires. La première zone est sous-forme d’un choix
multiple obligeant l’internaute-visiteur ou le futur membre du réseau à renseigner quel type de message
devrait être envoyé à l’équipe de coordination. Quant à la deuxième zone, elle est unique et oblige
l’internaute-visiteur à accepter ou pas d’adhérer à la politique d’utilisation de données personnelles qui est
conforme aux lois ou réglèments de l’UE (CNIL, Datainspektionen ou GDPR, etc). Il est accompagné

58
d’un lien de lecture de cette politique d’utilisation de données dans le cadre de cet annuaire en ligne
construit.
3.3.2 Le responsive
Les différentes pages ou interfaces web créées pour l’annuaire en ligne, et dont certaines viennent d’être
illustrées dans le précédent point, sont jusque-là présentées ergonomiquement ou de manière responsive
sous un format Desktop (1200px ou plus). Avec les différents scripts de la bibliothèque Bootstrap et de
CSS qui accompagnent le framework MVC de Episerver, ces différentes pages ou interfaces web créées
peuvent ainsi s’afficher aussi sous le format mobile-tablette (920px et 640px) et/ou sous le format mobile-
smartphone (480px et 320px). Ci-dessus, les résultats d’affichage de la page principale « Annuaire des
anciens » sous les formats responsives évoqués :

Figure 27 - Affichage responsive de la page principale « Annuaire des anciens » sous le format Desktop (ici, avec le
device HP Z Book 1200px).
Dans l’ensemble, pour réussir cette responsive, nous avons joué avec les Media queries.

59
 Figure 28 - Affichage responsive de la page principale « Annuaire des anciens » sous les formats Mobile/tablette
(ici, avec le device iPad : 768 px x 1024 px) et Mobile/smartphone (ici, avec le device iPhone X : 375 px x 812 px).
Toujours avec les différents scripts de la bibliothèque Bootstrap et de CSS utilisés, la navigation entre les
différentes pages ou interfaces web créées de l’annuaire en ligne reste fonctionnelle mais devient encore
plus conviviale. Au niveau des mobiles-tablettes et/ou des mobiles/smartphones, cette navigation utilise
voire un « Hamburger menu » qui, à première vue, cache la longue liste des liens qui ne s’affichent à
l’écran qu’après un clic. En faisant le tour complet de l’annuaire en ligne construit, plusieurs autres
éléments sont donc aussi à découvrir sur les différentes pages ou interfaces web créées.
Nous pensons qu’avec la responsive appliquée sur les différentes pages ou interfaces web créées, nous
avons alors permettre à tout internaute-visiteur ou futur utilisateur de l’annuaire en ligne construit de
pouvoir aimer le contenu qu’il va voir, mais aussi le lire et de trouver réellemnt ce qu’il cherche, puis de
l’utiliser.
3.3.3 Tests d’utilisabilité et d’accessibilité sur les différentes pages ou interfaces web créées
pour l’annuaire en ligne
Plusieurs tests (unitaires, d’utilisabilité et d’accessibilité) sont réalisés durant la création de différentes
pages ou interfaces web de l’annuaire en ligne.
Par rapport aux tests utilisateurs, notre attention est beaucoup plus focalisée sur les critères d’acceptation
définis sur chaque user storie lors de l’étape de collecte d’expression des besoins et d’analyse. Ils sont
alors réalisé au niveau de différentes versions de code produites à chaque itération ou sprint, et cela, en se
faisant passer pour le Scrum master virtuel qui devrait, dans le cadre de ce projet, écrire les différents cas
de tests et faire aussi les tests, mais aussi jouer les rôles des utilisateurs cibles.
Les tests utilisateurs réalisés sont précédés par des séries de tests unitaires faits par le web développeur
lors du codage de chaque user storie. Ici, une mesure de qualité et de rapidité avec laquelle un utilisateur
peut effectuer une tâche dans l’annuaire en ligne construit (performance attendue), le contrôle ou
l’affichage de différentes informations introduites dans l’annuaire par n’importe quel catégorie
d’utilisateurs (tests exploratoires ou fonctionnelles sur le contenu ou les données), ou l’assurance de
fonctionnement de différents liens de navigabilité entre les différentes pages ou interfaces web créées, etc.
ont été parmi les cas de tests réalisés. Les tests utilisateurs ont donc lieu à la fin du codage de chaque user
storie et à la fin de tous les sprints de la première version de l’annuaire en ligne, mais aussi avant la mise
en production de l’annuaire.

60
Une autre série de tests concernent les tests d’accessibilité (WCAG 2.1). Ces derniers servent de
vérification et de validation de l’ensemble de l’annuaire en ligne construit et portent sur les violations de
critères WCAG. Ils sont réalisés sur les versions de l’annuaire en ligne produites après le codage des users
stories (retenues pour chaque itération ou sprint) par le web développeur. Ci-dessus, nous reprenons
quelques critères WCAG 2.1. qui ont servis comme fondements pour cette série de tests d’accessibilité sur
les différentes pages ou interfaces web créées.

Quelques critères ou lignes directrices WCAG 2.1 N° de critère Niveau

Perceptible

Décrivez avec du texte tout le contenu qui n'est pas du texte. 1.1.1 A

Options d'offre si un enregistrement consiste uniquement en audio ou vidéo. 1.2.1 A

Entrez dans le code ce que les différentes parties de la page Web ont pour rôle. 1.3.1 A

Présentez le contenu d'un ordre significatif pour tout le monde. 1.3.2 A

Ne subordonnez pas les instructions aux caractéristiques sensorielles 1.3.3 A

Assurez-vous que tout le contenu est présenté correctement quelle que soit la 1.3.4 AA
direction de l'écran.

Étiquetez les champs de formulaire communs dans le code. 1.3.5 AA

Vérifiez que le texte placé avec des images en arrière-plan présente des valeurs 1.4.3 AA
de contraste suffisantes.

Utilisez du texte, pas des images, pour afficher du texte. 1.4.5 AA

...

Utilisable

Vérifiez si le service utilise des raccourcis clavier composés uniquement de 2.1.4 A

lettres. Ceux-ci doivent pouvoir désactiver, redéfinir ou être strictement limités
aux éléments d'interface focalisés.

Assurez-vous que le titre du site est compréhensible et descriptif. 2.4.2 A

Vérifier que les éléments du menu de navigation sont mis en évidence dans un 2.4.3 A
ordre logique

Assurez-vous que les liens sont clairs et compréhensibles même en dehors de leur 2.4.4 A
contexte

61
 Assurez-vous qu'il existe plus d'une façon de naviguer, telle que la carte du site 2.4.5 AA
ou le champ de recherche

Rédiger des en-têtes descriptifs et des étiquettes 2.4.6 AA

Assurez-vous que le texte des boutons et des commandes est conforme aux 2.5.3 A
étiquettes lisibles par machine

...

Compréhensible

Entrez la langue de la page dans le code 3.1.1 A

Entrez les changements de langue dans le code 3.1.2 AA

N'effectuez ou vérifiez qu’il ya aucune modification inattendue lors de la saisie 3.2.2 A

Être cohérent dans la navigation, la structure et la conception 3.2.3 AA

Créer des étiquettes de champ claires et cliquables 3.3.2 A

...

Robustesse

Assurez-vous que tous les composants d'interface ont un nom et un rôle pouvant 4.1.2 A
être déterminés automatiquement. Examinez attentivement ces éléments pour
rechercher des composants personnalisés, tels que ceux de la bibliothèque
JavaScript.

Assurez-vous que les appareils et accessoires fonctionnels peuvent présenter des 4.1.3 AA
messages non focalisés

...

Tableau 3 – Quelques critères WCAG 2.1 utilisés

Les résultats suivants ont été obtenus lors des tests d’accessibilité réalisé de manière sémi-automatique
avec l’outil « Total validator Basic ».

Nom du site Web Nivau A et AA

Nom de la page Total des Total des Erreurs et Erreurs et alertes

principale testée erreurs alertes alertes connues mais
trouvées trouvées connues et laissées
fixées par le volontairement
Web par le Web

62
 developpeur developpeur
almunimiageamiens.fr
Index (index.html) 7 2
(ce nom de domaine est
imaginé seulement. En
plus, il n’a pas été Annuaire des anciens 12 4
acheté et l’hébergement
de l’annuaire et de ses A propos de nous 8 6
différentes pages ou (ommig.html)
interfaces web créées
n’ont pas eu lieu) Blog (blogg-hem.html) 4 2

Contact (kontakt.html) 6 3

style.css 0 1
Les fichiers CSS testées
editor.css

Tableau 4 – Propositions Nombre de violations WCAG 2.1 après les tests automatiques de différentes pages ou
interfaces web créées

Figure 29 – Violations WCAG 2.1 trouvées sur la page d’accueil de notre annuaire en ligne avec Total validator.
Dans l’ensemble, une grande partie des violations WCAG observées et les différents autres problèmes
rencontrés lors des tests unitaires et d’utilisation ont été corrigés. Nous reprenons dans le tableau ci-dessus
les lignes de propositions faites sur comment resoudre quelques-unes de violations WCAG observées ou
obtenues après la série de tests d’accessibilité de différentes pages ou interfaces web créées.

63
Violation Réference Emplacement de l'élément Solution imaginée Violation Numéro de
critère de fixée réference de la
validation solution au
niveau de
TFS/ Git

W874 Ajouter un lien de [WCAG2 2.4.1 <!DOCTYPE html> Plusieurs alternatifs. Fournir un lien visible en haut de la Non. La Rien
navigation comme premier (A)] page, fournir un lien visible ailleurs sur la page, laisser
lien de la page comme tel
rendre le lien invisible, ou rendre le lien invisible jusqu'à
ce qu'il reçoive le focus du clavier

P871 Le texte du lien est
manquant.
[WCAG2 1.1.1 / <a href="http://localhost:52092/en/" Fournir un texte descriptif en tant que contenu de Non. La Rien
2.4.4 / 2.4.9 (A / title="MIAGE Amiens, Les Anciens"> l'élément <a> pour décrire le but de ce lien. Cette laisser
AAA)] description permet voire à l'utilisateur de distinguer ce comme tel
lien des autres liens de la page Web et aide l'utilisateur à
déterminer s'il doit le suivre ou pas.

E621 L'attribut « alt » de W3C pour <img Suivant la spéficification HTML en cours de validation, Non Rien
cette balise est manquant HTML 5 src="http://localhost:52092/globalassets l'attribut «alt » devrait être utilisé
/small_miage_amiens_lesanciens.png"/
>

E860 Lorsque vous utilisez [WCAG2 1.1.1 <img Ajouter une alternative texte pour permettre aux Non Rien
des images, spécifiez une (A)] src="http://localhost:52092/globalassets différentes technologies d'assistance ne peuvent pas
alternative textuelle courte /small_miage_amiens_lesanciens.png"/ identifier l'image ni en communiquer le but à l'utilisateur
avec l'attribut « alt » >

W860 Le texte « alt » est-il [WCAG2 1.1..1 <img Vérifier au niveau de l’interface EpiServer si le web Oui 27
délibérément vide (A)] src="http://localhost:52092/globalassets redacteur a omis de compléter ou renseigner cette
/startpage/amiensjumbo.jpg" "alt="" /> attribut.

64
P883 Imbriquer les en-têtes [WCAG2 1.3.1 <h3> Remplacer par <h1> et ajouter une classe à cette balise Non. La Rien
correctement (H1> H2> H3) (A)] pour pour appliquer la même taille de caractères (font- laisser
size) comme tel

E609 Cette balise ou contenu W3C pour <p> et <ul> L'un des suivants était attendu : <#pcdata> <a> <abbr> Non Rien
n'est pas autorisé ici. HTML 5 <area> <audio> <b> <bdi> <bdo> <br> <u> <var>
<video> <wbr>, etc.

P892 Utiliser CSS pour les [WCAG2 1.3.1 <ul> Utiliser CSS pour contrôler la mise en page et la Non. La Rien
effets de présentation (A)] présentation sur la page afin que les utilisateurs et leurs laisser
aides puissent la contrôler comme tel

Tableau 5 – Propositions de correction sur les différentes violations trouvées (Ici, sur la page d’accueil).

65
 Chapitre 4
Discussions et critiques

4.1 Par rapport à la réalisation de notre projet dans son ensemble

Le processus et/ou procédé de développement logiciel qui a été décidé et adopté par nous pour
pouvoir réaliser ce projet thématique associe les valeurs Scrum et les valeurs de l’UCD qui sont
reprises en partie dans le cadre théorique et pratique proposé par Garrett Jesse en 2011. C’est donc un
procédé de développement logiciel qui se présente désormais comme un procédé intégré ou unifié et
qui s’appuie à la fois sur la théorie et sur les bonnes pratiques existantes actuellement dans les
domaines du développement Web. En dehors d’associer les valeurs de Scrum et les valeurs de l’UCD,
il se sert aussi des recommandations fournies par Scott Isensee, Karel Vredenburg et Carol Righi en
2001, en rapport avec le développement logiciel centré utilisateurs qui utilise une approche intégrant
les histoires, les scénarios et les modèles pour pouvoir développer un produit-logiciel fiable,
fonctionnel et/ou convivial. D’ailleurs, l’approche proposée par Scott Isensee, Karel Vredenburg et
Carol Righi semble être devenue aujourd’hui l’approche la plus prisée des développeurs systèmes ou
web sans pour autant qu’elle soit déjà totalement constituée à un processus ad hoc.
Dans l’ensemble, les valeurs de procédés ou cadres agiles associés ici et les quelques
recommandations d’intégration utilisées ont également suivies de manière globale les groupes de
processus inspirés par la norme ISO/CEI 12207 qui n’impose pas en soi un modèle de cycle de vie
spécifique, ni de procédé de développement particulier. Avec toutes ces valeurs de procédés ou cadres
agiles et les quelques recommandations d’intégration suivies et utilisées, nous avons au final réussi
notre projet et créé l’annuaire en ligne demandée par le sponsor du projet.
Nous faisons aussi noter que nous avons réalisé ce projet seul en simulant et/ou en alternant les
différentes tâches ou activités réalisées qui sont définies clairement dans le PDL. Il pourrait alors y
avoir des faiblesses observables. Toutefois, toutes les tâches ou activités réalisées dans le cadre de ce
projet ont été (re)structurées à l’intérieur des 3 sprints définis dans le PDL où chaque sprint a
bénéficié d’un Product Backlog, d’un Sprint Backlog et d’un Increment contenant les différentes users
stories et autres éléments liés définis et/ou fournis. La planification de ces trois sprints (cf. sprint
planning repris dans notre PDL) a été globale et non détaillée au début du projet du fait que certaines
users stories devraient évoluer ou être redéfinies clairement plus tard, et cela, en fonction de
l’évolution du projet mais aussi des feedbacks qui devraient être obtenus du product-owner ou des
utilisateurs finaux lors des premiers prototypes des pages web à fabriquer ensemble. Elle a donc été
revue à la fin du premier sprint et du second sprint, cette première planification, en tenant compte de
la notion de sprint review.
Lors de la réalisation de différentes tâches ou activités planifées au niveau de chaque sprint, nous
avons également repris les quelques lignes générales incontournables et attribuées à n’importe quelle
méthode qualitative ou quantitative, et cela, via des remue-méninges ou des auto-réflexions (cf.
questions complémentaires) qui nous ont permis d’analyser, mais aussi de comprendre et de raffiner
les principaux besoins exprimés par le client ou les users stories des utilisateurs sous forme des
exigences fonctionnelles normalisées (mise en valeur des users stories). En plus, via les critères de
priorité ayant servi pour le choix du CMS utilisé, la définition de la priorité de réalisation de différents
66
users stories a aussi été facilitée et l’analyse de contenus définitifs de l’annuaire par plutôt une sorte
de compréhension phénoménologique de différentes expériences des utilisateurs. Tous ces éléments
nous ont donc permis d’arriver à mieux cerner par exemple comment les utilisateurs ou internautes-
visiteurs d’un annuaire en ligne ou d’un site web pensent, agissent, consultent et/ou regroupent
mentalement les informations (contenu) qui sont ou doivent être mises à leur disposition et comment
ils les recherchent, etc. Cette compréhension phénoménologique a aussi guidé la construction ou la
réalisation des différents tests systèmes, unitaires, fonctionnelles, d’intégration, utilisateurs et
d’accessibilité.
Lors de la la construction ou conception de cet annuaire en ligne, nous avons aussi également passé en
revue l’architecture informationnelle et/ou la structure de son contenu informationnel, et cela, « ...
grâce aux prototypes fabriqués avec l’aide des papiers fonctionnels pour pouvoir éviter des nombreux
risques qui pouvaient causer de la frustration et/ou de la gêne entre les développeurs et les
utilisateurs une fois la version bêta rendue fontionnelle » (Morville Peter et Rosenfeld Louis, 2006,
cité par Mbuta Ikoko, 2011). Avec chaque prototype fabriqué, la politique communicationnelle
visuelle qui a été définie ensemble avec le client ou par les utilisateurs simulés a même permis par la
suite à l’équipe de développement d’organiser et de catégoriser correctement l’ensemble de données
ou contenus définitifs de l’annuaire en ligne construit, puis d’amener les utilisateurs simulés de
s’impliquer à fond et de ne pas quitter ou zapper les pages web qui étaient en création ou finalisées
lors des différentes activités de tests car c’étaient en effet leurs propres pages web imaginées
ensemble avec le Development Team. Les sites web de l’UPJV (https://www.u-picardie.fr/) et du
département informatique de l’UPJV (précisement celui de MIAGE d’Amiens, http://www.miage-
amiens.fr/index.php), mais aussi celui de la fédération nationale des étudiants et diplômés de MIAGE
(« MIAGE connection », https://www.miage.net/) ont également servi des sources d’inspiration lors
du design, du choix et de la rédaction du contenu de l’annuaire en ligne construit.
Tous ces éléments évoqués démontrent la place d’une collaboration étroite ou d’une bonne
communication qui a existé de manière imaginaire entre les différentes parties prenantes du projet
(nous, le client et les autres parties prenantes simulées) malgré l’écart causé par l’usage d’un seul
canal (communication par messagerie électronique avec le sponsor du projet). Mais, dans l’ensemble,
nous pensons donc globalement que l’annuaire en ligne construit, s’il venait à être réellement mis en
ligne, va ainsi bénéficier d’une attirance manifeste positive lors des différentes consultations par des
vrais utilisateurs ou internautes-visiteurs (nous le souhaitons réellement pour gain de compétitivité ou
d’avantage concurrentiel).
4.2 Par rapport au codage et aux différents tests réalisés
Les users stories ont été considérées dans notre procédé intégré ou unifié décidé et adopté comme
étant un modèle d’exigences extra-fonctionnelles de la construction de l’annuaire en ligne demandé. A
partir d’elles, mais aussi de l’implication réel des utilisateurs virtuels simulés dans nos différents rôles
alternés, l’étape d’analyse et celle de conception de ce produit-logiciel ont été donc facilitées, mais
aussi l’étape du codage. Listées alors en partie dans le tableau 1 de ce rapport technique, elles sont
plutôt reprises de manière claire et détaillée au niveau du MS TFM (Azure DevOps Server with git)
utilisé dans ce projet pour pouvoir stocker et gérer via le cloud Microsoft les différentes versions de
notre code source. Donc, tous les users stories renseignés dans le cadre de projet ont en quelque sorte
été le véritable point de départ pour le raffinement des besoins exprimés par le client avant le
démmarage effectif du projet en exigences fonctionnelles normalisées, mais aussi de notre code écrit
en C#, HTML, CSS et JavaScript/Jquery, puis des certaines autres bibliothèques logicielles
complémentaires utilisées pour amélioration de l’annuaire et les tests d’accessibilité web.
67
Le succès et la qualité de notre code y réposent totalement. En plus, notons aussi que certaines users
stories parents ont été ajoutées pendant les activités de tests utilisateurs et ont même permis de
qualifier ou valider l’itération suivante en fonction des différents amendements faits ou améliorations
souhaitées et décidées par rapport aux résultats de tests obtenus. D’autres ont été également ajoutées
comme des users stories fils ou comme de tâches (tasks) aux users stories déja existantes. Dans
l’ensemble, elles ont été toutes scénarisées en tenant alors compte du principal modèle d’exigences lié
élaboré et qui servit pour la série de tests systèmes mais aussi des unitaires, utilisateurs et
d’accessibilité. Quant aux différents résultats de tests utilisateurs ou de l’évaluation heuristique
obtenus, ils semblent globalement dépendre en premier vue de l’expérience des utilisateurs. Toutefois,
pour ne pas faire soulever des doutes sur leur crédibilité et objectivité, il a été aussi ajouté à cette série
des tests utilisateurs réalisés les tests d’accessibilité web que nous allons même présenter les grandes
lignes dans le point qui va suivre.
Et, comme il vient d’être dit dans le précédent paragraphe, mais aussi tel qu’il a été déjà constaté dans
les différentes illustrations ou présentation de quelques résultats obtenus, notre annuaire en ligne
construit a également bénéficié d’un codage en C# et HTML 5, avec l’application de feuilles de styles
en CSS 3 et 4 et certains contrôles et fonctions dynamiques grâce aux bouts de code écrit en
JavaScript/Jquery et/ou utilisant le Bootstrap. Lors de notre codage, nous avons même fait de sorte
que nous tournions autour du Web semantique pour enfin créer des pages ou des interfaces web
maintenables et évolutives, mais aussi pour pouvoir les contrôler par la suite de manière simple ou la
plus significative. A l’instar du C#, qui est connu comme un langage orienté objet de haut niveau et
fortement typé, il est démontré aussi que le HTML, le CSS, le Bootstrap et le Javascript/Jquery qui
ont été également utilisés dans cette solution comportent également des règles indiquant comment
écrire un code. Et, comme pour des langues naturelles, ils ont une grammaire et un vocabulaire à
suivre. Nous nous sommes servis également par moment du code C# écrit comme étant le principal
débogeur de notre solution côté back-end mais le navigateur Chrome a aussi été utilisé pour le
débogage (inspection) de la partie front-end ou de différentes pages ou interfaces web créées et
stylisées. Les autres navigateurs web, le cas par exemple de Safari, Firefox, Edge et Internet Explorer,
ont été utilisé occasionnellement pour s’assurer simplement que le rendu de quelques pages ou
interfaces web créées était identique avec l’affichage décidée au niveau du Chrome, car l’Internet
Explorer arrive parfois à deconner et demande des codes complémentaires.
D’un point de vue semantique, nous avons pris soin d’utiliser des noms significatifs au niveau des
différents classes et autres attributs HTML (identifiants, titre, content, src, alt, liens, placeholder,
required, etc.). Toutefois, certaines balises HTML sémantiques, génériques (conteneurs, sections,
divisions, classes, identificateurs, asides, meta tags, etc.), voire génériques (p, h, label, etc.), sont
restées vides sans être associées à des classes ou à d’autres attributs (alt, tag, time, id, etc.). D’autres
par contre ont utilisé directement les scripts Bootstrap configurés et personnalisés au niveau du C#
(back-end). Pour les feuilles de styles (CSS), nous avonségalement utilisés la notion de pixels et em
comme unité pour les différentes aspects typographiques appliqués. Les codages RVB ou
hexadécimaux ou encore les noms classiques de couleurs en anglais ont été aussi utilisés, ensemble
avec l’opacité sur quelques couleurs ou liens hypertextes selon un besoin précis. Les boîtes classiques
CSS, et leurs marges et mises en page de remplissage (margin, padding, border, background, width,
height, etc.), mais aussi les autres éléments CSS de positionnement (cas de position, avec les cinq
valeurs connues: static, relative, absolute, fixed et inherit, ou cas de float, avec les valeurs left, right,
etc.) et les mises en pages réactives ou Bootstrap (responsives avec des médias queries) ne sont pas
également restés aux oubliettes. Les mises en pages résponsives nous ont par exemple permis de ne
pas créer et gérer plusieurs pages de base dans notre annuaire en ligne pour différents appareils. Nous
68
n’avons donc pas trouvé opportun d’utiliser le préprocesseur LESS ou SAAS ici mais au besoin, il
pourra faire partie d’une nouvelle release de cet annuaire en ligne construit.
Les différentes pages ou interfaces web créées renferment donc de manière globale différents
contenus multimédias (à l’instar des textes, images et vidéos, mais aussi des liens d’adresses internes
et externes, etc.). Ces différents contenus multimédias ont été classés ou liés aux différentes balises
HTML semantiques utilisées. Les images insérées sur ces différentes pages ou interfaces web créées
ont été aussi traitées de manière brute avec le MS Paint .Net et sont soit au format .png ou au format
.jpg. D’autres sont tout simplement des icones issues du Font-Awesone (alternatif de glyphicons).
L’utilitaire de capture d’écran, le ScreenHunter 7 free, a été d’une grande utilité dans l’alignement
typographique de tous les contenus nultimédias utilisés. Il nous a aidé à vérifier l’alignement exact de
box d’images mais aussi ceux de différents textes au niveau de différentes pages ou interfaces web
créées. Ce sont donc des pages ou interfaces web qui ont bénéficié d’une bonne structuration et d’une
bonne organisation dans leur ensemble, et cela, au niveau de l’en-tête de page (header), du pied de
page (footer), du contenu de page (content) et de navigation de page (nav), etc. Il s’agit en effet d’une
structuration stable et durable qui est plate et hierarchique et qui met en valeur nos propres sentiments
et ceux des utilisateurs ou internautes-visiteurs cibles. Toutefois, elles n’ont pas réellement bénéficié
d’une optimisation trop avancée car notre projet était tout juste une activité pédagogique. Le bouton
« scroll up », souvent pris en charge par Jquery, pouvait aussi être utilisé pour permettre aux
internautes-utilisateurs de retourner en haut de chaque page. Toutefois, cette option a +été écartée car
le footer de l’annuaire dispose déjà des liens utiles et importantes.
Avec les différents choix typographiques faits, les différentes pages ou interfaces web créées et leur
contenu semblent donc désormais être élégants, mais aussi pertinents, digestes, intéressants et
mémorables. Ces différentes pages ou interfaces web créées reflétent donc désormais dans leur
ensemble la surprise, l’émotion, la personnalité et l’homogénéité liées à la dynamique et à la rigueur
qui existeraient également dans la personne de tout ancien étudiant diplômé MIAGE d’Amiens.
4.3 Par rapport à la vérification et à la validation finale de différentes pages ou
interfaces web créées et de leur contenu
1° Au regard de la loi sur la protection de données à caractère personnel (CNIL, Datainspektionen
et/ou GDPR)
Suivant quelques exceptions et/ou grâce au consentement de parties prenantes concernés, nous avons
été à mesure de traiter mais aussi de publier certaines données à caractère personnel et sensible sur les
différentes pages ou interfaces web créées de l’annuaire en ligne construit. D’autres contenus repris
dans l’annuaire en ligne construit sont des contenus ouverts. Vous remarquerez également au niveau
du formulaire général de « contact » la présence d’un checkbox demandant par exemple le
consentement de l’internaute-visiteur d’adhérer ou pas à la politique d’utilisation de données à
caractère personnel et sensible ou au GDPR, etc. Ils sont voire associés aux liens hypertextes
permettant aux mêmes internautes-visiteurs, qui veulent par exemple entrer en contact avec notre
réseau, de pouvoir lire l’intégralité de textes de notre politique en la matière et de l’accepter ou non.
Les cookies sont également utilisés au niveau de l’annuaire en ligne construit. Ici, un bouton placé sur
la page d’accueil indique à l’internaute-visiteur d’accepter ou pas cet usage s’il veut continuer à
consulter ou pousuivre sa navigation entre les différentes pages ou interfaces web créées de
l’annuaire.

69
Dans l’ensemble, tous ces différents éléments évoqués montrent comment nous avons pris le soin de
placer le propriétaire de l’annuaire en ligne contruit, c.à.d. le réseau des anciens étudiants diplômés
MIAGE d’Amiens, sous la couverture de la loi.
2° En rapport aux directives WCAG 2.1.
Même avec l’implémentation de la fonction cookies sur la page d’accueil de l’annuaire construit et de
la conformité GDPR au niveau du formulaire de contact (page contact), etc., la validation de
différentes pages ou interfaces web créées s’avèrent aussi également nécessiares. Pour ce faire, nous
avons par exemple fait valider toutes les différentes pages ou interfaces web créées de manière sémi-
automatiquement, avec l’aide de l’outil « Total Validator », pour les faire conformer aux directives
d’accessibilité web, et cela, même si nous ne comptons pas réellement rendre ces pages ou interfaces
web créées accessibles ou disponibles en ligne ou à un large public pour l’instant. Moins non plus,
nous n’avons pas besoin d’obtenir à l’immédiat des meilleurs résultats (ou de les faire classer plus
rapidement et en première position) dans Google et/ou dans d’autres moteurs de recherche pour ces
différentes pages ou interfaces web créées, c.à.d. des résultats dans la gamme croissante de différents
robots ou programmes effectuant des recherches sur le Web pour le compte des organisations ou
entreprises (recherche et indexation). D’ailleurs, c’est alors dans ce cadre que la vérification et la
validation, comme un autre aspect de tests, de l’ensemble de l’annuaire en ligne construit n’a pas
produit un document d’acceptation par les utilisateurs (UAT : Users Acceptance Tests). Cette
faiblesse volontaire a été souhaitée ou décidée par nous car les outils GTM ou Google Analytics n’ont
pas été par exemple implémentés et/ou intégrés dans cette première version de l’annuaire en ligne
mais aussi parce qu’avec les rôles alternés joués par nous lors de ce projet faisait de nous à la fois juge
et partie. Toutefois, ils pourront faire l’objet d’une implémentation future si le réseau d’anciens
étudiants diplômés MIAGE d’Amiens décide un jour de publier sur Internet ou de mettre en
production cet annuaire en ligne construit et de poursuivre son développement professionnel et/ou son
amélioraion continue. Lors de cette future implémentation, nous allons alors essayer de nous appuyer
sur des users stories et autres exigences fonctionnelles normalisees pour produit un document UAT en
bonne et du forme, mais aussi implémenter par exemple le GTM ou le Google Analytics, etc. au sein
de l’annuaire en ligne construit pour connaître davantage les groupes cibles de notre réseau sur le
Web, et cela, grâce aux analyses statistiques qui seront faites puis de rassembler des informations
importantes capturées pour une amélioration continue de l’expérience utilisateur, etc.
En plus, les résultats de violations observées ou obtenues sur les différentes pages ou interfaces web
créées, après la série de tests d’accessibilité ou de disponibilité Web effectués avec « Total
validator », pourront également être traîtés dans leur ensemble de manière approfondie. Toutefois,
nous devons noter que les critères WCAG ont été aussi pris en compte lors de la conception de ces
différentes pages ou interfaces web créées et testées. Raison voire de la présence de différents
résultats de violations observées ou obtenues. Cette série de tests d’accessibilité ou de disponibilité
Web sémi-automatiques ont donc constitué en quelque sorte le prolongement de tests fonctionnels
réalisés par nous à la place des vrais utilisateurs lors des différentes itérations définies.

70
 Conclusion
« Tout ce qu’un homme est capable d’imaginer, d’autres hommes sont capables de le réaliser ».
C’est par cette phrase que la légende universelle a fini par prêter à Jules Verne que nous concluons
notre rapport technique.
En effet, c’est sur la base des principaux besoins exprimés par notre client, c.à.d. par le tuteur de ce
module thématique, et des exigences fonctionnelles et non fonctionnelles élaborées puis raffinées en
users stories pour un codage facile et claire que nous sommes parvenus à construire, créer et/ou
fabriquer l’annuaire en ligne qui nous a été demandé. Il s’agit tout simplement d’un annuaire en ligne
pour les anciens étudiants diplômés MIAGE d’Amiens (Université de Picardie Jules Verne ou UPJV
en sigle) et reprend donc leurs informations sur la filière académique suivie mais aussi leus profils
professionnels une fois une demande a été faite par le concerné et confirmée par l’administrateur de
l’annuaire. Tous les anciens étudiants diplômés MIAGE d’Amiens qui s’y trouvent ou dont les
informations sont publiés sont désormais membres du réseau ou de la communauté des anciens
étudiants diplômés MIAGE d’Amiens. Ils peuvent donc commencer à échanger sur certains sujets via
le blog implémenté mais aussi de rester digitalement en contact permanant entre eux et avec l’alma
mater. Des services ou activités de mentoring, des news, etc sont également disponibles ou offerts par
le réseau, sous forme d’évènements, avec l’aide de l’équipe de coordination.
Avec une analyse, une conception, un codage et des séries de tests réussis, en terme de structure, du
contenu et de l’esthétique implémentés sur cet annuaire en ligne construit, nous pensons qu’il y aura
davantage d’éxpériences utilisateur positives et profondes, notamment par les différents utilisateurs ou
internautes-visiteurs lors des consultations de différentes pages ou interfaces web créées.
Dans l’ensemble, c’est un projet thématique sur le développement logiciel ou web qui a réussi et qui a
aussi respecté la logique itérative ou agile Scrum et la logique centré utilisateur (UCD) que nous
avons souhaité intégrer et/ou utiliser ensemble. Il a donc bénéficié de la mise en oeuvre d’un procédé
théorique et pratique intégré ou unifié lite sans trop des contraintes. La facilité voire de la mise en
oeuvre de ce procédé constitue notre réponse au pourquoi la majorité des programmeurs web,
impliqués dans des projets de développement web actuels, préfèrent travailler suivant une approche
intégrant et/ou unifiant au moins deux ou plusieurs procédés connus du génie logiciel. En effet, c’est
pour s’adapter et arriver à couvrir les faiblesses présentées de part et d’autre par tous ces différents
procédés de développement logiciels, qu’il s’agisse des procédés agiles tout comme des procédés
prédictifs.
En plus, les lois et/ou réglèments européens en rapport avec la protection de données à caractère
personnel et l’accessibilité web ont été respectés mais peut-être pas dans son entierété. La petite
faiblesse, par exemple observée sur l’accessibilité WCAG 2.1., montre que même si nous devrions
travailler dans une logique de respect de différents critères liés, il serait parfois toujours difficile
d’aboutir à une violation nulle sans l’usage des outils de validation automatique ou sémi-
automatiques, le cas de Total validator. En travaillant par exemple sur cet aspect, j’ai pu comprendre
qu’il y a tellement d’alternatives à explorer. Donc, le sujet pourrait être encore davantage intéressant
et pouvoir être creusé davantage.
Pour finir, bien que l’annuaire en ligne est construit avec succès, nous pensons qu’il sera toujours
nécessaire de l’améliorer davantage ; surtout concernant l’aspect esthétique et accessibilité s’il devrait
un jour être mis en production. D’ailleurs, nous concernant, nous pensons que l’examination de la

71
structure de l’information et de l’esthétique d’un site et/ou d’une application web devrait devenir une
activité pas seulement importante mais aussi obligatoire avant sa mise en production. En plus, il nous
faudra continuer à faire un usage continue et pratique de la veille stratégique ou technologique dans
les deux domaines du web pour ainsi surveiller de façon permanente, proactive et ciblée
l’environnement global des internautes, mais aussi pour rester nous même à jour avec les technologies
web utilisées ou à utiliser dans le futur, et cela, à travers la littérature, des groupes d’intérêt actifs, des
plateformes de réseautage social en ligne, des forums de discussion ou blogs spécialisés, etc. Une
autre façon serait peut-être de rejoindre l’un des innombrables projets open source exécutés
aujourd’hui avec le soutien des firmes technologiques tells que Microsoft, Google, etc.

72
 Annexe A
Plan de développement de l’annuaire

73
 Annexe B
Code source de l’annuaire construit

74
 Bibliographie
Livre, monographie
[1] ANDREW Rachel, The CSS anthology, 101 essential tips, tricks & hacks Collingwood,
Australia: Sitepoint, 2007
[2] BARKER Deane, « Web Content Management. Systems, Features, and Best Practices »,
Publisher: O’Reilly Media, Inc., USA, 2016
[3] BENYON David, « Designing interactive systems : a comprehensive guide to HCI, UX
and interaction design », 3rd Edition, Pearson Education, Harlow, 2014
[4] BOHMAN Jan och HALLBERG Åke, Grafisk design: Det synliga språket, 1988
[5] CONSTANTINE Larry and LOCKWOOD Lucy, « Software for use: a practical guide to
the models and methods of usage-centered design », Addison-Wesley Professional, first
edition, 1999
[6] DUCKETT Jone, JAVASCRIPT & JQUERY interactive front-end Web development.
Publisher: John Wiley & Sons, Inc., USA, 2014
[7] EPISERVER CMS, Evaluator’s Guide
[8] GARRETT Jesse James, « The Elements of User Experience: User-Centered Design for
the Web and Beyond », Second Edition, New Riders, Indianapolis, IN, 2011.
[9] ISENSEE Scott, VREDENBURG Karel and RIGHI Carol, User-Centered Design: An
Integrated Approach, Prentice Hall, 2001.
[10] MBUTA IKOKO Dodi Alphonse, La mise en place d’un ERP (Enterprise Ressource
Planning) : CS/3 SAGE vu comme solution progicielle pour l’intégration des différents
systèmes d’information de la RVM (Régie des Voies Maritimes), Université Libre de
Kinshasa, Faculté des Sciences Economiques et Gestion, Département d’Informatique de
Gestion, Directeur Professeur IVINZA LEPAPA Alphonse Christian, Mémoire – Projet,
2003.
[11] NORMAN Donald A. and DRAPER Stephen W. (1986). « User Centered System Design.
New Perspectives on Human-computer Interaction ». CRC Press.
[12] POWELL Thomas A., HTML & CSS: The Complete Reference, Fifth Edition. McGraw-
Hill/Osborne, 2010.
[13] RIZCALLAH Marcel, Construire un annuaire d’entreprise avec LDAP. Applications intranet,
extranet et e-commerce, Collection Solutions Développeurs, Edition Eyrolles, Paris, 2000
[14] SOMMERVILLE Ian, « Software engineering », 8th edition, Pearson education, 2007
[15] SUNDSTRÖM Tommy, « Användbarhetsboken », Studentlitteratur, Lund, 2005
Rapport Technique ou document de travail
[16] MBUTA IKOKO Dodi Alphonse & MEKUATE DEFO Gisèle, « La création d’un Web
service : Note Reminder », activités pédagogiques n°2, Module D314, UFR des Sciences,
Université de Picardie Jules Verne, Amiens, France
75
[17] MBUTA IKOKO Dodi Alphonse et RIZWAN Shan, « Usages et rôles de l’Internet et du
datacenter dans une approche d’optimisation et/ou d’amelioration de la performance
organisationnelle d’une organisation. Cas du site Web et du centre de gestion de données
de l’UEPN-DDR, Working Paper, UEPN-DDR, MIS, 2010
Article d'un ouvrage collectif
[18] Directive (UE) 2016/2102 du Parlement Européen et du Conseil du 26 octobre 2016
relative à l'accessibilité des sites internet et des applications mobiles des organismes du
secteur public (Texte présentant de l’intérêt pour l’EEE), JO L 327 du 2.12.2016, p. 1–15.
[19] GULLIKSEN Jan, LANTZ Ann et BOIVIE Inger. (1998). User-Centred design in
practice - problems and possibilities. Workshop held at the PDC’98 and CSCW’98
conferences in Seattle. 14th of November, 1998. In proceedings of CSCW’98, 417
[20] KAUTZ Karlheinz, MADSEN Sabine & NORBEJERG Jacob, « Persistent problems and
practices in information systems development », Information Systems Journal, 17(3),
217-239. DOI: 10.1111/j.1365-2575.2007.00222.x
[21] PETTER Stacie Clark, DELONE William and McLEAN Ephraim, « Measuring information
systems success: Models, dimensions, measures, and interrelationships ». In: European
Journal of Information Systems. 2008; Vol. 17, No. 3. pp. 236-263
[22] Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la
protection des personnes physiques à l'égard du traitement des données à caractère personnel
et à la libre circulation de ces données, et abrogeant la directive 95/46/CE (règlement général
sur la protection des données) (Texte présentant de l’intérêt pour l'EEE), JO L 119 du
4.5.2016, p. 1–88
Documents web
[23] BARKER Deane, « Decoupled & Headless Content Management with Episerver », Episerver
Edition, Consulté en ligne le 17 mars 2019. Lien:
https://www.episerver.com/49a571/globalassets/episerver-headless-white-paper.pdf
[24] MURUGESAN San, DESHPANDE Yogesh, HANSEN Steve & GINIGE Athula, « Web
Engineering: a New Discipline for Development of Web-Based Systems », In: Murugesan S.,
Deshpande Y. (eds) Web Engineering. Lecture Notes in Computer Science, vol 2016.
Springer, Berlin, Heidelberg, 2001. Téléchargé le 17 avril 2019. Lien :
https://www.researchgate.net/publication/220795871_Web_Engineering_A_New_Discipline_
for_Development_of_Web-Based_Systems
[25] W3C: Web Content Accessibility Guidelines (WCAG) 2.0., juin 2009. Consulté en ligne le 09
mai 2019. Lien: https://www.w3.org/Translations/WCAG20-fr/
[26] W3C: Web Content Accessibility Guidelines (WCAG) 2.1., juin 2009. Consulté en ligne le 09
mai 2019. Lien: https://www.w3.org/TR/WCAG21/
[27] W3C: WCAG 2 FAQ (dernière mise à jour, 2018-06-22). Consulté en ligne le 13, le 14 et le
15 avril 2019. Lien: http://www.w3.org/WAI/WCAG20/wcag2faq/
[28] W3C: Web Accessibility Initiative (WAI). Consulté en ligne le 13 avril 2019. Lien :
https://www.w3.org/WAI/

76
[29] W3Schools. Consulté en ligne durant la periode de mai 2019. Lien :
https://www.w3schools.com/
[30] WEBBRIKTLINJER (Vägledningen för Webbutveckling), « Webbdirektivet - översikt ».
Consulté en ligne le 13 et le 15 avril 2019. Lien :
https://Webbriktlinjer.se/lagkrav/Webbdirektivet/

77