République de Côte d’Ivoire

MINISTERE DE LA COMMUNICATION ET DE
L’ECONOMIE NUMERIQUE
Ecole Supérieure Africaine des Technologies de Année académique 2021 – 2022
l’Information et de la Communication

MÉMOIRE DE FIN D’ÉTUDE POUR L’OBTENTION DU MASTER EN

SYSTÈMES D’INFORMATION ET GÉNIE LOGICIEL (SIGL)

CONCEPTION ET MISE EN PLACE D’UNE

ARCHITECTURE HAUTEMENT DISPONIBLE POUR
LE DÉPLOIEMENT DE LA PLATEFORME OPEN
DATA DU GOUVERNEMENT IVOIRIEN

M-22,KOF,189
Du 21 février 2021 au 21 aout 2021
Proposé par
KOFFI Kouassi Edy Aristide

Membres du jury

Prof. SORO Adama, Maitre de Conférence à l’université de Cocody, (Président du jury)

Dr KAMAGAE Beman, Enseignant – Chercheur à ESATIC (Rapporteur)
M. NZI Konan, Enseignant à ESATIC (Assesseur)
Mme Coulibaly Mariame, Enseignante à ESATIC (Membre)

Encadrants académiques
Maître de stage
Prof. COULIBALY Adama
Professeur à l’UFR Mathématiques /Informatiques ZAPFACK Fabrice
à l’université FHB de Cocody Co-fondateur et CTO de Data354
Dr ADOU Koffi Achille
Enseignant - Chercheur à ESATIC
1
1
 République de Côte d’Ivoire

MINISTERE DE LA COMMUNICATION ET DE
L’ECONOMIE NUMERIQUE
Ecole Supérieure Africaine des Technologies de Année académique 2021 – 2022
l’Information et de la Communication

MÉMOIRE DE FIN D’ÉTUDE POUR L’OBTENTION DU MASTER EN

SYSTÈMES D’INFORMATION ET GÉNIE LOGICIEL (SIGL)

CONCEPTION ET MISE EN PLACE D’UNE

ARCHITECTURE HAUTEMENT DISPONIBLE POUR
LE DÉPLOIEMENT DE LA PLATEFORME OPEN
DATA DU GOUVERNEMENT IVOIRIEN

M-22,KOF,189
Du 21 février 2021 au 21 aout 2021
Proposé par
KOFFI Kouassi Edy Aristide

Membres du jury

Prof. SORO Adama, Maitre de Conférence à l’université de Cocody, (Président du jury)

Dr KAMAGAE Beman, Enseignant – Chercheur à ESATIC (Rapporteur)
M. NZI Konan, Enseignant à ESATIC (Assesseur)
Mme Coulibaly Mariame, Enseignante à ESATIC (Membre)

Encadrants académiques
Maître de stage
Prof. COULIBALY Adama
Professeur à l’UFR Mathématiques /Informatiques ZAPFACK Fabrice
à l’université FHB de Cocody Co-fondateur et CTO de Data354
Dr ADOU Koffi Achille
Enseignant - Chercheur à ESATIC
2
DÉDICACE

À ma très chère famille qui tout au long de ce parcours n’a cessé de me soutenir,
recevez par ces mots mon éternelle gratitude.

iii
REMERCIEMENTS

Mes sincères remerciements :

Au Professeur Directeur Général de l’ESATIC pour son

KONATE Adama dévouement à nous fournir une formation de qualité
et à faire de notre établissement l’un des meilleurs.

Au Professeur Respectivement Professeur à l’UFR

COULIBALY Adama Mathématiques/Informatique à l’UFHB de Cocody
Et au Docteur ADOU et Enseignant - Chercheur à l’ESATIC, nos
Koffi Achille encadrants académiques pour leur disponibilité, leur
participation et leurs conseils avisés.

À M. ZAPFACK Fabrice Mon maître de stage, co-fondateur et CTO de

Data354, pour son soutien, sa confiance et son
implication dans la réalisation de ce projet.

À
DANHO Jethro
DIAKITE Youssouf
DIOP Assane
DOUGBAN Monsia
DOUMBIA Al Moustapha
Mes collaborateurs à Data354 pour leur soutien
KANGAH Jaures
KIDAM Balle
KOUADIO Yasmine
TOURE Issouf
TRAORE Abdoul-Aziz

iv
SOMMAIRE

INTRODUCTION

PARTIE I : GÉNÉRALITÉS

CHAPITRE 1 : ENVIRONNEMENT DE TRAVAIL

CHAPITRE 2 : PRÉSENTATION DU PROJET

PARTIE II : ANALYSE CONCEPTUELLE ET TECHNIQUE

CHAPITRE 3 : ANALYSE DE LA PLATEFORME OPEN DATA

CHAPITRE 4 : CONCEPTS, ÉTUDE ARCHITECTURALE ET

TECHNIQUE

PARTIE III : REALISATION, RÉSULTATS ET DISCUSSION

CHAPITRE 5 : APPLICATION DE L'ÉTUDE TECHNIQUE

CHAPITRE 6 : RÉSULTATS ET DISCUSSIONS

CONCLUSION

v
LISTE DES SIGLES ET ABREVIATIONS

AC Autorité de Certification
ACME Automated Certificate Management Environement
ALPN Application-Layer Protocol Negotiation
API Application Programing Interface
ARTCI Autorité de Régulation des Télécommunications de Côte d’Ivoire
Commission d’Accès à l’Information d’intérêts Public et aux
CAIDP
Documents Publics
CEO Chief Executif Officer
CICG Centre d’Information et de Communication Gouvernementale
CIS Center for Internet Security
CKA Certification Kubernetes Administrator
CKAD Certification Kubernetes Application Developper
CKS Certification Kubernetes Security
CNCF Cloud Native Computing Foundation
CTO Chief Technical Officer
CVE Common Vulnerabilities and Exposures
DNS Domain Name System
FAIR Findable Accessible Interoperable Reusable
FIPS Federal Information Processing Standard
HTTP HyperText Transfer Protocol
IDS Intrusion Detection System
JSON JavaScript Object Notation
KCNA Kubernetes and Cloud Native Associate
LDAP Lightweight Directory Access Protocol
LUKS Linux Unified Key Setup
OGP Open Government Partnership
PDB Pods Disruption Budget
RGPD Règlement Général sur la Protection des Données

vi
RPA Robotic Process Automation
TLS Transport Layer Security
SSH Secure SHell
SSL Secure Socket Layer
SSO Single Sign-On
UFHB Université Félix-Houphouët-Boigny
UFR Unité de Formation et de Recherche
VM Virtual Machine

vii
LISTE DES FIGURES

Figure 1 : Organigramme de Data354 .......................................................................... 5

