L'essentiel d'abord : avant de câbler le SSO sur votre WMS, OMS et TMS, ne commencez pas par la documentation du protocole. Consacrez un après-midi à construire un tableur à trois colonnes — la personne, son rôle dans chaque système, qui désactive le compte à son départ. Si vous n'arrivez pas à remplir cette feuille, peu importe que vous choisissiez SAML ou OIDC. J'ai vu ce même échec trois fois, et le point de rupture est toujours le même : le fournisseur d'identité se connecte parfaitement, et la correspondance des rôles côté métier est un désastre.
Pourquoi ça explose toujours la veille de la mise en production
Septembre 2023. Un 3PL de 60,000 pieds carrés en Californie du Sud, qui bascule WMS, OMS et TMS la même semaine. Pour faire simple, le client a donné à l'atelier un seul identifiant et mot de passe partagés sur les trois systèmes. Ça paraît efficace, non ?
Ça a explosé au troisième jour. Un représentant du service client qui pouvait consulter les commandes dans l'OMS pouvait aussi modifier les tarifs des transporteurs dans le TMS — parce que le rôle « CSR » ne signifiait pas du tout la même chose dans chaque système, et que le login partagé héritait des permissions les plus larges des trois. Le patron m'a demandé : « Ce n'est pas ça, le single sign-on ? Pourquoi ça devient pire ? » Ma réponse : ce n'est pas du single sign-on. C'est un point unique de défaillance avec un écran de connexion.
La façon dont on l'a sauvé était moche mais efficace : on a gelé 40 comptes partagés et quelques en une nuit, reconstruit 120 comptes individuels mappés personne–système–rôle, relancé l'activité, puis passé deux semaines à aligner les matrices de rôles et à tout brancher sur une source d'identité unique. Ce projet m'a gravé une leçon : le SSO répond à « qui êtes-vous ». L'autorisation répond à « que pouvez-vous faire ». Ce sont deux problèmes différents, et il ne faut jamais déléguer le second au premier.
La checklist : de zéro au SSO, étape par étape
Étape 1 : Inventoriez tous les comptes. Exportez tous les comptes des trois systèmes dans un tableur à trois colonnes : identifiant, système, rôle actuel. Signalez trois types — les comptes zombies d'employés partis (presque tous les projets en ont 5–10 %), les logins « publics » partagés (les plus courants sur les tablettes de picking), et les « comptes dieux » sur-privilégiés. Si on ne les nettoie pas avant la mise en production, le SSO ne change rien.
Étape 2 : Construisez la matrice de correspondance des rôles. Les lignes sont les rôles métier (picker, CSR, dispatcheur, superviseur d'entrepôt, finance, admin IT) ; les colonnes sont les trois systèmes ; chaque cellule dit exactement quels boutons ce rôle peut cliquer dans ce système. Attention : un « dispatcher » dans le TMS et un « dispatcher » dans le WMS ne sont probablement pas la même chose. Même nom, pouvoirs différents. Faites signer cette feuille par le responsable métier. Pas de signature, pas de mise en production.
Étape 3 : Choisissez votre source d'identité. Si l'entreprise a déjà un système d'identité d'entreprise, utilisez-le comme fournisseur d'identité — n'en construisez pas un deuxième. Ce n'est que s'il n'y a rien en place que vous passez à la décision de protocole de l'étape 4.
Étape 4 : Choisissez le protocole. Nouveaux systèmes : OIDC en premier. Systèmes legacy : vérifiez la prise en charge de SAML 2.0. Beaucoup de produits WMS traditionnels ne parlent que SAML — ne leur imposez pas OIDC et ne réécrivez pas leur code. Les trous de lapin de l'adaptation de protocole sont plus profonds qu'il n'y paraît.
Étape 5 : Mappez les attributs utilisateur. Décidez de ce que le fournisseur d'identité transmet en aval : matricule, email, département, rôle. Transmettez au moins un identifiant stable et globalement unique — le matricule, pas l'email, car les emails sont renommés. Pour chaque champ, nommez la source faisant autorité : le département vient des RH, point final.
Étape 6 : Branchez le flux de sortie (offboarding). La désactivation des comptes doit s'accrocher au processus de départ des RH, avec pour objectif « désactivé le dernier jour ». Impossible à automatiser ? Alors l'IT réconcilie manuellement la liste des départs chaque vendredi après-midi. J'ai vu ce trou trois fois. Début 2024, un entrepôt e-commerce d'articles pour la maison a fait un audit des permissions six mois après un lancement SSO propre et a découvert qu'un dispatcheur parti trois mois plus tôt pouvait toujours se connecter au TMS et consulter les tarifs des transporteurs — parce que personne n'avait jamais synchronisé la liste des départs des RH avec l'IT.
Étape 7 : Déployez par étapes. Pilote avec 5–10 personnes IT pendant une semaine, puis un entrepôt, puis tout le monde. Gardez l'ancien chemin de connexion disponible comme rollback pendant le pilote — cette ligne figure en tête de ma checklist du soir de mise en production, en permanence.
Faites les comptes d'abord : SAML vs OIDC vs comptes maison
| SAML 2.0 | OIDC | Comptes maison | |
|---|---|---|---|
| Idéal pour | Systèmes legacy, WMS/ERP traditionnels | Nouveaux systèmes, apps cloud-native | Petites équipes avec un ou deux systèmes |
| Effort d'implémentation | Moyen (config XML verbeuse) | Plus faible (JSON, écosystème mature) | Faible au début, élevé ensuite |
| Maintenance continue | Faible (standard mature) | Faible | Élevée (politique de mots de passe, audit, MFA — tout en DIY) |
| Support mobile/tablette | Faible | Fort | Dépend de votre code |
| Coût total long terme | Vieux mais stable | Choix par défaut des nouveaux projets | Perd de l'argent au-delà de deux systèmes — non |
Le cadre de décision est simple : si l'un des trois systèmes ne prend en charge que SAML, misez tout sur SAML. Tous les systèmes sont nouveaux ? OIDC. N'envisagez les comptes maison que si vous êtes certain de ne pas dépasser deux systèmes dans les deux prochaines années. Le vrai coût d'un système de comptes maison, ce n'est pas la construction — c'est le jour où vous branchez le quatrième système et découvrez que les trois premiers ont chacun inventé leur propre politique de mots de passe.
Checklist du soir de mise en production : tous les échecs habitent ici
- Supprimez les comptes de test. Presque tous les projets révèlent trois à cinq comptes de type test01 encore vivants la veille de la mise en production.
- Ne faites pas passer les comptes admin par le SSO. Gardez au moins un compte local de super-admin par système pour le jour où le fournisseur d'identité tombera. Écrivez le mot de passe sur papier et enfermez-le dans un coffre — oui, c'est primitif, et oui, ça a sauvé une mise en production.
- Alignez les délais d'expiration de session sur les trois systèmes. WMS à 8 heures et TMS à 30 minutes rendront les dispatcheurs fous. Standardisez sur 4–8 heures, avec une politique distincte pour les tablettes de haute saison qui ne se verrouillent jamais.
- Testez le scénario de zone morte. Quand le Wi-Fi de l'entrepôt tombe, la page de redirection SSO ne se charge pas sur la tablette et le picker reste planté devant le rack, les yeux dans le vide. Le mode dégradé de secours doit être testé pour de vrai, sur le vrai terrain.
- Assurez-vous que les journaux d'audit peuvent être joints. Quand quelque chose casse, vous devez pouvoir répondre « qu'est-ce que cet utilisateur a modifié dans le TMS hier à 2 p.m. » — et les journaux des trois systèmes doivent porter le même identifiant utilisateur.
Une note à contre-courant pour finir : beaucoup de gens se sentent plus en sécurité après la mise en production du SSO. La vérité va dans l'autre sens — le SSO transforme « une clé, une porte » en « une clé, trois portes », donc une clé perdue coûte trois fois plus cher. Le MFA n'est pas optionnel avec le SSO ; il fait partie du package. Trop de friction ? Alors imposez-le au moins pour les rôles d'admins et de finance.
Une chose à faire demain : exportez les comptes des trois systèmes et disposez-les dans les trois colonnes de l'étape 1. La première vérité que vous découvrirez est généralement celle-ci — les 80 comptes que vous pensiez avoir sont en réalité 110.
Par Lin Xiao, Consultante en implémentation WMS
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
