Memoire Josue Numbi Master 2 Ec2lt

REPUBLIQUE DU SENEGAL
Ecole Centrale des Logiciels Libres et de

Télécommunications
MEMOIRE DE FIN DE CYCLE
Pour l’obtention du : Diplôme de Master en Télécommunications et Réseaux
SUJET : Conception et Déploiement d’une Plate-forme de Téléconsultation
Lieu de stage : Groupe RTN
Présenté et soutenu par: Professeur Encadreur:
Josué NUMBI LUHEHO Dr. Samuel OUYA
Année Universitaire: 2017-2018

Mémoire de fin de cycle Master 2017-2018
DEDICACES
Je dédie ce mémoire à :
 Mon père Justin NUMBI NZUZI, qui peut être fier et trouver ici le résultat de longues années de
sacrifices pour m'aider à avancer dans la vie. Merci pour l'éducation et le soutien permanent venu de
toi, reçois à travers ce travail aussi modeste soit-il, l'expression de mes sentiments et de mon
éternelle gratitude ;
 Ma mère Chantal KENGE NGIMBI, qui a œuvré pour ma réussite, de par son amour, son soutien,
tous les sacrifices consentis et ses précieux conseils ;
 Mes frères et sœurs, qui m'ont encouragé tout au long de mes études, malgré la distance, ils n'ont
cessé de m'offrir leur amour et leur soutien infaillible;
 Mes proches, qui n'ont cessé d'être pour moi des exemples de persévérance, de courage et de
générosité ;
 Mes professeurs de l'EC2LT qui doivent voir dans ce travail la fierté d'un savoir bien acquis.
Conception et Déploiement d’une Plate-forme de Téléconsultation II

REMERCIEMENTS
Avant toutes choses, je tiens à rendre grâce à Dieu le Tout Puissant, le miséricordieux pour la force
qu'il m'a accordé dans les moments difficiles d'éditer ce mémoire, pour la patience et courage durant ces
longues années d’études.
J’exprime ma plus profonde reconnaissance à :
 Tout le corps professoral de l’EC2LT, qui ont su nous donné une formation didactique et
appréciable durant toute notre cursus, par la qualité de leurs enseignements et conseils ;
 Mes parents, qui m’ont toujours motivé sans cesse à devenir meilleur ;
 Mes frères et sœurs, qui m’ont aidé à avancer dans les moments difficiles ;
 Mon encadreur Docteur Samuel OUYA, pour sa disponibilité, rigueur et recommandation ;
 Mes amis et amies de par le monde qui n’ont cessé de m’encourager ;
 ISMAEL, pour sa disponibilité et son aide durant la réalisation de ce travail ;
 Tous mes compagnons de promotion ;
 Tous ceux qui, de près ou de loin, m’ont aidé à la réalisation de ce travail.
Conception et Déploiement d’une Plate-forme de Téléconsultation III

AVANT-PROPOS
L’Ecole Centrale des Logiciels Libres et de Télécommunications (EC2LT) de Dakar en partenariat

avec le groupe RTN (Réseaux et Techniques Numériques) offre une formation en Master de niveau BAC+5
adaptée aux secteurs des Télécommunications et des technologies en Réseaux permettant d’acquérir une
double compétence en Réseaux et en Télécommunications : le Diplôme de Master en Réseaux et
Télécommunications.
L’objectif de cette formation est de former des étudiants doués d’aptitudes professionnels,
compétents et capables de répondre aux besoins des entreprises dans les domaines des Réseaux
Informatiques et des Télécommunications, de développer des applications autour des Logiciels Libres.
Ceux-ci doivent être capables de comprendre les problèmes réels posés dans les entreprises et en particulier
en Afrique, de concevoir et implémenter les solutions matérielles et logicielles basées sur les outils open
source permettant d'améliorer efficacement le vecteur de communication dans les entreprises.
La formation s’étale sur cinq ans. L’enseignement comporte des cours théoriques et pratiques ainsi
qu’un stage de fin de formation de quatre(4) à cinq(5) mois en entreprise. A la fin de ce stage, l’étudiant est
tenu de présenter devant un membre du jury un projet de mémoire. C’est dans cette optique que ce présent
travail dont le sujet s’intitule « Conception et Déploiement d’une Plate-forme de Téléconsultation » a été
réalisé au sein du département d'étude de l’entreprise RTN.
Cette société œuvre principalement dans les domaines de la gestion des projets de
Télécommunications, Réseaux et Informatiques basés sur les Logiciels Libres ayant trait aux études,
conceptions, réalisations et planifications.
Conception et Déploiement d’une Plate-forme de Téléconsultation IV

RESUME
Avec l'apparition des Technologies de l'Information et de la Communication (TIC), les

communications se sont profondément modifiées. Il en va de même dans le domaine médical, la
télémédecine est une forme de pratique médicale à distance utilisant les TIC.
Cette pratique médicale va transformer le rapport entre les patients et les médecins dans le but
d'améliorer l'accessibilité aux soins dans les zones d'accès difficile grâce aux TIC.
La rencontre physique entre un médecin et un patient n'est pas toujours nécessaire puisque des
nombreux problèmes médicaux peuvent être réglés en ligne, sans que vous ayez besoin de vous déplacer.
Par ailleurs, le présent projet a pour but de mettre en évidence la conception et le déploiement d'une
plate-forme de téléconsultation intégrant la technologie WebRTC.
La WebRTC est une technologie permettant de faire de la communication en temps réel entre les
navigateurs Web en mode peer-to-peer. Elle permet aux applications telles que les appels vocaux, vidéos,
chat, de même que les applications liées au partage des fichiers et à la visioconférence de se faire à travers
un navigateur en temps réel sans passer par des protocoles propriétaires et sans nécessité de plugins, de
téléchargement, ou d’installation.
Grâce à ce projet, nous avons conçu une plate-forme de téléconsultation en temps réel accessible à
travers les navigateurs web permettant d’effectuer la consultation à distance où ni le patient, ni le médecin
n'est présent physiquement.
Mots-clés : Télémédecine, Téléconsultation, Patient, Médecin, Dispositif médical, Diagnostic.
Conception et Déploiement d’une Plate-forme de Téléconsultation V

ABSTRACT
With the emergence of information and communication technologies (ICTs), communications have
profoundly changed. The same is true in the medical field, telemedicine is a form of remote medical practice
using ICT.
This medical practice will transform the relationship between patients and physicians in order to
improve accessibility to care in areas of difficult access through ICT.
Physical meeting between a doctor and a patient is not always necessary since many medical
problems can be solved online, without you having to move.
In addition, the aim of this project is to highlight the design and deployment of a teleconsulting
platform integrating WebRTC technology.
WebRTC is a technology that allows real-time communication between web browsers in peer-to-
peer mode. It allows applications such as voice calls, videos, chat, as well as applications related to file
sharing and videoconferencing to be done through a browser in real time without going through proprietary
protocols and without the need for plugins, download, or installation.
Thanks to this project, we have designed a real-time teleconsultation platform accessible through
web browsers allowing remote consultation where neither the patient nor the physician is physically present.
Keywords: Telemedicine, Teleconsultation, Patient, Physician, Medical Device, Diagnosis.
Conception et Déploiement d’une Plate-forme de Téléconsultation VI

TABLE DES MATIERES
TABLE DES MATIERES
LISTE DES TABLEAUX................................................................................................................................. 9
LISTE DES FIGURES ................................................................................................................................... 10
SIGLES ET ABREVIATIONS....................................................................................................................... 11
INTRODUCTION .......................................................................................................................................... 12
I. Présentation Générale ............................................................................................................................... 14
I.1. Présentation de la Structure d’accueil ............................................................................................... 14
I.1.1. Présentation de L’Entreprise RTN ............................................................................................ 14

I.1.2. Mission de RTN......................................................................................................................... 14
I.1.3. Organigramme de RTN ............................................................................................................. 15
I.1.4. Domaine d’activité .................................................................................................................... 16
I.2. Présentation du Projet ....................................................................................................................... 18
I.2.1. Contexte............................................................................................................................................................... 18
I.2.2. Problématique ............................................................................................................................ 19
I.2.3. Objectifs et démarche à suivre................................................................................................... 20
II. Généralités sur la Télémédecine .................................................................................................................................... 21
II.1. Qu’est-ce que la Télémédecine ? .......................................................................................................................... 21
II.2. L’intérêt de la Télémédecine .................................................................................................................................. 22
II.3. Les composantes de la Télémédecine .................................................................................................................. 22
II.3.1. La Téléconsultation .......................................................................................................................................... 22
II.3.2. La Télé-expertise .............................................................................................................................................. 22
II.3.3. La Télésurveillance .......................................................................................................................................... 22
II.3.4. La Téléassistance .............................................................................................................................................. 22
II.4. Les dispositifs médicaux connectés ..................................................................................................................... 23
Conception et Déploiement d’une Plate-forme de Téléconsultation VII

II.5. Avantages et Inconvénients .............................................................................................................. 25
III. Présentation de WebRTC ......................................................................................................................... 27
III.1. Définition et Principes ...................................................................................................................... 27
III.2. Architecture générale de WebRTC .................................................................................................. 28
III.3. Fonctionnement ................................................................................................................................ 30
III.3.1. Architecture de fonctionnement ................................................................................................ 30
III.3.2. La Signalisation ......................................................................................................................... 31
III.3.3. La Traversée de NAT ................................................................................................................ 33
III.4. La Description de session SDP ........................................................................................................ 41
III.5. Les Protocoles de transport (SRTP, RTP, RTCP) ............................................................................ 42
III.6. Les Codecs ....................................................................................................................................... 45
III.7. Les APIs ........................................................................................................................................... 46
IV. Analyse et Conception de la Plate-forme ................................................................................................. 52
IV.1. Architecture et Fonctionnement ....................................................................................................... 52
IV.2. Choix des outils et technologies ...................................................................................................... 53
IV.2.1. Les Langages de programmation .............................................................................................. 53
IV.2.2. Les Protocoles http et WebSocket ............................................................................................. 55
IV.2.3. La Base de données (Mongo DB) ............................................................................................. 56
IV.3. Conception du système..................................................................................................................... 57
IV.3.1. Modélisation du système........................................................................................................... 57
IV.3.2. Environnement de développement ............................................................................................ 59
IV.4. Architecture du déploiement ........................................................................................................... 62
IV.5. Présentation des résultats ................................................................................................................ 63
CONCLUSION ............................................................................................................................................... 67
BIBLIOGRAPHIE ET WEBOGRAPHIE ...................................................................................................... 68
Conception et Déploiement d’une Plate-forme de Téléconsultation VIII

LISTE DES TABLEAUX
LISTE DES TABLEAUX
Tableau II.1 : Comparaison des codecs classiques et WebRTC.....................................................................45
Conception et Déploiement d’une Plate-forme de Téléconsultation

LISTE DES FIGURES
LISTE DES FIGURES
Figure I.1 : Organigramme de RTN .................................................................................................... 15
Figure II.1 : Architecture générale de WebRTC ................................................................................. 28
Figure II.2 : Architecture de Fonctionnement de WebRTC ............................................................................30
Figure II.3 : Etablissement d’une session peer-to-peer entre deux navigateurs .........................................32
Figure II.4 : Traversée de NAT par un serveur STUN ......................................................................................34
Figure II.5 : Demande et Réponse entre un client et un serveur STUN ............................................. 35
Figure III.1 : Traitement des flux audio et vidéo par GetUserMedia ..........................................................47
Figure III.2 : Fonctionnement de MediaStream ..................................................................................................49
Figure IV.1 : Architecture de fonctionnement de la plate-forme ...................................................................52
Figure IV.2 : Architecture d’accès à la plate-forme ...........................................................................................53
Figure IV.3 : Communication entre un navigateur et un serveur http ..........................................................55
Conception et Déploiement d’une Plate-forme de Téléconsultation X

