Oracle dans les SI publics français : le guide de sortie progressive pour les DSI qui veulent reprendre la main

# Oracle dans les SI publics français : le guide de sortie progressive pour les DSI qui veulent reprendre la main

En 2026, Oracle reste l'un des fournisseurs les plus présents dans les systèmes d'information des administrations françaises et des établissements publics. Bases de données, ERP, middleware : la dépendance est profonde, souvent invisible dans les budgets de fonctionnement, et structurellement coûteuse. Pendant ce temps, la pression tarifaire ne faiblit pas — les cycles de renégociation avec l'éditeur américain se concluent rarement en faveur de l'acheteur public.

Ce guide s'adresse aux DSI et responsables IT d'administrations, d'établissements publics ou de collectivités qui veulent engager une démarche concrète de réduction de cette dépendance. Pas de grand discours sur la souveraineté : des étapes, des leviers budgétaires, des acteurs européens à considérer.

Étape 1 — Cartographier précisément l'empreinte Oracle dans votre SI

Avant toute décision, il faut savoir exactement ce que vous payez et pourquoi. C'est souvent la première surprise : dans de nombreux établissements publics, la dépense Oracle est fragmentée entre plusieurs directions, plusieurs marchés, plusieurs prestataires intégrateurs — ce qui la rend difficile à lire dans sa globalité.

Actions concrètes :

• Compiler l'ensemble des contrats Oracle actifs : licences perpétuelles, abonnements cloud, support annuel, extensions de modules. Incluez les contrats portés par vos prestataires qui reposent eux-mêmes sur des licences Oracle.
• Identifier les usages réels versus les licences détenues. Le sur-licensing est fréquent dans le secteur public, notamment sur les bases de données Oracle Database dans des environnements virtualisés — où les règles de comptage de licences Oracle sont délibérément complexes.
• Dater les prochaines échéances contractuelles. C'est votre seule fenêtre de levier réel dans une renégociation ou une sortie.

Signal d'alerte budgétaire : Si votre coût de support annuel Oracle dépasse structurellement 20 % du budget logiciel global de votre direction, vous êtes en situation de dépendance critique. Ce ratio n'est pas une norme officielle — c'est un seuil pragmatique pour déclencher une analyse.

Étape 2 — Distinguer les dépendances critiques des dépendances héritées

Toutes les briques Oracle dans votre SI n'ont pas le même niveau de criticité ni le même coût de sortie. Confondre les deux, c'est soit sous-estimer le chantier, soit surestimer l'effort et ne jamais rien faire.

Actions concrètes :

• Catégorie A — Dépendances structurantes : les bases de données Oracle qui portent des applications métier critiques (RH, finance, gestion des usagers). La migration est possible mais longue — comptez 18 à 36 mois selon la complexité applicative.
• Catégorie B — Dépendances héritées : des modules ou outils Oracle dont l'usage réel est marginal, souvent conservés par inertie ou parce qu'ils font partie d'un bundle contractuel. Ce sont vos premières cibles de sortie rapide.
• Catégorie C — Dépendances imposées par un tiers : un éditeur de logiciel métier qui exige Oracle Database en prérequis. Ici, le levier n'est pas technique mais contractuel — et il passe par votre prochaine consultation marchés.

L'objectif de cette étape est simple : produire une matrice de priorisation qui guide vos arbitrages budgétaires sur les 3 prochains exercices.

Étape 3 — Intégrer le risque tarifaire Oracle dans vos projections budgétaires

C'est l'étape que beaucoup de DSI publics négligent, faute de temps ou parce que la dépense Oracle est perçue comme incompressible. Elle est pourtant décisive pour obtenir des arbitrages favorables en interne.

Actions concrètes :

