Packagesous R Simulationsepidemies Yvan TCHOUDIE Memoire Ingenieur 2014

Université de Yaoundé I University of Yaounde I
Ecole Nationale Supérieure National Advanced School of

Polytechnique Engineering
Département du Génie Department of Computer
Informatique Science
Conception et réalisation d’un package sous le

logiciel R pour la simulation/évaluation
d’épidémies
Mémoire de fin d’études/Master of Engineering
Présenté et soutenu par

Yvan TCHOUDIE DJOMESSI
En vue de l’obtention du :
Diplôme d’Ingénieur de Conception de Génie Informatique
Sous la Direction de :
Thomas DJOTIO NDIE, CC
Gaëtan TEXIER, Dr
Devant le jury composé de :

Président : Thomas TAMO TATIETSE, Pr.
Rapporteur : Thomas DJOTIO NDIE, CC.
Examinateur : Thomas BOUETOU BOUETOU, MC.
Invité : Gaëtan TEXIER, Dr.
Année académique 2013 - 2014

Mémoire soutenu le 23 Juin 2014
DEDICACES
A l'Eternel Dieu sans qui je n'aurais jamais pu réaliser ce mémoire, à qui je rends grâce pour
sa grandeur, sa bonté et ses bienfaits,
A mes Parents Mr DJOUAKEP Noël et Mme WANDJI Sarath, vous n'avez ménagé
aucun eort pour faire de moi ce que je suis aujourd'hui. Je vous suis redevable à toujours, pour
tout votre amour, votre aection, vos conseils, et vos encouragements,
A mes frères et soeurs Nadine, Juliot, Gaëlle, Christiane, Guilaine, Brice, pour leur attention,
leur soutien, leurs conseils, leur aection, pour leur amour et l'admiration qu'ils ont toujours
portés à mon égard,
A toute ma famille, et à tous mes amis,
A tous ceux qui oeuvrent pour le bien être de l'Humanité,
Je dédie ce mémoire
"Lorsque vous dites la vérité, vous n'avez à vous souvenir de rien." Mark
ii
REMERCIEMENTS
Nos remerciements s'adressent aux personnes suivantes :
• Le Pr Thomas TAMO TATIETSE - pour l'honneur qu'il nous accorde en acceptant de

présider ce Jury.
• Le Dr Thomas DJOTIO NDIE, mon encadrant académique pour sa disponibilité, ses re-
marques, les conseils, et l'encadrement apporté tout au long de ces dernières années d'étude
passées au sein du Département Génie Informatique de l'ENSP.
• Le Pr Thomas BOUETOU BOUETOU, chef du département du Génie Informatique,

pour avoir accepté de faire partie de mon jury en tant qu'examinateur, et aussi pour tous les
enseignements qu'il nous a transmis en mathématiques.
• Le Dr Guy VERNET - Directeur général du CENTRE PASTEUR DU CAMEROUN

(CPC) , pour l'accueil au sein de son entreprise.
• Le Dr Gaëtan TEXIER - Chef du Service d'épidémiologie et de santé publique (ESP)

du CPC, et également notre encadreur professionnel pour son suivi, ses suggestions et les
connaissances nouvelles qu'ils nous a transmises tout au long de ce travail, tous ceci ayant
constitué des éléments essentiels à l'amélioration de ce travail. Sa rigueur nous aura permis
de travailler avec le plus grand professionnalisme.
• Le Dr Georges-Edouard KOUAMOU - Enseignant à l'ENSP, qui a été pour nous durant

toute notre formation d'une aide inestimable ; il est pour nous une réelle source d'inspiration.
• Le Dr Eugène-Patrice NDONG NGUÉMA - Enseignant à l'ENSP, pour la méthodolo-

gie de travail et de raisonnement qu'il nous a enseignée, et pour toutes les connaissances
soudées en mathématiques qu'il nous a transmises. Ce fut un très grand plaisir de l'avoir
pour enseignant.
• Le corps enseignant et administratif de l'Ecole Nationale Supérieure Polytechnique de Yaoundé.
• Mes co-stagiaires, Estelle, Sébastien, Eric Asonganyi, Boris FOUOMENE, Cyprien KENGNE,
Wiyao Banakinao.
• Mes camarades, et mes amis Fernandes TCHOCOTE, Michael KAMTA, Franck NGAR-
INTCHA, Pascal NITCHEU, Fabuela Carelle JIOTCHANG, July TEKAM, Achille SOWA,
iii
Thierry KUATE, Ibrahima YAYA, Karl CHOUAMO, Armand NDJOCK, Lionel TCHAWE,
Moïse NZEUGA, Yannick KEMGNI, Walter NZEACHA, Michelle TOUMENI, Franky Lo-
ryanne, Gaëlle, Paola, Ornella TOUOYEM, Audrey MONGA, Cyrielle Laëticia, Christian
SOPKOUTIE, William DZEUKOU, Victor NDE, Daniel MBONGUE, Alain Charles MBONGO,
Vidal TCHINDA, Espoir TSAGUE, Françoise.
Ing. Segolene Vanessa NZEGA KOUAYEP et

• Mes marraine et parrain accadémiques
Ing. Eddy Cabral KENTSA NLEP.
• Mes soeurs chéries Nadine, Gaelle, Christiane noëlle, Guilaine, Vanelle, Erlande.
• Mes frères, cousins, cousines, neveux, nièces, particulièrement : Juliot, Fortune, Brice, Annicet
Taylor, Junior, Vicky, Franck, Manuella, Samanta, Dominique, Gilles, Christelle, Yannick,
Carelle, Loïc, Dimitri, Hugo, Chouquette, Corneille, Caleb.
• Mes tantes et oncles Hubert, Rachelle, Célestin, Rigobert, Rebecca, Félicité, Virginie, Clau-
dine, Lylyane, Sylvie, Alvine, Annie, Moïse.
• La famille KAMENI, en particulier Raoul et Gaëlle KAMENI.

• Tous ceux qui, de près ou de loin m'ont apporté un quelconque soutien, et ceux qui me
considèrent, j'exprime ici ma sincère reconnaissance.
iv
AVANT-PROPOS
L'Ecole Nationale Supérieure Polytechnique (ENSP) est une école de formation d'ingénieurs de
conception dans divers domaines. La formation comporte 2 cycles à savoir : le cycle MSP (Mathé-
matiques et sciences physiques) équivalent aux classes préparatoires, et un cycle de spécialisation,
où l'étudiant suit une spécialité bien donnée, devant s'achever par un stage ingénieur de n de
formation.
Le présent travail est le fruit des quatre premiers mois de stage ingénieur eectué au Centre
Pasteur du Cameroun (CPC). Le CPC est un Etablissement Public Administratif camerounais
doté de l'autonomie nancière. Il a été créé en 1959 à Yaoundé ; il dispose depuis 1985 d'une
Annexe à Garoua, et d'une antenne à Douala. Il est placé sous la double tutelle des Ministères
de la Santé publique et des Finances. Le CPC est membre du Réseau international des Instituts
Pasteur dont il partage la mission principale, la lutte contre les maladies infectueuses. Il assure
dans ce but quatre missions principales : Missions de service, de Santé Publique, de Recherche, de
Formation.
Le travail en question porte sur la simulation et l'évaluation des épidémies. Il est question
plus précisément de produire toute la partie graphique d'un logiciel de simulation d'épidémies en
utilisant les algorithmes de simulation développés par le CPC.
v
RÉSUMÉ
Le processus de détection d'épidémies est indispensable en épidémiologie. Celà entraîne la mise

