Suisse · Migration cloud
Le contexte
Migration des applications métier d'un établissement bancaire suisse vers un cloud privé OpenStack hébergé en Suisse. Le dossier a commencé par un audit des applications et des flux de données, s'est poursuivi par une bascule découpée en lots avec un repli possible à chaque étape et des tests de non-régression conduits avec les équipes métier, puis s'est prolongé par la supervision et l'exploitation de la cible. Nous publions cette référence sans nommer l'établissement : détailler l'architecture d'un système d'information à côté de la raison sociale de son propriétaire diminue la sécurité de ce système, et nous appliquons cette réserve à tous nos dossiers d'infrastructure. Dans une banque, l'informatique n'est pas un support parmi d'autres, c'est l'outil de production : un collaborateur qui n'ouvre pas un dossier client ne travaille pas, et l'indisponibilité se voit tout de suite en agence. S'y ajoute une exigence propre à ce secteur, celle de savoir où résident les données et qui en garde la maîtrise, question qui se tranche avant celle du coût ou de la performance.
Ce que nous avons réalisé
- Audit des applications et des flux de données
- Cible cloud privé OpenStack, hébergement en Suisse
- Bascule par lots avec repli possible
- Tests de non-régression avec les équipes métier
- Supervision et run après bascule
Rapatrier les données sans arrêter les agences
Les applications tournaient chez un hébergeur situé hors de Suisse, et la direction voulait ramener les données sous une gouvernance locale. Les deux exigences du projet se contredisaient en apparence : un déménagement d'infrastructure est toujours plus simple lorsqu'on peut tout arrêter, alors qu'une banque ne ferme pas ses agences pour laisser passer un chantier technique. Il fallait donc un scénario autorisant un retour en arrière à chaque palier, et non une bascule unique dont l'échec se paierait un lundi matin. Nous comparons les options d'hébergement local dans notre article sur garder ses données en Suisse.
La seconde difficulté était la dépendance entre applications. Un applicatif métier ne vit jamais seul : il s'appuie sur un annuaire, des bases, des échanges de fichiers, des flux entrants et sortants dont personne ne tient la liste complète. Tant que ces liens ne sont pas cartographiés, tout découpage en lots reste arbitraire et le plan de repli n'est qu'une intention. Le lieu d'hébergement de la cible relève de la même logique, celle d'un choix d'architecture arrêté en amont, comme nous l'expliquons dans notre article sur le choix d'une région cloud en Europe ou en Suisse.
Cartographier, puis basculer par lots avec retour arrière
L'audit a porté sur les applications et sur les flux de données avant toute décision de cible : ce qui parle à quoi, ce qui doit rester ensemble, ce qui peut partir seul. La cible retenue est un cloud privé OpenStack hébergé en Suisse, une orientation que nous détaillons sur notre page consacrée à OpenStack et qui répond à la contrainte de localisation sans transformer le système en assemblage sur mesure impossible à exploiter ensuite.
La bascule a ensuite été menée par lots, chaque vague disposant d'une fenêtre validée et d'un plan de retour, avec des tests de non-régression joués par les équipes métier et non par nous seuls : ce sont elles qui reconnaissent un comportement anormal dans leur propre application. Nous décrivons cette mécanique de lots et de repli dans notre article sur migrer vers le cloud sans coupure, et l'ensemble de la prestation sur notre page migration cloud. La supervision a pris le relais dès le lendemain de chaque vague, puisqu'une plateforme livrée sans exploitant se dégrade avant même d'avoir servi.
Comment nous avons procédé
-
Cadrage et cartographie
1 à 2 jours
-
Migration par lots
selon le volume
-
Run et supervision
en continu
Des applications métier exploitées en Suisse
Les applications métier tournent sur la cible convenue, hébergée en Suisse, et les agences n'ont pas eu à subir de coupure prolongée pendant le déplacement. Ce qui a fait la différence tient moins à l'outillage qu'à la méthode : des lots réversibles, et une validation confiée à ceux qui utilisent les applications tous les jours. L'exploitation est documentée et assurée par l'équipe qui a mené la migration, ce qui évite la transmission de dossier entre un intégrateur qui s'en va et un exploitant qui découvre la plateforme au premier incident.
Un projet, une panne, un rendez-vous.
Choisissez un créneau, ou décrivez votre besoin : nous répondons avec un périmètre clair, un prix hors taxes, et un interlocuteur nommé.