Hébergement de base de données MySQL. Description du service (D après OGC - ITIL v3 - Service Design- Appendix F : Sample SLA and OLA)

Hébergement de base de données MySQL. Description du service (D après OGC - ITIL v3 - Service Design- Appendix F : Sample SLA and OLA) Source : commundit:_ex:catalogue_services:db:sla_dit_mysql.docx Distribution : Tous les utilisateurs du service. Cet accord est fait entre le DIT et les utilisateurs du service. Cet accord couvre la mise à disposition et le support pour le service d hébergement de base de données MySQL qui permet aux utilisateurs du service de bénéficier de l administration du serveur MySQL et de la machine sur laquelle il se trouve. Cet accord est valide pour 12 mois du (01/01/2014) au (31/12/2014). Sauf demande de révision, au plus tard un mois avant la date d échéance, l accord sera automatiquement renouvelé pour un an. Les changements mineurs survenus pendant la période de validité pourront être ajoutés à l aide du formulaire d amendement, ils doivent être acceptés par les deux parties et mis en production au travers du processus de gestion des changements. NOM FONCTION DATE SIGNATURE Révisions Versions Date Auteur Commentaires 1.8 14/11/2008 Julia Paolini Dernière version ITIL v2 2.0 01/01/2012 Julia Paolini Passage en Version 3 d ITIL 2.1 08.05.2013 Fabien Figueras Point d entrée unique Service Desk 2.2 07/11/2013 Julia Paolini Modification Support Utilisateur 2.3 27/03/2014 Julia Paolini Diverses modifications, entre autres Requêtes des utilisateurs et Gestion des changements Page 1 sur 16

Table des matières 1. DESCRIPTION DU SERVICE.... 4 1.1 PRINCIPE DU SERVICE.... 4 1.2 BÉNÉFICES DU SERVICE.... 5 1.3 SPÉCIFICATIONS DÉTAILLÉES DU SERVICE.... 5 2 ETENDUE DE L ACCORD.... 6 2.1 COUVERT PAR L ACCORD.... 6 2.2 NON COUVERT PAR L ACCORD.... 7 3 HEURES D OUVERTURE DU SERVICE.... 7 3.1 PÉRIODES OUVRABLES.... 7 3.2 PÉRIODES DE MAINTENANCES.... 7 3.3 CALENDRIER DES CONGÉS.... 7 4 DISPONIBILITÉ.... 7 4.1 DÉFINITION D UNE PANNE OU D UNE INDISPONIBILITÉ (SI APPROPRIÉ).... 8 4.2 MÉTHODE DE CALCUL.... 8 4.3 OBJECTIF DE DISPONIBILITÉ.... 8 5 FIABILITÉ.... 9 5.1 DÉFINITION D UNE PANNE.... 9 5.2 MÉTHODE DE CALCUL.... 9 5.3 OBJECTIF DE FIABILITÉ.... 9 6 SUPPORT UTILISATEUR.... 9 6.1 HELP DESK.... 9 6.2 CALL CENTER.... 9 6.3 REQUÊTES DES UTILISATEURS.... 10 6.3.1 COMMANDES... 10 7 POINTS DE CONTACTS ET ESCALADE.... 11 8 PERFORMANCE... 11 9 CYCLE D EXÉCUTION DES TRAITEMENTS PAR LOTS «BATCH» (SI APPROPRIÉ).12 10 FONCTIONNALITÉS MINIMALES (SI APPROPRIÉ).... 12 11 GESTION DES CHANGEMENTS.... 12 11.1 MAINTENANCES DE L INFRASTRUCTURE.... 12 11.2 EVOLUTION DE L INFRASTRUCTURE.... 13 11.3 EVOLUTION DU NIVEAU DE SERVICE.... 13 Page 2 sur 16

12 CONTINUITÉ.... 13 13 SÉCURITÉ... 14 13.1 CONTRÔLE DES ACCÈS AUX BASES DE DONNÉES.... 14 13.2 POLITIQUE DE SAUVEGARDE.... 14 14 IMPRESSION (SI APPROPRIÉ).... 14 15 RESPONSABILITÉ.... 15 16 FACTURATION (SI APPROPRIÉ).... 15 17 RAPPORT SUR LE SERVICE ET RÉVISIONS.... 15 17.1 INDICATEURS DE PERFORMANCES... 15 18 GLOSSAIRE (SI APPROPRIÉ).... 16 19 FORMULAIRE D AMENDEMENT (SI APPROPRIÉ).... 16 Page 3 sur 16

