Optimisation tournées livraison IA : algorithmes et prédiction

L'optimisation des tournées de livraison par IA recouvre en réalité deux disciplines distinctes : la recherche opérationnelle (solveurs VRP) et l'apprentissage automatique prédictif. Les confondre est la première erreur des projets qui partent dans le mur. Un solveur VRP calcule l'ordre de visite optimal à partir de vos adresses et contraintes. L'IA prédictive estime les durées réelles de livraison, les créneaux de disponibilité des clients, la demande à venir. Les deux se combinent, mais n'ont pas les mêmes prérequis, les mêmes coûts ni les mêmes conditions de réussite.

Ce guide explique comment choisir la bonne approche selon votre situation, quelles données vous devez préparer, quels outils concrets (OR-Tools, VROOM, SaaS spécialisés) correspondent à quelle réalité terrain, et ce qui fait échouer ces projets même quand l'algorithme tourne parfaitement.

VRP et IA prédictive : deux approches à ne pas confondre

Le problème de tournées de véhicules (VRP, Vehicle Routing Problem) est un problème classique de recherche opérationnelle formulé dans les années 1950. On dispose d'un dépôt, d'un ensemble de points de livraison, d'une flotte de véhicules avec des capacités définies, et d'une matrice de temps de trajet. L'objectif : trouver l'affectation des points aux véhicules et l'ordre de visite qui minimisent le kilométrage total, le temps de tournée ou le nombre de véhicules utilisés.

Ce n'est pas de l'IA au sens apprentissage automatique. C'est de la combinatoire, résolue par des algorithmes exacts (branch-and-bound) pour les petits volumes, et par des heuristiques (Lin-Kernighan, Clarke-Wright, métaheuristiques comme le recuit simulé ou les algorithmes génétiques) pour les volumes réels où l'exact est trop lent.

L'IA prédictive intervient à un autre niveau. Elle ne calcule pas l'ordre de visite : elle améliore la qualité des données en entrée du solveur. Concrètement :

• Estimation des durées de livraison réelles. Le temps passé à chaque point ne se réduit pas au temps de trajet. Déchargement, accès au bon quai, attente en porterie, signature du bon de livraison : selon les types de clients, les horaires, les jours de semaine, ces durées varient du simple au triple. Un modèle entraîné sur l'historique des télématiques permet d'estimer ces durées avec une précision meilleure que les valeurs forfaitaires.
• Prédiction des fenêtres de disponibilité. Certains clients ne sont disponibles que sur des plages réduites. Un modèle de classification entraîné sur les historiques de livraison peut anticiper les créneaux à risque d'échec et en tenir compte lors du séquençage.
• Prévision de la demande pour pré-dimensionner la flotte. Sur les activités de livraison à domicile ou les tournées de distribution B2B régulières, prévoir le volume J+1 ou J+7 permet d'affecter le bon nombre de véhicules à l'avance. C'est une problématique de prévision de séries temporelles, pas de routage.

Soyons honnêtes : pour la plupart des PME de transport ou de distribution, la priorité est le solveur VRP. L'IA prédictive vient en deuxième étape, quand les données d'historique existent et quand le solveur de base tourne déjà en production.

Les données nécessaires avant de lancer quoi que ce soit

C'est là que 80 % des projets perdent du temps. On pense au modèle, on oublie les données.

Des adresses propres et géocodées

Un solveur VRP a besoin de coordonnées GPS ou d'une matrice de distances entre les points. Si vos adresses sont stockées sous des formats inconsistants (abréviations, noms de rues fantaisistes, codes postaux manquants), le géocodage va produire des coordonnées erronées. Une adresse mal géocodée décale un point de 500 mètres ou de plusieurs kilomètres, et le solveur optimise sur une réalité qui n'existe pas.

Avant tout projet, auditez la qualité de votre base adresses. La norme AFNOR NF Z10-011 cadre la structuration des adresses en France. Des outils comme la Base Adresse Nationale (BAN) permettent de valider et corriger vos adresses gratuitement via API. C'est une étape préliminaire non négociable.

Les contraintes opérationnelles formalisées

Un solveur VRP ne sait pas ce que vous n'avez pas dit. Les contraintes à modéliser explicitement :

• Capacité des véhicules (poids, volume, nombre de colis) pour chaque point de la flotte.
• Fenêtres horaires par point de livraison, avec la granularité réelle : une fenêtre de 2 heures n'a pas le même impact sur la faisabilité qu'une fenêtre de 30 minutes.
• Durée de service par type de point (particulier, point relais, entrepôt, grande surface). C'est souvent la donnée la plus mal renseignée dans les systèmes.
• Compétences chauffeurs si certains points requièrent des certifications (matières dangereuses, hayon élévateur, carte carburant entreprise).

L'historique télématique pour la couche prédictive

Si vous voulez aller plus loin que le solveur de base et intégrer de l'IA prédictive, il vous faut des données d'exécution : horodatages réels d'arrivée et de départ à chaque point, incidents de livraison, passages infructueux. Sur 12 à 24 mois selon la volumétrie, ces données permettent d'entraîner des modèles de durée de service par type de point, par heure, par jour de semaine.

