Choisir son ERP en 2026 : pourquoi la question de la souveraineté change tout

L'ERP n'est pas un logiciel comme les autres. Il pilote la facturation, archive les contrats, conserve l'historique commercial, héberge la paie, structure la comptabilité, modélise la production. Tout ce qui fait la valeur opérationnelle d'une entreprise transite par lui. Une coupure d'ERP, c'est une journée perdue. Une perte d'ERP, c'est parfois la mort d'une société.

Cette criticité change la nature du choix. Un ERP n'est pas un outil que l'on remplace tous les deux ans. C'est un investissement à dix ou quinze ans, indissociable de l'organisation, indissociable de la donnée. Et la donnée, en 2026, est devenue un sujet politique autant qu'opérationnel. Cloud Act, FISA 702, fragmentation géopolitique, sanctions extraterritoriales, tensions entre les blocs économiques : ce qui paraissait acquis dans les années 2010 — l'idée qu'un cloud américain valait n'importe quel autre cloud — ne tient plus. Le risque juridictionnel sur les données d'entreprise est désormais un paramètre incontournable de la décision d'achat.

Cet article propose une lecture comparative de quatorze ERP du marché, organisée autour des questions de souveraineté, de coût, d'ergonomie, de richesse et profondeur fonctionnelle, de stack technique, et de propriété des données.

Avertissement. Auguria est un cabinet de conseil et d'intégration spécialisé sur Odoo. Conscients de ce biais, nous avons cherché dans ce comparatif à présenter chaque solution avec la même rigueur, en exposant ses qualités et ses faiblesses, y compris pour Odoo. Selon le contexte de l'entreprise, un autre ERP peut être le meilleur choix — et nous le disons quand c'est le cas. L'objectif n'est pas de convaincre, c'est d'éclairer.

Les risques spécifiques du modèle propriétaire

Avant d'entrer dans les axes d'évaluation, il faut nommer un point souvent passé sous silence dans les comparatifs ERP : les risques structurels du modèle propriétaire. Ces risques ne sont pas des cas isolés ni des hypothèses théoriques. Ils sont régulièrement constatés sur le terrain, et ils sont absents par construction du modèle open source.

Récupérer ses propres données peut coûter cher. Dans une solution propriétaire, en particulier en SaaS, vos données métier sont stockées dans des structures et des formats que l'éditeur contrôle. Lorsque vient le moment de partir — fin de contrat, changement d'outil, désaccord commercial — l'export complet et exploitable de votre patrimoine informationnel n'est pas toujours évident. Certains éditeurs facturent l'extraction. D'autres ne fournissent que des exports dégradés, obligeant l'entreprise à payer un prestataire pour reconstruire ses données dans un format utilisable. Il existe des cas documentés d'organisations qui ont dû verser des sommes significatives, parfois à six chiffres, simplement pour récupérer ce qui leur appartenait.

Les audits de licence sont un levier commercial. SAP, Oracle, Microsoft, IBM et plusieurs autres grands éditeurs pratiquent des audits de conformité réguliers. Le constat est connu : ces audits débouchent fréquemment sur des redressements importants, parfois en centaines de milliers d'euros voire en millions, lorsque l'entreprise est jugée en sur-usage. Le sur-usage n'est pas toujours volontaire — il découle souvent d'une complexité contractuelle inextricable, où il est difficile pour le client de savoir précisément ce qu'il a le droit d'utiliser.

L'éditeur impose son calendrier. Quand SAP fixe la fin du support de SAP ECC à fin 2027 (avec une extension payante jusqu'en 2030), des dizaines de milliers de clients dans le monde se retrouvent obligés de migrer vers S/4HANA selon un agenda qu'ils n'ont pas choisi. Le même schéma se rejoue régulièrement chez Oracle, Microsoft, Sage ou Cegid lors des transitions majeures de gamme. Le client suit le rythme de l'éditeur, pas le sien.

Les hausses de tarif sont captives. Une fois un ERP installé, les processus métier configurés, les utilisateurs formés, les intégrations en place, le coût psychologique et financier de sortie devient prohibitif. L'éditeur le sait, et augmente ses tarifs annuels en conséquence. Les hausses de 5 à 20 % par an sur les abonnements SaaS propriétaires sont devenues la norme, non l'exception. Sur dix ans, l'effet cumulé est massif.

