Qui utilise le cloud computing ? Usages et choix de services

Le cloud computing est utilisé par les particuliers, les équipes métier, les développeurs, les services informatiques, les chercheurs, les établissements scolaires, les institutions publiques et les studios de création. Ils y accèdent par le réseau pour utiliser des logiciels, stocker des données, déployer des applications, traiter de l'information ou louer des ressources de calcul.

Un comptable utilisant une application en ligne et une chercheuse exécutant une simulation sont tous deux des utilisateurs du cloud. Leurs services et leurs responsabilités diffèrent. Pour choisir, il faut partir de la tâche à accomplir, du contrôle nécessaire et du travail que le fournisseur prendra en charge.

Les besoins expliquent mieux les usages que le secteur d'activité

Le secteur et la taille d'une organisation donnent du contexte, mais ne suffisent pas à définir ses besoins. Une petite équipe de développement peut exploiter une application complexe, tandis que le service financier d'un grand groupe a simplement besoin d'un logiciel comptable. Un administrateur hospitalier et un responsable dans le commerce peuvent rencontrer des problèmes de planification similaires, malgré des exigences différentes concernant les données et les validations.

Une même organisation peut utiliser plusieurs services cloud. Les employés partagent des documents, les développeurs déploient des applications, le service informatique configure des machines virtuelles et les analystes interrogent des bases de données. D'autres tâches restent sur des appareils locaux ou une infrastructure détenue en propre. L'adoption du cloud se décide généralement par besoin, plutôt que par un changement unique à l'échelle de l'organisation. Recenser les usages par équipe facilite l'examen de ces décisions.

Ce guide porte sur ces utilisateurs et leurs choix. Pour comprendre les raisons plus générales d'adopter un service, consultez notre article sur l'intérêt du cloud computing et ses limites.

Particuliers : applications, stockage cloud et sauvegarde

Les particuliers utilisent des applications cloud pour la messagerie, les calendriers, les documents partagés, les photos, la synchronisation de fichiers, les réunions en ligne et d'autres tâches courantes. Certains utilisent aussi des gestionnaires de mots de passe connectés ou des services multimédias. Ils accèdent généralement au logiciel ou au stockage sans administrer l’infrastructure sous-jacente.

Les décisions pratiques concernent le compte et les données. Pouvez-vous récupérer l'accès après la perte d'un téléphone ? Exporter vos fichiers dans un format exploitable ? Un lien partagé rend-il un dossier accessible à toute personne qui le reçoit ? Quelles fonctions restent disponibles sans connexion internet ?

Il faut aussi distinguer le stockage cloud de la sauvegarde. La synchronisation peut répercuter une suppression ou une modification indésirable sur plusieurs appareils. La récupération dépend des versions conservées, de la restauration des fichiers supprimés ou d'une sauvegarde distincte. Notre guide sur la synchronisation et la sauvegarde cloud explique cette différence.

Choix du service : une application prête à l'emploi ou un stockage géré convient généralement à ce besoin. Un serveur virtuel ne se justifie que si la personne souhaite exploiter elle-même un logiciel et peut en assurer la maintenance. Utiliser le cloud ne suppose pas d'en administrer l'infrastructure.

Équipes métier : le logiciel en tant que service

Les petites entreprises et les services non techniques utilisent le cloud pour la comptabilité, la relation client, la gestion de projet, l'assistance, les visioconférences, les boutiques en ligne et le partage de fichiers. Le logiciel en tant que service, ou SaaS, fournit une application existante sans demander à l'organisation de la développer et de l'héberger.

Le fournisseur exploite l'application et son infrastructure dans les conditions prévues par le service. L'entreprise décide toujours des accès, des informations importées, des intégrations activées et de la conservation des documents. Une personne doit retirer les comptes des employés qui partent, vérifier les liens partagés, maintenir les appareils connectés et organiser la récupération des comptes.

Prenons une petite agence qui utilise des outils distincts pour les projets, les factures et les fichiers. La comparaison utile porte sur leur adéquation au travail de l'agence et sur la circulation sûre des informations entre eux. Une plateforme plus étendue peut ajouter des coûts et de la configuration sans améliorer la tâche à accomplir.

Choix du service : examinez les fonctions, les contrôles d'administration, l'assistance, les possibilités d'export et le coût complet de l'abonnement. Même sans serveur à gérer, une petite équipe peut avoir besoin d'une aide technique extérieure. Pour les fichiers partagés, notre guide du stockage cloud multi-utilisateur présente les questions d'accès et de collaboration.

Développeurs : une plateforme cloud pour les applications

