diff --git a/.gitignore b/.gitignore
index d571b2e..d25e174 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,6 +12,7 @@ build/
 *.toc
 *.xdv
 *.tns
+_minted*
 
 # Temp files
 *.sw?
diff --git a/livrables/raffinages.txt b/doc/raffinages.txt
similarity index 100%
rename from livrables/raffinages.txt
rename to doc/raffinages.txt
diff --git a/livrables/rapport.pdf b/doc/rapport.pdf
similarity index 98%
rename from livrables/rapport.pdf
rename to doc/rapport.pdf
index 42a4bec..4d31ae0 100644
Binary files a/livrables/rapport.pdf and b/doc/rapport.pdf differ
diff --git a/doc/rapport.tex b/doc/rapport.tex
index 3004daf..063a753 100644
--- a/doc/rapport.tex
+++ b/doc/rapport.tex
@@ -7,7 +7,7 @@
 \usepackage{amssymb}
 \usepackage{color}
 \usepackage[french]{babel}
-\usepackage{hyperref}
+\usepackage[hidelinks]{hyperref}
 
 \usepackage{minted}
 %\usemintedstyle{borland}
@@ -33,7 +33,7 @@
 \title{\vspace{4cm} \textbf{Rapport de projet de programmation impérative} \\ Implémentation d'un algorithme de pageRank \vspace{1cm}}
 \author{Maxime Dubaux \\ Laurent Fainsin}
 \date{\vspace{7cm} Département Sciences du Numérique - Première année \\
-2020 - 2021 }
+    2020 - 2021 }
 
 \maketitle
 
@@ -78,17 +78,17 @@ Ada est un langage fortement typé. Comme nous manipulons ici plusieurs types de
 
 Lorsque nous trierons les données, nous ferons appel à l’algorithme QuickSort.
 
-Nous avons séparé le module Vector en trois sous-modules : Un module capable de stocker des entiers, un autre pour des flottants et un dernier pour des liens. Nous avons fait ce choix car créer un unique module générique Vector pour gérer ces trois types de données (très différents) était trop compliqué. Cela était tout de même faisable mais le code était compliqué à lire. Ainsi bien que le code soit quelque fois redondant, il est plus compréhensible. 
+Nous avons séparé le module Vector en trois sous-modules : Un module capable de stocker des entiers, un autre pour des flottants et un dernier pour des liens. Nous avons fait ce choix car créer un unique module générique Vector pour gérer ces trois types de données (très différents) était trop compliqué. Cela était tout de même faisable mais le code était compliqué à lire. Ainsi bien que le code soit quelque fois redondant, il est plus compréhensible.
 
 \subsection{Gestion des matrice de Google (google\_*.ads)}
 
-Nous devrons regrouper dans des modules génériques le code en rapport avec la gestion des matrices de Google. Nous utiliserons deux modules, un gérant les matrices naïves et un autre pour gérer les matrices creuses. 
+Nous devrons regrouper dans des modules génériques le code en rapport avec la gestion des matrices de Google. Nous utiliserons deux modules, un gérant les matrices naïves et un autre pour gérer les matrices creuses.
 
 Ces modules introduiront le type T\_Google, ainsi que des procédures et fonctions permettant de générer la matrice G, nécessaire au calcul du pageRank. Ils implémenteront aussi l’opération de multiplication entre un vecteur et une matrice.
 
 \subsection{Gestion du calcul du Pagerank (pagerank.adb)}
 
-Cette dernière partie s’occupe de regrouper tous les éléments présents dans les deux modules cités précédemment pour ainsi calculer itérativement le pageRank du réseau. Cette sous-partie gère de plus le traitement des arguments de la ligne de commande ainsi que la lecture et l’écriture des résultats dans des fichiers. 
+Cette dernière partie s’occupe de regrouper tous les éléments présents dans les deux modules cités précédemment pour ainsi calculer itérativement le pageRank du réseau. Cette sous-partie gère de plus le traitement des arguments de la ligne de commande ainsi que la lecture et l’écriture des résultats dans des fichiers.
 
 \section{Structures de données}
 
