Aller au contenu

AWS Mis à jour le 2026-10-22

Ce qu'un fournisseur de services gérés AWS fait vraiment (et ce qu'il ne devrait pas toucher)

Servez-vous-en pour évaluer un fournisseur de services gérés AWS avant de signer. On y explique quelles tâches quotidiennes il devrait assumer pour vous, comme la surveillance, les correctifs et les sauvegardes, et quelles décisions doivent rester à votre équipe.

Si vous comparez des fournisseurs de services gérés AWS, ou si vous vous demandez s’il vous en faut un, il vaut la peine de savoir ce que le mandat couvre vraiment. Ce type de fournisseur assure pour vous l’exploitation quotidienne de votre compte AWS. Concrètement, il surveille l’environnement en continu, répond aux incidents, applique les correctifs aux systèmes d’exploitation, vérifie que les sauvegardes se restaurent, garde en ordre l’IAM (Identity and Access Management, le système qui décide qui peut faire quoi dans le compte) et révise la facture chaque mois. Votre code applicatif, votre feuille de route produit et l’accès racine du compte devraient rester chez vous. Si une proposition brouille ces lignes, voyez-y une raison de continuer à chercher.

Ce que vous êtes en train de décider

L’expression « services gérés » couvre tout, du revendeur qui majore votre facture AWS et répond aux courriels durant les heures ouvrables jusqu’à l’équipe qui porte le téléavertisseur pour votre environnement de production. Avant de comparer des fournisseurs, décidez quelle couche vous achetez réellement.

Il existe trois couches distinctes, et les fournisseurs vendent régulièrement l’une en laissant entendre l’autre :

  • Facturation et administration de compte — facturation consolidée, achat d’instances réservées, revente de plan de soutien. Peu coûteux, peu de valeur, souvent confondu avec de la gestion.
  • Opérations d’infrastructure — la vraie affaire : surveillance avec un chemin de réponse humain, prise en charge des incidents, correctifs des systèmes et dépendances, vérification des sauvegardes, revues IAM, revues de coûts. C’est ce que « géré » devrait vouloir dire.
  • Opérations applicatives — déployer votre code, gérer votre pipeline CI/CD, parfois écrire de l’infrastructure en code pour de nouvelles fonctionnalités. Légitime, mais un mandat distinct avec des exigences d’accès distinctes.

Les questions de frontière comptent plus que la liste de fonctionnalités. Qui détient la racine du compte? Qui peut créer des utilisateurs IAM? Qui est réveillé à 3 h du matin, et qu’a-t-il le droit de faire sans vous demander? Un bon fournisseur a des réponses nettes; un imposteur parle d’outillage.

Quoi vérifier en premier

Avant d’évaluer qui que ce soit, établissez l’état actuel de votre compte, parce que l’écart entre l’état actuel et l’état géré est exactement ce que vous payez pour combler :

  1. Des alarmes existent-elles, et un humain les voit-il? Un compte sans alarmes CloudWatch, ou avec des alarmes qui alimentent une boîte de courriels jamais lue, n’a aucune opération aujourd’hui — peu importe l’organigramme.
  2. Qui a les droits d’administrateur? Listez les utilisateurs et rôles IAM avec AdministratorAccess. Si la réponse inclut d’anciens employés ou des identifiants partagés, le nettoyage IAM fait partie de tout premier mandat honnête.
  3. Quand quelqu’un a-t-il restauré une sauvegarde pour la dernière fois? L’existence d’instantanés n’est pas la même chose que des restaurations qui fonctionnent.
  4. CloudTrail est-il actif dans toutes les régions? Sinon, personne ne pourra auditer ce que le fournisseur fait plus tard.
  5. Qui possède le courriel racine et le dispositif MFA? Ce doit être vous, avant et après la signature.

Comment vérifier

Exécutez ces vérifications en lecture seule sur votre propre compte avant qu’un fournisseur ne le fasse :

# Qui suis-je, et quel compte est-ce?
aws sts get-caller-identity

# Inventaire des alarmes — quelque chose est-il vraiment surveillé?
aws cloudwatch describe-alarms \
  --query 'MetricAlarms[].[AlarmName,StateValue,AlarmActions[0]]' \
  --output table

# CloudTrail : existe-t-il un journal multi-région, et journalise-t-il?
aws cloudtrail describe-trails --query 'trailList[].[Name,IsMultiRegionTrail]'
aws cloudtrail get-trail-status --name <trail-name>

