diff --git a/basegit.tex b/basegit.tex
index 0d1d2cd7ae2c8d8b011a07598df44fb52ae993a0..be084e0423a49b61549b0501bf456514a8c7dcaa 100644
--- a/basegit.tex
+++ b/basegit.tex
@@ -4,13 +4,13 @@
 
 %======================================================================
 
-\frame{\frametitle{Possibilités}
+\frame{\frametitle{Ressources manipulées : possibilités}
   \begin{itemize}
   \item
     Les VCS travaillent principalement sur les fichiers texte\\
     (\ex{.txt}, \ex{.c}, \ex{.java}, \ex{.xml}...)
   \item
-    Les fichiers binaires (\ex{.jpg}, \ex{.doc}, \ex{.pdf}...) peuvent
+    Les fichiers binaires (\ex{.jpg}, \ex{.docx}, \ex{.pdf}...) peuvent
     également être intégrés mais ne peuvent prétendre qu'au
     versionage, pas à l'édition collaborative
   \item
@@ -30,7 +30,7 @@
 
 %======================================================================
 
-\frame{\frametitle{Usages}
+\frame{\frametitle{Méthodologie / usages}
   \begin{itemize}
   \item
     Utiliser un VCS suppose que les développeurs travaillent en
@@ -90,11 +90,11 @@
     \item
       contient la copie locale des sources du projet
     \item
-      contient, à sa racine, le répertoire \ex{.git} (configuration du
-      projet)
+      contient, à sa racine, le répertoire \ex{.git}\\
+      (configuration et gestion technique du projet)
     \end{itemize}
   \item
-    \emph{Index}
+    \emph{Index} (appelé également \emph{stage})
     \begin{itemize}
     \item
       espace temporaire utilisé pour préparer la transition de données
@@ -146,15 +146,16 @@
 \frame{\frametitle{Principe de fonctionnement intrinsèque}
   \begin{itemize}
   \item
-    Contrairement à d'autres VCS, Git s'intéresse aux
+    Contrairement à d'autres VCS, \ex{git} s'intéresse aux
     \textbf{contenus}, pas aux fichiers en tant que tels
   \item
     Les noms de fichiers, les dates de modification, n'interviennent
-    donc pas directement pour déterminer les modifications réalisées
-    depuis un \emph{commit} donné
+    donc pas directement pour déterminer les modifications de contenu
+    réalisées depuis un \emph{commit} donné
   \item
-    Git calcule pour chaque fichier une \emph{signature} SHA-1 lui
-    permettant de détecter des changements de contenu
+    \ex{git} calcule pour chaque fichier une \emph{signature}
+    \textbf{SHA-1} lui permettant de détecter efficacement des
+    changements de contenu
   \item
     Les noms de fichiers, les dates associées, ne sont considérées que
     comme des méta-informations
@@ -197,8 +198,8 @@
     Un \emph{même} contenu fournit toujours la \emph{même} signature
   \item
     D'un point de vue mathématique, il est possible que deux
-    contenus différents génèrent une même signature (une
-    \emph{collision})
+    contenus différents génèrent une même signature\\
+    (on est alors en présence d'une \emph{collision})
   \item
     Mais en pratique, la probabilité est infinitésimale et peut être
     ignorée sans risque
@@ -249,7 +250,7 @@
 \frame{\frametitle{Usage des signatures SHA-1}
   \begin{itemize}
   \item
-    Sous Git, les signatures SHA-1 permettent d'identifier les
+    Sous \ex{git}, les signatures SHA-1 permettent d'identifier les
     contenus
     \begin{itemize}
     \item
@@ -257,15 +258,15 @@
     \item
       de versions d'un projet (à travers ses fichiers)
     \item
-      de \emph{commits} (en y associant des infos relatives à leur
-      auteur)
+      de \emph{commits} (en considérant leur contenu et leurs
+      métadonnées)
     \end{itemize}
   \item
-    À chaque fois, la signature obtenue est supposée unique et
-    constitue un identifiant fiable
+    À chaque fois, la signature obtenue est supposée unique :\\
+    elle est considérée comme un identifiant fiable
   \item
-    Cette gestion de signatures est à l'origine des performances
-    de Git
+    Cette gestion de signatures est à l'origine des performances\\
+    de \ex{git}
   \item 
     Elle lui permet aussi de garantir l'intégrité d'un projet dans un
     contexte distribué