Les startups et les développeurs utilisent des ressources cloud pour héberger des sites et des API, créer des environnements de développement, automatiser les compilations et les tests, exécuter des tâches en arrière-plan et connecter leurs applications à des bases de données ou à du stockage objet. Leur travail consiste à déployer un logiciel qui fonctionne et dont ils peuvent surveiller, maintenir et restaurer le service.

Une plateforme applicative gérée peut prendre en charge les serveurs et l'environnement d'exécution dans les limites des fonctions qu'elle propose. Microsoft Azure App Service héberge, par exemple, des applications web, des services pour applications mobiles et des API REST. Le développeur reste responsable du code, des dépendances qu'il fournit, de la configuration, des identifiants et du comportement de l'application.

Les conteneurs permettent de regrouper une application et ses dépendances, mais le service d'hébergement détermine qui exploite les nœuds et l'orchestration. Les machines virtuelles donnent davantage de contrôle sur le système d'exploitation, avec plus d'administration. Une base de données gérée peut transférer une partie de la maintenance du moteur au fournisseur, tout en laissant le schéma et les performances des requêtes à l'équipe applicative.

Le serverless est une autre possibilité pour certaines tâches déclenchées par des événements. Amazon Web Services donne un exemple documenté de cette répartition. Le client n'est pas responsable du seul code : autorisations, dépendances, configuration des événements, gestion des erreurs et versions prises en charge restent à suivre. La documentation des environnements d'exécution d'AWS Lambda précise les obligations concernant le code et les dépendances, notamment la reconstruction et le redéploiement des images de conteneur lorsque des mises à jour sont nécessaires.

Choix du service : vérifiez les bibliothèques requises, les accès système, les données persistantes, le déploiement et le retour arrière, les journaux, le réseau et les limites de montée en charge. Une plateforme gérée convient lorsque ses contraintes correspondent à l'application. Les services d'infrastructure sont utiles lorsque le travail exige des contrôles qu'elle ne propose pas.

Services informatiques : infrastructure et reprise après sinistre

Les équipes informatiques utilisent le cloud pour les machines virtuelles, les réseaux, les identités, le stockage, la supervision, les environnements temporaires et les capacités de reprise. L'infrastructure en tant que service, ou IaaS, leur permet d'obtenir des ressources de calcul sans acheter le matériel physique ni construire leurs propres centres de données.

Ces équipes gèrent les liens entre les environnements cloud et les systèmes existants : connexion aux bureaux, accès aux applications, standards de configuration, correctifs, journaux et règles de déploiement. Dans un service de cloud public courant, le fournisseur exploite les centres de données physiques et certaines couches de plateforme. Le client exploite les ressources et les logiciels qui restent sous son contrôle.

Le guide de responsabilité partagée de Microsoft montre comment les tâches évoluent selon le modèle de service. Les clients doivent toujours gérer les données, les comptes et les appareils utilisés pour se connecter. Transférer davantage d'exploitation au fournisseur change le travail, sans supprimer le besoin d'un responsable.

La reprise après sinistre exige une conception précise. Un second emplacement ou un engagement de disponibilité du fournisseur ne prouve pas qu'une application pourra être restaurée après une suppression, une corruption ou une perte d'identifiants. Définissez les objectifs de reprise, identifiez les dépendances et testez la restauration complète. Notre article sur les tests de restauration explique comment vérifier que la récupération fonctionne.

Choix du service : évaluez le contrôle, l'intégration, la supervision, la reprise et les moyens d'exploitation de l'équipe. Un cloud privé est réservé à une organisation, mais peut être exploité par elle ou par un tiers. Associer un équipement local à une application cloud ne constitue pas automatiquement un cloud hybride au sens formel.

Équipes data, IA et recherche : traitement et capacité spécialisée

Les ingénieurs data, les analystes, les équipes d'apprentissage automatique et les chercheurs utilisent le cloud pour stocker des jeux de données, les transformer, les analyser, notamment à grande échelle si nécessaire, effectuer des simulations, travailler dans des notebooks, entraîner ou affiner des modèles et exécuter de l'inférence. Certains ont ponctuellement besoin de plus de puissance que leur matériel ne peut fournir. D'autres cherchent un service de données géré que plusieurs applications peuvent utiliser.

La première distinction porte sur l'exploitation d'un système ou l'utilisation d'une fonction gérée. Une équipe qui loue une instance administre les logiciels et l'environnement de sa charge de travail. Une équipe utilisant une base de données gérée a d'autres responsabilités. La documentation d'Amazon RDS distingue ainsi la maintenance de l'infrastructure et de la base des optimisations applicatives et des requêtes qui restent à la charge du client.

