Logiciel de gestion pour 5 camions : quelles fonctions sont vraiment nécessaires

En bref

Avec cinq camions, une petite entreprise peut encore sembler « gérable de mémoire ». En réalité, cinq véhicules, cinq conducteurs, une vingtaine de commandes, deux clients qui changent d’horaire et une absence suffisent à créer des dizaines de combinaisons opérationnelles en une seule journée.

Le bon logiciel de gestion ne doit pas transformer l’entreprise en multinationale. Il doit garantir six choses :

1. chaque commande n’existe qu’une seule fois ;
2. chacun voit quelle est la version à jour ;
3. le camion et le conducteur sont liés à l’activité ;
4. une modification ne reste pas confinée dans un chat ;
5. l’activité peut être clôturée et retrouvée ;
6. l’entreprise peut récupérer ses propres données.

Si ces six conditions fonctionnent bien, pour une flotte de cinq camions, c’est déjà un grand pas par rapport à Excel + téléphone + WhatsApp.

Pourquoi 5 camions suffisent déjà pour perdre le contrôle

Imaginons une journée simple :

• 5 camions ;
• 5 conducteurs ;
• 3 activités en moyenne par véhicule ;
• 15 activités au total ;
• 2 adresses modifiées ;
• 1 client en retard ;
• 1 conducteur qui termine plus tard que prévu ;
• 1 commande urgente ajoutée à 11:00.

Le problème n’est plus de « se souvenir de 15 livraisons ». Il consiste à maintenir la cohérence de toutes les relations :

commande ↔ client ↔ adresse ↔ horaire ↔ camion ↔ conducteur ↔ statut ↔ document

Si chacune vit dans un endroit différent, l’entreprise dépend de la mémoire du dispatcheur.

Le système opérationnel minimum de la flotte

Pour une flotte d’environ cinq camions, il est utile de considérer le logiciel comme un tableau opérationnel partagé, et non comme un ERP.

Les domaines minimums sont :

• clients et sites ;
• commandes ;
• conducteurs ;
• véhicules ;
• plan de la journée ;
• statut de l’activité ;
• éventuelles pièces jointes ;
• recherche dans l’historique.

Tout le reste vient après.

1. Données de référence réutilisables

Saisir de nouveau les mêmes données chaque jour est une source d’erreurs.

Le système devrait permettre d’enregistrer au moins :

Client

• raison sociale ;
• contacts opérationnels ;
• éventuels codes internes ;
• notes permanentes réellement nécessaires.

Site d’enlèvement/livraison

• adresse complète ;
• contact opérationnel si nécessaire ;
• créneaux/horaires récurrents ;
• notes d’accès utiles ;
• éventuelles références du client.

Conducteur

• nom ;
• contact opérationnel ;
• disponibilité ;
• informations nécessaires à l’affectation.

Véhicule

• immatriculation ou identifiant ;
• type ;
• caractéristiques nécessaires à la planification ;
• disponibilité.

Il ne faut toutefois pas transformer les données de référence en dépôt indiscriminé de données personnelles. Recueillez ce dont le processus a besoin et gérez séparément les données/documents qui exigent des protections ou des finalités différentes.

2. Commandes structurées

Chaque transport devrait avoir une fiche identifiable.

Champs pratiques :

• client ;
• référence de la commande ;
• date ;
• enlèvement ;
• livraison ;
• créneaux horaires ;
• marchandises/quantité parmi les informations nécessaires ;
• instructions opérationnelles ;
• éventuelle contrepartie si le système la gère ;
• statut ;
• notes et pièces jointes pertinentes.

La fiche doit distinguer les informations permanentes des notes temporaires. Si « décharger par le portail 3 » s’applique toujours à ce site, cela peut relever des données de référence. Si cela ne vaut qu’aujourd’hui, cela appartient à la commande.

3. Plan quotidien

Avec cinq camions, le plan doit pouvoir se lire en quelques secondes.

Une vue utile répond immédiatement à ces questions :

• qu’est-ce qui reste à affecter ?
• que fera chaque camion ?
• qui conduit ?
• quelle est la séquence ?
• quelles activités ont des horaires critiques ?
• lesquelles ont changé ?
• lesquelles sont terminées ?

Le plan ne doit pas chercher à remplacer les obligations relatives aux temps de conduite, au repos, au temps de travail ou à d’autres contraintes réglementaires. Il doit aider l’opérateur à organiser le travail et rendre visibles les contraintes que l’entreprise choisit de gérer dans le processus.

4. Conducteurs et véhicules liés

Écrire « Mario / 123AB » dans une note est différent d’affecter réellement une entité conducteur et une entité véhicule.

Le lien structuré permet de :

• voir toutes les activités d’un conducteur ;
• voir toutes les activités d’un camion ;
• éviter les doubles affectations évidentes ;
• changer une ressource sans réécrire la commande ;
• produire un historique cohérent ;
• créer des statistiques utiles.