L'éditeur peut être racheté ou disparaître. Infor a basculé sous contrôle de Koch Industries en 2020. Cegid est passé sous KKR. De nombreux acteurs du mid-market français ont changé de main au cours des cinq dernières années. Chaque rachat redéfinit la stratégie produit, les conditions commerciales et la roadmap. Dans le cas extrême d'un éditeur qui ferme ou qui arrête une ligne de produit, les clients restent avec un logiciel non maintenu, sans accès au code, et sans option claire de continuité.

La stack propriétaire amplifie tout cela. Quand le langage de développement (ABAP de SAP, X++ de Microsoft, SuiteScript d'Oracle) ou la base de données (HANA, Oracle Database, SQL Server) sont eux-mêmes propriétaires, les risques précédents se cumulent. Les compétences sont rares et chères, les licences sous-jacentes s'ajoutent à celle de l'ERP, et la portabilité devient quasi nulle.

Ces risques n'invalident pas le choix d'une solution propriétaire. Ils existent en contrepartie de qualités réelles : profondeur fonctionnelle parfois inégalée, écosystèmes industriels matures, intégrations natives avec d'autres outils. Mais une décision lucide intègre les risques autant que les forces. Les ignorer, c'est s'exposer à les découvrir au pire moment — celui où l'on voudrait justement en sortir.

Les quatre axes d'évaluation de la souveraineté

Une fois ces risques posés, la lecture des ERP s'organise autour de quatre axes complémentaires. Ils sont indépendants : un ERP peut être bon sur l'un et mauvais sur l'autre. La souveraineté complète exige de cocher les quatre.

Axe 1 — La juridiction de l'éditeur. Quel droit national ou supranational s'applique à l'éditeur ? Un éditeur soumis au droit américain — quand bien même il opère ses serveurs en Allemagne ou en France — reste exposé au Cloud Act, qui permet aux autorités fédérales américaines d'exiger l'accès à des données stockées par une entité sous juridiction US, où qu'elles se trouvent physiquement. Le FISA 702 va dans le même sens pour les communications électroniques. Un éditeur européen, à l'inverse, n'est pas soumis à ces dispositifs.

Axe 2 — Le statut du code source. Le code de l'ERP est-il propriétaire et fermé, ou bien libre, lisible et modifiable ? Un code fermé crée une dépendance fonctionnelle totale à l'éditeur : pour comprendre un dysfonctionnement, pour ajouter une fonction, pour corriger une vulnérabilité, il faut passer par lui. Un code libre permet à un intégrateur tiers ou à une équipe interne d'auditer, de corriger, d'étendre. Cette différence change radicalement la dynamique de la relation contractuelle dans le temps.

Axe 3 — La stack technique : langage et base de données. Un ERP repose sur deux briques techniques structurantes : un langage de programmation pour la couche applicative, et une base de données pour la couche de stockage. Chacune a sa propre licence et son propre marché de compétences.

Côté langages, certains sont libres et universels : Python (PSF License), Java (OpenJDK sous GPL avec Classpath Exception), PHP (PHP License), JavaScript. Les développeurs sont nombreux, les outils gratuits, la documentation abondante. Les compétences acquises sur un projet sont réutilisables ailleurs. À l'opposé, plusieurs grands ERP utilisent des langages propriétaires développés et contrôlés par leur éditeur : ABAP pour SAP, X++ pour Microsoft Dynamics F&O, SuiteScript pour Oracle NetSuite, le 4GL Harmony pour Divalto historique. Ces langages forment un marché captif : les développeurs y sont rares, leur tarif journalier est élevé, et leurs compétences sont peu transférables.

Côté bases de données, on retrouve la même fracture. 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 — parfois lourdement. Sur un déploiement ERP de taille significative, la licence de la base peut représenter une part non négligeable du coût total, parfois équivalente à celle de la couche applicative.

Un ERP construit sur une stack 100 % libre garantit la portabilité, la maîtrise des coûts à long terme, et l'accès à un marché de compétences ouvert. Une stack propriétaire ajoute une couche de verrouillage technique et financier, et rend toute migration future considérablement plus complexe.

Axe 4 — L'hébergement. Où l'infrastructure est-elle physiquement implantée, et surtout : qui l'opère juridiquement ? Un hébergeur français — OVHcloud, Scaleway, 3DS Outscale, NumSpot, ou les hébergeurs régionaux qualifiés — relève du droit français et européen. Un opérateur soumis au droit américain — AWS d'Amazon, Azure de Microsoft, Google Cloud Platform de Google — reste exposé au Cloud Act, même quand ses datacenters sont implantés à Francfort, Paris ou Londres. La localisation physique des serveurs ne suffit pas : c'est la juridiction de l'opérateur qui détermine l'exposition extraterritoriale.

Ces quatre axes sont indépendants et cumulatifs. Un ERP open source européen hébergé sur AWS perd sa souveraineté au niveau infrastructure. Un ERP propriétaire allemand déployé en on-premise sur serveurs propres conserve une souveraineté juridictionnelle, mais reste verrouillé par son code et sa stack. Seule la combinaison des quatre axes donne une souveraineté complète.

Panorama des ERP

Nous présentons les solutions en deux familles distinctes. D'abord les ERP construits autour d'un cœur open source, dont le modèle modifie en profondeur la relation entre l'entreprise et son éditeur. Ensuite les ERP propriétaires, dont la maturité fonctionnelle est souvent leur principal atout, mais qui supposent d'accepter les risques structurels exposés plus haut.

Famille 1 — Les ERP à cœur open source

Le modèle open source en ERP n'est pas seulement une question de licence ou de gratuité. Il modifie cinq paramètres fondamentaux :

• Le code peut être lu, audité et corrigé par n'importe quel développeur compétent.
• Les données sont stockées dans une base standard (PostgreSQL, MariaDB, MySQL) directement accessible sans intermédiaire.
• En cas de difficulté avec l'éditeur, n'importe quel autre prestataire peut prendre le relais.
• En cas de disparition de l'éditeur, le code reste utilisable et maintenable par la communauté.
• L'export, la sauvegarde et la migration des données ne dépendent pas de l'autorisation d'un tiers.

Une nuance s'impose néanmoins. Le modèle dit open core — pratiqué notamment par Odoo et Axelor — propose une partie Community sous licence libre et une partie Enterprise sous licence propriétaire avec accès aux sources. La partie Enterprise n'est ni libre ni redistribuable. Les modèles GPL ou AGPL stricts (Dolibarr, Tryton, ERPNext, Axelor Community) garantissent en revanche une ouverture totale.

Odoo

Description. Édité par la société belge Odoo SA, basée à Ramillies. Suite ERP all-in-one couvrant la quasi-totalité des fonctions de gestion. Modèle open core : Community sous LGPLv3, Enterprise sous licence propriétaire avec accès aux sources. Trois modes d'hébergement officiels : Odoo Online (SaaS multi-tenant), Odoo.sh (PaaS sur Google Cloud Platform — GCP, le cloud d'infrastructure de Google, opérateur américain soumis au Cloud Act), et On-Premise (déploiement libre).