Un point d'accès à un modèle géré peut convenir à une équipe qui veut intégrer l'inférence sans maintenir la couche de service. Elle doit encore évaluer le comportement du modèle, protéger les identifiants, contrôler les données transmises, surveiller les réponses et gérer les erreurs applicatives. Exploiter son propre serveur de modèle sur une instance constitue une autre voie lorsqu'un contrôle plus étendu est utile.

Un GPU est pertinent lorsque le logiciel et le traitement en bénéficient. Le prétraitement, de petits modèles, l'orchestration ou certaines tâches d'inférence peuvent fonctionner sur CPU. Vérifiez la mémoire, la compatibilité logicielle, les transferts, la durée des traitements et les capacités réellement disponibles. Notre guide des machines virtuelles GPU explique dans quels cas ce contrôle est utile.

Choix du service : associez stockage objet, bases gérées, outils d'analyse, instances CPU ou GPU et points d'accès aux modèles à la tâche. Pour la recherche, consignez les versions logicielles, les données d'entrée et les paramètres afin de permettre la reproduction du travail. Conservez les résultats durables en dehors des ressources qui seront supprimées à la fin d'une expérience.

Équipes créatives : collaboration et production

Les équipes créatives utilisent des services cloud pour le partage de ressources, la validation, le rendu, le transcodage, le traitement vidéo et les outils génératifs compatibles. Un studio peut avoir besoin d'une capacité supplémentaire pour un projet court tout en continuant le montage sur des postes locaux.

La vitesse de traitement n'est qu'une partie du calcul. Il faut également préparer les fichiers, importer les ressources, installer des logiciels compatibles, obtenir les licences, vérifier les résultats et les télécharger. Un rendu plus rapide peut malgré tout allonger le délai total si les transferts et la préparation prennent trop de temps.

La collaboration et le calcul répondent à des besoins distincts. Un service de fichiers partagés doit offrir des autorisations, des versions ou un historique et des moyens de récupération utilisables. Une instance de rendu doit disposer de logiciels compatibles et de ressources suffisantes. Un même produit n'a pas nécessairement à fournir les deux.

Choix du service : testez une tâche représentative, de l'import au résultat exploitable. Comparez sa durée totale et son coût à ceux du matériel existant, stockage et transferts compris. Définissez qui détient les ressources et comment les collaborateurs conserveront leurs accès après le projet.

Écoles, institutions publiques et organismes de recherche

Ces organisations peuvent utiliser le cloud pour les plateformes pédagogiques, la collaboration, les sites publics, l'administration, la recherche et l'analyse de données. Au sein d'un même établissement, les exigences varient : un site d'information public et un jeu de données de recherche à accès restreint ne doivent pas être évalués comme un seul besoin.

Le choix peut dépendre des conditions d'achat, de l'accessibilité, de la sensibilité des données, de leur conservation, des traces d'audit, du financement et de l'accès à long terme. Ces critères comptent aussi dans le secteur privé. Les exigences pertinentes viennent de l'institution et du travail à réaliser, pas uniquement de sa catégorie.

Pour un projet de recherche limité dans le temps, prévoyez le devenir des comptes, logiciels, jeux de données et résultats après la fin du financement. Pour une plateforme pédagogique, vérifiez l'accès aux fonctions essentielles et l'export du travail des élèves et du personnel. Tenez compte des différences d'appareils et de connexion.

Choix du service : associez les responsables des achats, de l'accessibilité, de la sécurité et de la gouvernance des données avant de transférer des informations restreintes. Pour des données sensibles, la région choisie n'est qu'une caractéristique du service. Elle ne prouve pas que toutes les exigences contractuelles, d'accès, de conservation et juridiques sont satisfaites.

Grandes organisations : cloud public, cloud privé et règles communes

Les grandes organisations ou celles soumises à des obligations sectorielles peuvent combiner SaaS, cloud public, cloud privé et infrastructure propre. Un service utilisant un logiciel prêt à l'emploi n'a pas les mêmes besoins qu'une équipe exploitant un système transactionnel ou une plateforme de données. Les systèmes existants, la latence, la sensibilité des informations et les compétences d'exploitation orientent le choix.

L'utilisation de services de deux fournisseurs cloud ou plus est couramment appelée multicloud. Plusieurs fournisseurs peuvent donner accès à des fonctions différentes, mais ajoutent des contrats, des autorisations, des intégrations et des factures à gérer. Le multicloud ne crée pas à lui seul de résilience. Les applications et les données doivent être conçues et testées pour supporter les défaillances que l'organisation entend couvrir.

