Logiciel gestion de parc engins rail-route

Point de départ

Décrire les décisions à prendre avant de comparer les logiciels

La recherche commence souvent par « gérer les engins » ou « remplacer les tableurs ». Ces objectifs sont trop larges pour départager deux solutions. Il faut d'abord lister les décisions récurrentes : quel matériel affecter, quelle configuration préparer, quels documents retrouver, quelle réserve traiter et qui peut remettre un statut à jour.

Un atelier court avec le responsable de parc, un utilisateur terrain et l'atelier permet de reconstituer trois ou quatre parcours réels. On suit une demande depuis son origine jusqu'à sa clôture, en notant les ressaisies, les fichiers annexes et les moments où l'équipe attend une information. Ce travail fournit des critères vérifiables et évite d'acheter une application séduisante qui ne représente pas l'organisation.

Checklist de travail

• ✓ Choisir une mission fréquente et une mission comportant un écart ou une indisponibilité.
• ✓ Identifier l'engin, ses équipements et la configuration réellement engagée.
• ✓ Nommer la personne qui prépare, celle qui constate et celle qui décide.
• ✓ Lister les documents lus, produits ou mis à jour à chaque étape.
• ✓ Repérer les périodes sans réseau et les appareils utilisés sur le terrain.
• ✓ Définir le résultat attendu : rapport, action, historique ou changement de disponibilité.

Le processus réel est le cahier des charges

Une démonstration devient utile lorsqu'elle reprend les données, les exceptions et les rôles de l'entreprise. Une longue liste de fonctions ne prouve pas qu'un scénario complet sera exécutable.

Architecture métier

Vérifier que la fiche engin relie les bonnes informations

Dans un parc rail-route, un même numéro ne suffit pas toujours. La machine de base, ses organes ferroviaires, ses accessoires, ses configurations et les pièces associées doivent pouvoir être distingués sans multiplier des fiches contradictoires. Le modèle doit aussi conserver les changements : remplacer un document ou fermer une réserve ne doit pas effacer ce qui a conduit à la décision.

Trackary centralise une fiche par engin, des catégories configurables, la planification, des contrôles et l'historique des rapports. Le cadrage précise la granularité utile au client : trop peu de structure transforme l'application en stockage de PDF ; trop de champs rend la saisie lente et encourage les contournements.

Objet

Question de démonstration

Signal d'alerte

Identité et configuration

Peut-on distinguer la machine, ses équipements et leur état à une date donnée ?

Un champ libre doit expliquer chaque variante

Documents

Une pièce est-elle reliée au bon engin, à une portée et à une version ?

Les fichiers sont seulement rangés par dossier

Échéances et actions

Une alerte mène-t-elle au rapport puis au traitement d'une observation ?

La date devient verte sans justificatif ni décision

Missions et rapports

Le constat terrain rejoint-il l'historique sans ressaisie ?

Le PDF final reste séparé de la fiche matériel

Évaluation

Faire exécuter les scénarios par les futurs utilisateurs

Une preuve de concept ne doit pas être une seconde présentation commerciale. Le responsable prépare une intervention, le technicien ouvre sa journée, réalise une saisie avec un écart, puis le bureau retrouve le rapport et attribue la suite. Si le terrain peut être mal couvert, le scénario est répété en coupant volontairement le réseau.

Il faut observer le nombre d'étapes, la compréhension des statuts et les points où un utilisateur hésite. La qualité de l'accompagnement compte autant que l'interface : reprise des données, paramétrage des modèles, gestion des droits, formation et support doivent avoir un responsable et un livrable.

• Préparer un jeu de données représentatif Importer quelques engins, configurations, documents et échéances réalistes, sans utiliser de données sensibles non nécessaires.
• Exécuter un départ normal Planifier, consulter la fiche, compléter le contrôle prévu et produire un rapport sans assistance permanente.
• Introduire un écart Ajouter une observation, une photo utile et une action, puis vérifier qui est averti et qui peut la clôturer.
• Tester le hors ligne préparé Charger la mission, couper le réseau, saisir, relancer l'application puis contrôler la synchronisation au retour.
• Relire l'historique Demander à une personne qui n'a pas participé au test d'expliquer la chronologie et les décisions.

Hors ligne ne signifie pas fonctionnement illimité

Le périmètre disponible localement, le volume des pièces, la reprise après interruption et les conflits doivent être testés sur les appareils et scénarios du déploiement réel.

Décision et déploiement

Noter la couverture, puis sécuriser l'adoption

La grille de choix doit séparer trois niveaux : couvert nativement, couvert après paramétrage, ou nécessitant une adaptation. Cette distinction rend le coût et le délai lisibles. Elle évite aussi de considérer comme disponible une fonction seulement évoquée pendant une démonstration.

Après le choix, un périmètre pilote permet de nettoyer les données et d'ajuster les modèles avant généralisation. Les indicateurs utiles portent sur le travail accompli : rapports complets, actions attribuées, temps de recherche d'une pièce, saisies en attente de synchronisation et écarts encore sans décision. Le nombre de connexions, seul, ne dit pas si le parc est mieux géré.

• Attribuer un propriétaire à chaque référentiel importé et définir la source qui fait foi.
• Documenter les rôles : consulter, préparer, saisir, relire, décider et administrer.
• Limiter le premier déploiement à un flux complet et à un groupe capable de faire des retours précis.
• Fixer une règle de correction des données plutôt que de masquer les doublons pendant la migration.
• Revoir les modèles après les premières missions et conserver la raison des changements.

Ce que Trackary peut démontrer

Trackary centralise les fiches engins, le planning, des contrôles configurables et l'historique des rapports. Lorsqu'un parcours hors ligne est inclus et configuré, sa portée doit être confirmée pendant le cadrage et testée dans les conditions réelles du déploiement. Toute intégration ou adaptation spécifique doit également être confirmée.

Questions fréquentes

Sources et limites de ce guide

• SNCF Réseau — Vérifier la conformité de vos engins de travaux ↗ Contexte officiel sur la vérification de conformité des engins de travaux ; il illustre pourquoi un statut logiciel ne remplace pas une démarche menée par l'acteur compétent.
• INRS — Vérifications initiales ou périodiques ↗ Repères pour distinguer maintien en état, vérifications et responsabilités ; utiles pour séparer les objets suivis dans le logiciel.
• SNCF Réseau — RFN-IG-SE 09 B-00 n°001, version 7 ↗ Règle d'exploitation particulière SNCF Réseau, accessible sur le portail de l'EPSF, à consulter dans son périmètre ; elle rappelle que les catégories et conditions d'emploi ne peuvent pas être réduites à un champ générique.
• Un logiciel centralise les informations et matérialise un processus défini par l'organisation. Il ne remplace ni l'analyse réglementaire, ni le contrôle physique, ni la décision d'une personne compétente.
• Les fonctions, intégrations, délais de reprise et modalités d'accompagnement doivent être vérifiés dans une démonstration et une proposition correspondant au périmètre réel.