Comment connecter Odoo à SAP : méthodes, coûts et pièges

Un groupe industriel, SAP au siège, trois filiales sous Odoo, et une personne qui recopie chaque lundi matin les commandes d'un système vers l'autre. Le fichier s'appelle « commandes_S32_v4_final.xlsx ». Il contient 180 lignes, deux erreurs de code article et un doublon que personne ne verra avant la clôture. Cette situation est extrêmement courante dans les groupes qui ont racheté des PME sans les basculer sur le SAP maison.

La question « comment connecter Odoo à SAP » arrive presque toujours à ce moment précis : quand le volume recopié devient trop élevé pour la personne qui le fait, et pas encore assez visible pour justifier un projet d'architecture. Elle arrive aussi dans l'autre sens, quand une direction financière veut garder SAP pour la consolidation et laisser les opérations basculer sur un outil plus léger. Dans les deux cas, la réponse technique est connue. C'est la réponse organisationnelle qui manque.

Cet article couvre les configurations réelles de coexistence, les méthodes de connexion disponibles de chaque côté avec leurs limites, les objets à synchroniser et dans quel sens, les fourchettes de coût, et les points de rupture qu'on retrouve sur la plupart des projets. Il se termine par la question que peu de prestataires posent : dans quels cas il vaut mieux ne pas connecter les deux systèmes du tout.

Trois configurations réelles où Odoo et SAP coexistent

Avant de choisir une méthode, il faut nommer la configuration. Les trois cas ci-dessous n'appellent ni les mêmes flux, ni le même budget, ni la même durée de vie pour l'interface.

SAP au siège, Odoo dans les filiales

C'est le cas le plus fréquent en France sur les groupes de taille intermédiaire. Le siège pilote la consolidation, les achats cadres et le référentiel produit dans SAP. Les filiales, souvent entre quinze et deux cents personnes, ont besoin d'un ERP (progiciel de gestion intégré) qu'elles peuvent paramétrer elles-mêmes sans passer par une file de tickets groupe. Odoo y répond bien sur les ventes, les stocks et la production.

Le flux est alors majoritairement descendant pour les données de référence, et remontant pour les résultats : les articles et les tiers viennent de SAP, les écritures et les stocks repartent vers SAP. C'est exactement le schéma que nous détaillons sur notre page dédiée à l'intégration SAP et Odoo, qui porte l'offre pour ce type de groupe.

SAP pour la finance, Odoo pour l'opérationnel

Ici, il n'y a qu'une seule entité juridique. SAP tient la comptabilité générale et analytique, parfois depuis quinze ans, avec un paramétrage que personne ne veut toucher. Odoo prend les ventes, les achats, l'entrepôt ou la fabrication, parce que le module SAP correspondant coûte trop cher à faire évoluer ou qu'il n'a jamais été déployé.

Le flux est plus étroit mais plus critique : ce sont les écritures et les rapprochements qui circulent. Une erreur de mapping sur un compte se voit à la clôture, pas avant. Si vous êtes dans ce cas, la question du périmètre comptable mérite d'être tranchée en amont, ce que nous abordons dans notre approche de la comptabilité sous Odoo.

Migration progressive de SAP vers Odoo

Troisième cas : l'interface n'est pas une cible, c'est un échafaudage. L'entreprise a décidé de sortir de SAP mais refuse le basculement en une nuit, souvent pour de bonnes raisons. On connecte alors les deux systèmes le temps de basculer module par module, ou entité par entité.

La conséquence est structurante pour le budget : une interface temporaire ne se conçoit pas comme une interface définitive. On accepte des flux plus grossiers, on tolère une reprise manuelle sur les cas rares, et surtout on se donne une date de retrait. Sans cette date, l'échafaudage devient permanent et coûte chaque année. Les arbitrages de séquencement sont détaillés dans notre article sur la méthode et le coût d'une migration ERP.

Décider ce qui circule, dans quel sens, et qui fait autorité

