Favok
Développeur full-stack & auteur
Le freelance français ne compare pas « Vercel vs AWS » comme un slide américain. Il compare un mutualisé OVH, o2switch ou Infomaniak d'un côté, et un Worker ou du Pages de l'autre. Les trois questions qui décident sont concrètes : combien coûte la facture en euros, où vit le courrier, et qui publie le site quand votre PC est éteint.
Ce n'est pas un comparatif de quatorze hébergeurs. C'est une méthode de décision par mode de panne, plus l'ordre exact d'une bascule qui ne coupe pas les mails. Si la boîte contact@ tombe le jour du flip DNS, le blog joli ne sert à rien et le client s'en souviendra plus longtemps que du temps de chargement.
Avant de comparer des grilles tarifaires, écrivez trois phrases. Elles tranchent la décision plus vite qu'un tableau.
Un indépendant qui ne sait répondre à aucune des trois choisira mal quel que soit le fournisseur. Ces phrases finissent aussi dans la proposition commerciale, ce qui évite les malentendus au premier incident.
PHP existant, tâches planifiées depuis le panneau, webmail sur le même serveur. Le courrier vit déjà là et c'est le point qu'on oublie systématiquement. Le piège classique : pointer le .fr vers un nouveau DNS sans recopier MX, SPF et DKIM. La procédure détaillée est ici : MX et SPF sur un .fr.
Le mutualisé fatigue à deux endroits. Premièrement, quand chaque déploiement est un FTP du vendredi soir : pas d'historique, pas de retour arrière, et un functions.php écrasé qui ne revient pas. Deuxièmement, quand une extension WordPress mange le CPU partagé et que l'hébergeur bride le compte sans prévenir clairement.
Ce n'est pas une raison pour tout casser le même week-end. Faites l'inventaire d'abord : les tâches planifiées, les boîtes mail et leurs alias, les certificats, les scripts qui écrivent des CSV quelque part. Cet inventaire prend deux heures et évite deux semaines de rattrapage.
L'avantage français est réel : facture en euros avec TVA récupérable, support téléphonique dans votre fuseau, et une interface que vous connaissez. L'inconvénient : un seul serveur, souvent sans chaîne de publication automatique.
Vitrine, blog, API légère, documentation. Le stockage clé-valeur n'est pas une base relationnelle : membres, commandes et stock demandent une autre source de données. Prévoyez-la dès le départ plutôt que de la découvrir au troisième client.
Le vrai gain est la publication. Un git push déclenche une prévisualisation puis la production. Vous partez en déplacement, le site se met quand même à jour, et un retour arrière est un commit, pas un souvenir. Pour un indépendant seul, c'est la différence entre un service et un hobby.
Le démarrage à froid se voit peu sur du HTML léger. Un rendu serveur lourd et des images non optimisées coûtent en revanche du temps de réponse et de l'argent. Ne recopiez pas « l'edge résout tout » sans avoir mesuré votre propre page.
Dix minutes de mesure valent mieux qu'un comparatif. Faites-le sur votre site actuel, pas sur un exemple.
1. Ouvrez les trois pages les plus lourdes : accueil, une page de contenu, une page de listing.
2. Dans les outils de développement, onglet réseau, cache désactivé, rechargez. Notez le poids total transféré et le nombre de requêtes.
3. Multipliez par vos pages vues mensuelles. Une page à 1,5 Mo et 20 000 vues font environ 30 Go de transfert par mois.
4. Comptez l'envoi de newsletter comme une ligne séparée. Le pic d'un mardi soir n'est pas la moyenne du mois.
Cette mesure explique pourquoi un « hello world » ment. Vos images de couverture ne pèsent pas 40 Ko. Le choc de facture vient exactement de là, et il se règle souvent en redimensionnant les images avant de changer d'hébergeur.
Comptez quatre lignes : HTML et fichiers statiques, images, requêtes dynamiques, stockage. Ajoutez une cinquième ligne pour le courrier si le webmail quitte le serveur mutualisé. Le tarif affiché sur un blog américain n'est pas votre facture, ne serait-ce qu'à cause du change et de la TVA.
Le mutualisé « illimité » cache généralement le CPU partagé et le nombre d'inodes. Le modèle à l'usage cache la bande passante et le nombre de requêtes. Les deux ont une limite ; la différence est ce qui arrive quand vous la touchez. Sur le mutualisé le site ralentit, à l'usage la facture monte.
N'ajoutez pas un second fournisseur « au cas où ». Une deuxième facture ne se justifie que si vous nommez la panne qu'elle évite. Un seul plafond, une seule alerte, et une page tarifs qui dit la même chose que la facture réelle. Pour le cadre auto-entrepreneur et le formulaire, voir auto-entrepreneur et RGPD.
Même règle que pour un .fr : recopiez les MX avant de toucher aux serveurs de noms. Un enregistrement MX derrière un proxy HTTP casse la remise ; le SMTP n'a rien à faire là. Un seul enregistrement SPF, jamais deux, sinon la politique devient invalide.
Le webmail du mutualisé disparaît si vous quittez le serveur. Prévoyez la boîte ailleurs — un service de messagerie dédié ou une offre MX séparée — avant la bascule, pas le soir même. Le blog ne remplace pas la boîte, et un client dont le devis part dans le vide ne revient pas.
Vérifiez avec deux résolveurs publics différents, plus un envoi aller-retour depuis une adresse externe. Si le courrier ne revient pas, vous savez quoi restaurer : les anciens serveurs de noms chez le registrar, pas la zone que vous venez de créer.
Exportez la zone complète. Recréez les enregistrements web et courrier chez la cible sans changer les serveurs de noms. Publiez une préproduction avec le vrai poids d'images. Baissez les TTL vingt-quatre à quarante-huit heures à l'avance. Basculez, notez l'heure UTC, puis vérifiez avec deux résolveurs.
Si le courrier est mort, revenez aux anciens serveurs de noms. N'empilez pas un deuxième changement pour « voir ». Gardez ensuite quarante-huit heures d'observation : rejets de messages, échecs SPF, montant sur la carte.
N'inventez pas un troisième intermédiaire réseau « pour la performance » le soir de la bascule. Un changement DNS à la fois, sinon vous ne saurez jamais lequel a cassé quoi.
Écrivez trois choses : qui publie, depuis où, et comment revenir en arrière. Un commit est un retour arrière ; un FTP écrasé n'en est pas un. Si vous restez sur du mutualisé, vérifiez la durée de rétention des sauvegardes et le temps de restauration. Une sauvegarde qui met six heures à revenir n'est pas un plan, c'est un espoir.
Les journaux : où sont-ils, combien de jours, qui y accède. Un indépendant soumis au RGPD ne conserve pas des journaux « au cas où » sans finalité écrite. Une ligne dans la politique suffit, mais elle doit être vraie.
La vitrine chez l'un, l'API existante chez l'autre, c'est viable si les hôtes sont nommés : www d'un côté, api de l'autre, mail en dehors de tout proxy. Écrivez cette répartition quelque part ; sans elle, vous payez deux factures et diagnostiquez une seule panne.
L'hybride crée deux modes de panne distincts. La vitrine peut tomber pendant que l'API répond, ou l'inverse. Dites au client quelle partie est touchée plutôt que « maintenance en cours » : la phrase exacte divise les relances par deux.
1. Trois phrases de panne écrites : facture, courrier, portable éteint.
2. Poids réel mesuré sur vos trois pages les plus lourdes.
3. MX, SPF et DKIM recopiés avant tout changement de serveurs de noms.
4. Un plafond de dépense et une alerte sur la carte.
5. Un retour arrière testé, pas supposé.
6. Si hybride : chaque sous-domaine attribué par écrit.
L'offre gratuite tient-elle sur la durée ? C'est une rampe d'accès, pas une promesse commerciale. Ne l'écrivez pas dans une proposition client : écrivez un plafond de dépense et ce qui se passe quand on l'atteint.
Faut-il ajouter un second fournisseur ? Seulement si vous nommez la panne qu'il évite. « Au cas où » n'est pas une raison, c'est une deuxième facture et un deuxième tableau de bord à surveiller.
Puis-je traduire un comparatif anglophone ? Non. L'intention française porte sur l'euro, la TVA, le .fr, le mutualisé et le support dans le fuseau. Un article traduit ne répond à aucune de ces cinq questions.
Peut-on garder WordPress sur une plateforme à l'usage ? Rarement tel quel. Faites l'inventaire des extensions et des tâches planifiées d'abord. Beaucoup de code PHP n'a rien à faire dans un environnement d'exécution léger, et le réécrire coûte plus cher que le mutualisé.
Quand faire la bascule ? Pas un vendredi, pas en fin de mois, pas pendant une campagne. Le matin d'un jour creux, avec le support du registrar joignable et un contact de secours hors du domaine concerné.
« Le site reste en ligne pendant que je suis en déplacement » n'est vrai que si la publication est automatisée. Sinon la phrase honnête est « je publie depuis mon portable, sous quarante-huit heures ». Les deux sont défendables ; c'est le mélange des deux qui produit un avis à une étoile.
Sur la facture, annoncez les postes plutôt qu'un forfait magique : une ligne pour l'hébergement, une pour le courrier s'il déménage, une pour le nom de domaine. Le client accepte une ligne expliquée bien plus facilement qu'une hausse non annoncée.
<!-- favokres-internal-links -->
İlgili okumalar: <a href="/blog/fr-domaine-fr-mx-2026" title="Domaine .fr: MX avant le flip DNS">Domaine .fr: MX avant le flip DNS</a> · <a href="/blog/cloudflare-pages-vs-vercel-solo-founders-2026" title="Cloudflare Pages vs Vercel for solo founders">Cloudflare Pages vs Vercel for solo founders</a> · <a href="/rehber/best-web-hosting-for-bloggers" title="Favokres rehberi">İlgili rehber</a> · <a href="/urunler" title="Favokres ürünleri">Mağaza</a>
Written by
Favok
Développeur full-stack & auteur
Nine years in software — backend and frontend with equal weight, not a slogan. I also spent a year in IT operations, the kind of work that makes you respect uptime. The same hands that ship APIs come from graphic design through modeling, 2D and 3D. I care how a thing looks and how it holds together. Favokres is my personal digital hub: AI-assisted publishing, SEO, a forum, and a shop. An autonomous brain keeps the site moving so pages stay useful, not frozen.
About the author
Fiche Google, avis vérifiés et page service claire: ce qui compte vraiment pour un artisan solo en 2026, sans agence. Étapes concrètes et contrôle live.
Consentement réel, un clic pour se désinscrire, preuve stockée: le double opt-in utile pour un blog solo sans tampon collé. Étapes concrètes et contrôle…
Pages et mail tombent ensemble si vous flippez les NS avant MX, SPF et DKIM. Inventaire, proxy orange, TTL, deux résolveurs.
Écrire pour des freelances français sans chiffres inventés: cadre URSSAF, TVA, et structure de billet utilisable.
Le test de retrait des liens, la mention placée à côté de l'offre, un formulaire RGPD honnête et des prix en euros datés.
Un guide LLC ne paie pas l’URSSAF. Mentions près du formulaire, euros, désinscription réelle.