Le service informatique central peut définir des règles d'identité, de sécurité et d'achat, tandis que les équipes choisissent des services approuvés pour leur travail. La finance et les responsables produit ont besoin de visibilité sur la consommation et les résultats. Les principes de la FinOps Foundation soulignent la collaboration entre finance, technologie, produit et direction dans la gestion des dépenses technologiques.

Les outils de gestion des coûts, les budgets et les alertes rendent les dépenses visibles, mais quelqu'un doit agir. Une alerte budgétaire ne constitue pas automatiquement un plafond de dépenses. Attribuez un responsable aux abonnements récurrents et aux ressources qui restent actives après un projet.

Choix du service : sélectionnez un environnement par besoin et identifiez son responsable d'exploitation. Une migration cloud doit résoudre un problème défini. Tout regrouper chez un fournisseur, ou tout répartir entre plusieurs, n'est pas un objectif utile sans ce lien avec le travail à accomplir.

Consommateurs et fournisseurs cloud : les cinq rôles du NIST

L'architecture de référence du NIST distingue cinq acteurs :

• Consommateur : une personne ou une organisation utilisant un service cloud.
• Fournisseur : l'entité qui rend le service disponible.
• Courtier : un intermédiaire gérant l'utilisation, la fourniture ou les relations entre consommateurs et fournisseurs.
• Auditeur : un évaluateur indépendant des services cloud ou de leur exploitation.
• Transporteur : un intermédiaire assurant la connectivité et le transport entre fournisseur et consommateur.

Cet article concerne principalement les consommateurs. Ces rôles décrivent la participation à un service, sans constituer des catégories d'entreprises exclusives. Une organisation peut consommer l'infrastructure d'un fournisseur tout en proposant sa propre application à ses clients.

Modèles de services cloud : lequel correspond à chaque utilisateur ?

La définition du NIST distingue logiciel, plateforme et infrastructure en tant que service. Ces modèles décrivent ce que reçoit le client. Les modèles de déploiement concernent les publics servis et l'organisation des infrastructures. Des produits peuvent combiner plusieurs fonctions. Les comparaisons suivantes constituent des points de départ ; vérifiez ensuite les responsabilités propres au service choisi.

• Particulier ayant besoin de fichiers ou d'un logiciel : envisagez du stockage cloud ou du SaaS. L'utilisateur gère le compte, les données, le partage et les dispositions de récupération ; le fournisseur exploite le stockage ou l'application proposés.
• Équipe métier ayant besoin d'une application partagée : envisagez du SaaS. L'équipe gère les utilisateurs, paramètres, documents et intégrations ; le fournisseur exploite l'application et l'infrastructure couvertes par le service.
• Développeur déployant une application : envisagez une plateforme gérée, un service de conteneurs ou une instance. L'équipe est responsable du code, des dépendances, de la configuration et du comportement ; les tâches du fournisseur dépendent du modèle d'hébergement.
• Service informatique ayant besoin de contrôle système : envisagez de l'IaaS ou un cloud privé adapté. L'équipe gère son OS, ses applications, ses identités et sa configuration réseau ; le fournisseur exploite les couches d'infrastructure convenues.
• Équipe data stockant et traitant des données : envisagez stockage objet, base gérée, analyse ou calcul. L'équipe gère la qualité, les autorisations, les requêtes et le cycle de vie ; le fournisseur exploite les composants du service choisi.
• Équipe IA exécutant des modèles : envisagez une instance ou un point d'accès d'inférence géré. L'équipe gère le traitement ou l'intégration API, les données, les accès et l'évaluation ; le fournisseur fournit le matériel et, pour un service géré, la couche d'inférence.
• Équipe de recherche ou de création ayant un besoin temporaire : envisagez du calcul CPU ou GPU adapté. L'équipe gère les logiciels, les entrées, la validation et la conservation des résultats ; le fournisseur fournit l'environnement de calcul choisi.

Quand une tâche peut-elle se passer du cloud ?

Des systèmes locaux ou détenus en propre peuvent mieux convenir à une tâche limitée, lorsqu'un matériel adapté est déjà disponible ou qu'un fonctionnement fiable hors ligne est nécessaire. Une activité continue et prévisible peut aussi justifier une capacité propre, à condition d'intégrer le renouvellement du matériel, l'électricité, la maintenance et le travail des équipes.

Les transferts peuvent changer la réponse. Si un grand jeu de données évolue constamment sur un équipement local, le déplacer peut prendre plus de temps ou coûter plus cher que le traiter à proximité. Certaines tâches exigent un contrôle physique direct, une connectivité restreinte ou un matériel que les fournisseurs disponibles ne proposent pas.

