ERP et souveraineté : le comparatif 2026

Le système d'information de gestion (ERP) est le cœur opérationnel de l'entreprise. Il concentre la donnée client, la donnée fournisseur, la donnée RH, la donnée comptable et financière, la donnée produit. Choisir un ERP, ce n'est donc pas seulement choisir un logiciel : c'est choisir à qui l'on confie son patrimoine informationnel, sous quelle juridiction et avec quel niveau de réversibilité.

En 2026, dans un contexte où le Cloud Act américain, le FISA 702, les sanctions extraterritoriales et la fragmentation géopolitique remettent en cause les évidences des vingt dernières années, la question de la souveraineté ne peut plus être traitée comme un sujet secondaire de DSI. Elle est devenue une question de gouvernance et de stratégie.

Cet article n'a pas pour objet de promouvoir une solution. Son but est de poser un cadre d'analyse rigoureux et de présenter chaque grand ERP du marché avec ses forces et ses limites, pour que chaque entreprise puisse arbitrer en fonction de son propre contexte.

Note de transparence. ANOR est un cabinet de conseil et d'intégration Odoo. Nous avons néanmoins fait l'effort dans cet article d'être le plus objectif possible, en présentant de façon équilibrée les forces et les limites de chaque solution — y compris d'Odoo, dont nous connaissons par expérience les limites et les contraintes. Notre position d'intégrateur ne nous empêche pas de reconnaître qu'un autre ERP peut être le bon choix pour un contexte donné. L'objectif de ce texte est d'aider à poser les bonnes questions, pas de pousser une réponse.

Quatre axes pour évaluer la souveraineté d'un ERP

La souveraineté n'est pas une case à cocher. C'est une combinaison de plusieurs dimensions qu'il faut évaluer ensemble.

1. La juridiction de l'éditeur. Sous quelle loi l'éditeur peut-il être contraint de transmettre vos données ? Un éditeur soumis au droit américain — y compris s'il héberge en Europe — peut être contraint par le Cloud Act de fournir vos données aux autorités fédérales US, sans que vous en soyez informé.
2. La nature du code. Le code est-il propriétaire et fermé, ou bien open source, auditable et modifiable ? Un code fermé crée une dépendance à l'éditeur pour la sécurité, la maintenance, l'évolution, la migration. Un code libre garantit la réversibilité.
3. La stack technique : langage et base de données. Un ERP repose sur un langage de programmation et une base de données, qui ont chacun leur licence et leurs implications économiques.
   Certains langages sont libres et universels : Python (PSF License, libre), Java (OpenJDK sous GPL+Classpath Exception), PHP (PHP License), JavaScript. Leur vivier de développeurs est mondial, leurs outils sont gratuits, leur documentation est abondante, et les compétences sont transférables d'un projet à un autre. D'autres sont propriétaires et spécifiques à un seul éditeur : ABAP chez SAP, X++ chez Microsoft Dynamics F&O, SuiteScript chez Oracle NetSuite, Harmony (4GL) chez Divalto historique. Le vivier de compétences y est restreint, les tarifs sont élevés, les outils sont souvent payants, et les développeurs formés sur ces technos sont captifs de l'écosystème éditeur.
   La même dichotomie existe pour les bases de données. PostgreSQL (PostgreSQL License, type BSD), MariaDB et MySQL (GPL) sont libres et gratuites. Oracle Database, Microsoft SQL Server, Azure SQL Database et SAP HANA sont propriétaires et payantes. Dans certains cas, la licence de la base représente une part significative du coût total de possession de l'ERP, parfois au même niveau que la licence applicative elle-même.
   Une stack entièrement libre (langage + BDD) garantit la portabilité, la pérennité, la maîtrise du coût, et l'accès à un marché de compétences ouvert. Une stack propriétaire verrouille techniquement et financièrement, et rend les migrations futures difficiles — changer de BDD ou de langage signifie réécrire l'ERP.
