1UP Distribution : transformer le commerce B2B autour d’Odoo

1. De la passerelle Odoo au produit B2B complet

Une histoire construite par étapes entre 2020 et 2026

En 2020, le premier outil dédié à 1UP gérait déjà les échanges Odoo autour des produits, des listes de prix, des clients, des commandes et des entrepôts. Il donnait aussi aux équipes des vues de contrôle sur les commandes en attente. Cette base a prouvé la valeur de l’automatisation, mais elle restait centrée sur la circulation des objets.

À partir de 2024, une nouvelle plateforme B2B a déplacé le centre de gravité vers les usages. Le catalogue et la recherche se sont enrichis, les comptes ont reçu leurs tarifs et leur périmètre, puis les commandes et documents ont été reconstruits autour d’identités partagées avec Odoo.

En 2025, un hub logistique spécialisé a relié Odoo, ShippingBo et les canaux de vente pour suivre commandes, préparations, expéditions et factures. Ce travail a renforcé la connaissance des transitions entre vente et livraison, ensuite réinvestie dans la plateforme principale.

En 2026, le produit réunit quatre espaces métier, vingt-six flux reliés à Odoo, deux familles d’API et douze assistants spécialisés. L’histoire continue encore : les commentaires de commandes et de devis Odoo, la préparation logistique et l’aide à la décision évoluent dans le même socle.

2. Faire évoluer un parcours complet à chaque étape

Relier l’écran, la règle métier, Odoo et l’exploitation

Dawap a organisé le produit par domaines et par parcours de bout en bout. Une évolution part d’un usage concret, traverse la règle métier, les données, l’intégration, l’interface et la mise en ligne. Cette continuité évite que l’écran et l’ERP finissent par donner deux réponses plausibles mais différentes.

Les lots ont été ordonnés selon leurs dépendances. Pour rendre une commande réellement exploitable, il fallait d’abord résoudre le compte, l’offre, le tarif et la disponibilité, puis protéger l’envoi vers Odoo et le suivi de son résultat. Pour préparer une livraison, il fallait rapprocher commandes, stock, arrivages, allocations et décisions logistiques.

Chaque étape conserve le fonctionnement utile de la précédente. Les comportements sensibles reçoivent des contrôles, des états explicites et un chemin de reprise avant d’être étendus à un autre espace ou à une autre API. La transformation avance ainsi sans opposer nouveau produit et continuité des opérations.

3. Le point de départ : automatiser sans encore unifier

Des échanges Odoo utiles, mais pas encore un produit commun aux équipes

La première application savait lire et écrire des objets Odoo, contrôler les tarifs et suivre les commandes qui n’avaient pas encore rejoint le système attendu. Elle répondait à une douleur concrète : éviter que chaque échange avec l’ERP repose sur une manipulation isolée.

Mais l’activité demandait progressivement davantage qu’un outil de synchronisation. Les clients voulaient retrouver leur offre et leurs documents ; les commerciaux avaient besoin d’une lecture complète du compte ; l’administration devait comprendre les référentiels et les flux ; la logistique devait préparer le travail à partir des engagements réels.

Le même concept traversait plusieurs contextes. Un produit pouvait être actif dans Odoo sans être vendable pour un compte. Une commande pouvait exister localement sans être encore confirmée par l’ERP. Un stock physique ne disait pas à lui seul ce qui pouvait être promis.

La transformation a donc conservé les sources utiles tout en déplaçant les décisions vers un domaine partagé. Le but n’était plus seulement de transporter des données, mais de rendre chaque étape compréhensible et actionnable par le bon profil.

4. Une vision : quatre usages autour d’un même domaine

Relier l’expérience client, la vente, l’administration et la logistique

Odoo reste la source des objets contractuels et financiers. La plateforme construit les expériences, les états de traitement, les projections et les outils de décision dont les équipes ont besoin. Les API et les messages relient ces responsabilités avec des identités stables.

Le produit est structuré autour du CRM, du catalogue, du panier, des ventes, des achats, du stock, de la livraison, de la finance, de l’identité et de l’intelligence artificielle. Chaque domaine porte ses règles ; les écrans et les connecteurs viennent les utiliser sans les réinventer.

