Dodi_Mbuta_La création d'un web service : « Note Reminder » _ Dodi Mbuta

sur 54
Activités pratiques et collaboratives entre apprenants
La création d’un web service : « Note Reminder » (activité n°2)
MBUTA IKOKO Dodi Alphonse & MEKUATE DEFO Gisèle
Université de Picardie Jules Verne, Amiens, France
_________________
Résumé
Les web services sont définis dans la littérature TI comme étant des cadres d’architecture
(Architecture Framework) pour la conversation entre deux ordinateurs, 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), ils sont
plutôt à présenter comme étant des technologies C/S améliorées 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.
Actuellement, trois types de web services sont implémentes au sein des organisations ou
entreprises, à savoir le SOAP, le REST/RESTful et l’OData. Ils sont bâtis sur des cadres
d’architecture orientés services (SOA : Service-Oriented Architecture) et/ou à partir des
processus ou services métier bien définis. Décrits généralement sous le format
cryptographique XML, les trois types de web services cités peuvent posséder plusieurs
fonctions, ressources ou services, consommables par des applications informatiques clientes
natives, web et/ou hybrides, et peuvent également gérer la sécurité́, la fiabilité́ et la gestion de
tous les échanges ou partages d’informations entre les ordinateurs dans un réseau de
communication.
Dans le cadre du module de cours - Ingénierie des systèmes à base de services -, suivi à
l’UPJV, nous allons donc tenter de créer un web service RESTful, de nom de « W-S Note
Reminder », sous l’IDE Netbeans, et cela, avec l’aide du langage JAVA EE et du web API
JAX-RS. Ce dernier sera une architecture logicielle client-serveur qui devrait être capable
d’offrir des fonctions, ressources ou services CRUD (Create, Read, Update and Delete) et
celles d’authentification des utilisateurs.
En complément, une application cliente devrait être développée pour consommer les
différentes fonctions, ressources ou services CRUD à implémenter sur ledit web service à
créer. Notre choix est porté sur ce type des web services car il est considéré́ comme le plus
populaire et utilise le protocole mythique de transfert hypertexte, le HTTP, dans toute son
Université de Picardie Jules Verne
UFR des sciences
Module de cours : D314, Ingénierie des systèmes à
base de services
Tuteur du cours et superviseur des activités :
Durand David

sur 54
intégralité, notamment avec l’usage des URL significatives ou opaques et des méthodes tels
que le GET, le HEAD, le POST et le DELETE. La modélisation pour l’ensemble de notre
produit-logiciel à créer et/ou à développer sera réalisée en UML.
Mots clés : Web service, SOAP, REST, OData, JAVA, JAX-RS, XML, JSON, etc.
1 Introduction
1.1 Contexte du projet
Le monde actuel, dominé désormais par l’Internet et par tous les grands acteurs de l’industrie
des TI, les web services ont fini par s’imposer comme étant l’élément central de toute
architecture logicielle utilisée dans n’importe quelle organisation ou entreprise qui se veut 2.0.
La littérature TI parle de trois types de web services qui sont utilisés actuellement, à savoir le
SOAP, le REST/RESTful et l’OData. Dans leur forme la plus simple, tous ces web services
sont définis comme étant des cadres d’architecture (Architecture Framework) pour la
conversation entre deux ordinateurs, 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. L’une des choses la plus importante et qui fait voire leur force
actuelle est leur format de messagerie qui est généralement sous le format XML. Toutefois, en
dehors de XML, d’autres formats sont également utilisés par des développeurs web, le cas de
format JSON, ATOM ou RSS.
Dans le cadre du module de cours D314 - Ingénierie des systèmes à base de services1
-, suivi à
l’UPJV, nous allons tenter de créer un web service de nom de « W-S Note Reminder ». Ce
web service à créer sera une architecture logicielle client-serveur qui devrait être capable
d’offrir des fonctions, ressources ou services CRUD (Create, Read, Update and Delete) et
celles d’authentification des utilisateurs. C’est donc un système ou un produit-logiciel client-
serveur à fabriquer et qui, selon les exigences du tuteur du module de cours, devrait aussi
donner aux utilisateurs finaux la possibilité de créer leur profil et/ou de s’authentifier, mais
aussi de créer, d’ajouter, d’afficher, d’éditer, de réarranger et de supprimer une note.
Les utilisateurs pour lesquels nous allons fabriquer ce produit-logiciel passent pour des accros
aux applications informatiques natives, web ou hybrides existant actuellement sur le marché
des TI. Virtuels dans le cadre de activité ou projet de développement informatique, ils sont
donc considérés comme des parties prenantes. Selon les règles de l’art, ils représentent ainsi la
maîtrise d’œuvre (MOA).
Pour pouvoir répondre alors aux exigences et/ou spécifications2
, fournies par le tuteur de ce
module de cours, une étroite collaboration est recommandée entre les différentes parties
prenantes du projet même si le projet devrait logiquement être réalisé par deux ressources
représentant la maîtrise d’ouvrage (MOE).
1
En informatique, un service désigne l’ensemble des programmes œuvrant pour effectuer des traitements
particuliers, manipulant des types de données ou d’informations particulières et partageant un mode de
communication. Donc, il forme un ensemble des protocoles et/ou des formats de données et de dialogue mais
aussi de règles d’échanges qui constituent tous les éléments de la structuration de l’information. Toutefois, il faut
noter ici qu’un protocole n’est pas directement vu comme un programme informatique mais aussi comme une
sorte de cahier des charges pour un ensemble de programmes exécutables ou à faire exécuter.
2
Les exigences sont des propriétés qui sont exposées afin de pouvoir résoudre un problème dans le monde réel.
Elles peuvent être fonctionnelles ou non fonctionnelles (cf. SWEBOK : 2004, cité par Mbuta Ikoko, 2011). Dans
un projet informatique, pour qu’un produit-logiciel fabriqué soit considéré comme conforme aux exigences
définies ou élaborées par les différentes parties prenantes, il devrait alors répondre aux besoins exprimés
explicitement par le client et/ou l’utilisateur final (exigences métier) mais aussi aux besoins non exprimés
(implicites) qui sont techniques et essentiels puis pris en compte par le fournisseur pour pouvoir transformer
réellement les besoins exprimés en une solution (exigences produit).

sur 54
1.2 Objectifs du projet
L’objectif principal de notre projet, comme nous venons de le mentionner dans le précédent
point, est de pouvoir créer un web service. Ce dernier, par notre propre décision, sera de type
RESTful et devra donc être extensible, neutre et indépendant afin de pouvoir offrir à
n’importe quelle application cliente la possibilité de consommer sans difficultés les
différentes fonctions, ressources ou services qui devraient être implémentés ou offerts. Parmi
les fonctions, ressources ou services attendus, nous devrions donc nous focaliser davantage
sur ceux qui vont permettre à un utilisateur de pouvoir ajouter (créer), afficher, éditer
(modifier), réarranger et supprimer une note, c.à.d. de pouvoir effectuer les différents services
CRUD. Le langage de programmation JAVA et l’ensemble de son écosystème, imposés par le
tuteur du module de cours, devraient donc soutenir cette implémentation ou mise en œuvre.
Profitons également pour préciser que la modélisation, pour l’ensemble de notre produit-
logiciel à créer et/ou à développer, sera réalisée en UML afin de nous faciliter la tâche de
concevoir en parallèle une base de données flexible pour le côté Back-end (serveur) lors de la
mis en production. Le côté Front-end (client) du produit-logiciel ne devrait pas non plus
échapper à l’usage des langages à balises ou à scripts, tels que le HTML/XHTML, le CSS, le
Java Script et le Bootstrap ou Guid enfin de dégager enfin la beauté d’un design que nous
souhaitons interactif ou react mais aussi professionnel.
1.3 Contenu
La suite de ce document constitue le rapport technique de réalisation de notre projet. Il
comporte 5 principaux points. Hormis l’introduction (point 1), le point 2 est un rappel
théorique. Il va tenter de nous permettre d’avoir une compréhension ou une vue d’ensemble
du sujet abordé, et cela, avec l’aide des points essentiels se rapportant aux trois web services
possibles d’implémentation et aux projets informatiques de développement logiciel mixte. Ce
deuxième point va être suivi par un troisième point. Ce dernier va tenter à son tour de nous
présenter les différentes technologies ou outils qui vont être utilisés par l’équipe de projet
constituée pour pouvoir concevoir le produit-logiciel. C’est aussi dans de ce troisième point
que le choix de notre méthodologie de travail et celui de notre approche technique de
réalisation du projet vont être détaillées. Le planning de travail et les ressources affectées
pendant la réalisation ou le déroulement de ce projet vont également être indiqués. Il s’agit
d’un planning déjà défini dans un autre document du projet intitulé « PDL : Plan de
développement logiciel ».
Quant au point 4 de ce rapport technique, il va concerner les résultats et les discussions sur les
résultats obtenus. Les éléments d’entrée vont concerner la conception réalisée pour obtenir un
produit-logiciel opérationnel, optimisé et sécurisé. Ici, sous une logique présentant les
différentes lignes conceptuelles, nous allons insister sur les spécifications ou les exigences
fournies par le client. Ces dernières vont donc nous permettre de créer et/ou de décrire de
manière détaillée des diagrammes UML que nous allons jugés importants. Il s’agit donc tout
simplement d’un point qui va présenter principalement les différents processus de conception
ou de développement de notre produit-logiciel3
. Quelques images et lignes de codes vont
également être présentées au cours de ce point pour montrer de manière concrète les
différentes technologies et approche programmatique utilisées pour la dite conception.
Le point 5 va être la conclusion de ce rapport technique. Il va présenter, dans un premier
temps, une synthèse sur la discussion de résultats obtenus lors de la réalisation dudit produit-
3
Rappelons ici qu’un processus représente un « ensemble d’activités ou actions à effectuer par une ou plusieurs
personnes dans une organisation ou une entreprise dans le but de créer un produit (bien ou service) ou de la
valeur » (Mbuta Ikoko, 2003). Selon la norme ISO 10006 : 2003, un processus est coordonné et maîtrisé. Il peut
également être un processus de management, de réalisation, ou de support.

