Évaluation de la préparation au Cloud : guide pour la transformation des entreprises

Une évaluation de la préparation à l'infonuagique est une analyse pré-migration structurée de l'infrastructure TI, des applications, de la posture de sécurité, des capacités organisationnelles et des hypothèses économiques d'une organisation, conçue pour déterminer si des charges de travail spécifiques et l'organisation dans son ensemble sont prêtes à migrer. Il ne s'agit pas d'une évaluation de la maturité infonuagique, qui mesure la capacité infonuagique actuelle et la sophistication opérationnelle. L'évaluation de la préparation mesure le niveau de préparation à la migration—et son résultat le plus important n'est pas la liste des charges de travail approuvées pour la migration, mais celles qui ne devraient pas l'être.

Pourquoi l'évaluation de la préparation à l'infonuagique est importante

Sauter ou condenser une évaluation de la préparation n'élimine pas ses coûts. Elle ne fait que les reporter à la phase de migration, où leur résolution est beaucoup plus coûteuse. Les conséquences d'une migration sans évaluation rigoureuse sont aussi prévisibles que précises :

• Échec de migration et reprise non planifiée
• Exposition à des risques de conformité
• Mauvais calcul du TCO
• Mauvais alignement stratégique

Une évaluation est le mécanisme utilisé pour déterminer si le risque de migration est acceptable avant que l’organisation ne s’engage dans la migration.

Principaux éléments d’une évaluation de l’état de préparation au cloud

Une évaluation rigoureuse de l’état de préparation au cloud examine sept domaines distincts. Chacun requiert sa propre méthodologie et produit ses propres constats de type aller/non-aller. Considérer ces domaines comme une simple liste de vérification unifiée—plutôt que comme des dimensions d’évaluation indépendantes—est l’endroit où la plupart des évaluations perdent en précision.

• Préparation de l’infrastructure
• Préparation des applications et des charges de travail
• Préparation des données
• Sécurité, conformité et gestion des risques
• Préparation organisationnelle et des compétences
• Analyse économique et TCO
• Alignement sur le modèle de déploiement infonuagique

Chacun de ces domaines est traité en détail dans les sections qui suivent. Le cadre n'est pas séquentiel — les sept domaines doivent tous être évalués avant de prendre les décisions liées à la séquence de migration, car les constats faits dans un domaine influent souvent sur les seuils de décision dans les autres.

Évaluation de votre infrastructure TI existante

La découverte de l’infrastructure est l’endroit où commencent les évaluations incomplètes — et où elles causent le plus de tort en aval. La tentation de limiter l’évaluation de l’infrastructure à un champ étroit, ou de s’appuyer sur les inventaires existants d’actifs, entraîne invariablement le même type d’échec : des dépendances non documentées émergent en cours de migration et obligent à des reprises imprévues.

L’évaluation de la préparation de l’infrastructure couvre six dimensions nommées :

• Inventaire et découverte
• Capacité de calcul
• Architecture réseau
• Systèmes de stockage
• Cartographie des dépendances
• Références de performance

Notez que l’évaluation de votre infrastructure ne se termine pas à la phase de découverte. Elle s’achève lorsque la cartographie des dépendances est suffisamment complète pour permettre l’ordonnancement des migrations de charges de travail sans créer de dépendances circulaires lors du transfert.

Évaluation de la préparation des applications et des charges de travail

L’évaluation des applications est le domaine où se prennent les décisions de mise en production les plus importantes — et où une mauvaise classification entraîne les échecs post-migration les plus coûteux.

Schéma de classification des charges de travail

Chaque charge de travail applicative évaluée en vue d’une migration vers le cloud appartient à l’une des quatre catégories suivantes. Les critères qui déterminent la classification ne sont pas subjectifs : ils découlent de caractéristiques mesurables de la charge de travail :

