Add WIP internship report
This commit is contained in:
nemunaire
parent
19c780b81e
commit
a03e6e75cc
|
|
@ -0,0 +1,41 @@
|
|||
DOCNAME = report
|
||||
TARGET = report.pdf
|
||||
|
||||
RM ?= rm -f
|
||||
MPP = perl -I../mpp ../mpp/mpp
|
||||
MPPFLAGS =
|
||||
PANDOC = pandoc
|
||||
PANDOCFLAGS = --latex-engine=xelatex --listings --toc --no-tex-ligatures --normalize --chapters
|
||||
BUTLER = perl -I../butler/src ../butler.pl
|
||||
BUTLERFLAGS = --docname=${DOCNAME} --xml=../internship.xml
|
||||
LATEX = xelatex
|
||||
LATEXFLAGS = -halt-on-error -no-shell-escape
|
||||
|
||||
DEPS := ../internship.xml $(shell ${MPP} --list-includes ${TARGET:.pdf=.md})
|
||||
|
||||
all: ${TARGET}
|
||||
|
||||
assistant: MPPFLAGS += --assistant
|
||||
|
||||
assistant: all
|
||||
|
||||
clean:
|
||||
${RM} ${TARGET}
|
||||
|
||||
${TARGET}: ${DEPS}
|
||||
|
||||
.md.mppmd:
|
||||
${MPP} ${MPPFLAGS} $< > $@
|
||||
|
||||
.mppmd.maintex:
|
||||
${PANDOC} ${PANDOCFLAGS} -t latex -o $@ $<
|
||||
|
||||
.maintex.tex:
|
||||
${BUTLER} ${BUTLERFLAGS} --main=$< > $@
|
||||
|
||||
.tex.pdf:
|
||||
${LATEX} ${LATEXFLAGS} -jobname=${@:%.pdf=%} $<
|
||||
${LATEX} ${LATEXFLAGS} -jobname=${@:%.pdf=%} $< >/dev/null
|
||||
${RM} ${@:.pdf=.aux} ${@:.pdf=.log} ${@:.pdf=.out} ${@:.pdf=.toc}
|
||||
|
||||
.SUFFIXES: .md .mppmd .maintex .tex .pdf
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
# Résumé du stage
|
||||
|
||||
%FIXME
|
||||
|
|
@ -0,0 +1,96 @@
|
|||
# Introduction
|
||||
|
||||
## Sujet et finalités
|
||||
|
||||
## Présentation de l'entreprise
|
||||
|
||||
Novaquark est un studio de jeux vidéo créé en janvier 2014 par Jean-Christophe
|
||||
\textsc{Baillie}. Il avait précédemment monté la start-up de robotique Gostai,
|
||||
rachetée par Aldebaran en 2012.
|
||||
|
||||
L'équipe se concentre sur la conception d'un jeu vidéo en ligne massivement
|
||||
multijoueurs dans un monde unique partagé par tous les joueurs : \Dual.
|
||||
|
||||
%FIXME Dual image
|
||||
|
||||
### Contexte concurentiel
|
||||
|
||||
Depuis la création de l'entreprise, de nombreux concurrents sont apparus,
|
||||
partageant des idées innovantes de \Dual :
|
||||
|
||||
- Untold Universe : projet incubé chez Startup 42 ;
|
||||
- No man sky ;
|
||||
- ...
|
||||
|
||||
\Dual a pour ambition d'avoir la dimension spatiale et communautaire du célébre
|
||||
jeu Eve Online (environ #FIXME joueurs), tout en permettant aux joueurs
|
||||
d'évoluer dans un monde éditable (à la manière de Minecraft).
|
||||
|
||||
### Organisation de l'équipe
|
||||
|
||||
Le studio se trouve actuellement au sein de l'incubateur de start-up Agoranov.
|
||||
|
||||
À mon arrivée, l'équipe était composée de 4 personnes :
|
||||
|
||||
- Jean-Christophe \textsc{Baillie} : fondateur et président de Novaquark ;
|
||||
- Étienne \textsc{Robin-Champigneul} : COO ;
|
||||
- Jérome \textsc{Jouvie} : développeur 3D ;
|
||||
- David \textsc{Bernard} : développeur serveur.
|
||||
|
||||
Proche de M. \textsc{Bernard}, j'ai fait mes débuts en tant que DevOps afin de
|
||||
mener à bien mon sujet de stage.
|
||||
|
||||
Depuis l'équipe s'est aggrandie et se compose aujourd'hui de 10 personnes :
|
||||
dont un concepteur de jeux-vidéo, un gestionnaire de communauté, un graphiste,
|
||||
un développeur client, et trois autres stagiaires.
|
||||
|
||||
## Maturité de l'entreprise
|
||||
|
||||
L'entreprise démarrant son activité, elle n'avait encore aucune base de travail
|
||||
lié à mon sujet de stage.
|
||||
|
||||
Les autres employés de l'entreprise travaillaient sur d'autres problématiques :
|
||||
principalement le code du client : moteur de rendu, expérience de jeu, etc.
|
||||
|
||||
Mon maître de stage s'est lui occupé du serveur et des problèmatiques réseau et
|
||||
système
|
||||
|
||||
## État de mes connaissances
|
||||
|
||||
Fort de mon expérience d'administration système au laboratoire des assistants,
|
||||
du laboratoire SRS et de nombreuses expériences personnelles, je partais à
|
||||
l'aise avec les technologies de virtualisation, à la base de l'informatique
|
||||
dans les nuages.
|
||||
|
||||
Mon travail sur l'environnement du serveur de jeu et de son cœur touche à
|
||||
l'ensemble de branche de la majeure SRS : système avec la recherche d'une
|
||||
architecture permettant d'assurer la montée en charge du jeu au fil d'une
|
||||
journée et de la vie du jeu ; réseau puisqu'il fallait prendre en compte les
|
||||
problématiques d'échanges entre les clients et les serveurs, mais aussi entre
|
||||
les serveurs eux-mêmes ; enfin sécurité car les serveurs seront exposés à un
|
||||
grand nombre de personnes qui ne se conteront pas de jouer via le client.
|
||||
|
||||
## Intérêt du stage pour l'entreprise
|
||||
|
||||
Pour l'entreprise, mon stage a permis d'établir :
|
||||
|
||||
* les bases pour permettre aux développeurs de travailler avec un serveur de
|
||||
jeu,
|
||||
* la recherche de méthodes pour assurer la mise à l'échelle du jeu une fois
|
||||
qu'il sera sorti,
|
||||
* la participation aux réflexions de design du serveur de jeu pour permettre
|
||||
une répartition de charge simple, fiable et aisée.
|
||||
|
||||
## Contexte de travail
|
||||
|
||||
L'entreprise est établie dans l'incubateur Agoranov ; une pièce nous y a été
|
||||
attribuée. Nous nous y retrouvons tous pour travailler, il est donc facile de
|
||||
parler à n'importe qui puisque l'on se trouve dans le même espace.
|
||||
|
||||
Dès le premier jour, une machine dotée de composants de pointe m'a été
|
||||
attribuée ; il m'a été laissé le choix du système d'exploitation. Au milieu de
|
||||
mon stage, j'ai eu besoin de travailler avec un disque dur plus réactif, à la
|
||||
suite de ma demande, celui-ci a été commandé dans la semaine.
|
||||
|
||||
Arrivé quelques semaines après la création de l'entreprise, j'ai participé à
|
||||
l'élaboration des premières documentations.
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
# Aspects organisationnels
|
||||
|
||||
## Découpage du stage
|
||||
|
||||
### État de l'art
|
||||
|
||||
Afin de mesurer l'ampleur de l'architecture qu'il est nécessaire de mettre en
|
||||
place, mon stage a débuté par plusieurs comparaisons d'outils et
|
||||
l'apprentissage de certains concepts propres aux jeux vidéo et tout
|
||||
particulièrement aux jeux massivement multi-joueurs.
|
||||
|
||||
Cette étape s'est terminée par le partage avec mon maître de stage de mes
|
||||
résultats ainsi que leur critique.
|
||||
|
||||
### Montée en compétences
|
||||
|
||||
Une fois les outils sélectionnés suivants les critères établis au travers de
|
||||
l'étape précédente, il a fallu monté en compétence sur ceux-ci.
|
||||
|
||||
### Développements et tests de monté en charge
|
||||
|
||||
À la suite de cet apprentissage, j'ai effectués des tests afin de valider les
|
||||
choix qui avaient été fait, afin d'en tirer les conclusions.
|
||||
|
||||
|
||||
## Respect des délais et critique de ce découpage
|
||||
|
||||
À de nombreuses reprises, le planning initialement prévu n'a pas pu être
|
||||
respecté afin de faire face aux besoins qui se sont matérialisés à divers
|
||||
moments. Ainsi, les parties concernant l'intégration de données métriques
|
||||
dans le serveur, utile dans le long terme, a été repoussé afin de se concentrer
|
||||
sur des besoins spécifiques de l'équipe comme la mise à disposition d'un
|
||||
serveur de jeu aux développeurs du client.
|
||||
|
||||
|
||||
## Nature et fréquence des points de contrôle en interne
|
||||
|
||||
Le développement du jeu suit une méthodologie agile : cela a commencé par
|
||||
Kaban, pour arriver aujourd'hui à Scrum.
|
||||
|
||||
Deux fois par semaines, toute l'équipe fait le point sur l'avancée de
|
||||
chacun. C'est l'occasion de recentrer les priorités.
|
||||
|
||||
Tous les jours, nous sommes tenu d'envoyer un petit compte-rendu de nos
|
||||
activités du jour, en n'oubliant pas d'indiquer les difficultés que l'on peut
|
||||
rencontrer. En fonction de la difficulté, un membre de l'équipe peut être amené
|
||||
à donner son avis sur le problème s'il l'a déjà rencontré par le passé.
|
||||
|
||||
Le soir est toujours une bonne occasion de discuter avec mon maître de stage :
|
||||
que ce soit pour se tenir mutuellement informé de nos activités ou pour faire
|
||||
des points sur les développements à venir.
|
||||
|
|
@ -0,0 +1,310 @@
|
|||
# Aspects scientifiques et techniques
|
||||
|
||||
## Analyse des plates-forme d'informatique dans les nuages
|
||||
|
||||
### Objectifs
|
||||
|
||||
Les serveurs du jeu seront regroupés au sein d'une structure permettant
|
||||
facilement d'adapter leur nombre en fonction du besoin (fortement en
|
||||
corrélation avec le nombre de joueurs inscrits et connectés).
|
||||
|
||||
Depuis quelques années, un grand nombre de plate-forme se développent,
|
||||
fournissant un service clef en main ; mais des solutions libres sont également
|
||||
disponibles lorsque l'on désire s'occuper du service manuellement.
|
||||
|
||||
Ici, l'objectif était de trouver les avantages et les inconvénients de chaque
|
||||
fournisseur et de contre balancer cette analyse par rapport aux solutions à
|
||||
mettre en place soi-même.
|
||||
|
||||
### Alternatives possibles
|
||||
|
||||
Développer une solution de mise à l'échelle automatique, parfaitement adapté à
|
||||
nos besoins n'était pas envisageable : cela aurait réclamé une équipe dédiée au
|
||||
développement de cette solution alternative. Comme ce n'est pas le cœur de
|
||||
métier du studio, cette solution a d'emblée été écartée.
|
||||
|
||||
### Cadre imposé
|
||||
|
||||
### Propositions retenues
|
||||
|
||||
Les fournisseurs de service d'hébergement dans les nuages retenus sont :
|
||||
|
||||
* Amazon Web Services Elastic Cloud 2 ;
|
||||
* Digital Ocean ;
|
||||
* Gandi ;
|
||||
* Google Compute Engine ;
|
||||
* Ikoula ;
|
||||
* Linode ;
|
||||
* Lunacloud ;
|
||||
* Numergy ;
|
||||
* Rackspace ;
|
||||
* Windows Azure.
|
||||
|
||||
Les solutions libres retenues sont :
|
||||
|
||||
* Ecalyptus ;
|
||||
* Libvirt.
|
||||
|
||||
### Résultats obtenus
|
||||
|
||||
%FIXME
|
||||
|
||||
|
||||
## Analyse des outils de déploiement automatique
|
||||
|
||||
### Objectifs
|
||||
|
||||
Les outils de déploiement automatique vont éviter toutes les problématiques de
|
||||
configuration des différents serveurs que peuvent être le manque
|
||||
d'harmonisation, les difficultés de réalisation des mises à jour, les besoins
|
||||
de tests de l'environnement avant la mise en production, le redéploiement
|
||||
rapide d'une version stable ou précédente.
|
||||
|
||||
Il est nécessaire de configurer de nombreuses machines dans différents cadres :
|
||||
|
||||
* ajout d'un nouveau serveur au sein du cluster (fournir le contexte) ;
|
||||
* configuration d'une machine virtuelle à destination des développeurs ;
|
||||
* configuration des serveurs annexes (sites web, bases de données, monitoring, ...).
|
||||
|
||||
### Alternatives possibles
|
||||
|
||||
Dans de nombreux environnements chaque machine est configurée à la main par un
|
||||
administrateur système, a chaque étape, une erreur humaine peut venir
|
||||
interférer dans la procédure de mise à jour.
|
||||
|
||||
Cette solution est évidemment à écarter si l'on veut garder le contrôle de son
|
||||
système d'information et pouvoir faire face à tout type de problème.
|
||||
|
||||
### Cadre imposé
|
||||
|
||||
### Propositions retenues
|
||||
|
||||
Les outils de déploiment automatique retenus sont :
|
||||
|
||||
* Ansible ;
|
||||
* Capistrano ;
|
||||
* CFEngine ;
|
||||
* Chef ;
|
||||
* Fabric ;
|
||||
* Puppet.
|
||||
|
||||
### Résultats obtenus
|
||||
|
||||
%FIXME
|
||||
|
||||
|
||||
## Analyse des solutions de virtualisation
|
||||
|
||||
### Objectifs
|
||||
|
||||
La virtualisation peut nous être utile à plusieurs niveaux :
|
||||
|
||||
* la mise en place d'un environnement de tests de plusieurs machines ;
|
||||
* l'utilisation d'un environnement standardisé pour les développeurs ;
|
||||
* le déploiement d'environnements standardisés et minimalistes.
|
||||
|
||||
Si dans une contexte de production les serveurs sont utilisés à une valeur
|
||||
proche de leur puissance maximale, pour un environnement de test, il est tout à
|
||||
fait envisageable de regrouper les différentes machines nécessaire au sein de
|
||||
plusieurs machines virtuelles d'une même machine physique, dédiée aux tests.
|
||||
|
||||
Pour les développeurs, l'installation de l'environnement de développement n'est
|
||||
pas toujours facile (surtout s'ils doivent alterner entre deux systèmes
|
||||
d'exploitation différent) et requiert une certaine standardisation (version
|
||||
précises de certaine bibliothèques, paquet particulier). La virtualisation
|
||||
permet de leur fournir un environnement clef en main qu'ils n'ont pas à
|
||||
maintenir.
|
||||
|
||||
Sont apparues ces dernières années des technologies prônant le déploiement en
|
||||
production de machines virtuelles ou conteneur. Cela permet d'avoir une série
|
||||
de machine hôte dédiée au déploiement et des machines virtuelles minimalistes
|
||||
et standardisées (pas d'écoute SSH par exemple).
|
||||
|
||||
### Propositions retenues
|
||||
|
||||
Sous GNU/Linux, les solutions retenues sont :
|
||||
|
||||
* Docker ;
|
||||
* Libvirt ;
|
||||
* Linux Kernel-based Virtual Machine (KVM) ;
|
||||
* Linux Containers (LXC) ;
|
||||
* Oracle VirtualBox.
|
||||
|
||||
Sur Windows, seul Oracle VirtualBox répondait aux contraintes, en particulier
|
||||
car le logiciel Boot2Docker s'intègre uniquement à cette solution.
|
||||
|
||||
### Résultats obtenus
|
||||
|
||||
Globalement, les technologies de virtualisation de type hyperviseur n'ont plus
|
||||
guère d'avantages face aux conteneurs : ils permettent de garantir un niveau de
|
||||
sécurité et d'isolation quasi-identique, sans avoir la lourdeur de gestion
|
||||
d'autant de noyau que l'on veut lancer de machines.
|
||||
|
||||
Docker et LXC ont donc été retenus. La première version stable de Docker est
|
||||
sortie pendant mon stage, ce qui a été déterminant pour le choix de cette
|
||||
solution. LXC reste dans la course pour tout ce qui nécessite une configuration
|
||||
avancée que ne permettrait pas de faire Docker.
|
||||
|
||||
|
||||
## Conception d'un programme de relevé de métriques système
|
||||
|
||||
### Objectifs
|
||||
|
||||
Afin de pouvoir déterminer le moment optimal pour démarrer un nouveau serveur,
|
||||
il faut relever un certain nombre de métrique et déterminer dans une première
|
||||
phase l'indicateur le plus adapté.
|
||||
|
||||
### Cadre imposé
|
||||
|
||||
Avant mon arrivée dans l'entreprise, mon maître de stage a fait le choix de la
|
||||
base de données InfluxDB pour le stockage des métriques (aussi bien système que
|
||||
business).
|
||||
|
||||
### Propositions retenues
|
||||
|
||||
La base de données retenue est toute récente ; c'est pourquoi il n'existait
|
||||
encore aucun programme pour faire simplement un relevé de métriques système
|
||||
(consommation CPU, mémoire vive disponible, bande passante, ...). Il a donc été
|
||||
choisi de le développer.
|
||||
|
||||
Le langage retenu fut le Go : le langage compilant les binaires statiquement,
|
||||
il n'y aurait donc rien de plus à installer sur les machines sur lesquels nous
|
||||
devrons faire les relevés.
|
||||
|
||||
### Résultats obtenus
|
||||
|
||||
Le projet a été terminé et mis en ligne publiquement sur GitHub sous licence
|
||||
CC0.
|
||||
|
||||
|
||||
## Mise en place d'un processus de livraison du serveur à destination des développeurs du client
|
||||
|
||||
### Objectifs
|
||||
|
||||
Notre jeu se basant sur un serveur, chaque personne utilisant le client
|
||||
(développeur ou graphiste) a donc besoin de se connecter à un serveur « stable
|
||||
» afin de pouvoir visualiser l'impact de ses modifications dans l'environnement
|
||||
de jeu.
|
||||
|
||||
Chaque développeur, pour ses tests peut avoir besoin d'une version particulière
|
||||
du serveur : une version avancée pour les développeurs travaillant sur
|
||||
l'intégration réseau, une version stable pour les graphistes, ... Et chacun
|
||||
peut avoir besoin de faire des tests dans un environnement particulier.
|
||||
|
||||
Ainsi, chacun devrait avoir accès à un serveur de jeu dédié et à un serveur de
|
||||
jeu global (lorsqu'il est question de faire des tests à plusieurs).
|
||||
|
||||
### Cadre imposé
|
||||
|
||||
Le temps passé au développement est primordial comparé au temps passé à tenter
|
||||
de configurer l'environnement à partir de la documentation. Une solution clef
|
||||
en main où le moins de connaissances préalables sont nécessaire est un plus.
|
||||
|
||||
### Propositions retenues
|
||||
|
||||
Pour la mise en place de ce processus, il a été retenu la mise à disposition :
|
||||
|
||||
* de machines virtuelles pré-configurées : l'équipe serveur met à disposition
|
||||
du reste de l'équipe des fichiers `.ova` : un disque virtuel au format `VMDK`
|
||||
associé à une configuration de machine virtuelle au format `OVF` ;
|
||||
* de conteneurs associés à des scripts d'automatisation ;
|
||||
* d'un conteneur sur une machine dédiée : l'équipe serveur s'occupe de mettre
|
||||
en place les conteneurs en fonction des besoins de chacun, sans avoir à gérer
|
||||
les problèmes lié à la configuration personnelle des machines de chacun.
|
||||
|
||||
### Difficultés
|
||||
|
||||
Chacune des solutions listée ci-dessus a été testée. La première solution a
|
||||
souffert d'un manque de consultation des besoins des développeurs : travailler
|
||||
dans une machine virtuelle en ligne de commande n'est en général pas à la
|
||||
portée des développeurs plus habitués à Visual Studio.
|
||||
|
||||
%FIXME parler de l'interface console
|
||||
|
||||
Dans un soucis d'harmonisation des technologies, Docker a été retenu dans un
|
||||
second temps pour répondre également aux problématiques de déploiement futurs.
|
||||
|
||||
Après une semaine de test sur les machines des développeurs, de nombreux
|
||||
problèmes m'ont été remontés. Ces problèmes étant liés d'une part à la
|
||||
difficulté de configuration automatique des machines sous Windows et d'autre
|
||||
part à la complexité grandissante des scripts automatisant pourtant seulement
|
||||
le téléchargement et l'exécution d'un conteneur dans un environnement connu, il
|
||||
a été décidé que ces machines virtuelles ne seraient plus distribuées aux
|
||||
développeurs : ils disposeront d'un accès sur une machine virtuelle maintenue
|
||||
par l'équipe en charge de l'administration système.
|
||||
|
||||
### Résultats obtenus
|
||||
|
||||
Compte tenu de la diversité des systèmes employés et de la non-maîtrise de
|
||||
ceux-ci par les développeurs (filtrage de ports par un anti-virus nouvellement
|
||||
installé, version différentes de Windows, ...), la solution utilisant des
|
||||
conteneurs contrôlés par l'équipe serveur sur une machine dédiée a été retenue.
|
||||
|
||||
|
||||
## Conception de l'architecture de test de monté en charge
|
||||
|
||||
### Objectifs
|
||||
|
||||
Une fois les premières versions du serveur livrées, nous nous sommes rapidement
|
||||
intéressé à ses capacités : en particulier le nombre maximum de joueurs pouvant
|
||||
être accueillit.
|
||||
|
||||
### Propositions retenues
|
||||
|
||||
En tant que start-up, nous avons eu un certain nombre de crédit sur Amazon Web
|
||||
Service afin de tester et démarrer notre activité sur leur plate-forme.
|
||||
|
||||
Nous avons donc utilisé un certain nombre de nos crédits afin de lancer 20
|
||||
machines virtuelles exécutant chacune plusieurs clients.
|
||||
|
||||
### Résultats obtenus
|
||||
|
||||
Dans un premier temps, la monté en charge montrait que le serveur ne permettait
|
||||
pas de dépasser 250 joueurs. Au delà, l'analyse qui s'en est suivie a montré
|
||||
que le scheduler de la bibliothèque d'acteurs que nous utilisions ne faisais
|
||||
pas correctement son travail : il en résultait une surcharge des canaux de
|
||||
diffusion, entraînant le plantage du serveur.
|
||||
|
||||
Ce problème a été corrigé dans la version suivante de la bibliothèque
|
||||
d'acteurs. La nouvelle monté en charge a permis d'atteindre cette fois plus de
|
||||
700 joueurs simultanément, à ce moment, c'était bien le CPU qui était limitant
|
||||
et il n'en résultat pas de plantage du serveur.
|
||||
|
||||
|
||||
## Conception de l'architecture des serveurs
|
||||
|
||||
### Objectifs
|
||||
|
||||
### Alternatives possibles
|
||||
|
||||
### Cadre imposé
|
||||
|
||||
### Propositions retenues
|
||||
|
||||
### Difficultés
|
||||
|
||||
### Résultats obtenus
|
||||
|
||||
|
||||
## Intégration de métriques dans le serveur
|
||||
|
||||
### Objectifs
|
||||
|
||||
Les métriques relevées précédemment concernait le système : consommation CPU,
|
||||
utilisation de la mémoire et de la bande passante, ... Pour des besoins
|
||||
statistiques (et à terme business), il est nécessaire d'intégrer au serveur
|
||||
l'envoi de métrique telles que le nombre de joueurs inscrits, connectés, ...
|
||||
|
||||
### Difficultés
|
||||
|
||||
Le serveur étant écrit en C++, il est nécessaire d'utiliser une bibliothèque C
|
||||
ou C++ pour s'interfacer avec la base de données. Malheureusement, comme elle
|
||||
est récente, cette bibliothèque n'avait pas encore été développée.
|
||||
|
||||
J'ai donc pris le soin de la développer puis de la proposer aux développeurs de
|
||||
la base de données qui l'ont intégré, La bibliothèque est désormais disponible
|
||||
sur GitHub : https://github.com/influxdb/influxdb-c
|
||||
|
||||
### Résultats obtenus
|
||||
|
||||
Le travail d'intégration de métriques a d'abord conduit à la réalisation
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
%%scoped-include(R_abstract.md)
|
||||
%%scoped-include(R_intro.md)
|
||||
%%scoped-include(R_organisationnels.md)
|
||||
%%scoped-include(R_technique.md)
|
||||
|
||||
\backmatter
|
||||
\appendix
|
||||
|
||||
\addcontentsline{toc}{part}{\protect\numberline{}Annexes}
|
||||
\part*{Annexes}
|
||||
|
||||
Ici les annexes.
|
||||
|
||||
\listoffigures
|
||||
\listoftables
|
||||
Reference in New Issue