sur pied de procédés informatiques comme par exemple des algorithmes de détection épidémiques.
Le problème c'est que les algorithmes de détection n'ont pas tous les mêmes performances, et en
général, un algorithme donné est performant pour la détection d'une épidémie particulière. Dans
le but de tester la performance de tels algorithmes, le Centre Pasteur du Cameroun (CPC) s'est
donné pour objectif de mettre sur pied un logiciel permettant de faire la simulation d'épidémies
temporelles, qui constitueront la base pour ces tests.
L'objectif de ce travail est de mettre en place une interface graphique permettant l'interaction
avec les algorithmes de simulation épidémiques (s'utilisant en ligne de commande) développés par
le CPC. Pour y parvenir, une prise en main du mode de fonctionnement des algorithmes en ligne de
commandes déjà écrits, en syntaxe du logiciel R est faite, an de produire l'interface qui facilitera
leur utilisation. Cet objectif vise aussi à constituer une librairie sous R, donc un package complet
pour de telles simulations.
Le logiciel que nous mettons sur pied est fait sur la base du logiciel de statistiques R, et il est
conçu sous forme de package R.
Mots clés : R, Gtk+, épidémie, simulation.
vi
ABSTRACT
The process of detection of outbreaks is essential in epidemiology. This leads to the development
of computational methods such as epidemic detection algorithms. The problem is that the detection
algorithms do not all have the same performance, and in general, a given algorithm is ecient for
the detection of a particular epidemic. In order to test the performance of such algorithms, the
Centre Pasteur of Cameroon (CPC) has the objective to develop a software to simulation time
epidemics, which form the basis for these tests.
The objective of this work is to implement a graphical interface for interaction with epidemic
simulation algorithms written at CPC (that operate in command line). To achieve this, grip the
operating mode algorithms command line already written syntax of R software is made to produce
the interface to facilitate their use. This objective also aims to build a library, so a complete package
for such simulations.
The software we are developing is done on the basis of the R statistical software, and is designed
as a package R.
Key words : R, Gtk+, epidemic, simulation.
vii
Table des matières
DEDICACES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
REMERCIEMENTS iii
AVANT-PROPOS v
RÉSUMÉ vi
ABSTRACT vii
GLOSSAIRE 1
Introduction générale 1
Contexte de l'étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Problématique et positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Motivations et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1 Concepts théoriques, état des lieux et état de l'art 4

1.1 L'Epidémiologie et La simulation d'épidémies . . . . . . . . . . . . . . . . . . . . . 5
1.1.1 Dénition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.2 Surveillance épidémiologique et alerte précoce . . . . . . . . . . . . . . . . . 5
1.1.3 La simulation des épidémies . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Le logiciel R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Présentation du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Fonctionnalités du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Les codes de simulation présents au CPC . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1 Présentation des codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.2 Fonctionnalités des codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Bibliothèques utilisables sour R pour la conception d'interfaces graphiques . . . . . 11
1.4.1 La bibliothèque Gtk+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.2 La bibliothèque Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.3 La bibliothèque Tcl/Tk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Présentation de la solution 14
2.1 Processus et élaboration du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Analyse du problème . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Spécicités fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Spécicités non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Contraintes techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
viii
TABLE DES MATIÈRES TABLE DES MATIÈRES
2.2.4 Diagramme des cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Diagrammes de séquences système . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 La barre des menus et le Menu Tree . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.3 La barre d'outils et les boutons rapides . . . . . . . . . . . . . . . . . . . . . 31
2.3.4 Les projets et l'explorateur projet . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.5 La zone de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.6 Architecture du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3 Réalisation d'un prototype 34

3.1 Présentation des technologies utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.1 Programmation S4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.2 Les environnements R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.3 Programmation S3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.4 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.5 La bibliothèque Gtk+ et le package RGtk2 . . . . . . . . . . . . . . . . . . . 36
3.2 Organisation en packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.1 Description du packetage de l'application . . . . . . . . . . . . . . . . . . . . 36
3.2.2 Diagramme de packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.3 Diagramme de classes du package Classes . . . . . . . . . . . . . . . . . . . . 38
4 Etude de cas : Cas du CPC 39

4.1 Bilan par rapport au cahier de charge . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Suivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5 Analyse des résultats et faisabilité économique 41

5.1 Application de la solution et résultats obtenus . . . . . . . . . . . . . . . . . . . . . 41
5.1.1 Interface principale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.1.2 Lors de la création d'un nouveau projet . . . . . . . . . . . . . . . . . . . . . 42
5.1.3 Console et Chargement de donnees . . . . . . . . . . . . . . . . . . . . . . . 43
5.1.4 Simulation et Graphiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.5 Diagnostique de convergence et évaluation . . . . . . . . . . . . . . . . . . . 48
5.2 Performance, faisabilité économique et productivité . . . . . . . . . . . . . . . . . . 50
5.3 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Conclusion 53
A Chaînes de Markov et Algorithmes markoviens 54
A.1 Propriété de Markov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.1.1 Dénition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.1.2 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A.2 Propriété de Markov forte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.2.1 Mesure sur l'espace des trajectoires . . . . . . . . . . . . . . . . . . . . . . . 58
A.2.2 Propriété de Markov forte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A.3 Action sur les mesures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.4 Récurrence, transience, périodicité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.4.1 Points essentiels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.4.2 Communication entre points-Irréductibilité . . . . . . . . . . . . . . . . . . . 62
ix
TABLE DES MATIÈRES TABLE DES MATIÈRES
A.4.3 Périodicité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
A.4.4 Récurrence et transience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.5 Méthodes de Monte Carlo par chaînes de markov (MCMC) . . . . . . . . . . . . . . 64
A.5.1 Intérêt des méthodes MCMC . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.5.2 Qualité de l'approximation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.5.3 Deux exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B Annexe : Quelques codes sources du logiciel 67

B.1 Classe Dynamic et quelques méthodes . . . . . . . . . . . . . . . . . . . . . . . . . . 67
B.2 Quelques méthodes de la classe Application . . . . . . . . . . . . . . . . . . . . . . 69
B.3 Quelques méthodes des classes FileBrowser et Tree . . . . . . . . . . . . . . . . . . 71
BIBLIOGRAPHIE 73
x
Table des gures
1.1 Console d'exécution du logiciel R (sous Linux) . . . . . . . . . . . . . . . . . . . . . 7

1.2 Apperçu du logiciel R-Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Apperçu des codes développés par le CPC . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Diagramme des cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Cas d'utilisation Importer les données . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Cas d'utilisation Transformer l'EDF . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 Cas d'utilisation Grapher les données . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Cas d'utilisation Diagnostique de convergence . . . . . . . . . . . . . . . . . . . . . 20
2.6 Cas d'utilisation Simuler une épidémie . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7 Cas d'utilisation Grapher la simulation . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8 Cas d'utilisation Evaluer la simulation . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9 Cas d'utilisation Grapher l'évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.10 Cas d'utilisation Console R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.11 Cas d'utilisation Imprimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.12 Cas d'utilisation Aide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.13 Cas d'utilisation Sauvegarder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.14 Cas d'utilisation Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.15 Cas d'utilisation Nouveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.16 Menu tree glogal du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.17 Menu tree du branches "Fichier" et "Edition" . . . . . . . . . . . . . . . . . . . . . 28
2.18 Menu tree branche "Données" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.19 Menu tree branche "Simulation" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.20 Menu tree des branches "Diagnostique de Convergence" et "Evaluation" . . . . . . . 30
2.21 Menu tree des branches "Graphiques" et "Aide" . . . . . . . . . . . . . . . . . . . . 30
2.22 Architecture de l'application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1 Diagramme de packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Diagramme de classes du package Classes . . . . . . . . . . . . . . . . . . . . . . . 38
5.1 Interface principale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Choix de l'emplacement du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 Choix du nom du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.4 Mini console et editeur basique de codes R . . . . . . . . . . . . . . . . . . . . . . . 43
5.5 Chargement des données depuis un chier . . . . . . . . . . . . . . . . . . . . . . . 44
5.6 Saisie de données et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.7 Transformation de l'EDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.8 Saisie de paramètres pour une simulation . . . . . . . . . . . . . . . . . . . . . . . . 46
xi
TABLE DES FIGURES TABLE DES FIGURES
5.9 Progression de la simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.10 Résultats de simulation, et graphique associé : Il est possible d'enregistrer le graphique,
ou de l'imprimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.11 Résultats de simulation, dans le cas d'une simulation multiple : Les résultats sont
achés dans une autre fenêtre, pour éviter un encombrement de l'IHM . . . . . . . 47
5.12 Diagnostique de convergence : Statistique de test, heidel . . . . . . . . . . . . . . . . 48
5.13 Diagnostique de convergence : Diagnostique graphique, histogramme des valeurs
générées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.14 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.15 Wireframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
B.1 Méthode d'initialisation de la classe Dynamic . . . . . . . . . . . . . . . . . . . . . 67
B.2 Méthode d'initialisation de la classe Dynamic 2 . . . . . . . . . . . . . . . . . . . . 68
B.3 apperçu simulation evaluation simultanée . . . . . . . . . . . . . . . . . . . . . . . . 68
B.4 simulation evaluation 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
B.5 connection signal simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
B.6 Apperçu méthode browseAndFill de la classe FileBrowser . . . . . . . . . . . . . . . 71
B.7 Apperçu méthode setNode de la classe Tree . . . . . . . . . . . . . . . . . . . . . . . 72
xii
Liste des tableaux
4.1 Tableau de l'Etat d'éxecution des diérentes taches relatives au logiciel. . . . . . . . 40
xiii
GLOSSAIRE
Expressions Signication
CPC Centre Pasteur du Cameroun
PMF Probability mass function
EDF Empirical distribution function
TIC Technique de l'information et de la communication
Gtk Giump ToolKit
RGtk2 Package R permettant d'utiliser la bibliothèque Gtk+
IHM Interface Homme Machine
Tcl Tool Command Language
Tcl-Tk Tcl tol
CRAN Comprehensive R Archive Network
ANOVA Analysis Of Variance
LGPL Lesser General Public License
GNOME GNU Network Object Model Environment
XFCE Environnement de bureau sous Linux, d'autres exemples sont KDE, GNOME
ITSM Inverse Sampling Transform Method
UML Unied Modeling Language
Menu Tree Arbre des menus
GUI Graphical User Interface
XML eXtensible Markup Language
Introduction générale
Contexte de l'étude
Le Centre Pasteur du Cameroun travaille à la simulation des phénomènes épidémiques,ce qui

permettra à terme de réaliser l'évaluation des algorithmes de détection des épidémies. Le niveau
de complexité des codes, des graphismes développés et des interactions entre les diérents modules
créés nécessite la réalisation d'une interface utilisateur facilitant l'utilisation de ces ressources. L'un
des aspects les plus importants d'une application est la capacité de l'interface qui est fournie à
interagir avec l'utilisateur. Avec la popularité sans précédent des ordinateurs dans la société d'au-
jourd'hui, les gens se sont nalement mis à attendre de ces interfaces utilisateur d'être graphiques.
Problématique et positionnement
Suite à des études et des analyses statistiques ([1]), des algorithmes de simulation épidémiques
sur le logiciel R ont été écrits et implémentés au CPC. Mais le problème est que ceux-ci pour
être utilisés nécessitent de taper des commandes dans l'invite de commandes de R, de faire les
tests manuellement, les remplissages, et sauvegardes en ligne de commande. . . , ce qui ne rend
pas facile l'interaction avec l'utilisateur (manque de transparence, impossibilité d'impression, de
recherche, d'ajouts d'algorithmes...). Ces algorithmes ne permettent pas non plus de faire des
simulations en utilisant des PMF (Probability mass function) ou EDF (Empirical distribution
function) présents dans une base de données. En plus, bien que la conformité soit respectée, les
algorithmes écrits et implémentés sourent de certains manques parmi les règles du génie logiciel[2],
en particulier la maintenabilité 1 , la portabilité 2 , l'évolutivité... et la structure des codes ne permet
pas de constituer un package. Compte tenu ceci, et des fonctionnalités assez contraignantes oertes
par ces codes, il apparait important de proposer un package complet et plus convivial qui facilitera
l'interaction avec l'utilisateur par le biais d'une IHM 3 (Interaction Homme-Machine), qui permettra
1. L'eort nécessaire pour corriger ou transformer un logiciel
2. aptitude d'un logiciel de fonctionner dans un environnement matériel ou logiciel diérent de son environnement
initial
3. Il s'agit de moyens et outils mis en ÷uvre an qu'un humain puisse contrôler et communiquer avec une
machine
2
Interface graphique d'une plateforme de simulation-évaluation dans le domaine de la surveillance
pour l'alerte précoce
les transactions avec une base de données de courbes épidémiques, comme celle qui est présente
au CPC, et qui donnera d'ailleurs la possibilité d'installer de nouveaux algorithmes de simulation
par téléchargement, par exemple, dans le logiciel. Ainsi, il s'agira pour nous dans le cadre de ce
travail de mettre sur pied une solution logicielle ecace, conviviale, libre et gratuite basée sur ces
algorithmes, en constituant un package R, an de répondre à ces problématiques.
Motivations et ob jectifs
Notre objectif principal est la mise sur pied d'un package pour le logiciel R, qui permettra la
simulation d'épidémies temporelles. De manière spécique, notre travail consiste en :
• La conception et l'implémentation d'interfaces graphiques destinées à l'IHM du package.
• La mise à jour des programmes présents au Centre Pasteur du Cameroun relatifs aux algo-
rithmes de simulation, pour permettre leur exploitation et l'interaction avec les programmes
liés à l'IHM.
• La structuration des programmes ainsi écrits et la création de chiers et programmes sup-

plémentaires nécessaires à la mise en ÷uvre dudit package, ainsi que toute la documentation
nécessaire.
Ce mémoire qui dégage la spécicité de la pratique par rapport aux principes théoriques des
enseignements, sans occulter le lien qui les unit, décrit les travaux menés vis-à-vis du logiciel.
• Dans le chapitre 1, nous ferons un état des lieux et de l'art en présentant l'état des codes de
simulation présents au CPC, ainsi que les diérentes approches connues comme solutions au
problème posé
• Dans le chapitre 2, nous présentons la démarche scientique utilisée pour le projet. Nous
abordons dans ce chapitre la conception du projet, présentons et justions les choix de
modèles et méthodes formelles, ainsi que les diérentes étapes de réalisation.
• Le chapitre 3 décrit les diérents détails de la mise en ÷uvre de notre solution, ainsi que
quelques résultats obtenus.
• Dans le chapitre 4, nous présentons l'intégration de la solution dans le cadre des exigences
du CPC, ainsi que des principales fonctionnalités prévues.
• Avant de conclure notre travail, nous faisons une analyse des résultats et justions la fais-
abilité économique du projet au chapitre 5. Nous présentons également dans ce chapitre les
gains apportés à l'entreprise ainsi que les limites de la solution.
• En conclusion générale nous ferons un bilan exhaustif du travail, avant de proposer quelques
perspectives.
Mémoire d'ingénieur en Informatique 3 TCHOUDIE DJOMESSI Yvan

Chapitre 1
Concepts théoriques, état des lieux et état
de l'art
Les deux types courants d'interfaces utilisateurs pouvant être utilisées pour un logiciel sont
les interfaces en ligne de commande ou Command Line Interface(CLI) et les interfaces graphiques
utilisateur ou Graphical User Interface( GUI). Les CLI se composent d'une console textuelle dans
laquelle on tape des commandes pour eectuer des traitements. Une interface graphique permet
l'interaction avec les environnements de bureau, par le biais des fonctionnalités oertes par la
souris. Ainsi, il sut de faire des clics pour faire les mêmes traitements qui nécessitaient de taper
des commandes.
Nous présentons une brève dénition de l'épidémiologie et des concepts associés. Nous présen-
tons ensuite le logiciel R, les codes R de simulation d'épidémies développés par le CPC, ainsi que
les approches utilisées et les approches utilisables pour la conception de logiciels avec interfaces
graphiques sous R.
4
1.1 L'Epidémiologie et La simulation d'épidémies
1.1.1 Dénition
L'épidémiologie est une discipline scientique dont l'objet est l'étude de la distribution des
problèmes de santé dans une population et le rôle des facteurs qui la déterminent([3]). L'épidémi-
ologie étudie des groupes de personnes et non des individus. L'analyse porte sur les tout type
d'individus( en bonne santé ou frappés par une maladie). L'épidémiologie permet de recueillir,
interpréter, utiliser l'information sur les problèmes de santé. Les objectifs de l'épidémiologie sont
la promotion de la santé et la réduction des problèmes de santé. L'épidémiologie peut servir à la
description de l'état de santé (épidémiologie descriptive), à l'explication de l'état de santé (épidémi-
ologie analytique), ou à l'évaluation des actions de soins (épidémiologie évaluative).
1.1.2 Surveillance épidémiologique et alerte précoce

La surveillance épidémiologique est une méthode d'observation fondée sur des enregistrements
en continu permettant de suivre l'état de santé ou les facteurs de risque d'une population dénie,
en particulier de déceler l'apparition de processus pathologiques et d'en étudier le développement
dans le temps et dans l'espace, en vue de l'adoption de mesures appropriées de lutte([4]). Elle
consiste principalement en la collecte, l'analyse et la diusion systématique des données sanitaires
pour la planication, l'exécution et l'évaluation des programmes de santé publique.
La sureveillance pour l'alerte précoce consiste à détecter de la façon la plus précoce possible le
démarrage d'une épidémie, d'une agression biologique. Elle privilégie l'ajout rapide dans la base de
données, des informations et données sanitaires simples, an qu'une analyse automatique puisse
être faite ([5]).Il est question de collecter et analyser le plus rapidement possible des données
précoces, simples et générales relatives à la santé de la population sous surveillance, en particulier
avant une conrmation diagnostique. Ici, la sensibilité 1 doit l'emporter sur la spécicité 2 .
1.1.3 La simulation des épidémies

Les algorithmes de détection épidémiques sont d'une grande importance dans le domaine de
la surveillance épidémique, car peuvent permettre de maîtriser une épdémie. Pour tester leur ef-
cacité, il faudrait faire des simulations d'épidémies (qui serviront de base pour les tests). La
pertinence d'une simulation d'épidémie implique qu'elle soit faite sur une base réaliste et de façon
reproductible([1, Siwe, 2012]). Ainsi, plusieurs approches de simulation d'épidémie ont été dévelop-
pées, et sont en général basées sur une modélisation spécique mathématique de l'épidémie, ou sur
la dénition d'un ensemble de paramètres de l'épidémie inuençant les algorithmes de détection ([6],
1. la sensibilité d'un test mesure sa capacité à donner un résultat positif lorsqu'une hypothèse est vériée
2. la spécicité mesure la capacité d'un test à donner un résultat négatif lorsque l'hypothèse n'est pas vériée

[1]). Les algorithmes de simulation d'épidémies développés au Centre Pasteur du Cameroun([1]),
utilisent une approche de simulation de courbes épidémiques permettant de prendre en compte
la dépendance entre les cas simulés, et comprennent quatre méthodes de simulation de Monte
Carlo par Chaîne de Markov ([19]) en temps discret. Ces algorithmes comprennent également des
mesures d'évaluation an de comparer les algorithmes et apprécier la qualité de l'ajustement des
données simulées.
1.2 Le logiciel R
1.2.1 Présentation du logiciel

Le logiciel S est l'un des plus puissants logiciels de statistiques. Ses performances font de lui un
logiciel pratiquement incontournable, notamment avec la possibilité qu'il ore de programmer.Ce
logiciel possède 2 implémentations : S-PLUS (version commerciale), et R (version libre). Les deux
sont puissants, exibles, et ont en outre, d'excellentes capacités graphiques[7]. La communauté
participant à l'évolution de R est très grande, et continue de grandir, si bien que l'on dispose
aujourd'hui de milliers de packages disponibles sur le site ociel, le CRAN 3 (Comprehensive R
Archive Network).
R est spécialisé dans le calcul et l'analyse statistique. C'est est un système d'analyse statis-
tique créé par Ross Ihaka et Robert Gentleman([8]) distribué librement en open source sous les
termes de la GNU General Public License. Son développement et sa distribution sont assurés par
plusieurs statisticiens rassemblés dans le R Development Core Team. R est aussi un langage de
programmation, et c'est un logiciel multi-plateforme (Linux, Mac, Windows).
L'interface de base de R est une CLI. La gure 1.1 donne un apperçu de la console d'exécution
du logiciel R (sous Linux).
Il existe toutefois des interfaces développées sous R permettant de faciliter l'exécution de com-
mandes, de chiers, les sauvegardes, etc. L'un des plus courants et populaires, est le logiciel R-
Studio. La gure 1.2 présente un aperçu de la fenêtre de RStudio.
3. Il s'agit d'un site où l'on peut trouver et télécharger du matériel concernant le logiciel de statistiques

Figure 1.1 Console d'exécution du logiciel R (sous Linux)

Figure 1.2 Apperçu du logiciel R-Studio
La particularité d'un logiciel tel que R est que l'on peut créer nos propres commandes en
faisant de la programmation, en écrivant des fonctions qui seront alors appelées depuis l'invite
de commandes R. Cependant, il est possible de programmer des interfaces graphiques dans R
(bien que ce soit moins évident que dans des langages comme C ou JAVA) qui permettront par
exemple à un utilisateur de faire appel à nos commandes de façon beacoup plus conviviale et facile.
De nombreux packages ont à cet eet été développés sous R pour permettre le développement
d'interfaces graphiques ([9]).

