De FileZilla à Siovos : pourquoi j'ai construit mon propre outil de déploiement

Mon premier déploiement, c'était sur GitHub Pages. Un repo, un DNS automatique en mon-repo.github.io, et c'était en ligne. Magique. Mais très vite, j'ai voulu mon propre nom de domaine, mon propre serveur. Et là, sans le savoir, c'était le début de quelque chose.

FileZilla et le Site du Zéro

J'ai loué mon premier serveur. Je ne savais même pas ce qu'était un VPS à l'époque, ni comment transférer mes fichiers dessus. J'ai cherché un tuto sur le Site du Zéro (maintenant OpenClassrooms) - et j'ai trouvé un guide pas à pas qui utilisait FileZilla. Un client FTP avec une interface graphique : tu glisses tes fichiers à gauche, ils apparaissent sur le serveur à droite.

Ça marchait. C'était même satisfaisant. J'ai refait ça sur plusieurs serveurs, avec plusieurs projets - qui n'ont jamais vraiment décollé pour la plupart, mais l'important avec le recul c'était le processus. À chaque fois, je comprenais un peu mieux ce qui se passait sous le capot.

WordPress, le clic magique et la réalité

Puis j'ai découvert WordPress. À l'époque, des gens autour de moi avaient besoin de sites web, et WordPress c'était la promesse du site en un clic. Et c'était vrai - sur 1&1 (devenu Ionos), tu cliquais sur "Installer WordPress", et deux minutes plus tard tu avais un site en ligne. C'est comme ça que j'ai découvert le déploiement simplifié : en montant des WordPress pour d'autres.

Mais moi j'étais développeur. Je me suis dit que j'aurais sans doute plus de succès pour mes idées de business en ligne en codant dans WordPress, et en parallèle je pouvais aussi le faire pour des clients. J'ai donc téléchargé le ZIP de WordPress en local, j'ai commencé à développer dedans, et là... le problème est arrivé : comment déployer mon code sur un serveur ?

C'est là que j'ai découvert les tutos DigitalOcean, que je suivais religieusement, étape par étape. Et ces tutos m'ont confronté à un monde que je ne connaissais pas encore bien. Il fallait se balader dans le serveur en SSH, utiliser scp pour copier des fichiers, configurer Apache, créer des bases de données, éditer des fichiers avec Vim pour la première fois. Des choses "simples" pour un sys admin, mais qui étaient un monde nouveau pour moi.

Le script qui ne servait à rien (mais qui a tout changé)

À force de répéter les mêmes commandes à chaque déploiement - connexion SSH, copie des fichiers, relance d'Apache, vidage du cache - le réflexe est venu naturellement : tout mettre dans un script. En me basant sur les tutos DigitalOcean, j'ai automatisé les étapes de déploiement. Mon script était nul, vraiment. Mais à l'époque, une fois que j'avais un état stable de ce script, je me disais qu'avec ça je pouvais faire de grandes choses. Je ne me doutais pas que cette habitude finirait par devenir un produit.

Le problème, c'est que ce script ne servait pas à grand-chose. Il existait déjà des outils bien meilleurs, plus fiables, avec des interfaces, et plein d'autres avantages. J'ai donc laissé cette idée d'en faire quelque chose d'industrialisable, et j'ai continué mon chemin de développeur.

Les rencontres qui font progresser

Et puis j'ai rencontré un développeur qui avait un passé de sys admin. Un mec très inspirant, très bonnes valeurs, droit dans ses bottes. J'ai beaucoup appris de lui. Sans le nommer entièrement, Rémi C. a probablement eu plus d'influence sur ma rigueur technique qu'il ne le pense.

Rémi faisait du code hyper propre. Il aimait le détail et savait reconnaître ce qui était bien construit de ce qui ne méritait pas vraiment d'attention. De par son passé de sys admin, ses scripts shell étaient structurés avec soin - des variables de couleur en en-tête, un affichage clair des étapes dans le terminal. C'est là que j'ai compris qu'un outil en ligne de commande pouvait aussi avoir une vraie UX.

J'ai voulu reprendre mon script de déploiement. Pas avec une grande ambition, juste le refaire en mieux, en m'inspirant de ce que Rémi faisait. Apprendre en refaisant.

