Memoire Français

Approche Distribuée Pour le Déploiement des Workflow
Bioinformatique
MESBAH Ayoub Rayane
28-MAIS-2024
Remerciement
Tout d’abord, nous tenons à exprimer notre profonde gratitude à ALLAH, le Tout-Puissant, de nous avoir
illuminé et ouvert les portes du savoir, ainsi que de nous avoir donné la force, le courage et la patience
nécessaires à la réalisation de ce mémoire.
Ce travail a été réalisé au sein de la plateforme Génomique-Bioinformatique de l’Institut Pasteur
d’Algérie. Nous tenons à remercier tout le personnel qui nous a aidés à mener à bien ce projet.
Un grand merci à nos encadreurs :
Monsieur HEBBACHI Khalil, ingénieur d’état au sein de l’Institut Pasteur d’Algérie, pour ses nombreux
conseils, sa patience et sa gentillesse.
Madame MEHDI Malika, maître de conférences à l’USTHB, pour nous avoir dirigés et guidés afin de
finaliser ce travail.
Nous souhaitons exprimer toute notre gratitude aux membres du jury qui ont bien voulu consacrer une
partie de leur temps pour évaluer notre travail.

Enfin, merci à toutes les personnes qui ont contribué, de près ou de loin, à la réalisation de ce travail.
2
Table des matières
Introduction Générale 10
1 Présentation de Contexte 12
1.1 Présentation de l’Institut Pasteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 État actuel de la Plateforme Génomique-Bioinformatique . . . . . . . . . . . . . . . . . . 13
1.3 Les Besoins Fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 Le Périmètre de Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 État de L’art des Workflows Scientifiques 15

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Contexte Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Le Workflow Scientifique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.2 Les Structures De Conception De Workflow (Workflow Building-blocks) . . . . . 17
2.4 Système de Gestion des Workflows Scientifiques . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1 Les Fonctions d’un SGWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.2 Caractéristiques des Système de Gestion des Workflows Scientifiques (SGWS) . . 18
2.5 Virtualisation : solution pour la reproductibilité . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.1 Virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2 Virtualisation de type 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.3 Virtualisation de type 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.4 Conteneurisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6 Scalabilité des WSs à l’Aide du Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6.1 Définition de Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6.2 Caractéristiques du cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6.3 Architecture Maître-Esclave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.4 Les éléments de cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7 Vue sur des solution concrète . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7.1 Nextflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7.2 Snakemake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3
TABLE DES MATIÈRES
2.7.3 Cromwell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3 Conception de la plateforme 28
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Architecture Globale du Système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Couche d’exécution (Execution Layer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Exécuteur local (Local Executor) . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2 Exécuteur de Cluster (Cluster Executor) . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.3 Défis de Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Couche Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.2 Description des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4.3 Conception Structurelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.4 Exploration des fonctionnalités du Middleware . . . . . . . . . . . . . . . . . . . 43
3.5 User Layer (Couche Utilisateur) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.5.1 Architecture du site Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.5.2 Conception de l’interface utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4 Implémentation de plateforme 52
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.1 Système D’Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.2 Éditeurs et Outils de Modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3 Les Technologies Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.1 HTML/ CSS / JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.2 Bootstrap 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4 Les Technologies de Back-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.1 Technologies de Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.2 Technologies de virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.3 Authentification et Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4.4 Stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.5 Configuration du Cluster Virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5.1 Configuration du Réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.5.2 Configuration de l’authentification et de la Synchronisation temporelle . . . . . . . 60
TABLE DES MATIÈRES
4.5.3 Configuration du Slurm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.5.4 Configuration du Stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.6 Présentation de la Plateforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5 Évaluation & Discussion 65

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2 Construction de l’Arbre Phylogénétique . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3 Conception du workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4 Protocole de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.4.1 Données de Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.4.2 Matérielle Du Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.4.3 Les Objectives de Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5 Évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5.1 Métrique d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5.2 Estimation de la partie purement séquentielle et la partie parallélisable du workflow 69
5.5.3 Estimation de l’accélération théorique . . . . . . . . . . . . . . . . . . . . . . . . 71
5.6 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.6.1 Speed-up (Accélération) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.6.2 Efficacité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.7 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6 Conclusion Générale 78
Bibliographie 79
Annexes 85
A 86
Table des figures
2.1 La Modélisation Mathématique d’un Workflow . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Structures de Workflow [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Les Types de virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Architecture Globale du Platforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 L’Organisation de l’Exécuteur Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 L’Organisation de l’Exécuteur de Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4 Diagramme de Cas d’utilisation Simplifier . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5 Diagramme de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6 Organigramme "Exécuter/Arrêter un Job" . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.7 Organigramme "Charger un conteneur local/public" . . . . . . . . . . . . . . . . . . . . . 45
3.8 Organigramme "Suppression des conteneurs" . . . . . . . . . . . . . . . . . . . . . . . . 47
3.9 Architecture MVC [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.10 Digramme de navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1 La Pile Logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2 Configuration du Réseau Virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3 Diagramme de Navigation Concret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1 Exemple d’arbre phylogénétique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2 Le workflow "Création d’Arbre Phylogénétique" . . . . . . . . . . . . . . . . . . . . . . . 67
5.3 la surestimation de la loi d’amdal pour les algorithmes hautements parallèles . . . . . . . . 72
5.4 Un graphe illustrant le temps d’exécution sur les différentes configurations . . . . . . . . . 73
5.5 Le Speed-up réal vs Speed-up théorique . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.6 L’efficacité des différentes configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
A.1 Diagramme de Cas d’Utilisation Détaillé . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6
Liste des tableaux
3.1 Types de classes et leurs Responsabilités . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1 Ports autorisés par le pare-feu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1 Matérielle de Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.2 Les Temps D’Exécutions Séquentielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3 Temps d’exécution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.4 Le Speed-up des différentes configurations . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.1 Description des étapes du workflow de l’Arbre Phylogénétique . . . . . . . . . . . . . . . 88
7
Liste Des Abréviations
WS Workflow Scientifique
SGWS Système de Gestion des Workflows Scientifiques
PGB Plateforme Génomique-Bioinformatique
IPA Institut Pasteur d’Algérie
DSL Domain Specific Language
HDD Hard-Disk Drive
SSD Solid-State drive
RAID Redundant Array of Independent Disks
LVM Logical Volume Manager
GNU GPL GNU General Public License
SGFD Système de Gestion de Fichier Distant
SGBDR Systém de Gestion de Base de données Relationelle
WMC Workflow Management Coalition
CDD Community-driven development
WDL Workflow Description Language
ISA Instruction Set Architecture
TDP Thermal design power
MAC Media Access Control
NIC Network Interface Controller
UML Unified Modeling Language
NAT Network Address Translation
RPC Remote Procedure Call
KVM Kernel-based Virtual Machine
MVC Model–view–controller
UUID Universally Unique Identifier
RAD Rapid application development
8
LISTE DES TABLEAUX
ORM Object Relational Mapper
UFW Uncomplicated Firewall
HOKEGA HouseKeeping Genes Analysis tool
DAG Directed Acyclic Graph

Introduction Générale
Le domaine scientifique, dans ses différentes branches (biologie, physique, chimie, etc.), connaît un dé-
veloppement rapide avec des réalisations incommensurables, grâce à l’intégration d’outils d’automatisation
et de technologies informatiques dans le processus scientifique. Les scientifiques veulent des outils adéquats
pour simplifier et automatiser la création, le déploiement et la gestion des workflows scientifiques, tout en
garantissant des performances optimales.
L’Institut Pasteur d’Algérie (IPA), et plus particulièrement la Plateforme Génomique-Bioinformatique
(PGB), est confronté à plusieurs défis liés aux workflows bioinformatiques. La conception de ces workflows
est complexe en raison de leur grande taille et du nombre important d’outils bioinformatiques utilisés. De
plus, la complexité temporelle est un enjeu majeur, car ces workflows nécessitent souvent beaucoup de temps
et de ressources.
La problématique principale réside donc dans la complexité des workflows bioinformatiques en termes
de conception et de temps d’exécution. Pour répondre à cette problématique, on propose l’utilisation de
SGWS (Système de Gestion des Workflows Scientifiques) comme plateforme de conception et de gestion des
WSs, ainsi que l’utilisation d’un cluster pour réduire la complexité temporelle. Cependant, le déploiement
des WSs sur les clusters soulève plusieurs défis supplémentaires, tels que la reproductibilité, la scalabilité,
la fiabilité et la gestion de ces workflows dans un environnement distribué.
L’objectif de ce projet est de proposer une approche distribuée pour le déploiement et la gestion
des workflows bioinformatiques, tout en garantissant à la fois la scalabilité et la reproductibilité.
Pour évaluer la solution, on utilisera le workflow de construction d’arbre phylogénétique comme cas de
test. On le soumettra à différents paramétrages en mesurant le speed-up expérimental et en le comparant
avec les bornes théoriques.
Ce travail revêt une importance cruciale pour l’IPA en proposant une solution novatrice pour l’exploi-
tation des clusters dans le domaine de la bioinformatique. Cette approche vise à accélérer et simplifier le
processus scientifique, favorisant ainsi des découvertes plus rapides dans des domaines essentiels tels que
la santé publique et la biologie moléculaire.
La thèse porte sur les points suivants :
— La définition du contexte théorique des Workflow Scientifiques (WSs) et des SGWSs.
10
LISTE DES TABLEAUX
— L’exploration de la virtualisation comme une solution candidate pour atteindre la reproductibilité des
WSs.
— L’exploration du cluster en tant que plateforme pour accélérer les WSs.
— Concevoir une solution adéquate pour exécuter et gérer les WSs selon les méthodes et technologies
du domaine.
— Évaluer la solution proposée à l’aide d’un workflow concret - la construction d’arbre phylogénétique.
La thèse est organisée en 6 chapitres :
— Chapitre 1 : Présentation du Contexte

Ce chapitre présentera l’état actuel du PGB et l’évaluera.
— Chapitre 2 : État de l’art des Workflow Scientifique

Ce chapitre explorera les WSs et les SGWSs, ainsi que les méthodes utilisées pour atteindre la
reproductibilité et la scalabilité des WSs.
— Chapitre 3 : Conception de la plateforme

Ce chapitre présentera la conception de la solution proposée.
— Chapitre 4 : Implémentation de la plateforme

Dans ce chapitre, on va définir les technologies utilisées pour mettre en œuvre la solution.
— Chapitre 5 : Évaluation & Discussion

Dans ce chapitre, on va tester et évaluer la solution développée en utilisant l’arbre phylogénétique
comme un workflow de test, puis on va discuter les résultats obtenus.
— Chapitre 6 : Conclusion Générale

Dans ce chapitre, on va présenter une conclusion générale du projet ainsi que de perspectives.
Chapitre 1
Présentation de Contexte
1.1 Présentation de l’Institut Pasteur

L’Institut Pasteur d’Alger a été créé en 1894 à l’initiative des docteurs Jean Baptiste Paulin Trolard et H.
Soulie. Il a été fondé dans le but de lutter contre les maladies infectieuses qui étaient prédominantes à cette
époque en Algérie.
En 1900, une mission scientifique a été envoyée de l’Institut Pasteur de Paris à l’Institut Pasteur d’Alger.
Cette mission, menée par les frères Edmond et Étienne Sergent, avait pour objectif de confirmer l’hypothèse
du docteur Alphonse Laveran concernant l’agent responsable du paludisme.
Sur la base des conclusions de cette mission, l’IPA (Institut Pasteur d’Algérie) a été pleinement fondé
le 31 décembre 1909 à la suite de l’union entre cette mission et l’Institut. L’IPA a été considéré comme
un institut d’outre-mer, affilié à l’Institut Pasteur de Paris et placé sous la tutelle des autorités coloniales
locales. Ses responsabilités ont été définies dans le contrat signé entre Charles Jonnart, gouverneur général
d’Algérie, et l’Institut Pasteur de Paris, dirigé par le Dr Émile Roux.
Conformément à ce contrat, l’IPA a été défini comme "Le centre de recherche scientifique selon les mé-
thodes pasteuriennes", chargé "d’étudier les maladies virulentes chez l’homme, les animaux et les plantes
pour l’intérêt de l’Algérie et des pays d’Afrique du Nord, l’enseignement des méthodes microbiologiques,
ainsi que l’organisation et la direction de toutes les recherches, missions et études scientifiques liées à la
microbiologie ou à la santé publique en Algérie", La direction de cet institut a été confiée au Dr Albert
CALMETTE de 1910 à 1912, puis au Dr Edmond SERGENT de 1912 à 1962.
L’IPA est également membre du Réseau International des Instituts Pasteur, dont la coordination est
assurée par l’Institut Pasteur de Paris, L’objectif commun du réseau est de développer un programme de
coopération scientifique axé notamment sur la protection de la santé publique. Cela inclut la surveillance
et le contrôle épidémiologique des maladies infectieuses et parasitaires telles que le SIDA, la grippe, la
tuberculose, le paludisme, le choléra, ...
12
CHAPITRE 1. PRÉSENTATION DE CONTEXTE
L’IPA participe activement aux grands programmes de recherche internationaux ou régionaux. Cela
inclut des activités telles que la recherche clinique, les enquêtes épidémiologiques et bien d’autres. Cette
participation renforce les collaborations scientifiques à l’échelle mondiale, favorise l’échange de connais-
sances et contribue à la lutte contre les maladies infectieuses au niveau mondial. [3]
Notre stage a été réalisé au niveau de la PGB (Plateforme Génomique-Bioinformatique) de l’ IPA.
1.2 État actuel de la Plateforme Génomique-Bioinformatique

Les chercheurs du PGB exécutent manuellement les workflows bioinformatiques. Ils enchaînent plusieurs
commandes et outils pour réaliser les différentes étapes d’un workflow, puis transfèrent les résultats de façon
manuelle à chaque étape. Cette méthode présente des problèmes majeurs, qu’on présente ci-dessous :
1. Vulnérable aux erreurs : Le recours aux outils de ligne de commande et à l’exécution manuelle peut
facilement conduire à des erreurs difficiles à suivre et à corriger.
2. Automatisation limitée : L’automatisation ne peut être réalisée qu’à travers l’exécution de scripts
en arrière-plan (daemons). Cette approche nécessite une grande expérience et des connaissances en
bash-scripting et en administration système, ce qui n’est pas le cas pour les chercheurs du PGB. De
plus, cela peut facilement entraîner des erreurs et des plantages du système.
3. Scalabilité limitée : Une seule machine peut être utilisée à la fois lors de l’exécution du workflow, ce
qui limite l’exploitation des ressources et l’amélioration des performances.
4. Reproductibilité non garantie : Même si les entrées et les paramètres restent constants, le chercheur
ne peut pas garantir à 100% que les résultats seront les même, à cause des variations de l’environnement
d’exécution lors du déploiement sur diverses architectures et systèmes d’exploitation.
5. Absence d’une interface graphique : Bien que la ligne de commande soit une interface puissante,
elle nécessite une formation importante. Il est donc préférable d’avoir une interface graphique plus
conviviale.
6. Contrôle et surveillance des ressources limités : En utilisant uniquement la ligne de commande, il est
difficile de suivre précisément la quantité de ressources utilisées lors de l’exécution. Cela complique
l’évaluation des workflows et la détection des bottlenecks.
Dans le cas de la construction de l’arbre phylogénétique (un workflow qui sera exploré dans le chapitre
évaluation et discussion), un outil spécifique a été développé, nommé HOKEGA [4]. L’outil HOKEGA a été
développé en tant qu’application web, mais malheureusement, l’application n’est pas actuellement utilisée
en raison de certaines limitations qui l’empêchent d’atteindre le niveau de production. Les suivantes sont
les limitations remarquées dans HOKEGA.
CHAPITRE 1. PRÉSENTATION DE CONTEXTE
1. Performance limitée : HOKEGA traite les tâches de manière séquentielle, ce qui peut entraîner des
performances faibles et médiocres, en particulier lorsqu’il s’agit de grands ensembles de données, de
plus HOKEGA ne peut exploiter que les ressources d’une seule machine.
2. Extensibilité limitée : HOKEGA est conçu pour gérer un seul workflow -arbre phylogénétique-, ce
qui signifie qu’il ne peut pas être étendu à d’autres workflows.
3. Faible Fiabilité :
— Aucun mécanisme de gestion des erreurs ou des exceptions n’est mis en place, si une erreur se
produit, l’utilisateur final ne peut pas la retrouver.
— Absence de mécanisme de récupération ou de sauvegarde des données.
Ces limitations soulignent la nécessité d’une nouvelle approche capable de résoudre ces problèmes et de
fournir une solution plus efficace et scalable pour le déploiement et la gestion des WSs.
1.3 Les Besoins Fonctionnels

Les principales exigences sont :
1. Fournir des mécanismes pour créer, déployer et gérer les WSs.
2. Assurer la reproductibilité et la réutilisabilité des WSs.
3. Améliorez les performances et réduisez le temps d’exécution.
4. Fournir une interface facile à utiliser pour interagir avec la plateforme.
1.4 Le Périmètre de Projet

La solution est destinée à être utilisée en interne par les chercheurs de la PGB (1 à 10 personnes), sur un
réseau local où tous les calculs ou stockages doivent être effectués sur des machines locales privées. Pour
des raisons de sécurité, aucun stockage ou calcule distant n’est autorisé. Les utilisateurs de la plateforme ne
sont pas novices en matière de programmation et de scripting.
Chapitre 2
État de L’art des Workflows Scientifiques
2.1 Introduction
Dans ce chapitre, on commence par présenter le workflow scientifique (WS), en couvrant sa définition
et ses éléments. Ensuite, on explore le Système de Gestion des Workflows Scientifiques (SGWS) comme un
moyen d’automatiser les WSs, en approfondissant sa définition, ses fonctions et ses caractéristiques. Par la
suite, on discute des moyens de garantir la reproductibilité et la scalabilité des WSs, et pour finir, on explore
quelques solutions concrètes.
2.2 Contexte Historique

Les workflows ont une histoire profonde dans la modélisation des processus scientifiques. Les chercheurs
ont réalisé dès le début la nécessité d’un paradigme bien défini pour décrire les différents processus
scientifiques, en particulier avec leur complexité croissante et leur consommation accrue de données.
Les premières tentatives ont consisté à concevoir des bases de données spéciales adaptées aux cas d’utili-
sation scientifique. Cependant, peu de temps après, les chercheurs ont remarqué les limites de cette solution
(contrôle limité, opérations d’écriture/mise à jour coûteuses, etc.), ce qui a abouti au développement de
plateformes sophistiquées comme WASA [5], (Workflow-Based Architecture to Support Scientific Database
Applications) en 1995 et ZOO [6], (un environnement de gestion des expériences scientifiques) en 1996 .
Ces plateformes ont aidé à formaliser le paradigme du workflow, mais en raison de leur complexité, elles
n’ont pas été largement adoptées dans le domaine scientifique.
Au cours des années 2000, de nouvelles plateformes telles que Kepler [7] et Ptolemy [8] ont été publiées.
Ces plateformes ont ajouté plusieurs nouvelles fonctionnalités (interface graphique, support multiplateforme,
etc.) pour simplifier la conception des workflows. Cependant, elles n’ont finalement pas pu suivre le rythme
de développement rapide des besoins scientifiques et des nouveaux environnements d’exécution (cloud,
cluster, etc.).
À l’ère actuelle, de nombreuses technologies sont en développement pour répondre au besoin d’une
solution générale permettant de gérer les workflows scientifiques de manière moderne, simple et scalable.
15
CHAPITRE 2. ÉTAT DE L’ART DES WORKFLOWS SCIENTIFIQUES
2.3 Le Workflow Scientifique
2.3.1 Définition
Il existe plusieurs définitions pour les workflow scientifiques, on a constaté que la plus complète est
la suivante : Un workflow scientifique est la description d’un processus permettant d’atteindre un objectif
scientifique, généralement exprimé en termes de tâches et de leurs dépendances. En règle générale, les
tâches d’un workflow scientifiques sont des étapes de calcul pour des simulations scientifiques ou des étapes
d’analyse de données. Les tâches d’un workflow scientifique sont organisées au moment de la conception et
orchestrées au moment de l’exécution en fonction du flux de données et éventuellement d’autres dépendances
spécifiées par le concepteur. Les workflow scientifiques peuvent être conçus visuellement, à l’aide de
diagrammes ou textuellement à l’aide d’un DSL [9].
D’un point de vue mathématique, on peux modilizer un workflow scientifique comme une paire 𝑤 =
® où 𝐴 représente un ensemble d’activités 𝑎𝑖 (tâche / étape de calcule) et 𝐷® est un ensemble de tuples
( 𝐴, 𝐷),
(𝑎𝑖 , 𝑎 𝑗 ) qui représentent la dépendance entre 𝑎𝑖 et 𝑎 𝑗 , indiquant ainsi l’ordre d’exécution des tâches. [10]
Il y a deux type de depenedence :
1. Dépendance de flux de données (data-flow).
2. Dépendance de flux de contrôle (control-flow).
En se basnt sur la definition mathematique on peut remarquer la similarité entre la modélisation d’un
worklfow et entre un DAG, ce qui la figure 2.1 montre.
Figure 2.1 – La Modélisation Mathématique d’un Workflow
En récapitulant, on peut dire qu’un workflow scientifique représente un ensemble de tâches de calcul
organisées en fonction du flux de données et du flux de contrôle, afin d’atteindre un objectif scientifique.
2.3.2 Les Structures De Conception De Workflow (Workflow Building-blocks)
Le WS suit une organisation axée sur les données (data-driven) [11], où les données traversent des
chemins constitués de différentes structures, qui applique certaines opérations sur ces données. Dans la
partie suivante, on présente ces structures [1].
— Les Structures simples (un à un) : La structure la plus simple est la structure du processus qui opère
sur une donnée d’entrée et génère une donnée de sortie. Plusieurs processus peuvent être combinés
séquentiellement pour produire une structure de pipeline, chaque processus du pipeline consomme
les données fournies par le processus précédent et transmet ses sorties au processus suivant.
— Les Structures complexes Il existe trois types de structures complexes

— Structure de distribution (Data distribution/partitioning) (un-à-plusieurs) : Cette structure
sert au partitionnement des données, elle produit des sorties qui sont consommées par plusieurs
processus, cette structure est hautement parallélisable et représente un point de désynchronisa-
tion.
— Structure d’agrégation (Data aggregation) (plusieurs à un) : Cette structure combine les
sorties des processus précédents et génère une sortie combinée de données, cette structure peut
potentiellement consommer beaucoup de temps et de ressources de calcul, elle représente un
point de synchronisation.
— Structure de redistribution (Data redistribution) (plusieurs à plusieurs) : Cette structure
peut être considérée comme une combinaison des deux structures précédentes, elle joue les
mêmes rôles discutés précédemment, mais elle est principalement utilisée lorsque les tâches de
combinaison et de partitionnement de données peuvent être effectuées dans le même processus
pour des gains potentiels.
Figure 2.2 – Structures de Workflow [1]
Après avoir établi une définition solide autour du workflow scientifique et son organisation, on passe aux
système utilisé pour automatiser la création et la gestion de ces workflows.
2.4 Système de Gestion des Workflows Scientifiques

Selon le Workflow Management Coalition (WMC) un système de gestion des workflows est un système qui
définit, gère et exécute complètement les workflows grâce à l’exécution de logiciels dont l’ordre d’exécution
est piloté par une représentation informatique de la logique du workflow [12].
Donc un SGWS peut être considéré comme un cadre logiciel conçu pour prendre en charge la création,
l’exécution et la gestion des workflow scientifiques. Ces SGWS assurent l’orchestration de multiples tâches
(activités) de calcul et le flux des données qui forment collectivement une expérience scientifique.
2.4.1 Les Fonctions d’un SGWS
Selon le modèle de référence proposé par le WMC [12], les fonctions d’un SGWS pourraient être
caractérisées en fonctions de temps de construction et fonctions de temps d’exécution .
Fonctions de Temps de Construction (Build-time Functions)
Les fonctions de temps de construction définissent et modélisent le workflow et ses dépendances ils
englobent deux aspects :
— L’aspect conceptuel : La définition des composants du workflow (structures).
— L’aspect relationnel : La définition de relations possible entre les composants du workflow.
Les aspects conceptuel et relationnel servent à la modélisation du workflow et sont généralement réalisés via
un DSL textuelle ou graphique, qui détermine l’expressivité, l’exhaustivité et les fonctionnalités offertes par
un SGWS. Il convient de noter que les fonctions de temps de construction peuvent inclure des responsabilités
supplémentaires telles que des outils d’administration et de gestion, des utilitaires de test et de débogage,
ainsi que la spécification de l’environnement d’exécution (variables d’environnement, configuration, etc.)
Fonctions de Temps d’exécution (Run-Time Functions)
Les fonctions de temps d’exécution impliquent la gestion de l’exécution du workflow et l’interaction

avec les ressources physiques et logiques. Elles concernent la gestion de l’exécution des tâches du workflow,
l’allocation des ressources et le contrôle du flux de données entre les différents processus du workflow.
2.4.2 Caractéristiques des SGWS
Dans la partie suivante, on va résumer les caractéristiques les plus importantes d’un SGWS [13].
— Convivialité : Une interface conviviale est cruciale pour assurer une adoption transparente, les scien-
tifiques ont besoin d’outils simples pour décrire, déployer et gérer les workflows, une automatisation
maximale est nécessaire pour masquer les spécifications techniques et la gestion des ressources.
— Flexibilité : Un SGWS doit assurer la flexibilité. On définisse la flexibilité comme la capacité d’un
système à répondre aux changements externes. Par exemple, une expérience effectuant une simulation
scientifique a des paramètres. Le SGWS doit permettre au scientifique de modifier les paramètres du
workflow sans recréer l’ensemble du workflow.
— Reproductibilité : La reproductibilité est la capacité de générer les mêmes résultats d’une expérience
sur différentes plateformes, à différents moments et par différentes personnes.
— Fiabilité : La fiabilité des WSs est essentielle, car leur exécution peut être longue. La "fiabilité" signifie
la capacité à résister aux erreurs. Le SGWS doit fournir des mécanismes pour gérer les erreurs et les
exceptions pendant l’exécution avec une pénalité minimale, et éviter les pertes de données en cas de
problèmes.
— Scalabilité : La scalabilité fait référence à la capacité du SGWS à gérer des quantités croissantes de
tâches. Un SGWS doit évoluer avec le nombre et la taille des workflows ainsi que la croissance de la
taille des données et des ressources
2.5 Virtualisation : solution pour la reproductibilité

Le processus scientifique est de nature expérimentale. Par conséquent, les scientifiques peuvent mener
le même processus scientifique à différentes occasions, avec des paramètres différents et sur différentes
plateformes. Pour cette raison, un SGWS doit assurer la reproductibilité des processus scientifiques. Il est
intéressant de noter qu’une problématique similaire existe dans le domaine du développement logiciel, où
les développeurs utilisent des technologies sophistiquées pour assurer la compatibilité des logiciels avec
différents systèmes d’hébergement. Dans les points suivants, on présente la virtualisation comme l’approche
principale utilisée par les SGWSs pour assurer la reproductibilité des WSs
2.5.1 Virtualisation
La virtualisation est une technologie qui utilise un logiciel appelé hyperviseur pour créer plusieurs
ordinateurs virtuels (appelés machines virtuelles) sur une seule machine physique (machine hôte), qui
partage ses ressources (CPU, mémoire, bande passante réseau, disque, etc.) avec les VMs. Chaque VM
fonctionne avec son propre système d’exploitation, ce qui est une caractéristique clé pour assurer la sécurité
et l’isolation de ces machines. La machine hôte gère les machines virtuelles et surveille leur comportement
ainsi que leur consommation de ressources. D’un point de vue théorique, les ressources limitées de la machine
hôte sont la seule limite lors de l’instanciation de VMs. D’un point de vue technique, la virtualisation est
implémentée en trois types principaux. [14]
2.5.2 Virtualisation de type 1
Dans la virtualisation de type 1, l’hyperviseur se comporte comme un système d’exploitation natif

avec un accès direct au matériel, d’où son appellation d’hyperviseur de niveau matériel (bare-metal). En
raison de ses propriétés, ce type d’hyperviseur offre de meilleures performances et une meilleure utilisation
des ressources par rapport à d’autres types [15]. De plus, il offre une grande stabilité et sécurité grâce à
son indépendance vis-à-vis du système d’exploitation hôte. Plusieurs fabricants proposent des solutions de
virtualisation de type 1, tels que VMware [16], Microsoft Hyper-V [17] et KVM [18]. À l’exception de
KVM, tous les hyperviseurs précédemment mentionnés sont des solutions propriétaires. Ils proposent une
version à usage minimal de leur produit, mais pour un usage professionnel, l’acquisition d’une licence est
nécessaire. De plus, pour une expérience optimale avec les hyperviseurs de type 1, notamment KVM, des
compétences en administration Linux sont requises.
2.5.3 Virtualisation de type 2
Dans la virtualisation de type 2, l’hyperviseur n’est qu’un logiciel exécuté sur la machine hôte, d’où son
appellation d’hyperviseur hébergé (hosted-VM). Contrairement aux hyperviseurs de type 1, un hyperviseur
de type 2 ajoute une couche supplémentaire entre le système d’exploitation hôte et la VM. Cela présente des
inconvénients majeurs en termes de performances et de sécurité. En revanche, il fournit une interface plus
conviviale pour la gestion et représente un moyen pratique pour tester et expérimenter. L’un des hyperviseurs
de type 2 les plus connus et les plus utilisés est Oracle VirtualBox [19]. Il offre une interface facile à utiliser
et est compatible avec les principaux systèmes d’exploitation. Ce logiciel est idéal pour le développement
et les tests, et il est utilisé dans différents domaines.
2.5.4 Conteneurisation
La conteneurisation est une forme de virtualisation au niveau du système d’exploitation (OS level) où
les dépendances d’un logiciel, telles que les fichiers de configuration, les bibliothèques et les binaires, sont
regroupées dans une image. L’exécution de cette image, appelée conteneur, se fait via un moteur (engine).
L’implémentation du moteur sur une plateforme spécifique garantit la compatibilité de toutes les images
avec cette plateforme, assurant ainsi une large compatibilité sans une forte consommation de ressources
[20].
Les conteneurs ont révolutionné la programmation scientifique. Ils peuvent atteindre des performances
comparables à une exécution native pour les applications intensives en CPU [21]. Cette technologie est
largement utilisée dans le domaine du HPC et du calcul distribué [22].
Bien que le concept de conteneurisation soit ancien (proposé par IBM en 1979) [23], son utilisation
commerciale la plus importante remonte à 2013 avec l’annonce du projet Docker [24]. Docker a été conçu
pour être une plateforme facilitant la distribution d’applications dans différents environnements, sans les
contraintes liées aux dépendances et aux restrictions de plateforme.
Figure 2.3 – Les Types de virtualisation
2.6 Scalabilité des WSs à l’Aide du Cluster

La demande croissante de puissance de calcul dans divers domaines scientifiques a conduit à une
transition des systèmes à machine unique vers des systèmes distribués. Cette évolution permet de surmonter
les limitations d’une machine unique en termes de performances et de ressources physiques.
2.6.1 Définition de Cluster
Un cluster est un type de systèmes distribués, en particulier un Système distribué de calcule, défini
comme un ensemble d’ordinateurs mis en réseau de manière à ce que la communication entre les nœuds
repose sur un échange de messages [25]. On peux considérer le cluster comme un ensemble de machines
autonomes utilisées pour le calcul et le stockage, interconnectées par un réseau local et coopérant ensemble
pour exécuter des tâches parallèles.
2.6.2 Caractéristiques du cluster
En raison de l’organisation des machines dans un cluster, plusieurs caractéristiques clés peuvent être
observées : [25]
— Processus multiples : Dans un cluster, plusieurs processus s’exécutent de manière dispersée sur
différentes machines, chacun avec son propre thread de contrôle indépendant.
— La communication Inter-processus : Dans un cluster, la communication entre les processus distants

est essentielle, généralement assurée par des messages échangés sur un réseau. La fiabilité et les
performances de la plateforme de communication sont cruciales pour garantir un fonctionnement
optimal du système.
— Espace d’adressage disjoint : Chaque nœud du cluster a son propre espace d’adressage, l’espace
mémoire partagé peut être virtualisé via le réseau mais aucune mémoire partagée physique n’est
requise.
— Concurrence : Les processus exécutés sur un système distribué présentent une nature concurrente,
nécessitant un mécanisme permettant de gérer cette exécution simultanée sans imposer de contraintes
sur le nombre ou le type de processus.
— Pas d’horloge centrale : L’absence d’une référence temporelle centrale est l’une des caractéristiques
les plus importantes des clusters, ce qui souligne la nécessité d’un mécanisme de synchronisation
bien défini. Cette synchronisation est généralement obtenue grâce à des protocoles de synchronisation
temporelle et à des horloges logiques.
— Échec Indépendant : Dans un cluster, des erreurs et des plantages peuvent survenir à n’importe
quel niveau. Par conséquent, un cluster fiable doit prendre des mesures de prévention pour gérer les
défaillances indépendantes des nœuds, tant au niveau des nœuds individuels qu’au niveau du système
dans son ensemble.
Un cluster se compose de plusieurs machines qui coopèrent pour exécuter des tâches en parallèle. Afin
d’organiser et de gérer cette complexité, une architecture adéquate doit être en place. Dans la section suivante,
on présente l’architecture maître-esclave, largement utilisée dans différents clusters de production. on va
examiner la répartition logique des responsabilités entre les composants ainsi que les défis cruciaux à relever
lors de l’implémentation de ce type d’architecture.
2.6.3 Architecture Maître-Esclave
L’architecteur maitre-esclave est l’une des architecture dominanate dans les system distribué [26], cette
architecture est une forme d’architecture orientée objet (object-based architecture) [27]. Dans cette confi-
guration, une machine maître, également appelée nœud de contrôle, coordonne l’exécution des tâches sur
plusieurs machines esclaves, également appelées nœuds de travail. Cette architecture peut être mise à
l’échelle simplement en ajoutant des nœuds supplémentaires ou en utilisant des nœuds spécialisés tels que
des machines de calcul dédiées ou de grandes machines de stockage. Le nombre maximal de nœuds est
principalement déterminé par la capacité du maître et la qualité du réseau. Cette architecture spécifie les
rôles et responsabilités de chaque machine, facilitant ainsi la gestion et le remplacement des composants.
Pour assurer des performances optimales, il est nécessaire de traiter certains points :
— La Communication : Une plateforme de communication fiable et rapide doit être mise en place pour
réduire la latence et assurer la transmission des données, toute latence ou déconnexion entre le maître
et les esclaves réduira considérablement les performances globales du système, de plus un mauvais
flux de données peut devenir un goulot d’étranglement lors de l’exécution de programmes parallèles.
— Gestion des Ressources : La gestion des ressources est déterminée à la fois avant le début du
travail (Ressources Allocation) et peut être optimisée au moment de l’exécution (Load-Balance).
Un mécanisme bien défini d’allocation des ressources améliorera les performances du système. Ce
mécanisme doit prendre en considération l’hétérogénéité des nœuds et les types de programmes
exécutés. Il doit être capable d’allouer la quantité appropriée de ressources pour chaque tâche sans
négliger aucune tâche spécifique, afin d’éviter un temps d’attente indéfini.
— Gestion des pannes : Il y a deux niveau critiques où des plantages peuvent survenir dans un cluster :
— Au Niveau du Maître : En raison de la gestion centralisée, toute erreur ou plantage survenant au

niveau du maître peut paralyser l’ensemble du système. Pour atténuer cette vulnérabilité, il existe
plusieurs mécanismes et mesures de prévention qui peuvent être mis en place. Le plus simple
consiste à attribuer un nœud maître secondaire, capable de prendre le relais en cas de défaillance
du maître principal (Masquage des pannes par redondance physique) [28]. Ce mécanisme de
secours assure la continuité du service en cas d’incident.
— Au Niveau de l’Esclave : Les erreurs et les plantages au niveau de l’esclave sont généralement
moins critiques, car ils n’arrêtent pas le système entier. Une solution simple pour résoudre ces
problèmes est de redémarrer le travail sur un autre nœud esclave (Retry). Pour prévenir ces
incidents, on peux répliquer le travail (Masquage des échecs par réplication des processus)
[29]. Bien que ce compromis puisse être difficile à accepter, il devient crucial lors de l’exécution
de travaux qui dépendent des résultats d’autres tâches. En ce qui concerne la persistance des
données, les sauvegardes (Backup) sont la solution la plus élémentaire.
2.6.4 Les éléments de cluster
Un cluster consiste de deux types d’éléments, les éléments matériels et les éléments logiciels, dans ce
qui suit on va présenter ces deux types.
Les éléments matériels
Les nœuds physiques : Les nœuds physiques intègrent tous les périphériques matériels responsables
de l’exécution du programme, du stockage des données et de la planification des tâches dans le cluster [30].
Voici les points clés lors de la choix d’un nœud.
— Processeur : Le processeur représente le cœur du système, responsable de l’exécution de toutes les

tâches, il existe plusieurs spécifications techniques à prendre en compte lors du choix d’un proces-
seur (Instruction Set Architecture (ISA), Fréquence d’horloge, Performances maximales en virgule
flottante, taille du cache, capacités multi-cœurs, Thermal design power (TDP), ...).
— Coprocesseur : Un coprocesseur est un processeur supplémentaire utilisé pour effectuer des tâches
spécialisées telles que des calculs arithmétiques approfondis ou un traitement graphique, il existe
différentes variantes de coprocesseur, mais les plus importantes sont les GPU’s, qui peuvent être utili-
sées pour accélérer certaines applications comme l’apprentissage automatique, simulation, traitement
d’image.
— Mémoire Principale : La vitesse et la taille de la mémoire principale sont cruciales à la fois pour les
nœuds de calcul (pour exécuter les processus) et les nœuds de contrôle (pour planifier les tâches), les
nouveaux modèles de mémoire peuvent fournir jusqu’à 32 Go de mémoire par stick avec des vitesses
qui atteint 6400 Mbps [31].
— Stockage : En ce qui concerne le stockage, deux technologies courantes sont utilisées, le HDD et le
SSD. Le premier offre de grandes capacités (jusqu’à 32 To) [32] avec des vitesses de lecture/écriture
lentes. Le SSD, en revanche, assure des vitesses de lecture/écriture rapides mais avec une capacité de
stockage moindre (1 To à 4 To) [33]. Les SSD sont principalement utilisés pour le boot de système
d’exploitation, tandis que les HDDs sont utilisés pour stocker les données. D’autres technologies
peuvent être utilisées pour améliorer la fiabilité et le performance du stockage, telles que le RAID et
le LVM.
Réseau
— Interconnexion de réseaux : Il existe plusieurs technologies utilisées pour interconnecter les nœuds
du cluster, mais la plus couramment utilisée est Ethernet en raison de sa fiabilité, de sa compatibilité et
de ses performances. Ethernet est normalisé sous IEEE 802.3 et présente différentes implémentations
offrant des vitesses variées : Ethernet (10 Mbps), Fast Ethernet (100 Mbps), Gigabit Ethernet (1000
Mbps à 4000 Mbps), et Ethernet sur fibre (100 Mbps à 100 Gbps) [34].
— Les Commutateurs : Le besoin de commutateurs puissants est primordial dans un cluster, une
interconnexion rapide et fiable ne suffit pas pour obtenir une connexion optimale entre les nœuds du
cluster, la fonction principale du commutateur est de connecter plusieurs périphériques au sein d’un
réseau local et de transférer intelligemment des trames de données entre eux en fonction de leurs
adresses MAC.
Éléments logiciels
— Système d’exploitation Le système d’exploitation est la configuration logicielle minimale requise

pour faire fonctionner une machine, dans le domaine d’HPC, Linux domine, pour les raisons suivantes :
1. Code source ouvert : le noyau Linux est disponible pour un usage public sous la licence
GNU GPL [35], pratiquement Linux est utilisé à travers ses implémentations appelées distribu-
tions comme Debian, openSUSE, Red-Hat .etc, ces distributions empaquettent le noyau Linux
en plus de plusieurs outils.
2. Personnalisation et Compatibilité : Un système d’exploitation basé sur Linux est extrêmement
personnalisable, il peut être adopté pour n’importe quel besoin spécifique (performance, efficacité
énergétique, haute sécurité, ...), de plus en raison de son état mature -33 ans -, Linux est
hautement compatible avec différentes architectures et matériels. Cet énorme héritage a permis
une optimisation plus approfondies.
3. Scalabilité : Linux implémente les technologies les plus récentes pour la gestion et l’exploitation
de clusters et de machines HPC. Sur la base du classement Top500 pour 2023 [36], les 500 super-
calculateurs les plus puissants au monde utilisent un système d’exploitation de la famille Linux.
4. Sécurité, Stabilité et Fiabilité : Linux est connu pour sa sécurité et sa stabilité, l’approche axée
sur la communauté (Community-driven development (CDD)) pour le développement du noyau a
permis à des milliers de développeurs de lire, tester et améliorer le code de base, ce qui a entraîné
un nombre minimal de bogues et de vulnérabilités de sécurité. en outre, Linux est soutenu par
d’énormes coopérations telles que Microsoft, Google, IBM, Oracle .etc.
5. Rentabilité La plupart des distributions Linux sont gratuites, Linux est rentable par rapport aux
systèmes d’exploitation propriétaires.
— Planification des Tâches (Scheduler)

Une mauvaise planification des tâches va entraîner une dégradation des performances du système. Pour
remédier à ce problème, un logiciel dédié, appelé planificateur de tâches (scheduler), gère l’allocation
des ressources et l’exécution des tâches sur le cluster. Parmi les planificateurs couramment utilisés
dans les environnements de clusters figurent Slurm [37], HTCondor [38], Torque [39], etc.
— Accès distant aux Données : Une gestion efficace des données au sein d’un cluster est essentielle. Les
nœuds à l’intérieur d’un cluster doivent pouvoir accéder à distance à un espace de stockage partagé
pour lire et écrire des données. Cela peut être réalisé via les SGFDs.
2.7 Vue sur des solution concrète

La dernière décennie a vu une énorme croissance dans le domaine du workflow scientifique, différentes
organisations et entreprises et même des développeurs indépendants proposent de nouveaux SGWSs. Dans
cette section, on va explorer trois SGWSs.
2.7.1 Nextflow
Nextflow est un SGWS publié le 9 avril 2013 en tant que projet open source, désormais sous licence
Apache. Il est principalement utilisé pour l’analyse de données bioinformatiques, mais peut être adapté à
d’autres domaines. Nextflow fournit un DSL facile à apprendre, basé sur le langage de programmation Groovy
[40], pour décrire les workflows. Il offre une grande compatibilité avec différents systèmes d’exploitation et
prend en charge diverses plateformes d’exécution, telles que les machines locales, les clusters et le cloud. Il
prend également en charge différentes technologies de conteneurisation, telles que Docker [24], Singularity
[41], Apptainer [42] et Podman [43]. De plus, Nextflow est largement documenté et dispose d’une énorme
quantité de matériel d’apprentissage gratuit. [44]
2.7.2 Snakemake
Snakemake est un SGWS et un Domain Specific Language (DSL) basé sur le langage de programmation
Python, principalement utilisé dans le domaine de la bioinformatique. Il est open source et sous licence MIT.
Snakemake a été introduit dans un article de recherche intitulé “Sustainable Data Analysis with Snakemake”
[45]. Il prend en charge différentes plateformes d’exécution, telles que les machines locales, les clusters et
le cloud. Par défaut, il utilise les environnements Conda [46] pour packager les dépendances du workflow.
Snakemake bénéficie d’une communauté grandissante ainsi que de ressources d’apprentissage de qualité
[47].
2.7.3 Cromwell
Cromwell est un SGWS open source développé par le Broad Institute et il est particulièrement conçu pour
l’exécution de workflow en bioinformatique. Cromwell utilise une implémentation spécifique du langage
WDL [48] qui vise à atteindre une lisibilité et une facilité d’écriture lors de la conception de workflow
scientifiques complexes, il est moins documenté et a une petite communauté par rapport aux deux solutions
précédentes, le principal inconvénient de Cromwell par rapport aux deux autres SGWSs est que le langage
utilisé pour décrire le workflow -WDL- n’est pas Turing-complet, ce qui signifie que les chercheurs sont
limités lors de la conception de workflow. [49]
2.8 Conclusion
Ce chapitre a présenté le cadre théorique nécessaire pour conceptualiser la solution adéquate pour l’IPA.
On a commencé par définir le WS et le SGWSs comme une plateforme utilisée pour automatiser la création,
le déploiement et la gestion des WSs. Ensuite, on a mis en évidence la virtualisation comme solution pour
assurer la reproductibilité des WSs, ainsi que le cluster comme plateforme pour accélérer les WSs. Enfin,
on a passé en revue certaines implémentations modernes de SGWS.
Chapitre 3
Conception de la plateforme
3.1 Introduction
Après avoir acquis une compréhension approfondie des WSs et des SGWSs, déterminé que la virtuali-
sation est la solution appropriée pour garantir la reproductibilité, et exploré les systèmes de cluster comme
plateforme pour accélérer le calcul scientifique, on passe à la phase de conception. Cette étape est cru-
ciale dans le développement de logiciels, car elle permet aux développeurs de formaliser les exigences
fonctionnelles des utilisateurs finaux et d’identifier les obstacles potentiels. Ce chapitre vise à définir les
fonctionnalités du système, à présenter un modèle à suivre pour la partie implémentation, et à décrire les
solutions choisies pour relever les défis rencontrés.
3.2 Architecture Globale du Système

On propose une architecture qui adopte un style en couches (layers). Elle comprend trois couches
principales : la couche d’exécution, la couche middleware et la couche utilisateur. Cette conception modulaire
facilite la scalabilité, la maintenabilité et l’extensibilité du système, La figure 3.1 illustre l’architecture
globale du système.
— Couche d’exécution (Execution Layer)
— Cette section est chargée de gérer l’exécution des jobs. On vise à définir une abstraction de job
cohérente pour assurer la compatibilité et la facilité d’intégration avec la couche middleware.
— Cette couche comprend des composants pour la soumission des jobs, l’allocation des ressources
et l’orchestration des jobs.
— L’accent est mis sur la gestion efficace des dépendances d’un job et la tolérance aux pannes.
— Couche Middleware (Middleware Layer)
— Agissant comme un pont entre la couche d’exécution et la couche utilisateur, la couche middle-
ware facilite la communication et l’échange de données.
28
CHAPITRE 3. CONCEPTION DE LA PLATEFORME
— Cette couche fournit des services tels que le traitement et la validation des données, la surveillance
de l’exécution des jobs, la récupération des résultats et le nettoyage après la fin de l’exécution
d’un job.
— La couche middleware masque les complexités associées à l’exécution des jobs et à la gestion
des conteneurs via des gestionnaires (handlers).
— Couche Utilisateur (User Layer)
— La couche utilisateur offre une interface conviviale pour interagir avec le système, où la simplicité
et l’intuitivité sont des considérations clés dans la conception pour améliorer l’expérience des
utilisateurs.
— Cette couche implémente une architecture Model–view–controller (MVC), qui permet de séparer
la logique, la présentation des données et la gestion des interactions utilisateur.
— Elle permet aux utilisateurs de soumettre et de surveiller les jobs et de visualiser les résultats.
Figure 3.1 – Architecture Globale du Platforme
Remarque : les handlers sont des composants logiques qui gèrent l’exécution et la gestion de certaines
tâches, ils seront explorés en détail dans la section middleware.
3.3 Couche d’exécution (Execution Layer)

La couche d’exécution est responsable de l’exécution des tâches, comme l’exécution d’un workflow ou
le chargement du conteneur. On propose deux modes d’exécution : un exécuteur local et un exécuteur
de cluster. Grâce à ces modes d’exécution, on vise à augmenter la fiabilité et la disponibilité du système.
L’exécuteur local permet de fournir un service minimal et d’assurer la continuité de service en cas de
défaillances matérielles ou d’erreurs logicielles sur l’exécuteur de cluster.
3.3.1 Exécuteur local (Local Executor)
L’exécuteur local est destiné à être utilisé sur une seule machine. Il représente une option simple, mais
moins efficace pour l’exécution des workflows. Son objectif est de servir dans des circonstances où l’exécuteur
de cluster n’est pas disponible. Cette configuration offre une grande flexibilité lors de la configuration et
garantit la disponibilité du plateforme.
3.3.2 Exécuteur de Cluster (Cluster Executor)
On propose le cluster comme plateforme principale pour accélérer les workflows bioinformatiques. Tous
les calculs seront exécutés sur des machines locales privées et administrés par les bioinformaticiens de l’IPA.
Pour assurer l’intégration du cluster avec la plateforme, on conçoit un mode d’exécution de cluster.
Comme mentionné dans le chapitre précédent, le cluster suivre une architecture maître-esclave où chaque
nœud joue un rôle spécifique. Cette architecture favorise la scalabilité et l’extensibilité.
Dans la section suivante, on présente l’organisation du cluster, où on décrit les nœuds du cluster et on
spécifié leurs responsabilités.
Le Nœud de Contrôle (Control Node)
Le nœud de contrôle coordonne l’exécution des jobs sur le cluster et l’allocation des ressources. Il planifie
également les jobs en fonction d’un algorithme prédéfini et joue un rôle important dans la supervision des
erreurs et des exceptions survenant au niveau des nœuds de calcul.
Caractéristiques :
— Nécessite des ressources CPU et mémoire modérées à élevées pour assurer une planification fluide
sans blocages.
— Doit disposer d’une connectivité réseau rapide pour communiquer avec les autres nœuds du cluster.
Nœud de Calcul (Compute Node)
Les nœuds de calcul sont responsables de l’exécution des jobs.

Caractéristiques :
— Nécessitent des ressources CPU et mémoire élevées.
— Doivent avoir un accès rapide aux nœuds de stockage pour gérer de grands ensembles de données.
— Peuvent bénéficier de l’accélération GPU pour certains types de calculs.

Le Nœud de Stockage (Storage Node)
Le nœud de stockage gère le stockage des données utilisées par d’autres nœuds, y compris les données
persistantes et temporaires.
— Stockage Persistant : Stocke les données à long terme, telles que les données de définition de workflow
et les résultats d’un job, garantissant la durabilité et la fiabilité.
— Stockage Temporaire : Stocke les données intermédiaires générées lors de l’exécution des jobs,
offrant un accès rapide et efficace.
Caractéristiques :
— Nécessite un stockage de grande capacité.
— Doit avoir une connexion réseau rapide pour diffuser les données aux différents nœuds.
Le Nœud de Soumission (Submission Node)
Le nœud de soumission est le seul nœud du cluster autorisé à soumettre des jobs et à récupérer les
résultats. Ce nœud est l’interface pour exploiter les ressources du cluster et est dédié à l’exécution du
middleware.
Après avoir défini globalement les deux modes d’exécution, on passe aux défis de conception. Dans cette
section, on présentera les défis de conception rencontrés et les solutions utilisées pour les résoudre.
3.3.3 Défis de Conception
Abstraction du Job
La couche d’exécution comprend deux modes d’exécution. Par conséquent, une abstraction de job
concise doit être définie de manière interopérable, ce qui signifie que même si le mode d’exécution diffère,
l’abstraction de job doit rester la même.
Du point de vue de la couche d’exécution, un job représente une ou plusieurs tâches à exécuter (job-step).
Il est défini avec les attributs suivants.
— Job ID : L’identifiant unique, pouvant être attribué par les générateurs de UUIDs, il est essentiel pour
garantir l’unicité de chaque job et évite tout conflit lors de l’exécution des jobs dans un environnement
distribué.
— Les Dépendances de Job

Les dépendances d’un job sont classées en 4 types
— Scripts : fichiers texte exécutables dans n’importe quel langage de programmation (python, ruby,
R, ...), il est important de noter la nécessité d’un script principal "main-script" qui représente le
point de départ de l’exécution de job.
— Fichiers de données : Tout type de fichier contenant des données requises pour l’exécution des
jobs (txt, csv, png, ...).
— Environnement d’exécution : OS, binaires, outils, ...
— Inputs/Outputs : Fichiers binaires ou de texte.
Accessibilité des dépendances
Les jobs sont destinés à être exécutés selon deux modes : en mode local ou (ou exclusif) en mode
cluster. Dans les deux cas, les jobs en cours d’exécution doivent accéder à leurs dépendances. En mode
local, une seule machine est utilisée, donc l’accès aux dépendances est direct, que ce soit par la lecture d’un
répertoire ou la récupération de données dans une base de données locale. En revanche, lors de l’exécution
d’un job en mode cluster, les job-steps peuvent être exécutés sur différentes machines, nécessitant ainsi un
espace de stockage rapide, fiable et partageable accessible par les différents nœuds du cluster. Cette exigence
est satisfaite par les SGFDs dans la partie de stockage temporaire du nœud de stockage. Pour identifier
précisément les dépendances de chaque job en temps d’exécution (Run-Time), toutes les dépendances
de job sont encapsulées dans un répertoire appelé le "work-directory" du job, portant le même nom que
l’identifiant du job.
Conteneurisation, une solution pour packager les dépendances
Différents jobs peuvent avoir des environnements d’exécution différents. La méthode traditionnelle
consiste à installer les dépendances sur les différents nœuds de calcul manuellement. Cependant, le pro-
blème est que les environnements d’exécution ont tendance à évoluer et, dans la plupart des cas, ils sont
incompatibles les uns avec les autres.
La solution la plus récente et la plus élégante consiste à packager les différentes dépendances dans
une machine virtuelle qui sera déployée sur tous les nœuds de calcul du cluster. Pour réduire le temps de
chargement et simplifier la gestion, on propose d’utiliser la technologie de conteneurisation. Le moteur
d’exécution de conteneur est installé sur les nœuds de calcul et chaque job est exécuté dans son conteneur
approprié. Lorsque le job est terminé, le conteneur est automatiquement supprimé pour éviter le gaspillage
d’espace de stockage.
Sécurité à l’intérieur du cluster
Le problème principal de sécurité dans un cluster est la capacité d’une machine non-autorisée à exploiter
les ressource de cluster. Pour relever ce défi, on propose un mécanisme d’authentification basé sur une clé, où
seules les machines disposant de cette clé sont autorisées à exploiter le cluster, en plus, plusieurs protocoles
de communication peuvent être utilisés pour améliorer la sécurité de communication entre les noeuds.
Contrôle de charge
On a également incorporé 2 mécanismes pour contrôler le nombre et la manière dont les jobs peuvent
exploiter l’exécuteur. La première est une variable de contrôle appeler max_allowed_time, qui est définie
par le concepteur, si un job dépasse le temps autorisé, il sera automatiquement arrêter. Le second est un
verrou global qui garantit le nombre maximum de jobs pouvant s’exécuter simultanément sur l’exécuteur.
Ces deux mécanismes garantissent qu’aucun job ne monopolisera l’exécuteur pendant une durée infinie, ce
qui entraîne un blocage total du système.
Le logging et la surveillance des ressources
Les logs et la surveillance des ressources sont des aspects cruciaux du système. On propose d’utiliser des
outils intégrés dans le système d’exploitation pour surveiller les ressources telles que le CPU et la mémoire.
Pour suivre l’exécution des jobs, on enregistre les logs de chaque job, y compris leur sortie standard (stdout)
et leur sortie d’erreur (stderr), sous forme de fichiers.
Fiabilité et disponibilité du platforme
L’amélioration de la disponibilité et de la fiabilité du système implique plusieurs stratégies. La partie

suivante explore la redondance comme stratégie principale pour garantir la fiabilité et la disponibilité du
platforme.
— Au niveau de noeud de stockage de données
— L’utilisation d’un SGBD à haute tolérance pour le stockage persistant qui fournit des mécanismes
et des technologies intégrés pour gérer les erreurs et les exceptions et assurer la cohérence des
données. De plus, on propose l’utilisation d’une base de données embarquée qui fonctionne
principalement en mode exécuteur local pour assurer la disponibilité du système même en cas
de défaillance du stockage principal.
— Pour le stockage temporaire, on propose l’utilisation d’un système de gestion de fichiers distribué
(SGFD), fournissant des verrous pour synchroniser les opérations de lecteur et écritures.
— Au niveaux de contrôle
— Configuration d’un nœud de contrôle secondaire qui est déclenchée automatiquement lorsque le
contrôleur principal tombe en panne.
— Mise en place d’un mécanisme de retour au service qui permet aux nœuds défaillants de rejoindre
automatiquement le cluster lorsque l’exception est gérée sans l’intervention de l’administrateur.
Après avoir résolu les différents défis de conception, On peux maintenant présenter l’organisation des
deux exécuteurs, les figures 3.2 et 3.3 illustrent respectivement chaque exécuteur.
Figure 3.2 – L’Organisation de l’Exécuteur Local
La figure 3.2 décrit l’organisation de l’exécuteur local, où un stockage local persistant (base de
données embarquée) est installé sur l’exécuteur local, ce stockage permettra au système de fonctionner
indépendamment du nœud de stockage et assurera la disponibilité du système si le nœud de stockage
échouait, de plus le diagramme montre l’organisation du "work-directory" du job qui contient ses dif-
férentes dépendances, le "work-directory" est accessible par les job-steps qui s’exécutent à l’intérieur
des conteneurs.
Figure 3.3 – L’Organisation de l’Exécuteur de Cluster
La figure 3.3 illustre l’organisation de l’exécuteur du cluster. Les "job-steps" sont exécutées dans
les nœuds de calcul, chacun à l’intérieur de son conteneur approprié. Les "work-directories" sont
exportées via un SGFD dans le nœud de stockage. Le stockage persistant utilisé est un SGBD haute
performance.
3.4 Couche Middleware

Dans la section précédente on a définie les deux mode de la couche d’exécution d’un point de vue
architecturale. Dans cet section, on va présenter un modal utilisant le langage de modélisation UML pour
définir les composants logiques chargés de gérer et d’exploiter la couche d’exécution, le middleware est la
couche intermédiaire entre l’utilisateur et la couche d’exécution.
Style de conception du middleware : Pour qu’on s’assure que le résultat final respectera l’objectif, on
va suivre un style de conception logicielle axé sur les cas d’utilisation. Les cas d’utilisation seront utilisés
comme artefact principal pour établir et tester le comportement souhaité du système.
3.4.1 Analyse des besoins
La première étape de l’analyse des exigences fonctionnelles d’un système consiste à identifier les
différents acteurs. Un acteur est défini selon le UML-User-Guide [50] comme un type particulier de classe
associée à un cas d’utilisation. Il représente généralement un rôle qu’un humain, un périphérique ou un autre
composant joue à l’intérieur du système.
Dans ce projet, la plateforme est destinée à être utilisée par des chercheurs en bioinformatique, qui sont le seul
type d’acteurs dans le système. Cet acteur est censé être quelqu’un qui connaît les langages de programmation
tels que Python, R, Matlab, bash, etc. De plus, le nombre maximum d’utilisateurs est contrôlé (1 à 10).
Pour encapsuler les différentes fonctionnalités qui doivent être fournies par la plateforme,on va utiliser
le diagramme de cas d’utilisation représenter par la figure 3.4. Le diagramme de cas d’utilisation détaillé
est dans l’annexe A.1.
Figure 3.4 – Diagramme de Cas d’utilisation Simplifier
3.4.2 Description des cas d’utilisation
Authentification
Ce cas d’utilisation fournit une interface pour la connexion et la déconnexion avec des sessions chro-
nométrées. Cela signifie que si un utilisateur est inactif pendant une période de temps définie, il sera
automatiquement déconnecté. Le mécanisme de connexion par "passphrase" sera utilisé pour authentifier
les utilisateurs. Les passphrases sont définies par l’administrateur, et chaque utilisateur est autorisé à utiliser
une seule passphrase. Ce mécanisme est suffisant en raison du nombre limité d’utilisateurs et de la nature
des utilisateurs (chercheurs de laboratoire professionnels). Par conséquent, un sous-système de surveillance
et de profilage des utilisateurs n’est pas requis.
Gestion des Workflows
Ce cas d’utilisation permet à l’utilisateur de :
1. Créez un workflow à partir de fichiers prédéfinis ou de nouveaux fichiers via un éditeur simple.
2. Supprimez un workflow s’il n’est pas utilisé.
3. Affichez les workflows existants et les inspectez.
4. Télécharger les fichiers d’un workflow.
La modification du workflow n’est pas autorisée directement, si un utilisateur souhaite modifier un workflow,
il doit le faire indirectement, ce qui signifie :
1. Téléchargez le workflow.
2. Modifier le workflow.
3. Uploader le nouveau workflow sous un nouveau id.
Cette décision de conception a été prise pour réduire les incohérences, simplifier l’implémentation et éviter
le problème de "dangling reference" (un workflow est modifié alors que ses jobs sont en cours d’exécution).
Gestion Des Jobs
Ce cas d’utilisation garantit les fonctionnalités suivantes
1. Créez un Job et l’exécutez.
2. Arrêter un job en cours d’exécution.
3. Inspectez un job (affichez les différentes informations d’un job).
4. La suppression d’un job peut être effectuée s’il a terminé.
5. Télécharger les inputs et les outputs d’un job.
6. Surveiller l’exécutions des jobs (voir les ressource utilisée et le temps d’exécution, les job-steps, le
log d’un job, stdout, stderr ...)
Gestion des Conteneurs
Ce cas d’utilisation permet à l’utilisateur de télécharger une image local qui packager les différents outils
utilisés dans le workflow, en outre, il permet à l’utilisateur de télécharger les conteneurs à partir de repository
publics. La gestion individuelle des conteneurs n’est pas requise pour les raisons suivantes :
1. Complexité supplémentaire pour l’utilisateur final.
2. La gestion individuelle des conteneurs peut entraîner des incohérences dans le système, en particulier
pour l’exécuteur du cluster (deux nœuds de calcul avec une configuration de conteneurs différente).
3. Gaspillage d’espace de stockage lors de l’enregistrement de chaque image individuelle.
Pour résoudre ces limitations, on propose deux solutions
1. La gestion des conteneurs n’est autorisée que via l’interface de ligne de commande pour l’adminis-
trateur du cluster.
2. Un mécanisme de nettoyage global pour supprimer tous les conteneurs des différents nœuds, ce qui
assure la cohérence le long des nœuds de calcul pour que tous les nœuds de calcul ont les mêmes
conteneurs.
Pour garantir la sécurité de la gestion des conteneurs, les téléchargements de image et le nettoyage -
suppression- des image sont contrôlés, ce qui signifie que ces opérations peuvent être autorisées ou bloquées.
La Surveillance de l’état du système
Ce cas d’utilisation permettra à l’utilisateur de surveiller l’état du système. L’objectif est de détecter les
erreurs et les exceptions, puis informer l’administrateur afin qu’il puisse résoudre ces problèmes. De plus,
grâce aux logs, l’utilisateur peut obtenir des informations sur l’exécution de certaines opérations, telles que
le chargement du conteneur, l’exécution des workflows, ...
3.4.3 Conception Structurelle
Après avoir défini les cas d’utilisation du système, on procède à la conception structurelle. Dans cette
partie, on veux définir les différentes classes dans le middleware, leurs propriétés et les relations entre elles,
on va utiliser le diagramme de classes du langage UML pour visualiser ces composants.
La figure 3.5 illustre les classes de middleware et les relations entre elles.
Figure 3.5 – Diagramme de Classes

Classe Type Responsabilités

WDTYPE Enumeration Class spécifiez le type de dépendance du workflow
WorkflowDependency Persistent Class encapsuler les données sur une dépendance du work-
flow
Workflow Persistent Class encapsuler les données de workflow
JobStateEnum Enumeration Class spécifier les états possibles d’un job
Job Dependency Persistent Class encapsuler les données sur une dépendance de job
JDType Enumeration Class spécifiez le type de dépendance d’un job
User Abstract Class Chargez les passphrases autorisées, Créez et effacez
des sessions
Job Persistent Class encapsuler les informations de job
Container Concrete Class encapsuler des informations sur le conteneur (tag, don-
nées)
Charger le conteneur à partir d’un fichier local ou d’un
dépot public
ContainerHandler Abstract Class
Exécute l’opération "suppression de tous les conte-
neurs"
LogHandler Abstract Class Créer et gérer les logs
JobListener Abstrcat Class écoutez la soumissions d’un job, lancer les jobs non
terminés au démarrage, Mettez en file d’attente un
nouveau job,Arrêter un job
JobHandler Concrete Class Gérer l’exécution d’un job, récupérer ses sorties, en-
voyer un signal d’arrêt au processus exécutant le job,
enregistrer les résultats dans la base de données, suivre
le temps d’exécution
ServerMonitor Abstract Class Cette classe est responsable de surveiller l’état du ser-
veur (CPU, MÉMOIRE, ... )
Table 3.1 – Types de classes et leurs Responsabilités
Type des classes
— Classe d’Énumération (Enumeration Class) : Une classe qui a un nombre finie de valeur possible.
— Classe Persistante (Persistent Class) : Une classe où ses attributs sont enregistrés dans une base de
données.
— Classe Abstraite (Abstract Class) : Aucun objet ne peut être instancié à partir de cette classe, ce
type de classes peut être utilisé pour encapsuler la logique.
— Classe Concrète (Concrete Class) : Classe qui a défini un blueprint pour la création d’objets, c’est
le rôle principale d’une classe.
3.4.4 Exploration des fonctionnalités du Middleware
Dans cette section, on explore deux cas d’utilisation majeurs du système, la gestion des jobs et la gestion
des conteneurs. on va utilisé l’organigramme pour simplifier la description du processus.
Exécuter/Arrêter un Job
La figure 3.6 représente deux organigrammes : le premier décrit les différentes étapes d’exécution
d’un job, et le deuxième décrit l’opération d’arrêt d’un job.
Figure 3.6 – Organigramme "Exécuter/Arrêter un Job"

Chargement des conteneurs
La figure 3.7 représente un organigramme qui décrit les différentes étapes à exécuter pour charger
un conteneur local/public sur l’exécuteur (local ou cluster).
Figure 3.7 – Organigramme "Charger un conteneur local/public"

Suppression de Conteneurs
la figure 3.8 représente un organigramme qui décrit les différentes étapes à exécuter pour effectuer
une suppression global des conteneurs sur l’exécuteur. On considère que l’opération de suppression
de conteneur est autorisée par l’administration.
Figure 3.8 – Organigramme "Suppression des conteneurs"

3.5 User Layer (Couche Utilisateur)

La couche utilisateur constitue l’interface principale entre le système et ses utilisateurs finaux. Elle
joue un rôle crucial dans l’expérience utilisateur globale en fournissant une interface conviviale et intuitive
pour interagir avec le système. Cette couche est composée de deux parties essentielles, l’architecture de
l’application web et la conception de l’interface utilisateur (UI). Dans cette section, on explore ces deux
aspects fondamentaux.
3.5.1 Architecture du site Web
D’un point de vue architectural, l’application web adopte l’architecture MVC, un modèle de conception
largement reconnu qui fournit une approche structurée pour la création d’applications web scalable et main-
tenables. Dans cette architecture, la logique d’application est divisée en trois composants interconnectés :
— Le Modèle : responsable de la gestion des données (validation, prétraitement, correction,....)
— Les Vues : responsable de la présentation des éléments de l’interface à l’utilisateur via des langages
de markup et des templates.
— Le Contrôleur : c’est un intermédiaire entre le Modèle et les Vues, il est responsable du routage à
l’intérieur du application web.
En adoptant l’architecture MVC, la plateforme assure une séparation claire des préoccupations, facilitant
le développement modulaire, la réutilisation du code et une maintenance plus facile.
Figure 3.9 – Architecture MVC [2]
3.5.2 Conception de l’interface utilisateur
Dans la conception des applications web, l’interface utilisateur (UI) joue un rôle crucial en tant que pas-
serelle vers les fonctionnalités d’application web. La figure 3.10 représente un diagramme de navigation
qui regroupe les principaux pages dans l’application web.
Figure 3.10 – Digramme de navigation

3.6 Conclusion
Dans ce chapitre, on a exposé l’architecture globale du système, en définissant la couche d’exécution
et ses modes (exécuteur local, exécuteur de cluster). On a également examiné les défis de conception, en
proposant des solutions correspondantes pour chacun d’eux. En outre, on a procédé à la définition de la
couche middleware et ses composants, en mettant particulièrement l’accent sur la synchronisation via les
locks et les sémaphores. En guise de conclusion, on a introduit l’architecture MVC comme le principal style
architectural utilisé pour concevoir l’application web, en plus, on a présenté l’interface utilisateur à travers
le diagramme de navigation. Dans le chapitre suivant, on va entamer la phase d’implémentation
Chapitre 4
Implémentation de plateforme
4.1 Introduction
Dans le chapitre d’implémentation, on présente en premier lieu les technologies utilisées pour construire
les différentes couches du système. Ensuite, on décrit la configuration du cluster virtuel, où on a utilisé
la technologie de virtualisation pour simuler un cluster. On conclut le chapitre en présentant des captures
d’écran de la solution finale.
4.2 Environnement de développement

Cette section contient les outils et les technologies utilisées dans le développement de la plateforme. On
a englobé tous les aspects du processus de développement, y compris l’environnement de développement,
les outils de modélisation, l’éditeur de code, le système d’exploitation, etc.
4.2.1 Système D’Exploitation
UBUNTU SERVER (20.04 LTS)
C’est une distribution Linux populaire pour les serveurs, dérivée du système d’exploitation Ubuntu. Elle
est open source, fiable et bénéficie d’une documentation complète qui simplifie les tâches d’administration
et de configuration. On a choisi d’utiliser la version minimale pour réduire l’empreinte du système d’ex-
ploitation et pour assurer que toutes les ressources sont principalement utilisées pour l’exécution des jobs
[51].
FEDORA 40
Fedora est un autre système d’exploitation Linux open source populaire, développé par Red-Hat en
2003. Il est conçu comme un système d’exploitation sécurisé à usage général. On a principalement choisi ce
système d’exploitation pour ses outils de développement polyvalents qui sont facilement accessibles grâce
au gestionnaire de paquets DNF [52].
52
CHAPITRE 4. IMPLÉMENTATION DE PLATEFORME
4.2.2 Éditeurs et Outils de Modélisation
VsCode
Visual Studio Code est un éditeur de code source léger et puissant développé par Microsoft en 2015.
Il est disponible pour Windows, Linux, mac-OS et prend en charge de nombreuses fonctionnalités utiles
telles que le débogage, la coloration syntaxique, la complétion intelligente de code, des extraits de code, la
re-factorisation de code et de nombreuses autres fonctionnalités, la raison la plus importante pour choisir
VsCode était son intégration transparente avec git et GitHub [53].
Graphor
Graphor est une application de modélisation UML et SysML écrite en Python. Cet outil, à la fois
puissant et simple d’utilisation, aide les développeurs à créer des graphiques et des représentations visuelles
de données pour décrire les différents aspects d’un système. Il est libre d’utilisation et permet d’exporter
vers différents formats de fichiers tels que XML, SVG, PDF, PNG [54].
JusInMind
Il s’agit d’une plateforme de conception UI/UX tout-en-un, pour la création d’interface utilisateur, de
prototypes et de simulations pour les applications web et mobiles. Cette plateforme propose une version
gratuite et est particulièrement bien adaptée au prototypage [55].
Draw.io
Une application Web gratuite pour dessiner différents types de diagrammes, c’est le principal outil utilisé
dans ce projet pour créer des diagrammes [56].
4.3 Les Technologies Front-end
4.3.1 HTML/ CSS / JavaScript
Le trio HTML, CSS et JavaScript sont les technologies dominantes pour la création de pages Web,
HTML est utilisé principalement pour définir la structure de la page Web où CSS peut être appliqué pour
ajouter un style et une animation supplémentaires, en plus JavaScript est utilisé pour rendre les sites Web
réactifs et dynamiques, voici quelques bibliothèques de JavaScript importantes utilisées dans ce projet :
— PrismJs : une bibliothèque légère pour styliser et mettre en évidence le code [57].
— Ace : une bibliothèque JavaScript pour créer des éditeurs de code riches en fonctionnalités et person-
nalisables [58].
— ZipJs : une bibliothèque pour la compression et la décompression de fichiers zip dans le navigateur
[59].
— ChartJs : une bibliothèque puissante pour créer des graphiques interactifs et visuellement attrayants
[60].
— Toastr : une bibliothèque légère pour afficher les boîtes de notification [61].
— SweetAlert2 : une bibliothèque pour afficher les boîtes de confirmation [62].
4.3.2 Bootstrap 5
C’est l’un des frameworks CSS et les projets open source les plus populaires au monde. Il a été créé par
Twitter en 2010. Il est utilisé pour construire et concevoir des sites web réactifs et dynamiques. Bootstrap
utilise des classes prédéfinies pour styliser les composants d’un site web, une approche qui privilégie le
développement rapide d’applications RAD, crucial pour les projets à temps limité [63].
4.4 Les Technologies de Back-End
Python 3.12
C’est un langage de programmation de haut niveau, polyvalent et puissant. La syntaxe simple et élégante
de Python, combinée à son typage dynamique et à sa nature interprétée, en fait un langage idéal pour les
scripts et le développement rapide d’applications dans de nombreux domaines [64]. Ce langage a été choisi
pour les raisons suivantes :
— Simple et facile à utiliser.
— Énorme communauté avec beaucoup de bibliothèques et de frameworks documentés et bien testés.
— La nouvelle version 3.12 offre de grandes améliorations en termes de vitesse et de nouvelles fonction-
nalités.
Remarque : le typage dynamique dans python peut devenir un problème majeur lorsque la taille et la
complexité du projet augmentent, pour résoudre ce problème, on propose l’utilisation de vérificateurs de
types statiques (static-type-checker) et de linters.
Flask
Flask est un micro-framework léger pour les applications web en Python. Il est conçu pour privilégier
la simplicité et l’efficacité, avec une architecture extensible grâce à des plugins. Flask prend en charge le
rendu des pages web (dynamic-page-rendering) grâce au moteur de templates Jinja2 [65], ce qui en fait une
option idéale pour implémenter l’architecture MVC [66].
SQLAlchemy
SQLAlchemy est une couche d’abstraction de base de données et un Object Relational Mapper (ORM)
qui nécessite peu ou pas de configuration pour être utilisé, et il s’intègre facilement avec Flask via le
plugin flask_sqlalchemy [67]. Cet ORM traduit les classes en tables relationnelles avec prise en charge des
instructions SELECT, INSERT, UPDATE et DELETE sans nécessiter d’écrire de SQL. Il est compatible
avec plusieurs SGBD! (SGBD!) tels que MySQL, MariaDB, PostgreSQL, SQLite, ce qui est crucial pour
assurer la portabilité de la base de données [68].
Nextflow
Nextflow a été choisi pour les raisons suivantes :
— Grande communauté et matériel d’apprentissage gratuit (documentation officielle, documentation

nf-core, tutoriels nf-core, etc.).
— Syntaxe similaire aux langages de programmation JAVA - car Groovy est un super-set de JAVA -, ce
qui a facilité la familiarisation avec l’outil.
— Une intégration transparente avec Docker et Slurm.
— Support d’outils pour le monitoring et le profiling.
4.4.1 Technologies de Cluster
Slurm (Simple Linux Utility for Resource Management)
Slurm est un système de gestion de la charge de travail et un scheduleur open source, tolérant aux
pannes et hautement scalable, il est utilisé pour la planification des tâches et la gestion des ressources sur
les clusters HPC, Slurm est un logiciel mature et largement utilisé, en plus il a un grand nombre de plugins
pour personnaliser le cluster pour différents besoins (efficacité énergétique, débit élevé, sécurité, ...) [37].
4.4.2 Technologies de virtualisation
VirtualBox
VirtualBox est un hyperviseur de type 2, gratuit et open source, ainsi qu’une application multi-plateforme
développée par Oracle. Il permet aux utilisateurs d’héberger plusieurs systèmes d’exploitation sur différents
systèmes hôtes tels que macOS, Windows, Linux ou Oracle Solaris. Il exploite également plusieurs interfaces
de para-virtualisation pour fournir des performances optimales sur différents systèmes d’exploitation hôtes.
VirtualBox sera principalement utilisé pour les tests et le développement [19].
Docker
Docker est une plateforme ouverte pour le développement, le déploiement et l’exécution d’applications
dans des conteneurs. Elle permet aux développeurs de séparer les applications de l’infrastructure, facilitant
ainsi une livraison rapide du logiciel [24]. Docker sera utilisé pour déployer des outils bioinformatiques,
évitant ainsi le besoin d’installer ces outils sur chaque nœud de cluster. Docker a été choisi pour les raisons
suivantes :
— Expérience préalable avec l’outil.
— Les chercheurs en bioinformatique à l’IPA sont familiers avec Docker.
— Soutenu par de grandes entreprises, ce qui assure sa stabilité et sa longévité.
4.4.3 Authentification et Synchronisation
L’authentification et la synchronisation jouent un rôle majeur dans le cluster. Pour permettre la soumission
de workflow sur plusieurs nœuds, le nœud de contrôle doit identifier chaque nœud et surveiller son état, la
partie suivante présentera les outils et technologies utilisés pour assurer l’authentification des noeuds dans
le cluster et sécuriser la connexion entre les nœuds.
SSH
SSH (Secure Shell) est un protocole cryptographique permettant une communication sécurisée sur les
réseaux. Il chiffre les connexions, assurant ainsi la confidentialité et l’intégrité des données. Utilisé de
manière étendue pour l’accès à distance et les transferts de fichiers, SSH intègre des mécanismes de sécurité
robustes tels que l’authentification par clé. Sa polyvalence et sa sécurité en font un outil essentiel pour
l’administration et la gestion de cluster [69].
MUNGE
MUNGE (MUNGE Uid ’ N ’ Gid Emporium) est un service d’authentification permettant de générer et
de valider des informations d’identification. Il fournit une gestion sécurisée des identités des utilisateurs et
des groupes dans des environnements informatiques distribués. MUNGE génère des informations d’identi-
fication uniques, appelées "creds" pour authentifier les utilisateurs et les processus, garantissant une sécurité
robuste. Son rôle est vital pour protéger la communication et le contrôle d’accès dans les clusters HPC [70].
NTP (Le Network Time Protocol)
NTP synchronise les horloges sur un réseau, assurant ainsi une référence temporelle uniforme. Il repose
sur une structure hiérarchique, avec des serveurs de référence de haute précision (horloge atomique) au
sommet, répartis dans le monde. La fiabilité et la sécurité de NTP en font un élément vital pour les
protocoles de sécurité [71].
4.4.4 Stockage
Dans la plateforme, il existe deux types d’espaces de stockage, le stockage persistant utilisé pour
enregistrer les entrés et les sorties des jobs, les dépendances de workflow ..., en plus un espace de stockage
temporaire partageable utilisé pendant l’exécution des jobs.
Stockage Persistant
MySQL : MySQL est un système de gestion de base de données relationnelle (SGBDR) open source
populaire, reconnu pour son efficacité et sa scalabilité. Il utilise le langage SQL pour définir, manipuler et
interroger la base de données. Grâce à sa fiabilité et à ses fonctionnalités étendues, MySQL est largement
utilisé dans diverses applications, allant des petits sites Web aux grandes entreprises [72].
SQLite : est un moteur de base de données SQL léger, autonome, sans serveur. Il est intégré directement
dans l’application, ce qui facilite son déploiement et sa gestion. Les bases de données SQLite sont stockées
sous forme de fichiers, ce qui les rend portables et adaptées aux applications de petite à moyenne taille. Il
prend en charge la syntaxe SQL standard et est largement utilisé dans les applications mobiles, les desktop-
apps et les systèmes embarqués [73].
Remarque : MySQL sera l’espace de stockage principal du cluster où SQLITE fonctionnera en mode
exécuteur local, le but est d’assurer la fiabilité et de fournir différentes configurations possibles.
Stockage Temporaire
NFS (Network File System) : NFS est un système de gestion de fichiers distribué permettant l’accès à
distance aux fichiers sur un réseau. Il facilite le partage et l’accès transparent des fichiers entre plusieurs sys-
tèmes au sein d’un réseau. NFS met en œuvre un mécanisme de partage au niveau des fichiers et supporte des
mécanismes de verrouillage et de synchronisation pour garantir la cohérence des accès aux fichiers partagés.
On a choisi de l’intégrer dans notre solution en raison de sa popularité et de sa documentation complète [74].
La figure 4.1 illustre la disposition des différentes technologies le long des différentes couches du
système.
Figure 4.1 – La Pile Logicielle

4.5 Configuration du Cluster Virtuel

Cette section concerne la configuration du cluster virtuel qui est l’environnement principal pour les tests
et le développement, on va utilisé VirtualBox pour créer les nœuds du cluster et les interconnecter via un
réseau virtuel.
4.5.1 Configuration du Réseau
On commence par configurer un réseau NAT virtuel qui assure la connexion entre les nœuds et la
connexion au web. La figure 4.2 illustre la configuration réseau du cluster virtuel [75] .
Figure 4.2 – Configuration du Réseau Virtuel
Configuration du pare-feu
Un pare-feu est un périphérique ou un logiciel de sécurité réseau qui surveille et contrôle le trafic réseau
entrant et sortant en fonction de règles de sécurité prédéfinies, on va utiliser un pare-feu logiciel intégré au
système d’exploitation Ubuntu appelé UFW [76].
Le tableau suivant illustre les services du cluster et leurs ports appropriés, il est important de permettre
la communication sur ces ports pour assurer la bonne exécution des différents services.
Le Service Port(s)/Protocole
SSH 22/tcp
2049/tcp, 2049/udp, 111/tcp, 111/udp,4045/tcp,
NFS
4045/udp, 4046/tcp, 4046/udp
Slurm 6817/tcp, 6818/tcp
NTP 123/udp
MySQL 3306/tcp
Table 4.1 – Ports autorisés par le pare-feu
4.5.2 Configuration de l’authentification et de la Synchronisation temporelle
Configuration du SSH
Les nœuds doivent être configurés de manière à ce que le nœud de contrôle puisse se connecter via SSH
à tous les autres nœuds sans mot de passe, grâce à l’utilisation des clés rsa, la connexion SSH est cruciale
pour le bon fonctionnement du Slurm.
Étapes de configuration :
1. Installation du serveur SSH sur les nœuds de calcule, les nœuds de stockage et de le nœud de
soumission.
2. Installez le client SSH sur les nœuds de contrôle.
3. Sur les nœuds de contrôles, générez une clé rsa et copiez-la sur tous les nœuds de calcul,de stockage
et de soumission.
Configuration de l’authentification via la clé MUNGE
MUNGE utilise des clés spéciales appelées "creds" pour authentifier les différents nœuds du cluster, le
contrôleur génère une clé unique et la partage avec tous les autres nœuds du cluster. De plus, le service
MUNGE doit être activé pour qu’il puisse s’exécuter au démarrage de système en arrière-plan.
Synchronisation des clocks
L’implémentation du protocole de synchronisation NTP établit non seulement une référence temporelle
cohérente, mais répond également aux problèmes d’authentification, garantissant l’ordre précis des données
reçues sur différents nœuds. De plus, divers services d’authentification, y compris MUNGE, reposent sur
une référence temporelle fixe lors des processus de réauthentification périodiques.
4.5.3 Configuration du Slurm
Slurm est configuré dans quatre modes différents :
1. Mode "control" : lors de l’exécution sur des machines destinées à être utilisées comme contrôleur.
2. Mode "backup" : lors de l’exécution sur des machines destinées à être utilisées comme contrôleur
secondaire.
3. Mode "compute" : lors de l’exécution sur une machine utilisée pour exécuter des jobs.
4. Mode "submit" : lors de l’exécution sur une machine utilisée uniquement pour soumettre les jobs.
Lorsque tous les nœuds sont configurés, un fichier de configuration global doit être partagé entre tous
les nœuds du cluster, ce fichier de configuration est utilisé par tous les nœuds pour :
1. Spécifiez les responsabilités de chaque nœud.
2. Définir des mécanismes de tolérance aux pannes.
3. Définissez l’algorithme de planification.
4. Définir les partitions du cluster (facultatif).
4.5.4 Configuration du Stockage
Il existe deux technologies utilisées pour stocker les données dans le nœud de stockage :
le NFS, utilisé pour les fichiers temporaires créés lors de l’exécution des jobs, et MySQL utilisé pour stocker
les données persistantes. De plus, le serveur contient une base de données intégrée SQLite utilisée dans le
mode d’exécution local.
Configuration d’NFS
NFS est installé en deux modes :
— Mode client : utilisé pour accéder aux entrées exportées (installé sur les nœuds de calcul, de contrôle
et de soumission).
— Mode serveur : utilisé pour exporter un chemin local vers des machines distantes (installé sur le nœud
de stockage).
Dans cette configuration, on utilise le NFS v.4 qui offre des performances optimisées grâce à les raisons
suivantes :
1. NFS v.4 réduit le nombre de RPC qui diminuent la latence.
2. Il maintient un état de session entre le client et le serveur, ce qui réduit le nombre de ré-authentifications
nécessaires.
4.6 Présentation de la Plateforme

Dans cette partie, on va présenter un aperçu global de la plateforme développée à travers le diagramme
de navigation concret.
Figure 4.3 – Diagramme de Navigation Concret

4.7 Conclusion
Dans ce chapitre, on a passé en revue les différentes technologies utilisées pour développer la plateforme,
tant du côté frontend que backend. On a également présenté les technologies utilisées pour configurer le
cluster. Ensuite, on a brièvement décrit les étapes de configuration. Enfin, on a illustré l’interface finale de
la plateforme à travers un diagramme de navigation concret.
Chapitre 5
Évaluation & Discussion
5.1 Introduction
Dans ce chapitre, on va tester et expérimenter sur le système. Tout d’abord, on définit le cas de test -l’arbre
phylogénétique- ainsi que son implémentation, les métriques d’évaluation et la configuration matérielle
utilisée. On finalise le chapitre en discutant et évaluant les résultats obtenus.
5.2 Construction de l’Arbre Phylogénétique

Un arbre phylogénétique est une représentation schématique des relations évolutives entre un groupe
d’organismes. Il montre comment différentes espèces ou groupes d’organismes sont liés les uns aux autres par
une ascendance commune, sur la base de similitudes et de différences dans leurs caractéristiques génétiques
ou morphologiques. Les espèces étroitement apparentées partagent un ancêtre commun plus récent et auront
des branches plus rapprochées, tandis que celles qui sont plus éloignées auront des branches plus éloignées.
La structure d’un arbre phylogénétique est souvent hiérarchique, les branches se divisant en branches plus
petites représentant des divergences évolutives successives. Le point de division des branches représente un
ancêtre commun partagé par les espèces ou les groupes qui suivent [77].
Dans ce cas de test, on va définir le workflow et le déployer sur la plateforme. Ce workflow créera un
diagramme d’arbre phylogénétique en utilisant les "housekeeping genes" comme métrique de similitude
entre les différentes espèces. Les "housekeeping genes" sont des gènes essentiels exprimés dans toutes les
cellules, cruciaux pour les fonctions cellulaires de base. Ils fournissent des références stables dans les études
d’expression génique, facilitant la comparaison entre différentes espèces [78].
La figure 5.1 représente le diagramme d’arbre phylogénétique de cinq espèces fictives, où des branches
plus proches indiquent une plus grande similitude entre les espèces.
65
CHAPITRE 5. ÉVALUATION & DISCUSSION
Figure 5.1 – Exemple d’arbre phylogénétique
5.3 Conception du workflow

Le workflow "création d’arbre phylogénétique" peut être considéré comme une fonction qui prend
2 entrées H et F où H représente les housekeeping genes sélectionnés et F les fichiers (|𝐹 | > 2) qui
représente la matière génétique, le workflow générera à la fin un fichier qui représente un diagramme d’arbre
phylogénétique, le diagramme 5.2 illustre la structure du workflow.
Figure 5.2 – Le workflow "Création d’Arbre Phylogénétique"
Pour une description plus détaillés des étape, considérer le tableau A.1 dans l’annexe A.
5.4 Protocole de test

Les tests seront effectués sur des configurations différentes où on va varier à la fois la taille de l’entrée
et le nombre d’unités de calcul. On va exécuter les différentes combinaisons de tailles d’entrée sur une
seule unité de calcul, représentant ainsi une exécution séquentielle pure sans parallélisme, afin d’obtenir une
référence de comparaison.
5.4.1 Données de Test
Pour garantir l’intégrité des données de test, on a sélectionné des fichiers de données préalablement
nettoyés provenant de la plateforme NCBI [79]. Le NCBI, acronyme de National Center for Biotechnology
Information, est une ressource librement accessible hébergée par l’Institut National de la Santé des États-
Unis (NIH). Cette plateforme est une référence majeure dans le domaine de la biologie et de la génétique,
offrant un accès à une vaste gamme d’informations biologiques, génétiques et médicales. En tant que
ressource centrale, le NCBI joue un rôle essentiel dans la recherche et la diffusion des connaissances dans
ces domaines, contribuant ainsi à l’avancement de la science et de la médecine.
Les données de test sont représentées sous forme de fichiers FASTA, qui sont des fichiers texte utilisés
pour stocker des séquences génétiques. Chaque entrée commence par une ligne d’en-tête débutant par ">",
suivie du nom ou de la description de la séquence. On a accès à 31 fichiers FASTA différents représentant
le matériel génétique bactérien, avec des tailles allant de 2,3 Mo à 4,5 Mo.
5.4.2 Matérielle Du Test
Après avoir défini le workflow de test, on va procéder à la spécification du matériel utilisé.
APPAREIL CPU MÉMOIRE STOCKAGE RÔLE

Desktop PC Rayzen 3400G 8 16GB 1TB HDD, Control-Node
Cores 4.2(Ghz) 160GB HDD, Submit-Node
256GB SSD Storage-Node
Compute-Node
Dell Laptop Intel i3 4 Cores 8GB 256GB SSD Compute-Node
4.1(GHz)
HP Laptop Intel i5 8 Cores 8GB 1TB HDD, Compute-Node
3.9(Ghz) 256GB SSD
Table 5.1 – Matérielle de Test
En raison de contraintes de ressources matérielles et dans le but d’optimiser les performances, on a choisi
de configurer tous les nœuds comme des nœuds de calcul, en plus de leurs rôles spécifiques. Cependant, dans
un déploiement pratique, il est fortement recommandé d’assigner à chaque machine une seule responsabilité
pour une meilleure gestion des ressources. En ce qui concerne l’infrastructure réseau, on a opté pour
l’utilisation d’un commutateur D-Link avec une interconnexion Fast-Ethernet.
D’autres facteurs tels que le cache de CPU, le système de refroidissement, le model et la génération de
processeur, la fréquence de la mémoire et d’autres éléments jouent un rôle crucial dans les performances
globales du système.
5.4.3 Les Objectives de Test
— Tester l’utilisabilité de la plateforme.
— Évaluer les performances de la plateforme.
5.5 Évaluation
5.5.1 Métrique d’évaluation
Afin d’obtenir une interprétation solide des résultats, on va utiliser les mesures de performance suivantes
[80].
Speed-up : L’accélération d’un algorithme parallèle par rapport à un algorithme séquentiel correspondant
est le rapport entre le temps de calcul de l’algorithme séquentiel et le temps de l’algorithme parallèle. Si le
facteur d’accélération est égal à 𝑛, on dit qu’on a une accélération de 𝑛-folds.
Speed-up = 𝑇𝑠 /𝑇𝑝
Efficacité : L’efficacité d’un système parallèle est définie comme l’accélération divisée par le nombre
d’unités de calcule, une faible efficacité indique une mauvaise utilisation des ressources.
Efficiency = Speed-up/𝑝
Notez que l’efficacité suppose une contribution uniforme de toutes les unités de calcul au speed-up,
ce qui n’est généralement pas le cas dans les tests réels.
5.5.2 Estimation de la partie purement séquentielle et la partie parallélisable du

workflow
Théoriquement, lors de l’évaluation de l’exécution parallèle d’un algorithme, il est nécessaire de calculer
précisément la partie séquentielle et la partie parallèle de celui-ci. Cependant, dans le cas du workflow actuel,
l’implémentation de certains outils tels que prokkaa [81] et mafft [82] ne peut pas être déduite avec certitude.
On propose donc d’adopter une approche expérimentale où on calcule l’exécution séquentielle du
workflow sur une seule unité de calcul en minimisant tout type de parallélisation. En fonction du temps
d’exécution séquentiel, on peut alors estimer les pourcentages de la partie purement séquentielle et de la
partie parallélisable du workflow en utilisant les relations suivantes.
Total Time = Sequential Time + Parallelzible Time

Sequential Time ∗ 100

Sequential portion =
Total Time
Parallelzible portion = 100 − Sequential portion
Application Numerique :
Partie parallélisable
Pourcentage de la
Temps total d’exécution du (Annotation + Extraction + Ali-
partie parallélisable
workflow gnement)
800s 768s 96%

792s 762s 96.21%
799s 768s 96.12%
Table 5.2 – Les Temps D’Exécutions Séquentielles
En se basant sur les valeurs du tableau 5.2, on peut estimer la partie parallélisable et la partie séquentielle
comme suit : 𝑃 𝑝 = 96% et 𝑆 𝑝 = 4%.
Ce résultat montre que le programme est hautement parallélisable, ce qui suggère un potentiel significatif
d’amélioration des performances grâce à l’exécution parallèle.
5.5.3 Estimation de l’accélération théorique
Deux lois les plus utilisées pour estimer l’accélération sont la loi d’Amdal et la loi de Gustafson. Dans
la partie suivante, on énonce les deux lois et en justifiant notre choix.
Loi d’Amdal
La loi d’Amdahl stipule que la vitesse globale d’un calcul parallélisé est limitée par la partie purement
séquentielle qui ne peut pas être parallélisée. Elle résume cette idée à travers l’inégalité suivante :
1
Speed-up ≤ 𝑃
(1 − 𝑃) + 𝑛
Où 𝑃 représente la partie parallélisable du code et 𝑛 représente le nombre d’unités de calcul.
Il est important de noter que l’atteinte de cette accélération maximale théorique peut ne pas être réalisable
en pratique en raison de facteurs tels que le temps de planification des tâches, les coûts de communication
et la surutilisation des ressources.
Loi de Gustafson
La loi de Gustafson est une extension de la loi d’Amdahl qui se concentre sur la scalabilité de la solution
plutôt que sur des problèmes de taille fixe. Alors que la loi d’Amdahl suppose une taille de problème fixe, la
loi de Gustafson suppose que la taille du problème peut augmenter avec le nombre de processeurs, permettant
de paralléliser une partie potentiellement plus grande du programme à mesure que plus de processeurs sont
ajoutés. Elle est donnée par la formule suivante.
Speed-up ≤ 𝑛 + (1 − 𝑛) × 𝑆
Où 𝑛 représente le nombre des unité de calcule et 𝑆 représente la partie purement séquentielle.
Pour visualiser clairement les résultats de la loi de Gustafson, on doit exécuter le workflow avec de grandes
tailles d’inputs et un grand nombre d’unités de calcul (par exemple, pour 20 cœurs, on devrait avoir 200
fichiers en entrée). Cependant, cela n’est pas réalisable dans notre cas en raison des limitations des données
de test disponibles (31 fichiers) et des ressources limitées (une exécution séquentielle de 200 fichiers d’entrée
prendrait des jours). Par conséquent, on a choisi d’utiliser la loi d’Amdahl malgré sa tendance à surestimer
le speed-up potentiel, en particulier pour un algorithme hautement parallélisable (voir figure ??).
Figure 5.3 – la surestimation de la loi d’amdal pour les algorithmes hautements parallèles
La figure 5.3 illustre la surestimation de la loi d’Amdahl pour les algorithmes hautement parallèles. Les
algorithmes hautement parallèles présentent des caractéristiques intéressantes. Selon la loi d’Amdahl, sur
un système à 20 cœurs, un programme avec une portion parallélisable de 95% peut atteindre un speed-up
de 10,25, tandis qu’un programme avec une portion parallélisable de 96% atteindra un speed-up de 11,36,
soit une différence d’environ 1,11. Cependant, il est important de noter que ce speed-up de 11,36 n’est
pas atteignable dans les scénarios réels, en raison de facteurs précédemment discutés (la communication,
l’ordonnancement, l’implémentation concrète, etc).
5.6 Résultats
Nombre de Temps d’exécution séquen- 1 Machine (8 2 Machines (12 3 Machines (20

fichier tielle sans parallélisation (1 cœurs) cœurs) cœurs)
cœur)
2 13m :20s 03m :55s 05m :47s 04m :27s
4 29m :30s 07m :38s 07m :52s 06m :42s
8 58m :37s 14m :11s 12m :22s 09m :32s
16 02h :02m :05s 28m :32s 22m :07s 16m :32s
31 04h :04m :17s 52m :52s 44m :17s 33m :37s
Table 5.3 – Temps d’exécution
Figure 5.4 – Un graphe illustrant le temps d’exécution sur les différentes configurations
La figure 5.4 illustre les temps d’exécution du workflow de l’arbre phylogénétique sur différentes
configurations. On a varié le nombre de fichiers d’entrée et le nombre d’unités de calcul. Comme prévu,
en augmentant le nombre de fichiers, la différence entre le temps d’exécution séquentielle et les temps
d’exécution parallèle devient plus importante. Elle atteint un maximum de 4 heures, 4 minutes et 17
secondes pour 31 fichiers sur une seule unité de calcul. Après la parallélisation sur 20 cœurs, on a obtenu
un temps d’exécution de 33 minutes et 37 secondes, ce qui représente une différence majeure de 3 heures,
30 minutes et 40 secondes. De plus, on a observé que pour de petites tailles d’entrée, des unités de calcul
supplémentaires n’ont pas réduit le temps d’exécution, et parfois l’ont même augmenté (cas de 2 et 4 fichiers).
Cela peut être dû au surcoût de l’ordonnancement qui augmente lorsque le nombre de fichiers d’entrée est
faible, ainsi qu’au temps de communication entre les différentes machines à travers le réseau, qui est bien
plus important que la communication interne via le bus. Dans la prochaine étape, on analysera plus en
profondeur l’accélération expérimentale et on la comparera à l’accélération théorique.
5.6.1 Speed-up (Accélération)
Nombre de fichiers 1 Machine (8 cœurs) 2 Machines (12 cœurs) 3 Machines (20 cœurs)
2 3,4 2,3 2,9
4 3,86 3,75 4,4
8 4,13 4,74 6,14
16 4,27 5,52 7,38
31 4,6 5,51 7,26
Table 5.4 – Le Speed-up des différentes configurations

Figure 5.5 – Le Speed-up réal vs Speed-up théorique
La figure 5.5 illustre à la fois l’accélération expérimentale et l’accélération théorique utilisant la loi
d’Amdahl. On note que pour de petites tailles d’entrée, des cœurs supplémentaires ne jouent pas un rôle
significatif dans l’accélération globale et peuvent même l’influencer négativement. En revanche, pour des
tailles d’entrée plus importantes, l’accélération s’améliore considérablement et atteint un maximum de 7,38
fois pour 16 fichiers sur une configuration de 20 cœurs.
5.6.2 Efficacité
Dans cette section, on vise à évaluer l’efficacité parallèle des différentes configurations afin d’identifier
celle qui est la plus performante.
Figure 5.6 – L’efficacité des différentes configurations
La figure 5.6 illustre l’efficacité des différentes configurations, où l’on constate que la première confi-
guration (8 cœurs sur un seul système) offre une efficacité optimale, ce qui s’explique par les raisons
suivantes :
1. Sur une seule machine, toute la communication se fait à travers le bus plutôt que sur le réseau.
2. Les machines moins efficaces ne deviennent pas un goulot d’étranglement pour l’exécution de work-
flow.
Les résultats précédents sont parfaitement conformes aux attentes, similaires à ceux d’un article de
recherche intitulé Speedup versus efficiency in parallel systems [83], où il est souligné que lorsque l’on met
à disposition des processeurs supplémentaires pour un système logiciel, des augmentations de speedup sont
obtenues au détriment de l’efficacité. Cela peut être aisément expliqué par la formule de l’efficacité, définie
comme le rapport entre le speedup et 𝑛. Selon la loi d’Amdahl, le speedup est limité, alors que 𝑛 ne l’est pas.
Ainsi, lorsque l’on augmente 𝑛, le speedup approche sa valeur maximale, et le quotient du speedup maximal
par 𝑛 tend vers 0. En termes simples, plus on ajoute d’unités de calcul, plus il devient difficile d’utiliser
efficacement ces unités.
5.7 Discussion
Les résultats précédents ont capturé les différents temps d’exécution du workflow de l’arbre phylogé-
nétique sur la plateforme développée. On a exécuté des tests sur 4 configurations différentes (1 cœur, 8
cœurs sur 1 machine, 12 cœurs sur 2 machines et 20 cœurs sur 3 machines) avec différentes tailles d’entrée
(2,4,8,16,31), puis on a calculé le speed-up et l’efficacité du système.
L’approche de parallélisation a permis d’atteindre un bonne speed-up. Pour une taille d’entrée de 31
fichiers et 20 cœurs, l’accélération atteint 7,26 folds, alors que la limite théorique est de 11,36 folds, ce qui
représente une différence de 4,1 folds.
Pour être équitable, on reconnaisse la surestimation de la loi d’Amdahl pour les algorithmes hautement
parallélisables, ce qui est le cas pour le workflow de l’arbre phylogénétique. Cependant, on peux également
présenter les points suivants comme des inconvénients potentiels :
— En raison de l’hétérogénéité des machines, certaines machines se comportent comme un goulot

d’étranglement pour le système, ce qui rend l’évaluation du système difficile et réduise le speed-up.
— L’absence d’un commutateur dédié et haute performance augmente la pénalité de communication.
— L’implémentation actuelle du workflow ne limite pas l’utilisation des ressources en fonction de la

taille des entrées, ce qui augmente le temps d’exécution pour de petites tailles d’entrée. Une solution
possible serait de créer une version modifiée optimisée pour de petites tailles d’entrée.
En ce qui concerne la reproductibilité, les conteneurs Docker ont joué un rôle significatif. Les outils
de bioinformatique tels que prokka [81], mafft [82], FastTree [84], FigTree [85] et Bio-python [86] ont été
packagés et déployés sur les différents nœuds de manière transparente avec un minimum de surcharge. De
plus, grâce à Nextflow, on a bénéficié d’une grande portabilité. Le workflow a été décrit une seule fois et
déployé sur différents environnements d’exécution sans aucune modification.
Chapitre 6
Conclusion Générale
À l’ère actuelle, la demande de plateformes HPC pour le calcul scientifique a atteint son apogée. Re-
connaissant ce besoin, l’IPA, une institution de premier plan dans les études biologiques et médicales en
Algérie, cherche une solution pour améliorer ses capacités de calcul pour les workflows bioinformatiques.
Cette thèse répond à ce besoin en proposant une conception de plateforme complète adaptée aux besoins de
l’institut.
En commençant par une analyse de l’état actuel du PGB où on a évalué la situation et détecté les
lacunes, ainsi que formulé les exigences fonctionnelles, cette thèse présent les bases théoriques des WSs et
des SGWSs, en soulignant l’importance de la virtualisation pour résoudre les problèmes de reproductibilité
et l’utilisation du cluster pour améliorer les performances et la scalabilité. S’appuyant sur ces concepts
théoriques, on a conçu une plateforme basée sur une architecture en couches (couche utilisateur, couche
middleware, couche d’exécution). Cette architecture assure la flexibilité et l’extensibilité de la plateforme,
en plus de prendre en charge 2 modes d’exécution (local et cluster) qui garantissent la disponibilité et la
configurabilité de la plateforme. On a proposé différents mécanismes pour assurer la sécurité, la fiabilité et
le contrôle de la charge du cluster.
La plateforme a été implémentée à l’aide de technologies modernes telles que Nextflow et Docker, en
plus d’un scheduleur mature, fiable et performant -Slurm-. Elle dispose également d’une interface utilisateur
ergonomique construite à l’aide des technologies web.
Grâce à des tests rigoureux en utilisant le workflow "construction d’arbre phylogénétique", sur différentes
configurations (1,8,12,20 cœurs) et tailles d’entrée (2,4,8,16,31), on a validé l’efficacité de la plateforme,
obtenant des résultats impressionnants. Notamment, on a réduit le temps de traitement de 31 fichiers de
04 :04 :17 sur un seul cœur à 00 :33 :37 sur 20 cœurs, démontrant les avantages de notre approche.
Cette plateforme n’est pas sans faille, on suggère les points suivants comme des améliorations possibles :
— Acquérir des machines fixes et stables à utiliser exclusivement pour la plateforme.
— Mettre en place un dépot public sur docker hub pour mieux gérer les conteneurs.
78
CHAPITRE 6. CONCLUSION GÉNÉRALE
— Étendez la plateforme en créant un générateur visuel complet pour le nextflow DSL.
Cette thèse propose une solution pratique pour répondre aux besoins informatiques de l’IPA. Elle offre des
performances améliorées, une meilleure scalabilité, et une fiabilité accrue, tout en présentant une interface
conviviale pour la création, le déploiement et la gestion des workflows bioinformatiques.
Bibliographie
[1] Shishir Bharathi, Ann Chervenak, Ewa Deelman, Gaurang Mehta, Mei-Hui Su, and Karan Vahi.
Characterization of scientific workflows. In 2008 third workshop on workflows in support of large-
scale science, pages 3–4. IEEE, 2008.
[2] Sadika Rahman Tanisha. The mvc architecture. https://medium.com/@sadikarahmantanisha/

the-mvc-architecture-97d47e071eb2, 2024. Accessed : 2024-05-27.
[3] Institut pasteur d’algérie. https://www.pasteur.dz/fr/presentation/historique, 2024. Ac-

cessed : 2024-05-23.
[4] DAHAK Chiraz and YAKOUB Allaaeddine. “hokega” : The housekeeping genes analysis tool. Thèse
de master 2, spécialité : Bioinformatique, Institut Pasteur d’Algérie, 2023/2024. Encadré par : Mr
HEBBACHI Khalil, Mme MEHDI Malika ;.
[5] Claudia Bauzer Medeiros, Gottfried Vossen, and Mathias Weske. Wasa : A workflow-based architecture
to support scientific database applications. In International Conference on Database and Expert
Systems Applications, pages 574–583. Springer, 1995.
[6] Yannis E Ioannidis, Miron Livny, Shivani Gupta, and Nagavamsi Ponnekanti. Zoo : A desktop
experiment management environment. In VLDB, volume 96, pages 274–285, 1996.
[7] Ilkay Altintas, Chad Berkley, Efrat Jaeger, Matthew Jones, Bertram Ludascher, and Steve Mock.
Kepler : an extensible system for design and execution of scientific workflows. In Proceedings. 16th
International Conference on Scientific and Statistical Database Management, 2004. IEEE, 2004.
[8] Ptolemy II. Ptolemy ii. http://ptolemy.eecs.berkeley.edu/ptolemyII/. Accessed : 2024-

05-23.
[9] P Refaeilzadeh, L Tang, and H Liu. In encyclopedia of database systems (eds. ling liu & m. tamer
özsu), 2009.
[10] Jun Qin and Thomas Fahringer. Scientific workflows : programming, optimization, and synthesis with
ASKALON and AWDL. Springer, 2012.
80
BIBLIOGRAPHIE
[11] Chee Sun Liew, Malcolm P Atkinson, Michelle Galea, Tan Fong Ang, Paul Martin, and Jano I Van
Hemert. Scientific workflows : moving across paradigms. ACM Computing Surveys (CSUR), 49(4) :2,
2016.
[12] David Hollingsworth and U Hampshire. Workflow management coalition : The workflow reference
model. Document Number TC00-1003, 19(16), 1995.
[13] Katharina Görlach, Mirko Sonntag, Dimka Karastoyanova, Frank Leymann, and Michael Reiter.
Conventional workflow technology for scientific simulation. Guide to e-Science : Next Generation
Scientific Research and Discovery, pages 7–9, 2011.
[14] Jiri Vojtesek and Martin Pipis. Virtualization of operating system using type-2 hypervisor. In In-
ternational Conference on Information and Communication Technology for Intelligent Systems, pages
239–247. Springer, 2016.
[15] Duarte Pousa and José Rufino. Evaluation of type-1 hypervisors on desktop-class virtualization hosts.
IADIS-JOURNAL ON COMPUTER SCIENCE AND INFORMATION SYSTEMS, 12(2) :86–101, 2017.
[16] Vmware. https://www.vmware.com/. Accessed : 2024-05-27.
[17] Hyper-v on windows. https://learn.microsoft.com/en-us/virtualization/

hyper-v-on-windows/about/. Accessed : 2024-05-27.
[18] Linux kvm. https://linux-kvm.org/page/Main_Page. Accessed : 2024-05-27.
[19] Virtualbox. https://www.virtualbox.org/. Accessed : 2024-05-27.
[20] Naweiluo Zhou, Huan Zhou, and Dennis Hoppe. Containerization for high performance computing
systems : Survey and prospects. IEEE Transactions on Software Engineering, 49(4) :2722–2740, 2022.
[21] Stephen S. et al. Container-based operating system virtualization : A scalable, high-performance

alternative to hypervisors. SIGOPS Oper. Syst. Rev., pages 275–287, 2007.
[22] P. Maenhaut, B. Volckaert, V. Ongenae, et al. Resource management in a containerized cloud : Status
and challenges. J NetwSyst Manage, 28 :197–246, 2020.
[23] Ouafa Bentaleb, Adam SZ Belloum, Abderrazak Sebaa, and Aouaouche El-Maouhab. Containerization
technologies : Taxonomies, applications and challenges. The Journal of Supercomputing, 78(1) :1144–
1181, 2022.
[24] Docker. https://www.docker.com/. Accessed : 2024-05-27.

BIBLIOGRAPHIE
[25] KG Srinivasa and Anil Kumar Muppalla. Guide to high performance distributed computing. Springer,
2015.
[26] Olivier Beaumont, Arnaud Legrand, and Yves Robert. The master-slave paradigm with heterogeneous
processors. IEEE Transactions on Parallel and Distributed Systems, 14(9) :897–908, 2003.
[27] Maarten Van Steen and Andrew S Tanenbaum. Distributed systems. Maarten van Steen Leiden, The
Netherlands, 2017.
[28] Maarten Van Steen and A Tanenbaum. Distributed systems principles and paradigms. Network,
2(28) :326, 2002.
[29] Maarten Van Steen and A Tanenbaum. Distributed systems principles and paradigms. Network,
2(28) :330, 2002.
[30] Jun Qin and Thomas Fahringer. Scientific workflows : programming, optimization, and synthesis with
ASKALON and AWDL. Springer, 2012.
[31] DDR5 SDRAM | Samsung Semiconductor Global Website. https://semiconductor.samsung.

com/dram/ddr/ddr5/, Accessed 2024. Accessed : May-29-2024.
[32] Seagate Technology LLC. Exos x x-mozaic. https ://www.seagate.com/fr/fr/products/enterprise-

drives/exos-x/x-mozaic/, 2024. Accessed : 2024-05-31.
[33] Seagate Technology LLC. Barracuda 520 ssd. https://www.seagate.com/fr/fr/products/

hard-drives/barracuda-520-ssd/. Accessed : 2024-05-31.
[34] Ieee standard for ethernet - amendment 11 : Physical layers and management parameters for 100 gb/s
and 400 gb/s operation over single-mode fiber at 100 gb/s per wavelength. IEEE Std 802.3cu-2021
(Amendment to IEEE Std 802.3-2018 and its approved amendments), pages 1–87, 2021.
[35] The Linux Kernel Archives. The linux kernel archives. https://www.kernel.org/. Accessed :
2024-05-24.
[36] TOP500.org. November 2023 top500 list. https://www.top500.org/lists/top500/2023/11/.

Accessed : 2024-05-24.
[37] SchedMD. Slurm documentation. https://slurm.schedmd.com/documentation.html, 2024.

Accessed : 2024-05-27.
[38] HTCondor Project. Htcondor. https://htcondor.org/. Accessed : 2024-05-31.

BIBLIOGRAPHIE
[39] Adaptive Computing Enterprises, Inc. Torque resource manager. https://adaptivecomputing.

com/cherry-services/torque-resource-manager/. Accessed : 2024-05-31.
[40] Groovy Development Team. Groovy. https://groovy-lang.org/, 2024. Accessed : 2024-05-27.
[41] Sylabs. Singularity user guide. https://docs.sylabs.io/guides/3.5/user-guide/index.

html.
[42] Apptainer. Apptainer. https://apptainer.org/, 2024. Accessed : 2024-05-27.
[43] Podman Project. Podman. https://podman.io/, 2024. Accessed : 2024-05-27.
[44] Nextflow. Nextflow. https://www.nextflow.io/index.html. Accessed : 2024-05-24.
[45] Felix Mölder, Konrad P. Jablonski, Ben Letcher, et al. Sustainable data analysis with snakemake
[version 2 ; peer review : 2 approved]. F1000Research, 10 :33, 2021.
[46] Conda Team. Conda documentation. https://conda.io/projects/conda/en/latest/index.

html. Accessed : 2024-05-27.
[47] Snakemake. Snakemake. https://snakemake.github.io/. Accessed : 2024-05-24.
[48] OpenWDL Project. Openwdl. https://openwdl.org/. Accessed : 2024-05-27.
[49] Cromwell. Cromwell documentation. https://cromwell.readthedocs.io/en/stable/. Acces-

sed : 2024-05-24.
[50] Grady Booch, James Rumbaugh, and Ivar Jacobson. Unified Modeling Language User Guide, The.
Addison Wesley, first edition, October 20 1998.
[51] Ubuntu. Ubuntu server. https://ubuntu.com/server, 2024. Accessed : 2024-05-27.
[52] Fedora Project. Fedora. https://fedoraproject.org/, 2024. Accessed : 2024-05-27.
[53] Visual Studio Code. Visual studio code. https://code.visualstudio.com/, 2024. Accessed :
2024-05-27.
[54] Gaphor. Gaphor. https://gaphor.org/en/, 2024. Accessed : 2024-05-27.
[55] Justinmind. Justinmind. https://www.justinmind.com/, 2024. Accessed : 2024-05-27.
[56] Diagrams.net. Drawio. https://app.diagrams.net/, 2024. Accessed : 2024-05-27.
[57] PrismJS. Prismjs. https://prismjs.com/index.html, 2024. Accessed : 2024-05-27.
[58] ACE. Ace editor. https://ace.c9.io/, 2024. Accessed : 2024-05-27.

BIBLIOGRAPHIE
[59] Gildas Lormeau. zip.js. https://gildas-lormeau.github.io/zip.js/, 2024. Accessed : 2024-

05-27.
[60] Chart.js. Chart.js. https://www.chartjs.org/, 2024. Accessed : 2024-05-27.
[61] Codeseven. Toastr. https://codeseven.github.io/toastr/, 2024. Accessed : 2024-05-27.
[62] SweetAlert2. Sweetalert2. https://sweetalert2.github.io/, 2024. Accessed : 2024-05-27.
[63] Bootstrap. Bootstrap. https://getbootstrap.com/, 2024. Accessed : 2024-05-27.
[64] Python. Python. https://www.python.org/, 2024. Accessed : 2024-05-27.
[65] Pallets Projects. Jinja documentation. https://palletsprojects.com/p/jinja/, 2024. Acces-

sed : 2024-05-27.
[66] Pallets Projects. Flask documentation. https://flask.palletsprojects.com/en/3.0.x/, 2024.

Accessed : 2024-05-27.
[67] Pallets Projects. Flask-sqlalchemy documentation. https://flask-sqlalchemy.

palletsprojects.com/en/3.1.x/, 2024. Accessed : 2024-05-27.
[68] SQLAlchemy. Sqlalchemy. https://www.sqlalchemy.org/, 2024. Accessed : 2024-05-27.
[69] OpenSSH. Openssh. https://www.openssh.com/, 2024. Accessed : 2024-05-27.
[70] Dun. Munge. https://dun.github.io/munge/, 2024. Accessed : 2024-05-27.
[71] OpenNTPD. Openntpd. https://www.openntpd.org/, 2024. Accessed : 2024-05-27.
[72] MySQL. Mysql. https://www.mysql.com/, 2024. Accessed : 2024-05-27.
[73] SQLite. Sqlite. https://www.sqlite.org/, 2024. Accessed : 2024-05-27.
[74] Ubuntu. Network file system (nfs). https ://ubuntu.com/server/docs/network-file-system-nfs, 2024.

Accessed : 2024-05-27.
[75] Oracle Corporation. Virtualbox user manual. https://www.virtualbox.org/manual/ch06.

html. Accessed : 2024-05-25.
[76] Ubuntu. Uncomplicated firewall (ufw). https://wiki.ubuntu.com/UncomplicatedFirewall,

2024. Accessed : 2024-05-27.
[77] Nature Education. Reading a phylogenetic tree : The meaning of mo-

nophyletic groups. https://www.nature.com/scitable/topicpage/
reading-a-phylogenetic-tree-the-meaning-of-41956/, 2024. Accessed : 2024-05-27.
BIBLIOGRAPHIE
[78] Chaitanya J. Joshi, Wenjun Ke, Aleksandra Drangowska-Way, Eleanor J. O’Rourke, and Nathan E.
Lewis. What are housekeeping genes ? PLoS Computational Biology, 18(7) :e1010295, July 2022.
[79] National Center for Biotechnology Information. Ncbi. https://www.ncbi.nlm.nih.gov/, 2024.

Accessed : 2024-05-27.
[80] D.L. Eager, J. Zahorjan, and E.D. Lazowska. Speedup versus efficiency in parallel systems. IEEE
Transactions on Computers, 38(3) :408–423, 1989.
[81] Torsten Seemann. Prokka : rapid prokaryotic genome annotation. https://github.com/tseemann/

prokka, 2024. GitHub repository Accessed : 2024-05-27.
[82] Kazutaka Katoh and Douglas M. Standley. Mafft multiple sequence alignment software. https:
//mafft.cbrc.jp/alignment/server/index.html, 2024. Accessed : 2024-05-27.
[83] Derek L Eager, John Zahorjan, and Edward D Lazowska. Speedup versus efficiency in parallel systems.
IEEE transactions on computers, 38(3) :412, 1989.
[84] Morgan N. Price, Paramvir S. Dehal, and Adam P. Arkin. Fasttree : Efficiently computing large
phylogenetic trees. http://www.microbesonline.org/fasttree/, 2024. Accessed : 2024-05-27.
[85] Andrew Rambaut. Figtree : Tree figure drawing tool. http://tree.bio.ed.ac.uk/software/

figtree/, 2024. Accessed : 2024-05-27.
[86] The Biopython Project. Biopython. https://biopython.org/, 2024. Accessed : 2024-05-27.

Annexe A
86
ANNEXE A.
Figure A.1 – Diagramme de Cas d’Utilisation Détaillé

ANNEXE A.
Workflow
Inputs Outputs Outils la Description
Processus
Annotation 𝑁 fichiers FASTA 𝑁 fichiers FASTA prokka [81] L’outil prokka annote les gènes four-
où 𝑁 ≥ 2 annotés nis sous forme de fichier fna en attri-
buant à chaque séquence une fonc-
tion à travers des comparaisons de
bases de données.
Extraction 𝑁 fichiers FASTA 𝑁 fichiers FASTA Bio-python Cette étape extrait la première appa-
annotés [86] rition de chaque housekeeping gene
dans le fichier FASTA.
Correction 𝑁 fichiers FASTA 𝑁 fichiers FASTA Bio-python Corrigez les gènes extraits en sup-
extraits primant tout housekeeping gene qui
n’apparaît pas dans tous les fichiers.
Séparation 𝑁 fichiers FASTA 𝑋 fichiers FASTA Bio-python Séparez chaque type de gènes dans
corrigés où 𝑋 représente le son fichier approprié.
nombre de house-
keeping genes uti-
lisés
L’alignement fait référence au pro-
cessus consistant à organiser plu-
Alignement 𝑋 fichiers FASTA 𝑋 fichiers FASTA mafft [82] sieurs séquences de manière à ce
multilignes alignés que les similitudes et les différences
entre elles deviennent apparentes.
Redistribuez chaque séquence ali-
gnée en fonction de son identifiant
Regroupement, approprié et produisez un seul fi-
𝑋 Fichiers 1 fichier FASTA Bio-python
Concaténation chier FASTA multiligne qui repré-
FASTA alignés multilignes
contenant toutes sente les séquences traitées.
les séquences
concaténées
Générez l’arbre phylogénétique
sous la forme d’un fichier NEWICK
qui est une représentation qui utilise
Construction 1 fichier FASTA 1 fichier NE- FastTree [84]
une notation basée sur des paren-
d’arbres multiligne WICK
thèses pour désigner les branches de
l’arbre.
transformez le fichier NEWICK en
Visualisation de 1 fichier NE- 1 fichier PDF FigTree [85] PDF.
l’arborescence WICK
Table A.1 – Description des étapes du workflow de l’Arbre Phylogénétique

Memoire Français

Transféré par

Droits d'auteur :

Formats disponibles

Memoire Français

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Memoire Français

Transféré par

Droits d'auteur :

Formats disponibles

Approche Distribuée Pour le Déploiement des Workflow

MESBAH Ayoub Rayane

nécessaires à la réalisation de ce mémoire.

Ce travail a été réalisé au sein de la plateforme Génomique-Bioinformatique de l’Institut Pasteur

Un grand merci à nos encadreurs :

conseils, sa patience et sa gentillesse.

partie de leur temps pour évaluer notre travail.

2 État de L’art des Workflows Scientifiques 15

4.5.3 Configuration du Slurm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5 Évaluation & Discussion 65

2.1 La Modélisation Mathématique d’un Workflow . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Architecture Globale du Platforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1 La Pile Logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.1 Exemple d’arbre phylogénétique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

A.1 Diagramme de Cas d’Utilisation Détaillé . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

3.1 Types de classes et leurs Responsabilités . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1 Ports autorisés par le pare-feu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.1 Matérielle de Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

A.1 Description des étapes du workflow de l’Arbre Phylogénétique . . . . . . . . . . . . . . . 88

SGWS Système de Gestion des Workflows Scientifiques

PGB Plateforme Génomique-Bioinformatique

IPA Institut Pasteur d’Algérie

DSL Domain Specific Language

HDD Hard-Disk Drive

SSD Solid-State drive

RAID Redundant Array of Independent Disks

LVM Logical Volume Manager

GNU GPL GNU General Public License

SGFD Système de Gestion de Fichier Distant

SGBDR Systém de Gestion de Base de données Relationelle

WMC Workflow Management Coalition

CDD Community-driven development

WDL Workflow Description Language

ISA Instruction Set Architecture

TDP Thermal design power

MAC Media Access Control

NIC Network Interface Controller

UML Unified Modeling Language

NAT Network Address Translation

RPC Remote Procedure Call

KVM Kernel-based Virtual Machine

UUID Universally Unique Identifier

RAD Rapid application development

ORM Object Relational Mapper

UFW Uncomplicated Firewall

HOKEGA HouseKeeping Genes Analysis tool

DAG Directed Acyclic Graph

La thèse porte sur les points suivants :

— La définition du contexte théorique des Workflow Scientifiques (WSs) et des SGWSs.

— L’exploration du cluster en tant que plateforme pour accélérer les WSs.

La thèse est organisée en 6 chapitres :

— Chapitre 1 : Présentation du Contexte

— Chapitre 2 : État de l’art des Workflow Scientifique

— Chapitre 3 : Conception de la plateforme

— Chapitre 4 : Implémentation de la plateforme

— Chapitre 5 : Évaluation & Discussion

— Chapitre 6 : Conclusion Générale

1.1 Présentation de l’Institut Pasteur

1.2 État actuel de la Plateforme Génomique-Bioinformatique

1.3 Les Besoins Fonctionnels