Exemple de situation : portail B2B de distribution de boissons pour les circuits CHR et GMS
Cet exemple de situation illustre une mission représentative de la distribution de boissons en CHR et GMS, sans projet réel nommé : portail B2B complet avec commandes en ligne, IoT sur les équipements de froid et agents IA pour le terrain.
Durée
Environ un an et demi en trois temps (discovery et architecture, développement et MVP, puis agents IA, IoT et analytics), à ajuster selon le périmètre réel.
Équipe
Équipe dimensionnée selon le projet
Technologies clés
Commandes en ligne
Part des commandes CHR et GMS passées via le portail, suivie depuis le lancement
Litiges équipements
Litiges sur équipements de froid non résolus dans les délais, relevés avant et après
Formation
Taux de complétion de la formation merchandising par les gérants de points de vente
Agents IA
Part des demandes résolues dès le premier contact par les agents IA
#Contexte — exemple de situation
Ce cas est un exemple de situation, construit pour illustrer une mission représentative du secteur. Il ne décrit pas un projet mené pour une entreprise réelle nommée.
Au total, un ordre de grandeur de 35 000 PDV clients actifs sur le territoire national.
#Le défi
Quatre complexités reviennent systématiquement sur ce type de projet de portail B2B.
Gestion du parc d'équipements de froid. Plusieurs dizaines de milliers d'unités déployées, souvent sans système de traçabilité centralisé opérationnel au départ. Les données existent en silos : CRM (données contractuelles), tableurs agents terrain (maintenance), ERP (données comptables). Aucun système ne sait en temps réel quels équipements sont chez quels clients, dans quel état.
Intégration des agents commerciaux terrain. Plusieurs centaines d'agents dont le quotidien va être modifié en profondeur. Le portail doit être conçu aussi pour l'agent commercial : suivi de portefeuille PDV, alertes merchandising, tableau de bord de performance.
Intégration SI existant. CRM, ERP, système SAV parfois hérité d'une acquisition, outil e-learning tiers, APIs partenaires logistiques. Le portail doit être le point d'entrée unifié consommant et alimentant tous ces systèmes.
#Notre solution type
Mission en trois phases sur 18 mois, avec un go-live intermédiaire à 9 mois.
#Phase 1 — Discovery et architecture (mois 1-3)
Ateliers avec la direction digitale, la DSI, une dizaine d'agents commerciaux terrain et une quinzaine de gérants de PDV.
Architecture cible : PWA React + backend Node.js/TypeScript sur AWS, PostgreSQL + Redis, intégration CRM via API REST bidirectionnelle, middleware event-driven Apache Kafka pour l'ERP, couche IoT AWS IoT Core, analytics Metabase + datalake S3.
#Phase 2 — Développement et déploiement MVP (mois 4-9)
Quatre modules principaux :
- Module commandes en ligne : catalogue personnalisé par PDV, panier avec suggestions basées sur l'historique, suivi de livraison temps réel, gestion bons de commande GMS multi-niveaux
- Module équipements de froid : tableau de bord par PDV, déclaration de panne en 3 clics, suivi intervention SAV, historique par appareil
- Module formation merchandising : modules e-learning courts (5-12 min), quiz de validation, badge de certification, tableau de bord formation agents
- Module analytics PDV : indicateurs par PDV pour les agents terrain (fréquence commande, panier moyen, taux d'équipement, alertes retard)
#Phase 3 — Agents IA et IoT (mois 10-18)
Trois agents IA développés avec Claude (Anthropic) :
- Agent support commandes : questions courantes PDV (statut livraison, disponibilité produit, tarifs).
- Agent coach merchandising : recommandations personnalisées d'optimisation de rayon basées sur les données de vente du PDV
Agents déployés dans le portail et sur un canal de messagerie mobile type WhatsApp Business API -- un choix fréquent une fois qu'une étude terrain confirme qu'une majorité de gérants de petits établissements communiquent déjà avec leur agent commercial via ce canal.
#Stack technique
- PWA React + TypeScript — frontend portail client et agent terrain
- Node.js / Express / TypeScript — backend API REST
- PostgreSQL + Redis — base de données et cache
- AWS (EC2, RDS, S3, CloudFront, IoT Core, SNS/SQS) — infrastructure cloud
- Apache Kafka — middleware event-driven pour ERP et CRM
- Claude (Anthropic) — moteur agents IA
- WhatsApp Business API — canal agent IA alternatif
- AWS IoT Core + MQTT — télémétrie équipements de froid
- Metabase + AWS S3 — analytics et tableaux de bord
- Figma + Design System Nehos B2B — conception UX
#Équipe type
- Un consultant lead / product owner — pilotage de la relation client et des priorités
- Un architecte technique — architecture cible, intégrations SI, couche IA et IoT
- Un·e lead développeur·se frontend — PWA, design system B2B
- Un·e développeur·se backend & intégrations — API, middleware, connecteurs CRM/ERP
- Un·e ingénieur·e data & analytics — datalake, dashboards
- Un·e UX designer senior — ateliers utilisateurs, tests terrain
- Un·e responsable gestion du changement — protocole d'embarquement des agents pilotes
- Un·e ingénieur·e IoT — déploiement capteurs et alertes SAV proactif
#Services Nehos associés
- Portail B2B & self-service client digital
- Agents IA support et service client
- Analytics & data — tableaux de bord métier
- IoT & objets connectés — traçabilité actifs terrain
- Conseil & stratégie digitale ROI-First
Questions & réponses
Questions fréquentes sur cet exemple de situation
Deux leviers reviennent systématiquement sur ce type de mission. Le premier est la discipline de priorisation : on retient un MVP resserré à partir du backlog de fonctionnalités et on repousse le reste en phase 2, ce qui évite le syndrome du périmètre extensible qui double les délais. Le second est l'architecture technique PWA et middleware événementiel : plutôt que d'attendre une refonte du système d'information existant (CRM, ERP), le portail consomme et alimente les systèmes en place par une couche d'intégration asynchrone, sans que l'entreprise ait à les modifier.
Sur ce type de mission, la décision vient généralement des ateliers terrain en phase 1. L'étude des habitudes de communication des gérants de PDV CHR révèle fréquemment qu'une majorité d'entre eux communiquent déjà avec leur agent commercial via une messagerie mobile grand public — pour signaler une panne, demander le statut d'une livraison ou commander en urgence. Déployer les agents IA uniquement dans le portail contraindrait ces gérants à changer leurs habitudes. Le déploiement sur un canal type WhatsApp Business API offre une continuité : le gérant envoie un message comme il le ferait avec son agent terrain, et l'agent IA répond avec les mêmes informations que le portail.
Nehos recommande une approche IoT-to-action en trois étapes. Étape 1 : choisir un périmètre pilote restreint (quelques types d'équipements et une zone géographique) et définir l'action métier attendue pour chaque alerte. Étape 2 : déployer les capteurs de température et de connectivité sur ce périmètre pilote. Étape 3 : relier les alertes au portail et aux équipes d'intervention, mesurer leur utilité, puis étendre par vagues seulement si le pilote le justifie.
Le protocole type se déroule en quatre temps. Recrutement d'un groupe pilote d'agents volontaires représentant toutes les régions et tous les profils de portefeuille, en incluant des profils sceptiques et pas seulement des early adopters. Ces agents pilotes participent à plusieurs rounds de tests utilisateurs UX, dont les retours modifient directement l'interface. Ils sont formés avant le lancement national et reçoivent un rôle d'ambassadeur avec un kit de présentation. Au lancement, ces ambassadeurs animent des sessions régionales pour leurs collègues, Nehos formant les formateurs. Ce protocole, documenté dans le playbook de gestion du changement Nehos, est généralement le facteur principal d'un taux d'adoption élevé des agents terrain.
Les deux canaux ont des logiques de commande structurellement différentes, ce qui impose une architecture par rôles et contextes d'usage fine. Côté CHR, les PDV sont majoritairement des indépendants, avec des commandes fréquentes, des volumes variables, et une forte sensibilité à la réactivité du support — l'expérience y est mobile-first, avec commande rapide et déclaration de panne en 3 clics. Côté GMS, les PDV fonctionnent avec des approvisionnements planifiés, des commandes à cycles définis, et des validations multi-niveaux (responsable rayon, directeur de magasin, centrale d'achat) — l'expérience y intègre des workflows de validation et l'import/export en masse. Les deux expériences sont servies par la même infrastructure backend et le même catalogue produit centralisé.
Le budget se chiffre sur devis, en 48 h après un premier échange. Une journée d'audit IA express (990 € HT, déduit du projet s'il est lancé dans les trois mois) permet de cadrer le périmètre avant tout engagement.
L'architecture technique peut être conçue dès la phase 1 avec l'internationalisation comme contrainte non fonctionnelle : multi-tenant (chaque filiale dispose de son espace isolé), multi-langues, multi-devises, et intégrations SI configurables par tenant. Ce choix d'architecture a un coût initial légèrement plus élevé, mais ouvre la trajectoire d'extension sans refonte majeure si l'entreprise décide un jour de dupliquer le portail sur d'autres marchés. C'est un point à trancher dès le cadrage, en fonction de la feuille de route internationale de l'entreprise cliente.