@@ -134,27 +134,27 @@ Voici l'ensemble des tests réalisés avec la commande time et valgrind sur l'or
 
 La commande suivante a été éxécutée pour élargir la taille maximale du stack:
 \begin{bashcode}
-$ ulimit -s unlimited
+    $ ulimit -s unlimited
 \end{bashcode}
 
 Valgrind génère une sortie similaire à celle-ci pour l'ensemble des programmes:
 \begin{bashcode}
-HEAP SUMMARY:
+    HEAP SUMMARY:
     in use at exit: 0 bytes in 0 blocks
     total heap usage: 22 allocs, 22 frees, 27,308 bytes allocated
 
-All heap blocks were freed -- no leaks are possible
+    All heap blocks were freed -- no leaks are possible
 
-ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
-ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
+    ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
+    ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
 \end{bashcode}
 
 Comme le heap n’est pas utilisé par le programme (mis à part pour quelques variables dont nous n’avons pas le contrôle direct), sachant le PID du programme, nous pouvons naïvement inspecter le fichier suivant pour connaître la taille qu’occupe le programme dans le stack :
 
 \begin{bashcode}
-$ build/pagerank fichiers_test/Exemple_sujet/exemple_sujet.net -n & \
- { while [[ -f /proc/$!/smaps ]]; do grep -A 1 stack /proc/$!/smaps >> stack.txt; done } ; \
- tail stack.txt
+    $ build/pagerank fichiers_test/Exemple_sujet/exemple_sujet.net -n & \
+        { while [[ -f /proc/$!/smaps ]]; do grep -A 1 stack /proc/$!/smaps >> stack.txt; done } ; \
+    tail stack.txt
 \end{bashcode}
 
 \newpage
@@ -164,28 +164,28 @@ $ build/pagerank fichiers_test/Exemple_sujet/exemple_sujet.net -n & \
 \subsubsection{exemple\_sujet.net}
 Stack size: 132 kB
 \begin{bashcode}
-$ time build/pagerank fichiers_test/Exemple_sujet/exemple_sujet.net -n
-real	0m0,009s
-user	0m0,000s
-sys	 0m0,006s
+    $ time build/pagerank fichiers_test/Exemple_sujet/exemple_sujet.net -n
+    real	0m0,009s
+    user	0m0,000s
+    sys	 0m0,006s
 \end{bashcode}
 
 \subsubsection{worm.net}
 Stack size: 1252 kB
 \begin{bashcode}
-$ time build/pagerank fichiers_test/Worm/worm.net -n
-real	0m0,073s
-user	0m0,061s
-sys	 0m0,009s
+    $ time build/pagerank fichiers_test/Worm/worm.net -n
+    real	0m0,073s
+    user	0m0,061s
+    sys	 0m0,009s
 \end{bashcode}
 
 \subsubsection{brainlinks.net}
 Stack size : 1570492 kB
 \begin{bashcode}
-$ time build/pagerank fichiers_test/Brainlinks/brainlinks.net -n
-real	2m41,387s
-user	2m41,074s
-sys	 0m0,280s
+    $ time build/pagerank fichiers_test/Brainlinks/brainlinks.net -n
+    real	2m41,387s
+    user	2m41,074s
+    sys	 0m0,280s
 \end{bashcode}
 
 \subsubsection{Linux26.net}
@@ -197,19 +197,19 @@ On peut tout de même estimer son espace mémoire à au moins 650 Go.
 \subsubsection{exemple\_sujet.net}
 Stack size: 132 kB
 \begin{bashcode}
-$ time build/pagerank fichiers_test/Exemple_sujet/exemple_sujet.net
-real	0m0,168s
-user	0m0,001s
-sys	 0m0,009s
+    $ time build/pagerank fichiers_test/Exemple_sujet/exemple_sujet.net
+    real	0m0,168s
+    user	0m0,001s
+    sys	 0m0,009s
 \end{bashcode}
 
 \subsubsection{worm.net}
 Stack size: 132 kB
 \begin{bashcode}
