Le projet en un coup d’œil
La recherche ne devait pas s’arrêter à une liste de produits : elle devait conduire au bon tarif B2B, à la bonne quantité et à une commande exploitable dans Odoo.
Dawap a construit les espaces client, commercial et administration, puis relié comptes, adresses, produits, prix, stocks, commandes, livraisons et factures.
Un panier mixte pouvait produire deux commandes Odoo distinctes afin de ne pas confondre les quantités immédiatement disponibles avec le reliquat.
Un portail B2B perd sa valeur dès que ses trois vérités se contredisent. Algolia peut retrouver une référence en quelques millisecondes ; si le prix ne correspond pas au compte ou si la commande n’arrive pas correctement dans Odoo, la vitesse de recherche ne sert plus à rien. Inversement, un ERP peut contenir une information exacte tout en restant trop éloigné du parcours d’un acheteur pour lui permettre d’agir seul.
C’est cette tension que la première plateforme de 1UP Distribution devait résoudre. En 48 jours, du 15 janvier au 3 mars 2024, Dawap a fait progresser un nouveau socle Symfony depuis le catalogue et la recherche jusqu’au panier, à la création des commandes Odoo, au suivi commercial et aux factures. Le projet ne se résume donc ni à un moteur de recherche, ni à un connecteur : il organise une continuité commerciale complète.
Le choix le plus révélateur apparaît au moment de valider un panier. Chaque ligne distingue la quantité disponible du reliquat. Lorsque les deux coexistent, le portail peut créer deux commandes Odoo, chacune avec ses propres lignes et sa propre référence. Cette règle montre ce que demande une véritable intégration Odoo : traduire une contrainte opérationnelle jusque dans le système de vente, sans la cacher derrière une interface séduisante.
1. 1UP Distribution et la vente aux professionnels
Un catalogue multi-marques dont chaque commande dépend du compte
1UP Distribution commercialise plusieurs marques et familles de produits auprès de clients professionnels. Dans ce contexte, une référence ne possède pas seulement un nom et un prix public. Elle s’inscrit dans une catégorie, une marque, un niveau de stock, un conditionnement et une grille tarifaire liée au compte qui commande.
Odoo porte le cœur transactionnel : comptes, adresses, catalogues, tarifs, commandes, préparations et factures. Le portail doit rendre ces informations utilisables sans les réinventer. Algolia intervient sur une autre responsabilité : offrir une recherche rapide, filtrable et suffisamment riche pour naviguer dans le catalogue. Symfony relie les deux, applique les règles du parcours et conserve l’état nécessaire entre la consultation et l’engagement.
La plateforme sert dès sa première phase trois publics. Le client prépare ses achats et retrouve ses documents ; le commercial choisit un compte et un contact pour travailler dans leur contexte ; l’administration contrôle les produits, comptes, commandes, factures, marques et catégories. Cette séparation évite de transformer le portail client en back-office universel et permet à chaque rôle d’accéder aux informations dont il a réellement besoin.
2. Une construction par chaînes métier complètes
Faire avancer catalogue, compte, panier et ERP par chaînes complètes
La chronologie du projet montre une progression très resserrée. Les premiers jours posent le socle Symfony, les commandes d’import, le produit PIM, l’indexation Algolia et la recherche asynchrone. Début février viennent les comptes Odoo, les commandes, les tarifs, les espaces commercial et administration, puis le panier et la gestion du stock disponible. Fin février ajoute factures, PDF, livraisons et traitements périodiques ; les 2 et 3 mars consolident le suivi des synchronisations, les tableaux de bord et les notifications de commande.
Chaque étape traverse plusieurs couches du produit. Une grille de prix est importée depuis Odoo, stockée localement, ajoutée à l’index, sélectionnée selon le compte, affichée dans le catalogue puis réutilisée lors de la création de la commande. Le travail suit ainsi la chaîne métier plutôt qu’une accumulation d’écrans indépendants.
Le projet disposait de configurations distinctes pour la sandbox et la production, ainsi que d’une chaîne de construction d’images PHP et Nginx dédiée aux branches correspondantes. Des tests d’intégration couvraient notamment les comptes, commandes, factures, produits, marques, catégories et prix. À ce stade, les jobs de tests du pipeline étaient cependant désactivés : la construction et la publication des images existaient, mais les tests ne bloquaient pas automatiquement une livraison. Cette limite appartient au premier palier et éclaire les besoins d’industrialisation traités ensuite.
3. Le point de départ : trois vérités à réconcilier
Recherche rapide, conditions commerciales et exécution ERP
Le problème initial n’était pas de choisir entre Algolia et Odoo. Ces outils n’ont pas le même rôle. Algolia sait restituer rapidement un catalogue enrichi et filtrable. Odoo reste responsable des comptes, des listes de prix, des adresses, des commandes et des documents transactionnels. Le portail devait préserver cette répartition tout en donnant à l’utilisateur l’impression d’un parcours continu.
La première difficulté tient au temps. Une recherche interactive ne peut pas attendre une succession d’appels ERP pour chaque produit affiché. Mais une copie locale devient dangereuse si elle reste figée. Dawap a donc construit des imports périodiques vers le modèle local, puis un index de recherche mis à jour à partir de ce modèle et des données Odoo. L’interface lit une représentation rapide ; les traitements planifiés entretiennent sa fraîcheur.
La deuxième difficulté tient au contexte. Deux clients peuvent rechercher la même référence sans disposer du même tarif. Le compte porte une catégorie de prix Odoo et le catalogue doit sélectionner les paliers correspondants. La troisième tient à l’engagement : stock affiché, quantité commandée et adresse choisie doivent encore produire des objets cohérents dans Odoo. Le projet prend donc en charge la transition entre voir, décider et commander.
Cette situation explique pourquoi une simple intégration de catalogue aurait été insuffisante. Le bon périmètre était un produit B2B : authentification, identité du compte, recherche, panier, commandes et documents. La valeur apparaît lorsque ces fonctions partagent la même règle commerciale au lieu de juxtaposer plusieurs outils.
Ce qui aurait pu être simplifié à tort
Un premier raccourci aurait consisté à afficher le prix catalogue Odoo pour tout le monde. Cela aurait rendu la recherche facile, mais aurait effacé les grilles négociées. Un second aurait été de considérer le stock comme un simple oui ou non, alors qu’une quantité demandée peut n’être que partiellement disponible.
Le projet refuse ces deux raccourcis. Le compte détermine le tarif visible et chaque ligne de panier sépare ce qui peut être servi immédiatement de ce qui reste à servir. Cette précision augmente la complexité du développement, mais elle protège la cohérence commerciale du parcours.
Le véritable coût d’une chaîne interrompue
Sans continuité entre compte, prix, stock et ERP, l’acheteur ne peut pas transformer seul sa recherche en commande fiable. Il peut trouver une référence sans connaître sa condition commerciale, préparer une quantité que le stock ne permet pas de servir ou obtenir une confirmation qui ne dit rien de la réalité dans Odoo.
Le premier palier ferme précisément ces ruptures. Au démarrage du nouveau socle, catalogue, prix de compte, panier et vente Odoo ne forment pas encore une chaîne. Quarante-huit jours plus tard, ils partagent le même contexte et conduisent jusqu’au suivi documentaire.
4. 48 jours pour obtenir un premier palier cohérent
Une progression du catalogue vers la transaction et le suivi
Le 15 janvier 2024 marque le démarrage du nouveau socle. Deux jours plus tard, le produit PIM, la commande d’envoi vers Algolia et la recherche avec rafraîchissement asynchrone sont déjà engagés. Ce premier lot donne immédiatement la direction : constituer une lecture catalogue performante, mais conserver un chemin vers les données opérationnelles.
Du 2 au 9 février, le périmètre s’élargit fortement. Authentification, déconnexion et réinitialisation du mot de passe sécurisent l’accès. Les comptes, commandes et lignes Odoo rejoignent le modèle local. Les prix et catégories tarifaires alimentent Algolia. Les espaces commercial et administration prennent forme, le panier apparaît, les quantités disponibles et les reliquats deviennent visibles, puis l’envoi du panier vers Odoo est construit.
Du 26 février au 1er mars, la plateforme ajoute ce qui transforme une commande isolée en relation suivie : factures, téléchargements PDF, préparations, adresses, imports par période, taxes et pagination. Les produits désactivés et les stocks peuvent mettre à jour la recherche. Les tableaux de bord client et commercial rapprochent les objets importés au lieu de laisser chaque fonction dans son propre écran.
Les 2 et 3 mars apportent enfin une couche d’exploitation : journal des synchronisations, calculs de tableaux de bord, planification des commandes et notifications adressées au client comme au commercial rattaché. La date du 3 mars correspond au dernier jalon structurel de cette première séquence. Elle ne signifie pas que le produit s’est arrêté là ; elle délimite le chapitre raconté ici.
Produits PIM, catégories, marques et images.
Index Algolia, filtres et rafraîchissement AJAX.
Comptes, prix, contacts et espaces dédiés.
Panier, stock, adresses et création Odoo.
Commandes, livraisons, factures, logs et emails.
5. La frontière choisie entre Algolia, Symfony et Odoo
Donner à chaque système une responsabilité lisible
Odoo reste la source des identifiants de comptes, des adresses, des catégories tarifaires, des produits, des stocks, des commandes, des préparations et des factures. Des commandes Symfony interrogent son API JSON-RPC, transforment les réponses et les enregistrent dans le modèle local. Ce modèle évite que chaque page dépende directement de plusieurs lectures ERP successives.
Algolia reçoit une projection orientée recherche. Chaque objet contient l’identifiant produit, la référence, le code-barres, le nom, la marque, le chemin de catégorie décliné sur trois niveaux, le stock, la segmentation, les statuts nouveauté et précommande, les informations de conditionnement et de réassort ainsi que les tarifs associés. Ce document de recherche est plus riche qu’une simple fiche avec titre et image.
Symfony porte la décision. Il choisit l’index de langue, construit les filtres, retrouve le panier du contact, applique la catégorie tarifaire du compte, contrôle les adresses, calcule les quantités disponibles et crée les objets de vente dans Odoo. Le portail n’est donc pas un passage transparent entre deux API : il contient les règles qui donnent du sens à leurs données.
Cette séparation permet aussi de diagnostiquer un écart. Une absence dans les résultats peut venir de l’état de recherche du produit ou de l’index ; un prix manquant renvoie à la catégorie tarifaire ; une commande refusée renvoie aux prérequis du compte, des adresses ou du commercial. Les responsabilités sont suffisamment distinctes pour savoir où chercher sans transformer tous les incidents en “problème ERP”.
Pourquoi Algolia ne devient pas la source commerciale
L’index contient des données de prix afin d’afficher rapidement les paliers disponibles. Pourtant, le compte et sa catégorie restent gérés dans l’application. La vue ne retient que les entrées qui correspondent à cette catégorie. Algolia accélère la lecture ; il ne décide pas quel contrat commercial s’applique.
Cette frontière a une conséquence pour la suite : si les exigences d’isolation tarifaire augmentent, il devient préférable de ne plus transporter toutes les catégories dans un même document de recherche. Le premier palier privilégie la rapidité de construction et la sélection applicative, avec cette limite clairement identifiée.
6. Une recherche catalogue conçue pour l’achat B2B
Retrouver une référence, filtrer puis agir sans quitter le contexte du compte
Le point d’entrée de commande interroge Algolia côté serveur. La personne peut saisir un terme puis filtrer par marque, catégorie de niveau un, deux ou trois, nouveauté et précommande. La réponse demande jusqu’à 500 résultats par page et restitue également les facettes nécessaires à la navigation. Une route dédiée recharge le tableau de résultats sans reconstruire toute la page.
Chaque résultat peut réunir référence, code-barres, marque, catégorie, stock, image, segmentation et conditions de quantité. Cette densité répond à un usage professionnel : l’acheteur sait souvent ce qu’il cherche et doit comparer des variantes ou des conditionnements rapidement. La recherche ne force pas un parcours éditorial long avant l’ajout au panier.
Les mises à jour ordinaires sont bornées à 50 produits marqués comme devant être réindexés. Deux reconstructions complètes en français sont prévues quotidiennement, à 6 heures et 14 heures, tandis que les changements incrémentaux passent toutes les cinq minutes. Après l’envoi réussi d’un objet, son indicateur de mise à jour est retiré pour éviter de le republier sans nécessité.
Le composant prévoit aussi des suffixes d’index et des contextes Odoo pour le français, l’anglais et l’espagnol. Dans la planification de production de ce premier palier, seul le français est exécuté. La capacité technique multilingue existe donc, mais elle ne doit pas être confondue avec trois catalogues effectivement maintenus en production.
Le gain observable côté utilisateur
La recherche rassemble dans une même interaction des dimensions qui auraient autrement demandé plusieurs consultations : identité du produit, hiérarchie de catalogue, marque, état commercial, stock et prix du compte. L’utilisateur peut passer d’un terme ou d’une facette à une ligne commandable sans ressaisir la référence ailleurs.
Ce gain reste fonctionnel, pas chronométré. Aucun temps moyen de recherche n’est publié. Ce que le produit démontre est la suppression d’une rupture de parcours : la réponse Algolia est directement replacée dans le panier et le contexte tarifaire du compte.
7. Des tarifs B2B résolus par compte et par quantité
Ne jamais remplacer une condition commerciale absente par un prix générique
Chaque compte Odoo importé peut être rattaché à une catégorie tarifaire. Les prix associés aux produits sont classés par quantité minimale. Dans le catalogue, le portail recherche au sein du résultat Algolia les lignes appartenant à la catégorie du compte courant. Le prix unitaire correspond au palier de quantité un ; le premier palier supérieur devient le conditionnement proposé par défaut.
Lorsque le compte n’a pas de catégorie ou qu’aucun prix compatible n’est disponible, le parcours ne doit pas inventer un montant de secours. La validation du panier vérifie explicitement la présence de la catégorie tarifaire avant tout envoi à Odoo. Cette règle empêche une commande techniquement créée mais commercialement incomplète.
Le tarif traverse donc toute la chaîne. Il naît de l’import Odoo, rejoint le modèle de prix, alimente le document Algolia, est filtré par le compte puis fournit à Odoo l’identifiant de liste de prix au moment de créer la commande. La valeur affichée et l’objet transactionnel partagent le même rattachement commercial.
Ce choix rend le projet utile au-delà de l’intégration technique. Il protège la lisibilité de la relation B2B : le client n’est pas traité comme un visiteur anonyme et le commercial peut préparer une commande dans le contexte du compte choisi. Notre page consacrée aux intégrations e-commerce approfondit cette continuité entre catalogue, panier et systèmes de gestion.
8. Trois espaces pour trois responsabilités
Servir le client sans confondre vente, assistance et administration
L’espace client permet de rechercher des produits, gérer un panier, choisir ses adresses, confirmer la transmission, consulter ses commandes en cours ou livrées et retrouver ses factures. L’accès est authentifié, avec initialisation et réinitialisation du mot de passe. Le parcours est centré sur le compte ERP rattaché à la personne connectée.
L’espace commercial ajoute une étape déterminante : choisir le compte puis le contact cible. Le panier est alors créé pour cette combinaison et conserve à la fois le commercial qui agit et l’utilisateur pour lequel la commande est préparée. Si aucun contact cible n’est choisi, l’ajout au panier reste bloqué. Cette protection évite de construire une commande dans un contexte incomplet.
L’administration dispose de vues sur les comptes, commerciaux, produits, marques, catégories, commandes, factures et synchronisations. Ces écrans ne sont pas seulement des tableaux de données ; ils donnent un lieu pour contrôler que les objets importés existent et pour retrouver l’état des flux lorsque le front ne correspond pas à l’ERP attendu.
La séparation des espaces est un gain de gouvernance observable. Un client ne reçoit pas les outils d’administration, un commercial ne doit pas simuler un achat sans compte cible et l’administration garde une lecture transversale. Le même socle sert plusieurs rôles sans aplatir leurs permissions ni leurs besoins.
9. Un panier qui porte déjà les règles de la commande
Compte, contact, adresses, commercial et disponibilité avant l’appel ERP
Lorsqu’un client ouvre un nouveau panier, le système lui associe son compte ERP, son utilisateur cible et les adresses de facturation et de livraison par défaut trouvées pour ce compte. Pour un commercial, le même objet est créé après sélection explicite du compte et du contact. Cette initialisation empêche le panier de rester une collection de références sans contexte contractuel.
Avant l’import, plusieurs prérequis sont contrôlés : le panier ne doit pas avoir déjà été utilisé, les deux adresses doivent exister, le compte doit posséder une catégorie tarifaire et un commercial Odoo doit lui être rattaché. En cas d’échec, une raison est enregistrée sur le panier. La personne ne découvre donc pas seulement un échec distant ; le produit sait nommer le prérequis manquant.
Chaque ligne conserve la quantité totale, la part disponible et la part non disponible, ainsi que leurs montants hors taxes respectifs. L’utilisateur peut retirer les reliquats avant confirmation. Cette action recalcule les lignes et les totaux, puis indique que le panier ne contient plus que des quantités disponibles.
Le panier devient ainsi un espace de décision. Il ne promet pas qu’une référence existe simplement parce qu’elle a été trouvée. Il vérifie le contexte, présente la réalité de disponibilité et laisse le choix entre conserver ou retirer ce qui ne peut pas être servi immédiatement. C’est cette étape qui prépare l’arbitrage de commande le plus singulier du premier palier.
10. Un panier mixte devient deux commandes Odoo
Séparer l’immédiatement disponible du reliquat sans perdre le lien client
Si le panier contient des quantités disponibles, le portail crée une première vente Odoo avec le compte, les adresses de facturation et de livraison, la liste de prix, le commercial et l’origine B2B. Il ajoute ensuite uniquement les quantités disponibles. Les lignes sont triées par marque et des séparateurs textuels peuvent être insérés pour rendre le document plus lisible dans l’ERP.
Cette vente est confirmée. Le portail relit ensuite les préparations associées et déclenche leur assignation lorsqu’elles existent. La référence Odoo est conservée dans le panier avant de poursuivre, ce qui protège au moins contre une nouvelle création complète au prochain passage.
Si certaines quantités ne sont pas disponibles, une seconde vente Odoo est créée avec le même contexte, mais uniquement pour le reliquat. Elle reçoit sa propre référence et peut contenir une note distincte. Elle est elle aussi confirmée : le projet ne la laisse pas au simple état d’un brouillon présenté à tort comme une commande future.
Ce découpage traduit une réalité d’exploitation en objets explicites. Le premier ensemble peut suivre son chemin de préparation, tandis que le second conserve les quantités restant à servir. Côté portail, le panier garde les deux identifiants. Côté Odoo, chaque ordre contient les lignes correspondant à sa disponibilité. La règle évite de masquer une commande partiellement servable derrière un seul statut ambigu.
Compte, adresses, tarif et commercial contrôlés.
Disponible et non disponible calculés par ligne.
Lignes servables créées, confirmées et assignées.
Reste à servir créé et confirmé séparément.
Les deux identifiants Odoo restent liés au panier.
Pourquoi cette règle crée de la valeur
Sans séparation, une commande globale peut donner l’impression que tout avance au même rythme. La distinction par disponibilité rend l’engagement plus honnête : les quantités servables et le reste possèdent des objets différents, donc des références et des suivis différents.
Aucun délai de livraison ou taux de rupture n’est déduit de cette architecture. Le bénéfice démontré est la qualité de représentation : Odoo reçoit deux ensembles cohérents au lieu d’une seule commande dont les lignes n’ont pas toutes la même situation opérationnelle.
11. Ramener commandes, livraisons et factures dans le portail
Ne pas arrêter l’expérience après le clic de confirmation
Les commandes créées sur le portail portent une origine B2B explicite dans Odoo. Le traitement périodique peut ensuite importer les ventes correspondantes, leurs lignes, leur compte, leurs adresses et leur commercial. Les vues client distinguent les commandes en cours de celles qui sont livrées, tandis que l’espace commercial accède à ses propres recherches et détails.
Les préparations de stock sont elles aussi importées. Elles prolongent la commande vers l’exécution logistique sans prétendre remplacer Odoo comme système d’enregistrement. Leur présence permet au portail de restituer une étape supplémentaire de la relation plutôt que de laisser le client avec la seule preuve que son panier a été soumis.
Les factures sont synchronisées par période, puis leurs PDF sont récupérés dans un espace organisé par compte. Au téléchargement, le contrôleur vérifie que la facture demandée existe et qu’elle appartient bien au compte ERP de la personne connectée. Même si un identifiant est modifié dans l’adresse, une facture d’un autre compte n’est pas servie.
La commande ne se termine donc pas dans une page de confirmation isolée. Le projet reconnecte l’historique transactionnel au compte et apporte au client une continuité documentaire. Cette capacité est approfondie dans le projet consacré au cycle de commande B2B, du panier à la facture, qui décrit l’état plus mature du programme.
12. Des synchronisations planifiées autour de la fraîcheur métier
Faire circuler les changements sans solliciter Odoo à chaque écran
La production de ce premier palier prévoit une cadence de cinq minutes pour les utilisateurs et commerciaux, les comptes, les adresses, les commandes, les préparations, les factures, les produits actifs ou désactivés, les stocks, les marques, les catégories, les prix et l’indexation incrémentale Algolia. Les prix-catégories, taxes et certains agrégats utilisent une cadence horaire ou quotidienne adaptée à leur rôle.
Les imports par période reçoivent une fenêtre temporelle afin de relire les changements récents. Cette stratégie limite le volume de chaque passage tout en laissant une marge pour reprendre des écritures dont l’horodatage ne serait pas exactement aligné avec l’exécution précédente. Les reconstructions complètes d’Algolia complètent l’incrémental deux fois par jour.
Un journal de synchronisation et des écrans de suivi apparaissent à la fin de la séquence. Ils rendent les exécutions repérables par les équipes d’administration et commerciales. Les sorties de chaque tâche sont également séparées dans des fichiers de log propres aux familles fonctionnelles : utilisateurs, comptes, commandes, catalogue ou prix.
Cette organisation apporte une fraîcheur cadrée, mais elle ne constitue pas une synchronisation temps réel. Une cadence de cinq minutes signifie qu’un changement peut rester momentanément absent du portail. Le projet choisit un compromis lisible entre charge ERP et actualisation ; la fiche ne le transforme pas en promesse instantanée.
Les notifications ne bloquent pas l’email dans la requête
Après la création des commandes, deux messages sont publiés : l’un prépare la notification du client, l’autre celle du commercial ERP. Symfony Messenger route les emails vers un transport asynchrone avec trois tentatives et un délai de reprise de trente secondes.
Cette asynchronie concerne l’envoi des messages, pas la création des commandes Odoo elle-même. Les appels JSON-RPC du panier attendent leur réponse avant de poursuivre. Distinguer ces deux comportements évite de promettre une résilience transactionnelle qui n’existait pas encore dans cette version.
13. Tests, environnements et première chaîne de livraison
Une base réelle, avec une barrière CI encore incomplète
Le projet contient dès ce palier des tests d’intégration ciblant des chaînes importantes : chargement des comptes, commandes et factures ERP, import des produits, marques et catégories PIM, ainsi que synchronisation des prix et catégories tarifaires. Ces tests valident les transformations de données essentielles entre le domaine local et les sources externes.
Les configurations de sandbox et de production séparent les images PHP et Nginx. La branche de développement construit les images de sandbox ; la branche principale construit celles de production. Cette distinction rend les environnements explicites et évite d’utiliser exactement le même tag mouvant pour les deux usages.
La limite doit être dite clairement : les jobs unitaires, d’intégration et applicatifs étaient présents mais commentés dans le pipeline de cette première phase. Les images pouvaient donc être renommées comme testées sans qu’un échec de suite automatisée interdise réellement leur publication. Les tests existaient ; ils n’étaient pas encore une barrière de promotion.
Cette différence entre “avoir des tests” et “faire dépendre la livraison de leur succès” est déterminante. Elle n’annule pas le travail fonctionnel réalisé, mais définit le prochain niveau de maturité. Le projet d’industrialisation de la plateforme 1UP Distribution montre comment cette dette de delivery a ensuite été reprise avec des contrôles obligatoires, une continuité de service et des procédures de retour.
14. Ce que le premier palier change concrètement
Un même parcours depuis la recherche jusqu’à la preuve transactionnelle
Pour le client, le gain observable est la continuité. Il peut s’authentifier, chercher jusqu’à 500 produits par page avec des facettes métier, retrouver le tarif de son compte, constituer un panier, choisir ses adresses, décider du sort des reliquats, envoyer la commande puis consulter ventes et factures. Ces actions ne demandent plus de quitter le portail pour reconstituer la chaîne.
Pour le commercial, le contexte devient actionnable. Il choisit un compte et un contact, retrouve le même catalogue, prépare un panier pour cette cible et conserve le rattachement du commercial Odoo au moment de la création. Cette capacité ne remplace pas la relation commerciale ; elle lui donne un outil cohérent avec les données qui gouvernent réellement la vente.
Pour l’administration, les imports réguliers et les écrans sur les comptes, produits, catégories, marques, commandes, factures et journaux de synchronisation forment une première surface de contrôle. Un objet absent ou un prérequis manquant possède un domaine identifiable. Le diagnostic ne dépend plus uniquement du symptôme visible dans le panier.
Pour 1UP Distribution, le résultat le plus important est architectural : catalogue rapide, règles de compte et transaction ERP appartiennent désormais au même produit. Aucun pourcentage de productivité ou de conversion n’est disponible pour quantifier cet effet. La preuve repose sur les parcours livrés, les règles appliquées et les objets transmis, pas sur une estimation marketing.
Un avant/après visible dans les capacités du produit
Avant ce palier dans le nouveau socle, il n’existe pas encore de chaîne continue entre recherche Algolia, prix de compte, panier et commande Odoo. À l’issue des 48 jours, cette chaîne est présente avec trois espaces, des synchronisations planifiées et un suivi documentaire.
La transformation peut donc être décrite précisément sans attribuer un volume d’usage. Ce qui change est la capacité du système : la recherche mène à une décision tarifée, la décision devient une ou deux commandes selon le stock, puis les objets Odoo reviennent dans le portail.
15. Les limites assumées du premier palier
Savoir exactement ce qui devait encore être renforcé
La création de commande appelle Odoo de façon synchrone et enchaîne la création de la vente, des lignes, la confirmation puis l’assignation. Plusieurs écritures locales sont enregistrées au fil du parcours, mais aucune transaction distribuée ne peut annuler automatiquement les objets déjà créés dans Odoo si une étape suivante échoue. Une reprise exige donc de regarder les identifiants et états déjà conservés.
La protection contre les doublons est partielle. Le panier refuse une nouvelle importation lorsqu’il est marqué comme utilisé ou qu’un identifiant Odoo correspondant existe. Cependant, le mécanisme n’est pas encore une idempotence de bout en bout fondée sur une clé stable comprise par le système distant. Une coupure au mauvais moment peut demander une intervention contrôlée.
La recherche transporte toutes les grilles tarifaires du produit dans le même document Algolia, puis l’application sélectionne la catégorie du compte. L’appel est effectué côté serveur et l’interface ne rend que le prix utile, mais cette architecture mêle encore donnée de recherche et ensemble des conditions commerciales. Une isolation plus stricte ou une résolution hors index constitue une évolution naturelle.
Ce cas prouve une recherche Algolia reliée au catalogue B2B. Pour une architecture transverse qui sépare retrieval, sources autorisées, génération et décision, la page intégrateur API IA, data et search porte ce cadrage. Le projet ne revendique ni RAG génératif ni les autres plateformes de cet univers.
Enfin, seul le français est effectivement planifié pour l’indexation, les tests ne bloquent pas le pipeline et le journal de synchronisation ne remplace pas une stratégie complète de reprise. Ces limites expliquent la trajectoire suivante du programme : renforcer contrats, files, idempotence, qualité de livraison et observabilité sans abandonner les parcours métier du premier palier.
16. Du premier portail à une plateforme B2B industrialisée
Conserver la logique métier tout en renforçant le système
Ce projet doit rester distinct des réalisations 1UP plus récentes. Il raconte le moment où recherche, tarifs, stock et commande ont été réunis pour la première fois dans le nouveau portail Symfony. Les fiches suivantes décrivent ce que ce socle est devenu après deux années d’évolution ; elles ne doivent pas être rétroactivement présentées comme des capacités de mars 2024.
Le projet Odoo, APIs et automatisation des flux B2B approfondit la circulation actuelle des données et les mécanismes de reprise. Le cycle de commande du panier à la facture montre la maturité transactionnelle obtenue autour des états et de la preuve d’import.
La fiche sur l’industrialisation de la plateforme traite les tests obligatoires, les contrats, la continuité et l’exploitation. Enfin, la transformation complète du commerce B2B autour d’Odoo replace cette première étape dans une histoire commencée avant 2024 et prolongée par la logistique, les achats et de nouveaux espaces métier.
Cette séparation des chapitres rend la preuve plus utile. Le lecteur peut juger la vitesse et les arbitrages du premier delivery, puis suivre les renforcements qui ont corrigé ses limites. La trajectoire ne gomme pas la dette initiale ; elle montre comment un produit métier gagne en profondeur à partir d’une base déjà utilisée.
17. Conclusion : la recherche n’a de valeur que si elle aboutit à la bonne commande
Un premier palier rapide, précis sur ses règles et honnête sur ses limites
En 48 jours, 1UP Distribution dispose d’une chaîne B2B qui part du catalogue, résout le tarif du compte, qualifie la disponibilité et crée les ventes correspondantes dans Odoo. Trois espaces répartissent les responsabilités. Les commandes, préparations et factures reviennent ensuite dans le portail pour prolonger la relation au-delà du panier.
La règle des deux commandes résume la qualité de cette première version : une contrainte de stock ne reste pas un message d’interface, elle modifie réellement la structure envoyée à l’ERP. Le disponible suit son propre chemin ; le reliquat conserve le sien. Le client, le commercial et l’administration travaillent ainsi sur des objets qui reflètent mieux la situation opérationnelle.
Le projet reste tout aussi instructif par ce qu’il ne prétend pas. Les gains business ne sont pas chiffrés sans mesure client, le multilingue n’est pas annoncé comme actif lorsqu’il ne l’est pas, les tests présents ne sont pas transformés en barrière CI imaginaire et l’appel Odoo synchrone est présenté avec son risque de reprise. Cette précision renforce la valeur de la preuve au lieu de l’affaiblir.
Pour construire ou reprendre un portail confronté aux mêmes enjeux de catalogue, de prix et de commande, notre accompagnement en intégration Odoo part de cette question simple : quelle vérité appartient à l’ERP, quelle lecture doit être accélérée et quels contrôles doivent relier les deux ? C’est à cet endroit qu’une connexion technique devient un système commercial réellement exploitable.
