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 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 / an550 documents différents

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

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

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

Interoperabilité

GTFS-RTSIRI

GTFSNEPTUNENTFS

TISSEO APINAVITIAGOOGLE MAPS

Servicesbas niveau

Serviceshaut niveau

Donnée statiquebrute

FortementStandardisé

Temp

s réel

Très peuStandardisé Valeur

ajoutée

“Sens“ de l'information

api.sncf.com

8

Facteurs de choix

FAIRE FAIRE FAIRE

OPENSOURCE

FAIRE

Tout projet logiciel amène aux choix suivants :

Code customIntégrateurs

Editeurs

Prestataire SSII

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

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

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

Architecture : microservices

AP

I EN

DP

OIN

TA

PI E

ND

PO

INT

ServiceCustom 1

ServiceCustom 2

Navitia

SYNTHESE

AP

I EN

DP

OIN

T Référentielde

Donnée consolidé

RéférentielsTemps 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

Conclusion

● L'OpenSource n'est pas un Quick-Win

● Microservices

● API : Norme & Extensibilité

● Il faut contribuer directement

14

Merci de votre attention

Xavier Raffin – Architecte logiciel@xavierraffin