Une date de fin de support ne dit pas que le produit s'arrête. Elle dit que l'éditeur cesse de fournir certaines choses, à certaines conditions, à partir d'une date, pour une version précise. Ces quatre éléments se relèvent ensemble sur la note officielle, sans quoi l'échéance ne vaut rien.
L’essentiel
- La date dépend de la version exacte : une échéance relevée pour une autre version fait décider sur une date fausse.
- Maintenance mainstream et maintenance étendue ne couvrent pas le même périmètre, et la seconde se facture généralement en supplément.
- Ces dates sont régulièrement repoussées : un relevé se revérifie chaque trimestre avant d'être porté en comité.
- Ce qui devient bloquant n'est pas l'arrêt du produit, c'est la perte des correctifs de sécurité au premier audit qui les exigera.
Périmètre Pour qui doit transformer une échéance éditeur en date de réexamen défendable. La page ne recommande aucune cible — celle que l'éditeur recommande est une information à relever, pas un arbitrage — et ne traite pas l'état de votre parc, qui se mesure côté socles hérités.
Une date de fin de support ne dit pas que le produit s'arrête. Elle dit que l'éditeur cesse de fournir certaines choses à certaines conditions, à partir d'une date, pour une version précise. Tant que ces quatre éléments ne sont pas relevés ensemble sur la note officielle, l'échéance ne vaut rien dans un dossier de budget — et elle en vaut moins encore dans un planning.
- La date dépend de la version exacte : appliquer à un socle une échéance relevée pour une autre version conduit à décider sur une date fausse.
- Maintenance mainstream et maintenance étendue ne couvrent pas le même périmètre, et la seconde se facture généralement en supplément.
- Ces dates sont régulièrement repoussées : une échéance relevée il y a un an se revérifie avant d'être portée en comité.
- Ce qui devient bloquant en pratique n'est pas l'arrêt du produit, c'est la perte des correctifs de sécurité au premier audit qui l'exigera.
Cette page décrit la méthode de relevé. Elle ne publie aucune date : une échéance sans le lien vers la note de l'éditeur et sa date de consultation est un chiffre orphelin, et ce site n'en produit pas.
Les quatre éléments qui rendent une échéance opposable
Le premier est la version exacte, numéro de patch compris quand l'éditeur en tient compte. Le deuxième est le niveau de maintenance concerné : mainstream, étendue, ou support technique résiduel, qui ne recouvrent ni les mêmes livraisons de correctifs ni les mêmes engagements de délai.
Le troisième est la source : l'adresse exacte de la note de maintenance ou de la page de cycle de vie de l'éditeur, pas un article de blog ni un comparateur, même récent. Le quatrième est la date de consultation, qui documente l'état de l'information au moment où vous l'avez portée dans votre dossier.
Les portails à ouvrir sont ceux des éditeurs eux-mêmes : le portail de support et de stratégie de maintenance de SAP, la Lifetime Support Policy d'Oracle, le cycle de vie des produits Microsoft, la documentation produit et les communications de fin de vie d'Informatica, le support et cycle de vie produit de Qlik. Ce sont des points d'entrée : l'URL à conserver est celle de la page qui porte votre version.
Que se passe-t-il concrètement le jour où la maintenance s'arrête
Le système continue de fonctionner. Ce qui cesse, ce sont les correctifs — de sécurité en particulier — et le support sur incident dans les conditions contractuelles habituelles. L'effet pratique apparaît rarement le jour de l'échéance : il apparaît au premier audit de sécurité, au premier incident bloquant, ou au premier changement d'environnement qui exigerait une compatibilité que plus personne ne certifie.
C'est pourquoi une échéance ne se traduit pas mécaniquement en date de migration. Elle se traduit en date de réexamen, à laquelle on remet trois éléments sur la table : l'exposition réelle du socle, le coût du support étendu s'il est proposé, et l'état d'avancement du tri d'usage. Rester dix-huit mois de plus sur un socle exposé mais isolé peut être la décision juste, à condition qu'elle soit écrite.
Un relevé qui reste vrai dans six mois
Ces dates font partie des éléments périssables, au même titre que les grilles tarifaires. Un réexamen trimestriel suffit : il consiste à rouvrir les notes déjà identifiées, à vérifier si la date a bougé, et à mettre à jour la ligne avec sa nouvelle date de consultation. Ce travail prend une heure par trimestre et évite l'argument qui fait renvoyer un dossier en séance suivante.
Conservez le relevé sous forme tabulaire, avec une ligne par couple produit-version : éditeur, produit, version, fin de maintenance mainstream, fin de maintenance étendue, cible recommandée par l'éditeur, adresse de la note, date de relevé. Chaque ligne porte sa propre date, parce que les notes ne sont pas mises à jour toutes en même temps.
Ce que cette page ne couvre pas
Elle ne dit pas vers quoi migrer. La cible recommandée par un éditeur est une information à relever, pas une recommandation à reprendre : l'éditeur recommande son propre catalogue, ce qui est légitime de sa part et insuffisant pour votre arbitrage.
Elle ne traite pas les clauses de votre contrat-cadre — plafonds de revalorisation, conditions du support étendu, engagements de volume — qui pèsent souvent plus lourd que l'échéance elle-même. Sur ce terrain, la bonne personne est votre direction des achats.
À lire ensuite
Le silo « Échéances éditeurs » du blog développe cette page article par article :
- Socles BI en fin de support : les échéances à surveiller
- SAP BW vers BW/4HANA : ce que la bascule impose vraiment
- OBIEE en fin de vie : Oracle Analytics Server ou Cloud ?
- Informatica PowerCenter vers IDMC : le calendrier réel
- Talend Open Studio en fin de vie : migrer ou changer d'ETL
Voir tous les articles « Échéances éditeurs »
Journal de mise à jour
- — Première publication de la page pilier.