Fournisseurs de services cloud : lequel choisir ?

Les fournisseurs de services cloud exploitent l'infrastructure ou les plateformes gérées auxquelles les clients accèdent par un réseau. Une comparaison utile commence par l'application : ce qui doit fonctionner, les lieux où ses données peuvent être traitées, les services dont elle dépend et le travail d'exploitation que votre équipe peut assumer.

Ce guide compare dix fournisseurs de cloud computing répartis en cinq catégories pratiques. AWS, Microsoft Azure, Google Cloud, Oracle Cloud Infrastructure, IBM Cloud, Alibaba Cloud, OVHcloud, DigitalOcean, CoreWeave et Hivenet proposent différentes façons d'exécuter des applications. Chaque profil présente les raisons de retenir un fournisseur dans une présélection et les conditions qui peuvent rendre une autre option plus adaptée. Il ne s'agit pas d'un classement chiffré.

Qu'est-ce qu'un fournisseur de services cloud ?

Un fournisseur de services cloud met à disposition, à la demande, des ressources de cloud computing ou une plateforme gérée. Le client demande des services par une console, une API ou une autre interface, tandis que le fournisseur exploite les couches d'infrastructure et de logiciel comprises dans l'offre.

La définition du cloud computing du NIST distingue l'infrastructure en tant que service, la plateforme en tant que service et le logiciel en tant que service. Cette comparaison porte sur les entreprises qui proposent une infrastructure cloud et des plateformes gérées. Une application prête à l'emploi, un cabinet de conseil et un fournisseur d'infrastructure correspondent à des achats différents.

Un prestataire de services gérés aide généralement son client à configurer, migrer ou exploiter des services, souvent sur le cloud d'une autre entreprise. Un revendeur commercialise l'accès à des produits tiers. Une entreprise peut jouer plusieurs de ces rôles. Il faut donc établir qui exploite le service sous-jacent, qui traite les incidents et avec quelle organisation le contrat est signé.

L'infrastructure cloud fonctionne toujours sur du matériel physique installé dans des centres de données. Le client peut la connecter aux systèmes qu'il exploite sur site. Dans un environnement hybride, la connectivité, les identités, la protection des données et les responsabilités d'exploitation doivent être cohérentes de part et d'autre.

Cloud public, cloud privé et cloud hybride décrivent des modes de déploiement. Ils ne permettent pas de classer simplement les entreprises : un même fournisseur peut proposer plusieurs modèles et laisser des responsabilités différentes au client dans chacun d'eux.

Les principales catégories de fournisseurs cloud

• Hyperscalers généralistes : AWS, Microsoft Azure et Google Cloud associent infrastructure et vastes catalogues de services gérés. Ils sont pertinents lorsqu'une application dépend de plusieurs services intégrés ou de plusieurs lieux de déploiement.
• Plateformes orientées entreprise : Oracle Cloud Infrastructure et IBM Cloud méritent d'être étudiés lorsque les logiciels existants, l'architecture, les accords de support ou les contraintes de migration influencent le choix.
• Fournisseurs présentant un intérêt géographique : OVHcloud peut entrer dans une évaluation d'infrastructures européennes, tandis qu'Alibaba Cloud propose une plateforme étendue avec des implantations en Chine et sur d'autres marchés. Aucun ne devrait être réduit à une simple étiquette régionale.
• Clouds orientés développeurs : DigitalOcean donne accès à des infrastructures applicatives courantes et à des services gérés. Vérifiez si ses produits couvrent les besoins réels de l'équipe.
• Spécialistes de l'IA et des GPU : CoreWeave et Hivenet proposent des options pour les tâches accélérées, avec des périmètres et des modes d'exploitation différents. Comparez un service précis plutôt que de considérer tous les spécialistes comme interchangeables.

Ces catégories se recoupent. DigitalOcean propose aussi des produits d'IA, et les hyperscalers fournissent également des GPU. Les catégories organisent une présélection ; elles ne remplacent pas la documentation actuelle du service. Notre guide du neocloud présente plus en détail cette catégorie d'infrastructure pour l'IA.

