Un directeur financier m'a appelé l'année dernière, paniqué. Son prestataire cloud venait de lui envoyer une facture de sortie à cinq chiffres pour récupérer ses propres données. Le contrat signé quatre ans plus tôt ne mentionnait nulle part le coût de la réversibilité. Résultat : il payait pour partir, après avoir payé pour rester. Voilà pourquoi choisir un fournisseur cloud sécurisé ne se joue pas sur la page tarifaire.
La question revient sans cesse dans les comités de direction : comment choisir fournisseur cloud sécurisé entreprise sans se tromper ? La réponse tient moins à la notoriété du prestataire qu'à ce que vous écrivez noir sur blanc dans le contrat, et à ce que vous êtes capable de vérifier vous-même. Je vais vous donner une méthode concrète, avec les critères techniques qui comptent vraiment et les questions à poser avant de signer. Pas de grille abstraite à vingt-deux cases : ce qui fait la différence entre un cloud qui protège et un cloud qui expose.
Points clés à retenir
- Le modèle de responsabilité partagée est le premier document à exiger : il délimite qui sécurise quoi.
- Une certification affichée sur un site ne vaut rien si elle ne couvre pas votre usage précis (périmètre, datacenters, services).
- Le chiffrement, la gestion des clés et la journalisation se vérifient en démonstration, pas sur une plaquette commerciale.
- La réversibilité et le coût de sortie doivent figurer au contrat avant la signature, jamais après.
- Un fournisseur qui refuse un droit d'audit ou reste flou sur ses sous-traitants ultérieurs est un signal d'alerte majeur.
Pourquoi choisir un fournisseur cloud sécurisé engage votre responsabilité, pas la sienne
Beaucoup d'entreprises croient acheter une sécurité en migrant vers le cloud. En réalité, elles achètent une infrastructure dont elles gardent une partie de la sécurité à leur charge. C'est le point que personne ne lit.
Le modèle de responsabilité partagée, ce contrat invisible
Le principe est simple, mais ses frontières varient d'un prestataire à l'autre. Grosso modo : le fournisseur sécurise le socle physique (bâtiments, matériel, hyperviseur, réseau), et vous sécurisez tout ce que vous y mettez (données, identités, configurations, accès). Le problème ? La ligne de partage n'est pas la même selon qu'il s'agit d'une machine virtuelle brute, d'une base de données managée ou d'une fonction serverless.
J'ai vu une équipe technique se féliciter d'avoir « tout migré chez le grand fournisseur ». Six mois plus tard, un bucket de stockage mal configuré exposait des exports clients. Le fournisseur n'était pas en tort : la configuration relevait du client. La leçon est amère mais utile : la sécurité de ce qui est managé dépend de ce qui n'est pas configuré par vous.
Ce que vous devez obtenir : un tableau écrit, service par service, indiquant qui contrôle quoi. Si votre interlocuteur botte en touche, prenez vos jambes à votre cou.
La conformité réglementaire comme filtre de premier tour
Avant même de parler technique, listez les obligations qui vous concernent. Le RGPD, d'abord, impose de savoir où sont hébergées les données et qui y accède. Pour les données de santé en France, la certification HDS est un prérequis. Pour les administrations et les opérateurs sensibles, le référentiel SecNumCloud de l'ANSSI et son visa de sécurité pèsent lourd. L'ISO 27001 reste un bon indicateur de maturité, à condition de vérifier le périmètre certifié.
Mon conseil, tranché : demandez le certificat, pas la capture d'écran du site. Vérifiez la date d'expiration, l'organisme certificateur, et surtout si vos services précis sont dans le périmètre. Une certification qui ne couvre pas votre usage ne vous protège pas.
La grille de critères techniques qui sépare un bon fournisseur d'un prestataire risqué
Une plaquette commerciale vous dira que tout est chiffré. C'est vrai pour à peu près tous les acteurs sérieux. La vraie question, c'est comment, avec quelles clés, et qui peut les manipuler.
Chiffrement et gestion des clés : le détail qui change tout
Exigez trois choses en démonstration, pas au téléphone :
- Le chiffrement au repos et en transit, avec les algorithmes utilisés.
- La gestion des clés : pouvez-vous apporter la vôtre (BYOK), la conserver chez vous (HYOK), ou rester sur une clé gérée par le prestataire ?
- Ce qui se passe si vous révoquez une clé : le prestataire perd-il réellement l'accès, ou conserve-t-il une copie de secours ?
Ce dernier point m'a valu une discussion tendue avec un fournisseur il y a deux ans. Sa réponse : « nous gardons une clé de récupération pour le support ». Traduction : quelqu'un chez lui pouvait accéder à mes données. Ce n'est pas rédhibitoire pour tout le monde, mais vous devez le savoir.
Identités, journalisation et réponse aux incidents
Une infrastructure sécurisée se reconnaît à ce qu'elle permet de tracer. Posez des questions précises : l'authentification multifacteur est-elle imposée par défaut ? Existe-t-il une gestion des accès privilégiés (PAM) ? Les journaux d'audit remontent-ils vers votre SIEM, et pendant combien de temps sont-ils conservés ?
Autre point souvent négligé : l'isolation multi-tenant. Vos données partagent-elles le même socle que celles d'autres clients, et comment le fournisseur garantit-il l'étanchéité ? La réponse doit être documentée, pas promise oralement.
Enfin, le plan de réponse aux incidents. Demandez : en combien de temps êtes-vous notifié en cas de violation ? Le RGPD fixe un cadre, mais le contrat doit préciser les modalités concrètes. Un fournisseur qui ne sait pas répondre à cette question n'a pas de plan.
Comment comparer concrètement les fournisseurs cloud sécurisés
Les grands hyperscalers (AWS, Azure, Google Cloud) offrent une profondeur de services difficile à égaler, mais une souveraineté et une réversibilité qui demandent un vrai travail contractuel. Les acteurs français ou européens mettent en avant la localisation des données et la conformité aux référentiels nationaux, parfois au prix d'un catalogue plus restreint. Il n'y a pas de bon choix universel : il y a un choix cohérent avec vos contraintes.
| Critère | Ce qu'il faut vérifier | Signal d'alerte |
|---|---|---|
| Certifications | Périmètre exact, datacenters concernés, validité | Certificat affiché mais introuvable ou expiré |
| Gestion des clés | BYOK / HYOK disponibles et documentés | Clé de récupération support non annoncée |
| Localisation | Pays d'hébergement et de traitement réel | Réplication hors UE non signalée |
| Réversibilité | Coût et format d'export des données prévus au contrat | Frais de sortie découverts à la fin |
| Sous-traitants | Liste à jour et clause de notification en cas de changement | Liste « confidentielle » ou non communiquée |
| Droit d'audit | Possibilité de faire auditer ou de recevoir un rapport d'audit tiers | Refus ou renvoi systématique au commercial |
Faut-il une matrice de décision pondérée ?
Oui, mais une matrice courte. Sur un projet récent, j'ai vu une équipe noter chaque fournisseur sur quarante critères. Au final, trois critères ont décidé, et les trente-sept autres ont servi à justifier une décision déjà prise. Ma méthode : pondérez cinq à sept critères, pas plus. La conformité et la réversibilité pèsent lourd ; le prix se calcule en coût total, pas en tarif mensuel.
Le coût total sécurisé inclut le prix du service, mais aussi la conformité, la formation des équipes, l'outillage de supervision et le coût de sortie éventuel. C'est ce chiffre-là qu'il faut comparer.
Les questions à poser avant de signer
- Quel est le SLA de sécurité, distinct du SLA de disponibilité ?
- Qui sont vos sous-traitants ultérieurs, et comment serai-je notifié d'un changement ?
- Puis-je obtenir un rapport d'audit indépendant récent ?
- Quel est le coût et le délai pour récupérer l'intégralité de mes données ?
- Que se passe-t-il en cas de résiliation : format d'export, durée de conservation, suppression certifiée ?
Les erreurs que j'ai commises (et que vous pouvez éviter)
Ma plus grosse erreur : avoir signé un contrat en me fiant à la réputation du fournisseur plutôt qu'aux clauses. Un nom connu ne garantit pas un engagement sur la réversibilité. J'ai découvert, trop tard, que l'export complet de nos données prenait trois semaines et coûtait plus cher que la migration initiale.
Deuxième erreur : avoir cru que « certifié » signifiait « tout est couvert ». La certification portait sur une partie du catalogue, pas sur le service que nous utilisions. Troisième : avoir négligé la question des sous-traitants. Un prestataire sérieux vous communique sa liste et s'engage à vous prévenir en cas de changement. Un prestataire qui esquive n'a pas envie que vous regardiez de trop près.
Avouons-le, ces erreurs coûtent cher mais elles s'évitent avec une checklist écrite et un peu de méfiance. La sécurité cloud ne se délègue pas entièrement : elle se contractualise.
Ce qui reste quand la migration est terminée
Le vrai test d'un fournisseur cloud sécurisé n'est pas la signature du contrat. C'est le jour où quelque chose casse. Ce jour-là, vous saurez si vos journaux remontent, si vos clés sont révocables, si quelqu'un décroche au support, et si vous pouvez partir sans rançon.
Alors posez la question qui dérange avant de signer : « si je veux vous quitter demain, que se passe-t-il ? » La qualité de la réponse vous en dira plus sur votre futur prestataire que n'importe quelle certification affichée en page d'accueil. Et si l'on vous répond que la question ne se pose pas, c'est précisément qu'il faut la poser.
