Intégration de boutique avec Odoo : flux, prérequis et contrôles

Nous connectons la boutique à Odoo selon un flux précis et l’interface disponible. La connexion suit les modèles réels de la base, les variantes et unités. Le connecteur ne doit pas supposer un schéma fixe avec les mêmes champs personnalisés partout.

Dans Odoo, la connexion suit les modèles réels, variantes et unités. Le connecteur ne doit pas supposer les mêmes champs personnalisés partout. Nous recensons les données nécessaires au catalogue, client et commande, et l’étape métier confirmant l’achat. Mises à niveau et changements de modules sont testés sur des enregistrements représentatifs, surtout avec lots, conversions de quantités ou ventes personnalisées.

Odoo 19 introduit JSON-2 API externe par HTTP avec clé API. Modèles, champs et méthodes disponibles dépendent de la base et figurent dans sa documentation dynamique. L’accès externe hébergé relève du forfait Custom. Standard et One App Free hébergés n’offrent pas le même accès. Les anciennes versions peuvent utiliser une autre interface. Un modèle personnalisé n’est pas supposé exister dans toutes les installations.

Une entreprise alimentaire vend le même produit à l’unité et par carton. La boutique conserve code de variante et unité d’achat ; la correspondance définit leur équivalence dans Odoo. Un carton n’est pas transmis comme une pièce ni converti deux fois. La commande suit le traitement métier convenu et les étapes prévues par l’application. Si un champ personnalisé change, le test révèle l’incompatibilité avant le transfert de transactions réelles.

Un scénario critique apparaît lorsqu’un champ personnalisé change et que l’envoi de commande ne correspond plus au schéma. Nous conservons référence externe et identifiant cible confirmé avant toute répétition. Nous distinguons échec d’accès, rejet métier et résultat incertain. L’opérateur doit pouvoir examiner l’enregistrement et rétablir l’état sans répéter les étapes terminées. Champs journalisés et responsable des attentes sont convenus.

Nous testons variante, autre unité et champ personnalisé modifié en environnement de test. Chaque cas documente données initiales attendues, enregistrement cible et statut client. Nous ajoutons échec de permissions et interruption de réponse. Un événement confirmé est répété pour vérifier que son effet métier ne change pas. Le procès-verbal d’acceptation définit équipe responsable et preuves de résolution.

L’étude confirme version Odoo et accès API/forfait autorisé, clé API limitée et documentation dynamique des modèles et modules réels. Avant production, nous documentons Modèles/schéma → accord de correspondance → Catalogue et variantes → boutique → Commande → confirmation métier Odoo. Nous attribuons renouvellement des accès, surveillance et corrections. Un changement de configuration ou règle métier déclenche un contrôle ciblé. Nous commençons par ce flux et ajoutons un canal après clarification de sa responsabilité et de ses scénarios d’acceptation.