Contribution à la conception à base de composants logiciels d’applications scientifiques parallèles

Contribution à la conception à base de composants
logiciels d’applications scientifiques parallèles

Machines multi-processeurs SMP

Une machine SMP (Symetric MultiProcessing) possède plusieurs processeurs permettant ainsi plusieurs fils d’exécutions simultanés. Dans une telle architecture la mémoire est partagée entre tous les processeurs et chacun y accède par le même bus. Ce bus devient le goulot d’étranglement de l’application. En effet, lorsque les fils d’exécutions d’une application accèdent en même temps à la mémoire le débit du bus diminue. Ce qui limite le passage à l’échelle en nombre de processeurs. NUMA L’architecture NUMA (Non Uniform Memory Access) est une solution aux limitations de l’architecture SMP. Celle-ci partitionne la mémoire et l’associe à chaque processeur. Cette approche limite le nombre de processeur pouvant accéder en même temps à une portion de mémoire. L’ensemble de la mémoire reste accessible à tous les processeurs mais plus la mémoire est éloignée d’un processeur plus son accès est lent. Par exemple, dans certaines architectures (Intel Xeon, AMD Opteron), la mémoire associée à un ensemble de processeurs n’est accessible aux autres que par l’intermédiaire des premiers. Cette architecture nécessite d’adapter l’exécution des applications en descendant à un niveau très bas dans les détails de conception. En effet, si on veut profiter des temps accès mémoire rapides il faut que les fils d’exécutions qui utilisent des données partagées soient placés sur des processeurs voisins dans la hiérarchie de mémoires. 

GPU

Le GPU (Graphics Processing Unit) est un circuit intégré présent sur les cartes graphiques qui présente une architecture parallèle. Il suit le paradigme Single Instruction Multiple Data (SIMD) c’est-à-dire qu’il permet d’exécuter une même instruction sur plusieurs données. Son rôle premier est d’accélérer l’exécution des tâches graphiques (à base de calcul vectoriel). Les GPU étant initialement prévus pour les applications graphiques (jeux vidéo), ils bénéficient de débouchés commerciaux importants, ce qui en fait une ressource matérielle peu onéreuse. Cependant, les applications graphiques ne sont pas les seules à pouvoir bénéficier de cette architecture matérielle. Il est possible d’utiliser le GPU pour exécuter les applications parallèles. C’est le GPGPU (General-purpose computing on graphics processing units). Il permet d’obtenir une grande puissance de calcul en utilisant un GPU ou une combinaison de GPU. Le GPU possède une mémoire propre et est relié au processeur et à la mémoire par l’intermédiaire du bus PCI. Ce bus a des performances moins élevées que le bus mémoire. Le GPU est composé d’une grande quantité d’unités de calcul dont le jeu d’instruction est plus simple que celui d’un processeur classique. Cette architecture est orientée vers l’exécution d’instructions en parallèle sur un ensemble de données. Exécuter des applications sur une telle architecture nécessite de prendre en compte l’ensemble de ces nouveaux paramètres. Il faut pouvoir spécifier quelles sont les instructions à exécuter sur le processeur central, celles qui peuvent être parallélisées sur le GPU et les transferts de données entre les mémoires du GPU et du processeur. Cela demande encore une fois de contrôler très précisément l’exécution de l’application.

Grappes

Une grappe est un ensemble d’ordinateurs indépendants qui apparaît à l’utilisateur comme un seul système. Elle est constituée d’un ensemble de serveurs ou de stations de travail assez homogène – chaque ordinateur d’une grappe est appelé noeud. Ils sont interconnectés par un réseau local (Local Area Network, LAN) reposant sur la technologie Gigabit Ethernet. Ce réseau est parfois doublé d’un second plus performant basé sur des technologies comme Quadrics, Myrinet ou InfiniBand. Dans ce cas le premier est utilisé pour les tâches communes (telles que l’administration). Une grappe nécessite un investissement moins important qu’un serveur multiprocesseur pour un même nombre de coeurs. Il a de plus l’avantage d’être extensible. L’inconvénient majeur est que les communications entre les noeuds d’une grappe sont beaucoup moins performantes qu’au sein d’un ordinateur multi-processeur. Afin d’utiliser pleinement les capacités d’une telle architecture il est nécessaire d’adapter les applications à la topologie réseau de la grappe. Suivant les topologies réseau utilisées les communications entres certains noeuds peuvent varier énormément. Une grappe peut être partagée entre plusieurs utilisateurs notamment grâce aux gestionnaires de tâches. UNIX possède son gestionnaire de tâche at mais il en existe d’autre comme OAR [53], PBS [35] ou LoadLeveler [77]. Ces gestionnaires de ressources permettent de réserver un ensemble de noeuds pour une période donnée. Une grappe peut aussi être gérée par un système d’exploitation à image unique (Single Image System, SSI) comme Kerrighed [84] ou Mosix [33] qui permet de voir la grappe comme un seul serveur fortement NUMA.