SIGLES ET ABREVIATIONS
SIGLES ET ABREVIATIONS
EC2LT Ecole Centrale des Logiciels Libres et de Télécommunications

RTN Réseaux et Techniques Numériques
WebRTC Web for Real Time Communication
API Application Programming Interface
DM Dispositif Médical
USB Universal Serial Bus
LED Light-Emitting Diode
WWW World Wide Web
HTML5 HyperText Markup Language 5
W3C World Wide Web Consortium
NAT Network Adress Translation
RTCweb Real Time Communication on Web
STUN Simple Traversal of UDP through NAT
ICE Interactive Connection Establishment
TURN Traversal Using Relay NAT
SIP Session Initiation Protocol
MGCP Media Gateway Control Protocol
ToIP Telephony over Internet Protocol
IP Internet Protocol
UDP User Datagram Protocol
IETF Internet Engineering Task Force
XMPP eXtensible Messaging and Presence Protocol
HTTP HyperText Transport Protocol
RTCP Real Time Control Protocol
RTP Real Time Protocol
FQDN Fully Qualified Domain Name
DNS Domain Name Server
URL Uniform Resource Locator
SDP Session Description Protocol
RTSP Real Time Streaming Protocol
SRTP Secure Real-Time Protocol
TLS Transport Layers Security
DTLS Datagram Transport Layer Security
IO Input Output
UML Unified Model Language
CSS3 Cascading Style Sheet 3
NoSQL No Structured Query Language
JSON/BJSON JavaScript Object Notation/Binary JavaScript Object Notation
Conception et Déploiement d’une Plate-forme de Téléconsultation XI

INTRODUCTION
INTRODUCTION
Actuellement, les technologies de l'information et de la communication ont connu un essor

remarquable tant dans les domaines de télécommunications que d'informatique. Les progrès technologiques
se sont traduits par le développement d'une multitude d'applications et services dans tous les secteurs
notamment dans le domaine de la télémédecine.
En effet, les technologies de l'information et de la communication permettent d'envisager de

nouvelles façons d'exercer la médecine notamment la téléconsultation.
La téléconsultation est une consultation médicale qui met en relation, à distance et en temps réel, un
patient et un médecin. Elle permet la consultation et le suivi du patient à distance.
Durant ces dernières années, on assiste à une grande évolution du Web, qui est dotée des
fonctionnalités avancées avec la capacité de faire passer de la voix et de la vidéo via des navigateurs Web.
C'est dans ces perspectives que Google a lancé le projet WebRTC qui intègre les fonctions de
communications temps réel peer-to-peer dans les navigateurs Web avec la première implémentation de l'API
WebRTC. Il se focalise sur des protocoles et des codecs existants.
Ainsi, le projet suivant a été proposé : « Conception et Déploiement d'une Plate-forme de

Téléconsultation » ; dont l'étude et la réalisation font l'objet d'obtention du diplôme de fin de cycle en
Master Télécommunications et Réseaux.
Le but de ce projet est de concevoir et déployer une plate-forme de téléconsultation permettant au

médecin d’effectuer, à distance et en temps réel une consultation avec un patient.
C'est dans cette optique que la démarche pour mieux appréhender les contours de ce projet nous a
amenés à structurer le présent document en quatre (04) chapitres :
Conception et Déploiement d’une Plate-forme de Téléconsultation 12

 Le premier chapitre consiste à faire une présentation générale : Nous aborderons la

présentation de la structure d’accueil et la présentation du projet ;
 Le deuxième chapitre parlera des généralités sur la télémédecine ;
 Le troisième chapitre consiste à faire une étude sur la technologie WebRTC, la
signalisation dans le WebRTC ainsi que les codecs ;
 Le quatrième chapitre abordera la conception de la plateforme, le choix de différents
outils informatiques utilisés et enfin la mise en œuvre.

Chapitre I
I. Présentation Générale
I.1. Présentation de la Structure d’accueil
I.1.1. Présentation de L’Entreprise RTN
RTN est une société dirigée par une équipe de professionnels qualifiés, et est spécialisée dans le
domaine de Télécommunications, de Réseaux et de l’Informatique. Elle est composée de techniciens,
d’ingénieurs, de professeurs, spécialisés dans le domaine de l’utilisation de logiciels libres et sont centrés sur
les services informatiques, techniques numériques et de télécommunications. RTN offre un ensemble de
formations rigoureuses basées sur des supports des cours, fruits de recherches approfondies. Ces supports
testés et avérés permettent aux apprenants de la dite école d’être aussitôt opérationnels.
I.1.2. Mission de RTN
La mission de RTN vise à accroître la compétitivité de ses clients par la valorisation des composants
informatiques, logiciels et réseaux constituants le système d’information de ces derniers. Cela leur confère
des gains importants en produisant plus et mieux à budget réduit, grâce à l’exploitation de la puissance des
logiciels libres existants et ceci, sans rupture des cycles d’exploitation de service de ces entreprises et sans
remise en cause organisationnelle. Leurs principaux objectifs sont de conseiller et de former le personnel des
entreprises qui veulent disposer des logiciels libres et adaptés à leurs besoins minimisant ainsi les coûts
d’investissements en réseaux informatiques tout en leur apportant une sécurité avancée.

I.1.3. Organigramme de RTN
Figure I.1: Organigramme de RTN
RTN dispose de trois laboratoires de recherches qui sont :
 Laboratoire de Virtualisation et de Cloud Compiting (LV2C)

 Laboratoire de Technologies de l’Information et de la Communication pour les
Enseignements (LTICE)
 Laboratoire de NGN et Applications Mobiles


I.1.4. Domaine d’activité
La société RTN offre une palette de services dans le domaine de la technologie de l’information et de
la communication. Les services de RTN sont orientés Open Source et sont réalisés selon les besoins et
l'exploration des opportunités d'entreprise. Elle répond par conséquent aux problèmes réels.
Ainsi, elle met également un accent sur le développement des services à valeurs ajoutées, et sur
l’interconnexion des réseaux Linux et Windows, participant de ce fait à la cohabitation et l’harmonisation
des réseaux hétérogènes Linux-Windows.
La RTN intervient aussi dans les domaines suivants :
 Conseils et orientations professionnelles pour la gestion d’un réseau d’entreprise

dynamique ;
 Formation et accompagnement des personnels d’entreprises ;
 Mise à niveau du personnel des entreprises sur les technologies de l’information et de
la communication.
La RTN dispense aussi d’un éventail de formations dont la liste non exhaustive est la suivante :
 Développement :
 Initiation à la programmation JAVA

 Android : Développement d’applications mobiles
 Développement de site Web HTML5&CSS3
 Site Web avec framework : Python&Django

 Services :
 Téléphonie sur IP avec l’IPBX open source Asterisk (SIP, SCCP, UNISTIM)
 Téléphonie sur IP avec le protocole H323
 Téléphonie sur IP avec Call Manager de Cisco
 Téléphonie sur IP avec Call Manager Express
 Interconnexion Call Manager Express-Asterisk
 IMS : De la théorie à la pratique
 Messagerie Collaborative
 L’annuaire LDAP
 Sécurité Réseaux
 Services Réseaux (DNS,DHCP,NFS,TFTP,etc)
 Certification :

 Certification JAVA
 Certification CISCO
 Certification Linux LPI 1&2
 Cœur de Réseau IP :

 MPLS : La technologie du cœur de l’operateur

 QoS : Déploiement de la qualité du service

I.2. Présentation du Sujet
I.2.1. Contexte du Sujet
L’accès aux soins des populations reste difficile dans les zones rurales ou dans les régions
éloignées car il est très compliqué d’avoir accès à un médecin ou un professionnel de la santé.
Les technologies de l’information et de la communication ont permis le développement de la

télémédecine et a donné naissance à de nouvelles formes de consultation et de diagnostic des patients : la
téléconsultation
La téléconsultation fait partie des pratiques médicales abordées par la télémédecine. C’est une
consultation médicale réalisée à distance et permet à un professionnel de santé, généraliste ou
spécialiste, de donner une consultation à distance à un patient.
La téléconsultation permet de réduire les contraintes liées au déplacement des patients et peut
être avantageux pour les personnes âgées ayant des difficultés à se déplacer pour pouvoir simplement
émettre un diagnostic.
C'est ainsi qu'il serait intéressant de mettre en place une plate-forme de téléconsultation qui va
grandement améliorer l'accessibilité médicale, particulièrement en région éloignée.
Pour cela, la révolution du web à travers la technologie WebRTC permet de faire de la

téléconsultation en utilisant les technologies du web

I.2.2. Problématique
Pendant longtemps, la consultation médicale s’est faite en se déplaçant à l’hôpital ou à domicile en

faisant appel à un médecin. Aujourd'hui, nous assistons à une révolution technologique où il est possible de
le faire à distance et en temps réel, le patient et le médecin peuvent être en contact tout en étant
physiquement à des milliers de kilomètres l’un de l’autre.
Les progrès technologiques ont profondément modifié la vision traditionnelle de la santé. La

télémédecine, et plus particulièrement la téléconsultation ont donc émergé depuis quelques années et
permettent de mettre en relation un patient et un médecin à distance, en vidéo ou audio via son ordinateur,
smartphone ou tablette.
Vous souffrez d'une maladie qui vous impose des déplacements réguliers à l’hôpital, vous habitez
dans une zone isolée où c'est difficile de vous rendre à chaque fois ; la téléconsultation est la solution idéale.
La téléconsultation permet d’améliorer la qualité de vie des patients, et réduire le plus possible les
inégalités d’accès aux soins comme pour notamment les usagers en situation d’isolement (zones rurales,
insulaires ou montagneuses).
Ce projet consiste à concevoir et déployer une plate-forme de téléconsultation dans le but de mettre
en relation un patient et un médecin puis de faciliter l’accès aux soins des populations.

I.2.3. Objectifs et démarche à suivre
L'objectif principal de ce projet de mémoire est de concevoir et déployer une plate-forme de

téléconsultation permettant de relier un patient et un médecin à distance et en temps réel via le web
en utilisant la technologie WebRTC puis de faciliter l’accès aux soins des populations.
La consultation médicale s’effectue par audio ou vidéo et le patient peut bénéficier de l’avis
médical d’un médecin.
Le démarche que nous suivrons consistera à :
 Maitriser la technologie WebRTC, les protocoles, son fonctionnement, les architectures, etc
 Maitriser l’utilisation de ses API
 Etudier de manière détaillée les protocoles de signalisation supporté par le Web tels que :
SIP, XMPP et Websocket.

Chapitre II
II. Généralités sur la Télémédecine
II.1. Qu’est-ce que la Télémédecine ?
La télémédecine est une forme de pratique médicale à distance utilisant les technologies de
l’information et de la communication. Elle met en rapport, entre eux ou avec un patient, un ou plusieurs
professionnels de santé, parmi lesquels figure nécessairement un professionnel médical et, le cas échéant,
d’autres professionnels apportant leurs soins au patient. (1)
Elle permet d'établir un diagnostic, d'assurer, pour un patient à risque, un suivi à visée préventive ou
un suivi post-thérapeutique, de requérir un avis spécialisé, de préparer une décision thérapeutique, de
prescrire des produits, de prescrire ou de réaliser des prestations ou des actes, ou d'effectuer une surveillance
de l'état des patients. (1)
Les premières expériences de télémédecine datent de 1960, lors d’une expérience de téléconsultation
réalisée par le Nebraska Psychiatric Institute, expérience justifiée par l’isolement des patients dans un Etat
américain peu peuplé. (2)
La télémédecine sera développée dans les années 1980, pour l’armée américaine, mais aussi à
destination de l’espace. C’est dans les années 1990 que se multiplient des projets d’envergure, avec le
concours et l’incitation de la Commission Européenne, jetant les bases de l’e-santé dans les régions
européennes. (2)
Les années 2000 consolident l’expérience acquise dans les différents secteurs de l’e-santé, et l’on
peut penser que la décennie à venir concrétisera les développements et les réalisations de cette discipline. (2)