1. Description du service. Le DIT offre un service d hébergement de base de données MySQL. Ce service est mis à disposition des services centraux et des Facultés de l école. Ce document présente les caractéristiques et les objectifs attendus pour ce service. Ce SLA doit être complété par un avenant pour chaque infrastructure avec les détails la concernant. Tous les objectifs doivent pouvoir être contrôlés et mesurés. Les engagements des parties sont annuels, des points de mesures concernant la disponibilité et la fiabilité du service seront fournis sur demande par le DIT. Les points à préciser au cas par cas feront l objet d un document annexe propre à chaque client du service. 1.1 Principe du service. Le DIT gère et administre les systèmes de gestion de base de données MySQL (et les serveurs sur lesquels ils sont installés) qui lui sont confiés. Les activités et tâches de ce service sont : les études, l administration, l exploitation et le support. Etudes : o Veille technologique sur le Système de Gestion des Bases de Données (SGBD). o Evolution de version des bases de données existantes. o Test, validation, pour les aspects techniques. o Définition des standards d utilisation et d exploitation des SGBD. Administration : o Création des bases de données en liaison avec les chefs de projets concernés. o Mise en œuvre du SGBD, administration et maintenance. o Mise en exploitation et gestion des serveurs (administration, automatisation, développement des procédures, sécurité et autorisation d accès, optimisation des traitements et des requêtes). o Participation au dimensionnement des bases de données et des serveurs. Exploitation : o Assurance de l intégrité des bases de données existantes en garantissant la sécurité physique (procédures de sauvegardes, restauration, journalisation, démarrage après incidents) et logique (confidentialité, accès). o Mise en œuvre des outils de surveillance du serveur et du serveur de base de données. o Utilisation optimale des bases de données en réglant leurs paramètres. Support : o Assistance aux utilisateurs (formation, requêtes techniques). o Support technique pour l ensemble des bases de données. o Gestion des performances et de l optimisation des ressources. Page 4 sur 16

1.2 Bénéfices du service. Les principaux avantages sont économiques, techniques, sécuritaires et d utilisation. Economiques : o Budgets précis et maîtrisés avec les forfaits centraux. o Pas de coûts de formation. o Réduction importante des coûts grâce à la rationalisation des systèmes et des versions. Techniques : o Des équipes d experts aux compétences étendues sont en charge des services. o Un taux de panne très faible et donc une très grande disponibilité. o Des ressources et solutions flexibles pour suivre les évolutions des besoins. Sécuritaire : o Surveillance des services. o Alimentation électrique sécurisée par générateurs de secours. o Pare-feu réseau. o Détection incendie. o Surveillance anti-intrusion. o Stockage et sauvegarde des données. D utilisation : o Des compétences techniques à un niveau optimum. o Des systèmes toujours à jour. o Les pannes sont gérées par le DIT! 1.3 Spécifications détaillées du service. Niveaux de consolidation Le niveau de consolidation reflète dans quelle mesure les ressources matérielles sont partagées avec d autres utilisateurs. Il dépendra principalement du niveau de performance et de confidentialité exigé. Il est bien sûr possible de commencer avec un niveau de consolidation très fort et de changer en fonction de l évolution des besoins. Le niveau de consolidation influence fortement le budget d hébergement. Hébergement mutualisé : On parle de mutualisation lorsque plusieurs bases de données cohabitent sur la même machine. C est le niveau le plus fort de consolidation, on peut mutualiser sur machine physique ou virtuelle. Le choix entre machine physique ou virtuelle est guidé par les besoins en IO. Pour un serveur virtuel les IO sont obligatoirement partagées, pas pour un serveur physique. Les débits pour les accès disques seront donc potentiellement meilleurs sur une machine physique. Hébergement dédié : On parle d'hébergement dédié lorsque le serveur est à l usage exclusif d un seul utilisateur. Pour une ou plusieurs bases de données. Des considérations de Page 5 sur 16

