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.

1. 1
Open APIs, OpenSource & OpenData
Le choix de l'ouverture
Xavier Raffin – Architecte logiciel
@xavierraffin

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
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
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
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
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
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
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
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
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 : 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
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
Conclusion
● L'OpenSource n'est pas un Quick-Win
● Microservices
● API : Norme & Extensibilité
● Il faut contribuer directement

14. 14
Merci de votre attention
Xavier Raffin – Architecte logiciel
@xavierraffin