1.2.2 Fonctionnalités du logiciel
Le logiciel R est à la fois un langage informatique et un environnement de travail : les com-
mandes sont exécutées grâce à des instructions codées dans un langage relativement simple, les
résultats sont achés sous forme de texte et les graphiques sont visualisés directement dans une
fenêtre qui leur est propre. C'est un logiciel interactif libre qui possède une large collection d'outils
statistiques et graphiques. Parmi ceux-ci, on peut citer entre autres :
• L'analyse des données : R dispose d'un ensemble de fonctions dédiées à l'analyse de données.
On a par exemple les fonctions pour la gestion de tables de contingence (table(), read.table(),
write.table(), read.csv(), read.delim(), as.dataframe(), write.csv2(), table.paint()...), la généra-
tion des échantillons aléatoires (fonction sample()), les caractéristiques d'une variable statis-
tique (summary, sample...), et bien d'autres
• L'Analyse numérique
• L'Algèbre linéaire : R permet de faire les opérations classiques sur vecteurs, tableaux et
matrices.
• La modélisation statistique
• Les analyses discriminantes et multivariées, les tests de normalité, la régression linéaire,
l'ANOVA...Ici, on distingue des fonctions telles que ks.test() (test de Kolmogorov Smirnov),
shapiro.test() (test de Shapiro), qqnorm(), qqplot(),des fonctions permettant de faire le test
de student, de Wilcoxon, le test de corrélation de Pearson, le test exact de Fisher...
• On peut également citer l'analyse discriminante linéaire, l'analyse discriminante quadratique,
les arbres de régression,
• Gestion de données, lecture, manipulation, stockage.
• Le moteur de sorties graphiques : il permet de réaliser des sorties écran ou chier.
1.3 Les codes de simulation présents au CPC
1.3.1 Présentation des codes

Les codes de simulation d'épidémies présents au CPC ont été développés en langage R. Il
s'agit de programmes procéduraux 4 destinés à être utilisés sous forme de commandes 5 . Il s'agit
principalement de 2 chiers contenant un ensemble de fonctions écrites, et testées, avec les résultats
des tests. Ainsi, à l'intérieur des chiers, on trouve des fonctions écrites, les appels de ces fonctions,
et les résultats des appels (en commentaires). Les codes sont bien commentés, mais les variables
(en particulier les paramètres des fonctions) ne sont pas susamment explicites (en général, il
s'agit de "data"), et les codes présentent certains bugs. La gure 1.3 donne un apperçu d'un de
4. La programmation procédurale est fortement basée sur l'utilisation de fonctions et procédures
5. Quand on écrit une fonction sous R, la fonction se comporte comme une commande, et peut ainsi être utilisée
avec les paramètres adéquats

ces codes.
Figure 1.3 Apperçu des codes développés par le CPC
1.3.2 Fonctionnalités des codes

Ces codes orent un ensemble de fonctionnalités utiles et intéressantes :
• Sélectionner une PMF
• Modier la PMF
• Simuler une épidémie
• Grapher la simulation
• Evaluer la simulation
• Faire un diagnostique de convergence dans le cas d'un algorithme markovien (Voir annexe)
• Grapher l'Evaluation
Mais tout celà necessite de taper des commandes. Ces fonctionnalités s'avèrent donc insu-
isantes pour pouvoir travailler aisément sur des simulations-évaluations, et ne facilitent pas l'aspect
gestion de données.

1.4 Bibliothèques utilisables sour R pour la conception d'in-
terfaces graphiques
1.4.1 La bibliothèque Gtk+

Présentation de Gtk+
La bibliothèque Gtk+ a été développée par Peter Mattis, Spencer Kimball, et Josh MacDonald
en 1997 à l'Université de Californie, Berkeley([10]). Sous licence Lesser General Public License
(LGPL), GTK + a été adoptée comme boite à outils graphique par défaut de GNOME (GNU
Network Object Model Environment) et XFCE, deux des environnements les plus populaires de
bureau Linux. Alors qu'il était à l'origine utilisé sur le système d'exploitation Linux, GTK+ a
depuis été étendu pour supporter d'autres systèmes d'exploitatios, tels que Microsoft Windows,
Mac OS, BeOS, Solaris, et d'autres. Gtk+ es une bibliothèque multiplateformes, pouvant être
utilisée dans de très nombreux langages de programmation, parmi lesquels on peut citer Syp
Script (avec GTK-Server), PHP (avec PHP-GTK), JavaScript++ ...
Fonctionnalités de Gtk+
• La bibliothèque Gtk+ permet de créer des objets appelés widgets, pouvant être entre autres :
des boutons, des barres de progressions, des zones d'achage et des zones de texte
• Ces objets peuvent être incorporés dans une fenêtre, ou une boite de dialogue (qui sont elles
aussi des widgets)
• Pour assurer l'interaction avec l'utilisateur, GTK est dirigé par des événements : ce qui signie
que l'objet restera inactif jusqu'à ce qu'un événement survienne. Il sera alors transformé
en signal par le widget qui a été pressé.
1.4.2 La bibliothèque Qt
Présentation de la bibliotheque Qt
Qt est une bibliothèque de développement d'applications graphiques multi-plateforme, perme-
ttant de compiler et exécuter des applications sur Windows, Mac OS X, Linux, et les diérentes
marques de Unix. Qt, aujourd'hui rachetée par Nokia, a été développée à l'origine par la société
Trolltech[11] pour faciliter la programmation en C++ d'applications graphiques. Aujourd'hui, Qt
peut être utilisée dans de nombreux langages de programmations et plateformes, comme Java,
Python, Ruby, PHP, R, .Net... Une grande partie de Qt est consacrée à fournir une interface de
la plate-forme permettant de presque tout faire, en allant de la représentation des caractères en
mémoire à la création d' applications graphiques multithread. Elle est principalement connue dans
le monde Linux pour être à la base de l'environnement graphique KDE. La bibliothèque Qt est

sous double licence. En eet, les versions GNU/Linux et UNIX de Qt sont sous licence GNU GPL,
et pour le reste, c'est la licence commerciale. Cette politique de double licence a été appliquée
uniquement pour GNU/Linux et UNIX dans un premier temps, mais depuis la version 4.0 de Qt,
elle est appliquée pour tous les systèmes.
Fonctionnalités de Qt
• La bibliothèque Qt permet aussi de créer des widgets.
• Les fonctionnalités de Qt permettant l'interaction avec l'utilisateur reposent sur les notions
de signal et slot.
• Un signal est une méthode qui est émise et non exécutée lorsqu'elle est appelée.
• Le programmeur, déclare les prototypes de signaux qui pourraient être émis.
• Un slot est une fonction membre qui peut être invoquée à la suite de l'émission du signal.
1.4.3 La bibliothèque Tcl/Tk

Présentation
Tcl (Tool Command Language) est un module de langues à multiples facettes.Tcl peut être util-
isé comme langage de script de commandes, comme un puissant langage interprété multi-plateforme
, comme une plate-forme de prototypage rapide,ou comme l'épine dorsale d'une application qui
est principalement écrite en C ou Java. Tcl est à la fois un logiciel libre et un ensemble support
commercial . Le noyau du langage Tcl est principalement soutenu par un groupe mondial de bénév-
oles. Les packages d'exécution Tcl/Tk sont inclus dans les packages Linux et FreeBSD. Tcl possède
plusieurs extensions, dont la plus populaire est Tk qui signie Tool Kit. C'est une extension de Tcl
développée en 1990 par John Ousterhout, qui fournit des composants de l'interface graphique par
Tcl.
Fonctionnalités
L'extension Tk fournit des outils pour la programmation graphique, y compris les toiles de
dessin, boutons, menus, etc. L'extension Tk est considérée comme faisant partie de la base de Tcl
et est incluse dans les distributions de code source sur SourceForge, et dans les distributions biaires
aussi. Les bibliothèques Tcl et Tk peuvent être intégrées dans une application compilée en C, Java
ou Fortran et peuvent être utilisées dans des langages interprétés, comme R. La syntaxe simple de
Tcl fait usage unique de scripts rapides et faciles à écrire.
Bien que pas aussi modernes que GTK + ou Qt, ces bibliothèques sont préinstallées en binaire
Windows, contournant ainsi les problèmes d'installation pour l'utilisateur nal. Les liaisons de R
à Tk ont été les premières à apparaître, et on conduit à de nombreux packages développés pour
R, parmi lesquels on peut citer Rcmdr, Sim.DiProcGUI, et bien d'autres. Son utilisation s'est

principalement généralisée par la facilité de développement d'interfaces graphiques pour X11 6 . Tcl
envoie simplement une commande comme une chaîne de texte à l'interprète Tcl qui renvoie le
résultat dans un objet de classe tclObj. La fonction Tcl peut être utilisée pour lire des scripts Tcl
avec("source lename"). Cela permet aux scripts arbitraires Tcl de s'exécuter dans une session R 7 .
6. X11 est une fonctionnalité et une technologie de rendu graphique utilisée par le logiciel R
7. Une session R correspond à une exécution du logiciel. Dans une telle session, on dispose des informations
et de l'historique des commandes, des données en mémoire depuis le lancement de la session, et il est possible de
sauvegarder une session à la n de son travail avant de fermer le logiciel

Chapitre 2
Présentation de la solution
Dans ce chapitre nous pésentons l'analyse et la conception de notre solution.Nous allons dans
un premier temps présenter le processus logiciel adopté. Il s'en suivra la présentation des besoins
fonctionnels et non fonctionnels ainsi que les contraintes techniques. Enn, nous allons présenter
la conception du logiciel ainsi que la manière avec laquelle il intègre ses diérents modules.
2.1 Processus et élaboration du logiciel
La création de notre logiciel passe par la mise en ÷uvre d'un ensemble d'activités qui permettent
la conception, l'écriture et la mise au point du logiciel en question (son implémentation par des
programmes informatiques). Ces activités ont été formalisées sour forme d'un processus logiciel.
Un processus logiciel est un ensemble structuré d'activités et leurs résultats menant à la réalisation
ou modication d'un produit logiciel. Le but d'un processus logiciel est de produire des logiciels
de qualité répondant aux besoins de leurs utilisateurs dans des temps et des coûts prévisibles.
Vu la complexité du système à développer, les spécications non fonctionnelles assez instables, la
taille de l'équipe de développement qui est réduite à une seule personne, l'aspect fonctionnel a été
privilégié. En eet, la mise en pratique des principes de la méthode agile XP ([12])a été choisie
comme modèle de Processus.
2.2 Analyse du problème
Nous présentons dans cette section l'ensemble des charges fonctionnelles et non fonctionnelles du
système à mettre en place, et les contraintes liées à la technologie. Nous formalisons enusite l'analyse
du problème à l'aide d'UML (Unied Modeling Language). UML est un langage de modélisation
graphique à base de pictogrammes. Il est apparu dans le monde du génie logiciel, dans le cadre de
la conception orientée objet[13]. La modélisation UML consiste en la conception de diagrammes
décrivant chacun soit l'analyse soit conception du logiciel ou d'un module du logiciel. Parmi ceux-
14
ci, on peut citer entre autre les diagrammes de cas d'utilisation, les diagrammes de séquences
systèmes, les diagrammes de séquence de conception (ou simplement diagrammes de séquence),
les diagrammes d'état de navigation, les diagrammes d'activité de navigation, les diagrammes de
communication, les diagrammes de classes participantes, les diagrammes de classes de conception,
les diagrammes de packetages...
2.2.1 Spécicités fonctionnelles

La solution proposée doit permettre à un utilisateur de suivre le processus de simulation-
évaluation des épidémies. Elle permettra également à l'utilisateur de valider les processus via
des évaluations et diagnostiques, et d'assurer la gestion de données. Pour cela, les fonctionnalités
requises sont les suivantes
• Importer des données EDF (Empirical Distribution Function) relatives à une épidémie, les
données pouvant se trouver soit dans un chier au format csv (Interprétable par un tableur),
soit dans une base de donnée, ou encore dans un simple chier texte.
• Sauvegarder des données (simulées ou non) dans une base de données, ou dans un chier
(csv, cvs, txt...)
• Simuler une épidémie, en utilisant les fonctions mathématiques de base (Methode linéaire,
exponentielle, sinusoïdale...)
• Simuler une épidémie, en utilisant les Méthodes de Monte Carlo, notamment la méthode
binomiale, la méthode ITSM (Inverse Transform Sampling Method), les méthodes basées sur
les chaines de Markov
• Faire des diagnostiques de convergence dans le cas de simulations avec des algorithmes
markoviens.
• Assurer l'évaluation de la simulation ou des simulations eectuée(s) notamment par la répli-
cation et le calcul de métriques d'évaluations.
• Permettre la simulation multiple, laquelle pourra être évaluée, et dans le cas d'algorithmes
markoviens, soumise à un diagnostique de convergence.
• Permettre de faire des graphiques sur l'interface, relatifs aussi bien aux courbes épidémiques
d'origines qu'aux résultats de simulation, et aux diagnostiques de convergence graphiques.
• Orir un module d'aide avec des démonstrations à l'appui, pour faciliter la prise en main du
logiciel.
2.2.2 Spécicités non fonctionnelles

En plus des contraintes fonctionnelles précédemment citées, le logiciel en question devra répon-
dre à des exigences secondaires
• La solution développée doit pouvoir s'intégrer sous forme de package automatiquement au
logiciel R, et interagir avec celui-ci pour permettre une utilisation simple.

• L'application doit pouvoir fonctionner sur toutes les plateformes supportant le logiciel R
(Linux, MS Windows, Mac OS)
• L'application doit être conviviale et ergonomique.
• L'application doit être robuste, portable et maintenable.
• Ainsi l'installation des dépendances (autres packages) devra se faire automatiquement, ainsi
que la résolution de dépendances.
• L'application devra permettre une gestion des données conviviale et assez intuitive, pour
faciliter la tâche à l'utilisateur.
2.2.3 Contraintes techniques

• Le logiciel sera développé en langage R (langage de programmation du logiciel R)
• Tous les outils utilisés pour la conception du logiciel devront être des outils gratuits
2.2.4 Diagramme des cas d'utilisation

La gure2.1 présente le diagramme des cas d'utilisation de l'application. Il s'agit, comme précisé
dans le livre UML([12]) de Pascal Roques, d'un diagramme qui montre les interactions fonction-
nelles entre les acteurs et le système que nous mettons en place. Un cas d'utilisation est une
fonctionnalité globale pouvant être nécessitée de la part de l'utilisateur. Pour ce qui est de la
séquentialité, on se rend compte compte que certaines tâches pour être exécutées nécessitent que
d'autres le soient déjà. Celà est matérialisé sur la gure 2.1par le mot clé "include". Ainsi, par
exemple, il apparaît sur cette gure qu'une tâche "Evaluer la simulation" nécessite qu'une tache
"Simuler une épidémie" soit déjà eecutue.

Figure 2.1 Diagramme des cas d'utilisation
2.3 Conception
2.3.1 Diagrammes de séquences système

Importer les données

Figure 2.2 Cas d'utilisation Importer les données
Transformer les données

C'est le cas d'utilisation permettant la modication de la distribution de probabilité (EDF)
initiale pour en obtenir une autre
Figure 2.3 Cas d'utilisation Transformer l'EDF