La première réunion technique d'un projet d'interface Odoo et SAP ne devrait pas parler de protocole. Elle devrait produire un tableau : quels objets circulent, dans quel sens, à quelle fréquence, et lequel des deux systèmes fait autorité en cas de désaccord. Ce dernier point est le plus important et le plus souvent esquivé.

Un objet sans système maître désigné produit tôt ou tard deux versions de la vérité. Le jour où un article existe avec deux libellés et deux prix, personne ne sait lequel corriger, et l'interface est accusée d'un problème qu'elle n'a pas créé.

Objet	Système maître habituel	Sens du flux	Fréquence courante	Difficulté
Articles et nomenclatures	SAP	SAP vers Odoo	Quotidienne ou à l'événement	Élevée : codification et unités
Clients et prospects	Variable selon le cas	Bidirectionnel ou Odoo vers SAP	À l'événement	Moyenne : doublons et adresses
Fournisseurs	SAP	SAP vers Odoo	Quotidienne	Faible à moyenne
Commandes de vente	Selon l'implantation de SAP OMS	Souvent SAP vers Odoo	Temps réel ou par lot horaire	Élevée : statuts et reliquats
Mouvements de stock	Odoo si l'entrepôt est chez lui	Odoo vers SAP	Par lot, souvent la nuit	Élevée : volumétrie
Écritures comptables	SAP	Odoo vers SAP	Quotidienne ou mensuelle	Élevée : plans comptables
Plan comptable et axes analytiques	SAP	SAP vers Odoo	À l'initialisation puis rare	Moyenne : profondeur des axes
Tarifs et conditions	SAP	SAP vers Odoo	Hebdomadaire	Moyenne : règles de calcul

Ce tableau est un point de départ, pas une norme. Sur un groupe où l'entrepôt est piloté par Odoo et la facturation par SAP, la colonne « système maître » change pour au moins trois lignes. Le sujet plus large de l'ouverture d'Odoo vers l'extérieur est traité dans notre guide sur les API et connecteurs pour intégrer Odoo à vos outils existants.

Qu'est-ce qu'Odoo sait exposer à un système tiers ?

Odoo expose l'intégralité de ses modèles métier par API, par modules connecteurs et par un framework d'intégration communautaire. L'ouverture est native et documentée, et c'est rarement là que se situe la contrainte technique.

Historiquement, Odoo expose ses modèles via XML-RPC et JSON-RPC : on s'authentifie avec une clé d'API, puis on appelle directement les méthodes de l'ORM (la couche qui relie les objets métier à la base de données), notamment search_read, create, write et unlink. Ces méthodes sont décrites dans la documentation de l'ORM Odoo. Depuis Odoo 19, l'éditeur documente une API externe JSON-2 et fournit un guide de migration depuis XML-RPC et JSON-RPC. Concrètement : si vous démarrez une interface aujourd'hui sur une version récente, posez la question du protocole cible dès le cadrage, pour ne pas écrire un connecteur sur une base que vous devrez reprendre à la prochaine montée de version.

Trois autres voies existent côté Odoo. Les modules connecteurs publiés sur l'Odoo Apps Store couvrent des périmètres étroits, souvent un domaine unique comme les données RH, et supposent que votre modèle de données ressemble à celui pour lequel ils ont été écrits. Le framework OCA connector, maintenu par l'Odoo Community Association, apporte ce qu'un développement rapide oublie systématiquement : une file de jobs asynchrones, un mécanisme de mapping et une gestion des erreurs rejouables. Enfin, les actions automatisées d'Odoo permettent de déclencher un appel sortant sur un événement, ce qui convient à des volumes faibles et pas au-delà.

La limite côté Odoo n'est donc pas l'accès aux données. C'est la charge : un appel unitaire par enregistrement sur cinquante mille articles bloque une base de production. Traitez par lots et paginez systématiquement, dès la première ligne de code.

Par quels mécanismes SAP échange-t-il avec l'extérieur ?