Cette architecture permet de faire évoluer un canal sans recopier le métier. Le portail client, le cockpit commercial, l’administration et la préparation logistique présentent des niveaux de détail différents, mais s’appuient sur les mêmes décisions de prix, de disponibilité et de périmètre.

La transformation correspond à une application métier sur mesure à plusieurs visages, connectée au SI et conçue pour rester exploitable.

5. Quatre espaces métier, quatre niveaux de responsabilité

Donner à chacun la bonne profondeur sans élargir ses droits

L’espace client réunit le compte, le catalogue, les tarifs, le panier, les commandes, les expéditions, les documents et l’assistance. Il rend le client autonome dans le périmètre exact de sa société.

L’espace commercial rapproche portefeuille, contacts, catalogue, devis, commandes, livraisons, factures, avoirs et indicateurs. Il relie la conversation avec le client aux engagements réellement enregistrés.

L’administration pilote les référentiels, les synchronisations, les achats, les ventes, la qualité des données, les assistants et les reprises. Elle expose le niveau de détail nécessaire pour comprendre une anomalie et agir.

L’espace logistique transforme les commandes et les stocks en travail de préparation. Ces quatre espaces partagent les mêmes identités, mais leurs parcours et leurs droits restent distincts : une interface plus riche ne devient jamais un droit implicite.

6. Le portail client B2B

Catalogue, prix et autonomie dans le contexte du compte

Le portail gère les invitations, l’activation du compte, les mots de passe, les CGV et le contexte multi-société. L’utilisateur choisit la société autorisée ; l’assortiment, le prix, les adresses, le panier, les commandes et les documents suivent ce périmètre.

Le catalogue combine distributions, catégories, marques, campagnes, nouveautés, variantes, images et fiches produit. Les prix proviennent des catégories tarifaires Odoo et les devises restent explicites. La disponibilité projetée protège les engagements existants.

Le client prépare un panier, relit les lignes et adresses, suit l’import, puis retrouve commandes, factures, avoirs, expéditions et assistance. Les états intermédiaires expliquent les traitements asynchrones.

L’étude de cas portail client, catalogue et tarifs personnalisés détaille cette expérience et les douleurs qu’elle résout.

7. Le cockpit commercial

Décider depuis le portefeuille, l’activité et les engagements

Le cockpit commercial transforme les objets du SI en poste de travail. Un compte réunit ses contacts, adresses, activité, commandes, livraisons, factures, avoirs et contraintes. Les commerciaux internes et externes travaillent dans leur portefeuille autorisé.

La prise de commande réutilise le catalogue et les règles transactionnelles. Les devis et commandes sont séparés, les étapes de livraison disposent d’une chronologie et les documents financiers prolongent la lecture après la vente. Les commentaires saisis dans Odoo restent visibles dans ce suivi.

Les radars de clients à sauver, les classements et les analyses multi-périodes priorisent les comptes à examiner. Chaque indicateur garde un chemin vers son origine et ne se présente pas comme une causalité automatique.

Le projet cockpit commercial et pilotage des comptes B2B montre comment cette densité devient une navigation et une liste d’actions.

8. La super-administration métier

Piloter les référentiels, la qualité et l’exploitation

L’administration couvre les clients, contacts, utilisateurs, identités, distributions, produits, catégories, marques, étiquettes, prix, stock, kits, précommandes, fournisseurs, achats, ventes, documents, assistants et supervision. Les menus sont organisés par grandes responsabilités métier.

Les équipes peuvent actualiser des objets depuis Odoo, contrôler les correspondances, suivre les exports, lancer des reconstructions et consulter l’origine d’un calcul de stock. Les opérations sensibles sont protégées par rôle, confirmation ou authentification renforcée selon leur impact.

Les vues exposent les incohérences, les dates, les sources et les chemins de correction. L’équipe peut comprendre si le problème vient du catalogue, d’un flux, d’une projection ou d’une donnée métier avant de modifier quoi que ce soit.

