Tout le monde a vécu la scène. Il est 17 h 30, vous êtes au centre-ville de Tunis, l'application annonce 28 minutes jusqu'à La Marsa. Une heure plus tard, vous êtes toujours au niveau du Kram. Pour un transporteur qui a promis un créneau de livraison, ou une navette de personnel qui doit être à l'usine à 6 h, c'est un problème d'exploitation. Comprendre d'où vient l'écart, c'est déjà la moitié du travail.
Pourquoi le GPS de Maps se trompe sur les routes tunisiennes
Un moteur d'itinéraire calcule un temps à partir d'une chose très simple : la longueur de chaque tronçon divisée par une vitesse supposée. Et en Tunisie, plusieurs de ces suppositions tombent à côté.
Le trafic, d'abord. La sortie de Tunis par la Route de la Marsa, ou vers Ben Arous et sa zone industrielle, entre 16 h 30 et 19 h, n'a rien à voir avec la même route à 14 h. Les applications grand public s'appuient sur les traces des téléphones pour estimer le trafic en direct. Ça fonctionne correctement sur les grands axes du Grand Tunis, beaucoup moins à Sfax, Sousse ou Bizerte où la densité de données est plus faible, et pas du tout pour anticiper un départ prévu à 7 h le lendemain.
Les ralentisseurs, ensuite. Un dos-d'âne tous les deux cents mètres dans une rue résidentielle de Mégrine ou de Hammam-Lif, ça fait tomber la vitesse moyenne bien en dessous de la limite affichée. Aucune base cartographique ne les recense tous, et le moteur suppose donc une rue à 50 km/h là où le livreur roule à 20.
Les ronds-points. La Tunisie en a beaucoup, et quelques-uns, à la sortie de Tunis ou de Sfax, sont de vrais carrefours à pertes de temps aux heures de pointe. Pour un moteur d'itinéraire, un rond-point coûte quelques secondes de pénalité forfaitaire. Sur le terrain, cela peut être cinq minutes.
Et puis il y a les routes qui ne sont pas sur la carte, ou qui y sont mal. Les nouveaux lotissements de la Soukra, de Raoued ou de la périphérie de Sfax poussent plus vite que les mises à jour cartographiques. Quand une rue manque, le moteur fait un détour absurde par l'axe principal, et le temps annoncé est faux par construction. C'est un point sur lequel on a beaucoup travaillé chez TMaps : notre base compte plus de 120 000 routes, avec en moyenne deux fois plus de routes nommées que Google Maps, surtout en zones périurbaines et dans les nouveaux quartiers.
Ce qu'un moteur d'itinéraire sait, et ce qu'il ignore
Un moteur d'itinéraire connaît la géométrie du réseau, les sens uniques, les interdictions de tourner quand elles sont renseignées, les classes de routes (autoroute A1, GP1, route régionale, rue locale) et une vitesse par classe. Avec ça, il produit un trajet cohérent et une distance juste. La distance, d'ailleurs, est presque toujours fiable. C'est le temps qui pose problème.
Ce qu'il ignore : l'état réel de la chaussée, le camion garé en double file devant le Marché central de Tunis, le temps de stationnement, le fait que votre chauffeur connaît un raccourci par le quartier, ou qu'il refuse l'autoroute avec un utilitaire chargé. Il ignore aussi tout ce qui se passe une fois arrivé : trouver le bâtiment, appeler le client, monter trois étages. Dans une tournée de livraison urbaine, ce temps à l'arrêt pèse souvent plus lourd que le temps de roulage.
Autrement dit, le GPS de votre appli Maps vous donne une bonne base et un mauvais chiffre final. C'est à vous de le corriger.
Comment un logisticien corrige le tir
La première chose à faire, c'est de mesurer. Si vous suivez vos véhicules (voir notre article sur le suivi de flotte en temps réel), vous disposez déjà des temps réels de chaque trajet. Comparez-les au temps estimé, par tranche horaire et par zone. Vous verrez vite des motifs se dessiner : un gros écart entre 17 h et 19 h vers la banlieue nord, un écart moyen le vendredi après-midi, presque rien la nuit. Ces motifs deviennent vos profils horaires.
Un profil horaire, concrètement, c'est un coefficient appliqué au temps brut selon l'heure de départ et la zone. On peut le gérer dans un simple tableau au début. Chez un transporteur de personnel qui dessert la zone industrielle de Ben Arous depuis les quartiers ouest de Tunis, c'est ce tableau, corrigé pendant deux mois avec les retours des chauffeurs, qui a permis de tenir les horaires. Le moteur restait le même ; c'est la lecture de son résultat qui avait changé.
Deuxième levier : les retours terrain. Un chauffeur qui signale « la rue est fermée pour travaux depuis lundi » ou « ce client, comptez dix minutes pour le stationnement » vous donne une information qu'aucune API ne détient. Il faut un moyen simple de la collecter (un bouton dans l'application chauffeur suffit) et une personne qui la relit une fois par semaine. Ce qui est structurel, comme le temps d'arrêt chez tel client, entre dans la fiche du client. Ce qui est temporaire, comme des travaux, devient une exclusion de tronçon pour quelques jours.
Troisième levier : recalculer vos matrices de distance régulièrement. Beaucoup d'équipes calculent une fois la matrice des temps entre leur dépôt et leurs points de livraison, puis la gardent six mois. Or les temps changent : nouveaux quartiers, nouvelle rocade, saison estivale à Sousse ou à Djerba. Relancer le calcul chaque semaine, coûte peu et évite des écarts qui s'accumulent en silence. Notre API de calcul d'itinéraire et la matrice de distance sont faites pour être appelées souvent, avec une facturation en dinar et des tarifs fixes qui ne vous dissuadent pas de le faire.
Deux cas concrets
Côté livraison, imaginez un e-commerçant qui expédie depuis un entrepôt à Mégrine vers tout le Grand Tunis. Le moteur lui donne une tournée d'une vingtaine d'arrêts en un peu plus de quatre heures. La réalité tourne autour de six. L'écart vient pour une part du trafic de l'après-midi vers l'Ariana et La Marsa, et pour une part plus grande du temps passé à chaque arrêt. La correction ne consiste pas à changer de moteur, mais à ajouter un temps de service par arrêt (différent pour un appartement, une entreprise ou un point relais) et à appliquer un profil horaire sur la partie roulage. Après cela, l'estimation devient assez fiable pour donner un créneau crédible au client.
Côté transport de personnel, la contrainte est inverse : l'heure d'arrivée est fixe, c'est l'heure de départ qu'il faut calculer. Un bus qui doit déposer trente ouvriers à 6 h dans une usine de Sousse ne peut pas se permettre l'optimisme du GPS. Dans la pratique, on calcule le trajet avec le profil du créneau 5 h à 6 h (souvent fluide), on ajoute les arrêts de ramassage avec un temps fixe pour chacun, et on garde une marge que l'on ajuste avec les retours des chauffeurs. Le jour où il y a un souk hebdomadaire sur le parcours, le chauffeur le signale, et la marge du jeudi augmente pour ce trajet uniquement.
Dans les deux cas, ce sont les données terrain qui font la différence, pas l'algorithme. Le moteur fournit un squelette solide ; les profils, les temps de service et les retours des chauffeurs lui donnent de la chair.
Si vous voulez repartir des bases, notre article sur le calcul d'itinéraire en Tunisie explique comment le moteur construit son trajet. Et si vous avez déjà des temps réels à comparer, testez notre API de routage sur vos propres trajets : c'est la seule façon de savoir où elle se trompe, et de combien.