performances ou légales peuvent conduire à choisir ce type de solution. Encore une fois soit sur une machine virtuelle ou sur une machine physique. Architectures L architecture décrit le nombre et le type de serveur mis en œuvre pour soutenir le service de base de données. Mono serveur : L architecture la plus simple est composée d un seul serveur. C est la solution la moins complexe à administrer et aussi la plus rapide et la moins chère à mettre en œuvre. Cependant les données ajoutées entre deux sauvegardes peuvent être perdues et en cas de grosse panne le temps de remise en état du service peut être long. Multi serveurs : Le niveau supérieur est composé de 2 serveurs ou plus. Un serveur est le maître et les autres sont esclaves. Les modifications effectuées par le maître sur les données sont répercutées sur les esclaves. En cas de perte du maître le service sera remis plus rapidement en fonction et les données modifiées entre deux sauvegardes sont disponibles en plusieurs endroits. Versions supportées Le support commence à partir de la version MySQL 5.0. Le support de la dernière version GA (Generally Available) n est pas automatique et sera décidé par le DIT après une procédure de tests. Une fois la migration engagée le DIT supportera la version courante et la version précédente pendant une durée annoncée lors de la migration. Les utilisateurs seront prévenus de la fin du support d une version avec un préavis de 3 mois. 2 Etendue de l accord. Cette section décrit ce qui est couvert par l accord et ce qui ne l est pas. 2.1 Couvert par l accord. Gestion des infrastructures de stockage (installation, maintenance ). Mesure des performances. Surveillance du système et du serveur MySQL via un outil de surveillance. Réalisation des tests pour les systèmes d exploitation et réalisation des documentations. Support aux administrateurs des bases de données. Page 6 sur 16

2.2 Non couvert par l accord. Administration des postes utilisateurs (installation, paramétrage, maintenance ). Systèmes d exploitation non supportés par MySQL et par le DIT. Support des applications utilisant la base de données. Installation de logiciel tiers sur les serveurs de bases de données (phpmyadmin, ). 3 Heures d ouverture du service. Le service est normalement disponible en permanence. Cependant le DIT s engage à maintenir l infrastructure dans son état optimum dans les périodes décrites ci-dessous. 3.1 Périodes ouvrables. Le DIT est ouvert du lundi au vendredi, de 8h à 17h. 3.2 Périodes de maintenances. L infrastructure pourra fonctionner dans un mode dégradé de performance ou être totalement indisponible lors des opérations de maintenance (cf. 11.1). Il est nécessaire de prévoir des périodes de maintenance pour l installation des correctifs du système d exploitation et du gestionnaire de base de données. Des interruptions planifiées du service seront aussi nécessaires pour faire des dépannages ou mises à jour des matériels. Le service pourra donc être interrompu entre 6h et 9h un jour par mois. Les utilisateurs seront avisés en général avec préavis d une semaine. 3.3 Calendrier des congés. Le DIT peut être fermé pendant certaines périodes de l année (par exemple les jours fériés). Lors de ces périodes aucun délai d intervention n est garanti. 4 Disponibilité. Le service est disponible s il n est pas en panne. L objectif annuel de disponibilité sera fonction du type d architecture retenue. Page 7 sur 16

Il est très important de comprendre et de mesurer l impact d une indisponibilité sur la capacité du client à assurer ses activités «business» (par exemple l indisponibilité du réseau empêche l utilisation des serveurs et donc ne permet pas de consultation ou de modifications de la base de données). 4.1 Définition d une panne ou d une indisponibilité (si approprié). On considère que le service est indisponible ou en panne (indisponibilité complète), en dehors des arrêts planifiés, lorsque qu il n est pas possible de se connecter au moteur de base de données hébergé par un des serveurs avec le client d administration adéquat depuis le local du Help desk du bâtiment MA. Une limite du nombre de connexions simultanées est mise en place pour chaque couple username@hostname. Si le seuil de connexions simultanées maximum au serveur MySQL est atteint pour un couple username@hostname, plus aucune nouvelle connexion n est autorisée pour ce couple tant que d autres ne seront pas libérées. De même, si le nombre de connexions simultanées maximum au serveur MySQL est atteint, plus aucune nouvelle connexion ne sera autorisée (indisponibilité partielle) tant que d autres ne seront pas libérées. Seule l indisponibilité complète est prise en compte dans le calcul de la disponibilité. 4.2 Méthode de calcul. Le calcul de la durée totale des pannes se fera en additionnant la durée totale des indisponibilités du service pendant les périodes ouvrables (cf 3.1). 4.3 Objectif de disponibilité. L objectif annuel est d offrir un niveau de disponibilité qualifié de : o Bon pour les mono serveurs. o Très bon pour les multi serveurs. Durée totale des indisponibilités Niveau de disponibilité 1h Excellent 5 h Très bon 10h Bon 41h Moyen 82h Médiocre Page 8 sur 16

