diff --git a/Theorie/Threads/coordination.rst b/Theorie/Threads/coordination.rst
index db00523beef162663e3250fc967bc2631f985e1d..d8e15e8087472ab264a0d317ef27efcd10bc684d 100644
--- a/Theorie/Threads/coordination.rst
+++ b/Theorie/Threads/coordination.rst
@@ -210,50 +210,44 @@ Il existe différentes implémentations des threads POSIX. Les mécanismes de co
 Il reste cependant quelques concepts qu'il est utile de connaître lorsque l'on développe des programmes découpés en threads en langage C.
 
 
+..
+	Variables ``volatile``
+	----------------------
 
-.. Variables ``volatile``
-.. ----------------------
-
-.. Normalement, dans un programme C, lorsqu'une variable est définie, ses accès sont contrôlés entièrement par le compilateur. Si la variable est utilisée dans plusieurs calculs successifs, il peut être utile d'un point de vue des performances de stocker la valeur de cette variable dans un registre pendant au moins le temps correspondant à l'exécution de quelques instructions [#fregister]_. Cette optimisation peut éventuellement poser des difficultés dans certains programmes utilisant des threads puisqu'une variable peut être potentiellement modifiée ou lue par plusieurs threads simultanément.
-
-.. Les premiers compilateurs C avaient pris en compte un problème similaire. Lorsqu'un programme ou un système d'exploitation interagit avec des dispositifs d'entrée-sortie, cela se fait parfois en permettant au dispositif d'écrire directement en mémoire à une adresse connue par le système d'exploitation. La valeur présente à cette adresse peut donc être modifiée par le dispositif d'entrée-sortie sans que le programme ne soit responsable de cette modification. Face à ce problème, les inventeurs du langage C ont introduit le qualificatif ``volatile``. Lorsqu'une variable est ``volatile``, cela indique au compilateur qu'il doit recharger la variable de la mémoire chaque fois qu'elle est utilisée.
-
-.. Pour bien comprendre l'impact de ce qualificatif, il est intéressant d'analyser le code assembleur généré par un compilateur C dans l'exemple suivant.
-
+	Normalement, dans un programme C, lorsqu'une variable est définie, ses accès sont contrôlés entièrement par le compilateur. Si la variable est utilisée dans plusieurs calculs successifs, il peut être utile d'un point de vue des performances de stocker la valeur de cette variable dans un registre pendant au moins le temps correspondant à l'exécution de quelques instructions [#fregister]_. Cette optimisation peut éventuellement poser des difficultés dans certains programmes utilisant des threads puisqu'une variable peut être potentiellement modifiée ou lue par plusieurs threads simultanément.
 
-..
+	Les premiers compilateurs C avaient pris en compte un problème similaire. Lorsqu'un programme ou un système d'exploitation interagit avec des dispositifs d'entrée-sortie, cela se fait parfois en permettant au dispositif d'écrire directement en mémoire à une adresse connue par le système d'exploitation. La valeur présente à cette adresse peut donc être modifiée par le dispositif d'entrée-sortie sans que le programme ne soit responsable de cette modification. Face à ce problème, les inventeurs du langage C ont introduit le qualificatif ``volatile``. Lorsqu'une variable est ``volatile``, cela indique au compilateur qu'il doit recharger la variable de la mémoire chaque fois qu'elle est utilisée.
 
-.. code-block:: c
-    int x=1;
-    int v[2];
-    void f(void ) {
-      v[0]=x;
-      v[1]=x;
-    }
+	Pour bien comprendre l'impact de ce qualificatif, il est intéressant d'analyser le code assembleur généré par un compilateur C dans l'exemple suivant.
 
-.. Dans ce cas, la fonction ``f`` est traduite en la séquence d'instructions suivante :
 
-..
+	.. code-block:: c
+	    int x=1;
+	    int v[2];
+	    void f(void ) {
+	      v[0]=x;
+	      v[1]=x;
+	    }
 
-.. code-block:: nasm
-   f:
-	movl	x, %eax
-	movl	%eax, v
-	movl	%eax, v+4
-	ret
-.. Si par contre la variable ``x`` est déclarée comme étant ``volatile``, le compilateur ajoute une instruction ``movl x, %eax`` qui permet de recharger la valeur de ``x`` dans un registre avant la seconde utilisation.
+	Dans ce cas, la fonction ``f`` est traduite en la séquence d'instructions suivante :
 
-..
+	.. code-block:: nasm
+	   f:
+		movl	x, %eax
+		movl	%eax, v
+		movl	%eax, v+4
+		ret
+	Si par contre la variable ``x`` est déclarée comme étant ``volatile``, le compilateur ajoute une instruction ``movl x, %eax`` qui permet de recharger la valeur de ``x`` dans un registre avant la seconde utilisation.
 
-.. code-block:: nasm
-   f:
-	movl	x, %eax
-	movl	%eax, v
-	movl	x, %eax
-	movl	%eax, v+4
-	ret
+	.. code-block:: nasm
+	   f:
+		movl	x, %eax
+		movl	%eax, v
+		movl	x, %eax
+		movl	%eax, v+4
+		ret
 