SAP échange par IDoc pour les flux de masse, par BAPI pour les appels unitaires confirmés, et par services OData sur les versions récentes. Reste à clarifier de quel SAP on parle, car le mot recouvre des produits très différents : SAP ECC et S/4HANA pour les grands comptes et les ETI, SAP Business One pour les structures plus petites, sans compter les briques cloud spécialisées. Les mécanismes d'échange ne sont pas les mêmes, et un chiffrage établi sur l'un ne vaut rien sur l'autre. Si votre comparaison porte sur la version PME, notre comparatif Odoo et SAP Business One détaille les écarts fonctionnels.

Sur ECC et S/4HANA, deux mécanismes historiques dominent. Les IDoc (Intermediate Documents) circulent via ALE (Application Link Enabling), la couche d'intégration asynchrone de SAP. SAP indique explicitement qu'ALE permet d'intégrer des processus entre systèmes SAP et non SAP, comme le décrit sa documentation officielle sur la technologie ALE. Un IDoc est un message structuré, typé, déposé et traité de façon asynchrone, avec un suivi de statut. C'est le mécanisme le plus adapté aux flux de masse : articles, commandes, mouvements.

Les BAPI (Business Application Programming Interface) sont l'autre voie : des modules fonctionnels appelables à distance, rattachés à des objets métier SAP, décrits dans la documentation SAP sur les BAPI. L'appel est synchrone : on obtient une réponse immédiate, donc une confirmation ou une erreur exploitable tout de suite. C'est le bon choix pour une création unitaire qui doit être confirmée à l'utilisateur, et le mauvais choix pour un déversement nocturne de cinquante mille lignes.

Sur S/4HANA, des services OData exposent une partie des objets de façon plus moderne, ce qui simplifie l'écriture côté Odoo. Reste la voie la plus ancienne et toujours très utilisée : le dépôt de fichiers structurés sur un serveur d'échange, à heure fixe. Elle a mauvaise réputation. Elle est pourtant parfaitement défendable sur des flux quotidiens non critiques, à condition d'accepter sa contrepartie, sur laquelle nous revenons plus bas.

Le vrai point de friction côté SAP est rarement technique. Il est contractuel et humain : obtenir un accès, un environnement de test représentatif et du temps d'un consultant SAP interne ou d'un prestataire tiers. C'est le poste qui décale les plannings, pas le développement.

Le cas SAP OMS : connecter la gestion des commandes

Une part des recherches sur ce sujet nomme SAP OMS, appellation de marché qui recouvre en réalité plusieurs briques de gestion des commandes selon l'édition SAP concernée. La configuration est claire : SAP centralise la prise de commande, la promesse de livraison et parfois l'allocation de stock, tandis qu'Odoo exécute la préparation, l'expédition et la facturation opérationnelle.

Le flux nominal tient en quatre étapes. La commande naît dans SAP OMS et descend vers Odoo, où elle crée un bon de commande et un ordre de préparation. L'entrepôt prépare et expédie sous Odoo, avec les outils de gestion des stocks et des mouvements. Odoo renvoie la confirmation d'expédition, les quantités réellement servies et les numéros de suivi. SAP met à jour le statut de la commande et déclenche la suite, facturation ou consolidation.

Trois détails font échouer ce schéma plus souvent que le reste. Le premier est la gestion des reliquats : si SAP attend une réponse partielle ligne par ligne et qu'Odoo raisonne par expédition complète, les statuts divergent dès la première rupture de stock. Le deuxième est l'annulation : une commande annulée dans SAP après préparation dans Odoo doit produire une action explicite, pas un silence. Le troisième est l'autorité sur le stock. Si SAP alloue et qu'Odoo décrémente, il faut décider lequel des deux a raison quand un colis casse au quai, et écrire ce cas dans les spécifications avant de développer.

Ce sont des cas de figure à dérouler en atelier, avec les personnes qui préparent les commandes, pas seulement avec la DSI. Une demi-journée passée là évite plusieurs semaines de correctifs.

