Intégration ERP : connectez Odoo à tout votre écosystème

ERP intégré ou best-of-breed ?

Un ERP intégré fait tourner la finance, les stocks, les ventes et les opérations sur une seule base de données, tandis que l'approche best-of-breed consiste à choisir le meilleur outil de chaque catégorie puis à les relier entre eux. Les deux approches fonctionnent en production, mais chacune échoue à sa manière, ce qui justifie de trancher la question délibérément plutôt que de la laisser se décider toute seule au fil de trois ans de décisions d'achat.

Miser sur l'intégré rapporte beaucoup : avec une seule base de données, il n'y a aucune synchronisation à construire, aucun mapping de champs à entretenir, et plus aucune discussion sur qui a raison quand deux systèmes se contredisent. La contrepartie, c'est qu'on vit avec la version que l'ERP propose de chaque fonction, donc son CRM restera moins riche qu'un CRM dédié, et son module d'entrepôt moins riche qu'un WMS dédié.

Le best-of-breed inverse ce compromis : chaque équipe obtient l'outil qu'elle voulait vraiment, et n'importe quel composant peut être remplacé sans toucher au reste. En contrepartie, on hérite d'une couche d'intégration qui se comporte comme un vrai logiciel à part entière, avec ses responsables, sa supervision et sa ligne budgétaire, et qui, contrairement aux systèmes qu'elle relie, tombe en panne sans faire de bruit.

Une voie médiane praticable consiste à garder un noyau intégré pour tout ce qui touche à l'argent ou au stock, puis à n'ouvrir des intégrations vers l'extérieur que là où un outil spécialisé se révèle clairement meilleur et où l'échange de données reste limité. Odoo se prête naturellement à cette logique : son noyau est vraiment une base de données unique plutôt qu'un assemblage de modules rachetés, et son API reste assez ouverte pour que les bords restent accessibles.

Où les intégrations ERP échouent réellement

Un projet d'intégration échoue rarement dès la construction initiale ; c'est plutôt trois mois plus tard qu'il vacille, presque toujours pour l'une de ces quelques raisons, celles-là mêmes contre lesquelles nous concevons avant d'écrire la moindre ligne de code.

Personne ne possède le contrat de données

Un développeur de la boutique renomme un champ, le déploie un mardi après-midi, et la synchronisation se met discrètement à perdre des commandes. La bonne pratique consiste à traiter la charge utile échangée entre deux systèmes comme une interface versionnée avec un responsable nommé de chaque côté, et tout changement de schéma comme une rupture, jamais comme un simple détail.

La synchronisation n'est pas idempotente

Un délai réseau provoque une nouvelle tentative, et celle-ci crée discrètement une deuxième commande pour un client qui n'en avait passé qu'une. La solution consiste à donner à chaque écriture une référence externe que le système destinataire peut vérifier, afin que rejouer deux fois le même message ne produise toujours qu'un seul enregistrement.

Les erreurs partent dans un journal que personne ne lit

Les enregistrements rejetés finissent par disparaître dans un fichier quelque part sur un serveur, et c'est des semaines plus tard que la comptabilité tombe sur le trou. Ce qu'il faut à une intégration, c'est une file visible, où chaque échec remonte avec son motif, et quelqu'un dont le travail consiste justement à la vider.

Le flux n'a été pensé que dans un sens

Les commandes et les prix sortent sans accroc, jusqu'au jour où arrive le premier remboursement et où l'on découvre qu'aucun chemin de retour n'existe. C'est généralement avec les retours, les annulations, les expéditions partielles et les corrections de prix que la plupart des intégrations tombent sur la seconde moitié d'un cahier des charges que personne n'avait pris la peine d'écrire.

Les tests ont été faits sur des données propres

Les jeux de test présentent des références bien propres et bien formées. La production, elle, a un espace en fin de code, un client dupliqué avec une casse différente et un article archivé depuis deux ans qui traîne encore sur une commande ouverte. C'est avant la mise en production qu'une intégration doit être testée sur une copie de données réelles, pas après.

Rien de tout cela n'a rien d'exotique ou de rare, et c'est précisément pour ça que la supervision et la file d'erreurs sont chiffrées dans chaque intégration dès le départ, plutôt que reportées à une phase deux qui ne se finance jamais.

Intégration B2B et EDI

L'intégration ERP B2B recouvre généralement quelque chose de plus précis que le simple fait de relier deux applications entre elles : votre ERP doit échanger bons de commande, factures et avis d'expédition avec un partenaire dont vous ne contrôlez absolument pas le format. Dans le commerce de gros et la distribution nord-américains, ce format-là, c'est le plus souvent l'EDI, où le grand partenaire publie la spécification et où les fournisseurs n'ont qu'à s'y conformer.

L'essentiel du travail tient moins au transport lui-même qu'à la correspondance entre vos données et un standard documentaire pensé autour du processus de quelqu'un d'autre. Le bon de commande d'un distributeur, par exemple, peut porter des remises, des codes de livraison propres à chaque magasin et des exigences de conditionnement qui n'ont simplement aucun champ prévu dans une commande de vente Odoo standard, tant que personne ne l'a créé.

L'EDI expliqué aux équipes ERPMise en place EDI Odoo pour le B2B au CanadaEstimer un projet de mise en conformité EDI