9 usages du cloud et comment choisir le bon service

Le cloud sert notamment à héberger des sites, tester des logiciels, stocker des fichiers, utiliser des applications métier, analyser des données, entraîner des modèles d'IA, produire des prédictions, effectuer des calculs intensifs et rétablir des systèmes après une panne. Chaque usage nécessite une combinaison différente de ressources, de logiciels et de responsabilités d'exploitation.

Une équipe qui cherche un calendrier partagé devrait généralement comparer des applications prêtes à l'emploi. Un développeur qui déploie sa propre API peut avoir besoin d'une plateforme applicative gérée ou d'une machine virtuelle. Louer un GPU ne répond à aucun de ces besoins si le logiciel n'en utilise pas.

Ce guide compare neuf usages du cloud selon le travail à effectuer, le type de service, l'intérêt attendu et la principale contrainte. Il précise aussi les cas auxquels Hivenet peut répondre, ceux pour lesquels il fournit une partie de la solution et ceux qui nécessitent un autre service.

Choisir le type de service avant le fournisseur cloud

La définition du cloud computing du NIST distingue trois modèles. L'infrastructure en tant que service (IaaS) fournit des ressources de calcul et de stockage ; le client gère ses systèmes d'exploitation et ses applications. La plateforme en tant que service (PaaS) propose un environnement géré pour déployer des applications. Le logiciel en tant que service (SaaS) fournit une application directement utilisable.

Ces catégories décrivent le partage des responsabilités, pas l'objectif du projet. Un site peut être hébergé sur une infrastructure IaaS ou une plateforme PaaS, tandis qu'un outil de création de sites constitue un service logiciel prêt à l'emploi. Vérifiez le contrat : la maintenance des bases de données, les sauvegardes, la surveillance, l'assistance et la sécurité applicative peuvent relever de parties différentes.

Le cloud public, le cloud privé et le cloud hybride décrivent des modes de déploiement. Ils ne précisent pas si un service permet de modifier des documents, d'exécuter un modèle ou de stocker des données. Une salle de serveurs privée n'est pas automatiquement un cloud privé, et utiliser plusieurs clouds ne rend pas une application portable par défaut.

Les indications concernant Hivenet évaluent l'adéquation au besoin, sans établir un classement de performances. Adapté signifie qu'un service pertinent existe, sous réserve de capacité disponible et de tests. Partiellement adapté signifie que Hivenet peut fournir certaines ressources, avec des outils ou services complémentaires. Hors de l'offre actuelle de Hivenet signifie que le service complet décrit ici ne fait pas partie de ses produits actuels.

1. Héberger des sites, des applications et des API

L'hébergement fournit à une application un environnement d'exécution et un accès réseau pour ses utilisateurs. Il peut s'agir d'une boutique en ligne, d'un portail client, du service qui alimente une application mobile ou d'une API appelée par d'autres logiciels. Un petit site et une application transactionnelle très sollicitée peuvent avoir des besoins très différents en mémoire, en performances de base de données et en disponibilité.

Les choix courants sont les machines virtuelles, les plateformes applicatives gérées et les services de création de sites. Une infrastructure cloud peut faciliter l'ajout de capacité sans acheter de serveurs physiques. L'application ne passe pas pour autant automatiquement à l'échelle : sa base de données, ses sessions, son déploiement et sa répartition du trafic doivent supporter la charge prévue.

Un développeur qui sait administrer un serveur peut apprécier une instance IaaS. Une petite équipe sans cette compétence peut préférer un PaaS ou un outil de création de sites hébergé. Une infrastructure locale existante peut rester pertinente pour une application interne dont la demande est stable, avec une assistance adaptée et sans accès public nécessaire. Comparez le coût d'exploitation complet, y compris la maintenance et les conséquences d'une indisponibilité.

Hivenet : adapté à l'hébergement géré par le client.Compute with Hivenet fournit des instances CPU et GPU. Les services web ordinaires nécessitent généralement des ressources CPU ; le client continue à exploiter ses logiciels. Un outil complet de création de sites ou un PaaS géré n'est pas inclus.

2. Développer et tester des logiciels

Les environnements cloud permettent de créer des espaces séparés pour développer un logiciel, reproduire une erreur, tester une mise à jour ou exécuter une tâche d'intégration continue. Une équipe peut, par exemple, créer une base de test isolée pour une version candidate, effectuer ses vérifications, conserver les résultats puis supprimer l'environnement.

