Licences Oracle : savez-vous vraiment ce que vous utilisez… et ce que vous payez ?

Jean-Michel Alluguette – OP&S
16 déc. 2025
5 min de lecture

Dernière mise à jour : 17 déc. 2025

Beaucoup d’entreprises paient des licences Oracle depuis des années.

Elles savent “globalement” ce qu’elles ont acheté (Enterprise Edition, Standard, quelques options…), mais une question reste souvent sans réponse claire :

Quelles options Oracle sont réellement utilisées aujourd’hui, sur quelles bases, et depuis quand ?

Et c’est là que se trouve le risque.

Car il existe un scénario très courant :

une option Oracle est activée (par test, par erreur, par paramétrage d’outil, par script), puis elle reste activée.

Au quotidien, personne ne s’en rend compte.

Mais le jour d’un audit éditeur, la facture peut devenir très élevée.

Dans cet article, on va voir :

pourquoi ce sujet est si piégeux,
les causes les plus fréquentes d’écarts licences,
une méthode simple pour reprendre le contrôle,
et comment OP&S peut aider à objectiver la situation avant qu’elle ne devienne un problème.

Pourquoi ce sujet est si sensible (et souvent sous-estimé)

Oracle n’est pas seulement une base de données.

C’est un écosystème de fonctionnalités, d’options et de packs qui peuvent être :

activés consciemment (choix d’architecture),
activés indirectement (outil, paramètre, job),
activés pendant un POC,
ou activés “par commodité”, puis oubliés.

Et dans beaucoup d’organisations, personne n’a une vision consolidée :

par base,
par environnement (PROD / pré-prod / DEV),
par période (depuis quand c’est activé),
et surtout : est-ce réellement utilisé ?

Résultat : on découvre trop tard.

Les 3 causes classiques d’écarts licences Oracle

1) L’activation “par curiosité” (ou par défaut)

Un DBA, un architecte, une intégration applicative… teste une fonctionnalité :

“juste pour voir”
“pour accélérer un traitement”
“pour faire un reporting”
“pour une migration”

Puis l’environnement change, on passe en production, l’équipe tourne… et l’option reste.

Le piège : ce n’est pas forcément visible par l’application.

Tout “fonctionne”.

Mais côté licences, c’est une autre histoire.

2) Le POC jamais nettoyé

C’est extrêmement fréquent :

une option est activée pendant un POC (ou dans un contexte projet),
tout le monde est concentré sur le go-live,
et personne ne fait une revue “licences & options” avant bascule.

Quelques mois plus tard :

l’option est toujours là,
et l’entreprise a intégré un risque licences “silencieux”.

3) Le manque de visibilité consolidée (le vrai problème)

Dans la plupart des entreprises, les infos sont dispersées :

un DBA a une vue sur sa base,
une autre équipe a une vue sur un autre périmètre,
le FinOps regarde surtout l’infra,
et les achats ne voient que les contrats.

Mais l’audit licences nécessite une vision transverse :

parc complet,
options activées,
usage réel,
historique,
environnements non-prod (souvent oubliés),
bases associées à des ERP (JDE, EBS) ou à des applis internes.

“Utilisé” vs “Activé” : la confusion qui coûte cher

Le point critique : activer une option ne veut pas dire qu’elle est “utilisée” au sens métier.

Mais pour une organisation, ce qui compte est de savoir :

Quelles options sont activées ?
Quelles options semblent réellement utilisées ?
Est-ce que l’usage est récurrent ou ponctuel ?
Depuis quand ?
Sur quels environnements ?

En pratique, c’est la seule façon de décider :

ce qui doit être régularisé,
ce qui doit être désactivé,
ce qui doit être documenté,
et ce qui doit être assumé contractuellement.

Demander un PoC gratuit (1 mois)

La méthode simple pour reprendre le contrôle (sans y passer des semaines)

Je recommande une approche en 4 étapes.

Étape 1 — Inventorier le parc Oracle (vraiment complet)

Cela paraît trivial, mais c’est souvent la première faille :

toutes les bases Oracle, toutes versions,
On-Prem et Cloud,
PROD et hors PROD,
bases d’ERP (JD Edwards, E-Business Suite) incluses,
environnements “temporaires” (projets, intégrations, sandbox).

Sans cet inventaire, vous passez à côté des risques.

Étape 2 — Lister les options / packs activés par base

Objectif : avoir une matrice simple :

Base

Edition

Options activées

Packs activés

