Gestion des versions pour le partage : évitez les écrasements
Mettez en place un contrôle de version pour les fichiers partagés afin d'éviter les écrasements, suivre les changements et revenir aux versions précédentes.
Éliminez le chaos des écrasements avec trois outils qui travaillent ensemble : l'historique de versions natif de votre plateforme de synchronisation (Google Drive conserve 100 versions ou 30 jours, Dropbox Business conserve 180 jours, OneDrive conserve 500 versions), le verrouillage par réservation/libération pour les fichiers qu'une seule personne doit modifier à la fois (SharePoint, Box ou des DAM comme Bynder), et Git ou Git-LFS pour tout ce qui est textuel ou qui nécessite un branchement explicite. Ajoutez par-dessus une convention de nommage avec suffixes vNN, et vous obtenez à la fois une récupération automatique (outil de synchronisation) et des instantanés intentionnels (style Git).
Les trois modes de défaillance des fichiers partagés
Chaque désastre d'écrasement est l'un de ces trois patterns. Reconnaissez-les et les solutions deviennent évidentes.
- Collision de sauvegardes simultanées : deux personnes éditent le même fichier en même temps ; le dernier à sauvegarder gagne, le travail du premier disparaît. Solutions : co-édition en temps réel (Google Docs, Office Online) ou verrouillage explicite (réservation SharePoint).
- Écrasement par erreur : quelqu'un ouvre "le fichier", l'édite, sauvegarde par-dessus la copie canonique en pensant sauvegarder une copie de travail personnelle. Solution : séparation claire source-de-vérité avec des copies canoniques en lecture seule.
- Historique perdu : un fichier était correct trois versions auparavant mais l'état actuel est cassé et personne ne peut reconstruire les étapes intermédiaires. Solution : historique de versions conservé sur la plateforme plus des instantanés disciplinés.
La plupart des équipes vivent les trois. La solution composite utilise des outils différents pour des modes de défaillance différents.
Co-édition en temps réel pour les documents vivants
Pour les textes et tableurs que beaucoup de personnes éditent, la co-édition en temps réel élimine complètement les collisions d'écrasement. Google Docs, Sheets et Slides gèrent 100+ éditeurs simultanés sans problème. Microsoft 365 Word Online et Excel Online sont juste derrière en parité, avec une meilleure fidélité des formats .docx legacy.
Notion, Coda et Airtable étendent cela aux docs structurés et aux bases de données avec une fusion basée sur des transformations opérationnelles ou des CRDT. Figma fait de même pour les fichiers de design avec un moteur multijoueur personnalisé.
Quand vous choisissez un outil, vérifiez que la co-édition en temps réel fonctionne avec vos tailles de fichiers réelles. Certains outils se dégradent au-delà de 1 000 lignes ou 50 pages. Testez avec des données réalistes avant de faire adopter l'outil à toute l'équipe.
Verrouillage par réservation pour les fichiers binaires
Les fichiers binaires — PSD, Illustrator .ai, InDesign .indd, Revit .rvt, Premiere .prproj, AutoCAD .dwg — ne peuvent pas fusionner proprement les conflits. Deux personnes qui éditent signifie que les modifications de l'une mourront. Le verrouillage explicite est la réponse.
Outils avec une réservation/libération mature :
- SharePoint : réservation/libération native sur n'importe quelle bibliothèque. Sous-utilisée mais éprouvée.
- Box : verrouillage de fichier avec un indicateur "qui l'a sorti"
- Bynder, Frontify, Brandfolder : DAM avec verrouillage intégré pour les assets créatifs
- Perforce Helix Core : le standard or pour les studios de jeux et les maisons VFX — commits atomiques sur des centaines de gigaoctets d'assets binaires
Pour les équipes qui vivent dans Dropbox ou Drive sans verrouillage natif, un verrouillage basé sur la discipline fonctionne : un fichier VERROUILLE-proprietaire.txt dans le dossier, ou un message épinglé dans le canal Slack du projet. Fragile mais suffisant pour les petites équipes.
Git et Git-LFS pour tout ce qui est textuel
Git est l'étalon-or du contrôle de version. Utilisez-le pour :
- Le code source (évidemment)
- Les docs en Markdown, wikis et bases de connaissance internes
- Les fichiers de configuration (Kubernetes YAML, Terraform, Ansible)
- Les schémas de données (Prisma, modèles dbt, migrations SQL)
- Tout ce pour quoi vous voulez un branchement explicite, des diffs et une revue de code
Git-LFS étend Git aux assets binaires volumineux. Il stocke les blobs binaires sur un serveur séparé et Git suit des pointeurs. Le Git-LFS de GitHub est gratuit jusqu'à 1 Go de stockage et 1 Go de bande passante mensuelle ; des packs de données à 5 $/mois ajoutent 50 Go chacun.
Pour les équipes qui associent Git à un travail créatif — sites marketing avec des images embarquées, projets jeux avec des PSD à côté du code — Git-LFS les colle ensemble. Pour le travail purement créatif sans code adjacent, les DAM ou Perforce conviennent mieux.
Historique de versions natif : le filet de sécurité
Chaque outil de synchronisation majeur conserve l'historique de versions automatiquement. Connaissez vos paramètres par défaut :
- Google Drive : 100 versions ou 30 jours, selon ce qui est le plus long. Les plans Workspace étendent à 100 versions sans limite de temps sur les formats non-Google.
- OneDrive et SharePoint : 500 versions par défaut, configurable par bibliothèque
- Dropbox : 30 jours sur Basic, 180 jours sur Business, 365 jours sur Advanced, illimité sur Enterprise
- Box : 100 versions sur Business, illimité sur Enterprise
- Apple iCloud Drive : seulement 30 jours ; le plus faible des grands acteurs
Vérifiez que votre forfait active réellement ce que vous pensez. Certaines organisations découvrent lors d'une crise que l'admin a réduit la rétention pour économiser sur le stockage deux ans auparavant.
Conventions de nommage comme instantanés explicites
L'historique de versions automatique est idéal pour les petites récupérations. Pour les jalons de projet, des instantanés nommés explicitement sont plus clairs. La convention vNN dans les noms de fichiers vous donne des instantanés ponctuels que les humains peuvent naviguer :
2026-06-12_ACME-RF_spec_v01.pdf2026-06-15_ACME-RF_spec_v02.pdf2026-06-19_ACME-RF_spec_v03.pdf
Quand quelqu'un demande "qu'avons-nous envoyé au client le 15 juin ?", vous pouvez répondre sans fouiller les métadonnées d'historique de versions. Nommez les versions majeures, laissez l'historique automatique gérer les interstitiels.
Exercices de rollback pour prouver que le système fonctionne
Une sauvegarde que vous ne testez jamais n'est pas une sauvegarde. Idem pour l'historique de versions. Une fois par trimestre, prenez un fichier aléatoire, prétendez qu'il a été corrompu hier, et mesurez le temps qu'il faut pour restaurer la version précédente. Si ça prend plus de 10 minutes, quelque chose est cassé — peut-être que la rétention de votre outil de synchronisation est plus courte que vous ne le pensiez, peut-être que personne ne sait où se trouve l'interface d'historique, peut-être que vous dépendez d'une personne en congé.
Documentez la procédure de rollback pour chacun de vos outils. Des captures d'écran aident. Épinglez le document à la racine du drive partagé.
Branchement pour le travail expérimental
Parfois une piste "et si on essayait ça" ne devrait pas toucher le fichier canonique. Pour le code source, vous créez une branche dans Git (git checkout -b experiment/nouvelle-hero). Pour les fichiers créatifs, l'équivalent est un dossier parallèle :
/Projets/ACME-RF/02-travail/
/Projets/ACME-RF/02-travail/experience-direction-alternative/
Travaillez dans le dossier expérimental jusqu'à ce qu'il remplace la direction principale (déplacez dans 02-travail/, renommez le canonique en 02-travail/archive-direction-originale/) ou soit abandonné (reste dans le dossier expérimental comme référence de l'exploration).
Ce pattern empêche le travail "et si" de polluer les fichiers de travail principaux tout en le préservant comme référence valide.
Livraison de fichiers versionnés à l'extérieur
Quand une version doit aller chez un client — une version majeure spécifique qu'il est en train de relire, pas votre travail en cours — envoyez-la via un canal de transfert, pas un lien de synchronisation. Le partage par lien depuis votre outil de synchronisation risque de montrer au client une version en cours d'édition qui évolue sous ses yeux.
Un lien de transfert capture le fichier à un instant T et l'expédie. Des services comme HexaTransfer, Dropbox Transfer et Smash figent l'état au moment de l'envoi. Le client voit exactement ce que vous avez envoyé, pour toujours, jusqu'à l'expiration du lien.
Essayez HexaTransfer sur https://hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.
Envoyez vos fichiers volumineux en toute sécurité avec le chiffrement de bout en bout
Transférez des fichiers jusqu'à 10 Go gratuitement avec le chiffrement de bout en bout. Aucun compte requis. Vos fichiers sont chiffrés dans votre navigateur avant l'envoi — personne d'autre ne peut les lire.
Envoyer un fichier