Deux fondateurs, même pile Laravel. L'un paie 12 € par mois de VPS et passe deux soirées par mois sur nginx et fail2ban. L'autre paie 89 € par mois de PaaS et pousse en git — mais découvre une facture de sortie réseau après un export CSV massif. Aucun n'a « gagné » : ils ont placé la complexité à des endroits différents.
PaaS ou serveur n'est pas une question de modernité. C'est : quelle partie du problème voulez-vous posséder — et laquelle pouvez-vous vous permettre de déléguer ? Le bon choix est celui où votre goulot — compétence, temps, argent — est le moins pénalisé.
Ce que vous déplacez avec un PaaS
| Responsabilité | VPS / dédié | PaaS courant |
|---|---|---|
| Système, noyau, durcissement SSH | Vous | Fournisseur |
| Déploiement (git push, build) | Vous scriptez | Intégré |
| Montée en charge horizontale | Vous (ou orchestrateur) | Souvent intégrée |
| Sauvegardes Postgres point-in-time | Vous ou extension | Souvent extension managée |
| Version PHP exacte | Total | Parfois limitée |
| Débogage réseau bas niveau | Total | Restreint |
Le PaaS achète du temps cognitif contre de la flexibilité et parfois du surcoût au compteur — secondes processeur, sortie réseau, workers.
Quand le serveur (VPS) reste le bon choix
Le VPS reste pertinent lorsque vous avez besoin d'un accès root complet : modules noyau, VPN site à site, pile logicielle exotique. Il convient aussi si vous visez un coût d'infrastructure minimal et disposez d'une compétence sysadmin en interne, ou si la conformité exige un contrôle fin que le PaaS ne permet pas. Une charge stable — sans prime pour une montée en charge automatique inutilisée — favorise le serveur dédié ou le VPS.
Une équipe à l'aise avec Docker, la CI/CD et la supervision tirera parti de cette liberté. Hetzner, OVH VPS, Infomaniak VPS : comparez dans l'annuaire en croisant région, sauvegardes et support.
Quand le PaaS se défend
Le PaaS prend sens lorsque l'exploitation infrastructure est faible ou absente — fondateurs développeurs sans administrateur système. Un déploiement fréquent, plusieurs fois par semaine, avec des environnements de prévisualisation, justifie souvent la plateforme managée. Une montée en charge imprévisible modérée et des environnements multiples — staging et production natifs, comme décrit dans environnement staging — accélèrent le passage du prototype à la production sans écrire Ansible.
Clever Cloud, Platform.sh, Render, Railway : lisez attentivement la tarification de sortie réseau et les politiques de mise en veille avant de vous engager.
Hybride et erreurs de trancher
Beaucoup d'équipes matures combinent PaaS pour les applications sans état, stockage objet plus base managée, et VPS pour les workers batch ou les outils internes. Les erreurs fréquentes méritent d'être nommées : choisir un VPS « pour économiser » sans compétence — fail2ban absent, sauvegardes fictives ; choisir un PaaS « pour aller vite » sans lire la facturation de sortie réseau ; migrer vers Kubernetes alors qu'un PaaS ou un VPS suffisait ; ignorer la réversibilité — export de base jamais testé.
Le sommet : déléguer l'infra ne délègue pas la responsabilité
Comparez via le comparateur et par usage.
Décider et avancer sans angle mort
Chiffrez vos heures d'exploitation infrastructure par mois aujourd'hui et la cible acceptable demain. Listez les contraintes non négociables — accès root, région Union européenne, pile imposée. Estimez le coût total PaaS sur douze mois incluant sortie réseau et workers. Si le doute persiste, testez les deux modèles un mois avec la même application. Documentez enfin une procédure d'export de base testée — la réversibilité se prouve le jour du changement, pas sur la slide architecture.
Questions fréquentes
PaaS signifie-t-il zéro exploitation ?
Non. Vous opérez toujours l'application, les migrations, les secrets et souvent le débogage de performance. Le PaaS retire surtout le système, les correctifs noyau et parfois le déploiement Git. La responsabilité vis-à-vis des utilisateurs reste la vôtre.
Un VPS est-il toujours moins cher ?
Sur la facture infra, souvent oui. Ajoutez temps d'administration, supervision, sauvegardes et sécurité : un fondateur seul peut payer plus cher en heures qu'un PaaS milieu de gamme. Calculez sur douze à trente-six mois.
Dépendance PaaS : comment la limiter ?
Standards ouverts (conteneur, Postgres standard), export de données régulier, évitez les services propriétaires irremplaçables sans couche d'abstraction. Testez une sortie avant d'engager des données critiques.
Données sensibles UE : PaaS ou serveur UE ?
Les deux peuvent convenir. Exigez contrat de sous-traitance, région documentée, sous-traitants listés — Clever Cloud, Scaleway ou VPS chez un hébergeur UE. Le guide RGPD et hébergeur détaille les questions à poser.
PaaS ou serveur : la bonne réponse indique où vous acceptez de penser le week-end — pas quel logo mettre sur la slide architecture.