Comparer les fournisseurs de services cloud selon l'application

Posez les mêmes quatre questions à chaque fournisseur : son périmètre convient-il, que devrez-vous exploiter, comment fonctionnent le déploiement et la facturation, et qu'est-ce qui pourrait compliquer une migration ? Les exemples de produits ci-dessous proviennent des catalogues officiels. Les recommandations de présélection sont des appréciations éditoriales fondées sur ces capacités, pas les résultats d'un test comparatif de performances.

Amazon Web Services

Périmètre et usages : AWS est un hyperscaler généraliste à envisager lorsqu'une plateforme nécessite plusieurs types d'infrastructure et de services gérés. Cette étendue peut être utile à une application qui combine données transactionnelles, traitement d'événements, analytique et IA.

Services et exploitation : le catalogue AWS comprend le calcul EC2, le stockage objet S3, les bases RDS, les fonctions Lambda et Bedrock. Chaque produit possède son propre périmètre de gestion. Utiliser une base gérée ne rend pas un serveur applicatif EC2 distinct géré par le fournisseur.

Déploiement et coût : confirmez la disponibilité de tous les services dépendants dans la région choisie. Établissez une estimation qui réunit calcul, stockage, requêtes, réseau, support et éventuel engagement. Une région proposant la VM requise ne fournit pas nécessairement toutes les fonctions associées ou la capacité attendue.

Limites et sortie : les intégrations personnalisées avec des API gérées peuvent ajouter du travail de migration. Retenez AWS lorsque son catalogue résout des besoins d'intégration réels. Pour une petite VM ou une tâche GPU définie, comparez aussi une offre plus ciblée : la taille du catalogue ne suffit pas à justifier le choix.

Microsoft Azure

Périmètre et usages : Azure est un hyperscaler généraliste à considérer pour relier des applications cloud à un environnement Microsoft existant, ainsi que pour évaluer du calcul, des conteneurs, des données ou des services d'IA. Il ne se limite pas aux applications Windows.

Services et exploitation : le catalogue Azure comprend Virtual Machines, Azure Kubernetes Service, App Service, Azure SQL Database et Microsoft Foundry. Déterminez les couches applicatives que votre équipe souhaite exploiter avant de choisir entre une VM, une plateforme de conteneurs et un service applicatif géré.

Déploiement et coût : vérifiez la disponibilité régionale des produits et intégrez les licences, le réseau, la supervision et le support à l'estimation. Si une proposition suppose la réutilisation de licences ou un accord remisé, confirmez l'éligibilité et les conditions contractuelles au lieu de considérer l'économie comme acquise.

Limites et sortie : les intégrations d'identité, de déploiement et de données peuvent devenir des dépendances lors d'une migration. Retenez Azure lorsqu'elles apportent une utilité concrète. Les équipes Linux devraient appliquer les mêmes critères de service que les autres, plutôt que l'exclure en raison de l'histoire de Microsoft.

Google Cloud

Périmètre et usages : Google Cloud est une plateforme généraliste à envisager pour l'analytique, les applications conteneurisées et les traitements qui associent calcul et services de données gérés. Son adéquation dépend des produits retenus et des compétences d'exploitation de l'équipe.

Services et exploitation : le catalogue Google Cloud comprend Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud SQL, BigQuery et Dataflow. Ces produits couvrent les instances autogérées, l'exécution applicative gérée, les bases de données et les traitements analytiques.

Déploiement et coût : vérifiez la disponibilité régionale et les règles de placement sur tout le parcours des données. Estimez le traitement, le stockage, les requêtes et les transferts selon le modèle de facturation du produit. Le prix d'une requête d'entrepôt de données ou d'un pipeline géré ne se déduit pas du tarif horaire d'une VM.

Limites et sortie : une image de conteneur peut être portable sans que les intégrations d'identité, d'événements, de données et de déploiement le soient. Retenez Google Cloud lorsque ses services gérés correspondent à l'application. Testez l'exportation et le remplacement de ces dépendances avant de supposer qu'une migration ultérieure sera simple.

