Tester un SAEIV avant de s'engager : 6 critères de pilote

En bref : tester un SAEIV avant de s'engager revient à vérifier, sur quelques lignes réelles, six points : la reprise du plan de transport, la fraîcheur de la position, la fiabilité de l'écart à l'horaire, l'adoption par les conducteurs, la validité des flux d'information voyageurs et l'exploitation des données après coup. Fixez la grille par écrit avant le démarrage, couvrez un cycle complet d'exploitation et décidez sur des critères, pas sur des impressions.

Que peut-on vraiment tester avant de signer un SAEIV ?

Trois niveaux existent, et ils ne répondent pas aux mêmes questions. La démonstration montre les écrans et le vocabulaire de l'outil : elle valide la compréhension, pas le comportement sur votre réseau. Un environnement de test avec vos données valide le paramétrage et la lecture du plan de transport. Un pilote sur quelques lignes avec de vrais véhicules et de vrais conducteurs valide l'ensemble de la chaîne, de la position GPS à l'information voyageurs.

Tous les fournisseurs ne proposent pas les trois niveaux, ni dans les mêmes conditions. La première question à poser est donc simple : qu'est-ce qui est possible avant la signature, avec quelles données, sur quel périmètre, et qui y consacre du temps de chaque côté ? Chez Pysae, le point d'entrée est la demande de démo, qui permet de cadrer avec l'équipe le test le plus adapté à votre réseau.

Pour une autorité organisatrice comme pour un exploitant, cette démarche complète un cahier des charges sans le remplacer. Les critères de choix détaillés sont dans notre guide des critères pour choisir un logiciel de transport public et dans l'article sur le choix d'une solution de supervision. Le test sert à vérifier, sur le terrain, ce que ces critères promettent sur le papier.

Quel périmètre donner à un pilote de SAEIV ?

Un bon pilote est petit mais représentatif. Retenez deux ou trois lignes qui ne se ressemblent pas : une ligne dense avec de la régulation, une ligne périphérique ou interurbaine avec de longs trajets, et si votre réseau en a une, une ligne scolaire ou à horaires particuliers. Associez-y un groupe de conducteurs volontaires et au moins une personne du poste de contrôle qui supervisera ces courses au quotidien.

La période doit couvrir un cycle complet d'exploitation : une semaine type, mais aussi un jour férié ou une période de vacances si votre offre change à ces dates. La durée exacte se fixe avec le fournisseur, en fonction de la taille du réseau. Ce qui compte est de ne pas juger l'outil sur la seule semaine où tout est calme.

Écrivez avant le démarrage ce que vous attendez, ligne par ligne. Sans critères posés à l'avance, la décision finale repose sur des impressions. Les six critères qui suivent servent de grille.

Critère 1 : le plan de transport est-il repris sans perte ?

Tout part du plan de transport : lignes, arrêts, courses, horaires, calendriers. La page « Comment ça marche » de Pysae indique que l'exploitant peut importer son plan de transport ou le saisir, et que les données restent modifiables à tout moment. Pendant le pilote, vérifiez trois choses : que toutes les courses de vos lignes pilotes apparaissent avec les bons horaires, que les calendriers (jours fériés, vacances) sont correctement interprétés, et que vous pouvez corriger un horaire vous-même sans passer par un ticket.

Ce test est aussi celui de la qualité de vos propres données. Un export GTFS imparfait se voit dès les premiers jours, et mieux vaut le découvrir pendant un pilote qu'après la mise en service. Si votre réseau dépend d'un logiciel de planification existant, la question de la liaison entre les deux se règle à ce stade : les standards à connaître sont détaillés dans l'article sur l'intégration du SAEIV à l'existant.

Critère 2 : la position affichée est-elle fraîche et exacte ?

C'est le test le plus simple et le plus parlant. Choisissez un véhicule, repérez-le physiquement à un arrêt connu, puis comparez avec l'écran du poste de contrôle. Recommencez à plusieurs moments de la journée et sur plusieurs lignes, y compris dans les zones où la réception est difficile (rues étroites, tunnels, zones boisées).

Pour la fraîcheur, la documentation du format GTFS Realtime (version 2.0, site gtfs.org) fait la distinction utile entre deux horodatages : celui de la position, défini comme le « moment at which the vehicle's position was measured », et celui du flux, qui identifie « the moment when the content of this feed has been created ». Un écart important entre les deux signale une latence quelque part dans la chaîne. Demandez à voir ces deux valeurs plutôt que de vous fier au seul affichage.

Côté Pysae, les pages Operations et « Comment ça marche » indiquent que les données de tout le parc sont actualisées toutes les 5 secondes. Pendant le pilote, vérifiez que ce rythme est bien constaté sur vos véhicules, avec vos terminaux et votre couverture réseau, plutôt que de le tenir pour acquis.

Critère 3 : l'avance et le retard sont-ils fiables pour le régulateur ?

La régulation repose sur l'écart à l'horaire. Selon la page « Comment ça marche », les données théoriques sont envoyées au GPS du conducteur, qui calcule l'avance ou le retard. Le test consiste à rapprocher, sur une série de courses, l'écart affiché au poste de contrôle de ce que le conducteur et un observateur constatent au passage de quelques arrêts.

Notez les cas qui posent problème : terminus avec battement, arrêts très rapprochés, courses qui s'enchaînent sur un même véhicule, itinéraires modifiés. Ce sont ces situations qui font la qualité d'un outil de régulation au quotidien, bien plus que les courses simples. Pour comprendre ce que le poste de contrôle doit pouvoir faire face à un écart, voir la régulation temps réel d'un réseau de bus.

Critère 4 : les conducteurs adoptent-ils l'application ?