4. L'hébergement. Où sont physiquement stockées les données et qui opère l'infrastructure ? Un hébergeur français comme OVHcloud, Scaleway ou Outscale offre une protection juridique différente d'AWS (Amazon), Azure (Microsoft) ou Google Cloud Platform (Google), même quand ces derniers proposent des régions européennes. Un opérateur soumis au droit américain reste exposé au Cloud Act, indépendamment de la localisation physique de ses datacenters.

Un ERP peut être européen mais propriétaire et donc verrouillé. Un ERP peut être open source mais hébergé sur un cloud américain et donc exposé. La souveraineté réelle est l'intersection de ces dimensions.

Panorama

Nous présentons les ERP en deux groupes. D'abord les solutions à cœur open source, dont le modèle change fondamentalement la relation entre l'entreprise et son éditeur. Ensuite les solutions propriétaires, dont les forces fonctionnelles sont souvent réelles, mais qui portent des risques spécifiques qu'il faut regarder en face.

ERP à cœur open source

Un ERP open source, ce n'est pas seulement un logiciel dont la licence est plus douce ou le prix plus bas. C'est un modèle de distribution qui modifie en profondeur la relation entre l'entreprise et son éditeur :

• Le code est auditable. N'importe quel intégrateur ou développeur compétent peut lire le code, vérifier son comportement, identifier un bug ou une vulnérabilité, contribuer une correction.
• Les données sont accessibles directement. Dans une base PostgreSQL, MariaDB ou MySQL standard, on peut extraire, sauvegarder, migrer ses données sans demander la permission à l'éditeur et sans dépendre de ses outils d'export.
• La réversibilité est structurelle. Si l'éditeur durcit ses conditions, change de stratégie ou disparaît, le code reste utilisable et maintenable. La communauté ou un autre prestataire peut prendre le relais.
• Le coût de sortie est maîtrisé. Pas de licence à récupérer, pas d'audit de conformité, pas de format propriétaire à déchiffrer.

Une nuance : le modèle dit open core (partie Community libre + partie Enterprise payante avec sources accessibles mais non redistribuables), pratiqué notamment par Odoo et Axelor, atténue cette pureté. La partie Enterprise reste sous licence propriétaire, même si son code est lisible. Les modèles GPL ou AGPL stricts (Dolibarr, Tryton, ERPNext, Axelor Community) offrent en revanche une ouverture totale et redistribuable.

Odoo

Profil. Éditeur belge (Ramillies). Suite ERP all-in-one open core. Community sous LGPLv3, Enterprise sous licence propriétaire avec accès aux sources. Trois modes d'hébergement officiels : Odoo Online (SaaS), Odoo.sh (PaaS sur Google Cloud Platform — GCP, le cloud d'infrastructure de Google, opérateur américain soumis au Cloud Act), On-Premise.