II.2. L’intérêt de le Télémédecine
Comme on peut le constater, la télémédecine n’est pas une nouvelle discipline médicale mais un
nouveau mode d’exercice de la médecine, pouvant s’appliquer à chacune des spécialités, dont l’objectif
est lors d’une prise en charge médicale, de minimiser les problèmes de distance entre différents
intervenants en faisant voyager les données médicales plutôt que les patients. (3)
 Développer les soins à domicile

 Limiter les déplacements aux personnes âgés ou handicapés
 Faciliter l’accès aux soins dans les zones d’accès difficile
 Raccourcir les délais d’attente
 Apporter un soutien psychologique aux malades, de sorte à ce qu’ils ne se sentent plus
seuls face à leur maladie
 Faciliter la concertation entre médecins
II.2. Les composantes de la Télémédecine
 La téléconsultation : Cette pratique de télémédecine permet à un professionnel médical de

consulter un patient à distance. Dans le cadre d’une téléconsultation, le patient peut avoir à ses
côtés un professionnel de santé assistant le professionnel à distance ainsi qu’un psychologue,
 La télé expertise : Cette pratique de télémédecine consiste, pour un professionnel médical, à

solliciter l’avis d’un ou de plusieurs professionnels médicaux experts à partir d’éléments du
dossier médical du patient,
 La télésurveillance médicale : Cette pratique de télémédecine permet à un professionnel de santé

d’interpréter à distance les données nécessaires au suivi médical du patient pour prendre des
décisions sur sa prise en charge,
 La téléassistance médicale : Cet acte qui relève de la télémédecine permet à un professionnel

médical d’assister à distance un autre professionnel au cours de la réalisation d’un acte. (4)


II.3. Les dispositifs médicaux connectés
Aujourd'hui les technologies de l'information et les objets connectés permettent de réaliser des
consultations médicales à distance et de maintenir des patients à domicile. Il est possible grâce à ces
dispositifs médicaux connectés, que le médecin puisse poser un diagnostic à distance.
II.3.1. Définition
Un dispositif médical (DM) est tout instrument, appareil, équipement, matière ou autre article,
utilisé seul ou en association, utilisé chez l'être humain pour le diagnostic, prévention, traitement d'une
maladie, d'une blessure ou d'un handicap, ou d'étude ou remplacement ou modification de l'anatomie
ou d'un processus physiologique. (5)
Il est destiné par le fabricant à être utilisé chez l'être humain à des fins médicales et dont
l'action principale voulue n'est pas obtenue par des moyens pharmacologiques, immunologiques,
métaboliques, mais dont la fonction peut être assistée par de tels moyens. (5)
II.3.2. Quelques dispositifs médicaux connectés et ses caractéristiques
 Thermomètre USB
Le thermomètre USB détecte l'humidité et la température de l'air et la mémorise internement.

Ce thermomètre USB en format réduit et une grande mémoire (jusqu'à un max de 32000 valeurs /
16.000 valeurs par paramètre) sert surtout au registre prolongé des données (comptoirs réfrigérés des
supermarchés, transports réfrigérés, entrepôts, salles climatisé pour PC). (6)
Le thermomètre USB fonctionne comme enregistreur de données autonome qui enregistre les
valeurs climatologiques dans les espaces de temps désirés. Ce thermomètre USB peut transmettre
toutes les valeurs à un ordinateur. Le registre du thermomètre USB peut s'activer manuellement. Il est
aussi possible de programmer préalablement le thermomètre USB (temps de début, fin, date et part de
mesure) et le laisser enregistrer. Une fois les valeurs transmises, vous pourrez les analyser dans
l'ordinateur. (6)

De plus, le logiciel inclus dans la livraison du thermomètre USB calcule le point de rosée.
L'horloge interne avec date du thermomètre USB permet à l'usager d’attribuer avec précision les
résultats. Une des caractéristiques spéciales de ce thermomètre USB est l'alimentation par batterie
lithium interne de longue durée de 3,6 V. Selon l'usage, la durée de vie de cette batterie de
thermomètre USB est d'environ un an. (6)
 PodoScope
Le podologue et son patient peuvent voir les images en temps réel sur un ordinateur portable, une
tablette ou un ordinateur de bureau. Une source de lumière externe n'est pas nécessaire à l'étude, car le
PodoScope intégrés de la lumière avec huit LED blanches lumineuses. Le PodoScope et son éclairage sont
alimentés via le port USB, de sorte que le PodoScope est toujours prêt et ne dépend pas de piles. (7)
 Stéthoscope USB
Le nouveau stéthoscope PCP-USB se connecte via le port USB d'un PC, d'un MAC ou d'un appareil
mobile et crée un canal audio identifiable dans le périphérique. (8)
 Convivial. Le patient, l'examinateur ou le professionnel de la santé, se branche dans le

stéthoscope à un port USB d'un PC ou d'une tablette.
 Pratique pour le clinicien. Seuls les écouteurs sont nécessaires. Des réglages de volume
faciles et des filtres audio sont inclus pour faciliter la qualité et la clarté du son.
 FDA approuvé. Contrairement à certains stéthoscopes téléphoniques sur le marché, les PCP-1
et PCP-USB sont approuvés par la FDA pour transmettre des données sur Internet. Les deux
sont considérés comme des dispositifs médicaux de classe II par la Food and Drug
Administration (FDA).
 Capacités de technologie vidéo. Ces stéthoscopes peuvent être déployés aux côtés de tout
système de vidéoconférence. Le stéthoscope PCP-USB n'a pas besoin d'une carte audio et,
par conséquent, fournit aux patients et aux cliniciens une interface vraiment simple et
transparente.

II.4. Avantages et Inconvénients
II.4.1. Avantages
 Beaucoup de patients se sentent mal à l'aise d'aller à l'hôpital ou au cabinet médical. Ce système
crée une communication entre les patients et les professionnels de la santé qui maintiennent la
commodité et l'engagement. De plus, grâce à la télémédecine, les informations et les images
médicales sont gardées confidentielles et transférées en toute sécurité d'un endroit à l'autre. Ainsi,
les gens peuvent croire à ce système et se sentir à l'aise pour demander de l'aide. (9)
 Cela permet d'économiser des vies dans les situations d'urgence, alors qu'il n'y a pas de temps
pour emmener le patient à l'hôpital.

 Dans de nombreuses communautés rurales ou dans des endroits éloignés ou post-catastrophe, des
soins de santé cohérents ne sont pas disponibles. La télémédecine peut être appliquée dans ces
endroits ou situations pour fournir des soins de santé d'urgence.

 Ce système est utile pour les patients résidant dans des zones inaccessibles ou des régions isolées.
Les patients peuvent recevoir des soins médicaux cliniques de leur domicile sans voyage pénible
à l'hôpital.

 Les innovations modernes de la technologie de l'information telles que la collaboration mobile
ont permis un partage et une discussion faciles d'informations sur les cas médicaux critiques chez
les professionnels de la santé de plusieurs endroits.
















 Ce système facilite également l'éducation à la santé, car le niveau primaire des professionnels de
la santé peut observer la procédure de travail des spécialistes des soins de santé dans leurs
domaines respectifs et les experts peuvent superviser les travaux du novice.

 La télémédecine élimine la possibilité de transmettre des maladies infectieuses entre les patients
et les professionnels de la santé.
II.4.2. Inconvénients
 Le coût global du système de télécommunication, en particulier les appareils de gestion de données et

la formation pratique des professionnels de la santé est génial. (9)

 Le traitement clinique virtuel diminue l'interaction humaine entre les professionnels de la santé et les
patients qui augmentent le risque d'erreur dans les services cliniques, si le service est dispensé par un
professionnel inexpérimenté. En outre, des informations médicales confidentielles peuvent être
divulguées par un système électronique défectueux.

 La télémédecine pourrait prendre plus de temps pour les difficultés liées à la connexion de la
communication virtuelle en raison de la faible vitesse de l'Internet ou du problème du serveur. En
outre, ce système ne peut pas fournir un traitement immédiat, par exemple des antibiotiques.

 La faible qualité des enregistrements informatiques de la santé, comme les radiographies ou d'autres
images, les rapports de progrès clinique, etc. courent le risque d'un traitement clinique défectueux.

 Le système de télémédecine nécessite une réglementation légale difficile pour prévenir les
fournisseurs de services non autorisés et illégaux dans ce secteur.

Chapitre III
III. Présentation de WebRTC
III.1. Définition et Principes de la WebRTC
III.1.1. Définition
La WebRTC est une technologie permettant de faire de la communication en temps réel entre les
navigateurs Web en mode peer-to-peer. Elle permet aux applications telles que les appels vocaux, vidéos,
chat, de même que les applications liées au partage des fichiers et à la visioconférence de se faire à travers
un navigateur en temps réel sans passer par des protocoles propriétaires et sans nécessité de plugins, de
téléchargement, ou d’installation. (10)
Elle est une initiative de RTCWeb qui vise à intégrer dans les navigateurs de communications en
temps-réel. Il est en effet l’implémentation d’un standard ouvert préparé par IETF au sein du groupe de
travail RTCWeb Working Group.
Pour permettre à ces applications de s’exécuter, le standard WebRTC met en œuvre trois API :
 MediaStream
 RTCPeerConnection
 RTCDataChannel
C’est grâce à ces API que la technologie WebRTC arrive à exécuter ses applications web que nous
verrons de manière plus détaillée dans le chapitre suivant.
III.1.2. Principes
WebRTC est un Framework open source (libre) pour le web pouvant activer de communication en
temps réel dans un navigateur. Pour cela, il inclut les bases de conception fondamentales pour des
communications de hautes qualités sur le web ; sur les réseaux de même que des composants audio et
vidéo utilisés dans les applications de visioconférence. Ces composants, quand ils sont implémentés dans
un navigateur peuvent être utilisés via une API JavaScript, ce qui facilite l’implémentation des
applications WebRTC. (10)

Ainsi, beaucoup d’applications et de services web utilisent déjà des fonctionnalités RTC, mais ces
derniers ont besoin de faire des téléchargements, d’installer des applications natives ou des plugins. Il
s’agit notamment de Skype, Facebook (Facebook Messenger) et Google Hangouts (Google Talk plugin).
Or le téléchargement, l’installation et la mise à jour des plugins peuvent s’avérer complexes, sujets aux
erreurs. (10)
Cependant, ces plugins peuvent être difficiles à déployer, déboguer, dépanner, tester et à maintenir.
Ils peuvent exiger des licences et l’intégration de technologies souvent complexes et coûteuses. La
WebRTC est supportée par quelques navigateurs, c’est-à-dire que cette dernière est implémentée
dans ces navigateurs. Il s’agit notamment de : Chrome, Mozilla, Opera, Aurora.
III.2. Architecture générale de WebRTC
WebRTC offre aux développeurs d’applications web la possibilité d’écrire des applications riches
en multimédia en temps réel (chat, partage de fichiers, visioconférence), sur le web sans nécessiter de
plugins, de téléchargements ou d’installation. Le but de WebRTC est d’aider à construire une solide plate-
forme RTC qui fonctionne sur plusieurs navigateurs web à travers de multiples plateformes.
Cependant, l’architecture générale de WebRTC est la suivante :
Figure II.1: Architecture générale de WebRTC (11)

