Exposer un service COBOL via une API REST : cas concret et architecture

Aujourd’hui, faire dialoguer du COBOL avec une application web n’a plus rien de théorique.
Que ce soit pour afficher une donnée en temps réel dans un portail client ou orchestrer un traitement à distance, exposer un service COBOL via une API REST, c’est possible. Et surtout, c’est devenu un vrai sujet dans les projets de modernisation mainframe.

Ce qu’il faut, c’est une architecture propre, une séparation claire des responsabilités, et un peu de méthode. Pas besoin de réécrire toute l’application. Juste poser un pont entre un monde fiable et un monde plus agile.

Pourquoi une API REST sur un système COBOL ?

Exposer un traitement COBOL via une API REST permet :

d’ouvrir un service legacy à d’autres systèmes modernes
de mutualiser des règles métier critiques
d’accélérer des projets côté front, mobile ou microservices
Le tout sans dupliquer la logique métier, ni compromettre la stabilité de l’existant.

On envoie pas tout le mainframe dans le cloud, on expose ce qui a de la valeur proprement.

Une architecture claire en trois couches

Le bon schéma, c’est celui qui isole le COBOL de l’API. On travaille souvent comme ça :

com.monsite.api
Interface publique : endpoints REST, contrôleur, objets de requête/réponse
com.monsite.service
Couche métier Java qui dialogue avec COBOL (socket, fichier, bridge, etc.)
com.monsite.impl
Implémentations spécifiques : version classique, moderne, mocks, etc.

Ce découpage permet de tester chaque couche indépendamment, de gérer plusieurs implémentations, et de faire évoluer le fond sans casser la forme.

Conception de l’API : contrat clair, types bien définis

Une bonne API REST, c’est un contrat stable.
On déclare une interface Java claire, indépendante de l’implémentation :


public interface CobolServiceApi {
    ResponseData processRequest(RequestData request);
}

Et les objets d’échange :


public class RequestData {
    private String accountNumber;
    private double amount;
    // getters / setters
}


public class ResponseData {
    private boolean transactionSuccess;
    private String message;
    private double newBalance;
    // getters / setters
}

Au final, cette approche permet de changer la logique COBOL derrière sans modifier le contrat REST exposé à l’extérieur.

Injection dynamique des implémentations COBOL

Plutôt que de coder une version en dur, on peut injecter dynamiquement l’implémentation selon le contexte (Spring ou autre DI).

Exemple de deux versions :


@Service("CobolClassique")
public class CobolClassiqueServiceImpl implements CobolServiceApi {
    public ResponseData processRequest(RequestData request) {
        // appel au programme COBOL classique
    }
}


@Service("CobolModerne")
public class CobolModerneServiceImpl implements CobolServiceApi {
    public ResponseData processRequest(RequestData request) {
        // nouvelle logique avec bridge ou wrapper
    }
}

Et dans le contrôleur :


@RestController
public class CobolServiceController {

    @Autowired
    private ApplicationContext appContext;

    @PostMapping("/cobol-service/{impl}")
    public ResponseData traiter(@PathVariable String impl,
                                @RequestBody RequestData request) {
        CobolServiceApi service = appContext.getBean(impl, CobolServiceApi.class);
        return service.processRequest(request);
    }
}

L’avantage ici est qu’on peut ajouter une nouvelle version sans toucher au contrôleur.
Juste une nouvelle classe et une nouvelle annotation.

Ce qu’il faut prévoir (et sécuriser)

Exposer du COBOL via une API REST, ce n’est pas anodin. Quelques points à bien gérer :

Performance

Évitez d’appeler un batch complet pour chaque requête. Gardez les appels REST rapides, isolés, sans effet de bord.

Encodage

COBOL → EBCDIC
REST → UTF-8

Pensez conversion. Sans ça, les caractères spéciaux ne passeront jamais correctement.

Sécurité

HTTPS obligatoire
Authentification robuste (OAuth2, JWT)
Validation stricte des inputs (rien ne passe sans contrôle)
Journalisation propre (sans fuite de données sensibles)

Et bien sûr, gérez les erreurs COBOL proprement pour renvoyer des statuts HTTP explicites (200, 400, 500, etc.).

Exemple concret d’architecture en place

Sur un projet dans le secteur assurantiel, un programme COBOL permettait de calculer en temps réel une simulation de prime.
Ce programme a été encapsulé via un microservice REST Java, qui appelle le COBOL en socket via un bridge natif et provoquait ainsi :

aucune logique métier réécrite
une intégration directe dans les parcours web
un délai de livraison raccourci de plusieurs semaines

Ce type de mise en API, on l’a déjà mis en place sur plusieurs projets, dans des contextes très différents.
Banque, assurance, logistique : dans tous les cas, l’idée est la même : exposer une brique COBOL sans réécrire 100 000 lignes.

On intervient pour cadrer l’architecture, définir les contrats API, et sécuriser les ponts entre les mondes.

Refonte d’une application COBOL bancaire critique via API Java

Banque & finance

Migration d’une application COBOL vers Java / Angular

Assurance

Tuning et optimisation d’un traitement batch COBOL sous Unix

Industrie

Conclusion

Exposer un service COBOL via une API REST, ce n’est pas faire du neuf avec du vieux.
C’est intégrer une logique éprouvée dans une architecture moderne, sans sacrifier ni la stabilité, ni la maintenabilité.

Avec une architecture en couches, une séparation claire entre API et implémentation, et un minimum de rigueur sur la sécurité et la performance, le COBOL peut parfaitement s’intégrer dans un écosystème API-first.

Contact

Vous avez un programme COBOL à exposer ?

Vous cherchez à exposer un traitement COBOL via une API REST sans tout refaire ?
On peut vous accompagner pour cadrer l’architecture, sécuriser les échanges, et mettre en production rapidement une passerelle stable.