Entrazure
Ce que couvre le conseil
Le portefeuille applicatif, établi une bonne fois. Chaque application avec un propriétaire nommé, sa criticité pour les affaires, son statut de support chez l’éditeur, l’endroit où elle tourne, ce qu’elle coûte en hébergement et en licences, et sa fréquence réelle de changement. La plupart des organisations détiennent trois versions partielles de cette liste dans trois directions différentes, et aucune ne concorde. Le mandat en produit une seule, dans un format qui peut être tenu à jour ensuite.
L’infrastructure en dessous. Versions de systèmes d’exploitation et de bases de données face à leurs dates de fin de support, réalité de la sauvegarde et de la restauration face aux objectifs affichés, identité, et chemins réseau dont les applications dépendent. C’est de là que viennent en général les échéances qui commandent la feuille de route, et ce sont rarement celles dont la direction discute en ce moment.
Une décision par application. Retirer, réhéberger, replateformer, refactorer ou conserver. Un choix par application, consigné avec sa raison, son coût et la condition qui le ferait changer.
Un plan par phases, avec un coût par phase. Des phases regroupées par dépendance plutôt que par direction, chacune avec une condition d’entrée, une condition de sortie, un coût et le risque qu’elle retire. Le plan dit ce que chaque phase achète, pour qu’un conseil d’administration puisse approuver la phase deux sans approuver tout le programme sur la foi d’une intention.
La question de la capacité, traitée honnêtement. Qui exécute chaque phase : votre équipe, un partenaire de réalisation, ou nous. Là où le plan suppose une compétence que votre organisation n’a pas, c’est écrit dans le plan plutôt que découvert au quatrième mois. Nos architectes travaillent en pratique : le raisonnement derrière chaque recommandation est documenté et relisible, il ne réside pas dans la mémoire d’une seule personne.
Les cinq décisions possibles
Retirer. La modernisation la moins chère qui existe. Les applications sans utilisateurs, celles que double un outil que vous payez déjà, et celles maintenues en vie pour un rapport que trois personnes lisent. Les candidates au retrait sont identifiées avec une preuve d’usage et un propriétaire nommé qui signe, parce que retirer une application sur une supposition est la manière classique de découvrir son dernier utilisateur critique.
Réhéberger. La déplacer telle quelle, dans un abonnement gouverné, avec le système d’exploitation et la base de données ramenés à une version supportée. Rapide, réversible et simple à raisonner, ce qui en fait la bonne réponse bien plus souvent que le marché ne l’admet. Réhéberger achète aussi du temps pour décider correctement, et le temps est en général la ressource rare.
Replateformer. Garder l’application, changer ce sur quoi elle repose : une base vers Azure SQL Managed Instance, une couche web vers App Service, un traitement par lots vers Container Apps. Effort d’ingénierie modéré, réduction réelle de ce que votre équipe doit corriger et exploiter.
Refactorer. Changer l’application elle-même. C’est l’option chère, et elle se justifie par la fréquence de changement, pas par l’âge. Une application qui livre souvent la mérite, une application qui n’a pas bougé depuis des années ne la mérite pas, quelle que soit l’impression qu’elle donne de l’extérieur. Quand nous recommandons de refactorer, l’argumentaire est construit en termes de modernisation applicative et chiffré comme tel.
Conserver. La laisser où elle est, délibérément, avec la raison écrite et une date de revue attachée. Dépendance matérielle, contrainte de latence, frontière de support éditeur et projet de remplacement déjà engagé sont des raisons légitimes de conserver. Azure Arc ramène les serveurs, les instances SQL et les clusters conservés sous les mêmes politiques, la même supervision et la même gestion des mises à jour que le reste : conserver ne veut donc pas dire exploiter deux modèles pour toujours.
Comment se déroule le mandat
Phase 1, l’inventaire. Accès en lecture seule, données de découverte plutôt que chiffriers, contrats et position de licences, entretiens avec les personnes qui exploitent chaque système. Aucune modification en production, à aucun moment.
Phase 2, les décisions de sort. Des séances de travail par groupe d’applications, avec les propriétaires dans la salle. Chaque application ressort de la séance avec une décision consignée ou avec un point bloquant nommé et une date. Les blocages sont presque toujours une question de propriété ou de support éditeur, et les deux se règlent moins cher ici qu’en pleine migration.
Phase 3, le séquencement et le coût. Les phases sont assemblées par dépendance, chiffrées, et ordonnées pour que les échéances qui mordent vraiment soient tenues d’abord. Le livrable inclut les phases que nous avons déconseillées, avec la raison : un plan qui cache ses options rejetées ne peut pas être contesté.
Phase 4, la gouvernance. Le portefeuille est transféré sous forme de registre vivant, avec une cadence de revue, un responsable et le petit ensemble de champs qu’il faut tenir à jour pour qu’il garde sa valeur. Un portefeuille que personne ne met à jour est une photo, et une photo se périme en un trimestre.
Ce que vous gardez
- Le portefeuille applicatif, avec un propriétaire, un coût et une fréquence de changement par application.
- Une décision consignée par application, avec sa raison et la condition qui la renverserait.
- Le calendrier de fin de support des systèmes d’exploitation, des bases de données et des produits éditeurs.
- Un plan par phases, avec condition d’entrée, condition de sortie et coût pour chacune.
- La liste des applications orphelines, isolée, avec la décision que chacune attend.
- Une analyse de rentabilité en langage de conseil d’administration : ce que coûte chaque phase, et ce qu’elle évite.
Pour qui c’est
Des organisations de 50 à 5 000 personnes portant un parc constitué sur une décennie ou plus, avec un mandat de modernisation et aucune fonction d’architecture interne pour lui donner forme. Des manufacturiers avec des systèmes d’usine, des organismes publics avec des applications métier de longue vie, des groupes de services de santé avec des dépendances cliniques, et toute organisation qui a absorbé une acquisition et hérité d’une deuxième version de tout.
Le mandat s’enchaîne bien juste après une stratégie infonuagique, qui règle la destination, et juste avant une migration infonuagique, qui exécute les décisions de sort consignées ici.
Pour qui ce n’est pas
Si vous savez déjà exactement ce qui bouge et quand, et que le désaccord porte sur l’exécution plutôt que sur la direction, achetez la migration et sautez le conseil.
Si le mandat est de réduire les coûts ce trimestre, la modernisation est le mauvais instrument. L’optimisation des coûts infonuagiques agit plus vite et n’exige pas un programme.
Et si la vraie contrainte est que personne ne financera les phases, le plan sera juste et rien ne se produira. C’est une question de direction et non d’architecture, qu’un mandat de direction SI à temps partagé traite plus directement qu’un rapport.
Pages liées
- Stratégie infonuagique, les décisions qui fixent la destination.
- Modernisation applicative, ce que replateformer et refactorer veulent dire concrètement.
- Migration infonuagique et sortie de VMware, le mandat qui exécute les décisions de sort.
- Azure infogéré et FinOps, le modèle d’exploitation dans lequel le parc atterrit.
- Tous les services Azure, le catalogue dans lequel chaque phase puise.
Questions fréquentes
Nous n’avons aucun architecte à l’interne. Est-ce que ça complique tout ?
C’est la situation de départ normale, et elle change le livrable plutôt que le prix. Sans fonction d’architecture interne, le plan est écrit pour être exécuté par une équipe d’exploitation appuyée par un partenaire de réalisation, et le raisonnement est consigné en entier au lieu d’être supposé. Nous disons aussi clairement quelles phases exigent une compétence que vous ne détenez pas aujourd’hui.
Faut-il tout moderniser ?
Non, et un plan qui modernise tout est un plan écrit pour être vendu, pas pour être exécuté. La plupart des portefeuilles se résolvent surtout en retirer, réhéberger et conserver, avec un petit ensemble d’applications où replateformer ou refactorer se rentabilise vraiment. Nommer ce petit ensemble avec justesse, c’est la valeur du mandat.
Qui décide du sort de chaque application ?
Vous, en séance de travail, avec notre recommandation et le raisonnement sous les yeux. Nous apportons les faits : statut de support, fréquence de changement, coût d’hébergement et de licences, dépendances, et le risque d’exploitation qu’il y a à ne rien faire. La décision est consignée avec le nom de la personne qui l’a prise et la date.
Et si une application n’a pas de propriétaire ?
C’est un constat, pas un obstacle. Une application dont personne ne répond est soit une candidate au retrait, soit un incident qui attend son déclencheur, et il coûte moins cher de trancher maintenant que pendant une fenêtre de migration. Les applications orphelines sont listées à part, pour que la direction voie la taille du problème.
En quoi est-ce différent d’un plan de migration ?
Un plan de migration répond à la question du comment. Celui-ci répond à la question du faut-il, dans quel ordre, et à quel coût par rapport à ce que ça évite. Les deux s’enchaînent : les décisions de sort prises ici deviennent le plan de vagues du mandat de migration, et plusieurs applications seront retirées avant que quoi que ce soit ne bouge.
Pouvez-vous exécuter le plan ensuite ?
Oui, et le plan est écrit pour que vous ne soyez pas obligés de nous choisir. Les phases portent des services nommés, des conditions d’entrée et de sortie et un coût par phase, ce dont un tiers compétent a besoin. Quand nous réalisons, le conseil et la construction sont chiffrés séparément, pour que chacun se juge sur ses propres mérites.
Une question sur ce mandat ?
Trois champs. Un architecte le lit et répond en un jour ouvrable.