#Odoo 19 open source pour PME France : guide complet 2026

Odoo 19, sorti en octobre 2025, est devenu en quelques mois la version de référence pour les PME françaises qui veulent reprendre la main sur leur ERP. Les éditeurs propriétaires historiques — SAP Business One, Sage 100, Microsoft Dynamics, Oracle NetSuite — continuent d'imposer des licences à plusieurs dizaines de milliers d'euros par an, des contrats d'hébergement hors UE et des feuilles de route que le client subit plus qu'il ne pilote. Dans le même temps, le contexte réglementaire français se durcit : facturation électronique pour les entreprises assujetties à la TVA, directive NIS2 transposée pour les entités essentielles et importantes (seuils ≥ 50 employés ou 10 M€ CA), exigences RGPD sur les bases CRM et RH.

Ce guide complet rassemble ce qu'une direction générale, un DAF ou un DSI de PME doit savoir avant d'engager un projet Odoo en 2026 : pourquoi l'open source change la donne face aux ERP propriétaires, ce qu'apporte concrètement Odoo 19 par rapport aux versions précédentes, comment migrer depuis Odoo 16/17/18 ou un autre ERP, quelles options d'hébergement et d'infogérance choisir, comment sécuriser la stack pour répondre à ISO 27001 et NIS2, et enfin comment connecter Odoo à des outils terrain comme Merlya pour les équipes mobiles. Le tout sans promesse marketing : références de version, commandes, ordres de grandeur tarifaires et points de vigilance issus de projets réels.

#1. Pourquoi Odoo open source pour une PME française en 2026

#1.1 Le coût caché des ERP propriétaires (SAP B1, Sage, Microsoft Dynamics)