L’architecture WebRTC est organisée en plusieurs couches :
 WebRTC C++ natif API

Cette couche est une API qui permet aux fabricants de navigateurs d’implémenter facilement les
composants web pour les communications audio/vidéos proposés par les API web. (11)
 Session management
Cette couche est nécessaire à l’établissement de session entre instances de navigateurs. Elle
communique avec les couches Transport, Vidéo Engine et Voice Engine. (11)
 Session/Transport
Cette couche est responsable du transport des messages de signalisation et des flux échangés entre
deux instances. Cette couche est constituée de trois composantes : (11)
 Stack RTP
Une pile réseau pour le protocole RTP, protocole de transport en temps réel
 STUN/ICE
C’est un composant qui permet d’utiliser les mécanismes STUN et ICE pour établir des connexions
entre différents types de réseaux (utilisé pour régler les problèmes de traversée de NAT)
 La couche Voice Engine

C’est un framework qui gère les codecs audio pris en compte par la carte son. Elle supporte les
codes iLBC, iSAC, opus (11)
 NetEQ
C’est un tampon de gigue dynamique et un algorithme de masquage d’erreur utilisé pour réduire
les effets négatifs de la gigue réseau et la perte de paquets. Il maintient la latence la plus faible possible
tout en conservant la meilleure qualité vocale. (11)
 Acoustic Echo Canceler (AEC)

Le suppresseur d’écho est un logiciel à base de composants de traitement de signal qui supprime,
en temps réel, l’écho acoustique résultant de la voix étant jouée entrée dans le microphone actif. (11)

 Noise Réduction
C’est un composant du traitement de signal permettant de supprimer certains types de bruits de
fond du signal. (11)
 La couche Video Engine
C’est un support pour la chaîne vidéo, à partir de la caméra sur le réseau, et à partir du réseau à
l’écran. Cette couche prend en compte les codecs vidéos tels que : VP8, Jitter Buffer Vidéo, et un
composant servant à l’amélioration d’images. (11)
III.3. Fonctionnement
Le fonctionnement de la technologie WebRTC prend en compte 3 entités respectives que sont ;

l’architecture, la signalisation et la traversée de NAT.
III.3.1. Architecture de fonctionnement
Figure II.2: Architecture de Fonctionnement de WebRTC (10)

L’objectif de la WebRTC est de permettre à une application JavaScript de s’exécuter dans un

navigateur standard afin qu’il puisse établir une communication en temps-réel audio et vidéo. Une
application peut utiliser un protocole de signalisation basé sur le WebSockets, et aussi les primitives RTC
pour capturer les flux audio et vidéo de la webcam, les encoder et les transmettre au correspondant.
En effet, cette figure montre que l’accès à une application WebRTC se fait selon les étapes suivantes :
 L’accès aux ressources médias (Microphone, Webcam etc.) par l’intermédiaire de

l’API GetUserMédia ;
 La transmission de ces flux dans le réseau grâce à l’API PeerConnection ;
 La liaison bidirectionnelle entre le client (Navigateur) et le serveur maintenue grâce
au protocole WebSockets.
III.3.2. La signalisation
WebRTC utilise RTCPeerConnection pour communiquer des données en continu entre les
navigateurs (aka pairs), mais il faut aussi un mécanisme pour coordonner la communication et pour envoyer
des messages de contrôle, un processus connu sous le nom de signalisation. Or ces méthodes et protocoles
de signalisation ne sont pas spécifiés par WebRTC c’est-à-dire que la signalisation n’en fait pas partie de
l’API RTCPeerConnection. (10)
En effet, les développeurs d’application WebRTC peuvent choisir n’importe quel protocole de
messagerie qu’ils préfèrent, tels que SIP, XMPP, WebSocket, et toute autre duplex approprié (dans le deux
sens) canal de communication. Nous verrons ces protocoles dans la partie signalisation de ce chapitre.
L’architecture suivante explique réellement l’établissement de session en utilisant le protocole JSEP

(Protocole JavaScript Etablissement de Session).

Figure II.3: Etablissement d’une session peer-to-peer entre deux navigateurs (10)
L’établissement d’une session entre deux navigateurs se fait selon les phases principales suivantes:
 D’abord, l’acquisition des ressources audio/vidéo dans le navigateur de l’émetteur par

l’utilisation de l’API GetUserMedia ;
 Ensuite, la transmission de ces flux sur le réseau et le rendre sur le navigateur du récepteur
grace à l’API PeerConnection ;
 Et enfin, le rendu sur le navigateur du récepteur.
Il est à noter qu’une fois la signalisation établie entre les navigateurs, les flux multimédias passent
directement entre ceux-ci. Ainsi, pour atteindre ce but, nous utiliseront deux principales API WebRTC :
 MediaStream : manipule les ressources multimédias

 PeerConnection : assure la communication à travers le réseau
En résumé, l’API WebRTC permet : (10)
 D’obtenir le streaming audio, vidéo ou autres données ;
 D’obtenir des informations réseaux telles que l’adresse IP et le port d’échange avec d’autres
clients WebRTC (connu sous le nom de pairs ou peers) ;
 De coordonner la communication de signalisation pour signaler les erreurs et lancer ou

fermer les sessions ;
 D’échanger des informations sur les médias et la capacité du client, telles que la résolution et
les codecs ;
 De diffuser le streaming audio, vidéo ou données.

Cependant, deux problèmes majeurs ont été relevés par les développeurs d’applications
WebRTC :
 La gestion de la signalisation laissée à l’appréciation du développeur parce que WebRTC ne

spécifie pas un protocole ;
 Le problème de traversée de NAT commun à toutes les applications TOIP quand elles se
trouvent derrière un routeur NAT. C’est-à-dire que si les deux clients se trouvent derrière un
routeur NAT, la signalisation passe mais les flux médias ne passeront pas.
III.3.3. Traversée de NAT
L’un des problèmes importants liés aux protocoles de signalisation au niveau du filtrage des flux.
Avant, les entreprises utilisaient des mécanismes de translation d’adresse (NAT), incompatibles avec les
flux multimédias. Raison pour laquelle, les boîtiers NAT et les pare-feux imposèrent les trois verrous
suivant à la traversée des flux ToIP : (10)
 Les protocoles de signalisation pour la TOIP standard, à l’instar de H.323, SIP et MGCP,
annoncent l’adresse IP des correspondants à l’intérieur des messages qu’ils envoient. Or si
ces adresses IP sont privées, elles ne sont pas exploitables en dehors du réseau local
déployant le NAT ;
 Un boitier NAT n’effectue pas la correspondance d’une adresse IP locale privée avec une
adresse IP publique correspondante que si le terminal local effectue une connexion réseau.
Par conséquent, si un terminal distant tente de joindre le terminal derrière le NAT, aucune
règle n’est ajoutée dans le boitier NAT, et le correspondant derrière le NAT est injoignable. Il
peut émettre un appel, mais n’en recevra pas ;
 Les ports utilisés dans le canal de données sont négociés dynamiquement dans le canal de
contrôle par les protocoles de signalisation. Un pare-feu ne peut donc statiquement pas ouvrir
les ports du canal de données puisque ces choix sont imprévisibles.

Pour pallier ce problème de traversée de NAT, il va falloir passer par l’intermédiaire d’un serveur
STUN, TURN ou ICE que nous verrons dans le point suivant.
Figure II.4: Traversée de NAT par un serveur STUN (10)
III.3.3.1. Le protocole STUN
STUN est un protocole destiné à la traversée des routeurs NAT. il permet d’établir des connexions
d’un poste, qui est situé derrière des routeurs NAT de découvrir son adresse IP publique ainsi que le type
de routeur NAT derrière lequel il est. Ces informations sont utilisées pour échanger correctement des
données UDP avec l’extérieur d’un réseau NATé. Pour ce faire, le poste situé en réseau privé émet des
requêtes vers le serveur STUN public. Le serveur STUN renvoie l’adresse publique et le port du routeur
NAT associé au réseau privé du poste. Il permet également aux terminaux de détecter dynamiquement le
type de NAT qui leur est appliqué. (10)
L’idée de base du protocole STUN consiste pour un client à demander l’adresse IP publique à un
serveur externe comme l’illustre la figure suivante. En connaissant cette adresse, l’application peut
reporter l’information dans ces messages.

Figure II.5: Demande et Réponse entre un client et un serveur STUN (10)
Le protocole STUN est un modèle client-serveur qui distingue deux catégories d’éléments : (10)
 Le client STUN : entité qui émet des requêtes STUN, et qui doit se trouver dans un domaine
privé. Le client STUN est implémenté au sein d’une application devant traiter et envoyer des
données dont le contenu (hors en tête) comporte des adresses IP. C’est généralement le terminal
de l’utilisateur qui a ce besoin, mais il peut aussi s’agir d’un terminal quelconque ;
 Le serveur STUN : entité qui reçoit et répond aux requêtes STUN. Pour exécuter correctement sa
fonction, le serveur STUN doit se trouver à l’extérieur du réseau privé, généralement dans le
réseau internet.

Le protocole STUN est standardisé, ce qui en fait une méthode privilégiée pour garantir aux
applications la meilleure compatibilité possible. Son coût est modique, puisqu’il ne nécessite que l’ajout
d’un serveur placé à une position stratégique. Le serveur reçoit des demandes brèves et y répond de façon
analogique, ce qui en fait une entité faiblement sollicitée par chaque utilisateur. (10)
Cette opération n’est toutefois pas transparente pour l’utilisateur, puisque les applications doivent
prendre en compte ce mécanisme dans les échanges qu’elles établissent.
Il est à noter que la méthode STUN, ne s’applique pas au NAT symétrique. En effet, la translation
d’adresses dépend également de la destination des messages envoyés. En utilisant le protocole STUN,
l’appelant contacte un serveur STUN et est vu par ce dernier avec une adresse IP qui peut être différente
de celle que l’appelant utilisera plus tard pour contacter son véritable destinataire. Autrement dit, le
serveur STUN retourne des informations d’adressage qui ne sont factuelles que pour lui et erronées pour
tout autre correspondant. Le NAT symétrique lui échappe donc. C’est pour résoudre ce problème que la
méthode TURN a été introduite. (10)
III.3.3.2. Le protocole TURN
TURN se base sur le protocole STUN par exemple pour le partage de clé cryptographie et
l’authentification du serveur et du client. C’est–à-dire que dans la pratique, les clients partagent avec le
serveur un secret permettant de les authentifier. Lors de l’envoi de données, les clients émettent une
requête sécurisée par TLS. Là encore, la communication doit être initiée par le terminal local au
mécanisme de NAT. Dès lors, l’utilisateur ne peut communiquer qu’avec un seul correspondant distant en
passant par le serveur TURN. (10)
Le protocole TURN est soumis à l’IETF en octobre 2003, avec une révision en juillet 2004, il a été
conçu pour les restrictions posées par la méthode STUN et permet aux utilisateurs qui se trouvent derrière
un réseau avec NAT ou derrière un pare-feu de communiquer quelle que soit la forme de NAT qui leur est
appliquée.
Tout comme pour STUN, l’idée est de disposer d’un serveur à l’extérieur du réseau natté, mais,
contrairement à STUN, le serveur ne se contente pas d’informer le client sous la forme de NAT qui lui est
appliquée. Il joue un rôle beaucoup plus actif et participe à l’acheminement des données en tant que relais.
Un client qui souhaite établir une communication avec un correspondant doit envoyer toutes ses requêtes et
données vers le serveur STUN, les transmet ensuite au correspondant. (10)