Grapher les données
Ce cas d'utilisation permet de représenter graphiquement la distribution de probabilité associée
à l'Epidémie initiale. Par défaut, ce sont les EDF initiales qui sont utilisées. Mais s'il y a eu
modication d'EDF, ce sont les EDF modiées qui seront utilisées à la place.
Figure 2.4 Cas d'utilisation Grapher les données

Diagnostique de convergence
Ici, il s'agit de diagnostiquer la qualité de la convergence pour un algorithme de simulation

basé sur les chaines de markov.
Figure 2.5 Cas d'utilisation Diagnostique de convergence
Simuler une épidémie
C'est le cas d'utilisation principal de simulation d'épidémie. A partir de données initiales, on

calcule à partir d'un algorithme donné les données relatives à l'Epidémie que l'on veut simuler,
selon les paramètres fournis pour la simulation.

Figure 2.6 Cas d'utilisation Simuler une épidémie

Grapher la simulation
Figure 2.7 Cas d'utilisation Grapher la simulation
Evaluer la simulation
Figure 2.8 Cas d'utilisation Evaluer la simulation

Grapher l'évaluation
Figure 2.9 Cas d'utilisation Grapher l'évaluation

Console R
Ici, il s'agit du cas d'utilisation permettant à l'utilisateur qui a besoin pour une quelconque
raison de saisir du code R. Il peut le faire directement sur le logiciel, soit en mode console directe,
soit dans un mini editeur purement basique développé sur l'interface de notre logiciel.
Figure 2.10 Cas d'utilisation Console R
Imprimer
Figure 2.11 Cas d'utilisation Imprimer

Aide
Nous permettons ici de faciliter la prise en main du logiciel à l'aide d'une documentation, et
de quelques exemples. Sont également prévues des démos.
Figure 2.12 Cas d'utilisation Aide

Sauvegarder
Figure 2.13 Cas d'utilisation Sauvegarder

Edition
Figure 2.14 Cas d'utilisation Edition
Nouveau
Figure 2.15 Cas d'utilisation Nouveau

2.3.2 La barre des menus et le Menu Tree
Etant donné que notre logiciel est beaucoup basé sur l'utilisateur, et ce qu'il fait, et vu la
complexité des codes et la densité des fonctionnalités, nous avons décidé de mettre une barre de
menu sur l'interface principale du logiciel. Elle permettra à l'utilisateur d'avoir accès à toutes les
fonctionnalités de l'application. Le Menu Tree (Arbre des menus) décrit l'arborescence des menus
rattachés à la dite barre de menus. Les gures suivantes présentent l'arbre des menus du logiciel
Figure 2.16 Menu tree glogal du logiciel
Figure 2.17 Menu tree du branches "Fichier" et "Edition"

Figure 2.18 Menu tree branche "Données"
Figure 2.19 Menu tree branche "Simulation"

Figure 2.20 Menu tree des branches "Diagnostique de Convergence" et "Evaluation"
Figure 2.21 Menu tree des branches "Graphiques" et "Aide"