• Cloud native : Charges de travail sans état, conteneurisées ou basées sur des microservices, sans dépendances rigides à l'infrastructure, conçues pour s'exécuter dans des environnements infonuagiques sans modification. Leur migration comporte un risque minimal.
• Prêtes pour le cloud : Charges de travail avec état pouvant fonctionner dans des environnements infonuagiques sans changements architecturaux, pourvu que les exigences de latence respectent les tolérances du réseau cloud et que la gravité des données n'entraîne pas de coûts de transfert prohibitifs. Ces charges exigent une validation des dépendances avant la migration, mais pas de refonte.
• Refonte requise : Charges de travail avec des architectures monolithiques, des références d’infrastructure codées en dur ou des profils de performance dépassant les tolérances réseau du cloud. La migration est possible, mais nécessite une correction architecturale avant la coupure. Le calendrier de correction doit être pris en compte dans la séquence de migration—ces charges ne peuvent être migrées au même rythme que les applications prêtes pour le cloud.
• À conserver sur site : Charges de travail nécessitant une latence inférieure à 100 ms entre des composants ne pouvant pas être co-localisés dans le cloud, applications sensibles à la conformité dans des juridictions où les exigences de résidence des données ne sont satisfaites par aucune région cloud disponible, ou systèmes patrimoniaux avec dépendances matérielles qui n’ont pas d’équivalent cloud. Il ne s'agit pas de « prêtes pour le cloud avec refonte »—elles sont candidates à la conservation sur site. L’évaluation doit mener explicitement à cette conclusion, et non la repousser.

Attribution du modèle de migration

La classification détermine quel modèle de migration est approprié. Ce sont des décisions distinctes et elles ne doivent pas être confondues :

• Rehost : Transfert direct (« lift-and-shift ») vers l’infrastructure infonuagique sans changement d’application. Approprié pour les charges de travail prêtes pour le nuage lorsque la rapidité de migration est prioritaire sur les opportunités d’optimisation.
• Replatform : Migrer vers un service infonuagique géré (p. ex., passer d’une base de données autogérée à un service de base de données géré) avec des modifications d’application minimales. Approprié pour les charges de travail prêtes pour le nuage lorsque la réduction des frais opérationnels justifie une complexité de migration modérée.
• Refactor : Reconcevoir l’architecture de l’application pour le déploiement natif infonuagique. Approprié pour les charges de travail nécessitant une refonte lorsque le bénéfice opérationnel à long terme justifie l’investissement de correction.
• Retire : Retirer les charges de travail sans utilisateurs actifs ou aux fonctionnalités redondantes. Les évaluations révèlent souvent des candidats à la mise hors service qui n’étaient pas visibles dans les portefeuilles d’applications existants.
• Retain : Conserver sur place sans migration. Le bon modèle pour les charges de travail classées « à conserver sur place »—il ne s’agit pas d’un état provisoire, mais bien du résultat d’une évaluation délibérée.

Sécurité, conformité et évaluation des risques

Le modèle de responsabilité partagée est le concept fondamental qui détermine la portée de l’évaluation de la sécurité et de la conformité. Selon ce modèle, les fournisseurs de services infonuagiques gèrent la sécurité de l’infrastructure infonuagique—installations physiques, hyperviseurs, réseau—tandis que les clients demeurent responsables de tout ce qui est déployé dans cet environnement : gestion des identités et des accès, chiffrement des données, segmentation réseau, sécurité applicative et conformité réglementaire. La frontière entre les contrôles gérés par le fournisseur et ceux gérés par le client varie selon le modèle de déploiement et le type de service, ce qui signifie que la portée de l’évaluation de la sécurité et de la conformité ne peut être déterminée tant que les modèles de déploiement potentiels n’ont pas été identifiés.

Préparation organisationnelle et des compétences

Une charge de travail peut être techniquement prête pour l’infonuagique même si l’organisation n’a pas les compétences ou les pratiques opérationnelles pour la gérer. Ces deux dimensions de préparation n’avancent pas nécessairement au même rythme, et confondre la classification des charges de travail avec la préparation organisationnelle mène souvent à des incidents post-migration.

L’analyse des écarts de compétences doit être spécifique à chaque rôle, et non globale. Les évaluations génériques qui concluent que « l’équipe a besoin d’une formation infonuagique » n’aboutissent à aucune recommandation exploitable. L’évaluation doit cibler les écarts par rapport aux exigences définies pour chaque rôle :