Quelle architecture choisir, et à quel budget ?

Quatre grandes façons de relier les deux systèmes coexistent, de l'échange de fichiers à quelques jours jusqu'au connecteur sur mesure dans une fourchette indicative de 2 000 à 15 000 €. Aucune n'est meilleure dans l'absolu : le choix dépend du volume, de la criticité, et de qui devra maintenir l'ensemble dans deux ans.

Approche	Principe	Coût indicatif	Délai courant	Limite principale
Échange de fichiers	Dépôt de CSV ou XML sur un serveur, import planifié des deux côtés	Le poste le plus bas du spectre	Quelques jours à deux semaines	Aucun retour d'erreur en temps réel, rejeu manuel
Connecteur sur mesure point à point	Module Odoo qui appelle IDoc, BAPI ou OData, avec file de jobs	2 000 à 15 000 € indicatifs selon le nombre de flux	2 à 8 semaines	Maintenance à votre charge à chaque montée de version
Middleware iPaaS	Plateforme d'intégration tierce qui orchestre les deux côtés	Abonnement selon le volume de messages, grille de l'éditeur retenu	Variable selon la maturité de l'équipe	Dépendance et coût récurrent qui croît avec le volume
Module du marché	Connecteur publié couvrant un périmètre prédéfini	Prix éditeur, à vérifier sur la fiche du module	Rapide si le périmètre correspond	Périmètre figé, adaptations souvent impossibles

La fourchette de 2 000 à 15 000 € pour un connecteur sur mesure, sur deux à huit semaines, est indicative et large pour une raison précise : elle recouvre aussi bien un flux unique unidirectionnel qu'un ensemble de six flux bidirectionnels avec reprise sur incident. Le nombre de flux et le nombre de champs mappés expliquent l'essentiel de l'écart. Le protocole retenu, presque rien.

Un point de méthode qui fait gagner du temps : chiffrez flux par flux, pas au forfait global. Un projet découpé en six lots se négocie, se priorise et se met en production progressivement. Un forfait global se subit.

Les points de rupture qu'on retrouve sur presque tous les projets

Les échecs d'interface entre Odoo et SAP se ressemblent beaucoup. Voici ceux que nous voyons revenir, dans l'ordre de fréquence.

Le référentiel articles ne coïncide pas

SAP porte un code matière avec une logique de codification définie il y a dix ou quinze ans. Odoo a été déployé avec des références lisibles par les commerciaux. Entre les deux, il n'y a pas de correspondance parfaite : des articles SAP n'existent pas dans Odoo, des variantes Odoo correspondent à un seul code SAP, des articles obsolètes traînent des deux côtés.

Le travail à faire relève de la gouvernance : qui crée un article, selon quelle règle, et ce qu'on fait des orphelins. Tant que ces trois réponses ne sont pas écrites, le meilleur connecteur du marché ne fera que propager la confusion plus vite.

Les unités de mesure

Odoo gère les unités et leurs conversions dans une catégorie commune. SAP distingue unité de base, unité de commande et unité de vente, avec des facteurs de conversion par article. Quand SAP stocke en kilogrammes et vend en cartons de douze, et qu'Odoo raisonne en pièces, une interface naïve produit des quantités fausses sans jamais lever d'erreur.

C'est le type de défaut qui passe la recette et se voit trois mois plus tard sur un inventaire. Testez les conversions sur des articles réels aux unités atypiques, pas sur un jeu de test propre.

Deux plans comptables qui ne parlent pas la même langue

Le plan SAP du groupe est souvent international et calé sur les besoins de consolidation. Le plan Odoo de la filiale française suit le plan comptable général. Il faut donc une table de correspondance, et elle n'est jamais bijective : plusieurs comptes Odoo pointent vers un compte SAP, certains comptes SAP n'ont pas d'équivalent.

