Avant d’envisager une modernisation ou un changement important sur IBM i, il est indispensable de commencer par un diagnostic.

Pas un audit générique, mais une vraie photographie de l’existant, métier par métier, programme par programme, pour savoir où on en est… et où on peut aller.

D’abord : comprendre le contexte et les objectifs

On ne prépare pas un jogging comme on prépare la Diagonale des Fous. Tout dépend de vos ambitions : voulez-vous moderniser une application, toute votre base de données, ou repenser l’ensemble de votre système ?

Un diagnostic commencera donc par des échanges avec vos équipes pour bien comprendre votre histoire, votre organisation, vos priorités et vos forces.

Une analyse à deux niveaux : globale et détaillée

Après cette première étape « humaine », il faut procéder à l’analyse technique.

Elle va se faire en deux temps :

• Quantitative, sur l’ensemble du périmètre (objets, programmes, bases, etc.)

• Qualitative, sur un échantillon plus restreint pour regarder en détail la qualité du code, des données, ou les pratiques utilisées

Des outils pour faire parler les programmes

Des outils vont être installés (il s’agit de la solution X Analysis) pour identifier :

• Les objets inutilisés (certains systèmes passent de 4000 fichiers à 800 actifs…)
• Les objets sans source ou dont le source est obsolète
• Les programmes selon leur complexité (nombre de boucles, lignes de code, niveaux imbriqués…)
• Les écarts entre objets et sources, très fréquents

Cela permet aussi de reconstituer les liens entre programmes, d’identifier ceux qui appellent des objets disparus, et d’évaluer les zones de risques.

Une vision claire grâce à des livrables adaptés

A l’issu de notre diagnostic, des documents sont remis :
– Un rapport complet (Qui reprend point par point, de manière détaillée, les périmètres audités)
– Une synthèse claire, avec les points clés et des recommandations
– Une proposition de feuille de route pour éclairer votre horizon

Focus sur la base de données et la qualité des données

C’est souvent la partie la plus négligée… et la plus critique. L’analyse va permettre d’identifier :

• Les enregistrement orphelins ou en doublons
• Les règles de gestion enfouies dans le code plutôt que portées par les données
• L’absence de contraintes d’intégrité (problématique dès qu’on veut exploiter ses données de maière fiable)

Un échantillon de 10 à 20 tables est étudié, et on en profite généralement pour vous montrer que le passage à SQL est sans impact sur vos programmes actuels.

Un accompagnement progressif

Le diagnostic se déroule sur plusieurs jours, avec des interviews, des collectes de données, et l’utilisation d’un outillage avancé. Il s’accompagne aussi de réflexions sur la sécurité, la performance, et l’organisation de vos équipes si besoin.

L’objectif : sortir du « monolithe » IBM i hérité du passé, et se rapprocher d’un système clair, modulaire, maîtrisé — tout en restant fidèle à la robustesse de la plateforme.

Visionnez la vidéo de 30 min détaillant ce process de Thierry Labrunie lors de iBelieve 2024 :