AWS a reconnu qu'il ne pourrait pas rendre l'accès à certaines données. Où est votre copie ?

Septembre 2026 aura offert un cours accéléré sur ce que le cloud est, et n'est pas. Un câble débranché par erreur chez Google. Une nuit de connexions dégradées dans dix-huit régions d'Azure. Et une phrase d'AWS qui mériterait d'être affichée dans tous les bureaux de DSI.

Ce qui s'est passé

Le mot le plus important : « exclusivement »

Deux définitions, sans raccourci. Chez les grands fournisseurs, une région est un ensemble géographique qui regroupe plusieurs zones de disponibilité. Chaque zone correspond à un ou plusieurs centres de données, conçus pour être isolés des autres zones de la région : alimentation, refroidissement et réseau séparés. Un service peut être réparti sur plusieurs zones, voire plusieurs régions, pour résister à la défaillance de l'une d'elles. Mais cette répartition se configure : elle n'est pas toujours appliquée par défaut, et elle a un coût.

Les clients dont les données étaient hébergées exclusivement dans cette zone dépendaient d'elle seule. AWS indique que la plupart des clients ont pu repartir en restaurant des sauvegardes ou en copiant des données restées accessibles. On peut le résumer d'une formule, à lire comme une formule et non comme un constat chiffré : ceux qui avaient une copie ailleurs avaient un plan. Les autres avaient un cloud.

Le faux sentiment de sécurité : « c'est répliqué »

C'est vrai, et ce n'est pas une sauvegarde. Une réplication a pour but de maintenir un service en marche quand un composant tombe. Elle ne vous protège pas de ce que vous faites vous-même, ni de ce qu'un attaquant fait avec vos accès :

• un dossier supprimé est supprimé partout, presque immédiatement ;

• un fichier chiffré par un rançongiciel est chiffré dans toutes les copies synchronisées ;

• une copie dans le même compte, la même région et chez le même fournisseur subit le même incident, ou le même piratage de compte.
  
  

Le cloud, c'est l'ordinateur de quelqu'un d'autre. Parfois, quelqu'un débranche un câble.

Dernier point à lire dans votre contrat, avant l'incident plutôt que pendant : un engagement de disponibilité se traduit en général par des crédits de service, pas par la restitution de vos données. À vérifier chez votre fournisseur.

Ce que ça change pour l'activité

Quatre heures d'indisponibilité, c'est une demi-journée de collaborateurs bloqués et de clients non servis. Une nuit dégradée passe presque inaperçue, jusqu'au jour où la même panne tombe à 10 h un mardi. Et une perte de données ne se rattrape pas : c'est la seule des trois situations qui ne se règle ni par patience ni par un avoir.

Cinq vérifications, dans l'ordre

1. Savoir où sont vos données

Une ligne par service : la région, la zone si vous la connaissez, le compte. La plupart des entreprises découvrent à cette étape qu'elles ne savent pas répondre.

2. Avoir une copie indépendante

Dans un autre compte, une autre région, chez un autre fournisseur ou sur une infrastructure que vous maîtrisez. C'est le principe de la règle 3-2-1-1-0 : plusieurs copies, sur des supports différents, dont une hors site et une non modifiable.

3. Restaurer ailleurs, pas seulement au même endroit

Une restauration réussie dans l'environnement qui est tombé ne prouve rien. Le test utile se fait dans une autre région ou sur une autre infrastructure, et se chronomètre : c'est ce chronomètre qui dit si vos délais de reprise sont tenables. Pour aller plus loin sur la protection des copies elles-mêmes, voir ce qui résiste vraiment à un rançongiciel.

4. Connaître l'ordre de reprise

Quand tout repart d'un coup, rien ne repart. Quelles trois activités redémarrent en premier, et dans quel ordre leurs dépendances ? C'est le cœur d'un plan de reprise, dont nous avons rappelé la logique dans notre article PRA contre PCA.

5. Relire son contrat

Disponibilité promise, crédits prévus, périmètre de responsabilité, durée de conservation des sauvegardes éventuellement incluses. Cinq minutes de lecture, une fois.

❓ Questions fréquentes

Rédigé par Sylvain Sarazin

J’aide les entreprises et collectivités à repartir vite après un incident informatique.
Artisan de la résilience IT