diff --git a/report/fiche_synthese.tex b/report/fiche_synthese.tex
index cc094f7..7e94903 100644
--- a/report/fiche_synthese.tex
+++ b/report/fiche_synthese.tex
@@ -66,31 +66,32 @@ fine-tuned caching and optimized code to mitigate this problem.
 \subsection*{Your contribution}
 
 This internship explored the possibility to compile DWARF's stack unwinding
-data directly into native assembly on the x86\_64 architecture. Instead of
-parsing and interpreting at runtime the debug data, the stack unwinding data is
-accessed as a function of a dynamically-loaded shared library.
+data directly into native assembly on the x86\_64 architecture, in order to
+provide fast access to the data at assembly level. This compilation process was
+fully implemented and tested on complex, real-world examples. The integration
+of compiled DWARF into existing, real-world projects have been made easy by
+implementing an alternative version of the \textit{de facto} standard library
+for this purpose, \prog{libunwind}.
 
 Multiple approaches have been tried, in order to determine which compilation
 process leads to the best time/space trade-off.
 
-Quite unexpectedly, the part that proved hardest of the project was finding a
+Unexpectedly, the part that proved hardest of the project was finding a
 benchmarking protocol that was both relevant and reliable. Unwinding one single
-frame is way too fast to be benched on a few samples (around $10\,\mu s$ per
-frame), and having a lot of samples is quite complex, since one must avoid
-unwinding the same frame over and over again, which would only benchmark the
-caching mechanism. The other problem is to distribute evenly the unwinding
-measures across the various program positions, including directly into the
-loaded libraries (\eg{} the \prog{libc}).
+frame is way too fast to provide a reliable benchmarking on a few samples
+(around $10\,\mu s$ per frame). Having a lot of samples is not easy, since one
+must avoid unwinding the same frame over and over again, which would only
+benchmark the caching mechanism. The other problem is to distribute evenly the
+unwinding measures across the various program positions, including directly
+into the loaded libraries (\eg{} the \prog{libc}).
 
 The solution eventually chosen was to modify \prog{perf}, the standard
 profiling program for Linux, in order to gather statistics and benchmarks of
-its unwindings, and produce an alternative version of \prog{libunwind} using
-the compiled debugging data, in order to interface it with \prog{perf},
-allowing to benchmark \prog{perf} with both the standard stack unwinding data
-and the alternative experimental compiled format. As a free and enjoyable
-side-effect, the experimental unwinding data is perfectly interfaced with
-\prog{libunwind}, and thus interfaceable at practically no cost with any
-existing project using the \textit{de facto} standard library \prog{libunwind}.
+its unwindings. Modifying \prog{perf} was an additional challenge that turned
+out to be harder than expected, since the source code is pretty opaque to
+someone who doesn't know the project well. This, in particular, required to
+produce an alternative version of \prog{libunwind} interfaced with the compiled
+debugging data.
 
 % What is your solution to the question described in the last paragraph?
 %