sur 54
logiciel mais aussi sur ceux du déroulement global de notre projet. En deuxième, nous allons
évoquer les quelques difficultés rencontrées et les perspectives futures relatives au produit-
logiciel réalisé ou créé.
2 Notions théoriques liées aux web services
2.1 L’Internet et ses différents protocoles ou services de base offerts
L’Internet regroupe aujourd’hui une multitude des réseaux de communication à l'échelle
mondiale mais aussi des outils, des applications et/ou des services TI aux caractéristiques très
variables. Devenu voire l’Internet des objets (Internet of things4
), par abus de vocabulaire et à
cause de l’extension de son nommage et des différents objets connectés5
se multipliant,
l’Internet est défini comme étant le « réseau des réseaux » ou l’ensemble de ressources
organisationnelles, technologiques, informationnelles ou multimédias rendues disponibles par
tous et auxquelles il est possible d’accéder via des infrastructures télématiques existantes. Il
est donc ce « service télématique grand public même si sa gouvernance et celle de tous les
autres outils, applications et/ou services TI qu’il fédère actuellement semblent être devenues
très complexes mais pas impossible » (Mbuta Ikoko, 2011). D’ailleurs, la difficulté
d’appréhender correctement ces deux types de gouvernance fait que ce service télématique
grand public, défini donc avec l’aide des applications informatiques natives, web ou hybrides
existant actuellement sur le marché des TI, soit également considéré comme étant un grand
réseau de communication ou une grande infrastructure technologique réellement ouverte,
neutre et indépendante.
Pour renforcer notre compréhension sur cette grande infrastructure technologique ou
télématique étendue et/ou ouverte, nous profitons de passer ci-dessous, de manière rapide et
synthèse, les différents services ou protocoles de base qui sont offerts ou fournis par sa base
technologique principale, à savoir le TCP/IP (lire davantage Pujolle Guy, 2002 ; Tanenbaum
Andrew, 2003 ; et Comer Douglas, 2006, cité par Mbuta Ikoko, 2007).
En effet, de manière fondamentale, nous avons deux niveaux de services ou protocoles de
base dans le réseau Internet : les services ou protocoles de niveau réseau et les services ou
protocoles de niveau application. Les services ou protocoles de base de niveau réseau sont
« responsables de la réception des datagrammes IP et de leur transmission sur un réseau
physique spécifique » (Comer Douglas, 2006, cité par Mbuta Ikoko, 2007). Ici, comme étant
lui-même un outil, application ou service télématique ou TI fédérant d’autres outils,
applications ou services TI pour utilisateurs professionnels, l’Internet fournit alors deux
grands types de services, à savoir (1) les services de transmission de paquets ou datagrammes
en mode sans connexion (connection less-UDP : User Datagramme Protocol) ou en mode
connexion (connexion oriented-TCP : Transmission Control Protocol), et (2) les services de
transport de flux fiable (suite à une possibilité d’interconnexion de machines ou objets
4
L’Internet des objets est la matérialisation du croisement entre l’informatique ubiquitaire et les objets connectés
ou produits intelligents. C’est tout simplement le réseau Internet qui est étendu au réseau des capteurs, c.à.d.
notre cyberespace qui est ainsi ouvert aux autres types d’outils, applications et services TI qui ne sont entre
autres que des produits intelligents ou objets connectés.
5
Les objets connectés sont définis comme « des objets électroniques connectés sans fil, partageant des
informations avec un ordinateur, une tablette ou un Smartphone, etc. et capables de percevoir, d'analyser et d'agir
selon les contextes et notre environnement » (http://www.usine-digitale.fr/objets-connectes/). Porter Michael et
Heppelmann James les appellent « des produits intelligents » et les définissent à leur tour comme « un
ensemble des systèmes complexes qui associent des équipements matériels, des capteurs, des stockages de
données, des microprocesseurs, des logiciels, avec d’innombrables possibilités de connectivité » (Porter Michael
et Heppelmann James, 2015, cité par Mbuta Ikoko, 2017). Pour eux, ces produits intelligents comprennent trois
séries d’éléments fondamentaux qui sont les composants physiques, les composants intelligents et les
composants de connectivité.

sur 54
intelligents). Les services de transport de flux fiable sont construits sur le niveau réseau avec
pour objectif de pouvoir l’enrichir. Ce niveau contient aussi quatre autres services ou
protocoles qui sont l’ARP (Adress Resolution Protocol), le RARP (Reverse Adress
Resolution Protocol), l’ICMP (Internet Control Message Protocol) et le RIP (Routing
Information Protocol). Ces quatre autres services ou protocoles sont associés à leur tour avec
d’autres protocoles de la pile TCP/IP pour pouvoir matérialiser les deux premiers services ou
protocoles que nous venons de citer (lire Pujolle Guy, 2002 ; Tanenbaum Andrew, 2003 ;
Lohier Stéphane et al, 2004 ; et Servin Claude, 2006, cité par Mbuta Ikoko, 2007). C’est donc
sur le niveau réseau que le protocole, nommé IP (Internet Protocol), offre les fonctions de
routage de paquets.
Quant au niveau application, il regroupe tous les services ou protocoles de base situés au-
dessus de la couche TCP et UDP du modèle TCP/IP. Ces services ou protocoles de base
proviennent presque tous du monde UNIX (lire Pujolle Guy, 2002 ; et Tanenbaum Andrew,
2003, cité par Mbuta Ikoko, 2007) et fonctionnent sous un modèle ou une logique
architecturale appelée C/S (client/serveur)6
. Le modèle C/S ont vu le jour vers la moitié des
années 1980. Leur avènement « se situait plus dans la phase de besoins de centralisation
(information cohérente, non redondante et accessible) et de décentralisation (conserver la
puissance et l’interface des micros - ordinateurs) des entreprises » (Ivinza Lepapa, 1997).
C’est un modèle d’architecture qui compose librement des services ou opérations génériques,
tels que le CRUD (Create-Read-Update-Delete), l’ETL (Extract-Transform-Load), ou l’EAI
(Enterprise Application Integration), en y ajoutant un nouvel organe qui est la bibliothèque de
ces différents services puis un éditeur correspondant qui permet la gestion de ladite
bibliothèque (lire Printz Jacques, 2012). Il permet une bonne communication ou une bonne
transmission de données avec l’aide des requêtes ou routines de base, c.à.d. avec l’aide des
appels de procédures distants (RPC : Remote Procedure Call) et/ou de procédures XDR
(eXternal Data Representation) qui répartissent à leur tour des données transmises entre les
postes clients et les postes serveurs et, accompagnent les différents services à exécuter. Il y a
même aujourd’hui une variante optimisée de ce modèle ou logique d’architecture C/S qui
existe sous une logique orientée service, appelée SOA (Service-oriented architecture). La
SOA renseigne tout simplement qu’un système informatique réparti est organisé comme une
structure de services de communication. Son but est de pouvoir répondre aux exigences
métier de ce système et, plus que d’autres technologies, l’une de ses forces ce qu’elle
encourage également la réutilisation des services implémentés. Elle représente donc aucune
exigence ou restriction des autres technologies et permet voire de créer en plus un service de
communication entre un poste client et un poste serveur dans n’importe quel langage de
programmation, avec des routines ou des normes telles que celles de RPC, CORBA (Common
Object Request Broker Architecture), XML (eXtensible Markup Language), OLE/DCOM
(Object Linking & Embedding/ Distributed Component Object Model), etc. Souvent associée
à des services web ou web services basés sur le SOAP (Simple Object Access Protocol), mais
pas uniquement limitée à eux, il faut noter que la SOA reste différente d’un web ou des
services du web même si ce dernier est la manière privilégiée pour réaliser une SOA. Gall
Nick (2014, cité dans l’encyclopédie Wikipédia, 2017) mentionne que la déclinaison des
SOA, telle qu’observée aujourd’hui au profit des services entièrement dédiés au web, est
connu sous le nom de WOA (Web Oriented Architecture) et définie sous la formule
mathématique : « WOA = SOA + WWW + REST ». Nous allons comprendre davantage cette
différence dans les sections qui vont suivre.
6
Dans la pratique, la maîtrise des systèmes architecturaux C/S passe plus par la compréhension des SGBD, des
middlewares, des objets et des interfaces graphiques.

sur 54
En parlant du web7
, disons tout simplement qu’il est un service ou un protocole Internet de
base au niveau de la couche application. Il s’occupe donc de la navigation entre les pages,
comme c’est fut le cas avec le GOPHER, et s’exécute en mode hypertexte non crypté -
HTTP : HyperText Transfert Protocol - ou en mode hypertexte crypté – HTTPS : HyperText
Transfert Protocol Secure -). Parmi les autres services ou protocoles Internet de base de
niveau application, nous avons aussi 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 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).
La maîtrise de tous ces différents services ou protocoles de base que nous venons de citer
constitue donc une des premières étapes pour la compréhension de l’univers Internet mais
aussi l’une des étapes importantes avant de pouvoir se lancer dans la création ou dans
l’implémentation d’un web service. Mais c’est quoi donc un service web, ou « web service »
en anglais, la section suivante va donc tenter de nous répondre.
2.2 Les web services
a) Définitions et autres éléments de base associés
Les web services pilotent aujourd’hui toute la communication sur l’Internet. Ils sont au cœur
des toutes les applications informatiques modernes et sont également comptés « parmi les
services ou protocoles les plus importants de la couche application de l’Internet »
(Tanenbaum Andrew, 2003). Agrebi Meriem et Chandon Jean-Louis (2009, cité par Mbuta
Ikoko, 2017), qui citent Eighmey John (1997) et Kumar Nanda et Benbasat Izak (2002),
parlent d’un « média le plus riche, pouvant intégrer du texte, des images, de l’audio et de la
vidéo ». En s’appuyant sur Printz Jacques (2012), qui parle à son tour de la conception et du
développement des applications informatiques modernes simples, sûres et adaptables par des
architectes, des décideurs DSI, des maîtres d’ouvrage et des chefs de projets, nous pouvons
également faire noter que les web service sont tout simplement « l’élément central de toute
architecture logicielle moderne » (Printz Jacques, 2012). En ce terme, ils disposent ainsi des
normes ou protocoles d’utilisation très stricts qui sont voire, dans la plupart de cas,
documentées pour le compte des développeurs web.
7
Le WWW : World Wide Web, appelé aussi « protocole ou service web », est un tout simplement 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 web 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). « Ces pages web reliés
disposent des noms uniques qui sont identifiables entre elles et leurs différents liens permettent alors de localiser
universellement toutes les ressources disponibles du web. Ils sont composés de trois parties qui sont le nom du
protocole HTTP (http://), le nom DNS de la machine où la page web devrait être hébergée (www.zaire.zr) et le
nom du fichier contenant la page (/presentation.html) et qui se trouve souvent dans un répertoire donné (accueil
par exemple). Les trois parties citées donnent donc lieu à un lien dit de type hypertexte
: http://www.zaire.zr/accueil/presentation.html. D’où le nom connu de lien hypertexte » (Mbuta Ikoko, 2001).

sur 54
Historiquement, nous pouvons préciser que les web services ne sont pas un concept nouveau.
D’ailleurs, dautres tentatives de réalisation d’un cadre d’architecture8
ont même existé bien
avant l’avènement d’Internet et de Web services. Déjà vers la moitié des années 1960, certaines
applications informatiques étaient implémentées avec des architectures similaires aux web
services et tournaient sur des serveurs physiques dits « mutualisés » (en miroirs ou en clustering)
ou « dédiés virtuels » (info gérés) qui « contiennent des données et fournissent des services
d’acquisition, de stockage, de traitement, d’échange et de diffusion des données » (Moreau René,
1987, cité par Mbuta Ikoko, 2003). Ces premiers cadres d’architectures similaires aux web
services étaient plutôt implémentées dans l’esprit de minimiser des risques qui étaient dus aux
pannes logicielles ou matérielles de l’époque. Quelques années plus tard, c.à.d. vers les années
1970 et 1980, les applications informatiques adoptèrent la technologie C/S et vont finir par faire
de son ensemble un cadre d’architecture alors disponible sur n’importe quelle application
informatique ou réseau de communication. L’essor des réseaux de communication ou des
applications informatiques dans les années 1990, le cas du réseau Internet, a donné une
importance sans précédent à cette technologie. Avec l’Internet rendu public, les web services ont
suivi et passent aujourd’hui pour l’amélioration continue de la technologie C/S.
Profitons de cette ligne synthèse historique pour dire aussi que l’une des premières véritables
implémentations notables du cadre d’architecture C/S amélioré, au style proche d’un web
service, fut celle qui était connue sous le nom de l’EDI ou du Web-EDI (Web - Electronic
Data Interchange). L’idée générale d’implémentation était ici la dématérialisation des
échanges de données entre entreprises. Avec le web-EDI, « les échanges ou communications
de données informatisées entre entreprises ou postes de travail sont traitées via des messages
ou des requêtes HTTP mais aussi parfois via des messages ou des requêtes SMTP » (Mbuta
Ikoko, 2001). Il s’agit donc de la même chose pour le web service aujourd’hui. Toutefois, le
format de ces messages ou de ces requêtes se différencie considérablement. Ceci veut
simplement dire que si vous êtes un architecte ou développeur logiciel et que vous souhaitez
utiliser du web-EDI ou du web service, vous devriez obligatoirement connaître le format de
messages à échanger et les normes ou spécifications qui les accompagnent, mais aussi
l’interface de programmation d’application utilisé (en anglais, API : Application
Programming Interface)9
et les principales actions, requêtes, verbes ou méthodes HTTP
associées, le cas par exemple des méthodes GET (demande de téléchargement de contenu
d’une page web), HEAD (récupération de l’en-tête d’une page web), POST (envoie des
informations d’une page web au serveur DNS pour traitement), PUT/PATCH (mise à jour de
la ressource) et DELETE (suppression de la ressource située sur l’URL spécifié). Cette
compréhension ou connaissance obligatoire de formats de messages à échanger, en rapport
8
Le cadre d’architecture dont il est question ici est à considérer en quelque sorte comme un sous cadre de celui
qui est souvent mis en place dans une entreprise. Celui de l’entreprise étant alors défini comme une composante
de sa stratégie informatique (pattern centralisé) au travers du cadre de présentation des technologies et des
processus d’entreprises mais aussi au travers de la productivité de cette présentation tout en impliquant la
sécurité face aux risques opérationnels et de conformité qu’ils conviendraient d’analyser les enjeux en termes de
communication, de coordination et de coopération en rapport avec les compétences des acteurs concernés. Il
s’agit aussi d’une spécification sur la façon d’organiser et de présenter par la suite l’architecture de l’ensemble
du système d’information ou informatique d’un organisme. Pour Morley Chantal (2012), cette spécification est
aujourd’hui employée dans la gouvernance tout projet système d’information.
9
Appelé web API dans notre contexte, l’interface de programmation d’application est donc vue ici comme un
langage utilisé pour communiquer avec un web service qui, comme un bibliothécaire, peut fournir à un poste
client via un navigateur web une collection des ressources dont dispose un serveur web, c.à.d. une bibliothèque.
Il s’agit au fait « d’un concept qui constitue aujourd’hui un des piliers de développement web, mais qui est
habituellement limité du côté d’une application cliente (y compris tous les Framework web utilisés). Il n’inclut
généralement pas les paramètres d’implémentation du serveur ou du navigateur web, tels que les SAPI ou les
API des moteurs de navigateur web, à moins qu'ils ne soient accessibles au public par un application web à
distance » (Wikipédia, 2017).

sur 54
avec le développement et le fonctionnement d’un web service, passe aujourd’hui pour une
compétence essentielle recommandée à tous les architectes ou développeurs web.
D’un point de vue pratique, c’est lors d’un échange ou d’une communication de données entre
postes de travail sur Internet qu’un web service et ses différentes ressources ou services
interviennent ou sont utilisés. Ici, le poste client concerné par cet échange devrait alors
envoyer une requête HTTP (au format HTML) et le serveur, qui reçoit cette requête, devra la
traiter et renvoie une réponse au poste client (voire figure 1).
Figure 1 – Requête entre un client et un server avec l’aide d’un (web) service
Les réponses renvoyées par le poste serveur ou par un web service au poste client
s’accompagnent toujours d’un code dit de retour ou d’état qui représente alors l’état dans
lequel se trouve le serveur et les ressources qu’il renferme. Le client peut utiliser ces codes
retour ou d’état pour identifier les réussites et les échecs d’échanges ou de communications,
puis répondre automatiquement aux étapes suivantes. Le RFC 7231 parlent donc de codes
retour à trois chiffres et les divisent même en 5 groupes ou séries : (1) la série 1XX : indique
qu’une RFC réponse comprend des informations ; (2) la série 2XX : indique que la demande
du client a été effectuée avec succès ; la série 3XX : indique également un succès mais le
client devrait effectuer en complément une action telle qu’une redirection vers une autre URI ;
la série 4XX : indique une erreur au niveau du client (la demande d’une page web qui n’existe
pas par exemple, etc.) ; et enfin la série 5XX : qui signifie que le serveur a rencontré une
erreur.
En plus, les deux postes concernés par l’échange évoqué ci-dessus peuvent aussi utiliser en
complément du JavaScript ou un autre langage de scripts pour traiter les différentes requêtes
et réponses HTTP. Dans ce cas, le client va ne plus recevoir seulement le contenu de la
réponse du serveur mais va aussi recevoir d’autres contenus connexes sous d’autres formats
en dehors du HTML, à savoir le format XML ou JSON, etc. L’illustration claire est souvent
celle d’un poste client qui demande des données logées sur un serveur SGBD (cf. principes
d’architecture C/S universel, dit « 3-tiers » ou à 3 strates ou couches10
par Gardarin Georges
et Gardarin Olivier, 1999). Donc, le web service à utiliser « ferait appel à une procédure
distante connue sous le nom de RPC. Il s’agit d’une norme ou procédure différente des
normes EDI traditionnelles, tels que EDIFACT, etc., et qui permet aux ordinateurs clients
d’appeler des fonctions ou des sous-routines, hébergées par des ordinateurs distants
(serveurs), en utilisant une syntaxe aussi similaire que possible au code qu’ils pourraient
utiliser localement. C’est une norme basée sur un environnement distribué (DCE : Distributed
Computer Environment) » (Mbuta Ikoko, 2001).
10
L’architecture trois tiers (« 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).

sur 54
Concernant le format de messages ou de requêtes évoqué ci-dessus, c’est le format XML qui
est le plus utilisé à ce jour. Ce dernier passe pour une grammaire universelle et c’est donc tout
simplement une évolution de HTML via le SGML (Standard Generalized Markup Language).
A la différence de HTML, les messages au format XML n’ont pas de tags prédéfinis. En plus,
nous devons faire noter ici que dans les premiers jours de web services, les données
structurées étaient renvoyées sous la forme d’un fichier XML simple utilisant un marquage
générique appelé POX (Plain Old XML). Ce format POX utilise des balises et des attributs de
la même manière que le HTML (Hypertext Markup Language) mais, selon les besoins, peut
aussi définir ses propres balises afin de pouvoir échanger des données vers et/ou à partir d’un
web service. Il est sensible à la casse et représente souvent des données dans différentes
zones (de stockage et filtrage de données, du web et du format de transport). Quant au format
XML actuel, les messages qu’il représente sont des données typées ou non typées qui peuvent
aussi être exportées, sérialisées, ou encryptées sous d’autres formats XML, dits
« particuliers », du genre POX (le cas d’ATOM), CSV (Comma-separated values), JSON
(JavaScript Object Notation) et RSS (Really Simple Syndication). Le RSS semble aujourd’hui
fédérer tous ces différents formats, à l’exception de ATOM qui souffre d’ambition à
compléter et/ou à remplacer totalement format RSS. Concernant le JSON, sa force se trouve
dans sa facilité d’être lu par un humain et d’être interprété par une machine. Il est
complètement indépendant des langages de programmation (C, C++, Perl, Python, Java, C#,
VB, JavaScript, etc.) mais utilise des conventions qui leur sont communes. Toutefois, dans un
web service, le stockage et le filtrage de données ou messages se font logiquement à travers
une base de données XML qui est juste un système logiciel permettant de stocker des données
au format XML. Cette base de données est souvent associée à une autre base de données
orientée document (document-oriented database, or document store), le NoSQL par exemple,
et, pour afin obtenir un document XML bien structuré pour et/ou dans un web service à partir
de cette association, on doit alors utiliser en complément un schéma XML ou un DTD
(Document Type Definition) et plusieurs autres modules optionnels, le cas de Xlink, de
Xpointer & Xfragments, de CSS (Cascading Style Sheets), de XSL (eXtensible Stylesheet
Language), de DOM (Document Object Modele), etc.
Pour conclure, disons que les web services sont issus de la technologie C/S qui est fondée à
son tour sur un des protocoles mythique de navigation entre les pages web, appelé le HTTP.
Ils sont actuellement implémentés en masse au sein des organisations en raison de
l’amélioration souhaitée sur la communication ou le digital. Pour Berners Lee et al. (RFC
1738, 1994), les pages web d’une application ou d’un site web, qui servent de navigation sur
le réseau Internet, sont accessibles et reliées les unes par rapport aux autres grâce aux
liens hypertextes. Elles sont donc nommées au moyen d’une URI (Universal Ressource
Identifier) ou URL (Universal Ressource Locator) et représentent au final des fichiers
hypermédias (voices, datas and images). Considérés aussi aujourd’hui comme l’un des
services clés et importants de cette technologie C/S, les web services passent également pour
une sorte des systèmes logiciels conçus pour supporter l’interopérabilité entre différentes
machines se trouvant sur un réseau de communication, à l’instar du réseau Internet. Mahmoud
Qusay et al. (2005, cité par Mbuta Ikoko, 2007) dit même que ces systèmes logiciels
représentent plutôt l’« implémentation d’une fonctionnalité commerciale bien définie, et les
différents web services à construire derrière cette implémentation sont consommés
aujourd’hui par des postes clients dans différentes applications ou processus métier ». Ils
permettent donc aux différentes applications informatiques de communiquer entre elles même
si elles sont implémentées sur des plates-formes ou avec des langages de programmation
différents. Leur but est désormais celui d’induire l’extensibilité et la neutralité mais aussi
l’indépendance entre les postes se trouvant dans une infrastructure technologique.

sur 54
b) Les web services phares et leurs différentes normes ou spécifications
Parmi les web services phares possibles d’implémentation actuellement au sein des
organisations, nous avons principalement le SOAP, le REST et l’OData. Ces trois web
services sont bâtis presque tous sur des cadres d’architectures orientés services (SOA). Ils
sont décrits en grande partie au format XML afin de pouvoir gérer correctement des processus
et des transactions, mais aussi la sécurité, la fiabilité et la gestion des échanges ou partages
d’informations dans un réseau de communication. Ils sont donc devenus des standards dans le
domaine du web. Ci-dessous, nous allons tenter de décrire de manière sommaire ces trois
standards phares du web actuellement.
- Le SOAP
Le SOAP est le tout premier web service connu du monde de l’Internet. Il a été développé et
opérationnalisé à la fin des années 1990. Il est tout simplement une série de spécification des
protocoles pour l’échange d’informations structurées entre différents systèmes distribués ou
décentralisés et éventuellement aussi hétérogènes. Il utilise le XML comme étant le format
des messages de demande et de réponse entre les clients et les serveurs. Comme spécification
de protocoles, il utilise et s’appuie aussi « sur d’autres protocoles de la couche application de
l’Internet, tels que le HTTP et le SMTP, pour une bonne extensibilité » (Tidwell Doug and
all., 2001 : traduction libre). Le SOAP définit donc quel format des messages XML utiliser
pour échanger des informations. Toutefois, à l’intérieur de ce format à utiliser, les
développeurs restent libres d’ajouter ce qu’ils veulent, le cas par exemple de l’inclusion des
pièces jointes binaires dans l’envoi d’un message de demande ou de réponse avec du MTOM
(Message Transmission Optimization Mechanism).
Pour rappel, à l’époque où le SOAP a été mis sur pied, la plupart des gens le connaissaient
alors comme le standard par défaut pour tout web service (lire Tidwell Doug and all., 2001).
Ivinza Lepapa (1997) a même évoqué que le SOAP était l’arrivée d’une norme de facto
robuste pour pouvoir enfin décrire correctement la manière d’intégrer des applications
informatiques en réseau, et dont l’architecture orientée services devrait en dépendre fortement
car son implémentation devrait viser la simplification de l’intégration tout en fournissant une
connectivité universelle aux systèmes et données existants. Actuellement, le SOAP et ses
différents protocoles ou spécifications implémentées11
, connues collectivement sous le nom
de normes WS (Web Services), sont toujours opérationnels et s’appliquent même désormais
aux autres types de web services. Ils passent donc pour ce standard rêvé et restent toujours
largement utilisés par certains professionnels du domaine. Toutefois, d’autres professionnels
le décrient en disant qu’il tente, ensemble avec ses protocoles ou spécifications, de générer
une course à la performance technologique.
Les protocoles ou les spécifications SOAP implémentées définissent normalement une
enveloppe (<SOAP envelope>) qui doit contenir le message à échanger. A l’intérieur de ladite
enveloppe, nous trouvons un en-tête (<header>) et un corps (<body>). Le corps inclut parfois
une section appelée « fault » (<fault>) et des sous-sections. Seul le corps <body> est
obligatoire. La section fault est uniquement utilisée pour les réponses lorsqu’une erreur
survient, non pour les demandes. Lors d’une demande ou appel d’un web service SOAP, le
corps (<body>) inclut généralement l’action à appeler sur le web service ainsi que tous les
11
Parmi les protocoles ou spécifications SOAP implémentées, nous pouvons citer le WS-star qui inclue le WS-
Policy, le WS-Addressing, le WS-Trust, le WS-Security, le WS-Transaction et d’autres. Fournis et gérés par
OASIS (acronyme Organization for the Advancement of Structured Information Standards), tous ces protocoles
SOAP, dérivés du WS-star, sont essentiels pour fournir des fonctionnalités d’entreprises aux web services. Ils
sont aujourd’hui indépendants de la plate-forme à utiliser ; ce qui signifie qu’un web service qui implémente du
WS-Transaction peut faire partie d’une transaction distribuée entre des systèmes hétérogènes. C’est le W3C qui
assure la mise à jour de la spécification de tous ces protocoles ou normes.

sur 54
arguments possibles. Via ses protocoles ou ses spécifications, le SOAP peut utiliser une
requête, souvent le POST ou le GEST, et soumettre l’enveloppe qui est définie en tant qu’une
charge utile pour une seule URL connue. Ici, l’infrastructure technologique liée dirigerait
alors cette demande vers une classe et vers une méthode basées sur un système C/S qui prend
en charge deux styles de communication réseau, à savoir le style RPC et le style d’échange
des messages ou des documents sous le format XML. Il y a également un style combinant le
XML et le RPC (XML-RPC). En raison de la nature neutre du format des messages ou
fichiers XML à échanger entre les différentes infrastructures ou plates-formes technologiques
ou encore entre les différents OS utilisés, les protocoles ou les spécifications SOAP peut aussi
s’associer avec un fichier d’échanges de messages qui a un format XML dérivé. C’est le
fichier WSDL (Web Services Definition Language) ou l’UDDI (Universal Description,
Discovery and Integration). Le fichier WSDL est utilisé dans SOAP pour exprimer les
services disponibles. Dans un environnement de développement donné (IDE : Integrated
Development Environement), le cas de Visual Studio de Microsoft ou de Netbeans de Sun
Microsystems, le fichier WSDL peut arriver donc automatiquement à générer des proxys de
code à personnaliser et qui devraient également aider par la suite un web service SOAP en
implémentation de pouvoir interagir par la suite avec une application cliente Par contre, le
fichier UDDI, c’est pour répertorier les services disponibles. Il existe également un autre
format XML dérivé en dehors du WSDL et de l’UDDI. C’est le fichier WADL (Web
Application Description Language). Ce dernier est souvent moins exploité par les
développeurs web mais sa description et/ou son implémentation aide à faciliter une
consommation automatique des différents services ou ressources à offrir par un web service
type.
Pour terminer, disons globalement que le web service SOAP met aujourd’hui à la disposition
des développeurs ou architectes web un fichier WSDL à l’intérieur du quel sont décrits, sous
un format XML, les détails de l’ensemble des différents services à utiliser indépendamment
de la plateforme, c.à.d. qui décrit le nom de chaque méthode d’action, les paramètres et les
valeurs de retour de chacun de services mais aussi les erreurs prévisibles. Le fichier est
relativement facile à comprendre mais parfois difficile à écrire.
- Le REST (Representational State Transfer)
Le REST est un autre standard web devenu aujourd’hui plus populaire que le SOAP. Il s’est
imposé dans le monde du web par le fait qu’il est une alternative facile d’implémentation
surtout pour le développement des applications clientes devant consommer au final un service
ou une ressource du web service créé ou implémenté.
A proprement parler, le REST ou RESTful n’est pas forcement un standard ou protocole mais
plutôt un style d’architecture logicielle (référence à la combinaison XML-RPC du SOAP) ou
tout simplement un ensemble des bonnes pratiques à respecter qui peut alors être utilisé avec
des nombreux formats de messages ou de requêtes. C’est donc un format de message
particulier pour tout web service c.à.d. une autre forme d’architecture multicouche orientée
service mais moins restrictif que le standard SOAP. Il aide donc au transfert d’état de
représentation des web services grâce aux messages, requêtes ou protocoles HTTP. Comme le
SOAP, il n’est pas du tout nouveau. Il a été initialement défini en 2000 par Roy Fielding dans
sa thèse de doctorat, avec 7 contraintes respectives (Client-Server architecture, de
Statelessness, de Cacheability, de Layered system, de Code on demand et d’Uniform
interface). D’ailleurs, Roy Fielding est présenté aujourd’hui dans toutes les réunions IETF
comme parmi les personnes qui ont contribuées énormément au développement du protocole
HTTP. L’on doit aussi également faire noter ici que les messages, requêtes ou protocoles
utilisés par le REST/RESTful sont plus petites, plus concises et peuvent être très rapides que
celles utilisées par le SOAP. Ils ne contiennent pas autant d’informations ou métadonnées que

sur 54
les messages, requêtes ou protocoles SOAP et ne sont voire généralement pas validés par le
client avant leur envoi. En plus, contrairement à SOAP, dont le noyau est seulement un format
de messagerie XML spécifique, les messages, requêtes ou protocoles HTTP envoyées par un
web service de type RESTful peuvent être dans n’importe quel format, mais les plus souvent
ils sont sous format XML ou JSON.
De manière pratique, les principaux objectifs des web services REST ou RESTful se situent
beaucoup plus au niveau des ressources ou services à offrir qui incluent (1) l’évolutivité (un
système basé sur le REST devrait fonctionner correctement avec de nombreux clients et de
nombreuses transactions), (2) la généralité des interfaces (c.à.d. l’adaptabilité ou intégration à
tout processus métier) et (3) le déploiement indépendant des composants (l’interface
utilisateur du système basé REST devrait être situé du côté client et le stockage du côté
serveur). Ces principaux objectifs tiennent donc, dans leur ensemble, à l’essentiel de tout
système C/S hypermédia distribué qui démontre enfin comment « l’interopérabilité et
l’intégration des applications informatiques en réseaux sont devenues un des enjeux de plus
en plus importants lié à la recherche d’une nouvelle voie de performance pour les entreprises,
et cela, depuis le constant fait en 1987 par Solow Robert » (Mbuta Ikoko, 2003). D’ailleurs,
plusieurs études ont même déjà démontré comment les entreprises qui ont introduites les web
services dans leur cœur de métier gagnent aujourd’hui du temps et sont performantes de
différentes manières. Il pourrait s’agir tout simplement de la simplification de certaines
procédures administratives ou financières et/ou de la réutilisation des anciennes applications
de manière ouverte au lieu de créer de nouvelles, etc.
Avec le style d’architecture logicielle RESTful, les principales actions, méthodes ou verbes
HTTP (POST, GET, PUT/PATCH and DELETE) semblent être donc utilisés dans toute leur
intégralité, notamment avec l’usage des URL significatives ou non opaques. Parfois d’autres
méthodes sont également utilisées au premier coup, le cas de CONNECT, d’OPTION ou de
TRACE. Le serveur et les clients basés sur ce style d’architecture n’ont pas aussi besoin
d’utiliser le même système d’exploitation ou le même langage de programmation pour
communiquer car, la communication dépend désormais logiquement des autres composants
intermédiaires. Pour Grojean Pascal et al. (2011), les différentes conceptions logicielles et
matérielles actuelles, qui sont ainsi centrées sur les données ou sur les ressources
informationnelles à échanger, ont même pour finalité, en dehors de l’évolutivité offerte par le
web service REST, de maximiser aussi l’efficacité, le débit et la robustesse, c.à.d. « la
performance opérationnelle de n’importe quelle infrastructure technologique pour tout service
orienté architecture » (Grojean Pascal et al, 2011).
Comme nous venons de le dire ci-haut, le web service REST/RESTful permet donc aux postes
serveurs de recevoir des demandes de postes clients sous la forme d’une ou des URL
significatives ou non opaques. Il est donc une approche d’interopérabilité attractive
recommandée et voire la plus utilisée aujourd’hui par la majorité des développeurs pour aussi
construire des applications clientes natives, web ou hybrides. En ces termes, les postes clients
devraient alors former leurs demandes en fonction des spécifications du web service RESTful
implémenté et des paramètres de passage qui peuvent être interprétés de manière appropriée.
Ceci paraît très différent du web service SOAP où les requêtes entre les postes clients et les
postes serveurs sont toujours construites en tant que des documents ou des messages XML.
Pour le succès et la réussite optimale de son implémentation, Richardson Leonard (2008, cité
par Fowler Martin, 2010) propose un modèle de maturité à 4 niveaux (voir la figure ci-
dessous).

