diff --git a/doc/rapport.gpp.md b/doc/rapport.gpp.md
index 81a70a34a103917a2131765e0f4003ace9f5e26f..b0ea0dc708fde73cbee656cba725e3e188fa82bd 100644
--- a/doc/rapport.gpp.md
+++ b/doc/rapport.gpp.md
@@ -60,6 +60,7 @@ abstract: |
 !!defacronym{BIOS}{_Basic Input Output System_: système de base d'entrée sortie}
 !!defacronym{DHCP}{_Dynamic Host Configuration Protocol_: protocole de configuration dynamique des hôtes }
 !!defacronym{EFI}{_Extensible Firmware Interface_: interface micrologicielle extensible unifiée}
+!!defacronym{ESP}{_EFI System Partition_: partition système EFI}
 !!defacronym{FTP}{_File Transfer Protocol_: protocole de transfert de fichier}
 !!defacronym{GPT}{_GUID Partition Table_: table de partitionnement GUID}
 !!defacronym{GRUB}{_GRand Unified Bootloader_}
@@ -69,9 +70,11 @@ abstract: |
 !!defacronym{IPFS}{_InterPlanetary File System_: système de fichier inter-planétaire}
 !!defacronym{IP}{_Internet Protocol_: protocole internet}
 !!defacronym{LDAP}{_Lightweight Directory Access Protocol_: protocole léger d'accès à un annuaire}
+!!defacronym{MAC}{_Media Access Control (address)_: adresse physique}
 !!defacronym{MBR}{_Master Boot Record_: enregistrement d'amorcage maître}
 !!defacronym{NAT}{_Network Address Translation_: traduction d'adresse réseau}
 !!defacronym{NFS}{_Network File System_: système de fichiers en réseau}
+!!defacronym{NVRAM}{_Non-Volatile Random Access Memory_: mémoire vive non volatile}
 !!defacronym{OS}{_Operating System_: système d'exploitation}
 !!defacronym{PC}{_Personal Computer_: ordinateur personnel}
 !!defacronym{PXE}{_Pre-boot eXecution Environment_: environnement d'exécution pré-démarrage}
@@ -82,7 +85,6 @@ abstract: |
 !!defacronym{UEFI}{_Unified Extensible Firmware Interface_: interface micrologicielle extensible unifiée}
 !!defacronym{WWW}{_World Wide Web_: toile mondiale / réseau mondial}
 
-
 !!tableofcontents
 !!newpage
 !!listofacronyms
@@ -1460,16 +1462,174 @@ le même temps que dans ces circonstances idéales.
 
 ## Amélioration des scripts de déploiement
 
-**TODO: Expliquer les problèmes rencontrés avec les scripts de
-déploiement initiaux et les nombreuses améliorations apportées par leur
-ré-écriture  
-quasi-complète (gestion des erreurs, stack traces, amélioration des
-logs, gestion des images plus grandes que le cache, mesure des timings,
-scripts utilitaires de maintenance, possibilité d'utiliser clonezilla,
-détection du point d'entrée EFI).**
+De très nombreuses améliorations ont été apportées aux scripts de
+déploiement, au point qu'ils sont presque complètement différents des
+scripts initiaux.
+
+### Gestion des erreurs
+
+Premièrement, la gestion des erreurs, inexistante dans le script initial
+a été rajoutée. Les codes de retour des commandes sont vérifiés et les
+données récupérées depuis la sortie de ces commandes sont validées avant
+utilisation. Si un code de retour ou une donnée récupérée n'est pas au
+format attendu, une fonction spéciale `fatal_error` est appelée avec
+comme argument un message d'erreur adapté à la situation. Cette fonction
+va afficher le message d'erreur, ainsi qu'une trace de la pile des
+appels (_stack trace_ en anglais). Cette trace permet d'identifier
+précisément à quelle ligne de quel fonction et dans quel fichier une
+erreur a eu lieu.
+
+Finalement, le script de déploiement `bootiful-deploy` sera quitté avec
+un code d'erreur, ce qui permet au script parent, `bootiful-init`, de
+détecter qu'une erreur a eu lieu et de proposer à l'utilisateur quelle
+action il souhaite effectuer parmi les choix suivants:
+
+- Recommencer le déploiement
+- Redémarrer la machine
+- Éteindre la machine
+- Ouvrir un _shell_ interactif (`/bin/bash`) pour étudier la cause de
+  l'erreur. Une fois le _shell_ terminé, l'utilisateur peut à nouveau
+  choisir ce qu'il souhaite faire.
+
+Le mécanisme de gestion d'erreurs a été très utile lors du développement
+et du test des scripts de déploiement pour comprendre pourquoi certaines
+erreurs arrivaient et adapter les scripts pour les éviter. Ce mécanisme
+sera aussi utile pour aider un futur administrateur du système à
+comprendre ce qu'il se passe si un déploiement ne se déroule pas comme
+prévu.
+
+### Mesure du temps écoulé
+
+Un système permettant de mesurer et d'afficher le temps passé dans
+chaque section du script de déploiement a été créé. Il permet de mesurer
+chacune des parties et d'afficher le temps passé dans chaque partie à la
+fin du script. Les parties mesurées sont classées en deux catégories:
+_batch_ et _interactive_. Les parties _batch_ sont celles qui sont
+exécutées automatiquement, sans intervention de l'utilisateur, tandis
+que les parties _interactive_ sont celles où le système attend un choix
+de l'utilisateur, comme par exemple le choix de l'image à déployer.
+Cette catégorisation des parties permet d'afficher à la fin du script
+combien de temps a été passé dans les parties _batch_ sans prendre en
+compte le temps passé à attendre un choix de l'utilisateur.
+
+### Amélioration des logs
+
+
+Plusieurs améliorations ont été apportées au mécanisme de logging. Dans
+le système initial, les flux `stdin` et `stdout` du script de
+déploiement étaient redirigés vers un fichier de log sur le serveur.
+Cela permet d'étudier à _posteriori_ comment le déploiement s'est
+effectué, et de vérifier la durée d'exécution. Cela permet aussi de
+comprendre ce qui s'est mal passé en cas d'erreur.
+
+Dans le système initial, étant donné que les flux sont redirigés vers un
+fichier, un écran noir est affiché sur l'écran du poste client. Cela a
+l'inconvénient de ne pas permettre à l'utilisateur du poste client de
+savoir ce qu'il est en train de se passer. Il n'est pas possible pour
+l'utilisateur de savoir si le déploiement est en cours ou s'il est
+bloqué sur une étape. La première modification apportée au système de
+logging a été d'utiliser la commande `tee` pour écrire dans les fichiers
+de log, au lieu d'une simple redirection. Cela permet aux sorties d'être
+simultanément affichées sur l'écran du client et sauvegardée dans les
+logs.
+
+De nombreux textes informatifs ont aussi été rajoutés dans la sortie du
+script pour expliquer ce qu'il est en train de se passer petit à petit.
+Cela permet de mieux contextualiser chaque ligne de log. Une barre de
+progression a aussi été rajoutée lors du déploiement d'une image au
+format _raw_ pour que l'utilisateur puisse suivre la progression du
+déploiement et qu'il puisse voir le temps écoulé ainsi qu'une estimation
+du temps restant.
+
+Le mécanisme initial de logging créait un fichier de log par poste
+client, en le nommant avec l'adresse !!acronym{MAC} du poste. Chaque
+déploiement successif était loggué dans ce même fichier. Pour bien
+différencier le début et la fin d'un log, une ligne facilement
+reconnaissable contenant la date et l'heure était affichée. Il y a
+plusieurs problèmes avec ce système:
+
+- Les fichiers de log peuvent devenir très gros après de nombreux
+  déploiements.
+- Le nettoyage du dossier de logs pour ne garder que les plus récents
+  est compliqué, car chaque fichier contient les logs de plusieurs
+  déploiements.
+- La manipulation avec des commandes standard telles que `grep`, `awk`,
+  `tail` du log d'un déploiement précis est compliqué.
+- La comparaison de deux logs de déploiement sur la même machine est
+  difficile car il faut trouver où les déploiements commencent et se
+  terminent dans le même fichier.
+
+Le système de log a donc été modifié pour qu'un fichier par déploiement
+soit créé par déploiement. Chaque fichier de log est nommé selon
+l'adresse mac de la machine ainsi que la date et l'heure du début du
+déploiement.
+
+### Intégration de _Clonezilla_ comme type d'image
+
+Le script de déploiement a été modifié pour pouvoir détecter si une
+image est au format _raw_ ou s'il s'agit d'une image _Clonezilla_. Selon
+le type d'image, des stratégies différentes sont utilisées pour
+différentes étapes du déploiement:
+
+- Détermination de la place nécessaire sur le disque pour déployer
+  l'image
+- Commandes utilisées pour le déploiement
+- Détermination du point d'entrée EFI.
+
+### Détection automatique du point d'entrée !!acronym{EFI}
+
+Si l'image est au format _Clonezilla_, le script de déploiement est
+capable de déterminer automatiquement quel sera le programme
+!!acronym{EFI} qui sera exécuté au prochain démarrage pour démarrer
+l'!!acronym{OS} déployé.
+
+En effet, les images _Clonezilla_ de systèmes !!acronym{EFI} contiennent
+un fichier spécial, `efi-nvram.dat`, qui contient les variables
+contenues dans la !!acronym{NVRAM} du système !!acronym{EFI} au moment
+de la création de l'image. Cette mémoire contient notemment l'ordre des
+entrées de boot et les programmes !!acronym{EFI} à exécuter pour chacune
+de ces entrées, si applicable.
+
+Par exemple, voici le contenu du fichier `nvram.dat` de l'image _Windows
+10_ mentionnée dans les sections précédentes:
+
+```bash
+BootCurrent: 0001
+Timeout: 0 seconds
+BootOrder: 0000,0001
+Boot0000* Windows Boot Manager	HD(1,GPT,0cccfd69-e584-4e2d-8a5d-6afa7130fcab,0x800,0x15e000) /File(\EFI\Microsoft\Boot\bootmgfw.efi) WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
+Boot0001* UEFI:  USB DISK 3.0 PMAP	PciRoot(0x0)/Pci(0x14,0x0)/USB(16,0)/CDROM(1,0x344,0x5e00)..BO
+```
+
+Le script de déploiement est capable de lire ce fichier, de trouver la
+première entrée contenant un chemin vers un exécutable !!acronym{EFI},
+et transformer ce chemin en un chemin _Unix_, c'est à dire avec
+le caractère `/` au lieu de `\` et des noms de dossiers et fichiers
+sensibles à la casse, qui correspondent à des dossiers et fichiers
+présents sur la partition !!acronym{ESP} qui vient d'être déployée.
+Cette conversion est importante car ce chemin devra être passé à
+!!acronym{GRUB}, qui ne sait lire que des chemins au format _Unix_.
+
+Une fois le point d'entrée déterminé un fichier `efi_entrypoint` est
+écrit à la racine de la partition !!acronym{ESP}. Il sera ensuite lu par
+!!acronym{GRUB} au prochain démarrage pour trouver le point d'entrée à
+exécuter. Le contenu de ce fichier ressemblera à ceci:
+
+```bash
+set efi_entrypoint=/efi/Microsoft/Boot/bootmgfw.efi
+```
+
+Si l'image est au format _raw_, ou alors qu'il est souhaité
+d'outrepasser la lecture automatique du point d'entrée d'une image
+_Clonezilla_, il suffit de rajouter un fichier `efi_entrypoint` dans le
+dossier de l'image. Ce fichier sera directement copié dans
+l'!!acronym{ESP}, sans qu'une tentative de détermination automatique du
+point d'entrée à partir du fichier `nvram.dat` soit effectuée.
 
 ## Personnalisation d'images post-déploiement
 
+Un système de personnalisation
+
 **TODO: expliquer pourquoi Ansible a été choisi pour cette tache, et des
 avantages que cela apporte de pouvoir customiser une image
 post-déploiement plutôt que d'avoir une multitude d'images pour chaque
diff --git a/doc/rapport.md b/doc/rapport.md
index db595d126bc499dd53d5468c3d826fa8d62fb76f..08526953649d984f22f6baca4b526754dfd7833d 100644
--- a/doc/rapport.md
+++ b/doc/rapport.md
@@ -12,6 +12,8 @@
 
 - **EFI**: _Extensible Firmware Interface_: interface micrologicielle extensible unifiée
 
+- **ESP**: _EFI System Partition_: partition système EFI
+
 - **FTP**: _File Transfer Protocol_: protocole de transfert de fichier
 
 - **GPT**: _GUID Partition Table_: table de partitionnement GUID
@@ -30,12 +32,16 @@
 
 - **LDAP**: _Lightweight Directory Access Protocol_: protocole léger d'accès à un annuaire
 
+- **MAC**: _Media Access Control (address)_: adresse physique
+
 - **MBR**: _Master Boot Record_: enregistrement d'amorcage maître
 
 - **NAT**: _Network Address Translation_: traduction d'adresse réseau
 
 - **NFS**: _Network File System_: système de fichiers en réseau
 
+- **NVRAM**: _Non-Volatile Random Access Memory_: mémoire vive non volatile
+
 - **OS**: _Operating System_: système d'exploitation
 
 - **PC**: _Personal Computer_: ordinateur personnel
@@ -1513,20 +1519,223 @@ Table des temps de déploiement d'une grande image _Windows 10_ dans plusieurs f
 
 
 
-Plusieurs choses
+Ces mesures permettent de se rendre contre de plusieurs faits
+remarquables, qui ne sont pas forcément intuitifs.
+
+Sur des très petites images le déploiement au format _raw_ compressé
+avec _gzip_ est plus rapide que le déploiement avec _Clonezilla_. Ceci
+peut s'expliquer par le fait que _Clonezilla_ prend du temps pour créer
+une table des partitions, un système de fichiers pour chacune de ces
+partitions et copie ensuite les blocs un à un sur chaque système de
+fichiers. Sur une grande image, ce mode de fonctionnement est "rentable"
+car il y a beaucoup de blocs qui n'auront pas à être copiés, alors
+qu'une image _raw_ devra passer du temps à copier les données de chacun
+de ces blocs. Sur une très petite image comme l'image _Debian_ mesurée
+ici, presque tous les blocs du système de fichiers sont déjà utilisés,
+donc la copie brute des données des partitions est plus rapide car tout
+le temps est passé à copier les données.
+
+Sur les plus grosses images, cependant, _Clonezilla_ a clairement
+l'avantage, car de nombreux blocs vides n'ont pas besoin d'être copiés.
+Ainsi, avec les images plus larges utilisées dans les mesures, le temps
+de déploiement des images plus larges au format _raw_ prend environ 5 à
+9 fois plus de temps que le temps de déploiement avec _Clonezilla_.
+
+Un autre fait remarquable est que le déploiement d'une image _raw_ déjà
+mise en cache prend plus de temps que le déploiement avec une copie
+simultanée dans le cache. Cela s'explique peut être par le fait que dans
+le premier cas, des données doivent être lues depuis le disque et
+écrites sur le même disque, tandis que dans le second cas, seule de
+l'écriture est effectuée.
+
+Par contre, dans le cas des images _Clonezilla_, le déploiement d'une
+image déjà présente en cache s'effectue plus rapidement que le
+déploiement d'une image présente en cache. C'est l'inverse de ce qui se
+passe avec les images _raw_. Cela s'explique par le fait que les images
+_Clonezilla_ sont copiées avant d'être déployées, alors que les images
+_raw_ sont copiées et déployées simultanément.
+
+Il est important de se rappeller que les mesures montrées ici sont
+effectuées dans des circonstances idéales: il n'y a qu'un seul client
+qui télécharge l'image, seul un switch réseau sépare le client du
+serveur et le client et le serveur sont les appareils connectés à ce
+réseau local. Dans des conditions réelles, plusieurs machines seront
+fréquemment en train de télécharger des images depuis le serveur en même
+temps. Dans ce cas, le temps de déploiement d'une image non présente en
+cache risque de prendre beaucoup plus de temps. Au contraire, le
+déploiement d'une image déjà mise en cache devrait théoriquement prendre
+le même temps que dans ces circonstances idéales.
 
 ## Amélioration des scripts de déploiement
 
-**TODO: Expliquer les problèmes rencontrés avec les scripts de
-déploiement initiaux et les nombreuses améliorations apportées par leur
-ré-écriture  
-quasi-complète (gestion des erreurs, stack traces, amélioration des
-logs, gestion des images plus grandes que le cache, mesure des timings,
-scripts utilitaires de maintenance, possibilité d'utiliser clonezilla,
-détection du point d'entrée EFI).**
+De très nombreuses améliorations ont été apportées aux scripts de
+déploiement, au point qu'ils sont presque complètement différents des
+scripts initiaux.
+
+### Gestion des erreurs
+
+Premièrement, la gestion des erreurs, inexistante dans le script initial
+a été rajoutée. Les codes de retour des commandes sont vérifiés et les
+données récupérées depuis la sortie de ces commandes sont validées avant
+utilisation. Si un code de retour ou une donnée récupérée n'est pas au
+format attendu, une fonction spéciale `fatal_error` est appelée avec
+comme argument un message d'erreur adapté à la situation. Cette fonction
+va afficher le message d'erreur, ainsi qu'une trace de la pile des
+appels (_stack trace_ en anglais). Cette trace permet d'identifier
+précisément à quelle ligne de quel fonction et dans quel fichier une
+erreur a eu lieu.
+
+Finalement, le script de déploiement `bootiful-deploy` sera quitté avec
+un code d'erreur, ce qui permet au script parent, `bootiful-init`, de
+détecter qu'une erreur a eu lieu et de proposer à l'utilisateur quelle
+action il souhaite effectuer parmi les choix suivants:
+
+- Recommencer le déploiement
+- Redémarrer la machine
+- Éteindre la machine
+- Ouvrir un _shell_ interactif (`/bin/bash`) pour étudier la cause de
+  l'erreur. Une fois le _shell_ terminé, l'utilisateur peut à nouveau
+  choisir ce qu'il souhaite faire.
+
+Le mécanisme de gestion d'erreurs a été très utile lors du développement
+et du test des scripts de déploiement pour comprendre pourquoi certaines
+erreurs arrivaient et adapter les scripts pour les éviter. Ce mécanisme
+sera aussi utile pour aider un futur administrateur du système à
+comprendre ce qu'il se passe si un déploiement ne se déroule pas comme
+prévu.
+
+### Mesure du temps écoulé
+
+Un système permettant de mesurer et d'afficher le temps passé dans
+chaque section du script de déploiement a été créé. Il permet de mesurer
+chacune des parties et d'afficher le temps passé dans chaque partie à la
+fin du script. Les parties mesurées sont classées en deux catégories:
+_batch_ et _interactive_. Les parties _batch_ sont celles qui sont
+exécutées automatiquement, sans intervention de l'utilisateur, tandis
+que les parties _interactive_ sont celles où le système attend un choix
+de l'utilisateur, comme par exemple le choix de l'image à déployer.
+Cette catégorisation des parties permet d'afficher à la fin du script
+combien de temps a été passé dans les parties _batch_ sans prendre en
+compte le temps passé à attendre un choix de l'utilisateur.
+
+### Amélioration des logs
+
+
+Plusieurs améliorations ont été apportées au mécanisme de logging. Dans
+le système initial, les flux `stdin` et `stdout` du script de
+déploiement étaient redirigés vers un fichier de log sur le serveur.
+Cela permet d'étudier à _posteriori_ comment le déploiement s'est
+effectué, et de vérifier la durée d'exécution. Cela permet aussi de
+comprendre ce qui s'est mal passé en cas d'erreur.
+
+Dans le système initial, étant donné que les flux sont redirigés vers un
+fichier, un écran noir est affiché sur l'écran du poste client. Cela a
+l'inconvénient de ne pas permettre à l'utilisateur du poste client de
+savoir ce qu'il est en train de se passer. Il n'est pas possible pour
+l'utilisateur de savoir si le déploiement est en cours ou s'il est
+bloqué sur une étape. La première modification apportée au système de
+logging a été d'utiliser la commande `tee` pour écrire dans les fichiers
+de log, au lieu d'une simple redirection. Cela permet aux sorties d'être
+simultanément affichées sur l'écran du client et sauvegardée dans les
+logs.
+
+De nombreux textes informatifs ont aussi été rajoutés dans la sortie du
+script pour expliquer ce qu'il est en train de se passer petit à petit.
+Cela permet de mieux contextualiser chaque ligne de log. Une barre de
+progression a aussi été rajoutée lors du déploiement d'une image au
+format _raw_ pour que l'utilisateur puisse suivre la progression du
+déploiement et qu'il puisse voir le temps écoulé ainsi qu'une estimation
+du temps restant.
+
+Le mécanisme initial de logging créait un fichier de log par poste
+client, en le nommant avec l'adresse <abbr title="Media Access Control (address): adresse physique ">MAC</abbr> du poste. Chaque
+déploiement successif était loggué dans ce même fichier. Pour bien
+différencier le début et la fin d'un log, une ligne facilement
+reconnaissable contenant la date et l'heure était affichée. Il y a
+plusieurs problèmes avec ce système:
+
+- Les fichiers de log peuvent devenir très gros après de nombreux
+  déploiements.
+- Le nettoyage du dossier de logs pour ne garder que les plus récents
+  est compliqué, car chaque fichier contient les logs de plusieurs
+  déploiements.
+- La manipulation avec des commandes standard telles que `grep`, `awk`,
+  `tail` du log d'un déploiement précis est compliqué.
+- La comparaison de deux logs de déploiement sur la même machine est
+  difficile car il faut trouver où les déploiements commencent et se
+  terminent dans le même fichier.
+
+Le système de log a donc été modifié pour qu'un fichier par déploiement
+soit créé par déploiement. Chaque fichier de log est nommé selon
+l'adresse mac de la machine ainsi que la date et l'heure du début du
+déploiement.
+
+### Intégration de _Clonezilla_ comme type d'image
+
+Le script de déploiement a été modifié pour pouvoir détecter si une
+image est au format _raw_ ou s'il s'agit d'une image _Clonezilla_. Selon
+le type d'image, des stratégies différentes sont utilisées pour
+différentes étapes du déploiement:
+
+- Détermination de la place nécessaire sur le disque pour déployer
+  l'image
+- Commandes utilisées pour le déploiement
+- Détermination du point d'entrée EFI.
+
+### Détection automatique du point d'entrée <abbr title="Extensible Firmware Interface: interface micrologicielle extensible unifiée ">EFI</abbr>
+
+Si l'image est au format _Clonezilla_, le script de déploiement est
+capable de déterminer automatiquement quel sera le programme
+<abbr title="Extensible Firmware Interface: interface micrologicielle extensible unifiée ">EFI</abbr> qui sera exécuté au prochain démarrage pour démarrer
+l'<abbr title="Operating System: système d’exploitation ">OS</abbr> déployé.
+
+En effet, les images _Clonezilla_ de systèmes <abbr title="Extensible Firmware Interface: interface micrologicielle extensible unifiée ">EFI</abbr> contiennent
+un fichier spécial, `efi-nvram.dat`, qui contient les variables
+contenues dans la <abbr title="Non-Volatile Random Access Memory: mémoire vive non volatile ">NVRAM</abbr> du système <abbr title="Extensible Firmware Interface: interface micrologicielle extensible unifiée ">EFI</abbr> au moment
+de la création de l'image. Cette mémoire contient notemment l'ordre des
+entrées de boot et les programmes <abbr title="Extensible Firmware Interface: interface micrologicielle extensible unifiée ">EFI</abbr> à exécuter pour chacune
+de ces entrées, si applicable.
+
+Par exemple, voici le contenu du fichier `nvram.dat` de l'image _Windows
+10_ mentionnée dans les sections précédentes:
+
+```bash
+BootCurrent: 0001
+Timeout: 0 seconds
+BootOrder: 0000,0001
+Boot0000* Windows Boot Manager	HD(1,GPT,0cccfd69-e584-4e2d-8a5d-6afa7130fcab,0x800,0x15e000) /File(\EFI\Microsoft\Boot\bootmgfw.efi) WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
+Boot0001* UEFI:  USB DISK 3.0 PMAP	PciRoot(0x0)/Pci(0x14,0x0)/USB(16,0)/CDROM(1,0x344,0x5e00)..BO
+```
+
+Le script de déploiement est capable de lire ce fichier, de trouver la
+première entrée contenant un chemin vers un exécutable <abbr title="Extensible Firmware Interface: interface micrologicielle extensible unifiée ">EFI</abbr>,
+et transformer ce chemin en un chemin _Unix_, c'est à dire avec
+le caractère `/` au lieu de `\` et des noms de dossiers et fichiers
+sensibles à la casse, qui correspondent à des dossiers et fichiers
+présents sur la partition <abbr title="EFI System Partition: partition système EFI ">ESP</abbr> qui vient d'être déployée.
+Cette conversion est importante car ce chemin devra être passé à
+<abbr title="GRand Unified Bootloader ">GRUB</abbr>, qui ne sait lire que des chemins au format _Unix_.
+
+Une fois le point d'entrée déterminé un fichier `efi_entrypoint` est
+écrit à la racine de la partition <abbr title="EFI System Partition: partition système EFI ">ESP</abbr>. Il sera ensuite lu par
+<abbr title="GRand Unified Bootloader ">GRUB</abbr> au prochain démarrage pour trouver le point d'entrée à
+exécuter. Le contenu de ce fichier ressemblera à ceci:
+
+```bash
+set efi_entrypoint=/efi/Microsoft/Boot/bootmgfw.efi
+```
+
+Si l'image est au format _raw_, ou alors qu'il est souhaité
+d'outrepasser la lecture automatique du point d'entrée d'une image
+_Clonezilla_, il suffit de rajouter un fichier `efi_entrypoint` dans le
+dossier de l'image. Ce fichier sera directement copié dans
+l'<abbr title="EFI System Partition: partition système EFI ">ESP</abbr>, sans qu'une tentative de détermination automatique du
+point d'entrée à partir du fichier `nvram.dat` soit effectuée.
 
 ## Personnalisation d'images post-déploiement
 
+Un système de personnalisation
+
 **TODO: expliquer pourquoi Ansible a été choisi pour cette tache, et des
 avantages que cela apporte de pouvoir customiser une image
 post-déploiement plutôt que d'avoir une multitude d'images pour chaque
diff --git a/doc/rapport.pdf b/doc/rapport.pdf
index 394dcd5a1f843ae31b7900132c3e5d5bdb1f0ce3..0a566c9d888f2de26825617844bf1956e63fde3d 100644
Binary files a/doc/rapport.pdf and b/doc/rapport.pdf differ