Telemachus standard mobilité (v0.2) marque une nouvelle étape dans la gouvernance ouverte de la donnée mobilité en France. Ce format pivot garantit transparence, interopérabilité et évolution communautaire.
Ce projet vise à harmoniser l’échange des données de mobilité à travers un système collaboratif de RFCs (Request for Comments). Ainsi, il garantit une évolution transparente et communautaire du standard.
🚀 Pourquoi un système de RFCs ?
Un standard vivant doit s’appuyer sur une gouvernance claire et un processus transparent.
De plus, le système de RFCs permet de :
- Documenter précisément chaque évolution du format ;
- Ouvrir la discussion à la communauté ;
- Assurer la traçabilité des décisions ;
- Structurer l’évolution du standard avec rigueur.
En effet, cette approche s’inspire des meilleures pratiques de l’IETF, d’OpenTelemetry ou encore de l’OGC.
📦 Les RFCs de la version 0.2
La version 0.2 introduit plusieurs RFCs fondamentaux :
| RFC | Titre | Statut | Lien |
|---|---|---|---|
| 0001 | Telemachus Core 0.2 | Accepté | Lien |
| 0003 | Dataset Specification 0.2 | Accepté | Lien |
| 0004 | Extended FieldGroups Schema | Accepté | Lien |
| 0005 | Adapter Architecture | Accepté | Lien |
| 0007 | Validation Framework & CLI Rules | Accepté | Lien |
| 0009 | RS3 Integration Pipeline | Accepté | Lien |
| 0011 | Versioning & Governance Policy | Accepté | Lien |
🗂️ Retrouvez l’ensemble des documents sur GitHub :
telemachus3/telemachus-spec
🔧 Un standard modulaire, compatible et validable
- RS3 génère les données brutes (IMU, GPS, vitesse…).
- Adapters traduisent les données industrielles (Webfleet, Samsara, Teltonika…).
- Schemas garantissent la cohérence entre jeux de données.
- Validator contrôle les alignements temporels, unités et complétude.
Par conséquent, cette approche transforme Telemachus en un véritable langage pivot entre simulation, télématique industrielle et recherche scientifique.
🧠 Un projet de standard, pas une simple bibliothèque
Avec le système de RFCs, Telemachus change d’échelle. Ce n’est plus seulement une librairie Python ou un dataset. En effet, c’est une spécification documentée et gouvernée.
Le processus se déroule ainsi :
1. Proposée — la RFC est en Draft.
2. Discutée — une issue publique est ouverte sur GitHub.
3. Implémentée — dans le code ou les schémas.
4. Publiée — dans une version officielle du standard.
Ce processus garantit la pérennité, la traçabilité et la crédibilité du format dans l’écosystème mobilité.
🗓 Et maintenant ?
- Renforcement de la validation sémantique (RFC-0007).
- Génération automatique des schémas JSON à partir des RFCs.
- Gouvernance ouverte (RFC-0011) et participation communautaire.
- Extension vers les données temps réel et les futures APIs constructeurs.
📘 Une nouvelle release Telemachus Spec v0.3 regroupera ces évolutions au premier semestre 2026.
💬 Rejoignez la discussion
💬 Discussions publiques sur GitHub :
RFC Discussions – telemachus3/telemachus-spec
🌍 Documentation officielle :
telemachus3.github.io/telemachus-spec
🔗 Articles internes :
RoadSimulator3.fr |
Référentiel virages OSM vs IGN
En s’appuyant sur un système de RFCs transparent et communautaire, Telemachus établit une gouvernance solide pour la donnée mobilité. Ce modèle collaboratif garantit la compatibilité, la traçabilité et la continuité du standard dans le temps.
👉 À lire aussi :
– Telemachus format pivot – un standard télématique ouvert
– RoadSimulator3 : simulateur inertiel 10 Hz
– OSM vs IGN : mesurer correctement un virage pour comprendre le risque conducteur
✍️ Auteur
Sébastien Edet — Créateur du simulateur RoadSimulator3 (RS3) et du standard Telemachus