Plateforme tout-en-un ou SAEIV : décoder le nouveau vocabulaire du transport public

En 2020, un cahier des charges de transport public parlait de SAEIV. En 2026, le même document parle de plateforme d'exploitation, de suite intégrée, parfois de hub de données mobilité. Les fonctions attendues ont peu bougé : localiser les véhicules, informer les voyageurs, piloter le service. Ce qui a changé, c'est le vocabulaire. Et quand deux éditeurs n'emploient pas les mêmes mots pour désigner la même chose, comparer leurs offres devient un exercice piégeux.

SAEIV : ce que le sigle couvre réellement

Système d'Aide à l'Exploitation et à l'Information Voyageurs. Le sigle réunit deux métiers distincts. Le SAE couvre l'aide à l'exploitation : localisation temps réel, suivi de l'avance et du retard, régulation, communication avec les conducteurs, restitution des kilomètres réalisés. L'IV couvre l'information voyageurs : prochains passages, écrans en station, application mobile, alertes en cas de perturbation, diffusion open data.

Le sigle ne dit rien du périmètre réel. Une offre peut être présentée comme un SAEIV en ne couvrant que le SAE, l'information voyageurs étant sous-traitée. La première question n'est donc pas de savoir s'il s'agit d'un SAEIV, mais quelles briques sont couvertes en propre et lesquelles reposent sur un partenaire.

Suite, plateforme, tout-en-un : trois mots, trois réalités

Ces termes sont employés comme des synonymes commerciaux. Techniquement, ils décrivent des architectures différentes.

Suite logicielle

Plusieurs logiciels distincts vendus ensemble par le même éditeur. Chacun a sa base de données, parfois son interface, souvent son propre identifiant de connexion. La cohérence commerciale est réelle, la cohérence technique reste à vérifier. La question à poser : si je modifie un service dans le module planification, l'information voyageurs se met-elle à jour automatiquement, ou faut-il un export ?

Plateforme

Un socle technique unique sur lequel les fonctions se greffent. Une base de données, un référentiel de lignes et d'arrêts, une gestion des droits. Les modules partagent la même donnée en temps réel. C'est ce qui permet qu'une déviation tracée par un régulateur remonte immédiatement dans l'application voyageurs sans ressaisie.

Tout-en-un

Terme commercial, sans définition technique. Il signifie que vous n'aurez pas besoin d'un autre fournisseur. C'est une promesse de périmètre, pas une promesse d'architecture : un tout-en-un peut parfaitement être une suite de logiciels mal reliés entre eux.

Les cinq notions techniques à maîtriser

• SaaS : le logiciel est hébergé et exploité par l'éditeur, contre un abonnement. Pas de serveur à héberger, mises à jour incluses, budget qui bascule de l'investissement vers le fonctionnement.
• API : interface permettant à deux logiciels d'échanger des données automatiquement. C'est le critère qui détermine si vous pourrez brancher billettique, comptage ou paie sans développement spécifique.
• GTFS : format standard de description de l'offre théorique, lignes, arrêts et horaires. Le langage commun de l'écosystème.
• GTFS-RT et SIRI : les deux standards temps réel. Le premier domine chez les calculateurs d'itinéraires grand public, le second est attendu par les plateformes régionales et nationales. Un système sérieux produit les deux.
• Multi-tenant : une même instance sert plusieurs clients avec cloisonnement des données. C'est ce qui rend les mises à jour continues possibles.

Trois formulations qui méritent une question de plus

Solution modulaire peut signifier deux choses opposées : des modules activables sur un socle commun, ce qui est un avantage, ou des produits séparés qu'il faudra faire dialoguer, ce qui est un coût. La question qui tranche : les modules partagent-ils le même référentiel de lignes et d'arrêts ?

Intégré ne précise pas le sens de l'intégration. Elle peut être native, la donnée circulant sans intervention. Elle peut passer par API, donc après un développement. Elle peut se faire par export et import manuels. Les trois s'appellent intégration et ne coûtent pas la même chose à exploiter.

Compatible signifie que l'échange est techniquement possible, pas qu'il tourne chez un client. Demandez une référence en exploitation, pas une capacité théorique.

La grille de traduction rapide

• Plateforme : une base de données, ou plusieurs ?
• Tout-en-un : quelles briques développées en interne, lesquelles revendues ?
• Modulaire : référentiel commun ou produits séparés ?
• Intégré : nativement, par API, ou par fichier ?
• Compatible : chez quel client, depuis quand ?
• Temps réel : quelle fréquence de rafraîchissement, quelle latence bout en bout ?
• Ouvert : quelle documentation d'API publique, accessible où ?

Ce que ça change pour votre cahier des charges

Arrêtez de spécifier des catégories, spécifiez des comportements. Écrire que la solution devra être une plateforme tout-en-un n'engage personne : le terme n'a pas de définition opposable. Écrire qu'une modification d'itinéraire saisie par un régulateur devra être répercutée dans le flux GTFS-RT en moins de 60 secondes sans intervention manuelle engage le fournisseur sur un résultat vérifiable en recette.

Même logique pour les interfaces : ne demandez pas une solution ouverte, demandez la liste des API disponibles, leur documentation publique et le nom d'un client qui les utilise en production.

Le vocabulaire continuera d'évoluer, c'est le propre d'un marché qui se structure. Les critères de décision, eux, restent stables : une donnée saisie une seule fois, disponible partout, et vérifiable.