Cet usage est intéressant lorsque la demande est intermittente ou que plusieurs personnes ont besoin d'environnements comparables. Une configuration reproductible compte davantage que la seule vitesse de création d'un serveur. Consignez les versions des dépendances, gardez les secrets hors des images et utilisez des données de test synthétiques ou correctement protégées. Copier les données clients de production sur chaque instance de test crée une exposition inutile.

Les plateformes de développement gérées réduisent la préparation ; les machines virtuelles administrées par l'équipe donnent davantage de contrôle sur les outils. Le développement local reste utile pour obtenir un retour rapide, travailler hors ligne ou utiliser du matériel spécialisé. Prévoyez le nettoyage des ressources : des instances oubliées et du stockage conservé peuvent continuer à être facturés.

Hivenet : adapté aux environnements de test administrés par l'équipe. Le guide de démarrage de Compute couvre les conteneurs et les machines virtuelles. Choisissez un matériel et une image compatibles, puis gérez les outils, les accès et le cycle de vie des ressources. Il s'agit d'une infrastructure de développement, plutôt que d'un service CI/CD entièrement géré.

3. Stocker et sauvegarder des données

Le stockage cloud peut accueillir les fichiers envoyés à une application, des jeux de données de recherche, des médias, des archives et des sauvegardes. Le premier choix concerne l'accès aux données. Une application de fichiers aide les personnes à parcourir des dossiers et à partager des documents. Le stockage objet permet aux logiciels d'accéder aux objets par une API. Le disque d'une instance en cours d'exécution remplit encore une autre fonction.

Un studio de design peut conserver ses fichiers de travail localement et copier ses projets terminés vers un stockage distant. Une application peut envoyer des images directement dans un stockage objet. Aucune de ces configurations ne prouve que les données seront récupérables : une synchronisation peut propager des suppressions, et une copie accessible avec les mêmes identifiants compromis peut aussi être menacée.

Pour une sauvegarde, définissez les données copiées, la fréquence, la durée de conservation des versions, les droits de suppression et les tests de restauration. Vérifiez que le service choisi prend en charge les fonctions de conservation ou d'immutabilité nécessaires ; la compatibilité S3 n'implique pas toutes les fonctionnalités de S3. Le stockage local peut mieux convenir à des accès aléatoires intensifs ou à une connexion Internet peu fiable, avec une copie distante séparée lorsque c'est pertinent.

Hivenet : adapté au flux de stockage approprié.Hivenet Object Storage prend en charge les usages compatibles S3. Store with Hivenet sert aux fichiers du quotidien et à la sauvegarde de photos. Send with Hivenet sert au transfert temporaire. Ces produits se distinguent du disque de travail d'une instance Compute ; aucun ne remplace à lui seul un plan de sauvegarde testé.

4. Utiliser des logiciels métier et collaborer

La messagerie, les calendriers partagés, la gestion de la relation client, la comptabilité, les réunions vidéo et l'édition collaborative sont des usages courants du cloud. Les utilisateurs accèdent aux logiciels dans un navigateur ou une application installée, tandis que le fournisseur exploite le service et l'infrastructure sous-jacente.

Le SaaS peut réduire le travail d'installation et de maintenance d'un logiciel sur les serveurs de l'entreprise. Il implique aussi des décisions concernant les comptes, les droits, les intégrations, l'export des données et les abonnements. Le client doit toujours désigner une personne chargée de retirer les accès des anciens employés, d'examiner les partages externes et de vérifier les possibilités de récupération ou d'export.

Pour une petite organisation, choisir un service prêt à l'emploi est généralement plus pratique que construire une plateforme de messagerie ou de comptabilité sur une infrastructure louée. Une application locale peut toutefois convenir à une équipe qui a besoin d'un accès hors ligne ou d'une intégration particulière. Testez le travail réel avec les utilisateurs, y compris leurs besoins d'accessibilité et les connexions faibles, avant de migrer.

Hivenet : hors de l'offre actuelle pour une suite complète de logiciels métier. Le stockage et le transfert de fichiers peuvent soutenir la collaboration, mais ne constituent pas une messagerie hébergée, un CRM, un outil de coédition bureautique ou un service comptable. Héberger soi-même un logiciel tiers implique d'autres responsabilités d'exploitation.

5. Traiter et analyser des données

Les organisations utilisent le cloud pour nettoyer des enregistrements, réunir des jeux de données, produire des rapports et traiter des événements. Une analyse nocturne des ventes peut tenir sur une seule instance CPU. L'analyse de données à grande échelle peut nécessiter un traitement distribué, un entrepôt de données ou une plateforme gérée avec planification et contrôle des accès.

