Versionnage de fichiers : ne perdez plus jamais vos modifications

Le versionnage de fichiers enregistre chaque révision pour pouvoir revenir en arrière après des écrasements accidentels, des suppressions et des dégâts causés par des ransomwares. Activez-le au niveau de la plateforme — S3 Versioning, Azure Blob Versioning, Google Cloud Storage Object Versioning, l'historique des versions Dropbox, les versions majeures/mineures SharePoint — et associez-le à des règles lifecycle qui expirent les anciennes versions après 30 à 180 jours. Sans versionnage, un seul rm -rf ou un client de synchronisation défaillant peut vaporiser des années de travail en quelques secondes, et la « sauvegarde cloud » que vous croyiez avoir n'est qu'une copie synchronisée des dégâts.

Ce que fait vraiment le versionnage de plateforme

Quand le versionnage est activé, un écrasement ne remplace pas l'objet — il crée une nouvelle version avec un nouveau VersionId. Les anciens octets restent sur le disque, récupérables par cet ID. Une suppression devient un « marqueur de suppression » plutôt qu'une destruction ; les versions précédentes restent restaurables jusqu'à ce que vous les purgiez explicitement.

Cela compte parce que la plupart des pertes de données ne sont pas des défaillances matérielles catastrophiques (la durabilité du cloud gère cela). C'est quelqu'un qui sauvegarde un tableur vide par-dessus un tableur rempli, ou un script avec un bug qui tronque mille fichiers, ou un ransomware qui chiffre tout ce qu'il peut atteindre. Le versionnage permet de remonter 30 jours en arrière et de reprendre là où les choses étaient saines.

Le coût de la conservation de toutes les versions

Les versions consomment du stockage, et le stockage coûte de l'argent. Un bucket avec 10 To de fichiers et une édition active peut accumuler 30 à 50 To de versions sur un an. L'atténuation : des règles lifecycle qui expirent les versions non courantes après une période définie, ou les déplacent vers des niveaux moins chers.

Une politique S3 lifecycle pratique :

• Versions non courantes : transition vers S3 Standard-IA après 7 jours
• Versions non courantes : transition vers Glacier Flexible Retrieval après 30 jours
• Versions non courantes : suppression après 180 jours
• Marqueurs de suppression sans versions non courantes : suppression après 1 jour

Pour Azure et GCS, les équivalents utilisent des conditions d'âge blobVersion ou Noncurrent. Modélisez le coût : 10 To de versions en S3 Standard représentent 230 $/mois ; en Glacier Flexible, 36 $/mois. La transition de niveau vaut quelques minutes de YAML.

Versions majeures vs mineures

Les systèmes orientés documents comme SharePoint, Google Workspace et Notion distinguent les versions majeures (publiées) des versions mineures (brouillons). Les brouillons s'accumulent entre les jalons ; les versions majeures représentent un état stable approuvé. Pour les contrats, les politiques et les spécifications, cette distinction est précieuse — vous pouvez partager publiquement le lien « version majeure 3 » tout en continuant à éditer les brouillons v3.1, v3.2 en privé.

Utilisez les versions majeures comme point de référence pour les parties externes. Verrouillez-les avec des permissions en lecture seule ou des workflows d'approbation pour que personne n'écrase accidentellement l'état publié. La colonne « Exiger l'approbation du contenu » de SharePoint s'active en un clic ; le flux d'approbation de Google Drive se configure en 2 minutes.

Contrôle de version pour le code source vs les documents

Git fonctionne parfaitement pour le texte (code source, markdown, fichiers .tf) car les diffs sont significatifs ligne par ligne. Il fonctionne mal pour les binaires : un fichier .psd de 50 Mo enregistré deux fois double la taille du dépôt, et git diff ne peut pas vous aider. Git LFS (Large File Storage) déplace les binaires vers un stockage séparé et conserve des pointeurs dans le dépôt — raisonnable pour les ressources artistiques, mauvais pour les documents généraux.

Pour les fichiers .docx, .xlsx, .pptx et .pdf, utilisez le versionnage natif de la plateforme cloud plutôt que Git. SharePoint, Drive et Dropbox stockent tous des deltas par version nativement et affichent une interface chronologique que les utilisateurs métier peuvent parcourir. Pour du contenu mixte (code plus PDFs plus fichiers de design), certaines équipes utilisent DVC ou LakeFS comme couches Git-pour-les-données sur le stockage objet — vaut la peine d'investiguer pour les équipes ML et données.

Rétention liée aux calendriers de conformité

