Encore sur Informix 12.10 ? Lisez ceci.

Conteneurs standalone : ce qui a changé

Jusqu'à récemment, pour exécuter Informix en conteneurs avec support enterprise en production, le seul chemin officiel passait par Cloud Pak for Data (CP4D). Les images Docker Hub — désormais migrées vers l'IBM Container Registry (ICR) — étaient Developer Edition : adaptées au développement, sans support IBM en production.

L'Informix Standalone Container supprime cette dépendance :

• Images production-grade pour Informix v14 et v15 sur IBM Container Registry.
• Déploiement direct sur Kubernetes et OpenShift sans CP4D.
• Support enterprise complet sous le contrat existant — pas un produit supplémentaire.
• Mise à niveau de Developer vers Enterprise Edition en changeant l'image et en appliquant l'installer.
• CASE bundles sur GitHub : ibm-informix-standalone.

Concrètement, cela signifie intégrer Informix dans les pipelines CI/CD, démarrer des instances pour les tests automatisés, déployer avec des Helm Charts en hybrid-cloud et disposer d'environnements de développement identiques à la production. Daniel Weber, Informix Container Dev Lead, a fait la démonstration lors du Tech Talk IIUG d'avril.

C'est le type d'annonce qui ne fait pas les gros titres mais qui change la façon d'opérer un produit au quotidien.

Informix 12.10 a perdu son support

Le 30 avril, IBM a achevé la transition d'Informix 12.10 vers le support étendu. Trois conséquences directes :

• Plus de correctifs de sécurité. Toute vulnérabilité découverte reste non corrigée.
• Plus de corrections de bogues. Le fixpack actuel est le dernier.
• Support technique uniquement payant sous Extended Support, jusqu'en 2030.

Le CSDK 4.10 (Client SDK) passe également en support étendu à la même date, ce qui affecte les drivers ESQL/C, ODBC et JDBC anciens.

12.10 a été publié en 2013. Treize ans de vie, c'est un cycle raisonnable. Mais de nombreux environnements de production tournent encore sous cette version parce que « ça marche » et qu'il n'y a jamais eu assez de pression pour migrer. Maintenant la pression existe — et elle coïncide avec un vrai chemin de modernisation : conteneurs, chiffrement natif, sauvegarde S3.

14.10 ou 15 : laquelle choisir pour migrer

Informix 15 (novembre 2024) est la première release majeure en plus de cinq ans, avec des changements profonds dans les structures internes du moteur : limites largement élargies (une partition peut contenir 140 billions de pages), chiffrement natif par dbspace, Wire Listener amélioré (MongoDB 3.2–4.2), sauvegarde native vers S3/Azure/IBM COS via ON-Bar, Helm Charts officiels et Java 11 obligatoire.

Informix 14.10xC13 (janvier 2026) est la dernière release de la branche 14.10 : améliorations d'archecker pour les SmartLOBs, Direct I/O pour les blocs 2K/4K et les corrections accumulées. Mature, éprouvée, conservatrice.

Notre recommandation : si l'environnement est stable et que vous n'avez pas besoin des fonctionnalités de la v15, le chemin 12.10 → 14.10 est le plus sûr. Il laisse le temps à Informix 15 d'accumuler des fixpacks. Si c'est un nouveau projet ou si vous avez besoin du chiffrement natif, de la sauvegarde cloud ou du déploiement Kubernetes natif, allez directement vers la v15.

Pourquoi former l'équipe est aussi important que migrer

Nous le constatons projet après projet. Une équipe met à jour Informix et continue d'opérer avec les mêmes procédures qu'il y a huit ans. Le serveur est en nouvelle version ; les compétences ne le sont pas.

La 14.10 a introduit AUTO_TUNE, qui rend inutiles de nombreux réglages manuels. La v15 change l'approche du chiffrement, de la sauvegarde et du déploiement. Et avec les conteneurs standalone, il y a un nouveau modèle opérationnel qui nécessite des compétences Kubernetes qu'un DBA classique n'a pas forcément. La documentation officielle se trouve dans le guide de déploiement conteneurisé d'Informix 15, mais la documentation ne remplace pas la formation pratique.