Recherchez huit éléments chez un fournisseur d’hébergement infogéré, et demandez chacun par écrit. Quatre décrivent le service : un périmètre délimité, une description claire de qui fait le travail, des niveaux de gravité chiffrés et un engagement de disponibilité assorti d’un recours défini. Quatre décrivent le risque : des sauvegardes prouvées par des tests de restauration, des formulations de conformité honnêtes, des clauses de résidence des données dans l’entente et des livrables de sortie.
Les sites web des fournisseurs se ressemblent. Les fournisseurs d’hébergement infogéré se distinguent par le contrat, par l’accord de niveau de service (SLA) et par les preuves qu’ils peuvent montrer. Ce guide donne à un chef de la technologie (CTO) ou à un directeur des TI chaque critère, la façon de le vérifier et le signal d’alarme à surveiller.
Que fait concrètement un fournisseur d’hébergement infogéré ?
Un fournisseur d’hébergement infogéré exploite l’infrastructure sous votre application et prend la responsabilité de la garder en santé. Le terme couvre un large éventail d’offres. La première tâche consiste donc à nommer la couche que vous achetez.
Trois couches se vendent couramment sous la même étiquette.
- La facturation et l’administration de compte. Le fournisseur revend ou regroupe des comptes cloud et des factures. Cette couche ajoute peu de valeur opérationnelle, et on la prend souvent pour de la gestion.
- L’exploitation de l’infrastructure. Le fournisseur s’occupe du durcissement, des correctifs, des sauvegardes, de la surveillance, de la garde et de la réponse aux incidents. C’est la couche que la plupart des acheteurs ont en tête quand ils parlent d’hébergement infogéré, de cloud infogéré ou de services de gestion d’infrastructure.
- L’exploitation applicative. Le fournisseur déploie votre code et fait tourner votre pipeline de release. Cette couche demande des accès plus profonds et fait habituellement l’objet d’un mandat distinct.
Un hébergeur WordPress infogéré standard, comme WP Engine ou Kinsta, vend une quatrième forme : une plateforme fixe avec des forfaits publics, où vous gérez le site. Ce modèle convient à beaucoup de sites. C’est un achat différent d’un contrat d’exploitation sur votre propre environnement.
Quels critères utiliser pour comparer des fournisseurs d’hébergement infogéré ?
Chacun des huit critères ci-dessous se vérifie dans un document avant la signature.
| Critère | Comment le vérifier | Signal d’alarme |
|---|---|---|
| 1. Limites du périmètre | Demandez un tableau de responsabilités : qui agit, qui approuve, qui vérifie, par fonction | Le fournisseur rechigne à mettre le périmètre par écrit |
| 2. Qui fait le travail | Demandez qui ouvre une alerte la nuit et à quel moment les ingénieurs seniors interviennent | « Un ingénieur senior répond à tout », sans modèle de dotation derrière |
| 3. Niveaux de gravité | Lisez les définitions de gravité et le délai de réponse chiffré pour chaque niveau | Des niveaux de gravité sans chiffres, ou un seul chiffre pour tout |
| 4. Engagement de disponibilité | Lisez ce que couvre le pourcentage, le crédit et les exclusions | Un pourcentage en vitrine, sans portée ni recours énoncés |
| 5. Sauvegardes | Demandez la date et le résultat du dernier test de restauration | Des journaux de sauvegardes réussies présentés comme preuve de récupération |
| 6. Affirmations de conformité | Demandez quel nom figure sur le rapport cité | Une formule comme « aligné SOC 2 », sans détenteur de rapport nommé |
| 7. Résidence des données et clauses de confidentialité | Trouvez dans l’entente la résidence, la sous-traitance et la notification des incidents de confidentialité | Une résidence promise lors d’un appel de vente et absente du contrat |
| 8. Sortie et portabilité | Demandez quels documents vous conservez, et si un déménagement d’hébergement est exigé | Des runbooks traités comme l’outillage interne du fournisseur |
Où s’arrête le périmètre du fournisseur ?
Le périmètre est une source fréquente de déception dans les contrats d’hébergement infogéré. Dans un cas typique, l’acheteur tient pour acquis que le fournisseur s’occupera d’un déploiement raté. Le fournisseur tient pour acquis que les déploiements relèvent du client. Aucune des deux hypothèses n’est écrite.
Demandez qu’on vous décrive en mots simples la frontière entre l’exploitation de l’infrastructure et l’exploitation applicative. Une application qui tombe à cause de ses propres défauts relève du génie logiciel, et aucun contrat d’exploitation ne la répare. Un bon document de périmètre nomme aussi la fenêtre de couverture, les actifs supervisés et la façon dont le travail hors périmètre est chiffré.
Pour une liste plus longue de questions de vérification, la base de connaissances propose douze questions pour évaluer une compagnie de gestion infonuagique AWS.
Qui fait le travail quand vous ouvrez un billet la nuit ?
Demandez à chaque fournisseur d’hébergement infogéré de décrire son modèle de dotation pour les nuits et les fins de semaine. Un modèle crédible de couverture en continu repose sur une rotation de garde formée qui travaille à partir de runbooks écrits. Les ingénieurs seniors interviennent pour les incidents les plus graves. Un runbook est une procédure documentée pour une panne connue.
Méfiez-vous d’une promesse voulant qu’un ingénieur senior réponde personnellement à chaque alerte. Couvrir les nuits, les fins de semaine, les vacances et les congés de maladie demande plusieurs personnes.
Demandez quel canal fait foi pour le calcul des délais de réponse. Si le délai se mesure à partir d’un billet, un appel téléphonique ou un message de clavardage ne démarre peut-être pas le chronomètre. La base de connaissances explique les clauses de soutien WordPress entreprise qui décident de tout à 3 h du matin.
À quoi le SLA engage-t-il le fournisseur, et quel est le recours ?
Un accord de niveau de service contient plusieurs promesses différentes. Lisez quatre points séparément.
Réponse confirmée ou résolution. Une réponse confirmée signifie qu’une personne a reçu l’incident, l’a confirmé et a entrepris le travail ou l’escalade. La résolution, c’est la correction. Beaucoup de fournisseurs s’engagent sur la première et fixent une cible pour la seconde. Un accusé de réception automatisé ne devrait pas compter comme une réponse confirmée.
Définitions de gravité. Un incident de gravité 1 (Sev-1) signifie habituellement que la production est en panne, et un incident de gravité 2 (Sev-2), qu’elle est dégradée. Votre personnel de soutien utilisera ces définitions. Un non-ingénieur doit donc pouvoir les lire. La base de connaissances explique comment rédiger des définitions de gravité lisibles par un non-ingénieur.
Ce que couvre le chiffre de disponibilité. Un pourcentage peut viser le réseau, l’infrastructure ou votre application. Un fournisseur ne peut s’engager que sur la disponibilité des couches qu’il contrôle.
Ce que couvre le crédit. Les crédits de service se rattachent habituellement à la disponibilité et non à un délai de réponse manqué. Le SLA désigne souvent les crédits comme le seul recours. Il énumère aussi des exclusions, comme la maintenance planifiée et les attaques par déni de service.
Vérifiez aussi si la couverture 24/7 est universelle ou si elle dépend du forfait.
Comment vérifier les sauvegardes, les affirmations de conformité et la résidence des données ?
Ces trois critères passent le même test : demandez des preuves, pas des adjectifs.
Sauvegardes. Une sauvegarde qui n’a jamais été restaurée est une hypothèse. Demandez quand le dernier test de restauration a eu lieu, ce qui a été restauré et combien de temps l’opération a pris. Dans un mandat auprès d’une entreprise canadienne de logiciel-service (SaaS) en techno juridique, l’audit initial a révélé qu’aucune restauration de base de données n’avait jamais été tentée et qu’il n’existait aucun runbook. La base de connaissances décrit comment savoir que la restauration d’une base de données fonctionne. Attendez-vous à ce qu’un fournisseur décrive ses pratiques de sauvegarde, et méfiez-vous de celui qui promet zéro perte de données.
Conformité. Un rapport SOC 2 est le rapport d’un auditeur indépendant sur les contrôles d’une organisation de services. Une attestation de ce genre appartient à l’organisation qui y est nommée. Le rapport d’un centre de données couvre généralement la couche physique et celle de la plateforme, pas les contrôles opérationnels qu’un fournisseur exécute par-dessus. Demandez à qui appartient le rapport et quelles couches il couvre. Si vos clients exigent un rapport détenu par le fournisseur lui-même, faites-en un filtre de présélection.
Résidence et clauses de confidentialité. La résidence, la sous-traitance, la notification des incidents de confidentialité et le retour ou la destruction des données devraient être écrits dans l’entente. Votre responsable de la protection des renseignements personnels peut alors se prononcer à partir de faits documentés. Il le fait en vertu de la Loi sur la protection des renseignements personnels et les documents électroniques (LPRPDE), la loi fédérale qui vise le secteur privé, ou de la Loi 25 sur la protection des renseignements personnels, au Québec. Demandez où se trouvent les sauvegardes et toute région de secours, pas seulement la région principale. Un autre article précise quoi exiger d’un hébergeur pour la résidence des données au Canada.
Que conservez-vous si vous partez, et devez-vous déménager votre hébergement ?
Demandez à chaque fournisseur de nommer ce qui vous suit à la sortie. Les livrables utiles sont un ensemble de runbooks écrits et un diagramme d’architecture qui décrivent votre environnement. Si ces documents vivent seulement dans les outils internes du fournisseur, partir revient à redécouvrir votre propre système.
Demandez aussi si le fournisseur exige que vous déménagiez votre hébergement. Certains fournisseurs gèrent seulement leur propre plateforme, et ce modèle est légitime quand il est annoncé ouvertement. Un fournisseur qui exige un déménagement vend une migration en plus de l’exploitation. Chiffrez et planifiez donc le tout comme un seul projet.
Quels facteurs déterminent le coût de l’hébergement infogéré ?
Le coût suit un petit nombre de facteurs, et un fournisseur devrait être capable de les nommer.
- Le nombre et la catégorie des environnements, comme la production, le staging et le développement.
- La complexité de l’architecture et la redondance, y compris la haute disponibilité et une deuxième région.
- Le profil de trafic et le volume de données.
- La fenêtre de couverture : heures ouvrables, couverture étendue ou 24/7.
- Le délai de réponse engagé pour chaque niveau de gravité.
- Le nombre d’actifs, de sites ou de serveurs supervisés.
- Les heures de projet, le travail de migration et les besoins de conformité ou de résidence.
La couverture est le facteur que les acheteurs sous-estiment, parce qu’une réponse en continu exige une rotation dotée en personnel. Si vos clients dorment quand vous dormez, une couverture en heures ouvrables est peut-être le choix honnête.
La structure de prix détermine aussi l’incitatif du fournisseur. Un prix par utilisateur appartient aux TI de bureau et en dit peu sur un environnement de production. Avec un prix en pourcentage des dépenses, le fournisseur gagne plus quand votre facture cloud grossit. Un prix par billet peut vous décourager de signaler des problèmes. Avec un prix fixe pour un périmètre écrit, le revenu du fournisseur reste le même, que votre facture baisse ou non. Un article complémentaire explique comment l’hébergement cloud infogéré est tarifé et ce qui fait bouger un devis.
Quand choisir un fournisseur d’hébergement infogéré, et quand s’en passer ?
Choisissez un fournisseur d’hébergement infogéré dans les conditions suivantes.
- Vous exploitez des systèmes de production sans équipe d’exploitation pour couvrir les nuits et les fins de semaine.
- Une seule personne détient l’essentiel du savoir de production, et rien n’est écrit.
- Les correctifs, la surveillance et les tests de restauration prennent sans cesse du retard sur le travail produit.
- Des clients ou des auditeurs demandent maintenant des preuves de contrôles que vous ne pouvez pas produire.
N’achetez pas d’exploitation infogérée dans les conditions suivantes.
- Toute votre empreinte tient en une instance et un compartiment de stockage. À cette taille, un contrat est une charge inutile.
- Vous avez assez de travail d’exploitation régulier pour occuper une personne à temps plein, ou votre produit est l’infrastructure. Embauchez cette personne. Un autre article compare l’embauche d’un ingénieur DevOps et l’impartition des opérations.
- Deux ingénieurs ou plus sont déjà responsables de l’exploitation. Ajouter un fournisseur divise la responsabilité, sauf si le partage du périmètre est explicite.
- Votre équipe compte deux développeurs. La construction ponctuelle d’un pipeline, avec sa documentation, est peut-être le bon format.
- Vous exploitez un site WordPress ordinaire. Un hébergeur WordPress infogéré standard, avec des forfaits publics, offre souvent un meilleur rapport qualité-prix.
- Vous avez besoin de TI de bureau, d’un centre d’assistance pour les employés ou d’un centre des opérations de sécurité. Ce sont d’autres catégories de fournisseurs.
Une liste de vérification à apporter à l’appel avec le fournisseur
Posez les huit mêmes questions à chaque fournisseur présélectionné, et demandez où chaque réponse figure par écrit.
- Où s’arrête votre périmètre, et pouvons-nous le voir sous forme de tableau de responsabilités ?
- Qui ouvre une alerte à 3 h du matin, et quel canal démarre le chronomètre de réponse ?
- Quels délais de réponse sont engagés, lesquels sont des cibles, et la couverture 24/7 dépend-elle du forfait ?
- Que couvre le chiffre de disponibilité, quel est le crédit, et qu’est-ce qui est exclu ?
- Quand avez-vous testé une restauration pour la dernière fois sur un environnement comme le nôtre ?
- Quel nom figure sur le rapport de conformité que vous mentionnez, et quelles couches couvre-t-il ?
- Où se trouvent nos données, nos sauvegardes et notre région de secours, et est-ce écrit dans l’entente ?
- Que conservons-nous si nous partons, et devons-nous déménager notre hébergement pour travailler avec vous ?
Notez chaque réponse selon un seul critère : son existence dans un document.
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. Stack Harbor sert des entreprises SaaS, des agences et des éditeurs qui exploitent des systèmes de production sans avoir leur propre équipe d’exploitation 24/7. Voici ses réponses publiées aux huit questions.
- Périmètre. Un mandat Opérations Cloud couvre l’exploitation de l’infrastructure, et l’exploitation applicative est cadrée à part. Le périmètre est écrit et signé.
- Qui fait le travail. Une rotation de garde travaille selon des runbooks conçus par des ingénieurs seniors, et les ingénieurs seniors sont responsables des Sev-1. Le soutien technique passe par le bureau de soutien. Le téléphone permet de joindre le gestionnaire de compte.
- SLA. Dans le SLA de Stack Harbor, l’entreprise s’engage à 99,9 % de disponibilité mensuelle pour son propre réseau et son infrastructure en tant que service (IaaS), avec un crédit de service comme seul et unique recours. Stack Harbor ne garantit pas la disponibilité. Sur les forfaits qui incluent la couverture des incidents, un Sev-1 reçoit une réponse confirmée en moins de 15 minutes et un Sev-2 en moins de 60 minutes. La résolution est une cible, et aucun crédit ne se rattache à un délai de réponse manqué.
- Conformité. Stack Harbor ne détient aucun rapport SOC 2, ni aucune certification ISO 27001, PCI DSS ou HIPAA, en son nom. La page confiance et sécurité sépare ce que les fournisseurs attestent de ce que Stack Harbor opère.
- Résidence. L’infrastructure canadienne propre à Stack Harbor est dans deux centres de données à Montréal. Une charge de travail placée dans ces centres de données reste au Canada, et le placement est documenté.
- Hébergement et sortie. Le service Gestion, supervision et soutien n’exige pas l’hébergement chez Stack Harbor. Chaque mandat livre un runbook écrit et un diagramme d’architecture.
- Prix. Stack Harbor ne publie aucun prix. L’entreprise remet un devis fixe pour un périmètre écrit après une évaluation, comme l’explique la page Comment nous cadrons les mandats.
Stack Harbor n’est pas le bon choix si vous avez besoin d’un rapport SOC 2 détenu par le fournisseur, de soutien technique par téléphone, d’une grille de forfaits publique ou de TI de bureau. Si ces quatre points ne sont pas des obstacles, la prochaine étape est une conversation de cadrage sur votre environnement.