III.3.3.3. La plateforme ICE
ICE par contre n’est pas un protocole, mais une méthodologie pour le passage des flux qui sont
soumis à des translations d’adresses. Elle prescrit l’utilisation des protocoles STUN et TURN et fournit un
cadre d’application au cas par cas. Cependant il est en étude sous forme de draft IETF. (10)
III.4. Signalisation
III.4.1. Définition
La signalisation désigne un ensemble de signaux nécessaire à l’établissement et la supervision des

communications. C’est un ensemble de messages de services échangés entre les commutateurs de réseau
ou entre ceux-ci et les équipements des utilisateurs, qui sont nécessaires à l’établissement et à la gestion
des communications. Ces messages portent sur l’état des liaisons du réseau et sur la nature des
équipements des utilisateurs. Elle concerne tous les échanges d’informations nécessaires pour la fermeture
et la maintenance d’un service de télécommunication. (11)
La signalisation est utilisée pour échanger trois types d’informations : (11)
 Les messages de contrôle de session : pour initier ou fermer la communication et signaler les
erreurs ;
 La configuration réseau : ici, il est question de savoir quelle est l’adresse IP et le port du service ?
 Les capacités des médias : là encore, il s’agit de déterminer quels codecs et quelles résolutions
peuvent être supportées par mon navigateur et le navigateur qu’il souhaite communiquer avec le
mien ?
La signalisation comprend les signaux requis pour la gestion des connexions : (11)
 Etablissement ;
 Contrôle de facturation ;
 Supervision et maintenance.

Cependant, la signalisation est le mécanisme par lequel les paires envoient des messages de
contrôle à chacun dans le but d’établir le protocole de communication, le canal et la méthode. Mais ceux-
ci ne sont spécifiés dans le standard WebRTC. C’est-à-dire que dans le cas de la technologie WebRTC,
aucun protocole requis n’est défini. Alors le développeur peut choisir n’importe quel type de protocole de
message (comme SIP, XMPP/Jingle), et n’importe quel type de canal de communication duplex (comme
WebSocket ou XMLHTTPRequest). (10)
Cependant nous allons nous consacrer à l’étude des protocoles de signalisations supportées par le
Standard WebRTC.
III.4.2. Protocoles de Signalisation
Dans le standard WebRTC, aucun protocole de signalisation n’est spécifié. Cependant, il est laissé
à l’appréciation des développeurs de choisir parmi les protocoles de messagerie (comme SIP, XMPP), où
de n’importe quel canal de communication duplex tel que WebSocket etc.
III.4.2.1. SIP
SIP est un protocole de signalisation défini par l’IETF permettant l’établissement, la libération et la
modification de sessions multimédias. Il hérite de certaines fonctionnalités des protocoles http (Hyper Text
Transport Protocol) utilisées pour naviguer sur le Web, et SMTP (Simple Mail Transport Protocol) utilisé
pour transmettre des messages électroniques. (11)
Le protocole SIP n’est qu’un protocole de signalisation. Une fois la session établie, les participants
de la session s’échangent directement leur trafic audio/vidéo à travers le protocole RTP (Real-Time
Transport Protocol) et RTCP (Real-Time Control Protocol). Hormis le transport de la voix, le protocole
SIP est utilisé dans la visioconférence, la messagerie instantanée et les jeux vidéo. (11)
Par ailleurs, SIP n’est pas un protocole de réservation de ressource, il ne peut donc pas assurer la
QoS. Il s’agit d’un protocole de contrôle d’appel et non d’un contrôle du média. SIP n’est pas non plus un
protocole de transfert de fichier tel que http, utilisé afin de transporter de grands volumes de données. Il a
été conçu pour transmettre des messages de signalisation courts afin d’établir, maintenir et libérer des
sessions multimédia. Des messages courts non relatifs à un appel peuvent néanmoins être transportés par
SIP de la même manière que les SMS. (11)

III.4.2.2. XMPP
XMPP est un ensemble de protocoles standard ouverts de l’IETF pour la messagerie instantanée.
XMPP est également un système de collaboration en quasi-temps-réel et d’échange multimédia via le
protocole Jingle, dont la voix sur IP (Téléphonie sur Internet), la visioconférence et l’échange de fichiers
sont d’exemples d’applications. Il est basé sur une architecture client-serveur permettant des échanges de
messages instantanés. (10)
Ce protocole hérite directement du protocole de messagerie Jabber qui a la vocation initiale de

proposer des fonctionnalités d’échange de messages instantanés et de notification de présence, ou plus
généralement d’un statut, entre les utilisateurs connectés au service. Il s'agit d'un protocole client-serveur à
authentification. Le trafic est transporté par TCP sur les ports standards 5222 entre le client et le serveur et
5269 entre serveurs. XMPP est un protocole décentralisé. Les flux sont chiffrés par TLS/SASL.
Chaque utilisateur est identifié par un identifiant unique nommé JID (Jabber ID). Le JID se
construit sous la forme : (10)
[nœud "@" ] domaine_xmpp [ "/" ressource]
Exemple : josue@rtn.sn/Bureau
Le nœud et la ressource sont des éléments facultatifs. Évidemment, il n'est pas aisé de
communiquer avec josue du domaine rtn.sn si l'on omet de spécifier le nœud. La ressource permet
d'envoyer un message à une destination choisie si le correspondant est connecté plusieurs fois avec le
même identifiant de domaine. (10)
Exemple : josue@rtn./Bureau et josue@rtn.sn/Maison
Dans le cas où la ressource n'est pas spécifiée, le message sera délivré à la connexion de plus haute
priorité, propriété de la connexion au moment de son établissement, d'une valeur choisie par le client.
Le domaine est un domaine XMPP. Il s'agit en pratique d'un FQDN qui sera résolu par des
enregistrements de type SRV du DNS. Une adresse IP est aussi acceptée. Un même domaine XMPP peut
ainsi être géré par plusieurs serveurs, tout comme un serveur peut bien sûr gérer plusieurs domaines
XMPP. (10)

III.4.2.3. WebSocket
Le protocole WebSocket est un mécanisme pour les applications Web, qui nécessite une
communication bidirectionnelle avec le serveur, et qui ne repose pas sur plusieurs connexions http
(utilisation de XMLHTTPRequest, d’iframe, ou de long polling). (10)
Ils sont disponible sur les dernières versions de navigateurs les plus connus tels que Firefox,
Google Chrome, Opera et Safari.
L’API WebSocket est donc développée par le W3C (le 20 Septembre 2012), pour créer une
instance de WebSocket, le seul argument que nous devons fournir est l’URL du serveur avec lequel nous
souhaitons établir une liaison. Elle commence obligatoirement par ws:// ou wss:// pour une connexion
sécurisée. (10)
Les attributs fonctionnels permettant de gérer les évènements sont : (10)
 onopen : ouverture d’une WebSocket ;

 onmessage : réception d’un message ;
 onerror : erreur(s) survenue(s);
 onclose : fermeture de WebSocket.
Cependant, les messages envoyés par le serveur sont notifiés par l’évènement onmessage
contenant le message du serveur sous forme de chaîne. Les évènements onerror, onopen et onclose
permettent de suivre en temps réel l’état de la connexion.
Les WebSocket fournissent deux méthodes : (10)
 send (data_string) pour envoyer un message au serveur ;

 close () pour fermer le socket
Ainsi, une fois la connexion établie en mode WebSocket, les données peuvent être envoyées et
reçues entre le client et le serveur en mode full duplex.

III.5. Description de session SDP
SDP est destiné à la description des sessions multimédia pour les annonces de session, l’invitation
à une session, et d’autres formes d’initiation de session multimédia. SDP est un protocole de description
de session pour les sessions multimédia. Un mode d’utilisation courant est celui qui permet à un client
d’annoncer une session de conférence en multidiffusion périodiquement et un paquet d’annonces à des
adresses et ports en multidiffusion bien connus en utilisant le protocole d’annonce de session. (11)
L’objectif de SDP est de convoyer des informations sur les flux de support dans les sessions
multimédia pour permettre aux receveurs d’une description de session de participer à la session. SDP est
principalement destiné en inter réseau, bien qu’il soit suffisamment généreux pour pouvoir décrire des
conférences dans d’autres environnements de réseau. (11)

SDP inclut : (11)
 Le nom et l’objet de la session ;
 L’heure ou les heures à laquelle ou auxquelles la session est active ;
 Le support comprenant la session ;
 Les informations pour recevoir ces supports (adresses, ports, formats, etc).
Puisque les ressources nécessaires à la participation à une session peuvent être limitées, certaines
informations supplémentaires peuvent être aussi souhaitables :
 Des informations sur la bande passante à utiliser par conférence ;

 Des informations de contact pour la personne responsable de session. En générale SDP doit
convoyer des informations suffisantes pour etre capable de se joindre à une session (avec
l’exception possible des clés de chiffrement) et pour annoncer les ressources à utiliser que
des non-participants peuvent avoir besoin de connaitre. (11)
SDP inclut des informations sur le support :

 Le type de support (vidéo, audio, etc) ;
 Protocole de transport (RTP/UDP/IP, H320, etc) ;
 Le format de support (vidéo, H261, audio, MPEG, etc).

Pour une session IP en multidiffusion sont aussi envoyés :
 L’adresse de multidiffusion pour le support ;


 Le port de transport pour le support ;
Ces adresses et ports sont l’adresse et le port de destination du flux multidiffusion, qu’il soit
envoyé, reçu ou les deux.
Pour une session en monodiffusion, sont envoyés :
 L’adresse distante pour le support ;


 Le port de transport pour l’adresse de contact.
La session description protocole (SDP) est un format de description des médias en streaming
paramètres d’initialisation. SDP est destiné à la description multimédia de session de communication aux
fins d’annoncer la session, d’invitation à une session, et de négocier de paramètres. SDP ne fournit pas les
médias lui-même mais il est utilisé pour la négociation entre les points d’extrémités du type de support, le
format, et toutes les propriétés associées. L’ensemble des propriétés et les paramètres sont souvent appelés
profil de session.
SDP a commencé comme une composante d’annonce de session protocole (SAP), mais à trouver
d’autres utilisations en fonction avec le RTP (temps réel transport protocole), en temps réel Streaming
Protocole (RTSP), session initiation protocole (SIP) et même comme un format autonome pour décrire
multicast session. (10)
III.6. Protocoles de transport (SRTP, RTP, RTCP)
Avec quel protocole transporter les flux de ToIP et plus généralement tous les flux multimédias,
soumis à des contraintes temporelles particulièrement fortes dans les réseaux IP ? Le protocole TCP exige
de nombreuses procédures de contrôle, qui le rendent peu adapté au transport des données multimédias
avec de fortes contraintes de délai. À l’inverse, le protocole UDP ne propose aucun mécanisme de
contrôle, ce qui ne le qualifie guère pour le traitement des données multimédias. (11)
Le protocole TCP est donc inadapté au temps réel, puis que tous les contrôles qu'il met en place
pour le transport des paquets pénalisent ses délais de transmission. La contrainte de fiabilité n'étant pas
compatible avec la contrainte de délai imposée par la ToIP. TCP, n'est donc pas un bon protocole pour les
transferts de type temps réel. (11)

