Pourquoi adopter une infrastructure cloud en entreprise ? Bénéfices et limites

Une infrastructure cloud permet d’accéder à des ressources informatiques sans acheter et exploiter soi-même tous les serveurs nécessaires. Elle peut aider une organisation à absorber des variations d’activité, à créer plus rapidement des environnements ou à faire évoluer ses services numériques. Elle n’est pourtant ni une garantie d’économies ni une assurance contre les interruptions.

Pour décider, mieux vaut partir d’un besoin concret, puis examiner chaque application plutôt que prévoir une migration générale par principe.

Les avantages du cloud pour une organisation

Le cloud donne accès à des ressources de calcul, de stockage et de réseau sous forme de services. Dans sa définition du cloud computing, le NIST retient notamment l’accès à la demande, l’élasticité et la mesure des ressources utilisées. Les fonctionnalités et les modalités de facturation varient selon les services et les fournisseurs.

Adapter la capacité à l’activité

Une application bien conçue peut disposer de ressources supplémentaires pendant un pic de fréquentation, puis en libérer lorsque la demande baisse. L’entreprise peut ainsi éviter de dimensionner en permanence son propre matériel pour le niveau maximal. Encore faut-il que l’application puisse évoluer de cette façon et que le modèle tarifaire soit adapté.

Accélérer les projets numériques

Les équipes peuvent créer des environnements de développement ou de test sans attendre l’achat et l’installation de serveurs physiques. Les plateformes et bases de données gérées transfèrent aussi une partie de la maintenance au fournisseur. En contrepartie, l’organisation peut disposer de moins de liberté de configuration et dépendre davantage des services choisis.

Mieux préparer la continuité d’activité

Le cloud offre des possibilités de sauvegarde et de déploiement dans des emplacements distincts. Mais la disponibilité dépend de l’architecture retenue. Il faut fixer un délai de reprise acceptable et une perte de données maximale tolérable, puis tester les procédures. Le guide de reprise après sinistre de Google Cloud présente ces deux objectifs. Une réplication ne remplace pas à elle seule une sauvegarde dont la restauration a été vérifiée.

Anticiper les coûts et la sécurité

La facturation à l’usage peut transformer une partie des dépenses initiales en charges récurrentes, sans pour autant réduire la facture totale. Comparez l’existant et plusieurs scénarios cloud, en tenant compte des périodes normales et des pics d’activité. Incluez la migration, le calcul, le stockage, les licences, l’assistance, la connectivité, les transferts de données et le temps des équipes. AWS recommande notamment de modéliser les transferts selon l’architecture et le volume d’utilisation.

Désignez un responsable du budget, identifiez les ressources par application ou par équipe et examinez régulièrement les dépenses et les capacités inutilisées. Le référentiel FinOps sur l’allocation des coûts propose des méthodes pour répartir les dépenses directes et partagées. Une alerte budgétaire ne bloque pas nécessairement les dépenses.

La sécurité exige également une répartition claire des tâches. Dans le modèle de responsabilité partagée d’AWS, le fournisseur protège l’infrastructure sous-jacente, tandis que les obligations du client dépendent du service utilisé. Pour une machine virtuelle, le client peut devoir corriger le système d’exploitation ; avec un service géré, la répartition change. Dans tous les cas, il faut préciser qui gère les accès, la configuration, les données et le suivi des incidents.

Quelle approche de migration choisir ?

Les services d’infrastructure offrent généralement davantage de contrôle ; les plateformes gérées réduisent certaines tâches d’exploitation. Une organisation peut aussi conserver une partie de ses systèmes existants et utiliser le cloud pour d’autres besoins. Cette approche hybride mérite d’être examinée lorsqu’une application dépend de matériel spécialisé, présente des contraintes de latence ou ne justifie pas encore le coût d’un transfert.

Application par application, les options comprennent un transfert avec peu de changements, une adaptation à des services gérés, une refonte, un remplacement, un maintien en l’état ou un retrait. Le guide de Microsoft sur les stratégies de migration relie ces choix aux objectifs de l’organisation. Avant de retenir un service géré, examinez aussi les conditions contractuelles, l’export des données et l’effort nécessaire pour changer de fournisseur.

Passer à l’action avec un projet pilote

1. Établir un point de référence. Recensez l’application, ses dépendances, son utilisation, ses coûts et ses performances. Précisez les exigences de sécurité et de localisation des données avec les parties concernées.
2. Délimiter le pilote. Choisissez une application avec un responsable identifié, un résultat attendu et des dépendances maîtrisables. Définissez l’architecture cible, le budget et les critères d’acceptation.
3. Préparer l’exploitation. Répartissez la gestion des accès, des journaux, des sauvegardes et de l’assistance. Prévoyez un retour arrière et testez la migration ainsi qu’une restauration avant la mise en production.
4. Mesurer avant d’étendre. Comparez coûts réels, délais de déploiement, performances et résultats des tests de reprise avec la situation initiale. Corrigez les écarts ; conservez ailleurs les applications pour lesquelles le transfert n’est pas justifié.

Le guide d’évaluation des charges de travail de Microsoft détaille notamment l’analyse des dépendances, des licences, des performances et des besoins de continuité.

Définir le rôle d’un partenaire technologique

Avant de lancer le projet, client et partenaire doivent s’accorder sur les livrables, les droits de décision, la propriété des comptes, les responsabilités de sécurité, la transmission des connaissances et l’assistance après déploiement. Les services d’Altweeb en conseil technologique, développement logiciel et renforcement d’équipes peuvent constituer des points de discussion pour une initiative numérique. Le périmètre et les responsabilités restent à définir pour chaque mission.

À retenir

Le cloud est pertinent lorsqu’il répond à un besoin mesurable de souplesse, de rapidité ou de continuité. Un pilote bien encadré permet de vérifier sa valeur réelle, sans imposer la migration de toutes les applications.

Pour approfondir ce sujet, découvrez aussi Conseil technologique et transformation digitale.