sur 54
Figure 2 - Modèle de maturité de Richardson (source : Fowler Martin, 2010).
Ce modèle de maturité permet aux développeurs web d’avoir un web API RESTful12
qui offre
la possibilité aux applications clientes natives, web ou hybrides et à leurs utilisateurs de
pouvoir consommer de façon neutre les différentes ressources à mettre à leur disposition par
le web service RESTful, mais aussi de pouvoir évaluer correctement la conception d’une
architecture logicielle qui doit produire ce type de web service spécifique, et cela, sous forme
des six contraintes de base énoncées par Fielding Roy. De manière descriptive, le niveau 0
(level 0) est caractérisé par les services qui ont un seul template ou URI13
et qui utilisent une
seule méthode ou verbe HTTP (généralement le POST). Cette URI s’apparente à un nom de
domaine ou à une adresse IP qu’on affecte à un ordinateur ou équipement connecté sur un
réseau Internet. « Le style combiné XML-RPC de SOAP et le Plain Old XML (POX) utilisent
aussi une méthode de conception presque similaire » (Webber Jim et al, 2010). Par contre, le
niveau 1 (level 1) emploie plusieurs URIs mais avec une seule méthode ou verbe HTTP. Les
services fournis par la seule méthode employée sur ce niveau exposent ainsi des nombreuses
ressources, tandis que les services de niveau 0 canalisent toutes les interactions attendues via
une seule et unique ressource. Quant au niveau 2 (level 2), il inclut les différentes fonctions
ou services CRUD. Ces différents fonctions ou services CRUD hébergent à leur tour de
nombreuses ressources adressables par un seul URI et prennent aussi en charge plusieurs
méthodes ou verbes HTTP sur chaque ressource ainsi exposée. D’ailleurs, l’implémentation
de différents services ou fonctions CRUD constitue alors l’objectif principal de notre projet
collaboratif comme nous l’avions déjà dit dans notre introduction. Enfin, le niveau 3 (level 3)
est le niveau le plus sensible de ce modèle de maturité. Il prend en charge la notion
d’hypermédia en tant que moteur de l’état d’application (HATEOAS : Hypermedia As the
Engine of Application State). Ici, « les représentations contiennent des liens URI vers d’autres
ressources susceptibles d’intéresser les consommateurs. Les services fournis conduisent les
consommateurs à travers une traînée de ressources, provoquant ainsi des transitions d’état
d’application » (Webber Jim et al, 2010). L’on doit alors savoir ici que les consommateurs ou
les applications clientes consommatrices de ce type de web service n’auront besoin d’aucune
connaissance préalable sur la façon d’interagir avec un serveur au-delà de la seule
compréhension générique de l’hypermédia.
12
WEBBER Jim et al. (2010) vont plus loin et disent également que la fourniture des réponses HTTP à un poste
client par un poste serveur, grâce au web service implémenté, est voire une partie essentielle du web API
RESTful. Et, ces réponses HTTP devraient correctement être formées et contenir des informations requises
suivant les formats standardisés ou définis par le RFC 7231, avec des codes retour à trois chiffres.
13
L’URI est la méthode la plus générique pour nommer et localiser une ressource web, ou une séquence
compacte des caractères qui, avec des moyens simples et extensibles, identifie une ressource web abstraite ou
physique. L’URL (Uniform Resource Locator) et l’URN (Uniform Resource Name) sont donc ses sous-
ensembles.

sur 54
- Le standard OData (Open Data Protocol)
OData est le troisième standard de la série. Il « permet la création et la consommation de
services des API RESTful sans avoir à se soucier des différentes approches pour définir les
en-têtes de requêtes et de réponses, les codes d’état, les méthodes HTTP, les conventions
d’URL, les types de média, les formats de charge utile, et les options de requêtes, etc. »
(http://www.odata.org, 2017). Ses spécifications « sont publiées sous Microsoft Open
Specification Promise (OSP), garantissant alors le format ouvert par l’absence de poursuites
basées sur les brevets logiciels » (Wikipédia, 2017). Actuellement, il passe pour la
combinaison des deux premiers standards que nous venons de présenter, c.à.d. le protocole
SOAP et l’architecture REST.
Dans sa conception d’origine, les requêtes ou les messages d’échange du web service OData
étaient formés directement avec les URIs ou templates à la place des requêtes ou messages au
format XML ou JSON. Dans sa forme actuelle, l’OData peut envoyer directement des
requêtes ou messages au format XML, qui s’avère aussi particulier que celui du RESTful, ou
au format JSON. Etant un peu plus spécifique que le RESTful, le format de message XML de
l’OData est dans la plupart de cas corrigé et ca devient tout simplement du format RSS ou
ATOM. Le CMS WordPress, qui dispose à ce jour de plusieurs plugins liés et qui est cher à
l’environnement Open source, passe donc pour un terrain pratique de ces différents jeux de
format OData par les développeurs web. Dans l’environnement propriétaire, l’ASP.NET Core
qui est toutefois un Framework web libre proposé par Microsoft et la communauté Open
source emboite aussi le pas. Il s’appuie souvent sur un CMS robuste et fiable développé par
l’entreprise suédoise EPi Server AB (https://www.episerver.se/).
c) Aspects sécurité de web services14
.
Les trois web services phares sont aujourd’hui standardisés et exempts des nombreuses
contraintes de plates-formes. Ils sont même considérés par tout le monde comme les
principaux cadres d’architecture existant pour la conversation entre deux ordinateurs, 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 des protocoles, des normes ou des
langages.
Toutefois, ces trois web services phares qui viennent d’être décrits sommairement, s’ils ne
sont pas sécurisés, peuvent alors faire l’objet d’une série d’attaques ensemble avec les
différents clients qui doivent consommer leurs ressources. Il s’agit par exemple des attaques
de type « man-in-the-middle ». En effet, les ressources ou les données que les web services
échangent peuvent être interceptées et/ou modifiées par une simple parodie au niveau de leurs
caches ARP (Address Resolution Protocol) ou tout simplement par une usurpation d’identité
des différents utilisateurs associés. Tanenbaum Andrew (2008) qui, en donnant l’exemple de
Eve qui utilisait par usurpation le device d’un réseau de communication pour rediriger le
trafic des plusieurs autres devices (ici ceux de Bob et Alice) vers son device, a même illustré
en clair ce type d’attaques. Il parle ainsi d’un possible sniffing ou récupération des mots de
passes sur des connexions HTTP sécurisées de type SSL (Secure Sockets Layer) ou TLS
(Transport Layer Security)15
. Chose donc possible car ce sont des cas qui sont rencontrés
14
La sécurité est vue ici comme une situation dans lequel le web service n’est exposé à aucun danger.
15
Les connexions HTTP sécurisés – HTTPS – sont souvent utilisées pour les transferts de paiement sur Internet
et pour les transferts sensibles au sein des entreprises, mais aussi pour la connexion et la gestion d’informations
privées, puis généralement pour protéger l’intégrité de l’utilisateur dans un réseau de communication. « Avec
HTTPS, la connexion ne devrait pas être interceptée par des tiers et l’utilisateur devrait être en mesure de croire
que le serveur Web est le même que ce qu’il prétend être. Il est également possible d’utiliser HTTPS pour

sur 54
aujourd’hui ; surtout si l’attaque est très bien faite avec l’aide d’outils tels que le Hping,
Ettercap, Dsniff, ou Aircrack-NG, etc.
Dans ces conditions, la sécurité de web services est très importante et fait aujourd’hui
référence à une attention particulière sur l’intégrité, la confidentialité et la disponibilité de
messages à échanger entre un poste client et un poste serveur mais aussi de leurs formats.
Hébergés naturellement au sein d’un serveur HTTP, il y a plusieurs solutions ou outils
logiciels qui sont mis aujourd’hui à la disposition des développeurs web ou administrateurs
réseaux afin de pouvoir se protéger ou protéger un web service implémenté des attaques types
cités ci-dessus. Il leur faut tout simplement bâtir une bonne politique sécuritaire pour le web
service à implémenter mais aussi pour l’ensemble du système d’information à mettre en place
qui devraient également utiliser des applications clientes consommatrices de ressources dudit
web service. Les développeurs web ou administrateurs réseaux doivent donc chercher à
s’assurer que les différents devices utilisés ou à utiliser dans leurs réseaux ont et/ou vont
obtenir et échanger par exemple des certificats numériques clients/serveurs (le cas de X.509,
CAcert, DigiCert, Comodo, Symantec/VeriSign, GlobalSign, etc.), des chiffrements (XML),
des signatures numériques16
, ou des clés API via des tiers de confiance : une sorte de logique
sécuritaire liée à la notion d’infrastructure à clés publiques : PKI et à celle de sa mise en
œuvre (lire davantage Diffie Whitfield et Hellman Martin, 1976 ; et Rivest Ronald, Shamir
Adi et Adleman Leonard, 1978). Ils doivent aussi chercher à mettre sur pied des mécanismes
efficaces de détection de tous les types d’attaques évoqués, et cela, via l’usage des sondes
IDS, IPS ou hybrides, l’usage des firewalls (par feu) OS sur les postes serveurs et clients,
l’écriture des scripts de protection et les mises à jour des systèmes. Par exemple, pour les
firewalls, à part ceux qui sont disponibles par défaut sur chaque type de systèmes
d’exploitation actuellement, il existe aussi des firewalls spécifiques, tels que Etherwall ou
Arpwatch, qui disposent d’un filtrage IP sûr pour tous les clients web ou mobiles et leur accès
à la WSDL. C’est le cas avec l’environnement ASP .Net de Microsoft. Ici, plusieurs web
services créés ou implémentés vont même plus loin car ils s’appuient et sont paramétrés sur la
politique sécuritaire interne (ASP Identity) ou sur celle des CMS qu’il intègre, nous citons par
exemple EpiServer qui tient alors compte des attaques spécifiques types et liées
(Authentication and autorisation, Injection projection, au Cross-site scripting (XSS), Cross-
site request forgery (CSRF), Security misconfiguration, Insecure cryptographic storage,
Failure to restrict URL access, Transport layer protection, Unvalidated redirects and forwards,
et Virus protection).
En dehors de ces éléments sécuritaires présentés, nous devons aussi nous rappeler que, par
défaut, un web service n’intègre pas des mécanismes contre le rejet. Donc, les développeurs
web ou administrateurs réseaux doivent pouvoir les intégrer, tels que ceux de protection
applicative et de protection système sur toutes ses fonctions ou services sensibles. Ainsi, avec
la spécification ou norme WS-Security, un web service a particulièrement la possibilité d’être
mieux sécurisé au niveau des messages à échanger et/ou du fichier WSDL mis à disposition.
vérifier l’identité de l’utilisateur, à condition que l’utilisateur possède le certificat approprié, mais cette option est
rarement utilisée » (Wikipédia, 2017).
16
Nous précisons ici qu’une signature numérique n’est pas une signature électronique standard mais plutôt une
signature électronique avancée. A la différence d’une signature électronique standard qui désigne tout procédé
électronique permettant de faire valoir l’acceptation d’un contrat ou d’un dossier en utilisant l’authentification à
un facteur (vérification de l’identité du signataire par e-mail, identifiants de réseaux sociaux, mots de passe, code
PIN de téléphone, etc.), une signature numérique utilise, si nécessaire, l’authentification à plusieurs facteurs, et
cela, pour renforcer davantage le niveau de sécurité déjà existant. Elle utilise enfin un identifiant numérique basé
sur un certificat pour authentifier l’identité du signataire. Cet identifiant est lié au document via un système de
cryptage et sa validation est assurée par des autorités de certification agréées ou des prestataires de services de
confiance. C’est le cas d’Adobe Sign aujourd’hui qui repose alors sur un procédé où le document final est
accompagné d’une piste d’audit.

sur 54
Il s’agit au fait d’une norme de sécurité qui définit les principales fonctions de protection
d’intégrité, de confidentialité et de disponibilité des messages à échanger et fournit en plus
des mécanismes de sécurité utilisant les protocoles cryptographiques du web classique17
aux
différentes attaques types évoqués ci-dessus. Cela, pour pouvoir associer des demandes de
sécurité aux messages à échanger et à leur trafic dans un format lisible par la machine.
D’ailleurs, le cryptage d’un message contenu dans un fichier WSDL, à échanger pour les
seuls utilisateurs autorisés, est fait avec l’aide de ces mécanismes de sécurité et/ou des
chiffrements XML. Les clés API WSS (chaînes arbitraires émises par des fournisseurs de
services web pour des développeurs afin qu’ils puissent les inclure dans leurs demandes de
service) et d’autres normes de sécurité web qui sont reprises dans le guide de référence
OWASP (2017) et dans le document de l’EC-Council (2010) sont aussi utilisées.
Pour terminer cette section, nous devons savoir que les protocoles, les normes ou les langages
qui soutiennent la création et la sécurisation de ces trois types de web services phares ou de
l’ensemble de web services sont à majorité du type SOAP. Dans le lot de protocoles, normes
ou langages évoqués, il faut aussi noter le OAuth et le OpenID. Le OAuth est aujourd’hui très
populaire car utilisé par plusieurs du web tels que Google, Amazon et PayPal. Ils sont donc
utilisés, tous ces protocoles, normes ou langages, pour aider les différentes applications
clientes natives, web ou hybrides construites autour de n’importe quel type de web services à
mieux s’améliorer et consommer des méthodes ou ressources mis à leur disposition. Enfin, il
existe également de nombreuses approches de sécurisation comme nous venons de les
présenter mais la chose la plus importante à retenir serait de toujours héberger son web
service sur un serveur HTTP qui prend en charge les différents enjeux cryptographiques.
2.3 Rappel sur le projet informatique de développement logiciel mixte
a) Définitions et types et modes d’approvisionnement de projets informatiques
Les projets informatiques construisent ou fabriquent des logiciels pour les organisations ou
entreprises. Ils sont souvent réalisés en interne ou à l’externe des entreprises, et cela, pour des
raisons de productivité ou performance organisationnelle mais aussi en fonction de la
disponibilité des acteurs TI compétents dans des entreprises. En ces termes, ils gèrent alors
toutes les ressources TI et tous les dispositifs de communication liés, puis soutiennent dans
l’ensemble « … l’évolution des systèmes d’information existants dans les organisations. Ils
font partie des projets systèmes d’information » (Morley Chantal, 2012).
De manière globale, il existe 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 de projets informatiques tournent la plupart de temps autour de cinq dimensions
fondamentales, qui sont : (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). Ces cinq dimensions sont
souvent rattachées à la gestion des difficultés techniques de conception et de réalisation des
logiciels souhaités par des clients. Toutefois, dans la pratique, elles sont aussi rattachées à la
gestion des difficultés de la mise en œuvre effective et/ou de l’exploitation et maintenance de
logiciels conçus et réalisés. Ici, même dans des conditions où un projet informatique type et
l’ensemble de son équipe doivent s’appuyer sur des architectures informatiques et/ou des
réseaux de communications sophistiqués et opérationnels du client ou existants sur le marché.
17
Les protocoles cryptographiques du web classique les plus connus sont le HTTPS de type SSL ou TLS, le
LDAP (Lightweight Directory Access Protocol) et l’Active Directory. Ils sont également utilisés par des
mécanismes de sécurité de contrôle d’accès, de gestion des sessions, de gestion des comptes, de gestion des
exceptions - Try/Catch -, et de gestion des entrées et audit dans un produit-logiciel.

sur 54
En plus, certaines propriétés de risques apparaissent également ; le cas, par exemple, de
gestion et sécurité des données (protection, confidentialité, intégrité, disponibilité, sûreté, …)
et de qualité des services offerts (disponibilité des services, pérennité, relation avec les
utilisateurs, …).
Pour pouvoir gérer les différentes difficultés évoquées, les acteurs TI de la maîtrise d’ouvrage
(MOA), c.à.d. de l’organisation TI partenaire ou tout simplement le fournisseur de services
TI, qui sont affectés au projet informatique de développement ou de maintenance logiciels
quelconque, vont alors devoir partager les responsabilités, mais aussi les risques et les
bénéfices éventuels du projet avec les acteurs TI et métiers de la maîtrise d’œuvre (MOE),
c.à.d. de l’organisation cliente. Cela, en plus de l’obligation des acteurs TI de la MOA de
transférer leurs expertises aux acteurs TI de la MOE. Parce que nous sortons déjà les lignes de
l’aspect partenariat ou fourniture de services TI au sein d’une entreprise, profitons pour faire
noter que la littérature TI parle de l’existence des quatre modes d’approvisionnement TI
possibles au sein d’une organisation ou entreprise. Il s’agit 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é (dans notre cas, la fabrication ou la fourniture d’un produit-logiciel à un client) (lire
davantage Mbuta Ikoko, 2011). Suivant ce contexte, nous pouvons en plus dire qu’un projet
informatique de développement logiciel mixte ne serait pas seulement une organisation
temporaire mais aussi un processus de modélisation unique et complexe. Cette organisation
temporaire ou ce processus de modélisation a donc une finalité ou un but à atteindre, - la
fabrication d’un produit-logiciel -, mais aussi des objectifs bien définis ou fixés à partir de
cette finalité ou but.
b) Organisation et moyens de pilotage opérationnel au sein d’un projet informatique de
développement logiciel mixte
Le projet informatique de développement logiciel est un processus de modélisation unique et
complexe. Si nous suivons Frederick Brooks (2001, cité par Mbuta Ikoko, 2011), qui a aussi
évoqué cet aspect des choses, nous pouvons dire en complément que ce type de projet paraît
également complexe d’un point de vue alors de pilotage et/ou de gestion (des coûts, des
délais, du temps, des ressources et des communications, etc.) mais également de fabrication
du produit-logiciel. Derrière ce point de vue, il comporte au fait « une part importante
d’incertitudes ou de risques liés et qui font suite aux particularités dues surtout au produit-
logiciel à fabriquer » (Frederick Brooks 2001, cité par Mbuta Ikoko, 2011).
Pour arriver à bien le gérer, il faut devoir tout d’abord établir et organiser une politique de
gestion adaptée mais aussi définir par la suite des objectifs à réaliser ou atteindre (cf. ISO/CEI
9000 : 2005). Dans le lot des objectifs à définir ou à fixer, il y a trois qui sont majeurs et qui
doivent coûte que coûte être atteints. Il s’agit des objectifs liés (1) au respect des exigences
exprimées ou élaborées par les parties prenantes, (2) au respect des coûts et (3) au respect des
délais. Ces objections ne sont souvent atteints qu’avec la volonté des différents acteurs
impliqués ou parties prenantes du projet et avec l’aide des différentes autres ressources ou
capacités organisationnelles mises à la disposition (humaines, financières, matérielles,
informationnelles, etc.).

