Mainframes et centralisation¶

L'ere ou tout tournait sur une seule machine — et pourquoi ce modèle refuse de mourir.

Le contexte historique¶

Dans les années 1960, l'informatique d'entreprise naissait autour d'une évidence : une seule machine puissante servait tous les utilisateurs. IBM dominait le marche avec le System/360, lance en 1964 — une famille de machines compatibles entre elles, ce qui constituait une revolution. Avant le System/360, chaque modèle avait son propre jeu d'instructions, ses propres périphériques, son propre système d'exploitation. Changer de machine signifiait reecrire tout le logiciel.

Le System/360 a introduit un principe fondamental qui nous parait évident aujourd'hui : la compatibilité ascendante. On pouvait écrire un programme sur un modèle d'entree de gamme et le faire tourner sur un modèle plus puissant sans modification. Ce principe a permis aux entreprises d'investir dans le logiciel en sachant que cet investissement survivrait au remplacement du matériel.

Note

La compatibilité ascendante du System/360 a créé un verrouillage si puissant qu'IBM continue de vendre des mainframes z16 en 2025, toujours compatibles avec du code écrit en 1964.

Architecture centralisee¶

L'architecture mainframe repose sur un modèle radicalement centralise. Toute la puissance de calcul, toute la mémoire, tout le stockage se trouvent dans une seule machine physique. Les utilisateurs interagissent via des terminaux passifs — de simples écrans relies au mainframe par des lignes dédiées.

graph TB
    MF["Mainframe central<br/>CPU + Memoire + Stockage"]
    T1["Terminal 3270"]
    T2["Terminal 3270"]
    T3["Terminal 3270"]
    T4["Terminal 3270"]
    IMP["Imprimante"]
    DISK["Disques<br/>DASD"]
    TAPE["Bandes<br/>magnetiques"]

    T1 --SNA/SDLC--> MF
    T2 --SNA/SDLC--> MF
    T3 --SNA/SDLC--> MF
    T4 --SNA/SDLC--> MF
    MF --- DISK
    MF --- TAPE
    MF --- IMP

Le terminal 3270 d'IBM est l'exemple type du terminal passif. Il n'effectue aucun traitement local. Il envoie des frappes clavier au mainframe et affiche les écrans que le mainframe lui renvoie. Toute la logique — de la validation d'un champ de saisie au calcul d'un solde bancaire — s'exécuté sur le mainframe.

Caractéristiques du terminal passif¶

Aspect	Description
Traitement local	Aucun — tout est délégué au mainframe
Affichage	Écran a caractères, pas de graphique
Protocole	SNA (Systems Network Architecture)
Autonomie	Inutilisable sans connexion au mainframe
Coût	Faible par poste — la puissance est centralisee

Ce modèle a un avantage majeur que l'on sous-estime souvent : la simplicité opérationnelle. Il n'y a qu'une seule machine a administrer. Les mises à jour se font en un seul endroit. Il n'y a pas de problème de cohérence entre des copies distribuées. La sécurité est centralisee. Le déploiement est instantané — on change le programme sur le mainframe et tous les utilisateurs voient immédiatement la nouvelle version.

Batch processing¶

Le traitement par lots (batch) est le mode d'exécution originel des mainframes. On soumet un ensemble de travaux (jobs) qui s'exécutent sequentiellement sans interaction utilisateur. Chaque job est défini par un langage de contrôle — JCL (Job Control Language) chez IBM.

//PAIEJOB  JOB (COMPTA),'PAIE MENSUELLE',CLASS=A
//STEP1    EXEC PGM=CALCPAIE
//INPUT    DD DSN=RH.EMPLOYES.DATA,DISP=SHR
//OUTPUT   DD DSN=COMPTA.PAIE.RESULT,DISP=(NEW,CATLG)
//SYSOUT   DD SYSOUT=A

Ce JCL définit un job de paie. Il prend en entree le fichier des employes, exécuté le programme CALCPAIE, et produit un fichier de résultats. Si le job échoué, il peut être relance sans effet de bord — les fichiers intermédiaires sont nettoyes automatiquement.

Le batch processing n'a rien de primitif. Il résout elegamment plusieurs problèmes :

Optimisation des ressources : les jobs tournent la nuit quand les terminaux sont inactifs
Reproductibilite : le même job avec les mêmes données produit le même résultat
Auditabilite : chaque exécution est tracee, horodatee, archivee
Planification : les dépendances entre jobs sont declarees explicitement

Tip

Les pipelines CI/CD modernes, les DAGs Airflow, les jobs Spark — tous descendent conceptuellement du batch processing mainframe. On a change les outils, pas le paradigme.

Transaction monitors¶

L'arrivee du traitement transactionnel en ligne (OLTP) a transforme le mainframe. Au lieu d'attendre la nuit pour traiter les opérations, on pouvait désormais les exécuter en temps réel — retrait bancaire, reservation de vol, mise à jour de stock.

Deux systèmes ont domine cette ere :

CICS (Customer Information Control System)¶

CICS est un moniteur transactionnel qui géré les interactions utilisateur en temps réel. Il prend en charge la gestion des terminaux, le routage des transactions, la gestion de la mémoire et la coordination avec les bases de données. Un programme CICS reçoit une requête, effectue le traitement, met à jour la base et renvoie un écran de réponse — le tout en quelques millisecondes.

