Pourquoi le tail spend est l'enjeu silencieux des achats indirects
Dans la plupart des organisations, le tail spend représente 20% de la valeur des achats indirects mais 80% des transactions. C'est l'angle mort historique : trop éclaté pour mériter une stratégie catégorielle, trop volumineux en nombre de lignes pour être traité au cas par cas par les category managers.
Trois choses se passent quand on le laisse en l'état.
1. L'utilisateur attend. Six mois pour qu'un salarié obtienne une souris ergonomique parce que la demande passe par un sourcing complet. Cinq mois pour qu'un labo récupère une pièce de consommable parce que le fournisseur est nouveau et que la création a pris six relances. Sur le papier, on respecte le process. Dans la vraie vie, l'équipe arrête d'utiliser les achats.
2. Le maverick spend explose. Quand le canal officiel met cinq mois pour livrer un objet à 80 €, l'utilisateur sort sa carte personnelle, achète sur Amazon, et passe en note de frais. C'est rationnel de son point de vue. Sauf qu'à l'échelle d'un groupe, ça représente des milliers d'euros par jour de spend qui échappe à toute négociation, à toute donnée, à toute conformité.
3. Le coût transactionnel dépasse le coût d'achat. Créer un fournisseur, traiter une facture à 80 €, gérer la note de frais, archiver, contrôler. Le coût administratif d'une transaction tail dépasse régulièrement la valeur de l'achat lui-même. L'organisation paie deux fois : une fois en achat, une fois en process.
Le sujet n'est donc pas seulement "économiser sur le tail". C'est rendre du temps aux équipes, fluidifier l'expérience, et arrêter de gaspiller en transactionnel ce qu'on prétend économiser en sourcing.
La marketplace : le bon outil, sous conditions
Amazon Business est conçu exactement pour ce cas. Le catalogue couvre 99% du besoin tail courant (consommables, IT léger, mobilier, fournitures, équipement labo de base). L'expérience utilisateur reproduit celle d'Amazon grand public, donc l'utilisateur sait l'utiliser sans formation. Les prix sont compétitifs et benchmarkés en continu. L'intégration ERP via punchout permet de garder PO, three-way match et données propres.
Le client voulait précisément ce mix : reprendre le contrôle (donnée, conformité, prix) tout en améliorant l'expérience (délais, ergonomie, simplicité). Sur ce double objectif, la marketplace est un outil cohérent.
À une condition : la déployer comme un projet de transformation, pas comme un module SaaS.
Mon mandat
Côté Amazon Business EU, j'ai accompagné le déploiement chez ce groupe sur 30+ sites en EMEA. Le contrat existait, le tenant était live, l'adoption était à zéro. Six mois plus tard, le maverick spend sur les catégories couvertes était divisé par deux et l'expérience utilisateur s'était inversée.
Ce que j'ai trouvé sur le terrain
Les classiques du tail spend non géré, à grande échelle :
- Une politique achats écrite avant l'ère des marketplaces, muette sur le tail, pleine de zones grises.
- Aucune liste partagée des catégories qui doivent passer par Amazon Business et de celles qui n'en relèvent pas.
- Des category managers réticents (perte de contrôle) ou silencieusement soulagés (moins de bruit), sans récit commun.
- Des utilisateurs qui continuaient à passer en notes de frais parce que c'était plus rapide.
- Une intégration IT au minimum : SSO ok, punchout ok, three-way match à trous.
L'outil fonctionnait. Ce qui manquait, c'était un déploiement pensé comme un programme.
Les quatre conditions pour qu'une marketplace tienne sa promesse
Une marketplace ne crée pas de la conformité par sa seule présence. Elle a besoin de quatre piliers, exécutés en parallèle, dès le premier site.
1. Un business case clair, partagé, chiffré. Avant tout déploiement, on pose les chiffres : volume tail spend actuel, part en maverick, coût transactionnel par ligne, délai moyen d'obtention, économies attendues sur prix et sur process. Pas un slide marketing : un dossier que la finance valide. Sans ce document, le programme se fait challenger à chaque comité, et la première difficulté de déploiement le tue. Avec, on a un point d'ancrage objectif quand l'IT pousse une autre priorité ou quand un category manager veut sortir une catégorie du scope.
2. Un sponsor C-level visible. Sur ce dossier, j'ai demandé que CPO et CFO co-portent le programme, sur le papier, avec une revue trimestrielle. Toute initiative tail spend rétrécit le territoire perçu de certains category managers et ajoute du travail à l'IT. Sans un sponsor capable d'arbitrer au-dessus des deux, le projet cale en trois mois. Le sponsoring doit être visible à chaque kickoff site : message vidéo, responsabilités nommées, objectif chiffré.
3. Des cas d'usage écrits et signés. Chaque catégorie tail est cartographiée dans trois cases : dans le périmètre Amazon Business, hors périmètre (couverte par un contrat existant ou par une équipe catégorie) et zone grise à arbitrer. Le document est revu et signé par les category managers. À partir de là, la question n'est plus "est-ce que ça doit passer par Amazon Business ?" mais "cette catégorie est-elle dans la liste ?". Ce seul document retire la moitié des frictions et donne aux utilisateurs une réponse claire.
4. Une vraie phase d'hypercare site par site. L'hypercare est l'étape où la plupart des projets digitaux meurent en silence. Sur ce déploiement, nous avons exécuté un cycle de 8 semaines par site : un champion local nommé, des office hours hebdo, un point d'escalade unique vers les achats ops, un suivi quotidien des commandes qui passaient hors punchout, et un point de clôture avec le site lead avant de déclarer le go-live complet. Surtout, l'hypercare a servi à tester en conditions réelles les cas d'usage écrits à l'étape précédente. Une catégorie qui s'avère mal cadrée, c'est l'hypercare qui le détecte, et c'est à ce moment-là qu'on ajuste la liste, pas trois mois plus tard.
C'est la combinaison qui produit le résultat. Un sponsor sans business case est un slogan. Un business case sans cas d'usage reste théorique. Des cas d'usage non testés en hypercare deviennent des dogmes faux. L'hypercare sans sponsor manque d'oxygène dès le deuxième site.
Ce que ça a changé pour le client
Six mois après la première vague, le maverick spend sur les catégories tail couvertes était divisé par deux. Un salarié qui voulait une souris ergonomique l'avait sous 48 heures. Un labo qui avait besoin d'un consommable courant le commandait dans la matinée. Les category managers ont arrêté de gérer des tickets à 80 € et sont remontés sur les catégories qui produisent réellement des économies. La finance a récupéré une donnée auditable sur un périmètre opaque depuis des années.
Amazon Business était la techno qui rendait l'expérience possible. Le business case, le sponsor, les cas d'usage et l'hypercare sont ce qui a transformé un contrat signé en programme tail spend qui tient.