Une trace GPX de douze kilomètres, un dénivelé positif de six cent quarante mètres, trois points de vue repérés au format de coordonnées : voilà tout ce que possédait, au départ, l’office de tourisme d’une vallée de montagne pour rédiger une fiche de randonnée présentable sur son site WordPress. Transformer ces données brutes en texte lisible représentait, sentier après sentier, un travail de rédaction conséquent pour une équipe de trois permanents.
Le test mené au printemps 2023 a consisté à confier cette mise en forme à un modèle de langage, alimenté par les données du fichier GPX et quelques repères fournis par un guide de montagne local, avant validation systématique sur le terrain.
Le pipeline mis en place
Chaque randonnée existait déjà sous forme de trace GPX exportée d’un appareil GPS professionnel, associée à un fichier de notes de terrain rédigées par le guide : nature du sol, présence de points d’eau, difficulté d’orientation à certains croisements. Ces éléments étaient assemblés dans un prompt structuré, envoyé à l’API du modèle via une extension personnalisée développée pour l’office, qui produisait un texte de présentation destiné à un type de contenu personnalisé « Sentier ».
Le prompt imposait un format fixe : distance, dénivelé et durée en préambule chiffré, puis un texte descriptif de l’itinéraire, jamais d’appréciation subjective sur la difficulté sans confirmation du guide.
Ce que la relecture de terrain a corrigé
Sur les trente-quatre fiches produites durant la phase de test, le guide a systématiquement effectué une vérification sur le terrain avant publication, et non une simple relecture depuis son bureau. Cette étape a permis de repérer deux erreurs notables : une description de croisement de sentiers qui inversait la direction à suivre, déduite d’une lecture erronée des coordonnées GPX par le modèle, et une mention de « source d’eau potable » à un point où l’eau existait bien mais n’était en réalité pas certifiée potable par la commune.
Les ajustements apportés après ces erreurs
- Interdiction explicite, dans le prompt, de qualifier une source d’eau sans confirmation écrite du guide dans les notes de terrain.
- Ajout systématique d’un sens de lecture précis pour les coordonnées, avec vérification manuelle de chaque changement de direction mentionné dans le texte généré.
- Passage à une relecture en deux temps : une première sur écran pour la cohérence générale, une seconde sur le terrain pour la fiabilité pratique.
- Ajout d’une mention systématique de la date de dernière vérification physique du sentier, affichée en bas de chaque fiche publiée.
Un gain de temps réel malgré ces réserves
Malgré ces deux erreurs corrigées à temps, l’équipe estime que la rédaction complète des trente-quatre fiches aurait nécessité environ trois semaines de travail rédactionnel classique, contre une dizaine de jours avec ce dispositif, relecture de terrain comprise. Le gain provient surtout de la mise en forme homogène du texte, jamais de la suppression de la vérification humaine.
Une limite assumée du dispositif
Le guide reste catégorique sur un point : aucune information de sécurité, comme la présence d’un passage exposé ou la nécessité d’un équipement spécifique, n’est jamais publiée sans qu’il l’ait lui-même vérifiée sur place durant la saison en cours. Le modèle de langage aide à écrire, jamais à évaluer un risque de terrain.
La règle affichée en interne à l’office : une donnée GPS ne remplace jamais une paire de chaussures sur le sentier.
En résumé
Ce cas montre qu’un modèle de langage peut utilement transformer des données techniques disparates en un texte cohérent, à condition de traiter chaque affirmation générée comme une hypothèse à vérifier plutôt que comme un fait acquis. Pour un office de tourisme de montagne, cette vérification de terrain n’est pas une option supplémentaire : elle conditionne directement la sécurité des randonneurs qui suivront la fiche.
