Le projet en un coup d’œil
Le prix, la disponibilité, les adresses, les zones, l’import et les documents devaient rester cohérents malgré les reprises et délais externes.
Dawap a relié relecture, réservation, soumission idempotente, import Odoo, suivi, annulation, factures et avoirs.
Le client et les équipes savent si la commande est prête, en traitement, partielle, confirmée ou à reprendre.
Le moment le plus risqué d’un commerce B2B n’est pas toujours le paiement. C’est la transition entre une intention construite dans le portail et un engagement accepté par l’ERP. Le stock peut changer, une adresse peut être invalide, une commande peut devoir être scindée, le réseau peut couper après l’écriture et un second clic peut répéter la demande.
Le cœur transactionnel devait donc tenir ensemble la réservation temporaire du stock, la relecture zonée, l’import Odoo, la progression, la gestion des échecs, la synchronisation locale, l’annulation et le suivi commercial. En isoler une seule étape aurait laissé des zones grises exactement aux endroits où le client et les équipes ont besoin d’une réponse certaine.
Dawap a traité ce chantier comme une automatisation de processus métier où l’état, la preuve et la reprise comptent autant que le chemin nominal. Le résultat n’est pas un bouton “Commander” : c’est une chaîne capable d’expliquer précisément ce qui s’est passé après ce bouton.
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. La commande dans le modèle B2B de 1UP Distribution
Un engagement commercial qui traverse plusieurs systèmes
Une commande 1UP Distribution part d’un compte, d’un assortiment et d’une catégorie de prix. Elle contient des produits dont la disponibilité peut dépendre du stock immédiat, d’une réservation, d’un approvisionnement ou d’une règle de diffusion. Elle doit utiliser une adresse autorisée et rejoindre Odoo avec des références stables.
Après l’import, la relation continue : statut de vente, préparation, expédition, livraison, facture, avoir, paiement et parfois annulation. Les clients et commerciaux consultent cette histoire depuis des interfaces différentes, mais doivent lire la même réalité.
Le moteur transactionnel se trouve donc à l’intersection du portail client B2B, de l’intégration Odoo et des opérations logistiques. La responsabilité du projet est de conserver la continuité entre ces contextes sans les rendre indissociables.
2. Modéliser la transaction comme une machine à états
Chaque transition possède ses préconditions, ses effets et sa reprise
Le cadrage a décrit le cycle complet : panier actif, relecture, réservation, prêt à importer, import en cours, traitement par zone, confirmation, échec et libération. Les règles de modification et de reprise ont été écrites avant de multiplier les boutons.
Chaque lot a été testé avec les variations qui provoquent les incidents réels : double soumission, snapshot périmé, quantité devenue insuffisante, ligne supprimée, adresse changée, import partiel, réponse Odoo tardive, commande déjà existante ou document encore absent.
La livraison s’est faite par incréments observables. Le backlog Jira a séquencé les sprints par réduction du risque transactionnel : protéger l’engagement, rendre la progression lisible, puis ouvrir les reprises et les documents aval. Les équipes ont pu vérifier le panier, la progression, les commandes créées et les synchronisations dans l’environnement de validation avant d’élargir le périmètre. Les outils de replay et de diagnostic ont été livrés avec le workflow.
3. Les risques cachés entre le panier et la facture
Une succession de petits écarts peut produire une grosse rupture de confiance
Le premier risque est la concurrence sur le stock. Deux clients peuvent voir la même quantité et confirmer à quelques secondes d’intervalle. Sans réservation temporaire, le portail promet davantage que ce que l’entreprise peut diffuser. Avec une réservation mal libérée, il crée au contraire de fausses ruptures.
Le deuxième risque est la répétition. Le client peut cliquer deux fois, une application mobile peut retenter après timeout et un worker peut reprendre un message. Si chaque tentative crée un nouvel objet externe, la résilience devient une source de doublons.
Le troisième risque est l’écart de statut. Une base locale peut avoir enregistré la demande alors qu’Odoo ne l’a pas acceptée. Présenter immédiatement une commande confirmée rend ensuite toute correction incompréhensible pour le client et l’équipe.
La plateforme ne confond jamais “demande reçue”, “stock protégé”, “import envoyé” et “commande confirmée par Odoo”. Ces états restent distincts dans le domaine et dans l’interface.
Le timeout qui peut créer deux commandes
Le scénario critique n’est pas forcément un refus explicite. Odoo peut avoir accepté la commande tandis que la réponse se perd avant de revenir au portail. Pour l’utilisateur, l’opération semble échouée ; pour l’ERP, elle existe déjà. Une relance naïve transforme alors un incident réseau en double engagement commercial.
L’identité de soumission et la vérification de l’état externe sont donc aussi importantes que le payload. Le système doit pouvoir reconnaître l’intention initiale, retrouver son éventuel résultat et ne créer un nouvel objet que lorsqu’il a établi que le premier n’existe pas.
Le stock visible n’est pas encore un stock promis
Une disponibilité affichée est une photographie calculée. Entre cette lecture et la confirmation, d’autres paniers, une correction d’inventaire ou un engagement commercial peuvent modifier la capacité réelle. Confondre affichage et réservation revient à faire porter le risque de concurrence aux opérations.
La chaîne distingue donc trois moments : informer avec une projection, protéger temporairement une capacité, puis transférer l’engagement à la commande reconnue par l’ERP. Les expirations et libérations complètent ce cycle pour qu’une tentative abandonnée ne crée pas une rupture artificielle.
4. Un panier qui porte du métier
Compte, distribution, variantes et identités de lignes
Le panier appartient à un utilisateur dans le contexte d’un compte et d’une distribution. Ses lignes référencent des produits et variantes résolus dans le catalogue effectif. Les opérations d’ajout, de mise à jour, de suppression et de remplacement valident ce périmètre à chaque écriture.
Les lignes conservent une identité stable nécessaire à la relecture, à la réservation et au rapprochement après import. Les quantités invalides, produits hors distribution ou paniers déjà confirmés sont refusés. Vider ou modifier un panier déclenche la libération ou le recalcul des réservations associées.
Les commerciaux disposent d’un parcours de prise de commande fondé sur le même domaine. L’API externe peut créer et modifier les paniers avec des gardes et une idempotence explicites. Il n’existe pas deux vérités transactionnelles selon que la commande vient du client ou d’un vendeur.
Le panier reste modifiable tant que son état le permet. Une fois engagé dans l’import, les mutations sont bloquées ou mises en attente de vérification pour empêcher qu’une version locale diverge de celle envoyée à Odoo.
5. Relecture, adresses et préconditions
Valider le contexte au dernier moment utile
La relecture vérifie le compte, la distribution, les lignes, les prix, les disponibilités et les adresses. Le client peut choisir son adresse principale parmi celles autorisées. Une adresse extérieure au compte ou une destination insuffisamment qualifiée ne passe pas par simple manipulation du payload.
Les données de stock sont relues avec un snapshot suffisamment frais. La plateforme refuse de confirmer sur une projection absente ou périmée. Cette décision peut sembler moins fluide qu’un succès optimiste, mais elle évite une promesse que les opérations devraient ensuite réparer.
La table de relecture regroupe les lignes et expose les erreurs au bon niveau. Le client comprend quel produit doit être ajusté et pourquoi. Les références de commande et informations nécessaires à l’import sont clarifiées avant la soumission.
Cette approche rejoint le principe présenté dans l’article workflow devis-commande B2B : garder prix et preuve : revalider au passage de l’intention à l’engagement.
6. Réserver le stock sans le bloquer indéfiniment
Une protection temporaire avec un cycle de vie complet
Avant l’import, le système crée des réservations détaillées pour les lignes du panier. Elles sont prises en compte dans les lectures de disponibilité du catalogue, du mobile et des audits. Un autre panier voit donc la capacité réduite pendant la fenêtre d’engagement.
Chaque réservation possède une durée et un état. Une modification de ligne, un vidage, une expiration ou un échec définitif libère la capacité. Une importation réussie termine la réservation lorsque l’engagement Odoo et les projections suivantes peuvent prendre le relais.
Les réservations couvrent aussi la disponibilité future et les reliquats lorsqu’ils sont autorisés. Le système conserve le détail nécessaire pour savoir quelle ligne et quelle source de capacité ont été engagées, au lieu de manipuler un compteur global impossible à expliquer.
Les crons d’expiration et tests de concurrence protègent ce cycle. Les échecs de libération et les snapshots manquants ont des chemins défensifs dédiés.
7. Découpage par zones et plans d’intégration
Une intention client peut produire plusieurs objets ERP
Selon la distribution, les produits et les règles de stock, un panier peut être découpé en plusieurs zones d’intégration. Le plan calcule les regroupements avant l’écriture et conserve la relation entre chaque ligne locale et l’objet attendu côté Odoo.
La relecture présente ce découpage sans obliger le client à connaître l’architecture interne. Les états de progression peuvent ensuite être suivis par zone : une partie réussie ne masque pas l’échec d’une autre, et un retry cible le périmètre qui en a besoin.
Les identités du plan sont déterministes. Recalculer ou reprendre ne doit pas déplacer arbitrairement les lignes entre objets. Les tests couvrent les paniers zonés, les références et les imports partiels.
Cette modélisation permet de représenter la réalité logistique sans prétendre qu’un panier correspond toujours à une commande, une expédition et une facture uniques.
8. Un import Odoo idempotent
Créer exactement ce qui doit l’être, même après une coupure
La soumission déclenche le flux d’import Odoo avec les références de compte, adresses, lignes et zones validées. Une identité stable permet de reconnaître une demande déjà traitée. L’écriture locale et l’appel externe ne sont pas présentés comme une transaction magique unique.
Si la connexion coupe après l’envoi, la reprise vérifie l’état avant de recréer. Les réponses et identifiants externes sont persistés lorsqu’ils deviennent disponibles. Les commandes nouvellement créées sont resynchronisées localement pour rapprocher le résultat de la source.
Les écritures API de panier ont été rendues idempotentes et les changements incompatibles de contrat bloqués en CI. Cette protection s’applique aux clients techniques comme aux parcours web.
Le détail des stratégies de déduplication Odoo est développé dans l’article intégration API Odoo : fiabiliser commandes, stock et reprise.
9. Progression, erreurs et reprise
Rendre la zone grise visible au lieu de la cacher
L’interface distingue le panier prêt, en vérification, en cours d’import, partiellement traité, confirmé et échoué. La progression par zone reste disponible sur l’écran de confirmation. Un utilisateur qui recharge la page retrouve l’état, au lieu de déclencher automatiquement une nouvelle écriture.
Les erreurs locales et externes sont rattachées au bon niveau. Une rupture de contrat, une donnée Odoo refusée ou une disponibilité devenue insuffisante ne produit pas le même chemin de reprise. Le produit conserve les informations qui aident l’équipe à corriger la cause.
Une réservation est libérée lorsqu’un échec rend l’import impossible ; elle est conservée lorsqu’une reprise peut encore aboutir. Cette nuance évite à la fois de bloquer artificiellement du stock et de le remettre en vente pendant qu’une commande existe peut-être déjà dans l’ERP.
Les outils de replay passent par des confirmations et un contrôle du canal B2B. Ils sont conçus pour réparer une exécution, pas pour contourner les préconditions du workflow.
Compte, prix, adresse et disponibilité
Capacité temporaire par ligne
Identité stable et zones Odoo
Références externes réconciliées
Livraison, facture, avoir et paiement
10. Commande confirmée, historique et annulation
Faire basculer la lecture vers la vérité Odoo
Après confirmation, la commande synchronisée devient l’objet de référence du suivi. Le portail et le cockpit commercial affichent les lignes, statuts, références et engagements accessibles. Les paniers ne sont plus modifiables comme si la transaction restait locale.
Les demandes d’annulation passent par des règles d’éligibilité et un flux Odoo. Une commande déjà trop avancée, hors périmètre ou non annulable est refusée. La sandbox permet de valider ce comportement sans manipuler une vente de production.
Les statuts sont traduits dans un vocabulaire compréhensible sans effacer les distinctions utiles. Une confirmation de vente, une préparation et une expédition sont des jalons différents. Les dates Odoo sont normalisées pour éviter les décalages de fenêtre ou de fuseau.
L’historique donne ainsi au client et au commercial la même base de discussion. Les interfaces adaptent la profondeur, mais ne reconstruisent pas deux histoires concurrentes.
11. Factures, avoirs et preuve financière
Prolonger la commande jusqu’aux documents comptables
Les factures et avoirs sont synchronisés avec leurs lignes, devises, canaux et références. Les endpoints client et commercial exposent uniquement les documents du périmètre autorisé. Les factures non postées ne sont pas présentées au client comme définitives.
Les pièces PDF stockées depuis Odoo sont réutilisées. Cette décision protège la conformité du document et évite qu’une génération locale produise une mise en page ou un montant différent. Les erreurs d’attachement restent observables.
Les règlements et allocations peuvent compléter la lecture dans le cockpit commercial. Les invariants empêchent une allocation sur le mauvais document ou un total incohérent. L’avoir conserve sa nature au lieu d’être affiché comme une facture négative générique.
La transaction est alors traçable jusqu’à sa preuve financière, ce qui répond à l’objectif initial : ne pas perdre l’histoire entre le panier, l’ERP et les documents remis au client.
12. Expédition, tracking et promesse client
Ne pas arrêter le récit au statut de commande
Les lignes de vente sont rapprochées des lignes d’expédition et des engagements de livraison. Le portail expose le suivi disponible ; le cockpit commercial dispose d’une timeline ; les opérations gèrent le diagnostic détaillé dans leur pipeline.
Le tracking transporteur peut être actualisé manuellement dans le cadre prévu. Les expéditions préparées et livrées alimentent l’historique et les analyses. Les canaux B2B et B2C restent séparés pour ne pas fausser les engagements ou les calculs de franco.
Les commandes partielles et reliquats ne sont pas aplatis en un unique statut rassurant. La promesse reflète ce qui est réellement prêt, expédié ou attendu. Cette précision réduit les réponses contradictoires entre service client, commercial et logistique.
La logique approfondie de préparation est détaillée dans le projet achats, stock et livraisons B2B.
13. Tests transactionnels et contrôles de non-régression
Prouver les cas qui coûtent cher lorsqu’ils échouent
Les tests couvrent les mutations de panier, les réservations, les expirations, les snapshots périmés, le découpage en zones, les imports partiels, les références, l’idempotence, les annulations, les PDF et les allocations financières.
Les contrats API vérifient les payloads et les erreurs. Les scénarios de sécurité essaient les accès croisés entre comptes. Les tests d’intégration s’appuient sur une base et des fixtures représentatives pour valider les contraintes réelles.
Les branches de récupération sont volontairement testées : échec du dépôt, réponse externe invalide, état terminal incohérent, réservation déjà libérée ou commande existante. Ces chemins rares sont précisément ceux qu’un test manuel heureux ne rencontrera pas.
La CI parallélise la suite et bloque les changements incompatibles. Le détail du volume et de la couverture est présenté dans le projet d’industrialisation plutôt que répété comme un trophée sans contexte.
14. Résultats obtenus et limites
Une commande explicable de bout en bout
Le cycle construit une continuité entre le panier, la disponibilité, les adresses, l’import Odoo, la commande, l’expédition et les documents. Chaque étape critique possède un état et une identité, ce qui rend la reprise possible sans dupliquer aveuglément.
Le client obtient une information plus honnête pendant le traitement ; les équipes disposent de détails pour diagnostiquer ; l’ERP garde la propriété des objets contractuels et financiers. Le portail n’a pas besoin de prétendre qu’un traitement asynchrone est instantané.
Aucun taux d’abandon, délai moyen ou volume de commandes n’est avancé sans mesure client consolidée. La preuve porte sur le workflow livré, les transitions observables et le niveau de contrôle appliqué aux scénarios de reprise.
Le cycle reste dépendant de la qualité des référentiels et de la disponibilité externe. L’architecture ne supprime pas cette dépendance ; elle l’isole, l’observe et la rend récupérable.
Ce que voit le client pendant une opération non instantanée
Le produit ne remplace pas l’attente par un faux succès. Il indique que la demande est reçue, que le stock est protégé, que l’import progresse ou qu’une action est nécessaire. Un rechargement retrouve le même état et n’expédie pas une seconde intention.
Cette honnêteté réduit l’incertitude : le client sait ce qui est acquis, les équipes savent ce qui reste à confirmer, et tous disposent de la même référence lorsque la transaction demande une intervention.
Ce que gagnent les équipes de run
Une anomalie peut être située dans la chaîne : précondition locale, réservation, plan zoné, écriture Odoo, réconciliation ou document aval. L’intervention porte sur le bon objet et conserve les traces de la tentative précédente.
Le workflow devient ainsi exploitable dans la durée. La reprise n’est plus un script exceptionnel connu d’une seule personne, mais une capacité gouvernée qui respecte les mêmes droits et invariants que le parcours nominal.
15. Conclusion : traiter la commande comme un engagement
Automatiser sans effacer les états intermédiaires
Ce projet montre pourquoi un cycle B2B solide ne se résume pas à envoyer un panier à un ERP. Il faut protéger le stock, figer le contexte, reconnaître les répétitions, suivre l’import, rapprocher le résultat et prolonger la preuve jusqu’aux documents.
Dawap a construit une transaction explicable : le produit sait ce qui est demandé, réservé, envoyé, confirmé ou échoué. Cette nuance donne aux équipes une capacité de reprise et au client une expérience plus fiable.
Pour étudier un processus comparable, notre offre d’automatisation des processus métier est le point d’entrée. Le cas 1UP en montre la traduction sur un flux où chaque doublon ou faux statut a un coût réel.