Oracle Cloud Infrastructure

Périmètre et usages : OCI est une option orientée entreprise à évaluer pour des parcs de bases de données et d'applications Oracle, ainsi que pour des besoins de calcul généraliste ou d'infrastructure spécialisée. Utiliser Oracle en fait un candidat, pas un gagnant automatique.

Services et exploitation : le catalogue cloud d'Oracle comprend des bases de données, des machines virtuelles, des serveurs physiques dédiés, des GPU, du calcul HPC, des conteneurs et du stockage. Comparez le service précis de base gérée ou de calcul à son équivalent ailleurs.

Déploiement et coût : confirmez les lieux où la configuration requise est proposée et ses connexions aux systèmes existants. Demandez une estimation détaillée des licences, options de base de données, ressources de calcul, stockage, transferts et support. Évitez les affirmations générales selon lesquelles tout transfert serait gratuit ou toute application Oracle moins chère sur OCI.

Limites et sortie : les fonctions de base de données, les licences et les outils d'exploitation peuvent déterminer le plan de sortie. Retenez OCI lorsque ces exigences d'entreprise comptent. Si l'application n'en dépend pas, comparez les fournisseurs sur la même tâche mesurée plutôt que de supposer qu'une étiquette « entreprise » apporte une valeur en soi.

IBM Cloud

Périmètre et usages : IBM Cloud est une plateforme orientée entreprise à envisager lorsque l'exploitation hybride, les systèmes IBM existants ou les pratiques de déploiement fondées sur Red Hat influencent le projet. Les exigences d'achat et de support peuvent peser autant que la configuration de calcul.

Services et exploitation : le portefeuille IBM Cloud comprend des infrastructures virtuelles et physiques dédiées, des services de conteneurs et des architectures de déploiement pour les entreprises. Les architectures publiées incluent des parcours Power Virtual Server et Red Hat OpenShift.

Déploiement et coût : confirmez la disponibilité du service, les configurations prises en charge et la connectivité dans le lieu retenu. Obtenez une estimation comprenant l'infrastructure, les droits logiciels, les opérations gérées et le support. Une architecture hybride doit aussi préciser les tâches qui restent liées aux systèmes propres du client.

Limites et sortie : l'architecture et les procédures propres à la plateforme nécessitent toujours un plan d'exportation ou de remplacement. Retenez IBM lorsque ses options répondent à une exigence documentée. Une petite application qui n'en a pas besoin devrait aussi considérer une configuration de service plus simple chez un autre fournisseur.

Alibaba Cloud

Périmètre et usages : Alibaba Cloud est une plateforme généraliste à étudier lorsque des utilisateurs ou des systèmes en Chine et sur d'autres marchés asiatiques occupent une place importante dans le déploiement. Ses implantations mondiales couvrent aussi des marchés hors d'Asie : le présenter comme un fournisseur exclusivement asiatique serait inexact.

Services et exploitation : son catalogue couvre le calcul, les bases de données, le stockage et les services d'IA. Elastic Compute Service fournit des instances de serveurs cloud avec plusieurs modes d'achat, dont le paiement à l'usage et l'abonnement.

Déploiement et coût : vérifiez la région précise, les modalités de compte et de contrat, la disponibilité des produits et le trajet réseau vers les utilisateurs. Incluez les frais d'instance, de disque, de bande passante et de support. Testez la latence et les transferts entre les lieux réellement utilisés par l'application.

Limites et sortie : les intégrations d'API et les choix régionaux demandent une préparation, comme chez les autres fournisseurs. Retenez Alibaba Cloud lorsque l'association de produits et d'implantations répond au besoin. Si la géographie est la raison principale, validez-la par un essai plutôt que de supposer un résultat identique pour tous les utilisateurs d'Asie-Pacifique.

OVHcloud

Périmètre et usages : OVHcloud est à inclure dans une évaluation d'infrastructures européennes et de services cloud reposant sur des technologies open source courantes. Une préférence géographique doit être confrontée au produit et au contrat précis.

