Infogérance cloud en entreprise

L'infogérance cloud échoue rarement sur la technique. Elle échoue quand le périmètre reste flou, quand la frontière de responsabilité entre l'hébergeur, le prestataire et l'entreprise n'a jamais été posée, et quand le contrat enferme le client au lieu de le libérer. Ce guide opérationnel détaille, sans parti pris éditeur, l'infogérance cloud d'entreprise de bout en bout sur Microsoft Azure et AWS : définition et frontières, périmètre inclus et exclu, modèle de responsabilité partagée décliné pour les deux hyperscalers, niveaux de délégation, grille de SLA lisible, supervision 24/7, continuité d'activité, FinOps opérationnel, conformité (RGPD, ISO 27001, HDS, NIS2, DORA), réversibilité concrète, onboarding, coûts et critères de choix. L'objectif : vous donner les moyens de décider et de contractualiser sereinement, pas de vous vendre un cloud propriétaire.

Qu'est-ce que l'infogérance cloud en entreprise ?

L'infogérance cloud est la délégation, totale ou partielle, de l'exploitation d'une infrastructure hébergée dans le cloud à un prestataire spécialisé. Concrètement, vous confiez la supervision, la maintenance, la sécurité opérationnelle, les sauvegardes, les mises à jour et la disponibilité de vos environnements Azure ou AWS à une équipe externe qui en assure le bon fonctionnement au quotidien, selon des engagements de service contractualisés (SLA).

