Faut-il encore donner un accès SSH pour publier une correction ?

À quoi sert réellement SSH

SSH est un accès puissant : il permet d’exécuter des commandes directement sur le serveur, de manipuler des fichiers et des services. C’est indispensable pour certaines tâches d’infrastructure ou de diagnostic avancé.

Mais publier une correction courante — un module, un thème, une règle de prix — ne nécessite pas forcément cet accès. Ce qui compte alors, c’est de vérifier que la boutique vend toujours, pas d’ouvrir un terminal.

Le réflexe « pour publier, il faut SSH » mélange deux besoins : l’intervention technique rare et la validation métier fréquente. Les distinguer réduit les risques.

Les risques d’un accès SSH banalisé

Chaque accès SSH distribué élargit la surface d’attaque. Un identifiant qui traîne, un prestataire qui garde un accès après la fin d’une mission, et la production devient vulnérable.

Un accès direct mal utilisé peut aussi provoquer une panne : une commande lancée sur le mauvais serveur, un fichier supprimé par erreur. La puissance de SSH est aussi sa dangerosité.

Enfin, le commerçant ne contrôle pas ce qui se passe en SSH. La validation lui échappe : il ne voit pas le changement, il fait confiance. Or la décision métier devrait rester visible.

La méthode : réserver SSH aux cas qui l’exigent

Pour les changements courants, remplacez l’accès serveur par une validation web : une preview testable que le commerçant ou le chef de projet vérifie dans son navigateur.

Gardez SSH pour les cas techniques rares (diagnostic profond, opération d’infrastructure), avec des accès limités dans le temps et tracés. Le quotidien passe par la validation, l’exception par l’accès privilégié.

DriftOps publie depuis cette validation claire : le changement est vérifié sur une preview, approuvé, puis mis en ligne, sans exposer le serveur à chaque correction.

Publication par SSH vs validation web

Publier par SSH paraît direct, mais reste réservé aux techniciens et laisse peu de trace métier. Le client ne voit pas le changement, et l’accès doit être maintenu et sécurisé dans le temps.

Une validation web rend le changement visible et décidable par une personne non technique, tout en gardant les accès serveur fermés pour les opérations courantes.

Cas d’usage : corriger un module de livraison

Une agence corrige un module de livraison sur une boutique PrestaShop. Plutôt que de demander un accès SSH au client, elle prépare le correctif et le présente sur une preview.

Le client teste une commande sur la copie, vérifie que le bon transporteur apparaît, puis valide. Aucun accès serveur ne lui est demandé, et l’agence n’a pas eu besoin d’ouvrir la production.

La correction est publiée après validation, avec une trace claire de qui a approuvé, sans élargir la surface de risque.

Checklist pour limiter le recours à SSH

Quelques principes réduisent la dépendance aux accès serveur.

• Identifier les changements courants publiables via validation web.
• Réserver SSH aux interventions techniques rares.
• Limiter les accès SSH dans le temps et les tracer.
• Retirer les accès des prestataires en fin de mission.
• Donner au commerçant une preview à valider plutôt qu’un accès.
• Conserver une trace de validation pour chaque publication.

Mesurer la réduction de l’exposition

Suivez le nombre d’accès SSH actifs et la part des publications réalisées sans accès serveur. Les deux doivent diminuer à mesure que la validation web prend le relais.

Comptez aussi les incidents liés à une manipulation serveur : leur baisse confirme que limiter SSH réduit réellement le risque.

Conclusion : SSH en exception, pas en routine

SSH ne doit pas être le passage obligé de chaque correction. Pour les changements courants, une validation web protège mieux la boutique et garde la décision côté métier.

En réservant l’accès serveur aux cas qui l’exigent vraiment, vous réduisez l’exposition et les erreurs. DriftOps rend la publication possible sans ouvrir le serveur.