Sans cet historique, on ne peut pas entraîner grand-chose d'utile. Et si votre TMS (Transportation Management System) ne remonte pas ces données de façon fiable, c'est par là qu'il faut commencer.

Les outils concrets : OR-Tools, VROOM, SaaS

Voici l'état du terrain en 2026 pour les équipes qui veulent passer à l'acte.

OR-Tools (Google, open source)

OR-Tools est la bibliothèque de recherche opérationnelle de Google, disponible en Python, Java, C++ et .NET sous licence Apache 2.0. Son module de routage de véhicules gère les contraintes VRP classiques : capacité, fenêtres horaires (VRPTW), durée maximale de tournée, dépôts multiples. C'est le point de départ naturel pour une équipe technique qui veut construire sa propre solution sans abonnement.

La documentation officielle est bien faite, avec des exemples complets sur le VRP avec fenêtres horaires. Le vrai coût est humain : intégrer OR-Tools dans un workflow de production (récupération des commandes, géocodage, calcul de la matrice de distances via l'API Google Maps ou OSRM en open source, export vers les TMS chauffeurs) représente plusieurs semaines de développement.

VROOM (open source)

VROOM (Vehicle Routing Open-Source Optimization Machine) est un solveur VRP plus spécialisé qu'OR-Tools, exposé via une API REST légère. Il est plus rapide sur les gros volumes (plusieurs milliers de points) et s'intègre nativement avec OSRM ou OpenRouteService pour le calcul de matrices de distances sans dépendance à l'API Google. Pour des volumes élevés avec contrainte de coût d'appels API, c'est souvent le meilleur choix technique.

SaaS spécialisés

Pour une PME sans équipe de développement dédiée, les SaaS de routage embarquent les mêmes algorithmes dans une interface web et des API prêtes à l'emploi :

• Route4Me et OptimoRoute : solutions anglophones bien établies, intégrations TMS nombreuses, tarifs par véhicule et par mois.
• Metaroute : solution française, interface en français, support adapté aux contraintes réglementaires locales (temps de conduite, repos, ADR).
• Les ERP de transport (Cargou, Akanea Trace, Hardis Reflex) intègrent généralement un module de tournées basé sur ces solveurs, ce qui évite une intégration supplémentaire si vous êtes déjà équipés.

Outil	Type	Cas d'usage	Compétence requise
OR-Tools	Open source, bibliothèque Python	Solution sur mesure, intégration TMS, contraintes complexes	Développeur Python
VROOM	Open source, API REST	Gros volumes, infrastructure propre, sans coût API carte	Développeur backend
OptimoRoute / Route4Me	SaaS	PME sans dev, interface web, intégration rapide	Utilisateur métier
Metaroute	SaaS français	Flotte française, conformité ADR, support en français	Utilisateur métier
Module TMS intégré	Module ERP	Déjà sur Cargou / Akanea / Hardis, éviter une intégration	Paramétrage fonctionnel

Gains conditionnés : ce qu'on peut réalistement attendre

Soyons précis sur les ordres de grandeur, parce que les chiffres marketing sur ce sujet sont souvent extravagants.

Si vos tournées sont planifiées manuellement ou par simple logique géographique (on regroupe par quartier, point barre), un solveur VRP laisse généralement 15 à 30 % de kilométrage évitable. C'est le cas le plus favorable, et c'est réel : la combinatoire dépasse rapidement les capacités de l'intuition humaine dès qu'on dépasse 20 points par tournée.

Si vous utilisez déjà un outil de routage de base (Google Maps en multi-étapes, un TMS ancien avec algorithme simplifié), le gain marginal d'un solveur plus sophistiqué est de l'ordre de 5 à 12 % selon la densité des contraintes. Moins spectaculaire, mais mesurable.

La prédiction IA des durées de livraison réduit principalement le nombre de retards en fin de tournée et les passages infructueux (livraison tentée quand le client est absent). Son impact kilométrique est indirect. En revanche, sur les activités où les passages infructueux génèrent un second passage (et ses coûts), le gain peut être substantiel selon le volume.

Une règle simple : si votre flotte fait moins de 15 points de livraison par véhicule et par jour, le gain algorithmique sera marginal. Un planificateur humain expérimenté fait généralement aussi bien à ce volume. Le seuil de rentabilité d'un projet d'optimisation se situe plutôt à partir de 20 à 30 points par tournée.

Pour les aspects de suivi et de traçabilité qui accompagnent souvent ces projets, voir notre article sur l'automatisation du suivi des livraisons et des relances en transport.

Limites réelles et ce qui fait échouer ces projets

C'est la partie que les éditeurs de SaaS n'ont pas intérêt à mettre en avant.

La qualité des adresses sabote l'optimisation

On l'a dit, mais ça mérite d'être répété : un solveur VRP est aussi bon que la matrice de distances qu'il utilise, et la matrice est aussi bonne que le géocodage, qui est aussi bon que les adresses en entrée. Sur des entreprises qui gèrent leurs adresses dans un ERP ancien avec des champs libres non structurés, le taux d'adresses mal géocodées peut dépasser 10 à 15 %. Le solveur tourne parfaitement sur des données qui ne correspondent pas à la réalité terrain. Résultat : des tournées techniquement optimales qui envoient des chauffeurs au mauvais endroit.

C'est le frein numéro un. Et il n'y a pas de raccourci : il faut nettoyer les adresses avant de lancer le projet.

Les contraintes terrain non modélisées

Un algorithme ne sait pas que le client de la rue des Acacias ne reçoit jamais avant 9h30 parce que son responsable réception arrive en retard le mardi. Il ne sait pas que la zone industrielle de Pierrefitte a un sens unique qui a changé en janvier. Il ne sait pas que ce chauffeur connaît bien ce secteur et fait systématiquement les stops dans un ordre différent parce que le stationnement est difficile.

Ces contraintes implicites existent dans toutes les flottes. Si elles ne sont pas formalisées dans le système (et elles ne le sont presque jamais complètement), les chauffeurs vont modifier les tournées. Ce qui est parfaitement rationnel de leur côté. Mais si les modifications ne remontent pas dans le système, l'algorithme ne peut pas apprendre, et on tourne en rond entre la tournée optimale théorique et la tournée réelle improvisée.

L'acceptation des équipes terrain

C'est le facteur d'échec le plus sous-estimé dans les réunions de projet. Un chauffeur qui a planifié ses tournées pendant cinq ans selon sa propre logique ne va pas changer ses habitudes parce qu'un algorithme lui dit que c'est sous-optimal. Surtout s'il n'a pas été consulté pendant la conception du projet, s'il perçoit l'outil comme un moyen de surveillance, ou si la première version du système lui impose des tournées qui oublient des contraintes terrain qu'il connaît.

Les projets qui fonctionnent ont tous prévu une phase de co-construction avec les équipes terrain, un mécanisme de remontée des exceptions (le chauffeur peut signaler une contrainte dans l'appli de tournée), et une période de rodage où les tournées algorithmiques sont présentées comme des suggestions modifiables.

La surenchère sur la couche IA

Un piège fréquent chez les équipes qui ont lu des articles sur l'IA logistique : vouloir intégrer la prédiction IA dès le démarrage, avant même que le solveur VRP tourne en production et que les équipes l'utilisent vraiment. On construit un modèle de prédiction des durées de livraison sur des données d'historique de mauvaise qualité, on l'intègre dans un solveur qui n'est pas encore stabilisé, et on obtient un système complexe qui ne tient pas ses promesses. Mieux vaut stabiliser le solveur de base, collecter 6 à 12 mois de données d'exécution propres, puis envisager la couche prédictive.

Quand choisir le solveur VRP, quand ajouter l'IA prédictive

Une grille de lecture simple pour décider où mettre l'énergie :

Situation	Approche recommandée
Tournées planifiées manuellement, plus de 20 points par véhicule	Solveur VRP en priorité (OR-Tools, SaaS). ROI immédiat.
Outil de routage existant mais contraintes non prises en compte	Reconfigurer et enrichir le solveur existant avant tout ajout IA.
Taux de passages infructueux supérieur à 8 à 10 %	Diagnostic d'abord : problème d'adresses ou de fenêtres horaires ? Souvent réglé par le solveur, pas par du ML.
Durées de livraison très variables, données télématiques disponibles sur 12 mois	IA prédictive sur les durées de service, en complément du solveur.
Demande très variable (pics saisonniers, zones géographiques nouvelles)	Prévision de demande (séries temporelles) pour dimensionner la flotte.
Moins de 15 points par tournée, flotte de 2 à 3 véhicules	Optimisation manuelle ou SaaS léger suffit. Pas de projet IA à ce stade.

Pour aller plus loin sur les cas d'usage IA dans le transport et la logistique au sens large, voir notre article sur l'IA pour le transport et la logistique en PME.

Si vous avez identifié un cas d'usage concret sur votre flotte et que vous voulez évaluer la faisabilité, notre équipe propose un cadrage court via notre page solution IA sur mesure.

Questions fréquentes sur l'optimisation de tournées par IA

En résumé

L'optimisation des tournées de livraison par IA commence presque toujours par un solveur VRP bien configuré, pas par du machine learning. La recherche opérationnelle (OR-Tools, VROOM, SaaS spécialisés) apporte le gain kilométrique principal. L'IA prédictive vient en deuxième étape, quand les données télématiques existent et que le solveur de base est stabilisé en production.

Les deux conditions non négociables : des adresses propres et géocodées, et des contraintes opérationnelles formalisées. Sans elles, l'algorithme le plus sophistiqué optimise sur du vent.

Et soyons directs sur le facteur humain : un projet d'optimisation de tournées qui n'embarque pas les chauffeurs dès la conception finit avec des tournées algorithmiques que personne n'applique. Ce n'est pas un problème d'IA. C'est un problème de conduite du changement.