IMS (Information Management System)¶

IMS combine une base de données hierarchique et un moniteur transactionnel. Développé pour le programme Apollo de la NASA, il gerait l'inventaire des pieces du module lunaire. Sa base hierarchique navigable est un ancêtre direct des bases de données document comme MongoDB.

sequenceDiagram
    participant T as Terminal 3270
    participant CICS as CICS Region
    participant PGM as Programme COBOL
    participant DB as DB2 / IMS DB

    T->>CICS: Transaction (ex: INQC)
    CICS->>PGM: Routing vers programme
    PGM->>DB: SQL / DL/I
    DB-->>PGM: Resultats
    PGM-->>CICS: Ecran de reponse
    CICS-->>T: Affichage BMS

Le concept clé introduit par CICS et IMS est la transaction ACID : atomique, cohérente, isolee, durable. Si une opération échoué a mi-chemin, tout est annule. Si le mainframe tombe en panne pendant une transaction, celle-ci est automatiquement annulee au redémarrage. Ce niveau de garantie reste un standard que les systèmes distribués modernes peinent a atteindre.

Pourquoi les mainframes survivent¶

Un chiffre revient souvent : les mainframes traitent encore environ 70% des transactions financieres mondiales. Ce n'est pas de l'inertie — c'est un choix rationnel. Les tentatives de migration ont souvent échoué ou coute plus cher que le maintien.

Facteur	Explication
Fiabilité	Disponibilité de 99,999% — 5 minutes d'arrêt par an
Performance I/O	Architecture optimisee pour les E/S massives, pas le calcul pur
Sécurité	Certification EAL5+, chiffrement matériel intégré
Capacité transactionnelle	Des milliards de transactions par jour sans dégradation
Coût par transaction	Paradoxalement bas malgre le prix d'achat élevé
Base de code existante	Des millions de lignes de COBOL qui fonctionnent

Le problème n'est pas technique — il est humain. Les développeurs COBOL partent à la retraite. La formation sur ces systèmes a quasiment disparu des universites. Le risque principal du mainframe en 2025 n'est pas la panne matérielle, c'est la perte de compétences.

Warning

Avant de proposer une migration off-mainframe, on doit chiffrer le coût réel : reecriture du code, migration des données, validation reglementaire, risque opérationnel. La plupart des projets de migration mainframe depassent leur budget initial d'un facteur 3 a 5.

Héritage : concepts qui survivent¶

Le mainframe a forge des concepts que l'on retrouve partout dans l'informatique moderne, souvent sans en connaître l'origine :

Transactions¶

Les propriétés ACID définies par les moniteurs transactionnels mainframe restent la référence. Chaque base de données relationnelle les implémenté. Les systèmes distribués modernes (Saga, 2PC) sont des tentatives de reproduire ces garanties dans un contexte où elles ne sont plus gratuites.

Files de messages¶

Les mainframes utilisaient déjà des files de messages pour découpler les producteurs des consommateurs. MQSeries (devenu IBM MQ) est ne sur mainframe avant d'être porte sur d'autres plateformes. Kafka, RabbitMQ, SQS — tous reposent sur le même principe.

Scheduling et orchestration¶

Le JES (Job Entry Subsystem) du mainframe géré la soumission, la priorisation et l'enchainement des jobs batch. C'est exactement ce que font aujourd'hui Kubernetes Jobs, Airflow, Temporal ou Step Functions — avec plus de flexibilite mais les mêmes concepts fondamentaux.

Le mainframe a été le premier système multi-utilisateur à grande échelle. Les mécanismes d'isolation entre utilisateurs (RACF pour la sécurité, partitions logiques) sont les ancêtres directs de la virtualisation et du multi-tenancy cloud.

graph LR
    subgraph "Concepts mainframe"
        A["Transactions ACID"]
        B["Files de messages"]
        C["Scheduling batch"]
        D["Multi-tenancy"]
    end

    subgraph "Equivalents modernes"
        E["Saga / 2PC"]
        F["Kafka / RabbitMQ"]
        G["Airflow / K8s Jobs"]
        H["Cloud / Conteneurs"]
    end

    A --herite--> E
    B --herite--> F
    C --herite--> G
    D --herite--> H

La leçon du mainframe¶

Le mainframe nous enseigne une vérité inconfortable : la centralisation fonctionne remarquablement bien quand on peut se la permettre. Un seul point de déploiement, une seule source de vérité, une seule équipe d'exploitation — c'est infiniment plus simple à opérer qu'un système distribué.

On a quitte le mainframe non pas parce qu'il etait mauvais, mais parce qu'il ne pouvait pas répondre a deux exigences nouvelles : l'interface graphique riche que les utilisateurs reclamaient, et la decentralisation du pouvoir de décision informatique vers les départements métier. Le PC et le client/serveur ont apporte ces deux choses — au prix d'une complexité opérationnelle que le mainframe n'avait jamais connue.

Chaque fois qu'on construit un système distribué, on devrait se demander : est-ce que la distribution est vraiment nécessaire, ou est-ce qu'on pourrait résoudre le problème avec un système plus simple et plus centralise ?

Chapitre suivant : Client-serveur — la decentralisation commence, avec ses promesses et ses pieges.