Maintenance de site internet à Paris

Les sites WordPress, PrestaShop, Shopify et les applications Laravel ou Symfony, ainsi que les développements spécifiques dont le code et les accès sont disponibles.

La condition d’entrée est toujours la même : le code, les accès et la base doivent être fournis. Nous ne prenons pas en maintenance un site dont le code appartient à un prestataire qui refuse de le transmettre — nous serions responsables d’un système que nous ne pouvons pas lire, et la première correction se ferait à l’aveugle.

Avant de s’engager, nous conduisons un état des lieux d’une demi-journée à deux jours : version du socle et sa fenêtre de support, extensions installées et leur maintenance, présence d’un environnement de test, état des sauvegardes et date de leur dernière restauration réussie, journaux d’erreurs. Cet état des lieux conditionne le contrat et peut conclure à des travaux de remise à niveau préalables.

Deux cas se refusent : un socle dont la version n’a plus aucun correctif de sécurité et que vous ne souhaitez pas mettre à niveau, et une production sans environnement de préparation possible.

Les mises à jour de sécurité, la surveillance de disponibilité, les sauvegardes, la vérification des journaux, le suivi des performances et le contrôle des points sensibles du site.

Le rythme est mensuel pour les mises à jour ordinaires, immédiat pour les correctifs de sécurité critiques. Chaque intervention suit la même séquence : sauvegarde, application sur l’environnement de préparation, contrôle des parcours qui touchent à l’argent et aux données, puis production. Sauter l’étape de préparation fait gagner une heure et coûte une journée les fois où la mise à jour casse quelque chose.

La surveillance porte sur la disponibilité — une vérification toutes les minutes depuis l’extérieur —, sur les certificats et leur date d’expiration, sur l’espace disque, et sur les erreurs applicatives. Une alerte sans destinataire nommé ne sert à rien : le contrat dit qui est prévenu et dans quel délai.

La vérification des sauvegardes est la partie que les contrats mentionnent et que personne ne fait. Nous restaurons réellement, sur un environnement séparé, et le compte rendu du test vous est transmis.

Selon des délais convenus au contrat. La priorité est donnée à la remise en service, puis à l’analyse de la cause et aux mesures qui évitent la répétition de l’incident.

Les délais sont écrits par niveau de gravité : site indisponible ou commandes bloquées, parcours dégradé, anomalie sans effet sur l’activité. Un contrat qui annonce un délai unique pour tout ne veut rien dire, parce qu’il ne sera tenu que pour le plus grave.

La remise en service passe d’abord, et cela signifie parfois revenir à la version précédente sans avoir compris. C’est un choix assumé : chercher la cause sur une production arrêtée coûte des heures de chiffre d’affaires. L’analyse vient ensuite, sur une copie.

Chaque incident donne lieu à un compte rendu écrit : ce qui s’est passé, ce qui a été fait, ce qui a été identifié comme cause, et la mesure prise pour éviter la répétition. Sans cette dernière ligne, le même incident revient. C’est aussi ce document qui permet de discuter si l’incident relevait du contrat ou d’une évolution.

Les correctifs de sécurité sont appliqués rapidement. Les mises à jour importantes passent par un environnement de préparation afin de contrôler les effets sur les fonctions et l’affichage.

La distinction est nécessaire parce que l’automatisation complète a un coût connu : une mise à jour d’extension appliquée sans contrôle casse en moyenne quelque chose plusieurs fois par an sur un site qui en compte vingt. Les cas les plus fréquents sont un affichage dégradé sur un gabarit, un formulaire qui n’envoie plus, et un conflit entre deux extensions qui touchent au même endroit.

Nous automatisons donc les correctifs de sécurité mineurs du socle, et nous traitons à la main les mises à jour majeures, les extensions liées au paiement, au formulaire et au référencement, et tout ce qui touche au modèle de données.

Un point à vérifier dans tout contrat, chez nous comme ailleurs : ce qui se passe quand une mise à jour casse le site. Le délai de rétablissement et la responsabilité doivent être écrits, sinon la discussion a lieu au mauvais moment.