Atouts. Étendue fonctionnelle remarquable, avec plus de 90 modules officiels et plusieurs milliers d'apps tierces. Interface utilisateur moderne, l'une des meilleures du marché des ERP. Stack technique entièrement libre (Python, PostgreSQL). Réseau mondial d'intégrateurs et de partenaires. Accessibilité tarifaire, particulièrement à l'entrée. Personnalisation ouverte à tout développeur Python. Le mode On-Premise officiel permet un déploiement souverain complet, sans renoncer à la licence Enterprise.

Faiblesses. Roadmap éditeur centralisée, sans mécanisme formel d'influence par les clients. Cycle de versions annuel avec un support de trois ans en Enterprise, ce qui impose des migrations régulières et coûteuses. Politique commerciale Enterprise qui se durcit, avec des hausses tarifaires significatives ces dernières années. Le code Enterprise n'est pas libre malgré la lisibilité des sources, ce qui limite la portée du label « open source ». 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 inégale selon les modules — certains restent en deçà de spécialistes verticaux (production complexe, EAM, retail spécialisé).

Souveraineté. Logiciel : excellente (éditeur belge, stack libre). Hébergement : variable selon le mode. Online et Odoo.sh sont sur GCP donc soumis au Cloud Act. On-Premise sur cloud souverain (OVHcloud, Scaleway, Outscale, NumSpot) ou serveurs propres = souveraineté complète.

Dolibarr