Ajoutez les axes analytiques, qui n'ont pas la même profondeur des deux côtés, et la TVA, qui ne se code pas de la même façon. Cette table de correspondance doit être validée par la personne qui signe la liasse, pas par un développeur.

La volumétrie et les fenêtres de traitement

Une interface qui tourne bien sur mille lignes peut s'effondrer sur cent mille. Le point de bascule dépend du protocole et de la façon dont les appels sont écrits, mais le symptôme est constant : le traitement nocturne déborde sur les heures ouvrées et ralentit la production.

La bonne pratique est de mesurer tôt, sur un volume représentatif de votre pic annuel et pas de votre mois moyen. Vérifiez-le sur votre instance avant de vous engager : découvrir le plafond en recette coûte un report de mise en production.

Le rejeu après incident

Une interface tombe. Le réseau coupe, SAP est en fenêtre de maintenance, un champ obligatoire a changé. Toute la question tient à ce qui se passe ensuite. Sans clé d'idempotence (un identifiant qui garantit qu'un même message traité deux fois ne crée pas deux enregistrements), le rejeu produit des doublons.

Sans file de jobs et sans journal consultable par un utilisateur métier, personne ne sait ce qui est passé et ce qui manque. C'est précisément ce qu'apporte un framework comme celui de l'OCA, et c'est ce qu'un développement rapide écrit en trois jours ne contient jamais. Un connecteur sans rejeu n'est pas un connecteur moins cher, c'est un connecteur non terminé.

Les droits d'écriture et la traçabilité

Écrire dans SAP depuis Odoo suppose un compte technique, des autorisations, et une trace de qui a fait quoi. Les équipes SAP sont légitimement prudentes sur ce point, surtout sur les objets financiers. Anticipez ce sujet dès le premier atelier : c'est fréquemment lui qui décale la mise en production de plusieurs semaines.

Ce que coûte l'interface, à la construction et au fil de l'eau

Le budget d'une interface se lit en deux temps. La construction, qu'on chiffre facilement. L'exploitation, qu'on oublie presque toujours, et qui finit par dépasser la construction sur la durée de vie du dispositif.

Poste	Ce qu'il recouvre	Ordre de grandeur
Cadrage et cartographie des flux	Ateliers, choix des systèmes maîtres, spécifications de mapping	Quelques jours, à provisionner avant tout chiffrage ferme
Développement du connecteur	Module Odoo, appels SAP, file de jobs, journalisation	2 000 à 15 000 € indicatifs, 2 à 8 semaines
Nettoyage du référentiel	Dédoublonnage articles et tiers, unités, comptes	Dépend de l'état des données, poste le plus sous-estimé
Environnements et accès SAP	Comptes techniques, bac à sable, temps du consultant SAP	Souvent porté par le groupe, à négocier tôt
Licences middleware éventuelles	Abonnement iPaaS si cette voie est retenue	Grille de l'éditeur, indexée sur le volume
Supervision et corrections	Surveillance des files, reprise d'incidents, montées de version	À inscrire dans un contrat de maintenance

L'essentiel de la facture part dans l'alignement du référentiel, sans lequel le connecteur n'a aucun sens. Une entreprise qui arrive avec des articles propres et un mapping comptable validé sort dans le bas de la fourchette. Une entreprise qui découvre pendant la recette que trois cents articles existent en double sort dans le haut, et avec un mois de décalage.

Sur le volet récurrent, une interface entre deux ERP n'est pas un dispositif qu'on installe et qu'on oublie. Odoo publie une version majeure par an, SAP applique ses propres correctifs, et chaque changement de champ des deux côtés peut casser un mapping. Ce point est développé dans notre article sur le support et la maintenance applicative sous Odoo. Pour situer l'interface dans un budget Odoo complet, notre analyse du coût réel d'un projet Odoo donne le cadre général.

Dans quels cas vaut-il mieux ne pas connecter Odoo et SAP ?