Le protocole UDP ne comporte que des fonctionnalités de transport pur, sans aucun mécanisme de
contrôle. L’adressage des données avec les ports de communication utilisés est sa seule fonction
fondamentale. C’est un atout par rapport aux éléments contraignants mentionnés pour le protocole TCP.
UDP notamment plus rapide que ne l’est TCP. Donc il est bon pour la communication en temps réel. (11)
Des deux protocoles candidats au transport des données multimédias, l’un est « trop complet » et
l’autre est trop limité. Il est cependant possible de partir du protocole UDP et de lui ajouter des
fonctionnalités d’ordonnancement. Le protocole RTP a été proposé à cette seule fin de reconstitution de
l’ordre du flux d’origine. Pour sa part, RTCP a été conçu pour offrir une vision de l’état du réseau et
permettre à une application d’adapter les flux en conséquence.
Les protocoles RTP et RTCP
Comme indiqué précédemment, le couple de protocoles RTP/RTCP a été conçu dans le but
d’enrichir les fonctions d’UDP et de fournir à ce dernier ce dont il a besoin pour gérer efficacement les
données multimédias temps réel. Aujourd’hui, ce couple s’utilise systématiquement dans les applications
multimédias interactives, à la fois pour la téléphonie, la vidéo, les jeux vidéo et la réalité virtuelle. (11)
RTP (Real-time Transport Protocol)
RTP est utilisé pour le transport de bout en bout de flux ayant des contraintes temporelles fortes,
typiquement pour les flux multimédias avec interactivité, tel le service de téléphonie sur IP. (11)
Initialement, RTP était conçu pour un environnement multicast, dans lequel un émetteur diffuse
son contenu vers plusieurs récepteurs en parallèle. Le cas d’un flux unicast, dans lequel un émetteur
n’émet que pour un unique récepteur, n’est qu’un cas particulier et plus simple d’application multicast.
RTP assure un contrôle spécifique des données temps réel. Il permet de reconstituer les propriétés temps
réel des flux médias en opérant sur deux niveaux, la synchronisation des flux d’un côté et la reconstitution
de l’ordre des paquets émis et la détection des pertes de paquets de l’autre : (11)

 Synchronisation des flux : Si l’audio et la vidéo sont transmis séparément, le destinataire doit jouer la
séquence audio de façon à ce que cette dernière coïncide avec la séquence vidéo. Pour cela, RTP
ajoute aux paquets émis une estampille de date, appelée horodatage, ou timestamp. Cette estampille
indique le moment pendant lequel le paquet a été émis, ce qui permet de reproduire les mêmes délais
inter paquet et de jouer les paquets audio et vidéo de manière synchronisée ; (11)
 Reconstitution de l’ordre des paquets émis et détection des pertes de paquets. Les paquets IP sont
transmis indépendamment les uns des autres. En conséquence, leur ordre d’arrivée chez le
destinataire n’est pas forcément conforme à leur ordre d’émission.
RTCP (Real-time Transport Control Protocol)
Décrit dans la RFC 3550, RTCP est un protocole de contrôle et de supervision du réseau. Il opère
comme une sonde qui rend compte aux émetteurs des performances dont la communication en cours
bénéficie. Son objectif est d’offrir aux participants d’une session une vision sur l’état du réseau et de s’y
adapter de façon dynamique. Il fournit de ce fait un rapport sur la qualité de distribution, incluant le délai
de bout en bout, la gigue et le taux de pertes. Ce rapport est envoyé de façon périodique afin que les
intervenants puissent disposer d’une mise à jour fréquente de l’état du réseau. (11)
Par exemple, si un utilisateur fait de la téléphonie et que, par le biais du protocole RTCP, son
correspondant lui envoie des rapports signalant un fort taux de perte de paquets, il peut considérer que le
codec qu’il utilise est trop gourmand pour être supporté dans les conditions actuelles du réseau. Il peut dès
lors sélectionner un codec de qualité plus fiable mais nécessitant moins de ressources. (11)
Dans sa spécification, RTCP n’est aucunement indispensable pour le fonctionnement de RTP.

Néanmoins, leur association apporte une cohérence globale dans le traitement des communications
multimédias. Tous deux doivent être pensés et intégrés au niveau applicatif. Les rapports fournis par
RTCP peuvent optimiser la qualité de la transmission. (11)

SRTP
SRTP a été conçu par Cisco et Ericsson. Il a été publié en mars 2004 par IETF dans la RFC 3711. Ce
protocole est une extension de RTP (Protocole de Transport en temps réel) qui intègre des fonctions de
sécurité. Tout comme RTP, SRTP est destiné VoIP (Voice over IP). Il est destiné à fournir le cryptage, le
chiffrement, l’authentification et l’intégrité de messages et la protection dans la relecture des données
RTP dans les deux unicast et multicast. (11)
III.7. Codecs
Cependant, le tableau ci-dessous fait une comparaison entre les différents entités et codecs mis en jeu.
Tableau II.1 : Comparaison des codecs classiques et WebRTC (11)
VoIP Classique WebRTC
Protocoles de SIP/H323 Non définie
Signalisation
Protocoles de RTP/RTCP RTP/RTCP
Transport des Médias
Sécurité SRTP dans SIP SRTP

H.335 dans H.323
Traversée de NAT STUN/TURN/ICE dans SIP STUN/TURN/ICE

H.450.X dans H.323
Codecs Vidéo H.263, H.264 VP8
Codecs Audio La série des codecs G.7xx G.711, ilBC, ISAC

III.1. Les APIs?
III.1. Qu’est-ce qu’une API?
Une API (Application Programming Interface) est un ensemble de classes et de méthodes ou des
fonctions normalisés qui sert de façade par laquelle un logiciel offre de services à d’autres logiciels. Elle
est souvent offerte par une bibliothèque logicielle ou un service web, le plus souvent accompagnée d’une
description qui spécifie comment des programmes consommateurs peuvent se servir des fonctionnalités de
programme fournisseur. (10)
Ainsi, dans le cas de WebRTC, les API suivants tels que MediaStream, PeerConnection et
RTCDataChannel sont intégrés dans le navigateur. Cependant, l’étude de ces API s’avère nécessaire pour
l’implémentation ou la conception d’une application Web.
III.2. API MediaStream (Aka GetUSerMedia)
L’API MediaStream permet de contrôler les différentes interfaces de périphériques multimédia du

terminal (microphone, haut-parleur, camera, etc) et de capturer les flux multimédia. Le Stream API, et en
particulier son objet MediaStream est au cœur de WebRTC. Toute la partie multimédia passe par elle,
quelles que soient la source et la destination du trafic. La figure suivante illustre l’acquisition des flux
multimédia par l’API MediaStream. (10)

Figure III.1:Traitement des flux audio et vidéo par GetUserMedia (10)
Un flux média (MediaStream) contient et traite les pistes audio et vidéo. Ces flux peuvent provenir
de différentes sources (locales ou distantes) et sont émis à des destinations variables (locales ou distantes
également). Au sein de cette interface, seul l’objet MediaStream reste immuable quelle que soit le cas de
figure considéré. Les différentes étapes illustrées sur la figure ci-dessus sont les suivantes : (10)

1. Construction de l’objet MediaStream
L’objet MediaStream prend en paramètre soit une connexion distante (PeerConnection, voir ci-
après), soit un objet LocalMediaStream ayant accès aux ressources locales du terminal. Pour des raisons
de sécurité, ces accès sont explicitement donnés par l’utilisateur via l’usage de bouton (Par exemple
diffuser ma vidéo). La fonction GetUserMedia () récupère simultanément ou séparément (il est possible
d’appeler plusieurs fois), les différentes sources afin de les traiter par la suite.
2. Sources Locales
Ces sources peuvent émaner de différentes origines, notamment d’équipements de capture en temps
réel (microphone, webcam, camera, …) ou de fichiers locaux au terminal. Le support de ces différentes
sources est assuré grâce aux nouvelles fonctionnalités offertes par HTML5 (File API Media Capture)
3. Gestion de différent flux
Un MediaStreamTrack est créé pour chacun des flux, audio, vidéo. S’il existe plusieurs flux
simultanés, ceux-ci sont stocker au sein de type MediaStreamTrackList. Ces listes sont utilisées pour créer
le flux média.
Grâce à ces listes, l’objet MediaStream est dynamique. Il devient en effet possible d’ajouter et de
retirer à la volée des flux multimédia sans avoir besoin de recréer un nouvel objet (fonction add () de
l’objet MediaStreamTrackList).
Les pistes audio peuvent contenir un nombre de variables de canaux (mono, stéréo, 5.1 …)
permettant leur utilisation dans des multiples situations. Ces canaux sont les plus petites unités d’un
MediaStream.
4. Utilisation du MediaStream
Cet objet MediaStream peut ensuite être utilisé dans divers cas de figures :
 Le flux peut être directement affiché dans le navigateur local, ce qui peut servir à
afficher le retour d’une webcam locale ou le flux en provenance d’un tiers via un
objet PeerConnection en entrée ; -Les flux peuvent être enregistrés dans de fichiers
locaux ;

 Les flux peuvent être envoyés à un tiers à l’aide d’un objet PeerConnection ce
qui est l’objet défini de WebRTC.
Le schéma suivant illustre le fonctionnement de l’API MediaStream
Figure III.2: Fonctionnement de MediaStream (10)
La figure ci-dessus illustre un cas d’usage typique du fonctionnement de MediaStream. La

fonction getUserMedia() (1), déclenchée par un bouton, autorise l’accès aux différents équipements
(Microphone, webcam…)(2) afin d’en récupérer les flux audio/vidéo.
Ces LocalMediaStream ou MediaStreamTrack sont traités par la fonction appelée (callback) en cas
de succès, afin de les ajouter aux MediaStreamTrackList d’un objet MediaStream, créant
effectivement le flux média. Celui-ci peut ensuite être ajouté à une connexion sortante (4)
PeerConnection afin de transmettre le flux à un destinataire. (10)
La pratique veut que ces objets MediaStream disposent d’une URL pour l’objet binaire qu’elle
représente (BLOB ou Binary Large Object). La fonction CreateObjectURL crée cet URL. Les données
de l’objet que cet URL représente doivent être compréhensibles directement par les éléments HTML5
audio ou vidéo. (10)

III.3. API PeerConnection
L’objet PeerConnection est primordial pour l’établissement d’une connexion de manière

transparente, entre deux entités RTCWeb. Définie au sein de la même spécifique que la Stream API, elle
risque d’être altérée en profondeur dans les mois à venir puisque l’IETF est entrain de définir un
framework d’établissement de session pour RTCWeb/WebRTC (JSEP ou JavaScript Session
Establissement Protocol actuellement en draft 00) qui aura un impact sur les routines de l’objet
PeerConnection. (10)
L’objet PeerConnection gère l’ensemble de l’établissement de connexion avec la partie distante.

Comme décrit dans la figure ci-dessus, lors de sa création, il est possible de remarquer qu’il prend deux
paramètres qui traitent deux aspects bien distincts : (10)
 Son premier paramètre spécifie un serveur STUN/TURN pour la traversée

de NAT des flux multimédias qui est systématiquement tentée par l’usage
d’ICE ;
 Son second paramètre défini la fonction à appeler (callback) pour envoyer

des messages de signalisation. Il est dès lors possible de manipuler et de
personnaliser les messages envoyés au destinateur via cette fonction.
La signaling callback passée en second paramètre permet de générer les messages de signalisation,
nécessaires pour échanger les informations de connexion, grâce à SDP.
III.4. API Data Channel
Un canal de données (DataChannel) WebRTC permet d’envoyer des données texte ou binaire sur
une connexion active à un pair. (10)
Ainsi que l’audio et la vidéo, WebRTC en charge la communication en temps réel pour les autres
types de données.
L’API de RTCDataChannel permet l’échange peer-to-peer de données arbitraires, avec une faible
latence et un débit élevé.
Il existe de nombreux cas d’utilisation potentiels pour l’API, y compris :
 Jeu de gaming ;
 Application de bureau à distance ;



 En temps réel le chat texte ;

 Le transfert de fichiers.
