Le projet en un coup d’œil
Catalogue, prix, clients, ventes, achats, factures et logistique dépendent du même ERP, mais n’ont ni la même fréquence ni le même risque.
Dawap a construit 25 flux Odoo, des contrats API, des files dédiées, des retries, des replays et des contrôles de fraîcheur.
Les équipes savent quelle source fait foi, ce qui a été traité, ce qui attend et ce qui doit être repris.
“Connecter Odoo” peut désigner un appel API de quelques lignes ou un système critique qui transporte toute l’activité. Chez 1UP Distribution, l’ERP intervient dans les comptes, les produits, les prix, les commandes, les achats, les expéditions, les factures, les avoirs et les paiements. Une intégration partielle ou opaque aurait seulement déplacé les ressaisies et rendu les erreurs plus difficiles à diagnostiquer.
Le véritable enjeu était de faire cohabiter des flux de nature radicalement différente. Une lecture catalogue peut être différée et reconstruite ; une création de commande doit produire exactement un effet ; une facture doit rester opposable ; une projection de stock doit pouvoir expliquer les mouvements qui l’ont formée. Les pullers Odoo, les files, les contrôles de replay, les devises et les mappings ont donc été conçus comme un ensemble cohérent.
Dawap a appliqué une approche d’intégrateur Odoo orientée production : expliciter la propriété de chaque donnée, séparer les lectures des écritures, rendre les traitements idempotents, isoler les charges longues et fournir une preuve observable de l’exécution.
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. Odoo au cœur du SI 1UP Distribution
Un ERP central, mais plusieurs expériences et temporalités
Odoo porte les références structurantes du commerce : partenaires, produits, catégories de prix, commandes, achats, expéditions et documents financiers. La plateforme B2B ajoute des expériences spécialisées pour les clients, les commerciaux et les administrateurs, ainsi que des projections nécessaires à la disponibilité et au pilotage.
Ces deux mondes ne peuvent pas être fusionnés naïvement. L’ERP reste la source de vérité pour les objets contractuels et comptables ; l’application possède certaines données d’expérience, des états de traitement et des projections calculées. La responsabilité est définie champ par champ et flux par flux.
Les volumes et rythmes sont différents. Une fiche produit peut être lue des milliers de fois entre deux mises à jour ; une image demande un traitement de fichier ; une facture doit conserver son document ; une commande doit être créée exactement une fois ; une projection logistique doit pouvoir être reconstruite. L’architecture d’intégration traduit ces différences.
2. Cartographier avant d’automatiser
Source, déclencheur, contrat, preuve et reprise pour chaque flux
Chaque flux a été décrit par son propriétaire, sa direction, son déclencheur, son périmètre, sa stratégie de date, son identité externe, ses effets et son niveau de criticité. Cette carte évite de confondre une synchronisation de référence, une projection locale et une écriture transactionnelle.
Les lots ont ensuite été livrés verticalement et vérifiés avec des fixtures, des contrats et des environnements de validation. Le backlog Jira a traité en priorité les flux dont l’échec pouvait bloquer une commande, fausser un prix ou priver le run de diagnostic. Les intégrations n’étaient pas considérées terminées lorsqu’un appel réussissait une fois : il fallait traiter la pagination, les données absentes, les dates, les devises, les doublons, la reprise et l’observabilité.
Les replays manuels et commandes d’administration ont été conçus comme des opérations sensibles. Ils respectent le canal B2B, demandent une confirmation lorsque nécessaire et n’effacent pas l’historique. Cette discipline réduit le risque qu’une tentative de réparation crée une deuxième anomalie.
3. Les douleurs d’une intégration ERP critique
Le danger n’est pas seulement la panne : c’est la divergence silencieuse
Une panne franche se voit. Une synchronisation qui oublie quelques lignes, utilise une mauvaise fenêtre de date ou réimporte un objet sous un nouvel identifiant peut rester invisible plus longtemps. Elle finit alors dans un mauvais prix, une commande absente, un stock faux ou une facture introuvable.
Les rythmes différents créent une autre difficulté. Rafraîchir tout Odoo à chaque affichage est impossible ; accepter indéfiniment une donnée locale périmée est dangereux. Le système devait pouvoir dire quand la donnée a été acquise, quand elle doit être relue et quand un parcours doit refuser de s’engager.
Enfin, les corrections opérationnelles étaient un enjeu de premier plan. Relancer un flux sans filtre peut charger l’ERP, dupliquer des écritures ou mélanger B2B et B2C. Les outils de reprise devaient être plus sûrs que les scripts ponctuels qu’ils remplacent.
Un flux réussi n’est pas seulement un code HTTP 200. Il doit produire l’effet attendu, conserver son identité, rendre sa progression lisible et permettre une réconciliation avec la source.
La divergence silencieuse coûte plus cher qu’une panne visible
Lorsqu’un service tombe, l’organisation sait qu’elle doit interrompre ou dégrader un parcours. Lorsqu’une synchronisation semble fonctionner mais omet une page, décale une fenêtre temporelle ou associe la mauvaise devise, les décisions continuent sur une base fausse. La correction arrive plus tard, souvent après qu’une autre équipe a produit un document ou pris un engagement.
Le projet a donc recherché des preuves de cohérence, pas seulement de disponibilité : compteurs lus et écrits, identifiants externes, états terminaux, fraîcheur, anomalies métier et capacité à retrouver le lot responsable.
Pourquoi la reprise fait partie de la conception initiale
Une intégration durable doit supposer que le réseau, l’ERP ou une donnée source finiront par échouer. Si le seul plan consiste à relancer toute la synchronisation, le jour de l’incident transforme une réparation simple en risque de duplication ou de surcharge.
Chaque famille de flux a donc reçu une stratégie de reprise proportionnée : retry automatique pour un défaut transitoire, rejet visible pour une donnée invalide, replay ciblé pour une intervention et reconstruction complète lorsque la projection locale doit être recalculée.
4. Une cartographie de 25 flux Odoo
Organiser l’intégration par domaines métier
Le catalogue de flux couvre les référentiels CRM, le catalogue, les catégories tarifaires et prix, les ventes, les factures et avoirs, les achats, les réceptions, les expéditions, les paiements et les données nécessaires aux projections. Les flux sont séparés au lieu d’être enfermés dans une synchronisation monolithique.
Cette séparation permet d’adapter la fréquence et les garanties. Les produits et images n’ont pas la même stratégie que les commandes ; les documents financiers n’ont pas la même tolérance à l’échec qu’un enrichissement de catalogue ; une écriture de partenaire ou de commande exige une identité stable avant toute reprise.
Les périodes de lecture sont normalisées et propagées jusqu’aux pullers. Les traitements privilégient les objets récents lorsqu’une reprise progressive est utile. Les lots et tailles de batch sont ajustés selon le domaine pour ne pas saturer l’ERP ou la mémoire applicative.
Cette logique correspond à notre offre d’intégration API : le connecteur n’est qu’une brique ; la valeur vient de l’architecture complète des flux, de leurs contrats et de leur exploitation.
5. Définir les sources de vérité
Ne pas laisser deux systèmes décider du même fait
Odoo reste propriétaire des partenaires, des identifiants commerciaux, des documents de vente, des achats, des expéditions et de la finance. La plateforme conserve des copies de lecture, les documents nécessaires et les identifiants de réconciliation, mais ne réécrit pas l’histoire d’un objet contractuel.
L’application est en revanche propriétaire de certains états d’expérience et de traitement : onboarding, session, panier avant import, progression d’une tâche, tickets, projections de disponibilité, caches et agrégats. Ces données sont utiles parce qu’elles répondent à des besoins que l’ERP n’a pas vocation à servir en temps réel.
Lorsqu’une donnée combine plusieurs sources, le calcul est explicite. La disponibilité, par exemple, part de mouvements et engagements importés puis applique des réservations locales et des règles de diffusion. Elle n’est ni un champ Odoo recopié, ni une quantité inventée par le front.
Cette gouvernance évite les mises à jour circulaires. Elle est également documentée pour l’IA : un assistant doit savoir quel outil consulter et ne peut pas présenter une mémoire conversationnelle comme une donnée métier.
6. Mappings, identités externes et devises
Fiabiliser les relations qui survivent aux synchronisations
Les entités locales conservent des identifiants Odoo normalisés et soumis à des contraintes d’unicité. Les mappings de partenaires, produits, commandes, factures, lignes et expéditions sont isolés afin de rendre les conversions testables. Une propriété renommée dans le code ne doit pas changer silencieusement son sens externe.
Les canaux et le périmètre B2B sont propagés sur les commandes et comptes concernés. Cette information protège les tableaux de bord, les replays et le pipeline contre le mélange d’activités différentes. Les filtres ne sont pas ajoutés après coup dans une vue : ils font partie du contrat des flux.
Les devises sont des relations explicites sur les ventes, achats, factures et avoirs. Les prix et montants ne sont pas interprétés sans leur devise source. Les écarts d’arrondi et allocations sont protégés par des invariants, particulièrement dans les flux financiers.
Les adresses, contacts et lignes d’expédition sont eux aussi mappés avec leur contexte. Cette granularité permet de rapprocher une ligne de vente d’une livraison, au lieu de considérer qu’une commande entière suit toujours un seul chemin.
7. Queues, workers et orchestration asynchrone
Découpler l’expérience web des traitements longs
RabbitMQ et Symfony Messenger portent les tâches qui ne doivent pas bloquer une requête : synchronisations, imports, exports, images, reconstructions et assistants IA. Des files distinctes séparent les familles de charge et empêchent qu’un lot volumineux de catalogue bloque une écriture de vente.
Les workers disposent de politiques de retry adaptées. Une erreur temporaire peut être retentée ; une violation de contrat ou une donnée impossible doit rejoindre un état d’échec visible. Les messages transportent une identité suffisante pour retrouver le contexte sans embarquer une copie obsolète de tout l’objet.
Les crons et commandes de maintenance lancent les synchronisations périodiques, expirent les réservations et réconcilient les projections. Leur présence est documentée dans le run afin que la production ne dépende pas d’une connaissance orale.
La séparation des files fait partie de l’observabilité et de l’exploitation des intégrations : elle permet de mesurer le retard, d’isoler un incident et de reprendre sans arrêter l’ensemble du produit.
Fenêtre, pagination et canal B2B
Validation, mapping et identité externe
File dédiée, worker et retry
Écriture ou projection locale
État, métrique, réconciliation et replay
8. Idempotence, transactions et cohérence
Pouvoir rejouer sans produire deux fois l’effet métier
Les écritures sensibles utilisent des identités déterministes et contrôlent l’existence d’un objet avant d’en créer un autre. Les endpoints d’écriture de panier sont idempotents ; les imports de commande conservent les références qui permettent de reconnaître une reprise après coupure réseau.
Les transactions locales sont limitées aux effets qu’elles peuvent réellement garantir. Un commit en base ne signifie pas que l’ERP a accepté l’écriture ; l’état distingue donc préparation, envoi, confirmation et erreur. Cette modélisation empêche de déclarer une commande finalisée trop tôt.
Les messages asynchrones IA et métiers possèdent eux aussi une identité stable. Un retry ne doit pas créer un second run ou un deuxième document. Les erreurs sont enregistrées avec le contexte utile et les actions de reprise passent par les mêmes gardes que l’exécution initiale.
L’article Odoo API : éviter les doublons détaille les principes généraux ; le projet 1UP en fournit une mise en œuvre transversale.
9. Deux APIs au service de parcours distincts
Client B2B et commercial externe sans exposer le modèle interne
L’API client couvre les produits, prix, stocks, commandes, factures, avoirs et paniers dans le contexte du compte autorisé. L’API commerciale externe adapte les contrats aux usages du portefeuille et de la prise de commande. Les deux familles partagent les règles applicatives sans fusionner leurs scopes.
Les schémas décrivent les champs attendus, les erreurs et les exemples utiles. Des tests bloquent les changements incompatibles du contrat OpenAPI. Cette protection évite qu’une refactorisation interne casse silencieusement une application consommatrice.
Les contrôleurs sont minces et les mappers transforment les sorties métier. Les APIs ne renvoient pas des entités Doctrine sérialisées par défaut. Ce choix donne la liberté de faire évoluer la persistance tout en maintenant un contrat externe stable.
L’API client n’expose pas un endpoint générique qui transformerait directement n’importe quel panier en commande. Le flux de soumission reste encadré par le parcours prévu. Cette limite évite de promettre un contrat d’intégration que les règles transactionnelles ne sécurisent pas encore.
10. Fraîcheur, snapshots et réconciliation
Savoir quand une donnée n’est plus assez fiable pour engager le métier
Chaque lecture critique ne peut pas appeler Odoo, mais chaque cache ne peut pas être considéré éternellement valide. Les snapshots et dates de rafraîchissement servent à qualifier la fraîcheur. Certains parcours peuvent afficher une information datée ; un engagement de stock peut exiger une reconstruction récente.
La réconciliation compare les objets locaux et externes, récupère les changements récents et traite les annulations ou corrections. Les réceptions fournisseur annulées, les expéditions actives et les précommandes font partie des cas où une projection locale doit être revue.
Les mécanismes de rebuild permettent de repartir des événements et snapshots lorsque la cohérence l’exige. Ils possèdent des états terminaux, des protections contre les exécutions concurrentes et des tests de récupération.
Le modèle de stock est détaillé dans l’article WMS, OMS, ERP et front : quelle source de vérité pour le stock et dans le projet logistique de la série.
11. Observabilité, replays et outils d’exploitation
Diagnostiquer un flux sans deviner
Les activités API, synchronisations et files disposent de traces et d’états consultables. Les équipes peuvent identifier le flux, le compte, la fenêtre de date, la progression, l’échec et la dernière tentative. Les secrets et payloads sensibles sont filtrés pour que l’observabilité ne devienne pas une fuite.
Les replays permettent de relancer un flux Odoo avec un périmètre et une intention clairs. Les écrans et assistants qui déclenchent ces actions demandent une confirmation ; ils ne contournent pas les droits du back-office. Les enregistrements les plus récents peuvent être traités d’abord afin de rétablir rapidement la valeur opérationnelle.
Les alertes et intégrations de monitoring signalent les anomalies importantes. Le produit distingue une file en retard, un appel externe échoué, une donnée périmée et une règle métier bloquante. Cette classification accélère l’escalade vers la bonne personne.
Le run devient ainsi une capacité du produit, pas une réaction après incident. C’est l’un des apports les plus importants d’une API sur mesure pensée pour durer.
12. Sécurité des flux et actions sensibles
Protéger les données autant que leur transport
Les accès Odoo sont configurés par environnement et ne sont pas exposés aux clients. Les APIs utilisent des scopes, des rôles, des limites de débit et des contrôles de périmètre. Les refresh tokens ne peuvent pas changer de portée pour obtenir un accès supérieur.
Les opérations d’administration et replays sont réservés aux rôles prévus, protégés contre le CSRF dans le web et journalisés. Les écritures de prix sont séparées des espaces qui ne doivent pas les effectuer. Les actions à fort impact demandent une confirmation explicite.
Les dépendances sont suivies, les contrats de sécurité testés et les composants exposés soumis aux protections HTTP prévues. La CSP reste en mode report-only pendant son durcissement ; elle n’est donc pas présentée comme une enforcement complète en production.
Cette transparence évite un faux signal de maturité. La sécurité est un processus avec preuves et limites, approfondi dans le projet d’industrialisation.
13. Tests de contrats et qualité de l’intégration
Tester les frontières autant que le domaine
Les fixtures reproduisent des réponses et cas Odoo pour tester les mappings sans dépendre de l’ERP à chaque exécution. Les tests d’intégration valident la persistance, les identités, les devises, les dates et les écritures ; les tests applicatifs couvrent les erreurs et les états de reprise.
Les contrats OpenAPI et les sorties des APIs client et commerciale sont vérifiés. Une modification incompatible doit être détectée dans la CI. Les tests couvrent également les scopes, les objets hors portefeuille et les contrôleurs de refresh.
Les flux de catalogue, achats, ventes, disponibilité et logistique possèdent des tests ciblés sur leurs invariants. Les branches défensives — réponse vide, identifiant absent, date invalide, mouvement annulé — sont couvertes parce qu’elles déterminent la résilience réelle.
Cette intégration s’inscrit dans une suite de 22 991 tests et 239 326 assertions sans échec lors du contrôle de référence. Ce volume prouve l’étendue du contrôle automatisé ; il ne garantit pas à lui seul l’absence de tout incident futur.
14. Résultats obtenus et limites
Un SI plus cohérent parce que ses frontières sont explicites
Le système d’intégration donne à 1UP Distribution une circulation structurée entre Odoo et les espaces B2B. Les données sont mappées, contextualisées, datées et associées à une stratégie de reprise. Les équipes disposent d’outils pour observer et relancer plutôt que d’attendre une correction ponctuelle.
Les parcours web gagnent en réactivité grâce à l’asynchrone et aux lectures spécialisées, sans déclarer prématurément qu’une écriture externe est terminée. Les APIs peuvent évoluer derrière des contrats contrôlés et des scopes séparés.
Les limites restent visibles : certaines écritures logistiques sont volontairement soumises à confirmation humaine, la fraîcheur dépend de l’état des flux et la CSP doit encore franchir son passage d’observation à enforcement complète. Ces limites sont suivies, pas masquées.
Pour voir cette infrastructure à l’œuvre dans une transaction critique, le projet suivant détaille le cycle de commande B2B du panier à la facture.
Ce que l’exploitation peut désormais expliquer
Une donnée absente peut être qualifiée : objet non lu, contrat rejeté, message en attente, effet externe non confirmé ou projection non reconstruite. Cette distinction évite de traiter chaque incident comme un problème indifférencié entre le portail et Odoo.
Les outils de run donnent également un chemin de correction proportionné. L’équipe peut reprendre le flux ou l’objet concerné, observer le résultat puis réconcilier la source, sans improviser une requête qui contournerait les invariants du produit.
Ce que le socle ne prétend pas résoudre seul
Une architecture observable ne supprime ni les indisponibilités d’un système tiers ni les erreurs de données d’origine. Elle réduit leur rayon d’impact, révèle plus tôt les incohérences et fournit les moyens de revenir à un état maîtrisé.
Les politiques de fraîcheur, les seuils d’alerte et les autorisations de replay restent des décisions de gouvernance. Elles doivent évoluer avec les volumes, les engagements clients et la criticité réelle de chaque flux.
15. Conclusion : une intégration qui peut être opérée
Odoo relié au B2B avec des contrats, des états et des reprises
La force de ce projet n’est pas d’avoir appelé beaucoup d’endpoints. Elle est d’avoir transformé 25 flux en un système compréhensible : responsabilité des données, mappings, queues, identités, fraîcheur, observabilité, sécurité et modes de reprise.
Ce socle permet au portail, au cockpit commercial, aux commandes, à la logistique et aux assistants de travailler avec la même réalité sans exiger que chaque écran reproduise l’ERP.
Pour un chantier comparable, la page intégrateur Odoo porte l’offre commerciale. Cette étude de cas montre le niveau de profondeur nécessaire lorsque l’intégration devient le système circulatoire du métier.
