Natural et ADABAS : un couple qui ne se migre pas naïvement
Les applications Natural sur ADABAS ont une réputation méritée de rapidité et de robustesse. Contrairement à une idée répandue, ce ne sont pas des technologies figées : l’éditeur les fait évoluer, elles tournent aujourd’hui sur Linux et dans le cloud, et elles s’exposent en API REST. Ce qui vieillit, ce n’est pas la plateforme — c’est la connaissance du code écrit dessus.
Pourquoi elles sont encore là
ADABAS a été conçu pour des accès très rapides sur de gros volumes, à une époque où cela supposait de renoncer au modèle relationnel. Le pari a tenu : ces applications traitent aujourd’hui des charges considérables avec des temps de réponse que leurs remplaçantes peinent parfois à égaler. Et Natural, langage de quatrième génération, permet d’écrire en quelques lignes ce qui en demanderait cinquante ailleurs — donc d’avoir produit, en trente ans, un patrimoine applicatif énorme pour un effectif modeste.
Ce patrimoine est précisément le problème : il est vaste, il est vivant, et les gens qui le connaissent partent.
Une plateforme qui a continué d’évoluer
Il faut le dire clairement, parce que beaucoup de décisions se prennent sur une image datée : Software AG maintient un engagement de support affiché jusqu’en 2050 et au-delà, sous le nom d’Adabas & Natural 2050+. Concrètement, cela veut dire que la plateforme n’impose plus les contraintes qu’on lui prête.
Natural et ADABAS tournent sur le mainframe comme sur Linux et dans le cloud. Le développement se fait dans NaturalONE, un environnement moderne fondé sur Eclipse, avec gestion de versions et intégration dans une chaîne DevOps — on ne développe plus dans un éditeur pleine page. La logique métier écrite en Natural s’expose en points d’accès REST et OpenAPI, ce qui permet à une application web ou à un service tiers de l’appeler sans rien réécrire. Et côté mainframe, une partie de la charge peut être déportée sur processeurs spécialisés pour réduire la facture.
La conséquence est importante pour votre arbitrage : rester n’est pas forcément immobile, et partir n’est pas la seule façon de moderniser. Une organisation peut parfaitement conserver son cœur Natural, l’ouvrir en API, déplacer son exploitation sur Linux et travailler en intégration continue. Encore faut-il que quelqu’un sache lire le code existant pour savoir ce qui peut être exposé et ce qui doit être repris.
Ce qui rend la reprise difficile
Un modèle de données qui n’est pas relationnel
ADABAS n’est pas une base relationnelle habillée autrement. Un même champ peut contenir plusieurs valeurs, des groupes de champs peuvent se répéter au sein d’un enregistrement, et des clés composées peuvent être calculées à partir de morceaux d’autres champs. Tout cela est naturel dans ADABAS et n’a pas d’équivalent direct en SQL. La projection vers un modèle relationnel n’est donc pas une conversion : c’est une décision de conception, prise fichier par fichier, qui engage la suite.
Le programme mélange les couches
Natural a été pensé pour que le même code décrive l’accès aux données, la règle de gestion et l’écran. C’est ce qui le rend productif, et c’est ce qui complique la migration : pour séparer ce qui doit devenir une base, un service et une interface, il faut d’abord identifier les trois dans un texte qui ne les distingue pas.
Les définitions de données sont partagées
Les descriptions de fichiers sont mutualisées entre les programmes. Une modification apparemment locale se propage, et le périmètre réel d’un changement n’apparaît qu’à qui sait remonter ces dépendances.
Ce que je fais
Maintien en condition opérationnelle
Corrections, évolutions, analyse d’incidents, optimisation d’accès. Le travail courant sur une application qui doit continuer de servir.
Cartographie du patrimoine
Quels programmes existent réellement, lesquels sont encore appelés, quelles définitions de données sont partagées, où sont les règles de gestion. Sur un patrimoine Natural, cet inventaire réserve toujours des surprises — du code mort en quantité, et des traitements critiques que personne n’avait recensés.
Transfert de compétences
Former l’équipe qui reprend, sur son propre code : structure d’un programme Natural, accès aux données, pièges des champs multiples et des groupes répétitifs, méthode de lecture d’un existant.
Appui sur la migration
Le rôle qui manque presque toujours : celui qui connaît le système de départ et peut dire à l’équipe cible ce que chaque structure signifie réellement, plutôt que de la laisser deviner.
Les quatre voies, et ce qu’elles coûtent
Moderniser sur place est la voie qu’on oublie le plus souvent, alors que c’est fréquemment la plus rentable : garder le cœur Natural, l’exposer en API, passer l’exploitation sur Linux, industrialiser les livraisons. Le patrimoine est conservé, le risque est faible, et l’application redevient intégrable au reste du système d’information. Elle suppose toutefois de continuer à disposer de la compétence Natural, donc de la transmettre.
Le réhébergement change le socle sans toucher à l’application : il traite le risque d’infrastructure, pas celui de compétence.
Le transcodage automatique produit du code cible à partir du Natural existant. Il se heurte au modèle de données — champs multiples, groupes répétitifs, clés calculées — et le résultat doit être éprouvé sur des données réelles avant d’être cru.
La réécriture donne le meilleur système final et suppose de connaître l’ancien, puisque c’est lui la spécification. Ce qui ramène à la cartographie.
Je ne vends aucune de ces quatre voies, et je n’ai pas d’intérêt à ce que vous quittiez la plateforme. Je vous aide à choisir sur des faits, et je tiens le côté existant quelle que soit la décision.
Pour qui
Les organisations qui exploitent un patrimoine Natural/ADABAS avec une équipe qui se réduit, les sociétés de services qui en héritent dans un contrat de TMA, et les directions qui doivent arbitrer une migration sans dépendre du seul avis de celui qui la réalisera.
J’interviens aussi sur OpenVMS, Bull GCOS 7, COBOL et les environnements mainframe IBM.