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

ii

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

iii

(CMS), GDPR, Directives ou accessibilité Web (WCAG) et Projet et processus de développement des

sites et/ou applications web CMS Episerver

iv

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

v

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

vi

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

vii

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

viii

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

1

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.

2

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

3

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

4

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.

5

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 ».

6

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.

7

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.

8

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 ».

9

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/ ».

10

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.

11

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.

12

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.

13

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.

14

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.

15

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.

16

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.

17

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).

18

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.

19

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

20

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).

21

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).

22

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é20

de 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).

23

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

24

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.

25

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.

26

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

27

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 ».

28

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é].

29

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).

30

é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.

31

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 ».

32

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é

33

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

34

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.

35

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

d’accessibilité WCAG

Total validator Basic 11.7.0

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

logicielles

Bootstrap 3.4.0 et Font-awesone 4.7.0 (en liens sur une page

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

36

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 ».

37

(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.

38

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

39

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/).

40

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 à

41

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.

42

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

43

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 ?

44

- 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

et non fonctionnelles

Source Priorité

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

Visual Studio 2019

Development Team

(développeur web)

1

Stratégie/Portée Installation et configuration de Episerver

(extension Visual studio), de Find et des autres

modules Episerver

Development Team

(développeur web)

1

Contenu En tant qu’un utilisateur, je souhaite lire des

informations pertinentes, digestes,

intéressantes et mémorables et et facilement

Product-owner

(Client/Utilisateurs)

2

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.

45

accessibles sur les différentes pages à

construire

Contenu En tant qu’un utilisateur, je souhaite lire des

informations sur le nom, compétence, parcours

et profession de chaque membre inscrit et

facilement accessibles sur les différentes pages

à construire

Product-owner

(Client/Utilisateurs)

2

Esthétique En tant qu’un utilisateur, je souhaite voir

maintenir une certaine équilibre et identité

visuelle sur le site lors de la navigation entre

les pages et/ou consultation

Product-owner

(Client/Utilisateurs)

2

Esthétique / structure En tant qu’un utilisateur, je souhaite voir

l’annuaire conserver un design simple,

compréhensible et élégant sur chaque appareil

utilisé

Product-owner

(Client/Utilisateurs)

2

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

stocker et de sécuriser toutes les données

Development Team

(développeur web)

2

Structure L’annuaire doit avoir des liens fonctionnels et

des éléments cliquables

Product-Owner

(client/utilisateurs)

Development Team

(développeur web)

1

Contenu L’annuaire doit mettre en évidence des champs

de recherche visible pour chercher et/ou filtrer

des informations images et une navigation

structurée et accessible

Product-owner

(Client/Utilisateurs)

et Development

Team (développeur

web)

1

Contenu En tant qu’un utilisateur, je souhaite voir sur

l’annuaire des images inspirantes

Product-owner

(Client/Utilisateurs)

et

1

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

informé sur le fil d’actualités (liens RSS) une

fois inscrit

Product-owner

(Client/Utilisateurs)

et

1

46

Contenu L’annuaire respecter les lois sur les données

personnelles et/ou sur le GDPR

Product-owner

(Client/Utilisateurs)

et Development

Team (développeur

web)

1

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

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é),

47

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 :

48

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.

Accueil

Annuaire des anciens

A propos de nous

...

...

Blog

...

...

Contact

49

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

50

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

51

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-

52

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.

53

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

54

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.

55

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.

56

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).

57

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)

58

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é

59

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.

60

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.

61

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

direction de l'écran.

1.3.4 AA

É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

de contraste suffisantes.

1.4.3 AA

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

lettres. Ceux-ci doivent pouvoir désactiver, redéfinir ou être strictement limités

aux éléments d'interface focalisés.

2.1.4 A

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

ordre logique

2.4.3 A

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

contexte

2.4.4 A

62

Assurez-vous qu'il existe plus d'une façon de naviguer, telle que la carte du site

ou le champ de recherche

2.4.5 AA

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

étiquettes lisibles par machine

2.5.3 A

...

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

être déterminés automatiquement. Examinez attentivement ces éléments pour

rechercher des composants personnalisés, tels que ceux de la bibliothèque

JavaScript.

4.1.2 A