Services et exploitation : le catalogue Public Cloud d'OVHcloud comprend du calcul, Kubernetes géré, du stockage, des bases de données et du réseau. Sa documentation décrit l'accès à l'API OpenStack pour automatiser l'infrastructure. Les produits gérés et les instances autogérées n'impliquent pas les mêmes responsabilités d'exploitation.

Déploiement et coût : établissez quels services et quelles configurations sont disponibles ensemble dans le lieu requis. Examinez les unités de facturation, le trafic inclus, les conditions de support et les frais optionnels du produit retenu. Une déclaration tarifaire générale ne remplace pas un devis couvrant l'application complète.

Limites et sortie : OpenStack et d'autres interfaces standard peuvent aider à automatiser et à migrer, sans rendre les configurations identiques d'un cloud à l'autre. Retenez OVHcloud lorsque ses services et son mode d'exploitation conviennent. La nationalité du fournisseur ne règle pas à elle seule les questions d'accès, de résidence ou de gouvernance des données.

DigitalOcean

Périmètre et usages : DigitalOcean est une option orientée développeurs pour les équipes qui construisent des sites web, des API et des applications autour d'infrastructures courantes et de services gérés. Il mérite une place dans la présélection lorsque l'équipe souhaite évaluer un ensemble relativement ciblé de modes de déploiement.

Services et exploitation : le catalogue DigitalOcean comprend Droplets, App Platform, Kubernetes, Managed Databases et le stockage objet Spaces, ainsi que des offres d'IA. Un Droplet laisse davantage d'administration système au client qu'une plateforme applicative gérée.

Déploiement et coût : vérifiez l'emplacement et les ressources disponibles pour chaque composant. Comparez l'offre de calcul, le stockage, les sauvegardes, les quotas de transfert, les dépassements et le support nécessaires au trafic prévu. Des formules familières ne sont utiles que si l'application respecte leurs limites.

Limites et sortie : vérifiez les moteurs de bases de données, les extensions, les contrôles d'entreprise et les intégrations, sans présumer la présence ou l'absence d'une fonction. Retenez DigitalOcean lorsque ses produits couvrent l'architecture. Étudiez d'autres options lorsqu'une capacité obligatoire ou une implantation ne peut pas être fournie par les services choisis.

CoreWeave

Périmètre et usages : CoreWeave est un spécialiste de l'infrastructure d'IA à évaluer pour l'entraînement, l'inférence et d'autres tâches fortement consommatrices de GPU. La comparaison doit inclure l'orchestration, le réseau et le stockage qui entourent les accélérateurs.

Services et exploitation : CoreWeave Kubernetes Service exécute Kubernetes géré sur des serveurs physiques CPU et GPU. Le client doit toujours comprendre ses responsabilités concernant les images, les données, les accès et le comportement applicatif. Un cluster géré ne prend pas en charge à sa place l'application de recherche ou de service de modèles.

Déploiement et coût : demandez la configuration d'accélérateurs, le lieu, les conditions de capacité et les détails d'interconnexion nécessaires. Comparez le cluster ou le traitement complet, stockage, réseau, capacité inutilisée et support compris, à une configuration équivalente.

Limites et sortie : la compatibilité Kubernetes ne supprime pas les dépendances de stockage, de réseau, d'ordonnancement ou d'exploitation. Retenez CoreWeave lorsque son infrastructure d'IA correspond à l'échelle et aux besoins techniques de la tâche. Pour une petite application généraliste, vérifiez que ce mode d'exploitation résout une difficulté réelle.

Hivenet

Périmètre et usages : Hivenet est un spécialiste à évaluer pour des besoins définis de GPU, de CPU, d'inférence et de stockage. Sa pertinence dépend de la correspondance entre un service précis et la tâche, plutôt que de l'étendue d'un catalogue d'hyperscaler.

Services et exploitation : Compute with Hivenet propose des VM et des conteneurs. Des services distincts comprennent une Inference API gérée et du stockage objet compatible S3. Private AI est un parcours de déploiement accompagné dont le périmètre fait l'objet d'un accord spécifique.