# Qui détient les droits d'administrateur?
aws iam list-entities-for-policy \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Dans la console, vérifiez CloudWatch > Alarms pour tout ce qui est en INSUFFICIENT_DATA depuis sa création (signe que personne ne les a jamais ajustées) et IAM > Users pour des clés d’accès de plus d’un an. La documentation IAM à https://docs.aws.amazon.com/iam/ décrit à quoi ressemble une hygiène d’identifiants saine si vous voulez un point de référence.

L’approche

  1. Mettez la portée par écrit sous forme de tableau de responsabilités. Pour chacun de : surveillance, réponse aux incidents, correctifs, sauvegardes, coûts, sécurité, déploiements et DNS — qui agit, qui est informé, qui approuve. Si un fournisseur résiste à le mettre sur papier, l’ambiguïté est le produit.
  2. Exigez un accès délégué, jamais d’identifiants partagés. Le fournisseur travaille via un rôle IAM intercompte dédié ou une attribution IAM Identity Center que vous pouvez révoquer en une seule action. La racine reste chez vous. La même logique de moindre privilège s’applique à l’intérieur du compte — voir les profils d’instance IAM bien faits pour comprendre comment ce raisonnement s’étend aux charges de travail.
  3. Faites de la surveillance le premier livrable. Un fournisseur qui ne peut pas vous montrer l’ensemble d’alarmes qu’il déploiera dès la première semaine vend un tableau de bord, pas des opérations. Une base concrète ressemble à l’ensemble d’alarmes CloudWatch dont un SaaS en production a besoin.
  4. Convenez du chemin d’incident avant le premier incident. Définitions de sévérité, cibles de réponse par sévérité, et qui communique avec vos clients. Les cibles de réponse diffèrent entre les niveaux heures ouvrables et 24/7 — obtenez par écrit le niveau que vous achetez.
  5. Établissez la cadence des coûts. Une revue mensuelle avec des actions concrètes (redimensionnement, couverture d’engagements, ressources orphelines) est la norme. La structure d’honoraires du fournisseur ne devrait pas croître quand votre facture AWS gonfle par gaspillage — la tarification en pourcentage de la dépense pointe l’incitatif dans le mauvais sens.

Quand c’est le mauvais choix

Si toute votre empreinte se résume à une instance EC2 et un compartiment S3, un contrat de services gérés est une charge inutile — un mandat ponctuel de durcissement plus le plan de soutien Developer d’AWS (voir https://aws.amazon.com/premiumsupport/ pour la structure des niveaux) vous couvre. De même, si vous avez déjà deux ingénieurs ou plus qui possèdent réellement les opérations — téléavertisseur, correctifs, tests de restauration — ajouter un fournisseur crée un problème de double cerveau, sauf si le partage de portée est explicite. Et aucun fournisseur ne répare une application qui plante à cause de ses propres bogues; c’est du travail d’ingénierie, pas des opérations.

Erreurs courantes

  • Acheter la couche revendeur et supposer que les opérations sont incluses. Une facturation consolidée plus un courriel de soutien, ce n’est pas de la gestion.
  • Céder la racine « pour simplifier les choses ». Le partage de la racine n’est jamais requis pour les opérations et vous enlève votre contrôle de dernier recours.
  • Signer sans tableau de responsabilités. Six mois plus tard, une instance sans correctifs est compromise et chaque partie pointe l’autre du doigt.
  • Juger sur des captures d’écran de tableaux de bord. N’importe qui peut installer Grafana. Demandez qui a été réveillé mardi dernier à 2 h et ce qui s’est passé ensuite.

Garder le contrôle

  • Gardez les identifiants racine, le courriel racine et le compte payeur entre vos mains, en permanence.
  • Passez en revue l’activité CloudTrail du fournisseur chaque trimestre — les actions de son rôle sont toutes journalisées si vous avez laissé le journal actif.
  • Exigez un rapport mensuel écrit : incidents, changements, état des correctifs, vérification des sauvegardes, actions sur les coûts.
  • Réexécutez les commandes de vérification ci-dessus deux fois par année; le compte devrait s’améliorer chaque fois.
  • Conservez votre propre copie de l’infrastructure en code et des procédures pour que la relation reste réversible.

Un fournisseur de services gérés qui fait bien son travail rend votre compte AWS ennuyant : à jour, surveillé, sauvegardé, et moins cher chaque trimestre — pendant que vous gardez les clés. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.