sur 54
Quant à la politique de gestion, cette dernière fait simplement appel à la gouvernance des TI
pour pouvoir parvenir au but ou à la finalité du projet (souvent la fabrication ou la fourniture
d’un produit-logiciel). Il s’agit d’une politique qui est souvent reprise dans un document,
appelé « charte de projet informatique de développement logiciel mixte ». Ce dernier est
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 de 201218
, le contenu de cette charte ne peut être
défini en l’absence d’une certaine compréhension claire sur la manière qui sera planifiée,
organisée, dirigée (pilotage) et contrôlée les différentes ressources à affecter au projet pour
pouvoir atteindre le but et les différents objectifs définis.
Sur la base de toutes ces lignes reprises ci-dessus, un projet informatique de développement
logiciel mixte est souvent piloté en cogestion, c.à.d. entre les acteurs TI de la fonction système
d’information ou TI de l’organisation cliente ou entreprise commanditaire et les acteurs TI de
l’organisation partenaire ou entreprise sous-traitante. Ensemble, avec les bénéficiaires c.à.d.
les acteurs des autres fonctions ou unités d’affaires concernées de l’entreprise commanditaire,
appelés souvent « experts métier », les deux groupes clés d’acteurs (acteurs TI de la fonction
système d’information ou TI de l’organisation cliente et ceux de l’organisation partenaire)
doivent en pratique unir et harmoniser leurs efforts pour pouvoir atteindre le but défini ou les
objectifs fixés. Ils ne doivent donc pas se préoccuper seulement de la gestion des coûts, des
délais, du temps, des ressources et des communications, etc. mais aussi de la mise sur pied des
différents processus et procédés19
qui se rattachent alors ainsi au développement ou à la
fabrication du logiciel, c.à.d. ils doivent faire une sorte d’alignement stratégique du produit-
logiciel ou du système d’information à construire ou devant évoluer en continue pour se
conformer à la stratégie globale de l’organisation ou de l’entreprise commanditaire (lire
Henderson John et Venkatraman Natarajan, 1993, et Scott Morton, 1995, cité par Mbuta
Ikoko, 2009).
Ici, il est même recommandé au chef d’un tel projet de pouvoir alors disposer d’un bon profil
et d’adopter un bon style ou rôle de gestion pour le mener à bien ou sur une réussite ou
succès. Pour Vital Roy et al. (2007, cité par Mbuta Ikoko, 2009), se basant sur les travaux
d’Aaron Shenhar (2001), de Gottschalk Peter et Karlsen Jan (2005, qui utilisent 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 par le chef d’un projet informatique de
développement logiciel mixte peut être soit celui de producteur, de directeur, de
coordonnateur, ou de contrôleur. Cette série des styles ou des rôles de gestion à jouer par le
chef de projet fait même directement appel à un profil de type « leader transactionnel ». Le
18
Le PMBoK, Project Management Body of Knowledge, est un ensemble des bonnes pratiques ou un corpus de
connaissances publiée par le PMI (Project Management Institute) et mondialement reconnue dans le domaine de
management de projets. Il décrit 5 groupes de processus (initialisation, planification, exécution, suivi et contrôle,
et clôture) qui donnent une vision macroscopique de management ou de gestion de tout type des projets et qui,
par une représentation à deux dimensions, sont croisés avec 10 domaines de connaissances pour pouvoir gérer
correctement un projet. Ces 10 domaines de connaissances sont la gestion de l’intégration, la gestion de la
portée, la gestion du temps, la gestion des coûts, la gestion de la qualité, la gestion des ressources humaines, la
gestion de la communication, la gestion des risques, la gestion des achats, et la gestion des parties prenantes.
19
La norme NF X 50-125 (cité par Mbuta Ikoko, 2003), définit un procédé comme un ensemble des moyens et
des méthodes qui permettent d’accomplir une activité (tout en préservant leurs dépendances intrinsèques). Dans
le développement informatique, les procédés les plus connus sont les procédés prédictifs en V, en W, en Cascade
et en Spirale, et les procédés synthétiques ou agiles tels que le RUP : Rational Unified Process, le 2TUP : Two
Tracks Unified Process, le RAD : Rapid Application Development, le XP : eXtreme Programming, le Scrum,
etc. Suivant les recommandations fournies par le cabinet Gartner Inc., le procédé prédictif en V ne devrait
d’ailleurs plus être utilisé depuis 2012.

sur 54
chef de projet peut aussi avoir le profil de type « leader transformationnel ». Dans ce cas, la
série des styles ou rôles de gestion qu’il doit jouer ou adopter peut être soit celui d’un agent
de liaison, d’un innovateur, d’un mentor ou d’un facilitateur. Toutefois, si le chef de projet est
une ressource externe à l’organisation ou entreprise commanditaire, il devrait ajouter au
premier profil ou au second profil cité le style ou le rôle de gestion dit de « spokesman » sinon
alors celui de « resources allocator » s’il est une ressource interne à l’entreprise
commanditaire.
Au niveau de PMBoK, il est même également recommandé au chef d’un projet type 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 du management classique dont nous
avons déjà évoqué, à savoir la planification, l’organisation, la direction et le contrôle. C’est
donc un management qui, via la fonction « contrôle », devrait aider le chef de projet à mettre
par exemple sur pied une démarche qualité basée sur l’amélioration continue des exigences
élaborées20
et, au même moment et par principe d’unicité d’un projet, d’intégrer tous les
autres processus ou activités spécifiques à définir par transformation ou par déclinaison des
différents objectifs fixés. Pour planifier (définir ou élaborer), maîtriser, assurer et améliorer
par exemple continuellement les exigences élaborées dans le cadre d’un projet informatique
de développement logiciel mixte mais aussi les satisfaire, la démarche qualité ou agile est
donc recommandée à tout prix. C’est une démarche adoptée et utilisée actuellement par
plusieurs communautés TI à travers le monde. Elle constitue désormais le socle de
management de la qualité, appelé Système de Management de la Qualité (SMQ), « … qui 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é » (NF EN ISO 9000 : 2000).
C’est donc une démarche qui devrait donc aider un projet informatique de développement
logiciel type à gagner encore davantage en efficacité et en efficience et à accroître la
satisfaction de son sponsor ou de son client.
c) Les activités clés dans un projet informatique de développement logiciel mixte
Les activités se définissent en général comme un ensemble homogènes d’actions ou de
processus, concourant à un même objectif, et nécessitant les mêmes compétences, et analysant
les types de travaux et les responsabilités opérationnelles. En les décrivant, « on définit alors
le quoi faire » dans un contexte de créativité et de changement. Les activités représentent
également une manière d’élaborer des dispositifs pour conduire un projet basé « sur le
concept de contrôle et de régulation qui guide son fonctionnement et son évolution » (PMBoK
Guide, 2012).
Dans le cadre d’un projet informatique de développement logiciel mixte, l’ensemble des
activités à définir par les acteurs constitués se concentrent beaucoup plus sur l’analyse, la
conception, la programmation et les tests et installation. Il s’agit au fait d’une série d’activités
dites « techniques » et qui sont reprises dans tous les modèles de cycle de vie ou de
développement logiciel qui ne sont rien d’autre que des procédés énoncés du développement
20
En informatique, l’amélioration continue passe pour activité régulière ou agile qui permet, par la prévention
des erreurs, d’accroître la capacité à satisfaire des exigences définies ou élaborées. Toutefois, l’on doit avoir à
l’esprit que le mieux est l’ennemi du bien. Ainsi, il est toujours recommandé des actions ou des tâches maîtrisées
et bien définies dont la réalisation est fixée en fonction des contraintes de coût, de délai et/ou du temps et de
qualité. La qualité qui est vue, dans le cadre de développement logiciel, comme le but ou l’exigence ultime à
atteindre car elle se retrouve étroitement liée à la réalisation au point qu’il est même très difficile aujourd’hui de
partager distinctement les activités de développement de celles de qualité.

sur 54
informatique. Ces différentes activités techniques sont également associées aux autres types
d’activités dites « génériques » ou « de gestion », à savoir « l’initialisation, la planification,
l’exécution, le suivi et contrôle, et la clôture » (cf. Larsson Erik et Gray Clifford, 2011 ; et
PMBoK Guide, 2012). Ensemble, toutes ces activités forment donc les différentes phases
inter-reliées pour exécuter un projet informatique de développement logiciel mixte. Elles
comportent ainsi des dates de début et de fin (principe de temporalité de projet) et, par
principe de pluridisciplinarité de projet, sont alors réalisées ou exécutées pas seulement par le
groupe d’acteurs constitués (ressources humaines) mais également par la prise en compte des
autres ressources ou capacités organisationnelles (financières, matérielles, informationnelles,
etc.). Elles sont également en relation entre elles car non linéaires, et ces relations sont voire
mises en évidence pour permettre d’atteindre au final les objectifs fixés ou définis à partir du
but ou de la finalité même de projet. De manière générale, c’est le plan de développement
logiciel (PDL) qui décrit toutes ces activités, et cela, de façon la plus détaillée ou concrète
possible.
3 Méthode de travail et approche technique adoptée pour la réalisation de notre projet
de développement logiciel
3.1 Méthode de travail et planning de tâches à réaliser par les acteurs
Notre projet informatique de développement logiciel va dans une logique mixte (pour des
raisons pratique). Et, comme nous l’avions déjà signifié dans le PDL qui était produit avant le
démarrage de ce projet, deux ressources clés vont donc réaliser ce projet informatique de
développement logiciel mixte. Il s’agit en effet de Mme MEKUATE DEFO Gisèle et de M.
Mbuta Ikoko Dodi Alphonse. Ces deux ressources représentent la partie MOA de ce projet.
Et, pour le respect des règles d’art, le tuteur du module de cours qui est une ressource
virtuelle, représente automatiquement la partie MOE (cliente). Il représente aussi les
utilisateurs finaux.
Pour la mise en œuvre de notre projet, une séance préparatoire d’échange de points de vue a
eu lieu entre les deux ressources MOA via WhatsApp. Les conclusions de cette séance ont été
confirmées via un rapport mail (voir annexe). De cette séance, nous avons été donc amené à
produire notre PDL et à pouvoir partager des rôles et des responsabilités liés (tableau 1). Le
PDL produit nous a aussi fourni les grandes lignes et la méthodologie complète de cette
activité de développement, et cela, selon les différentes règles de l’art liées au développement
logiciel. Ci-dessous, les rôles et les responsabilités de notre projet tels qu’ils ont été définis
dans notre PDL.
Rôles et responsabilités Nom de l’acteur
Gestionnaire du projet Gisèle Mekuate
Analyste ou architecte de l’application Dodi Mbuta
Développeur du produit-logiciel Dodi Mbuta & Gisèle
Mekuate
Testeur du produit-logiciel Dodi Mbuta & Gisèle
Mekuate
Responsable de la documentation et du
déploiement du produit-logiciel
Dodi Mbuta & Gisèle
Mekuate
Responsable qualité du projet et du
produit-logiciel
Dodi Mbuta & Gisèle
Mekuate
Tableau 1 - Rôles et responsabilités des acteurs clés du projet
Nous faisons noter ici qu’il s’agit d’une organisation ou gestion collégiale car notre projet se
veut flexible, créatif et productif. Donc, les rôles et les responsabilités liés et repris ci-dessus

