J'ai ensuite calculé pour chaque tronçon la dénivelée positive (D>0) ou négative (D<0) et la distance linéaire (Dist) en repérant les coordonnées des extrémités des tronçons par déplacement du curseur sur le profil altimétrique d'Openrunner de l'étape comme je l'ai indiqué plus haut. J'ai déterminé la pente positive ou négative de chaque tronçon en % en divisant la dénivelée par la distance et en multipliant par 100. Ainsi, par exemple, le tronçon "Le Monêtier les Bains - Le Puy Jaumar" a une dénivelée positive de 330 m, une longueur de 1900 m et une pente de + 17 % (soit 17 m de dénivelée positive pour 100 m de distance).

Ensuite j'ai essayé d'estimer le temps nécessaire pour parcourir chaque tronçon. Comme je connais la pente, le distance et la dénivelée entre deux points consécutifs, j'ai utilisé l'algorithme suivant :
1. Si la pente est inférieure à un seuil déterminé SP (par exemple 10 %), je considère que je vais parcourir ce tronçon à une vitesse moyenne (sur la distance) VB fixée à l'avance (par exemple 3000 m/h). Si ça monte, j'irai peut être un peu moins vite, mais si ça descend, j'irai plus vite. Statistiquement, cela doit se compenser. Je divise donc la distance par la VB pour obtenir la durée du parcours. En fait, tout se passe comme si je marchais sur un parcours horizontal, mais à une vitesse plus faible que la normale (on porte quand même un sac de 12 kgs).
2. Si la pente est supérieure à SP et si la dénivelée est positive, je considère que je monte à une vitesse de montée (par rapport à la dénivelée) VM déterminée (par exemple 420 m/h). Si la pente est supérieure à SP et si la dénivelée est négative, je considère que je descend à une vitesse de descente (par rapport à la dénivelée) VD déterminée (par exemple 480 m/h). Je divise donc la dénivelée par VM ou VD. Cette fois-ci, c'est la dénivelée qui détermine le temps et non la distance.

Les paramètres SP, VB, VM et VD peuvent être modifiés dans les cases adhoc du tableur et toutes les durées sont alors recalculées automatiquement. Les durées en minutes apparaissent dans la colonne mn. Il suffit enfin de sommer les valeurs des tronçons pour obtenir les dénivelées positive et négative globales, la distance et le temps de parcours de chaque étape. Lors de la préparation, j'ai choisi les valeurs comme indiquées précédemment et pendant la randonnée, j'ai essayé de noter les durées réelles pour vérifier si mes données estimées avaient quand même quelque chose à voir avec les valeurs réelles.

Alors, quels sont les résultats ? Ils sont plutôt satisfaisants et sont représentés ci dessous. La ligne Ecart en mn représente la différence entre la Durée réelle et la Durée estimée avec la méthode détaillée précédemment. Si l'écart est positif (resp. négatif), cela signifie que la durée de l'étape a été plus longue (resp. moins longue) que prévu.