Docker, la pipeline, et le déclic

Les années ont passé. J'ai pris en main Docker, qui a changé une fois de plus ma façon de développer. Au travail, j'ai découvert ce qu'était une architecture professionnelle : GitLab CI pour la pipeline, des environnements conteneurisés, une zone exposée mais maîtrisée, et surtout une zone interne - des services accessibles uniquement par les équipes, invisibles depuis internet.

C'est ce côté interne qui m'a amené vers Siovos.

J'avais déployé des outils open source pour mes projets perso, mais contrairement au travail, tout était exposé sur le web. Strapi, Grafana, des outils d'admin - accessibles publiquement avec un simple login/mot de passe. Ça ne me plaisait pas. On peut scanner et voir ce qu'on utilise. Et une porte d'entrée, même fermée, ça donne une indication aux intéressés.

Au-delà de ça, si un seul des outils qui n'avaient aucune raison d'être exposés publiquement avait une faille, ça multipliait mes chances d'avoir un problème. Avoir des outils en interne n'élimine pas complètement le risque, mais on passe à une étape supérieure.

Le VPN, le VPS partagé, et la reprise de zéro

C'est là que mon deuxième parcours a commencé. Comment ajouter un VPN sur mon serveur ?

Problème : mon serveur était partagé. Je ne le savais pas encore, mais il ne me permettait pas d'installer et configurer les outils que je souhaitais. Seule une liste très restreinte était disponible - suffisante pour mettre des sites web en ligne, mais pas assez pour construire une architecture d'entreprise comme celle que je côtoyais quotidiennement au travail.

J'ai donc pris un nouveau VPS sur Hostinger, et j'ai repris de zéro. Cette fois, il fallait ajouter OpenVPN - un bon VPN, mais qui s'est avéré très compliqué à mettre en place pour moi. Les questions d'accessibilité, d'ouverture et fermeture réseau - cette fois, il n'y avait plus de tuto à suivre aveuglément. Il fallait vraiment comprendre ce que je faisais.

De l'artisanat à Siovos

De par mon expérience, j'avais compris l'intérêt d'avoir un script pour pouvoir itérer. Je remettais le serveur à zéro avec un Debian vierge, et je recommençais. Installation par installation, parfois en reculant parce qu'un ordre précis devait être respecté, mais au moins j'avais un script. Le problème, c'est qu'il était devenu impossible à maintenir.

Je me suis dit que ce travail, quelqu'un l'avait forcément industrialisé avant moi. J'ai découvert Ansible, qui m'a permis de penser de façon plus structurée - en modules, en briques réutilisables, avec la possibilité de redéployer partiellement et de manière idempotente. Ma façon de travailler a changé, et le résultat était enfin professionnel.

Et puis l'idée est venue naturellement : pourquoi ne pas rendre accessible ce qui m'avait demandé des mois d'itérations pour stabiliser ? Derrière chaque déploiement qui marchait du premier coup, il y avait des remises à zéro du serveur, des corrections, des ajustements - encore et encore. Construire une interface, permettre à d'autres équipes de ne pas refaire ce chemin. C'est comme ça que Siovos a démarré - pas sur un business plan, mais sur une frustration partagée.

Aujourd'hui, Siovos Desktop déploie en 15 minutes ce qui me prenait des jours :

• Kubernetes (K3s) - orchestration de conteneurs, prêt pour la production
• VPN WireGuard - infrastructure invisible depuis internet
• DNS privé - résolution interne automatique
• Certificats SSL - TLS automatique via une PKI interne
• Reverse proxy - Traefik configuré avec rate limiting et security headers
• CI/CD - GitHub Actions connecté au cluster
• Monitoring - Grafana et Prometheus préconfigurés

Tout configuré, tout sécurisé, tout accessible via VPN.

C'est l'outil que j'aurais aimé avoir quand je transférais mes fichiers avec FileZilla.

Si vous êtes développeur ou que vous gérez une équipe technique, et que votre infrastructure tient encore sur des scripts maison ou des déploiements manuels, ce parcours vous parle probablement. Siovos Desktop a été construit exactement pour ça.

Télécharger Siovos Desktop gratuitement →