Ainsi, on observe sur le Menu Tree 92 menus parmi lesquels on dénombre 79 feuilles 1 . Celà
coorespond à au moins 79 cas de navigation (délenchables par clics de l'utilisateur)
2.3.3 La barre d'outils et les boutons rapides

Tandis que la barre de menus se veut exhaustive en terme de fonctionnalités de l'application,
la barre d'outils propose quelques raccourcis vers des menus susceptibles d'être les plus utilisés. En
eet, pour les fonctionnalités les plus souvent utilisées, nous allons créer des outils correspondants
que l'on regroupera en une barre d'outils. A coté de celle-ci, des boutons raccourcis seront également
placés pour les fonctionnalités telles que Simuler une épidémie, Grapher la simulation...
2.3.4 Les projets et l'explorateur projet

An de faciliter les taches de gestion, et d'assurer une bonne visibilité des taches eectuées
ainsi que des données manipulées, Nous avons décidé d'utiliser l'approche de projet. Un projet
correspond à un ensemble de travaux eectués sur la base d'un ensemble de données en entrée. A
partir de données, toutes les simulations eectuées, toutes leurs évaluations, les graphiques associés,
... seront relatifs à un projet donné. Ainsi, les données et résultats relatifs à un projet pourront
être enregistrés, et visualisés, et l'utilisateur pourra créer autant de projets que nécessaire. An de
faciliter le suivi des données manipulées, chaque projet sera doté d'un explorateur projet qui sera
situé dans une zone bien précise de l'interface du logiciel. Pour ce faire, nous utiliserons un arbre
dont le sommet sera représenté par le libellé du projet, et les noeuds par les diérents dossiers et
chiers relatifs au projet en question.
2.3.5 La zone de travail

Il sera également question de créer un sous-module pour gérer le coeur même des travaux de
simulation. Pour le rendu, une zone de l'interface fera oce de zone de travail. Ainsi, toutes les
données, les résultats de simulation, de diagnostique pour les algorithmes markoviens, ainsi que les
graphiques, les résultats d'évaluation seront présentés dans cette zone. Y seront également présents
quelques boutons pour gérer de façon rapide certains éléments de cette zone (Par exemple exporter
un graphique).
2.3.6 Architecture du système

Nous présentons ici l'architecture du logiciel que nous mettons en place. On peut observer sur
la gure 2.22 pricipalement 4 modules :
1. Une feuille d'un arbre est un noeud qui n'a pas de ls

• Le module GUI Statique.
Dans ce module seront développés tous les composants du logiciel qui sont statiques, donc qui
ne varient pas aucours de l'utilisation du logiciel (Barres de menus, Barres d'outils...), ainsi
que les algorithmes associés à l'action de l'utilisateur sur ces composants (clicks, déroulement
d'un menu...)
• Le module GUI Dynamique.
Ici, il s'agit des composants qui varient en fonction des actions de l'utilsateur (que ce soit sur
ces modules où d'autres) On a principalement ici les composants tels que la zone graphique,
les zones de données, les zones d'achage, les zones pour la console, l'explorateur projet...
• Le module utilitaires de simulations et de traitements (Utils).
Ce module sera constitué principalement des codes présents au CPC, et d'autres fonctions
diverses de la logique métier 2 qui seront écrites, et qui ne sont pas liées à la partie graphique
du logiciel.
• Le module navigateur de chier.
Ce module permettra de gérer la logique métier liée aux chiers d'un projet.Tandis que l'ex-
plorateur projet (du module GUI dynamique) gére l'achage sur l'interface, toutes les anal-
yses liées à l'écoute d'évenements sur le projet(suppression de chiers, nouveaux chiers...)
seront gérées par le Navigateur de chier, qui communiquera à chaque fois avec l'Explorateur
projet pour l'achage. Ainsi, c'est le navigateur chier qui manipulera l'arborescence d'un
projet.
2. La logique métier correspond aux fonctions de traitement des données, sans se préoccuper ni de la provenance
des données, ni de la destination des résultats. Il est juste question de produire des données en entrée, traitements,
et données en sorties

Figure 2.22 Architecture de l'application

Chapitre 3
Réalisation d'un prototype
3.1 Présentation des technologies utilisées
3.1.1 Programmation S4
La structure du langage R, qui est de manière à faciliter la tache à l'utilisateur (qui n'est à
priori pas un informaticien), n'intègre pas vraiment la philosophie orientée objet. C'est un langage
procédural dont la syntaxe est assez simple. Toutefois, il intègre un concept orienté objet (qui n'est
pas aussi developpé comme dans les langages tels que Java, C++). Il s'agit de la programmation
S4. S4 est la quatrième version de S. Et en plus la notion d'objet en S4 n'est pas vraiment précise.
L'encapsulation n'est pas vraiment assurée dans la mesure où toute méthode déclarée doit d'abord
être dénie de façon générique 1 (il s'agit d'une dénition globale, visible par tous les objets de la
session de travail), et les méthodes sous R sont comme les fonctions. Or il est impossible de passer
des variables par référence, ni par adresse à une fonction à R (ce qui fait qu'une fonction R ne
peut modier aucune variable ne lui étant pas locale 2 ). Ainsi, les setters 3 ne sont vraiment pas
capables de faire leur travail (qui est de modier des valeurs). Ceci est d'autant plus restreint si
l'on tient compte du fait qu'il n'existe pas non plus la notion de pointeurs sous R. Ainsi, l'objet
devient pratiquement inutilisable. En fait il faudrait que toutes les variables de tout le logiciel
soient globales, et que chaque fois que l'on veuille en modier une, qu'on le fasse par aectation,
en faisant par exemple "var1 <- updateMethod(var1) ;".
1. via la fonction setGeneric

2. Une variable locale à une fonction est une variable qui n'existe que dans le contexte d'exécution de la fonction
3. en langage objet, un setter est une méthode qui modie un attribut de l'objet
34
3.1.2 Les environnements R
Heureusement, il existe une fonctionnalité de R(que beaucoup d'utilisateurs de R négligent 4 )
qui nous a permis de résoudre le problème. Il s'agit des environnements. Toutefois, les environ-
nements sont assez délicats, et demandent d'être minutieux dans la manipulation. Ces derniers
sont beaucoup plus ecaces et complexes que les pointeurs dans un contexte d'encapsulation, et
aussi lorsque l'on veut développer des méthodes pour modier des objets. Un environnement, c'est
comme une abstraction d'une mémoire 5 . Ainsi, chaque objet, variable, fonction, methode déclarée
sous R appartient à un environnement donné, un environnement pouvant lui même être un objet
d'un autre environnement. L'environnement le plus grand, c'est le global Environment (environ-
nement par défaut), dont le père est emptyenv. Ainsi, pour assurer non seuleument l'encapsulation,
mais aussi aux setters de pouvoir faire leur travail, nous créons un environnement pour chaque
objet instance d'une classe, et tous les attributs de cet objet sont traités dans cet environnement.
3.1.3 Programmation S3
Le mécanisme orienté objet S4 étant encore jeune (et donc pas aussi expérimenté que les mé-
canismes objets des langages comme Java, C#, C++), il est très complexe à mettre en oeuvre
et parfois moins ecace (par exemple lorsque l'on veut écrire une fonction capable d'agir sur des
objets natifs de R). De plus, Il est assez dicile de gagner aussi bien en largeur qu'en hauteur de
la même façon : en eet, le fait que la syntaxe de R soit de manière à ne pas être très restric-
tive, et qu'en plus c'est un langage faiblement typé à la base procédural, et interprété, fait que
certaines fonctionnalités pour être implémentées, devraient sour de ne pas bénécier des possi-
bilités oertes par la programmation orientée objet, et être écrites de façon procédurale, ce qui est
assuré par la programmation S3. Ainsi les codes développés au CPC (qui étaient naturellement en
programmation S3) ont été laissés en programmation S3, ainsi que les modications apportées.
3.1.4 Environnement de développement

Les logiciels GUI pour l'utilisation de R sont assez nombreux (RStudio, RGui, TexStudio...),
mais ne sont pas vraiment adaptés pour la programmation (détecttion instantannée d'erreurs, In-
dentation automatique ecace, ...). Le logiciel ECLIPSE optimisé pour le langage Java, dispose
d'un plugin, statEt, permettant de développer en tant que programmeur des applications sous R,
et d'exécuter du code R. Son mode de coloration est nettement meilleur pour le programmeur,
y compris son mode d'indentation et de sélection. Ajouté à celà, son navigateur de projet assez
convivial, et très bien orienté projets de développement, le rend nettement mieux pour le devel-
oppement sous R. En plus il permet la détection automatique instantanée des erreurs de syntaxe.
4. ce qui n'est pas assez surprenant, vu qu'ils sont pas très nombreux à être des programmeurs, dont à s'intéresser
à des fonctionnalités de programmation avancée
5. Un environnement r peut être vu comme un espace de stockage d'objets R

Mais étant donné que le logiciel ECLIPSE n'est pas conçu à la base pour les développeurs R (mais
Java), son débogueur n'est pas encore très ecace, contrairement à celui de RStudio. De plus cer-
taines fonctionnalités ne sont pas supportées par le plugin statEt (comme par exemple la gestion
d'éditeurs 6 lors de l'édition de textes (chaines de caractères).
3.1.5 La bibliothèque Gtk+ et le package RGtk2

Nous avons choisi d'utiliser la bibliothèque Gtk+, car elle est multiplateformes, d'actualité (elle
ore un très grand nombre de fonctionalités modernes, contrairement à Tcl/Tk), et permet de por-
grammer ausi bien en mode procédural qu'en mode orienté objet, contrairement à la bibliothèque
Qt qui est développée principalement de façon à permettre la programmation orientée objets. A
celà, on peut aussi ajouter le fait que pour un développement sous Windows à sources fermées avec
Qt, il est nécessaire d'acheter une licence. Les widgets créés pour notre application peuvent être
disposés dans une fenêtre selon notre volonté grâce à un logiciel approprié comme Glade ([14]),
qui génère un chier XML pour l'interface. Le chier XML généré par ce logiciel peut alors être
modié directement et adapté aux besoins, pour enn être lu depuis R grâce au package RGtk2
et à la fonction gtkBuilder(). Le comportement des objets graphiques est alors géré grâce à la
fonction gSignalConnect().
3.2 Organisation en packages
3.2.1 Description du packetage de l'application

Etant donné que notre logiciel est développé en couplant les méthodes de programmation ori-
entée objet et procédurale, Nous aurons un package pour les codes orientés objet, et un autre pour
les codes procéduraux. Nous disposerons également d'une couche d'interopérabilité, principalement
composée de chiers XML des diérentes interfaces de l'application. Enn, étant donné que toute
méthode doit avoir une dénition visible par tous les modules de l'application, Nous aurons un
package Generique pour les diérentes dénitions de méthodes. Enn, une couche de persistance
permettra les transactions avec les sources persistentes de données (Base de donnée).
6. notamment lors de l'utilisation de la fonction edit

3.2.2 Diagramme de packages
Figure 3.1 Diagramme de packages

3.2.3 Diagramme de classes du package Classes
Le package Classes est constitué uniquement de classes (donc d'abstractions d'objets en S4).
La gure3.2 représente le diagramme de classes de ce package. Les autres packages contiennent
soit des programmes S3, soit des chiers Xml.
Figure 3.2 Diagramme de classes du package Classes

Chapitre 4
Etude de cas : Cas du CPC
4.1 Bilan par rapport au cahier de charge
Le CPC attendait de ce projet un logiciel tout en un permettant :

• d'assurer la simulation des épidémies
• l'évaluation des simulations
• d'assurer le diagnostique de convergence des algorithmes markoviens
• de faire les graphiques de données, de simulations et d'évaluations
• d'assurer une bonne gestion de données et d'entrées-sorties
Tout celà en utilisant les codes de simulation présents au CPC, et en les améliorant le cas
échéant.
La solution que nous avons développée répond à chacune de ces exigences, exepté le module gestion
de données (Recherches, Suppression, Importation depuis un serveur distant, aide) qui est encore
en cours de conception. L'état d'avancement de la réalisation du logiciel est actuellement de 80%.
4.2 Suivi
Une première démo a été faite, et les bugs ont été relevés et corrigés. Les résultats obtenus
suite à la coreecition de ces bugs sont présentés au chapitre suivant. Actuellement, le module de
gestion de données sur un serveur MySQL distant nécessite d'avoir le prototype de la BD, ce
qui sera bientôt le cas, et celà permettra d'achever ce module. Concernant le module d'aide, il
est en pleine conception, et comprendra notamment des démos intégrées au logiciel, permettant
de prendre en main facilement l'utilisation du logiciel. Le module de gestion de données et édi-
tion est presque achevé. Le tableau suivant présente l'état des diérentes taches constituant les
spécications logicielles
39
Tache Etat
Import export EDF Achevée
Graphiques EDF Achevée
Transformation EDF(simulation jours) Achevée
Simulation d'épidémies Achevée
Evaluation de la simulation d'une épidémie Achevée
Graphiqes de la simulation Achevée
Graphiqes de l'Evaluation En cours
Simulation multiple Achevée
Diagnostique de convergence Achevée
Module Gestion Projet Achevée
Edition console, Impression, entrées-sorties Achevée
Module Edition En cours
Module Interaction Serveur MySQL distant En cours
Module Aide En cours
Table 4.1 Tableau de l'Etat d'éxecution des diérentes taches relatives au logiciel.

Chapitre 5
Analyse des résultats et faisabilité

économique
L'implémentation du prototype de notre application ayant été faite, ainsi que son application
dans le contexte des préoccupations exprimées par le CPC, nous présentons dans le présent chapitre,
une analyse des résultats obtenus, ainsi que les détails concernant la productivité et la faisabilité
économique du projet. Nous allons pour celà montrer le donner que nous gagnons par l'application
des diérentes méthodes proposées, ensuite nous ferons une analyse économique du déploiement
de la solution et nous allons terminer par un bilan. Il faut noter que le logiciel dans son état actuel
est achevé à 80% et sera complètement achevé à la n du stage, et actuellement les programmes
nouvellement écrits font un total de plus de 10 000 (dix-milles) lignes de code.
5.1 Application de la solution et résultats obtenus
5.1.1 Interface principale

La gure 5.1 présente l'interface principale du logiciel
L'on peut remarquer sur cette interface diérentes zones :
• La barre des menus : elle permet à l'utilisateur d'avoir tous les repères pour l'utilisation du
logiciel. C'est le résultat de la mise en pratique du Menu tree présenté au Chapitre 2.
• La barre d'outils dont il était question au Chapitre 2, ainsi que les diérents boutons de
raccourcis sont également présents
• La barre de gauche correspond à l'explorateur de chiers présenté dans la conception
• La zone centrale correspond à la zonde de travail.
• La partie sud de la fenêtre contient une barre de progression permettant de suivre l'évolution
de longues simulations.
41
Figure 5.1 Interface principale
5.1.2 Lors de la création d'un nouveau projet

Lorsque que l'on sélectionne le menu nouveau projet, ou que l'on clique sur new, diérents
écrans sont achés pour assurer la création et l'initialisation du projet.
Figure 5.2 Choix de l'emplacement du projet

Figure 5.3 Choix du nom du projet
5.1.3 Console et Chargement de donnees

Dans un projet on commence par charger des données. On peut aussi utiliser la mini console
développée pour faciliter l'utilisation de commandes natives de R
Figure 5.4 Mini console et editeur basique de codes R

En ce qui concerne la lecture des données, il est possible, comme précisé dans la conception
au chapitre 2, d'importer des données existantes, ou de les saisir. Ainsi, après saisie, les données
sont importées dans le projet actif, et feront après vérication, oce d'EDF. Pour le chargement
de données existantes, un boite de dialogue de sélection de chier est achée, et l'utilisateur
sélectionne alors l'emplacement des données.
Pour ce qui est du cas de la saisie de nouvelles données, on ache plutôt une fenêtre de saisie
sous forme de tableau, dans laquelle l'utilisateur pourra saisir les diérentes données.

Figure 5.5 Chargement des données depuis un chier
Figure 5.6 Saisie de données et validation

Les données étant chargées, le processus de simulation des jours peut leur être appliqué. Il
s'agit du processus permettant, à partir d'une EDF d'un nombre de jours donné, d'obtenir, par
une transformation appropriée, une nouvelle EDF, correspondant au nombre de jours souhaité (le
nombre de jours souhaité pouvant être indiéremment supérieur ou inférieur au nombre initial de
jours)
Figure 5.7 Transformation de l'EDF
5.1.4 Simulation et Graphiques

Il est possible d'eectuer une simple simulation 1 , ou une simulation multiple 2 .
Il est même par ailleurs possible de simuler et évaluer au même moment
1. En choisissant un seul algorithme de simulation(Procédure de shrinkage de la méthode de Gibbs, Méthode

Binomiale, Metropolis Indépendant...)
2. C'est à dire avec plusieurs algorithmes de simulation

Figure 5.8 Saisie de paramètres pour une simulation
La barre de progression de l'interface permet de suivre l'évolution de la simulation, surtout

lorsqu'elle est longue (Si, par exemple, l'utilisateur choisit de faire une simulation multiple, donc
sélectionne plusieurs algorithmes de simulation, et même plusieurs nombres de jours et nombres
de cas d'épidémie)
Figure 5.9 Progression de la simulation
A la n de la simulation, les résultats sont achés dans l'onglet approprié de la zone de travail,
et l'utilisateur peut décider de représenter graphiquement les résultats de la simulation. Dans ce
cas, le graphe est tracé par la méthode appropriée, et ce dans la surface destinée au tracé de
graphiques.

Figure 5.10 Résultats de simulation, et graphique associé : Il est possible d'enregistrer le

graphique, ou de l'imprimer
Figure 5.11 Résultats de simulation, dans le cas d'une simulation multiple : Les résultats sont
achés dans une autre fenêtre, pour éviter un encombrement de l'IHM

5.1.5 Diagnostique de convergence et évaluation
Les écrans obtenus lors d'un diagnostique de convergence dans le cas d'algorithmes markoviens
sont présentés ci-après.Suivant le diagnostique eectué, les résultats peuvent être des graphes, des
listes de valeurs sous forme de tableau de données (donc de dataframes 3 ), soit sous forme d'un
ensemble de chires ayant chacun une signication précise. C'est pourquoi la page correspondante
à l'achage des résultats de diagnostique de convergence a été divisée en trois onglets, chacun
étant adapté à un type de résultat précis. Sont également présentés ici les écrans obtenus lors de
l'évaluation d'une ou plusieurs simulations, quelqu'elles soient.
Figure 5.12 Diagnostique de convergence : Statistique de test, heidel

Le diagnostique par la méthode de Heidel donne en résultat un ensemble de valeurs signica-
tives, qui sont ainsi représentées sur l'interface. Dans le cas d'un diagnostique graphique, le résultat
peut être un graphique (comme la méthode de l'histogramme des valeurs générées). Le résultat
peut aussi être un dataframe.
3. Les tableaux de données sous R sont représentés par le type de données "data.frame"

Figure 5.13 Diagnostique de convergence : Diagnostique graphique, histogramme des valeurs

générées
Lors de l'évaluation, Un tableau de donnée (objet de type data.frame) est créé, renseignant sur
les diérentes valeurs de chaque métrique d'évaluation calculée, pour chaque n-uplet de paramètres
de simulation. Le dataframe en question est aché dans un objet de type RGtkDataFrame 4
Figure 5.14 Evaluation
4. Il s'agit d'un objet particulier relatif au package RGtk2, faisant le lien entre la représentation structurelle des
data.frame de R, et la representation par widget des TreeModel de la bibliothèque Gtk+

Figure 5.15 Wireframe
5.2 Performance, faisabilité économique et productivité
Nous avons présenté les diérents composants de notre logiciel en attente aux objectifs précisés
en début du document. Celà nous permet nettement de ressortir les améliorations par rapport aux
algortihmes de simulation-évaluation en ligne de commande.
• Ainsi, l'utilisateur n'aura plus à taper des commandes, (donc de se rassurer de la syntaxe
de celles-ci) pour faire ses simulations et diagnostiques. Il lui sura à chaque fois de faire
de simples clics et de saisir juste les paramètres nécessaires à une simulation dans une boite
de dialogue assez conviviale, puis attendre que tout se passe. La mise en place d'une telle
fonctionnalité est d'autant plus importante si l'on tient compte du fait que lorque l'on tra-
vaille sur des simulations, on se repète très souvent. Car un résultat pourrait ne pas nous
convaincre, et on pourrait vouloir réessayer avec les mêmes paramètres (la simulation se base
sur des distributions empiriques, donc les résultats d'une simulation ne sont pas des fonctions
déterministes 5 ). Surtout qu'à chaque fois que l'on fait une simulation, on peut l'évaluer, la
grapher.
• Les diérentes données, les résultats de simulations, les graphiques sont désormais dans une
même fenêtre (la fenêtre du logiciel), l'utilisateur ayant juste à cliquer sur l'onglet correspon-
dant pour visualiser ce qui l'intéresse. Contrairement à l'ancienne méthode où les résultats
s'achaient dans une console 6 , et ce quelque soit la nature des données (hormis les graphes),
5. Une fonction déterministe est une fonction qui, pour des paramètres donnés, donnera toujours le même résultat,
contrairement à une fonction probabiliste, dont le résultat dépend, en plus des données, d'un phénomène aléatoire
6. les consoles en informatiques sont réputées pour ne pas être conseillées comme IHM

ce qui ne permettait pas d'avoir une vue plus claire des résultats, et plus descriptive.
• Le système de gestion de données mis en place permet une manipulation de données et des
rendus beaucoup plus ecaces. En eet, étant donné que le logiciel sera destiné à de nom-
breuses simulations (par exemple, chaque fois qu'il faudra tester un algorithme de détection
épidémique), il y a beacoup de données à manipuler. Les codes écrits en console se con-
tentaient non seuleument d'enregistrer automatiquement tous les résultats dans un même
dossier mais le faisaient aussi avec des noms de chiers pratiquement statiques (le seul dy-
namisme ici était lié aux paramètres de simulation). Ainsi, non seuleument on peut arriver
facilement après 30 simulations, à un dossier comportant des centaines de chiers de types
divers (des graphiques, des chiers de données, des résultats de simulation, d'évaluation...)
mais il se trouve aussi qu'à chaque fois que l'on faisait une autre simulation avec les mêmes
paramètres, les anciennes données étaient écrasées, donc on perdait toutes les autres simu-
lations. Le module de gestion mis en place notamment avec le système de projets, permet
de résoudre ces problèmes. Ainsi, quand on travaille sur un projet, les données sont organ-
isées selon un système hiérarchique bien déni, et sont enregistrées en fonction du nom du
projet choisi au préalable par l'utilisateur. De plus, des boutons et menus présents sur le
logiciel permettent à l'utilisateur de faire manuellement des enregistrements, et même des
impressions, s'il le souhaite.
Sur un plan économique, on peut dire que notre solution est vraiment très optimale. En eet, La
seule nécessité, sur le plan matériel, pour le fonctionnement du logiciel, c'est un ordinateur moderne
(donc ayant une capacité mémoire et un micropresseur acceptables). Sur le plan du logiciel, tous
les outils utilisés pour la conception et le développement du package sont open source. En ce qui
concerne l'aspect compétences, le développement aura nécessité un informaticien pré-ingénieur
pendant un durée de stage de 6 mois, soit une compétence équivalente à une équipe d'un ingénieur
pour une durée déterminée de 6 mois en développement backend et frontend.
5.3 Bilan
L'objectif de ce travail était de proposer un logiciel permettant une interaction plus aisée avec
un utilisateur lors de la simulation des épidémies en se basant sur les algorithmes en ligne de
commande développés au CPC, et ce de façon transparente 7 et conviviale pour l'utilisateur, sans
qu'il ne doive travailler avec une console. Nous avons ainsi démontré que notre solution est plus
interactive et plus bénéque : gain en temps, gain dans la gestion, etc. Nous avons en eet fournis
des modules fonctionnels (interface d'import-export de données, de graphiques, de simulations, de
gestion de projet...). Sous forme de package R, le logiciel pourra être installé depuis le site ociel
des packages de R, par tout utilisateur du logiciel R. Ainsi, il sera faire des simulations d'épidémies
7. de façon à ce que l'utilisateur puisse utiliser le logiciel sans avoir besoin de connaître le mécanisme mis en
place pour son fonctionnement, et ne soit pas obligé de retenir un ensemble de commandes

en fonction de des objectifs de l'utilisateur.(l'objectif du CPC était au départ de pouvoir simuler
des épidémies pour tester les algorithmes de détection épidémiques) : Le logiciel pourra par exemple
servir à la mise sur pied d'un simulateur complet.

Conclusion
Il était question pour nous de proposer un package permettant d'eectuer plus aisément les
simulations d'épidémies. Pour y parvenir, nous avons fait un état des lieux, et un état de l'art des
possibilités de développement d'interfaces graphiques pour R. Ainsi, notre solution est basée sur le
logiciel de statistiques R (puisque les codes qui devaient être utilisés ont été developpés sous ce le
logiciel). Notre choix après établissement d'un comparatif s'est basé sur la bibliothèque Gtk+ et le
package RGtk2 assurant le lien entre le logiciel R et cette bibliothèque. Actuellement le projet est
à 80% de son avancement, et sera achevé à la n du stage, qui est prévue pour le 27 juillet 2014.
L'une des principales limites de la solution, est que le client informatique utilisé est lourd. En
eet, si l'on tient compte du fait que faire des simulations complexes et repetées demande en général
beaucoup de ressources, une simple machine de bureau pourrait ne pas être ecace. Ainsi, comme
perspective, on pourrait penser à un serveur de simulation qui eectue tous les calculs nécessaires,
et envoie les résultats par réseau à un client qui est en fait l'ensemble des interfaces. Une telle
architecture pourrait aussi prévoir un serveur de Base de données dédié. Une autre perspective
du projet est que le package puisse être publié et laissé libre sur le site ociel du logiciel R. Une
perspective serait aussi de pouvoir améliorer le nombre d'algorithmes de simulation possible pour
le logiciel, et de donner la possibilité à un utilisateur d'intégrer au logiciel son propre algorithme
de simulation écrit dans la syntaxe de R.
53
Annexe A
Chaînes de Markov et Algorithmes

markoviens
Ce chapitre ne se prétend pas un cours complet sur les Chaînes de Markov ; il se contente
de résumer un certain nombre de dénitions, élémentaires ou non, de la théorie des Chaînes de
Markov.
A.1 Propriété de Markov
A.1.1 Dénition
Noyau de transition
Soit S un ensemble ni ou dénombrable. On appelle noyau de transition sur S, toute application
p : S × S → R+ telle que, pour tout x ∈ S, p(x, ·) est une loi de probabilité sur S. On note de
façon commode p(·, ·) pour matérialiser le fait que l'application est à 2 variables.
De façon pratique, étant donné un système (physique par exemple) capable d'occuper des états
d'un ensemble d'états donné S, p(x, y) pourx, y ∈ S peut être interprété comme la probabilité de
se retrouver à l'état y sachant qu'on vient de l'état x.
Dans la suite, nous noterons xm:n pour désigner la suite (xm , xm+1 , ...xn ), et xm:∞ pour désigner la
suite (xm , xm+1 , ...).
Chaîne de Markov
Etant donné un ensemble ni ou dénombrable S, une suite de variables aléatoires (Xn )(n≥0) dénie
sur un espace probabilisé (Ω, F, P ) et à valeurs dans S est appelée chaîne de Markov d'es-
pace d'états S lorsqu'il existe une famille de noyaux de transitions (pn (·, ·))(n≥0) et une loi de
54
probabilité ν sur S tels que : pour tout n ≥ 0, et toute suitex0:n d'éléments de S ,
n−1
(A.1)
Y
P (X0:n = x0:n ) = ν(x0 ) pi (xi , xi+1 )
i=0
On dit alors que (Xn )(n≥0) est une chaîne de Markov de loi initiale ν et de famille de
noyaux de transitions (pn (·, ·))(n≥0) .
Propriété On montre que si la propriété (A.1) est vériée pour un entier donné n ≥ 1, alors
elle est automatiquement vériée pour tout entier m ≤ n.
Ceci nous permet de déduire une propriété fondamentale, appelée propriété de Markov.
Proposition 1 : Propriété de Markov

Etant donné une chaîne de Markov (Xn )(n≥0) sur un ensemble ni ou dénombrable S , dénie sur
un espace probabilisé (Ω, F, P ), pour tous m ≥ 0 et n ≥ m + 1, et toute suite x0:n d'éléments de
S telle que P (X0:m = x0:m ) > 0,
P (Xm+1:n = xm+1:n |X0:m = x0:m ) = P (Xm+1:n = xm+1:n |Xm = xm )
On énonce souvent cette propriété de manière informelle en disant que, pour une chaîne de
Markov(où l'indice m est interprété comme un temps), les états futurs de la chaîne ne dépendent
de ses états passés que par l'intermédiaire de l'état présent. On parle aussi souvent d' abscence
de mémoire La preuve résulte de (A.1) par un calcul immédiat conduisant à l'identité suivante :
n−1
(A.2)
Y
P (Xm+1:n = xm+1:n |X0:m = x0:m ) = pi (xi , xi+1 )
i=m
On note que l'expression ci-dessus n'est autre que la probabilité pour que les n−m premiers pas
d'une chaîne de Markov de loi initiale δxm et de famille de noyaux de transitions (pm+K )k≥0 soient
donnés par xm+1 , ...xn . Dit de manière informelle : Sachant toutes les valeurs passées jusqu'au
temps n (y compris la valeur de Xn ),la chaîne se comporte à partir du temps n comme une nouvelle
chaîne de Markov, issue de Xn .
On déduit de ce qui précède le lien suivant entre la loi ν et les noyaux de transition pi (·, ·) inter-
venant dans la défnition (A.1) :
ν = loi de X0 (A.3)
et, pour tout n ≥ 0, tout x ∈ S tel que P (Xn = x) > 0, et tout y ∈ S ,
pn (x, y) = P (Xn+1 = y|Xn = x) (A.4)

Observons que la donnée de (Xn )n≥0 n'impose aucune contrainte sur la valeur de pn (x, ·) lorsque
P (Xn = x) = 0. Il est cependant plus commode de supposer a priori dans la dénition d'une chaîne
de Markov que l'on a aaire à un noyau de transition.
Inversement, si une suite de variables aléatoires (Xn )n≥0 vérie la propriété de Markov, on
montre que, en dénissant ν et pn (·, ·) par les identités A.3 et A.4 précédentes, et en dénissant
arbitrairement pn (·, ·) lorsque P (Xn = x) = 0 (étant donné que, bien entendu, aucune contrainte
n'est imposée sur la valeur de pn (x, ·) dans ce cas), la dénition d'une chaîne de Markov est satis-
faite. Autrement dit :
La propriété de Markov caractérise les chaînes de Markov.
Une manière plus sophistiquée, mais aussi équivalente, d'énoncer la propriété de Markov, con-
siste à faire appel à la notion de tribu et de probabilité conditionnelle à une tribu. Etant donnée
une variable aléatoire Z dénie sur (Ω, F), on notera σ(Z) la sous-σ−algèbre de F engendrée par Z .
Plus particulièrement, pour tout n ≥ 0, nous utiliserons la notation Fn := σ(X0:n ) = σ(X0 , ..., Xn ).
On peut alors reformuler la propriété de Markov de la manière suivante :
Proposition 2 : Etant donné une chaîne de Markov (Xn )n≥0 sur un ensemble ni ou dénom-
brable S, dénie sur un espace probabilisé (Ω, F, P ), pour tous m ≥ 0 et n ≥ m + 1, et toute suite
xm+1 , ...xn d'éléments de S , l'égalité suivante a lieu P − presquesurement
P (Xm+1:n = xm+1:n |Fm ) = P (Xm+1:n = xm+1:n |σ(Xm ))
Dans certains exemples, on peut être amené à étudier la validité de la propriété énoncée dans la
proposition précédente en remplaçant la ltration 1 (Fn ))n≥0 par une plus grosse. Plus précisément,
supposons donnée une famille de sous-σ−algèbres (Gm ))m≥0 telle que, pour tous n ≥ m, Gm ⊂ Gn
et vériant Fm ⊂ Gm pour tout m ≥ 0. On dit que (Xn )n≥0 vérie la propriété de Markov par
rapport à (Gm ))m≥0 si la propriété énoncée dans la proposition précédente est valable lorsque l'on
remplace Fn par Gn .
Lorsque les noyaux de transition associés aux diérents pas de la chaîne sont identiques, c'est-
à-dire qu'il existe un noyau p tel que pn = p pour tout n, on dit que l'on a aaire à une chaîne
de Markov homogène (ou parfois, mais cette terminologie n'est pas très heureuse, de chaîne de
Markov à probabilités de transition stationnaires). Dans le cas contraire, on parle de chaîne de
Markov inhomogène. Ici, nous considérerons principalement des chaînes de Markov homogènes,
et cette propriété d'homogénéité sera sous-entendue la plupart du temps.
1. Famille croissante au sens de l'inclusion de σ−algèbres

A.1.2 Exemples
Ex.1 : Marche aléatoire dans Z

Soient une famille dénombrable {Zi }i≥1 de variables aléatoires indépendantes de Rademacher
(vériantP (Zi = −1) = P (Zi = +1) = 21 ∀i ≥ 1).
On pose X0 = 0, et pour tout n ≥ 1,
n
X
Xn = Zi
i=1
X est appelée marche aléatoire sur Z.

X est une chaîne de markov homogène de loi initiale ν dénie par ν = δ0 , et de noyau de transition
p tel que : p(x, ·) = 12 .δx+1 + 12 .δx−1 ∀x ∈ Z
Ex.2 : Diusion d'un gaz et urne

Les chaînes de Markov avaient été introduites avant les travaux de Markov :
• En 1889, Galton a introduit des chaînes de Markov pour étudier le problème de la disparition
de noms de famille.
• En 1907, Ehrenfest a introduit des chaînes de Markov pour étudier la diusion d'un gaz.
Ex.3 : Chaînes de Markov et ADN
L'ADN est une succession de nucléotique, l'adémine, la cytosine, la guanine et la thymine.

Par exemple "gactgaactctgag..." Rappelons qu'il y a en réalité deux brins complémentaires, le "a"
s'associant toujours au "t", et le "c" avec le "g". On note cg le dinucléotide c suivi de g. Ces
dinucléotides ont naturellement tendance à disparaître (par méthylation "c" mute facitement en
"t"). La séquence "cg" est alors plus rare que ce que l'on pourrait espérer. Dans certaines régions
toutefois, appelée ilôts, on trouve beaucoup de "cg". Soit X0 le premier nucléotide d'une séquence
d'ADN. Il suit la loi intiale ν = (νa , νc , νg , νt ). Il est légitime
  de penser que la suite des nucléotides
a
 
c
(Xn )n∈N n'est pas indépendante. Pour le vecteur X = 
g , un modèle markovien est adapté

 
t
• Dans la région d'ilôts "cg", la matrice de transition (observée empiriquement) est
 
18, 0% 27, 4% 42, 6% 12, 0%
 
17, 1% 36, 8% 27, 3% 18, 8%
p=
16, 1%

 33, 9% 37, 5% 12, 5%

7, 8% 35, 4% 38, 3% 18, 5%

• Et dans la région où on est pas en présence d'ilôts "cg",
 
30, 0% 20, 5% 28, 5% 21, 0%
 
32, 2% 29, 8% 7, 8% 30, 2%
p=
24, 8%

 24, 6% 29, 8% 20, 8%

17, 7% 23, 9% 29, 2% 29, 2%
Ex.4 : Processus de Galton-Watson

On considère le processus généalogique suivant : la première génération (numérotée 0) est constituée
d'un nombre donné p ≥ 1 d' individus. A chaque génération, chaque individu appartenant à cette
génération donne lieu à un nombre aléatoire d'enfants, qui appartiennent à la génération suivante,
la règle étant que les nombres d'enfants obtenus par les diérents individus aux cours des diérentes
générations sont des variables aléatoires i.i.d. On montre que la suite de variables aléatoires (Xn )n≥0
dénie par Xn := nombred0 individusprsents dans la génération numéro n, constitue une chaîne
de Markov.
A.2 Propriété de Markov forte
Les dénitions et propriétés du paragraphe précédent ne faisaient intervenir que des tronçons
de longueur nie de la trajectoire innie formée par la suite (Xn )n≥0 . Il est intéressant de pouvoir
étudier en tant que telle cette trajectoire aléatoire.
A.2.1 Mesure sur l'espace des trajectoires

Etant donné un ensemble ni ou dénombrable S , munissons S de la tribu H comprenant toutes
les parties de S , puis munissons S N de la tribu produit H⊕N correspondante. Nous obtenons l'es-
pace d'états dans lequel vivent les trajectoires de la chaîne (Xn )n≥0 . Par un argument d'extension
standard , on obtient la généralisation suivante de la proposition 1 (la proposition 2 se généralise
de manière identique) :
Proposition 3
Etant donné une chaîne de Markov (Xn )(n≥0) sur un ensemble ni ou dénombrable S , dénie sur
un espace probabilisé (Ω, F, P ), pour tout m ≥ 0, et tout x0:m tel que P (X0:m = x0:m ) > 0, et tout
A ∈ H⊕N
P (Xm+1:∞ ∈ A|X0:m = x0:m ) = P (Xm+1:∞ ∈ A|Xm = xm )
Ainsi, par extension de l'équation (A.1) à des trajectoires innies, on peut caractériser la loi d'une
chaîne de Markov en tant que probabilité sur (S N , H⊕N ). On part d'une loi de probabilité ν sur
S , et d'une famille de noyaux de transitions p = (pk (·, ·))k≥0 sur S . En vertu, par exemple, du

théorème d'extension de Kolmogorov, il existe alors une unique mesure de probabilité Pν,p sur
(S N , H⊕N ) vériant pour tout n ≥ 0 l'identité
n−1
Y
{n+1,··· }
Pν,p ({x0 } × · · · × {xn } × S ) = ν(x0 ) pi (xi , xi+1 )
i=0
. Dans ce cadre, la dénition (A.1) se généralise en la proposition suivante :
Proposition 4
Etant donné un ensemble ni ou dénombrable S, une suite de variables aléatoires (Xn )(n≥0) dénie
sur un espace probabilisé (Ω, F, P ), (Xn )(n≥0) est une chaîne de Markov de loi initiale ν et de
famille de noyaux de transitions p = (pn (·, ·))(n≥0) si et seulement si la loi de x0:n vue comme
variable aléatoire dénie sur (Ω, F, P ), (Xn )(n≥0) et à valeurs dans (S N , H⊕N ), est égale à Pν,p . En
d'autres termes, si pour tout A ∈ H⊕N ,
P (X0:∞ ∈ A) = Pν,p (A)
. La proposition ci-dessus illustre le fait que la propriété d'une famille de variables aléatoires
(Xn )(n≥0) d'être une chaîne de Markov (par rapport à sa ltration naturelle) ne dépend que de la
loi de probabilité de cette suite de variables aléatoires. Ex,p désigne l'espérance relative à Pν,p . Dans
le cas homogène, on peut noter plus simplement Pν,p au lieu de Pν,p , et même, encore, simplement
Pν (ceci lorsque, bien entendu, aucune confusion ne peut être faite sur les transitions). Il est parfois
très utile, pour étudier les propriétés de la trajectoire (Xn )(n≥0) , de se ramener à l'espace-image
des trajectoires (S N , H⊕N , Pν,p ) que l'on appelle parfois l'espace canonique associé à la chaîne de
Markov. Dans le cas où ν est la mesure de Dirac ν = δx , la notation Px,p est préférée à Pδx ,p (et
donc Px,p ou Px dans le cas homogène). De même, pour l'espérance, Ex,p (et Ex,p ou Ex dans le cas
homogène). Notons que la probabilité Pν,p peut s'écrire comme un mélange de telles probabilités
associées à des lois initiales concentrées en un point :
X
Pν,p = ν(x)Px,p
x∈S
. Les opérateurs de décalage θn sur S N sont dénis pour tout n ≥ 0 par
θn (x0 , x1 , · · · ) = (xn , xn+1 , · · · )
On vérie que, sur l'espace probabilisé (S N , H⊕N , Pν,p ), la suite de variables aléatoires (Xn )n≥0 , à
valeurs dans S , est bien une chaîne de Markov de loi initiale ν et de famille de noyaux de transitions
p = (pk )k≥0 , ce qui prouve en particulier pour toute loi ν , et toute famille de noyaux de transition
p, il existe une chaîne de Markov qui leur est associée. La propriété de Markov peut se ré-exprimer

dans ce contexte de la manière suivante (en concaténant la proposition 1 et l'équation (A.2)) :
Proposition 5
Pour tout m ≥ 0, et tout A ∈ H⊕N ,
Pν,p (Xm:∞ ∈ A|Fm ) = PXm ,θm (p) (X0:∞ ∈ A), Pν,p − p.s (A.5)
Cette identité peut être réécrite sous la forme
−1
Pν,p (θm (A)|Fm ) = PXm ,θm (p) (A), Pν,p − p.s
A.2.2 Propriété de Markov forte

Une extension très importante de la propriété de Markov discutée précédemment consiste à
considérer un conditionnement par un tronçon de trajectoire dont la longueur n'est pas xée, mais
de longueur aléatoire.
Dénition : Temps d'arrêt

Etant donnée une suite de variables aléatoires (Xn )n≥0 dénies sur un espace probabilisé (Ω, F, P )
et à valeur dans un ensemble ni ou dénombrable S , une variable aléatoire T dénie sur (Ω, F, P ) à
valeurs dans N ∪ {+∞} est appelée un temps d'arrêt de (Xn )n≥0 lorsque, pour tout n ∈ N, l'évène-
ment {T = n} s'exprime en fonction de X0 , · · · , Xn , ou, en termes plus précis, {T = n} ∈ Fn Un
exemple fondamental de temps d'arrêt est fourni par les temps d'atteinte, par exemple dénis par
T := inf {n ≥ 0; Xn ∈ B}, où B ⊂ S
Proposition 6 : Propriété de Markov forte

Etant donné une chaîne de Markov (Xn )n≥0 dénie sur (Ω, F, P ), à valeurs dans un ensemble ni
ou dénombrable S , de loi initiale ν et de famille de noyaux de transition p = (pn )n≥0 , et un temps
d'arrêt T de la suite (Xn )n≥0 , la propriété suivante est vériée : pour tout m ≥ 0, et tout A ∈ H⊕N ,
et toute suite x0 , · · · , xm d'éléments de S tels que P (X0:T = x0:T , T = m) > 0,
P (XT :∞ ∈ A|X0:T = x0:T , T = m) = Pxm ,θm (p) (A) (A.6)
La propriété énoncée dans la proposition est appelée propriété de Markov forte, par opposition
à la propriété discutée jusqu'à présent, que l'on peut rebaptiser propriété de Markov simple.
Sachant toutes les valeurs passées jusqu'au temps T (et en particulier la valeur de XT ), la chaîne
se comporte à partir du temps T comme une nouvelle chaîne de Markov, issue de XT . On voit
bien que, du fait que T est supposé être un temps d'arrêt, l'événement {T = m} s'exprime en
terme de variables X0 , · · · Xm et que (A.6) est donc une conséquence de la propriété de Markov

usuelle. En introduisant la tribu FT sur Ω dénie comme l'ensemble des événements C ∈ F tels
que C ∩ {T = n} ∈ Fn pour tout n ≥ 0, on peut réécrire l'équation A.6 sous la forme suivante :
sur l'événement {T < +∞}, on a, pour tout A ∈ H⊕N , l'identité
P (XT :∞ ∈ A|FT ) = PXT ,θT (p) (A), P − p.s (A.7)
A.3 Action sur les mesures
S désigne un ensemble ni ou dénombrable. Sont présentées diverses opérations associant noy-
aux, fonctions, et mesures sur S . Tout d'abord, étant donnés deux noyaux de transition p et q sur
S , on dénit le produit pq par la formule : pour tout x, y ∈ S
X
(pq)(x, y) := p(x, z)q(z, y),
z∈S
et l'on vérie que l'on a ainsi déni un nouveau noyau de transition sur S .A présent, étant donnée
une mesure positive ν sur S, et un noyau de transition p sur S , le produit νp est déni par la
formule : pour tout x ∈ S
X
(νp)(x) := ν(y)p(y, x),
y∈S
avec la convention 0 × +∞ = 0, et l'on vérie que l'on a ainsi déni une nouvelle mesure positive
sur S , possédant la même masse que ν : (νp)(S) = ν(S). Pour une fonction positive (à valeurs
dans [0; +∞]) f dans S , et un noyau de transition p sur S , on dénit également le produit pf par
la formule
X
(pf )(x) := f (y)p(x, y),
y∈S
avec la convention 0 × +∞ = 0.On vérie que l'on a ainsi déni une nouvelle fonction positive sur
S , et l'on note que supx∈S (pf )(x) ≤ supx∈S f (x). Enn, étant donnée une mesure positive ν sur S
et une fonction positive f , nous noterons
X
νf := f (x)ν(x).
x∈S
Les dénitions ci-dessus s'étendent naturellement au cas d'une mesure signée ν = ν+ − ν− et d'une
fonction à valeurs réelles f = f+ − f−
Proposition 7 :Les produits précédents sont associatifs

Même s'il ne couvre pas la totalité des cas possibles, on peut néanmoins retenir le résultat suivant.
Proposition 8 :L'action d'un noyau de transition à droite (sur les fonctions) dénit un opérateur

linéaire continu de norme 1 de l∞ (S) dans lui-même. L'action d'un noyau de transition à gauche
(sur les mesures) dénit un opérateur linéaire continu de norme 1 de l1 (S) dans lui-même.Les
actions à gauche et à droite sont duales pour la dualité entre mesures signées de masse nie et
fonctions bornées.
Dans le cas où S est un ensemble ni, on peut interpréter matriciellement les opérations précé-
dentes : les noyaux s'identient à des matrices indexées par S × S , les mesures comme des vecteurs-
lignes indexés par S , et les fonctions comme des vecteurs-colonnes indexés par S . Les produits
précédents s'identient alors exactement aux produits usuels entre matrices. Dans la suite, nous
utiliserons la notation pn pour désigner le produit itéré n fois du noyau de transition p avec lui-
même, avec la convention selon laquelle p0 (x, y) = 1 si x = y et p0 (x, y) = 0 sinon.
A.4 Récurrence, transience, périodicité
A.4.1 Points essentiels

Etant donné un noyau markovien p sur un ensemble ni ou dénombrable S , un point x ∈ S est
dit inessentiel (pour p(·, ·)) s'il existe m ≥ 1 et y ∈ S tels que pm (x, y) > 0 et pk (y, x) = pour tout
k . Un point est dit essentiel lorsqu'il n'est pas inessentiel. Autrement dit, un point est inessentiel
lorsqu'il existe une probabilité positive pour que, partant de x, la chaîne atteigne un point d'où
elle ne peut jamais revenir en x. Une première décomposition de l'espace d'états S s'écrit alors
S = Siness. ∪ Sess.
Proposition 9 :Si x est un point essentiel et y un point inessentiel (par rapport à p(·, ·)), alors
pm (x, y) = 0 pour tout m. En d'autres termes, l'ensemble des points essentiels est stable par p(·, ·) :
si x ∈ Sess , p(x, Sess ) = 1
A.4.2 Communication entre points-Irréductibilité

On dit que x et y communiquent (par rapport à p(·, ·)) s'il existe m1 et m2 tels que pm1 (x, y) >
0 et pm2 (y, x) > 0.
Proposition 10 :La relation de communication entre points dénit une relation d'équivalence
sur S .
Proposition 11 :Si C est une classe d'équivalence pour la communication incluse dans Sess , C
est stable par p(·, ·) : si x ∈ C, p(x, C) = 1.

On dit que p(·, ·) est irréductible si x communique avec y pour tous x, y dans S . D'après les
propositions précédentes, la restriction de p(·, ·) à une classe de communication de Sess est irré-
ductible. Quitte à enlever de S les points inessentiels par rapport au noyau de transition considéré
(qui ne sont visités qu'un nombre ni de fois sur toute la durée d'une trajectoire), et à étudier
séparément les chaînes obtenues par restriction sur chaque classe de Sess , (rappelons que celles-ci
sont stables), on peut donc se ramener à étudier des noyaux de transition irréductibles. Ceci ne
signie pas pour autant que le comportement de la chaîne à partir de points inessentiels soit inin-
téressant !
Remarque :On constate que, si une chaîne de Markov possède un noyau de transition irréductible,
tous les points de S ont une probabilité positive d'être visités, quelle que soit la loi initiale, et, par
conséquent, ce noyau est le seul compatible avec cette chaîne. On peut donc parler d'une chaîne
de Markov irréductible sur un ensemble S . Attention cependant, la notion d'irréductibilité dépend
de l'ensemble S dans lequel on considère que la chaîne prend ses valeurs : une chaîne, vue comme
famille de variables aléatoires dans un ensemble S1 pourra se révéler irréductible sur S1 , mais pas
sur un ensemble S2 contenant S1 . Notons aussi que la dénition de l'irréductibilité entraîne le fait
que, pour tout x ∈ S , il existe m ≥ 1 tel que pm (x, x) > 0
A.4.3 Périodicité
On dénit la période (par rapport à p(·, ·)) d'un point x par
d(x) = p.g.c.d.{n ≥ 1; pn (x, x) > 0}
(Avec la convention que p.g.c.d.∅ = +∞).

Pour un noyau irréductible, on constate que la période est nécessairement nie pour tout point.
Par exemple, on voit facilement que, pour (le noyau de transition de) la marche aléatoire simple
sur Z, la période de tout point est égale à 2.
Proposition 12 :Si p(·, ·) est irréductible, d(x) = d(y) pour tous x, y ∈ S .

Ainsi, lorsque p(·, ·) est irréductible, on parle donc de la période d du noyau ou de la chaîne, sans
préciser le point. Lorsque d = 1, on dit que p(·, ·) est apériodique.
Remarque :Une condition susante très simple pour avoir apériodicité dans le cas d'une chaîne
irréductible est qu'il existe au moins un point x tel que p(x, x) > 0
Proposition 13 :Supposons p(·, ·) irréductible, et de période d. Considérons x et y dans S . Si

pour 2 entiers m et n, on a pm (x, y) > 0 et pn (x, y) > 0, alors d divise m − n.
A.4.4 Récurrence et transience
Dénition
On dit que x ∈ S est récurrent (pour p(·, ·)) si Px (T1 (x) < +∞) = 1. Si Px (T1 (x) < +∞) < 1, x
est dit transient.
Proposition 14 :Si x est récurrent, Px (Ti (x) < +∞) = 1 pour tout i, autrement dit, x est
visité une innité de fois, ou encore Px (N (x) = +∞) = 1
Proposition 15 :Si x est transient, Px (N (x) < +∞) = 1 et Ex (N (x)) < +∞. On a même
que la loi de N (x) sous Px est exactement une loi géométrique de paramètre Px (T1 (x) = +∞) > 0
CorollaireLe point x est récurrent si, et seulement si

+∞
X
Px (Xi = x) = +∞
i=1
A.5 Méthodes de Monte Carlo par chaînes de markov (MCMC)
Les notes qui vont suivre sont basées autour de l'idée suivante : Tout algorithme itératif
utilisant le hasard simule une chaîne de Markov . Lorsqu'on décrit un algorithme stochas-
tique basé sur une chaîne de Markov, on parle d'un algorithme markovien. On désigne par le nom
générique de méthodes de Monte-Carlo par chaînes de Markov (ou Markov Chain Monte Carlo,
souvent abrégé en MCMC, en anglais les méthodes consistant à simuler une loi de probabilité ν
à partir d'une chaîne de Markov ergodique de loi invariante ν . Le principe de base de la méthode
est le suivant : en simulant n pas de la chaîne, avec n susamment grand, on s'attend à ce que
Xn fournisse une variable aléatoire approximativement distribuée selon la loi ν . Alternativement,
la loi des grands nombres entraîne que n−1 Sn (f ) fournit une approximation de ν(f )
A.5.1 Intérêt des méthodes MCMC

L'un des intérêts des méthodes MCMC est qu'elles peuvent être mises en oeuvre dans des situ-
ations où une simulation directe de ν par les méthodes usuelles s'avère impossible ou prohibitive en
temps de calcul. Par exemple lorsque ν n'est connue qu'à une constante multiplicative près, et que
l'espace sur lequel ν est dénie comporte un grand nombre d'éléments. Cette situation n'est pas

rare, et elle est en fait caractéristique des mesures de Gibbs, qui apparaissent en physique statis-
tique, et des probabilités conditionnelles à un événement complexe, qui apparaissent naturellement
en statistique bayésienne. Dans une telle situation, il est en général aisé de construire et de simuler
des chaînes de Markov ergodiques possédant ν pour loi invariante. Deux exemples canoniques (mais
très loin d'être les seuls) sont l'algorithme de Metropolis et l'échantillonneur de Gibbs décrits ci-
après.Notons que la méthode classique de simulation directe par rejet, suppose également que la
loi à simuler n'est connue qu'à une constante multiplicative près.Cependant, les méthodes MCMC
peuvent être mises en oeuvre dans diverses situations où la probabilité de rejet obtenue par cette
méthode directe est prohibitivement petite, permettant en quelque sorte une approche progressive
de la loi à simuler n'entraînant que des probabilités de rejet raisonnables à chaque pas.
A.5.2 Qualité de l'approximation
Une question qui se pose dans le contexte des méthodes MCMC est celle de la précision de
l'approximation de ν . Pour un n donné, quelle est la qualité des approximations obtenues ? Pour
une précision donnée, comment doit-on choisir n ? Divers types d'approches peuvent être envisagés :
• une approche théorique, consistant à établir mathématiquement des bornes sur la qualité
de l'approximation obtenue, c'est-à-dire sur la rapidité de la convergence de la chaîne vers
l'équilibre. Cette approche peut être menée à bien dans plusieurs situations intéressantes, et
nous en verrons quelques exemples dans la partie Analyse quantitative de la convergence .
Il faut cependant mentionner que, dans de nombreux exemples intéressants, il est très dicile,
voire impossible, d'obtenir des bornes exploitables en pratique. Les problèmes mathématiques
correspondants se révèlent trop diciles !
• une approche exploitant des critères empiriques, testés au fur et à mesure de la simulation,
et censés permettre de diagnostiquer le fait que la chaîne est proche de l'équilibre. Le plus
souvent, ces critères sont basés sur un mélange de résultats mathématiques (par exemple des
résultats asymptotiques) et d'hypothèses plus ou moins bien justiées empiriquement, mais
que l'on ne sait pas prouver dans le contexte envisagé. Les critères de ce type sont en général
condamnés à être mis en défaut dans certaines situations pathologiques pour lesquelles
ces hypothèses ne sont pas vériées, fournissant alors des résultats incorrects.
• l'approche dite de simulation exacte , ou parfaite , dans laquelle on cherche, en ranant
la méthode de simulation employée, à obtenir des variables aléatoires distribuées exactement
selon la loi ν . Ces approches ne sont praticables que lorsque certaines hypothèses supplé-
mentaires (par exemple, mais pas exclusivement, des propriétés de monotonie) sont vériées.
Nous verrons deux exemples de cette approche : la méthode de Propp-Wilson et l'algorithme
de Fill.

A.5.3 Deux exemples
Dans ce qui suit, nous donnons deux exemples classiques de chaînes de Markov se prêtant à une
utilisation dans le contexte des méthodes MCMC. Ces deux méthodes peuvent être mises en oeuvre
sous des hypothèses très générales, ce qui ne signie pas qu'elles soient toujours performantes ou
qu'elles constituent un standard absolu dans le domaine. On notera qu'elles ont pour particularité
de conduire à des chaînes de Markov réversibles.
Algorithme de Métropolis
On suppose donnée une mesure de probabilité ν sur un ensemble S vériant ν(x) > 0 pour tout
x ∈ S , et un noyau de transition q irréductible et apériodique sur S et vériant q(x, y) > 0 si et
seulement si q(y, x) > 0. Les transitions de l'algorithme de Metropolis peuvent être décrites de la
manière suivante : partant de x, on génère Y selon la loi q(x, ·). Si ν(Y )q(Y, x) ≥ ν(x)q(x, Y ), on
va en Y à coup sûr. Sinon, on va en Y avec une probabilité de ν(Y )q(Y,x)
ν(x)q(x,Y )
, et l'on reste en x sinon.
On vérie que le noyau obtenu est irréductible et apériodique(les mouvements possibles sont les
mêmes pour l'algorithme de Metropolis et pour q ), et que ν est réversible pour ledit noyau. Le
choix du noyau q ainsi que de la condition initiale est laissé à l'utilisateur de la méthode ; il peut
s'avérer critique pour l'ecacité de l'algorithme obtenu, et diverses préconisations, plus ou moins
fondées sur des considérations théoriques ou empiriques, existent, quant à la manière d'eectuer
celui-ci en fonction de ce que l'on sait de la loi ν .
Echantilloneur de Gibbs
On suppose ici que S est de la forme S = AV , où A et V sont des ensembles fnis, et que l'ensemble
S0 des x ∈ S vériant ν(x) > 0 est connexe pour la relation de voisinage dénie sur S par les
modications d'une seule coordonnée. On appelle S0 cet ensemble, et l'on construit une chaîne de
Markov sur S0 dont les transitions sont dénies de la manière suivante :
Pour x ∈ S0 , v ∈ V et a ∈ A, on note xv,a l'élément de S0 défni par xv,a (w) = x(w) pour tout
w 6= v , et xv,a (v) = a. Les transitions de l'échantillonneur de Gibbs sont dénies ainsi : partant de
x ∈ S0 , on choisit uniformément au hasard un élément v de V , et l'on dénit y par y(w) = xv,a ,
a étant choisi selon la probabilité ν(xv,a )( b∈A ν(xv,b ))−1 , c'est-à-dire la loi sous ν de la v − ieme
P
coordonnée d'un élément de S conditionné à être égal à x en toutes les coordonnées diérentes de
v. On vérie que ce conditionnement est bien déni pour x ∈ S0 , et qu'un élément y qui ne serait
pas dans S0 a une probabilité nulle d'être sélectionné par ce mécanisme de transition, qui laisse
donc S0 stable. On vérie par ailleurs aisément le caractère irréductible et apériodique du noyau
ainsi obtenu sur S0 , ainsi que la réversibilité de ν par rapport à celui-ci.

Annexe B
Annexe : Quelques codes sources du logiciel
Dans cette annexe sont présentés quelques apperçus des codes sources de notre logiciel. A l'Etat
d'avancement actuel, le logiciel contient plus de 10 000 lignes de codes, hormis les anciens codes
ayant été modiés. Ces codes sources sont repartis en divers chiers, et diverses classes.
B.1 Classe Dynamic et quelques méthodes
B.1.1Méthode d'initialisation, avec utilisation de chier xml glade et de l'objet Gtk-

Builder
Figure B.1 Méthode d'initialisation de la classe Dynamic
67
Figure B.2 Méthode d'initialisation de la classe Dynamic 2
B.1.2 Méthode de simulation permettant l'évaluation simultanée
Figure B.3 apperçu simulation evaluation simultanée

Figure B.4 simulation evaluation 2
B.2 Quelques méthodes de la classe Application
B.2.1 Méthode de connection du signal sur les objets pouvant déclencher la simu-
lation d'épidémies

Figure B.5 connection signal simulation

B.3 Quelques méthodes des classes FileBrowser et Tree
Notons tout d'abord que se sont ces classes qui nous permettent de gérer le navigateur de
chiers. Etant donné que R est faiblement typé, que les structures de données sur les graphes et
arbres sont inexistantes, et qu'il n'y a pas de package permettant l'utilisation propre des arbres
(Par contre, il y a des packages traitant sur les arbres de décisions, qui sont des outils purement
statistiques, et ne répondent pas à nos besoins) ni des graphes, nous avons écrits des codes R pour
l'implémentation la structure d'arbre. La classe Tree (arbre) contient des attributs, parmi lesquels
des attributs de type la classe Node (noeud). La classe FileBrowser hérite de la classe Tree, et est
spécialisée dans l'arbre de chiers. Sont présentées ici quelques méthodes de ces classes.
Méthode permettant le parcours des chier et le remplissage des structures de

données associées
Figure B.6 Apperçu méthode browseAndFill de la classe FileBrowser

Figure B.7 Apperçu méthode setNode de la classe Tree

Bibliographie
1 Leonel SG. Évaluation des méthodes de Monte Carlo pour la simulation des courbes
épidémiques, Mémoire professionnel. Yaoundé : ISSEA ; 2012. 2, 5, 6
2 Jalote P. An Integrated Approach to Software Engineering. 3rd ed. New York : Springer
Science+Business Media ; 2005. 2
3 Valleron AJ. L'Epidémiologie humaine-Conditions de son développement en FRANCE, et
Role des Mathématiques. Avenue du Hoggar, BP 112, Parc d'activités de Courtaboeuf : EDP
Sciences ; 2006. 5
4 B Dufour BT P Hendrikx. Élaboration et mise en place de systèmes de surveillance épidémi-
ologique des maladies à haut risque dans les pays développés. International Oce of Epizootics.
2006 ;25(1) :187198. 5
5 Texier G DXMJ Chaudet H. Surveillance épidémiologique pour l'alerte précoce et systèmes
d'information. Lavoisier ; 2011. 5
6 Jackson ML PIDJ Baer A. A simulation study comparing aberration detection algorithms for
syndromic surveillance. BMC Med Inform Decis Mak ; 2007. 5
7 Everitt BS. An R and S-PLUS Companion to Multivariate Analysis. London : Springer-Verlag ;
2005. 6
8 Chambers JM. Software for Data Analysis :Programming with R. New York : Springer Sci-
ence+Business Media ; 2008. 6
9 Michael F Lawrence JV. Programming Graphical User Interfaces in R. Parkway NW : Taylor
& Francis Group ; 2012. 8
10 Krause A. Foundations of GTK+ Development. Berkeley : Apress ; 2007. 11
11 Jasmin Blanchette MS. C++ GUI Programming with Qt 3. New Jersey : Pearson Education ;
2004. 11
12 Roques P. Les cahiers du programmeur UML2 : Modéliser une application web. 4th ed. Paris :
Éditions Eyrolles ; 2008. 14, 16
13 Bersini H. L'orienté objet : Cours et exercices en UML 2 avec Java 5, C# 2, C++, Python et
PHP 5. 3rd ed. Paris : Éditions Eyrolles ; 2011. 14
73
14 Giroux M. Développer Très Rapidement des Applications. Rennes : Liberlog ;. 36
15 Williams G. Data Mining With Rattle and R :The Art of Excavating Data for Knowledge
Discovery. New York : Springer Science+Business Media ; 2011.
16 Pennington H. GTK+ / Gnome Application Development. 1st ed. Red Hat Advanced Devel-
opment Labs : New Riders Publishing ; 1999.
17 Duncan Temple Lang ML. RGtk2 : A Graphical User Interface Toolkit for R. Journal of
Statistical Software. 2010 ;37(8) :152.
18 Pierre Lafaye de Micheaux BL Rémy Drouilhet. Le logiciel R :Maîtriser le langage,Eectuer
des analyses statistiques. New York : Springer ; 2011.
19 Brémaud P. Initiation aux probabilités et aux chaînes de Markov. 2nd ed. New York : Springer ;.
6
.

Packagesous R Simulationsepidemies Yvan TCHOUDIE Memoire Ingenieur 2014

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Packagesous R Simulationsepidemies Yvan TCHOUDIE Memoire Ingenieur 2014

Hochgeladen von

Copyright:

Verfügbare Formate

Université de Yaoundé I University of Yaounde I

Ecole Nationale Supérieure National Advanced School of

Conception et réalisation d’un package sous le

Mémoire de fin d’études/Master of Engineering

Présenté et soutenu par

Devant le jury composé de :

Année académique 2013 - 2014

A toute ma famille, et à tous mes amis,

A tous ceux qui oeuvrent pour le bien être de l'Humanité,

Nos remerciements s'adressent aux personnes suivantes :

• Le Pr Thomas TAMO TATIETSE - pour l'honneur qu'il nous accorde en acceptant de

• Le Pr Thomas BOUETOU BOUETOU, chef du département du Génie Informatique,

• Le Dr Guy VERNET - Directeur général du CENTRE PASTEUR DU CAMEROUN

• Le Dr Gaëtan TEXIER - Chef du Service d'épidémiologie et de santé publique (ESP)

• Le Dr Georges-Edouard KOUAMOU - Enseignant à l'ENSP, qui a été pour nous durant

• Le Dr Eugène-Patrice NDONG NGUÉMA - Enseignant à l'ENSP, pour la méthodolo-

• Le corps enseignant et administratif de l'Ecole Nationale Supérieure Polytechnique de Yaoundé.

Ing. Segolene Vanessa NZEGA KOUAYEP et

• La famille KAMENI, en particulier Raoul et Gaëlle KAMENI.

Le processus de détection d'épidémies est indispensable en épidémiologie. Celà entraîne la mise

Mots clés : R, Gtk+, épidémie, simulation.

Key words : R, Gtk+, epidemic, simulation.

1 Concepts théoriques, état des lieux et état de l'art 4

3 Réalisation d'un prototype 34

4 Etude de cas : Cas du CPC 39

5 Analyse des résultats et faisabilité économique 41

B Annexe : Quelques codes sources du logiciel 67

1.1 Console d'exécution du logiciel R (sous Linux) . . . . . . . . . . . . . . . . . . . . . 7

4.1 Tableau de l'Etat d'éxecution des diérentes taches relatives au logiciel. . . . . . . . 40

Le Centre Pasteur du Cameroun travaille à la simulation des phénomènes épidémiques,ce qui

• La structuration des programmes ainsi écrits et la création de chiers et programmes sup-

Mémoire d'ingénieur en Informatique 3 TCHOUDIE DJOMESSI Yvan

1.1.2 Surveillance épidémiologique et alerte précoce

1.1.3 La simulation des épidémies

Mémoire d'ingénieur en Informatique 5 TCHOUDIE DJOMESSI Yvan

1.2.1 Présentation du logiciel

Mémoire d'ingénieur en Informatique 6 TCHOUDIE DJOMESSI Yvan

Figure 1.1  Console d'exécution du logiciel R (sous Linux)

Mémoire d'ingénieur en Informatique 7 TCHOUDIE DJOMESSI Yvan

Figure 1.2  Apperçu du logiciel R-Studio

Mémoire d'ingénieur en Informatique 8 TCHOUDIE DJOMESSI Yvan

1.3 Les codes de simulation présents au CPC

1.3.1 Présentation des codes

Mémoire d'ingénieur en Informatique 9 TCHOUDIE DJOMESSI Yvan

Figure 1.3  Apperçu des codes développés par le CPC

1.3.2 Fonctionnalités des codes

Mémoire d'ingénieur en Informatique 10 TCHOUDIE DJOMESSI Yvan

1.4.1 La bibliothèque Gtk+

Mémoire d'ingénieur en Informatique 11 TCHOUDIE DJOMESSI Yvan

1.4.3 La bibliothèque Tcl/Tk

Mémoire d'ingénieur en Informatique 12 TCHOUDIE DJOMESSI Yvan

Mémoire d'ingénieur en Informatique 13 TCHOUDIE DJOMESSI Yvan

2.1 Processus et élaboration du logiciel

2.2 Analyse du problème

2.2.1 Spécicités fonctionnelles

2.2.2 Spécicités non fonctionnelles

Mémoire d'ingénieur en Informatique 15 TCHOUDIE DJOMESSI Yvan

2.2.3 Contraintes techniques

2.2.4 Diagramme des cas d'utilisation

Mémoire d'ingénieur en Informatique 16 TCHOUDIE DJOMESSI Yvan

Figure 2.1  Diagramme des cas d'utilisation

2.3.1 Diagrammes de séquences système

Mémoire d'ingénieur en Informatique 17 TCHOUDIE DJOMESSI Yvan

4.1 Tableau de l'Etat d'éxecution des diérentes taches relatives au logiciel. . . . . . . . 40

• La structuration des programmes ainsi écrits et la création de chiers et programmes sup-

Figure 1.1 Console d'exécution du logiciel R (sous Linux)

Figure 1.2 Apperçu du logiciel R-Studio

Figure 1.3 Apperçu des codes développés par le CPC

2.2.1 Spécicités fonctionnelles

2.2.2 Spécicités non fonctionnelles

Figure 2.1 Diagramme des cas d'utilisation

Figure 2.2 Cas d'utilisation Importer les données

Figure 2.3 Cas d'utilisation Transformer l'EDF

Figure 2.4 Cas d'utilisation Grapher les données

Figure 2.5 Cas d'utilisation Diagnostique de convergence

Figure 2.6 Cas d'utilisation Simuler une épidémie

Figure 2.7 Cas d'utilisation Grapher la simulation

Figure 2.8 Cas d'utilisation Evaluer la simulation

Figure 2.9 Cas d'utilisation Grapher l'évaluation

Figure 2.10 Cas d'utilisation Console R

Figure 2.11 Cas d'utilisation Imprimer

Figure 2.12 Cas d'utilisation Aide

Figure 2.13 Cas d'utilisation Sauvegarder

Figure 2.14 Cas d'utilisation Edition

Figure 2.15 Cas d'utilisation Nouveau

Figure 2.16 Menu tree glogal du logiciel

Figure 2.17 Menu tree du branches "Fichier" et "Edition"

Figure 2.18 Menu tree branche "Données"

Figure 2.19 Menu tree branche "Simulation"

Figure 2.20 Menu tree des branches "Diagnostique de Convergence" et "Evaluation"

Figure 2.21 Menu tree des branches "Graphiques" et "Aide"

Figure 2.22 Architecture de l'application

Figure 3.1 Diagramme de packages

Figure 3.2 Diagramme de classes du package Classes

Figure 5.1 Interface principale

Figure 5.2 Choix de l'emplacement du projet

Figure 5.3 Choix du nom du projet