L’API a plusieurs fonctionnalités pour profiter au maximum de RTCPeerConnection et permettre

une communication puissante et flexible peer-to-peer :
 Tirer parti de la configuration de session RTCPeerConnection ;


 Canaux simultanés multiples avec des priorités ;

 Sémantique de livraison fiables et peu fiables ;

 La Sécurité intégrée (DTLS) et le contrôle de congestion ;

 Aptitude à utiliser avec ou sans audio ou vidéo.

Chapitre IV
IV. Analyse et Conception de la Plate-forme
IV.1. Architecture et Fonctionnement
Figure IV.1: Architecture de fonctionnement de la plate-forme
La plate-forme de téléconsultation est hébergée quelque part sur internet et pour y accéder, il faudrait
d’abord avoir accès à ce réseau.
Cependant, chaque patient et médecin doivent s’authentifier avant d’accéder à la plate-forme. Une
fois l’authentification réussie, les patients accèdent à la page d’accueil et peut consulter un médecin à
distance par vidéo ou audio.

Ainsi, la figure ci-dessous montre comment un patient ou un médecin accède à la plateforme
Figure IV.2: Architecture d’accès à la plate-forme
IV.2. Choix des outils et technologies
IV.2.1. Les Langage de programmation
IV.2.1.1. UML
Le langage UML (Unified Modeling Language) est un langage de modélisation graphique qui
permet de modéliser des données. Il propose des outils de concept et de modélisation des systèmes
d’informations.
UML est utilisé pour spécifier, visualiser, modifier et construire les documents nécessaires au bon
développement d’un logiciel orienté objet. Il offre un standard de modélisation pour représenter
l’architecture logicielle. (12)
Les différents éléments représentables sont : (12)
 Activité d’un objet/logiciel


 Acteurs

 Processus

 Schéma de base de données

 Composants logiciels

 Réutilisations des composants
La modélisation proposée par le langage UML utilise divers types de diagrammes spécifiques
repartis en deux groupes suivants:

 Diagramme de composants

 Diagramme de paquetages

 Diagramme de déploiement

 Diagramme de Structure Composite
Comportement du système :

 Diagramme d’état de transition

 Diagramme d’activité

 Diagramme de séquence

 Diagramme de collaboration

 Diagramme de vue globale des interactions

 Diagramme de Temps
IV.2.1.2. HTML5/CSS3
HTML5 (HyperText Markup Language 5) est la cinquième version de HTML qui définit de
nombreuses nouvelles fonctionnalités pour les pages web notamment la construction des éléments
dynamiques et multimédia comme les balises audio et vidéo. Elle définit également les WebSockets
comme étant le nouveau protocole de transport pour la communication bidirectionnelle flux duplex entre
le serveur et le navigateur. (14)
IV.2.1.3. JavaScript
JavaScript en abrégé JS est un langage de programmation de scripts principalement utilisé dans les
pages web interactives mais aussi coté serveur. Il est orienté objet à prototype, c’est-à-dire que les bases
du langage et ses principales interfaces sont fournies par des objets. Il permet aussi d’accentuer,
d’améliorer et d’enrichir la partie graphique de votre page HTML (Menu déroulant graphique, changement
de couleur …). (15)

IV.2.2. Les Protocoles http et Websockets
IV.2.2.1. Le protocole http
HTTP est un protocole de communication client-serveur destiné pour le web. Il est situé au
niveau de la couche application du modèle OSI. Il peut fonctionner sur n’importe quelle connexion
fiable, dans les faits, on utilise le protocole TCP comme couche de transport et le serveur http écoute
les requêtes sur le port 80. (10)
Les clients web les plus connus sont les navigateurs web permettant à un utilisateur d’accéder à
un serveur contenant les données.
Ainsi un client http envoie une requête au serveur qui à son tour envoie une réponse comme la
montre la figure ci-dessous :
Figure IV.3: Communication entre un navigateur et un serveur http
En effet, cette communication entre le navigateur et le serveur se fait en deux étapes :
 Le navigateur effectue une requête http.


 Le serveur traite la requête puis envoie une réponse http.

IV.2.2.2. Le protocole WebSockets
Les WebSockets constituent un élément essentiel pour les applications web, qui nécessite une
communication bidirectionnelle avec le serveur, et qui ne repose pas sur plusieurs connexions http. Ils sont
disponibles dans les dernières versions des navigateurs les plus connus tels que Firefox, Google Chrome,
Opera et Safira.
IV.2.3. La Base de données MongoDB
MongoDB (de l'anglais humongous qui peut être traduit par « énorme ») est un système de gestion
de base de données orientée documents, répartissable sur un nombre quelconque d'ordinateurs et ne
nécessitant pas de schéma prédéfini des données. Il est écrit en C++. Le serveur et les outils sont distribués
sous licence AGPL, les pilotes sous licence Apache et la documentation sous licence Creative Commons2. Il
fait partie de la mouvance NoSQL. (13)
MongoDB permet de manipuler des objets structurés au format BSON (JSON binaire), sans schéma
prédéterminé. En d'autres termes, des clés peuvent être ajoutées à tout moment « à la volée », sans
reconfiguration de la base. (13)
Les données prennent la forme de documents enregistrés eux-mêmes dans des collections, une
collection contenant un nombre quelconque de documents. Les collections sont comparables aux tables, et
les documents aux enregistrements des bases de données relationnelles. Contrairement aux bases de données
relationnelles, les champs d'un enregistrement sont libres et peuvent être différents d'un enregistrement à un
autre au sein d'une même collection. Le seul champ commun et obligatoire est le champ de clé principale («
id »). Par ailleurs, MongoDB ne permet ni les requêtes très complexes standardisées, ni les JOIN, mais
permet de programmer des requêtes spécifiques en JavaScript. (13)

IV.3. Conception du Système
IV.3.1. Modélisation du système
IV.3.1.1. Etude de Cas
Soit un cabinet médical ou un hôpital général désirant offrir un service de téléconsultation à ses
patients. Cependant, l’hôpital ou le cabinet médical dispose d’une plateforme de téléconsultation.
Ainsi, l’administrateur peut démarrer l’application avant que les patients et les médecins y
accèdent via leurs navigateurs web en tapant l’url de l’application.
Avant de se connecter le patient doit avoir un compte. Lors de la connexion si l’authentification

n’est pas avérée, il a la possibilité de retaper son login et son mot de passe. Dans le cas où il parvient à
s’authentifier, il peut y accéder pour faire la consultation à distance.
S’il veut passer un appel vidéo ou audio, alors il pourra entrer en contact avec un médecin disponible.
Une fois l’appel terminé, un patient peut se déconnecter de la plate-forme. Puis l’administrateur
peut arrêter l’application.
Pour modéliser le système, nous allons suivre les différentes étapes qui suivent.
IV.3.1.2. Liste des acteurs
 Identification des acteurs
Acteurs principaux :
Utilisateur (Patient/Médecin) : s’authentifier, faire la consultation par vidéo ou audio

 Identificateurs des cas d’utilisation


  Démarrer le système
  Création compte
  Authentification
  Initialiser mot de passe
  Faire la consultation par audio ou vidéo
 Arrêter le système
Cependant, nous allons présenter le cas d’utilisation suivant
IV.3.1.3. Diagramme des cas d’utilisation

IV.3.2. Environnement de développement
IV.3.2.1. Présentation de Node.js
Node.js est une plateforme logicielle utilisée pour développer des applications web rapides et
évolutive coté serveur. Il utilise JavaScript comme langage de script. Node.js utilise un modèle non
bloquant piloté par les événements d’entrée/sortie qui le rend léger et efficace, idéal pour les applications
de données interactives en temps réel. (10)
Cependant, il nous permet de développer très simplement des applications évolutives. Comment ?
En quelques mots : l’idée est d’utiliser des I/O non bloquantes pour gérer toutes les requêtes entrantes,
sortantes ainsi que tout le processus lié à la requête.
Node.js est un serveur dits non bloquants par ce qu’il n’utilise qu’un seul thread pour gérer les
requêtes entrantes. En outre, Node.js ne propose pas, dans ses API, des fonctions bloquantes. Puis toutes
les fonctions fournies par Node.js prennent en paramètre un callback. Une fois que la fonction aura
terminé son traitement, le callback sera appelé avec le résultat en paramètre et une éventuelle erreur. (10)
Ainsi, pendant toute la durée du traitement, le thread sera relâché et pourra être donné à une autre
requête pour effectuer un autre traitement. Nous sommes donc face à un système évènementiel.

Et JavaScript est un très bon choix de langage du fait que l'on peut programmer de manière
fonctionnelle avec celui-ci. Les callbacks dans tous les sens, nous connaissons très bien avec des librairies
comme JQuery qui nous habituent depuis déjà quelques temps à ce type de développement. Contrairement
à ce que l’on peut penser, Node.js n’est pas un serveur HTTP au même titre qu’apache, nginx, lighthttpd
etc… (10)
Node.js est juste un serveur, ce qui signifie qu’il peut se comporter comme un serveur web mais
qu’il n’est pas voué uniquement à ça, il est possible de répondre à toutes sortes de besoins client/serveur
(FTP, mail etc..) à partir du moment où vous lui donnez les bonnes instructions. En effet ce programme
traite les instructions que vous lui donnerez en JavaScript. Ça pourrait paraître surprenant car nous
sommes habitués à voir le JavaScript fonctionné côté client (plus précisément sur le navigateur), et même
si ce dernier a évolué de manière fulgurante ces dernières années (il est loin le temps où JavaScript faisait
uniquement concurrence à flash pour les animations toutes saccadées des menus dépliants) Node.js nous
prouve qu’il est également possible d’utiliser ce langage côté serveur tout comme on le ferait avec du PHP,
ASP, C, Java etc… (10)
IV.3.2.2. Avantages de Node.js
Le JavaScript peut être utilisé comme langage unique pour le serveur et pour la partie cliente, ce
qui homogénéise le programme et facilite la vie du développeur. (10)
Node.js permet de faire des requêtes asynchrone qui permet une gestion des
entrées/sorties de manière non bloquante, très pratique pour les applications qui ont
besoin de temps réel ;
Node.js, utilisé en tant que serveur web, reste très performant (bien plus qu’apache)
en temps de réponse/requête simultané, deux petits graphiques pour vous faire une
idée.

IV.3.2.3. Désavantage de Node.js
Avec Node.js vous devez tout gérer, Node.js est une base, vous ne pourrez pas l’utiliser
directement en tant que serveur web/ftp/webservice/autre… sans avoir à coder. Fort heureusement, il
existe un écosystème de modules déjà écrits, testés et éprouvés qui nous épargnent beaucoup travail (nous
pensons notamment au paquet “Express” qui permet de transformer facilement Node.js en un serveur
Web). (10)
Existe encore très peu de docs francophones sur le sujet,
La maturité12 des librairies à disposition côté serveur serait moins évoluée que celle
de PHP, Python, Ruby, Java etc…
En réalité, le plus gros point faible de Node.js, est précisément sa jeunesse: il est
encore impossible de déterminer si le serveur est fiable sur le long terme en
production.

IV.3. Architecture du déploiement

IV.5. Présentation des résultats
1. Accès à la plate-forme
Un patient lance son navigateur web en tapant l’URL du serveur pour y accéder à la plate-forme.
Cependant, si ce dernier possède déjà un compte, il s’authentifie afin d’y accéder. Dans le cas contraire, il
va cliquer sur l’onglet CREER UN COMPTE pour créer un compte.
2. Création d’un compte
Cette rubrique permet à un patient de créer un compte.

