Le projet en un coup d’œil
Catalogue, prix, disponibilité, documents et contexte de compte ne formaient pas encore un parcours client unifié.
Dawap a construit un portail multi-compte relié au SI, depuis l’onboarding jusqu’au panier, aux commandes et au support.
Le client voit son assortiment, son prix et la quantité réellement diffusable, tandis que les équipes gardent le contrôle.
Un portail B2B peut être très joli et rester inutilisable. Il suffit que le mauvais prix apparaisse, que la disponibilité soit approximative, qu’un contact puisse consulter le mauvais compte ou qu’une commande quitte le site sans preuve de son import dans l’ERP. Pour 1UP Distribution, le sujet n’était donc pas de refaire une boutique : il fallait transformer une relation commerciale complexe en expérience autonome, sans effacer les règles qui la rendent fiable.
Le défi consistait à faire tenir une chaîne entière derrière une interface compréhensible : reconnaître la société active, résoudre son assortiment, appliquer ses conditions tarifaires, qualifier la quantité réellement engageable, protéger le panier, transmettre l’intention à Odoo puis restituer commandes et documents. Si une seule de ces étapes se désolidarise des autres, l’autonomie promise au client se transforme en charge supplémentaire pour les équipes.
Dawap a traité ce chantier comme une conception de portail client et extranet B2B : partir des droits, des sources de vérité et des tâches à rendre autonomes, puis construire les écrans autour de ces décisions. Cette façade client s’appuie sur des capacités approfondies séparément : flux Odoo, cockpit commercial, cycle de commande et logistique.
Un programme, huit projets complémentaires
Chaque projet part d’une souffrance métier précise et montre la réponse effectivement livrée. La vue d’ensemble relie le portail client, le cockpit commercial, Odoo, la commande, la logistique, l’IA et le socle d’industrialisation.
1. 1UP Distribution et son commerce B2B
Un distributeur dont l’expérience client dépend directement du SI
1UP Distribution opère un catalogue destiné à des clients professionnels. Une même relation peut impliquer plusieurs sociétés, plusieurs contacts, des adresses différentes, des conditions tarifaires propres, une limite de crédit, des produits réservés à certaines distributions et des commandes qui doivent rejoindre Odoo sans ambiguïté.
Ici, “afficher un produit” ne suffit pas. Il faut résoudre une chaîne de questions : ce compte a-t-il le droit de le voir ? À quel prix ? Dans quelle devise ? Quelle quantité peut-on promettre sans consommer le stock déjà engagé ? Cette adresse est-elle autorisée ? La commande est-elle encore modifiable ? Sa facture et son avoir existent-ils dans l’ERP ?
Le portail est donc une application métier à destination des clients. Son interface doit rester simple, mais cette simplicité repose sur une forte profondeur fonctionnelle. C’est précisément le type de produit que couvre notre expertise en application métier sur mesure.
2. Une méthode guidée par les parcours et les invariants
Cadrer chaque écran à partir de la donnée qui l’autorise
Le travail a commencé par les rôles, les comptes, les catégories de prix, les distributions, les statuts de commande et les sources de vérité. Ces éléments ont été traduits en règles vérifiables avant de devenir des écrans. Ce choix évite le piège du prototype séduisant qui ne tient plus lorsqu’il rencontre les cas réels.
Le delivery a avancé par parcours verticaux : inviter un contact, choisir son compte, trouver un produit, comprendre son prix et son stock, préparer un panier, relire l’engagement puis retrouver la commande et ses documents. Chaque lot traversait l’interface, le domaine, la persistance, les intégrations et les tests.
Les sujets ont été suivis dans un backlog Jira vivant, livrés en sprints, démontrés et consolidés dans les environnements prévus avant leur exploitation. La priorité allait aux parcours qui rendaient d’abord le client autonome sans fragiliser les règles commerciales. Les flux asynchrones et les cas d’échec ont été traités en même temps que les parcours heureux : une importation ERP en attente ou échouée devait être visible, compréhensible et récupérable.
3. Les douleurs de départ
Quand le client dépend des équipes pour comprendre ce qu’il peut acheter
Avant un portail unifié, les frictions se déplacent vers les commerciaux et l’administration des ventes. Le client demande un prix, une disponibilité, une facture ou un état de commande. L’équipe recherche le bon compte dans l’ERP, vérifie une règle, reformule la réponse et recommence au prochain besoin. Le coût n’est pas seulement le temps passé : c’est aussi l’incertitude créée par plusieurs versions d’une même information.
La personnalisation B2B ajoute une difficulté absente d’un e-commerce classique. Un catalogue global peut contenir des produits que le compte n’est pas autorisé à commander ; un prix conseillé peut être différent de son tarif contractuel ; une quantité physique peut déjà être réservée ; une adresse peut appartenir à une autre société du groupe. Le portail devait empêcher ces confusions avant qu’elles deviennent une anomalie commerciale.
La troisième douleur concernait la continuité. Un panier confirmé mais pas encore importé dans Odoo ne doit ni disparaître, ni être présenté comme une commande définitive. Une facture doit provenir du bon document ERP. Un contact qui change de société ne doit pas conserver un accès historique par accident. La qualité du portail se mesure donc dans les transitions et les cas limites, pas seulement dans sa page d’accueil.
Le front n’invente jamais une vérité commerciale pour rendre le parcours plus fluide. Il explique l’état disponible et délègue la vérité contractuelle, financière ou documentaire au système qui en est responsable.
Le coût caché d’une réponse reconstruite à la main
Une demande de prix ou de stock paraît anodine tant qu’on la regarde isolément. Répétée sur plusieurs comptes, plusieurs références et plusieurs commandes, elle mobilise les commerciaux sur des tâches de recherche plutôt que sur la relation. Elle augmente aussi le délai de réponse précisément au moment où le client cherche à décider.
Le risque le plus coûteux n’est pas toujours une erreur spectaculaire. C’est la petite divergence crédible : un tarif qui semble juste mais appartient à une autre catégorie, une quantité disponible qui ignore une réservation ou un document rattaché au mauvais périmètre. Ces écarts fragilisent la confiance et obligent ensuite les équipes à prouver ce qui s’est réellement passé.
Pourquoi une boutique standard ne suffisait pas
Le besoin ne se résumait pas à afficher des fiches et encaisser un panier. Le contexte de compte devait gouverner chaque lecture et chaque écriture, depuis la recherche produit jusqu’au téléchargement d’un avoir. Cette portée devait être contrôlée côté serveur, pas seulement conservée dans un filtre ou une session d’interface.
Le produit devait également vivre avec l’ERP sans lui demander de répondre à chaque clic. Il fallait donc concevoir des modèles de lecture rapides, des synchronisations observables et des validations tardives capables de réconcilier confort d’usage et vérité contractuelle.
4. Onboarding, invitations et choix du compte
Donner accès vite, sans ouvrir le mauvais périmètre
Le parcours commence avant la première connexion. Le produit gère l’invitation des contacts, l’initialisation et la réinitialisation du mot de passe, la migration de comptes historiques, la politique de mot de passe et l’acceptation des conditions générales de vente. L’objectif est d’éviter les créations parallèles et de rattacher l’utilisateur à une identité métier déjà connue.
Un contact peut être lié à plusieurs comptes autorisés. Le portail rend ce contexte explicite et conserve la société sélectionnée dans les parcours qui en dépendent. Catalogue, prix, adresses, panier, commandes et documents sont relus avec ce périmètre. Le changement de compte n’est donc pas un simple filtre d’interface : il change la portée métier de l’expérience.
Les cas dégradés sont prévus : invitation expirée, compte sans distribution active, contact sans adresse utilisable, utilisateur hérité à migrer, conditions non acceptées ou compte placé sous contrôle de crédit. Au lieu de laisser l’utilisateur face à une page vide, le produit oriente l’action, bloque ce qui serait dangereux et conserve ce qui peut rester accessible.
Cette approche rejoint les principes détaillés dans notre article sur le self-service utile d’un portail client : automatiser les tâches répétitives, mais garder une issue claire lorsqu’une décision humaine reste nécessaire.
5. Un catalogue réellement personnalisé
Montrer l’offre accessible au compte, pas une vitrine générique
Le catalogue B2B repose sur les distributions actives, les statuts produits, les catégories, les marques, les campagnes et les règles de visibilité. La navigation combine recherche, filtres, tris, sélections, nouveautés et mises en avant sans perdre le contexte du compte. Les rails du tableau de bord sont chargés de manière différée pour protéger le temps d’affichage initial.
La fiche produit rassemble les éléments utiles à une décision professionnelle : variantes, images, conditionnement, informations de stock, disponibilité future, éventuels produits en kit, nouveautés, seuils et contexte tarifaire. Les produits non vendables ne sont pas simplement “cassés” dans le panier ; leur état est expliqué plus tôt dans le parcours.
Les équipes disposent en parallèle d’outils de merchandising et d’administration : activation d’une distribution, pilotage des statuts, filtres de marque et de catégorie, campagnes visuelles, synchronisation des images et contrôle des produits qui suivent le procurement. Le portail peut donc évoluer sans que chaque mise en avant devienne une intervention technique.
Le résultat est un catalogue dont la richesse n’efface pas la règle commerciale. Pour une entreprise confrontée au même sujet, la page intégration PIM et catalogue détaille les enjeux de synchronisation, de qualité et de diffusion que ce projet matérialise.
6. Prix, catégories tarifaires et conditions B2B
Faire du bon prix une donnée métier traçable
Le prix affiché dépend de la catégorie tarifaire associée au compte et des données synchronisées depuis Odoo. Le produit conserve les devises et les références nécessaires pour éviter qu’un prix public ou une conversion implicite ne remplace une condition négociée. Les écrans ne masquent pas une absence de tarif par une valeur approximative.
Les catégories de prix peuvent être rafraîchies, contrôlées et utilisées dans le catalogue, la fiche produit et le panier. Les incohérences — prix absent, source périmée, devise inattendue, catégorie non reliée — sont traitées comme des signaux opérationnels. Cette discipline protège autant la marge de 1UP Distribution que la confiance de son client.
Au moment de la commande, le système conserve les données nécessaires à la preuve de ce qui a été présenté et soumis. La relation entre panier, commande Odoo, facture et avoir empêche qu’une simple évolution de catalogue réécrive l’histoire d’une transaction déjà engagée.
Dawap a ainsi relié le travail de développement d’application connectée à un ERP à une expérience de vente lisible : la complexité reste dans le produit, tandis que le client reçoit une information contextualisée.
7. Une disponibilité que l’entreprise peut réellement promettre
Ne pas confondre stock physique, stock réservé et quantité vendable
Le portail ne se contente pas de recopier une quantité Odoo. Il s’appuie sur une projection de disponibilité B2B qui tient compte des stocks, des mouvements, des réservations actives, des paniers verrouillés, des engagements de livraison et des approvisionnements attendus. Une fraîcheur insuffisante peut empêcher une validation au lieu de laisser passer une promesse fragile.
Cette règle devient particulièrement importante pour les précommandes, les kits et les produits suivis par approvisionnement. Le système peut distinguer une disponibilité immédiate, une quantité future et un potentiel dépendant d’une arrivée fournisseur. Il protège aussi les engagements existants : vendre le même stock deux fois n’est pas une erreur d’affichage, c’est un incident commercial.
Les paniers actifs réservent temporairement la capacité nécessaire. Une mutation libère ou recalcule ces réservations ; une expiration les restitue ; une confirmation les conserve jusqu’à l’issue de l’intégration. Le catalogue et la fiche produit relisent cet état pour que deux parcours concurrents ne partent pas d’une photographie devenue fausse.
Le modèle complet est approfondi dans le projet achats, stock disponible et préparation des livraisons. Ici, l’enjeu est l’effet côté client : une promesse compréhensible et défendable.
8. Panier, relecture et soumission de la commande
Transformer une sélection en engagement contrôlé
Le panier gère l’ajout, la modification, la suppression, le remplacement complet et la reprise d’un panier existant. Il ne devient commandable qu’après une relecture de la disponibilité, du compte, des adresses, des lignes et de leur distribution. Les erreurs sont rattachées aux lignes concernées afin que le client puisse corriger au lieu de recommencer.
Avant l’import Odoo, une vue de synthèse présente la composition, les zones éventuelles, les quantités et les réservations. La soumission utilise une identité déterministe et des protections d’idempotence pour éviter qu’un double clic ou une reprise réseau ne crée plusieurs engagements.
L’état d’intégration reste visible : prêt, en vérification, en cours d’import, partiellement importé, confirmé ou échoué. Lorsque le panier doit être scindé selon des règles de distribution ou de stock, cette progression est explicitée. Le client n’est pas abandonné entre l’interface et l’ERP.
Ce choix illustre un principe plus large du développement d’automatisation de processus métier : automatiser l’exécution tout en conservant des états, des preuves et des chemins de reprise.
Identité, société, adresses et distribution autorisée.
Catalogue, tarif, devise et disponibilité contextualisés.
Lignes relues et capacité réservée temporairement.
Soumission idempotente, progression et reprise par zone.
Commande confirmée, documents et statuts synchronisés.
9. Commandes, factures, avoirs et suivi
Donner au client une mémoire fiable de sa relation commerciale
Une fois la commande créée, le portail expose l’historique autorisé du compte, le détail des lignes, les références, les statuts et les informations de livraison disponibles. Les libellés évitent de confondre un panier local, une commande importée et une expédition réellement avancée dans le SI.
Les factures et avoirs proviennent des flux Odoo. Les documents PDF sont servis à partir des pièces stockées et contrôlées, sans reconstruire une facture dans le front. Les règlements et allocations disponibles peuvent compléter la lecture financière, avec une portée limitée au compte courant.
Le client peut également retrouver des informations de suivi et, lorsque le périmètre l’autorise, demander l’annulation d’une commande. Les règles refusent une action trop tardive ou non autorisée plutôt que de produire une demande que les équipes ne pourraient pas honorer.
Pour approfondir la logique de preuve entre étapes, l’article rapprocher bon de commande, devis et facture complète ce retour d’expérience sans remplacer la preuve du projet.
10. Centre d’aide et support contextualisé
Réduire les demandes répétitives sans fermer la porte à l’humain
Le portail regroupe le centre d’aide et les tickets dans le même environnement que le compte. Le client peut retrouver les réponses disponibles, formuler une demande et conserver le contexte utile. L’objectif n’est pas de cacher le support derrière une FAQ, mais d’éviter que chaque échange commence par rechercher la société et la commande concernées.
Cette proximité avec le parcours transactionnel rend l’assistance plus précise. Une demande peut être reliée à un compte, à un document ou à un problème observé après connexion. Les équipes disposent alors d’éléments plus structurés, et le client comprend mieux où en est sa sollicitation.
Le produit prépare aussi la coexistence avec l’assistant de support documenté dans le projet IA. Celui-ci peut aider à orienter vers une connaissance ou une donnée autorisée, mais il ne remplace pas un workflow de ticket, une décision commerciale ou une action sensible.
Le portail garde ainsi une règle simple : le self-service prend en charge ce qui est fiable et répétable ; la relation humaine reste disponible dès que le cas sort du cadre.
11. Rôles, périmètres et sécurité des comptes
La bonne interface ne vaut rien si elle expose le mauvais client
Les autorisations sont vérifiées côté serveur à partir de l’identité, des rôles, du compte sélectionné et de la ressource demandée. Les identifiants présents dans une URL ou un payload ne suffisent jamais à ouvrir une commande, une facture, un panier ou une adresse. Des tests ciblent explicitement les risques d’accès horizontal entre comptes.
Les actions d’écriture sont protégées par CSRF dans l’interface, par des contrats et des scopes dans les APIs, et par des confirmations lorsque l’impact le justifie. La MFA, les politiques de mot de passe, la journalisation et les limites de débit renforcent la défense sans transformer chaque consultation en parcours pénible.
L’impersonation administrative est encadrée pour le support et le diagnostic. Elle ne doit pas contourner silencieusement les règles d’onboarding ou laisser croire qu’une action humaine a été réalisée par le client. Les traces et le périmètre restent essentiels dans un outil contenant des données commerciales.
Cette dimension ne se voit pas toujours dans une maquette, mais elle différencie un portail de démonstration d’un produit exploitable. Elle rejoint notre offre d’authentification et sécurité des intégrations.
12. Architecture du portail
Séparer l’expérience client des flux et règles qui la soutiennent
L’application repose sur Symfony 8, PHP 8.4, MySQL, Redis, RabbitMQ, Docker et Nginx. Le code distingue les contextes de catalogue, CRM, panier, ventes, disponibilité, documents, sécurité et intégration. Cette séparation aide à faire évoluer un parcours sans déplacer involontairement une règle critique dans un autre.
Les lectures utiles au client sont optimisées pour l’interface, tandis que les écritures passent par des cas d’usage métier. Les synchronisations et traitements lourds utilisent des messages, des workers, des retries et des mécanismes de reprise. L’utilisateur obtient un état rapide ; le système conserve la possibilité de finir ou rejouer proprement le travail.
Le portail client cohabite avec un espace commercial et un back-office d’administration, sans fusionner leurs permissions. Il expose aussi une API client pour certains usages de catalogue, prix, stock, commandes, factures, avoirs et paniers. Dans le périmètre vérifié, cette API ne propose pas de raccourci générique “panier vers commande” : la soumission sensible reste cadrée par les parcours prévus.
Cette franchise est importante. Une étude de cas crédible décrit ce qui existe et les frontières actuelles. Elle ne transforme pas un catalogue d’endpoints en promesse de capacité qui n’a pas été livrée.
13. Tests, déploiement et exploitation
Protéger le parcours jusque dans les cas qui arrivent rarement
Les parcours sont couverts à plusieurs niveaux : règles de domaine, services applicatifs, dépôts, contrôleurs, contrats API, sécurité, templates et scénarios d’intégration. Les cas testés incluent les comptes hors périmètre, les snapshots périmés, les réservations expirées, les imports partiels, les pièces absentes et les doubles soumissions.
La CI exécute les contrôles par shards, vérifie l’architecture et les contrats, construit les images puis prépare le déploiement. Les environnements Docker rendent les services dépendants — base, cache, files et serveur web — plus proches de la production que ne le ferait une simple exécution PHP locale.
L’exploitation dispose de logs, de métriques d’activité, d’états de synchronisation et de commandes de reprise. Lorsqu’un flux externe devient indisponible, le but n’est pas de masquer l’erreur derrière un succès local, mais de la rendre visible et récupérable.
Le socle qualité global du programme atteint une couverture PCOV stricte de 100 %. Le détail des preuves, de la maintenabilité, de la sécurité et des limites encore suivies est volontairement isolé dans le projet industrialisation de la plateforme B2B.
14. Résultats obtenus et limites assumées
Une expérience plus autonome, sans promesse commerciale artificielle
Le résultat principal est un parcours client cohérent. Le compte, l’assortiment, le prix, la disponibilité, le panier, la commande et les documents ne sont plus des réponses séparées : ils forment une continuité lisible. Le client gagne en autonomie sur les tâches répétitives et conserve un point de contact lorsqu’une décision sort du cadre.
Pour 1UP Distribution, le portail réduit le besoin de reconstruire manuellement le contexte avant chaque réponse. Il donne aussi des états plus explicites sur les imports et les engagements, ce qui aide les équipes à intervenir au bon endroit au lieu de corriger des symptômes dans plusieurs outils.
La limite volontaire concerne la mesure business publique. Aucun taux de conversion, volume de commandes ou gain de temps non validé par le client n’est avancé. Les preuves publiables portent sur le périmètre livré, les règles intégrées, les tests et les mécanismes d’exploitation.
Ce projet constitue la façade client du programme. Pour comprendre comment les commerciaux utilisent la même donnée, poursuivez avec le cockpit commercial et le pilotage des comptes B2B.
Ce qui change réellement pour le client
Le client n’a plus besoin de connaître l’organisation interne de 1UP Distribution pour avancer. Il part de son compte, voit une offre qui lui appartient, comprend ce qui peut être engagé et retrouve les preuves de la relation au même endroit. Cette continuité réduit les ruptures de contexte et rend le self-service crédible.
L’autonomie ne signifie pas que toutes les exceptions deviennent automatiques. Lorsqu’un contrôle de crédit, une incohérence de prix ou une situation logistique exige une décision, le portail bloque clairement l’étape concernée et donne aux équipes le contexte nécessaire pour intervenir.
Ce qui change pour les équipes 1UP
Les commerciaux et l’administration des ventes peuvent consacrer moins d’énergie à reconstruire une information déjà disponible. Les demandes restantes sont mieux qualifiées, car elles arrivent avec un compte, un objet et un état identifiés.
Le produit rend également les anomalies plus actionnables. Une synchronisation en attente, une catégorie tarifaire absente ou une réservation expirée possède un emplacement et un chemin de reprise. L’équipe ne dépend plus uniquement d’une investigation technique déclenchée après une plainte client.
15. Conclusion : rendre le B2B simple sans le simplifier à tort
Une expérience client soutenue par de vraies règles métier
Ce portail montre le type de travail que Dawap cherche à rendre visible : une interface claire n’est que la partie émergée. Sous le catalogue se trouvent les droits, les prix, la disponibilité, les réservations, les flux ERP, les documents et les reprises qui rendent l’expérience fiable.
Le projet parle aux distributeurs dont les clients réclament plus d’autonomie, mais dont le commerce ne peut pas être réduit à un prix unique et un stock brut. C’est dans cet espace entre simplicité d’usage et complexité métier qu’un développement sur mesure crée le plus de valeur.
Pour cadrer un sujet comparable, notre page portail client et extranet B2B présente le point d’entrée commercial. Cette étude de cas reste la preuve de ce que cette approche devient une fois livrée.
