Le choix d'une architecture cloud se présente souvent comme une question technique. Il s'agit en réalité d'un arbitrage entre coût, contrôle et contraintes réglementaires. Voici comment le poser correctement.
La question nous est posée presque chaque semaine, généralement sous la forme suivante : faut-il tout migrer vers le cloud. La réponse honnête est qu'elle dépend de critères que peu d'entreprises examinent avant de décider, et que le mauvais choix se paie soit en facture mensuelle, soit en rigidité.
Clarifier les trois modèles
Le cloud public
Votre infrastructure fonctionne sur les serveurs d'un fournisseur mutualisé, AWS, Azure, Google Cloud ou OVHcloud. Vous payez à l'usage, vous ne gérez aucun matériel, et la capacité s'ajuste en quelques minutes.
Le cloud privé
Les serveurs vous sont dédiés, hébergés dans vos locaux ou chez un prestataire. Vous conservez le contrôle complet de l'environnement et de la localisation des données, avec en contrepartie un investissement initial et une charge d'administration.
Le cloud hybride
Une répartition entre les deux. Les données sensibles ou soumises à contrainte réglementaire restent sur l'infrastructure privée, tandis que les charges variables et les environnements de test s'exécutent sur le cloud public.
Les cinq critères qui décident réellement
1. La contrainte réglementaire
C'est le critère qui prime sur tous les autres, car il n'est pas négociable. Certaines catégories de données, notamment dans la santé, la banque et le secteur public, sont soumises à des obligations de localisation. Si vos données ne peuvent légalement pas quitter le territoire, le débat sur le coût devient secondaire.
Cette question se traite avant l'étude technique, pas après. Nous avons vu des projets de migration abandonnés à mi-parcours pour cette raison, après engagement de dépenses.
2. La nature de votre charge de travail
Une charge stable et prévisible, par exemple un ERP interne utilisé par cinquante personnes aux heures ouvrées, est généralement moins chère sur une infrastructure dédiée. Le cloud public facture une flexibilité que vous n'utilisez pas.
Inversement, une charge très variable, un site de e-commerce avec des pics saisonniers ou une application de traitement ponctuel, justifie pleinement le modèle à l'usage.
3. La latence et la connectivité
Ce point est déterminant dans le contexte algérien et souvent sous-estimé. Une application hébergée à Francfort ou en Irlande subit une latence perceptible depuis Alger, et surtout devient totalement indisponible en cas de coupure de votre lien internet.
Pour un système critique en temps réel, une caisse de point de vente, une gestion de production, un contrôle d'accès, cette dépendance représente un risque opérationnel réel. Un fonctionnement en mode dégradé local doit être prévu.
4. Le coût réel sur trois ans
La comparaison du prix mensuel affiché induit systématiquement en erreur. Il faut intégrer les éléments suivants pour obtenir une comparaison honnête.
- Les frais de sortie de données, qui peuvent être significatifs chez certains fournisseurs.
- Le coût des sauvegardes et de leur conservation dans la durée.
- Le temps d'administration interne, qui est un coût même s'il n'apparaît sur aucune facture.
- Le renouvellement du matériel dans le cas d'une infrastructure privée, généralement sur cinq ans.
- Les licences, dont le mode de facturation diffère parfois selon le mode d'hébergement.
5. Les compétences disponibles en interne
Une infrastructure privée exige quelqu'un capable de la maintenir, de la mettre à jour et d'intervenir en cas d'incident. Si cette compétence n'existe pas en interne et n'est pas externalisée par contrat, le cloud public transfère cette responsabilité au fournisseur. C'est un argument souvent décisif pour les structures de taille moyenne.
Une erreur fréquente. Migrer une application ancienne telle quelle vers le cloud public sans la réarchitecturer. Vous obtenez alors les inconvénients des deux modèles : la facture du cloud, sans le bénéfice de l'élasticité.
Recommandations par profil
- PME sans service informatique. Cloud public pour la messagerie et la bureautique, infrastructure locale simple pour les applications métier critiques qui doivent fonctionner même sans internet.
- Entreprise soumise à contrainte de localisation. Cloud privé pour les données concernées, cloud public pour tout le reste. C'est le cas d'usage type de l'hybride.
- Commerce avec forte saisonnalité. Cloud public, dont le modèle à l'usage correspond exactement au profil de charge.
- Industrie et production. Infrastructure locale pour le pilotage temps réel, cloud pour la consolidation, le reporting et la sauvegarde externalisée.
Une dernière question à poser
Avant tout engagement, demandez au fournisseur pressenti comment vous récupérerez vos données si vous décidez de partir dans deux ans, sous quel format, dans quel délai et à quel coût. La clarté de la réponse est un excellent indicateur de la qualité de la relation à venir.