1
Open APIs, OpenSource & OpenData
Le choix de l'ouverture
Xavier Raffin – Architecte logiciel
@xavierraffin
2
Tisséo
Régie de transport de Toulouse
Métro Bus Tram
“3ème“ réseau TC de France
Indépendante sur l'IV
~10 développeurs
3
Historique OpenSource
Calculateurs IV temps réel et backoffice
● SYNTHESE depuis 2001
● en GPL depuis 2007 : 5 contribut...
4
Historique OpenData & Open API
Offre théorique
● depuis 2012 : GTFS et Neptune
API temps réel
● En OpenData depuis 2013
...
5
Conséquences
Des dizaines d'applications
Des niches trouvent une réponse
Améliore l'expérience utilisateur TC
Coût ouver...
6
Conséquences
Pression sur les outils maisons
● Abandonner ?
● Assumer ?
OpenSource pour suivre le rythme
Stratégie de lo...
7
Interoperabilité
GTFS-RT
SIRI
GTFS
NEPTUNE
NTFS
TISSEO API
NAVITIA
GOOGLE MAPS
Services
bas niveau
Services
haut niveau
...
8
Facteurs de choix
FAIRE FAIRE FAIRE
OPENSOURCE
FAIRE
Tout projet logiciel amène aux choix suivants :
Code custom
Intégra...
9
Difficultés
Gouvernance
Technique
Définir le périmètre fonctionnel
Définir les exigences techniques :
● Simple / Scalabl...
10
Difficultés
Sans compétence interne :
● vous déléguez l'appréciation de la situation à des tiers
● vous dépendez de tie...
11
Architecture : modulaire et extensible
Nécessité de flexibilité :
● étendre la norme
● Modifier / étendre le comporteme...
12
Architecture : microservices
APIENDPOINTAPIENDPOINT
Service
Custom 1
Service
Custom 2
Navitia
SYNTHESE
APIENDPOINT
Réfé...
13
Conclusion
● L'OpenSource n'est pas un Quick-Win
● Microservices
● API : Norme & Extensibilité
● Il faut contribuer dir...
14
Merci de votre attention
Xavier Raffin – Architecte logiciel
@xavierraffin
Prochain SlideShare
Chargement dans…5
×

Open APIs, OpenSource & OpenData dans le transport public

708 vues

Publié le

Pour suivre le rythme de l'innovation « digitale » dans le transport public, Tisséo a fait le choix de l'ouverture.
Ou comment l’OpenSource permet l'amélioration continue en s'appuyant sur une architecture adaptée (microservices, API, ...)
Egalement un retour d'expérience et les écueils à éviter dans la collaboration OpenSource.

0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
708
Sur SlideShare
0
Issues des intégrations
0
Intégrations
225
Actions
Partages
0
Téléchargements
5
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Open APIs, OpenSource & OpenData dans le transport public

  1. 1. 1 Open APIs, OpenSource & OpenData Le choix de l'ouverture Xavier Raffin – Architecte logiciel @xavierraffin
  2. 2. 2 Tisséo Régie de transport de Toulouse Métro Bus Tram “3ème“ réseau TC de France Indépendante sur l'IV ~10 développeurs
  3. 3. 3 Historique OpenSource Calculateurs IV temps 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. 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. 5 Conséquences Des dizaines d'applications Des niches 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. 6 Conséquences Pression sur les outils maisons ● Abandonner ? ● Assumer ? OpenSource pour suivre le rythme Stratégie de long terme Un staff de contributeurs internes expérimentés
  7. 7. 7 Interoperabilité GTFS-RT SIRI GTFS NEPTUNE NTFS TISSEO API NAVITIA GOOGLE MAPS Services bas niveau 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. 8 Facteurs de choix FAIRE FAIRE FAIRE OPENSOURCE FAIRE Tout projet logiciel amène aux choix suivants : Code custom Intégrateurs Editeurs Prestataire SSII
  9. 9. 9 Difficultés Gouvernance Technique Définir le périmètre fonctionnel Définir les exigences techniques : ● Simple / Scalable ● Controle d'intégrité / Montée en charge ● Embarqué ? Risques : Bureaucratie et Monstre de complexité
  10. 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. 11 Architecture : modulaire et 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. 12 Architecture : microservices APIENDPOINTAPIENDPOINT Service Custom 1 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. 13 Conclusion ● L'OpenSource n'est pas un Quick-Win ● Microservices ● API : Norme & Extensibilité ● Il faut contribuer directement
  14. 14. 14 Merci de votre attention Xavier Raffin – Architecte logiciel @xavierraffin

×