Assurez-vous que les appareils et accessoires fonctionnels peuvent présenter des

messages non focalisés

4.1.3 AA

...

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

principale testée

Total des

erreurs

trouvées

Total des

alertes

trouvées

Erreurs et

alertes

connues et

fixées par le

Web

Erreurs et alertes

connues mais

laissées

volontairement

par le Web

63

almunimiageamiens.fr

(ce nom de domaine est

imaginé seulement. En

plus, il n’a pas été

acheté et l’hébergement

de l’annuaire et de ses

différentes pages ou

interfaces web créées

n’ont pas eu lieu)

developpeur developpeur

Index (index.html)

7 2

Annuaire des anciens 12 4

A propos de nous

(ommig.html)

8 6

Blog (blogg-hem.html) 4 2

Contact (kontakt.html) 6 3

Les fichiers CSS testées

style.css 0 1

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.

64

Violation Réference

critère de

validation

Emplacement de l'élément Solution imaginée Violation

fixée

Numéro de

réference de la

solution au

niveau de

TFS/ Git

W874 Ajouter un lien de

navigation comme premier

lien de la page

[WCAG2 2.4.1

(A)]

<!DOCTYPE html> Plusieurs alternatifs. Fournir un lien visible en haut de la

page, fournir un lien visible ailleurs sur la page,

rendre le lien invisible, ou rendre le lien invisible jusqu'à

ce qu'il reçoive le focus du clavier

Non. La

laisser

comme tel

Rien

P871 Le texte du lien est

manquant.

[WCAG2 1.1.1 /

2.4.4 / 2.4.9 (A /

AAA)]

<a href="http://localhost:52092/en/"

title="MIAGE Amiens, Les Anciens">

Fournir un texte descriptif en tant que contenu de

l'élément <a> pour décrire le but de ce lien. Cette

description permet voire à l'utilisateur de distinguer ce

lien des autres liens de la page Web et aide l'utilisateur à

déterminer s'il doit le suivre ou pas.

Non. La

laisser

comme tel

Rien

E621 L'attribut « alt » de

cette balise est manquant

W3C pour

HTML 5

<img

src="http://localhost:52092/globalassets

/small_miage_amiens_lesanciens.png"/

>

Suivant la spéficification HTML en cours de validation,

l'attribut «alt » devrait être utilisé

Non Rien

E860 Lorsque vous utilisez

des images, spécifiez une

alternative textuelle courte

avec l'attribut « alt »

[WCAG2 1.1.1

(A)]

<img

src="http://localhost:52092/globalassets

/small_miage_amiens_lesanciens.png"/

>

Ajouter une alternative texte pour permettre aux

différentes technologies d'assistance ne peuvent pas

identifier l'image ni en communiquer le but à l'utilisateur

Non Rien

W860 Le texte « alt » est-il

délibérément vide

[WCAG2 1.1..1

(A)]

<img

src="http://localhost:52092/globalassets

/startpage/amiensjumbo.jpg" "alt="" />

Vérifier au niveau de l’interface EpiServer si le web

redacteur a omis de compléter ou renseigner cette

attribut.

Oui 27

65

P883 Imbriquer les en-têtes

correctement (H1> H2> H3)

[WCAG2 1.3.1

(A)]

<h3> Remplacer par <h1> et ajouter une classe à cette balise

pour pour appliquer la même taille de caractères (font-

size)

Non. La

laisser

comme tel

Rien

E609 Cette balise ou contenu

n'est pas autorisé ici.

W3C pour

HTML 5

<p> et <ul> L'un des suivants était attendu : <#pcdata> <a> <abbr>

<area> <audio> <b> <bdi> <bdo> <br> <u> <var>

<video> <wbr>, etc.

Non Rien

P892 Utiliser CSS pour les

effets de présentation

[WCAG2 1.3.1

(A)]

<ul> Utiliser CSS pour contrôler la mise en page et la

présentation sur la page afin que les utilisateurs et leurs

aides puissent la contrôler

Non. La

laisser

comme tel

Rien

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

66

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

67

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.

68

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

69

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.

70

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.

71

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

72

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.

73

Annexe A

Plan de développement de l’annuaire

74

Annexe B

Code source de l’annuaire construit

75

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

76

[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/

77

[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/