Hébergement cloud en Algérie: les questions que chaque entreprise doit poser

Décrire la charge de travail avant de comparer les fournisseurs

La due diligence commence par le système à héberger. Une vitrine publique, un ERP, un service de paiement et un outil d’analyse n’ont ni les mêmes données, ni le même niveau de disponibilité, ni la même tolérance à la latence. Sans ce contexte, les réponses commerciales ne peuvent pas être comparées objectivement.

Documentez les utilisateurs, les volumes actuels et projetés, les heures critiques, les intégrations, les données sensibles, l’objectif de reprise, la perte de données tolérable et les compétences internes disponibles. Faites aussi apparaître ce qui restera sous la responsabilité de votre équipe: comptes, configuration, code, sauvegardes applicatives ou surveillance.

Les 24 questions à poser avant de signer

• Où sont situés les environnements principaux, les sauvegardes et les copies de secours?
• Quelles entités juridiques et quels sous-traitants interviennent dans le service?
• Quels composants sont gérés par le fournisseur et lesquels restent à notre charge?
• Comment les administrateurs du fournisseur sont-ils authentifiés, autorisés et journalisés?
• Les données sont-elles chiffrées en transit et au repos, et qui gère les clés?
• Comment les correctifs critiques sont-ils priorisés, testés et déployés?
• Quels rapports d’audit ou attestations peuvent être fournis, avec quel périmètre?
• Quel SLA couvre le service exact, et comment l’indisponibilité est-elle mesurée?
• Quelles exclusions réduisent le SLA et quelles compensations sont prévues?
• Quels objectifs de reprise et de perte de données sont contractuellement soutenus?
• À quelle fréquence les sauvegardes sont-elles produites, isolées et contrôlées?
• Quand la dernière restauration complète a-t-elle été testée et avec quel résultat?
• Le plan de continuité couvre-t-il une panne de site, de réseau et de personnel?
• Quels canaux de support fonctionnent en dehors des heures ouvrées?
• Quels délais de réponse et d’escalade sont associés à chaque sévérité?
• Qui nous informe d’un incident, dans quel délai et avec quelles informations?
• Peut-on exporter les données, configurations, journaux et sauvegardes dans un format exploitable?
• Combien de temps une sortie complète prend-elle et qui supporte son coût?
• Que devient chaque copie de données après la fin du contrat?
• Quelles limites techniques, quotas et dépendances peuvent bloquer une montée en charge?
• Comment les coûts de trafic, stockage, sauvegarde, support et licences évoluent-ils?
• Comment isoler les environnements de développement, test et production?
• Quelles options de connectivité redondante existent depuis nos sites algériens?
• Pouvons-nous réaliser un test de reprise et un exercice de réversibilité avant engagement long?

Transformer les promesses en preuves vérifiables

Une réponse oui ou non est rarement suffisante. Pour chaque exigence critique, demandez une preuve: extrait de rapport, architecture, procédure, exemple de rapport d’incident, historique de disponibilité, résultat de restauration ou démonstration d’export. Vérifiez que la preuve couvre le service acheté et non une autre offre du même fournisseur.

Les certifications peuvent réduire l’effort de contrôle, mais elles ne remplacent ni la compréhension du périmètre ni la configuration de votre propre environnement. Le modèle de responsabilité partagée signifie qu’une infrastructure robuste peut héberger une application mal configurée, des comptes trop puissants ou des secrets exposés.

Calculer le coût total et le coût d’un incident

Le prix affiché ne couvre souvent qu’une partie du coût. Ajoutez la connectivité, les transferts de données, les sauvegardes, la réplication, les licences, la surveillance, l’assistance, le temps d’administration, les environnements non productifs et les opérations de migration. Simulez un mois normal, un pic d’activité et une restauration majeure.

Le fournisseur le moins cher peut rester le meilleur choix, mais cette conclusion doit tenir après intégration des risques et des coûts d’exploitation. À l’inverse, payer une option premium n’a de valeur que si l’équipe sait l’utiliser et si les engagements répondent aux scénarios critiques.

Exemple anonymisé: un portail de commandes avec une dépendance ERP

Une PME prévoit d’héberger un portail B2B. Le devis initial couvre les serveurs et le stockage, mais pas le trafic sortant, la supervision, l’environnement de test ni la restauration assistée. L’ERP reste sur site et dépend d’un seul lien internet. Le risque principal n’est donc pas le centre de données, mais la chaîne complète entre le portail, le site de l’entreprise et l’ERP.

La décision retient un hébergement adapté, une file de synchronisation tolérante aux coupures, une seconde connectivité pour le site critique, des sauvegardes exportables et un test de restauration avant lancement. La comparaison change parce que le périmètre réel est devenu visible.