Comment remplacer Google Drive par un serveur Nextcloud qui vous appartient

Le stockage cloud est la chose la plus intime que la plupart des gens confient à une entreprise. Pas les documents — les photos, les scans de papiers d'identité, les déclarations d'impôts, la sauvegarde d'un téléphone qui contient tout. Cela vit dans un compte qu'un système automatisé peut suspendre sans appel possible, sur des serveurs qui scannent ce que vous envoyez, rattaché à une identité que vous avez vérifiée il y a des années et que vous ne pouvez plus détacher. Les gens découvrent la forme réelle de cet arrangement au pire moment possible, généralement quand un compte bloqué emporte avec lui vingt ans de photos de famille. Nextcloud est la réponse open source : les mêmes clients de synchronisation, la même application mobile, les mêmes liens de partage — tournant sur une machine que vous louez, contenant des fichiers que personne d'autre n'indexe. L'installer tient en un après-midi. Ce qui détermine si le résultat est réellement meilleur que ce que vous avez quitté, c'est le disque en dessous, et une question de chiffrement que presque tous les tutoriels traitent mal.

Ce que Nextcloud remplace réellement

Nextcloud n'est pas tant une application unique qu'une petite suite qui couvre l'essentiel de ce que fait un compte cloud grand public. Cette étendue est la raison même pour laquelle l'auto-hébergement en vaut la peine : remplacer un seul service par son équivalent auto-hébergé justifie rarement la maintenance que cela demande, mais en remplacer cinq par un seul serveur, généralement oui.

• La synchronisation et le partage de fichiers, qui en est le cœur. Des clients de bureau pour Windows, macOS et Linux, des applications mobiles pour les deux plateformes, et une interface web — le même comportement « glissez un dossier et il apparaît partout » que vous connaissez déjà.
• La sauvegarde des photos depuis votre téléphone, avec envoi automatique de la pellicule, albums et regroupement par visages. Pour la plupart des gens, c'est de loin la plus grosse part des données, et la raison pour laquelle le disque doit être correctement dimensionné.
• Le calendrier et les contacts via les standards ouverts CalDAV et CardDAV, que tout téléphone parle nativement — aucune application tierce n'est nécessaire pour les synchroniser.
• Des documents collaboratifs via une suite bureautique que vous pouvez ajouter, pour éditer tableurs et fichiers texte dans le navigateur sans jamais les envoyer ailleurs.
• Des liens de partage publics avec mot de passe, date d'expiration et dossiers de dépôt en upload seul — la fonctionnalité qui met généralement fin à l'habitude d'envoyer de grosses pièces jointes par email.
• Le versionnage côté serveur et une corbeille, si bien qu'un fichier écrasé ou une mauvaise synchronisation reste récupérable sans avoir à recourir à une sauvegarde.

La limite mérite d'être posée clairement, car le discours autour de l'auto-hébergement le fait rarement. Nextcloud vous donne le contrôle et la confidentialité. Il ne vous donne pas la durabilité d'un hyperscaler — ces entreprises répliquent vos données sur plusieurs continents, ce qu'un unique serveur loué ne fait pas, aussi bons soient ses disques. Cela ne rend pas non plus les fichiers gratuits : vous payez le stockage dans tous les cas, simplement auprès d'un hébergeur qui n'a jamais demandé votre nom plutôt qu'un qui l'a fait. L'auto-hébergement échange la fiabilité de quelqu'un d'autre contre votre propre contrôle, et ce n'est un bon échange que si vous prenez au sérieux la moitié « fiabilité ».

Vous devenez le prestataire de stockage

C'est le coût honnête de l'opération, et il vaut bien mieux le comprendre avant la migration qu'après. Personne ne surveille votre disponibilité, personne ne détient de copie de vos photos, et personne ne décroche au bout d'une ligne de support au moment où un client de synchronisation signale un conflit sur un fichier dont vous aviez besoin ce matin.