L'intérêt est de choisir les ressources selon le traitement, au lieu de dimensionner chaque poste de travail pour l'analyse la plus exigeante. Un traitement périodique peut, par exemple, utiliser de la capacité supplémentaire pendant son exécution. Le transfert des données, leur validation et le retour des résultats prennent néanmoins du temps ; la puissance de calcul n'est qu'une partie du travail.

Gardez le calcul à proximité des grands jeux de données lorsque la durée des transferts, la bande passante ou les frais risquent de dominer. Un tableur ou une base locale peut être plus simple pour un volume modeste. Avant d'introduire un moteur distribué, mesurez la limite actuelle et vérifiez que le travail peut être réparti efficacement.

Hivenet : partiellement adapté. Compute et le stockage objet peuvent contribuer à une chaîne d'analyse exploitée par le client. Leur location n'inclut pas automatiquement un entrepôt de données géré, un service Spark géré, un catalogue ou une application décisionnelle. Ces responsabilités supplémentaires comptent dans la comparaison avec une plateforme cloud gérée.

6. Entraîner des modèles d'IA et expérimenter

L'entraînement ajuste un modèle à partir de données. L'expérimentation comprend la préparation des jeux de données, la comparaison des configurations, l'évaluation des résultats et parfois l'ajustement d'un modèle existant. Un chercheur peut louer un GPU pour une expérience limitée plutôt qu'acheter du matériel utilisé occasionnellement. D'autres tâches d'apprentissage automatique fonctionnent correctement sur CPU.

Choisissez les ressources selon le logiciel et le modèle. La mémoire GPU, les formats numériques pris en charge, la mémoire système, les débits de stockage et la compatibilité des bibliothèques peuvent compter autant que le nom du GPU. Vérifiez que le traitement complet tient dans les ressources disponibles, avec l'état d'entraînement et les points de sauvegarde, au lieu de comparer uniquement la taille du fichier du modèle à la mémoire.

Le calcul cloud est utile lorsque le matériel spécialisé manque localement ou que la demande varie beaucoup. Un poste local fortement utilisé peut rester économique, surtout si les données sont déjà à proximité. Comparez le coût d'une expérience terminée, avec la préparation, les exécutions échouées, les transferts et la conservation des résultats. Ajouter du matériel ne corrige pas des données médiocres ou une méthode d'évaluation inadaptée.

Hivenet : adapté aux expériences compatibles administrées par le client. Les instances CPU ou GPU disponibles peuvent exécuter les outils d'entraînement appropriés. Validez la capacité avant de vous engager ; le service ne doit pas être présenté comme une plateforme d'entraînement distribué gérée ou comme une solution adaptée à toutes les tailles de modèles.

7. Exécuter l'inférence IA

L'inférence utilise un modèle déjà entraîné pour produire un résultat : classer un document, générer une image, recommander un contenu ou répondre avec un modèle de langage. Ses exigences diffèrent de celles de l'entraînement. Le temps de réponse, le volume de requêtes, les accès simultanés, la qualité du modèle et la disponibilité orientent souvent le choix.

Un service d'inférence géré peut réduire la maintenance du moteur d'exécution. L'auto-hébergement donne davantage de contrôle sur les poids du modèle, les bibliothèques et les réglages, mais laisse le déploiement et l'exploitation au client. Les deux approches nécessitent toujours des contrôles d'accès applicatifs, un traitement approprié des données d'entrée et une évaluation des résultats.

Mesurez une activité représentative, avec les périodes creuses et les pointes de trafic. La facturation peut dépendre des requêtes, des tokens, des instances actives ou de la capacité réservée ; ces modèles ne sont pas équivalents. Un endpoint dédié peut coûter de l'argent tant qu'il fonctionne, même sans requêtes. Une exécution locale peut mieux convenir au travail hors ligne, à une réponse immédiate sur l'appareil ou à un petit modèle compatible avec le matériel existant.

Hivenet : adapté lorsque le modèle et la capacité correspondent au besoin. L'API d'inférence Hivenet propose des endpoints gérés et compatibles OpenAI pour les modèles pris en charge. Elle facture la durée d'exécution de la capacité dédiée des réplicas, plutôt qu'un tarif universel au token. Compute permet aux clients d'exploiter leur propre moteur ou des poids personnalisés.

8. Effectuer du HPC, du rendu et des traitements par lots

Les simulations scientifiques, les calculs d'ingénierie, le rendu d'images et les grands ensembles de tâches indépendantes peuvent dépasser la puissance d'un poste de travail. Des ressources cloud peuvent aider à respecter une échéance ou à absorber une activité temporaire sans acheter du matériel dimensionné pour la pointe.