Description. Projet français porté par la Dolibarr Foundation, structure associative. Licence GPLv3 stricte. Pas d'éditeur commercial unique : la gouvernance est communautaire, le développement collaboratif.

Atouts. Souveraineté maximale sur les quatre axes, sans aucune réserve : éditeur français, code GPL strict, stack libre (PHP, MariaDB ou PostgreSQL), hébergement entièrement libre. Aucun coût de licence. Communauté active depuis plus de quinze ans. Excellente adéquation aux besoins TPE et petites PME. Marketplace Dolistore avec un catalogue de modules tiers nourri. Architecture simple, donc facile à maintenir et à comprendre.

Faiblesses. Couverture fonctionnelle plus restreinte qu'Odoo, particulièrement faible sur les sujets industriels lourds, le multi-pays complexe, la supply chain avancée et la production multi-niveaux. Interface moins moderne, moins fluide. Profondeur insuffisante pour des ETI complexes. Écosystème de prestataires professionnels plus restreint et moins structuré. Gouvernance associative qui n'offre pas de roadmap commerciale prévisible — un avantage en termes de souveraineté, un inconvénient pour les acheteurs qui veulent un engagement éditeur fort.

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

Tryton

Description. Issu d'un fork historique d'OpenERP en 2008. Porté par la Tryton Foundation, fondation européenne avec une présence en Allemagne, Belgique et Espagne. Licence GPLv3. Stack Python et PostgreSQL.

Atouts. Architecture extrêmement rigoureuse, modulaire et stable. Profondeur comptable solide. Code particulièrement propre, apprécié des développeurs exigeants. Souveraineté maximale (fondation européenne, stack libre).

Faiblesses. Interface utilisateur austère, peu d'investissement sur l'UX. Écosystème de partenaires très restreint, donc faible disponibilité de ressources. Documentation parfois lacunaire. Marché de l'emploi limité, ce qui complique le recrutement. Coût d'expertise élevé en raison de la rareté des compétences.

Souveraineté. Maximale.

Axelor

Description. Éditeur français. Suite ERP, BPM et CRM unifiée, sous licence open source AGPLv3 pour la version Community, propriétaire pour la version Enterprise. Stack Java et PostgreSQL. Studio low-code intégré.

Atouts. Studio low-code permettant des personnalisations sans coder, ce qui réduit la dépendance aux développeurs. Couverture fonctionnelle large, intégration native ERP + BPM + CRM. Éditeur français indépendant. Stack technique libre.

Faiblesses. Part de marché modeste face à Odoo, ce qui limite l'écosystème de prestataires et la base de clients. Licence AGPLv3 contraignante pour les intégrations propriétaires (toute modification utilisée à travers un 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 (sources accessibles).

ERPNext (Frappe)

Description. Éditeur indien, Frappe Technologies. Licence GPLv3 stricte. Stack Python et MariaDB. Couverture fonctionnelle large. Repose sur le framework Frappe, lui-même réutilisable pour d'autres applications.

Atouts. Open source intégral, pas de version Enterprise propriétaire. Stack libre. Couverture fonctionnelle large. Aucun coût de licence. Communauté dynamique. Plateforme Frappe utilisable au-delà de l'ERP.

Faiblesses. Éditeur indien, ce qui pose une question d'éloignement géographique, culturel et juridique pour une organisation européenne. Écosystème de prestataires européens encore modeste. Localisation française perfectible — la comptabilité, la fiscalité et la paie françaises ne sont pas le terrain naturel de l'éditeur. Profondeur fonctionnelle moyenne sur certains domaines critiques.

Souveraineté. Bonne au sens strict (Inde hors dispositif extraterritorial US, GPL strict, stack libre). Réserve sur la localisation de l'éditeur, qui peut être bloquante pour certaines organisations.

Famille 2 — Les ERP propriétaires

Les ERP qui suivent reposent sur du code propriétaire, des licences payantes (souvent par utilisateur), et fréquemment sur des stacks techniques elles-mêmes propriétaires. Ils héritent par construction des risques nommés en début d'article : captivité des données, audits de licence, calendriers imposés, hausses tarifaires, dépendance à la pérennité de l'éditeur, verrouillage technique.

Pour autant, ces solutions présentent des forces que le modèle open source n'égale pas toujours : des écosystèmes verticaux ultra-spécialisés (mode, automobile, expertise comptable, défense), une intégration native avec d'autres briques d'un SI propriétaire (notamment Microsoft Office), ou une profondeur fonctionnelle construite sur plusieurs décennies. Le bon choix ne consiste pas à les rejeter par principe, mais à les évaluer en regardant honnêtement la balance bénéfice / risque.