5 Fiabilité. C est le nombre maximum de pannes annuelles pendant les heures ouvrables. Ce point peut aussi être mesuré en terme de MTBF (temps moyen entre pannes) ou MTSI (temps moyen entre incidents système). L objectif annuel de fiabilité sera fonction du type d architecture retenue. 5.1 Définition d une panne. (cf. 4.1) 5.2 Méthode de calcul. Le calcul du nombre de pannes se fera en additionnant la durée totale des indisponibilités complètes du service pendant les périodes ouvrables (cf. 3.1). 5.3 Objectif de fiabilité. L objectif annuel est d offrir un niveau de fiabilité qualifié de : o Bon pour les mono serveurs. o Bon pour les multi serveurs. Nombre de panne Niveau de fiabilité 1 Excellent 2 Très bon 3 Bon 5 Moyen 10 Médiocre 6 Support utilisateur. Le support du DIT comporte deux niveaux : Le premier est constitué par le «HelpDesk» et le «Call Center», le deuxième par les spécialistes du DIT. 6.1 Help Desk. Le Help Desk est situé au rez-de-chaussée du bâtiment MA, avenue Piccard 3 (http://plan.epfl.ch/?room=helpdesk), il est ouvert du lundi au vendredi de 8h à 18h. 6.2 Call Center. Le Call Center du Help Desk est ouvert du lundi au vendredi de 7h30 à 18h. Téléphone interne à l école : 1234 Téléphone depuis la Suisse : 021 69 312 34 Téléphone depuis l étranger : 41 21 69 312 34 E-mail : 1234@epfl.ch Page 9 sur 16

6.3 Requêtes des utilisateurs. Les requêtes sont classées en trois catégories : Commandes, Demandes et Incidents. Commandes : concernent des services standardisés, cf. 6.3.1. Les requêtes du type commande sont généralement constituées d un circuit de validation qui peut sortir du DIT. Le délai garanti commence après la validation de la commande. Demandes : concernent des besoins non standards. Incidents : le service ne fonctionne pas comme attendu. Le délai de traitement des demandes et de résolution des incidents dépend de leur complexité et n est pas garanti. En cas d escalade au niveau 2 de la requête le temps maximum qui peut s écouler avant l intervention sera de 1h pour un incident, 2 jours pour une demande. Ce temps est comptabilisé pendant les heures ouvrables (cf. 3.1). 6.3.1 Commandes Les commandes ne peuvent être faites que par du personnel de faculté ou des services centraux. Les étudiants ne peuvent pas faire de commandes. Les commandes doivent être validées avant leurs réalisations ; les validations peuvent être effectuées: par le responsable informatique, par exemple dans le cas d une création de bases de données. ou de manière automatique, seuls les propriétaires de la base de données peuvent faire des commandes la concernant. Voici des exemples de prestations standardisées offertes: Description de la commande Validation Délais après validation Création d une base de données responsable informatique 2 jours ouvrables Création, modification ou suppression d un ou plusieurs utilisateurs (username@hostame) pour une base de données automatique 2 jours ouvrables Suppression d une base de données et de ses utilisateurs liés automatique 2 jours ouvrables La modification des administrateurs de la base de données automatique 2 jours ouvrables La restauration d une base de données à un instant donné (dans la limite de la durée de rétention définie dans la police automatique 2 jours ouvrables Page 10 sur 16

de backup du serveur) La restauration d une base de données de production en cas d arrêt du service applicatif à un instant donné (dans la limite de la durée de rétention définie dans la police de backup du serveur) La mise à disposition d un dump et des logs binaires d une base de données à un instant donné (dans la limite de la durée de rétention définie dans la police de backup du serveur) automatique automatique 1 jour ouvrable 2 jours ouvrables Cette liste est non exhaustive, les commandes et leurs délais doivent être définis pour chaque infrastructure dans un avenant. 7 Points de contact et escalade. Pour tous contacts voir 6.2. En cas de non satisfaction du support, la personne à contacter est le chef du groupe DIT- Exploitation. Le numéro du ticket concernant le cas devra figurer dans la demande d escalade. 8 Performance. Les performances d une base de données sont influencées par la conception, les logiciels et les matériels mis en œuvre. La conception de la base de données est fondamentale, en effet il est très difficile une fois l application écrite de la modifier en profondeur pour la rendre plus performante. Les logiciels sont importants par les degrés de réglages qu ils offrent. Le choix du système d exploitation et du moteur de base de données est donc aussi très important. Le matériel mis en œuvre présente intrinsèquement des goulots d étranglement. Les trois ressources à surveiller sont les disques, le processeur et la mémoire. Pour aider l utilisateur à obtenir les meilleures performances possibles de ses applications, le DIT s engage à mettre à sa disposition ses administrateurs de bases de données. Ils pourront le conseiller en amont du projet pour les choix d architectures matérielle et logicielle. Ils pourront aussi mettre en place des mesures en cours de développement ou lors de la production pour identifier les goulots d étranglement et proposer des solutions pour améliorer les performances. Page 11 sur 16

9 Cycle d exécution des traitements par lots «batch» (si approprié). Ne concerne pas ce service. 10 Fonctionnalités minimales (si approprié). Ne concerne pas ce service. 11 Gestion des changements. Tous les changements doivent être annoncés, évalués, autorisés, prioritisés, planifiés, testés, réalisés, documentés et révisés. Un des attributs de chaque changement est sa priorité : Normale : Le document de demande de changement (RFC) doit être complet et la demande fera l objet d une validation par le Change Manager ou le Change Advisory Board. Un changement «normal» sera annoncé au minimum un mois avant la date de réalisation. Standard : C est un changement identique à un changement «normal» déjà réalisé avec succès, la demande est automatiquement validée. Le changement standard sera annoncé au minimum 7 jours calendaires avant la date de réalisation. Urgente : C est un changement qui doit être effectué en urgence (service bloqué ou danger imminent), il est annoncé et sera validé par l Emergency CAB. Les incidences sur le service seront détaillées dans l annonce. 11.1 Maintenances de l infrastructure. Lors des opérations de maintenance (cf. 3.2), l infrastructure sera indisponible dans les cas suivants : Description Type changement Responsable Mises à jour de l OS normal/standard/urgent DIT Mises à jour du serveur de base de données normal/standard/urgent DIT Evolution de l infrastructure normal/standard DIT Lors des opérations de maintenance (cf. 3.2), l infrastructure restera disponible dans les cas suivants : Page 12 sur 16

Description Type changement Responsable Mises à jour du logiciel de sauvegarde standard DIT Mises à jour du logiciel surveillance de l OS standard DIT 11.2 Evolution de l infrastructure. L infrastructure doit dès sa conception être prévue pour pouvoir évoluer relativement facilement pendant toute la durée prévue de son fonctionnement. Les évolutions sont soit matérielles soit logicielles et sont généralement des changements «normaux» qui sont annoncés au moins un mois avant la date de réalisation. Les changements matériels induisant généralement des investissements feront l objet d une étude au cas par cas. Les évolutions logicielles légères sont traitées dans le cadre de la maintenance normale. Des évolutions lourdes, comme le changement de version du système d exploitation ou du gestionnaire de base de données, sont aussi à prévoir. Bien que moins fréquentes elles occasionneront des interruptions plus longues et seront traitées au cas par cas. 11.3 Evolution du niveau de service. Le niveau de service est convenu pour l année budgétaire, sa modification n est donc pas possible en cours d année. La demande sera néanmoins prise en compte dans le processus d amélioration de la qualité de service. 12 Continuité. Le DIT met en œuvre les moyens informatiques pour garantir qu en cas de panne d un composant unique le service ne sera pas perturbé. Les accès réseau sont redondants et en cas d interruption de service d un composant réseau le basculement sur la solution de secours est transparent. Dans le cas d utilisation de machines virtuelles on s appuie sur l infrastructure de virtualisation qui dispose d un haut niveau de redondance qui lui permet de garantir la continuité du service. En effet en cas de perte d un serveur, les machines virtuelles impliquées sont redémarrées sur un autre serveur. Cette opération ne doit pas affecter le fonctionnement ni le niveau de performance du reste de l infrastructure. A cet effet les machines virtuelles sont enregistrées sur un SAN. Ce niveau de continuité est habituellement qualifié de «Crash Page 13 sur 16

Consistant», c est l équivalent de l arrêt brutal de l alimentation sur une machine physique. Les cas extrêmes de la perte totale de la baie de stockage ou du centre de calcul du bâtiment ne sont pas traités ici. 13 Sécurité. Les droits d administration de la base de données n induisent aucune autorisation sur les autres bases de données ni sur le système d exploitation du serveur. 13.1 Contrôle des accès aux bases de données. L accès à la base de données sera, de préférence et pour des raisons de sécurité, limité au(x) serveur(s) applicatif(s). L utilisateur devra fournir les informations suivantes (devant respecter une certaine convention de nommage) : nom de la base de données souhaitée, nom d utilisateur souhaité, FQDN de la ou des machines applicatives devant avoir accès à la base de données, si nécessaire, l alias réseau souhaité, nombre de connexions simultanées nécessaires au bon fonctionnement de l application. Il est possible de sécuriser les connexions MySQL avec SSL. 13.2 Politique de sauvegarde. Les serveurs sont sauvegardés par le service centralisé de backup de l EPFL. Pour pallier aux cas de corruption des données les bases de données sont sauvegardées en ligne à intervalles réguliers. Les opérations de sauvegarde des bases de données en ligne peuvent occasionner un ralentissement des temps de réponses. La fréquence de ces opérations sera négociée avec l utilisateur pour garantir le meilleur compromis entre performance et cohérences des données. 14 Impression (si approprié). Ne concerne pas ce service. Page 14 sur 16

15 Responsabilité. Le DIT est responsable : du système d exploitation du serveur, du serveur MySQL. Le client est responsable de : sa (ses) base(s) de données, son (ses) utilisateur(s) utilisé(s) pour l accès à la base de données. Sauf avis contractuel contraire le DIT n est pas responsable de la conception, du développement, de la maintenance et des performances des applications qui utilisent les bases de données MySQL. De même les informations contenues dans les bases de données, leur cohérence n est pas de la responsabilité du DIT. Enfin concernant les sauvegardes le DIT n est pas responsable de la qualité des données sauvegardées. 16 Facturation (si approprié). L hébergement des bases de données fait partie des prestations de base que le DIT offre aux services centraux et aux Facultés. Une fraction des ressources est disponible pour la période budgétaire. Le service ne fera pas l objet de facturation sauf en cas de demande qui dépasserait le quota alloué. 17 Rapport sur le service et révisions. L engagement de service a une validité d un an. Lors du dernier trimestre de l année courante, si les indicateurs ne sont pas conformes aux objectifs fixés ou qu une modification a été demandée, une étude sera réalisée. Elle conduira à la production d un plan d amélioration de la qualité qui fournira, au minimum, les informations suivantes : Proposition d amélioration de l existant. Possibilités d évolution. Coûts (investissement, récurrent, humain). Planification de mise en œuvre. 17.1 Indicateurs de performances Les indicateurs de performances permettent de suivre l évolution de la qualité de service pendant la période de référence. Etant entendu que seule la valeur sur l ensemble de la période est contractuelle. Page 15 sur 16

Indicateur Fréquence de publication Mesuré par Nombre de pannes À la demande Help desk Durée des pannes À la demande Help desk Délais d intervention À la demande Help desk 18 Glossaire (si approprié). Abréviation Acronyme Jargon dump ITIL log binaire NAS OLA SAN SLA Définition Sauvegarde de la base de données sous format texte Information Technology Infrastructure Library Fichier contenant les modifications apportées à la base de données Network Attached Storage Operational Level Agreement (accord de service entre différents départements du fournisseur) Storage Area network Service Level Agreement (accord de service entre le client et le fournisseur) username@hostname Représentation d un utilisateur MySQL comprenant le nom d utilisateur MySQL (username) ainsi que la machine depuis laquelle se fait la connexion (hostname) 19 Formulaire d amendement (si approprié). Le formulaire permet d enregistrer les amendements survenus d un commun accord pendant la période contractuelle. Il contiendra les détails techniques, les dates et les signatures des parties. Les révisions sont mentionnées en début de document. Page 16 sur 16