sur 54
sont alternés. Ils ont l’impression d’être figés dans notre tableau seulement pour le respect de
règles de l’art.
Nous rappelons aussi que lors de la production de notre PDL, le « backlog product » du web
service et de l’application cliente web à créer a été défini et validé par l’ensemble de
différentes parties prenantes de notre projet (MOE/MOA). Un planning de leur production a
été également établi. Ci-dessous, le tableau qui reprend les quelques lignes globales de ce
planning.
Activités / Tâches Période de réalisation
des activités / tâches
Durée de réalisation
des activités / tâches
Acteurs
responsables des
activités / tâches
Début Fin Durée Effort 2 ressources
SPRINT_0 : Démarrage et
planification du projet
Mars Mars 1.5 semaine N/A Alternance cyclique
hebdomadaire entre
acteurs
SPRINT_1 : Elaboration de
l’application et début de la
rédaction technique du rapport
Avril Avril 4 semaines N/A Alternance cyclique
hebdomadaire entre
acteurs
SPRINT_2 : Construction de
l’application et poursuite de la
rédaction technique du rapport
Avril Mai 6 semaines N/A Alternance cyclique
hebdomadaire
SPRINT_3 : Tests finaux
(Intégration, UAT, etc.),
correction du rapport
technique, rédaction du manuel
utilisateur et préparation de la
mise en exploitation définitive
de l’application
Mai Mai 1.5 semaine N/A Alternance cyclique
hebdomadaire
SPRINT_4 : Clôture du projet
et transmission au tuteur des
différentes ressources liées
produites
Mai juin 0.5 semaine N/A Alternance cyclique
hebdomadaire
Tableau 2 - Planning temporel des tâches ou activités
Avec cette portée globale du projet, couplant avec le PDL produit avant le démarrage réel du
projet, nous pensons donc être à mesure de pouvoir réaliser le produit-logiciel demandé. Les
lignes globales renseignées dans ce tableau sont basées ici sur une approche de
développement Agile, connue sous le nom de « Scaled Agile Framework », SAFe en abrégé21
,
et proposée ou créée par Leffingwell Dean. Concernant le temps calendaire, il est défini et
réajusté en tenant compte des différentes activités pratiques et collaboratives des autres
modules de cours suivis mais aussi de nos propres activités professionnelles car les deux
ressources clés du projet sont également des employés à temps plein.
Au fait, l’approche SAFe adoptée passe aujourd’hui pour un mélange des plusieurs forces et
valeurs que l’on retrouvait et que l’on retrouve encore dans la majorité des modèles ou
procédés prédictifs et/ou synthétiques connus de développement logiciel, le cas de V, RUP,
2TUP, RAD ou Scrum. Elle paraît donc la mieux adaptée pour tout type de projet TI (même le
nôtre : deux ressources travaillant à distance et dont les problèmes de communication peuvent
se poser également problème). Toutefois, c’est plus le côté « valeurs Scrum » de cette
approche qui nous intéresse davantage et qui devrait ainsi être mis au devant de la scène lors
le cadre de notre projet, avec la possibilité de définir et de mettre alors sur pied des Product
21
Le SAFe est définie comme une méthode qui favorise l’alignement, la collaboration et la diffusion dans un
grand nombre d’équipes agiles. Il est développé par et pour les praticiens, en s’appuyant sur trois principaux
savoirs : le développement de logiciels agiles, le développement de produits allégés et la pensée systémique
(Leffingwell Dean, 2017, Source : http://www.scaledagileframework.com/about/).

sur 54
Backlog, des Sprint Planning, des Sprint Backlog, des Sprint Review, ou des Increment à
succès (cf. figure 3).
Figure 3 - Scrum framework et ses principales parties (Sutherland Jeff et Schwaber Ken, 2017, source :
https://www.scrum.org/resources/what-is-scrum).
Les valeurs Scrum qui sont intégrées dans notre approche sont au nombre de cinq, à savoir
l’engagement, le courage, le focus, l’ouverture et le respect. Pour Schwaber Ken (2016), lors
du webinar Scrum à , « lorsque ces cinq valeurs sont incarnées et vécues au quotidien par une
équipe de projet, les piliers de la transparence, de l’inspection et de l’adaptation chers à
l’approche Scrum émergent aussi naturellement ». Rappelons ici que l’approche Scrum dont
notre approche adoptée tente alors d’insister sur les valeurs reste à ce jour « la méthodologie
agile la plus utilisée parmi les méthodes agiles existantes » (Cohn Mike, 2010). Elle est aussi
« la plus éprouvée, documentée et supportée » (Cohn Mike, 2010). Son intégration dans
l’approche proposée par Leffingwell Dean et adoptée dans le cadre de notre projet nous
permettrait donc de travailler davantage en étroite collaboration et avec des rétroactions ou
itérations continues tout au long du déroulement du projet. Ceci atteste aussi que le client de
notre projet et/ou les utilisateurs finaux du produit-logiciel à fabriquer ou à créer sont
automatiquement impliqués aux différentes activités définies et liées dès leur début jusqu’à
leur fin d’exécution. Cette mention importante, recommandée voire à répétition dans la
littérature TI (lire Schwaber Ken et Beedle Mike, 2002 ; Lavoie Luc, 2009 ; et Vickoff Jean-
Pierre, 2009 ; cités par Mbuta Ikoko, 2011), constitue le principal avantage de toute méthode
agile.
En plus, « le côté Scrum de l’approche SAFe répond parfaitement à la modélisation des
besoins métier du MOA (client) et des exigences fonctionnelles spécifiques à élaborer pour le
produit-logiciel à fabriquer par la MOE (développeurs) » (Leffingwell Dean, 2017 : traduction
libre). Ce sont donc des besoins et/ou des exigences qui ne sont entre autre que des users
stories c.à.d. des descriptions de différentes fonctionnalités d’un produit-logiciel avec plus de
précision.
En somme, la méthode adoptée dans ce projet est tout simplement une combinaison de
SAFe/Scrum. Validée par le client, lequel certifie que l’équipe de développement a bien
compris son problème, cette méthode combinée nous donne la possibilité d’aligner les
différents objectifs et exigences métiers sur les futures composantes du système d’information
ou produit-logiciel à construire et/ou à mettre en œuvre, et cela, dans l’esprit de répondre
correctement « à la dynamique et au besoin de performance organisationnelle d’une
organisation suivant une gouvernance concertée capable de gérer plus tard l’écart entre
l’approche conceptuelle et le modèle empirique à opérationnaliser » (Zachman John, 1987,
cité par Mbuta Ikoko, 2009). Si nous suivrons également les trois phases d’analyse décrites
par Grosjean Pascal et al. (2011), à savoir le choix du modèle d’architecture, la définition de

sur 54
l’architecture applicative et la définition de l’architecture de déploiement22
, ou celles de Ross
Jeanne et al. (2006), qui mettent en place un cadre virtuel d’architecture de référence pour une
entreprise, notre méthode adoptée devrait aussi également prendre en compte les aspects
fonctionnels, structurels et comportementaux des parties prenantes respectives du projet mais
aussi les contraintes et les opportunités offertes par les capacités TI rendues disponibles par
ces dernières à partir des différentes stratégies TI à adopter ou existantes au sein de
l’organisation cliente. Il s’agit au fait des contraintes et des opportunités « qui sont
susceptibles de rassurer les futurs utilisateurs et d’augmenter la maîtrise de la complexité qui
est également le thème central pour toute architecture de système d’information à mettre en
place » (Caseau Yves, 2012, in Printz Jacques, 2012).
Pour Leffingwell Dean (2017), créateur de la méthode SAFe, les phases d’analyse de cette
méthode ou démarche de développement informatique débutent voire toujours par la
définition d’un modèle général du système d’information à mettre en place, « dont la
conception devrait se faire de la manière la plus conceptuelle possible, c.à.d. continue,
itérative et incrémentale tout en intégrant la vision transformatrice ou évolutionniste du client
à partir de sa compréhension et de son environnement d’affaires (éléments d’analyse de
l’organisation cliente) » (Mbuta Ikoko, 2009). C’est ce que Ross Jeanne et al. (2006) ont aussi
avancé tout en proposant la mise en place d’une fondation qui devra permettre l’exécution
optimisée de différentes activités d’un projet ou d’une organisation. Pour Ross Jeanne et al.
(2006, cité par Mbuta Ikoko, 2012), « cette fondation est fonction d’un modèle opérationnel
(operating model), d’une architecture d’entreprise (enterprise architecture23
) et d’un modèle
de gouvernance des TI ». Le modèle opérationnel étant défini comme étant une représentation
abstraite de la façon dont les parties prenantes d’un projet opèrent « ...à travers les domaines
de processus, l’organisation et le choix de technologies afin d’accomplir des fonctions
respectives attendues » (Wikipédia, 2017), il traduit alors, ensemble avec l’architecture
d’entreprise et le modèle de gouvernance des TI d’une organisation, le niveau d’intégration et
de standardisation des différents processus métier qui doivent être automatisés au niveau du
produit-logiciel à fabriquer ou à mettre en œuvre.
3.2 Présentation et description synthèse du système d’information ou produit-logiciel à
mettre sur pied.
Notre produit-logiciel à fabriquer devra disposer d’un web service créé qui a pour nom «
NoteReminder ». Il s’agit d’un nom donné par le tuteur de ce module de cours (D314).
Le web service créé devra proposer de stocker à l’aide d’une base de données embarquée ou
d’une ressource persistante des notes à créer et à manipuler par un utilisateur. Un des IDE de
l’environnement JDK et le langage Java EE devraient être utilisés pour pouvoir coder tous les
22
Les trois différentes phases d’analyse mentionnées servent à modéliser la compréhension du problème posé
par le client. Elles servent aussi à bien définir le contour de l’application et à permettre de savoir ce qui devrait
être intégré dans la solution, mais aussi ce qui ne doit pas l’être, puisque la solution ne doit prendre en compte
que ce qui a été identifié lors de ces phases d’analyse.
23
Le cadre d’architecture d’une entreprise, comme nous l’avons déjà défini précédemment, est modélisable sous
la forme d’un système d’information de communication et de collaboration entre les différentes parties prenantes
de cette entreprise. Il est composé de 4 niveaux de modélisation qui sont (1) le niveau métier, qui définit la
stratégie métier, la gouvernance, l’organisation et les processus métier clés d’une entreprise ; (2) le niveau
applicatif, qui contient le parc applicatif d’une entreprise, les interactions entre applications et la couverture
fonctionnelle de ces dernières comme éléments de sa définition ; (3) le niveau données, qui concerne la structure
et l’organisation des données au niveau logique et physique, les référentiels de données ainsi que la manière avec
laquelle ces données sont gérées et enfin, (4) le niveau technique qui décrit à son tour l’infrastructure logicielle,
matérielle et réseau nécessaire au déploiement des données et des applications. Les web services, qui sont décrits
comme des cadres d’architecture logicielle, se situent ainsi au niveau technique de celui-ci, avec une
interpénétration sur les 3 autres niveaux restant. C’est donc un sous cadre d’architecture d’entreprise.

sur 54
besoins ou exigences fonctionnelles renseignées par le tuteur du module, représentant en
grande partie les opérations ou fonctionnalités CRUD. Hormis ces éléments, le web service à
créer doit également offrir une meilleure convivialité web et une bonne qualité de ses
services. Il s’agit d’un web service de type RESTful mais devra naturellement s’appuyer et
répondre aux différentes spécifications et contraintes sécuritaires issues du SOAP.
Une application cliente devrait également être développée pour pouvoir interroger ou
consommer les différents services qui vont être offerts par ce web service. L’application
cliente à développer serait une application web ou mobile qui devrait toutefois rester
indépendante du web service à créer. Elle aura pour nom « Client-NoteReminder », nom
emprunté au projet du module D228, en rapport avec le développement des applications
clientes mobiles sous Android.
3.3 Détails sur les différentes technologies et sur l’environnement de développement
choisis et utilisés.
Pour la création de notre web service, nous avons décidé d’utiliser l’IDE Netbeans. Ce dernier
s’accompagne naturellement du langage de programmation exigé, à savoir le Java Enterprise
Edition (JEE). Le MAVEN est aussi utilisé ici comme le moteur de production de Netbeans.
Notons que le Netbeans est choisi par notre équipe de projet car ce dernier est considéré
aujourd’hui comme l’IDE le plus populaire, mais aussi stable et convivial de l’écosystème
JEE. Il a même encore gagné actuellement plus des crédits face à un autre IDE populaire
connu, à savoir l’Eclipse, qui supporte mal le moteur de production MAVEN que nous avons
décidé d’utiliser. Le Netbeans utilise presque toutes les ressources JDK (Java Development
Kit) ou intègre les différents tools, bibliothèques et web API liés, tels le JAX-WS et le JAX-
RS, etc. Il offre aussi la possibilité de pouvoir faire facilement le développement des
applications natives, web ou hybrides et fonctionne, et cela, de concert avec plusieurs autres
langages de programmation concurrents, tels que le C#, le PHP, le C++ et le Ruby, mais aussi
avec des langages de balises, de styles ou de scripts, tels que le JS, le Type script, le CSS, le
Less, le Sass et le HTML (XHTML). Face également aux ressources à fournir par un web
service et/ou à consommer par une application cliente native, web ou hybride, le Netbeans
apporte également une sécurité considérable car il automatise de manière optimisée les
différentes tâches ou activités techniques de développement logiciel sous Java.
Quant au JEE, qui est un des langages de programmation orienté objet (POO), à l’instar de
C#, C ++, Ruby ou PHP, etc., chaque objet à coder va être décrit sous la forme d’une classe
Java qui contient ainsi des variables d’instance (qualités dont dispose une classe) et des
méthodes (ce que la classe peut faire-faire). Une classe créée pourra facilement hériter les
propriétés des autres classes, de sorte que le code déjà écrit peut être réutilisé à plusieurs
endroits et à plusieurs reprises (lire à propos la notion d’héritage, d’abstraction, de
polymorphisme, d’injection de dépendance, etc.). Ayant décidé de créer ou d’implémenter un
web service de style RESTful, le web API compatible avec le JEE est donc le JAX-RS. Ce
web API va être utilisé dans notre produit-logiciel pour piloter les différentes annotations24
qui, au fait, permettent l’accès aux différentes fonctions, ressources ou services attendues de
notre web service. Pour SANTIAGO & PERICAS Geertsen (2013), ce web API crée voire
automatiquement des web sockets qui offrent à leur tour des fonctionnalités pour la création
de pages web interactives et une expérience utilisateur plus riche. Ses spécifications
fournissent donc à la fois l’API client et l’API serveur qui implémentent les fonctionnalités
requises pour l’échange qualitative, sécurisée et fiable de ressources ou services à consommer
par l’application cliente. Configurable ou intégrable au sein de Netbeans et/ou via GlassFish
24
Les annotations sont importantes dans notre contexte car elles vont faciliter la représentation et le codage des
éléments qui forment des parties de notre modèle du web service RESTful à créer.

sur 54
qui matérialise également la réalisation et la sécurisation d’accès aux modèles de données, le
web API JAX-RX est donc aussi classé actuellement parmi les web API de haut niveau et les
plus utilisées dans l’écosystème JEE.
Pour le développement de la partie cliente de notre produit-logiciel, c’est la technologie
Android qui devrait normalement être choisie. Il s’agissait d’un choix non orienté mais qui
devrait faire suite aux spécifications des besoins ou exigences fonctionnelles croisées de notre
activité collaborative avec celles de l’activité individuelle du module de cours D228, traitant
du développement des applications mobiles sous Android. Néanmoins, après avoir téléchargé
et installé le SDK d’Android sous MacBook Pro, il s’était dégagé une complexité dans
l’utilisation d’un IDE autre que l’Android Studio ; nous voulons dire l’IDE Netbeans que
nous avons choisi pour la création de notre web service mais aussi d’autres tels que l’Eclipse,
JDeveloper, Jbuilder, Jcreator et BlueJ. Nous avons fini par comprendre que cette approche de
développement semble être devenu obsolète actuellement par manque de mise à jour mais
aussi par positionnement de l’IDE Android Studio face aux autres IDE en terme de
développement des applications mobile. En plus, le SDK d’Android passe beaucoup mieux
aujourd’hui avec le moteur de production Gradle de Google. C’est voire la raison pour
laquelle nous avons décidé d’écarter l’approche Android dans cette activité collaborative et de
réaliser aussi directement le développement de la partie cliente sous Netbeans (une approche
pédagogique qui n’a rien avoir avec une exigence professionnelle), toujours avec le langage
Java EE. Dans tous les cas, le développement des applications natives, web ou hybrides sous
Android se fait aussi avec le même langage de programmation c.à.d. le langage Java. Donc,
rien de perdu pour cet apprentissage pédagogique.
3.4 Glossaire sommaire des autres outils utilisés dans notre projet informatique de
développement logiciel mixte.
- UML
L’UML (Unified Modelisation Language) ou langage de modélisation unifié, en français, est
un cadre d’analyse objet itératif et incrémental orienté service mais aussi un support de
communication performant car piloté par les besoins des utilisateurs. Pour Blanc Xavier et
Mounier Isabelle (2006), l’UML « est supportée aujourd’hui par la quasi-totalité d’outils ou
environnement de développement logiciel, lesquels permettent l’édition de modèles ou
diagrammes UML et offrent des capacités tels que la génération de code, tests et
documentation, le suivi d’exigences ou le Reverse Engineering ». Il nous permet, en tant
qu’architecte ou développeur, d’exprimer un modèle d’analyse claire tout en utilisant un
formalisme ou une notation de modélisation qui est régie par un ensemble de règles
sémantiques et pragmatiques syntaxiques connues universellement. La version UML que nous
utilisons dans ce projet, le 2.0, dispose de cinq modèles (modèle utilisateur, modèle structurel,
modèle comportemental, modèle d’implémentation et modèle environnemental) servant ainsi
à décrire l’architecture intégrée du système d’information à concevoir, et cela, via des
perspectives nettement différentes.
A proprement parler, l’UML est donc une notation qui intègre un langage de haut niveau
d’abstraction ou d’expression, le OCL (Object Constraint Language). Ce dernier permet alors
de décrire des contraintes sur les cinq modèles cités et s’écarte du côté génération totale du
code. Les contraintes étant souvent vues comme des restrictions sur des valeurs d’un modèle
ou d’une architecture non représentable en UML. Ceci fait que l’OCL va donc offrir des
descriptions précises et non ambiguës du comportement du logiciel tout en complétant des
diagrammes et en définissant des pré-conditions, des post-conditions ou des invariants pour

sur 54
une opération donnée25
. C’est le logiciel ArgoUML qui servira de créer nos diagrammes ou
modèles UML.
- XML et les données JSON
Comme décrit au niveau du chapitre 2, le langage ou le format XML constitue la base
structurelle et configurationnelle pour tout web service à mettre sur pied. Dans le cadre de
notre projet, nous avons décidé d’utiliser ce format de fichier mais avec un autre format de
fichiers qui interviendra au niveau de la définition de données de notre web service à créer. Il
s’agit du format JSON (JSONP). Grâce à Netbeans et au GlassFish, nous aurons la possibilité
de générer et/ou de personnaliser les différents fichiers ou classes à créer, et cela, suivant le
contrat ou le contexte souhaité par notre client ou par les utilisateurs finaux de notre produit-
logiciel (annotation principale et nom du web service, port, URL du service ou package
contenant le service, etc.). L’utilitaire DOM qui est intégré au niveau du navigateur Safari ou
du navigateur Chrome installé sur nos Mac Book pro devrait nous aider à tester les données
qui seront issues de ces deux formats adoptés.
La collection de différentes données qui seront issues de ces deux formats de fichiers, avec
des fonctionnalités communes, devrait au final constituer notre base de données (lire la notion
de persistance de données dans Java avec Paumard José, http://blog.paumard.org/cours/jpa/).
Pour rappel, une base de données est soigneusement construite et décrite ou d’habitude
partagée et bien organisée pour pouvoir s’adapter à tout système d’information existant ou en
construction. Parce qu’il s’agit d’un système CRUD en construction, nous avons décidé de
nous focaliser sur des entités ressources (Repository) ou POJO (Plain Old Java Objets) que
nous allons représenter via notre web API pour le client et qui vont être stockées plus tard
dans une base de données en production. Donc, il ne nous sera pas vraiment important, dans le
cadre de cette activité pédagogique collaborative, de pouvoir mettre directement sur pied une
véritable approche de gestion de données car les entités ressources ou POJO qui vont être
créés vont ainsi s’apparenter à une base de données acceptable d’un point de vue conception
UML, surtout que nous aurons moins de données à tester.
- La documentation technique du projet
La méthode que nous avons décidé d’utiliser pour sauvegarder, échanger et mettre à jour la
documentation technique de notre projet est le Google Drive. Il aurait aussi été facile
d’utiliser le
4 Résultats et discussions
4.1 Processus de modélisation de notre produit-logiciel, le « Note Reminder »
a) Reconstitution des besoins du client et/ou élaboration des différentes exigences
fonctionnelles pour le web service créé et l’application cliente développée.
Pour savoir ce que notre système d’information ou produit-logiciel construit, le « Note
Reminder », devrait avoir comme fonctionnalités et être capable de les réaliser, nous avons
procédé à une modélisation UML. Lors de ce processus de modélisation, nous avons été donc
amenés à rassembler soigneusement les différents besoins ou spécifications de la partie
cliente, et cela, suivant l’approche agile retenue (SAFe/Scrum) et une logique pratique
d’ingénierie SOC (Service-Oriented Computing, lire davantage Maha Driss et al, 2011). Par la
suite, nous avons présenté les spécifications ou besoins non-fonctionnels pris en compte et
25
En pratique, comme nous allons le voir dans le point 4, ces différents pré-conditions, des post-conditions ou
des invariants sont rendus visibles ou définis lors de la réalisation des cas d’utilisation ou users stories si nous
devons donc nous conformer à l’approche agile que nous avons adoptée.

sur 54
leur importance. Les acteurs et les différents cas d’utilisation de notre produit-logiciel ont été
alors identifiés. L’ajout des relations entre ces différents cas d’utilisation nous a enfin permis
de construire des diagrammes de cas d’utilisation, d’activité, de séquence et de classes.
La base spécifique de la reconstitution et/ou de la mise à jour des besoins du client en
exigences fonctionnelles et non-fonctionnelles était principalement basée sur les différentes
spécifications reprises par le tuteur du module D314 et intégrées dans notre PDL. Ces
différentes spécifications ont été considérées comme des « users stories » par rapport à notre
approche agile retenue, le SAFe/Scrum. Et, pour ne pas faire du faux avec notre approche,
nous les avons repris après une séance de travail de leur reconstitution tout en y ajoutant des
éléments d’informations supplémentaires qui paraissaient essentiels et pratiques à nos yeux.
Les éléments d’informations supplémentaires ont été recueillis par un couplage avec les
spécifications de l’activité du module de cours D228, et cela, dans le but de construire un
Product Backlog fiable pour notre projet collaboratif et qui devrait ainsi répondre au principe
des users stories, c.à.d. au principe dit « MoSCoW : Must have, Should have, Could have et
Won’t have » (lire Wikipédia à propos du principe MoSCoW).
Ci-dessous, les grandes lignes de besoins fournis et couplés (cf. énoncé de cette activité
collaboratrice et celui de l’activité individuelle du module D228). Ces besoins ont consisté à
ce que le web service à créer et l’application cliente à développer, soient à mesure de gérer
et/ou de consommer les ressources ou services à mettre à disposition. Il s’agit au fait, pour un
utilisateur donné de notre produit-logiciel, de pouvoir :
- créer son compte
- ajouter une note
- afficher le détail d’une note
- éditer ou modifier une note
- réarranger des notes
- supprimer une note
Ces besoins ou spécifications, rédigés de manière courte mais aussi avec précision,
représentent des users stories de type Must have et sont donc la base principale de notre
contrat, tel que souhaité par notre client principal ou représentant des utilisateurs finaux (le
tuteur du module D314 et/ou le tuteur du module D228). Ils forment ainsi les différentes
lignes comportementales de notre « design pattern ».
Au regard du modèle de maturité de Richardson présenté au chapitre 2, ces besoins ou
spécifications citées étaient vues immédiatement par nous comme des exigences
fonctionnelles ou « acceptance criterium » de notre produit-logiciel car se situant au niveau 2
du modèle. Ce sont donc des fonctions, ressources ou services CRUD qui constituent à leur
tour les différentes méthodes, actions ou verbes HTTP attendus du côté serveur et qui
devraient être consommés du côté client de notre produit-logiciel. Le côté serveur, qui
implémente et représente ainsi notre web service, ne comporte donc concrètement dans ce cas
qu’un seul URI ou template (/note), un seul modèle d’URI (/note/{noteId}) et quatre
méthodes HTTP (POST, GET, PUT et DELETE). Il devrait aussi être optimisé par un
complément de méthodes ou actions similaires ou non similaires fournissant ainsi à un
utilisateur un accès ou une authentification fiable et sécurisée aux différentes ressources ou
services à gérer et/ou à consommer via le client. Ces actions similaires ou non similaires sont
classées dans la catégorie des Should have en référence à la notion de users stories. Il s’agit en
effet des actions suivantes :
- Seuls les utilisateurs à créer dans notre produit-logiciel en construction qui pourront ajouter,
afficher, éditer, réarranger et supprimer les différentes notes ;

sur 54
- Les utilisateurs à créer devront avoir un profil donné (administrateur ou utilisateur avec
privilèges non absolus, etc.) ;
- Les utilisateurs à créer devraient se connecter ou s’authentifier avec un username et un
password avant de pouvoir gérer et/ou consommer les différents services ou ressources
CRUD de notre produit-logiciel en construction. Ils sont donc les seuls habilités à les faire ;
- Les utilisateurs à créer pourront modifier et supprimer leur mot de passe mais aussi d’autres
informations sur le profil les concernant (nom, prénom, username, email, etc.) ;
- Les utilisateurs à créer pourront se déconnecter une fois qu’ils auront finis de consommer les
services ou ressources CRUD souhaitées au niveau du produit-logiciel en construction ;
- Les informations sur les utilisateurs créés et les différentes opérations CRUD réalisées
pourront être contenues dans une base de données à concevoir ou créer ; et
- Les informations sur les utilisateurs et sur les différentes notes à gérer devraient également
être conservées dans une base de données à concevoir ou créer.
b) Les autres exigences, dites « non-fonctionnelles », prises en compte pour notre
produit-logiciel (côté serveur et côté client).
Dans la littérature TI, la logique d’ingénierie SOC que nous avons utilisée en partie présente
les exigences non-fonctionnelles sous le terme « qualité de service » (QdS). La qualité de
service à offrir par notre web service se réfère donc « à des diverses propriétés telles que la
disponibilité, le temps de réponse, la sécurité, le débit, etc. » (Menascé Daniel, 2002, cité par
Maha Driss et al, 2011). Il s’agit donc des exigences non-fonctionnelles renfermant également
certains users stories liés au Must have, Should have, Could have et Won’t have. Ci-dessous,
les exigences non-fonctionnelles prises en compte par l’équipe de projet et les différentes
propriétés les sous-baissant.
- En rapport avec le type d’architecture dont notre méthodologie de conception se base.
Pour Jacques Printz (2012), qui a décrit davantage le côté fonctionnel et logique (principes et
règles de construction) des différents modèles d’architectures logiciels à construire dans des
organisations, l’implémentation de n’importe quel modèle d’architecture exige aujourd’hui
une connaissance approfondie des capacités TI à associer ainsi que leurs limites ; surtout en
rapport également avec les acteurs qui vont être impliqués au projet. Ces considérations
amènent ainsi aux implémentations fiables et/ou optimisées et permettent voire aux acteurs TI
impliqués au projet d’entretenir des rapports étroits et profonds avec l’ensemble de la chaine
de valeur ou d’autres unités d’affaires dites utilisatrices du futur produit-logiciel. Ces
considérations, comme nous l’avons mentionné aux chapitres 2 et 3, sont aussi la base de
notre démarche de projet et de conception agile et/ou UML qui est centrée sur une
architecture orientée services CRUD, que ca soit du côté web service ou du côté client (lire les
éléments du contrat de fonctions ou services de notre produit-logiciel mentionné au point a de
ce chapitre).
Ainsi, l’architecture orientée services que nous allons réalisé dans le cadre de ce projet devrait
être une architecture à trois couches ou « trois tiers » (presentation, application - business ou
logic - and datas) qui intègre l’architecture cyclique ou le pattern MVC26
au niveau de sa
couche présentation. D’une certaine manière, elle serait donc liée aux 4+1 niveaux ou vues de
conception logicielle proposés en 1995 par Kruchten Phillip, et cela, dans le but d’aligner
l’ensemble de notre produit-logiciel aux différents besoins du client ou préoccupations
26
Le MVC (Model-View-Controller) est une architecture et une méthode de conception qui organise l’Interface
Homme-Machine (IHM) d’une application logicielle (cf. architecture trois-tiers). C’est donc un design pattern de
type cyclique qui est considéré ici comme une sous-architecture se situant au niveau présentation de
l’architecture trois tiers ou à trois couches. Dans la pratique, il divise l’IHM en un modèle (de données), une vue
(présentation, interface utilisateur) et un contrôleur (logique de contrôle, gestion des évènements,
synchronisation). Chacun de ces trois éléments de division ayant alors un rôle précis dans l’interface.

sur 54
fonctionnelles exprimées par nos utilisateurs finaux. C’est donc aussi une architecture multi-
utilisateur qui s’appuie sur l’ensemble des éléments, formes et motivations ou choix rationnels
continus ou itératifs que les différentes parties prenantes du projet ont présentés lors de
différentes phases d’analyse27
(lire davantage Perry Dewayne et Wolf Alexander, 1992, cité
par Nassima Sadou, 2007 ; et par Mbuta Ikoko, 2009). Hormis la nature flexible et
interopérable souhaité pour notre web service, cette architecture serait alors disponible,
sécure, évolutive et utilisable.
- En rapport avec la disponibilité et la sécurité
Pour pouvoir rendre disponible et sécuriser notre produit-logiciel ou son architecture mais
aussi les données qui seront renseignées et sauvegardées, nous avons décidé, lors du codage
des actions candidates à automatiser, d’ajouter des utilisateurs et de définir leur profil en
pouvoir absolu et en pouvoir non absolu. Cette ligne essentielle, recommandée aujourd’hui
comme spécification basique pour toute application informatique web à concevoir, est aussi
reprise sur le site Microsoft « MSDN Flash newsletter » (cf. https://msdn.microsoft.com/fr-
fr/library/zdh19h94(v=vs.100).aspx.). Il est alors précisé que les développeurs des
applications web ou mobiles devraient penser faire exécuter leurs applications avec des
privilèges les plus fiables mais aussi les protéger contre des utilisateurs nuisibles. Ils devraient
également donner aux futurs utilisateurs, avec un pouvoir absolu, la possibilité de connaître
tous les autres utilisateurs et faciliter l’accès sécurisé aux bases de données. En plus, ils
devraient permettre la conservation secrètes de données liées28
, créer des messages d’erreur
sécurisés29
, utiliser de façon sécurisée les cookies et protéger toutes les ressources contre les
menaces ou attaques de divulgation d’informations, de déni de service, de répudiation, ou de
falsification, etc. Ces différentes recommandations, comme nous l’avons déjà mentionné au
point 2, sont aujourd’hui diluées dans le guide OWASP et dans le guide de l’EC-Council qui
servent de référentiels en la matière.
Ensuite, pour ne pas tomber dans le piège des batteries des équipements à utiliser (cf. cas
Apple, Toshiba, HP, Samsung, etc.), la disponibilité et la sécurité que nous évoquons
devraient logiquement se faire accompagner de l’exigence de consommation d’énergie mais
qui, malheureusement, n’a pas été prise en compte par nous. Toutefois, nous avons essayé, au
niveau de notre code, de faire de sorte que les services ou fonctionnalités CRUD qui seront
alors exécutées de façon synchrones et asynchrones, individuellement et en séquences sur les
données, soient lites et limitées, et cela, de manière à éviter également toute non performance
ou tout surcharge sur notre web service et/ou de notre application cliente.
- En rapport avec le temps de réponse et l’évolutivité
Le temps de réponse et l’évolutivité des services à offrir par l’architecture d’un produit-
logiciel sont classés aujourd’hui comme des exigences non-fonctionnelles les plus attendues
par tout client et/ou utilisateur d’un web service ou d’une application cliente native, web ou
hybride. Elles sont aussi prises en compte dans notre projet en rapport avec la performance de
27
Nous pensons que chacune des phases de notre analyse a obéi à certains points de vue transverses du système
d’information ou produit-logiciel que nous venons de mettre en place, particulièrement à travers les différents
diagrammes UML construits.
28
Avec l’évolution liée aux requêtes ou API container, le cas de XMLHttpRequest, l’accès sécurisé aux
ressources web ou mobile a même fini par donner naissance à un autre mécanisme de sécurité, le « Cross-Origin
Resource Sharing ». Ce dernier est même recommandé par le Web Applications Working Group du W3C car il
« fournit un moyen aux serveurs web de contrôler les accès en mode cross-site et d’effectuer des transferts de
données sécurisés en ce mode » (https://developer.mozilla.org/fr/docs/HTTP/Access_control_CORS).
29
C’est également à ce niveau que va intervenir la configuration des différentes réponses HTTP au niveau de
notre web service à créer.

sur 54
notre produit-logiciel. Ainsi, notre web service et notre application cliente resteront évolutifs
grâce à l’ouverture de leur code et aux mises à jour de différents plugins ou extensions
utilisés. Nous rassurons voire notre principal client que notre code et le format de données
utilisés disposent également d’un pool de connexions configurables afin que le web service et
l’application cliente web restent évolutifs.
- En rapport avec l’utilisabilité
La norme ISO 9241-11:2018 (lignes directrices relatives à l’utilisabilité) définit l’utilisabilité
comme étant le degré selon lequel un produit fabriqué peut-être utilisé, par des utilisateurs
identifiés, pour atteindre des buts définis avec efficacité, efficience et satisfaction, dans un
contexte d’utilisation spécifié. Trois variables servent donc pour sa mesure, à savoir
l’efficacité, l’efficience et la satisfaction, et représentent la performance et la qualité dudit
produit. Dans le cadre de ce projet informatique de développement logiciel, l’utilisabilité fait
référence à l’utilisation de notre produit-logiciel qui est ainsi liée à l’ergonomie interactive
entre l’homme et le système. Elle constitue un des critères clé pour fidéliser l’utilisateur d’une
application native, web ou hybride (cf. notion de « responsive design »).
En ce qui nous concerne, nous avons fait de sorte que l’utilisateur de notre produit-logiciel
puisse se retrouver face à un affichage convivial et qualitatif aidant à opérationnaliser et/ou à
matérialiser les différentes fonctions ou services CRUD attendues sur une note. En plus,
suivant le besoin exprimé par le client, il est possible que l’utilisateur puisse visualiser les
notes créées par ordre chronologique, par importance ou par choix d’une couleur donnée
(actions de réarranger). Cette convivialité et qualité offerte via l’interface graphique devrait
aussi permettre à notre produit-logiciel de disposer enfin d’une accessibilité simple pour tout
type ou profil utilisateur car l’utilisabilité que nous souhaitions ici passe pour une exigence
non-fonctionnelle présentant le contact de l’utilisateur avec le produit-logiciel en
implémentation. Par son biais, l’on imagine satisfaire les différentes fonctions et/ou services
attendus pour notre web service. D’ailleurs, avec le web 2.0, cette accessibilité est vue comme
étant la capacité pour une ressource web à rendre son contenu accessible pour tout le monde
quelque soit l’handicap ou la déficience. Elle est même devenue aujourd’hui une norme du
W3C établie dans le cadre du Web Accessibility Initiative (WAI).
Derrière cette accessibilité présentée pour notre produit-logiciel, il se cache donc la notion de
charte graphique et de design, mais aussi celle de métriques et grilles (reponsive design de
pages avec CSS, Less/Sass et Bootstrap) et de la documentation d’utilisation du produit-
logiciel qui a été prise en compte. Cet accès aux ressources et/ou services du web service que
notre code offre, mais aussi la facilité d’utilisation de ce produit-logiciel, sont résumés par
l’UX (User experience design). Avec ce dernier point évoqué, nous devrions aussi tenir
compte du multilinguisme mais nous avons fait fi de cet aspect des choses faute de temps
matériel.
4.2 Différents diagrammes construits
a) Diagramme de cas d’utilisation
Avec les exigences fonctionnelles et non-fonctionnelles reconstituées mais aussi
l’identification des acteurs ou utilisateurs, nous pouvons ainsi identifier et présenter les
différents cas d’utilisation de notre produit-logiciel, le « Note Reminder ». Les différents cas
d’utilisation identifiés ou collectés ici sont repartis en deux packages : le package « CRUD
services for user » et le package « CRUD services for note ». Le package « CRUD services
for user » concerne l’action de créer un utilisateur dans « Note Reminder ». Cette dernière se
voit directement être associée avec d’autres actions génériques types, à savoir celles de
supprimer un utilisateur et de mettre à jour son profil et ses paramètres de login (user name et

sur 54
password), puis de se connecter et de se déconnecter. Par contre, le package « CRUD services
for note » concerne les actions d’ajouter, d’afficher, d’éditer, de supprimer et de réarranger
des notes dans « Note Reminder ». Ces deux packages étant presque semblables, la collection
d’un des cas d’utilisation illustrerait l’ensemble.
Figure 5 – Diagramme de cas d’utilisation identifiés pour le package « CRUD services for note ».
Le raffinement du cas d’utilisation « gérer compte ou profil utilisateur » (cf. « CRUD services
for user ») peut se présenter comme suit :
Figure 6 – Diagramme de raffinement des différents cas d’utilisation identifiés pour le package « CRUD
services for user ».
Les différents cas d’utilisation repris à travers ces deux diagrammes nous ont permis de
modéliser en clair notre contrat ou processus métier orienté services CRUD. Ils ont décrit

sur 54
graphiquement ce que notre produit-logiciel a comme « besoins fonctionnels essentiels ». En
les décrivant textuellement, nous devrions donc avoir en détail ce que notre produit-logiciel
pourrait être à mesure de faire réellement, et par quel type d’acteurs ou utilisateurs. Ci-
dessous, la description textuelle de ces différents cas d’utilisation identifiés, considérés
également comme des futurs items ou « sprints backlogs » à réaliser et à tester en itération
suivant l’approche agile que nous avions adoptée, à savoir le Safe/Scrum.
Ø se connecter dans le Note Reminder
Sommaire d’identification
Titre : connexion
Résumé : Une fois le compte et le profil utilisateur créés, l’utilisateur avec pouvoir absolu ou non absolu peut
alors se connecter pour pouvoir accéder aux différentes ressources ou services CRUD à consommer, et cela, de
manière sécurisée.
Priorité et niveau d’effort : au besoin et suivant le temps que l’équipe du projet aura car l’option login et mot de
passe sont optionnels dans le contexte de cette activité.
Acteurs : Utilisateur avec ou sans pouvoir absolu dans notre contexte.
Date de création : 14/03/2018 Date de mise à jour : 20/05/2018
Version : 1.0 Responsable : alternance cyclique
Description de scénarios sur la fonction
Pré-conditions: L’utilisateur de Note Reminder doit être positionné sur sa page de connexion. Cette page affiche
une image logo comme marque de Note Reminder avec choix d’accès à l’espace client ou à l’espace serveur.
Entrée :
• Cliquez sur le lien client ou serveur de la page d’accueil général et une page d’authentication devra
s’afficher.
• Saisissez le user name (email) et le pass word
• Cliquez sur le bouton « Connecter ».
Traitement et sortie : Le système vérifie et exécute les différentes entrées ou indications fournies par l’utilisateur
(user name et password). Si les différentes informations ou indications de modification fournies sont dans le
format correct et valide (annotation Regex définie), l’utilisateur va alors se connecter dans l’application et sera
redirigé vers la page d’accueil client ou serveur suivant le choix opéré. Si les différentes informations ou
indications fournies n’existent pas ou existent mais ne sont pas dans le bon format, le message d’erreur approprié
sera affiché donnant la possibilité de renseigner à nouveau le login et le password. L’on note également que
l’historique de cet accès utilisateur pourrait être sauvegardé automatiquement dans la base de données de
production une fois l’application déployée. Les codes retour réagiront ici suivant un échec ou un succès.
Ø créer un compte et/ou profil utilisateur dans le Note Reminder
Titre : création d’un compte
Résumé : Le produit logiciel « Note Reminder » peut être protégé par un login et un mot de passe. L’utilisateur
avec un pouvoir absolu ou non absolu doit devoir accéder à cette fonctionnalité de création de compte pour ainsi
utiliser toutes les fonctionnalités du produit-logiciel.
Priorité et niveau d’effort : applicable dans notre contexte selon le choix du développeur
Date de création : 14/03/2018 Date de mise à jour : N/A
Pré-conditions: Avoir installé et disposer d’un accès web sur le produit-logiciel à partir de son device. Au cas où
un utilisateur est déjà créé, ce cas de création ou d’enregistrement est non applicable.
Entrée :
• Dans la page d’accueil du client ou du serveur, cliquez sur « Ajouter ou créer un utilisateur ».
• Le formulaire d’ajout d’un utilisateur apparaît.
• Saisissez les informations ou indications requises. Il s’agit d’indiquer ici le nom, le prénom, l’email, le
mot de passe, et le lien du blog si ce dernier en dispose. Quant à la date de création de l’utilisateur, elle
sera associée automatiquement lors du traitement de la requête ou après validation de l’action par
l’utilisateur qui vient de créer son profil ou l’administrateur back-end.
• Cliquez sur « Enregistrer »
Traitement et sortie : Le système vérifie et exécute les différentes informations ou indications fournies par
l’utilisateur. Si les différentes entrées ou indications fournies sont dans le format correct et valide (annotation
Regex définie), elles sont alors sauvegardées dans la base de données (avec historique) et le compte ou profil
utilisateur est ajouté (code retour 201). La page de confirmation sera affichée (code retour 200). Si les différentes

sur 54
informations ou indications fournies existent déjà ou ne sont pas dans le bon format, le message d’erreur
approprié sera affiché (avec code retour soit 400, 403, ou 409).
Ø changer ou modifier le mot de passe et/ou d’autres informations liées au profil
Titre : changer le mot de passe et/ou le profil utilisateur
Résumé : L’utilisateur doit être en mesure de changer son mot de passe et/ou son profil en toute sécurité sur le
système.
Priorité et niveau d’effort : au besoin et suivant le temps que l’équipe du projet aura car c’est un cas optionnel
dans le cadre de cette activité.
Pré-conditions (optionnel): L’utilisateur doit être authentifié en tant qu’un utilisateur avec un pouvoir absolu ou
non absolu (cf. Cas d’utilisation « Se connecter » in package « CRUD services for user »).
Entrée :
• Cliquez sur l’icône du menu d’utilisateur dans le coin supérieur droit de la page d’accueil de Note
Reminder. Un menu déroulant s’affiche.
• Cliquez ou appuyez en sélectionnant « Password et Profil » dans le menu.
• Le formulaire de changement ou modification de mot de passe et/ou profil apparaît.
• Saisissez les différentes informations ou indications souhaitées sur les différents onglets ou labels
renseignés (old PW, new PW, etc.)
• Cliquez sur le bouton « Changer le mot de passe ».
l’utilisateur (old and new password, etc.). Si les différentes informations ou indications fournies sont dans le
format correct et valide (annotation Regex définie), elles sont alors sauvegardées dans la base de données (avec
historique) et le changement s’opère. La page de confirmation de changement s’affiche (avec code retour 200
dans le back-end). Si les différentes informations ou indications fournies n’existent pas ou existent mais ne sont
pas dans le bon format, le message d’erreur approprié sera affiché (avec code retour soit 400, 401, 403, ou 404
dans le back-end).
Ø Supprimer un utilisateur ou son profil
Sommaire d’identification de la fonction
Titre : suppression d’un utilisateur
Résumé : Le système doit être protégé par un login et un mot de passe. L’utilisateur avec un pouvoir absolu ou
non absolu peut alors se connecter pour accéder à cette fonctionnalité mais pas un invité.
Priorité et niveau d’effort : au besoin et suivant le temps que l’équipe du projet aura car cet aspect de sécurité est
un cas optionnel dans le cadre de cette activité.
Entrée :
• Cliquez sur l’action dans la page d’accueil du serveur pour afficher les options de modification du profil
ou de mot de passe ou de supression de l’utilisateur.
• En cliquant sur l’ption suppression, le formulaire de suppression de l’utilisateur apparaît.
• Vous pouvez ainsi supprimer sur l’utilisateur choisie en cliquant sur le bouton « Supprimer ».
Traitement et sortie : Le système va vérifier l’action de l’utilisateur et l’exécuter. Si l’action est correct ou valide,
la réponse de confirmation sera affichée suivant l’implémentation standard de réponse HTTP. Les codes retour
de succès ou d’echec entrent donc en jeu (200, 201, 400, 401, 403, ou 404, etc.).
Ø ajouter ou créer une note dans le Note Reminder
Titre : ajouter une note
Résumé : Le but de cette partie de l’application est d’ajouter une nouvelle note dans le Note Reminder. Ici,
l’utilisateur connecté pourra saisir le texte, choisir une couleur de note (parmi une palette de couleurs proposée
par l’application), choisir une date d’échéance. La note nouvellement créée se placera en tête de liste.
Priorité et niveau d’effort : applicable dans notre contexte selon le choix ou l’appréciation de la ressource
développeur qui s’occupera de cette tâche de programmation en fonction des phases de responsabilités alternées.

sur 54
Entrée :
• Dans la page d’accueil du client ou du serveur, cliquez sur « Ajouter une note ».
• Le formulaire d’ajout d’une note apparaît.
• Saisissez les informations ou indications requises pour une note. Il s’agit d’indiquer ici le nom de la
note, son contenu, la date d’échéance, l’heure et la fréquence de la note. Quant au nom de l’utilisateur et
la date de création de la note, ces derniers y sont associés automatiquement lors du traitement de la
requête ou après validation de l’action par l’utilisateur qui vient de créer la note.
• Appuyez sur « Enregistrer ».
Traitement et sortie : Le système vérifie et exécute les différentes entrées ou indications fournies par l’utilisateur.
Si les différentes informations ou indications fournies sont dans le format correct et valide (annotation Regex
définie), elles sont alors sauvegardées (l’historique) et le compte ou le profil utilisateur est ajouté (code retour
201). La page de confirmation sera affichée (code retour 200). Si les différentes informations ou indications
fournies existent déjà mais ne sont pas dans le bon format, le message d’erreur approprié sera affiché (avec code
retour soit 400, 403, ou 409).
Ø Afficher les détails de notes dans le Note Reminder
Titre : Afficher une note
Résumé : Pour avoir un bon aperçu des notes créées ou existantes dans Note Reminder, elles doivent être
présentées de manière appropriée (cf. notion de design et d’ergonomie).
Entrée : Les notes qui s’affichent sur la page d’accueil de l’application cliente ou serveur sont limitées seulement
à 10. Toutes sont actives et pas encore arrivées à échéance ou terminées. Si vous souhaitez voir les autres notes
créées et actives dans « Note Reminder », vous devrez cliquer sur les icones « carousel » de défilement qui se
trouvent juste à côté de la dernière note. Toutefois, pour afficher le détail d’une note, vous pouvez procéder
comme suit :
• Cliquez sur le lien « Afficher détail de la note» qui sera visible sous la note en question.
• Dans le lien « Afficher détail de la note », il y a un sous menu qui permet à l’utilisateur de choisir un
affichage des notes soit par couleur, par date de création, ou par date d’échéance. La page affichant les
différentes notes apparaît suivant le lien cliqué. Il s’agit au fait de la page fils de la page d’accueil du
client ou du serveur de Note Reminder. En défilant la page d’accueil, vous avez le glyphicon ou
« carousel » permettant de passer à la page suivante des notes ou de revenir sur la page précédente.
l’utilisateur. Si les différentes informations ou indications fournies sont dans le format correct et valide
(annotation Regex définie), elles sont alors sauvegardées (avec historique). La réponse de confirmation ou
d’échec (code retour 200, 201, 400, 403, ou 409) peut être vue et affichée en inspectant la page courante sous
DOM.
Ø éditer et/ou modifier une note dans le Note Reminder
Titre : changer et/ou modifier une note
Résumé : Dans le prolongement naturel de la fonction ajouter ou créer une note, il y a également la fonction
permettant d’ajuster les indications renseignées par l’utilisateur concernant une note créée, à savoir le nom de la
note, son contenu, la date d’échéance, l’heure et la fréquence.

sur 54
Entrée :
• Dans la page d’accueil du client ou du serveur, cliquez sur « détail de la note ».
• Le formulaire de détail de la note apparaît. Il y a également une possibilité de cliquer sur le lien action
de la note pour obtenir la possibilité de modification ou de suppression.
• Dans le formulaire de détail de la note, il y a un lien donnant la possibilité de « Editer une note ».
• Le formulaire d’édition d’une note apparaît avec l’action clic.
• Vous pouvez ainsi mettre à jour ou modifier les informations ou indications renseignées souhaitées au
niveau de la note choisie.
• Pour finir, il faudra cliquer sur le bouton « Enregistrer ».
l’utilisateur (nom de la note, son contenu, date d’échéance, heure et fréquence, etc.). Si les différentes entrées ou
indications fournies sont dans le format correct et valide (annotation Regex définie), elles sont alors
sauvegardées dans la base de données (avec historique) et le changement s’opère. La page de confirmation de
modification s’affiche (avec code retour 200 dans le back-end). Si les différentes informations ou indications
fournies n’existent pas ou ne sont pas dans le bon format, le message d’erreur approprié sera affiché (avec code
retour soit 400, 401, 403, ou 404 dans le back-end).
Ø réarranger une note dans le Note Reminder
Titre : réarranger une note
Résumé : Il s’agit d’écrire une fonction permettant à l’utilisateur de faire descendre ou remonter une note dans la
liste d’affichage se trouvant sur la page d’accueil de l’application du côté client ou du côté serveur. Cette option
de filtrage peut alors se faire via la date d’échéance, la couleur ou la priorité de différentes notes actives ou
existantes.
Acteurs : Utilisateur avec un pouvoir absolu ou utilisateur avec un pouvoir non absolu.
Entrée :
• Pour l’affichage par couleur, par date d’échéance, ou par priorité de la note, l’on doit cliquez sur le lien
par date d’échéance qui est la seule option à développer. Les autres options (par priorité ou par couleur
pourront être développer si nous disposons du temps. Le clic sur le lien nous permet d’afficher les
notes par date d’échéance descendant ou remontant (byorder and byorderdescending).
Traitement et sortie : Le système va vérifier les différents clics de l’utilisateur pour voir s’ils sont dans la logique
back-end d’exception ou pas implémentée dans le serveur. Si un clic est correct ou valide, l’action sera exécutée
avec succès sinon elle sera un echec (les différents codes ou réponses HTTP entrent alors en jeu (200, 201, 400,
401, 403, ou 404, etc.).
Ø supprimer une note dans le Note Reminder
Titre : supprimer une note
Résumé : Si l’utilisateur veut supprimer complètement la note, il devrait donc y avoir une fonction pour cela.
Acteurs : Utilisateur avec un pouvoir absolu ou utilisateur avec un pouvoir non absolu.
Entrée :
• Dans la page d’accueil du client ou du serveur, cliquez sur « détail de la note ».
• Le formulaire de détail de la note apparaît. Il y a également une possibilité de cliquer sur le lien action
de la note pour obtenir la possibilité de modification ou de suppression.

sur 54
• Dans le formulaire de détail de la note, il y a un lien donnant la possibilité de « Supprimer une note ».
• Le formulaire de suppression d’une note apparaît avec l’action clic.
• Vous pouvez ainsi supprimer sur la note choisie en cliquant sur le bouton « Supprimer ».
Traitement et sortie : Le système va vérifier l’action de l’utilisateur et l’exécuter. Si l’action est correcte ou
valide, la réponse de confirmation sera affichée suivant l’implémentation standard de réponse HTTP. Les codes
retour de succès ou d’echec entrent donc en jeu (200, 201, 400, 401, 403, ou 404, etc.).
Ø se déconnecter dans le Note Reminder
Titre : se déconnecter
Résumé : Le système est protégé par un login et un mot de passe pour y accéder. A la fin de son utilisation,
l’utilisateur doit pouvoir se déconnecter pour terminer l’ensemble des processus internes déclenchés.
Priorité et niveau d’effort : au besoin et suivant le temps que l’équipe du projet aura car cet aspect de sécurité est
un cas optionnel dans le cadre de cette activité.
Acteurs : Utilisateur avec un pouvoir absolu ou sans pouvoir absolu dans notre contexte.
Version : 1.0 Responsable : alternance cyclique.
Entrée :
• Cliquez sur l’icône du menu d’utilisateur dans le coin supérieur droit de la page d’accueil de Note
Reminder. Un menu déroulant s’affiche
• Cliquez ou appuyez en sélectionnant « Se déconnecter » dans le menu.
• La page de connexion apparaît.
Traitement et sortie : Idem ou presque similaire au cas d’utilisation « Se connecter ».
b) Diagramme d’activité
Les descriptions textuelles que nous venons de présenter dans le précédent point nous ont
permis de comprendre et de détailler clairement les différents cas d’utilisation identifiés.
Comme dit précédemment, elles ne sont que les actions CRUD déjà évoquées. En plus,
comme nous l’avons aussi mentionné, ces différents cas d’utilisation décrits passent
également pour des futurs sprints backlogs à réaliser (cf. Scrum). Toutefois, pour matérialiser
notre design, nous montrons ci-dessous, sous une logique processuel et à travers un
diagramme d’activité, comment ces différents cas d’utilisation ou actions CRUD décrites
seront ordonnées et menées dans le temps et dans l’espace par les différents acteurs ou
utilisateurs associés ou identifiés.

sur 54
Figure 7 - Diagramme d’activité centrée sur le package « CRUD services for note »
Les différentes actions reprises dans ce diagramme d’activité constituent donc le socle de
notre produit-logiciel (côté serveur et côté client)30
. Elles doivent alors être retenues et
automatisées dans sa version beta ou 1.0. En rappel, ces actions ou services sont :
- créer ou ajouter un compte ou profil utilisateur dans Note Reminder
- ajouter une note
- afficher le détail d’une note
- éditer ou modifier une note
- réarranger des notes
- supprimer une note
Lors du codage, le niveau logique ou business de ces différentes actions ou services retenus et
à automatiser a été donc caché derrière l’architecture cyclique MVC.
30
La logique processuel reprise ici serait similaire aux actions ou cas d’utilisation identifiés dans le cadre du
package « CRUD services for user ». Donc, nous avons fait fi de ce package ici et aucun diagramme d’activité
lié a été alors construit. Nous avons appliqué à la place, lors de notre codage, le principe de la réutilisation des
objets.

sur 54
c) Diagramme de séquence
Ci-dessous, le diagramme de séquence de notre produit-logiciel. A partir de la logique
processuelle et architecturale définie dans le point b, nous pouvons observer l’interaction
intégré du package « CRUD services for note » et du package « CRUD services for user »
sous forme des scénarios numérotés.
Figure 8 - Diagramme de séquence
Les différentes actions CRUD de la séquence 8 de ce diagramme, ou de notre package
« CRUD services for note », a été également détaillée dans des diagrammes de séquence
séparés. Ces diagrammes de séquence séparés n’ont pas été repris dans ce rapport technique.
d) Diagramme de classes, modèle d’objets et/ou modèle de données.
Pour obtenir un produit-logiciel performant et de qualité, nous avons également privilégié la
création d’un modèle d’objets et d’un modèle de données. Le modèle d’objets créé dans cette
modélisation décrit donc les différents objets sur lesquels la base de données en production
pourrait stocker des informations. Se trouvant dans une POO (Programmation Orientée
Objet), les objets physiques devraient ici représenter également des événements. Ainsi, l’objet
note, qui est alors la résultante de différents événements ou actions du package « CRUD
services for user », passe donc pour l’événement principal de notre produit-logiciel. Il va
interagir ainsi avec les événements ou les actions de l’autre package (le diagramme de
séquence de la figure 8 a même fait une illustration partielle de cette interaction).
Le modèle d’objets est donc une instance de notre modèle de classes créé. D’ailleurs, nous
signalons que les deux modèles ont été construits en parallèle. Au niveau du modèle d’objets,
il y a possibilité de montrer, par abstraction, la relation existante entre les deux principaux
objets créés de nos packages (user et note) mais aussi des autres objets intervenants. Dans le
modèle de classes ci-dessous (voire figure 9), les deux principaux objets créés sont devenus
réellement des classes. Ainsi, la relation ou l’association entre les objets « note » et « user »
est même représentée de manière plus concise. Elle suit ici la normalisation de type 1 à n.