La distinction entre un calcul fortement couplé et de nombreux travaux indépendants est essentielle. Un projet de rendu peut être réparti en images calculées séparément. Une simulation qui échange fréquemment des données entre les nœuds peut dépendre d'une interconnexion particulière, de sa latence et d'un système de fichiers parallèle. Ajouter des serveurs distants ordinaires ne crée pas automatiquement un cluster HPC adapté.

Vérifiez les licences, la prise en charge des CPU ou GPU, la mémoire, les performances d'entrée-sortie et la durée des transferts de résultats. Comparez le temps d'achèvement et le coût total du travail. Un cluster local existant peut rester préférable pour une utilisation soutenue ou un réseau spécialisé. Le guide de simulation HPC explique l'effet de ces dépendances sur les performances.

Hivenet : partiellement adapté. Les calculs compatibles avec une seule instance et les lots faiblement couplés peuvent utiliser les ressources Compute disponibles. La présence d'un ordonnanceur géré, d'un stockage parallèle, d'une interconnexion spécialisée ou d'un environnement HPC complet ne doit pas être supposée. Validez ces exigences séparément avant de choisir le service.

9. Préparer la reprise après sinistre et la continuité d'activité

La reprise après sinistre rétablit un système informatique après une perturbation grave. Le stockage cloud peut conserver des copies hors site, et le calcul cloud fournir un environnement pour reconstruire une application. La continuité d'activité couvre aussi les personnes, la communication, les dépendances et la poursuite des tâches essentielles pendant l'interruption.

Définissez le RPO, soit la perte de données maximale acceptable exprimée en durée, et le RTO, soit le délai cible de rétablissement du service. Une sauvegarde quotidienne ne permet pas de promettre une reprise avec seulement quelques minutes de modifications perdues. Maintenir une réplique active peut raccourcir la reprise, mais augmente le coût et ne protège pas de toutes les défaillances communes.

Sauvegardez les données et configurations nécessaires, protégez les accès de secours et testez la restauration complète. Les recommandations AWS sur la reprise après sinistre relient les objectifs, la stratégie et les tests. Une seconde copie n'est utile que si elle reste accessible et exploitable pendant l'incident envisagé.

Hivenet : partiellement adapté. Le stockage et le calcul peuvent contribuer à un plan de reprise conçu par le client. Leur utilisation ne prouve pas l'existence d'une reprise entièrement gérée, d'un basculement automatique, de domaines de défaillance indépendants ou d'un délai de reprise garanti. Pour certains systèmes, un second site local ou un service spécialisé répondra mieux aux objectifs.

Cinq questions pour choisir les bons services cloud

1. Cherchez-vous une application prête à l'emploi ou une infrastructure ? Pour un besoin métier courant, commencez par le SaaS. Pour déployer votre logiciel, comparez un PaaS à une infrastructure administrée par votre équipe.
2. La demande varie-t-elle ? Distinguez les pointes occasionnelles d'une utilisation régulière. Vérifiez la capacité disponible, les quotas, les frais minimums et les ressources qui restent facturées après l'arrêt du travail.
3. Quelles ressources faut-il au traitement ? Mesurez les besoins en CPU, mémoire GPU, mémoire système, stockage, réseau et base de données. Choisissez la plus petite configuration qui répond à l'objectif réel, puis testez-la.
4. Qui assurera l'exploitation ? Attribuez la responsabilité des mises à jour, des identifiants, de la surveillance, des sauvegardes, des incidents et de l'assistance. Une instance peu chère peut coûter cher si personne n'a le temps de la maintenir.
5. Pouvez-vous gérer les données et quitter le service ? Examinez les exigences de localisation, les accès, les formats d'export, les coûts de transfert et la restauration. Testez une migration avec des données représentatives avant qu'elle devienne urgente.

Un cas d'usage décrit le travail à effectuer ; un avantage explique pourquoi une configuration pourrait l'améliorer. Une capacité flexible peut aider lors d'une expérience courte, tandis qu'un serveur existant peut convenir à une demande stable. Le choix dépend de la situation concrète, pas du seul fait d'utiliser le cloud.

Pour un premier déploiement, choisissez un traitement bien délimité et définissez ce qu'un essai réussi doit démontrer. Consignez les conditions de départ, le délai, la fiabilité, le travail d'exploitation et la facture complète. Ces éléments sont plus utiles que de supposer que tous les usages du cloud donneront le même résultat.