-$ time build/pagerank fichiers_test/Worm/worm.net
-real	0m0,034s
-user	0m0,016s
-sys	 0m0,004s
+    $ time build/pagerank fichiers_test/Worm/worm.net
+    real	0m0,034s
+    user	0m0,016s
+    sys	 0m0,004s
 \end{bashcode}
 
 \newpage
@@ -217,19 +217,19 @@ sys	 0m0,004s
 \subsubsection{brainlinks.net}
 Stack size: 14748 kB
 \begin{bashcode}
-$ time build/pagerank fichiers_test/Brainlinks/brainlinks.net
-real	1m55,939s
-user	1m55,909s
-sys	 0m0,012s
+    $ time build/pagerank fichiers_test/Brainlinks/brainlinks.net
+    real	1m55,939s
+    user	1m55,909s
+    sys	 0m0,012s
 \end{bashcode}
 
 \subsubsection{Linux26.net}
 Stack size: 41152 kB
 \begin{bashcode}
-$ time build/pagerank fichiers_test/Linux26/Linux26.net
-real	437m38,234s
-user	437m34,783s
-sys	 0m0,440s
+    $ time build/pagerank fichiers_test/Linux26/Linux26.net
+    real	437m38,234s
+    user	437m34,783s
+    sys	 0m0,440s
 \end{bashcode}
 
 \section{Conclusion}
@@ -238,7 +238,7 @@ Nos programmes ne génèrent aucune erreur selon Valgrind et s'exécutent pour c
 
 Les fichiers .org et .p qu’ils génèrent sont aussi pratiquement identiques à ceux fournis par l’énoncé. Il y a parfois quelques différences dans les fichiers .ord car certaines pages ont la même valeur de poids et parce que nous n'avons probablement pas utilisé le même algorithme de tri. De même les seules différences dans les fichiers .p sont dans les décimales après la précision donnée.
 
-On remarque facilement la supériorité temporelle et spatiale de la version creuse contre la version naïve, surtout lorsque N et N\_links sont grands. 
+On remarque facilement la supériorité temporelle et spatiale de la version creuse contre la version naïve, surtout lorsque N et N\_links sont grands.
 
 \subsection{Améliorations encore possible}
 
@@ -250,18 +250,18 @@ Il serait aussi possible de rendre l’algorithme QuickSort générique mais nou
 
 Finalement une dernière amélioration possible est celle de supprimer network du scope lorsque nous n’en n’avons plus besoin. En effet , une fois le réseau créé à partir du fichier .net, nous le gardons jusqu’à la fin de l'exécution du programme. Cependant il est possible de s’en débarrasser après la création de G.
 
-\section{Apports personnels} 
+\section{Apports personnels}
 
 Ce projet nous a permis de consolider nos connaissances sur les structures de données, car nous avons longuement réfléchi lesquelles étaient les plus adaptées au problème. De même, nous avons eu l’occasion de revoir plusieurs algorithmes classiques, nous permettant de mieux les maîtriser. Nous sommes tout de même déçus de ne pas avoir eu plus de temps à consacrer à l’optimisation du programme.
 
 \newpage
 
 \begin{thebibliography}{9}
-    \bibitem{wiki_pageRank} 
+    \bibitem{wiki_pageRank}
     Wikipedia, PageRank \\
     \href{https://en.wikipedia.org/wiki/PageRank}{https://en.wikipedia.org/wiki/PageRank}
-    
-    \bibitem{wiki_CSR} 
+
+    \bibitem{wiki_CSR}
     Wikipedia, Sparse matrix \\
     \href{https://en.wikipedia.org/wiki/Sparse_matrix#Compressed_sparse_row_(CSR,_CRS_or_Yale_format)}{https://en.wikipedia.org/wiki/Sparse\_matrix\#Compressed\_sparse\_row\_(CSR,\_CRS\_or\_Yale\_format)}
 
diff --git a/livrables/sources.zip b/livrables/sources.zip
deleted file mode 100644
index 3664f84..0000000
Binary files a/livrables/sources.zip and /dev/null differ
diff --git a/livrables/sources_naive.zip b/livrables/sources_naive.zip
deleted file mode 100644
index 93514bb..0000000
Binary files a/livrables/sources_naive.zip and /dev/null differ