Migration mainframe vers le cloud : les enjeux stratégiques du commerce moderne

Si vous pensiez que le mainframe était une relique du passé, Shopify nous rappelle dans son guide Mainframe-to-Cloud Journey: Enterprise Commerce (2026) que la réalité est tout autre: environ 10 000 mainframes seraient encore en activité aujourd'hui, dont sept des dix plus grands retailers mondiaux. Pour les directions e-commerce, la migration n'est plus un débat théorique, mais un arbitrage de plus en plus urgent. Et c'est précisément là que les choses se compliquent, parce qu'une mauvaise feuille de route peut coûter cher — très cher.

Le vrai sujet, c'est ce qui se passe autour du mainframe

Le matériel, lui, fonctionne toujours. Ce qui a changé, c'est le coût de tout ce qui l'entoure: maintenance, intégrations, et surtout les opportunités marché qu'on laisse filer pendant qu'une demande d'évolution dort dans un pipeline. Selon les chiffres relayés par Shopify (issus d'une étude Kyndryl), 98 % des organisations déplacent aujourd'hui une partie de leurs applications hors du mainframe, mais la part moyenne migrée est passée de 36 % à 28 % en un an, et sur 500 répondants, un seul prévoit de tout sortir. Les équipes deviennent sélectives: on ne migre plus « par principe », on choisit ses charges de travail. Vous reconnaissez probablement ce réflexe — on garde ce qui est critique, on repousse ce qui est trop risqué, et on reporte la décision stratégique. C'est humain, mais c'est aussi ce qui finit par faire dériver les chantiers.

Migration ou modernisation: ne confondez plus les deux

C'est le piège que je vois le plus souvent en mission. Une migration déplace une charge de travail vers une autre infrastructure; une modernisation change la façon dont cette charge est construite pour tirer parti du nouveau terrain. Et, détail que beaucoup de CTO découvrent après la bascule: on peut migrer sans moderniser, puis constater, un an plus tard, que l'agilité n'est pas au rendez-vous. Le workload tourne dans le cloud, oui, mais comme il tournait avant, avec ses rigidités d'origine. La cible n'est d'ailleurs presque jamais un fournisseur unique: le schéma hybride revient dans presque tous les projets sérieux — infrastructure d'un hyperscaler, plateforme SaaS pour la couche transactionnelle, et une couche d'intégration qui relie ce qui reste sur site. C'est ce réalisme qui rend la décision plus facile: on arrête de chercher LA destination, et on assigne chaque workload à la bonne.

Ce qu'il faut mettre sur la table avant de lancer le projet

Avant d'enthousiasmer votre COMEX, trois questions méritent un audit honnête. Quelles fonctions commerce critiques reposent encore sur le mainframe — gestion des commandes, moteurs de prix, allocation de stock, facturation B2B? Quel est le coût total de possession réel, en incluant l'immobilisation que représente chaque demande de changement bloquée? Et surtout, quel est le coût acceptable d'une coupure ou d'un incident pendant la bascule? Si vous n'avez pas de réponse claire à ces trois questions, le dossier que vous présenterez à votre direction financière ne tiendra pas. C'est souvent à ce stade que les projets basculent du « c'est urgent » au « on refait un point dans six mois » — et je vois encore trop d'entreprises s'y enliser. Le bon réflexe, à mon sens: traiter chaque système métier selon sa propre tolérance au downtime et ses dépendances aval, plutôt que de parler du mainframe comme d'un bloc monolithique.