Les files, activités API et synchronisations disposent enfin de vues de suivi. L’administration ne sert donc pas seulement à configurer : elle donne les moyens d’exploiter et de reprendre le produit.

9. Odoo, vingt-six flux et deux familles d’API

Le système circulatoire de la plateforme

Le catalogue d’intégration compte vingt-six flux reliés à Odoo autour du CRM, du catalogue, des prix, des ventes, des achats, des expéditions, des factures, des avoirs, des paiements et des suppressions. Ils sont séparés par domaine, fréquence et risque plutôt que regroupés dans un import unique.

Les traitements longs passent par des files dédiées. Les identités externes, les fenêtres de date, les devises et les canaux sont conservés. Une reprise contrôlée peut ainsi cibler le flux et la période utiles sans dupliquer une commande ni mélanger le B2B et le B2C.

Deux familles d’API servent les parcours client et commercial externe. Leurs droits, leurs erreurs et leurs contrats sont suivis séparément du stockage interne. Une évolution de la base ne change donc pas silencieusement ce qui a été promis aux applications connectées.

Le projet intégration Odoo et automatisation des flux B2B approfondit cette circulation. Notre offre d’intégration API Odoo en constitue le point d’entrée pour un besoin centré sur l’ERP.

10. Catalogue, merchandising, prix et disponibilité

Transformer les référentiels en offre réellement vendable

La plateforme ne publie pas un export brut de produits. Elle résout les distributions actives, statuts, catégories, marques, variantes, images, campagnes, nouveautés, kits et précommandes. Les équipes peuvent piloter la visibilité et comprendre les exclusions.

Les catégories de prix Odoo donnent le tarif du compte. Les devises et relations de prix sont contrôlées ; une source absente ou périmée ne devient pas un prix par défaut silencieux. Le panier conserve le contexte nécessaire à la preuve.

La disponibilité rapproche les stocks, mouvements, expéditions, réservations et approvisionnements. Le client voit une synthèse ; le commercial et l’administration peuvent descendre jusqu’aux mouvements, aux instantanés de calcul et aux allocations.

L’offre affichée devient ainsi une décision expliquée : un produit visible, au tarif du compte, dans la bonne devise et avec une quantité que l’entreprise peut réellement engager.

11. Le cycle de commande B2B

Du panier modifiable à l’objet Odoo confirmé

Le panier valide le compte, la distribution, les variantes et les quantités. La relecture contrôle les adresses, prix, disponibilité et fraîcheur. Des réservations temporaires protègent la capacité pendant l’engagement.

Le plan peut découper les lignes en zones d’import. La soumission porte une identité stable, suit la progression et distingue demande reçue, import en cours, partie confirmée, échec et commande Odoo synchronisée.

Les mutations sont bloquées au bon moment ; les réservations expirent ou se libèrent selon le résultat ; les annulations passent par leurs propres règles. Le client et le commercial retrouvent ensuite la même commande adaptée à leur interface.

Le projet cycle de commande, du panier à la facture expose la machine à états, les cas limites et les preuves transactionnelles.

12. Factures, avoirs, paiements et documents

Prolonger la vente jusqu’à la preuve comptable

Les factures et avoirs synchronisés conservent leurs lignes, devises, canaux et identités Odoo. Les factures non postées ne sont pas publiées au client comme définitives. Les avoirs restent typés plutôt que noyés dans une table générique.

Les PDF stockés depuis Odoo sont réutilisés pour garantir la conformité du document. Les écritures et allocations de paiement sont protégées par des invariants sur le document, la devise et les montants.

Le cockpit commercial utilise ces données pour comprendre le règlement et le risque. Le portail donne au client ses documents dans le bon périmètre. Les API servent les mêmes lectures à leurs consommateurs autorisés.

Ce domaine prouve que la transformation ne s’arrête pas au taux de clic ou au panier. Elle relie la promesse commerciale à la preuve financière et au service après la vente.

13. Achats, fournisseurs et disponibilité projetée

Faire entrer l’amont dans la promesse client