• Les sauvegardes vous appartiennent, et elles ne sont pas optionnelles. Une grappe RAID survit à un disque mort ; elle ne survit pas à un dossier supprimé, une mise à niveau ratée ou un ransomware qui traverse un répertoire synchronisé. Le versionnage et la corbeille sont des fonctions de confort, pas une sauvegarde.
• La disponibilité vous appartient. Un client de synchronisation qui ne peut pas joindre le serveur met les changements en file d'attente discrètement et rattrape le retard plus tard, ce qui est indulgent — mais un lien de partage que vous avez envoyé à un client est mort tant que la machine est hors ligne.
• Les mises à jour vous appartiennent, et Nextcloud les publie à un rythme soutenu. C'est une application PHP sur une IP publique qui contient toute votre vie, donc appliquer les correctifs n'est pas quelque chose à reporter en attendant un mois plus calme.
• La capacité est à vous de surveiller. Un téléphone qui envoie automatiquement chaque photo remplira un disque que vous aviez dimensionné généreusement, selon un calendrier que vous n'aviez pas prévu, et un disque plein corrompt bien plus qu'il n'arrête simplement les choses.
• La restauration vous appartient. Restaurer signifie la base de données et l'arborescence de fichiers ensemble, à un instant cohérent. Restaurer l'une sans l'autre produit une interface qui fonctionne mais qui liste des fichiers qui ne sont pas là.

Rien de tout cela n'est lourd une fois que c'est en place. Ce sont quelques minutes par mois, plus un après-midi appliqué au démarrage, et c'est la même discipline qu'exige n'importe quel service auto-hébergé — la différence, c'est seulement que celui-ci contient les choses que vous détesteriez le plus perdre. Si vous êtes déjà passé par l'hébergement d'un site web par vous-même, rien de tout cela ne vous sera étranger.

Dimensionner la machine : budgétisez pour les données, pas pour l'application

Nextcloud lui-même est une application PHP modeste. Presque toutes les erreurs de dimensionnement viennent ici du fait de budgétiser pour l'application et d'oublier que tout l'exercice consiste à contenir des données qui croissent. Trouvez la bonne taille dès le départ, car migrer plus tard une arborescence de fichiers et sa base de données d'une machine à une autre est l'après-midi le moins agréable de tout l'auto-hébergement.

• Le stockage est la décision qui détermine votre offre, et il vous en faut environ le double de ce que vos fichiers pèsent aujourd'hui. Le versionnage conserve d'anciennes copies des fichiers modifiés, la corbeille retient les suppressions pendant une fenêtre de rétention, et les vignettes et aperçus générés représentent un pourcentage réel en plus d'une photothèque.
• La mémoire détermine le ressenti plutôt que le fonctionnement. 2 GB font tourner une instance mono-utilisateur ; 4 GB sont confortables pour un foyer avec des envois automatiques depuis un téléphone ; 8 GB et plus deviennent utiles dès qu'une suite bureautique et une poignée d'utilisateurs simultanés entrent en jeu.
• Le CPU est inactif presque tout le temps, puis compte brièvement énormément — la première génération d'aperçus sur une photothèque importée, et toute conversion de document à la volée, sont les pics pour lesquels il vaut la peine de garder de la marge.
• La base de données veut du stockage rapide, les fichiers beaucoup moins. Les opérations sur les métadonnées sollicitent constamment la base, tandis que l'arborescence de fichiers relève surtout de lectures et écritures séquentielles — c'est pourquoi un petit disque racine en NVMe associé à de la capacité en volume est une meilleure configuration qu'un unique gros volume lent.
• Le transfert est illimité ici, mais l'envoi initial d'une photothèque existante représente un pic ponctuel réellement conséquent. Prévoyez qu'il tourne toute une nuit plutôt que d'être surpris par lui.

En pratique, cela retombe sur deux configurations selon ce que vous stockez réellement. En dessous de quelques centaines de gigaoctets — documents, photothèque modeste, une ou deux personnes — le VPS-8 à $13.99/mo avec 4 vCPU EPYC, 8 GB DDR5 ECC et 120 GB de NVMe Gen4 est rapide et largement suffisant. Dès qu'un téléphone avec sa pellicule entre en jeu, la capacité devient toute la question et le NVMe devient la mauvaise chose à payer : un serveur de stockage à partir de $7.99/mo vous donne 1 TB en RAID-6, et le STO-4 à $22.99/mo vous en donne 4 TB — une tout autre catégorie de marge que n'importe quel VPS, pour une fraction du prix au téraoctet. Si vous regroupez un foyer ou une petite équipe au-delà de ça, un serveur dédié à partir de $64/mo avec 2 × 1 TB de NVMe vous donne à la fois la vitesse et l'espace sans que le calcul ne devienne absurde.

Étape par étape : d'un serveur tout neuf à une synchronisation opérationnelle

1. 01Déployez le serveur et durcissez-le d'abordUne machine Debian ou Ubuntu, une authentification SSH par clé uniquement, un pare-feu qui refuse tout par défaut — avant qu'un seul fichier ne s'y trouve. Faites cela pendant que la machine est encore vide et sans intérêt.
2. 02Pointez un domaine vers le serveur et laissez un certificat s'émettreLes clients Nextcloud refuseront de synchroniser en HTTP simple, à raison. Le nom d'hôte doit résoudre vers la machine avant que le certificat ne puisse être émis, ce qui est de loin la cause la plus fréquente d'installation ratée.
3. 03Choisissez votre méthode d'installation et tenez-vous-yL'image de conteneur est la voie la plus rapide et la plus simple à maintenir à jour ; une installation manuelle sur un serveur web et une base de données vous donne plus de contrôle sur le réglage fin. Choisissez-en une — mélanger les deux, c'est exactement comme ça que les mises à niveau se cassent.
4. 04Utilisez une vraie base de données, pas SQLiteSQLite fonctionne pour exactement un utilisateur qui ne fait pas grand-chose, et s'effondre dès que deux clients synchronisent en même temps. Choisissez MariaDB ou PostgreSQL au moment de l'installation, car convertir après coup est une migration désagréable.
5. 05Ajoutez un cache mémoire et configurez les tâches de fondRedis pour le verrouillage et la mise en cache, et un cron au niveau système pour les tâches de fond plutôt que le déclenchement par défaut via le navigateur. Sauter ces étapes est exactement pourquoi certaines instances auto-hébergées semblent poussives et d'autres instantanées.
6. 06Augmentez les limites d'upload avant de migrer quoi que ce soitLes valeurs par défaut sont calibrées pour de petits fichiers et rejetteront une vidéo ou une image disque. Corrigez d'abord les limites dans la configuration du serveur web et de PHP, sinon votre premier gros envoi échouera à quatre-vingt-dix pour cent.
7. 07Migrez vos fichiers en une seule passe délibéréeEnvoyez l'ensemble de vos fichiers existants depuis un client de bureau, ou copiez-les directement en place et déclenchez un scan. Faites cela une seule fois, de nuit, avant que qui que ce soit ne dépende de l'instance.
8. 08Connectez les clients, puis mettez en place les sauvegardes le jour mêmeSynchronisation de bureau, envoi automatique depuis le téléphone, calendrier et contacts. Configurez ensuite la sauvegarde et testez-la réellement — une instance en production sans chemin de restauration est un compte à rebours.

Chiffrement : ce qui vous protège réellement, et ce qui en a seulement l'air

C'est la section qui compte le plus si vous avez quitté un cloud grand public précisément parce qu'une entreprise pouvait lire vos fichiers, et c'est celle que la plupart des guides traitent mal. Nextcloud propose une fonctionnalité appelée chiffrement côté serveur. L'activer donne l'impression d'avoir la réponse. Ce n'est presque jamais le cas, et comprendre pourquoi vous évite un faux sentiment de sécurité, pire que l'absence totale de chiffrement.

• Le chiffrement côté serveur garde les clés sur le serveur. L'application doit pouvoir déchiffrer vos fichiers pour vous les servir, donc quiconque a accès à la machine en fonctionnement a accès à tout ce que la machine possède. Cela protège contre un disque volé ou un backend de stockage externe non fiable — pas contre un serveur compromis ou son opérateur.
• Le chiffrement de bout en bout est la vraie protection, et il est délibérément limité. Il chiffre côté client pour des dossiers spécifiques, ce qui signifie que le serveur ne peut réellement pas les lire — et signifie tout aussi bien pas d'interface web, pas d'aperçus, pas de recherche côté serveur et pas de liens de partage publics pour ce contenu.
• Le chiffrement intégral du disque sur le serveur protège une machine éteinte. Un serveur en fonctionnement a le volume monté et la clé en mémoire, donc cela défend contre la mise au rebut et la saisie physique d'une machine froide, et rien d'autre.
• Chiffrer avant l'envoi est ce que la plupart des gens veulent réellement. Un outil qui chiffre un dossier localement et synchronise le texte chiffré vous donne une confidentialité réelle avec un Nextcloud tout à fait normal en dessous, au prix des aperçus et de l'accès via le navigateur pour ce dossier.
• Le chiffrement du transport n'est pas le chiffrement du stockage. HTTPS protège les fichiers en transit et rien au repos, et confondre les deux est le malentendu le plus courant dans tout ce domaine.

Pour la plupart des gens, la réponse honnête est mixte. Faites tourner l'instance normalement — c'est votre serveur, et le confort des aperçus, de la recherche et des liens de partage est précisément la raison pour laquelle vous n'utilisez pas simplement une archive chiffrée. Prenez ensuite la minorité de fichiers véritablement sensibles — les papiers, les clés, les choses qui compteraient dans une mauvaise année — et chiffrez-les côté client avant qu'ils n'atteignent jamais le disque. Cela vous donne un cloud utilisable et un vrai coffre-fort, plutôt qu'un compromis médiocre qui prétend être les deux à la fois.

Les fuites d'identité qu'une installation par défaut laisse en place

Nextcloud supprime l'entreprise qui lisait vos fichiers. Il ne supprime pas, à lui seul, tout ce qui rattache le serveur à une personne — et la plupart de ces éléments viennent d'étapes qui semblent sans rapport avec le stockage.

• Le domaine. Un registrar détient votre identité même quand le WHOIS public est expurgé, et il a besoin d'une adresse de contact valide pour garder le nom actif. Le nom d'hôte est la façon la plus courante de retracer un service auto-hébergé jusqu'à son propriétaire.
• La transparence des certificats. Dès qu'un certificat est émis, le nom d'hôte exact est publié dans des journaux publics que n'importe qui peut consulter. Un sous-domaine que vous pensiez privé — cloud.quelquechose, files.quelquechose — est annoncé au monde entier, horodaté.
• L'hébergeur. Si le serveur a été loué avec une carte à votre nom légal, la machine est à votre nom légal, quoi qu'il tourne dessus. Cela se joue à l'inscription, bien avant le premier fichier.
• Les notifications push mobiles. Les applications officielles font par défaut transiter les notifications par les services push des éditeurs de plateforme, ce qui signifie que des métadonnées sur votre instance atteignent Google ou Apple, même si vos fichiers, eux, n'y vont jamais.
• Les métadonnées des photos. Les images transportent des données EXIF, y compris des coordonnées GPS et des identifiants d'appareil. Déplacer une pellicule vers votre propre serveur n'en supprime rien — cela ne fait que la déplacer vers un endroit que vous contrôlez, ce qui est mieux, mais n'équivaut pas à la supprimer.
• Les intégrations externes. Le partage fédéré, les backends de stockage distants, les notifications par email et les vérifications de mise à jour de la boutique d'applications contactent tous l'extérieur depuis la machine, et chacun d'eux est un tiers qui voit votre serveur.
• Les journaux du serveur. Vos propres journaux enregistrent les adresses IP et les user agents de chaque synchronisation. Sur votre propre machine, ce n'est pas un problème — jusqu'à ce que la machine soit saisie, moment où vos journaux deviennent des preuves sur vos propres déplacements.

Refermer ces fuites est un travail ordinaire, pas quelque chose d'exotique. Choisissez un registrar qui accepte la crypto et ne collecte que le strict minimum. Placez la machine chez un hébergeur qui n'a jamais demandé qui vous êtes et payez-la depuis un solde en crypto — Bitcoin est pseudonyme plutôt qu'anonyme, donc recharger en Monero est ce qui referme la trace on-chain si cela compte pour vous. Désactivez les notifications push si les métadonnées vous dérangent, et acceptez le délai de synchronisation que cela entraîne. Et si l'instance n'est jamais destinée qu'à vous et une poignée de personnes de confiance, ne l'exposez pas du tout à l'ensemble d'internet : placez-la derrière un tunnel WireGuard et laissez-la ne répondre que sur ce tunnel — ce qui supprime aussi toute une catégorie d'attaques contre une page de connexion publique.