Déploiement et coût : vérifiez la configuration disponible et la capacité régionale. Compute fonctionne avec des crédits prépayés et une facturation à la seconde pendant l'exécution des instances ; l'inférence gérée repose sur une facturation de capacité par réplica. Chiffrez le service choisi et ses ressources associées plutôt que de comparer des unités incompatibles.

Limites et sortie : testez les interfaces prises en charge, l'exportation, le cycle de vie et la reprise. Retenez Hivenet lorsque ces services ciblés répondent au besoin. Confirmez les alternatives si vous avez besoin d'une base gérée précise, d'une plateforme serverless ou d'un catalogue d'entreprise plus large : l'accès à une instance de calcul ne prouve pas leur disponibilité.

Comment choisir un fournisseur de services cloud

Définissez une stratégie cloud avant de comparer les noms

Pour évaluer les fournisseurs, décrivez l'application, les types de services nécessaires, l'utilisation prévue, les lieux acceptables, les besoins de reprise et les compétences de l'équipe. Séparez les exigences obligatoires des préférences. Un fournisseur incapable de satisfaire une exigence obligatoire ne devrait pas rester dans la présélection grâce à un prix attractif sur un autre poste.

Une API de production peut, par exemple, nécessiter un moteur de base pris en charge, une connectivité privée, une procédure de reprise définie et un accord de support adapté. Un traitement de rendu par lots peut surtout dépendre de la mémoire GPU, des licences logicielles, du stockage des résultats et de la rapidité de libération des ressources après exécution.

Comparez les tâches d'exploitation et les responsabilités

Attribuez les responsabilités pour les identités, les systèmes d'exploitation, les mises à jour, le déploiement, la supervision, les sauvegardes, la restauration et les incidents. Le modèle de responsabilité partagée varie selon le service : acheter de l'IaaS, du PaaS ou du SaaS transfère des parties différentes du travail au fournisseur.

Un plan de contrôle géré ne signifie pas que l'application l'est aussi. Examinez les contrôles de sécurité et les preuves pour le service et la configuration réels. Des références commerciales aux certifications, à la résilience ou aux secteurs réglementés ne démontrent pas que chaque déploiement répond à vos exigences.

Vérifiez la sécurité, le stockage des données et la disponibilité

Confirmez les lieux où se trouvent les données principales, les réplicas, les sauvegardes, les journaux et les services connectés. Vérifiez aussi qui peut accéder à l'environnement et comment fonctionne le support. Un sélecteur de région ne répond qu'à une partie de la question, comme l'explique notre guide sur les lieux de stockage du cloud.

Distinguez la présence au catalogue de la capacité accessible à votre compte. Une famille d'instances annoncée peut être soumise à des quotas ou à des limites d'allocation. Demandez comment la capacité s'obtient, si un engagement la réserve et ce qui se passe après l'arrêt ou le remplacement d'une instance.

Estimez les coûts cloud complets

Utilisez le même profil de demande, la même configuration, les mêmes hypothèses de système d'exploitation, les mêmes contraintes géographiques et la même période pour chaque candidat. Incluez calcul, stockage, requêtes, réseau, transferts, sauvegardes, supervision, licences, support et temps de travail technique.

Confrontez ensuite l'estimation à une demande habituelle, à une période chargée et à une reprise après panne. Les remises liées à un engagement ou à une capacité interruptible ont des conditions différentes. Consignez-les. Un faible tarif horaire ne prédit pas de façon fiable le coût d'une inférence réussie, d'un traitement terminé ou d'un mois d'exploitation.

Testez la reprise après sinistre et la migration cloud

Confiez à quelques candidats la même tâche représentative. Relevez l'effort de préparation, le débit utile, la latence, les erreurs et la facture obtenue. Testez la restauration ou le redémarrage, en plus de l'exécution réussie.

Lisez les accords de niveau de service pour le produit, la région et la configuration précis. Vérifiez la période de mesure, les exclusions, les compensations et les obligations du client. Un engagement de disponibilité ne décrit pas toutes les étapes nécessaires à la récupération de votre application ou de vos données.

