Déployer un site statique ne devrait pas être une mission lunaire

Avouons-le : mettre en ligne un site statique ne devrait pas ressembler au décollage d'une fusée Falcon.

Pourtant en 2024, on voit encore des développeurs passer des heures à configurer des pipelines CI/CD, rédiger des scripts de déploiement, gérer des variables d'environnement, et se battre avec des plateformes qui promettent la simplicité mais livrent de la complexité. C'est épuisant.

Puis arrive un outil comme pgs.sh — un service de déploiement minimaliste qui fait une seule chose, mais le fait parfaitement.

Le retour de rsync

Ce qui rend pgs.sh élégant, c'est son refus de réinventer la roue. Pas de mécanisme d'upload propriétaire, pas de nouvelle CLI à apprendre. L'outil mise sur ce que les développeurs connaissent déjà : rsync.

Si tu traînes dans le milieu depuis un moment, rsync t'a probablement sorti d'affaire plus d'une fois. C'est le couteau suisse du transfert de fichiers — rapide, fiable, et rodé à l'usage depuis des décennies. pgs.sh lui offre simplement un chez-soi sur le web, avec du TLS automatique en prime.

La commande parle d'elle-même :

rsync -rv public/ pgs.sh:/monprojet/

C'est tout. Ton dossier public/, synchronisé directement vers une URL fonctionnelle. Pas de fichiers YAML. Pas de webhooks. Pas de "merci de patienter pendant que nous préparons votre environnement de build."

Pourquoi ça compte pour les devs et les startups

Voici le problème avec la complexité : elle s'accumule. Un processus de déploiement "juste pour l'instant" a une fâcheuse tendance à devenir de la dette technique qui te hante pendant des mois. Chaque fichier de config, c'est une chose de plus qui peut casser, une chose de plus que les nouveaux membres de l'équipe doivent maîtriser, une abstraction de plus entre toi et la mise en production.

Quand tu retires les couches inutiles, il reste :

De la vitesse. Pas seulement la vitesse de déploiement, mais la vitesse cognitive. Tu ne bascules pas entre des interfaces de dashboard et des pages de documentation. Tu tapes une commande que tu connais déjà.

De la fiabilité. Moins de pièces mobiles, moins de risques de défaillance. Pas de pannes de ton provider CI qui impactent ton workflow. Pas de limites de taux surprises. Juste rsync qui fait ce qu'il fait depuis 1996.

De la portabilité. Les commandes rsync sont un savoir transférable. Le script de déploiement que tu écris aujourd'hui fonctionnera que tu sois sur pgs.sh, ton propre serveur, ou l'infrastructure d'un pote. C'est puissant.

La philosophie derrière l'outil

Il y a une leçon plus large ici, sur les outils qu'on choisit et qu'on construit.

On s'est collectivement convaincus que plus de fonctionnalités égal plus de valeur. Qu'une plateforme de déploiement a besoin d'intégration Kubernetes, d'environnements de preview, de déploiements par branche, d'analytics en temps réel et d'optimisation par IA pour justifier son existence.

Mais pgs.sh pose une question différente : et si la meilleure fonctionnalité était l'absence de fonctionnalité ?

Ce n'est pas de l'anti-progrès — c'est une contrainte intentionnelle. En limitant drastiquement le périmètre, pgs.sh devient incroyablement fiable pour sa mission unique. Pas de matrice de fonctionnalités à naviguer, pas de plans tarifaires à déchiffrer, pas d'upsell vers un plan enterprise.

Pour les startups qui avancent vite et les développeurs qui veulent juste livrer, cette clarté a une vraie valeur.

Où les déploiements simples trouvent leur place

Soyons réalistes : les déploiements rsync en une commande ne sont pas la solution universelle. Les applications complexes avec des APIs backend, des bases de données et du routage dynamique nécessitent une infrastructure plus sophistiquée. C'est là que les cloud platforms, l'orchestration de containers et les pipelines CI/CD complets montrent leur utilité.

Mais pour tous les sites statiques, landing pages, documentations et side projects qui constituent le tissu du web ? L'approche simple gagne.

Et honnêtement ? Même pour des projets plus ambitieux, il y a quelque chose à dire sur le fait de garder le déploiement des assets statiques le plus simple possible, tout en réservant la complexité là où elle apporte vraiment de la valeur.

Réflexions finales

Les meilleurs outils semblent souvent évidents rétrospectivement. Bien sûr qu'un déploiement devrait être aussi simple. Bien sûr qu'on ne devrait pas avoir besoin d'un doctorat en DevOps pour publier un site.

pgs.sh nous rappelle que les outils qu'on utilise au quotidien méritent le même design attentif que les produits qu'on construit. Parfois, l'exploit d'ingénierie le plus impressionnant, c'est de savoir ce qu'on ne va pas construire.

Si tu n'as pas encore experimenté avec des outils de déploiement sans friction, c'est le bon moment pour commencer. Ton futur toi (et tes utilisateurs) t'en remercieront.

Quelle est ta philosophie de déploiement ? Tu kiffes les pipelines complexes ou tu embrasses la simplicité ? Balance en commentaire — on adore discuter de comment vous livrez du code.