Les réglementations dictent la durée de conservation des versions. La règle SEC 17a-4 exige que les enregistrements des courtiers-négociants soient conservés 3 à 6 ans. HIPAA conserve les dossiers 6 ans minimum. SOX veut 7 ans pour les données financières. Le RGPD plafonne dans l'autre sens — ne conservez pas les données personnelles plus longtemps que nécessaire, sous le contrôle de la CNIL en France.

Étiquetez les fichiers sensibles pour que les règles lifecycle respectent les minimums et maximums réglementaires. Un tag S3 comme retention-class: sox-7y peut piloter les transitions lifecycle, les durées de blocage d'objets et la suppression finale. Utilisez S3 Object Lock en mode Compliance pour les copies réglementaires immuables — même les utilisateurs root ne peuvent pas supprimer pendant la période de rétention, ce qu'exigent exactement les règles WORM (Write Once Read Many).

Protection contre les ransomwares via les versions

Une attaque de ransomware qui atteint vos clients de synchronisation chiffrera les fichiers sur le terminal et enverra les versions chiffrées vers le cloud. Le versionnage vous sauve — les versions pré-chiffrement existent toujours. Mais seulement si deux conditions sont remplies : le versionnage était activé avant l'attaque, et la rétention est assez longue pour couvrir le délai de détection.

Le temps de présence moyen des ransomwares en 2025 se situe autour de 11 jours pour les entreprises de taille intermédiaire. Une rétention de versions de 30 jours est le minimum ; 90 jours est plus sûr. Associez le versionnage à la protection contre les suppressions (S3 MFA Delete, suppression douce Azure avec un administrateur différent) pour qu'un attaquant qui compromet un compte ne puisse pas purger l'historique des versions. Testez la restauration chaque trimestre — simulez la suppression d'un dossier de test et chronométrez la récupération.

Conventions de nommage pour les versions partagées

Quand vous partagez une version spécifique avec l'extérieur — envoyer à un client « la v3 approuvée du contrat » — vous avez besoin d'un pointeur stable qui ne change pas quand quelqu'un édite. Utilisez l'un de ces trois schémas :

1. URL présignée vers un VersionId spécifique (S3 : ?versionId=...) — valable 7 jours maximum, immuable
2. Une copie de la version approuvée dans un bucket /publié/ séparé avec la version dans le nom du fichier (contrat-v3.0-2026-12-15.pdf)
3. Un export PDF instantané pour que les modifications post-approbation n'affectent pas la copie partagée

Pour le partage ponctuel d'une capture spécifique avec quelqu'un extérieur à votre plateforme, les outils de transfert chiffrés de bout en bout envoient un fichier précis avec un lien à usage unique. HexaTransfer convient à cet usage : envoyez la version figée, transmettez le lien, et le destinataire reçoit exactement ce que vous souhaitiez sans avoir accès à l'ensemble de votre plateforme.

Surveillance et alertes sur les événements de versionnage

L'historique des versions n'est utile que si vous remarquez quand vous en avez besoin. CloudTrail (AWS), Activity Log (Azure) et Cloud Audit Logs (GCP) journalisent chaque événement de versionnage. Alertez sur des taux de suppression inhabituels — 10 000 appels DeleteObject en une heure ne vient probablement pas d'un utilisateur qui fait du nettoyage.

Construisez un tableau de bord simple montrant le nombre de versions par bucket, le stockage total des versions et les ratios de marqueurs de suppression. Un bucket où les marqueurs de suppression dépassent soudainement les objets vivants est un signal de détresse : soit une suppression massive s'est produite, soit la rétention de versionnage est sur le point de purger ce que vous vouliez conserver. Des résumés hebdomadaires par e-mail valent mieux qu'attendre l'audit trimestriel.

Le runbook de récupération

Documentez le processus de restauration avant d'en avoir besoin. Un bon runbook couvre :

1. Comment lister les versions (aws s3api list-object-versions, az storage blob list --include v)
2. Comment restaurer un VersionId spécifique comme version courante (S3 : copie avec --version-id)
3. Comment restaurer en masse tout un préfixe à un instant donné (scripts avec filtres d'horodatage)
4. Comment restaurer des objets supprimés (supprimer les marqueurs de suppression)
5. Qui a la permission de faire chacune de ces opérations (généralement pas la même personne qui a causé la perte)

Imprimez-le. Parcourez-le une fois par trimestre avec un scénario fictif. Quand l'événement réel survient, la mémoire musculaire l'emporte sur la lecture de documentation sous pression.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.