• Analyse de l’écart de compétences par catégorie de rôle, y compris les architectes cloud, ingénieurs DevOps, spécialistes FinOps et spécialistes en sécurité
• Dimensions de la préparation du modèle d’exploitation : adoption du CI/CD, infrastructure en tant que code et pratiques infonuagiques natives
• Préparation culturelle et gestion du changement : L’organisation doit disposer d’un mandat exécutif, de structures de collaboration interfonctionnelles et d’une capacité de gestion du changement pour soutenir les transformations opérationnelles qu’exige la migration infonuagique

Choisir le bon modèle de déploiement infonuagique

La sélection du modèle de déploiement n’est pas une décision d’architecture technique prise après l’évaluation des charges de travail. Les contraintes de conformité et les exigences de contrôle sont des filtres non négociables qui éliminent certains modèles de déploiement avant même d’évaluer la pertinence technique. Une organisation ayant des charges de travail réglementées soumises à des exigences de souveraineté des données dans des juridictions où les régions infonuagiques publiques ne répondent pas aux exigences de résidence ne peut pas choisir le nuage public pour ces charges, peu importe les avantages en termes de coûts ou de performance. L’évaluation doit appliquer en premier lieu les filtres de conformité.

Défis courants lors des évaluations de la préparation infonuagique

Il existe une réelle tension au cœur de chaque évaluation de la préparation infonuagique : une découverte exhaustive et une cartographie des dépendances prennent du temps, ce que les échéanciers de migration accommodent rarement, mais une évaluation incomplète peut mener à des échecs de migration qui consomment beaucoup plus de temps que les travaux de découverte n’en auraient pris. Aucun choix n’est sans coût. Les défis ci-dessous sont ceux où cette tension risque le plus de causer des problèmes.

• Découverte incomplète
• Mauvaise classification de la charge de travail
• Mauvaise compréhension de la responsabilité partagée
• Mauvais calcul des écarts de compétences
• Erreurs de modélisation des coûts

Meilleures pratiques pour l’évaluation de la préparation au Cloud

1. Outils de découverte automatisés — Déployez des outils de découverte automatisés avec et sans agent sur l’ensemble du périmètre de l’infrastructure avant le début de toute évaluation manuelle. L'analyse par agent capte les dépendances au niveau des processus et les connexions réseau que les outils sans agent ne peuvent détecter; la détection sans agent permet d’atteindre les périphériques réseau et les systèmes hérités ne prenant pas en charge les agents.
2. Équipe d’évaluation interfonctionnelle — Constituez l’équipe d’évaluation en y incluant dès le départ des architectes de l’infrastructure, des responsables d’applications, des spécialistes en sécurité, des responsables de la conformité et des parties prenantes des finances.
3. Validation de la charge de travail pilote — Sélectionnez deux ou trois charges de travail représentant la gamme des catégories de classification du portefeuille : une native infonuagique, une nécessitant une refonte et une candidate à la conservation sur site; soumettez-les à la méthodologie complète d’évaluation avant d’évaluer l’ensemble du portefeuille.
4. Approche d’évaluation itérative — Structurez l’évaluation en phases, avec des points de contrôle explicites entre la découverte de l’infrastructure, la classification des charges de travail et la sélection du modèle de déploiement.
5. Soutien de la direction — Obtenez une autorisation explicite de la direction pour que l’évaluation puisse recommander de conserver certains éléments sur site et identifier les exigences de correction à appliquer avant la migration, et pas seulement des feuilles de route de migration. Sans cette autorisation, les équipes d’évaluation subissent des pressions organisationnelles pour classer les charges de travail comme prêtes pour le nuage, afin de maintenir l’élan de migration.

Liste de vérification de la préparation à la migration

La préparation est un seuil d’évaluation, et non un exercice d’achèvement. Les éléments ci-dessous sont des déclarations de seuil go/no-go organisées par domaine d’évaluation. Une charge de travail ou un domaine qui ne peut satisfaire à une déclaration de seuil n’est pas prêt — et le séquencement de la migration doit en tenir compte.