Le ticket d'entrée affiché par les ERP propriétaires ne reflète qu'une partie du coût réel. Un SAP Business One, un Sage 100, un Microsoft Dynamics 365 Business Central ou un Oracle NetSuite cumulent licence par utilisateur (souvent plusieurs centaines d'euros par mois et par siège), maintenance annuelle (15 à 22 % du prix de licence selon les éditeurs), modules additionnels facturés séparément, frais d'intégration via un revendeur certifié, et coûts de sortie élevés en cas de changement d'éditeur. Sur un cycle de cinq ans, une PME de 30 à 80 utilisateurs dépasse fréquemment les 10 000 € HT de licences annuelles, avant même les coûts d'infogérance et d'évolutions.

Le second coût caché est la dépendance fonctionnelle : la feuille de route est dictée par l'éditeur, les développements spécifiques deviennent rapidement orphelins à chaque montée de version majeure, et la propriété intellectuelle du code custom appartient parfois au revendeur plutôt qu'à l'entreprise cliente. Pour une PME française, cela signifie absence de levier réel pour aligner l'ERP sur ses processus métier en évolution.

#1.2 Open source = sortie de la dépendance éditeur

Odoo est disponible en deux éditions. La version Community est 100 % open source et gratuite : code source publié sous licence LGPLv3, plus de 70 applications métier (CRM, comptabilité, gestion de stock, RH, e-commerce, helpdesk, projet, achats, MRP), une communauté de plus de 100 000 développeurs contributeurs dans le monde. La version Enterprise ajoute des modules supplémentaires (notes de frais avancées, signature électronique native, planning, certains connecteurs propriétaires) et un support éditeur direct, contre une licence par utilisateur sensiblement plus accessible que les concurrents propriétaires.

Le bénéfice clé n'est pas seulement le coût. C'est la réversibilité : le code est auditable, la base PostgreSQL est standard et exportable à tout moment, les modules custom restent la propriété de l'entreprise, et le marché de l'intégration est concurrentiel — une PME mécontente de son partenaire peut en changer sans renégocier ses licences. C'est aussi la transparence sécurité : les vulnérabilités sont publiées, corrigées en upstream, et un audit de code reste possible — contrairement à la boîte noire d'un ERP propriétaire.

#1.3 Souveraineté : hébergement France vs Odoo SH (Belgique)

La question de la souveraineté ne se réduit pas au lieu de stockage géographique. Elle couvre trois dimensions : juridiction applicable aux données (Cloud Act américain vs RGPD européen), sous-traitants techniques effectifs (les hyperscalers américains restent sous Cloud Act même via leurs filiales européennes), et capacité de réversibilité technique.

Odoo SH, l'offre cloud de l'éditeur, héberge ses bases sur l'infrastructure Odoo en Belgique. Cela répond à la contrainte UE mais reste sous influence d'un éditeur unique, avec une infrastructure standardisée qui ne convient pas toujours aux exigences sectorielles (santé, finance, défense). Pour une PME qui doit démontrer la conformité ISO 27001 ou NIS2, ou qui héberge des données sensibles (RH, R&D, contrats stratégiques), un hébergement chez un acteur français certifié — OVHcloud, Scaleway, Outscale, Hexanet, Jaguar Network — combiné à une infogérance par un intégrateur local apporte une chaîne de responsabilité plus claire. Certains acteurs offrent des certifications HDS (santé) ou SecNumCloud (qualification ANSSI) qui ne sont pas accessibles via Odoo SH.

#2. Odoo 19 : ce qui change vraiment (mai 2026)

Odoo 19 est la version stable courante depuis octobre 2025. Odoo 18 reste largement déployée sur le parc, et la migration s'étale progressivement sur 2026. Voici ce qui change réellement par rapport aux versions précédentes.

#2.1 Nouveautés majeures de la version

Refonte des Units of Measure (UoM). La version 19 simplifie la gestion des unités de mesure avec des changements structurels : suppression de la table uom.category et du champ uom_type dans uom.uom, renommage de factor_inv en relative_factor, et utilisation de relative_uom_id pour lier directement les unités entre elles. Exemple de migration de code XML pour un module custom :

<!-- Odoo 18 -->
<record id="product_uom_cubic_cm" model="uom.uom">
    <field name="name">cm³</field>
    <field name="category_id" ref="product_uom_categ_vol"/>
    <field name="factor">0.001</field>
    <field name="factor_inv">1000</field>
</record>

<!-- Odoo 19 -->
<record id="product_uom_cubic_cm" model="uom.uom">
    <field name="name">cm³</field>
    <field name="relative_factor">0.001</field>
    <field name="relative_uom_id" ref="product_uom_meter"/>
</record>

Tout module personnalisé manipulant des unités de mesure doit être revu avant montée de version.

API auto-documentée. Odoo 19 génère automatiquement la documentation de l'API depuis la base de données, ce qui réduit le temps d'intégration pour les équipes techniques qui maintiennent des modules spécifiques ou des connecteurs métier.

Agents IA intégrés. La version introduit des agents IA capables d'analyser les données commerciales et suggérer des actions (relances clients, optimisation des stocks), de générer des rapports basés sur des modèles prédictifs, et d'assister les utilisateurs via des chatbots intégrés à l'interface. L'IA peut être entraînée sur les données spécifiques à l'entreprise, mais l'usage doit être encadré côté RGPD — voir notre pillar sécurité IA.

Interface utilisateur revue. Design plus épuré, navigation simplifiée, mode sombre disponible dans tous les modules, constructeur de sites web amélioré avec de nouveaux snippets dynamiques, point de vente (POS) optimisé pour les commerces physiques (gestion des cours, presets pour la vente à emporter).

Améliorations performance. Optimisation des requêtes SQL pour une meilleure réactivité sur les bases volumineuses, gestion des droits d'accès simplifiée par fusion des règles d'accès et des privilèges, support multi-devises consolidé pour les PME exportatrices.

#2.2 Compatibilité Factur-X 2026 et facturation électronique

Odoo 19 intègre les exigences de facturation électronique pour le marché français, avec prise en charge des formats obligatoires (NF525 en cours de validation à confirmer par l'ANSSI ou la DGFiP) et de Factur-X. Pour les PME assujetties à la TVA, le calendrier de réforme française impose une bascule progressive : la version 19 d'Odoo est livrée avec les modules nécessaires pour émettre et recevoir des factures électroniques via les plateformes partenaires (PDP) et le portail public de facturation.

À noter : la conformité technique de l'ERP ne suffit pas, il faut aussi raccorder l'entreprise à une PDP agréée et adapter les processus comptables (cycle achats, validation des factures fournisseurs, archivage à valeur probante). Un partenaire d'intégration doit accompagner ce volet réglementaire.

#2.3 Modules accessibles en Community vs Enterprise

La distinction Community/Enterprise se joue surtout sur les modules transverses (RH, paie, marketing, signature). Pour une PME industrielle ou commerçante qui n'a pas besoin de ces modules, Community couvre 80 % des besoins fonctionnels. Pour une PME de services avec paie et notes de frais, Enterprise est souvent justifié.

#3. Migration vers Odoo 19 : du legacy à 19

#3.1 Depuis Odoo 16 / 17 / 18 : étapes, durée, pièges

La migration depuis Odoo 18 est la plus directe : Odoo Upgrade Service supporte le passage 18 → 19 et la majorité des modules standards migrent automatiquement. Le travail réel porte sur les modules personnalisés. Depuis Odoo 16 ou 17, il est conseillé d'enchaîner les sauts de version (16 → 17 → 18 → 19) plutôt que de tenter un saut direct, pour minimiser les ruptures sur les développements custom.

Prérequis techniques. Python 3.10 ou supérieur. PostgreSQL 17 recommandé. Serveur dédié ou cloud souverain (OVH, Scaleway, Outscale). Sauvegarde complète testée — base de données + filestore (pièces jointes) + code des modules personnalisés.

Étapes pour un environnement on-premise.

1. Nettoyage de la base source. Corriger les erreurs visibles dans l'interface d'administration, désinstaller les modules obsolètes, fermer les transactions ouvertes, purger les pièces jointes orphelines.
2. Soumission à Odoo Upgrade Service. Extraire le dump via pg_dump, soumettre via la plateforme officielle d'Odoo (nécessite un compte Odoo.com), récupérer le dump migré et le filestore retravaillé.
3. Adaptation des modules personnalisés. Odoo ne migre que le code standard. Les modules custom doivent être adaptés manuellement aux nouvelles API : refonte UoM, suppression des décorateurs obsolètes, mise à jour des appels ORM.
4. Test en staging. Restaurer la base migrée sur un environnement isolé, lancer odoo-bin -u all pour mettre à jour tous les modules, jouer les scénarios métier critiques (cycle ventes, comptabilité, inventaire, paie).
5. Bascule production. Fenêtre de coupure planifiée, généralement un week-end ou une nuit selon la taille de la base. Re-bascule possible si test post-migration KO.

Durée typique. Pour une PME de 30-80 utilisateurs avec 3 à 5 modules custom modérés : 4 à 8 semaines de bout en bout, dont 1 à 2 semaines de fenêtre de production effective. Plus la base est ancienne (Odoo 14, 15) et plus les modules custom sont nombreux, plus la durée s'allonge.

Pièges récurrents. Sauvegardes non testées (« WARN : une sauvegarde non testée est une sauvegarde inutile » — restaurez-la sur staging avant de lancer la migration). Modules custom obsolètes dont le mainteneur a disparu de la communauté. Dépendances Python incompatibles entre versions (utiliser pip list pour comparer). Permissions PostgreSQL mal alignées entre l'ancien et le nouveau serveur. Modules tiers payants dont la licence n'est plus valide pour la nouvelle version.

Pour les hébergements cloud (Odoo SH), la migration est gérée par Odoo, mais un planning reste nécessaire pour minimiser l'indisponibilité côté utilisateurs et préparer les communications internes.

#3.2 Depuis un autre ERP (Sage, EBP, SAP B1) : la reprise de données

Migrer depuis un ERP propriétaire est un projet plus structuré qu'une montée de version Odoo. Trois phases.

Phase 1 : cartographie fonctionnelle. Recenser les modules réellement utilisés dans l'ERP source, les processus métier en place, les développements spécifiques, les interfaces avec des outils tiers (banque, paie externalisée, e-commerce). Sortir du périmètre la fonctionnalité morte ou inutilisée — c'est la première source d'économie.

Phase 2 : reprise de données. Tiers (clients et fournisseurs), articles et nomenclatures, comptabilité (plans de comptes, écritures historiques sur 2 à 5 ans selon l'obligation légale), stocks (état à date de bascule), affaires en cours. Les exports natifs CSV/Excel des ERP sources sont souvent partiels — il faut prévoir un script de reprise et plusieurs itérations de test sur la base Odoo cible.

Phase 3 : double run et bascule. Période de fonctionnement parallèle où les saisies se font dans les deux systèmes, le temps de valider que la base Odoo restitue les mêmes chiffres que le système source. Le double run typique dure 1 à 3 mois.

Budget indicatif. Pour une PME industrielle de 50 utilisateurs migrant depuis SAP B1 ou Sage 100 vers Odoo 19 : 5 000 € à 15 000 € HT pour la part purement technique de migration (source : retours d'expérience partagés sur les forums Odoo), à laquelle s'ajoutent le paramétrage fonctionnel, la reprise de données, le double run et la formation utilisateurs, ce qui amène le projet global plutôt entre 30 000 € et 80 000 € HT selon la complexité. Comptez environ 1 500 € pour une session de formation adaptée aux équipes.

#3.3 Modules customs : revue compatibilité

Avant toute migration, lister exhaustivement les modules personnalisés et les évaluer selon trois critères : utilité réelle (le module est-il encore utilisé ou peut-il être retiré), équivalent standard (la fonctionnalité a-t-elle été couverte en natif dans Odoo 19), complexité de portage (l'effort de réécriture est-il proportionné au bénéfice).

Beaucoup de modules custom historiques deviennent inutiles parce que la fonctionnalité est arrivée en natif au fil des versions Odoo. Un audit modules en amont permet souvent de supprimer 30 à 50 % du patrimoine custom et d'alléger d'autant le coût de migration. Les modules conservés sont adaptés selon les changements d'API documentés dans les release notes officielles.

#4. Hébergement et infogérance Odoo

#4.1 Auto-hébergement vs Odoo SH vs prestataire France

Trois modèles coexistent.

Auto-hébergement on-premise. L'entreprise installe Odoo sur son propre serveur (physique ou virtuel) et gère elle-même la stack. Pertinent pour les PME avec une équipe IT interne compétente et des contraintes fortes de souveraineté ou de connectivité (production industrielle, sites isolés). Coût : pas de redevance d'hébergement, mais charge interne pour les sauvegardes, mises à jour, monitoring, sécurité.

Odoo SH (cloud éditeur). Hébergement géré par Odoo en Belgique, déploiement Git-based, scalabilité automatique, sauvegardes incluses. Pertinent pour démarrer rapidement sans compétence sysadmin interne. Limites : moins de flexibilité sur la configuration serveur, juridiction belge, dépendance à un fournisseur unique.

Prestataire France (infogérance dédiée). Un intégrateur français héberge Odoo chez un opérateur cloud souverain (OVH, Scaleway, Outscale, Hexanet, Jaguar Network) et assure la TMA. Pertinent pour les PME qui veulent réversibilité, conformité ISO 27001 ou NIS2, et un interlocuteur unique en français. Coût mensuel récurrent, mais SLA contractualisé et chaîne de responsabilité claire.

#4.2 Stack technique : PostgreSQL, Nginx, sauvegardes, supervision

Une stack Odoo souveraine bien dimensionnée pour une PME de 30 à 100 utilisateurs s'articule autour de :

• Base de données. PostgreSQL 17 (recommandé pour Odoo 19), réplication streaming pour la haute disponibilité, partitionnement des tables volumineuses (logs, pièces jointes), vacuum automatique réglé.
• Reverse proxy et terminaison TLS. Nginx en frontal, certificats Let's Encrypt automatisés, HSTS activé, headers de sécurité (CSP, X-Frame-Options, Referrer-Policy).
• Workers Odoo. Calibrage du nombre de workers HTTP et cron selon la charge (règle empirique : 2 workers HTTP par CPU disponible, 1 worker cron par instance).
• Sauvegardes 3-2-1-1-0. Outils open source comme Restic (chiffrement, déduplication) ou Borg (compression, vérification d'intégrité). Exemple Restic :

  restic backup /var/lib/odoo --exclude="*.log" --host odoo-prod
  

  Sauvegarde de la base PostgreSQL (pg_dump quotidien complet + WAL archiving continu), du filestore (pièces jointes), et du code des modules.
• Supervision et SIEM. Wazuh (SIEM open source) couplé à Suricata (IDS/IPS) pour la détection d'intrusions et la corrélation des événements. Exemple de règle Wazuh pour détecter les tentatives de brute force sur Odoo :

  <rule>
    <category>web</category>
    <decoded_as>odoo</decoded_as>
    <description>Multiple failed login attempts</description>
    <if_sid>31100</if_sid>
    <match>Failed login</match>
    <repeat>5</repeat>
    <timeout>300</timeout>
  </rule>
  

• Automatisation infrastructure. Ansible pour la configuration des serveurs et des déploiements applicatifs, Terraform pour le provisioning de l'infrastructure (machines, réseau, stockage objet) en mode infrastructure as code.
• Intégration continue. Pipelines CI/CD pour les mises à jour, les tests automatisés et les déploiements en staging puis production.

#4.3 Le rôle d'un infogérant ISO-compliant

La TMA (Tierce Maintenance Applicative) couvre quatre axes critiques pour la pérennité d'Odoo : maintenance corrective (résolution des bugs et anomalies), maintenance évolutive (intégration de nouvelles fonctionnalités ou adaptations réglementaires), maintenance préventive (surveillance proactive pour éviter les incidents), support utilisateur (assistance fonctionnelle et technique).

Un infogérant ISO 27001 compliant ajoute par-dessus la TMA classique : journalisation et conservation des logs sur 12 mois, plan d'audit interne et de revue de direction, gestion documentée des incidents et des changements, procédures de notification en cas de violation de données (RGPD article 33 : 72 heures à la CNIL), revue régulière des accès et des privilèges.

Critères de choix d'un infogérant Odoo :

• Maîtrise opérationnelle d'Odoo (versions récentes, modules courants, modules custom).
• Hébergement chez un opérateur français certifié.
• Outils open source pour la supervision et les sauvegardes (Wazuh, Restic, Borg).
• SLA clairs : temps de réponse, disponibilité, procédures d'escalade.
• Capacité à intervenir sur les enjeux NIS2 et ISO 27001.

M-KIS propose une infogérance Odoo open source et ISO-compliant, avec hébergement France et stack open source (PostgreSQL, Wazuh, Restic, Ansible).

#5. Sécurité Odoo : RGPD, ISO 27001, NIS2

#5.1 Hardening serveur Odoo (firewall, SSH, fail2ban)

Un serveur Odoo exposé sur Internet sans hardening sera scanné et attaqué dans les 24 heures suivant sa mise en ligne. Mesures minimales :

• Firewall. Blocage par défaut, ouverture explicite des ports nécessaires (80/443 pour le trafic HTTP/HTTPS, 22 ou port SSH custom restreint par IP source).
• SSH. Désactivation de l'authentification par mot de passe (clés uniquement), désactivation du login root direct, port SSH non standard, fail2ban configuré sur les logs SSH.
• Mises à jour. Application régulière des correctifs système (Debian/Ubuntu LTS recommandés), suivi des bulletins de sécurité Odoo officiels pour les patchs applicatifs.
• Permissions. Utilisateur Odoo dédié sans droits sudo, séparation stricte du code, du filestore et des bases.
• Logs centralisés. Tous les logs Odoo, Nginx, PostgreSQL et système envoyés vers un SIEM (Wazuh) pour corrélation et alerting.

#5.2 Sauvegardes 3-2-1-1-0

La règle 3-2-1-1-0 : 3 copies des données, sur 2 supports différents, dont 1 hors site, 1 immuable (immutable, non modifiable même par un administrateur compromis), avec 0 erreur lors du test de restauration. Restic et Borg supportent nativement le chiffrement et la déduplication. Le stockage hors site peut être un bucket S3-compatible chez un opérateur français (Scaleway Object Storage, OVH Object Storage).

Le point critique reste le test de restauration. Une sauvegarde non testée est une sauvegarde inutile. Programmer mensuellement une restauration complète sur environnement de test et valider que la base Odoo redémarre, que les modules se chargent et que les écritures comptables sont cohérentes.

#5.3 Conformité RGPD : registre, DPO, anonymisation des bases de test

Odoo héberge naturellement des données personnelles : contacts CRM (prospects, clients), salariés (module RH), candidats (recrutement). Les obligations RGPD applicables :

• Registre des traitements. Documenter tous les traitements impliquant Odoo : finalité, base légale, durée de conservation, destinataires, mesures de sécurité.
• DPO (Data Protection Officer). Désignation obligatoire pour les entreprises traitant des données sensibles à grande échelle. Recommandée pour toute PME utilisant Odoo en CRM ou RH.
• Anonymisation des bases de test. Une base copiée en environnement de staging contient les vrais clients et salariés. Mettre en place un script d'anonymisation systématique au moment du clonage (emails remplacés, téléphones randomisés, salaires neutralisés).
• Droit à l'effacement. Procédure documentée pour répondre aux demandes RGPD article 17 : suppression effective dans Odoo, dans les sauvegardes (ou conservation justifiée par une obligation légale supérieure), dans les outils tiers connectés.
• Durée de conservation. Purge automatique des contacts non actifs au-delà de la durée légale (3 ans après dernier contact commercial pour les prospects, durée légale spécifique pour les données RH et comptables).

#5.4 NIS2 : Odoo dans le périmètre « système d'information essentiel »

La directive NIS2, transposée en droit français, impose aux entités essentielles et importantes (PME atteignant ≥ 50 employés ou 10 M€ de CA dans les secteurs concernés) un ensemble d'obligations cybersécurité : gestion des risques, mesures techniques et organisationnelles, notification des incidents significatifs à l'ANSSI sous 24 heures (alerte précoce) puis 72 heures (notification détaillée).

Un ERP Odoo qui pilote la comptabilité, les ventes et la gestion des stocks d'une PME entre généralement dans le périmètre du système d'information essentiel au sens NIS2. Concrètement, cela implique : analyse de risques documentée portant sur Odoo, mesures de sécurité tracées (hardening, sauvegardes, supervision), plan de continuité et de reprise d'activité testé, procédure d'incident avec délais de notification, formation des utilisateurs et sensibilisation cybersécurité.

Vérifier votre éligibilité NIS2 et préparer la mise en conformité est une étape préalable à tout projet Odoo en 2026 pour les PME concernées. L'audit gap ISO 27001 (service M-KIS) couvre largement les exigences NIS2 quand il est mené en parallèle.

#6. Cas d'usage : Odoo + Merlya pour les TPE/PME terrain

Une part importante des PME utilisatrices d'Odoo emploie des équipes terrain qui n'ont pas vocation à passer leur journée devant un poste de travail : artisans du bâtiment, plombiers, électriciens, paysagistes, techniciens itinérants, livreurs, équipes commerciales en clientèle. Pour ces profils, la saisie dans Odoo via l'interface web ou même mobile reste un frein opérationnel — chantier, voiture, atelier ne se prêtent pas à la saisie écran.

Merlya — assistant WhatsApp/Telegram pour artisans est un produit M-KIS qui répond à ce besoin : l'artisan ou le technicien dicte ou photographie ses devis, ses factures, ses bons d'intervention, ses notes de frais directement depuis WhatsApp ou Telegram. Merlya transcrit, structure et pousse les données dans Odoo via l'API standard. Le gérant retrouve dans Odoo des écritures propres sans avoir à reprendre les notes papier ou les photos floues du téléphone.

Cas d'usage concrets :

• BTP et artisanat. Le chef de chantier dicte le compte rendu de fin de journée depuis sa camionnette, Merlya crée la fiche d'intervention dans Odoo et alimente le suivi de chantier.
• Services à domicile. L'aide-ménagère ou le technicien envoie une photo du bon signé par le client, Merlya l'attache à la facture Odoo correspondante.
• Commerce ambulant et marchés. Le vendeur dicte les ventes du jour, Merlya alimente le module ventes Odoo et déclenche la facturation.
• Équipes commerciales itinérantes. Le commercial dicte le compte rendu de visite, Merlya enrichit la fiche client dans le CRM Odoo.

L'intérêt pour une PME qui équipe ses équipes terrain : Odoo reste l'ERP de référence pour la gestion centralisée (comptabilité, stocks, paie), Merlya devient la couche de saisie naturelle pour le terrain. L'investissement Merlya se rentabilise vite : 1 à 2 heures de saisie administrative économisées par technicien et par semaine couvrent largement le coût mensuel.

#7. FAQ

Combien coûte Odoo 19 Community vs Enterprise ? Odoo 19 Community est gratuit (licence LGPLv3). Les coûts réels sont l'hébergement, l'infogérance et les développements custom. Odoo 19 Enterprise se facture à l'utilisateur par mois (tarif variable selon le contrat éditeur), avec des modules additionnels inclus (RH, paie, notes de frais avancées, eSign). Pour une PME industrielle ou commerçante sans besoin RH avancé, Community couvre 80 % des cas.

Faut-il un prestataire ou auto-héberger ? L'auto-hébergement est pertinent si l'entreprise dispose d'une équipe IT interne avec compétences PostgreSQL, Linux et sauvegardes testées. Sans cette compétence, un prestataire d'infogérance français garantit la disponibilité, la sécurité et la conformité — surtout pour les PME soumises à NIS2 ou cherchant la certification ISO 27001.

Combien de temps pour une migration depuis Sage / SAP B1 ? Pour une PME de 50 utilisateurs : 3 à 6 mois de bout en bout, incluant cartographie fonctionnelle, paramétrage, reprise de données, double run et formation. Le budget global se situe entre 30 000 € et 80 000 € HT selon la complexité fonctionnelle et le volume de données à reprendre.

Odoo est-il vraiment souverain ? Odoo est un éditeur belge, donc UE. La version Community est publiée en open source, le code est auditable, la base PostgreSQL est portable. Hébergée chez un opérateur français certifié et infogérée par un intégrateur local, l'installation est entièrement sous juridiction française et hors Cloud Act. La souveraineté dépend du choix d'hébergement, pas seulement du logiciel.

Quelle est la différence entre Odoo SH et un hébergeur France ? Odoo SH est le cloud géré par l'éditeur Odoo en Belgique. Avantage : démarrage rapide, scalabilité automatique. Limite : juridiction belge, infrastructure standardisée, dépendance à un fournisseur unique. Un hébergeur français (OVH, Scaleway, Outscale) avec un infogérant local offre plus de flexibilité, des certifications spécifiques (HDS, SecNumCloud) et une chaîne de responsabilité française complète — au prix d'une charge d'infogérance à provisionner.

Odoo 19 est-il conforme facturation électronique 2026 ? Odoo 19 intègre les modules nécessaires pour émettre et recevoir des factures électroniques au format Factur-X et se raccorder aux plateformes partenaires (PDP) du dispositif français. La conformité technique de l'ERP doit être complétée par le raccordement à une PDP agréée et l'adaptation des processus comptables. Le calendrier de réforme française impose une bascule progressive — vérifier l'échéance applicable à votre entreprise selon votre taille.

#8. Comment M-KIS accompagne vos projets Odoo

M-KIS est un cabinet de conseil basé à Maxéville (Meurthe-et-Moselle, Grand Est), positionné sur la sécurité de l'information ISO 27001, la conformité NIS2 et l'infogérance open source. L'offre Odoo couvre trois phases.

Audit et cadrage. Diagnostic NIS2 à 2 500 € HT pour évaluer l'éligibilité et la conformité de l'infrastructure Odoo existante ou cible, audit gap ISO 27001 entre 5 000 € et 12 000 € HT pour formaliser le plan de mise en conformité, audit modules custom et cartographie fonctionnelle pour les projets de migration.

Mise en œuvre. Migration Odoo 19 depuis versions antérieures ou autres ERP, paramétrage des modules métier, reprise de données, double run et formation utilisateurs, raccordement aux plateformes de facturation électronique.

Infogérance ISO-compliant. Infogérance Odoo open source hébergée en France, supervision SOC Wazuh open source à partir de 1 500 € de mise en service plus 800 € à 2 500 € par mois selon le périmètre, TMA, gestion des sauvegardes 3-2-1-1-0 testées mensuellement, support utilisateur.

Pour les PME qui équipent des équipes terrain (BTP, services à domicile, commerce ambulant, techniciens itinérants), Merlya — assistant WhatsApp/Telegram pour artisans complète Odoo en apportant la saisie vocale et photo depuis le terrain, avec synchronisation directe vers l'ERP.

Un projet Odoo 19 réussi en 2026 combine trois choses : la bonne version logicielle, une infrastructure souveraine et sécurisée, et un partenaire qui comprend à la fois les enjeux techniques et le contexte réglementaire français. M-KIS porte ces trois dimensions de manière intégrée.