Vue fonctionnelle : démêlez le spaghetti de votre application

Sans conventions de nommage, une application IBM i devient vite illisible : un plat de spaghetti où l’on ne sait plus où commence une nouille ni où finit l’autre. La vue fonctionnelle de DISCOVER en reconstitue la carte : à partir du code, des métadonnées et des liens entre composants, elle déduit le découpage fonctionnel, le nomme et le rend navigable bien au-delà des seuls développeurs.

Ne construisez plus cette carte vous-même. Pointez votre application, demandez la détection des composants et le nommage des nœuds par IA. L’outil travaille en arrière-plan sur les grosses applications, pendant que vous passez à autre chose.

Deux mécanismes se complètent. À partir du référentiel de métadonnées ARCAD, des algorithmes de Louvain regroupent les composants selon leurs interactions et forment des groupes fonctionnels ; l’IA retravaille ensuite le nommage pour le rendre accessible. L’algorithmique garantit, l’IA rend lisible.

Le résultat est une arborescence à plusieurs niveaux : un parent (disons la gestion des commandes et des clients) a ses enfants, qui ont eux-mêmes les leurs. Pour chaque groupe, vous voyez le nombre de composants, leur type et le détail de ce qu’il contient.

Le nommage est déduit des descriptions de composants, très utilisées sur l’IBM i : un fichier commande et des programmes associés donnent un titre comme « gestion des commandes ». Le découpage, lui, repose sur l’analyse des liens entre composants : poids, interactions et type. Un programme qui modifie un fichier ne pèse pas comme un programme qui le lit, et cette distinction nourrit chaque niveau.

Rien n’est figé pour autant. L’IA ne colle pas toujours à la façon dont on veut voir les choses : renommez un nœud, regroupez autrement, ajoutez des commentaires ou de nouveaux enfants.

Une fois la carte construite, deux sens de lecture s’offrent à vous. Partez du plus haut niveau (l’application entière) et plongez, ou partez d’un composant et remontez vers ce qui l’entoure.

Trois points de départ sont possibles :

À mesure que vous descendez, une mini-carte situe votre position. Vous survolez un nœud pour révéler son contenu, consultez les liens entrants et sortants, tracez le chemin depuis le menu principal, zoomez à la molette pour reprendre de la hauteur.

Posez la question « si je modifie ce composant, qu’est-ce qui est impacté ? ». L’outil ressort tous les éléments concernés dans un diagramme plus concis qu’une analyse d’impact classique, chacun avec son positionnement fonctionnel.

Une analyse de développeur travaille programme à programme ; ici, elle est orientée fonctionnel. Changez un simple programme CL, et vous voyez aussitôt qu’il touche la gestion des commandes et des clients, jusqu’à la création de commande. Pour vous repérer : liens pleins pour une connexion directe, cercles pointillés pour la zone d’influence.

La carte ne sert pas qu’à comprendre, elle sert aussi à nettoyer. Un composant isolé, qui ne tourne pas avec les autres, n’a peut-être rien à faire dans le périmètre de l’application : retirez-le.

À l’inverse, un groupe incomplet trahit souvent un composant manquant. Ce fichier devrait être relié aux commandes ou aux clients, mais le lien n’apparaît pas : en cherchant, vous découvrez que le programme dort dans la bibliothèque d’un développeur, à l’écart. Remettez la source à sa place, relancez l’analyse, et le fichier se reconnecte à son contexte.

Là où il n’y avait qu’un enchevêtrement technique, lisible surtout pour des techniciens chevronnés, la vue fonctionnelle fait apparaître une carte fonctionnelle vivante et accessible : construite automatiquement, navigable, corrigeable. Surtout, cette connaissance ne reste plus l’apanage de quelques-uns : développeurs, analystes et responsables de modernisation y accèdent dans un langage qu’ils comprennent.

Les diagrammes se sauvegardent et s’intègrent à votre documentation. Et l’approche tient à l’échelle : l’un de nos clients exploite DISCOVER sur une application de quelque 92 000 composants, relations comprises.