Non. Elles limitent les conséquences mais ne remplacent pas les mises à jour, la surveillance, la gestion des accès et la restriction des permissions.

Une sauvegarde répond à une seule question : peut-on revenir en arrière. Elle ne dit rien de la porte par laquelle quelqu’un est entré, et restaurer sans avoir fermé cette porte reproduit l’incident dans les jours qui suivent. C’est le scénario le plus courant sur les sites compromis que nous reprenons.

Les trois mesures qui empêchent réellement l’essentiel des intrusions sur les sites de PME : des socles et extensions à jour, une authentification à deux facteurs sur les comptes d’administration, et la suppression des comptes inutilisés. Aucune n’est coûteuse, et leur absence explique la majorité des cas.

Et une sauvegarde n’existe que si elle a été restaurée. Un fichier de sauvegarde jamais testé peut être tronqué, chiffré avec une clé perdue, ou ne pas contenir la base. Nous testons la restauration à intervalle régulier et vous transmettons le résultat, parce que c’est le seul moyen de savoir.

Oui après audit. L’analyse porte sur le socle technique, les extensions, la sécurité, les performances, les accès et les dépendances, afin d’identifier les travaux préalables éventuels.

C’est une part importante de notre activité de maintenance et cela ne pose pas de difficulté particulière, à condition que le code et les accès soient fournis. Nous ne demandons aucune explication sur les raisons du changement d’agence et nous ne commentons pas le travail de notre prédécesseur : l’audit dit ce qui est, pas ce qui aurait dû être.

Un cas nous fait refuser : un projet en litige avec le prestataire précédent, avant que la situation contractuelle soit clarifiée. Reprendre un site dont la propriété du code ou du domaine est contestée nous expose et vous expose.

L’audit conclut souvent à des travaux préalables — mise à niveau du socle, suppression d’extensions abandonnées, mise en place d’un environnement de préparation. Ils sont chiffrés séparément du contrat de maintenance, parce qu’il serait malhonnête de les diluer dans un abonnement mensuel.

Par un compte rendu régulier : mises à jour appliquées, incidents traités, performances observées, points de vigilance et recommandations d’évolution éventuelles.

Le compte rendu est mensuel et tient sur une page. Il liste ce qui a été fait avec sa date, les incidents avec leur durée d’indisponibilité réelle, le résultat du dernier test de restauration, et ce que nous voyons venir — un certificat qui expire, une version de langage en fin de support, une extension dont l’éditeur ne répond plus.

La dernière rubrique est celle qui a de la valeur. Un site ne se dégrade pas brutalement : il accumule des échéances que personne ne suit. Les annoncer six mois avant permet de les budgéter ; les découvrir le jour où le paiement ne fonctionne plus coûte une intervention d’urgence.

Le compte rendu distingue aussi ce qui relève du contrat et ce qui a été facturé au temps passé, avec le détail. C’est ce qui évite la discussion de fin d’année sur ce que l’abonnement couvrait.

Non par défaut. Les évolutions font l’objet d’un chiffrage distinct. Un volume d’heures peut toutefois être prévu au contrat pour les petites demandes récurrentes.

La frontière est simple à énoncer et utile à tenir : la maintenance remet en état ce qui existe, une évolution ajoute ce qui n’existait pas. Corriger un formulaire qui n’envoie plus est de la maintenance ; ajouter un champ à ce formulaire est une évolution, même si cela prend dix minutes.

Nous prévoyons souvent un forfait d’heures — deux à quatre par mois — pour les petites demandes : un texte à changer, une image à remplacer, un champ à ajouter. Ce forfait évite d’émettre un devis pour un quart d’heure de travail, et son solde figure au compte rendu mensuel.

Au-delà, une évolution suit le chemin normal : périmètre écrit, chiffrage, validation. C’est plus lent et c’est ce qui empêche un contrat de maintenance de devenir un développement continu sans budget ni recette — situation dont personne ne sort satisfait.