SAP S/4HANA et déclinaisons

Description. Référence mondiale pour les ERP grand compte. Éditeur allemand, siège à Walldorf. Coté à la fois à Francfort et à la NYSE. Décliné en S/4HANA (grand compte), Business One (PME), Business ByDesign et GROW with SAP (mid-market SaaS).

Atouts. Profondeur fonctionnelle sans équivalent sur la finance, la supply chain et la production. Standard de fait dans plusieurs grands secteurs : industrie lourde, aéronautique, énergie, pharmacie. Écosystème mondial très dense (consultants, formations, certifications, spécialistes verticaux). Capacité reconnue à supporter de très grandes organisations multi-pays avec une complexité réglementaire et fiscale élevée.

Faiblesses. Coût total de possession très élevé, sur tous les postes (licences, intégration, maintenance à 22 % par an, ressources humaines rares et chères). Migrations brutales et coûteuses — la fin du support de SAP ECC à fin 2027, avec extension payante jusqu'à 2030, force des dizaines de milliers de clients à basculer sur S/4HANA selon un calendrier imposé. Code propriétaire ABAP, langage spécifique SAP qui requiert une expertise rare. UX historiquement complexe, l'apport de Fiori améliore mais ne résout pas tout. Roadmap éditeur unilatérale. Stack BDD propriétaire HANA. Pratiques d'audit de licence connues pour leur fermeté.

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

Oracle NetSuite

Description. Pure player SaaS américain, propriété d'Oracle. Très implanté sur le segment mid-market et les ETI à dominante financière. Présence française.

Atouts. Modèle SaaS pur, sans gestion d'infrastructure côté client. Internationalisation native : multi-devises, multi-pays, conformités locales. Reporting financier robuste, héritage Oracle. Mises à jour continues. Délai de mise en œuvre court sur les périmètres standard.

Faiblesses. Couverture industrielle et production faible. Personnalisation contrainte par SuiteScript, langage propriétaire de type JavaScript. 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 connu de longue date pour ses pratiques d'audit de licence agressives.

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

Microsoft Dynamics 365

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

Atouts. Intégration native avec Office 365, Teams, Power BI, Power Platform — argument décisif quand le SI est déjà 100 % Microsoft. UX moderne. Écosystème de partenaires massif. Capacité de personnalisation low-code via Power Platform.

Faiblesses. Coûts de licence élevés et en croissance. 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, captif.

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

Infor CloudSuite

Description. Suite ERP verticalisée par industrie : mode, automobile, distribution, santé, équipements industriels. Éditeur américain, propriété de Koch Industries depuis 2020.

Atouts. Verticaux métier très profonds et matures : Fashion, Automotive, M3 (industrie discrète), LN. SaaS sur AWS. Approche par best practices industrielles standardisées par secteur, qui réduit les coûts de paramétrage sur les périmètres types.

Faiblesses. É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 la plateforme parfois pénible pour les clients sur d'anciennes versions.

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

Sage

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

Atouts. Maturité produit élevée. Conformité fiscale et sociale française très solide (compta, paie, FEC, déclarations). Forte base installée, particulièrement chez les experts-comptables. Écosystème de prestataires français dense. Bonne réputation sur la paie et la comptabilité.

Faiblesses. Hétérogénéité technique entre les produits — passer de Sage 100 à Sage X3 n'est pas une montée en gamme, c'est un changement de logiciel. UX souvent datée. Stratégie commerciale qui pousse à la migration vers Intacct, conçu et opéré aux États-Unis, ce qui pose un sujet souveraineté de plus en plus aigu. 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 dont l'hébergement est à vérifier.

Cegid

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

Atouts. Verticaux très profonds et matures sur les segments visés. Conformité française irréprochable. Solide ancrage sur le marché français. SaaS mature.

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

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

Divalto

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

Atouts. Très bonne adéquation aux PME industrielles françaises. Verticaux négoce, BTP, distribution techniques bien servis. Proximité éditeur. Indépendance capitalistique française. Tarification raisonnable.

Faiblesses. Notoriété et taille d'écosystème modestes face aux grands acteurs. 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