Environnement

C’est l’étape qui révèle souvent des surprises, notamment sur les environnements non-prod.

Étape 3 — Corréler avec l’usage réel (et l’historique)

C’est là que vous passez d’une liste brute à une vue exploitable :

option activée ponctuellement → risque à qualifier
option activée “tout le temps” → risque élevé si non couvert
option activée depuis des mois / années → problème structurel
option activée sur DEV uniquement → à surveiller, mais impact différent

Sans historique, vous pouvez difficilement prouver quoi que ce soit.

Étape 4 — Produire un plan d’action “licences”

À ce stade, vous devez pouvoir décider rapidement :

Qu’est-ce qu’on garde (car utile / assumé) ?
Qu’est-ce qu’on désactive (car inutile) ?
Qu’est-ce qu’on documente (par précaution) ?
Qu’est-ce qu’on escalade aux achats (renégociation / régularisation) ?

Comment OP&S aide concrètement

OP&S a été conçu pour éviter ce scénario classique :

“on découvre un problème licences quand il est trop tard”.

Avec OP&S, vous pouvez :

surveiller les options activées sur l’ensemble du parc Oracle (multi-bases, multi-environnements)
corréler avec l’usage observé dans le temps
identifier les environnements à risque (PROD et hors PROD)
générer des rapports lisibles pour DBA, RSSI, audit interne et achats
être alerté lorsqu’une option “apparaît” soudainement (activation récente)

Et surtout : vous disposez d’une base factuelle pour discuter en interne (et avec un éditeur si besoin).

Exemple d'audit licence automatisé sous OP&S avec historique

Check-list : 10 points à vérifier maintenant (en 30 minutes)

Avez-vous une liste complète de toutes vos bases Oracle (y compris hors PROD) ?
Savez-vous quelles bases sont en Enterprise Edition vs Standard ?
Connaissez-vous la liste des options activées par base ?
Avez-vous un historique de ces activations (depuis quand) ?
Les environnements DEV/TEST utilisent-ils des options non couvertes ?
Des options ont-elles été activées pendant un POC “oublié” ?
Des équipes applicatives ont-elles accès à des fonctionnalités Oracle avancées sans gouvernance ?
Avez-vous une procédure de revue licences après migration / rebuild / upgrade ?
Êtes-vous capable de produire un rapport consolidé en moins d’une journée ?
Avez-vous un plan clair : désactiver / documenter / régulariser ?

Si vous cochez “non” à plusieurs points, vous avez un vrai sujet.

Les erreurs à éviter (vraiment fréquentes)

Erreur #1 : attendre “l’audit” pour agir

Le jour où un audit est annoncé, vous n’avez plus le temps de travailler proprement :

on panique,
on désactive dans l’urgence,
on perd la traçabilité,
et on abîme la relation interne entre équipes.

Erreur #2 : ne regarder que la PROD

Les environnements hors PROD sont souvent les plus risqués :

plus d’expérimentations,
moins de gouvernance,
des options activées “juste pour tester”.

Erreur #3 : confondre “légal” et “réel”

Même si vous avez acheté X licences, la vraie question est :

est-ce que votre usage réel correspond à votre contrat ?
et pouvez-vous le démontrer de manière factuelle ?

Exemples concrets rencontrés chez nos clients

L'option "compress=yes" lors d'export Datapump => ADVANCED COMPRESSION activé
Un infogérant qui lance un rapport AWR sans se renseigner des licences acquises par son client => Diagnostic Pack activé
Des SQL Profiles positionnés sur des requêtes SQL_ID non performantes pour fixer un plan d'exécution => Tuning Pack activé
TDE (Transparent Data Encryption) testé pour crypter les datafiles => Advanced Security activé
Golden Gate mis en place sur environnement de Test. Licences suffisantes uniquement pour la PROD => Golden Gate activé

Conclusion

La plupart des problèmes licences Oracle ne viennent pas d’une “fraude” :

ils viennent de l’absence de visibilité, de POCs oubliés et d’options activées sans gouvernance.

Avec une approche simple (inventaire → options activées → usage réel → plan d’action), vous pouvez :

réduire le risque,
éviter les mauvaises surprises,
et souvent identifier des économies possibles.

Un audit préventif qui change la donne

Nous proposons un audit gratuit d’un mois avec un rapport complet à la clé.

Utile pour :

– auditer votre conformité,

– préparer une négociation avec l’éditeur,

– dormir plus tranquille