diff --git a/Inst_eddies/Analysis/plot_eddy_contours.py b/Inst_eddies/Analysis/plot_eddy_contours.py
index 472e3be05fa4f668b20204b72691fa1963a8dc98..e04fa4c2d4ba28d3179ca7dab10fec2d042eb7b2 100755
--- a/Inst_eddies/Analysis/plot_eddy_contours.py
+++ b/Inst_eddies/Analysis/plot_eddy_contours.py
@@ -136,7 +136,7 @@ if __name__ == "__main__":
 
     parser = argparse.ArgumentParser()
     parser.add_argument("-d", "--date", type = int, help = "date index")
-    parser.add_argument("-g", "--grid", help = "plot grid",
+    parser.add_argument("-g", "--grid", help = "plot grid points",
                         action = "store_true")
     parser.add_argument("-w", "--window", help = "choose a limited plot window",
                         type = float, nargs = 4,
diff --git a/Inst_eddies/Documentation_texfol/documentation.tex b/Inst_eddies/Documentation_texfol/documentation.tex
index 32e25edbdaf2d8a414bfdaa16de44b44b2133a8a..be22d676a9f44ba0f86499f2fc7e2474d5c130d2 100644
--- a/Inst_eddies/Documentation_texfol/documentation.tex
+++ b/Inst_eddies/Documentation_texfol/documentation.tex
@@ -654,9 +654,11 @@ Si un contour extérieur est bien défini (non vide) alors il a par
 construction une amplitude supérieure à \verb+min_amp+ et une surface
 suffisante.
 
-Si une forme dans \verb+max_speed_contour.shp+ est non vide alors
-la vitesse correspondante dans \verb+extremum.dbf+ est la vitesse
-sur cette forme.
+Si une forme dans \verb+max_speed_contour.shp+ est non vide alors la
+vitesse correspondante dans \verb+extremum.dbf+ est la vitesse sur
+cette forme. Si une forme dans \verb+max_speed_contour.shp+ est vide
+alors la vitesse correspondante dans \verb+extremum.dbf+ est la
+vitesse sur le contour extérieur.
 
 L'indice de date et l'indice de tourbillon dans
 \verb+outermost_contour.dbf+ et \verb+max_speed_contour.dbf+
@@ -677,11 +679,6 @@ coup sûr les polygones pour 16 ans dans un seul fichier shp, même en
 séparant cyclones et anticyclones. Faire un triplet de shapefiles par
 an.
 
-J'avais d'abord mis la valeur de vitesse dans le fichier
-\verb+max_speed_contour.dbf+ mais cette vitesse peut être associée au
-contour extérieur, avec un contour vide dans
-\verb+max_speed_contour.shp+.
-
 \section{Structures de données}
 \label{sec:structures}
 
@@ -701,14 +698,7 @@ de SSH. Mémoire utilisée par un scalaire de ce type :
   & = \mathrm{taille}(\mathtt{polyline}) + 2\ \mathrm{mots} \\
   & = 2 (\mathtt{n\_points} + 2) \mathrm{mots}  
 \end{align*}
-soit 8 (n\_points + 2) B. J'ai hésité à ajouter un champ speed,
-scalaire réel, pour une valeur de vitesse associée au contour. La
-vitesse utilisée peut être la composante azimutale par rapport à un
-centre défini indépendamment du contour. De ce point de vue, la
-définition de ce type dérivé serait un peu gênante. Par ailleurs, il
-ne serait pas très satisfaisant de laisser ce champ non défini pour le
-contour le plus extérieur, pour lequel nous n'avons pas besoin de
-calculer une vitesse.
+soit 8 (n\_points + 2) B.
 
 Nous avons besoin que la composante extr\_map de snapshot soit étendue
 en longitude dans le cas d'un domaine périodique pour son utilisation
@@ -1215,16 +1205,16 @@ Cf. algorithme \ref{alg:set_all_outerm}.
   \label{alg:set_all_outerm}
 \end{algorithm}
 
-Depuis la commission 37b4b5c6, il serait possible de chercher un
-contour de vitesse maximale pour chaque tourbillon immédiatement après
-avoir trouvé son contour extérieur, au lieu de faire une première
-itération sur les extremums pour trouver les contours et une seconde
-itération pour trouver le contour de vitesse maximale. (On reviendrait
-ainsi à l'organisation envisagée jusqu'à la commission 8fe2368c.)
-L'avantage serait une économie de mémoire vive : on ne stockerait pas
-tous les contours dans le snasphot. Inversement, il y a un avantage de
-souplesse à séparer les deux phases : laisser la voix à d'autres
-processus de recherche des contours.
+Depuis la commission fc7f1bd, on cherche un contour de vitesse
+maximale pour chaque tourbillon immédiatement après avoir trouvé son
+contour extérieur, au lieu de faire une première itération sur les
+extremums pour trouver les contours extérieurs et une seconde
+itération pour trouver le contour de vitesse maximale. (On est ainsi
+revenu à l'organisation envisagée jusqu'à la commission 8fe2368c.)
+L'avantage est une économie de mémoire vive : on ne stocke pas tous
+les contours dans le snasphot. L'inconvénient est qu'on a perdu de la
+souplesse pour laisser la voie à d'autres processus de recherche des
+contours.
 
 Notons ici :
 \begin{align*}
@@ -1709,7 +1699,11 @@ appeler \verb+polygon_contains_point+. Ou chercher les points connexes
 Déplacer la vitesse de \verb+extremum.dbf+ à
 \verb+outermost_contour.dbf+ ou \verb+max_speed_contour.dbf+ ? C'est
 possible mais ce n'est pas sûr qu'on y gagne en clarté et en facilité
-d'utilisation.
+d'utilisation. J'ai hésité à ajouter un champ speed, scalaire réel, au
+type dérivé ssh\_contour, pour une valeur de vitesse associée au
+contour. La vitesse utilisée peut être la composante azimutale par
+rapport à un centre défini indépendamment du contour. De ce point de
+vue, la définition de ce type dérivé serait un peu gênante.
 
 Modifier le critère de recouvrement : intersection des contous
 extérieurs supérieure à 50 \% et intersection des contours de vitesse