--- title: "Suivre des transporteurs sans API : la réalité technique au Québec" description: "Navigateurs headless, extraction de portails et courriels automatisés — comment on connecte les transporteurs qui n'ont jamais bâti d'API." url: "https://www.m3tracker.com/blogue/carrier-integration-without-apis" language: fr-CA published: "2026-04-02" modified: "2026-04-02" author: "M³ Tracker Team" site: "M³ Tracker" keywords: ["suivi transporteur sans API Québec", "extraction automatisée portail transporteur LTL", "navigateur headless suivi fret Canada", "courriel automatisé statut expédition", "intégration Guilbault Vitran automatisation", "courtier fret Montréal outil suivi", "données PRO numéro extraction transporteur"] --- # Suivre des transporteurs sans API : la réalité technique au Québec Au Québec, le paysage du transport LTL a une particularité que les plateformes américaines ne comprennent pas : la majorité des transporteurs n'offrent pas d'API. Guilbault, basé à Laval, opère un des plus grands réseaux LTL de la province. Leur portail web fonctionne bien. Mais il n'y a pas d'endpoint REST à appeler. Pas de JSON. Pas de webhook. C'est un site web conçu pour des humains qui tapent des numéros PRO dans un champ de recherche. Même constat pour Vitran, Transkid, et plusieurs transporteurs régionaux qui couvrent les corridors Montréal–Toronto, Québec–Saguenay, ou les routes vers les Maritimes. Le portail existe. L'API, non. Alors comment bâtir un tableau de bord unifié quand la moitié de vos transporteurs ne parlent pas aux logiciels ? On a dû construire trois approches distinctes. ## La pile d'intégration en trois couches Chez M³ Tracker, on classe chaque transporteur dans une de trois catégories. Environ 30 % offrent une API utilisable — Morneau à Montréal, Speedy Transport. Un autre 40 % ont un portail web qu'on peut scraper. Le dernier 30 % n'a rien de numérique : il faut passer par courriel ou téléphone. Chaque courtier a un mix différent selon sa clientèle et ses corridors. ### Couche 1 : Les API directes Quand un transporteur offre une API, on l'utilise. Point. Morneau fournit un endpoint REST qui retourne du JSON structuré — date de ramassage, historique des statuts avec horodatage et terminal, date de livraison, preuve de livraison. On envoie un numéro PRO, on reçoit tout ce qu'il faut. Les champs qu'on extrait systématiquement : - **Numéro PRO** et références secondaires du client - **Date et heure de ramassage** avec terminal d'origine - **Historique des événements** — chaque scan avec horodatage et localisation (ex. : « Départ terminal Montréal 14:32 HNE ») - **Date de livraison estimée** et date réelle - **Preuve de livraison** — nom du signataire, heure, parfois un document numérisé Les API sont fiables et rapides. Mais elles couvrent à peine un tiers des transporteurs qu'un courtier québécois utilise au quotidien. ### Couche 2 : Extraction des portails par navigateur headless C'est ici que ça devient technique — et c'est la couche qui couvre le plus de transporteurs. Prenons Guilbault. Leur portail de suivi accepte un numéro PRO et affiche une page avec le statut, les dates, et les mouvements entre terminaux. Un répartiteur ouvre Chrome, tape le numéro, lit l'écran. Nous, on fait exactement la même chose, sauf que notre « répartiteur » est une instance Chromium headless qui roule sur un serveur. Techniquement, on utilise Playwright — pas Puppeteer. Playwright gère mieux les contextes multi-navigateur et a un système d'auto-attente plus fiable pour les pages qui chargent du contenu dynamiquement. Le navigateur headless ouvre la page de suivi du transporteur, remplit le champ PRO, soumet le formulaire, attend que les résultats se rendent, puis extrait les données du DOM avec des sélecteurs CSS spécifiques à ce transporteur. Pour Vitran, la structure HTML est différente — les événements de statut apparaissent dans un tableau avec des colonnes date, heure, lieu, description. Pour Transkid, encore une autre disposition. Chaque transporteur a son propre adaptateur avec sa propre logique d'extraction. Il n'y a pas de raccourci. Quelqu'un doit analyser chaque portail et écrire le code d'extraction manuellement. ### Ce qu'on extrait des portails Les données extraites par scraping sont identiques à celles des API : numéros PRO, dates, événements de statut, noms de terminaux. La différence est mécanique — on lit du texte dans des éléments HTML au lieu de parser du JSON. Dans votre tableau de bord, le résultat est le même. Un détail qui surprend : les localisations de terminaux. Quand Guilbault affiche « Arrivé au terminal de Winnipeg » sur leur page, on capture ça. Quand Vitran montre qu'un envoi a quitté leur hub de Calgary, on récupère l'horodatage et le lieu. Ce niveau de détail permet aux courtiers de répondre à la question « où est mon fret ? » avec des faits précis au lieu de deviner. ## Limites de débit et scraping responsable On ne prend pas l'infrastructure des transporteurs à la légère. Un courtier qui vérifie le portail de Guilbault cinq fois par jour pour un envoi, c'est anodin. Un logiciel qui le vérifie toutes les dix minutes pour deux cents envois, c'est autre chose. Notre système de scraping impose plusieurs contraintes : - **Une requête à la fois par domaine transporteur.** Jamais de requêtes parallèles vers le même site. Si on a 50 envois Guilbault à vérifier, ils passent dans une file d'attente, un par un, avec une pause entre chaque. - **Vérifications pendant les heures d'affaires seulement.** De 7 h à 19 h, heure de l'Est, du lundi au vendredi. Le fret ne bouge pas à 3 h du matin. Nos scrapers non plus. - **Disjoncteurs (circuit breakers).** Si le portail d'un transporteur retourne trois erreurs consécutives — serveur en panne, timeout, structure de page inattendue — on arrête. Le disjoncteur se déclenche et le backoff est exponentiel : 5 minutes, puis 15, puis une heure. - **Intervalles configurables.** Un envoi ramassé hier avec une livraison prévue mardi prochain n'a pas besoin d'être vérifié toutes les 30 minutes. On ajuste la fréquence selon l'âge de l'envoi et la fenêtre de livraison estimée. Au final, notre scraping génère moins de trafic qu'un répartiteur humain qui vérifie le portail manuellement pendant sa journée. On remplace des clics par un script qui fait la même chose, poliment. ## Le suivi par courriel pour les transporteurs hors réseau Certains transporteurs n'ont ni portail ni API. Groupe LF fonctionne comme ça. Pareil pour certains transporteurs régionaux qui couvrent des corridors comme Rouyn-Noranda–Val-d'Or, ou les routes vers la Côte-Nord et le Bas-Saint-Laurent. Pour ces transporteurs, on a bâti un système de demande de statut par courriel. Le processus : 1. Vous cliquez « Demander une mise à jour » sur un envoi dans votre tableau de bord M³ Tracker 2. On envoie un courriel bilingue professionnel au répartiteur ou au contact opérationnel du transporteur 3. Le courriel contient quatre boutons colorés : **Ramassé** (bleu), **En transit** (ambre), **Retardé** (rouge) et **Livré** (vert) 4. Le transporteur clique le bon bouton — pas de compte à créer, pas d'application, pas de mot de passe 5. Le statut se met à jour instantanément dans votre tableau de bord Ça marche étonnamment bien. Le répartiteur voit un courriel propre et simple. Il clique un bouton. C'est fait. Cinq secondes. La plupart des transporteurs répondent en quelques heures pendant les jours ouvrables. Certains répondent en minutes, surtout après avoir vu le format une ou deux fois. Chaque bouton pointe vers une URL unique avec un jeton qui expire après sept jours. Le transporteur peut aussi ajouter une note — « retardé cause tempête à Sept-Îles » ou « livraison demain AM » — qui apparaît dans votre tableau de bord à côté du changement de statut. Pas besoin d'échanges de courriels interminables. ## Quand un portail change de structure Le plus grand risque du scraping de portails : un transporteur qui refait son site web. Ça arrive. Guilbault met à jour sa page de suivi, et soudainement nos sélecteurs CSS pointent vers le vide. On gère ça de deux façons. D'abord, chaque scraper inclut une détection d'erreur — si la structure attendue n'est pas trouvée, il ne retourne pas silencieusement des données vides. Il signale l'échec et l'envoi est marqué pour révision manuelle. Ensuite, on surveille les taux de réussite en continu. Si le scraper de Guilbault passe de 98 % à 40 % du jour au lendemain, on sait que leur portail a changé et on met à jour l'adaptateur. En pratique, la plupart des transporteurs modifient leurs portails rarement. Une ou deux fois par année, maximum. Et les changements sont souvent mineurs — un nom de classe CSS, un nouveau div wrapper. Corriger un scraper cassé prend typiquement une heure, pas une semaine. ## Le tableau de bord unifié Tout l'intérêt de cette approche en trois couches : vous, le courtier, n'avez pas à vous soucier de comment les données ont été obtenues. Un envoi suivi via l'API de Morneau a exactement la même apparence qu'un envoi scrapé du portail de Guilbault ou qu'un envoi mis à jour par courriel d'un petit transporteur de l'Abitibi. Chaque envoi affiche les mêmes champs : transporteur, numéro PRO, statut actuel, historique, date de ramassage, livraison estimée, livraison réelle. La barre de progression en quatre étapes — Réservé, Ramassé, En transit, Livré — fonctionne pareil peu importe la source de données. Vous pouvez filtrer, trier, chercher et exporter en CSV sans penser à la plomberie en dessous. Les transporteurs automatisés (API et portails) se mettent à jour tout seuls. Les transporteurs manuels passent par le courriel. Votre tableau de bord montre les deux, côte à côte, dans le même format. C'est le but : un seul écran, tout votre fret, zéro portail à naviguer. ## Commencer avec M³ Tracker Si vous êtes un courtier en transport au Québec qui jongle entre cinq portails de transporteurs et une pile de fils de courriels, c'est exactement pour ça qu'on a bâti M³ Tracker. On supporte déjà Guilbault, Vitran, Morneau, Speedy Transport, Transkid et d'autres — avec de nouveaux transporteurs ajoutés régulièrement selon les besoins de nos utilisateurs. [Créez un compte](/signup) et ajoutez votre premier envoi en moins de deux minutes. ## Questions fréquentes ### Comment M³ Tracker extrait-il les données des portails de transporteurs comme Guilbault ? On utilise un navigateur headless Chromium (Playwright) qui visite le portail du transporteur, entre le numéro PRO, et extrait les données du DOM — dates, statuts, terminaux — exactement comme un humain le ferait, mais de façon automatisée avec des sélecteurs CSS propres à chaque transporteur. ### Le scraping de portails est-il fiable à long terme ? Plus qu'on pense. La plupart des transporteurs canadiens modifient leurs portails une ou deux fois par année. Chaque scraper inclut une détection d'erreur — si la structure change, le système le signale immédiatement au lieu de retourner des données vides. La correction prend généralement une heure. ### Comment fonctionne le suivi par courriel pour les petits transporteurs ? On envoie un courriel bilingue professionnel au répartiteur du transporteur avec quatre boutons colorés (Ramassé, En transit, Retardé, Livré). Le transporteur clique un bouton — pas de compte à créer, pas d'application à installer. Le statut se met à jour en temps réel dans votre tableau de bord. ### Quels champs de données sont extraits pour chaque expédition ? Numéro PRO, date de ramassage, date de livraison estimée et réelle, historique complet des statuts avec horodatage et terminal (ex. : « Arrivé au terminal de Québec 08:15 HNE »), et preuve de livraison quand disponible. --- [M³ Tracker](https://www.m3tracker.com/) — suivi automatisé des expéditions pour les courtiers en transport canadiens.