WebAcappella Fusion rend la création de site web accessible. Conséquence directe : les utilisateurs s'enhardissent. Ce qui devait être un site vitrine de cinq pages devient un portail de 200 pages, un blog accumulé sur cinq ans, une boutique de 600 produits. Au début, ça grandit naturellement. Et puis un jour, la publication commence à durer dix minutes. Puis quinze. Puis vingt. Et ce n'est pas la construction du site qui rame — c'est le transfert vers le serveur.
Le succès qui fait grossir les sites
Plus un outil est accessible, plus il attire des projets ambitieux. C'est exactement le destin de WebAcappella Fusion : une mairie qui ajoute toutes ses délibérations sur cinq ans (300 pages), un cabinet d'avocats qui publie une fiche par décision (450 pages), un photographe qui fait une page par mariage (800 pages avec galeries), une boutique qui finit avec 1 200 références. Ces sites existent. Ils tiennent dans WA Fusion sans broncher : la construction multiprocessus les génère en quelques dizaines de secondes, même quand ils dépassent les 500 fichiers.
Mais une fois le site construit, il faut encore l'envoyer sur le serveur. Et c'est là que les choses se compliquent.
Le moment où la publication devient un calvaire
Sur un site de cinq pages, la publication FTP est invisible : trois secondes, c'est terminé. Sur un site de 500 pages avec ses images, ses CSS, ses JS, ses pages produit, le scénario change. Voici ce que vivent les utilisateurs de gros sites :
- Une publication qui prend 15 à 30 minutes, pendant lesquelles on n'ose plus toucher à l'ordinateur
- Des échecs à 80 % : la connexion lâche, le client FTP se déconnecte, il faut tout recommencer
- Des fichiers manquants : un transfert interrompu laisse une partie du site dans l'ancienne version, l'autre dans la nouvelle
- Des fichiers corrompus : un transfert binaire mal géré, et l'image apparaît cassée en ligne
- Le doute permanent sur ce qui est réellement en ligne après une publication chaotique
Ce n'est pas un défaut de WebAcappella, ni de votre hébergeur, ni de votre connexion internet. C'est une limite structurelle du protocole utilisé.
FTP : un protocole de 1971
FTP, pour File Transfer Protocol, a été spécifié en 1971. Le contexte de l'époque : quelques chercheurs s'envoyaient des fichiers entre laboratoires sur ARPANET. À ce moment-là, transférer une centaine de fichiers d'un coup n'était même pas un cas d'usage envisagé. FTP a été conçu pour de la transaction simple, pas pour de la synchronisation efficace de milliers de fichiers.
Cinquante ans plus tard, le protocole est toujours là, et ses limites structurelles aussi :
- Pas de transfert différentiel à l'intérieur des fichiers : si un fichier a changé d'un seul octet, FTP le réenvoie en entier
- Une connexion (ou presque) par fichier : la négociation TCP s'additionne fichier après fichier, ce qui plombe les sites avec beaucoup de petits fichiers
- Pas de vérification d'intégrité native : FTP ne sait pas dire si un fichier est arrivé identique à l'original
- Pas de reprise automatique : une coupure réseau et le transfert repart de zéro (ou laisse un état incohérent)
- Échec partiel = site cassé : si la moitié des fichiers passe et l'autre échoue, votre site est en ligne dans un état mixte impossible à diagnostiquer
Sur un site de cinq pages, ces limites sont invisibles. Sur un site de 500 pages, elles deviennent paralysantes.
rsync : un algorithme pensé pour ça
rsync, créé en 1996 par Andrew Tridgell pour sa thèse de doctorat, n'est pas un protocole de transfert : c'est un algorithme de synchronisation différentielle. La différence est fondamentale. Là où FTP transfère, rsync compare puis transfère — uniquement ce qui a changé.
Concrètement, voici ce que rsync fait que FTP ne sait pas faire :
- Delta encoding intra-fichier : si vous modifiez deux paragraphes dans une page HTML, rsync ne renvoie que les blocs modifiés à l'intérieur du fichier — pas le fichier entier
- Une seule connexion SSH multiplexée : tout le transfert passe par un canal sécurisé unique, sans renégociation à chaque fichier
- Compression à la volée : les données sont compressées avant l'envoi et décompressées à l'arrivée, ce qui réduit drastiquement le volume sur le réseau
- Checksum d'intégrité sur chaque fichier transféré : aucun risque de fichier corrompu
- Reprise automatique en cas d'interruption : si la connexion lâche, rsync reprend exactement où il s'est arrêté
- Suppression coordonnée (option
--delete) : les fichiers supprimés localement sont aussi supprimés côté serveur, ce qui évite l'accumulation de vieux fichiers fantômes
Le résultat : sur un site de 500 pages où vous modifiez trois paragraphes, FTP renverrait potentiellement plusieurs fichiers entiers. rsync envoie quelques kilo-octets et c'est terminé.
Intégré nativement dans WebAcappella Fusion
rsync est habituellement réservé aux administrateurs système : ligne de commande, gestion des clés SSH, options à mémoriser. Rien de tout ça n'est demandé à l'utilisateur de WebAcappella Fusion. L'intégration est complète et invisible.
Dans les paramètres de publication de votre site, le mode rsync est disponible aux côtés de FTP et SFTP. Vous renseignez vos identifiants SSH, WA Fusion gère le reste : la synchronisation, la compression, le rapport d'avancement, la reprise en cas de pépin. Vous cliquez sur « Publier », et c'est tout.
Vos projets, vos contenus, vos identifiants ne changent pas : seul le mécanisme de transfert vers le serveur évolue. Vous pouvez basculer de FTP à rsync sur un site existant sans perdre quoi que ce soit.
Notre expertise sur rsync ne s'arrête pas à WebAcappella Fusion. Intuisphere développe et maintient également RsyncBrowser, un client SSH/rsync graphique standalone pour les utilisateurs qui ont besoin d'orchestrer leurs synchronisations en dehors de l'éditeur de site : sauvegardes de serveur, miroirs de données, déploiement de scripts, transferts ponctuels de gros volumes. C'est en partie cette expérience accumulée sur le terrain qui nous a permis d'intégrer rsync dans WA Fusion avec autant de finesse — gestion des clés SSH, reprise propre, rapport d'avancement clair.
Disponible chez les hébergeurs avec accès SSH
rsync ne fonctionne pas par-dessus FTP : il a besoin d'un accès SSH côté serveur. C'est cette exigence qui explique pourquoi tous les hébergeurs ne peuvent pas le proposer. Les offres mutualisées d'entrée de gamme se limitent souvent au FTP simple, sans SSH.
Les hébergeurs qui supportent l'accès SSH (et donc rsync dans WebAcappella Fusion) :
- o2switch : SSH activé par défaut sur tous les comptes — rsync fonctionne immédiatement, sans configuration particulière
- OVH : disponible sur certaines offres (mutualisé Performance, hébergements VPS et dédiés). Vérifiez sur l'espace client la présence d'un accès SSH
- Hébergeurs Linux avec SSH activé : tout fournisseur qui propose un accès shell fonctionne (Infomaniak, PlanetHoster, et la majorité des VPS)
Si votre offre actuelle ne propose que du FTP, deux options : conserver la publication FTP (qui reste pleinement fonctionnelle, simplement moins efficace sur les gros sites), ou migrer vers une offre incluant SSH si la taille de votre projet le justifie.
Le bénéfice concret : la vitesse maximale de votre connexion
Avec rsync intégré dans WebAcappella Fusion, le débit de publication correspond quasi-directement au minimum entre la vitesse montante de votre connexion internet et la capacité d'écriture de votre hébergeur. Il n'y a plus de surcoût protocolaire qui ralentit l'ensemble.
En clair :
- Une mise à jour ponctuelle (quelques pages modifiées sur un site de 500) prend quelques secondes — le temps d'envoyer les deltas
- Une publication initiale complète d'un gros site prend exactement le temps de transférer ses fichiers à votre vitesse de connexion. Pas plus
- Plus de timeouts, plus de reprises manuelles, plus de doute sur l'état du site en ligne
Combiné avec la construction multiprocessus côté local, le pipeline complet — depuis « j'ai modifié du contenu » jusqu'à « le visiteur voit la nouvelle version » — devient quasi instantané, même sur les sites les plus volumineux.
Pour qui, à quel moment ?
Si votre site fait quelques pages et que la publication FTP prend dix secondes, vous n'avez objectivement pas besoin de rsync. Restez sur ce qui marche.
Si votre projet grandit, si vous commencez à éviter de publier parce que ça prend trop de temps, si vous avez déjà eu une publication interrompue qui a laissé votre site dans un état douteux : c'est le signal. Vérifiez si votre hébergeur propose SSH, basculez en mode rsync dans les paramètres de publication, et la différence est immédiate.
C'est typiquement le genre de fonctionnalité dont on n'a pas conscience qu'on en a besoin… jusqu'au jour où on l'a, et où on se demande comment on faisait avant.