Supercalculateurs

Les supercalculateurs sont conçus pour exécuter des tâches nécessitant une très grande puissance de calcul comme, par exemple, les simulations numériques de météorologie, climat, cosmologie… Ils sont très onéreux et demandent généralement une infrastructure spécifique. Top500 Le Top500 [23] propose un classement des 500 plus puissants supercalculateurs. Les performances de ces supercalculateurs sont évaluées grâce au test de performance Linpack (http ://www.netlib.org/linpack/hpl/) et le classement s’effectue suivant le nombre d’opérations à virgule flottante par seconde (FLoating point Operations Per Second, FLOPS). Sequoia Le 14 juin 2012, le plus puissant supercalculateur du top500 était Sequoia (un supercalculateur de la série IBM Blue Gene/Q) avec une puissance théorique maximale de 20132.7 pétaFLOPS. Il possède 98304 noeud de calcul, 1572864 coeurs et 1.6Po de mémoire. Ses processeurs sont des Power Architecture à 16 ou 8 noeuds. Son système d’exploitation est Linux. K Computer Le K Computeur est actuellement le second plus puissant supercalculateur du Top500 avec une puissance théorique maximale de 11.2804 pétaFLOPS. Il possède 88128 processeurs de 8 coeurs chacun, soit un total de 705024 coeurs. Son système d’exploitation est Linux. Le K computer possède un réseau toroïdal et utilise une version optimisée pour cette topologie de la librairie OpenMPI. Tianhe-IA Tianhe-IA est un supercalculateur qui utilise l’architecture GPGPU. Il est équipé de 14336 processeurs Xeon et de 7168 GPU Tesla. Sa puissance théorique est de 4,701 pétaFLOPS. Sur chaque carte deux processeurs Xéon sont associés à un GPU Tesla. Ces processeurs sont connectés par un réseau propriétaire spécialement conçu pour ce supercalculateur. Tera 100 Tera-100 est la première machine française du classement Top500 qui est située à la 17ème place. C’est un supercalculateur fabriqué par Bull. Il est composé de 4370 noeuds et rassemble au total 138368 coeurs Xeon. Son système d’exploitation est linux. Sa puissance théorique est de 1254.55 pétaFLOPS. Et il utilise un réseau d’interconnexion InfiniBand sur une topologie constituée d’une grappe de flat tree. 18 Chapitre 2. Ressources matérielles et paradigmes de programmation Ces supercalculateurs nécessitent des investissements très importants. Néanmoins leur durée de vie est inférieure aux codes qu’ils exécutent. Comme le montrent les quelques exemples issus du Top500, l’architecture d’un supercalculateur peut varier énormément de l’un à l’autre. Tous les paramètres changent : les processeurs, la topologie réseau, la présence ou non de GPU. Cette très forte hétérogénéité implique un effort de portage des applications. Il est ainsi nécessaire d’adapter les applications à chacun de ces supercalculateur. 2.2.6 Grilles 2.2.6.1 Computing grid Une grille de calcul est un type d’architecture matérielle qui permet aux institutions de mutualiser leurs ressources matérielles pour résoudre des problèmes de plus grande taille. Cela permet aussi aux institutions ayant des moyens financiers limités d’avoir accès à une grande puissance de calcul pour un moindre coût. Une grille de calcul fédère les ressources de calcul des différentes institutions y prenant part. Elle est donc souvent hétérogène. En effet, les ressources partagées ne sont pas du même type car acquises et maintenues par les différentes institutions de la grille. Il n’y a par ailleurs pas de politique centralisée de gestion de ces ressources. Une grille peut ainsi être constituée de grappes de serveurs, de supercalculateurs ou de simples stations de travail. Ces ressources de calcul varient par le nombre et l’architecture des noeuds, les réseaux les interconnectant et leurs capacités de stockage. Une première définition de la grille de calcul à été donnée dans les années 90 par Foster et Kesselman [69] : “A computational grid is a hardware and software infrastructure that provides dependable, consistent, pervasive, and inexpensive access to high-end computational capabilities.” Ces deux auteurs ont ensuite fait évoluer cette définition [70] : “Grid computing is concerned with coordinated resource sharing and problem solving in dynamic, multi-institutional virtual orgranizations “ Dans cette dernière version les auteurs mettent l’accent sur le caractère partagé de cette architecture matérielle. Finalement, Ian Foster propose une définition de la grille en trois points [68] : Une grille de calcul est un système qui : – coordonne des ressources non soumises à un contrôle central, – en utilisant des protocoles et interfaces standardisés et ouverts – pour offrir des services non triviaux. C’est-à-dire dont l’utilité est supérieure à la somme des utilités des sous-services la constituant. La suite de cette sous-section présente différents exemples de grilles. EGI, European Grid Infrastructure [19] est un projet Européen dont l’objectif est de fournir des ressources de calcul aux chercheurs européens (industriels ou scientifiques) issus de divers champs de recherche. Cette grille est répartie entre presque 350 centres, rassemblant plus de 300000 coeurs et totalisant une capacité de stockage de plus de 100 Po, le tout reposant sur le réseau GÉANT[20] qui offre jusqu’à 10Go/s entre certains sites. XSEDE Extreme Science and Engineering Discovery Environment (XSEDE) [98] est la suite du projet TeraGrid [22]. Il est financé par le National Science Foundation (NSF). XSEDE est une grille répartie sur le territoire américain qui est constituée de grappes de PCs, de machines 2.2. Ressources matérielles 19 vectorielles, de supercalculateurs. Les sites sont interconnectés par une réseau à haut débit de 40 Gbit/s. La puissance de calcul est de plus 2 PetaFLOPS et la capacité de stockage de 30 Po. Plate-forme expérimentale Grid’5000 Aladdin Grid’5000 [97] est une plate-forme expérimentale disponible pour la recherche sur les systèmes parallèles et/ou distribués. À ce jour Grid’5000 est composée de grappes disponibles sur 10 sites : Lille, Rennes, Orsay, Nancy, Bordeaux, Lyon, Grenoble, Toulouse, Reims et Sophia-Antipolis. Les grappes sont constituées soit d’AMD (Opteron), soit d’Intel (Xeon). Grid’5000 rassemble en juin 2012 de 1594 noeuds soit 3064 processeurs ou 8700 coeurs. Les différents sites de la plate-forme sont reliés par le réseau Renater[99] qui offre un débit pouvant aller jusqu’à 10Go/s entre la plupart des sites. Les réseaux des grappes constituant Grid’5000 sont de type Gigabit Ethernet, Myrinet, ou InfiniBand. Chaque grappe est gérée par le gestionnaire de ressource OAR. Il est possible d’utiliser le système d’exploitation installé sur les noeuds (debian linux) ou de déployer son propre système d’exploitation. 

Desktop grid

La desktop grid est une autre forme de grille[81]. Elle propose d’utiliser les ressources inutilisées des ordinateurs personnels connectés à internet. En effet ces ordinateurs n’utilisent qu’environ 10% de leurs ressources de calcul lorsqu’ils sont utilisés et pratiquement 0% lorsqu’ils sont en veille. World Community Grid World Community Grid est un exemple de ce genre de grille. Elle est constitué de 400000 membres. Un volontaire désirant participer à cette grille doit installer un logiciel mettant sont ordinateur à disposition des utilisateurs. Ce logiciel est paramétrable. Il permet au volontaire de spécifier le taux de partage de son ordinateur. C’est à dire le taux maximal d’utilisation du processeur, la taille de la mémoire partagée ainsi que les plages horaires pendant lesquelles le partage est effectif. Le volontaire peut aussi arrêter l’application à tout moment. Ce type de ressource peut rassembler des centaines de milliers d’ordinateurs et présente une grande hétérogénéité, les ordinateurs des volontaires ayant des caractéristiques matérielles très dissemblables. Le taux de partage d’une ressource, la bande passante et les latences des ordinateurs volontaires ainsi que la volatilité des ressources (un volontaire peut éteindre son ordinateur à tout moment) sont aussi des paramètres à prendre en compte lors du portage d’une application vers ce genre de ressource. Des environnements de programmation comme XtremWeb [54] ou BOINC [4] (utilisé par World Community Grid) facilitent ce genre de développement. Cette configuration matérielle convient particulièrement bien aux applications de type parameter sweep. Cependant, la pertinence de ce type de plate-forme pour d’autres types d’application (par exemple mapreduce) est à l’étude. Notamment, avec BitDew[65]

Cloud

Le cloud computing propose à l’utilisateur de ne payer que les ressources qu’il consomme effectivement. L’utilisateur n’a plus besoin d’avoir un ensemble de ressources toujours disponibles et cela même lorsqu’il n’a aucune tâche à exécuter. Le cloud lui propose un nombre de ressources théoriquement infini – en pratique assez limité. Lorsque l’utilisateur a besoin de ressources de calcul, le cloud lui fournit la quantité de ressources dont il a besoin. Une fois le calcul terminé, 20 Chapitre 2. Ressources matérielles et paradigmes de programmation les ressources sont libérées. L’utilisateur est facturé relativement au nombre d’heures utilisées par serveur. Le prix des ressources varie avec le taux d’utilisation du cloud. Il est intégré, ainsi que la demande de calcul, dans le choix du nombre de ressources à utiliser. Les clouds peuvent être classifiés en différents niveaux de services : – SaaS (Software as a Service) : Ce niveau propose d’accéder à des services à la demande. Ces services sont accessible via une interface web ou une Api. Un exemple est le Microsoft Online Services qui propose Exchange. – PaaS (Platform as a Service) : Dans cette forme de cloud, l’utilisateur a en charge le développement ou le paramétrage des applications. Les ressources exécutant ces applications sont, elles, maintenues par le cloud. Des exemples de ce type de cloud sont Google App Engine et Microsoft Azure. – IaaS (Infrastructure as a Service) : dans ce niveau de service les utilisateurs ont accès a un environnement d’exécution par le biais de machines virtuelles. Ce type de service est proposé par Amazon EC2[18] par exemple. Dans le contexte du cloud computing, le nombre de ressources disponibles est inconnu. Concevoir une application pour cette ressource implique donc de prendre en compte la souplesse de celle-ci. HPC@Cloud Amazon EC2 offre aussi des ressources compatibles avec le HPC. Ainsi, l’utilisateur peut choisir ses ressources dans une grappe de calcul ou de GPU (bande passante élevée, une faible latence réseau et des capacités de calcul élevées). L’utilisation du cloud pour le HPC permet par ailleurs le chiffrage du coût d’utilisation des ressources. Les expériences récentes [24] établissent un prix de 5000$ par heure pour 50000 noeuds de calcul. FutureGrid FutureGrid[21] est un projet américain financé par la National Science Foundation (NSF) dont le but est de fournir une plate-forme pour la recherche dans le domaine des grilles de calcul et du cloud computing. À cette fin, le projet FutureGrid rassemble plus de 5600 noeuds répartis entre six sites. FutureGrid est intégré dans TeraGrid[22]. Ses ressources sont accessibles à travers des outils comme Nimbus[79], OpenNebula[13], Eucalyptus[10].

Discussion

Cette section a présenté un aperçu des différentes ressources disponibles pour les applications scientifiques. Deux aspects se dégagent de cette présentation. Premièrement, le caractère hétérogène de leur ensemble, deuxièmement leur évolution continue. Hétérogénéité des ressources L’ensemble des ressources matérielles décrit dans cette section présente des caractéristiques très hétérogènes. Les processeurs, la hiérarchie de la mémoire et la topologie du réseau est différente d’une architecture à une autre. Concevoir une application ayant une performance optimale pour ces architectures nécessite d’adapter ses différentes parties à chacune d’entre elles. Les communications, le parallélisme, le partage de données doivent être adaptés à chaque architecture. Évolution rapide Ces ressources évoluent très rapidement, bien plus rapidement que les applications qu’elles exécutent. La puissance de calcul augmente régulièrement. Mais les autres paramètres évoluent aussi. Ainsi, le nombre de processeurs par ordinateur, l’architecture des processeurs, la vitesse des réseaux et les topologies proposés évoluent. De plus, de nouvelles  architectures matérielles apparaissent régulièrement. Celles-ci présentent des caractéristiques nouvelles qui impliquent un effort de portage.

Table des matières

1 Introduction
1.1 Conception d’applications scientifiques
Applications scientifiques
1.2 Objectifs
Simplicité de programmation
Expressivité
Abstraction des ressources
Performances
1.3 Contributions
Composition à gros grain
Adaptation à grain fin
Raffinement de maillage adaptatif
1.4 Organisation du document
1.5 Publications
1.5.1 Publication dans un atelier international
1.5.2 Articles en cours de soumission dans des conférences internationales
I Contexte
2 Ressources matérielles et paradigmes de programmation
2.1 Introduction
2.2 Ressources matérielles
2.2.1 Des mono-processeurs aux machines parallèles
2.2.2 Machines multi-processeurs
SMP
NUMA
2.2.3 GPU
2.2.4 Grappes
2.2.5 Supercalculateurs
Top
Sequoia
K Computer
Tianhe-IA
Tera
2.2.6 Grilles
2.2.6.1 Computing grid
Plate-forme expérimentale Grid’
2.2.6.2 Desktop grid
World Community Grid
2.2.7 Cloud
HPC@Cloud
FutureGrid
2.2.8 Discussion
Hétérogénéité des ressources
Évolution rapide
2.3 Paradigmes de programmation d’applications scientifiques
2.3.1 Introduction
2.3.2 Mémoire partagée
2.3.2.1 Multithread
2.3.2.2 Pthread
2.3.2.3 OpenMP
2.3.2.4 GPGPU
CUDA
OpenCL
OpenACC
2.3.3 Mémoire Distribuée
2.3.3.1 Passage de messages
MPI
MPI-1
MPI-2
MPI-3
PVM
2.3.3.2 Appel de procédure distante
GridRPC
2.3.3.3 Appel de méthode distante
Corba
2.3.3.4 Appel de service
2.3.4 Discussion
2.4 Analyse
2.4.1 Ressources hétérogènes
Difficulté de programmation
2.4.2 Évolution rapide des ressources
Effort constant de portage
Nombre de ressources inconnues et variable .
Paramètre énergie
2.5 Conclusion
3 Modèles de composition
3.1 Composition spatiale : Modèles de composants .
3.1.1 Définitions
Composant logiciel
Port .
Assemblage
3.1.2 CCM
Composants
Assemblage
3.1.3 FRACTAL
Objectif
Concepts
3.1.4 GCM
3.1.5 CCA
Composants
ADL
Parallélisme
3.1.6 HLCM
Types de composants
Connecteurs
Connexions
Implémentations des composants
Low Level Component
3.1.7 Analyse
Mode de communication
Hiérarchie
Langage d’assemblage
3.2 Composition temporelle : Modèles de flux de travail
3.2.1 Définitions
Tâche
Ports
Composition
3.2.2 KEPLER
Actors
Director
Paramètres
3.2.3 Triana
3.2.4 AGWL
3.2.5 MOTEUR
3.2.6 ASSIST
3.2.7 Analyse
Flot de contrôle
Abstraction des ressources
Application parallèles
3.3 Composition spatiale et temporelle
3.3.1 Introduction
3.3.2 ICENI
3.3.3 ULCM
Composants
Assemblage
Composition temporelle
Modèle transparent d’accès aux données
Paradigme maître-travailleur
3.3.4 STKM
3.3.5 Analyse
3.4 Conclusion
4 Table des matières
4 Environnements de développement
4.1 ESMF
4.2 CACTUS
4.3 PALM
4.4 SALOMÉ
4.4.1 Architecture Générale
4.4.2 Modèle de programmation
4.4.2.1 Modèle de composants
4.4.2.2 Modèle de workflow
4.4.2.3 Schéma de calcul
4.5 Analyse
4.6 Conclusion
II Contribution
5 Applications de décomposition de domaine dans SALOMÉ
5.1 Introduction
5.2 Motivation
5.2.1 Décomposition de domaine
Introduction .
5.2.2 FETI
5.2.3 Application motivante : simulation de phénomènes thermo-mécaniques Code_ASTER
5.2.3.1 Implémentation MPI
5.2.3.2 Implémentation SALOMÉ
Architecture de l’implémentation
5.2.4 Limitations du modèle de programmation
5.2.4.1 Automatisation
5.3 Clonage de noeuds et de ports dans YACS
5.3.1 Vue d’ensemble
5.3.2 Clonage de noeuds
5.3.3 Clonage de ports
Cas 11-N1
Cas N1-1N
Cas 1N-N1
Cas 1N-11
5.3.4 Connexions entre noeuds répliqués
5.3.5 Implémentation du clonage de noeuds et de ports
5.3.5.1 Ports dataflow
5.3.5.2 Ports datastream
5.3.6 Initialisation des services
5.3.7 Analyse
5.4 Évaluation
5.4.1 Programmation de l’application de décomposition de domaine
Construction native
Construction avec extension
Comparaison
5.4.2 Performances à l’exécution
5.4.3 Complexité de programmation des applications évolutives
5.5 Discussion
5.6 Conclusion
6 Décomposition de domaine et composition bas niveau 61
6.1 Introduction
6.2 Motivation
6.3 Modèles de programmation existants .
6.3.1 Modèles spécialisés par infrastructures
6.3.2 Les modèles s’adaptant aux ressources
6.3.3 Les modèles de composants logiciels
6.3.4 Analyse
6.4 Low Level Component (L2C)
6.4.1 Vue d’ensemble de L2C
6.4.2 Analyse
6.5 Utilisabilité de L2C avec une application Jacobi
6.5.1 Une première version de l’application de décomposition de domaine en L2C
6.5.1.1 Version de base avec composants logiciels
6.5.1.2 Parallélisation par mémoire partagée
6.5.1.3 Parallélisation par mémoire distribuée
6.5.1.4 Analyse
6.5.2 Une version modulaire de la décomposition de domaine avec L2C
6.5.2.1 Parallélisation par mémoire partagée
6.5.2.2 Parallélisation par mémoire distribuée
6.5.2.3 Parallélisation hiérarchique
6.5.3 Un seul processus, plusieurs allocations mémoire
6.5.4 Analyse
6.6 Évaluations expérimentales
6.6.1 Réutilisation de code
6.6.1.1 Version de driver
6.6.1.2 Version avec connecteurs
6.6.2 Accélération
6.6.3 Pénalité de performance
6.6.4 Performances multi-coeurs
6.6.5 Passage à l’échelle
6.6.6 Complexité cyclomatique
6.6.7 Analyse
6.7 Conclusion
7 Composition et raffinement de maillage adaptatif
7.1 Introduction
7.1.1 Méthode de raffinement de maillage adaptatif
7.1.2 AMR et composants
7.2 AMR avec Ulcm
7.2.1 Vue générale d’Ulcm .
7.2.2 ULCMi : Une implémentation de Ulcm
7.2.3 Implémentation de l’AMR dans Ulcm
Application HeatM HmainM
7.2.4 Discussion
6 Table des matières
7.3 AMR avec SALOMÉ
7.3.1 Composants SALOMÉ
7.3.2 Structure de l’application
7.3.2.1 Construction du schéma de couplage
7.3.2.2 Exécution du schéma
7.3.3 Analyse
7.4 Évaluation
7.4.1 Évolution d’un scénario
7.4.2 Temps d’exécution entre étapes de reconfiguration
7.5 Discussion
7.6 Conclusion
III Conclusion
8 Conclusion et perspectives
8.1 Conclusion générale
8.1.1 Objectif et problématique
8.2 Contributions
8.2.1 Ajout dynamique d’une cardinalité aux noeuds de la plate-forme SALOMÉ
8.2.2 Utilisation d’un modèle de composants logiciels de bas niveau pour la conception d’applications
8.2.3 Conception d’applications de raffinement de maillage adaptatif à base de composants
8.3 Perspectives
8.3.1 Utilisation de l’extension du modèle de programmation de SALOMÉ
pour la conception d’applications AMR
8.3.2 Augmentation du niveau d’abstraction dans SALOMÉ
8.3.3 Extension du modèle HLCM à la dynamicité
8.3.4 Algorithmes de choix

projet fin d'etudeTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *