Infogérance vs TMA : deux factures, deux métiers. L'hébergeur « s'occupe du serveur ». Le développeur « s'occupe du site ». Le jour où le tunnel de vente renvoie une erreur 500, chacun montre l'autre. Cet article dessine la frontière, ce que je prends en TMA, ce que je laisse à l'infra, et pourquoi un forfait unique « tout compris » à 39 € n'est souvent ni l'un ni l'autre. Voir aussi les articles sur le choix d'un prestataire et le forfait mensuel.
🧾 Infogérance : le dessous
Disque, RAM, réseau, OS, parfois PHP, snapshots, pare-feu. « Le serveur répond ». Ce qu'elle ne couvre pas : vérifier un panier, mettre à jour Elementor, lire un message Messenger en échec.
Un bon infogéreur est précieux. Un infogéreur qui dit « on fait aussi la TMA Woo » sans copie de test : frontière floue.
🛠️ TMA : le dessus
Mises à jour du CMS, plugins, vérification, code, monitoring applicatif, 2FA, XML-RPC, files. Je le fais. Je ne gère pas votre hyperviseur.
Les backups : l'infra a des snapshots, la TMA a des dumps restaurés (article sauvegardes). Les deux.
- Qui restaure une maj plugin ratée
- Qui monte le PHP
- Qui vérifie le panier
- Qui paie l'astreinte du tunnel de paiement
⚠️ Le trou
PHP trop vieux : l'infra peut monter, la TMA doit tester. Un 500 : logs app vs machine. Sans runbook commun, le client attend.
Infogérance vs TMA : deux factures assumées, ou un prestataire qui assume explicitement les deux. Pas un flou.
📞 Un incident, qui appelle qui
Le tunnel renvoie une erreur un samedi. Avec deux prestataires, le runbook dit dans quel ordre on regarde : la TMA lit les logs de l'application, si la cause est la machine (disque plein, base injoignable), elle ouvre un ticket chez l'infogéreur avec les preuves.
Vous n'avez qu'un numéro à appeler, et personne ne renvoie la balle. C'est ça, une frontière écrite.
✅ Ce que je mets par écrit entre infogéreur et TMA
Je note qui possède le serveur, qui possède l'application, qui prévient l'autre lors d'un changement de PHP ou d'une panne. Une page, deux signatures.
Sauvegarde restaurable, accès à votre nom, double authentification pour l'administration. Puis 24 à 72 h de suivi après tout changement serveur. Sans ce suivi, chacun croit que l'autre a vérifié.
- Périmètre serveur et application écrit
- Copie de test avant tout changement de PHP
- Un changement serveur à la fois, annoncé
- Contrôle humain puis 24 h de suivi après chaque changement
📌 Ce que je refuse sur ce sujet
Je refuse les contrats où personne ne sait qui répond lors d'une panne. Je refuse de toucher au serveur d'un autre sans accord écrit. Je refuse les changements de PHP sans test sur l'application.
Je refuse aussi de me taire : si votre infogéreur couvre déjà tout, je vous le dis. Cet article n'est pas un prétexte pour vous faire payer un second contrat.
Le serveur up n'est pas le tunnel de vente up. Deux métiers, deux factures.
🧭 Questions fréquentes
Faut-il clarifier qui fait quoi tout de suite ? Oui si une panne récente est restée sans responsable. Sinon, relisez vos deux contrats avant le prochain renouvellement.
Peut-on laisser l'infogéreur toucher à l'application sans copie de test ? Rarement : changer la version de PHP côté serveur peut casser le site. Il faut une copie sur laquelle on vérifie avant de toucher à la production.
Combien de temps pour répartir les rôles ? Une réunion et une page écrite suffisent : qui surveille quoi, qui répond à qui, en combien de temps. Le reste se règle à l'usage.
