Oracle 19c et 26ai : le compte à rebours est lancé. Quelle trajectoire choisir ?

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

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

Pendant des années, beaucoup d’entreprises ont standardisé sur Oracle 19c. C’est logique : c’est une version long terme, largement déployée, et encore supportée pendant plusieurs années.

Mais le contexte change : Oracle a annoncé l’arrivée d’Oracle AI Database 26ai on-premises sur Linux x86-64 à partir de janvier 2026.

La question n’est donc plus “19c ou rien”, mais plutôt :

Comment sécuriser 19c à court terme, tout en préparant proprement la prochaine grande étape (26ai) ?

Cet article vous propose une approche pragmatique, orientée production : réduire les risques, maîtriser les coûts, et éviter de migrer des problèmes en même temps que la version.

Release Schedule Database — Doc ORACLE 742060.1

Pourquoi ce sujet est maintenant “DSI”, pas seulement “DBA”

Une trajectoire de version Oracle touche plus que la technique :

Production / DSI : fenêtres de maintenance, continuité de service, réversibilité
Sécurité : posture patching, dette technique, conformité
Infra / Cloud / FinOps : dimensionnement, coûts, rationalisation
ERP (JDE, EBS) : compatibilité, batchs, traitements critiques
Achats / Licences : options activées, risque audit, trajectoire contractuelle

Donc il faut sortir du débat “upgrade technique” et raisonner “pilotage”.

19c : une base solide, mais pas une stratégie complète

19c reste une étape importante : Premier Support jusqu’au 31 décembre 2029, et Extended Support jusqu’au 31 décembre 2032 (selon la documentation Oracle).

Mais même si 19c tient encore plusieurs années, vous devez anticiper deux choses :

La dette technique s’accumule si vous repoussez indéfiniment la trajectoire suivante.
L’arrivée de 26ai donne un nouveau point de convergence (et donc un nouveau calendrier de décisions).

26ai en janvier 2026 (Linux) : ce que ça change concrètement

Oracle a annoncé une disponibilité on-premises de 26ai pour Linux x86-64 en janvier 2026 (RU 23.26.1).

Sans rentrer dans le marketing “AI”, l’impact réel pour vous est surtout :

un nouveau “cap” majeur pour les trajectoires post-19c,
un sujet de roadmap (quand migrer ? quel lot ? quel périmètre ?),
et la nécessité de se préparer (compatibilités, tests applicatifs, runbooks, etc.).

Les 3 erreurs classiques quand on parle “19c / 26ai”

Erreur 1 — Penser “version” au lieu de penser “risque”

Une migration réussie, ce n’est pas “ça démarre”.

C’est “ça démarre et c’est stable et les performances sont maîtrisées et les coûts/licences sont sous contrôle”.

Erreur 2 — Migrer sans photographie “avant”

Sans état des lieux (avant), vous ne pouvez pas prouver :

si vous avez amélioré,
ou si vous avez régressé,
ni expliquer aux métiers ce qui a changé.

Erreur 3 — Migrer en embarquant des problèmes non traités

Si votre environnement est déjà en dérive (I/O, contention, paramètres, volumétrie), la migration peut :

amplifier le bruit,
compliquer le diagnostic,
te faire perdre du temps (et de la crédibilité).

Demander un PoC gratuit (1 mois)

La bonne approche : une trajectoire en 2 temps (court terme + prochaine étape)

Temps 1 — Sécuriser et rationaliser l’existant (souvent sur 19c)

Objectif : stabiliser, réduire les risques, maîtriser les coûts sans attendre la migration.

identifier les bases à risque (perf / contention / I/O / configuration),
repérer la dérive (tendances sur plusieurs mois),
nettoyer les sujets coûts/licences (options activées, surdimensionnement).

Temps 2 — Préparer la prochaine étape (26ai) de façon industrialisée

Objectif : ne pas “subir” 26ai, mais être prêt à migrer par lots, proprement.

choisir un périmètre pilote,
définir les critères de succès (perf, stabilité, batchs, SLA),
industrialiser (runbook, tests, validation avant/après).

Comment OP&S aide à piloter la trajectoire 19c → 26ai (sans benchmark manuel)

C’est exactement là qu’OP&S a de la valeur : vous n'avez pas besoin de lancer un benchmark sur plusieurs semaines, car les métriques existent déjà dans l’historique.

OP&S :

collecte des métriques régulièrement et conserve l’historique,
rend visibles les déviations (avant/après, tendances, périodes comparables),
met en évidence la “signature” du problème (I/O, concurrence, configuration…),
et permet d’objectiver les discussions DSI / DBA / Infra / ERP / Achats.

En migration, la capacité clé c’est : comparaison “avant vs après” sur des périodes équivalentes (mêmes créneaux, mêmes batchs, mêmes charges).

Check-list “prêt pour 19c / 26ai ?”

Ai-je l’inventaire complet de mes bases (PROD + hors PROD) ?
Ai-je identifié les bases critiques (ERP, batchs, flux métiers) ?
Est-ce que je sais quelles bases dérivent en performance (tendance) ?
Est-ce que je sais si la douleur vient plutôt d’I/O, contention, ou configuration ?
Ai-je une vue claire du surdimensionnement (gains infra/FinOps) ?
Ai-je identifié les options Oracle activées et l’usage réel (risque licences) ?
Ai-je une “photo avant” exploitable pour valider la migration ?
Ai-je un périmètre pilote et un runbook de validation ?

Conclusion

Avec la disponibilité annoncée de 26ai on-prem Linux en janvier 2026, il devient pertinent d’adopter un discours (et une stratégie) “19c + trajectoire vers la prochaine version majeure”.

19c reste un socle solide et supporté plusieurs années, mais la vraie réussite consiste à :

stabiliser et rationaliser maintenant,
et préparer 26ai sans embarquer de dette technique.

Un audit pré-migration pour éviter les mauvaises surprises

Nous proposons un audit Oracle pré-migration d’un mois, avec rapport à la clé.

Vous verrez ce qui se passe vraiment dans vos bases :

– où sont les risques de performance,

– quelles options sont activées sans être justifiées,

– quels gains vous pouvez obtenir en rationalisant avant la migration.

Un audit préventif maintenant peut vous éviter des mois de stress plus tard.