L'infogérance ne consiste pas à « héberger » votre infrastructure : celle-ci reste dans votre compte cloud, à votre nom. Elle consiste à en opérer le fonctionnement : détecter les incidents, les corriger, appliquer les correctifs, surveiller la sécurité, piloter les coûts et garantir la continuité. C'est le métier du Run (l'exploitation récurrente), par opposition au Build (la construction d'une infrastructure, qui relève d'un projet).

Le périmètre d'un contrat d'infogérance se raisonne en trois couches, qu'il faut traiter distinctement :

• L'infrastructure : machines virtuelles, conteneurs et clusters Kubernetes, réseau, stockage, équilibrage de charge, pare-feux, DNS, identités, sauvegardes. C'est le socle technique sur lequel tout repose.
• L'applicatif : middlewares, bases de données managées, serveurs d'application, files de messages, caches, chaînes de déploiement CI/CD. La frontière avec le métier se situe ici.
• Le poste de travail (optionnel) : terminaux, messagerie, environnements bureautiques managés. Souvent traité séparément de l'infogérance d'infrastructure cloud, mais parfois inclus dans un contrat global.

À retenir : l'infogérance cloud n'externalise pas votre responsabilité, elle externalise votre charge d'exploitation. Vos données, vos accès et votre conformité restent les vôtres. Comprendre cette frontière est le premier acte de maturité d'un contrat d'infogérance.

Le besoin d'infogérance émerge généralement après une migration cloud d'entreprise : une fois l'infrastructure construite, il faut la faire vivre, et peu d'organisations disposent en interne d'une équipe Ops disponible 24/7. L'infogérance répond à ce besoin de continuité.

Infogérance cloud, ce que ce n'est pas

L'infogérance n'est pas de la gestion de parc ni de la maintenance informatique classique. Gérer un parc, c'est administrer des postes, des imprimantes, un annuaire local et des licences. L'infogérance cloud, c'est exploiter une infrastructure dynamique, programmable, facturée à l'usage, où la sécurité est partagée avec un hyperscaler et où la moindre erreur de configuration peut exposer des données ou faire exploser une facture. Les compétences ne sont pas les mêmes : on parle ici d'ingénierie de plateforme, de SRE (Site Reliability Engineering), de FinOps et de sécurité cloud.

L'infogérance n'est pas non plus un simple contrat de surveillance. Surveiller sans pouvoir agir n'a aucune valeur opérationnelle : un bon contrat associe la supervision (détecter) à l'exploitation (corriger), avec des délais d'intervention engagés.

Infogérance, services managés (MSP), hébergement : démêler les termes

Le marché entretient volontairement la confusion entre quatre notions proches. Les distinguer est essentiel pour comparer des offres et éviter les mauvaises surprises contractuelles.

| Notion | Ce que c'est | Ce que vous déléguez | Qui possède l'infrastructure | |---|---|---|---| | Hébergement / cloud public | La fourniture des ressources de calcul, stockage et réseau (Azure, AWS, OVHcloud) | Rien d'opérationnel : vous louez de la capacité, vous l'exploitez vous-même | Vous (compte cloud à votre nom) | | Infogérance cloud | L'exploitation déléguée de votre infrastructure cloud existante, sous SLA | Le Run : supervision, incidents, correctifs, sécurité, sauvegardes, FinOps | Vous | | Services managés (MSP) | Terme large : un prestataire opère un service de bout en bout, parfois sur son propre cloud | Variable selon le contrat ; souvent une couche de service packagée | Vous ou le MSP, selon le modèle | | Gestion de parc / maintenance | Administration des postes, licences, support utilisateurs | Le support de proximité, hors infrastructure cloud | Vous |

La nuance entre infogérance et services managés (MSP) est subtile et souvent commerciale. En pratique :

• L'infogérance désigne historiquement l'exploitation d'une infrastructure que vous possédez. Le prestataire intervient dans votre environnement, sur vos comptes cloud.
• Les services managés désignent une offre plus packagée, parfois liée au cloud du prestataire (un MSP qui vend son propre datacenter ou sa propre plateforme). Le risque, dans ce cas, est l'enfermement : votre infrastructure vit chez le prestataire, et la quitter devient coûteux.

Le point de vigilance numéro un : un prestataire qui vous infogère sur son cloud à lui crée un conflit d'intérêt et une dépendance. Un prestataire indépendant infogère votre infrastructure dans vos comptes Azure ou AWS, à votre nom. La différence est invisible le jour de la signature, décisive le jour où vous voulez partir. C'est le cœur de la réversibilité, traitée plus bas.

Le périmètre d'un contrat : ce qui est inclus, ce qui ne l'est pas

Un contrat d'infogérance sérieux distingue noir sur blanc ce qu'il couvre et ce qu'il ne couvre pas. L'absence de cette distinction est la première cause de litige. Voici les deux faces d'un périmètre type, à adapter selon le niveau de délégation choisi.

Ce qui est généralement inclus

| Domaine | Prestations couvertes | |---|---| | Supervision | Monitoring 24/7 des ressources, alerting, détection d'incident, tableaux de bord de disponibilité | | Exploitation | Traitement des incidents et des demandes, redémarrages, gestion des capacités, application des correctifs et mises à jour | | Sécurité opérationnelle | Gestion des vulnérabilités, durcissement (CIS Benchmarks), revue des accès, surveillance des menaces (Microsoft Defender for Cloud, AWS GuardDuty) | | Sauvegarde & continuité | Configuration et test des sauvegardes, supervision des jobs, exécution et test des plans de reprise (PRA) | | FinOps | Suivi des coûts, rightsizing, recommandations d'engagements, revues mensuelles, alertes budgétaires | | Gouvernance | Reporting, comités de suivi, documentation à jour, gestion des changements |

Ce qui n'est généralement PAS inclus (sauf avenant)

• Le développement applicatif : écrire ou modifier le code de vos applications métier reste à votre charge ou à celle de votre éditeur. L'infogérant exploite, il ne développe pas vos fonctionnalités.
• Les projets de Build : construire une nouvelle architecture, migrer une charge, refondre un environnement relèvent du mode projet, facturé séparément (voir conseil en architecture).
• Les coûts de consommation cloud : la facture Azure ou AWS vous est facturée par l'hyperscaler (ou refacturée en transparence). Les honoraires d'infogérance sont distincts de la consommation cloud.
• Le support utilisateur final / poste de travail, sauf si explicitement contractualisé.
• Les licences logicielles tierces (éditeurs, bases de données propriétaires) au-delà de leur exploitation.
• La responsabilité juridique de traitement des données : vous restez responsable de traitement au sens du RGPD ; l'infogérant est sous-traitant (article 28).

Un bon contrat nomme explicitement les zones grises : qui patche le système d'exploitation des VM ? qui met à jour les images de conteneurs ? qui gère les certificats TLS ? qui répond la nuit ? Si ces questions n'ont pas de réponse écrite, le périmètre n'est pas défini.

Le modèle de responsabilité partagée : où s'arrête le prestataire

C'est le point le plus mal traité du marché, et la première source de litige de périmètre. Dans le cloud, l'exploitation et la sécurité sont partagées entre trois acteurs : l'hyperscaler (Azure ou AWS), l'infogérant et vous. L'hyperscaler est responsable de la sécurité du cloud (datacenters, matériel, hyperviseur, réseau physique) ; vous êtes responsable de la sécurité dans le cloud (configuration, identités, données, applications). L'infogérance vient s'intercaler sur cette seconde moitié : elle prend en charge une partie de votre responsabilité, selon un partage à contractualiser. Confondre ces frontières, c'est laisser des trous béants, ou payer deux fois pour la même chose.

Pour un contrat, l'essentiel est de fixer noir sur blanc la frontière prestataire / client, couche par couche : qui exploite les identités (Entra ID sur Azure, IAM sur AWS), qui configure le réseau, qui supervise les outils de sécurité (Microsoft Defender for Cloud, AWS GuardDuty), qui pilote les sauvegardes et le PRA, sachant que la responsabilité des données, des décisions d'habilitation et de la conformité ne quitte jamais le client (l'infogérant restant sous-traitant au sens de l'article 28 du RGPD). Cette frontière remonte avec le modèle de service : en IaaS, le système d'exploitation reste côté infogérant ; en PaaS (Azure SQL, Amazon RDS, App Service), l'hyperscaler reprend l'OS et le middleware ; en SaaS, presque tout est géré par le fournisseur. Plus vous montez vers le managé, moins il reste de surface à infogérer, mais la responsabilité des données et des accès ne disparaît jamais.

Le détail opérationnel « qui patche quoi » (les matrices IaaS/PaaS/SaaS déclinées couche par couche pour Azure et AWS, et le cycle de vie complet d'un correctif) relève du pilier maintenance : voir qui patche quoi : le MCO cloud. Pour le contrat d'infogérance, exiger cette répartition signée reste un test décisif de la maturité du prestataire : la plupart se contentent d'un « nous assurons la sécurité » qui ne dit ni quelle couche, ni quel partage. Pour la sécurité opérationnelle, voir aussi la sécurisation d'infrastructure cloud.

Les trois domaines et les niveaux de délégation

L'infogérance se décline sur trois domaines (infrastructure, applicatif, poste de travail) et trois niveaux de délégation. Le choix du niveau dépend de vos compétences internes, de votre tolérance au risque et de votre besoin de contrôle.

• Infogérance totale : le prestataire exploite l'intégralité du périmètre, 24/7. Vous n'avez plus d'équipe Ops interne, ou elle se consacre exclusivement à la valeur métier. Adapté aux PME et scale-ups sans équipe Ops, ou aux ETI qui veulent recentrer leurs effectifs sur le Build.
• Infogérance partielle : le partage est fonctionnel ou horaire. Le prestataire couvre par exemple les nuits et week-ends (astreinte), tandis que votre équipe gère les heures ouvrées ; ou bien il prend l'infrastructure pendant que vous gardez l'applicatif. Adapté aux organisations disposant d'une équipe interne à renforcer.
• Infogérance sélective : seules certaines briques sont déléguées (la sécurité, le FinOps, ou un cluster Kubernetes critique). Adapté aux DSI matures qui veulent un appui ciblé sur une expertise rare.

Aide à la décision : totale, partielle ou sélective ?

| Votre situation | Niveau recommandé | |---|---| | Pas d'équipe Ops, pas d'astreinte, croissance rapide | Totale | | Équipe Ops réduite, besoin de couvrir les nuits/week-ends | Partielle (astreinte) | | Équipe interne compétente mais manque d'expertise sécurité ou FinOps | Sélective | | Volonté de garder la main mais besoin de bras supplémentaires | Partielle (par domaine) | | Infrastructure critique 24/7, exigence de disponibilité élevée | Totale avec SLA renforcé |

Le bon niveau n'est pas figé : beaucoup d'organisations démarrent en sélectif sur un périmètre pilote, puis élargissent. Cette montée en charge progressive limite le risque et permet de tester la qualité de la relation avant de tout déléguer. C'est un sujet récurrent : voir le maintien en conditions opérationnelles (MCO cloud) pour la partie exploitation continue.

Les avantages réels pour l'entreprise

Les bénéfices de l'infogérance sont concrets, à condition de ne pas les confondre avec des promesses automatiques.

• Recentrage sur le cœur de métier : vos équipes IT cessent de passer leurs nuits à éteindre des incendies et se concentrent sur ce qui crée de la valeur (produit, données, métier). L'exploitation devient un service, pas une charge mentale permanente.
• Accès à une expertise rare et qualifiée : recruter et retenir un ingénieur cloud senior, un expert sécurité ou un FinOps practitioner est difficile et coûteux. L'infogérance mutualise cette expertise sur plusieurs clients, à un coût accessible.
• Disponibilité et continuité : une astreinte 24/7 outillée détecte et traite les incidents quand votre équipe dort. Le temps de réaction observé s'améliore nettement par rapport à une équipe réduite sans astreinte.
• Maîtrise budgétaire : un forfait mensuel transforme une charge variable et imprévisible (recrutement, turnover, astreinte, formation) en dépense d'exploitation lisible. Le volet FinOps, lui, agit directement sur la facture cloud.
• Scalabilité : le prestataire absorbe la croissance de votre infrastructure sans que vous ayez à recruter en urgence. La capacité opérationnelle suit votre activité.
• Réduction du risque : une équipe spécialisée applique les bonnes pratiques (sauvegardes testées, correctifs à jour, durcissement) que les équipes internes débordées repoussent souvent.

Aucun de ces bénéfices n'est mécanique. Ils se constatent quand le périmètre est clair, le SLA réaliste et la gouvernance vivante. Une infogérance signée puis oubliée, sans comités ni reporting, dérive vers une boîte noire. La valeur naît de la relation pilotée, pas du contrat seul.

Supervision 24/7 : ce que le contrat doit couvrir

La supervision est le système nerveux du Run : sans elle, aucun engagement de service ne tient. Pour un contrat d'infogérance, un seul point de vigilance suffit à séparer une offre sérieuse d'une coquille vide. « Supervision 24/7 » recouvre en effet deux réalités à ne pas confondre : l'alerting automatique (des outils surveillent vos ressources et émettent des alertes) n'est qu'une moitié du sujet ; c'est l'astreinte humaine, un ingénieur qui reçoit l'alerte, l'analyse et agit dans le délai engagé (la GTI), qui transforme la détection en continuité réelle. Une alerte qui sonne dans le vide la nuit ne résout rien. Exigez donc que le contrat précise laquelle des deux il couvre, sur quelles plages, et avec quel délai d'intervention.

Le détail de la chaîne de détection, taxonomie monitoring / observabilité / supervision, outils nommés (Azure Monitor, Amazon CloudWatch), NOC contre astreinte réelle et « qui lit l'alerte à 3 h du matin », relève d'un sujet à part entière : voir la supervision cloud 24/7. Pour le contrat d'infogérance, ce qui compte est que la supervision soit adossée à une astreinte engagée et à la grille SLA détaillée plus bas. Pour une infrastructure instable ou imprévisible, le diagnostic préalable reste essentiel : voir infrastructure cloud instable.

Sécurité, sauvegardes, PCA/PRA et continuité d'activité

L'infogérance porte une part centrale de votre résilience opérationnelle. Trois piliers structurent ce volet.

Sécurité opérationnelle

La sécurité en infogérance ne se résume pas à installer un antivirus. Elle couvre la gestion continue des vulnérabilités, le durcissement des configurations selon les CIS Benchmarks, la revue régulière des accès et des habilitations, la rotation des secrets, le chiffrement des données au repos et en transit, et la surveillance des menaces. Face à la montée des ransomwares, la capacité à détecter une attaque et à restaurer rapidement depuis des sauvegardes saines (immuables, isolées) devient le test ultime de la posture de sécurité.

Sauvegardes

Une sauvegarde n'a de valeur que si elle est testée. Trop d'organisations découvrent le jour de l'incident que leurs sauvegardes étaient incomplètes, corrompues ou non restaurables. L'infogérance assure la configuration, la supervision des jobs, et surtout le test périodique de restauration. Les bonnes pratiques modernes recommandent des sauvegardes immuables et hors-ligne pour résister au chiffrement par ransomware.

PCA et PRA : continuité et reprise

La continuité fait partie intégrante de l'exploitation. Pour le contrat d'infogérance, l'enjeu est de fixer qui est responsable de l'exécution et du test des plans, et selon quels objectifs de RTO (temps maximal de rétablissement) et de RPO (perte de données maximale acceptable, par exemple 15 minutes de transactions). Un PRA non testé est une hypothèse, pas un plan : les tests de bascule périodiques documentés sont donc un livrable à exiger explicitement. Le détail des architectures de continuité (niveaux de redondance, réplication multi-zones et inter-régions, ingénierie du PCA/PRA) relève du pilier maintenance : voir la continuité d'activité PRA/PCA du MCO cloud.

SLA : la grille chiffrée et lisible que le marché évite

Un contrat d'infogérance qui annonce « SLA garantis » sans chiffres ne garantit rien. Le SLA (Service Level Agreement) est le cœur contractuel : il définit les engagements de service mesurables. Un SLA sérieux contient au minimum les éléments suivants.

• La disponibilité : exprimée en pourcentage (par exemple 99,9 %), avec sa méthode de mesure et sa fenêtre (24/7 ou heures ouvrées). À titre indicatif, 99,9 % autorise environ 8 h 45 d'indisponibilité par an ; 99,95 % environ 4 h 22 ; 99,99 % environ 52 minutes.
• La GTI (garantie de temps d'intervention) : le délai entre la détection/déclaration d'un incident et le début de la prise en charge par un ingénieur.
• La GTR (garantie de temps de rétablissement) : le délai entre la déclaration et le rétablissement du service.
• Les plages horaires : 24/7, heures ouvrées étendues, ou astreinte. La couverture conditionne le prix.
• Les pénalités : les avoirs ou réductions appliqués si les engagements ne sont pas tenus.

Voici une grille de SLA représentative du marché, à calibrer selon la criticité réelle de chaque application. Les valeurs ci-dessous sont indicatives et constatées sur des contrats d'infogérance ; elles ne constituent pas un engagement contractuel par défaut.

| Criticité | Disponibilité visée | GTI | GTR | Plage | Pénalités | |---|---|---|---|---|---| | P1 : Critique (production, revenus) | 99,95 % | < 15 min | < 4 h | 24/7 | Avoir progressif par tranche dépassée | | P2 : Importante | 99,9 % | < 30 min | < 8 h | 24/7 ou HO étendues | Avoir | | P3 : Standard | 99,5 % | < 2 h | < 1 jour ouvré | Heures ouvrées | Avoir réduit | | P4 : Faible (test, recette) | Best effort | < 1 jour ouvré | < 3 jours ouvrés | Heures ouvrées | — |

Garde-fou de lecture : aucun prestataire honnête ne « garantit zéro incident ». Ce qui se contractualise, c'est un délai d'intervention et de rétablissement, et une disponibilité visée mesurée sur une période. Méfiez-vous des promesses de disponibilité parfaite : elles trahissent une méconnaissance de la réalité de l'exploitation. La bonne question n'est pas « garantissez-vous 100 % ? » mais « que se passe-t-il, concrètement, quand un incident P1 survient à 3 h du matin ? ».

La criticité doit être attribuée application par application, pas globalement. Payer un SLA P1 pour un environnement de test est un gaspillage ; appliquer un SLA P4 à votre site marchand est une faute. Cette cartographie de criticité est l'un des premiers livrables d'un onboarding sérieux.

Les types de cloud et leur infogérance

L'infogérance s'adapte au type de cloud sur lequel repose votre infrastructure. Chaque modèle a ses implications opérationnelles.

• Cloud public (Azure, AWS, Google Cloud, OVHcloud, Scaleway) : élasticité maximale, innovation continue, facturation à l'usage. L'infogérance y est la plus standardisée et la plus outillée.
• Cloud privé : infrastructure dédiée, isolation renforcée. L'infogérance porte alors aussi sur le socle, avec moins d'élasticité native.
• Cloud hybride : combinaison de public et de privé/on-premise. L'infogérance doit couvrir la cohérence des deux mondes, le réseau d'interconnexion et la sécurité de bout en bout.
• Cloud souverain : pour les organisations soumises à des exigences de souveraineté (secteur public, données sensibles), des offres comme celles qualifiées SecNumCloud ou des clouds opérés en France (OVHcloud, Scaleway) répondent à des contraintes de localisation et de protection contre les lois extraterritoriales. L'infogérance doit alors respecter ces contraintes de périmètre.

Un prestataire réellement indépendant infogère sur plusieurs fournisseurs sans vendre le sien. La neutralité multi-cloud est rare : le marché est dominé par des MSP qui poussent leur propre plateforme. Pouvoir comparer Azure et AWS sans parti pris, et exploiter l'un comme l'autre, est un différenciateur concret.

À qui s'adresse l'infogérance cloud ?

L'infogérance n'est pas réservée aux grands comptes. Elle répond à des profils variés.

• Les PME sans équipe IT dédiée à l'exploitation cloud, qui ne peuvent pas se permettre une astreinte interne mais ont des applications critiques.
• Les ETI qui veulent recentrer leur DSI sur les projets métier et déléguer le Run récurrent.
• Les scale-ups et startups en forte croissance, sans équipe Ops structurée, qui ont besoin d'une exploitation professionnelle pour soutenir leur montée en charge sans recruter en urgence.
• Les éditeurs SaaS dont la disponibilité de la plateforme conditionne directement le chiffre d'affaires et la satisfaction client.
• Les organisations soumises à des contraintes réglementaires (santé, finance, secteur public) qui ont besoin d'une exploitation conforme et auditable.

Le dénominateur commun : une infrastructure cloud dont la disponibilité compte, et une équipe interne qui ne peut pas, ou ne veut pas, porter seule la charge d'exploitation 24/7.

Conformité réglementaire : RGPD, ISO 27001, HDS, NIS2, DORA

La conformité n'est pas une case à cocher : c'est une exigence opérationnelle qui structure l'infogérance, surtout pour les secteurs régulés. Voici comment chaque cadre se traduit concrètement.

RGPD

Vous restez responsable de traitement au sens du RGPD. L'infogérant agit comme sous-traitant et doit signer un accord de sous-traitance conforme à l'article 28 : finalités, durée, mesures de sécurité, sous-traitance ultérieure encadrée, assistance en cas de violation, et localisation des données. Une infogérance bien menée documente les flux de données et la localisation (hébergement en région européenne) pour soutenir votre conformité.

ISO 27001

L'ISO 27001 est la norme de référence du management de la sécurité de l'information. Un prestataire engagé dans une démarche ISO 27001 applique des processus formalisés (gestion des accès, des incidents, des changements, des sauvegardes) qui bénéficient directement à votre exploitation. Attention au vocabulaire : seul l'organisme certifié peut afficher la certification ; une démarche n'est pas une certification.

HDS : hébergement de données de santé

Pour le secteur santé, l'hébergement de données de santé impose le recours à un hébergeur certifié HDS. La certification vise l'hébergeur, pas l'infogérant ni la configuration applicative. Une infogérance pour le secteur santé s'appuie donc sur un partenaire certifié HDS (les régions Azure et certaines offres AWS disposent d'hébergeurs certifiés en France), et veille à ce que l'exploitation respecte ce périmètre. Voir le secteur santé.

NIS2

La directive NIS2 élargit considérablement le nombre d'entités soumises à des obligations de cybersécurité (entités essentielles et importantes). Appliquée à l'infogérance, elle impose : une gestion des risques formalisée, des mesures techniques et organisationnelles, la gestion du risque lié aux prestataires (votre infogérant fait partie de votre chaîne d'approvisionnement) et des obligations de notification d'incident dans des délais courts. L'infogérance doit donc être contractuellement alignée sur ces obligations : qui notifie quoi, à qui, en combien de temps.

DORA : résilience opérationnelle (finance/assurance)

Le règlement DORA (Digital Operational Resilience Act) s'applique au secteur financier et assurantiel. Il opérationnalise quatre exigences directement pertinentes pour l'infogérance :

• La gestion du risque lié aux prestataires tiers de TIC : votre infogérant est un prestataire critique potentiel, à encadrer contractuellement (registre, clauses de sortie, droits d'audit).
• Les tests de résilience opérationnelle : tests de PRA, exercices de continuité, et pour les entités importantes, tests de pénétration fondés sur la menace.
• La gestion et la notification des incidents majeurs liés aux TIC.
• La stratégie de sortie et la réversibilité : DORA exige explicitement des plans de sortie documentés pour les prestataires critiques, ce qui rejoint le pilier réversibilité.

La plupart des contenus du marché « évoquent » NIS2 et DORA sans les opérationnaliser. Pour les secteurs finance et santé, l'enjeu n'est pas de citer ces cadres mais de les traduire en clauses, en tests et en livrables. Une infogérance crédible vous remet la documentation qui soutient votre propre conformité. Pour le cadre général, voir la conformité cloud et la cybersécurité cloud.

FinOps opérationnel : la maîtrise des coûts intégrée au Run

Le FinOps est cité par tout le marché et presque jamais décliné en méthode. Pour un contrat d'infogérance, retenez le principe : l'exploitation est le moment idéal pour piloter les coûts, parce que l'équipe qui opère au quotidien est celle qui voit les gaspillages. Un contrat sérieux intègre donc le suivi des coûts au Run, rightsizing, engagements (Savings Plans, Reserved Instances), extinction des environnements hors usage, étiquetage et revues mensuelles coût/application, au lieu de le facturer en option ou de l'exclure du périmètre.

À titre indicatif, les démarches FinOps intégrées à l'exploitation permettent d'observer des réductions de facture cloud significatives la première année (souvent de l'ordre de 20 à 35 % constatés sur des environnements jamais optimisés), sans dégrader le service. Ces ordres de grandeur sont des moyennes constatées, pas des promesses : le gain dépend de l'état initial. Le détail des leviers en exploitation (TCO d'exploitation, mécanique des réservations, tagging et rightsizing en continu) est traité dans la maîtrise des coûts en exploitation du MCO cloud. Pour un travail dédié, voir l'optimisation des coûts cloud et l'audit FinOps.

La réversibilité : sortir sans douleur

C'est le pilier de marque le plus différenciant, parce que tout le monde le promet vaguement et personne ne le détaille. La réversibilité, c'est votre capacité à reprendre la main ou à changer de prestataire sans tout reconstruire. Un contrat d'infogérance sans réversibilité concrète est un piège à retardement.

La réversibilité réelle se mesure à des éléments tangibles, pas à une clause de style :

• Infrastructure as Code dans VOS dépôts : tout ce qui est construit et maintenu l'est en Terraform ou Bicep, versionné dans vos dépôts Git, pas dans un coffre privé du prestataire. Vous pouvez relire, auditer et rejouer votre infrastructure à tout moment.
• Comptes cloud à votre nom : vos abonnements Azure et vos comptes AWS vous appartiennent. Le prestataire y intervient avec des accès délégués, révocables d'un clic. Votre infrastructure ne vit jamais « chez lui ».
• Run-book et documentation remis : les procédures d'exploitation, les schémas d'architecture, les configurations et les contacts sont documentés et tenus à jour, et cette documentation vous est remise régulièrement, pas seulement à la sortie.
• Plan et tests de sortie : un plan de réversibilité écrit décrit comment transférer l'exploitation à une équipe interne ou à un autre prestataire, avec un transfert de connaissances organisé. Idéalement, ce plan est testé, pas seulement rédigé.

La réversibilité n'est pas une faveur consentie à la sortie : c'est une propriété de conception, présente dès le premier jour. Si tout est en code dans vos dépôts, sur vos comptes, avec une documentation à jour, alors partir devient un projet maîtrisable et non un saut dans le vide. C'est exactement ce qu'exige DORA pour les prestataires critiques, et ce que tout DSI devrait exiger par principe. C'est aussi ce qui distingue un prestataire indépendant d'un MSP qui vous enferme sur son cloud.

Pour comprendre les fondations techniques de cette autonomie, voir l'infrastructure DevOps et la gouvernance cloud.

Onboarding : la reprise d'une infrastructure existante

L'un des sujets les plus absents des contenus concurrents, alors qu'il conditionne tout. Reprendre l'exploitation d'une infrastructure existante (souvent mal documentée) ne s'improvise pas : cela se déroule en phases datées. Voici un phasing type, à adapter selon la taille du périmètre.

| Phase | Durée indicative | Contenu | |---|---|---| | 1. Audit & état des lieux | Semaines 1-2 | Inventaire des ressources, cartographie des applications et dépendances, revue de sécurité et de conformité, cartographie de criticité, évaluation des coûts | | 2. Transfert de connaissances | Semaines 2-4 | Sessions avec l'équipe sortante ou interne, récupération des accès, des configurations et des particularités, identification des zones à risque | | 3. Outillage & documentation | Semaines 3-5 | Mise en place de la supervision, des alertes et de l'astreinte ; rédaction du run-book ; reconstruction de l'IaC si absent ; tableaux de bord | | 4. Période de double run | Semaines 5-7 | Exploitation partagée et supervisée, validation des procédures, ajustement des seuils d'alerte | | 5. Bascule & exploitation nominale | À partir de la semaine 7 | Prise en charge complète sous SLA, comités de gouvernance en régime établi |

Cette montée en charge progressive limite le risque. Reprendre brutalement une infrastructure inconnue du jour au lendemain est la garantie d'incidents évitables. Pour les situations difficiles (infrastructure non documentée, dette technique lourde), voir reprendre une infrastructure cloud existante.

Gouvernance conjointe : comités, RACI et KPI partagés

Une infogérance livrée à elle-même devient une boîte noire. La gouvernance est ce qui maintient la relation vivante et pilotable. Elle s'articule autour de deux instances et d'une matrice de décision.

• Le comité stratégique (trimestriel) : il réunit la direction et le prestataire pour revoir la trajectoire, les évolutions de périmètre, les grands arbitrages (sécurité, budget, modernisation) et la satisfaction.
• Le comité opérationnel (mensuel) : il fait le point sur les incidents, le respect des SLA, les actions FinOps, les changements à venir et les indicateurs.

La répartition décision / exécution / contrôle se formalise dans une matrice RACI : qui décide, qui exécute, qui est consulté, qui est informé. Sans cette clarté, les décisions se diluent et les responsabilités se perdent au premier incident sérieux.

Le reporting doit être exploitable, pas décoratif : disponibilité réelle contre objectif, incidents par criticité, respect des GTI/GTR, évolution des coûts, état des sauvegardes et des tests de PRA, vulnérabilités traitées. Un tableau de bord lisible par une direction non technique est le signe d'une infogérance mature.

Infogérance des environnements Kubernetes et cloud-native

Le sujet est massivement sous-traité par le marché, alors que de plus en plus d'applications tournent sur Kubernetes. Infogérer un cluster managé (AKS sur Azure, EKS sur AWS) exige des compétences spécifiques, distinctes de l'administration de machines virtuelles.

L'exploitation cloud-native couvre notamment :

• La gestion des mises à jour de version du cluster et des nœuds, sans interruption de service (rolling updates).
• Le contrôle d'accès RBAC (qui peut faire quoi dans le cluster) et l'isolation des charges.
• Les network policies (segmentation réseau entre pods), le contrôle d'admission et les politiques de sécurité des pods.
• La supervision spécifique (santé des pods, des nœuds, autoscaling, saturation des ressources).
• La chaîne de déploiement CI/CD et la gestion des manifestes en IaC.

Une infogérance qui prétend couvrir Kubernetes sans maîtriser RBAC, les network policies et le cycle de vie des clusters n'est pas crédible sur le sujet. Pour approfondir, voir la sécurité Kubernetes et le consultant Kubernetes.

Combien coûte l'infogérance cloud ? Modèles, durée et livrables

C'est la question la plus posée et la moins bien traitée. Voici un cadrage honnête, sans prix ferme : le coût réel dépend du périmètre, de la criticité et du niveau de service.

Les modèles de tarification

• Forfait mensuel : le modèle dominant. Un montant fixe couvre un périmètre et un niveau de SLA définis. Il offre la prévisibilité budgétaire. C'est le modèle adapté à la majorité des infogérances.
• Tarification à la ressource : le forfait est indexé sur le volume infogéré (nombre de serveurs, de clusters, d'environnements). Adapté aux infrastructures à périmètre variable.
• Au temps passé (régie) : pour des interventions ponctuelles hors périmètre récurrent (projets de Build, expertises ciblées).
• Modèle hybride : un socle forfaitaire (Run) + de la régie pour les projets. C'est souvent le plus juste.

La fourchette budgétaire

À titre indicatif, un contrat d'infogérance cloud d'entreprise se situe généralement dans une fourchette de 3 000 à 15 000 € par mois, selon le périmètre, la criticité et le niveau de service. Une PME avec une infrastructure simple et un SLA standard se situera dans le bas de la fourchette ; une ETI avec des environnements critiques 24/7, du Kubernetes et des exigences de conformité fortes, dans le haut, voire au-delà.

Ce budget est une fourchette indicative, pas un prix ferme : il s'établit sur devis, après analyse du périmètre. Méfiez-vous des forfaits affichés trop bas : ils cachent souvent un périmètre réduit (alerting sans astreinte humaine, GTR longues, FinOps exclu).

Le TCO réel : équipe interne contre infogérance

La vraie comparaison n'est pas « infogérance contre rien faire », mais « infogérance contre équipe interne ». Internaliser une exploitation 24/7 implique bien plus que des salaires.

| Poste de coût (équipe interne 24/7) | Réalité sur 3 ans | |---|---| | Salaires chargés (2-3 ingénieurs Ops/SRE pour couvrir une astreinte) | Le poste le plus lourd ; profils rares et chers | | Recrutement | Coûts de recrutement et délais de plusieurs mois par poste | | Astreinte | Compensations, fatigue, rotation à organiser | | Formation & certifications | Maintien des compétences Azure/AWS/Kubernetes/sécurité | | Turnover | Départ d'un expert = perte de connaissance et nouveau recrutement | | Outillage | Licences de supervision, sécurité, FinOps |

Sur trois ans, le coût complet d'une équipe d'exploitation interne capable de couvrir un service 24/7 dépasse fréquemment celui d'une infogérance externalisée équivalente, surtout pour une PME ou une ETI qui ne peut pas mutualiser ces profils sur plusieurs clients. Et ce calcul ignore le risque : un seul départ peut désorganiser une petite équipe Ops, là où un prestataire absorbe l'aléa. La décision n'est donc pas qu'une question de prix, c'est une question de résilience.

Durée et livrables

L'infogérance est un engagement récurrent, généralement contractualisé sur 12 à 36 mois, avec des clauses de réversibilité. Les livrables récurrents incluent : tableaux de bord de disponibilité et de coûts, rapports mensuels d'exploitation, comptes rendus de comités, run-book à jour, registre des incidents, et rapports de tests de PRA et de sauvegardes.

Comment choisir son prestataire d'infogérance cloud

Une checklist neutre, à utiliser pour comparer les offres objectivement. Posez ces questions à chaque candidat : les réponses floues sont aussi instructives que les réponses précises.

• Indépendance : le prestataire infogère-t-il sur vos comptes Azure/AWS, ou pousse-t-il son propre cloud ? Y a-t-il un conflit d'intérêt entre conseil et revente ?
• Réversibilité concrète : l'IaC est-il dans vos dépôts ? Les comptes sont-ils à votre nom ? Le plan de sortie est-il écrit et testé ?
• SLA chiffrés : la grille GTI/GTR/disponibilité est-elle détaillée par criticité, avec pénalités, ou se résume-t-elle à « SLA garantis » ?
• Astreinte humaine réelle : qui répond à 3 h du matin, et en combien de temps ? Est-ce de l'alerting automatique ou une vraie astreinte ?
• Certifications et expertise : l'équipe détient-elle des certifications reconnues (Azure Solutions Architect Expert, AWS DevOps Engineer Professional, CISSP, FinOps) ? Sur quelles plateformes ?
• FinOps inclus : l'optimisation des coûts est-elle dans le périmètre, avec des revues régulières, ou hors contrat ?
• Conformité : le prestataire signe-t-il un accord de sous-traitance RGPD (art. 28) ? Suit-il une démarche ISO 27001 ? Sait-il opérer avec un partenaire certifié HDS, et appliquer NIS2/DORA si vous êtes concerné ?
• Gouvernance : des comités et un reporting exploitable sont-ils prévus, ou la relation se résume-t-elle à des tickets ?
• Références : le prestataire a-t-il opéré des infrastructures comparables à la vôtre, dans votre secteur ?

Le meilleur révélateur de la qualité d'un prestataire est sa transparence sur ses limites. Un prestataire qui vous dit clairement ce qu'il ne fait pas, qui chiffre ses SLA et qui documente votre sortie inspire plus confiance qu'un discours sans aspérité. La sérénité se construit sur la clarté, pas sur les promesses.

Pourquoi Architecte Cloud

Architecte Cloud est un intermédiaire indépendant qui met en relation avec des prestataires d'expertise et d'infogérance cloud sur Microsoft Azure et AWS, du conseil à l'exploitation 24/7. Notre positionnement répond directement aux angles morts du marché.

• Indépendance et transparence : les prestataires de notre réseau infogèrent votre infrastructure dans vos comptes Azure et AWS, à votre nom. Nous ne vendons pas de cloud propriétaire, donc nos recommandations n'ont aucun parti pris. Coûts clairs, aucun engagement caché.
• Autonomie et réversibilité par conception : tout ce qui est construit et maintenu l'est en code (Terraform, Bicep) versionné dans vos dépôts. Documentation et run-book remis. Vous n'êtes jamais enfermé.
• Expertise qualifiée : des prestataires disposant des certifications requises (Azure Solutions Architect Expert, AWS DevOps Engineer Professional, CISSP, Azure Security Engineer, FinOps Certified Practitioner), partenaires Microsoft Azure (Solutions Partner for Infrastructure) et AWS (Advanced Tier Services). Démarche ISO 27001, membre de la FinOps Foundation.
• Preuves : un réseau de prestataires expérimentés, sélectionnés sur leurs références et leur ancienneté.

Nous traduisons la technique en décisions claires (coûts, risques, délais) pour la DSI comme pour la direction générale. Découvrez nos services, nos secteurs ou notre approche.

Cas représentatifs par secteur

Exemples représentatifs et anonymisés, cohérents avec des contextes d'infogérance réels. Les chiffres illustrent des ordres de grandeur constatés, pas des engagements.

• Industrie (ETI) : un groupe industriel sans astreinte interne confie l'infogérance de ses environnements Azure de production. Mise en place d'une supervision 24/7 et d'un PRA testé ; le temps de détection des incidents passe de plusieurs heures à quelques minutes constatées, et la facture cloud baisse d'environ un quart après rightsizing. Voir le secteur industrie.
• Finance (PME assujettie DORA) : un acteur financier doit aligner son exploitation sur DORA. Mise en place d'un registre des prestataires tiers, de tests de résilience documentés et d'un plan de sortie testé. L'infogérance soutient directement la conformité réglementaire.
• Santé (éditeur de logiciel médical) : exploitation sur un hébergement chez un partenaire certifié HDS, avec accord de sous-traitance RGPD et sauvegardes immuables contre le ransomware. Voir le secteur santé.
• SaaS (scale-up) : un éditeur en forte croissance, sans équipe Ops, délègue l'exploitation de sa plateforme AWS et de ses clusters EKS. L'astreinte 24/7 soutient la disponibilité, pendant que l'équipe interne se concentre sur le produit. Voir le secteur SaaS.

Pour les autres secteurs, voir distribution et secteur public.

Par où commencer

La bonne porte d'entrée n'est pas de signer un contrat à l'aveugle, mais de poser un diagnostic. Un audit d'infrastructure cloud établit l'état des lieux, la cartographie de criticité, les risques et le périmètre réaliste d'infogérance. C'est sur cette base que se construit un contrat juste, avec le bon niveau de SLA et le bon budget.

Prêt à clarifier votre besoin d'exploitation ? Démarrez par notre diagnostic en ligne ou échangez directement avec un architecte via contact. Réponse sous 48 h ouvrées, sans engagement.

Pour aller plus loin dans la compréhension du cloud, consultez aussi notre guide du cloud.

FAQ : Infogérance cloud en entreprise

Qu'est-ce que l'infogérance cloud ?

L'infogérance cloud est la délégation, totale ou partielle, de l'exploitation d'une infrastructure hébergée dans le cloud à un prestataire spécialisé. Celui-ci assure la supervision, la maintenance, la sécurité opérationnelle, les sauvegardes et la disponibilité de vos environnements Azure ou AWS, selon des engagements de service (SLA). Votre infrastructure reste dans vos comptes cloud, à votre nom : c'est la charge d'exploitation qui est externalisée, pas la propriété.

Quelle est la différence entre infogérance et services managés (MSP) ?

L'infogérance désigne historiquement l'exploitation d'une infrastructure que vous possédez : le prestataire intervient dans vos comptes cloud. Les services managés (MSP) désignent une offre plus packagée, parfois liée au cloud du prestataire. Le point de vigilance : un MSP qui opère sur son propre cloud crée une dépendance, alors qu'un prestataire indépendant infogère dans vos comptes Azure ou AWS, ce qui préserve votre réversibilité.

Quelle est la différence entre infogérance cloud et hébergement cloud ?

L'hébergement (Azure, AWS, OVHcloud) fournit les ressources de calcul, de stockage et de réseau : vous louez de la capacité. L'infogérance, elle, exploite cette infrastructure pour vous : supervision, incidents, correctifs, sécurité, sauvegardes, FinOps. Héberger sans infogérer signifie que vous gérez vous-même l'exploitation. Les deux sont complémentaires, pas équivalents.

Quels services sont inclus dans un contrat d'infogérance cloud ?

Un contrat type inclut la supervision 24/7, le traitement des incidents et des demandes, l'application des correctifs et mises à jour, la sécurité opérationnelle (gestion des vulnérabilités, durcissement, surveillance des menaces), la configuration et le test des sauvegardes, l'exécution des plans de reprise, le pilotage FinOps des coûts, et la gouvernance (reporting, comités, documentation). Le périmètre exact se définit contrat par contrat.

Qu'est-ce qui n'est PAS inclus dans l'infogérance cloud ?

Ne sont généralement pas inclus, sauf avenant : le développement de vos applications métier, les projets de Build (nouvelles architectures, migrations), la facture de consommation cloud elle-même, le support utilisateur final, les licences logicielles tierces, et la responsabilité juridique de traitement des données (vous restez responsable de traitement au sens du RGPD). Un bon contrat nomme explicitement ces exclusions.

Combien coûte l'infogérance cloud pour une entreprise ?

À titre indicatif, un contrat d'infogérance cloud d'entreprise se situe généralement entre 3 000 et 15 000 € par mois, selon le périmètre, la criticité et le niveau de service. Le modèle dominant est le forfait mensuel. Ce budget est une fourchette indicative établie sur devis, après analyse du périmètre. Comparé au coût complet d'une équipe d'exploitation interne 24/7 sur trois ans (salaires, recrutement, astreinte, turnover), l'infogérance est souvent plus économique et plus résiliente pour une PME ou une ETI.

Comment choisir son prestataire d'infogérance cloud ?

Vérifiez son indépendance (infogère-t-il vos comptes ou pousse-t-il son cloud ?), la réversibilité concrète (IaC dans vos dépôts, comptes à votre nom, plan de sortie testé), des SLA chiffrés par criticité (GTI/GTR/disponibilité avec pénalités), une astreinte humaine réelle, les certifications de l'équipe, le FinOps inclus, la conformité (RGPD art. 28, démarche ISO 27001, NIS2/DORA si concerné) et une gouvernance avec reporting exploitable. La transparence sur les limites est le meilleur révélateur de qualité.

Quels sont les trois domaines de l'infogérance ?

Les trois domaines sont l'infrastructure (machines virtuelles, conteneurs, clusters Kubernetes, réseau, stockage, sauvegardes), l'applicatif (middlewares, bases de données managées, CI/CD) et le poste de travail (terminaux, messagerie, environnements bureautiques, souvent traité séparément). Chacun peut être délégué de façon totale, partielle ou sélective selon vos compétences internes et votre besoin de contrôle.

Qu'est-ce qu'un SLA en infogérance et que doit-il contenir (GTI/GTR) ?

Un SLA (Service Level Agreement) définit les engagements de service mesurables. Il doit contenir : la disponibilité visée en pourcentage (par exemple 99,9 %) avec sa méthode de mesure, la GTI (garantie de temps d'intervention, délai de prise en charge d'un incident), la GTR (garantie de temps de rétablissement, délai de retour au service), les plages horaires (24/7 ou heures ouvrées) et les pénalités en cas de manquement. Un SLA sans chiffres ne garantit rien : les engagements doivent être déclinés par niveau de criticité.

Qu'est-ce que la réversibilité dans un contrat d'infogérance ?

La réversibilité est votre capacité à reprendre la main ou à changer de prestataire sans tout reconstruire. Elle se mesure à des éléments concrets : l'Infrastructure as Code (Terraform, Bicep) versionnée dans vos dépôts, les comptes cloud à votre nom avec accès délégués révocables, le run-book et la documentation remis régulièrement, et un plan de sortie écrit et idéalement testé. C'est une propriété de conception présente dès le premier jour, pas une faveur à la sortie. Le règlement DORA l'exige pour les prestataires critiques.

Infogérance cloud totale ou partielle : que choisir ?

L'infogérance totale délègue l'intégralité de l'exploitation 24/7 ; elle convient aux organisations sans équipe Ops ou voulant recentrer leurs effectifs sur le métier. L'infogérance partielle partage la charge (par horaires ou par domaine) et convient aux équipes internes à renforcer. L'infogérance sélective ne délègue que certaines briques (sécurité, FinOps, un cluster critique) et convient aux DSI matures. Beaucoup d'organisations démarrent en sélectif sur un pilote, puis élargissent.

L'infogérance cloud est-elle adaptée aux PME ?

Oui. L'infogérance permet justement aux PME, qui ne peuvent pas se permettre une astreinte interne 24/7 ni recruter des experts cloud rares, d'accéder à une exploitation professionnelle à coût maîtrisé. Le forfait mensuel transforme une charge imprévisible en dépense lisible, et le prestataire mutualise l'expertise sur plusieurs clients. C'est souvent plus économique et plus résilient que d'internaliser pour une organisation de taille modeste.

Infogérance Azure ou AWS : comment décider ?

Le choix dépend de votre existant, de vos compétences, de vos contraintes réglementaires et des services dont vous dépendez. Azure s'impose souvent dans les environnements Microsoft (Entra ID, écosystème 365) ; AWS offre la plus large étendue de services. Un prestataire réellement indépendant compare les deux sans parti pris et peut infogérer l'un comme l'autre, voire les deux en multi-cloud. La décision se prend sur des critères objectifs, pas sur la plateforme que le prestataire préfère vendre.

L'infogérance cloud assure-t-elle la conformité RGPD, NIS2 et DORA ?

L'infogérance soutient votre conformité mais ne s'y substitue pas : vous restez responsable de traitement au sens du RGPD, l'infogérant étant sous-traitant (article 28). Pour NIS2, l'infogérance doit s'aligner sur la gestion du risque prestataire et les obligations de notification d'incident. Pour DORA (finance/assurance), elle doit fournir registre des tiers, tests de résilience et plan de sortie. Une infogérance crédible remet la documentation qui soutient votre propre conformité ; elle ne délivre pas une conformité « clé en main ».

Comment se déroule la reprise d'une infrastructure existante ?

La reprise se fait en phases datées : audit et état des lieux (cartographie des ressources, applications, dépendances, criticité), transfert de connaissances (récupération des accès et configurations), outillage et documentation (supervision, run-book, reconstruction de l'IaC si nécessaire), période de double run supervisée, puis bascule en exploitation nominale sous SLA. Cette montée en charge progressive, généralement sur quelques semaines, limite le risque d'incidents évitables.

Qui est responsable de la sécurité : le prestataire, l'hébergeur ou l'entreprise ?

Les trois, selon le modèle de responsabilité partagée. L'hyperscaler (Azure, AWS) sécurise le socle physique, l'hyperviseur et le réseau. L'infogérant prend en charge la configuration, les correctifs, les accès et la surveillance des menaces. L'entreprise reste responsable de la classification de ses données, des décisions d'habilitation et de sa conformité. La frontière exacte dépend du modèle de service (IaaS, PaaS, SaaS) et doit être formalisée dans une matrice signée.

Comment éviter la dépendance (vendor lock-in) à son infogérant ?

En exigeant une réversibilité concrète dès la signature : Infrastructure as Code (Terraform, Bicep) dans vos dépôts, comptes cloud à votre nom avec accès délégués révocables, documentation et run-book remis régulièrement, et un plan de sortie écrit et testé. Évitez les prestataires qui hébergent votre infrastructure sur leur propre cloud : c'est la principale source d'enfermement. Avec un prestataire indépendant qui opère dans vos comptes, changer de prestataire reste un projet maîtrisable.