L'infogérance informatique ne se limite plus à surveiller quelques serveurs en salle machine. Elle couvre aujourd'hui un système d'information éclaté entre des serveurs physiques résiduels, des environnements cloud sur Azure et AWS, un réseau, un parc de postes de travail, la sécurité, les sauvegardes et le support aux utilisateurs. Cette page traite l'infogérance dans son périmètre le plus large : ce qu'elle recouvre réellement domaine par domaine, ce qui distingue l'infogérance classique de l'infogérance cloud, comment lire un contrat et ses engagements de service, et surtout comment choisir un infogéreur sans se retrouver enfermé. Le tout avec le regard d'un intermédiaire indépendant, ancré sur le cloud, qui cadre votre besoin et vous met en relation avec des prestataires qualifiés.
- Exploitation du SI
- Azure & AWS
- Support N1 / N2 / N3
- SLA, GTI, GTR
- Réversibilité contractuelle
- L'infogérance informatique est l'externalisation, totale ou partielle, de l'exploitation d'un système d'information : serveurs, cloud, réseau, postes de travail, sécurité, sauvegardes et support utilisateur.
- Le marché bascule du modèle classique (parc physique) vers le modèle cloud (Azure, AWS), où l'exploitation devient programmable et pilotée par la donnée.
- Trois niveaux de délégation : totale, partielle, sélective. Trois engagements clés : SLA, GTI, GTR, adossés à une astreinte réelle.
- Deux points non négociables : la frontière de responsabilité écrite et la réversibilité (code et comptes à votre nom).
- Budget indicatif d'un contrat récurrent : 3 000 à 15 000 € par mois, sur devis selon le périmètre.
Qu'est-ce que l'infogérance informatique ?
L'infogérance informatique est la délégation contractuelle, à un prestataire spécialisé, de tout ou partie de l'exploitation d'un système d'information. Le terme, apparu en France dans les années 1990, désigne le fait de confier à un tiers le fonctionnement quotidien de l'informatique : maintenir les systèmes disponibles, corriger les incidents, appliquer les mises à jour, protéger les données et assister les utilisateurs, contre un engagement de service mesurable.
L'idée fondatrice n'a pas changé : recentrer l'entreprise sur son métier en confiant l'exploitation technique à ceux dont c'est le métier. Ce qui a changé, c'est l'objet exploité. Hier, on infogérait des serveurs physiques, un réseau local et des postes. Aujourd'hui, la majeure partie de la valeur s'est déplacée vers le cloud public, où l'infrastructure n'est plus un matériel que l'on possède mais un ensemble de services que l'on consomme. L'infogérance moderne doit donc couvrir un système d'information hybride, à cheval entre le peu qui reste sur site et l'essentiel qui vit désormais sur Azure ou AWS.
Il faut distinguer d'emblée l'infogérance de deux notions voisines. Elle n'est pas de l'hébergement : héberger, c'est fournir la capacité (un datacenter, un cloud public) ; infogérer, c'est faire fonctionner ce qui tourne dessus. Elle n'est pas non plus de la TMA (tierce maintenance applicative) : la TMA maintient le code de vos applications métier, l'infogérance maintient le socle technique sur lequel ces applications s'exécutent. Confondre ces trois métiers conduit à des contrats troués, où chacun croit que l'autre s'occupe d'un sujet que personne ne traite.
À retenir : l'infogérance externalise votre charge d'exploitation, pas votre responsabilité. Vos données, vos décisions d'accès et votre conformité restent les vôtres. Comprendre cette frontière est le premier acte de maturité d'un contrat.
Run et Build : deux mondes, deux logiques
L'infogérance appartient au monde du Run, l'exploitation récurrente, par opposition au Build, la construction d'une infrastructure ou d'une application, qui relève du mode projet. Un projet a un début et une fin ; l'infogérance est récurrente par nature et se mesure dans la durée. Cette distinction est structurante pour le contrat comme pour le budget : construire une architecture cloud est un investissement ponctuel, l'exploiter est un abonnement mensuel. Le besoin d'infogérance émerge d'ailleurs souvent au lendemain d'une migration cloud d'entreprise : une fois l'infrastructure bâtie, il faut la faire vivre, et peu d'organisations disposent en interne d'une équipe disponible en continu.
Le périmètre couvert : les sept domaines d'un SI infogéré
Un contrat d'infogérance informatique sérieux nomme précisément ce qu'il couvre. Le périmètre le plus large s'organise en sept domaines. Tous ne sont pas systématiquement délégués : le choix dépend de vos compétences internes et de vos priorités, mais chacun doit être explicitement inclus ou exclu, jamais laissé dans le flou.
-
Serveurs
Machines physiques résiduelles et machines virtuelles cloud : disponibilité, correctifs du système d'exploitation, capacités, redémarrages, cycle de vie.
-
Cloud (Azure / AWS)
Exploitation des ressources managées, conteneurs et clusters Kubernetes (AKS, EKS), pilotage des coûts (FinOps), gouvernance des comptes et abonnements.
-
Réseau
Connectivité LAN/WAN, VPN et interconnexions (ExpressRoute, Direct Connect), pare-feux, DNS, équilibrage de charge, supervision de la latence.
-
Postes de travail
Parc bureautique, gestion de flotte (MDM/Intune), messagerie, environnements collaboratifs, déploiement d'applications, cycle de renouvellement.
-
Sécurité
Maintien en conditions de sécurité : gestion des vulnérabilités, durcissement, protection des postes (EDR), revue des accès, surveillance des menaces.
-
Sauvegarde & continuité
Configuration et supervision des sauvegardes, tests de restauration, sauvegardes immuables, plans de reprise et de continuité (PRA/PCA).
-
Support / helpdesk
Assistance aux utilisateurs et traitement des incidents par niveaux (N1, N2, N3), gestion des demandes, escalade, base de connaissances.
Cette largeur de périmètre est ce qui distingue l'infogérance informatique générale d'une prestation plus ciblée. Un contrat cloud pur se concentre sur l'infrastructure Azure ou AWS ; un contrat d'infogérance informatique peut englober jusqu'au dernier poste de travail et à la hotline qui répond aux collaborateurs. C'est aussi ce qui en fait un sujet à cadrer avec méthode, car un périmètre trop large mal découpé coûte cher, et un périmètre trop étroit laisse des angles morts.
Ce qui est inclus, ce qui ne l'est pas
| Domaine | Généralement inclus | Généralement exclu (sauf avenant) |
|---|---|---|
| Serveurs & cloud | Supervision, correctifs, incidents, capacités, sauvegardes | Développement d'applications métier, projets de Build |
| Réseau | Exploitation, supervision, sécurité des flux | Refonte d'architecture réseau, câblage physique |
| Postes de travail | Support, mises à jour, gestion de flotte | Achat du matériel, licences applicatives tierces |
| Sécurité | MCS, gestion des vulnérabilités, EDR | Audit de sécurité approfondi, pentest, SOC complet |
| Sauvegarde | Configuration, supervision, tests de restauration | Coût de stockage cloud (facturé par l'hyperscaler) |
| Support | Helpdesk N1/N2/N3 selon contrat | Formation métier des utilisateurs |
| Conformité | Documentation, journalisation, assistance | Responsabilité juridique de traitement (reste au client) |
Un bon contrat nomme explicitement les zones grises : qui patche le système d'exploitation des serveurs ? qui gère les certificats TLS ? qui répond au collaborateur bloqué à 8 h du matin ? qui restaure après une erreur de manipulation ? Sans réponse écrite à ces questions, le périmètre n'existe pas.
Infogérance classique et infogérance cloud : ce qui change vraiment
C'est la ligne de partage qui structure tout le marché aujourd'hui. L'infogérance classique a été pensée pour des infrastructures que l'on possède : serveurs physiques, baie de stockage, hyperviseur, réseau local. Maintenir en condition y signifie surveiller du matériel, remplacer des disques, gérer des garanties et des fins de support, appliquer des correctifs sur des systèmes d'exploitation administrés de bout en bout. Les outils historiques sont eux-mêmes ancrés sur site.
L'infogérance cloud change la nature même du travail. Le matériel disparaît du périmètre client : vous ne gérez plus de disques ni d'hyperviseurs, mais des services élastiques et facturés à l'usage. L'exploitation devient logicielle : on n'inspecte plus un serveur, on interroge une API, on déclenche un correctif via un service managé, on reconstruit un environnement à partir de code. Et les coûts, figés en salle machine, deviennent variables et pilotables mois après mois, ce qui fait du FinOps une composante native de l'exploitation.
| Critère | Infogérance classique | Infogérance cloud (Azure / AWS) |
|---|---|---|
| Objet exploité | Serveurs physiques, baie, hyperviseur | Services managés, conteneurs, ressources élastiques |
| Frontière de responsabilité | Vous gérez tout le matériel et l'OS | Partagée avec l'hyperscaler, variable selon IaaS/PaaS/SaaS |
| Mode d'intervention | Physique, sur site ou à distance | Par API, en Infrastructure as Code |
| Modèle de coût | Capital figé (matériel amorti) | Dépense variable, pilotable en continu (FinOps) |
| Outils | Supervision réseau, ordonnanceurs on-premise | Azure Monitor, CloudWatch, Update Manager, Policy |
| Élasticité | Limitée par le matériel installé | Native, la capacité suit l'activité |
La plupart des systèmes d'information réels sont hybrides : quelques serveurs encore sur site, l'essentiel des charges déjà sur Azure ou AWS. Une infogérance informatique crédible doit donc savoir opérer les deux mondes et surtout gouverner leur cohérence : une vision consolidée de la supervision, des correctifs et de la sécurité à travers des environnements hétérogènes. C'est précisément là qu'un prestataire encore centré sur des réflexes de datacenter atteint sa limite. Le socle purement cloud de cette exploitation relève de notre page pilier, l'infogérance cloud en entreprise, dont cette page est la porte d'entrée large ; pour un environnement 100 % Microsoft, voir l'infogérance Azure.
Le piège le plus courant : appliquer au cloud des réflexes hérités du datacenter. Superviser un cloud comme des serveurs physiques, c'est passer à côté de l'automatisation native, sur-payer de la capacité dormante et croire que « le cloud se gère tout seul ». Le cloud ne se gère pas tout seul : il se gère autrement.
Support et helpdesk : les niveaux N1, N2, N3
Le support aux utilisateurs est le visage quotidien de l'infogérance, celui que les collaborateurs perçoivent directement. Il s'organise classiquement en trois niveaux, hérités des cadres de gestion des services informatiques (ITIL / ITSM).
- N1, premier niveau : réception et qualification des demandes et des incidents, traitement des cas courants selon des procédures établies (réinitialisation d'accès, incident bureautique, question d'usage), escalade si nécessaire. C'est le point de contact.
- N2, deuxième niveau : diagnostic technique approfondi, résolution des incidents qui dépassent les procédures du N1. Compétences système, réseau et cloud confirmées.
- N3, troisième niveau : expertise pointue (architecture, ingénierie, correction de fond) et intervention sur la configuration profonde. C'est le niveau qui traite les incidents complexes et alimente l'amélioration continue, parfois en lien avec l'éditeur ou l'hyperscaler.
Ce support humain se distingue de la supervision technique, qui détecte les incidents avant même qu'un utilisateur ne s'en aperçoive. Les deux fonctionnent ensemble : la supervision capte le signal, le helpdesk traite la demande. La taxonomie complète de la détection (monitoring, observabilité, NOC, astreinte, « qui lit l'alerte à 3 h du matin ») fait l'objet d'une page dédiée : voir la supervision cloud 24/7. Pour l'infogérance informatique, l'essentiel est que le contrat précise les plages de couverture du helpdesk, les canaux (téléphone, portail, courriel), et les délais de prise en charge par niveau de gravité.
Les niveaux d'infogérance : totale, partielle, sélective
Le degré de délégation se choisit selon vos compétences internes, votre tolérance au risque et votre besoin de garder la main.
-
Infogérance totale
Le prestataire exploite l'intégralité du périmètre, en continu. Adaptée aux organisations sans équipe interne d'exploitation, ou qui veulent recentrer leurs effectifs sur la valeur métier.
-
Infogérance partielle
Le partage est horaire ou fonctionnel : le prestataire couvre les nuits et week-ends en astreinte, ou prend l'infrastructure pendant que vous gardez l'applicatif. Pour une équipe interne à renforcer.
-
Infogérance sélective
Seules certaines briques sont déléguées : la sécurité, le FinOps, un cluster Kubernetes critique. Pour les DSI matures qui veulent un appui ciblé sur une expertise rare.
Le bon niveau n'est pas figé. Beaucoup d'organisations démarrent en sélectif sur un périmètre pilote, valident la qualité de la relation, puis élargissent progressivement. Cette montée en charge limite le risque et permet de tester un prestataire avant de tout lui confier. La mécanique détaillée de ces niveaux, avec la grille d'aide à la décision et les profils types, est développée sur le pilier : voir choisir entre infogérance totale, partielle ou sélective. Pour la partie exploitation continue et maintenance, voir aussi le maintien en conditions opérationnelles (MCO cloud).
Le modèle de responsabilité partagée
Dès qu'une partie du SI vit dans le cloud, la responsabilité de l'exploitation et de la sécurité se partage entre trois acteurs : l'hyperscaler (Azure ou AWS), l'infogéreur 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). L'infogérance s'intercale sur cette seconde moitié : elle prend en charge une partie de votre responsabilité, selon un partage à contractualiser.
La frontière exacte remonte avec le type de service. En IaaS (machine virtuelle), le système d'exploitation invité et ses correctifs restent à votre charge, donc à celle de l'infogéreur si vous les déléguez. En PaaS (base de données managée, App Service), l'hyperscaler reprend l'OS et le moteur, et votre surface d'exploitation se réduit. En SaaS, presque tout est géré par le fournisseur. Ce qui ne quitte jamais le client, quel que soit le modèle : la responsabilité des données, des décisions d'habilitation et de la conformité, l'infogéreur restant sous-traitant au sens de l'article 28 du RGPD.
Exiger cette répartition signée, couche par couche, est un test décisif de la maturité d'un prestataire. La plupart se contentent d'un « nous assurons la sécurité » qui ne dit ni quelle couche, ni quel partage. Le détail opérationnel du « qui patche quoi », avec les matrices IaaS/PaaS/SaaS déclinées pour Azure et AWS, est traité sur le MCO cloud et le patch management. La sécurisation technique de fond relève de la sécurisation d'infrastructure cloud.
SLA, GTI, GTR et astreinte : les engagements de service
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 des engagements mesurables. Quatre notions doivent y figurer clairement.
- La disponibilité Exprimée en pourcentage (99,9 %, 99,95 %…), avec sa méthode de mesure et sa fenêtre. À titre de repère, 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éclaration d'un incident et le début de sa prise en charge par un ingénieur.
- La GTR (garantie de temps de rétablissement) Le délai entre la déclaration et le retour au service. Souvent présentée comme un objectif visé, car elle peut dépendre de tiers.
- L'astreinte La couverture réelle hors heures ouvrées : une équipe joignable et engagée sur un délai, pas une boîte courriel non surveillée. C'est elle qui transforme une alerte nocturne en action.
Ces engagements se calibrent application par application, selon la criticité. Payer un SLA maximal pour un environnement de test est un gaspillage ; appliquer un SLA minimal à votre site marchand est une faute. Un point de vigilance sépare une offre sérieuse d'une coquille vide : l'écart entre l'alerting automatique (un outil émet une alerte) et l'astreinte humaine (un ingénieur reçoit l'alerte, l'analyse et agit dans le délai engagé). Une alerte qui sonne dans le vide la nuit ne résout rien.
La grille SLA chiffrée complète, déclinée par niveau de criticité (P1 à P4) avec GTI, GTR, plages et pénalités, est détaillée sur le pilier : voir la grille SLA, GTI et GTR de l'infogérance. 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.
Sécurité et conformité : RGPD, ISO 27001, sauvegardes
La sécurité et la conformité ne sont pas des options d'un contrat d'infogérance : elles le structurent, surtout dans les secteurs régulés. Trois cadres reviennent systématiquement.
- RGPD : vous restez responsable de traitement, l'infogéreur agit comme sous-traitant et doit signer un accord conforme à l'article 28 (finalités, durée, mesures de sécurité, sous-traitance ultérieure encadrée, assistance en cas de violation, localisation des données). Une infogérance bien menée documente les flux et la localisation (hébergement en région européenne) pour soutenir votre conformité.
- ISO 27001 : 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é affiche la certification ; une démarche n'est pas une certification.
- Sauvegardes : une sauvegarde n'a de valeur que testée. L'infogérance assure la configuration, la supervision des jobs et, surtout, le test périodique de restauration. Face aux rançongiciels, les bonnes pratiques imposent des sauvegardes immuables et isolées, qu'un administrateur compromis ne peut ni modifier ni supprimer.
Les architectures conçues par les prestataires du réseau sont conformes RGPD, et leur exploitation s'inscrit dans une démarche ISO 27001. Le panorama réglementaire complet (RGPD, ISO 27001, HDS, NIS2, DORA) et sa traduction en clauses sont traités sur la conformité en infogérance cloud et sur notre page conformité cloud. Pour la sécurité opérationnelle de fond, voir la cybersécurité cloud.
Réversibilité et propriété : ne jamais être captif
C'est le point qui sépare un partenaire d'un piège. Trop de contrats créent une dépendance silencieuse : infrastructure hébergée sur le cloud du prestataire, configurations dans un coffre privé, comptes ouverts à son nom. Le jour où vous voulez partir, tout est à reconstruire. La réversibilité est votre capacité à reprendre la main ou à changer d'infogéreur sans repartir de zéro. Elle se mesure à des éléments tangibles, pas à une clause de style.
Les quatre preuves d'une réversibilité réelle. Un, l'Infrastructure as Code (Terraform, Bicep) versionnée dans vos dépôts Git, pas dans un coffre du prestataire. Deux, les comptes cloud à votre nom (votre tenant Azure, vos comptes AWS), où le prestataire intervient avec des accès délégués révocables. Trois, un run-book et une documentation remis régulièrement, pas seulement à la sortie. Quatre, un plan de réversibilité écrit et testé, décrivant le transfert vers une équipe interne ou un autre prestataire.
Cette autonomie n'est pas une faveur consentie à la sortie : c'est une propriété de conception, présente dès le premier jour. C'est aussi ce que le règlement DORA exige explicitement des prestataires critiques dans la finance et l'assurance, et ce que tout décideur devrait exiger par principe. Les fondations techniques de cette indépendance sont détaillées sur l'infrastructure DevOps et la gouvernance cloud.
Comment choisir son infogéreur : la grille de critères
C'est la partie la plus utile et la moins bien traitée. Choisir un infogéreur ne se joue pas sur le prix affiché mais sur des critères objectifs. Posez ces questions à chaque candidat : les réponses floues sont aussi instructives que les réponses précises.
- Indépendance Le prestataire opère-t-il sur vos comptes Azure et AWS, ou pousse-t-il son propre cloud ? Y a-t-il un conflit d'intérêt entre conseil et revente ? Un intermédiaire indépendant n'a rien à vous vendre d'autre que la bonne orientation.
- 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é ? La réponse conditionne votre liberté future.
- 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 engagée ?
- Expertise et certifications L'équipe détient-elle les certifications reconnues (Azure Solutions Architect Expert, AWS DevOps Engineer Professional, CISSP, FinOps Certified Practitioner) et sur quelles plateformes ?
- Périmètre du support Le helpdesk N1/N2/N3 est-il inclus, sur quelles plages, avec quels délais ? Les postes de travail sont-ils couverts ?
- FinOps inclus L'optimisation des coûts est-elle dans le périmètre, avec des revues régulières, ou facturée en option ?
- 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éduit-elle à des tickets ?
Le signal d'alarme à connaître. Un prestataire qui héberge votre infrastructure sur son cloud à lui crée une dépendance et un conflit d'intérêt. La différence est invisible le jour de la signature, décisive le jour où vous voulez partir. Un infogéreur indépendant opère votre infrastructure dans vos comptes, à votre nom.
Le meilleur révélateur de la qualité d'un prestataire est sa transparence sur ses limites. Un infogéreur 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.
Comment contractualiser : les clauses qui protègent
Une fois le prestataire choisi, le contrat traduit la relation en obligations. Cinq clauses méritent une attention particulière, car ce sont elles qui se retournent contre vous en cas de litige si elles sont mal rédigées.
- Le périmètre détaillé : la liste précise de ce qui est inclus et exclu, domaine par domaine, avec les zones grises nommées. C'est la première cause de conflit quand elle manque.
- Les niveaux de service : la grille SLA par criticité (disponibilité, GTI, GTR, plages), les modalités de mesure et les pénalités. Un SLA sans méthode de mesure ni pénalité n'engage à rien.
- La matrice de responsabilité (RACI) : qui décide, qui exécute, qui est consulté, qui est informé, pour chaque type de décision. Sans cette clarté, les responsabilités se perdent au premier incident sérieux.
- La sous-traitance RGPD (art. 28) : l'accord qui encadre le traitement de vos données personnelles, indispensable dès que le prestataire y accède.
- La réversibilité et la clause de sortie : le plan de transfert, la propriété du code et des comptes, le préavis, l'assistance à la sortie. À négocier à l'entrée, jamais à la sortie.
La gouvernance vivante complète le contrat : un comité opérationnel mensuel (incidents, respect des SLA, actions FinOps, changements) et un comité stratégique trimestriel (trajectoire, arbitrages, satisfaction). Une infogérance signée puis oubliée dérive vers une boîte noire. La valeur naît de la relation pilotée, pas du contrat seul. Le détail de la gouvernance conjointe (comités, RACI, KPI partagés) et de l'onboarding en phases datées figure sur le pilier infogérance cloud entreprise.
Combien coûte l'infogérance informatique ? Modèles et budget
C'est la question la plus posé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 et convient à la majorité des contrats.
- Tarification au poste : le prix est indexé sur le nombre d'utilisateurs ou de postes gérés (fréquent pour le volet support et poste de travail). Adaptée aux organisations dont l'effectif est la bonne unité de mesure.
- Tarification à la ressource : le forfait suit le volume infogéré (serveurs, clusters, environnements). Adaptée aux infrastructures cloud à périmètre variable.
- Au temps passé (régie) : pour les interventions ponctuelles hors périmètre récurrent (projets de Build, expertises ciblées).
- Modèle hybride : un socle forfaitaire pour le Run, complété de régie pour les projets. Souvent le plus juste.
La fourchette budgétaire
- Récurrentengagement mensuel, généralement sur 12 à 36 mois
- 3 à 15 k€budget indicatif par mois, sur devis selon le périmètre
- Forfaitmodèle dominant, au poste ou à la ressource selon le cas
- Hors consola facture cloud reste distincte, à votre nom
À titre indicatif, un contrat d'infogérance informatique 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. Une PME avec une infrastructure simple et un SLA standard se place dans le bas de la fourchette ; une ETI avec des environnements critiques en continu, du Kubernetes, un parc de postes étendu et des exigences de conformité fortes, dans le haut, voire au-delà.
Cette fourchette est un budget indicatif, présenté en repère de discussion et confirmé sur devis après analyse du périmètre. Ce n'est pas un prix ferme. La consommation cloud elle-même (votre facture Azure ou AWS) reste distincte et à votre nom, sans marge cachée. 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).
La vraie comparaison n'est pas « infogérance contre ne rien faire », mais « infogérance contre équipe interne ». Internaliser une exploitation en continu suppose plusieurs ingénieurs en rotation, du recrutement de profils rares, une astreinte à organiser, de la formation et un turnover à absorber. Sur trois ans, ce coût complet dépasse fréquemment celui d'une infogérance équivalente, surtout pour une PME ou une ETI qui ne peut pas mutualiser ces profils. Le volet FinOps agit en plus directement sur la facture cloud : les démarches d'optimisation intégrées à l'exploitation permettent d'observer des réductions de l'ordre de 20 à 35 % constatés la première année sur des environnements jamais optimisés, sans garantie, le gain dépendant de l'état initial. Voir l'optimisation des coûts cloud et notre audit FinOps.
Migrer d'une infogérance classique vers une infogérance cloud
Beaucoup d'organisations sont liées à un infogéreur historique orienté datacenter, alors que leur SI a déjà largement basculé dans le cloud. Le symptôme est connu : des coûts qui dérivent, une réactivité limitée, un prestataire qui « fait tourner » sans piloter les coûts ni exploiter l'automatisation cloud. Changer d'infogérance est alors un projet à part entière, dont la réussite tient à trois conditions.
D'abord, un état des lieux honnête : inventaire des ressources sur site et dans le cloud, cartographie des applications et de leurs dépendances, revue de sécurité, cartographie de criticité, évaluation des coûts. C'est l'objet d'un audit d'infrastructure cloud. Ensuite, un transfert de connaissances organisé avec l'équipe sortante (récupération des accès, des configurations, des particularités, identification des zones à risque), suivi d'une période de double run supervisée avant la bascule complète. Enfin, la reconstruction de l'Infrastructure as Code quand elle est absente, pour ne plus dépendre du savoir d'une personne. Cette montée en charge progressive limite le risque d'incidents évitables. Les situations les plus difficiles (infrastructure non documentée, dette technique lourde) sont traitées sur reprendre une infrastructure cloud existante.
L'infogérance par secteur
Le périmètre reste le même, mais les contraintes changent radicalement selon l'activité. Quatre profils illustrent ces différences.
- Industrie : des groupes industriels sans astreinte interne confient l'exploitation de leurs environnements de production, souvent hybrides (Azure et serveurs résiduels). L'enjeu : une supervision consolidée et un PRA testé. Voir le secteur industrie.
- Santé : l'hébergement des données de santé impose un partenaire certifié HDS. La certification vise l'hébergeur, pas l'infogéreur ni la configuration ; l'exploitation doit respecter ce périmètre, avec accord de sous-traitance RGPD et sauvegardes immuables. Voir le secteur santé.
- Finance et assurance : le règlement DORA impose un registre des prestataires tiers, des tests de résilience documentés et un plan de sortie testé. L'infogérance doit soutenir directement cette conformité. Voir le secteur finance.
- Éditeurs SaaS : la disponibilité de la plateforme conditionne le chiffre d'affaires. Une scale-up sans équipe d'exploitation délègue le Run de sa plateforme AWS et de ses clusters EKS pendant que l'équipe interne se concentre sur le produit. Voir le secteur SaaS.
Ces cas sectoriels, dans leur dimension d'exploitation managée de bout en bout, sont détaillés sur le pilier infogérance cloud entreprise. Le panorama de tous nos secteurs d'intervention complète cette vue.
Notre rôle : intermédiaire indépendant
Architecte Cloud est un intermédiaire indépendant. Nous ne réalisons pas nous-mêmes les prestations d'infogérance : nous cadrons votre besoin d'exploitation, clarifions le périmètre et les niveaux de service, puis nous vous mettons en relation avec des prestataires et experts qualifiés de notre réseau, sur Microsoft Azure et AWS. Ce sont eux qui exploitent, supervisent et sécurisent. Notre indépendance est votre garantie : nous n'avons pas de cloud propriétaire ni d'outil à vous vendre, donc nos recommandations n'ont aucun parti pris. Tout ce qui est construit et maintenu vous appartient (code Infrastructure as Code dans vos dépôts, comptes cloud à votre nom, documentation remise), et vous restez libre de reprendre la main à tout moment.
Les prestataires de notre réseau disposent des certifications requises (Azure Solutions Architect Expert, AWS DevOps Engineer Professional, CISSP, Azure Security Engineer, FinOps Certified Practitioner), sont partenaires Microsoft Azure (Solutions Partner for Infrastructure) et AWS (Advanced Tier Services), en démarche ISO 27001 et en lien avec la FinOps Foundation. 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, notre approche et le guide du cloud.
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, sans payer pour un service surdimensionné ni découvrir des angles morts après la signature.
Prêt à clarifier votre besoin d'exploitation ? Démarrez par notre diagnostic en ligne ou échangez directement avec un architecte via le formulaire de contact. Réponse sous 48 h ouvrées, sans engagement.
FAQ : Infogérance informatique
Qu'est-ce que l'infogérance informatique ?
L'infogérance informatique est la délégation contractuelle, à un prestataire spécialisé, de tout ou partie de l'exploitation d'un système d'information : serveurs, cloud, réseau, postes de travail, sécurité, sauvegardes et support aux utilisateurs. Le prestataire maintient les systèmes disponibles, corrige les incidents, applique les mises à jour et protège les données, contre des engagements de service mesurables (SLA). L'idée fondatrice est de recentrer l'entreprise sur son métier en confiant l'exploitation technique à des spécialistes, sans lui transférer sa responsabilité juridique sur les données.
Quelle est la différence entre infogérance classique et infogérance cloud ?
L'infogérance classique a été pensée pour des infrastructures que l'on possède (serveurs physiques, baie de stockage, hyperviseur) : on surveille du matériel et on gère un cycle de vie physique. L'infogérance cloud exploite des services élastiques sur Azure ou AWS : le matériel disparaît du périmètre client, l'exploitation devient logicielle (pilotée par API et en Infrastructure as Code) et les coûts deviennent variables et pilotables en continu (FinOps). La plupart des SI réels sont hybrides et exigent une infogérance capable d'opérer et de gouverner les deux mondes.
Que couvre un contrat d'infogérance informatique ?
Un périmètre large couvre sept domaines : les serveurs (physiques et virtuels), le cloud (Azure, AWS), le réseau (LAN/WAN, VPN, pare-feux), les postes de travail (parc, messagerie, gestion de flotte), la sécurité (vulnérabilités, durcissement, EDR), la sauvegarde et la continuité (PRA/PCA), et le support utilisateur (helpdesk N1/N2/N3). Tous ne sont pas systématiquement délégués : chaque domaine doit être explicitement inclus ou exclu dans le contrat, avec les zones grises nommées.
Quels sont les niveaux d'infogérance ?
Il existe trois niveaux de délégation. L'infogérance totale confie l'intégralité de l'exploitation au prestataire, pour les organisations sans équipe interne. L'infogérance partielle partage la charge par horaires (astreinte de nuit et week-end) ou par domaine, pour renforcer une équipe existante. L'infogérance sélective ne délègue que certaines briques (sécurité, FinOps, un cluster critique), pour les DSI matures qui veulent un appui ciblé. Beaucoup d'organisations démarrent en sélectif sur un pilote, puis élargissent progressivement.
Que signifient SLA, GTI et GTR dans un contrat d'infogérance ?
Le SLA (Service Level Agreement) définit les engagements de service mesurables : disponibilité visée en pourcentage, plages de couverture et pénalités. La GTI (garantie de temps d'intervention) est le délai entre la déclaration d'un incident et le début de sa prise en charge par un ingénieur. La GTR (garantie de temps de rétablissement) est le délai jusqu'au retour au service, souvent présentée comme un objectif visé car elle peut dépendre de tiers. Ces engagements se calibrent par niveau de criticité, application par application, et doivent être adossés à une astreinte humaine réelle.
Combien coûte l'infogérance informatique ?
À titre indicatif, un contrat d'infogérance informatique 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, parfois tarifé au poste (pour le support) ou à la ressource (pour le cloud). Ce budget est une fourchette indicative établie sur devis, après analyse du périmètre. La consommation cloud (facture Azure ou AWS) reste distincte et à votre nom. Comparé au coût complet d'une équipe interne en continu sur trois ans, l'infogérance est souvent plus économique et plus résiliente pour une PME ou une ETI.
Comment choisir son infogéreur ?
Évaluez neuf critères objectifs : l'indépendance (opè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é, une astreinte humaine réelle, les certifications de l'équipe, le périmètre du support (helpdesk, postes), le FinOps inclus, la conformité (RGPD art. 28, démarche ISO 27001, HDS/NIS2/DORA si concerné) et une gouvernance avec reporting exploitable. La transparence d'un prestataire sur ses limites est le meilleur révélateur de sa qualité.
Qui est responsable de la sécurité : le prestataire ou l'entreprise ?
Les deux, plus l'hyperscaler, selon le modèle de responsabilité partagée. Azure ou AWS sécurise le socle physique, l'hyperviseur et le réseau physique. L'infogéreur prend en charge la configuration, les correctifs, les accès et la surveillance des menaces sur le périmètre délégué. L'entreprise reste responsable de la classification de ses données, des décisions d'habilitation et de sa conformité : elle demeure responsable de traitement au sens du RGPD, l'infogéreur étant sous-traitant (article 28). La frontière exacte dépend du modèle de service (IaaS, PaaS, SaaS) et doit être formalisée par écrit.
L'infogérance informatique inclut-elle le support aux utilisateurs ?
Elle peut l'inclure, mais ce n'est pas automatique : le helpdesk doit être explicitement contractualisé. Le support s'organise en trois niveaux : N1 (réception et qualification des demandes, cas courants), N2 (diagnostic technique approfondi) et N3 (expertise pointue et intervention profonde). Le contrat doit préciser les plages de couverture, les canaux (téléphone, portail, courriel) et les délais de prise en charge par niveau de gravité. Ce support humain se distingue de la supervision technique, qui détecte les incidents avant même qu'un utilisateur ne les signale.
Comment éviter la dépendance à son infogéreur ?
En exigeant une réversibilité concrète dès la signature : l'Infrastructure as Code (Terraform, Bicep) versionnée dans vos dépôts, les comptes cloud à votre nom avec des accès délégués révocables, une documentation et un run-book remis régulièrement, et un plan de sortie écrit et idéalement 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 d'infogéreur reste un projet maîtrisable plutôt qu'un saut dans le vide. Le règlement DORA impose d'ailleurs cette réversibilité pour les prestataires critiques.
Infogérance ou hébergement : quelle différence ?
L'hébergement fournit la capacité : un datacenter ou un cloud public (Azure, AWS) où vos ressources s'exécutent. L'infogérance fait fonctionner ce qui tourne dessus : supervision, incidents, correctifs, sécurité, sauvegardes, support. Héberger sans infogérer signifie que vous gérez vous-même l'exploitation. Les deux sont complémentaires, pas équivalents. De même, l'infogérance se distingue de la TMA (tierce maintenance applicative), qui maintient le code de vos applications métier, là où l'infogérance maintient le socle technique sur lequel elles s'exécutent.
L'infogérance informatique convient-elle aux PME ?
Oui. L'infogérance permet justement aux PME, qui ne peuvent pas se permettre une astreinte interne en continu ni recruter des experts cloud rares, d'accéder à une exploitation professionnelle à coût maîtrisé. Le forfait mensuel transforme une charge imprévisible (recrutement, turnover, astreinte, formation) 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, à condition de choisir un prestataire indépendant qui préserve la propriété de votre infrastructure.