sur 54
Figure 9 - Le modèle de classes
Les différents objets présentés dans ce modèle de classes ne sont entre autre que des classes
avant leur instanciation. Ils correspondent aux tables virtuelles et possèdent chacun ses
propres méthodes et propriétés, c.à.d. des champs ou des attributs ayant des noms, des types
de données ou des valeurs, etc. Ci-dessous, leur description :
TABLE USER
Nom du champ Type Taille/Valeurs Description
id String 8 ID unique auto-incrémenté de l’utilisateur : clé
primaire de la table. Il peut aussi être saisi
manuellement
firstName String 15 Nom de l’utilisateur sur 15 caractères maximum
lastName String 15 Prénom de l’utilisateur sur 25 caractères
maximum
email String 20 Adresse e-mail de l’utilisateur sur 15 caractères
maximum. Elle peut également être utilisée
comme Login par l’utilisateur pour s’identifier
lors de chaque accès dans le produit-logiciel
userName String 15 Login de l’utilisateur sur 15 caractères maximum
password String 15 Mot de passe de l’utilisateur sur 15 caractères
maximum
blogURL String 10 Adresse URL du blog de l’utilisateur s’il en a
(optionnel)
Tableau 3 – Table User
TABLE NOTE
Nom du
champ
Type Taille/Valeurs Description
id String 8 ID unique auto-incrémenté de la note ou tâche : clé primaire de la
table
Title Varchar 10 Le champ du titre de la note est bloqué sur 10 caractères maximum
description
String 25 Description de la note sur 25 caractères maximum
priority String 10 Niveau d’importance ou de priorité de la note
colorNameFile String 10 Couleur à choisir sur les trois fichiers disponibles (red, green, red)
pour donner un statut à la note
echeance Date jj-mm-aa Date de réalisation de la note (tâche)
Link String Date d’échéance ou de fin de la tâche
user (iduser) String - ID unique étranger de l’utilisateur sur 8 caractères maximum.
L’utilisateur enregistrant les informations sur la note ou tâche
Tableau 4 – Table Note