On peut trouver des explications aux écarts les plus importants. Une partie de l'étape E02 se déroulait hors sentier dans un terrain assez délicat lors de la descente du Pic du Lac Blanc. Lors de l'étape E03, il fallait emprunter une cheminée câblée avec pas mal de randonneurs (et même de jeunes enfants), ce qui nous a obligé à patienter un bon moment. Dans les étapes E05, E06 et E07, il y avait de longues portions peu pentues (du Pas d'Anna Falque à Villar d'Arène, Plateau d'Emparis, Contournement des Deux Alpes) où notre moyenne horaire était bien supérieure à 3 km/h. L'étape E08 était notre première grande étape de montagne avec uniquement de fortes pentes positives et négatives (Col du Vallon et Col de la Muzelle) et nous avons gagné beaucoup de temps dans les descentes. Cette situation ne s'est pas reproduite dans l'étape E10, car la descente du Col de la Vaurze vers le Refuge des Souffles comportait une longue traversée à flan de montagne qui paraissait plus ou moins horizontale sur la carte et qui s'est révélée plus importante en longueur et en dénivelée avec une succession de montées et de descentes.

5. Estimation des distances

Elle a été faite à partir des données relevées sur les cartes et les profils altimétriques d'Openrunner. Elle est donc directement liée à la précision des tracés sur les cartes. On comprend assez facilement que le tracé ne pose pas de problème sur les portions peu accidentées, mais il devient très difficile, voire même impossible, de reproduire toutes les sinuosités des sentiers de montagne dans les pentes les plus raides. D'ailleurs, les tracés sur les cartes IGN montrent de petits zigzags qui ne représentent pas vraiment la réalité. Pour illustrer mes propos, il suffit d'aller voir la photo "Vallouise01.jpg" prise lors de la dernière étape pour voir ce qu'est réellement un sentier de montagne dans une zone pentue. Il conviendrait donc de majorer les distances proposées par Openrunner de 10 à 20 % en fonction des pentes rencontrées aussi bien à la montée qu'à la descente. Comme il est illusoire de mesurer les distances réelles avec un podomètre, j'ai systématiquement majoré les distances proposées par Openrunner de 15 %.

6. Estimation des dénivelées

Lors de la préparation de l'itinéraire, j'ai remarqué que les dénivelées données par Openrunner sont assez éloignées de celles que j'ai relevé à la main sur les cartes. Parfois l'erreur dépasse 20 % (souvent en plus). Comme je relève très soigneusement les altitudes des points hauts et bas, je me suis dit qu'il y avait forcément un problème quelque part. Comment procède Openrunner ? Je pense qu'il calcule l'altitude de chaque point défini par l'utilisateur en fonction de sa position sur la carte. Comment se repère-t-il ? Mystère, mais il faut très souvent faire de gros zooms sur les courbes de niveau pour avoir une bonne estimation. L'altitude peut être repérée à 10 ou 20 mètres près dans les zones montagneuses là où les courbes de niveau sont visibles.

Pour analyser plus finement la cause de toutes ces erreurs, imaginons qu'Openrunner soit plus malin que moi (c'est pas dur...) et estime l'altitude avec une erreur de 5 mètres. Supposons maintenant un parcours qui se déroule rigoureusement à la même altitude, par exemple 875 m, constitué de 20 points consécutifs. Supposons qu'Openrunner définisse les altitudes comme suit : 870, 880, 870, 880... jusqu'au vingtième point. Lorsqu'il va calculer les dénivelées, il va trouver entre deux points consécutifs une montée ou une descente de 10 mètres, soit une dénivelée positive de 100 m et une dénivelée négative de 100 m alors qu'on est resté rigoureusement à la même altitude. Sachant qu'il faut un grand nombre de points pour définir un itinéraire, on voit tout de suite que ce mode de calcul peut conduire à des écarts importants !

L'erreur sera d'autant plus grande si le parcours est un peu vallonné. Par contre, lorsqu'on a des montées (ou des descentes) régulières avec une pente significative, les erreurs vont se rattraper naturellement. Dans le cas d'une montée, si un point est coté trop bas, comme le suivant sera coté nettement plus haut, il n'y aura pas d'erreur sur l'ensemble de la montée. Idem dans le cas d'une descente. Ce sont donc les zones à faible pente (voire sur le plat) qui posent problème, car la détermination des altitudes peut conduire à des erreurs qui vont se cumuler parfois de façon importante.

Finalement, j'ai décidé de faire confiance à mes relevés manuels et de vérifier tout cela sur le terrain lorsque je relèverai les cumuls de dénivelée indiqués par mon altimètre ! Après analyse des résultats donnés par mon altimètre, je constate que mes relevés sont tout à fait satisfaisants, excepté lorsqu'il y a des montagnes russes même de faible amplitude que je n'ai pas détecté sur les cartes, comme par exemple entre le Col de la Vaurze et le Refuge des Souffles, où j'ai relevé 2358 m de D>0 (au lieu de 2231 m) et 1682 m de D<0 (au lieu de 1550 m). Si on considère les autres étapes, les valeurs données par l'altimètre sont supérieures d'environ 3 à 4 % aux valeurs relevées sur les cartes. On peut donc considérer cela comme un bon résultat.

Voici le graphique du parcours global.