Description. É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.

Atouts. Profondeur fonctionnelle remarquable sur l'EAM (Enterprise Asset Management), la gestion de projets complexes et les 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.

Faiblesses. 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 est souvent déployé sur Azure, ce qui réintroduit une question d'hébergement. Capital majoritairement détenu par des 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 mirage du « cloud souverain »

Une mention particulière s'impose pour les offres labellisées « cloud souverain » ou « cloud de confiance ». Plusieurs hyperscalers américains ont monté des co-entreprises avec des opérateurs français : Bleu (Microsoft Azure × Capgemini × Orange), S3NS (Google Cloud × Thales). L'objectif affiché est d'obtenir la qualification SecNumCloud de l'ANSSI et d'isoler les opérateurs européens des injonctions américaines. Sur le papier, le dispositif améliore la situation. Dans la pratique juridique, le débat reste vif : tant que la technologie sous-jacente est conçue, opérée et licenciée par un éditeur soumis au droit américain, l'isolation totale est juridiquement contestable.

Pour qui cherche une garantie pleine et entière, les vrais clouds souverains restent limités aux opérateurs européens à capital européen et à technologie européenne : OVHcloud, Scaleway, 3DS Outscale (qualifié SecNumCloud), NumSpot, et les hébergeurs régionaux français qualifiés.

Tableau de synthèse

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

Quels ERP offrent une souveraineté complète ?

Pour qu'un ERP atteigne une souveraineté pleine, les quatre conditions suivantes doivent être réunies en même temps :

1. Éditeur sous juridiction non extraterritoriale, idéalement européenne.
2. Code source libre, auditable, 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 américain.

Solutions qui répondent aux quatre conditions sans réserve :

• Dolibarr — France, GPLv3, PHP et MariaDB ou PostgreSQL libres, auto-hébergement libre.
• Tryton — fondation européenne, GPLv3, Python et PostgreSQL libres, auto-hébergement libre.
• Axelor Community — France, AGPLv3, Java OpenJDK et PostgreSQL libres, auto-hébergement libre.
• Odoo Community — Belgique, 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 Union européenne.

Solutions souveraines sous condition :

• Odoo Enterprise on-premise déployé sur cloud souverain (OVHcloud, Scaleway, Outscale, NumSpot) ou sur serveurs propres : souverain en pratique, avec la nuance d'une licence Enterprise propriétaire (sources accessibles, non redistribuables). Odoo Online et Odoo.sh, qui reposent sur GCP, ne répondent pas à cette exigence.
• 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 américaine directe (Sage est britannique, hors Cloud Act), mais code propriétaire et le plus souvent stack technique propriétaire (HANA, Oracle DB, SQL Server). La souveraineté reste partielle.

En conclusion

Choisir un ERP, c'est choisir une dépendance pour les dix à quinze prochaines années. La nature et la profondeur de cette dépendance varient considérablement selon la solution retenue.

Opter pour un éditeur américain, c'est accepter une exposition extraterritoriale en échange d'une maturité produit indéniable, d'une intégration parfois unique avec d'autres outils US, et d'un écosystème dense.

Opter pour un éditeur propriétaire européen, c'est lever une partie du risque juridictionnel, mais conserver l'essentiel des risques structurels du modèle propriétaire — captivité des données, audits de licence, calendrier subi, hausses tarifaires captives, dépendance à la stratégie commerciale d'un éditeur unique.

Opter pour un open source européen, c'est obtenir le contrôle complet du logiciel, des données et de l'infrastructure, en contrepartie d'un investissement initial plus élevé en compétences et en intégration.

Aucune de ces options n'est universellement supérieure aux autres. Le bon ERP est celui qui combine au mieux la couverture du métier de l'entreprise, sa taille, sa culture, sa capacité d'investissement, son SI existant, et son niveau d'exigence en matière de souveraineté.

L'objectif de ce comparatif n'est pas de désigner un gagnant, mais de fournir une grille pour choisir avec lucidité. Une organisation peut, en pleine connaissance de cause, retenir SAP pour sa profondeur fonctionnelle ou Microsoft Dynamics pour sa cohérence avec un SI Office déjà installé. La condition est que les risques associés soient identifiés, documentés, et acceptés — pas découverts en cours de route.

Choisir son ERP, c'est choisir sa dépendance. Autant savoir laquelle on choisit.