Les fournisseurs, commandes d’achat, lignes et réceptions Odoo alimentent la vision de l’amont. Les dates et quantités attendues contribuent à la disponibilité future sans être confondues avec un stock déjà reçu.

Le moteur conserve les événements, les instantanés de calcul et les allocations. L’ancienneté protège les demandes les plus anciennes ; les réservations de panier réduisent la capacité ; les annulations et corrections de réception déclenchent une réconciliation.

Les kits utilisent la capacité de leurs composants. Les précommandes suivent leur date de première vente et leur activation. Les exceptions de suivi d’approvisionnement restent pilotées et historisées.

L’équipe dispose ainsi d’une disponibilité projetée qui distingue clairement le stock présent, ce qui est déjà promis et ce qui doit encore arriver d’un fournisseur.

14. Préparation des livraisons

Une feuille de charge qui explique ses décisions

La préparation hebdomadaire organise les commandes, expéditions, capacités, arrivages, montants et tensions. Les vues séparent les canaux, regroupent les destinations et calculent les règles de franco. Les destinations non qualifiées disposent d’un diagnostic.

Les propositions de réservation et réallocation sont reliées aux lignes exactes. Avant une action, le produit montre les bénéficiaires et les victimes potentielles. Les écritures Odoo à impact restent confirmées par un humain.

Les expéditions préparées conservent un historique. Le suivi transporteur peut être actualisé dans le cadre prévu. Les chronologies alimentent les clients et les commerciaux sans leur exposer tout le poste de travail opérationnel.

L’étude de cas achats, stock disponible et préparation des livraisons détaille cette chaîne et les décisions qui restent volontairement validées par un humain.

15. Douze assistants métier à partir d’un premier socle de six

Accélérer l’accès aux données sans créer une nouvelle source de vérité

Le premier socle réunissait six assistants. Il s’est depuis étendu à douze rôles spécialisés : orientation générale, requêtes de données, tableaux de bord, connaissance interne, qualification d’entreprise, support client, opportunités commerciales, catalogue produit, contrôle produit, approvisionnements, allocation de stock et prix.

Chaque assistant reçoit un périmètre fonctionnel et des sources autorisées. Les requêtes de données restent en lecture seule ; les connaissances internes sont cloisonnées ; un profil commercial et un administrateur ne consultent pas automatiquement les mêmes contenus.

Les assistants préparent une lecture, une analyse ou une proposition. Les actions sensibles repassent par les parcours métier habituels et leur confirmation. Si un service d’intelligence artificielle devient indisponible, le catalogue, les commandes et la logistique continuent de fonctionner.

L’étude de cas sur le premier socle d’assistants connectés aux données métier montre comment cette capacité a été introduite avant son extension.

16. Sécurité, identité et gouvernance des actions

Protéger les comptes, les périmètres et les écritures

Les rôles distinguent les clients, les commerciaux, l’administration et la logistique. Chaque ressource vérifie aussi le compte ou le portefeuille autorisé côté serveur : modifier un identifiant dans l’adresse ne suffit pas à ouvrir les données d’un autre client.

Les formulaires et actions sensibles ajoutent confirmation, protection contre les requêtes détournées, authentification multifacteur ou limitation de fréquence selon le risque. L’accompagnement d’un utilisateur par un administrateur reste lui aussi encadré et traçable.

Les journaux conservent ce qui aide à comprendre une action sans recopier les secrets ni les contenus sensibles. Les dépendances et les images livrées sont contrôlées, tandis que les secrets restent fournis séparément dans chaque environnement.

Cette sécurité est intégrée au parcours. Elle protège aussi bien le document consulté par un client que la reprise d’un flux, l’accès à un assistant ou une décision logistique à fort impact.

17. Architecture, contrôles et continuité de service

Le socle qui permet à tout le reste de continuer à évoluer

Le socle Symfony, MySQL, Redis, RabbitMQ, Docker et Nginx est organisé par domaines et interfaces. Les règles de compte, de commande, de stock ou d’autorisation peuvent ainsi être vérifiées sans dépendre de tous les systèmes à la fois.

