L’hébergement cloud infogéré n’a pas de prix unique, parce que le travail change d’un environnement à l’autre. Le coût dépend d’une courte liste de facteurs : le nombre d’environnements que vous exploitez, leur architecture, la charge qu’ils portent, la fenêtre de couverture et l’engagement de réponse qu’il vous faut, et le travail dans le périmètre. Un devis sérieux nomme ces facteurs et rattache le chiffre à un périmètre écrit. Ce guide aide un fondateur, un responsable des finances ou un directeur TI à établir son budget avant le premier appel avec un fournisseur.
Que payez-vous quand vous achetez de l’hébergement cloud infogéré ?
L’hébergement cloud infogéré réunit une infrastructure et le travail d’exploitation qui la garde en marche. Un devis couvre donc deux coûts différents, et l’acheteur devrait demander à les voir séparément.
Le premier coût est l’infrastructure : calcul, stockage, réseau, sauvegardes et licences. C’est la plateforme cloud ou d’hébergement qui le facture, qu’il s’agisse d’AWS (Amazon Web Services), d’un autre cloud public ou de la plateforme du fournisseur infogéré.
Le deuxième coût est le travail d’exploitation : surveillance, correctifs, tests de restauration, réponse aux incidents, escalade aux fournisseurs et améliorations planifiées. C’est un coût de personnes et de processus. Il ne diminue pas parce qu’un serveur est petit.
Du côté de l’exploitation, les fournisseurs vendent trois couches différentes sous la même étiquette « infogéré » :
- La facturation et l’administration de compte. Le fournisseur revend ou regroupe le compte cloud. Cette couche coûte peu et change peu la façon dont l’environnement fonctionne, et les acheteurs la prennent souvent pour de la gestion.
- L’exploitation de l’infrastructure. Durcissement, correctifs, sauvegardes, surveillance, garde et réponse aux incidents. C’est la couche que la plupart des acheteurs croient acheter.
- L’exploitation applicative. Déployer votre code et faire tourner son pipeline de mise en production. C’est habituellement un mandat distinct, avec ses propres exigences d’accès.
Deux devis très éloignés l’un de l’autre sont souvent des devis pour des couches différentes. Demandez à chaque fournisseur quelle couche son chiffre couvre. La base de connaissances décrit ce que fait un fournisseur d’exploitation infonuagique gérée (MSP) sur AWS, et ce qu’il ne devrait pas toucher.
Quels modèles de tarification allez-vous rencontrer, et quel incitatif chacun crée-t-il ?
Cinq modèles de tarification reviennent dans l’hébergement infogéré, le cloud infogéré et la gestion d’infrastructure. Chacun récompense le fournisseur pour quelque chose de différent. Le modèle vous en dit donc autant que le chiffre.
| Modèle de tarification | Fonctionnement | Incitatif créé | Convient quand |
|---|---|---|---|
| Grille publique de forfaits | Des forfaits fixes avec des limites publiées de sites, de visites, de stockage ou de ressources | Le produit est standardisé. L’usage au-delà d’une limite devient un dépassement ou un changement de forfait forcé. | Votre charge est standard et vous voulez acheter sans appel de vente |
| Par utilisateur ou par poste | Des frais mensuels pour chaque employé pris en charge | Le coût suit les effectifs | Vous achetez du soutien TI de bureau. C’est la mauvaise catégorie pour l’hébergement de production. |
| Pourcentage des dépenses cloud | Une part de votre facture cloud mensuelle | Le fournisseur gagne plus quand la facture grossit, y compris par le gaspillage | L’empreinte change vite et vous acceptez un incitatif plus faible à contrôler les coûts |
| À l’heure ou au billet | Vous payez le temps passé ou chaque demande | Le fournisseur gagne plus quand plus de choses tournent mal. Le coût mensuel est difficile à prévoir. | Le travail est occasionnel et aucune couverture continue n’est nécessaire |
| Devis fixe pour un périmètre écrit | Un mandat mensuel fixe ou un prix de projet fixe, cadré par environnement, par site ou par serveur | Le fournisseur gagne la même chose, que votre facture baisse ou non. Le travail hors périmètre exige un nouveau devis. | Vous exploitez des environnements de production qui demandent une couverture continue et un coût prévisible |
Aucun modèle n’est mauvais dans tous les cas. Évitez un modèle dont l’incitatif joue contre le résultat que vous visez.
Quels facteurs déterminent le devis d’un hébergement cloud infogéré ?
Les fournisseurs qui chiffrent un périmètre examinent à peu près les cinq mêmes groupes de facteurs. Si vous pouvez décrire chaque groupe pour votre propre environnement, vous pouvez prévoir dans quel sens un devis bougera.
| Groupe de facteurs | Ce que le fournisseur examine | Pourquoi le devis bouge |
|---|---|---|
| L’environnement | Nombre et classe des environnements (production, staging, développement), complexité de l’architecture, redondance comme la haute disponibilité ou une deuxième région, pile de runtime et de bases de données | Chaque environnement reçoit des correctifs, une surveillance et des sauvegardes. La redondance multiplie les systèmes à garder synchronisés. |
| La charge | Profil de trafic, charge concurrente, volume de données, comportement de l’autoscaling | La charge fixe la taille de l’infrastructure et l’ampleur de la planification de la capacité |
| Couverture et réponse | Fenêtre de couverture (heures ouvrables, étendue ou 24/7), engagement de réponse pour chaque niveau de gravité, actifs supervisés et vérifications sur mesure | La couverture est un coût d’effectifs. C’est le facteur que les acheteurs sous-estiment le plus. |
| Le parc | Nombre de sites, de comptes ou de serveurs. Pour les agences, le nombre de sites clients et si le travail est en marque blanche ou cogéré. | Plus d’unités, c’est plus de correctifs, plus de sauvegardes et plus de billets |
| Le travail dans le périmètre | Heures projet mensuelles, feuille de route d’améliorations, post-mortems, projet de migration ou de consolidation, exigences de conformité ou de résidence des données, cadence des mises en production | C’est du temps de projet et de conseil, en plus du maintien de l’environnement en marche |
Certains produits ont leur propre structure de prix. Une plateforme applicative infogérée, souvent appelée PaaS (plateforme en tant que service), facture habituellement les ressources consommées, et certains fournisseurs ajoutent des frais de plateforme par environnement. Les ententes d’agence peuvent jumeler un mandat de base à une facturation par site. Les agences peuvent comparer les modèles dans le guide sur l’hébergement pour les agences qui gèrent plusieurs sites WordPress.
Pourquoi une couverture 24/7 coûte-t-elle tellement plus cher qu’une couverture en heures ouvrables ?
Couvrir un seul poste jour et nuit prend plusieurs personnes une fois qu’on compte les nuits, les fins de semaine, les vacances et le roulement. Cette arithmétique des effectifs est le coût derrière chaque couverture 24/7, que vous bâtissiez la rotation vous-même ou que vous l’achetiez. La page de cadrage de Stack Harbor évalue une rotation interne 24/7 à six équivalents temps plein et plus, une fois les vacances, la maladie et l’épuisement couverts. La base de connaissances explique ce qu’exige une vraie rotation de nuit en surveillance.
Achetez la couverture dont vos clients ont besoin. Si vos clients dorment quand votre équipe dort, une couverture en heures ouvrables ou étendue est peut-être le choix honnête.
La couverture peut aussi monter par paliers. Dans un scénario type, une entreprise SaaS B2B a reconstruit sa garde avec un sprint de rédaction de runbooks le premier mois. Elle est ensuite passée par étapes d’une couverture en heures ouvrables étendues à une couverture 24/7 complète au troisième mois.
Un accord de niveau de service (SLA) qui couvre les incidents comporte habituellement un engagement sur le délai de réponse, c’est-à-dire le temps qu’une personne met à confirmer l’incident et à commencer le travail. Le délai de résolution est habituellement une cible et non un engagement. Demandez à chaque fournisseur lequel des deux son chiffre décrit. Si vous hésitez entre une embauche et un contrat, la comparaison entre embaucher un ingénieur DevOps ou impartir les opérations traite de la couverture et de la continuité.
Pourquoi beaucoup de fournisseurs infogérés ne publient-ils pas leurs prix ?
Un fournisseur infogéré peut publier une grille de prix quand il vend un produit standardisé, et les hébergeurs de plateforme à forfaits fixes le font. Un fournisseur qui exploite des environnements de production sur mesure ne le peut habituellement pas. Deux environnements qui comptent le même nombre de serveurs peuvent différer beaucoup en redondance, en couverture, en travail de conformité et en heures projet. Une seule grille chiffrerait donc mal au moins l’un des deux.
Sans grille, vous ne pouvez pas faire une présélection sur le prix seul. Demandez donc trois choses à chaque fournisseur avant tout appel.
- L’unité de prix : environnement, site, serveur, utilisateur ou part des dépenses.
- La liste des facteurs qui changent le chiffre.
- Les étapes qui produisent le devis, et ce que vous gardez si vous ne signez pas.
Traitez comme une estimation tout chiffre ferme donné avant que le fournisseur ait vu votre environnement. L’écart peut arriver plus tard sous forme d’avenants.
L’hébergement cloud infogéré fait-il baisser la facture d’infrastructure ?
L’hébergement cloud infogéré fait parfois baisser la facture d’infrastructure, et parfois la facture monte. Les deux résultats peuvent être le bon. Les scénarios types publiés par Stack Harbor vont dans les deux sens. Chaque chiffre ci-dessous décrit un seul mandat et n’est pas un résultat typique.
- Dans un scénario type, une architecture à deux régions pour la résidence des données d’un SaaS canadien a fait monter le coût d’infrastructure de 38 %, à cause de la deuxième région et des outils dédoublés qui l’accompagnaient. Le scénario type rapporte un revenu entreprise attribuable d’environ sept fois cet écart dans la même fenêtre.
- Dans un scénario type, un monolithe Laravel est passé à une plateforme applicative infogérée et le coût d’infrastructure a monté de 11 %. En contrepartie, environ soixante heures d’ingénierie de fondateur ont été récupérées chaque mois.
- Dans un scénario type, un passage d’AWS au cloud infogéré avec refonte de l’architecture a réduit le taux mensuel de 54 %, sauvegardes, supervision et frais d’opération inclus. La même proposition estimait qu’une remédiation sans quitter AWS aurait réduit la facture de 28 %.
Mesurez le résultat avec vos propres chiffres. Notez la facture d’infrastructure actuelle, les heures internes consacrées à l’exploitation chaque mois et le coût des incidents récents. Comparez ensuite les trois mêmes chiffres après le changement. Pour une entreprise SaaS, la base de connaissances montre comment calculer le coût par client sur un cloud infogéré. Les équipes des finances peuvent commencer par une analyse de facturation AWS que les finances peuvent lire. Le calculateur de coûts cloud de Stack Harbor donne une estimation approximative, fondée sur des repères de l’industrie, de la part d’une facture cloud qui est probablement gaspillée.
Comment comparer deux devis d’hébergement infogéré ?
Pour comparer deux devis d’hébergement infogéré, décomposez chacun en trois parts.
- Les frais de base. Le chiffre récurrent de la première page.
- Les conditions de dépassement. Ce qui arrive quand le trafic, le stockage, les sites ou les heures dépassent le forfait.
- Vos propres heures. Le temps que votre équipe passera encore sur tout ce que le forfait exclut.
Les frais de base vous en disent le moins des trois. Des frais bas, un dépassement sans plafond et une longue liste d’exclusions peuvent coûter plus cher que des frais plus élevés avec un périmètre complet. Apportez ensuite cette liste de vérification à chaque appel avec un fournisseur.
- Quelle couche le devis couvre-t-il : l’administration de la facturation, l’exploitation de l’infrastructure ou l’exploitation applicative ?
- Quelle est l’unité de prix, et qu’est-ce qui fait changer le chiffre après la signature ?
- Quelle est la fenêtre de couverture, et le délai annoncé est-il un délai de réponse confirmée ou un délai de résolution ?
- Quels systèmes sont supervisés, et les tests de restauration des sauvegardes font-ils partie du périmètre ?
- Comment le travail hors périmètre est-il chiffré, et reçoit-il un devis avant de commencer ?
- Une migration est-elle incluse, distincte, ou exigée comme condition du service ?
- Quelle documentation gardez-vous si vous partez ?
- Un crédit de service s’applique-t-il à la disponibilité, au délai de réponse, ou à aucun des deux ?
D’autres critères de sélection se trouvent dans le guide qui explique quoi rechercher chez un fournisseur d’hébergement infogéré.
Quand l’hébergement cloud infogéré vaut-il son coût, et quand est-ce le mauvais achat ?
Payer pour une exploitation infogérée vaut généralement son coût dans les situations suivantes.
- Une panne en production vous coûte des revenus ou des renouvellements, et personne dans l’équipe n’est responsable de l’exploitation.
- Un seul ingénieur assure la garde, sans relève et sans runbooks écrits.
- Les correctifs, les tests de restauration et la surveillance passent sans cesse après le travail sur le produit.
- Des clients ou des auditeurs demandent des preuves de contrôles que votre équipe ne peut pas produire aujourd’hui.
Un contrat infogéré est le mauvais achat dans les situations suivantes.
- Vous avez l’équivalent d’un poste d’exploitation à temps plein de travail régulier. Embauchez la personne, surtout si l’infrastructure est votre produit.
- Toute votre empreinte tient dans une instance et un compartiment de stockage. Un contrat infogéré est du surcoût à cette taille.
- Deux ingénieurs ou plus sont déjà responsables de l’exploitation. Ajouter un fournisseur divise la responsabilité, à moins que le partage du périmètre soit explicite.
- Votre équipe compte deux développeurs. La mise en place ponctuelle d’un pipeline, documentation comprise, est peut-être la bonne taille.
- Vous voulez acheter à partir d’une grille de prix publique, sans appel de cadrage. Un hébergeur de plateforme à forfaits publiés est la bonne catégorie, et un hébergeur WordPress infogéré standard convient à un seul site standard.
- Les alertes viennent de défauts de l’application elle-même. C’est du travail de génie logiciel, et ni une embauche en exploitation ni un fournisseur infogéré ne le règle.
Les équipes qui ont des compétences cloud à l’interne peuvent bien s’en tirer sur AWS sans couche infogérée. Le cadre de décision cloud infogéré ou AWS pour une PME traite de ce choix.
Où se situe Stack Harbor
Stack Harbor est un fournisseur d’exploitation infonuagique gérée (MSP) pour les environnements de production, de propriété canadienne, dont le siège est à Montréal. L’entreprise sert des entreprises SaaS, des agences et des éditeurs, typiquement des organisations d’environ 5 à 200 personnes qui exploitent des systèmes de production sans avoir leur propre équipe d’exploitation 24/7.
Stack Harbor ne publie pas de prix et n’a pas de grille tarifaire publiée. Les mandats sont cadrés par environnement, par site ou par serveur, jamais par utilisateur. Stack Harbor ne chiffre pas un pourcentage de la facture infonuagique et ne facture pas au billet. Le chiffre est un mandat mensuel fixe ou un prix de projet fixe, produit après une évaluation écrite que l’acheteur garde, qu’il signe ou non. Le prix est fixe pour le périmètre de l’entente, et tout ce qui sort de ce périmètre est chiffré à part avant de commencer. Le prix de Cloud PaaS, sa plateforme applicative, combine des frais de plateforme par environnement et les ressources utilisées. La méthode complète se trouve sur la page qui explique comment Stack Harbor cadre et chiffre un mandat.
Héberger chez Stack Harbor n’est pas requis. L’offre d’exploitation continue, Opérations Cloud, couvre des environnements sur AWS, Azure, Google Cloud, OVH, DigitalOcean et des serveurs dédiés. Elle couvre aussi des environnements sur l’infrastructure de Stack Harbor au Canada, dans deux centres de données à Montréal. La couverture est cadrée en heures ouvrables, étendue ou 24/7. Pour les forfaits qui incluent la couverture des incidents, le SLA publié engage Stack Harbor à une réponse confirmée en moins de 15 minutes pour la gravité 1 (Sev-1) et en moins de 60 minutes pour la gravité 2 (Sev-2). La résolution est une cible, pas un engagement.
Ce modèle convient mal à un acheteur qui a besoin d’une grille de prix publique pour acheter en libre-service. Une équipe qui veut voir les facteurs par écrit avant le chiffre peut demander une évaluation écrite de son environnement, puis vérifier le devis à l’aide du tableau des facteurs ci-dessus.