3. Authentification
Une fois créer un compte, donc on s’authentifie (avec son login et son mot de passe) pour
accéder à la plate-forme.
4. Accès à la plate-forme
Après authentification, le patient accède à la plate-forme de téléconsultation. Cependant, il peut choisir
dans la liste suivante un médecin disponible pour une consultation médicale.

On constate qu’il y a trois médecins présents dans la base de données, il suffit juste de cliquer sur un
nom de médecin pour le consulter et en cliquant on lui propose de passer un appel audio ou vidéo. S’il n’est
pas disponible, on lui affiche un message de même s’il a déjà un appel en cours.
Une fois cliqué, la plate-forme demande d’activer les ressources multimédias (caméra, micro, haut-
parleur). Pour autoriser, il suffit de cliquer sur Autoriser
5. Consultation médicale en cours
La première capture montre le médecin Justin qui reçoit un appel vidéo du patient dianko pour une
consultation médicale et la seconde montre le médecin en pleine consultation avec le patient.
Quand un médecin se connecte à la plate-forme, il dispose de la liste de tous les patients enregistrés,
on constate qu’il y a seulement trois patients enregistrés. Le médecin Justin reçoit un appel vidéo du patient
dianko et il a la possibilité d’accepter ou refuser cet appel.

On peut constater que le médecin Justin est en pleine consultation avec le patient dianko. C’est une
pratique avantageuse car cela vous évite des déplacements réguliers à l’hôpital. Pour se déconnecter de la
plate-forme, on clique sur déconnexion à gauche

CONCLUSION
L’essor des télécommunications et l’arrivée d’internet ont permis à la téléconsultation à prendre une
place de plus en plus importante dans la prise en charge des patients.
Les objectifs de ce projet ont été atteints, bien que nous ayons eu à faire face à des difficultés ; nous
avons montré les possibilités qui existent pour faciliter l’accès aux soins des populations à travers la
technologie WebRTC qui nous a permis de déployer une plate-forme de téléconsultation.
Ainsi, nous avons étudié la télémédecine dans sa généralité, puis énumérer les principaux outils
nécessaires suivants : Nous avons utilisé node.js comme plateforme logicielle pour développer notre plate-
forme. Nous avons mis en place une base de données Mongo DB qui stocke les comptes des patients et
médecins avec leurs paramètres de connexion (login et mot de passe). Nous avons conçu notre plate-forme
de téléconsultation en utilisant ces technologies. Lors de la conception, nous avons relevé quelques
difficultés parce qu’il fallait d’abord comprendre les langages de programmation, et la syntaxe des APIs
WebRTC.
Cependant, pour mener à bien l’étude du projet, il a fallu adopter une certaine démarche ;
Premièrement, nous avons effectué une recherche bibliographique afin de connaitre les différents outils et
moyens indispensables pour concevoir notre plate-forme, en suite nous avons procéder en sa conception et
enfin aux différents choix technologiques.
Donc, nous disposons d’une plateforme qui répond aux besoins réels en termes de téléconsultation et
améliore l'accessibilité médicale, particulièrement en région éloignée. .
Par ailleurs, ce projet peut évoluer en intégrant des nouvelles fonctionnalités telles que la
messagerie instantanée, la prescription d’ordonnance via la plate-forme, la création de dossiers médicaux
pour chaque patient.
BIBLIOGRAPHIE ET WEBOGRAPHIE
BIBLIOGRAPHIE ET WEBOGRAPHIE
1. https://fr.wikipedia.org/wiki/T%C3%A9l%C3%A9m%C3%A9decine
2. https://www.infirmiers.com/pdf/tfe-philippe-derouard.pdf
3. https://dl.ummto.dz/bitstream/handle/ummto/464/Zerrouki%20Fodil.pdf?sequence=1&isAllowed=y
4. http://www.66millionsdimpatients.org/la-qualite-de-vos-soins/la-telemedecine/
5. https://fr.wikipedia.org/wiki/Dispositif_m%C3%A9dical
6. http://www.pce-france.fr/fiches-mesureurs/thermometre-usb-pce-ht-71.htm
7. http://www.dino-lite.eu/index.php/fr/component/k2/item/2298-podoscope
8. http://www.usbsteth.com/products/
9. http://www.rxdx.in/advantages-and-disadvantages-of-telemedicine-in-rural-areas/
10. ADBDELRAHIM Ibrahim Mahamat. Conception et réalisation d'une application web de
visioconférence via WebRTC. Dakar : Ecole Centrale des Logiciels Libres et de
Télécommunications, 2013.
11. https://webrtc.org/. [En ligne] https://webrtc.org/architecture/.
12. Xavier Blanc, Isabelle MOUNIER,. UML 2 pour les développeurs. s.l: Editions Eyrolles
13. https://fr.wikipedia.org/wiki/MongoDB
14. Nebra, Matheu. Apprenez à créer votre site avec HTML5 et CSS3. s.l. : Site du zéro, 2012.
15. Johnnan Pardanaud, Sébastien de la Marck. Dynamisze votre site web avec JavaScript. s.l:
Site du zéro, 2012.

ANNEXES
ANNEXES
PARTIE A : INSTALLATION DE L’ENVIRONNEMENT DE

DEVELOPPEMENT
Node.js est notre environnement de développement, cependant, il peut être installé sur les systèmes
suivants : Linux, Windows, et Mac OS. Ainsi, avant d’installer node.js, on installe d’abord son installateur
NPM. Il est à noter que nous travaillons dans un environnement Linux plus précisément Ubuntu 14.04
64bits.
Cependant, l’installation de node.js se fait selon les étapes suivantes :
1. Mise à jour du système
2. Installer Node.js
Il vous suffit donc de rentrer la commande suivante
Pour lancer un serveur nodejs, on tape la commande node nom_serveur.js
Pour voir la version on tape npm –v et node –v

3. Installation des modules
ExpressJS est un module pour nodeJS développé, entre autres, par Tj Holowaychuk. Nous n'allons
utiliser qu'une petite partie des possibilités de ce framework. ExpressJS n'est pas intégré par défaut à
nodeJS, il faut l'installer à l'aide de l'outil npm « node packaged modules ».
À l'aide de la console, placez-vous dans le dossier qui va accueillir votre fichier JavaScript (côté
serveur), puis tapez : npm install express
Pour utiliser MongoDB avec un serveur tournant sous nodeJS, nous allons devoir installer 2 éléments :

PARTIE B : INSTALLATION DE LA BASE DE DONNEES MONGODB
Dans cette rubrique, nous montrons l’installation de notre base de données MongoDB qui va stocker
les patients et les médecins. L’installation se fait selon les étapes qui suivent : (19)
1. Importez la clé publique utilisée par le système de gestion de package
MongoDB ne fournit que des paquets pour les versions de 64 bits LTS (support à long terme) Ubuntu. Les
outils de gestion des paquets Ubuntu (dpkg et apt) assurent la cohérence et l'authenticité des paquets en
exigeant que les distributeurs signent des paquets avec des clés GPG. Exécutez la commande suivante pour
importer la clé publique GPG de MongoDB :
2. Créer un fichier de liste pour MongoDB
3. Mettez à jour les paquets
4. Installer les paquets MongoDB
5. Démarrer et arrêter MongoDB


Langue

Memoire Josue Numbi Master 2 Ec2lt

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Memoire Josue Numbi Master 2 Ec2lt

Titre original :

Transféré par

Droits d'auteur :

REPUBLIQUE DU SENEGAL

Ecole Centrale des Logiciels Libres et de

MEMOIRE DE FIN DE CYCLE

Pour l’obtention du : Diplôme de Master en Télécommunications et Réseaux

SUJET : Conception et Déploiement d’une Plate-forme de Téléconsultation

Lieu de stage : Groupe RTN

Présenté et soutenu par: Professeur Encadreur:

Josué NUMBI LUHEHO Dr. Samuel OUYA

Année Universitaire: 2017-2018

Conception et Déploiement d’une Plate-forme de Téléconsultation II

J’exprime ma plus profonde reconnaissance à :

Conception et Déploiement d’une Plate-forme de Téléconsultation III

L’Ecole Centrale des Logiciels Libres et de Télécommunications (EC2LT) de Dakar en partenariat

Conception et Déploiement d’une Plate-forme de Téléconsultation IV

Avec l'apparition des Technologies de l'Information et de la Communication (TIC), les

Mots-clés : Télémédecine, Téléconsultation, Patient, Médecin, Dispositif médical, Diagnostic.

Conception et Déploiement d’une Plate-forme de Téléconsultation V

Keywords: Telemedicine, Teleconsultation, Patient, Physician, Medical Device, Diagnosis.

Conception et Déploiement d’une Plate-forme de Téléconsultation VI

TABLE DES MATIERES

TABLE DES MATIERES

LISTE DES TABLEAUX................................................................................................................................. 9

LISTE DES FIGURES ................................................................................................................................... 10

I. Présentation Générale ............................................................................................................................... 14

I.1. Présentation de la Structure d’accueil ............................................................................................... 14

I.1.1. Présentation de L’Entreprise RTN ............................................................................................ 14

II.1. Qu’est-ce que la Télémédecine ? .......................................................................................................................... 21

II.2. L’intérêt de la Télémédecine .................................................................................................................................. 22

II.3. Les composantes de la Télémédecine .................................................................................................................. 22

II.3.1. La Téléconsultation .......................................................................................................................................... 22

II.3.2. La Télé-expertise .............................................................................................................................................. 22

II.3.3. La Télésurveillance .......................................................................................................................................... 22

II.3.4. La Téléassistance .............................................................................................................................................. 22

II.4. Les dispositifs médicaux connectés ..................................................................................................................... 23

Conception et Déploiement d’une Plate-forme de Téléconsultation VII

II.5. Avantages et Inconvénients .............................................................................................................. 25

III. Présentation de WebRTC ......................................................................................................................... 27

III.1. Définition et Principes ...................................................................................................................... 27

III.2. Architecture générale de WebRTC .................................................................................................. 28

III.3. Fonctionnement ................................................................................................................................ 30

III.3.1. Architecture de fonctionnement ................................................................................................ 30

III.3.2. La Signalisation ......................................................................................................................... 31

III.3.3. La Traversée de NAT ................................................................................................................ 33

III.4. La Description de session SDP ........................................................................................................ 41

III.5. Les Protocoles de transport (SRTP, RTP, RTCP) ............................................................................ 42

III.6. Les Codecs ....................................................................................................................................... 45

III.7. Les APIs ........................................................................................................................................... 46

IV. Analyse et Conception de la Plate-forme ................................................................................................. 52

IV.1. Architecture et Fonctionnement ....................................................................................................... 52

IV.2. Choix des outils et technologies ...................................................................................................... 53

IV.2.1. Les Langages de programmation .............................................................................................. 53

IV.2.2. Les Protocoles http et WebSocket ............................................................................................. 55

IV.2.3. La Base de données (Mongo DB) ............................................................................................. 56

IV.3. Conception du système..................................................................................................................... 57

IV.3.1. Modélisation du système........................................................................................................... 57

IV.3.2. Environnement de développement ............................................................................................ 59

IV.4. Architecture du déploiement ........................................................................................................... 62

IV.5. Présentation des résultats ................................................................................................................ 63

BIBLIOGRAPHIE ET WEBOGRAPHIE ...................................................................................................... 68

Conception et Déploiement d’une Plate-forme de Téléconsultation VIII

LISTE DES TABLEAUX

LISTE DES TABLEAUX

Tableau II.1 : Comparaison des codecs classiques et WebRTC.....................................................................45

Conception et Déploiement d’une Plate-forme de Téléconsultation