Logistique : planification et gestion des aléas

En bref. L'IA ne remplace pas le plan de départ ; elle identifie les écarts dès qu’un aléas survient et propose une replanification réaliste, basée sur les données opérationnelles en temps réel. Son rôle est celui d’un assistant de décision qui ajuste les flux sans éliminer le risque, mais en réduisant le délai de réaction. La valeur se mesure à la rapidité de l’ajustement, pas à l’élimination totale des imprévus.

Une situation concrète de rupture de planification

Lors d’une réunion de suivi hebdomadaire chez un fabricant de pièces automobiles, le responsable logistique a constaté que le tableau de prévision des livraisons, actualisé la veille, indiquait un taux de service de 92 % alors que le réel, relevé sur le terrain, était tombé à 78 % après une panne de camion sur l’axe Rhône‑Alpes. Le plan théorique, établi à partir des historiques de demande et des capacités théoriques, ne tenait pas compte de cet événement ponctuel. L’écart de quatorze points a déclenché une recherche urgente de solutions de replanning, menée principalement avec des tableaux Excel et des appels téléphoniques.

Pourquoi la planification théorique reste insuffisante

Les modèles de prévision classiques reposent sur des hypothèses de stabilité : demande moyenne, temps de transit constants, disponibilité des ressources. En pratique, les aléas (panne de véhicule, retard de fournisseur, changement de priorité client) surviennent avec une fréquence qui, selon les enquêtes sectorielles, représente entre 15 % et 25 % des journées ouvrées dans une chaîne logistique moyenne. Lorsqu’un tel écart apparaît, le plan initial devient obsolète en quelques heures, obligeant les équipes à reconstituer un nouveau planning à partir de zéro, ce qui consomme du temps et augmente le risque d’erreurs de saisie.

Où l’IA intervient réellement : la détection d’écarts et la proposition de replanification

L’IA ne crée pas le plan de base ; elle analyse en continu les flux réels (données de géolocalisation des camions, niveaux de stock provenant du WMS, entrées du ERP) et compare ces valeurs aux prévisions établies. Dès qu’un écart dépasse un seuil défini (par exemple, un retard de livraison supérieur à deux heures ou une rupture de stock supérieure à 5 % du stock de sécurité), le système déclenche une alerte et propose un nouveau séquence d’activités. Cette proposition prend en compte les contraintes opérationnelles restantes : capacités des quais, horaires des conducteurs, créneaux de livraison clients. Le résultat n’est pas un plan définitif, mais une série d’ajustements suggérés que le responsable peut valider, modifier ou rejeter.

Exemple d’outilchain réaliste

Un dispositif fréquemment observé dans des PME industrielles comprend :

• Des capteurs GPS embarqués sur les flotteurs, envoyant leurs positions toutes les cinq minutes à un serveur cloud.
• Un ERP (ex. SAP Business One) qui fournit les commandes clients et les prévisions de demande hebdomadaires.
• Un workflow d’automatisation n8n ou Make qui récupère les données GPS et les stocks, les normalise et les envoie à un modèle de prévision.
• Un modèle de langage léger, tel que Mistral 7B ou GPT‑4o en mode « instruction », chargé de détecter les écarts et de générer une liste d’actions de replanification (réaffectation de camion, report de livraison, appel à un transporteur de secours).
• Un tableau de bord Excel ou un CRM (ex. HubSpot) où le responsable logistique visualise les propositions, indique sa décision et enregistre le résultat pour enrichir le modèle futur.

Cette chaîne ne nécessite pas de remplacement complet du système existant ; elle s’appuie sur les données déjà collectées et ajoute une couche d’analyse rapide. Le temps moyen entre la détection d’un écart et la proposition d’ajustement, observé dans des pilotes similaires, se situe autour de vingt à trente minutes, contre plusieurs heures lorsqu’on s’appuie uniquement sur des réunions de crise.

Quand ne pas automatiser la replanification (la réponse est « ne le faites pas »)

Dans les environnements où la variabilité provient principalement de décisions humaines non capturées par les systèmes (par exemple, des changements de priorité dictés par le directeur commercial lors d’un appel impromptu), l’automatisation peut produire des suggestions en décalage avec la réalité stratégique. Si les entrées de données sont manquantes ou peu fiables — cas fréquent lorsque les transporteurs ne partagent pas leurs positions ou lorsque les saisies manuelles d’entrées de stock sont effectuées une fois par jour — le risque de proposer un replan basé sur des informations erronées augmente considérablement. Dans ces cas, il vaut mieux conserver un processus de révision manuelle, soutenu par des points de contrôle réguliers, plutôt que de se fier à une sortie algorithmique qui pourrait entraîner des surcoûts ou des ruptures de service.

Prochaine étape concrète pour diriger une expérimentation

Commencez par cartographier, sur une période de deux semaines, tous les événements qui ont entraîné un décalage entre le plan de livraison publié et la réalisation réelle, en notant la source de l’aléa (transport, fournisseur, demande interne) et le temps de réaction observé. Identifiez un point de donnée facilement accessible (par exemple les horaires de départ enregistrés par les conducteurs) et mettez en place un flux simple avec Make qui compare ces horaires aux prévisions du ERP et envoie une notification par e‑mail lorsqu’un écart dépasse une heure. Évaluez, pendant un mois suivant, si cette alerte permet de réduire le temps moyen de décision de replanification de plus de trente pour cent avant d’envisager l’ajout d’un modèle de prévision plus élaboré.

Questions fréquentes

Quelle différence entre une prévision de demande et une détection d’écart en temps réel ?

Une prévision de demande estime ce qui devrait se produire à partir d’hypothèses historiques ; elle est généralement réalisée hebdomadairement ou mensuellement. La détection d’écart compare, à chaque nouveau message de donnée (position GPS, niveau de stock), la réalité observée à cette prévision et signale immédiatement lorsqu’un seuil est dépassé.

Faut‑il remplacer mon ERP actuel pour bénéficier de ces fonctionnalités ?

Non. L’approche décrite s’appuie sur les exportations ou les API de votre ERP existant pour récupérer les prévisions et les commandes. Les outils d’automatisation (n8n, Make) et le modèle de langage agissent comme une couche intermédiaire qui n’altère pas le cœur de votre système.

Dans quels types d’entreprises l’IA de replanification est‑elle peu adaptée ?

Lorsque les décisions critiques sont prises hors des systèmes d’information (par exemple, des changements de priorité verbaux lors de réunions informelles) ou lorsque la qualité des données de terrain est irrégulière, les suggestions automatisées peuvent être hors contexte. Dans ces cas, un suivi humain régulier reste plus sûr qu’une automatisation prématurée.

Quel ordre de grandeur de temps puis‑je espérer gagner avec une telle mise en place ?

Dans des pilotes menés auprès de PME de distribution, le délai entre la constatation d’un problème et la première action corrective est passé de plusieurs heures (souvent après une réunion de crise) à une vingtaine de minutes grâce à l’alerte automatisée. Ce gain dépend toutefois de la fréquence et de la gravité des aléas rencontrés dans votre chaîne spécifique.

Comment m’assurer que les propositions de l’IA restent conformes à mes contraintes opérationnelles ?

Le workflow d’automatisation doit inclure une règle de validation qui vérifie chaque suggestion contre vos capacités réelles (nombre de quais disponibles, heures de conduite autorisées, créneaux de livraison clients). Toute proposition qui viole une de ces contraintes est soit rejetée, soit renvoyée avec une note d’ajustement avant d’être présentée au responsable.