diff --git a/report/report.org b/report/report.org
index f402a2e..7075cb6 100644
--- a/report/report.org
+++ b/report/report.org
@@ -102,7 +102,7 @@ nature aléatoire de l’algorithme. Cependant, on constate également une
 croissance importante du temps d’exécution suivant également ce nombre
 d’itérations réussies.
 
-Vous trouverez en Annexe 1.1 un exemple d’image générée à partir de
+Vous trouverez en Annexes (§[[*M%C3%A9thode 1]]) un exemple d’image générée à partir de
 ~img/mahakala-monochrome.png~ avec 2000 améliorations via cette méthode.
 
 ** Réduction du panel des couleurs
@@ -130,10 +130,19 @@ sur le nombre d’exécutions indiqué.
 |                500 |                 6.747 |         0.235 |              10 |
 |               1000 |                19.608 |         0.327 |               5 |
 
-On peut remarquer une très nette amélioration de la rapidité d’exécution du
-logiciel. Étant donné que cette modification ne sera à priori pas en conflit
-avec d’autres méthodes, cette amélioration sera conservée pour toutes les autres
-avancées suivantes.
+On peut remarquer une  amélioration dans la rapidité d’exécution du logiciel.
+Cependant, le résultat n’est pas aussi important qu’escompté. Je suppose que
+cela est dû au fait que l’algorithme précédent peut considérer un rapprochement
+d’une zone déjà colorée vers la couleur d’origine comme une amélioration, avec
+une possibilité plus large sur ce plan-là que pour le second algorithme qui se
+doit d’être plus précis concernant les couleurs. Une nette amélioration du
+résultat est toutefois visibles, voir Annexes (§[[*M%C3%A9thode 2]]) pour une image
+générée à partir de ~img/mahakala-monochrome.png~ via la méthode 2 et avec 2000
+améliorations.
+
+Étant donné que cette modification ne sera à priori pas en conflit avec d’autres
+méthodes, cette amélioration sera conservée pour toutes les autres avancées
+suivantes.
 
 ** Une taille des formes aléatoire mais contrôlée
 
@@ -142,7 +151,40 @@ une taille minimale et maximale selon le nombre d’éléments posés et le nomb
 total d’éléments à poser. Ainsi, on pourrait privilégier tout d’abord de grandes
 formes en début de génération pour encourager petit à petit les formes à réduire
 en taille. Cela permettrait d’obtenir rapidement une représentation grossière de
-l’image pour ensuite pouvoir progressivement afiner les détails.
+l’image pour ensuite pouvoir progressivement afiner les détails. La taille de la
+forme à appliquer est définie comme suit :
+
+#+begin_export latex
+$$coef=\frac{nbIterRestantes}{totalIter}$$
+$$tailleMinimale=coef \frac{min(Width,Height)}{2}$$
+$$tailleMaximale=tailleMinimale*2+1$$
+$$taille=Rand([\![tailleMinimale;tailleMaximale[\![)$$
+#+end_export
+
+Voici les moyennes de temps d’exécution selon le nombre d’itérations réussies
+sur le nombre d’exécutions indiqué.
+
+|                  / | <                     | <             |               < |
+| Nb d’améliorations | Temps d’exécution (s) | Variation (s) | Nb d’exécutions |
+|--------------------+-----------------------+---------------+-----------------|
+|                 10 |                       |               |             200 |
+|                 50 |                       |               |             100 |
+|                100 |                       |               |              50 |
+|                200 |                       |               |              20 |
+|                500 |                       |               |              10 |
+|               1000 |                       |               |               5 |
+
+Cette version du logiciel est nettement plus lente que ses versions précédentes
+du fait de la contrainte de taille pour les formes pouvant potentiellement
+améliorer l’image, cependant la qualité des images générées est plus haute que
+celle des version précédentes, voir en Annexes (§[[*M%C3%A9thode 3]]).
+
+Cette méthode ne me semble que moyennement concluante, certes la vitesse
+d’exécution du logiciel est beaucoup plus faible, mais il est également vrai que
+la qualité des images générées est supérieure aux deux autres méthodes. Ainsi,
+il sera possible d’utiliser les modifications apportées par cette méthode en
+utilisant une option ~-s [ --size ]~ avec les méthodes suivantes pour activer
+cette modification de l’algorithme.
 
 ** Concurrence entre threads
 
@@ -150,8 +192,12 @@ Une utilisation na
 
 * Annexes
 ** Images
+*** Méthode 1
 #+CAPTION: Image générée à partir de ~img/mahakala-monochrome.png~ avec 2000 améliorations avec la première méthode
 [[./output1.png]]
-
+*** Méthode 2
 #+CAPTION: Image générée à partir de ~img/mahakala-monochrome.png~ avec 2000 améliorations avec la seconde méthode
 [[./output2.png]]
+*** Méthode 3
+#+CAPTION: Image générée à partir de ~img/mahakala-monochrome.png~ avec 2000 améliorations avec la troisième méthode
+[[./output3.png]]
diff --git a/report/report.pdf b/report/report.pdf
index 252f466..e881a21 100644
Binary files a/report/report.pdf and b/report/report.pdf differ