-.. Le qualificatif ``volatile`` force le compilateur à recharger la variable depuis la mémoire avant chaque utilisation. Ce qualificatif est utile lorsque le contenu stocké à une adresse mémoire peut être modifié par une autre source que le programme lui-même. C'est le cas dans les threads, mais marquer les variables partagées par des threads comme ``volatile`` ne suffit pas. Si ces variables sont modifiées par certains threads, il est nécessaire d'utiliser des :term:`mutex` ou d'autres techniques de coordination pour réguler l'accès en ces variables partagées. En pratique, la documentation du programme devra spécifier quelles variables sont partagées entre les threads et la technique de coordination éventuelle qui est utilisée pour en réguler les accès. L'utilisation du qualificatif ``volatile`` permet de forcer le compilateur à recharger le contenu de la variable depuis la mémoire avant toute utilisation. C'est une règle de bonne pratique qu'il est utile de suivre. Il faut cependant noter que dans l'exemple ci-dessus, l'utilisation du qualificatif ``volatile`` augmente le nombre d'accès à la mémoire et peut donc dans certains cas réduire les performances. 
+	Le qualificatif ``volatile`` force le compilateur à recharger la variable depuis la mémoire avant chaque utilisation. Ce qualificatif est utile lorsque le contenu stocké à une adresse mémoire peut être modifié par une autre source que le programme lui-même. C'est le cas dans les threads, mais marquer les variables partagées par des threads comme ``volatile`` ne suffit pas. Si ces variables sont modifiées par certains threads, il est nécessaire d'utiliser des :term:`mutex` ou d'autres techniques de coordination pour réguler l'accès en ces variables partagées. En pratique, la documentation du programme devra spécifier quelles variables sont partagées entre les threads et la technique de coordination éventuelle qui est utilisée pour en réguler les accès. L'utilisation du qualificatif ``volatile`` permet de forcer le compilateur à recharger le contenu de la variable depuis la mémoire avant toute utilisation. C'est une règle de bonne pratique qu'il est utile de suivre. Il faut cependant noter que dans l'exemple ci-dessus, l'utilisation du qualificatif ``volatile`` augmente le nombre d'accès à la mémoire et peut donc dans certains cas réduire les performances. 
 
 Variables spécifiques à un thread
 ---------------------------------
diff --git a/Theorie/Threads/threads.rst b/Theorie/Threads/threads.rst
index 1e0c2a72025996059ce05d5b89fd6741c63b0e61..c0f15410ac5a86ea6469aa9fcddf5a86d072c120 100644
--- a/Theorie/Threads/threads.rst
+++ b/Theorie/Threads/threads.rst
@@ -84,37 +84,35 @@ Considérons la fonction ``f`` :
     }
     return m;
   }
-
-.. En assembleur, cette fonction se traduit en :
-
-..
-
-.. code-block:: nasm
-	f:
-	subl	$16, %esp
-	movl	24(%esp), %eax
-	movl	20(%esp), %ecx
-	movl	%ecx, 12(%esp)
-	movl	%eax, 8(%esp)
-	movl	$0, 4(%esp)
-	movl	$0, (%esp)
-	.LBB0_1:
-	movl	(%esp), %eax
-	cmpl	8(%esp), %eax
-	jge	.LBB0_3
 ..
-	movl	12(%esp), %eax
-	movl	4(%esp), %ecx
-	addl	%eax, %ecx
-	movl	%ecx, 4(%esp)
-	movl	(%esp), %eax
-	addl	$1, %eax
-	movl	%eax, (%esp)
-	jmp	.LBB0_1
-	.LBB0_3:
-	movl	4(%esp), %eax
-	addl	$16, %esp
-	ret
+	En assembleur, cette fonction se traduit en :
+
+	.. code-block:: nasm
+		f:
+		subl	$16, %esp
+		movl	24(%esp), %eax
+		movl	20(%esp), %ecx
+		movl	%ecx, 12(%esp)
+		movl	%eax, 8(%esp)
+		movl	$0, 4(%esp)
+		movl	$0, (%esp)
+		.LBB0_1:
+		movl	(%esp), %eax
+		cmpl	8(%esp), %eax
+		jge	.LBB0_3
+
+		movl	12(%esp), %eax
+		movl	4(%esp), %ecx
+		addl	%eax, %ecx
+		movl	%ecx, 4(%esp)
+		movl	(%esp), %eax
+		addl	$1, %eax
+		movl	%eax, (%esp)
+		jmp	.LBB0_1
+		.LBB0_3:
+		movl	4(%esp), %eax
+		addl	$16, %esp
+		ret
 
 
 Pour qu'un processeur puisse exécuter cette séquence d'instructions, il faut qu'il puisse accéder :
diff --git a/index.rst b/index.rst
index 99ad989a973d9f4a165186f6f45d017c09ee2046..5777bff2ac3c2ce099d7abd1fa31a2e34a0bb155 100644
--- a/index.rst
+++ b/index.rst
@@ -63,24 +63,25 @@ Fichiers
 ..   Theorie/Fichiers/fichiers-signaux
 
 
-******
-Outils
-******
-
-.. toctree::
-   :maxdepth: 2
-
-   Outils/intro-outils
-   Outils/git
-   Outils/make
-   Outils/ssh
-   Outils/cunit
-   Outils/processus
-   Outils/valgrind
-   Outils/gdb
-   Outils/gprof
-   Outils/shell
-   Outils/gcc
+..
+	******
+	Outils
+	******
+
+	.. toctree::
+	   :maxdepth: 2
+
+	   Outils/intro-outils
+	   Outils/git
+	   Outils/make
+	   Outils/ssh
+	   Outils/cunit
+	   Outils/processus
+	   Outils/valgrind
+	   Outils/gdb
+	   Outils/gprof
+	   Outils/shell
+	   Outils/gcc
 
 *******
 Annexes