Fermeture d'un datacenter, migration vers Azure et OpenStack, engagement de disponibilité à 99,99 % et 15 % de coût d'exploitation en moins. Le déroulé réel, y compris ce qui a failli bloquer.
Un grand compte du secteur public français, un datacenter à fermer, et deux cents applications qui ne pouvaient pas s'arrêter.
Le datacenter hébergeait un système d'information construit sur vingt ans : applications métier, socles d'échange, annuaires, outils de gestion interne. La décision de fermeture du site était prise, la date connue, et aucune application ne disposait d'une architecture cible documentée.
Trois contraintes rendaient le projet non standard. Les applications étaient enchaînées entre elles, si bien qu'en déplacer une seule ne fonctionnait pas. Une partie des socles techniques arrivait en fin de vie (systèmes AIX, environnements Windows anciens) et ne pouvait pas être simplement recopiée. Enfin, les fenêtres d'intervention étaient très courtes : les métiers ne pouvaient pas perdre le service plus de quelques heures, y compris la nuit et le week-end.
Quatre étapes, dans cet ordre. Les inverser est la cause la plus fréquente des migrations qui dérapent.
Chaque application a été décrite par son propriétaire métier, son socle technique, ses flux entrants et sortants et sa criticité. Ce travail a duré plusieurs mois et a évité de découvrir les dépendances pendant les bascules.
Trois scénarios ont été chiffrés en coût complet : tout cloud public, tout cloud privé, et hybride. Le scénario retenu combine Azure pour les applications les plus standardisées et OpenStack pour celles qui exigent un socle maîtrisé, avec un plan de reprise d'activité pour chaque lot.
Les applications ont été regroupées par grappes de dépendances, puis migrées vague par vague, en commençant par les moins critiques pour roder le processus. Chaque vague comportait une fenêtre de bascule, un retour arrière testé et une cellule de crise prête à revenir en arrière sous une heure.
Une migration n'est terminée que quand l'exploitation sait faire sans l'architecte. Documentation d'exploitation, procédures de reprise, tests de restauration et formation des équipes internes faisaient partie du périmètre, pas d'une option.
200 applications migrées sans arrêt de service supérieur aux fenêtres annoncées, et un datacenter fermé à la date prévue.
15 % de coût d'exploitation en moins par rapport à l'hébergement sur site, à périmètre de service égal. L'écart vient du socle technique : moins de serveurs physiques à maintenir, moins de contrats de support matériel, une supervision factorisée.
99,99 % de disponibilité engagée, avec un plan de reprise d'activité testé et une restauration vérifiée, pas seulement documentée.
Le point le plus utile n'est pas le chiffre : c'est que la méthode a survécu à un changement de périmètre en cours de route. Les grappes de dépendances identifiées à l'étape 1 ont permis de réordonner des lots sans reprendre l'ensemble du plan.
Le périmètre est plus petit, les pièges sont les mêmes.
Vous devez sortir d'une plateforme dont le support s'arrête. La question n'est pas « vers quoi migrer » mais « dans quel ordre, sans casser ce qui fonctionne ».
Le coût d'exploitation se pilote par l'architecture, pas par la renégociation. Dimensionnement, stockage, sorties réseau et supervision pèsent plus que le tarif horaire.
Une sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde. Nous testons la restauration, pas seulement la copie.
Nous apportons la conception et restons sur l'exécution des lots critiques, puis nous transférons. L'équipe interne garde la connaissance.
Un audit de 12 points, mené sur vos serveurs et vos sauvegardes, qui aboutit à une liste d'actions classées par risque. Aucun engagement au-delà.
Disponibilité, sauvegardes, reprise d'activité, sécurité des accès, obsolescences, coûts. Vous repartez avec le rapport et les priorités, que nous travaillions ensemble ensuite ou non.
Vous cherchez un renfort d'architecte plutôt qu'un prestataire complet ? Voir l'offre de renfort en sous-traitance.
