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.

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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

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

Ähnlich wie Dodi_Mbuta_La création d'un web service : « Note Reminder » _ Dodi Mbuta (20)

Mehr von Daniella Mbuta

Mehr von Daniella Mbuta (6)

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