Testez le bénéfice attendu avant de modifier l'organisation. Une équipe peut conserver des systèmes locaux pour une tâche et utiliser le cloud pour le stockage, la collaboration ou le calcul temporaire. Le cloud ne suppose pas l'abandon de toute infrastructure propre.

À quels utilisateurs techniques s'adresse Compute with Hivenet ?

Compute with Hivenet peut convenir aux développeurs, aux équipes data et IA, aux chercheurs et aux équipes créatives exécutant des traitements CPU ou GPU compatibles. Notebooks, API, prétraitement, expérimentation de modèles, tâches en arrière-plan et rendu en sont des exemples. Ce sont des possibilités d'utilisation, sans supposer que toutes ces équipes ont besoin d'une instance.

Les utilisateurs sélectionnent des ressources disponibles et un environnement, puis se connectent pour exécuter leurs logiciels. La documentation des VM et des conteneurs distingue les machines virtuelles offrant un contrôle système des modèles de conteneur sans accès root. Vérifiez quel environnement permet d'utiliser les paquets et les contrôles nécessaires.

Pour une équipe souhaitant un point d'accès à un modèle géré, Hivenet Inference API constitue une autre voie. Hivenet exploite la couche de service ; le client gère l'intégration, les identifiants, les requêtes, les données et l'évaluation des résultats. Ses réplicas dédiés sont facturés selon leur durée de fonctionnement. Il ne faut donc pas supposer un arrêt automatique sans requête ni une facturation limitée aux appels.

Choisissez selon le travail que votre équipe souhaite exploiter. Aucune de ces deux voies ne remplace un logiciel métier prêt à l'emploi lorsque le seul besoin est une application partagée.

Les questions à traiter pour chaque utilisateur du cloud

Avant d'adopter un service, précisez le travail qui reste à faire :

1. Que doit-il accomplir ? Définissez la tâche, les utilisateurs, les données, les performances et la disponibilité nécessaires.
2. Qui contrôle les accès ? Attribuez l'administration des comptes, les autorisations, les identifiants et le retrait des utilisateurs.
3. Que devons-nous maintenir ? Recensez les logiciels, paramètres, appareils et intégrations sous votre responsabilité.
4. Que se passe-t-il en cas de panne ? Testez la récupération et identifiez les fonctions essentielles pendant l'indisponibilité.
5. Quel est le coût complet ? Incluez abonnement ou durée de fonctionnement, stockage, transferts, assistance et exploitation.
6. Comment quitter le service ? Testez l'export des données, le remplacement des fonctions essentielles et les dispositions de fermeture du compte.

La sécurité et la confidentialité exigent des vérifications liées, mais différentes. Notre guide sur la sécurité et la confidentialité dans le cloud distingue la protection contre les accès non autorisés des décisions concernant l'utilisation des informations.

Questions fréquentes

Une personne utilisant seulement la messagerie en ligne est-elle un utilisateur du cloud ?

Oui. Utiliser une messagerie hébergée par un fournisseur revient à consommer un logiciel cloud. Il n'est pas nécessaire d'exploiter une machine virtuelle ni de connaître l'infrastructure physique du fournisseur.

Toute entreprise a-t-elle besoin d'infrastructure cloud ?

Non. Une entreprise peut utiliser des applications SaaS sans administrer d'infrastructure louée. Certains traitements peuvent aussi mieux fonctionner sur son matériel local existant. Évaluez chaque besoin séparément.

Qui gère les dépenses cloud ?

Le titulaire du compte paie la facture, mais une gestion utile demande souvent de la coopération. La finance a besoin de visibilité, les responsables de service expliquent les besoins et les équipes techniques identifient les ressources inutilisées ou les conceptions inefficaces. Attribuez cette responsabilité même pour quelques abonnements. Comparez les économies à leur effet sur la qualité de service et le travail d'exploitation, plutôt que de considérer une facture réduite comme une preuve suffisante de valeur.

Les équipes IA ont-elles toujours besoin de GPU ?

Non. Le modèle, le logiciel, la mémoire et les performances visées déterminent le matériel. Des CPU conviennent à certaines tâches. Un point d'accès géré peut également éviter de choisir ou d'exploiter directement le matériel d'inférence.

Le stockage cloud est-il distinct du cloud computing ?

Le stockage est l'une des fonctions du cloud. Une personne qui l'utilise reste un utilisateur de services cloud. Un besoin limité au stockage est aussi valable que la location de capacité de calcul.