sur 54
4.3 Ecriture du code et présentation des certains éléments spécifiques liés.
a) Les processus répondant au contrat des différentes actions au niveau du web service
et au niveau de l’application cliente
• Définition de l’URI ou URL de base
Comme nous l’avons évoqué en passant, dans notre chapitre 2, les ressources représentées
par une URL sont constituées d’un domaine (domain ou localhost), d’un espace de nom de
contexte (context root), d’un URI de base du chemin de l’application (base URI) et d’un nom
lié à la ressource concernée. Dans la pratique, deux manières sont possibles pour définir ou
créer une URL de base au sein d’une application web sous Java : par héritage et à partir d’un
fichier descripteur de déploiement (le fichier web.xml).
Par héritage, nous avons créé une classe de configuration (RESTConfig) qui sous-classe la
classe d’application (java.ws.rs.ApplicationPath) qui est notre chemin d’application annoté.
Cette classe définit donc l’URI de base ou racine de notre produit-logiciel. Comme nous
l’avons énoncé au chapitre 3, cette création ou implémentation mais aussi celles qui vont
suivre vont être réalisées avec l’aide de l’IDE Netbeans, du langage de programmation Java et
du web API JAX-RS.
Figure 10 – Le code de configuration de l’URI de base (« /api »).
Le nom de l’URI ou URL de base, c.à.d. de l’API, passe donc ici par l’annotation
@ApplicationPath(« /api ») (voir figure 10). La deuxième approche se focalise à la
spécification de l’URL pour le mappage de servlet au niveau du fichier web.xml. Cette
spécification se trouve également reprise, avec certains détails de description, dans les
différents fichiers pom.xml de nos deux applications, avec des lignes d’indication tels que le
localhost:8081/rest-serverNoteReminder/api/, pour le web service, et le localhost:8080/rest-
clientNoteReminder/api/, pour le client.

sur 54
Figure 11 – Extrait du code généré par Netbeans pour le fichier pom.xml côté serveur que nous avons adapté par
la suite
Un troisième fichier pom.xml existe au sein de notre produit-logiciel pour matérialiser le lien
de deux autres fichiers pom.xml car nous utilisons ici le Maven comme notre moteur de
production.
A part la configuration et l’implémentation de notre URI de base via ces deux méthodes, l’on
doit aussi faire mentionner que les autres fichiers XML créés au niveau du web service et au
niveau du client (le beans.xml et le nb-configuration.xml), qui passent aussi pour une des
étapes essentielles, mais également le fichier web.xml, ont été personnalisés en fonction de
notre contrat ou de notre logique implémentative. En décidant de définir notre racine ou URI
de base via les deux méthodes sus évoquées, un point à garder à l’esprit ce que c’est l’URI
définie dans le mappage de servlet qui l’emporte sur l’autre.
Une fois l’URI de base définie, à partir duquel nous souhaitons que les ressources de notre
produit-logiciel répondent, nous avons alors la possibilité de créer et de configurer nos classes
agiles qui représentent alors les ressources et les méthodes de ressources elles-mêmes.
• Création des ressources et des entités de ressources et implémentation de différentes
méthodes
En rapport avec les deux ressources qui étaient ressorties lors de notre conception (notes et
users), nous les avons alors créé dans notre IDE et avons fait annoter leurs différents chemins
au niveau de deux classes créées. Ces deux classes sont créées au niveau d’une des extensions
du package de notre serveur (org.emiage.rest.servernotereminder). Il s’agit d’une extension
« rest » qui a été donc créée pour contenir nos deux principales ressources. Pour la ressource
notes, cette implémentation est donc visible au niveau de la classe Java « NoteResource »).
Pour la ressource users, elle l’est au niveau de la classe Java « UserRessource ».

sur 54
Figure 12 – Extrait du code implémentant la ressource Note
Les chemins que nous avons annotés ici sont donc indiqués en faisant des transferts de
chemins URI relatifs aux annotations concernées, et cela, en tant que valeurs de nos chaînes
(@Path(« /notes ») et @Path(« /users »)).
Pour arriver à rendre ces différentes ressources accessibles, nos deux classes de ressources
racine sont donc définies de manière distinctes (Ressource note : api/notes et Ressource
utilisateur : api/users, voir illustration sur la figure 13 ci-dessous).
Figure 13 – définition et schématisation de différentes actions possibles de notre produit-logiciel
Les différentes fonctions ou services CRUD que nous avons implémentées par la suite sur ces
deux ressources ou entités, c.à.d. les méthodes ou actions HTTP attendues pour notre produit-
logiciel s’appuient également sur cette logique. Nous avons même utilisé l’annotation
@PathParam pour cette accessibilité. Dans la partie cliente de notre produit-logiciel, les deux
ressources et les méthodes de ces ressources sont représentées via l’URI de base. Pour ce
faire, deux autres classes Java (Note et User) ont été aussi créées au niveau du package de
notre serveur, mais dans un nouveau dossier ou une nouvelle extension que nous avons
nommé « entity ». Au niveau du package client (org.emiage.rest.clientnotereminder),
l’extension qui renferme les mêmes classes porte aussi le nom d’ « entity ». Les getters () et
les setters (), mais aussi les equals () et le hashCode (), puis les constructeurs de ces deux
Chemins de
resources
URI de
base
Méthodes de
ressources

sur 54
classes créées ont été générés automatiquement. Toutefois, nous avons adapté certains
constructeurs en « sans arguments » pour que la sérialisation décidée sur nos ressources ne
puissent pas échouer. D’autres extensions ont été aussi créées au niveau du package de notre
serveur et du package de notre client, à l’instar de « repository », « repository/exception »,
« bean », « restclient », etc. La validation « bean » accompagne donc notre produit-logiciel et
sa partie cliente est aussi capable de consommer toutes ces ressources de manière fiable
(grâce à des annotations @Consumes and @Produces implémentées).
Vers et depuis JSON, nous avons aussi décidé de sérialiser la classe User et la classe Note que
nous avions créées, et cela, grâce à l’API JAXB qui est conçue pour lier des objets Java à
XML et/ou JSON afin qu’ils puissent être sérialisés ou désérialisés en tant que documents
XML et/ou JSON. L’annotation utilisée à propos est le @XmlRootElement. Elle remplace en
quelque sorte l’annotation @Entity. Pour finir, nous rappelons aussi que les deux entités ou
classes que nous avions créées et dont nous avons sérialisés sont tout simplement des objets
Java (POJO : Plain Old Java Object). Elles sont alors considérés comme les ressources
persistantes que nous avons décidé de représenter dans la partie cliente via notre API REST.
Lors de la mise en production, elles devront donc être stockées et gérées totalement par un
SGBD relationnel, précisément le MySQL (il s’agit ici de notre propre préférence car nous
utilisons le Maven comme moteur de production, @Entity). Au fait, pour la partie production
de notre produit-logiciel, le MySQL mais aussi le SQLite sont donc parmi les types de SGBD
les mieux adaptés. Ces derniers, en dehors de créer des « vues »31
ou des tables virtuelles sous
plusieurs formats pour pouvoir cacher correctement aux utilisateurs la gestion technique très
complexe et compliquée des objets ou des données. Ils fournissent aussi également un
contrôle de transaction et de récupération pour restaurer des objets ou des données d’une base
de données à état cohérent antérieur, et cela, après une défaillance matérielle ou logicielle.
Nous profitons ici pour dire que la base de données objet créée (POJO) manque souvent de
standard. Des nombreuses lacunes sont même présentées à ce jour par comparaison à une base
de données relationnelle classique. Nous citons le cas de la performance qui devient souvent
inférieure lorsque d’énormes quantités d’objets sont lues ou manipulées : ce qui n’est pas le
cas avec une base de données relationnelle classique. Ce dernier est tout simplement un
système logiciel ou applicatif qui permet efficacement de matérialiser les fonctions intégrées
CRUD retenues, c.à.d. les fonctions d’ajout ou création, de découverte (recherche), de mise à
jour (insertion ou modification) et de suppression, s’associant chacune, comme nous l’avions
dit dans le chapitre 2, avec une méthode, action ou verbe HTTP définie.
Il s’en est suivi de l’implémentation effective de différentes méthodes HTTP. La méthode
POST est implémentée ici, - côté client et côté serveur-, pour pouvoir permettre aux
utilisateurs finaux de créer ou ajouter une note ou des notes dans la version beta de notre
produit-logiciel. Disposant d’un caractère non sûr et non-idempotent32
, la méthode POST
n’est pas seulement implémentée pour créer ou ajouter une note mais aussi comme un
mécanisme de transfert polyvalent qui sert à déplacer les différents documents XML entre des
postes clients et des postes serveurs. Il s’agit, pour Yener Murat et Theedom Alex (2015),
d’une possibilité offerte souvent aux développeurs web qui sortent un peu du cadre CRUD
31
Dans le contexte d’une base de données relationnelle, l’on signale ici qu’une vue relationnelle est totalement
différente de la vue du MVC. Il s’agit plutôt d’une relation virtuelle c.à.d. d’une table définie via une expression
de requête. Elle n’est pas stockée physiquement dans la base de données mais peut être interrogée en tant
qu’autres relations. Parfois, il est possible de modifier aussi les vues par insertion, suppression ou mise à jour.
32
Notons que le RFC 7231 a ajouté deux notions aux principales méthodes ou verbes HTTP connus à ce jour. Il
s’agit des méthodes, dites « safes », qui ne modifient pas les données sur le serveur peu importe le nombre de
fois qu’elles sont appelées (le cas de GET et HEAD), et des méthodes idempotentes, qui peuvent modifier les
données dès le premier appel (le cas de GET, HEAD, PUT et DELETE). Quant à la méthode POST, elle est
curieusement ni safe ni idempotent.

sur 54
classique. Ainsi, la méthode POST implémentée pour la ressource note et user peut accepter
deux instances de cette ressource en tant que paramètre c.à.d. à partir du corps HTTP d’une
requête POST. Comme dit dans le précédent paragraphe, les instances implémentées sont
sérialisées (serializable), et cela, à partir de la charge utile JSON du corps HTTP vers elles.
Elles sont conservées, ces instances, au sein de la couche de persistance de notre produit-
logiciel. Notre charge utile contient alors une représentation de la note et de l’utilisateur,
codée en tant que document JSON/XML.
Nous avons aussi implémentée la méthode GET. Elle concerne ici l’affichage d’une note ou
d’un utilisateur créé ou à créer mais aussi pour invoquer d’autres méthodes distantes via le
tunnel ou la base URI. Elle récupère aussi les codes de réponses HTTP standards de notre web
service (les réponses 200, 201, 404, etc. que nous avons repris dans la description textuelle de
certains cas d’utilisation). D’ailleurs, comme nous allons le mentionner dans le point qui va
suivre, avons alors tenté d’implémenter une méthode de gestion des exceptions particulière.
Donc, nos méthodes GET sont implémentées et s’utilisent de manière explicite dans notre
produit-logiciel pour récupérer les informations d’état ou de représentation des ressources à
partir de toutes les ressources ou services à mettre sur pied.
En dehors de la méthode GET, nous avons poursuivi notre implémentation avec la méthode
PUT. Cette dernière s’occupe, quant à elle, de l’édition ou de la modification d’une note ou
des notes créées c.à.d. de mise à jour de différentes informations renseignées sur une note ou
un user identifié par un URI calculé par le client. Notre tentative d’implémentation de la
méthode d’exception, liée à l’échéance de réalisation de la note, accompagne ainsi la dite
méthode. Au niveau de notre code source, nous pourrions observer les méthodes GET et PUT
grâce à des annotations liées et/ou dérivées, tels que le @GET, le @PUT, le @Consumes, le
@Produces (MediaType.APPLICATION_JSON) et le @Path(« {echeance:
d{9}[d|X]$} »), etc. Étant donné que la méthode GET n’apporte aucune modification d’état
côté service à laquelle notre application cliente peut être tenu responsable, les représentations
à générer en tant que réponses à GET ont été mises en cache, et cela, comme conseillé dans le
livre de Yener Murat et Theedom Alex (2015). Les performances de l’infrastructure
implémentée semblent donc être améliorées car la latence est supposée réduite, tout en
renforçant voire la sécurité et en encapsulant les systèmes hérités au sein de la même
infrastructure. Il s’en est suivi également l’implémentation des autres méthodes, à l’instar de
la méthode DELETE ayant le @DELETE comme élément d’annotation.
Quant à la méthode DELETE, elle matérialise l’action suppression d’une note dans notre
produit-logiciel. Ainsi, lors de l’exécution de la méthode HTTP liée, la requête HTTP est
donc envoyée à l’URI de la ressource concernée. Ensuite, le service hébergeant la ressource
concernée peut interpréter cette requête comme une indication que l’utilisateur de
l’application cliente vient de décider que la ressource soit supprimée. Il s’agit d’une décision
qui dépend donc des besoins de l’utilisateur mais aussi de l’ensemble des services
implémentés.

sur 54
Figure 14 – Extrait du code implémentant la méthode GetAllNote, avec l’annotation @GET qui est renseignée.
• Les tests et les réponses HTTP sur les différentes méthodes instances ou méthodes
implémentées
Les tests de différentes méthodes ou actions HTTP implémentées dans notre produit-logiciel
ont été réalisés avec l’aide du navigateur Safari et de l’utilitaire DOM par défaut de MacBook
Pro (via Inspect element). Ces tests ont impliqué un contrôle centralisé, mais aussi distribué
ou partagé entre les ressources serveur et client de notre produit-logiciel, et cela, grâce aux
structures de classes Java créées qui ne sont en réalité que des tables ou POJO. Nous aurions
également souhaité expérimenter Postman qui s’exécute avec l’aide du navigateur Chrome
mais le temps requis pour l’activité nous a fait défaut. Pour l’ensemble du code Java EE et
JSF sur notre produit-logiciel, nous avons fait des tests unitaires manuels car nous n’avions
pas la maîtrise de l’approche TDD sous cet environnement. En plus, le JUnit ne semble pas
très familier pour l’instant.
En plus, pour pouvoir faciliter une bonne consommation de différents services ou ressources
offertes par notre web service, nous avons tenté de mettre sur pied une logique de réponses
HTTP liée au générateur de réponses internes (standard HTTP). Toutefois, ne disposant pas
d’une expertise avérée en langage Java, nous avons préféré nous arrêter à un niveau dont nous
avons jugé acceptable (voir les classes d’exceptions se trouvant au niveau du package
repository/exception). Si le produit-logiciel aurait été réalisé avec le langage C# ou le langage
PHP en Back-end, qui sont nos langages d’usage professionnels, il n’y aurait eu aucun souci
pour avancer dans cette logique d’exceptions. Avec le Java EE, nous avons refusé de pouvoir
consacrer un autre temps fous de lecture et d’apprentissage comme ce fut le cas pour les
autres tâches de codage réalisées dans le cadre de ce projet. Honnêtement, avec le langage
Java EE, nous avons été un peu embêté car nous recourions à chaque étape de notre codage à
des ressources en ligne (merci grand-père Google) et/ou à des lectures des ouvrages qui se
sont présentés à nous (voir bibliographie) car c’est un langage que nous avons abandonné il y
a plus de 12 ans aujourd’hui.

sur 54
Pour terminer ce point, les méthodes de réponses HTTP standard ou internes de notre serveur
et celles dont nous avons implémenté au niveau du web service ont donc été ajoutées dans le
souci de répondre en grande partie aux différentes lignes du modèle de maturité de
Richardson. D’ailleurs, dans le même ordre de raisonnement, une classe « LinkResource » a
été créée au niveau de notre package « entity » pour faire fonctionner notre produit-logiciel
avec une matérialisation de l’Hypermédia (HATEOAS). Cette ressource, le
« LinkRessource », fait du parsing sur les deux principales ressources (NoteRessource et
UserRessource) définies et créées mais aussi sur la classe nommée « Hypermedia » au niveau
du client pour une interopérabilité correcte de l’ensemble du produit-logiciel. Pour
matérialiser l’HATEOAS, le livre de Yener Murat et Theedom Alex (2015) a été très
explicite. Il nous a beaucoup aidé surtout grâce aux exemples de codes fournis.
Figure 15 – Extrait du code implémentant la méthode Hypermedia (HATEOAS)

