Télécharger pour lire hors ligne
Téléchargé parXavier Raffin
Open APIs, OpenSource & OpenData dans le transport public
Le document présente l'historique et les résultats d'une initiative open source pour le réseau de transport de Toulouse, Tisséo, mettant en avant l'importance des API et de l'ouverture des données depuis 2001. Il discute des défis liés à la gouvernance technique et au développement des compétences internes, ainsi que des modèles d'architecture modulaires et extensibles. En conclusion, il souligne que l'open source nécessite un investissement significatif et une contribution active pour être véritablement efficace.
Open APIs, OpenSource & OpenData dans le transport public
- 1. 1 Open APIs, OpenSource& OpenData Le choix de l'ouverture Xavier Raffin – Architecte logiciel @xavierraffin
- 2. 2 Tisséo Régie de transportde Toulouse Métro Bus Tram “3ème“ réseau TC de France Indépendante sur l'IV ~10 développeurs
- 3. 3 Historique OpenSource Calculateurs IVtemps réel et backoffice ● SYNTHESE depuis 2001 ● en GPL depuis 2007 : 5 contributeurs ● 2013 créé une fondation SYNTHESE OpenSource ● 2014 première intégration Navitia : 5 contributeurs ● 2015 quitte la fondation SYNTHESE ● 2015 TimeTable : 6 contributeurs +500 000 utilisateurs +10 millions d'appels par mois 9 millions de Fiches Horaires / an 550 documents différents
- 4. 4 Historique OpenData &Open API Offre théorique ● depuis 2012 : GTFS et Neptune API temps réel ● En OpenData depuis 2013 ● 2014 service de calcul d'itinéraire API non normalisée 2012 2013 2014 2015 2016 25 millions 20 millions 15 millions 10 millions 5 millions 18 millions de requêtes/mois +230 developpeurs
- 5. 5 Conséquences Des dizaines d'applications Desniches trouvent une réponse Améliore l'expérience utilisateur TC Coût ouverture marginal Licence Odbl & clef API ● Bon niveau de contrôle ● Peu d'incidents Pas de quota / Pas de monétisation
- 6. 6 Conséquences Pression sur lesoutils maisons ● Abandonner ? ● Assumer ? OpenSource pour suivre le rythme Stratégie de long terme Un staff de contributeurs internes expérimentés
- 7. 7 Interoperabilité GTFS-RT SIRI GTFS NEPTUNE NTFS TISSEO API NAVITIA GOOGLE MAPS Services basniveau Services haut niveau Donnée statique brute Fortement Standardisé Tempsréel Très peu Standardisé Valeur ajoutée “Sens“ de l'information api.sncf.com
- 8. 8 Facteurs de choix FAIREFAIRE FAIRE OPENSOURCE FAIRE Tout projet logiciel amène aux choix suivants : Code custom Intégrateurs Editeurs Prestataire SSII
- 9. 9 Difficultés Gouvernance Technique Définir le périmètrefonctionnel Définir les exigences techniques : ● Simple / Scalable ● Controle d'intégrité / Montée en charge ● Embarqué ? Risques : Bureaucratie et Monstre de complexité
- 10. 10 Difficultés Sans compétence interne: ● vous déléguez l'appréciation de la situation à des tiers ● vous dépendez de tiers sur votre Roadmap ● vos décisions sont ralenties ● on ne vous prêtera pas attention de la même manière Le coût d'ouverture d'un projet en opensource est important (doc, com, bugtracking, support, intégration continue,… ) Sans cet investissement cela ne décollera pas
- 11. 11 Architecture : modulaireet extensible Nécessité de flexibilité : ● étendre la norme ● Modifier / étendre le comportement ● Garder des parties fermées, spécifiques et propriétaires Réactivité, efficacité Garder un “facteur de différentiation“ Pas de BigBang : incrémental
- 12. 12 Architecture : microservices APIENDPOINTAPIENDPOINT Service Custom1 Service Custom 2 Navitia SYNTHESE APIENDPOINT Référentiel de Donnée consolidé Référentiels Temps réel L'intelligence de recoupement des informations est là L'intelligence de recoupement des informations est là C'est ça qui rend tout possible !
- 13. 13 Conclusion ● L'OpenSource n'estpas un Quick-Win ● Microservices ● API : Norme & Extensibilité ● Il faut contribuer directement
- 14. 14 Merci de votreattention Xavier Raffin – Architecte logiciel @xavierraffin