Impartition de la gestion AWS vs embaucher son propre ingénieur DevOps : la comparaison honnête

Les équipes sur AWS arrivent souvent au moment de choisir entre embaucher un ingénieur DevOps et confier la gestion de l’environnement à un fournisseur de services gérés. L’ingénieur DevOps est la personne qui bâtit et exploite vos déploiements, vos serveurs et votre configuration infonuagique. Embauchez-en un si ce qui vous manque, c’est de la profondeur : quelqu’un qui apprend votre produit, participe à votre planification et améliore la plateforme au fil des mois. Impartissez si ce qui vous manque, c’est de la couverture. Une équipe gérée surveille l’environnement jour et nuit, a déjà vu votre type d’incident chez d’autres clients et continue de travailler quand une personne est malade ou en congé. Bien des équipes finissent par combiner les deux; commencez donc par nommer le manque qui vous nuit le plus en ce moment.

Ce que vous êtes en train de décider

Enlevez le titre de poste et listez le travail réel qu’un environnement AWS génère. Il tombe dans trois piles :

• Travail de conception — décisions d’architecture, infrastructure en code, pipelines CI/CD, stratégie de coûts, posture de sécurité. Irrégulier, à fort jugement, profite du contexte produit.
• Opérations récurrentes — correctifs, vérification des sauvegardes, ajustement des alarmes, hygiène IAM, revue mensuelle des coûts. Stable, procédural, profite de la répétition sur plusieurs environnements.
• Réponse aux incidents — être joignable, diagnostiquer sous pression, atténuer, écrire le post-mortem. Arrivées aléatoires, punitif à 3 h du matin, profite d’avoir un banc de relève.

Un ingénieur couvre bien la première pile, la deuxième si son calendrier est défendu, et la troisième seulement pendant ses heures d’éveil et son emploi. Cette dernière clause est la limite structurelle : une embauche unique est un facteur d’autobus de un, environ 45 heures ouvrables par semaine sur les 168 où l’environnement existe, avec un savoir qui sort par la porte en même temps que la personne. Rien de tout ça n’est une critique de la personne; c’est de l’arithmétique sur le rôle.

Un fournisseur géré inverse le profil. La couverture est le produit — rotations, escalade, procédures, répétition sur des dizaines d’environnements — mais personne de leur côté n’assiste à votre planification de sprint ni ne ressent votre feuille de route produit dans ses tripes. Les fournisseurs qui prétendent remplacer entièrement votre jugement d’ingénierie survendent; ce qu’ils remplacent, c’est le téléavertisseur et la corvée.

Quoi vérifier en premier

1. Comptez les vraies heures. Journalisez deux semaines d’interruptions : correctifs, surveillance de déploiements, chasse aux alarmes, questions de coûts. Moins de dix heures par semaine de travail des piles deux et trois ne justifie pas un poste complet.
2. Nommez la réponse de 3 h du matin aujourd’hui. Si c’est une personne précise, informellement, vous avez un trou de couverture peu importe qui vous embauchez ensuite.
3. Vérifiez votre réalité d’embauche. Le délai pour pourvoir un poste d’infrastructure vraiment sénior sur le marché canadien se compte en mois, et l’entrevue exige une expertise que vous n’avez peut-être pas à l’interne.
4. Auditez le facteur d’autobus. Si la personne qui a bâti l’environnement partait vendredi, qu’est-ce qui est documenté? La réponse change le coût d’intégration des deux options.

Comment vérifier

Mettez des chiffres sur votre propre situation avant que quiconque vous vende les siens :

# À quelle fréquence ça sonne vraiment? Historique d'alarmes, 90 derniers jours
aws cloudwatch describe-alarm-history \
  --history-item-type StateUpdate \
  --start-date 2026-04-05T00:00:00Z --end-date 2026-07-04T00:00:00Z \
  --max-records 100 \
  --query 'AlarmHistoryItems[].[AlarmName,Timestamp,HistorySummary]'

# Quelle est la vraie taille du parc? Instances, bases de données, fonctions
aws ec2 describe-instances \
  --query 'length(Reservations[].Instances[])'
aws rds describe-db-instances --query 'length(DBInstances)'

# Vélocité de changement — les événements d'écriture CloudTrail cette semaine
# vous disent combien d'opération se passe réellement
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ReadOnly,AttributeValue=false \
  --start-time 2026-06-27T00:00:00Z --max-results 50