sur 54
Figure 16 – Extrait du code implémentant la classe LinkResource
4.4 Page d’accueil global et deux autres pages d’accueil secondaires de notre produit-
logiciel (côté serveur et côté client).
Figure 17 – Page d’accueil global de notre produit-logiciel.

sur 54
Figure 18 – Page d’accueil secondaire côté client.
Figure 18 – Page d’accueil secondaire côté serveur.
5 Conclusion
5.1 Eléments finaux de discussions
Derrière cette activité collaboratrice, nous sommes donc parvenus à comprendre davantage les
bases programmatiques de la création et de la mise en œuvre d’un web service de type
RESTful avec l’IDE Netbeans qui fonctionne et supporte ainsi l’écosystème Java EE dans son
ensemble. Nous avons aussi compris comment on peut arriver à faire consommer les

sur 54
différentes ressources d’un web service via une autre application web implémentée comme
client au serveur. Ici, la nature orientée annotation de l’API JAX-RS nous a été d’une très
grande utilité grâce surtout à sa correspondance paradigmatique avec des nombreuses
applications web modernes développées sous d’autres langages de programmation, le cas du
langage C# ou PHP, etc. En plus, même si la compréhension de cet API n’a pas été du tout
facile d’un seul coup, elle nous a également permis au final de configurer avec facilité les
différentes fonctionnalités Back-end et Front-end retenues de notre produit-logiciel.
Derrière ce point de vue conceptuel, nous avons aussi fait de sorte que la modélisation de
l’ensemble de notre produit-logiciel, avec la notation UML utilisé, reste indépendante de
l’IDE et/ou de la plateforme d’exécution à utiliser car nous pourrions décider plus tard de
basculer cette solution dans une autre plate-forme d’exécution sans faire des modifications
conceptuelles. Pour rappel, il faut noter qu’une plate-forme d’exécution englobe à la fois les
langages de programmation (Java, C++, C#, etc.) et les serveurs d’applications (J2EE, PHP,
EJB, .Net, etc.). Son usage dans notre code a alors facilité la mise en œuvre des différentes
fonctions, ressources ou services RESTful attendues.
En se référant à notre modeste expertise en C#, nous dirions que l’ensemble du produit-
logiciel implémenté semble être non achevé ou pas totalement complet. Qu’à cela ne tienne,
avec la clôture de ce projet, notre produit-logiciel dispose alors d’une abstraction de haut
niveau sur l’URI de base défini ; l’URI qui nous a voire permis d’ajouter facilement des
fonctionnalités qui ont simplifié par la suite la construction des différentes ressources ou
services, mais aussi des autres packages ou dépendances cibles accompagnant ledit produit (le
cas de repository, exceptions, entity, etc.). L’avantage supplémentaire lié à tous ces ressources
et packages ou entités typées créées est observable à partir de l’intégration de différents
modules fonctions ou méthodes, et cela, suivant les fonctionnalités souhaitées. Ceci permet
alors aux utilisateurs de pouvoir utiliser les différentes méthodes d’invocation HTTP
implémentées dans notre code et qui permettent voire aussi de tracer l’objet créateur des
différents évènements. Les invocations HTTP en question peuvent également être exécutées
séparément. Du côté serveur, notre web service est ainsi l’endroit où les différentes méthodes
ou contrats de services HTTP ont été les plus respectés, et cela, afin de permettre au côté
client de consommer aisément les ressources mises à sa disposition (cf. notion
d’interopérabilité). L’API JAX-RS, qui a servi comme interface de programmation ou
librairie de notre produit-logiciel via sa pléthore de fonctionnalités et annotations, nous a
également offert un grand contrôle sur la communication et la gestion de différentes
ressources serveur et sur l’interaction la plus riche avec l’application cliente (avec prise en
charge de traitement asynchrone).
Au début du développement, cela nous a un peu semblé flou et stressant car les fichiers
pom.xml et web.xml, qui s’appuient sur le moteur de production utilisé, à savoir le MAVEN,
présentaient des erreurs qui nous ont même poussé à penser carrément changer de technologie
ou d’écosystème. Il y avait en effet une question de compréhension exacte de comment écrire
ou personnaliser les fichiers pom.xml et web.xml créés ou générés au niveau de l’IDE
Netbeans, et cela, dans le but de créer un web service de type RESTful tournant avec le
moteur MAVEN. Toutefois, nous avons tenu bon et la personnalisation a été un succès après
la lecture de la documentation officielle sur le net (https://jcp.org/en/home/index,
https://maven.apache.org/, etc.) et des quelques exemples de code sur d’autres sites web
également. Cette documentation et ces quelques exenples de code nous ont donc été
également d’une grande utilité pour le reste. Parce que nous parlions de la documentation,
nous faisons aussi noter qu’au cours des différentes phases de notre projet, le contenu de notre
rédaction technique a été amélioré de manière itérative sur Google Drive. Cette amélioration
consistait en une reconstitution claire des besoins fonctionnels et à la création des diagrammes
de cas d’utilisation, d’activité, de séquence et de classes, mais aussi des autres éléments tels

sur 54
que les précisions sur les bouts de code source, les tests, les quelques images capturées du
produit-logiciel, etc. Honnêtement, la proposition d’utiliser le Github (https://github.com/) ou
le GitLab (https://about.gitlab.com/) était aussi avancée pour leur wiki et leur version de
gestion offerts mais nous n’avons pas trouvé opportun car cette activité collaborative était
d’abord avant tout un projet d’apprentissage pédagogique et non sociale qui ne pouvait être
disponible ou visible en ligne qu’une fois finalisé et validé par le tuteur du module de cours.
Ayant un profil partagé en administration avec certains amis ou collègues pour des intérêts
professionnels autres que Java, un autre élément de frein de leur usage était donc cette peur de
se faire corriger à chaque étape par les commentaires de différents membres de notre
communauté qui ont ainsi accès à nos espaces respectifs, et cela, avant même la fin définitive
de notre projet. Au final, nous n’aurions rien fait en autonomie car notre communauté Github
ou GitLab semble aussi disposer des expertises, ressources, solutions et exemples
professionnels fiables en JAVA en rapport avec un web service de type SOAP ou RESTful
qui peuvent ainsi offrir des fonctions, des ressources ou des services CRUD optimisées. Nous
avons donc souhaité resté un peu authentique et autonome lors de la création de notre code
dans le cadre de ce projet pédagogique.
Avec les résultats obtenus, nous pouvons toutefois dire avec modestie que nous l’avons fait
même si nous ne sommes qu’encore au début de notre retour sur l’écosystème Java EE, et cela
comme dit dans le chapitre 4, après plus de 12 ans de sa mise à l’écart au profit des autres
langages de programmation et Framework sur Linux, Microsoft et iOS, à savoir le C#, le PHP
et l’Angular (y compris JavaScript et Jquery), mais aussi des CMS tels que Episerver et
WordPress. Il y a donc à nouveau du chemin à parcourir pour une nouvelle aventure avec cet
écosystème JEE (chose que je n’imagine pas aujourd’hui vu mon expérience professionnelle).
D’ailleurs, je profite de ces lignes pour dire que nous avons alors connu quelques petites
difficultés lors de la mise sur pied de notre solution. Dans un premier temps, nous avons
connu un problème de communication et de logique programmatique entre les deux
ressources ou membres clés du projet. Ce problème a affecté au début notre méthodologie de
travail et notre temps calendaire. Il s’agit par exemple des horaires et des disponibilités pour
les stands up hebdomadaires sur WhatsApp. Ces derniers n’ont pas été respectés comme
prévu. Cette indisponibilité de part et d’autre a donc rendu très difficile le suivi dans le temps
de réalisation de différents sprints définis. C’est voire la raison pour laquelle nous avons
préféré ne pas détailler notre tableau initial de planning des activités dans ce rapport
technique, dont les écarts constatés présentent une interpellation, une faiblesse et un défi à
relever dans des projets futurs. Hormis cette faiblesse, notre méthode de travail nous a
toutefois permis de continuer à travailler en étroite collaboration ou en coopération, grâce aux
cinq valeurs Scrum qui sont intégrés. Une autre difficulté ce que nous n’avions pas la même
approche d’écriture de code ou de logique de programmation. Pour pouvoir contourner cette
faiblesse, nous sommes arrivés sur la conclusion que nous ne pourrions écrire ou s’inspirer
d’un code que si nous le comprenons et savons l’expliquer à l’autre dans toutes ses tournures.
Ce concept paradigmatique arrêté a semblé très importante pour nous ; surtout pour un bon
échange des compétences dans une sorte de « pair programming » virtuel et pouvoir produire
au final une application originale avec des fonctions et/ou des méthodes fiables et optimisées
même si certaines d’entre elles pourraient être inspirées des exemples disponibles sur le net et
écrits par d’autres développeurs (cf. « Stack Overflow : https://stackoverflow.com » du réseau
de sites de Stack Exchange, « Code Project https://www.codeproject.com/ », « CodePen :
https://codepen.io/ », « Css-tricks : https://css-tricks.com/ », « W3schools :
https://www.w3schools.com/ » géré en Norvège par la firme Refsnes Data, etc.). En dehors de
ces deux difficultés exposées, le Bean validation et l’HATEOS ont été mis sur pied avec
moins d’efforts. L’authentification de l’utilisateur de notre produit-logiciel n’a pas été
finalisée complètement. Seule la méthode de création d’un utilisateur et celle d’accès aux
ressources avec un password et un login ont été implémentées (figure 18 et figure 19). Les

sur 54
méthodes de mise à jour et de suppression d’un profil utilisateur n’ont pas été implémentées
(nous l’avons fait sciemment33
). Le sorting et/ou le filtrage (réarrangement) des notes par
échéance/couleur/priorité n’ont pas été totalement finalisés par question de timing.
Néanmoins, nous avions tant soit peu relevé les autres défis en faisant, par exemple, que
l’hypermédia, en tant que moteur de l’état de notre produit-logiciel, puisse permettre au client
de naviguer à travers ce dernier sous la forme de liens HTTP générés par la partie Back-end
(le web service et/ou serveur). Dans tout le cas, vaut mieux un produit-logiciel non finalisé
qu’un produit-logiciel finalisée mais avec des fonctionnalités moins fiables ou corrompues et
ne respectant pas les différents users stories définis. Il faudra également noter que nous avons
réalisé les différents tests unitaires et le débogage du code JAVA de façon manuelle car ne
maîtrisant pas parfaitement l’utilitaire JUnit et l’approche TDD sous Java. L’apprentissage de
cet utilitaire et l’implémentation de l’approche TDD sous Java allaient encore nous prendre du
temps. Ce sont donc ces différents services ou fonctionnalités non finalisées et réalisées en
partie qui seront corrigées et réalisées dans le futur si nous arrivons à dégager du temps dans
nos obligations professionnelles actuelles.
5.2 Perspectives
Via cette activité pédagogique collaborative, nous venons de confirmer encore une fois de
plus la facilité qui s’offre aujourd’hui aux développeurs web de pouvoir mettre également en
œuvre des web services ou des styles d’architecture de type RESTful sous un environnement
de développement donné et, dans le cas qui était notre, particulièrement sous l’IDE NetBeans
qui fonctionne sous l’écosystème Java EE. Avec l’utilisation en masse des objets connectés et
de l’Internet des objets (IoT), les web services, particulièrement le RESTful, peuvent être
donc utilisés sur n’importe quelle plateforme technologique pour faciliter la sécurité, la
fiabilité et la gestion de tous les échanges ou partages d’informations entre les ordinateurs
dans un réseau de communication. Avec toutes ces facilités offertes, le RESTful a encore des
bons jours devant lui et va encore demeurer la plus populaire pendant très longtemps. Sa
maîtrise d’implémentation ouvre donc la voie aux différents développeurs web à des
innovations futures dans l’univers de l’Internet et/ou du web qui pilote actuellement plusieurs
secteurs d’activité. En rapport avec le modèle d’objets et de données de notre produit-logiciel,
nous devrions donc faire de sorte que tout accès à la base de données, par des potentiels
utilisateurs, soit géré réellement par le SGBD MySQL lors de la mise en production et que
soit également finalisé le codage de sorting et/ou filtrage (réarrangement) des notes par
échéance/couleur/priorité. Le manuel d’utilisation devrait aussi ne pas être omis.
Pour terminer, nous comprenons que le tuteur de ce module de cours a une préférence de
l’écosystème Java EE (Netbeans, Android Studio, etc.) et il reste le maître à bord de son
module. Mais, il serait mieux de pouvoir laisser le choix libre aux membres de différents
projets ou activités pédagogiques collaboratives futures de pouvoir développer un produit-
logiciel avec la technologie dont ils ont la maîtrise et/ou vont se sentir plus à l’aise (le cas de
C# et ASP .Net, de PHP et Laravel et d’Angular/TypeScript pour ce qui nous concerne) au
lieu de pouvoir en imposer une (un des facteurs de succès dans l’innovation technologique).
Nous aurions donc fait une application web professionnelle et digne à un temps raisonnable
car nous n’aurions pas à lire de manière folle mais aussi à apprendre et à créer au même
moment que nous développions. Oui, apprendre à nouveau un langage que nous avons
abandonné il y a plus de 10 ans.
33
Il a été fait sciemment car, suivant la dynamique actuelle de besoins des clients ou utilisateurs, il est même
devenu aujourd’hui difficile à un commanditaire ou à un client d’exprimer à un seul coup un besoin pertinent et
voire de le formaliser comme un objectif transformable ou déclinable. Un produit-logiciel fabriqué pousuit
désormais une amélioration continue.

sur 54
6 Références bibliographiques
6.1 Ouvrages
- ALLAMARAJU Subbu, « RESTful Web Services Cookbook », First Edition, O’Reilly
Media, 2010.
- BLANC Xavier et MOUNIER Isabelle, « UML 2 pour les développeurs : cours et
exercices corrigés », Eyrolles, Paris, 2006.
- COHN Mike, « Succeeding with Agile : Software Development Using Scrum »,
Addison-Wesley Professional, 2010
- GRIFFITHS Dawn and GRIFFITHS David, Head First Android Development. A
Brain-Friendly Guide, First Edition, O’Reilly, 2015.
- GROSJEAN Pascal, MOREL Médéric, NOLIN Simon-Pierre et PLOUIN Guillaume,
« Performance des architectures IT : Comprendre, résoudre et anticiper », 2ième
édition, Collection InfoPro, Dunod, Paris, 2011
- McGARY Charlotte, « SQL By Example : Learn how to create and query databases in
eigth easy lessons ! », Kindle Edition, 2017.
- MORLEY Chantal, « Management d’un projet système d’information : principes,
techniques, mise en œuvre et outils », 7ième
édition, Collection InfoPro, Dunod, Paris,
2012.
- PRINTZ Jacques, « Architecture logicielle : Concevoir des applications simples, sûres
et adaptables », Collection Etudes et Développement, Dunod, Paris, 2012.
- RICHARDSON Leonard and RUBY Sam, « RESTfull Web Services », First Edition,
O’Reilly, 2007.
- ROQUES Pascal, « UML 2 par la pratique », 6ième
édition, Collection Best of
Eyrolles, Eyrolles, Paris, 2011.
- TARDIEU Hubert, NANCY Dominique et PASCOT Daniel, « Conception d’un
système d’information : construction de la base des données », Les éditions
d’organisation, Paris, Gaëtan Morin Editeur, Québec, 1980.
- VAUQUIER Dominique, « Plan qualité du logiciel et des services Internet »,
AFNOR, Saint- Denis-La-Plaine Cedex, 2003.
- VICKOFF Jean-Pierre, « Méthode Agile : les meilleures pratiques, compréhension et
mise en œuvre », Edition QI, RAD Sarl, 2009.
- WEBBER Jim, PARASTATIDIS Savas, ROBINSON Ian, « REST in Practice:
Hypermedia and Systems Architecture », First Edition, O’Reilly Media, 2010.
- YENER Murat et THEEDOM Alex, « Professional Java EE Design Patterns », First
Edition, Wrox, 2015.
- TIDWELL Doug, SNELL James, and KULCHENKO Pavel, « Programming Web
Services with SOAP », First Edition, O’Reilly, 2001.
6.2 Travaux, articles, revues et autres ressources
- ANDROID Studio, « Ressources officielles en ligne pour développeurs »,
https://developer.android.com/studio/intro/index.html, Consulté en Mars et Avril
2018.
- BENJAMIN L., « PhoneGap, création d'applis mobiles multiplateforme », 16 octobre
2014, http://www.alsacreations.com/tuto/lire/1646-introduction-phonegap.html,
Récupéré en ligne sur alsacréations en mars 2018.
- CATHALA C., « Les nouveautés des applications Windows phone Silverlight 8.1. »,
04 avril 2014, http://blog.soat.fr/2014/04/les-nouveautes-des-applications-windows-
phone-silverlight-8-1/, Récupéré sur Soat blog en février 2018.

sur 54
- DAHAN Olivier, « Cross-plateforme : la mise en page sous Android (de Xaml à
Xml) », 2013, http://www.e-naxos.com/Blog/post/Cross-plateforme-la-mise-en-page-
sous-Android-(de-Xaml-a-Xml).aspx, Consulté en Mars 2018.
- FOWLER Martin, « Richardson Maturity Model. Steps toward the glory of REST »,
march 2010, https://martinfowler.com/articles/richardsonMaturityModel.html,
Consulté en Novembre 2017.
- IVINZA LEPAPA Alphonse Christian, « L’architecture Client-Serveur : les
médiateurs ou middleware », Working paper DES télématique, ULB, 1997
- DRISS Maha, JAMOUSSI Yassine, MOHA Naouel, JEZEQUEL Jean-Marc et BEN
GHEZALA Henda Hajjami, « Une approche centrée exigences pour la composition
de services web », Revue des Sciences et Technologies de l’Information – Série ISI :
Ingénierie des Systèmes d’Information, Lavoisier, 2011, 16 (2), pp.97-125.
- MBUTA IKOKO Dodi Alphonse, « les modèles techniques et marketing actuels pour
la commercialisation des services personnalisés en ligne : présentation et éléments
synthèse de compréhension », Working Paper, Université de Picardie Jules Verne
(UPJV), UFR des Sciences, Avril-2017.
- les modèles techniques et marketing actuels pour la commercialisation des services
personnalisés en ligne : présentation et éléments synthèse de compréhension
- MBUTA IKOKO Dodi Alphonse, « Eléments d’élaboration d’un modèle de tests de
vérification et de validation dans un projet de développement mixte : l’exemple de
Payment Manager 1.0 », Les cahiers de BSD n°4, mai-2011, 36 pages.
- MBUTA Ikoko Dodi Alphonse et RIZWAN Shan, Infrastructure technologique de
l’Unité d’Exécution du Programme National du Désarmement, Démobilisation et
Réinsertion (UEPN-DDR) : Redéfinition de la politique sécuritaire », Workking
paper, UEPN – DDR, sous la supervision de TOMS Martin (BioID Technologies SA),
inédit, Kinshasa, Juillet 2009.
- MBUTA IKOKO Dodi Alphonse, « Le site web informationnel de l’Unité d’Exécution
du Programme National du Désarmement, Démobilisation et Réinsertion (UEPN-
DDR) : éléments retenus pour sa conception, sa mise en œuvre et son succès »,
Working Paper, UEPN-DDR et Université Libre de Kinshasa (ULK), FSEG-DIG,
Kinshasa, Kinshasa, Octobre 2007 ;
- MBUTA IKOKO Dodi Alphonse, « La mise en place d’un ERP : CS/3 de SAGE vu
comme solution progicielle pour l’intégration des systèmes d’information à 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, Mémoire – Projet, 2003.
- MBUTA IKOKO Dodi A., « La mise en place d’un EDI comptable et financier à
l’AMI-Congo (Agence Maritime Internationale Congolaise) : analyse des besoins,
proposition et implémentation de la solution », Université Libre de Kinshasa, Faculté
des Sciences Economiques et Gestion, Département d’Informatique de Gestion, TFC,
2001.
- PAUMARD José, « JAVA en ligne », http://blog.paumard.org/cours/java/, Consulté en
ligne entre Octobre 2017 et Janvier 2018.
- PAUMARD José, « JAVA Persistence API », http://blog.paumard.org/cours/jpa/,
Consulté en ligne entre Février 2018 et Juin 2018.
- RICHARDSON Leonard, « Justice Will Take Us Millions Of Intricate Moves. Act
Three : The Maturity Heuristic », 2008,
https://www.crummy.com/writing/speaking/2008-Qcon/act3.html, Consulté en
Novembre 2017.
- SANTIAGO & PERICAS Geertsen (Editors), « JAX-RS: Java API for RESTful. Web
Services (specifications) », Version 2.0 Final Release, 2013.

sur 54
7 Annexes
7.1 Notice d’installation et de déploiement (Non réalisé faute de temps mais ça devrait
suivre la logique de cas d’utilisation textuelle présentée et mettre à jour si possible ces
derniers)
7.2 Code source complet (web service et application cliente).
7.3 Plan de Développement Logiciel

Dodi_Mbuta_La création d'un web service : « Note Reminder » _ Dodi Mbuta

Contenu connexe

Tendances

Similaire à Dodi_Mbuta_La création d'un web service : « Note Reminder » _ Dodi Mbuta

Plus de Daniella Mbuta

Dodi_Mbuta_La création d'un web service : « Note Reminder » _ Dodi Mbuta