Dans la plupart des entreprises de transport, le dispatch repose encore sur l’expérience d’une ou deux personnes, un tableur et un téléphone. Cela tient jusqu’au premier vrai pic, une panne, ou le jour où le dispatcheur qui « gardait tout dans sa tête » s’en va. Pour un directeur des opérations, le coût est mesurable : chaque trajet à vide, créneau manqué et conducteur inoccupé ponctionne la marge, et la planification manuelle ne le détecte tout simplement jamais.
D’après notre expérience, ce domaine appelle rarement une révolution produit. Bien plus souvent, il lui faut un bon logiciel et des ingénieurs qui comprennent la logistique. Nous n’exploitons pas de bureau de dispatch à nous, mais nous avons construit des systèmes de qualité opérationnelle sur des projets industriels et backend ; nous savons donc concevoir un système de dispatch et une couche d’optimisation des tournées, et pourvoir un projet qui arrive réellement en production.
Pourquoi le dispatch manuel fait-il autant mal ?
L’affectation manuelle ne s’échelonne pas de façon linéaire. À dix missions par jour, un dispatcheur gère tout à l’instinct ; à cent, l’instinct s’épuise, et le nombre de combinaisons véhicule-mission-créneau croît exponentiellement. Ce que l’entreprise paie, ce ne sont pas les erreurs mais le manque de visibilité : personne ne peut dire si le plan au tableau est 5 % ou 25 % moins bon que l’optimum.
S’y ajoute la fragilité qui l’accompagne. Quand les règles d’affectation ne vivent que dans les habitudes d’une personne, l’entreprise les perd le jour où cette personne s’en va. Le logiciel écrit ces règles, les versionne et les partage dans l’équipe, ce qui rend les décisions reproductibles et auditables.
Qu’est-ce qu’un tableau de dispatch et comment accélère-t-il l’affectation ?
Le cœur de tout système de dispatch est le tableau, une vue opérationnelle unique où le dispatcheur embrasse une journée entière d’activité de la flotte. Nous le concevons pour réunir au même endroit les missions, les véhicules, les conducteurs et leurs heures de travail. Il porte généralement :
- un vivier de missions filtré par statut, région et priorité,
- une chronologie des véhicules et des conducteurs montrant disponibilités et heures,
- une affectation par glisser-déposer avec validation immédiate des conflits,
- des statuts en temps réel : planifié, en route, livré, en retard.
Une telle interface ne remplace pas le dispatcheur ; elle lui retire le travail mécanique. Le système veille à ce que deux missions n’atterrissent jamais sur le même créneau et qu’une tournée ne dépasse jamais la charge utile, pendant que la personne décide là où le contexte compte vraiment.
Comment fonctionnent la planification et l’optimisation des tournées ?
Sous le tableau se trouve un moteur qui formule la planification des tournées comme un problème d’optimisation. Dans la littérature, c’est la famille VRP (Vehicle Routing Problem), avec des variantes qui tiennent compte de la charge utile, des fenêtres horaires et de plusieurs conducteurs. En pratique, nous ne cherchons pas une réponse parfaite, infaisable en calcul à l’échelle réelle, mais une réponse assez bonne dans un temps acceptable.
Le moteur doit respecter des contraintes dures qu’il ne peut jamais enfreindre, et des contraintes souples qu’il cherche à minimiser :
- la charge utile et la capacité par véhicule (poids, places palettes, volume),
- les fenêtres horaires de livraison et d’enlèvement côté client,
- le temps de travail des conducteurs et les pauses obligatoires (conformité réglementaire),
- la compatibilité mission-véhicule (frigorifique, ADR, hayon, dimensions).
Comme fonction objectif, nous prenons typiquement la minimisation du coût total : distance, temps et trajets à vide. Nous recourons à des solveurs d’optimisation (des moteurs comme OR-Tools) et à des algorithmes heuristiques, en ajustant l’approche à la taille de la flotte plutôt que l’inverse.
Comment le système gère-t-il les fenêtres horaires et les créneaux ?
Les fenêtres horaires sont l’endroit où la théorie rencontre la réalité quotidienne. Le client veut une livraison entre 8 et 10 heures, l’entrepôt n’a un quai libre qu’à certaines heures, et le conducteur doit y arriver avant la fin de son service. Un système bien conçu traite un créneau comme une ressource que l’on peut réserver, libérer et replanifier dès que la réalité s’écarte du plan.
Nous construisons ici un mécanisme qui vérifie en continu si le planning reste réalisable et signale les livraisons à risque avant qu’elles ne deviennent des retards. Quand le trafic frappe ou qu’une mission express arrive, le moteur recalcule la tournée de façon incrémentale au lieu de tout reconstruire de zéro, ce qui permet au dispatcheur de réagir en minutes plutôt qu’en heures.
Comment automatiser l’affectation aux sous-traitants ?
Les entreprises plus grandes transportent rarement tout avec leur propre flotte, et le système doit donc aussi comprendre les sous-traitants et transporteurs externes. À ce moment-là, la logique d’affectation cesse de ne concerner que les tournées et commence à peser le coût d’achat de la prestation, la disponibilité et la fiabilité du partenaire.
Dans ce type de modules, nous concevons généralement une bourse de missions ou un mécanisme d’appel d’offres, où le système propose une mission à un groupe défini de transporteurs, recueille les réponses et suggère un choix selon les règles du client. Nous automatisons aussi les règlements et les documents (ordre de transport, preuve de livraison), pour que travailler avec un sous-traitant ne fasse pas naître un second workflow dans l’e-mail et Excel.
Comment intégrer un système de dispatch à la télématique et à un TMS ?
Un système de dispatch ne vit pas en vase clos. Sa valeur ne croît qu’une fois relié au reste du paysage informatique de l’entreprise. Le plus souvent, nous le branchons sur :
- la télématique et le GPS des véhicules (position, consommation de carburant, style de conduite),
- les systèmes TMS et ERP (commandes, contreparties, facturation),
- une application mobile conducteur (missions, navigation, statut, e-POD),
- des API externes de cartographie et de trafic pour des temps de parcours réalistes.
Nous concevons ces intégrations via une couche d’API et d’événements, pour qu’une position issue de la télématique mette à jour le statut sur le tableau, et qu’une preuve de livraison depuis le téléphone du conducteur clôture la mission dans le TMS. Les données circulent alors dans un seul sens au lieu d’être retapées entre systèmes.
Où l’IA aide-t-elle vraiment dans l’optimisation des tournées ?
L’IA est souvent survendue, nous la traitons donc comme un complément à un moteur de règles solide plutôt que comme son remplacement. Elle gagne sa place là où comptent la prédiction et l’apprentissage à partir de l’historique : prévoir le temps de parcours réel à partir des trajets passés, estimer la durée de déchargement à un point donné, ou prédire le volume de missions des prochains jours pour planifier la flotte à l’avance.
Notre compétence en modèles et en données est réelle au sein du groupe RITS, nous pouvons donc concevoir et brancher une telle couche une fois que les données du client sont prêtes. Plus souvent, toutefois, nous conseillons de remettre d’abord le dispatch et les données en ordre et de n’ajouter la prédiction qu’ensuite, car un modèle nourri de chaos n’améliorera pas les décisions.
Quelles compétences apportons-nous à un projet de ce type ?
Nous ne revendiquerons pas ici un déploiement de dispatch achevé ; ce que nous fournissons, ce sont les personnes qui construisent de tels systèmes. Nous façonnons l’équipe autour du cahier des charges, et une équipe type comprend :
- un architecte / développeur backend (Java, .NET ou Node) pour le moteur et les API,
- un spécialiste de l’optimisation à l’aise avec le VRP et les solveurs (OR-Tools, modèles opérationnels),
- un développeur frontend pour le tableau de dispatch et les vues opérationnelles,
- un ingénieur intégration / DevOps pour la télématique, le TMS et les déploiements.
Cette configuration nous permet d’intervenir aussi bien sur une construction neuve que sur l’évolution d’un outil existant, quand il manque au client une compétence précise dans sa propre équipe.
Comment procédons-nous chez RITS ?
Nous travaillons comme partenaire nearshore depuis la Pologne, dans un fuseau horaire proche, ce qui compte pour un projet opérationnel, car les changements logistiques doivent se discuter le jour même. Nous vérifions les compétences avant le démarrage et branchons l’équipe sur le rythme de travail du client, ses revues de code et ses réunions sans longue montée en charge. Notre recrutement se boucle généralement en trois semaines environ, et ne s’étire que pour des exigences non standard.
Nous livrons cela le plus souvent de deux façons : en logiciel sur mesure construit par notre équipe, ou en renfort d’équipe quand le client a ses propres ingénieurs et doit ajouter des rôles manquants, comme un spécialiste de l’optimisation des tournées.
Par où commencer avec l’optimisation des tournées et du dispatch ?
Partez du problème le plus coûteux : trajets à vide, livraisons en retard ou dépendance à un seul dispatcheur. Cela vous dira s’il vous faut d’abord un tableau et une affectation plus propre, ou directement un moteur d’optimisation. En parallèle, vérifiez la qualité de vos données, car sans positions, horaires et paramètres de véhicules fiables, aucun algorithme ne calculera une tournée sensée. Nous avons traité les différences entre modèles de collaboration dans notre article sur les modèles de collaboration IT.
Vous préparez un système de dispatch ou une optimisation des tournées ? Parlons-en - nous ajusterons une équipe et une architecture à votre flotte et à vos processus.
Construisez votre dispatch et votre optimisation des tournées avec nous