Préparation de l’infrastructure

• La découverte automatisée (avec ou sans agent) a été complétée pour 100 % de l’infrastructure concernée, sans qu’aucun actif ne soit exclu en raison de contraintes d’accès.
• Les cartes de dépendance sont complètes pour toutes les charges de travail concernées, avec identification des dépendances circulaires et documentation des plans de remédiation.
• Les références de performance (CPU, mémoire, stockage I/O, débit réseau) sont documentées pour toutes les charges de travail, en conditions normales et de pointe.
• L’examen de l’architecture réseau est terminé, et les profils de latence sont validés pour toutes les charges de travail nécessitant des communications inter-composantes.

Préparation des applications et des charges de travail

• Chaque charge de travail incluse dans le périmètre a été classifiée comme cloud native, cloud-ready, nécessitant une refactorisation ou à retenir sur site, avec des critères de classification documentés.
• Les charges de travail à retenir sur site ont été officiellement exclues du périmètre de migration, avec la justification consignée.
• Les charges de travail nécessitant une refactorisation possèdent des plans de remédiation documentés avec des estimations d’échéancier qui sont reflétées dans la séquence de migration.
• Des modes de migration (rehébergement, replatforming, refactorisation, retrait, maintien) ont été attribués à chaque charge de travail et validés par rapport aux résultats de la cartographie des dépendances.

Préparation à la sécurité et à la conformité

• Les limites du modèle de responsabilité partagée ont été définies pour chaque modèle de déploiement cible, avec les exigences de contrôle gérées par le client documentées.
• L’analyse des écarts de conformité est terminée pour tous les cadres réglementaires applicables (RGPD, HIPAA, SOC 2, ISO 27001), avec les écarts attribués aux responsables de la remédiation.
• Les exigences de résidence des données ont été validées par rapport aux régions infonuagiques disponibles pour toutes les charges de travail réglementées, sans conflit de résidence non résolu restant.
• La remédiation des écarts de contrôle concernant l’identité, le chiffrement et la segmentation réseau est terminée ou bénéficie d’un calendrier documenté précédant l’étape de migration.

Préparation organisationnelle et des compétences

• L’analyse des écarts de compétences est terminée par catégorie de rôle nommé (architectes cloud, ingénieurs DevOps, praticiens FinOps, spécialistes en sécurité), avec des écarts quantifiés.
• La capacité du pipeline CI/CD et de l’infrastructure sous forme de code est évaluée, avec identification et résolution des écarts pouvant affecter l’exécution de la migration.
• Le plan de gestion du changement est documenté, l’appui de la direction est confirmé et la structure de l’équipe interfonctionnelle est établie.

Préparation économique et TCO

• Le modèle TCO est complet, couvrant les coûts d’infrastructure actuels, la main-d’œuvre et les outils de migration, les frais de transfert de données, les changements de licences et les coûts opérationnels en nuage prévus.
• Le modèle de coûts a été examiné par les parties prenantes des finances et reflète la structure réelle des coûts organisationnels, et non seulement les estimations fournies par le fournisseur.
• L’autorisation budgétaire couvre l’ensemble du modèle TCO, y compris les imprévus pour les exigences de remédiation avant migration identifiées lors de l’évaluation.

Alignement du modèle de déploiement

• Des filtres de conformité ont été appliqués pour éliminer les modèles de déploiement qui ne peuvent pas satisfaire aux exigences réglementaires avant l’évaluation de la compatibilité technique.
• La sélection du modèle de déploiement est documentée pour chaque charge de travail ou catégorie de charges de travail, avec l’indication du principal déclencheur de sélection.
• Les configurations hybrides ou multinuages ont des exigences documentées en matière de gouvernance et de gestion opérationnelle que l’organisation a confirmé pouvoir respecter.

Comment HCLTech aide les organisations à évaluer leur préparation au cloud

