Commencez par votre charge de travail, pas par un plan d’hébergement
Dressez la liste des parcours qui créent de la valeur ou du risque : première visite, recherche, connexion, fiche produit, envoi de formulaire, paiement, mise à jour de l’éditeur ou appel d’API. Pour chacun, enregistrez les requêtes de pointe ou les utilisateurs concurrents, la taille des payloads, la personnalisation, les dépendances et les régions des visiteurs. Incluez le travail planifié et administratif car il consomme les mêmes ressources.
Transformez la liste en mesures d’acceptation. Largest Contentful Paint, ou LCP, mesure le chargement du contenu principal ; Interaction to Next Paint, ou INP, la réactivité ; et Cumulative Layout Shift, ou CLS, les déplacements inattendus. Google décrit comme bonnes les cibles : LCP en 2,5 secondes ou moins, INP sous 200 millisecondes et CLS inférieur à 0,1. Ajoutez des cibles de complétion de route, de temps de réponse serveur et de taux d’erreur.
Ne laissez pas une page rapide mise en cache servir de substitut à une transaction authentifiée ou dépendante d’une base de données.
Définissez la période de pointe, la croissance attendue, les pics de campagne et le chevauchement des travaux par lot.
Indiquez si l’hébergeur, votre équipe ou un tiers contrôle chaque goulot d’étranglement probable.
Comparez capacité, limites et comportement d’évolutivité
Demandez les limites qui se cachent derrière l’offre : compute et mémoire, performances de stockage, connexions à la base de données, limites de workers, facturation réseau, contrôles de requêtes et contraintes liées aux voisins partagés. « Bande passante illimitée » n’indique pas si l’application peut effectuer suffisamment de travail non mis en cache lors d’un pic. Demandez quelles métriques sont visibles et pendant combien de temps elles restent disponibles.
L’évolutivité importe uniquement lorsque son déclencheur, son délai, son plafond et son prix sont connus. Confirmez si elle est automatique, si les sessions et les jobs sont préservés et ce qui arrive au plafond. Préférez un test au pic attendu et au-delà plutôt qu’une revendication théorique de capacité. La marge d’exploitation est une décision métier, pas un pourcentage universel.
Comparez les temps de réponse p95 ou p99, pas seulement la moyenne.
Collectez les temps de base de données, de queue et d’API amont pendant le test.
Estimez les coûts de montée en charge, de livraison, de sauvegarde et de seconde région avant de vous engager.
Positionnez l’origine volontairement et validez la diffusion
Choisissez une région d’origine en fonction de l’emplacement de l’audience, des dépendances applicatives, des besoins de localisation des données et de l’accès opérationnel. Testez depuis des géographies et conditions réseau représentatives. Un réseau de diffusion de contenu, ou CDN, est un cache distribué qui peut servir des ressources admissibles plus près des visiteurs et réduire le travail à l’origine ; il ne remplace pas une origine, une base de données ou une application saines.
Inspectez les en-têtes et le comportement, pas seulement un réglage de tableau de bord. Les assets statiques versionnés peuvent généralement avoir une durée de vie plus longue car une mise à jour a une nouvelle URL. Les réponses dynamiques et personnalisées nécessitent des règles explicites. HTTP distingue les caches partagés des caches privés ; les informations de compte ne doivent pas devenir réutilisables par un autre client. Répétez une purge de cache et un rollback.
Capturer une première visite et une visite de retour, car les états de cache diffèrent.
Valider Cache-Control et les clés de cache pour pages, assets, cookies, paramètres et locale.
Documenter comment le personnel autorisé désactive une règle néfaste sans exposer de contenu sensible.
Traitez la preuve de rétablissement comme une exigence de performance
Demandez ce qui est sauvegardé, où les copies vivent, la rétention, l’autorité de restauration et si les sauvegardes couvrent bases de données, téléchargements, code, configuration et infrastructure. Définissez l’objectif de point de récupération (RPO) comme la perte de données acceptable en temps, et l’objectif de temps de récupération (RTO) comme le délai de restauration acceptable. Fixez les deux en fonction des conséquences métier, pas d’un défaut de forfait.
Une sauvegarde réussie n’est pas une preuve de rétablissement. Le CISA recommande des tests de récupération planifiés, et AWS indique que la reprise après sinistre doit être évaluée et testée. Restaurez une copie récente en isolation, vérifiez les enregistrements et médias importants, suivez la séquence documentée et enregistrez le temps écoulé. Une région secondaire peut réduire certains risques mais ajoute coûts et complexité.
Récupérer un fichier ou un enregistrement sans écraser les données actuelles.
Limiter l’accès aux restaurations et garder les identifiants et runbooks de récupération disponibles pour les intervenants autorisés.
Un snapshot de base de données peut ne pas recréer les paramètres, les versions applicatives ou les règles de diffusion.
Évaluez le support et la responsabilité partagée avant d’en avoir besoin
Comparez le périmètre du support, les horaires, les canaux, l’escalade et la différence entre incidents de plateforme et dépannage applicatif. Obtenez la responsabilité écrite pour les patchs, bases de données managées, TLS, règles de pare-feu, sauvegardes et restaurations. Une promesse de support est utile quand elle nomme le propriétaire et l’action suivante dans un scénario réaliste.
Passez en revue les rôles d’accès, l’authentification multi-facteurs, les journaux d’audit, la gestion des secrets et l’isolation des comptes. Pour les cartes de paiement ou les données sensibles réglementées, les fonctionnalités d’hébergement seules n’établissent pas la conformité. Utilisez cette comparaison comme entrée technique et obtenez un examen qualifié en sécurité, juridique ou conformité de l’architecture de paiement et des obligations applicables.
Demandez comment le fournisseur gère une restauration échouée, une base de données saturée ou une règle de cache nuisible.
Vérifiez qui peut modifier la production, lire les sauvegardes, voir les logs et créer des identifiants.
Les crédits de service et la couverture managée peuvent comporter des conditions matérielles.
Réalisez des tests comparatifs réalistes et sûrs et conservez la grille d’évaluation
Utilisez la même release, la même intention de configuration et le même script de test pour chaque candidat. Lancez un test de base, le pic attendu, un court spike, une période soutenue et un exercice sûr de récupération ou de déploiement. AWS recommande des environnements proches de la production, des scénarios définis, une surveillance à l’échelle de l’architecture, des données désensibilisées ou synthétiques, et des retests réguliers. Obtenez l’approbation du fournisseur et respectez sa politique de test.
Combinez des tests en laboratoire contrôlés avec des données de terrain après le lancement. Les tests en labo sont reproductibles pour le débogage ; les données de terrain reflètent les appareils réels, les réseaux, la géographie, l’état du cache et le comportement. Revisitez la grille d’évaluation après des releases majeures ou des changements de dépendance. SIU peut transformer les constats en durcissements pré-lancement, remédiations assignées à des propriétaires et améliorations prêtes au rollback.
Maintenez cohérence sur les emplacements, la concurrence, l’état du cache et les payloads.
Conservez les minutages des routes, les erreurs, les métriques ressources, les versions, les coûts et les observations.
Sélectionnez l’option répondant aux besoins documentés à un coût d’exploitation soutenable.