diff --git a/docs/jdb.md b/docs/jdb.md
index 6f33f9b..1877d27 100644
--- a/docs/jdb.md
+++ b/docs/jdb.md
@@ -1417,4 +1417,22 @@ Je soupconne la création d'engines d'être à l'origine de ces performances pre
 
 Autre soucis, il semble que plus je change d'image plus la detection est lente et plus je consomme de RAM.
 
-Il va falloir que je travaille encore un peu.
\ No newline at end of file
+Il va falloir que je travaille encore un peu.
+
+J'ai tenté de mettre un stopwatch sur une des créations d'engine Tesseract et le résultat me parait fou... Plus d'une seconde c'est dingue.
+
+J'ai testé dans d'autres endroits du code et effectivement il semble que la création d'un engine prenne entre une et deux secondes ce qui est une ETERNITEE what !
+
+Donc il faut optimiser tout ca.
+
+Une idée serait de décomposer le threading mais cela me demanderait un gros refactor et je n'ai pas envie d'en refaire un la...
+
+Sinon, une fois qu'ils sont créés ils ne prennent pas de temps du tout. Créer une fois tous les engines et ensuite les utiliser pourrait être une bonne idée. Cela prendrait longtemps au load mais ensuite les reconnaissances devraient être super rapides.
+
+Ok alors ca c'est déja plus ce à quoi je m'attendais !
+On est de nouveau à plus de 10s de loading time mais on est descendu à deux secondes par OCR. (Bon autre soucis, l'utilisation de la RAM est ridicule plus de 2gb mais ce qui m'inquiète c'est que j'ai l'impression qu'elle augmente plus on change d'image)
+
+J'ai règlé (en partie) le soucis en obligeant le GC (Garbage Collector) à collecter après chaque detection. même après 50 detections l'utilisation de la ram se stabilize autour des 2GB.
+
+Bon en paralellisant la création des Engines le soucis c'est que cela demande d'allouer beaucoup trop de mémoire d'un coup alors le programme se fige pendant genre cinq secondes avant de tout créer. Du coup même si la création est plus rapide, on se retrouve avec un temps total plus long... Je pense que l'on va devoir se contenter de ces dix secondes.
+