Comment choisir un logiciel de gestion pour une petite entreprise de transport

En bref

Pour une petite entreprise de transport, le meilleur logiciel de gestion n’est pas celui qui a le plus de fonctions. C’est celui qui est utilisé tous les jours, réduit les manipulations manuelles et reste compréhensible lorsque le dirigeant n’est pas devant l’ordinateur.

Un mauvais choix peut échouer de deux façons :

1. un logiciel trop simple qui, après quelques mois, se retrouve de nouveau utilisé avec Excel et WhatsApp ;
2. un logiciel trop complexe qui demande tellement de configuration qu’il est rejeté par les opérateurs.

La sélection devrait donc être un petit projet opérationnel, et non une décision prise après une démonstration commerciale d’une heure.

Partir des problèmes, pas des fonctions

Avant de chercher des fournisseurs, décrire les cinq problèmes qui font perdre le plus de temps ou génèrent le plus de risque.

Exemples :

• les commandes arrivent par trois canaux ;
• le plan n’existe que sur le PC d’une seule personne ;
• une modification communiquée au conducteur n’est pas reportée dans le fichier ;
• la même adresse est ressaisie chaque jour ;
• le POD arrive plusieurs jours plus tard et n’est pas rattaché à la commande ;
• on ne sait pas quelles commandes sont encore ouvertes ;
• il est difficile de comprendre quelle quantité de travail a été réalisée pour chaque client.

Pour chaque problème, définir une mesure simple :

« Aujourd’hui, nous recopions chaque commande trois fois. Objectif : ne la saisir qu’une seule fois. »

Cette phrase vaut plus que « nous voulons nous numériser ».

Écrire 10 exigences avant de voir les démonstrations

Les exigences doivent être décrites comme des activités, pas comme des mots à la mode.

Exemple de liste

1. Créer une commande en moins de deux minutes.
2. Réutiliser les clients et sites déjà saisis.
3. Voir toutes les commandes non planifiées.
4. Affecter camion et conducteur depuis le même écran.
5. Déplacer une activité sans la recréer.
6. Permettre au conducteur de voir la version mise à jour.
7. Conserver l’identité de la personne qui a modifié la donnée, lorsque disponible.
8. Rechercher un historique par client/date/référence.
9. Exporter les commandes dans un format lisible.
10. Gérer des comptes séparés pour les personnes qui l’utilisent.

Ajouter ensuite les exigences propres à l’entreprise : plusieurs enlèvements, groupage, caisses mobiles, ensembles articulés, contraintes client, documents, import Excel, API, etc.

Essayer le logiciel avec des commandes réelles

Ne pas utiliser uniquement le jeu de données préparé par le vendeur. Prendre cinq cas réels, en supprimant les données personnelles ou confidentielles qui ne sont pas nécessaires à l’essai.

Tester :

Cas 1 — commande normale

Un enlèvement, une livraison, un conducteur, un camion.

Cas 2 — modification

Après l’affectation, le client modifie l’horaire ou l’adresse. Vérifier où apparaît la modification et si la version précédente reste reconstituable.

Cas 3 — exception

Conducteur indisponible : est-il simple de réaffecter ?

Cas 4 — plusieurs activités

Un trajet avec plusieurs enlèvements ou livraisons, si cela fait partie de l’exploitation réelle.

Cas 5 — clôture

Livraison terminée, statut mis à jour, éventuel document lié, commande retrouvable après un mois.

Chronométrer les étapes. Si la démonstration d’une fonction exige continuellement l’intervention du consultant, se demander si l’opérateur quotidien pourra l’utiliser.

Évaluer la facilité d’utilisation et l’adoption

Le logiciel ne se choisit pas seulement pour le dirigeant. Impliquer au moins une personne qui planifie et, s’il y a une composante conducteur, un ou deux conducteurs.

Observer :

• comprennent-ils où commencer sans explications continues ?
• les erreurs sont-elles récupérables ?
• les noms des champs correspondent-ils au langage utilisé dans l’entreprise ?
• l’écran de la journée montre-t-il ce qui est réellement nécessaire ?
• les informations essentielles sont-elles lisibles sur téléphone ?
• faut-il trop de clics pour une activité répétée des dizaines de fois ?

Une fonction techniquement puissante que personne n’utilise a une valeur opérationnelle nulle.

Vérifier la propriété, l’export et la portabilité des données

L’une des questions les plus importantes est souvent négligée :

Si je change de logiciel dans trois ans, comment emporter mes données ?

Demander par écrit :

• quelles données sont exportables ;
• dans quels formats ;
• si l’export est en libre-service ou exige une assistance ;
• s’il existe des coûts d’extraction ;
• s’il est possible d’exporter les pièces jointes/documents ;
• comment sont maintenus les liens entre la commande et les pièces jointes ;
• combien de temps les données restent disponibles après la résiliation ;
• comment la suppression finale est effectuée.

CSV/XLSX peut suffire pour de nombreuses données tabulaires ; pour des systèmes plus élaborés, il peut être important d’avoir des API ou des exports structurés.

Éviter une dépendance dans laquelle l’entreprise peut voir les données mais ne peut pas les récupérer de manière raisonnable.

RGPD : que demander au fournisseur

