Connecteur · EDI & logistique
Connecteur Odoo ↔ EDI & logistique
Ici, pas d'API REST élégante : des fichiers déposés sur un SFTP, des formats figés depuis vingt ans, et des accusés de réception qu'il faut vraiment lire.
C’est le domaine le moins glamour de l’intégration, et celui où les incidents coûtent le plus cher. Pas d’API élégante ni de documentation interactive : des fichiers déposés sur un serveur SFTP, des formats stabilisés depuis vingt ans, et des interlocuteurs qui ne changeront rien pour vous.
Ça fonctionne très bien — à condition de respecter deux règles que les intégrations bâclent systématiquement.
Règle 1 : un fichier déposé n’est pas un fichier accepté
Un flux EDI se conçoit dans les deux sens : on envoie, et on lit les retours. Le cycle de vie d’un message devient un état à part entière côté Odoo — envoyé, accusé, accepté, rejeté — avec l’erreur en clair quand il est rejeté.
Règle 2 : le rapprochement de stock avec un prestataire
Quand un logisticien détient votre marchandise, deux stocks coexistent : le sien, qui fait foi physiquement, et le vôtre dans Odoo, qui fait foi commercialement. Ils divergent toujours — casse, erreur de préparation, retour non déclaré, inventaire.
Le connecteur doit donc prévoir, dès le premier jour, un état de stock périodique du prestataire, rapproché automatiquement, avec les écarts remontés à un humain. Sans ça, l’écart se découvre à l’inventaire annuel, et il devient impossible à expliquer.
Ce qui circule, concrètement
| Flux | Sens | Rythme typique |
|---|---|---|
| Ordre de préparation | Odoo → prestataire | Plusieurs fois par jour |
| Confirmation d’expédition + suivi | Prestataire → Odoo | Plusieurs fois par jour |
| État de stock | Prestataire → Odoo | Quotidien |
| Réception attendue | Odoo → prestataire | À chaque approvisionnement |
| Commande client (GMS) | Enseigne → Odoo | Selon le contrat |
| Avis d’expédition | Odoo → Enseigne | À chaque expédition |
| Facture | Odoo → Enseigne | Selon le contrat |
Rien de tout cela n’est en temps réel, et c’est très bien : la logistique fonctionne par lots, et un lot bien tracé vaut mieux qu’un temps réel approximatif.
La grande distribution : le cas à part
Les enseignes attendent des messages normalisés. Le vocabulaire est standard, mais chaque enseigne a ses variantes : champs obligatoires supplémentaires, codes propres, règles de nommage.
D’où notre position, qui va contre notre intérêt immédiat : au-delà d’une enseigne ou deux, passez par une plateforme EDI. Elle parle le dialecte de chacun de vos clients, absorbe leurs évolutions, et Odoo n’a qu’un seul interlocuteur à connaître. Développer trois dialectes maison, c’est trois maintenances à vie pour un bénéfice nul.
Les transporteurs
Beaucoup plus simple, heureusement. Les transporteurs exposent des API : Odoo demande une étiquette, reçoit un PDF et un numéro de suivi, qui remonte sur la commande puis vers le client.
C’est le flux le plus rentable à automatiser, parce qu’il supprime une saisie manuelle par colis. Sur cent colis par jour, le calcul est vite fait.
Les limites, dites franchement
Odoo n’est pas un outil EDI. Ne comptez pas transformer l’ERP en traducteur de messages normalisés : ça finit en développement spécifique impossible à maintenir.
Les formats propriétaires ne se devinent pas. Un prestataire qui ne fournit pas de spécification écrite est un risque projet : nous demandons la spécification et des fichiers d’exemple avant de chiffrer, pas après.
Le SFTP est un point de défaillance. Clés, quotas, purges, indisponibilités : ça se surveille, avec alerte quand un dépôt échoue. Un flux qui s’arrête sans que personne ne le sache est pire qu’un flux qui n’existe pas.
Pour les places de marché, voir marketplaces ; pour la volumétrie côté Odoo, performance.
Questions fréquentes
Odoo fait-il de l'EDI nativement ?
Non, pas au sens des messages normalisés attendus par la grande distribution. C’est un chantier à part entière : soit un développement dédié, soit — plus souvent le bon choix — une plateforme EDI spécialisée qui parle à vos clients et à laquelle Odoo se connecte une seule fois.
Pourquoi passer par une plateforme EDI plutôt que de développer ?
Parce que chaque enseigne a ses variantes du même message normalisé. Développer pour trois enseignes, c’est trois dialectes à maintenir, et une quatrième qui arrivera avec le sien. La plateforme absorbe cette diversité ; Odoo n’a qu’un seul interlocuteur. Nous le disons alors que ça réduit notre part du projet.
Comment sait-on qu'un fichier a bien été traité ?
Par l’accusé de réception, et lui seul. C’est le point que la plupart des intégrations négligent : un fichier déposé sur un SFTP n’est pas un fichier accepté. Sans lecture des accusés, vous découvrez le rejet quand le client appelle pour dire qu’il n’a rien reçu.
Peut-on connecter un prestataire logistique (3PL) ?
Oui, c’est un cas fréquent. Le principe est un échange de fichiers : Odoo envoie les ordres de préparation, le prestataire renvoie les confirmations d’expédition et les numéros de suivi, et un état de stock périodique permet de rapprocher. Le rapprochement est obligatoire : les stocks divergent toujours.
Et les étiquettes transporteur ?
Les transporteurs exposent en général des API : on demande une étiquette, on reçoit un PDF et un numéro de suivi qui remonte sur la commande. C’est plus moderne que l’EDI, et beaucoup moins pénible.
Un point technique à valider ?
Décrivez le contexte : version d'Odoo, systèmes en jeu, volumétrie. Réponse d'un intégrateur sous 24 h ouvrées.