Une évaluation diagnostique doit être capable de produire des recommandations de conservation sur site et des exigences de remédiation avant migration — et pas seulement des feuilles de route de migration. Une évaluation qui ne donne qu'un feu vert n'est pas un diagnostic; c'est un exercice de qualification de vente.

Nous structurons nos évaluations de préparation au cloud afin de produire des constats qui reflètent réellement la préparation organisationnelle, y compris les constats qui retardent ou réorientent les plans de migration. Notre modèle d'engagement s'étend sur quatre à huit semaines, selon la portée du portefeuille, avec des points de revue structurés entre la découverte de l'infrastructure, la classification des charges de travail, et la sélection du modèle de déploiement. L'évaluation s'aligne directement sur le cadre composé de sept éléments décrit précédemment, de sorte que les constats sont traçables à des domaines d'évaluation spécifiques plutôt qu'agrégés en un seul score de préparation.

Notre service d’évaluation de la préparation au cloud comprend :

• Cadre d’évaluation : Une méthodologie structurée d’évaluation en sept domaines, appliquée de façon cohérente à l’ensemble du portefeuille de charges de travail concernées, avec des critères de classification documentés et des seuils d’acceptation ou de refus par domaine.
• Outils de découverte automatisée : Analyses avec ou sans agent déployées sur l’infrastructure concernée pour produire des cartes de dépendances, des points de référence de performance et des inventaires de configuration.
• Classification des charges de travail et attribution des modèles de migration : Classification par charge de travail (cloud natif, prêt pour le cloud, refonte requise, à retenir sur site) avec attribution du modèle de migration et exigences de correction documentées pour les charges nécessitant une refonte.
• Analyse des écarts de conformité : Analyse des écarts spécifique au cadre par rapport aux exigences réglementaires applicables, avec attribution des responsabilités et des échéanciers pour le traitement des écarts de contrôle.
• Modèle TCO : Modèle de coûts complet couvrant les coûts de l’état actuel, de la migration et des opérations prévues dans le cloud, révisé avec les parties prenantes financières.
• Livrables de l’évaluation : Indices de préparation par domaine et charge de travail, carnet de correction requis et priorisé, liste de maintien sur site avec justification et recommandations de séquence de migration découlant des résultats de l’évaluation.

Questions fréquemment posées sur les évaluations de l’état de préparation au cloud

1. Quelle est la différence entre une évaluation de la préparation au cloud et une évaluation de la maturité cloud ?

   Une évaluation de la préparation au cloud détermine si des charges de travail spécifiques et l’organisation sont prêtes à migrer vers le cloud. Une évaluation de la maturité cloud mesure la capacité globale de l’organisation en matière de adoption du cloud et son niveau de sophistication opérationnelle. La préparation concerne la migration précise et à court terme ; la maturité représente un niveau de capacité en continu.

2. Combien de temps dure une évaluation de la préparation au cloud et qu’en résulte-t-il ?

   La plupart des évaluations de la préparation au cloud durent de quatre à huit semaines, selon la taille du portefeuille et la complexité de l’infrastructure. Les livrables incluent des évaluations de préparation par charge de travail, un carnet à remédier, une liste de conservation sur site avec justification documentée et des recommandations de séquencement de migration.

3. Quels sont les risques de sauter une évaluation de la préparation au cloud ?

   Les organisations qui sautent une évaluation formelle n’en évitent pas les coûts — elles les paient au travers de migrations ratées, d’incidents de conformité et de dépassements budgétaires au moment de l’exécution. Les écarts de dépendance, oublis de conformité et lacunes de compétences que l’évaluation aurait dévoilés deviennent plutôt des incidents en production.

4. Toutes les charges de travail peuvent-elles être migrées dans le cloud ?

   Non. Les charges de travail nécessitant une latence inférieure à 100 ms entre des composantes interdépendantes, les applications sensibles à la conformité dans des juridictions où aucune région cloud ne satisfait les exigences de résidence des données, et les systèmes légacys avec des dépendances matérielles non réplicables dans le cloud sont des candidats à conserver sur site. L’évaluation permet de les identifier explicitement.