La plupart des projets web se terminent au lancement. L'agence livre le site, le client paie la facture finale, et les deux parties passent à autre chose. Trois mois plus tard, le client envoie un email : "un bouton est cassé, notre page de pricing a une faute de frappe, et nous voulons ajouter une nouvelle étude de cas."
Ce n'est pas un problème. C'est un pattern attendu. Les sites web ne restent pas les mêmes — la question est de savoir si vous avez structuré une manière durable de les maintenir.
Les 90 premiers jours après le lancement sont les plus riches en changements. Voici ce qui nécessite typiquement de l'attention :
Mises à jour des dépendances JavaScript. Les packages npm publient régulièrement des correctifs de sécurité et des versions majeures. Un site Next.js qui se lance en mars aura des dizaines de mises à jour disponibles en juin.
Problèmes CMS et contenu. Nouveaux types de contenu qui ne correspondent pas au template, images aux mauvaises dimensions, erreurs de syntaxe MDX dans les articles de blog, champs requis manquants.
Intégrations tierces. HubSpot change son script d'embed. Intercom met à jour son API widget. L'outil de consentement cookies publie un changement cassant.
Changements SEO et performance. Google met à jour son crawler. Une nouvelle fonctionnalité ajoute du JavaScript qui dégrade les performances.
Analytics et tracking. GA4 change son schéma d'événements. Une nouvelle campagne marketing nécessite un nouveau tracking.
Nouveau contenu et pages. Études de cas, articles de blog, landing pages, pricing mis à jour.
Les CTO et développeurs en interne gèrent bien la maintenance quand ils ont le temps. Le problème est que "quand ils ont le temps" est le goulot d'étranglement.
Le mode d'échec : un formulaire cassé reste non corrigé pendant trois semaines parce que le CTO était concentré sur le produit. Une faute de frappe sur la page de pricing persiste deux mois parce que personne ne possède le site après le lancement.
Pour les entreprises sans ressources techniques dédiées, la maintenance DIY est effectivement zéro maintenance. Le site se dégrade jusqu'à ce que quelque chose casse publiquement, puis il y a une panique pour le corriger — souvent avec qui est le moins cher et disponible plutôt qu'avec qui connaît le site.
Le support ad-hoc signifie : quelque chose casse, vous envoyez un email à quelqu'un, il corrige et envoie une facture. C'est bien pour les sites très stables qui changent rarement.
Le problème avec l'ad-hoc : le temps de réponse n'est pas garanti. Une agence en support ad-hoc met votre correction dans sa file d'attente de projets existants. Selon leur charge de travail, "corriger un formulaire cassé" peut signifier 24 heures d'attente ou deux semaines d'attente.
Un retainer de maintenance signifie : des honoraires mensuels fixes couvrent un ensemble défini de travaux continus. Temps de réponse, périmètre, et processus sont convenus en amont.
Ce que couvre un retainer :
Ce qu'un retainer ne couvre généralement pas :
Un retainer de maintenance fait sens quand :
Votre site change régulièrement. Une équipe marketing qui publie des articles, ajoute des études de cas, et crée des landing pages chaque semaine bénéficie d'une relation permanente.
Votre site est critique pour le business. Une entreprise B2B SaaS dont le site génère 40 % des demandes de démo ne peut pas se permettre un formulaire de contact cassé pendant deux semaines.
Vous n'avez pas de ressource technique interne. Si le site casse et que personne en interne ne peut évaluer le problème, vous avez besoin d'un accès garanti à quelqu'un qui peut.
Vous utilisez des intégrations qui évoluent. Les sites avec HubSpot, Stripe, Intercom, ou des intégrations similaires ont besoin de quelqu'un qui surveille quand ces services publient des changements affectant votre implémentation.
Vous avez un développeur en interne. Si quelqu'un dans votre équipe peut lire la codebase et déployer des corrections, vous n'avez pas besoin de payer pour un accès permanent en externe.
Votre site est genuinement statique. Un site qui n'a pas changé en 12 mois et ne changera pas dans les 12 prochains n'a pas de besoin continu.
Votre budget ne le supporte pas. Un site bien construit ne casse pas fréquemment. Si votre budget est serré, le support ad-hoc à un taux horaire plus élevé est moins cher qu'un retainer mensuel quand le site n'a besoin d'attention qu'une fois par trimestre.
Notre retainer de maintenance est sur mesure — contactez-nous pour un devis adapté à votre projet. Il couvre :
Le développement supplémentaire au-delà de 4 heures est facturé à 130 €/heure. Les fonctionnalités majeures sont devisées séparément.
Les clients en retainer obtiennent une planification prioritaire pour les nouveaux projets.
La bonne question n'est pas "ai-je besoin d'un retainer ?" — c'est "que se passe-t-il quand mon site a un problème et que j'ai besoin qu'il soit corrigé dans les 24 prochaines heures ?"
Si vous avez une réponse claire qui n'implique pas une recherche paniquée de celui qui est disponible et abordable à ce moment-là, vous allez bien. Sinon — un retainer vaut le coût.
Vous voulez comprendre à quoi ressemble une relation de maintenance avec Zynra ? Démarrez une conversation — nous regarderons votre site et vous dirons quel niveau de support continu est vraiment judicieux.
Nous prenons un nombre limité de projets chaque trimestre. Dites-nous ce que vous construisez.
Comment faire le SEO d'un nouveau site, dans l'ordre : indexation, vrais mots-clés, bases on-page et techniques, contenu qui répond aux requêtes. Sans blabla.
Vérification analytics, indexation Search Console, baseline de performance, premières mises à jour de contenu. Le calendrier post-lancement de 30 jours qui détecte les problèmes avant les utilisateurs.