Cinq situations rendent l'interface plus coûteuse que le problème qu'elle prétend résoudre : un volume trop faible, des périmètres qui se recouvrent, un remplacement plus sain, un SAP qui doit rester seul, et une interface qui sert à éviter une décision. Un intégrateur a un intérêt évident à vendre une interface, et nous les détaillons quand même.

Quand le volume ne le justifie pas. Vingt commandes par semaine recopiées à la main représentent environ une heure de travail hebdomadaire. Un connecteur, même dans le bas de la fourchette, plus sa maintenance, met plusieurs années à devenir rentable sur ce volume. Le seuil se situe bien plus haut, et il dépend surtout du taux d'erreur de la saisie manuelle, pas du nombre de lignes. Si la recopie ne produit pas d'erreurs coûteuses, elle n'est pas le problème.

Quand les périmètres se recouvrent. Si SAP et Odoo gèrent tous les deux les commandes, tous les deux les stocks et tous les deux la facturation, l'interface ne résout rien : elle fige une redondance et vous oblige à maintenir deux paramétrages qui doivent rester cohérents. C'est une double maintenance permanente, avec une charge qui augmente à chaque évolution métier. Dans ce cas, la bonne décision est de trancher les périmètres avant de parler technique.

Quand remplacer est plus sain que connecter. Une filiale unique sur un SAP peu paramétré, sans exigence de consolidation complexe, n'a souvent aucun intérêt à maintenir deux systèmes. Un déploiement Odoo complet avec reprise de l'historique, dans la fourchette indicative de 15 000 € et plus sur deux à trois mois pour une configuration multi-sociétés et multi-devises, revient parfois moins cher sur trois ans qu'une interface plus sa maintenance et deux jeux de licences. Le calcul se fait sur la durée, pas sur le devis initial.

Quand SAP doit rester seul. Symétriquement, certains contextes ne gagnent rien à ajouter Odoo. Une industrie très réglementée dont les processus qualité sont validés dans SAP, avec des audits qui portent sur ces processus, paiera la revalidation bien plus cher que le confort d'usage gagné. Là, SAP garde l'avantage, et le dire honnêtement fait partie du travail.

Quand l'interface sert à éviter une décision. C'est le cas le plus fréquent et le moins avouable. Deux directions ne s'accordent pas sur l'outil cible, alors on connecte les deux en attendant. L'interface devient l'arbitre technique d'un désaccord politique, et elle vivra aussi longtemps que le désaccord. Ce n'est pas un projet SI, et aucun connecteur ne le réglera.

Cadrer le projet : ce qu'on teste avant de développer

Quand la décision de connecter est prise, cinq étapes évitent l'essentiel des mauvaises surprises. Elles ne coûtent presque rien comparées à leur effet sur le reste du projet.

• Inventorier les objets et désigner un système maître pour chacun. Un tableau signé par les deux directions, pas un compte rendu de réunion.
• Extraire des données réelles des deux côtés. Cent articles pris au hasard dans SAP, cent dans Odoo, et une tentative de rapprochement manuel. Le taux d'échec de cet exercice prédit assez bien la charge de nettoyage à venir.
• Prototyper un flux unique de bout en bout. Un seul objet, un seul sens, sur un environnement de test. L'objectif est de faire remonter les champs obligatoires que personne n'avait mentionnés, le protocole se validant tout seul en chemin.
• Tester le rejeu et l'échec. Couper la connexion en plein traitement, puis relancer. Vérifier qu'aucun doublon n'apparaît et que le journal indique clairement ce qui manque. Menez cet essai pendant le prototype, quand corriger ne coûte encore rien.
• Prévoir une période de double contrôle. Pendant quelques semaines, on compare les deux systèmes sur les objets critiques. C'est fastidieux, et c'est la seule façon de détecter les écarts silencieux, ceux qui ne lèvent aucune erreur.