• Modélisez un scénario de hausse tarifaire sur votre périmètre Oracle actuel sur 5 ans. Oracle, comme l'ensemble des éditeurs américains en position dominante, a historiquement augmenté ses tarifs de support et ses prix cloud bien au-dessus de l'inflation. Sans inventer de chiffres, posez la question directement à votre interlocuteur Oracle et demandez-lui de s'engager contractuellement sur un plafond — vous constaterez que c'est rarement possible.
• Calculez le coût total de possession (TCO) réel, pas seulement le coût de licence. Intégrez : le coût des compétences internes ou externes spécifiques Oracle, le coût des audits de licences (qui sont des outils de pression tarifaire), le coût de la complexité de gouvernance.
• Présentez ce TCO en comité de direction comme un risque budgétaire documenté, pas comme un souhait technique. C'est ce cadrage qui débloque les enveloppes de migration.

Étape 4 — Identifier les alternatives européennes adaptées à votre contexte

Le marché européen des bases de données et des ERP pour le secteur public s'est structuré. Il ne s'agit pas de remplacer Oracle par une solution moins bonne : il s'agit de choisir des alternatives dont le modèle économique et la gouvernance sont compatibles avec les exigences d'un acheteur public souverain.

Sur la couche base de données :

PostgreSQL, en tant que standard open source, est aujourd'hui déployé à grande échelle dans des administrations européennes. Ce n'est pas un acteur — c'est une fondation technologique. Ce qui compte pour vous, c'est l'écosystème de support européen autour. Des acteurs comme Dalibo (éditeur et société de services française, spécialiste PostgreSQL) proposent un accompagnement et un niveau de support contractuel crédibles pour des environnements de production critiques dans le secteur public.

Sur la couche ERP et gestion publique :

Agilium (France) est un exemple d'acteur européen positionné sur les ERP pour le secteur public et les collectivités, avec une approche de déploiement souverain. L'enjeu n'est pas de dresser un catalogue, mais de vérifier, pour tout candidat, trois critères non négociables : siège social européen, hébergement des données sur infrastructure européenne certifiée, et capacité contractuelle à auditer le code ou les conditions de service.

Ce qu'il faut exiger dans vos appels d'offres :

• Clause de réversibilité explicite et documentée
• Engagement sur la localisation des données (SecNumCloud ou équivalent européen)
• Modèle de licence sans mécanisme d'audit unilatéral à l'initiative de l'éditeur

Étape 5 — Construire une feuille de route de migration budgétairement soutenable

La principale raison pour laquelle les sorties Oracle n'aboutissent pas dans le secteur public, c'est qu'elles sont présentées comme des projets tout-ou-rien. Le bon modèle est incrémental.

Actions concrètes :

• An 1 : Sortir les briques Catégorie B identifiées à l'étape 2. Objectif : réduire la surface contractuelle Oracle et dégager un premier retour budgétaire visible. Ce retour finance partiellement la suite.
• An 2-3 : Conditionner tout nouveau projet applicatif à l'absence de prérequis Oracle. Intégrer cette clause dans vos cahiers des charges. C'est le levier le plus puissant sur le long terme : stopper l'extension de la dépendance avant de la réduire.
• An 3-5 : Engager la migration des Catégorie A, en commençant par les applications les moins critiques et en capitalisant sur les retours d'expérience des administrations pionnières (la DINUM publie des ressources sur ce sujet).

Sur le financement : Les fonds européens (notamment le programme DIGITAL Europe) et les dispositifs de l'ANSSI pour la montée en maturité des SI publics peuvent cofinancer des projets de migration vers des solutions souveraines. Votre interlocuteur DINUM régional ou votre préfecture numérique peut vous orienter vers les guichets disponibles en 2026.

Ce que vous devez avoir produit à l'issue de ce guide

• Une cartographie complète de votre empreinte Oracle avec coût total documenté
• Une matrice de priorisation des dépendances (A/B/C)
• Un modèle de risque tarifaire sur 5 ans présentable en direction générale
• Une feuille de route de migration en 3 horizons temporels
• Un premier appel d'offres reformulé pour exclure Oracle comme prérequis implicite

La dépendance à Oracle dans les SI publics français n'est pas une fatalité technique. C'est un choix contractuel qui se perpétue par inertie et par absence de visibilité budgétaire. Rendre cette dépendance visible est la première étape — et la seule qui ne coûte rien.