Pour les vérifications réglementaires, l’entreprise doit en revanche continuer à utiliser les données et systèmes prévus par la réglementation applicable, y compris le tachygraphe lorsqu’il est requis.

5. Communication des modifications

La véritable valeur apparaît lorsque quelque chose change.

Si le client déplace la livraison de 14:00 à 16:00, le processus idéal est le suivant :

1. le bureau modifie la commande ;
2. le plan reflète la nouvelle information ;
3. le conducteur reçoit/voit la mise à jour dans le canal opérationnel prévu ;
4. la modification reste reconstructible si le système conserve l’historique/l’audit ;
5. il n’existe pas deux versions concurrentes.

WhatsApp peut continuer à servir aux conversations et aux urgences, mais ne devrait pas être la seule archive de la décision opérationnelle.

6. Statut et clôture de l’activité

Une PME devrait définir peu de statuts, mais des statuts clairs.

Exemple :

à planifier → planifié → affecté → en cours → terminé

N’ajoutez des statuts que s’ils ont de véritables conséquences opérationnelles, comme « problème » ou « annulé ».

Trop de statuts créent de la confusion. Trop peu empêchent de comprendre ce qui manque.

La règle est la suivante : chaque statut doit répondre à la question « que doit-il se passer ensuite ? ».

7. Documents et pièces jointes

Lier un document à la commande peut éviter des dossiers et des recherches sans fin. Mais il faut distinguer :

• une pièce jointe opérationnelle dans le logiciel de gestion ;
• un document pertinent sur le plan fiscal/juridique ;
• une éventuelle obligation de conservation numérique selon la réglementation applicable.

Le fait qu’un PDF soit téléversé dans le cloud ne signifie pas automatiquement que les éventuelles exigences de conservation prévues pour ce document sont satisfaites. Pour les documents soumis à des obligations spécifiques, il faut vérifier le bon processus avec des conseillers et des sources officielles.

Ce qui n’est pas nécessairement utile au départ

Pour cinq camions, il n’est pas obligatoire de commencer avec :

• un moteur d’optimisation avancé ;
• des appels d’offres transporteurs ;
• un entrepôt de données ;
• de la business intelligence complexe ;
• de la télématique propriétaire ;
• une comptabilité complète ;
• des dizaines d’intégrations ;
• des automatisations fondées sur l’IA ;
• des workflows d’approbation d’entreprise.

Si l’une de ces fonctions résout un problème réel, elle peut avoir du sens. L’essentiel est de ne pas l’acheter parce qu’elle « fait professionnel ».

Une journée type numérisée

07:00 — ouverture

Le dispatcheur ouvre le plan et voit :

• 12 activités déjà planifiées ;
• 2 à affecter ;
• 1 camion indisponible ;
• les notes opérationnelles de la journée.

08:15 — nouvelle commande

Un e-mail arrive. L’opérateur crée une commande en utilisant le client et le site déjà enregistrés.

09:00 — changement de conducteur

Un conducteur ne peut pas poursuivre. L’activité est réaffectée. Tout le monde voit la nouvelle combinaison.

11:30 — changement d’horaire

Le client déplace la livraison. La commande est mise à jour et le conducteur reçoit la nouvelle information.

16:30 — clôture

Les activités terminées passent au bon statut. Les éventuels documents sont liés au trajet selon le processus de l’entreprise.

Fin de journée

Le plan du lendemain part de données déjà structurées, et non d’une reconstitution des chats.

Quelles données mesurer avec cinq camions

Cinquante KPI ne sont pas nécessaires. Ceux-ci peuvent suffire :

• commandes par jour/semaine ;
• activités terminées vs ouvertes ;
• commandes par client ;
• nombre de modifications/exceptions ;
• commandes saisies manuellement vs importées ;
• documents manquants, s’ils sont gérés ;
• nombre d’activités par véhicule/conducteur comme donnée opérationnelle, et non comme substitut aux vérifications de conduite/travail.

Si un indicateur ne conduit pas à une décision, il peut être supprimé.

Checklist : le logiciel de gestion est-il adapté à 5 camions ?

• Puis-je créer rapidement une commande ?
• Le client et le site sont-ils réutilisables ?
• Est-ce que je vois immédiatement les commandes non planifiées ?
• Puis-je affecter le camion et le conducteur sans dupliquer les données ?
• Une modification apparaît-elle à la personne qui doit l’exécuter ?
• Puis-je rechercher d’anciennes commandes ?
• Puis-je exporter les données ?
• Les différents utilisateurs ont-ils des comptes distincts ?
• Le système conserve-t-il un historique utile des modifications ?
• Les documents peuvent-ils être liés sans confondre archivage et conservation réglementaire ?
• Puis-je travailler sans acheter de modules inutiles ?
• Le personnel peut-il l’utiliser après une formation raisonnable ?