Ces étapes valent aussi pour d'autres environnements du même type. Notre article sur la connexion entre Odoo et Microsoft Dynamics 365 décrit une démarche comparable avec des mécanismes techniques différents. Pour les définitions générales, notre fiche sur l'intégration ERP pose le vocabulaire.

Questions fréquentes

Comment connecter Odoo à SAP OMS concrètement ?

La commande descend de SAP OMS vers Odoo par IDoc ou par service, crée un bon de commande et un ordre de préparation, puis Odoo renvoie la confirmation d'expédition avec les quantités servies. Les trois points à spécifier avant tout développement sont la gestion des reliquats, le traitement des annulations tardives et l'autorité sur le stock alloué.

Quels sont les inconvénients d'Odoo dans une architecture avec SAP ?

Odoo change de version majeure une fois par an, ce qui impose de vérifier chaque connecteur à chaque montée, et son modèle de données est plus souple que celui de SAP, donc plus facile à laisser dériver. En revanche il s'ouvre plus facilement et se paramètre sans passer par une file de tickets groupe, ce qui explique sa place en filiale.

Quels sont les problèmes rencontrés avec une interface Odoo et SAP ?

Les trois plus fréquents sont un référentiel articles qui ne se recouvre pas, des unités de mesure converties silencieusement de travers, et l'absence de mécanisme de rejeu après incident. Aucun des trois n'est un problème de protocole, tous se détectent en phase de cadrage si on extrait des données réelles.

Quel langage de programmation utilise Odoo pour un connecteur ?

Le cœur d'Odoo est écrit en Python, avec du XML pour les vues et les données de paramétrage. Un connecteur prend donc la forme d'un module Python installé dans Odoo, ou d'un service externe qui appelle l'API d'Odoo depuis n'importe quel langage.

Combien coûte un connecteur entre Odoo et SAP ?

Pour un développement sur mesure, comptez une fourchette indicative de 2 000 à 15 000 € sur deux à huit semaines, l'écart s'expliquant par le nombre de flux et de champs mappés bien plus que par le protocole. À cela s'ajoutent le nettoyage du référentiel et la supervision, deux postes qui ne figurent presque jamais dans le devis initial.

Faut-il un middleware ou un développement direct ?

Un middleware se justifie quand vous connectez plus de deux systèmes, quand vos équipes savent l'administrer, et quand le coût récurrent est accepté à l'avance. Pour deux systèmes et quelques flux stables, un connecteur direct bien construit, avec file de jobs et journalisation, revient généralement moins cher sur trois ans.

Peut-on connecter Odoo à SAP Business One de la même façon ?

Non, les mécanismes diffèrent : SAP Business One n'expose pas les IDoc et les BAPI de l'univers ECC et S/4HANA, mais ses propres interfaces. Un chiffrage établi pour S/4HANA ne se transpose donc pas, et la question du remplacement pur et simple se pose plus souvent sur cette gamme.

En résumé

Connecter Odoo à SAP est un problème résolu sur le plan technique. Odoo expose ses objets par API et par framework de connecteur, SAP par IDoc, BAPI et services, et ces mécanismes fonctionnent depuis des années dans les deux sens. Ce qui décide de la réussite se joue ailleurs : dans la désignation d'un système maître pour chaque objet, dans l'état du référentiel articles, dans la table de correspondance comptable, et dans la capacité à rejouer un flux après incident sans créer de doublons.

Le budget suit la même logique. Un connecteur sur mesure se situe dans une fourchette indicative de 2 000 à 15 000 € sur deux à huit semaines, mais c'est le nettoyage des données et la maintenance qui font l'écart réel entre deux projets comparables. Et avant tout cela, il reste la question qu'il faut poser en premier : ces deux systèmes doivent-ils vraiment coexister sur la durée. Cette question se tranche mieux à deux, avec vos volumes et vos contraintes de groupe posés sur la table. Décrivez-nous votre configuration quand vous voulez, et nous vous dirons franchement si l'interface se justifie. Nos retours de projets montrent par ailleurs des configurations proches de la vôtre.