Exportez les données et la configuration nécessaires pour partir. Identifiez les dépendances aux API propriétaires, aux fonctions de bases de données, aux identités et aux outils de déploiement. Demandez les horaires de support, les engagements de réponse, les procédures d'escalade et les conditions de retrait des services. Pour le calcul, utilisez la liste de cinq questions à poser au fournisseur.

Hyperscaler ou fournisseur cloud spécialisé ?

Un fournisseur généraliste peut convenir lorsque plusieurs services gérés doivent fonctionner ensemble et que l'équipe bénéficie de leur intégration. Un spécialiste peut convenir lorsqu'une tâche définie exige un matériel, un environnement de service de modèles ou un mode d'exploitation qu'il fournit.

Comparez des achats équivalents. Une instance GPU, un point d'accès à un modèle géré et une plateforme d'IA complète n'incluent pas le même travail. Comparez le matériel au matériel, l'inférence gérée à l'inférence gérée, et l'ensemble des responsabilités dans chaque cas. Le nombre de services et la taille de l'entreprise ne répondent pas à cette question.

La présentation de l'infrastructure distribuée de Hivenet éclaire la conception de ses produits. La distribution ne prouve pas à elle seule un prix inférieur, une meilleure fiabilité ou un résultat de sécurité précis. Appliquez à Hivenet les mêmes exigences de preuve qu'aux autres candidats.

Quand utiliser plusieurs fournisseurs cloud

Utiliser un fournisseur pour une plateforme applicative et un autre pour une tâche spécialisée peut être raisonnable si l'ensemble satisfait les exigences. Chiffrez les connexions entre eux, notamment les transferts, l'intégration des identités, la supervision, les passages de relais opérationnels et le support.

Plusieurs fournisseurs ne créent pas automatiquement de la redondance. Si le second ne peut pas reprendre le service requis, ou si les deux parcours dépendent du même stockage, l'application peut toujours s'arrêter lors d'une panne. Une reprise entre fournisseurs exige une architecture explicite et une procédure testée.

Le multicloud ne supprime pas non plus la dépendance aux fournisseurs. Il peut créer plusieurs ensembles de dépendances. Retenez-le lorsqu'un bénéfice mesurable justifie le travail d'exploitation supplémentaire, et désignez un responsable de l'ensemble du système.

Questions fréquentes

Quel est le meilleur fournisseur cloud ?

Il n'existe pas de réponse universelle. Pour un projet précis, le meilleur candidat satisfait les exigences obligatoires de service, de localisation, de sécurité, de reprise et de support, puis obtient des résultats acceptables lors d'un essai représentatif. Un fournisseur adapté à une plateforme d'entreprise peut être superflu pour un petit traitement par lots.

Quel fournisseur cloud coûte le moins cher ?

Comparez la facture complète selon les mêmes hypothèses. Incluez les ressources inactives, les transferts, les engagements et le travail de votre équipe. Les tarifs publiés aident à construire l'estimation ; ils ne permettent pas de désigner un fournisseur universellement moins cher.

Un fournisseur européen garantit-il la souveraineté des données ?

Non. Examinez l'entité contractante, le périmètre du service, la localisation de l'infrastructure, les modalités d'accès, les sous-traitants, les contrôles techniques et les engagements applicables. La propriété ou l'emplacement peuvent constituer des éléments pertinents, sans régler seuls toute la question.

Un spécialiste peut-il remplacer un hyperscaler ?

Il peut remplacer un service précis lorsque les exigences correspondent. Remplacer une plateforme entière est un autre projet, surtout si les applications dépendent de bases gérées, d'identités, d'analytique, de messagerie ou d'autres services intégrés.

Combien de fournisseurs conserver dans la présélection finale ?

Deux ou trois candidats qui satisfont déjà les exigences obligatoires constituent un point de départ pratique. Cela permet de mener un essai réaliste. Élargissez la liste si aucun ne convient, plutôt que de consacrer le même effort à des fournisseurs manifestement inadaptés.