Un logiciel de gestion du transport peut contenir des noms, coordonnées, données de conducteurs, documents et informations opérationnelles se rapportant à des personnes physiques. Le rôle en matière de protection des données dépend du service et des traitements concrets, mais dans les services SaaS ordinaires, le fournisseur peut agir, pour différentes activités, comme sous-traitant pour le compte de l’entreprise cliente.

L’article 28 du RGPD régit la relation entre responsable du traitement et sous-traitant et exige que le traitement soit encadré par un contrat ou un autre acte juridique comportant les éléments prévus par le règlement.

Avant la signature, demander :

• un DPA/accord de traitement des données ;
• une liste des sous-traitants ultérieurs ou un mécanisme d’information à leur sujet ;
• où les données sont traitées/conservées ;
• les mesures de sécurité déclarées ;
• la gestion des violations de données à caractère personnel ;
• le support pour les demandes d’accès/suppression lorsque cela s’applique ;
• les règles de restitution/suppression en fin de contrat ;
• les durées de conservation et les sauvegardes ;
• les éventuels transferts internationaux et leurs bases juridiques.

Une page indiquant « conforme au RGPD » ne suffit pas : les informations doivent être cohérentes avec le service concret.

Sécurité, sauvegardes et continuité

Pour une petite entreprise, une journée sans plan de transport peut être plus grave que de nombreuses fonctions manquantes. Demander donc comment le fournisseur gère la fiabilité.

Comptes

• utilisateurs individuels ;
• politique de mots de passe ;
• MFA si disponible ;
• révocation des accès ;
• rôles et autorisations.

Sauvegardes

• existe-t-il des sauvegardes ?
• à quelle fréquence ?
• combien de temps sont-elles conservées ?
• les procédures de restauration sont-elles testées ?

Continuité

• existe-t-il une page d’état ou un canal pour les incidents ?
• quels niveaux de service sont prévus contractuellement, le cas échéant ?
• comment travaille-t-on si Internet ou le service ne sont pas disponibles ?

Journaux

Pour les opérations importantes, savoir qui a modifié une donnée peut réduire les discussions et le temps de reconstitution.

Une PME ne doit pas nécessairement exiger l’architecture d’une banque, mais elle doit comprendre si son plan opérationnel dépend d’un système sans mesures adéquates.

Lire le contrat et les coûts cachés

Vérifier au moins :

• durée minimale ;
• renouvellement automatique ;
• conditions de résiliation ;
• modalités de révision des prix ;
• nombre d’utilisateurs/véhicules inclus ;
• coûts des modules ;
• coûts API ;
• coûts d’onboarding ;
• assistance incluse ;
• SLA, s’ils sont pertinents ;
• responsabilité et limitations ;
• export des données ;
• période d’accès après résiliation ;
• conditions des personnalisations ;
• propriété d’éventuels développements spécifiques.

La question « combien cela coûte-t-il par mois ? » ne suffit pas.

Éviter les personnalisations prématurées

Pendant la démonstration, il est facile de dire : « nous faisons différemment, faites-nous cette modification ». Dix personnalisations plus tard, le projet devient coûteux et difficile à mettre à jour.

Avant de demander un développement spécifique, distinguer :

Exigence légale/contractuelle. Elle doit être gérée correctement.

Exigence opérationnelle essentielle. Sans elle, le processus ne fonctionne pas.

Habitude. « Nous avons toujours fait ainsi » n’est pas nécessairement une exigence.

Préférence. Elle peut être sacrifiée si le nouveau processus est plus simple.

Essayer d’abord le produit standard. Personnaliser uniquement ce qui crée un avantage réel ou évite un problème concret.

Plan de migration

Une petite entreprise ne devrait pas transférer automatiquement dix ans de fichiers désordonnés.

Un plan simple peut être :

Phase 1 — nettoyage

Éliminer les doublons et standardiser au moins les clients, sites, conducteurs et véhicules.

Phase 2 — import

Charger les données de référence et, si nécessaire, une période limitée de commandes historiques.

Phase 3 — essai parallèle bref

Utiliser le nouveau système avec un groupe limité ou pendant quelques jours, en évitant des mois de double travail.

Phase 4 — date de bascule

Établir : « à partir de lundi, toutes les nouvelles commandes naissent ici ».

Phase 5 — archive

Conserver l’ancien matériel selon les obligations applicables, mais ne plus l’utiliser comme plan courant.

Fiche de notation pour comparer 3 logiciels

Utiliser une note de 1-5 et attribuer un poids.

Les poids doivent être adaptés. L’intérêt du tableau est d’éviter qu’une démonstration spectaculaire sur une fonction secondaire domine le choix.

Checklist finale

• Avons-nous écrit les problèmes avant de voir les produits ?
• Existe-t-il 10 exigences vérifiables ?
• Avons-nous essayé des commandes réelles ?
• La personne qui planifie a-t-elle testé le logiciel ?
• Les conducteurs ont-ils testé la partie qui les concerne ?
• Avons-nous mesuré le nombre d’étapes ?
• Pouvons-nous exporter les données et les pièces jointes ?
• Avons-nous lu les informations DPA/confidentialité et les sous-traitants ultérieurs ?
• Les sauvegardes et la continuité sont-elles claires ?
• Avons-nous calculé le coût sur trois ans ?
• Le contrat explique-t-il la sortie et la résiliation ?
• Pouvons-nous commencer sans personnalisations lourdes ?
• Existe-t-il un plan de migration concret ?