Guide · Maintenance IBM i (AS400)
Un serveur IBM i qui fait tourner la gestion commerciale, la comptabilité ou la production ne s’entretient pas comme un parc Windows. Le système est réputé stable, mais sa maintenance repose sur quelques savoir-faire peu répandus : configuration des Power Systems, application des PTF, sauvegardes système et programmes RPG écrits parfois depuis des années. Cette page s’adresse aux dirigeants, aux DAF et aux responsables informatiques qui se demandent quand reprendre la main sur cet environnement et comment cadrer une prestation.
Sommaire
La maintenance IBM i (AS400), c’est quoi ?
Maintenir en condition opérationnelle un environnement IBM i consiste à garder le système, les données et les applications en service, tout en préparant ses évolutions. Le terme AS/400 désigne la lignée d’origine : le système s’appelle aujourd’hui IBM i et fonctionne sur des serveurs Power Systems, parfois découpés en partitions LPAR pour séparer production, test et secours.
Système et correctifs
Les corrections sont livrées sous forme de PTF, regroupées en paquets cumulatifs et en groupes de PTF par domaine (base de données, Java, sécurité, matériel). Leur application suppose de connaître la version d’IBM i en place, le niveau déjà installé et la compatibilité avec les logiciels sous licence. Une version qui sort du support de l’éditeur ne reçoit plus de corrections : la montée de version devient alors une décision à planifier, avec des tests sur les applications métier.
Sauvegardes et reprise
La sauvegarde combine la sauvegarde système (SAVSYS, qui exige le système en état restreint, donc un arrêt planifié) et celle des bibliothèques applicatives, souvent pilotée par BRMS. Une sauvegarde n’a de valeur que si elle se restaure : des tests réguliers, sur des objets choisis, vérifient la chaîne complète. Le plan de secours, qu’il s’agisse d’une réplication vers un autre serveur ou d’une partition de reprise, doit être accompagné d’une procédure de redémarrage écrite.
Applications RPG et échanges
Beaucoup d’environnements contiennent des programmes RPG et des programmes CL accumulés au fil des années, parfois en format fixe ancien, parfois en RPG libre plus récent. Leur maintenance suppose de comprendre les sources, les fichiers physiques et logiques, et les files de messages où remontent les erreurs. Les utilisateurs y accèdent le plus souvent par une émulation 5250, tandis que les échanges avec le reste du système d’information passent par fichiers à plat, transferts FTP, accès ODBC à la base Db2 for i ou services web : ce sont souvent les points les moins documentés.
Quand faut-il s’en occuper ?
Plusieurs signaux montrent qu’un environnement IBM i demande une reprise en main :
- Une connaissance concentrée sur une personne : l’administrateur maison connaît seul le système et approche de la retraite, sans procédure écrite.
- Une version qui sort du support : le serveur tourne encore, mais les correctifs ne suivent plus et la montée de version se fait sous contrainte.
- Des PTF jamais appliquées : l’installation date, et personne n’a repris le calendrier des correctifs depuis.
- Des sauvegardes jamais restaurées : les supports sont produits chaque nuit, sans qu’une restauration complète ait été vérifiée.
- Des programmes RPG que plus personne n’ose modifier : faute de documentation des sources et des dépendances, chaque changement paraît risqué.
- Une maintenance matérielle qui arrive à échéance : le contrat du constructeur doit être renouvelé ou remplacé, et son coût comparé à d’autres options.
- Des échanges bricolés : les flux vers la comptabilité, la boutique en ligne ou des partenaires reposent sur des traitements non supervisés.
- Une direction qui hésite : moderniser l’application de gestion ou la remplacer est une décision qui gagne à s’appuyer sur un état des lieux précis.
Comment se déroule un projet
Avant : état des lieux
Le spécialiste relève la version d’IBM i, le niveau de PTF, le modèle du serveur Power Systems, la liste des applications et leurs dépendances, ainsi que l’état des sauvegardes et des plans de secours. Ce diagnostic écrit sert à chiffrer deux options, maintenir ou migrer, et à fixer les priorités avant tout engagement sur un périmètre.
Pendant : correctifs, tests et bascule
Les correctifs sont appliqués sur une fenêtre convenue, avec une procédure de retour arrière. Une montée de version passe par une copie de test, une série de contrôles sur les programmes RPG et les traitements de fin de période, puis une bascule planifiée en dehors des heures de travail. Le calendrier se précise au devis, selon la taille de l’environnement et les périodes d’activité de l’entreprise.
Après : supervision et passation
La surveillance des files de messages, des travaux en erreur, de l’espace disque et des performances est mise en place ou ajustée. La documentation des procédures et des accès, ainsi que la passation de connaissances à l’équipe qui suivra le serveur, sont remises à l’entreprise pour que la compétence ne repose plus sur une seule personne.
Ce qui distingue une bonne offre
Deux propositions ne sont comparables que si elles couvrent le même périmètre. Une offre sérieuse précise d’abord le niveau de maintenance inclus : correctifs seuls, ou correctifs, surveillance et interventions. Elle indique les horaires d’intervention, l’existence d’une astreinte et le mode d’intervention, à distance ou sur place. Elle explique comment la compétence IBM i est doublée au sein du prestataire, et qui réalise les montées de version. Elle distingue les tâches récurrentes, comme l’application des PTF, des projets ponctuels, comme la modernisation de programmes RPG ou l’intégration d’une nouvelle interface. Enfin, elle décrit les livrables : documentation, procédures de restauration testées, tableau de bord de supervision. Une offre qui reste vague sur ces points paraît moins chère mais se révèle souvent plus coûteuse à l’usage.
Les erreurs fréquentes
Quelques erreurs reviennent souvent dans les environnements IBM i. Chacune a sa parade :
- Confier la maintenance sans état des lieux : exigez un diagnostic écrit avant de signer sur un périmètre.
- Repousser les correctifs indéfiniment : l’écart se creuse et chaque application devient plus difficile à valider. Un calendrier de PTF convenu avec les équipes métier évite cette dérive.
- Ne jamais tester la restauration : une sauvegarde réussie n’est pas forcément utilisable. Planifiez un test documenté sur des objets représentatifs.
- Modifier un programme RPG sans cartographie : une dépendance oubliée provoque un incident en fin de traitement. Inventoriez sources et interfaces avant toute modification.
- Réduire la compétence à une seule personne : le jour de son départ, le savoir disparaît avec elle. Tenez une documentation à jour et désignez un binôme.
Les questions à poser avant de signer
Qui interviendra concrètement sur votre serveur ? Demandez les profils prévus, les accès accordés et la manière dont la compétence est doublée, car les spécialistes IBM i sont moins nombreux que sur d’autres systèmes.
Quel calendrier de correctifs et de montées de version est proposé ? Le planning doit dire qui valide les tests et quelles applications sont vérifiées avant chaque bascule.
Les tests de restauration sont-ils inclus et planifiés ? Une sauvegarde qui n’a jamais été restaurée ne prouve rien. Vérifiez la fréquence des tests, leur périmètre et le compte rendu remis.
Comment la connaissance des applications RPG est-elle consignée ? Le prestataire doit pouvoir expliquer quels documents seront remis à l’entreprise et qui pourra les mettre à jour après la fin du contrat.