Logiciel de transport : préparer une demande au support

À la régulation, au bureau ou sur le terrain, constater un problème dans le logiciel ne suffit pas toujours à l’expliquer. « L’écran ne marche pas » laisse plusieurs questions ouvertes : quelle action était en cours, qu’attendait-on et qu’a-t-on vu exactement ? Une demande précise donne au support un point de départ exploitable.

Voici une méthode pour préparer cette demande dans une entreprise de taxi conventionné, d’ambulance ou de VSL. Elle ne suppose aucune fonction particulière du logiciel. Son objectif : décrire les faits, limiter les essais inutiles et conserver le fil jusqu’à la vérification de la réponse.

1. Dire quelle tâche est empêchée

Commencez par l’action que la personne cherchait à accomplir : retrouver une mission, consulter un planning, enregistrer une modification ou ouvrir un document. Précisez ensuite ce qui reste possible. Un affichage inhabituel, une action bloquée et une information qu’on ne sait pas retrouver n’appellent pas forcément la même réponse.

Décrivez l’impact concret sur l’organisation, sans conclure vous-même à une panne générale. Par exemple : « Le bureau ne peut pas vérifier les missions de demain depuis ce poste ; la consultation fonctionne sur l’autre poste. » Si vous ne l’avez pas vérifié ailleurs, écrivez simplement que le périmètre est encore inconnu.

Indiquez aussi depuis quand le problème est observé et si la tâche fonctionnait auparavant. Une heure approximative, signalée comme telle, vaut mieux qu’une précision inventée. Pour une activité bloquée, utilisez le canal prévu par votre éditeur pour ce type de situation.

2. Relever le contexte sans joindre de données de patient

Notez le rôle de la personne, le type d’appareil, le navigateur ou l’application utilisée et le nom de l’écran. Ajoutez la version seulement si elle est facilement accessible. Inutile de passer la matinée à chercher une information technique avant de signaler un blocage.

Décrivez la succession des actions avec les libellés visibles. Recopiez un message d’erreur uniquement après avoir vérifié qu’il ne contient pas de donnée de patient ou d’identifiant confidentiel. N’envoyez ni mot de passe, ni document métier réel, ni capture contenant une liste de missions.

Si une illustration est utile, préférez un schéma ou une reconstitution avec des données entièrement fictives, clairement présentée comme telle. Une image n’est pas indispensable : une description précise de l’écran et de l’action peut suffire à lancer l’échange.

3. Séparer les étapes, le résultat attendu et le résultat observé

Rédigez trois petits blocs. Dans le premier, indiquez les étapes effectuées, dans leur ordre. Dans le deuxième, décrivez ce que vous pensiez obtenir et sur quoi repose cette attente : une consigne reçue, un usage habituel ou une démonstration. Dans le troisième, décrivez ce qui s’est réellement affiché.

Ne remplacez pas l’observation par une explication supposée. « La liste reste vide après la recherche » est un constat ; « les données ont été effacées » est une hypothèse tant que cela n’a pas été établi.

S’il existe un espace d’essai autorisé, vous pouvez y vérifier une séquence avec des données fictives. Sinon, signalez que le cas n’a pas été reproduit. Ne créez pas de fausses missions dans l’environnement de travail et ne répétez pas une action d’enregistrement ou d’envoi dont le résultat est incertain. Demandez au support comment poursuivre.

4. Envoyer une demande courte, puis garder un seul fil

Choisissez un objet qui associe l’action et le symptôme : « Consultation du planning : liste vide après changement de date ». Le message doit permettre de retrouver le contexte, les étapes, l’attendu, l’observé et l’impact sans devoir relire plusieurs échanges dispersés.

Désignez une personne qui rassemble les retours de l’équipe. Si un numéro de demande est attribué, conservez-le. Ajoutez les nouvelles observations dans le même échange, en distinguant les faits nouveaux des essais déjà effectués. Cela évite que chacun recommence séparément les mêmes vérifications.

Précisez si une solution temporaire est utilisée et ce qui reste à contrôler. Ne présentez pas cette solution comme une correction définitive. Une demande claire peut aussi déboucher sur une explication d’usage : gardez cette possibilité ouverte, sans accuser le logiciel ni mettre en cause la personne qui l’utilise.

5. Exemple fictif : un filtre qui paraît ne pas se réinitialiser

Ce cas est entièrement fictif. Il ne décrit ni un incident DriveSoft ni une interface ou une fonctionnalité garantie.

Dans un espace d’essai imaginaire, une personne consulte un planning de démonstration. Elle sélectionne un véhicule fictif, puis utilise une commande de remise à zéro. La liste reste limitée à ce véhicule. L’équipe prépare le message suivant.

Objet : planning de démonstration — filtre toujours visible après remise à zéro.

Contexte : poste du bureau, navigateur habituel, essai effectué ce matin. Aucun dossier réel utilisé.

Étapes : ouvrir le planning d’essai ; sélectionner le véhicule fictif A ; utiliser la commande de remise à zéro.

Attendu : retrouver la liste complète de démonstration, selon la consigne reçue. Observé : le véhicule A reste sélectionné et la liste reste filtrée.

Impact et vérifications : exercice de formation interrompu ; aucune mission réelle modifiée. Le comportement n’a pas été testé sur un autre poste. Demande : confirmer le fonctionnement prévu et indiquer la prochaine vérification.

6. Vérifier la réponse avant de clore le sujet

Quand une réponse arrive, reformulez l’action proposée avant de l’effectuer si elle n’est pas claire. Une fois la vérification possible, reprenez la tâche de départ et notez le résultat. Si le problème persiste, indiquez à quelle étape le comportement diffère encore.

Clore une demande, c’est pouvoir dire ce qui a été vérifié, dans quel contexte et par qui. Si la réponse apporte une nouvelle consigne d’utilisation, transmettez-la aux rôles concernés et ajoutez-la à vos exercices de prise en main : drivesoft.fr/blog/prise-en-main-logiciel-transport-autonomie-equipe

Vous comparez des logiciels pour votre entreprise ? Abordez aussi l’assistance lors du rendez-vous : canal de contact, informations à fournir et suivi d’une demande. Pour en discuter pendant une démonstration DriveSoft : drivesoft.fr/demo