Forces. Couverture fonctionnelle très large (90+ modules officiels, milliers d'apps tierces). UX moderne. Stack technique 100 % libre (Python/PSF, PostgreSQL). Écosystème de partenaires mondial. Coût d'entrée modéré. Personnalisation accessible à tout développeur Python. Mode on-premise officiel et pleinement supporté, ouvrant une voie vers la souveraineté complète.

Limites. Roadmap éditeur centralisée et imposée. Cycle de versions court (sortie annuelle, support 3 ans en Enterprise) qui impose des migrations régulières et coûteuses. Politique commerciale Enterprise qui se durcit (hausses de prix). Code Enterprise non libre malgré l'accès aux sources — frontière open core souvent débattue. Coexistence avec la communauté OCA (Odoo Community Association), qui maintient un large catalogue de modules libres complémentaires : la relation entre l'éditeur et l'OCA est dynamique, parfois en discussion, et illustre la dualité du modèle open core. Profondeur fonctionnelle variable selon les modules : certains restent légers face à des spécialistes verticaux (production complexe, EAM, retail spécialisé).

Souveraineté. Logiciel : excellente (BE, stack libre). Hébergement : dépend du mode choisi — Online et Odoo.sh sur GCP donc soumis au Cloud Act, On-Premise sur cloud souverain ou propre = pleinement souverain.

Dolibarr

Profil. Projet français porté par la Dolibarr Foundation (association). Licence GPLv3. Pas d'éditeur commercial central — modèle communautaire pur.

Forces. Souveraineté maximale sur les quatre axes (FR, GPL stricte, stack libre PHP et MariaDB ou PostgreSQL, hébergement libre). Pas de licence à payer. Communauté active et pérenne. Adaptation TPE/PME excellente. Marketplace Dolistore avec modules tiers nombreux. Architecture simple, facile à maintenir.

Limites. Couverture fonctionnelle plus restreinte qu'Odoo, surtout sur industrie, multi-pays, supply chain avancée, production complexe. UX moins moderne. Profondeur fonctionnelle limitée pour ETI complexes. Écosystème de prestataires professionnels plus restreint et moins structuré. Gouvernance associative = pas de roadmap commerciale prédictible. Le modèle communautaire est une force pour la souveraineté, une faiblesse pour les acheteurs qui cherchent un engagement éditeur fort.

Souveraineté. Maximale, sur tous les axes, sans réserve.

Tryton

Profil. Fork historique d'OpenERP (2008), porté par la Tryton Foundation (présence Allemagne, Belgique, Espagne). GPLv3. Stack Python/PostgreSQL.

Forces. Architecture rigoureuse, modulaire, stable. Profondeur comptable forte. Code propre, idéal pour développeurs. Souveraineté maximale (fondation européenne, stack libre).

Limites. UX austère, peu d'investissement sur l'expérience utilisateur. Écosystème de partenaires très restreint. Documentation parfois sommaire. Marché de l'emploi limité. Coût d'expertise initial élevé.

Souveraineté. Maximale.

Axelor

Profil. Éditeur français. Suite ERP/BPM/CRM open source sous AGPLv3 (Community gratuit, Enterprise payant). Stack Java/PostgreSQL. Studio low-code intégré.

Forces. Studio low-code permettant des personnalisations sans coder. Couverture fonctionnelle large (ERP + BPM + CRM unifiés). Éditeur français. Stack libre.

Limites. Part de marché modeste face à Odoo. Écosystème de partenaires limité. Licence AGPLv3 contraignante pour les intégrations propriétaires (toute modification utilisée en réseau doit être publiée). Notoriété internationale faible. Profondeur fonctionnelle moyenne sur certains domaines spécialisés.

Souveraineté. Excellente sur les quatre axes en édition Community. Enterprise reste sous licence propriétaire (avec accès aux sources).

ERPNext (Frappe)

Profil. Éditeur indien (Frappe Technologies). GPLv3. Stack Python/MariaDB. Couverture fonctionnelle large.

Forces. Open source intégral. Stack libre. Couverture fonctionnelle large. Coût d'entrée nul. Communauté dynamique. Plateforme Frappe réutilisable pour développer d'autres applications.

Limites. Éditeur indien — éloignement géographique et culturel, pérennité de la relation contractuelle à examiner. Écosystème de prestataires européens modeste. Localisation française perfectible (compta, fiscalité, paie). Profondeur fonctionnelle moyenne sur certains domaines critiques.

Souveraineté. Bonne (Inde hors dispositif extraterritorial US, GPL stricte, stack libre). Réserve sur la localisation de l'éditeur, qui peut être un sujet pour certaines organisations européennes.

ERP propriétaires

Avant de détailler chaque solution, il faut nommer clairement les risques spécifiques au modèle propriétaire. Ces risques ne sont pas théoriques. Ils se matérialisent régulièrement dans la vie des entreprises, et ils sont structurellement absents du modèle open source.

Le risque de captivité des données. Vos données métier (clients, fournisseurs, transactions, historiques de vente, comptabilité, stocks) sont stockées dans des formats et des structures contrôlés par l'éditeur. En cas d'arrêt de contrat, de litige commercial, de changement de politique tarifaire ou de rachat de l'éditeur, récupérer ses données dans un format exploitable peut coûter très cher — et certains éditeurs facturent explicitement l'export complet, ou ne proposent que des exports partiels et dégradés, obligeant l'entreprise à payer des prestations d'extraction pour retrouver ses propres informations. Dans un modèle SaaS pur, la situation est encore plus asymétrique : les données sont chez l'éditeur, dans son infrastructure, et il détient techniquement les clés.

Le risque d'audit de licence. Les grands éditeurs propriétaires (SAP, Oracle, Microsoft, IBM) pratiquent des audits de conformité qui se soldent fréquemment par des redressements financiers significatifs, parfois en centaines de milliers ou en millions d'euros, quand l'entreprise est jugée en sur-usage de ses droits de licence — que le sur-usage soit volontaire ou résulte d'une complexité contractuelle inextricable. Ces audits sont un levier commercial autant qu'un mécanisme juridique.

Le risque de fin de support imposée. L'éditeur décide unilatéralement de la fin de vie de ses versions. SAP a fixé la fin du support d'ECC 6.0 à fin 2027 (extension payante jusqu'en 2030), contraignant ses clients à migrer vers S/4HANA sur un calendrier qu'ils n'ont pas choisi. Oracle, Microsoft, Sage ou Cegid procèdent régulièrement à des transitions similaires. Le client subit le calendrier éditeur, pas son propre rythme d'entreprise.

Le risque de hausse de prix captif. Une fois l'ERP déployé et les processus métier imbriqués, le coût de sortie est tel que l'éditeur peut augmenter ses tarifs de renouvellement ou de maintenance sans craindre le départ massif des clients. Les hausses annuelles de 5 à 20 % sur les suites SaaS propriétaires sont devenues courantes, et s'accumulent année après année.

Le risque de disparition, rachat ou pivot stratégique. Un éditeur peut être racheté (Infor par Koch, Talentsoft par Cegid, et de nombreux autres cas), avec des conséquences immédiates sur la stratégie produit, les conditions commerciales ou la feuille de route. Dans le cas extrême d'une faillite ou d'un arrêt de produit, les clients se retrouvent avec un logiciel non maintenu, sans code source accessible, et sans voie technique de sortie.

Le risque de la stack propriétaire. Lorsque le langage (ABAP, X++, SuiteScript) ou la base de données (HANA, Oracle DB, SQL Server, Azure SQL) sont eux-mêmes propriétaires, les risques ci-dessus sont démultipliés : les compétences pour maintenir le système sont rares et chères, les licences sous-jacentes s'additionnent à celle de l'ERP, et la migration vers un autre socle nécessite une réécriture complète.

Aucun de ces risques n'existe de façon structurelle avec un logiciel libre déployé sur une infrastructure maîtrisée : le code est auditable, la base de données est standard et accessible, les données sont exportables sans autorisation, et la continuité d'exploitation ne dépend pas de la bonne santé commerciale d'un éditeur unique. Le modèle propriétaire, lui, repose sur une asymétrie fondamentale : l'éditeur détient le pouvoir technique et contractuel, le client paie pour continuer à utiliser ce qu'il a déjà payé.

Cela ne signifie pas que les solutions propriétaires soient à rejeter en bloc. Leurs forces fonctionnelles, leur maturité, la profondeur de leurs écosystèmes sectoriels peuvent justifier le choix dans certains contextes. Mais ces forces se paient aux risques décrits ci-dessus, qu'il faut intégrer honnêtement à la décision.

SAP S/4HANA et déclinaisons

Profil. Référence mondiale ERP grand compte. Allemand (Walldorf), coté à Francfort et à la NYSE. Décliné en S/4HANA (grand compte), Business One (PME), Business ByDesign et GROW with SAP (mid-market SaaS).

Forces. Profondeur fonctionnelle inégalée sur finance, supply chain, production. Standard de fait dans l'industrie, l'aéronautique, l'énergie, la pharma. Écosystème mondial massif (consultants, formations, certifications, spécialistes). Capacité à supporter des organisations de très grande taille et à forte complexité réglementaire ou multi-pays.

Limites. Coût total de possession très élevé (licences, intégration, maintenance 22 % par an, ressources rares et chères). Migrations brutales et coûteuses (fin de support ECC fixée à fin 2027, extension payante jusqu'à 2030). Code propriétaire ABAP qui requiert une expertise rare. UX historiquement complexe (Fiori améliore mais ne résout pas tout). Roadmap éditeur unilatérale. Stack BDD propriétaire HANA. Audits de licence connus pour être agressifs.

Souveraineté. Partielle. Juridiction allemande favorable et RGPD natif, mais cotation NYSE, présence opérationnelle US massive et offres cloud RISE/GROW reposant largement sur AWS, Azure et GCP réintroduisent une exposition extraterritoriale par l'hébergement. La version on-premise sur infrastructure souveraine reste possible, mais à contre-courant de la stratégie commerciale actuelle de l'éditeur.

Oracle NetSuite

Profil. Pure player SaaS américain (Oracle), dominant sur le segment mid-market et ETI à dominante financière, présent en France.

Forces. SaaS pur sans gestion d'infrastructure. Internationalisation native (multi-devises, multi-pays, conformités). Reporting financier robuste. Mises à jour continues. Délai de mise en œuvre court sur les périmètres standard.

Limites. Couverture industrielle et production faible. Personnalisation contrainte par SuiteScript (langage propriétaire JavaScript-like). Coût qui croît rapidement avec le nombre d'utilisateurs et de modules. Verrouillage technique et contractuel fort sur Oracle. Stack BDD entièrement propriétaire. Oracle est historiquement connu pour ses pratiques d'audit de licence.

Souveraineté. Nulle. Éditeur US, infrastructure Oracle, Cloud Act et FISA 702 applicables.

Microsoft Dynamics 365

Profil. Suite ERP/CRM modulaire de Microsoft, hébergée sur Azure : Finance & Operations (grand compte), Business Central (mid-market), Customer Engagement (CRM).

Forces. Intégration native avec Office 365, Teams, Power BI, Power Platform. UX moderne. Écosystème de partenaires massif. Cohérence forte avec un SI déjà 100 % Microsoft. Capacité de personnalisation low-code via Power Platform.

Limites. Coûts de licence élevés et croissants. Verrouillage Azure très fort. Migrations entre versions complexes. Faible portabilité hors écosystème Microsoft. Dépendance à Power Platform pour l'extensibilité, qui devient elle-même un coût récurrent. X++ est un langage propriétaire Microsoft.

Souveraineté. Nulle. Éditeur US, hébergement Azure, Cloud Act applicable. Les offres Bleu (Microsoft + Capgemini + Orange) visent à atténuer ce risque mais ne lèvent pas l'incertitude juridique tant que la technologie sous-jacente reste sous contrôle US.

Infor CloudSuite

Profil. Suite verticalisée par industrie (mode, automobile, distribution, santé, équipements industriels). Américain, propriété de Koch Industries depuis 2020.

Forces. Verticaux métier très profonds (Fashion, Automotive, M3 industrie discrète, LN). SaaS sur AWS. Approche par best practices industrielles standardisées par secteur.

Limites. Écosystème de partenaires moins dense en France que SAP ou Microsoft. Outils de personnalisation en cours de modernisation. Coût élevé. Verrouillage AWS. Modernisation de plateforme parfois pénible pour les clients historiques.

Souveraineté. Nulle. Éditeur US, AWS, Cloud Act applicable.

Sage

Profil. Britannique, présent depuis longtemps en France. Gamme éclatée : Sage 100 (TPE/PME FR), Sage X3 (mid-market international), Sage Intacct (SaaS finance, conçu aux US), Sage Business Cloud.

Forces. Maturité produit. Conformité fiscale et sociale française très solide (compta, paie, FEC, déclarations). Forte base installée. Écosystème de prestataires français dense. Bonne réputation sur la paie et la compta.

Limites. Hétérogénéité technique entre les produits — passer de 100 à X3 = changement de logiciel, pas une montée en gamme. UX souvent datée. Stratégie commerciale qui pousse à la migration vers Intacct (conçu et opéré aux US, ce qui pose un sujet souveraineté). Coûts en croissance. Stack BDD propriétaire (SQL Server, Oracle).

Souveraineté. Bonne sur les produits historiques (UK, hors Cloud Act). À examiner produit par produit pour Intacct (US-conçu) et pour les offres SaaS (hébergement à vérifier).

Cegid

Profil. Éditeur français, fort sur certains verticaux : retail (Cegid Retail), expertise comptable et paie (Cegid Loop), HR (Cegid Talentsoft), gestion fiscale.

Forces. Verticaux très profonds. Conformité française irréprochable. Solide ancrage marché français. SaaS mature.

Limites. Peu adapté en dehors des verticaux ciblés. Hétérogénéité de la gamme issue de croissance externe. Capital largement détenu par fonds d'investissement étrangers (KKR notamment), à intégrer dans l'analyse de souveraineté capitalistique éditeur. Stack BDD propriétaire (SQL Server). Coût de licence et SaaS en croissance.

Souveraineté. Bonne sur l'axe juridictionnel (FR), avec attention à la structure capitalistique évolutive et à l'hébergement (souvent Microsoft Azure).

Divalto

Profil. Éditeur français spécialisé PME industrie, négoce et distribution. Gamme Divalto Infinity (ERP) et Divalto Weavy (CRM mobile).

Forces. Très bonne adéquation PME industrielle française. Verticaux négoce, BTP, distribution techniques. Proximité éditeur. Indépendance capitalistique française. Tarification raisonnable.

Limites. Notoriété et taille d'écosystème modestes face aux grands. Couverture internationale limitée. Migration en cours de la stack historique Harmony (4GL propriétaire) vers .NET, ce qui crée une transition technique pour les clients historiques. Stack BDD propriétaire (SQL Server).

Souveraineté. Excellente sur l'axe éditeur (FR, capital indépendant). Hébergement le plus souvent maîtrisé par le client. Stack technique en partie propriétaire.

IFS Cloud

Profil. Éditeur suédois, référence sur les industries asset-intensive et project-driven : énergie, défense, aéronautique, maintenance d'équipements, services sur sites.

Forces. Profondeur fonctionnelle EAM (Enterprise Asset Management), gestion de projets complexes, services sur le terrain. Forte présence dans la défense et l'aéronautique européennes. Juridiction suédoise. UX moderne (depuis IFS Cloud).

Limites. Coût élevé. Écosystème de partenaires moins dense en France que SAP ou Microsoft. Stack technique en partie propriétaire (Java + Oracle DB). IFS Cloud souvent déployé sur Azure, ce qui réintroduit une question d'hébergement. Capital majoritairement détenu par fonds d'investissement (EQT et Hg).

Souveraineté. Bonne au plan éditeur (Suède). À examiner sur l'hébergement (Azure courant) et sur la BDD (Oracle propriétaire).

Le piège du « cloud souverain »

Méfiance sur les offres labellisées « cloud souverain » ou « cloud de confiance ». Plusieurs hyperscalers américains ont structuré des co-entreprises avec des opérateurs français (Bleu pour Microsoft Azure avec Capgemini et Orange, S3NS pour Google Cloud avec Thales) en visant la qualification SecNumCloud de l'ANSSI. Ces montages améliorent la protection contre l'extraterritorialité, mais le débat juridique reste ouvert sur leur capacité à isoler totalement les opérateurs européens des injonctions américaines tant que la technologie sous-jacente reste contrôlée par les éditeurs US.

Les vrais clouds souverains au sens strict restent OVHcloud, Scaleway, Outscale (3DS Outscale, qualifié SecNumCloud), NumSpot, ainsi que les hébergeurs régionaux français qualifiés.

Tableau comparatif

ERP	Coût (licence / intégration / maintenance)	Ergonomie	Richesse fonctionnelle	Profondeur fonctionnelle	Souveraineté	Langage / BDD (licences)	Propriété des données
Odoo	€ / €€ / modérée	Excellente, moderne	Très large (90+ modules, milliers d'apps)	Variable, complétable par dev	Logiciel : excellente (BE). Hébergement : Online et .sh sur GCP, on-premise = souverain	Python (PSF, libre) + JS/OWL / PostgreSQL (libre)	Selon mode : Google (Online et .sh) ; client (on-premise)
Dolibarr	0 / € / faible	Correcte, moins moderne	Bonne TPE/PME	Limitée sur industrie et multi-pays	Maximale (FR, GPLv3)	PHP (libre) / MariaDB (GPL) ou PostgreSQL (libre)	Client (auto-hébergement libre)
Tryton	0 / €€ / modérée	Austère	Bonne, très modulaire	Profonde (comptabilité)	Excellente (fondation européenne, GPL)	Python (libre) / PostgreSQL (libre)	Client
Axelor	€ (Comm. 0, Ent. payant) / €€ / modérée	Bonne (studio low-code)	Large	Moyenne-bonne	Excellente Community (FR, AGPLv3)	Java (OpenJDK, libre) / PostgreSQL (libre)	Client
ERPNext (Frappe)	0 / € / faible	Bonne	Large	Moyenne	Bonne (Inde, GPLv3)	Python (libre) + JS / MariaDB (GPL)	Client si auto-hébergé
SAP S/4HANA	€€€€€ / €€€€€ / 22 % an	Moyenne (Fiori)	Maximale	Très profonde (finance, SCM, industrie)	Partielle (DE mais NYSE et RISE sur hyperscalers US)	ABAP (propriétaire SAP) + Java / HANA (propriétaire SAP)	Client si on-prem ; SAP, AWS, Azure ou GCP si RISE
SAP Business One	€€€ / €€€ / 18-22 % an	Moyenne	Bonne PME	Moyenne	Partielle	C# / SQL Server (propriétaire MS) ou HANA	Client ou hébergeur partenaire
Oracle NetSuite	€€€€ / €€€€ / inclus SaaS	Datée	Très large	Bonne (finance), faible (production)	Nulle (US, Cloud Act, FISA)	SuiteScript (propriétaire Oracle) / Oracle Database (propriétaire)	Oracle (US)
Microsoft Dynamics 365	€€€€ / €€€€ / inclus SaaS	Bonne (intégration Office)	Très large (F&O, BC, CE)	Variable selon module	Nulle (US, Azure, Cloud Act)	X++ (propriétaire MS) + C# / Azure SQL (propriétaire MS)	Microsoft Azure (US)
Infor CloudSuite	€€€€ / €€€€ / inclus SaaS	Bonne	Large (verticaux industriels)	Profonde (industrie discrète, mode)	Nulle (US depuis Koch Industries)	Java + Mongoose / multi-BDD, cloud AWS	Infor / AWS (US)
Sage (X3, 100, Intacct)	€€€ / €€€ / 18-22 % an	Variable, souvent datée	Bonne, éclatée entre produits	Bonne (compta et paie FR)	Bonne (UK, hors Cloud Act) ; Intacct US-conçu	4GL Sage, .NET selon produit / SQL Server ou Oracle (propriétaires)	Client (on-prem) ou Sage (cloud)
Cegid	€€€ / €€€ / variable	Variable selon produit	Forte sur verticaux (retail, expertise comptable)	Forte sur verticaux ciblés	Bonne (FR), capital fonds étrangers	.NET / SQL Server (propriétaire MS)	Client ou Cegid (souvent Azure)
Divalto	€€ / €€ / modérée	Correcte	Bonne (PME industrie et négoce)	Bonne sur ses cibles	Excellente (FR, capital indépendant)	Harmony (propriétaire) puis .NET / SQL Server (propriétaire)	Client le plus souvent
IFS Cloud	€€€€ / €€€€ / inclus	Bonne	Forte (EAM, gestion de projets, industrie)	Très profonde (industrie de process et asset-intensive)	Bonne (Suède) ; Azure courant	Java / Oracle Database (propriétaire)	Client ou IFS Cloud (souvent sur Azure)

Légende coût : € très faible · €€ modéré · €€€ élevé · €€€€ très élevé · €€€€€ premium grand compte.

Solutions souveraines à tous les niveaux

Pour qu'un ERP soit considéré souverain à tous les niveaux, quatre conditions doivent être réunies cumulativement :

1. Éditeur en juridiction non extraterritoriale (idéalement européenne).
2. Code source libre, auditable et modifiable.
3. Langage et base de données sous licence libre.
4. Hébergement maîtrisé : auto-hébergement ou cloud souverain non lié à un acteur soumis au droit US.

Solutions qui cochent les quatre cases sans réserve :

• Dolibarr (FR, GPLv3, PHP et MariaDB/PostgreSQL libres, auto-hébergement libre).
• Tryton (fondation européenne, GPLv3, Python et PostgreSQL libres, auto-hébergement libre).
• Axelor Community (FR, AGPLv3, Java OpenJDK et PostgreSQL libres, auto-hébergement libre).
• Odoo Community (BE, LGPLv3, Python et PostgreSQL libres, auto-hébergement libre).
• ERPNext (Inde, GPLv3, Python et MariaDB libres, auto-hébergement libre) — souverain au sens technique strict, sous réserve d'accepter un éditeur hors UE.

Solutions qui peuvent être souveraines sous condition :

• Odoo Enterprise on-premise sur cloud souverain (OVHcloud, Scaleway, Outscale, NumSpot) ou serveurs propres : souverain en pratique, mais avec une licence Enterprise propriétaire (accès aux sources, pas redistribuable). Odoo Online et Odoo.sh ne sont pas souverains (GCP).
• Axelor Enterprise sur infrastructure souveraine : même logique.

Solutions exclues d'une souveraineté complète :

• Tous les éditeurs américains : Oracle NetSuite, Microsoft Dynamics 365, Infor — exclus par la juridiction de l'éditeur.
• SAP, IFS, Sage, Cegid, Divalto — éditeurs hors juridiction US directe (Sage est UK, donc hors Cloud Act), mais code propriétaire et le plus souvent stack technique propriétaire (HANA, Oracle DB, SQL Server). La souveraineté est partielle, jamais complète.

Conclusion

La souveraineté est une question de risque assumé. Choisir un éditeur américain, c'est accepter le risque extraterritorial en échange d'une maturité produit, d'un écosystème dense et souvent d'une intégration fluide avec d'autres outils US. Choisir un éditeur propriétaire européen, c'est limiter le risque juridictionnel mais conserver une dépendance économique et technique forte vis-à-vis d'un éditeur unique, avec les risques spécifiques du modèle propriétaire (captivité des données, audits de licence, fins de support imposées, hausses tarifaires captives). Choisir un open source européen, c'est obtenir le contrôle complet du logiciel, des données et de l'hébergement, en échange d'un investissement initial supérieur en compétences et en intégration.

Aucune solution n'est universellement bonne. Le bon ERP est celui qui correspond simultanément au métier de l'entreprise, à sa taille, à sa culture, à sa capacité d'investissement, à son écosystème existant et à son niveau d'exigence souveraine.

La grille proposée ici n'a pas vocation à pousser une réponse, mais à objectiver les axes du choix. Une organisation peut, en toute lucidité, choisir SAP pour sa profondeur fonctionnelle malgré sa souveraineté partielle, ou Microsoft Dynamics pour sa cohérence avec son SI Office malgré l'exposition Cloud Act. Ce qui compte, c'est que ce choix soit conscient, documenté et révisable — et que les risques du modèle propriétaire soient intégrés à la décision plutôt qu'ignorés.

Choisir son ERP, c'est choisir sa dépendance. Autant la choisir avec lucidité.