Un SAEIV vaut ce que valent les données saisies et reçues à bord. Pendant le pilote, interrogez les conducteurs volontaires : la prise de service est-elle rapide, l'écran est-il lisible en conduite, la messagerie avec le régulateur est-elle claire, le guidage GPS correspond-il à l'itinéraire réel ? La page Formations de Pysae décrit d'ailleurs la formation « Application Conducteur - Driver » autour de la prise de service, du comptage des voyageurs, des échanges avec le régulateur et du guidage GPS : ce sont les mêmes points à observer pendant le test.

Recueillez les retours par écrit, avec les conducteurs eux-mêmes, et pas seulement via l'encadrement. Un outil refusé en cabine ne produit pas de données fiables, quelle que soit la qualité du poste de contrôle. Les attentes côté cabine sont détaillées dans l'article sur ce que l'aide à l'exploitation doit afficher en cabine.

Critère 5 : l'information voyageurs publiée est-elle valide ?

Si le réseau diffuse du temps réel, le pilote doit tester ce qui sort vers les voyageurs et vers les applications tierces. La page Pysae sur l'information voyageurs et le GTFS-RT liste trois types de flux : mises à jour des trajets (retards, annulations, modifications d'itinéraire), positions des véhicules, et alertes de service. Demandez à recevoir ces flux pendant le pilote et passez-les dans un validateur de flux GTFS Realtime, comme vous le feriez pour un flux de production.

Contrôlez aussi le résultat côté voyageur : le temps d'attente affiché à un arrêt correspond-il à l'arrivée réelle ? Une annulation ou un changement de trajet saisi au poste de contrôle apparaît-il bien dans l'application ? Les erreurs les plus courantes sur les flux sont décrites dans GTFS-RT en pratique : ce que les exploitants font mal avec les flux temps réel, et la différence entre les deux grands formats dans l'article sur SIRI et GTFS-RT.

Critère 6 : les données sont-elles exploitables après coup ?

Un pilote qui ne laisse aucune trace exploitable est un pilote perdu. La page « Comment ça marche » indique que Pysae permet de rejouer les courses, de consulter les historiques et les tracés réels, et d'exporter les données vers les autorités organisatrices. La page Operations mentionne des statistiques (taux de prise de course, ponctualité, kilométrage, fréquentation) avec un export Excel pour l'autorité organisatrice.

Utilisez le pilote pour produire un vrai livrable : refaites avec l'outil le rapport mensuel que vous remettez aujourd'hui à votre autorité organisatrice, ou celui que vous attendez de votre exploitant. Si vous n'obtenez pas le même résultat, ou pas dans un format utilisable, vous le saurez avant d'avoir signé.

Quelles questions poser sur l'accompagnement avant de démarrer ?

Un pilote réussi dépend autant de l'équipe en face que de l'outil. La page « Comment ça marche » de Pysae mentionne un Account Manager dédié pendant toute la durée du contrat et un onboarding personnalisé au déploiement. Demandez ce que cela donne concrètement pendant la phase de test : qui répond aux conducteurs, qui corrige un paramétrage, en combien de temps vous obtenez une réponse.

Demandez aussi comment les formations sont organisées. La page Formations indique des sessions en présentiel ou à distance, au choix lors de la demande. Prévoyez du temps pour vos propres équipes : un test mal accompagné donne une mauvaise image d'un bon outil, et l'inverse est tout aussi vrai.

Comment décider à la fin du pilote ?

Reprenez la grille écrite avant le démarrage et notez chaque critère avec trois niveaux : acquis, à corriger avec échéance, bloquant. Un critère bloquant sur la position, la régulation ou l'information voyageurs doit être levé avant signature. Un critère à corriger doit figurer dans le contrat avec une date et une personne responsable.

• Plan de transport : courses, horaires et calendriers repris, correction autonome possible.
• Position : fraîcheur constatée, écart avec le terrain mesuré.
• Régulation : avance et retard cohérents avec l'observation.
• Conducteurs : retours écrits, points de blocage identifiés.
• Voyageurs : flux validés, affichage cohérent avec la réalité.
• Données : rejeu des courses et export conforme à votre reporting.

Pour cadrer ce qui suit la décision, notamment le déploiement par étapes, voir déployer un module de supervision sur 30 lignes.

Questions fréquentes

Peut-on tester un SAEIV avant de l'acheter ?

Cela dépend du fournisseur et du périmètre. On distingue la démonstration, un environnement de test avec vos données et un pilote sur quelques lignes avec de vrais véhicules. Chez Pysae, le point d'entrée est la demande de démo, qui permet de cadrer le test adapté à votre réseau.

Combien de lignes faut-il retenir pour un pilote de SAEIV ?

Deux ou trois lignes représentatives suffisent : une ligne dense avec de la régulation, une ligne périphérique ou interurbaine, et si possible une ligne à horaires particuliers. Le but est de couvrir des situations différentes, pas de multiplier les lignes.

Comment vérifier la fiabilité d'une position GPS pendant un test ?

Comparez la position affichée au poste de contrôle avec la position réelle d'un véhicule à un arrêt connu, à différents moments et sur plusieurs lignes. Pour un flux GTFS Realtime, comparez aussi l'horodatage de la position et celui du flux pour repérer une latence.

Que faire des résultats du pilote dans le contrat ?

Chaque critère à corriger doit figurer dans le contrat avec une échéance et un responsable. Un critère bloquant sur la position, la régulation ou l'information voyageurs doit être levé avant la signature.

Vous préparez le choix d'un SAEIV et souhaitez cadrer un test sur vos lignes ? Cliquez sur le bouton « Demander une démo » : l'équipe Pysae échange avec vous sur votre réseau et sur le périmètre de test le plus adapté.