Figure 2 : Fonctionnement de l'Open Data .................................................................. 8
Figure 3 : Architecture de Data fair ........................................................................... 18
Figure 4 : Scalabilité verticale et la scalabilité horizontale (source:
https://fr.acervolima.com/) ......................................................................................... 24
Figure 5 : Tolérance aux pannes, exemple (Source : https://www.wallarm.com/ ) ... 25
Figure 6 : Architecture de la conteneurisation (Source : https://www.lebigdata.fr) .. 26
Figure 7 : Docker swarm (source : docs.docker.com) ............................................... 27
Figure 8 : Architecture de Kubernetes (source : https://medium.com) ..................... 28
Figure 9: Architecture de Rancher ............................................................................ 33
Figure 10 : Défense en profondeur............................................................................. 36
Figure 11 : Communication SSH (source : https://doubleoctopus-com.translate.goog)
.................................................................................................................................... 37
Figure 12 : Architecture avec bastion (source: https://blog.octo.com) ...................... 38
Figure 13 : Communication HTTPS .......................................................................... 41
Figure 14 : Restriction de domaine ............................................................................ 44
Figure 15 : Utilisation de pare-feu applicatif (source : https://www.nginx.com) ...... 45
Figure 16 : Architecture Prometheus (source: https://prometheus.io/) ...................... 48
Figure 17 : Architecture finale du système ................................................................ 51
Figure 18 : Charte Helm data fair déployée ............................................................... 55
Figure 19 : Interface de connexion de rancher ........................................................... 56
Figure 20 : Présentation du cluster Rancher .............................................................. 56
Figure 21 : Interface Admin Data fair ........................................................................ 57
Figure 22 : Visualisations Data Fair .......................................................................... 57
Figure 23 : Accueil portail open data ivoirien ........................................................... 58
Figure 24 : Jeux de données consultés sur le portail open data ivoirien .................... 58

viii
LISTE DES TABLEAUX

Tableau 1 : Services proposés par Data354 ................................................................. 5

Tableau 2 : Planning d'exécution du projet ................................................................ 14
Tableau 3 : Estimation financière du projet ............................................................... 14
Tableau 4 : Avantages et inconvénients de Kubeadm ............................................... 32
Tableau 5 : Avantages et Inconvénients de Kubespray ............................................. 32
Tableau 6 : Avantages et inconvénients de K3S ........................................................ 34

ix
INTRODUCTION

Les données ouvertes (open data) sont des informations numériques, qu'elles
soient d'origine privée ou publique, librement accessibles et utilisables par les usagers.
Elles sont créées généralement par des collectivités ou des institutions publiques et
proposées sous des licences dites libres d'exportation, de distribution, de modification
et de commercialisation. Le terme « open data » est apparu pour la première fois en
1995 dans une publication scientifique du National Research Council des États-Unis
des intitulée « On the Complete and Open Exchange of Scientific Data », avant d'être
adopté et formalisé par les états européens. Depuis, le concept représente une véritable
opportunité de croissance pour les entreprises qui l'utilisent pour rendre leurs études
de marché plus efficaces.

A l'instar des pays occidentaux, la Côte d'Ivoire n'est pas en marge de cette
révolution numérique. Son aventure avec l’open data débute en 2014 à l'initiative du
Centre d'information et de communication gouvernementales (CICG) et se poursuit
aujourd'hui. Le but, étant d’améliorer et de garantir l’égalité d’accès aux données
publiques à l’ensemble des partenaires techniques et financiers, au secteur privé, à la
société civile et aux citoyens. Dès lors, la Côte d’Ivoire est dotée d’une plateforme
open data hébergée et managée par une entreprise à l’étranger. Cependant pour des
raisons de souveraineté et de sécurité il est important que la plateforme Open Data du
gouvernement ivoirien et toutes ses données soient migrées vers les serveurs du
gouvernement. Cependant la mise en place d’une solution open data locale
s'accompagne de responsabilités politiques, sociales, juridiques, économiques et
surtout techniques. Les enjeux techniques sont plus importants et nécessitent une
attention particulière, car cette solution peut impliquer des applications complexes et
de pointe. L’objectif de cette étude serait donc de mettre en place une architecture
hautement en vue de déployer et maintenir la plateforme open data du gouvernement
ivoirien sur ces propres centres de données. Cela nous amène donc à explorer le sujet :
“Conception et mise en place d'une architecture hautement disponible pour le
déploiement de la plateforme open data du gouvernement ivoirien”. A travers
cette étude, nous visons à déployer et maintenir une plateforme de données ouvertes

1
en Côte d'Ivoire dans des centres de données du gouvernement, en tenant compte des
besoins de cette plateforme.

Ainsi dit, comment mettre en place une architecture technique adéquate pour
le déploiement de la plateforme open data ivoirienne ? Quelle architecture
fonctionnelle présente cette plateforme et quelles en sont les exigences en termes de
ressources et dispositions techniques ? Quelles méthodes et outils de déploiement
répondent le mieux aux exigences d'un tel système ?

Il s’agira donc de mettre en place un système basé sur une architecture hautement
disponible tout en respectant les aspects de sécurité, de fiabilité et de disponibilité.

Pour répondre à cette problématique, nous présenterons dans un premier dans la

généralité, les aspects administratif et managérial du projet afin de mieux le
comprendre, puis à travers une étude conceptuelle nous définirons les concepts liés à
l’étude et la démarche à suivre pour la mise en place de notre système, et enfin dans la
partie des résultats nous présenterons les réalisations et les discuterons.

2
PARTIE I : GÉNÉRALITÉS

3
Cette partie décrit tous les aspects généraux liés à notre environnement de travail,
depuis la structure d'accueil jusqu’aux méthodes et outils utilisés en entreprise.
Consacré à la compréhension du sujet elle abordera aussi la généralité sur l’open data
et les avancés de cette initiative en Côte d’Ivoire.

CHAPITRE 1 : ENVIRONNEMENT DE TRAVAIL

I. PRÉSENTATION DE LA STRUCTURE D’ACCUEIL

Présentation générale

Data354 est une société de conseil en technologie pour les produits et services
dans le domaine de l'ingénierie et de l'analyse des données. La société accompagne les
acteurs des secteurs publics et privés dans le développement de solutions de gestion
de données et d'analyse prédictive. Fondée en 2020 par une équipe expérimentée,
interdisciplinaire, cette entreprise a une vision très précise : “Mettre en place des outils
d'analyse et de prévision de pointe au service des organisations opérant en Afrique”.
Pour ce faire, elle assiste ses partenaires tout au long de leur processus de
transformation des données grâce à son expertise technique et à ses capacités de
conseil en stratégie et en gestion.

Domaines de compétences

Partenaire privilégié des cabinets de conseils en transformation digitale en

Afrique et en Europe, data354 propose une large gamme de prestations externalisées
telles que :

- la cartographie de l’infrastructure technique et des données existantes ;

- la collecte, le stockage, la sécurisation, le traitement, la visualisation et la

valorisation de données internes et externes ;

- la mise en place d’outils d’aide à la décision ;

- l’intelligence artificielle : machine learning / deep learning (entraînement des

modèles, prédictions et visualisation).

Elle accompagne également les entreprises technologiques internationales à

l’adaptation de leurs solutions aux marchés africains.

4
Les services proposés par l’entreprise sont regroupés en trois grands groupes :

Tableau 1: Services proposés par Data354

Data strategy Data management Data intelligence

Évaluation de la maturité Infrastructure Big data et Data science
Data Stratégie & plan de temps réel Business Intelligence
gouvernance Qualité des données RPA2
Acculturation Data Data Catalog1

Equipes

Data354 fonctionne selon un mode de gestion entièrement agile et se compose

de plusieurs équipes travaillant ensemble pour atteindre les objectifs et la vision de
l'entreprise.

Figure 1: Organigramme de Data354

1
Data catalog : Un Data Catalog est un emplacement centralisé où sont regroupées les informations sur les données contenues
dans une base de données : les métadonnées.
2
RPA : La RPA, ou Robotic Process Automation, est une technologie permettant d’automatiser des processus métier qui
nécessitent, jusque-là, l’intervention d’un humain. C’est -à-dire traiter des tâches répétitives et chronophages grâce à l’utilisation
de logiciels d’intelligence artificielle capables d’imiter un travailleur humain.

5
 3.1. Equipe dirigeante

Il s’agit de l’équipe fondatrice, composée du Chief Executive Officer (CEO) et

du Chief Technology Officer (CTO).

3.2. Équipe de management

Cette équipe est responsable de l'administration de l'entreprise. Elle s'assure de

son bon fonctionnement et veille au respect de toutes les normes et principes établis
dans la pratique.

3.3. Équipe de marketing et vente

Composée essentiellement de Consultants et Commerciaux qualifiés, cette

équipe est responsable de la stratégie de vente et l’image commerciale de l’entreprise.
Elle est directement rattachée au CEO.

3.4. Équipe technique

Dirigée par le CTO, cette équipe multidisciplinaire est responsable de

l'exécution des tâches confiées à l'entreprise. Elle se compose de Data Scientists, Data
Engineers, MLOps, Data Architects, Data Analysts, Spécialistes BI, Développeurs,
Devops. Pour la mise en œuvre de ce projet, nous avons travaillé spécifiquement en
tant que DevOps avec l'aide de consultants externes expérimentés.

6
 II. MÉTHODES ET OUTILS DE TRAVAIL

SCRUM

La méthodologie SCRUM est un Framework de gestion de projet agile qui

décrit un ensemble de réunions, d'outils et de rôles qui interagissent de concert pour
aider les équipes à structurer leur travail et à le gérer. Fondé sur la théorie de contrôle
empirique de processus, le SCRUM utilise une démarche itérative et progressive afin
d’optimiser la prédictibilité et le contrôle de risque. Ses trois piliers fondamentaux sont
la transparence, l’inspection et l’adaptation. L'équipe SCRUM est constituée d’un
product owner, d’un scrum master et d’une équipe de développement.

Open source

L’open source désigne des applications ou logiciels informatiques dont le code

source est accessible au public. L’utilisation des applications open source a Data354
est d’une grande importance car permet à l'équipe d’apprendre de plus en plus à travers
du code d’applications très abouties et une grande communauté de développeurs
expérimentés. Et dans certains cas, comme celui de ce projet, de contribuer à
l'amélioration d’applications.

DevOps

Le DevOps est une approche qui concilie deux équipes antérieurement

opposées : les développeurs (Dev) et les administrateurs de système et d’architecture
(Ops). C’est donc une combinaison de philosophies, de pratiques et d’outils qui
augmente la capacité de l’entreprise à livrer des applications et services à grande
vitesse. Cette vitesse de livraison améliore la relation avec les clients sur un marché
de plus en plus compétitif. Les principaux avantages de cette approche sont :

- la vitesse de développement ;
- la livraison rapide des applications et services ;
- la fiabilité du processus ;
- la mise à l’échelle.

7
CHAPITRE 2 : PRÉSENTATION DU PROJET

I. GÉNÉRALITÉS ET ENJEUX DE L’OPEN DATA

Généralités

Figure 2: Fonctionnement de l'Open Data

Les données ouvertes sont un ensemble de données librement disponibles qu'il

est possible d'utiliser et de partager sans restriction. Tout utilisateur doit pouvoir
accéder aux données, les réutiliser et les redistribuer librement. Ces trois critères
permettent une interopérabilité avec des données provenant de sources diverses.
L’open data couvre plusieurs secteurs tels que la géolocalisation, la finance, les
sciences, le transport, la culture, le sport, la santé, l'environnement. Il rassemble
également un certain nombre d'objectifs qui concernent autant les administrations que
les entreprises. Ce sont :

- une meilleure transparence des données vis-à-vis des utilisateurs ;

- une efficacité accrue des politiques publiques et des collectivités ;
- une amélioration de la coopération avec l'apport de nombreuses ressources en
vue de créer une valeur économique et sociale ;
- la création de nouvelles possibilités d'affaires.

8
Pour être considérées comme ouvertes, les données doivent satisfaire aux huit critères
adoptés en vertu des principes des données ouvertes. Les données libres doivent être :

- primaires : Les données doivent être brutes et non traitées ;

- fraîches : elles doivent être accessibles dès leur production et régulièrement
actualisées ;
- accessibles : disponibles pour le plus grand nombre d'usagers et de préférence
en téléchargement ou en ligne. L’accessibilité inclut également un coût
raisonnable de la donnée (si elle n’est pas gratuite) ;
- non-discriminatoires : elles doivent être utilisables par tous sans aucune
discrimination dans leur usage (commercial, à but non-lucratif) ;
- lisibles par les machines : elles peuvent faire l’objet d’un traitement
automatisé par les machines informatiques ;
- dans un format ouvert : le format de la donnée ne doit pas être la propriété
d'une organisation ou d'une entreprise. Sa gouvernance doit être commune par
les différents usagers ;
- avec une licence libre : elles doivent pouvoir être modifiables et redistribuées
même à des fins commerciales.

Mais comment le système judiciaire compte-t-il réglementer les données

ouvertes ? Les données publiques sont censées respecter la vie privée des individus.
Elles doivent être anonymisées pour les publications. S'il se produit que ces
informations personnelles sont publiées, elles devront respecter les règles du "privacy
by design"3 énoncées par le RGPD. Les personnes concernées par ces informations
doivent d'abord y consentir.

En Côte d’Ivoire, la protection des données à caractère personnel est régie par
l’ARTCI selon la loi 2013-450 sur la protection des données personnelles pour
répondre aux exigences de la transformation numérique.

3
privacy by design: Le principe de “privacy by design” est un principe instauré par le Règlement Général sur la
Protection des Données (RGPD). Il permet une protection optimale des données personnelles dès la conception
et lors de chaque usage d’une nouvelle technologie. Ainsi, à ce principe, la protection des données personnelles
n’est plus une option pour les entreprises mais une obligation inhérente à chacune de ses activités.

9
 Enjeux

L’Open Data est l'un des principaux enjeux numériques dans le monde. Il
favorise l'innovation grâce à l'élimination des obstacles à l'accessibilité, à l'utilisation
et à la distribution de la donnée.

2.1. Enjeux pour les gouvernements

La disponibilité des données garantit la transparence des valeurs

gouvernementales. Cela présente de nombreux avantages. Les données ouvertes
peuvent aider à améliorer les services publics en augmentant l'efficacité de l'éducation
et en améliorant la mobilité dans les transports. Il s’agit aussi d’un facteur d'égalité
d'accès au savoir. Les données ouvertes favorisent la création de valeurs sociales et
économiques qui contribuent à la croissance.

L’open data s’avère aussi très utile lors de la gestion de crises humanitaires.
L’accès aux données géographiques, statistiques, sanitaires et environnementales est
très important pour l’aide à la prise de décision. Cet accès a permis, par exemple,
d’aider des personnes et des organismes lors de la crise humanitaire d’Haïti. Ces
informations avaient permis de cibler les approvisionnements dans les zones les plus
atteintes.

2.2. Enjeux pour les entreprises

Pour les entreprises, les données ouvertes signifient des opportunités de

croissance commerciale, et le libre accès aux sources d'information rend les études de
marché plus efficaces. Les entreprises peuvent l'utiliser pour améliorer leurs services
et produits. De nombreuses informations peuvent être collectées et intégrées via des
API. L'accès gratuit des données permet à ces entreprises de se concentrer sur des
activités à valeur ajoutée.

10
 II. L’OPEN DATA EN CÔTE D’IVOIRE

L’initiative du gouvernement

L'Initiative Open Data Côte d'Ivoire a été lancée depuis 2014 par le CICG. Elle
vise à encourager et permettre aux organismes publics de diffuser de manière
spontanée et structurée des documents et données publiques à partir d’une plateforme
dynamique et interactive, consultable par tout citoyen en quête d’information dite du
domaine public. Ce projet de plateforme nationale « data.gouv.ci » est la traduction
technique des engagements pris par le Premier Ministre dans le cadre du Plan d’Action
de la Côte d’Ivoire dans « Open Government Partnership-OGP », Organisation
Internationale dont la Côte d’Ivoire est membre depuis 2015.

« Data.gouv.ci » s’inscrit également dans le projet de « Maturité Numérique »

conduit par le ministre de l’Économie Numérique et de la Poste, comme l’un des
indicateurs de transparence et de bonne gouvernance. Il contribuera aussi à améliorer
et garantir l’égalité d’accès aux données publiques à l’ensemble des partenaires
techniques et financiers, au secteur privé, à la société civile et aux citoyens tels que
prescrits par la loi n°2013-867 du 23 décembre 2013 relative à l’accès à l’information
d’intérêt public adoptée à l’initiative du ministre de la communication.

Le projet « Open Data Côte d’Ivoire » se déroule en étroite collaboration avec

la Commission d’Accès à l’Information d’Intérêt Public et aux Documents Publics
(CAIDP), OGP Côte d’Ivoire du Ministère de l’Industrie et des Mines, le Ministère de
l’Économie Numérique et de la Poste. [4]

Point d’avancement des travaux

Depuis 2021, la mise en œuvre du projet a été confiée à data 354, qui a opté
pour une solution open source qu’on détaillera plus bas. Jusqu'à présent, le
gouvernement de Côte d'Ivoire dispose d'une plateforme de données ouvertes et d'un
portail de publication et de visualisation de données disponibles sur le lien
https://data.gouv.ci, tous deux hébergés sur un cloud public par une entreprise
étrangère.

11
 III. PRESENTATION ET ORGANISATION DU PROJET

Contexte et justification

La Côte d'Ivoire dispose désormais d'une plateforme de données ouvertes

hébergée et gérée à partir d’un cloud public sous le domaine data.gouv.ci dans le cadre
de son déploiement de l’open data. Cependant, pour des raisons de souveraineté et de
sécurité, il a été recommandé que toutes les applications déployées sous le nom de
domaine “gouv.ci” soient hébergées et gérées par les centres de données du
gouvernement ivoirien. Dans ce contexte, data354 a été mandatée afin de proposer et
mettre en œuvre des stratégies de déploiement prenant en compte la sécurité, la fiabilité
et la haute disponibilité pour l'hébergement de ladite plateforme.

Objectifs

2.1. Objectif général

Notre objectif général est de proposer et implémenter une stratégie de

déploiement d’architecture hautement disponible afin d’assurer l'hébergement de la
plateforme open data du gouvernement ivoirien sur ses propres centres de données.

2.2. Objectifs spécifiques

Afin d’atteindre notre objectif général nous nous sommes fixé des objectifs
spécifiques, qui sont :

- étudier la plateforme Open Data choisie, plus précisément son architecture

fonctionnelle et ses composants afin d’en comprendre les exigences en termes
de ressources et dispositions techniques ;
- étudier les méthodes, plans d’architectures et technologies à mettre en œuvre
pour répondre aux exigences de la plateforme ;
- appliquer les recommandations de notre étude méthodologique dans un
environnement test afin d’en observer les résultats et tirer des conclusions.

12
 Contraintes

3.1. Contraintes techniques

3.1.1. Serveurs

L’application ainsi que ses bases de données devront être installées sur des
serveurs physiques ou virtuels. Ces serveurs devront provenir des centres de données
du gouvernement ivoirien et si possible de localités différentes.

3.1.2. Clients

Le système doit être accessible via plusieurs types d’appareils tels que les PC
portables, les PC fixes, les « Clients légers » et les tablettes électroniques. Il devra
aussi être supporté par les systèmes d’exploitation tels que Windows et UNIX/linux.

3.2. Contraintes organisationnelles

3.2.1. Utilisateurs finaux

L’utilisation de la plateforme open data est divisée en deux parties. D’un côté
les institutions étatiques, les entreprises publiques qui ont pour rôle de rendre
disponible les données, et de l'autre l'ensemble des citoyens, entreprises et startups,
enseignants, étudiants, chercheurs et particuliers qui utilisent les données soit pour des
besoins personnels soit pour en produire une valeur commerciale.

3.2.2. Livrables

À la fin de notre étude nous nous attendons aux livrables suivant :

- l'architecture technique du système ;

- une stratégie de déploiement détaillée et documentée ;
- la plateforme open data déployée dans un environnement de test selon
l’architecture technique adoptée ;
- le portail public déployé dans un environnement de test.

13
 Planning d’exécution

Tableau 2: Planning d'exécution du projet

Durée Tâche Livrables

Setup de l’environnement
2 Semaines
de travail

Architecture technique et
10 Semaines Conception du système
technologies appropriées

Prise en main des outils et

3 Semaines
technologies à utiliser

Mise en œuvre et Plateforme déployée en

6 Semaines
application environnement test

Estimation financière

Tableau 3: Estimation financière du projet

Kubernetes Administrator (CKA) 260 000 F CFA

Kubernetes Application Dev (CKAD) 260 000 F CFA
Formation Kubernetes Security Specialist (CKS) 260 000 F CFA
Kubernetes and Cloud Native Associate (KCNA) 165 000 F CFA
Livres et documents 122 000 F CFA
Ordinateur portable 800 000 F CFA
Outils de travail
Communication et internet 150 000/mois * 6 900 000 F CFA
Ressources Compute Engine e2-standard-2 129 000 F CFA
serveurs Compute Engine Persistent Disk 60 GiB 145 000 F CFA
3 041 000 F CFA

Cette estimation ne reflète que les ressources matérielles et la formation

nécessaires pour mener à bien ce projet. Pour ce qui est de la main d'œuvre, elle est
fonction de l'expérience du réalisateur des tâches et peut varier de 15000/h/H à
50000/h/H (h : heure, H : Homme).

Cette partie sur les généralités nous a été utile pour mieux comprendre le projet dans
son contexte général et nous permet d’aborder avec plus de sérénité la prochaine partie
consacrée à l’analyse conceptuelle et technique.

14
PARTIE II : ANALYSE CONCEPTUELLE ET
TECHNIQUE

15
Cette partie décrit les points techniques de la solution adoptée par le Gouvernement de
Côte d'Ivoire. Elle examine de plus près son architecture, ses composants et ses
opérations pour en déduire les besoins et les exigences concernant les ressources et les
dispositions architecturales à adopter.

CHAPITRE III : ANALYSE DE LA SOLUTION OPEN

DATA

I. DESCRIPTION ET FONCTIONNEMENT DE DATA

FAIR

Description de data fair

Data Fair est un écosystème open source permettant de mettre en œuvre une
plateforme de partage de données (interne ou public) et de visualisations. Cette
plateforme peut être à destination du grand public, qui peut accéder aux données au
travers de visualisations interactives adaptées, ou d’un public plus expert qui peut
accéder aux données au travers des APIs.

Le mot FAIR fait référence à de la donnée « Facile à trouver, Accessible,

Interopérable et Réutilisable ». Cela est rendu possible grâce à l'indexation des données
sur la plateforme. Elle permet de réaliser des recherches complexes dans des volumes
de plusieurs millions d’enregistrements et d'accéder plus facilement et rapidement aux
informations qui nous intéressent. L'accès aux données au travers d'APIs normalisées
et documentées permet d'interfacer la plateforme avec d'autres systèmes d'information
et facilite la réutilisabilité des données.

Fonctionnement général

Les jeux de données sont en général créés par les utilisateurs en chargeant des
fichiers tabulaires ou géographiques : le service stocke le fichier, l'analyse et déduit un
schéma de données. Les données sont ensuite indexées suivant ce schéma et peuvent
être interrogées au travers d'une API Web.

16
En complément des jeux de données basés sur les fichiers, Data Fair permet également
de créer des jeux de données éditables par formulaire et des jeux de données virtuels
qui sont des vues configurables d'un ou plusieurs jeux de données.

L'utilisateur peut sémantiser les champs des jeux de données en leur attribuant
des concepts, par exemple en déterminant qu'une colonne contenant des données sur 5
chiffres est un champ de type Code Postal. Cette sémantisation permet 2 choses : les
données peuvent être enrichies à partir de données de référence ou elles même devenir
données de référence pour en enrichir d'autres, et les données peuvent être utilisées
dans des visualisations adaptées à leurs concepts.

Les visualisations permettent d'exploiter au maximum le potentiel des données

des utilisateurs. Quelques exemples : un jeu de données contenant des codes de
commune peut être projeté sur une carte du découpage administratif ivoirien, un jeu
de données contenant des codes de parcelles peut être projeté sur le cadastre.

Principaux atouts

Data Fair permet de mettre en place une organisation centrée autour de la donnée grâce
à ces principaux atouts :

- possibilité de charger des données sous différents formats de fichiers ou par

saisie via formulaire, permettant même de faire du crowd sourcing4 ;
- consultation des données au travers d'un large choix de visualisations
interactives (graphiques, cartes, moteurs de recherche) ;
- possibilité de créer plusieurs portails suivant les cas d'usage (open data,
échanges internes) ;
- création facilitée d'APIs de données et enrichissement des données pour leur
donner encore plus de valeur ;
- mise en place de traitements périodiques permettant d'alimenter
automatiquement la plateforme en données ;
- cadre sécurisé, code source ouvert et utilisation de standards.

4
Le crowd sourcing est une pratique consistant à obtenir des informations ou des contributions à une
tâche ou un projet en faisant appel aux services d'un grand nombre de personnes, rémunérées ou non,
généralement via l'internet.

17
 II. ARCHITECTURE APPLICATIVE ET COMPOSANTS

Architecture de Data Fair

Figure 3: Architecture de Data fair

18
 Composants

2.1. Data Fair

Data Fair est le module principal de la solution. Il permet d'exposer facilement

les données via une API web, contractualisée et documentée, ce qui permet aux
développeurs de les réutiliser facilement dans leurs applications. De plus les données
peuvent être sémantisées, ce qui permet ensuite de les enrichir avec d'autres données
sémantisées. Ainsi, des données qui ont une adresse peuvent par exemple être
complétées par des coordonnées GPS, ce qui permet de les afficher sur une carte.

2.2. Simple Directory

Simple directory est le service responsable de la gestion des comptes. Il permet

de gérer 2 types de comptes dans data fair : les comptes utilisateurs et les comptes
d’organisation.

2.2.1. Gestion de session décentralisée

Le rôle principal de Simple Directory est de permettre aux utilisateurs de

s'authentifier dans la plateforme. Cela se fait au moyen de jetons stockés sur le client.
Les clients envoient leur jeton à chaque requête HTTP, et chaque service dans
l'infrastructure est capable de vérifier que le jeton est correct. Cela se fait en vérifiant
que la clé publique mise à leur disposition par Simple Directory correspond à la clé
qui a permis de chiffrer ledit jeton.

2.2.2. Connection des utilisateurs

Les utilisateurs peuvent se connecter avec un mot de passe et un email ou en

utilisant un compte externe existant tel qu’un compte Gmail, Facebook, Github ou
Linkedin via le protocole OAuth25. D’autres protocoles ou fournisseurs d’identités tels
que LDAP ou SSO seront bientôt implémentés.

5
OAuth 2.0 est un protocole qui permet à un utilisateur d'accorder à un site web ou à une application
tierce l'accès à ses ressources protégées, sans nécessairement révéler ses informations d'identification à
long terme ou même son identité.

19
 2.3. Data Fair Portal

Data Fair Portal permet de réaliser des portails de données, publics ou privés.
Une organisation peut avoir plusieurs portails, et il sera bientôt possible de réaliser des
portails multi-organisations. Chaque portail peut être publié sur un nom de domaine
différent, Data Fair Portal agît à la manière d'un reverse proxy pour que chaque requête
HTTP soit traitée dans le contexte du portail auquel elle fait référence.

2.4. Data Fair Processing

Data Fair Processing permet de programmer des traitements périodiques. Ils

permettent d'aller récupérer des données à certains endroits, les transformer et les
publier sur Data Fair, ce qui facilite la mise à jour automatique de certains jeux de
données spécifiques.

2.5. Connecteurs de catalogues

Les connecteurs de catalogues permettent d'interagir avec des catalogues de

données, pour moissonner leurs données ou au contraire y publier des jeux de données
hébergés sur Data Fair. Contrairement aux traitements de données périodiques, les
connecteurs de catalogue permettent de synchroniser des ensembles de jeux de
données.

2.6. Notify

Notify est le service responsable de la gestion des notifications de la

plateforme. Il permet en pratique d’envoyer des alertes qui peuvent être transmises
dans le navigateur, sur un smartphone ou par email.

2.7. Analytics

La gestion des Analytics et autres statistiques d'utilisation de la plateforme peut se

faire de 2 manières :

- à l'aide d'un service en ligne externe à la plateforme, tel que Google Analytics
- avec un service Analytics déployé sur la même infrastructure que Data Fair

20
 2.8. Capture

Le service Capture permet de créer des images à partir de visualisations web

ou des documents PDF.

2.9. Thumbor

Thumbor est un service d'imagerie intelligent qui permet de recadrer,

redimensionner, appliquer des filtres et optimiser des images à la demande. Dans le
contexte de data-fair il est utilisé pour le recadrage et le redimensionnement des
graphiques pour une meilleure présentation.

2.10. Backup

Le service Backup permet de sauvegarder les données des différents services

de la plateforme dans un format compressé. Les différentes bases MongoDB6, les
données de data-fair et les utilisateurs de simple-directory sont enregistrées lors d’une
sauvegarde. Il est possible de configurer une sauvegarde périodique ou de déclencher
une sauvegarde manuellement.

2.11. Statistiques API

Le service des statistiques permet d'extraire des statistiques d'utilisation des

API à partir des logs HTTP de services tels que Nginx7. Dans la mesure ou Data Fair
et les différents services associés utilisent beaucoup les mécanismes de cache pour
améliorer les temps d'accès aux ressources, des statistiques précises d'utilisation des
différents points d'accès de la plateforme ne peuvent être extraites qu'après coup.

Les logs d'accès aux API sont publiés sur Data Fair sous la forme d'un jeu de données
qui peut ensuite être exposé partiellement à des organisations en leur proposant les
données filtrées les concernant.

6
MongoDB est un programme de base de données orienté documents, multiplateforme et disponible
sous forme de source. Classé comme un programme de base de données NoSQL, MongoDB utilise des
documents de type JSON avec des schémas optionnels.
7
Nginx est un serveur web qui peut également être utilisé comme proxy inverse, équilibreur de charge,
proxy de messagerie et cache HTTP.

21
 III. EXIGENCES FONCTIONNELLES ET NON
FONCTIONNELLES

Exigences fonctionnelles

Une exigence fonctionnelle est une exigence définissant une fonction du

système à développer. Ce que le système doit faire. Dans notre cas, nous aborderons
les points sur la sécurité, l’interopérabilité et la conformité.

1.1. La sécurité

Cette exigence décrit l’aspect sécuritaire que nous devons adopter dans la mise
en place ce notre système. La sécurité demeure une des exigences fonctionnelles
majeures, le système étant à la base un système d'exposition des données. Aussi, le
nombre important de services à déployer nous poussent à apporter un regard très
particulier à l’aspect de la sécurité, surtout au niveau de la communication entre ces
différents services. Pour notre système, chaque communication entre les services devra
être chiffrée et accessible qu’au ayant droit. Nous devons faire très attention aux
données publiées et à leur confidentialité, elles doivent respecter les règles et normes
en vigueur sur le territoire de leur publication ou selon l'organisation qui les publie.

1.2. L’interopérabilité

L'interopérabilité est la capacité d'un système à communiquer avec d'autres

systèmes en dehors de sa conception. La plus courante consiste à utiliser un système
d'API pour externaliser certaines fonctions. Ce critère est très important pour le bon
fonctionnement de notre système, celui-ci pouvant interagir avec des outils externes
tels que les logiciels de surveillance, d'alertes et de journalisation.

1.3. La conformité

Les exigences fonctionnelles de conformité valident que le système développé

est conforme aux normes industrielles. Dans notre cadre de travail, satisfaire
l’exigence de conformité revient à fournit un système qui respecte les normes et
bonnes pratiques en vigueur dans le domaine des architectures systèmes et du
déploiement d’applications.

22
 Exigences non fonctionnelles

Une exigence non-fonctionnelle est une exigence qui caractérise une propriété
(qualité) désirée du système telle que sa performance, son adaptabilité, sa portabilité,
sa maintenabilité.

2.1. La performance

Compte tenu des nombreux services que la plateforme doit offrir pour
fonctionner, l'un des critères les plus importants du système est la performance. Par
conséquent, le système doit être suffisamment efficace en termes de ressources et de
capacité de stockage pour prendre en charge tous les modules à déployer.

2.2. L’adaptabilité

L'adaptabilité du système est définie comme sa capacité à s'adapter aux

changements d'environnement sans modifier son comportement. Avant que le système
ne passe en production sur les serveurs du gouvernement ivoirien, il doit passer par
une phase d'évaluation dans un environnement de tests et pouvoir s'adapter à
l'environnement de production sans modifier son comportement.

2.3. La portabilité

La portabilité signifie la capacité d'un système logiciel à fonctionner dans

différents environnements, à condition que le cadre sous-jacent de dépendances reste
le même. Cela nécessite que la plateforme et tous ses composants soient installés et
supportés par un système d'exploitation différent de celui utilisé pour le
développement.

2.4. La maintenabilité

La maintenabilité est la capacité d'un équipement à être dépanné, dans un temps

donné, à moindre coût et selon des conditions spécifiées. Il doit aussi retrouver sa
fiabilité initiale. La fiabilité est un autre aspect de la disponibilité. Cette caractéristique
de qualité met l'accent sur la disponibilité du système sous certaines conditions.

Les exigences ci-dessus nous aideront à guider de meilleures décisions sur les
méthodes et les outils à utiliser au fur et à mesure que la recherche progresse.

23
CHAPITRE IV : CONCEPTS ET TYPES

D’ARCHITECTURES TECHNIQUES

I. CONCEPTS

La haute disponibilité

La disponibilité est un enjeu essentiel des infrastructures informatiques. La

haute disponibilité consiste à mettre en place une infrastructure spécialisée, en
appliquant des principes, processus et méthodes dans le but de réduire les charges et
les erreurs, ce qui favorise l’accélération de la reprise d’activité, afin de limiter au
maximum les indisponibilités. Afin d’assurer cette haute disponibilité plusieurs
facteurs sont à considérer tels que la mise à l’échelle, la résilience et la tolérance aux
pannes.

1.1. La mise à l’échelle

La mise à l’échelle ou scalabilité est un terme employé dans le domaine de

l'informatique matérielle et logicielle, pour définir la faculté d'un produit à s'adapter
aux fluctuations de la demande en conservant ses différentes fonctionnalités. [5]

Figure 4: Scalabilité verticale et la scalabilité horizontale (source: https://fr.acervolima.com/)

La mise à l’échelle verticale consiste à augmenter les capacités (RAM, CPU) d’une
même machine alors que la mise à l’échelle horizontale augmente le nombre de
ressources.

24
 1.2. La résilience

Dans le domaine des technologies de l'information, la résilience fait référence

à la capacité d'un système informatique à continuer de fonctionner face à des pannes,
des incidents, des piratages ou une augmentation des opérations commerciales. Il s'agit
de mettre en place des "mesures de protection" pour minimiser l'impact des problèmes
informatiques sur l’ensemble ou une partie du système. [6]

En plus de protéger les données en cas de piratage, de vol ou de sinistre, il est

également important de maintenir le bon fonctionnement du système. En tant que tel,
le concept de résilience informatique comprend un ensemble de mesures et de
processus pour résoudre les problèmes potentiels.

1.3. La tolérance aux pannes

Un système est tolérant aux pannes s'il peut continuer à fonctionner malgré la
défaillance de certains composants. Ceci nous permet de renforcer la robustesse de
notre infrastructure. Dans le cas des serveurs de déploiement de système d'exploitation,
le système dans son ensemble est tolérant aux pannes si les serveurs de déploiement
de système d'exploitation font office de machines de secours les unes pour les autres.
Lorsqu'un serveur tombe en panne, les autres serveurs gèrent ses requêtes. [7]

Figure 5: Tolérance aux pannes, exemple (Source : https://www.wallarm.com/ )

25
 La conteneurisation

Selon Red Hat, La conteneurisation consiste à rassembler le code du logiciel et

tous ses composants (bibliothèques, frameworks et autres dépendances) de manière à
les isoler dans leur propre espace (« conteneur »).

Figure 6: Architecture de la conteneurisation (Source : https://www.lebigdata.fr)

Cette isolation de l’application facilite son déplacement entre les plateformes et

infrastructures car l’application dispose de tout ce dont elle a besoin dans le conteneur.

Les conteneurs simplifient le processus de création, de test, et de déploiement des

applications sur différents types de plateformes depuis un poste de travail local vers
un data center sur site ou même dans le cloud. Ces principaux avantages sont :

- moins de ressources nécessaires ;

- une portabilité accrue ;

- fonctionnement plus cohérent ;

- meilleure efficacité et développement d’applications.

Les conteneurs sont un exemple parfait d'architecture de microservices, car ils nous
permettent de nous concentrer sur le développement des services sans avoir à nous
soucier des dépendances. Les applications cloud natives modernes sont généralement
construites sous forme de microservices à l'aide de conteneurs.

26
 Orchestrateurs de conteneurs

L’orchestration des containers désigne le fait d’automatiser le déploiement, la

gestion, la mise à l'échelle et la mise en réseau des conteneurs. Les outils
d'orchestration des conteneurs Docker les plus connus sont Docker Swarm et
Kubernetes.

3.1. Docker swarm

Intégré à Docker Engine depuis sa version 1.12 (2016), Docker Swarm est
l’outil d’orchestration natif de Docker qui permet de gérer une multitude de conteneurs
déployés sur une machine hôte. Il offre une haute disponibilité aux applications à
travers ces nombreux nœuds “workers” gérés par un nœud maître. [8]

Figure 7 : Docker swarm (source : docs.docker.com)

Docker swarm est très efficace dans la gestion des ressources pour les conteneurs.

3.2. Kubernetes

Kubernetes est une plateforme open source d’orchestration de conteneurs

permettant d’automatiser le déploiement, la mise à échelle et la gestion des
applications conteneurisées. Il est initialement développé par Google à l’image de son
propre système d’orchestration en interne (Borg). Kubernetes a l’avantage docker
swarm car contrairement à ce dernier, il offre d’énormes possibilités d’administration
et de gestion des nœuds, et permet de créer un système complet en fonction de nos
ressources. [9]

27
 II. ETUDE ARCHITECTURALE

Etude détaillée de Kubernetes

1.1. Architecture

Figure 8: Architecture de Kubernetes (source : https://medium.com)

1.2. Composants

1.2.1. Le control plane (master node)

Les composants Master fournissent le plan de contrôle du cluster. Ils prennent

des décisions globales à propos du cluster.

Les composants Master peuvent être exécutés sur n'importe quelle machine du cluster.
Toutefois, par souci de simplicité, les scripts de mise en route démarrent typiquement
tous les composants master sur la même machine et ne s'exécutent pas de conteneurs
utilisateur sur cette machine. Les différents composants du control plane sont :

- kube-apiserver : composant sur le master qui expose l'API Kubernetes. Il

s'agit du front-end pour le plan de contrôle Kubernetes ;

- etcd : Base de données clé-valeur consistante et hautement disponible utilisée

comme mémoire de sauvegarde pour toutes les données du cluster ;

28
 - kube-scheduler : composant qui surveille les pods nouvellement créés qui ne
sont pas assignés à un nœud et sélectionne un nœud sur lequel ils vont
s'exécuter. Les facteurs pris en compte pour les décisions de planification
(scheduling) comprennent les exigences individuelles et collectives en
ressources, les contraintes matérielles/logicielles/politiques, les spécifications
d'affinité et d'anti-affinité, la localité des données, les interférences entre
charges de travail et les dates limites.
- Kube-Controller-manager : composant qui exécute les contrôleurs.
- node controller : responsable de détecter et apporter une réponse
lorsqu'un nœud tombe en panne ;
- replication controller : responsable de maintenir le bon nombre de
pods pour chaque objet ReplicationController dans le système ;
- endpoints controller : remplit les objets Endpoints (c'est-à-dire joint
les Services et Pods) ;
- service account & token controllers : créent des comptes par défaut
et des jetons d'accès à l'API pour les nouveaux namespaces.

- cloud-controller-manager : Le cloud-controller-manager exécute les

contrôleurs qui interagissent avec les fournisseurs cloud sous-jacents.

1.2.2. Le data plane (worker node)

Les workers sont des nœuds qui sont chargés d'exécuter les applications dans des pods.
Ils sont composés de:

- kubelet : agent qui s'exécute sur chaque nœud du cluster et s'assure que les
conteneurs fonctionnent dans un pod ;
- kube-proxy : proxy réseau qui s'exécute sur chaque nœud du cluster et
maintient les règles réseau sur les nœuds ;
- container runtime : logiciel responsable de l'exécution des conteneurs.

29
 1.3. Concepts

1.3.1. Les Pods

Un pod est un groupe d'un ou plusieurs conteneurs, avec des ressources de

stockage et de réseau partagées, et une spécification sur la façon d'exécuter les
conteneurs. Le contenu d'un pod est toujours co-localisé et co-planifié, et s'exécute
dans un contexte partagé. Un pod modélise un "hôte logique" spécifique à une
application : il contient un ou plusieurs conteneurs d'applications relativement bien
couplés.
Dans les contextes non cloud, les applications exécutées sur la même machine
physique ou virtuelle sont analogues aux applications cloud exécutées sur le même
hôte logique. [10]
1.3.2. Les contrôleurs

Les contrôleurs sont des abstractions de niveau supérieur qui s'appuient sur les
objets de base et fournissent des fonctionnalités supplémentaires. Les principaux
contrôleurs en Kubernetes sont :
- deploiement : un déploiement fournit des mises à jour déclaratives pour les
Pods et les ReplicaSets ;
- replicatSet : l'objectif d'un ReplicaSet est de maintenir un ensemble stable de
répliques de pods en fonctionnement à tout moment ;
- statefulSet : le StatefulSet est l'objet de l'API de charge de travail utilisé pour
gérer les applications avec état. Il gère le déploiement et la mise à l'échelle d'un
ensemble de pods, et fournit des garanties sur l'ordre et l'unicité de ces pods.
- daemonSet : un DaemonSet garantit que tous les nœuds (ou certains)
exécutent une copie d'un Pod. Lorsque des nœuds sont ajoutés au cluster, des
pods leur sont ajoutés. Lorsque des nœuds sont retirés du cluster, ces pods sont
mis au rebut ;
- jobs : un Job crée un ou plusieurs Pods et continue à essayer l'exécution des
Pods jusqu'à ce qu'un nombre spécifié d'entre eux se termine avec succès ;
- cronJobs : une CronJob crée des Jobs selon un calendrier répétitif. Il exécute
un Job périodiquement selon un calendrier donné, écrit au format Cron.

30
 1.3.3. Les services

Dans Kubernetes, un service est une abstraction qui définit un ensemble

logique de pods et une politique permettant d'y accéder (parfois ce modèle est appelé
un micro-service). L'ensemble des pods ciblés par un service est généralement
déterminé par un selector. Un selector est un champ que possède un service dans lequel
il specifie les pods qu’il veut atteindre au moyen de leurs labels (étiquette qui identifie
un pod) Il existe quatre types de service : NodePort, ClusterIp, ExternalName et
LoadBalancer.

1.3.4. Configuration

Pour gérer la configuration, les principales ressources utilisées par Kubernetes

sont les configMaps et les secrets.
1.3.4.1. configMap

Un ConfigMap est un objet de l'API qui vous permet de stocker une

configuration que d'autres objets peuvent utiliser. Contrairement à la plupart des objets
Kubernetes qui ont une spécification, un ConfigMap a des champs data et binaryData.
Ces champs acceptent des paires clé-valeur comme valeurs.

1.3.4.2. Secrets

Un secret est un objet qui contient une petite quantité de données sensibles,
comme un mot de passe, un jeton ou une clé. Ces informations pourraient autrement
être placées dans une spécification de Pod ou dans une image de conteneur.
1.3.5. Stockage

Pour la gestion de stockage, kubernetes utilise les volumes persistants.Un

PersistentVolume (PV) est un élément de stockage dans le cluster qui a été provisionné
par un administrateur ou dynamiquement à l'aide de Storage Classes. Il s'agit d'une
ressource dans le cluster, tout comme un nœud est une ressource du cluster. Les PV
sont des plugins de volume comme les Volumes, mais ont un cycle de vie indépendant
de tout Pod individuel qui utilise le PV.

Les PV sont fournis par des fournisseurs de stockage qui doivent être installés au
préalable.

31
 1.4. Distributions

1.4.1. Kubeadm

Kubeadm aide à démarrer un cluster Kubernetes minimum, viable et conforme

aux meilleures pratiques. Avec Kubeadm, votre cluster doit passer les tests de
conformité Kubernetes. Kubeadm prend également en charge d'autres fonctions du
cycle de vie, telles que les mises à niveau, la rétrogradation et la gestion des jetons.

Tableau 4: Avantages et inconvénients de Kubeadm

Avantages Inconvénients
Méthode d'installation officielle Toujours en version bêta
Installation sans effort L'installation HA nécessite le
développement d'un fichier manifeste
Peut être utilisé en mode cloud ou bare- Installation de bas niveau
metal

1.4.2. Kubespray

Kubespray est un Framework pour installer et gérer les services systemd et les
pods statiques. Il utilise Kubeadm en arrière-plan. En général, kubespray est géré par
des playbooks ansibles. Il existe également un module Terraform.

Tableau 5: Avantages et Inconvénients de Kubespray

Avantages Inconvénients
Installation déclarative avec variables et L'installation très longue (plus de 30
inventaire minutes)
Disponible pour les installations sur Nécessite beaucoup de prérequis
site, sur métal et dans le cloud. matériels et logiciels.
Personnalisation facile avec Ansible
Prise en charge des modules
complémentaires Kubernetes
personnalisés.
Il dispose de modules terraform pour les
environnements AWS et OpenStack.

32
 1.4.3. Ranger

Rancher est une pile logicielle complète pour les équipes qui adoptent les
conteneurs. Elle répond aux défis opérationnels et de sécurité liés à la gestion de
plusieurs clusters Kubernetes, tout en fournissant aux équipes DevOps des outils
intégrés pour l'exécution des charges de travail conteneurisées. [11]

Figure 9: Architecture de Rancher

Rancher propose trois distributions pour l'initialisation d’un cluster Kubernetes.

33
 1.4.3.1. K3S

K3s est une distribution conçue pour les applications IoT et edge. Elle supprime
de nombreuses fonctionnalités/plugins obsolètes et remplace les composants
Kubernetes par des alternatives légères pour atteindre des tailles binaires allant jusqu'à
60 Mo. Par exemple, K3S utilise sqlite plutôt que etcd. K3S est recommandé pour les
installations locales, en dev, test ou statging. [12]

Tableau 6: Avantages et inconvénients de K3S

Avantages Inconvénients
faibles besoins en ressources et faible Nécessite un développement pour une
coût. charge importante.
C'est une option parfaite pour les
installations locales.

1.4.3.2. RKE

RKE est un nouvel outil de Rancher qui permet d'installer et de gérer des
composants Kubernetes sous forme de conteneurs docker ou de clusters Kubernetes.
RKE peut être exécuté dans le cloud ou sur site.

Tableau 7 : Avantages et inconvénients de RKE2

Avantages Inconvénients
Installation facile Nouvelle solution pour les installations
et la gestion de kubernetes
Approche déclarative, un seul YAML
Automatisation facile
Peut être utilisé sur le cloud ou le bare-
metal
Bien documenté
Solution de backup pour etcd

34
 1.4.3.3. RKE2

RKE2, également connue sous le nom de RKE Government, est la distribution

Kubernetes de nouvelle génération de Rancher. Il s'agit d'une distribution Kubernetes
entièrement conforme qui se concentre sur la sécurité et la conformité au sein du
secteur du gouvernement fédéral américain. Pour atteindre ces objectifs, RKE2 fait ce
qui suit :

- fournit des valeurs par défaut et des options de configuration qui permettent
aux clusters de passer le CIS Kubernetes Benchmark v1.6 avec une
intervention minimale de l'opérateur ;
- permet la conformité à la norme FIPS 140-2 ;
- analyse régulièrement les composants pour détecter les CVE à l'aide de Trivy
dans notre pipeline de construction.

RKE2 combine le meilleur des deux mondes à partir de la version 1.x de RKE (ci-
après dénommé RKE1) et K3s.

De K3s, il hérite de la convivialité, de la facilité d'utilisation et du modèle de

déploiement.

De RKE1, il hérite d'un alignement étroit avec Kubernetes en amont. Par endroits, K3s
s'est écarté de Kubernetes amont afin d'optimiser les déploiements en périphérie, mais
RKE1 et RKE2 peuvent rester étroitement alignés sur l'amont.

Il est important de noter que RKE2 ne s'appuie pas sur Docker comme le fait RKE1.
Il lance les composants du plan de contrôle en tant que pods statiques, gérés par le
kubelet. Le moteur d'exécution de conteneur intégré est containerd.

Dans le choix d’une distribution nous recherchons une solution mature, complète et
qui respecte les exigences de sécurité et conformité citées plus haut. Kubespray et
Kubeadm sont assez bas niveau et ne fournissent pas d’outils pour de la gestion facile
du cluster. Quant à K3S ; il est plus adapté pour les environnements de développement
et de tests. RKE 2 sera donc notre choix de distribution kubernetes, car il réunit tous
les outils nécessaires pour la mise en place d’un cluster Kubernetes en production et
respecte les exigences telles que la sécurité et la conformité.

35
 Facteurs clés à considérer dans la mise en place du système

2.1. La sécurité

La sécurité est le premier facteur qui retient notre attention dans la mise en
place d’un tel système. Le système étant constitué de plusieurs modules qui
communiquent entre eux, cela favorise plus d'interactions et donc une multitude de
trafics qui doivent être surveillés avec précaution afin de s’assurer qu’aucune donnée
n’est compromise durant son transfert et même pendant son stockage. Dans le domaine
de la sécurité informatique, l’une des meilleures pratiques recommandées par les
experts et même étudiée en cours est l’application de la défense en profondeur. Il s’agit
d’une approche multicouche qui consiste à protéger un système à plusieurs niveaux
superposés.

Figure 10: Défense en profondeur

Dans notre contexte, étant donné que nous travaillons avec un cluster, nous pouvons
appliquer une couche de sécurité dédiée à celui-ci, c'est-à-dire la sécurité du cluster.
Cette couche pourrait se situer entre celle de l'hôte et celle de l’application. Chaque
niveau ou couche de sécurité engage des responsabilités propres qui peuvent différer
d'acteurs, de procédures et d'outils.

36
Dans notre étude nous nous intéresserons plus précisément aux couches de sécurité qui
incombent notre responsabilité, c'est-à-dire la sécurité des machines, du cluster, des
applications et des données.

2.1.1. Sécurité des hôtes

La sécurité de l'hôte consiste à protéger les machines virtuelles de toutes les

attaques externes.

2.1.1.1. Connexion et accès sécurisés

Lorsqu’on dispose d’ordinateurs distants, la première chose à faire en matière de

sécurité est de sécuriser leur accès. Pour ce faire, nous envisageons d'utiliser un
protocole de communication sécurisé. La communication SSH est devenue la norme
de communication entre les ordinateurs d'un même réseau.

Figure 11: Communication SSH (source : https://doubleoctopus-com.translate.goog)

Secure Socket Shell est un protocole sécurisé qui connecte un client à un compte
administrateur (compte shell) sur un système serveur, généralement dans le but
d'effectuer des tâches d'administration système [13].

Contrairement à son conquérant Telnet, SSH utilise le cryptage pour empêcher les
attaques "man-in-the-middle".

37
 2.1.1.2. Intégration de bastion

En sécurité des systèmes d'information, un bastion est un élément d'un réseau

informatique qui est placé dans une partie accessible de l'extérieur comme Internet,
soit en le plaçant devant un pare-feu, soit dans une zone démilitarisée d'un intranet
(Système d'Information Privé).

Figure 12: Architecture avec bastion (source: https://blog.octo.com)

Un hôte bastion est utilisé pour isoler les activités privées des attaques extérieures
tout en fournissant des services accessibles de l'extérieur. Dans ce cadre, nous
l'utilisons pour nous connecter aux différentes machines du cluster et conserver les
données sensibles échangées entre elles.

2.1.1.3. Restriction d’adresse IP et de ports

Par défaut, Kubernetes nécessite l'ouverture de certains ports pour les services de
type NodePort. Cependant, pour des raisons de sécurité, nous évitons d'utiliser ce type
de service et n'autorisons que le port 80 pour accéder à ces services. Cela nécessite la
mise en œuvre d'une ressource d'entrée dans le but de rediriger les demandes entrantes
vers le service approprié.

38
 2.1.2. Sécurité du cluster

La sécurité du cluster consiste à mettre en place des outils et politiques de

gouvernance au sein du cluster dans le but de sécuriser l'accès à certaines ressources
et prévenir d’éventuelles manipulations qui pourraient causer son dysfonctionnement.

2.1.2.1. Politique de sécurité des pods (Pod security

policy)

Une politique de sécurité des pods est une ressource de niveau cluster qui contrôle
les aspects sensibles de la sécurité de la spécification des pods. Les objets
“PodSecurityPolicy” définissent un ensemble de conditions qu'un pod doit respecter
pour être accepté dans le système, ainsi que des valeurs par défaut pour les champs
associés. Nous l’utiliserons dans notre contexte pour définir un modèle à suivre pour
l’installation de toutes les applications de notre cluster. Les pods qui ne respecteront
pas ce schéma ne pourront être installés sur le cluster.

2.1.2.2. Budget de perturbation des pods

Un budget de perturbation des pods (PDB) permet de limiter la perturbation de

notre application lorsque ses pods doivent être reprogrammés pour une raison
quelconque, comme des mises à niveau ou des travaux de maintenance de routine sur
les nœuds Kubernetes. En tant que propriétaire d'une application, nous pouvons créer
une ressource “PodDisruptionBudget” (PDB) pour chaque application. Une PDB
limite le nombre de Pods d'une application répliquée qui sont hors service
simultanément à cause de perturbations volontaires. Cette ressource est très utile pour
éviter les erreurs humaines qui peuvent entraîner le dysfonctionnement de l'application
ou du système entier.

2.1.2.3. Les comptes de services

Un compte de service (ServiceAccount) fournit une identité pour les processus qui
s'exécutent dans un Pod. À cette identité peut être lié des rôles et permissions afin de
restreindre ses actions dans le cluster. Dans notre contexte, nous les utilisons pour
restreindre les droits d’administration à certains pods de l’application car par défaut ils
en disposent tous. [14]

39
 2.1.2.4. Contrôle d'accès basé sur les rôles

Le contrôle d’accès basé sur le rôle (RBAC) est un mécanisme de contrôle

d’accès qui définit les rôles et les autorisations de chaque utilisateur. Les rôles sont
définis en fonction de caractéristiques telles que l’emplacement, le service,
l’ancienneté ou les tâches d’un utilisateur. Les autorisations sont attribuées en fonction
de l’accès (ce que l’utilisateur peut voir), des opérations (ce que l’utilisateur peut faire)
et des sessions (pendant combien de temps l’utilisateur peut le faire) [15].

Avec Kubernetes les ressources chargées du RBAC sont les “Role”,

“ClusterRole”, “RoleBinding” et “ClusterRoleBinding”. Les “Role” et “ClusterRole”
contiennent des règles qui représentent un ensemble de permissions. Les permissions
sont purement additives (il n'y a pas de règles de "refus"). Une ressource “Role” définit
toujours les permissions dans un espace de nom particulier ; lorsque vous créez un
rôle, vous devez spécifier l'espace de nom auquel il appartient.

“ClusterRole”, en revanche, est une ressource sans espace de noms. Les ressources ont
des noms différents (“Role” et “ClusterRole”) parce qu'un objet Kubernetes doit
toujours être soit namespaced soit non namespaced ; il ne peut pas être les deux.

Les ClusterRoles ont plusieurs usages. Nous pouvons les utiliser pour :

- définir des autorisations sur des ressources à espace de noms et se voir accorder
un accès au sein d'un ou de plusieurs espaces de noms individuels ;
- définir des autorisations sur des ressources d'espace de noms et obtenir l'accès
à travers tous les espaces de noms ;
- définir des permissions sur des ressources à l'échelle du cluster.

Les ressources “RoleBinding” et “ClusterRoleBinding” permettent de lier

respectivement un “Role” et un “ClusterRole” à un compte de service, un utilisateur
ou un groupe. [15]

40
 2.1.3. Sécurité des applications

2.1.3.1. La communication HTTPS

A l’instar des hôtes, la communication entre applications nécessite d'être

sécurisée afin de préserver la confidentialité des informations échangées entre elles.
L’un des meilleurs moyens de le faire avec les applications web est d’utiliser le
protocole HyperText Transfer Protocol Secure (HTTPS). Le protocole HTTPS est une
combinaison du HTTP (non sécurisé) avec une couche de chiffrement comme SSL ou
TLS qui permet de sécuriser le transfert d’informations entre un client et un serveur
ou deux applications web.

Figure 13: Communication HTTPS

Avec cette couche de sécurité en plus, d’éventuels attaquants “Homme du milieu”8 ne

pourront exploiter les données qu’ils auront interceptées car elles seront chiffrées.

Dans notre étude, nous nous intéresserons plus précisément au processus

d'établissement d’une connexion HTTPS entre un client quelconque et nos serveurs,
depuis la génération des clés des certificats de notre domaine jusqu'à leur
implémentation sur lesdits serveurs. À ce jour, nous connaissons deux moyens de
signer les certificats pour nos applications web. Les certificats auto-signés ou les
certificats signés par des tiers de confiance appelés les autorités de certifications.

8
L’Homme du milieu ou encore Man in the Middle est une pratique couramment utilisée par les pirates
informatiques dans le but d’intercepter les informations pendant les échanges entre deux ou plusieurs nœuds.

41
 2.1.3.1.1. Les autorités de certifications

En cryptographie, une autorité de certification est un tiers de confiance

permettant d'authentifier l'identité des correspondants. Elle délivre des certificats
décrivant des identités numériques et met à disposition les moyens de vérifier la
validité des certificats qu'elle a fournis. [16] Pour activer le HTTPS sur notre
application web, nous devrons donc obtenir un certificat auprès d’une autorité de
certification (AC).

Pour ce faire nous utiliserons un AC open source, gratuit et reconnu par les
navigateurs web, letsEncrypt. Afin d’obtenir un certificat pour le domaine de notre
application auprès de Let’s Encrypt, nous devons apporter la preuve que nous avons
le contrôle du domaine. Avec Let’s Encrypt, cela est possible en utilisant un logiciel
qui utilise le protocole ACME qui fonctionne généralement sur les hôtes web.

2.1.3.1.2. Le protocole Automated Certificate

Management Environment (ACME)

Le protocole ACME est un protocole de communication pour l'automatisation

des échanges entre les autorités de certification et les propriétaires de serveur web,
permettant le déploiement automatisé d’une infrastructure à clé publique. [17] Il
permet à l'autorité de certification de communiquer directement avec le serveur afin
d'obtenir et installer des certificats SSL/TLS. En pratique, cette opération s’effectue
sans nécessiter aucune intervention humaine, et cela grâce aux challenges ACME.

2.1.3.1.3. Les challenges ACME

Les challenges ACME sont des tests qui permettent aux autorités de
certification de vérifier que nous sommes bien propriétaire de notre nom de domaine.
Le challenge que nous avons choisi de relever doit être rempli afin que nous recevions
les certificats de votre domaine à installer sur votre serveur.

42
 ➢ Le challenge HTTP (HTTP 01)

Dans ce défi, l'Autorité de Certification demande au client d'héberger un

nombre aléatoire sur une URL aléatoire sur le port 80 au chemin /.well-known/acme-
challenge. L’AC valide le contrôle client en envoyant une requête HTTP GET à cette
URL. C'est un défi polyvalent. En hébergeant un défi-réponse sur HTTP sur le port 80,
le client prouve qu'il contrôle un port protégé pour le domaine demandé. Le type de
défi http-01 est le plus facile à configurer car n'importe quel serveur Web peut héberger
la réponse au défi sous forme de fichier statique.

➢ Le challenge DNS (DNS-01)

L'AC ACME demande au client de fournir un enregistrement TXT DNS

aléatoire pour le domaine en question. Elle vérifie le défi en interrogeant le DNS pour
cet enregistrement TXT. Ce défi convient lorsque le serveur ACME ne peut pas
atteindre directement le domaine demandé. Dans ce cas, nous devons être en mesure
d'effectuer une recherche DNS pour confirmer notre requête. Cependant, la
configuration du client DNS-01 est généralement plus complexe, car le client ACME
nécessite la modification des enregistrements DNS.

➢ Le challenge TLS ALPN (tls-alpn-01)

L'autorité de certification ACME utilise TLS pour valider un défi, en tirant

parti de la négociation du protocole de la couche d'application (ALPN). Le client
présente un certificat TLS auto-signé contenant la réponse au défi sous la forme d'une
extension spéciale de certificat X.509. Ce type de défi est utile lorsqu'une politique de
sécurité exige que l'AC atteigne le client via une connexion TLS. Il s'agit d'un type de
défi populaire dans les cas où un contrôleur d'entrée fait face aux clients qui tentent de
recevoir un certificat.

43
 2.1.3.2. La restriction de domaine

La restriction de domaine est une technique qui permet de limiter les domaines
autorisés à interagir avec notre application. Cela réduit les angles d’attaques car pour
attaquer, il faudrait utiliser une application de notre système hébergée sur un nom de
domaine que nous avons autorisé. Dans notre cas, sa mise en place nécessite d'héberger
tous les services de data-fair à partir d’un même domaine et d’utiliser un proxy pour
rediriger les requêtes vers le service concerné en fonction du chemin de ladite requête.
Nous illustrons le principe à travers la figure suivante.

Figure 14: Restriction de domaine

Dans cette illustration la requête sera redirigée vers le service Thumbor et toute requête
provenant d’un domaine autre que datafair.data354.com n’aura aucune suite.

2.1.3.3. L’utilisation de pare-feu applicatif

Les pare-feux applicatifs, ou pare-feux en couche d’application, utilisent une

série de politiques configurées pour déterminer s’il faut bloquer ou autoriser les
communications vers ou depuis une application. Alors que les pare-feux traditionnels
contrôlent le flux de données vers et depuis l’unité centrale, en examinant chaque
paquet lors de son passage, un pare-feu applicatif va plus loin en contrôlant l’exécution
des fichiers ou du code par des applications spécifiques. De cette façon, même si un
intrus pénètre dans un réseau ou un serveur, il ne peut pas exécuter de code malveillant.

44
 Figure 15: Utilisation de pare-feu applicatif (source : https://www.nginx.com)

Un pare-feu applicatif peut être actif ou passif. Les pare-feux applicatifs actifs
inspectent activement toutes les requêtes entrantes, y compris le message effectif
échangé, pour détecter toute vulnérabilité connue comme des injections SQL, des
altérations de paramètres ou de cookies, et des scripts intersites9. Seules les requêtes
considérées « propres » sont passées à l’application.

Les pare-feux applicatifs passifs se comportent de manière similaire à un

système de détection d’intrusion (IDS) c’est-à-dire qu’ils inspectent également toutes
les requêtes entrantes pour y détecter des vulnérabilités connues, mais sans rejeter ou
refuser activement ces requêtes si une attaque potentielle est découverte. [18]

9
Scripts intersites : Les scripts intersites (XSS ou CSS) sont une forme d’attaque d’application Web, utilisée pour
accéder à des informations privées en fournissant du code malveillant aux utilisateurs finaux via des sites Web de
confiance.

45
 2.1.4. Sécurité des données

La sécurité des données est entièrement à la charge du fournisseur de stockage.

Comme nous l’avons vu plus haut, les fournisseurs de stockage stockent les données
dans des volumes persistants qu’ils peuvent chiffrer par la suite. Dans notre cas, le
fournisseur de stockage Longhorn prend en charge les volumes chiffrés en utilisant
une solution de chiffrement de disque basée sur le noyau Linux (LUKS, Linux Unified
Key Setup). Pour cela le module dm_crypt10 devra être chargé et cryptsetup11 installé
sur les nœuds de travail [19].

2.2. Surveillance, alertes et journaux

2.2.1. Description

La surveillance est un ensemble de pratiques d'analyse et de contrôle des

métriques pertinentes qui donnent des informations nécessaires sur l’état d’un système.

Les alertes donnent plus de sens à la surveillance, car permettent de garantir la

promptitude de l'équipe d'opérations en cas d’urgence. Sans la programmation
d’alertes, le système devra être constamment dirigé par l’humain dans le but de déceler
les éventuelles pannes. Ces alertes portent généralement sur les métriques recueillies
dans la phase de surveillance et sont classées par ordres de priorité.

Les journaux sont un peu différents du monitoring. Il s’agit d’une technique

qui permet de retracer toutes les actions et interactions effectuées sur le système par
les utilisateurs ou d’autres services externes. S’avoisinant au monitoring (vu plus haut)
son but est d’avoir des informations précises et détaillées sur le déroulement des
opérations liées au systèmes, et connaître éventuellement la source de problèmes en
cas de panne.

10
dm crypt: dm-crypt est un sous-système transparent de chiffrement de disques dans le noyau Linux versions
2.6 et supérieur.
11
cryptsetup: cryptsetup est un utilitaire disponible sur les systèmes linux qui permet de chiffrer des partitions de
disque.

46
 2.2.2. Monitoring de cluster

Le monitoring de cluster consiste à collecter toutes les données sur les nœuds
qui composent le cluster telles que les charges de travail en cours d'exécution, en
attentes ou en échec, les ressources (Mémoire disques, mémoire RAM et CPU)
utilisées et/ou restantes, le but étant de surveiller l'état de santé du cluster. Ce type de
monitoring est important car combiné aux alertes permet aux équipes de réagir
rapidement en cas de défaillance d'un nœud. Il est géré entièrement par
l’administrateur du cluster.

2.2.3. Monitoring des applications

Le monitoring d'applications est plus axé sur le métier, c'est-à-dire les données
liées aux fonctions de l’application. Ce type de monitoring est de la responsabilité du
développeur de l’application.

2.2.4. Prometheus

Prometheus est une boîte à outils open-source de surveillance des systèmes et

d'alerte construite à l'origine chez SoundCloud. Depuis sa création en 2012, de
nombreuses entreprises et organisations ont adopté Prometheus, et le projet dispose
d'une communauté de développeurs et d'utilisateurs très active. Il s'agit désormais d'un
projet open source autonome et maintenu indépendamment de toute entreprise. Sa
particularité est qu’il peut être utiliser pour la surveillance, les alertes et les journaux.

Prometheus collecte et stocke ses métriques sous forme de données de séries

temporelles, c'est-à-dire que les informations relatives aux métriques sont stockées
avec l'horodatage auquel elles ont été enregistrées, aux côtés de paires clé-valeur
facultatives appelées étiquettes.

47
Figure 16: Architecture Prometheus (source: https://prometheus.io/)

Les principales caractéristiques de Prometheus sont les suivantes :

- un modèle de données multidimensionnel avec des données de séries

temporelles identifiées par un nom de métrique et des paires clé/valeur ;
- promQL, un langage d'interrogation flexible pour exploiter cette
dimensionnalité ;
- aucune dépendance à l'égard du stockage distribué ; les nœuds de serveur
unique sont autonomes ;
- la collecte des séries temporelles s'effectue via un modèle "pull" sur http ;
- le chargement de séries temporelles est pris en charge par une passerelle
intermédiaire ;
- les cibles sont découvertes via la découverte de services ou la configuration
statique ;
- plusieurs modes de prise en charge des graphiques et des tableaux de bord.

48
 2.3. Sauvegarde et restauration

La sauvegarde est un excellent moyen de prévenir d’éventuelles catastrophes

et d'assurer une reprise de service rapide à la suite de celles-ci. Dans le cadre de notre
étude, nous nous intéresserons plus précisément à la sauvegarde et la restauration du
cluster et de l’application.

2.3.1. Sauvegarde du cluster

La sauvegarde du cluster nous permet de conserver l'état de celui-ci, c'est-à-

dire les configurations, les ressources et applications installées. Elle est d’une utilité
majeure lors des reprises de service après des catastrophes ou pannes inopinées. Dans
l’univers Kubernetes, la sauvegarde du cluster est généralement assurée par la
distribution en fonction de son niveau. La distribution que nous avons choisie dans le
cadre de notre étude, RKE2, dispose des fonctions de sauvegarde et restauration que
nous utiliserons dans la phase d'implémentation.

2.3.2. Sauvegarde des données de l’application

La sauvegarde des données de l’application, quant à elle concerne les données

internes à celle-ci, c’est-à-dire les informations contenues dans les bases de données
liées à l’application. Dans ce cas, la sauvegarde est assurée par le système de gestion
de la base de données.

2.4. Migration des données

Dans notre cas de figure, la plateforme ayant été hébergée et gérée par une
entreprise étrangère, a engendré plusieurs données importantes qui doivent être
migrées dans les centres de données du gouvernement ivoirien. Notre tâche concernant
cette migration des données se fera en collaboration avec l’entreprise qui héberge
actuellement la plateforme. Cependant notre système doit être capable de les exploiter
ou de les convertir dans le même but.

49
 2.5. Tests

Les tests sont importants pour prouver la robustesse et la qualité du système

mis en place. Il existe plusieurs types de tests tels que les tests de performance, les
tests fonctionnels et les tests structurels. Dans notre contexte nous ne pouvons
effectuer ni les tests fonctionnels ni les tests structurels car ceux-ci sont à la charge du
développeur de l’application. En tant que responsable de l’architecture de déploiement,
les tests que nous effectuerons seront des tests de performance et certains tests pour
évaluer la réaction du système face aux éventuelles pannes telles que le
dysfonctionnement d'un nœud ou des erreurs de configuration.

2.6. Automatisation

L’automatisation est l’un des facteurs les plus importants, surtout quand on a à
sa charge un système complexe composé de plusieurs nœuds. Il existe plusieurs
niveaux d’automatisation en fonction de nos attentes.

- l’initialisation du cluster : mettre en place le cluster Kubernetes avec tous ces

composants, le control-plane et tous les nœuds workers. Après cette
initialisation, le cluster devrait être opérationnel et accessible aux clients pour
utilisation.
- l’installation des prérequis : installer tous les prérequis applicatifs tels que
les applications de surveillance et les fournisseurs de stockage pour assurer le
bon fonctionnement de notre système ;
- l’installation de data fair : Installer tous les composants de data-fair, notre
plateforme open data ;
- la migration des données : faire migrer toutes les données de data fair dans le
nouveau cluster.

En fonction de nos besoins nous pouvons décider d’automatiser tout le processus ou

de s'arrêter à une phase précise et continuer manuellement. En ce qui concerne notre
projet, nous nous arrêterons à l’installation de la plateforme data-fair car la migration
des données nécessite encore un support extérieur, celui des hébergeurs actuels de la
plateforme.

50
 Proposition finale du système

3.1. Architecture

Figure 17: Architecture finale du système

A la fin de notre étude, nous obtenons un système distribué sur trois serveurs d’un
cluster administrer par Kubernetes. Pour notre environnement de test nous
travaillerons avec trois machines virtuelles dont les capacités sont :
- 2 vCPU ;
- 60 Gi de disque SSD & 8 Gi de RAM ;
- système d’exploitation Debian 11.
Les serveurs externes seront des ressources cloud.

3.2. Caractéristiques

Les caractéristiques de notre système sont les suivantes :

- l’application est accessible via HTTPS sur les ports 443 et 80 ;

- la ressource Ingress redirige tout le trafic vers les services appropriés ;
- les sauvegarde de cluster et des PV se font sur des serveurs externes ;
- un nœud maître et deux nœuds workers ;
- le bastion sert pour les connexions SSH aux différents serveurs du cluster.

51
PARTIE III : REALISATION, RESULTATS
ET DISCUSSION

52
Cette partie est divisé en niveaux de code et de configuration qui retracent
chronologiquement l’implémentation des méthodes et outils choisis lors de la phase
conceptuelle. Il s’agira aussi de présenter les résultats de notre étude et de les
confronter.

CHAPITRE 5 : APPLICATION DE L'ÉTUDE

TECHNIQUE

I. PRÉPARATION DE L’ENVIRONNEMENT DE
DÉPLOIEMENT

Initialisation du cluster Kubernetes

1.1. Initialisation de RKE 2 sur le control plane

sudo -s
curl -sfL https://get.rke2.io | sh -
systemctl enable rke2-server.service
systemctl start rke2-server.service
journalctl -u rke2-server -f

1.2. Initialisation RKE 2 agent sur chacun des nœuds

sudo -s
curl -sfL https://get.rke2.io | INSTALL_RKE2_TYPE="agent" sh -
systemctl enable rke2-agent.service
mkdir -p /etc/rancher/rke2/
nano -m /etc/rancher/rke2/config.yaml

53
 1.3. Installation de Rancher dans le cluster

kubectl create namespace cattle-system

# If you have installed the CRDs manually instead of with the `--set
installCRDs=true` option added to your Helm install command, you should
upgrade your CRD resources before upgrading the Helm chart:
kubectl apply -f https://github.com/cert-manager/cert-
manager/releases/download/v1.5.1/cert-manager.crds.yaml

# Add the Jetstack Helm repository

helm repo add jetstack https://charts.jetstack.io

# Update your local Helm chart repository cache

helm repo update

# Install the cert-manager Helm chart

helm install cert-manager jetstack/cert-manager \
--namespace cert-manager \
--create-namespace \
--version v1.5.1

helm install rancher rancher-latest/rancher \

--namespace cattle-system \
--set hostname=rancher.data354.com \
--set replicas=3 \
--set ingress.tls.source=letsEncrypt \
--set letsEncrypt.email=edy.koffi@data354.com \
--set letsEncrypt.ingress.class=nginx

Une fois ces commandes exécutées, nous disposons de l’interface et des

fonctionnalités d’administration de rancher dans notre cluster Kubernetes.

54
 Déploiement de data fair

2.1. Création, signature et publication de la chart Helm de data

fair

Les chartes Helm sont des packages de ressources Kubernetes qui permettent
de les regrouper ainsi que leurs configurations dans le but d’automatiser et
d’harmoniser le déploiement de plusieurs composants en un seul temps. Dans notre
cadre nous avons créé une charte Helm qui a permis de déployer tous les composants
de data fair. Par la suite nous l’avons signé puis déployé sur artifacthub, la plateforme
publique d’hébergement des chartes Helms.

Figure 18: Charte Helm data fair déployée

1. Déploiement de data fair dans le cluster

helm repo add data354-helm https://data354.github.io/helm

helm repo update
helm install data-fair data354-helm/data-fair

L’exécution de ces commandes permet d’installer data fair et toutes ses composantes
dans notre cluster Kubernetes.

55
CHAPITRE 6 : RESULTAT ET DISCUSSION

I. RÉSULTATS

Présentation de l’interface d’administration du cluster

Figure 19: Interface de connexion de rancher

Figure 20: Présentation du cluster Rancher

Il s’agit sur ces images des interfaces d’administration du cluster Kubernetes. Elles
nous permettent de gérer les différentes charges de travail et d’avoir des métriques
élémentaires sur l’état de notre cluster.

56
 Présentation de la plateforme open data

Figure 21: Interface Admin Data fair

Figure 22: Visualisations Data Fair

Les interfaces ci-dessus représentent le back office de la solution Open Data Data-Fair.
Ces interfaces sont utilisées pour l’administration de la plateforme et la création des
portails de publication de données.

57
 Présentation du portail open data ivoirien

Figure 23: Accueil portail open data ivoirien

Figure 24: Jeux de données consultés sur le portail open data ivoirien

Les images ci-dessus présentent le portail public du gouvernement ivoirien déployé

sur le nom de domaine data.gouv.ci. Il permet d’exposer les données pour les
téléchragelents et de les représenter à travers plusieurs types de visualisation.

58
 II. Discussion

Confrontation des résultats

Comme énoncé dans l’introduction nous visions la mise en place d’un système
hautement disponible pour l'hébergement de la plateforme open data du gouvernement
ivoirien. Après plusieurs recherches effectuées dans le domaine des architectures
logicielles et du déploiement d’applications micro services, nous avons obtenu un
système distribué reparti sur trois nœuds dans un cluster Kubernetes. Ce système nous
a permis de déployer la plateforme open data et le portail d’exposition de données du
gouvernement tout en respectant les critères de sécurité, maintenabilité,
interopérabilité, fiabilité. Au vu des résultats obtenus et conjointement aux livrables
attendus, nous pouvons affirmer avec certitude que nous avons atteint notre objectif,
celui de déployer la plateforme open data du gouvernement ivoirien dans un
environnement de test en local.

Critiques

Comparé aux méthodes classiques ou traditionnelles de déploiement basé sur les

applications monolithiques, nous apportons une touche innovatrice en utilisant les
conteneurs. En effet, cette technologie basée sur la virtualisation légère du système
d’exploitation permet de faire abstraction de plusieurs aspects bloquants dans les
procédures de déploiements des systèmes classiques tels que les contraintes des
systèmes d’exploitation, des bibliothèques requises, et les longues séances de
configuration. Il faut aussi noter que la création et la publication des charts Helms dans
le cadre de notre étude est un grand apport pour toutes les installations futures du projet
data fair, et cela quel que soit l’organisation.

Bien que nos résultats aient été concluants, et que nous avons pu délivrer tous nos
livrables attendus, nous sommes toujours en instance de tests et validation afin de
pousser le système au-delà de ses performances et apporter les améliorations
nécessaires pour assurer un meilleur déploiement dans un environnement de
production.

59
CONCLUSION

Dans notre étude nous nous intéressions au domaine de l’Open Data et ses
enjeux pour le gouvernement ivoirien. Notre problème était donc de savoir comment
mettre en place une architecture hautement disponible pour le déploiement de la
plateforme open data du gouvernement ivoirien sur ses propres serveurs, en tenant
compte des aspects de sécurité, de fiabilité et de disponibilité. Notre approche
méthodologique à consister à étudier la plateforme Open Data du gouvernement afin
d’en découvrir les exigences, tant d’un point de vue technique qu’organisationnelle,
puis, les exigences connues, il s’agissait d’étudier les différentes architectures
techniques et outils technologies à notre disposition dans le but de trouver les moyens
les mieux appropriés pour la mise en place de notre système, tout en respectant lesdites
exigences qui sont la sécurité, l’interopérabilité, la conformité, la performance,
l’adaptabilité, la portabilité et la maintenabilité. A la suite de notre étude nous
aboutissions à un système distribué basé sur l'utilisation de conteneurs et orchestré par
Kubernetes qui comprend trois nœuds dont un nœud master et deux nœuds workers.
Ce système nous a permis de pouvoir héberger et maintenir la plate-forme Open Data
du gouvernement ivoirien sur ses serveurs internes. La mise en pratique à travers
l’implémentation des méthodes et outils dans notre environnement de test nous a
permis de confirmer notre étude théorique selon laquelle la mise en place d’une
architecture hautement disponible reposait sur la gestion de la sécurité, de la mise à
l’échelle, de la tolérance aux pannes et de la distribution des charges du système.

60
BIBLIOGRAPHIE

1) Lin, L. C., & Patel, S. P. (2021). The System Design Interview, 2nd Edition.

Independently published.

2) Martin, R. C. (2021). Clean Craftsmanship : Disciplines, Standards, and

Ethics (Robert C. Martin Series) (1re éd.). Addison-Wesley Professional.

3) Martin, R. (2017). Clean Architecture : A Craftsman’s Guide to Software

Structure and Design (Robert C. Martin Series) (1re éd.). Pearson.

WEBOGRAPHIE

4) Portail officiel des données ouvertes. (2021). data.gouv.ci. Consulté le 29 juin

2022, à l’adresse https://data.gouv.ci/pages/open-data

5) Href, E. (2014, 23 octobre). Scalabilité - Techno & UX - EcommerceMag.fr.

Ecommercemag. Consulté le 7 octobre 2022, à l’adresse

https://www.ecommercemag.fr/Definitions-Glossaire/Scalabilite-245357.htm

6) Qu’est-ce que la résilience informatique ? (s. d.). oracle.com. Consulté le 4

juillet 2022, à l’adresse https://www.oracle.com/fr/security/definition-

resilience-informatique.html

7) Tolérance aux pannes. (s. d.). © Copyright IBM Corp. 2007, 2014. Consulté

le 4 juillet 2022, à l’adresse

https://www.ibm.com/docs/fr/tpmfod/7.1.1.16?topic=security-fault-tolerance

8) L’écosystème Docker : aperçu de l’outil. (2020, 24 septembre). IONOS Digital

Guide. Consulté le 7 octobre 2022, à l’adresse
https://www.ionos.fr/digitalguide/serveur/know-how/docker-lecosysteme-de-
la-plateforme-de-conteneurs/

x
 9) Qu’est-ce-que Kubernetes ? (2022, 29 juin). Kubernetes. Consulté le 6 juillet

2022, à l’adresse https://kubernetes.io/fr/docs/concepts/overview/what-is-

kubernetes/

10) Kubernetes. (2022). Pods. Consulté le 5 mai 2022, à l’adresse

https://kubernetes.io/docs/concepts/workloads/pods/

https://kubernetes.io/fr/docs/concepts/overview/components/

11) Experts en gestion des environnements Kubernetes avec SUSE RANCHER.

(s. d.). zenops. Consulté le 6 juillet 2022, à l’adresse

https://www.zenops.fr/suse-rancher/

12) K3s. (s. d.). Consulté le 6 juillet 2022, à l’adresse https://k3s.io/

13) Secret Double Octopus. (2021, août 15). What is Secure Socket Shell (SSH) ?

| Security Wiki. Consulté le 22 juillet 2022, à l’adresse https://doubleoctopus-

com.translate.goog/security-wiki/protocol/secure-socket-

shell/?_x_tr_sl=auto&_x_tr_tl=fr&_x_tr_hl=fr

14) Configurer les comptes de service pour les pods. (2021, août 3). Kubernetes.

Consulté le 6 juillet 2022, à l’adresse

https://kubernetes.io/fr/docs/tasks/configure-pod-container/configure-service-

account/

15) Qu’est-ce que le contrôle d’accès basé sur le rôle (rbac) ? (2021). Entrust.

Consulté le 20 août 2022, à l’adresse

https://www.entrust.com/fr/resources/faq/what-is-role-based-access-control

16) Wikipedia contributors. (2022, 15 septembre). Autorité de certification.

Consulté le 7 juillet 2022, à l’adresse

https://fr.wikipedia.org/wiki/Autorit%C3%A9_de_certification

xi
17) A.S., Z. (s. d.). Protocole ACME pour les serveurs Windows. SSLmarket.

Consulté le 7 juillet 2022, à l’adresse

https://www.sslmarket.fr/blog/protocole-acme-pour-les-serveurs-windows

18) F5. (2021). Qu’est-ce qu’un pare-feu applicatif ? F5. Consulté le 5 août 2022,

à l’adresse https://www.f5.com/fr_fr/services/resources/glossary/application-

firewall

19) David Ko. (2021, 11 octobre). Welcome Longhorn 1.2. Longhorn. Consulté le

4 août 2022, à l’adresse https://longhorn.io/blog/longhorn-v1.2/#encryption-

volume-and-backup

xii
TABLE DES MATIÈRES

DÉDICACE iii
REMERCIEMENTS iv
SOMMAIRE v
LISTE DES SIGLES ET ABREVIATIONS vi
LISTE DES FIGURES viii
LISTE DES TABLEAUX ix
INTRODUCTION 1
CHAPITRE 1 : ENVIRONNEMENT DE TRAVAIL 4
I. PRÉSENTATION DE LA STRUCTURE D’ACCUEIL 4

Présentation générale ................................................................................... 4

Domaines de compétences ........................................................................... 4

Equipes ......................................................................................................... 5

II. MÉTHODES ET OUTILS DE TRAVAIL 7

SCRUM ........................................................................................................ 7

Open source.................................................................................................. 7

DevOps ......................................................................................................... 7

CHAPITRE 2 : PRÉSENTATION DU PROJET 8

I. GÉNÉRALITÉS ET ENJEUX DE L’OPEN DATA 8

Généralités.................................................................................................... 8

Enjeux ........................................................................................................ 10

II. L’OPEN DATA EN CÔTE D’IVOIRE 11

L’initiative du gouvernement ..................................................................... 11

Point d’avancement des travaux................................................................. 11

xiii
 III. PRESENTATION ET ORGANISATION DU PROJET 12

Contexte et justification ............................................................................. 12

Objectifs ..................................................................................................... 12

Contraintes ................................................................................................. 13

Planning d’exécution .................................................................................. 14

Estimation financière ................................................................................. 14

CHAPITRE III : ANALYSE DE LA SOLUTION OPEN DATA 16

I. DESCRIPTION ET FONCTIONNEMENT DE DATA FAIR 16

Description de data fair .............................................................................. 16

Fonctionnement général ............................................................................. 16

Principaux atouts ........................................................................................ 17

II. ARCHITECTURE APPLICATIVE ET COMPOSANTS 18

Architecture de Data Fair ........................................................................... 18

Composants ................................................................................................ 19

III. EXIGENCES FONCTIONNELLES ET NON FONCTIONNELLES 22

Exigences fonctionnelles ............................................................................ 22

Exigences non fonctionnelles ..................................................................... 23

CHAPITRE IV : CONCEPTS ET TYPES D’ARCHITECTURES TECHNIQUES 24

I. CONCEPTS 24

La haute disponibilité ................................................................................. 24

La conteneurisation .................................................................................... 26

Orchestrateurs de conteneurs ..................................................................... 27

xiv
 II. ETUDE ARCHITECTURALE 28

Etude détaillée de Kubernetes .................................................................... 28

Facteurs clés à considérer dans la mise en place du système ..................... 36

Proposition finale du système .................................................................... 51

CHAPITRE 5 : APPLICATION DE L'ÉTUDE TECHNIQUE 53

I. PRÉPARATION DE L’ENVIRONNEMENT DE DÉPLOIEMENT 53

Initialisation du cluster Kubernetes ............................................................ 53

Déploiement de data fair ............................................................................ 55

CHAPITRE 6 : RESULTAT ET DISCUSSION 56

I. RÉSULTATS 56

Présentation de l’interface d’administration du cluster .............................. 56

Présentation de la plateforme open data..................................................... 57

Présentation du portail open data ivoirien .................................................. 58

II. Discussion 59

Confrontation des résultats ......................................................................... 59

Critiques ..................................................................................................... 59

CONCLUSION 60
BIBLIOGRAPHIE x
WEBOGRAPHIE x
TABLE DES MATIÈRES xiii
RÉSUMÉ xvi
ABSTRACT xvi

xv
RÉSUMÉ

Dans le cadre du déploiement de l'Open Data, la Côte d'Ivoire dispose

désormais d'une plateforme de données ouvertes hébergée et gérée à l’étranger sous le
domaine data.gouv.ci. L’objectif de notre étude est de déployer la solution Open Data
du gouvernement sur ses serveurs. Notre problématique est de donc de savoir
Comment mettre en place une architecture technique pour le déploiement de l’Open
Data en Côte d’Ivoire ? Quelles sont les exigences de la solution Open Data
ivoirienne ? Quels méthodes et outils sont les mieux adaptés pour répondre à ses
exigences ? Notre démarche pour répondre à cette problématique consiste d’abord à
mener une étude sur la plateforme ; trouver des outils qui répondent à ses exigences et
enfin implémenter ces dits outils dans un environnement de tests. Nous aboutissons à
un système distribué basé sur l'utilisation de conteneurs et orchestré par Kubernetes
qui sera utilisé pour héberger et maintenir la plate-forme Open Data du gouvernement
de Côte d'Ivoire en tenant compte de la haute disponibilité, la sécurité et la fiabilité du
système.

Mots clés : Open data, Architecture, Visualisation, Données, Devops.

ABSTRACT

As part of the deployment of Open Data, Côte d'Ivoire now has an open data
platform hosted and managed abroad under the domain data.gouv.ci. The objective of
our study is to deploy the government's Open Data solution on its servers. Our problem
is therefore to know How to set up a technical architecture for the deployment of Open
Data in Côte d'Ivoire? What are the requirements of the Ivorian Open Data solution?
What methods and tools are best suited to meet its requirements? Our approach to
address this issue is to first conduct a study on the platform, find tools that meet its
requirements and finally implement these tools in a test environment. We end up with
a distributed system based on the use of containers and orchestrated by Kubernetes
that will be used to host and maintain the Open Data platform of the government of
Côte d'Ivoire taking into account the high availability, security and reliability of the
system.

Keywords : Open data, Architecture, Visualization, Data, Devops

Ecole supérieure Africaine des Technologies de l’information et de la communication (ESATIC) xvi

Treichville – Zone 3, km 4 BD Marseille – BP 1501 Abidjan 18.

Site web: https://www.esatic.ci , email: direction.esatic@esatic.ci