Le system programmer installe et règle z/OS, le DBA tient Db2, l'ingénieur middleware administre CICS et IMS. L'architecte technique mainframe travaille au-dessus de ces métiers. Il choisit le nombre de LPAR et de systèmes dans le sysplex, la répartition des charges entre les sites, le mode de réplication GDPS, la façon dont une application Java ou un partenaire appelle une transaction. Il porte aussi les sujets que la direction regarde : la facture logicielle, le renouvellement des machines, la sortie ou non de certaines applications.
Les candidats sortent presque tous d'un poste d'ingénieur système, de production ou de middleware sur z/OS, avec une grande profondeur sur une brique. L'entretien vérifie qu'ils raisonnent sur l'ensemble : ce que coûte un pic de MSU sur la moyenne glissante de quatre heures, ce qui se passe quand une coupling facility disparaît, ce qu'une API change par rapport à un échange de fichiers. Les profils venus du distribué connaissent souvent la modernisation, mais sous-estiment le batch et le data sharing.
Les missions récentes associent souvent le mainframe à Java et au cloud, sur des projets de cohabitation ou de migration. Le PDF propose 30 questions sur six axes, un cas de 20 minutes et une grille de notation.
Le socle IBM Z sous la responsabilité de l'architecte
IBM Z et z/OS
Les serveurs IBM Z, dont la génération z17 est disponible depuis juin 2025, découpés en partitions logiques (LPAR). z/OS 3.2 est sorti en septembre 2025 et z/OS 2.5 a quitté le support standard fin septembre 2026. L'architecte suit ces calendriers pour planifier machines et versions.
Parallel Sysplex
Plusieurs systèmes z/OS qui travaillent comme un seul, reliés par des coupling facilities. Avec le data sharing de Db2 ou d'IMS et la répartition des transactions, une application continue de tourner quand un système s'arrête. Le nombre de systèmes et l'emplacement des coupling facilities sont des choix d'architecture.
GDPS et réplication des disques
L'offre d'IBM qui pilote la continuité entre sites : réplication synchrone des disques sur courte distance, avec HyperSwap pour basculer les disques sans arrêt, et réplication asynchrone vers un site lointain. Elle automatise la bascule des systèmes et des disques lors d'un sinistre ou d'un test.
CICS, IMS, Db2 for z/OS et IBM MQ
Les moniteurs transactionnels, la base de données et la messagerie du mainframe. L'architecte ne les administre pas au quotidien, mais il décide où tourne une nouvelle fonction, comment les données sont partagées et comment les messages circulent avec le distribué.
z/OS Connect et ouverture
z/OS Connect expose des transactions CICS ou IMS et des données Db2 sous forme d'API REST décrites en OpenAPI. S'y ajoutent MQ, la réplication de données vers le distribué et la publication d'événements vers Kafka. Le choix du mode d'échange dépend du temps réel attendu et du coût CPU.
Capacité et facturation logicielle
La facture des logiciels IBM se calcule souvent sur la consommation en MSU, mesurée sur une moyenne glissante de quatre heures. Le plafonnement de capacité, les processeurs zIIP et les offres Tailored Fit Pricing, facturées à la consommation, changent ce calcul. Un architecte mainframe doit savoir lire ce poste de coût.
Sécurité z/OS
RACF ou un produit équivalent pour les identités et les droits, le chiffrement des data sets et des flux, la propagation de l'identité d'un utilisateur d'API jusqu'à la transaction. L'ouverture du mainframe multiplie les points d'entrée et doit être pensée avec la sécurité.
Modernisation et DevOps
Git, Zowe et des pipelines de build pour le COBOL, réhébergement sur des environnements qui émulent CICS et JCL hors mainframe, réécriture progressive en Java, ou maintien sur z/OS avec des API. L'architecte construit la trajectoire et chiffre chaque option.
Le poste se rencontre chez les grands utilisateurs d'IBM Z, chez les infogéreurs qui hébergent des mainframes pour plusieurs clients et en prestation, souvent en mission longue sur un programme de modernisation. Les offres sont peu nombreuses et visent des profils seniors, avec une forte expérience de z/OS et du middleware. Les sujets récents mêlent cohabitation avec Java et le cloud, analyse des traitements batch et des accès aux données, et définition de trajectoires de migration. La connaissance du distribué est attendue, mais la profondeur sur z/OS reste le critère qui écarte le plus de candidats.
Ce qu'un architecte mainframe doit maîtriser
- Topologie Parallel Sysplex et LPAR
- Continuité, GDPS et cyber-résilience
- Architecture CICS, IMS, Db2 et MQ
- Ouverture par API, événements et sécurité
- Capacité, MSU et coûts logiciels
- Trajectoires de modernisation
Questions d'architecture IBM Z et réponses attendues
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Une application transactionnelle doit continuer à tourner pendant l'arrêt d'un système z/OS. Que faut-il dans la topologie du sysplex pour que ce soit vrai ?
Une bonne réponseAu moins deux systèmes actifs, idéalement sur deux machines, avec Db2 ou IMS en data sharing pour que chacun accède aux mêmes données. Deux coupling facilities dont une hors des machines qui hébergent les systèmes, ou des structures dupliquées. Des régions CICS clonées sur chaque système, une répartition des transactions par CICSPlex SM, et une adresse réseau dynamique (Sysplex Distributor, DVIPA) pour que les clients ne voient pas l'arrêt. Il vérifie aussi que l'application n'a pas d'affinité avec un système.
Signal d'alerte« Le mainframe ne tombe jamais », ou un sysplex à deux systèmes sans data sharing présenté comme hautement disponible.
Question 2 · senior
Vous concevez la continuité entre deux sites à 20 km et un troisième à 600 km. Comment répartissez-vous la réplication avec GDPS ?
Une bonne réponseRéplication synchrone des disques entre les deux sites proches, avec HyperSwap pour basculer les disques sans arrêt des systèmes et un RPO nul. Réplication asynchrone vers le site lointain, avec un RPO de quelques secondes, pour le sinistre régional. Il précise l'emplacement des systèmes de contrôle GDPS, hors des systèmes de production, les liens à prévoir et l'ordre de bascule. Il fait tester la bascule complète, pas seulement celle des disques.
Signal d'alerteUne réplication synchrone vers le site à 600 km, ou des sauvegardes sur bande présentées comme un plan de reprise.
Question 3 · confirmé
Un partenaire doit consulter en temps réel des données gérées par une transaction CICS. API, MQ ou réplication de données vers le distribué : comment tranchez-vous ?
Une bonne réponseUne API par z/OS Connect quand le partenaire a besoin de la règle métier de la transaction et d'une réponse immédiate, avec un contrat OpenAPI et une granularité pensée pour l'appelant. MQ quand l'échange peut être asynchrone ou que le mainframe doit être protégé des pics. Une réplication des données vers une base distribuée quand les lectures sont massives et que la donnée brute suffit, ce qui retire la charge du mainframe. Il chiffre l'effet de chaque option sur la consommation CPU et donc sur la facture.
Signal d'alerteOuvrir un accès direct à Db2 depuis l'extérieur, ou une seule réponse quel que soit le besoin.
Question 4 · senior
La facture logicielle IBM a pris 15 % en un mois, à volumes métier constants. Quels relevés ouvrez-vous en premier, et qu'y cherchez-vous ?
Une bonne réponseIl part des rapports de consommation (SCRT, enregistrements SMF 70 et 89) pour trouver le pic de la moyenne glissante sur quatre heures, la LPAR et l'heure. Il cherche ce qui tourne à ce moment-là : un batch décalé, une nouvelle API, un REBIND qui a dégradé un chemin d'accès, une charge Java qui ne part plus sur zIIP. Il propose de déplacer des traitements hors du pic, de corriger le programme en cause, de revoir le plafonnement, et compare avec un contrat à la consommation si le profil s'y prête.
Signal d'alerteDemander une remise à IBM sans analyse, ou ignorer le lien entre pic de consommation et facture.
Question 5 · senior
La direction veut sortir une application du mainframe d'ici trois ans. Par quoi commencez-vous, et comment chiffrez-vous le gain réel ?
Une bonne réponseUn inventaire des programmes, des transactions, des chaînes batch, des données et des dépendances avec les autres applications. Un choix argumenté par bloc : réhébergement sur un environnement qui émule CICS et JCL, réécriture progressive en Java avec des API qui isolent l'existant, ou maintien de certains blocs sur z/OS. Il prévoit la synchronisation des données pendant la cohabitation, des tests de non-régression qui comparent les sorties batch, et il chiffre ce que la sortie fait réellement baisser dans la facture.
Signal d'alerteUne conversion automatique de tout le COBOL en une seule bascule, ou une estimation du gain fondée sur le seul coût du matériel.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Architecte mainframe : réponses aux questions courantes
Architecte mainframe ou system programmer z/OS : quelle différence en entretien ?
Le system programmer installe et maintient z/OS, règle WLM, prépare les IPL et applique la maintenance. L'architecte décide de la forme du socle et de son évolution : topologie du sysplex, continuité entre sites, ouverture, coûts, trajectoire. Beaucoup d'architectes ont été system programmers, et c'est un bon signe. En entretien, chacun décrit une décision qu'il a portée devant une direction, avec les options écartées et le chiffrage.
Un architecte venu du distribué peut-il porter un programme de modernisation ?
Pour la cible Java ou cloud, oui. Pour la partie mainframe, il lui faudra un binôme expert z/OS. Les risques d'une modernisation se trouvent souvent dans le batch, le data sharing, les dépendances entre chaînes et la facture logicielle, que les profils distribués connaissent mal. Quand un seul profil porte le programme, il doit savoir lire une chaîne batch et expliquer ce qu'est une moyenne glissante sur quatre heures.
Quel test technique pour un architecte mainframe ?
Un cas en entretien vaut mieux qu'un questionnaire sur les commandes z/OS. Le cas décrit un sysplex, deux sites, une facture et une demande d'ouverture par API, et attend un schéma et une recommandation. Une contrainte s'ajoute en cours de route, comme un budget logiciel gelé ou une exigence de reprise après cyberattaque. On voit vite si la personne relie disponibilité, coûts et sécurité.
Ces profils sont-ils plutôt salariés ou indépendants ?
Les deux. Les grands utilisateurs d'IBM Z recrutent en CDI pour garder la compétence, et beaucoup de missions de modernisation passent par des ESN ou des indépendants pour quelques mois. Pour une mission courte, une expérience de la même trajectoire est attendue. Pour un poste durable, la profondeur sur le sysplex et la continuité compte davantage, car la trajectoire évoluera plusieurs fois pendant le contrat.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