Faire vivre le serveur après la migration

Un serveur de fichiers qui fonctionne depuis un an est un serveur de fichiers que personne n'a regardé depuis un an. Une brève routine fait toute la différence entre cela et perdre ce que vous l'aviez construit pour protéger.

• Sauvegardez la base de données et l'arborescence de fichiers ensemble, à partir d'un instant cohérent. Une sauvegarde de fichiers sans sa base de données correspondante se restaure en une instance qui semble vide, pleine de fichiers orphelins.
• Gardez une copie qui n'est pas sur le serveur. Un instantané qui vit sur la même machine survit à une panne de disque et à rien d'autre — pas à une compromission, pas à une suppression accidentelle qui se synchronise partout, pas à un compte perdu.
• Restaurez une fois, délibérément, pendant que tout va bien. Une sauvegarde non testée de votre photothèque n'est qu'une hypothèse sur vos souvenirs.
• Mettez à jour au rythme du projet et ne sautez jamais de version majeure. Nextcloud se met à niveau une version majeure à la fois, et en sauter deux d'un coup est une migration que vous devrez démêler à la main.
• Surveillez l'espace libre avec une vraie marge. Les mises à niveau ont besoin de place pour travailler, et un disque qui se remplit pendant une migration de base de données, c'est exactement comment une mise à jour de routine se transforme en restauration.
• Vérifiez que les tâches de fond tournent réellement. La génération des aperçus, le nettoyage de la corbeille et l'élagage des versions en dépendent tous, et un cron silencieusement cassé se manifeste des mois plus tard sous la forme d'un disque mystérieusement plein.

Ajoutez au passage un contrôle externe — quelque chose qui va chercher la page de connexion depuis l'extérieur et se plaint dès qu'elle cesse de répondre vous informe que l'instance est en panne avant qu'un client de synchronisation en file d'attente ne le fasse. Et traitez la machine elle-même comme le décrivent les dix premières minutes sur un nouveau VPS, car l'enjeu sur une machine qui détient chaque document que vous possédez n'est pas moindre que sur une machine qui détient de l'argent.

Les erreurs qui font perdre leurs fichiers aux gens

• Installer sur SQLite parce que c'était la valeur par défaut, puis le regarder se bloquer la première fois que deux appareils synchronisent simultanément.
• Traiter la corbeille et les versions de fichiers comme une sauvegarde, et découvrir qu'elles n'en sont pas une le jour où un client de synchronisation propage une suppression partout.
• Migrer toute la photothèque avant de configurer les sauvegardes, et vivre pendant un mois dans la fenêtre où l'unique copie se trouve sur une machine louée.
• Activer le chiffrement côté serveur, en conclure que les fichiers sont désormais privés vis-à-vis de l'hébergeur, et agir sur la base de cette croyance.
• Dimensionner le disque pour ce que les fichiers pèsent aujourd'hui, sans marge pour les versions, la corbeille et les aperçus.
• Sauter la configuration du cache mémoire et des tâches de fond, puis blâmer le matériel pour une instance qui semble lente.
• Laisser les limites d'upload à leurs valeurs par défaut, et découvrir en pleine migration que tout fichier volumineux échoue silencieusement.
• Sauter deux versions majeures en une seule mise à niveau parce que l'instance est restée sans y toucher pendant un an.
• Louer le serveur et enregistrer le domaine à votre propre nom, après avoir fait tout le reste correctement.

Nextcloud fait partie des rares projets auto-hébergés qui égalent véritablement le produit commercial qu'ils remplacent sur ce qui compte au quotidien — la synchronisation fonctionne tout simplement, l'application mobile fonctionne tout simplement, et au bout d'une semaine vous cessez de remarquer la différence. L'installation prend un après-midi et la migration une nuit. Ce qui vous reste, c'est chaque fichier que vous possédez, sur une machine qui ne répond qu'à vous, payée depuis un solde en crypto, chez un hébergeur qui n'a jamais demandé votre nom. Dimensionnez le disque pour ce que les données deviendront plutôt que pour ce qu'elles sont, chiffrez côté client la petite part qui en a vraiment besoin, et mettez en place la sauvegarde avant d'en avoir besoin plutôt qu'après.