Un petit parc avec des alarmes rares et une faible vélocité de changement est un problème d’opérations à temps partiel — cette forme favorise l’impartition ou un arrangement fractionnaire. Un grand parc en changement constant est une plateforme d’ingénierie — cette forme exige de la profondeur interne, possiblement avec une couverture de nuit impartie par-dessus. Les niveaux de soutien d’AWS (https://aws.amazon.com/premiumsupport/) se placent sous l’une ou l’autre réponse pour les problèmes côté AWS, mais ne couvrent ni votre charge de travail ni votre téléavertisseur.

L’approche

1. Notez votre trou : profondeur ou couverture. Relisez les trois piles. Si les déploiements sont lents et l’architecture dérive, votre trou est la profondeur — favorisez l’embauche. Si les nuits, fins de semaine, correctifs et sauvegardes sont à découvert, votre trou est la couverture — favorisez le fournisseur. La plupart des entreprises sous environ trente ingénieurs ont un trou de couverture et le diagnostiquent à tort comme un problème d’embauche.
2. Si vous embauchez : protégez le rôle contre la corvée pure. Un ingénieur sénior qui passe sa semaine à appliquer des correctifs et chasser des alarmes est un problème de rétention que vous avez mis à l’horaire vous-même. Automatisez agressivement la pile récurrente — les mêmes recettes qu’un fournisseur exécuterait, comme la base d’alarmes CloudWatch — et gardez son calendrier majoritairement en conception.
3. Si vous impartissez : gardez l’autorité de conception à l’interne. Quelqu’un sur votre paie possède la direction d’architecture et révise les changements du fournisseur. Déléguer les opérations est sain; déléguer le jugement, c’est comme ça qu’on se réveille verrouillé.
4. Considérez l’hybride délibérément, pas par accident. Un ingénieur plateforme à l’interne plus des opérations 24/7 imparties est la configuration stable la plus courante dans la gamme intermédiaire : la profondeur là où elle se compose, la couverture là où c’est de l’arithmétique.
5. Peu importe le chemin, contractualisez les sorties. Pour l’embauche : documentation et infrastructure en code comme exigences du poste, pas comme faveurs. Pour le fournisseur : votre compte, votre code, transfert défini. La comparaison n’est pas que des coûts; c’est de la réversibilité.

Quand c’est le mauvais choix

L’impartition est mauvaise quand votre produit est l’infrastructure — une plateforme d’hébergement, une entreprise de pipelines de données — où le savoir opérationnel est votre substance concurrentielle. L’embauche est mauvaise quand la charge honnête est de quinze heures par semaine; l’ingénieur que vous voulez ne restera pas pour un travail de maintenance, et celui qui reste n’est pas celui que vous vouliez. Et aucun des deux choix ne répare une application qui réveille à cause de ses propres défauts — ce budget appartient à l’ingénierie dans tous les cas.

Erreurs courantes

• Mener la décision purement au calcul de coûts. Les vraies variables sont les heures de couverture, le facteur d’autobus, le temps vers la compétence et la réversibilité; le coût suit la structure.
• Embaucher une personne et déclarer le 24/7 couvert. Un humain ne peut pas être une rotation; prétendre le contraire épuise de bons ingénieurs.
• Impartir sans garder de responsable interne. Un fournisseur sans supervision dérive exactement comme un compte sans supervision; la relation elle-même est un rôle.
• Traiter le choix comme permanent. La bonne réponse à dix ingénieurs est régulièrement mauvaise à quarante; l’erreur est de ne pas la revisiter.

Garder le contrôle

• Revisitez la décision chaque année avec la même analyse en trois piles; notez ce qui a changé.
• Peu importe le modèle, exigez les mêmes preuves mensuelles : état des correctifs, tests de restauration, journal d’incidents, actions sur les coûts.
• Gardez l’infrastructure en code et les procédures dans vos dépôts sous les deux modèles — le fournisseur contribue aux vôtres, pas l’inverse.
• Suivez les réveils par semaine et le délai d’accusé de réception comme métriques de santé neutres qui exposent l’échec de l’un ou l’autre modèle.

La profondeur et la couverture sont deux besoins réels; l’erreur coûteuse est d’acheter l’un en souffrant du manque de l’autre. 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.