Les contrôles couvrent les calculs métier, les échanges avec Odoo, les messages asynchrones, les API et les parcours des quatre espaces. Une anomalie corrigée laisse un scénario qui protège le comportement au lot suivant.

Les mises en production passent par trois environnements séparés. Une passerelle de maintenance, des sessions persistantes, des vérifications avant réouverture et une reprise bornée des flux protègent les utilisateurs pendant le changement de version.

Le projet industrialiser la plateforme sans interrompre les opérations détaille ce socle. Ici, sa valeur tient à ce qu’il sécurise toute la transformation, du catalogue à la livraison.

18. Une chaîne de valeur continue, de l’offre à l’exploitation

Comprendre comment les capacités se renforcent au lieu de s’empiler

Le catalogue ne crée de valeur que si l’offre, le prix et la disponibilité sont résolus pour le bon compte. Cette promesse doit ensuite survivre au panier, à la réservation, à l’import Odoo, à l’expédition et au document financier. Chaque maillon dépend du précédent, mais conserve son propre état et sa propre preuve.

Le cockpit commercial traverse cette chaîne dans le sens de la relation : comprendre le compte, préparer une vente, suivre l’engagement et intervenir lorsqu’un signal se dégrade. L’administration la traverse dans le sens de l’exploitation : maintenir les référentiels, diagnostiquer les flux, reconstruire une projection et confirmer les actions à risque.

Les assistants ajoutent un accès guidé à cette complexité. Ils orientent, interrogent ou contextualisent, puis retournent vers les objets et les parcours déterministes. L’industrialisation protège enfin l’ensemble par les contrats, les contrôles, les droits, les files, les déploiements et les procédures de reprise.

Cette continuité explique pourquoi le projet ne peut pas être résumé à un site connecté à Odoo. La valeur vient de la capacité à faire circuler une intention commerciale jusqu’à son exécution, puis à rendre chaque transition observable et récupérable.

19. Ce que la transformation change pour 1UP Distribution

Une continuité plus lisible pour les clients comme pour les équipes

Le premier gain est la continuité. Un compte, un produit, un prix, une commande et une livraison ne vivent plus comme cinq sujets séparés. Chaque espace donne la lecture utile à son utilisateur tout en conservant les identités qui permettent de suivre le parcours complet.

Le deuxième gain est l’autonomie. Le client retrouve son offre et ses documents ; le commercial pilote son portefeuille ; l’administration comprend et reprend les flux ; la logistique prépare les commandes ; les assistants accélèrent l’accès à l’information.

Le troisième gain est la capacité d’évolution. Une nouvelle règle de catalogue, un champ de commande, une lecture Odoo ou un outil d’aide à la décision rejoint des domaines et des contrats déjà établis. Le produit peut progresser sans recréer une intégration isolée à chaque besoin.

Enfin, les équipes gardent la maîtrise des décisions à fort impact. L’automatisation prépare, synchronise et signale ; les droits, les validations humaines et les états explicites déterminent ce qui peut réellement modifier une promesse faite au client.

20. Choisir le bon point d’entrée selon votre enjeu

Commencer par la douleur la plus proche, puis suivre ses dépendances

Si la priorité est l’autonomie des comptes, le projet portail client B2B montre comment assortiment, tarif, disponibilité et documents deviennent une expérience contextualisée. Pour un enjeu d’efficacité commerciale, le cockpit commercial part du portefeuille et des décisions quotidiennes.

Si le risque se situe entre les systèmes, l’intégration Odoo et ses vingt-six flux expose l’orchestration, tandis que le cycle de commande approfondit les réservations, les états et la reprise transactionnelle.

Pour une tension sur la promesse logistique, le projet achats, disponibilité et livraisons relie l’amont fournisseur aux allocations. Le premier socle de six assistants IA raconte le début d’une capacité désormais étendue à douze rôles.

Les premières étapes restent visibles dans les projets consacrés à la plateforme B2B connectée à Odoo et Algolia et au hub ShippingBo, Odoo et canaux de vente. L’industrialisation actuelle montre comment toutes ces capacités continuent d’évoluer sans interrompre les opérations.