Remplacer un WMS sans arrêter l'entrepôt suppose de savoir, à un moment donné, exactement ce qu'il contient. Chez un fabricant de menuiseries industrielles, nous avons conçu pour cela un module d'inventaire dans une GPAO : un outil de comptage par scan, à plusieurs passes, qui a servi à vérifier les données migrées depuis l'ancien système et à sécuriser la bascule. Ce cas client en décrit les choix et les enseignements.
Contexte
L'entreprise, spécialisée dans la menuiserie industrielle, gérait son entrepôt avec un WMS (Warehouse Management System) ancien, développé en Delphi, qui ne répondait plus aux exigences de traçabilité et de gestion des flux. Son remplacement était devenu prioritaire, alors même que la nouvelle GPAO web ne couvrait pas encore l'intégralité du flux de fabrication. Les opérateurs étaient équipés de terminaux mobiles Zebra, et l'étiquetage des colis reposait sur des imprimantes Zebra connectées au cloud.
Le problème
Le défi était double : assurer la continuité des opérations pendant la transition, et garantir l'intégrité des données entre l'ancien et le nouveau système. L'historique des colis, des palettes et des emplacements devait passer d'une base SQL à une base documentaire, sans certitude que tout ce que l'ancien WMS affichait existait encore physiquement. Un inventaire complet, outillé, était la seule façon de valider la migration avant de basculer.
Ce que nous avons mis en place : un module d'inventaire dans une GPAO
La migration des données
Nous avons d'abord extrait les données de l'ancien logiciel depuis ses tables SQL, puis écrit un script de migration vers la base NoSQL MongoDB de la nouvelle GPAO. Il ne s'agissait pas d'une copie : le passage d'un modèle relationnel à un modèle document a demandé un mapping complet, une réorganisation des structures pour exploiter les nouvelles fonctions, et un enrichissement des données avec le contenu de chaque colis, information que l'ancien système ne connaissait pas. En parallèle, des scripts ont généré les commandes clients manquantes, les emplacements et les palettes, afin de rattacher correctement chaque colis à ces informations.
Le module d'inventaire
Face à l'incertitude sur les données migrées, le module d'inventaire est devenu le cœur de la bascule. Il ne sert pas seulement à compter : il synchronise les deux systèmes et garantit l'exactitude des données au moment du basculement. Ses fonctions, dans l'ordre d'un inventaire :
- Création et initialisation. Copie intégrale des données des deux systèmes dans une table d'inventaire dédiée ; verrouillage des accès au WMS, notifié en temps réel par WebSocket au lancement du comptage, pour empêcher toute modification concurrente.
- Comptage par scan. Scan de chaque colis sur la palette, scan de validation de la palette complète, scan de l'emplacement pour confirmer la localisation. Un colis non reconnu peut être créé directement pendant l'inventaire.
- Tableau de bord en temps réel. Nombre de colis à inventorier, nombre inventorié, écarts détectés, pourcentage d'avancement ; traçabilité des opérations par opérateur ; interface d'administration pour corriger une donnée.
- Comptages multiples. Un premier comptage de référence ; un second comptage possible sur les lignes sélectionnées, le premier étant gelé ; un troisième pour trancher les écarts persistants. Les besoins de recomptage sont communiqués aux opérateurs par impression automatique d'un PDF.
- Interface opérateur. Une application responsive sur les terminaux Zebra, avec un enchaînement de scans volontairement simple.
La clôture
À la clôture, un script parcourt chaque ligne inventoriée et met à jour les tables du WMS en appliquant une règle de priorité claire : la valeur du troisième comptage si elle existe, sinon celle du deuxième, sinon celle du premier.
Un choix assumé pour tenir le délai
Pour répondre à l'urgence du déploiement du nouveau WMS, nous avons volontairement renoncé à l'affectation automatique des lignes à chaque opérateur. Ce choix a accéléré la mise en production sans dégrader l'efficacité du comptage.
Résultats
- une transition sécurisée entre l'ancien et le nouveau système ;
- la validation et la correction des données migrées, ligne par ligne ;
- une visibilité en temps réel sur l'avancement de l'inventaire ;
- une réduction significative du risque d'erreur dans la gestion des stocks.
Ce que nous en retenons
Un inventaire est le meilleur test d'une migration. Aucun rapprochement de tables ne remplace le passage physique devant chaque palette. C'est ce qui a permis de valider, puis de corriger, les données migrées.
Verrouiller pendant le comptage. Un inventaire sur un stock qui bouge ne vaut rien. Le blocage du WMS par notification WebSocket est techniquement simple et indispensable.
Compter plusieurs fois, en gelant chaque passe. Le triple comptage avec priorité au plus récent donne une règle de réconciliation que tout le monde comprend, et évite les discussions à la clôture.
Livrer vite ce qui compte. Renoncer à une fonction confortable (l'affectation automatique) pour tenir une date de bascule est souvent le bon choix. Ce qui se passe lorsque les conditions d'une bascule ne sont pas réunies fait l'objet d'un autre retour d'expérience. Pour le choix des codes-barres et des terminaux, voir notre guide des codes-barres en production.
Et aujourd'hui ?
Ce besoin est couvert en standard par le module Inventaire d'Odoo : emplacements, colis et palettes, inventaires tournants et comptage par scan sur terminal mobile, que nous mettons en place dans le cadre de notre intégration Odoo pour l'industrie. Côté atelier, Planitrack assure le suivi des OF à la douchette, et le hub logiciel GPAO simple pour PME présente l'ensemble de notre offre. Demander une démo.