Support
Maintenance de site internet : corriger et faire évoluer
On n'appelle pas la maintenance pour entretenir un site. On l'appelle parce que quelque chose ne marche plus.
ELBAHI.NET intervient sur les sites en ligne, y compris ceux qu'elle n'a pas construits. Une demande de maintenance prend trois formes : le site ne répond plus, quelque chose ne fonctionne plus comme avant, ou il manque une fonction. Les trois n'appellent ni le même délai ni le même traitement, et c'est cette distinction qui organise le travail.
Ce que comprend la prestation
Une demande de maintenance arrive sous trois formes : le site est tombé, quelque chose ne fonctionne plus comme avant, ou il faut ajouter une fonction. Les trois n'ont ni la même urgence ni le même déroulé.
Les traiter dans la même file revient à faire attendre une panne derrière une évolution, et c'est ainsi qu'on perd une journée de commandes.
La panne
Le site est inaccessible ou une fonction critique est cassée. On rétablit d'abord, on explique ensuite, et le compte rendu suit sous quelques jours.
L'anomalie
Un formulaire qui n'envoie plus, un affichage cassé sur un navigateur. Reproduite, corrigée, puis vérifiée sur le parcours réel.
L'évolution
Une page à ajouter, une fonction à étendre. Elle est chiffrée avant d'être engagée, et n'entre jamais en concurrence avec une panne.
Mises à jour applicatives
Cœur, extensions, thème, sur un environnement d'essai avant la production. Une mise à jour appliquée directement en ligne finit par casser une page.
Journal des interventions
Chaque demande, sa date, ce qui a été fait. C'est ce qui permet de voir qu'une même anomalie revient et de traiter sa cause.
Point mensuel
Ce qui a été traité, ce qui reste, ce qui devrait être refait plutôt que rafistolé. Sans ce point, la maintenance masque une dette au lieu de la réduire.
Trois demandes qui n’ont rien à voir entre elles
Une demande de maintenance arrive presque toujours avec la même phrase : il y a un souci sur le site. Elle recouvre trois situations très différentes, et le premier travail consiste à savoir laquelle.
| La demande | Ce qu’elle exige | Ce qui passe en premier |
|---|---|---|
| Le site ne répond plus | remettre en ligne, comprendre ensuite | tout le reste attend |
| Quelque chose ne marche plus | reproduire, corriger, vérifier | avant toute évolution |
| Il manque une fonction | cadrer, développer, reporter | quand les deux autres sont vides |
Cette hiérarchie n’est pas une politesse commerciale. Une évolution engagée pendant qu’une anomalie traîne double le risque : on modifie un site déjà instable, et l’on ne sait plus laquelle des deux interventions a causé quoi.
La panne — remettre en ligne d’abord
Quand le site ne répond plus, la priorité n’est pas de comprendre mais de rétablir. Un diagnostic complet mené pendant que la boutique est fermée coûte plus cher que la panne elle-même.
L’ordre est donc inversé par rapport à l’intuition : on revient à un état connu qui fonctionnait, on remet en ligne, et l’analyse vient après, sur une copie. Cela suppose de disposer d’un point de retour — c’est là que l’hébergement et la maintenance se rejoignent.
Ce qui se décide avant l’incident, jamais pendant : qui appelle qui, sur quel numéro, et à partir de quand on considère qu’il y a urgence.
L’anomalie — la reproduire avant de la corriger
Un appel qui annonce « le formulaire ne marche pas » ne décrit pas une anomalie, il décrit un symptôme. Une correction commence toujours par reproduire le problème, parce qu’on ne corrige pas ce qu’on n’a pas vu.
Trois informations font gagner l’essentiel du temps, et vous êtes le seul à les avoir :
- ce que vous faisiez exactement, étape par étape
- ce que vous attendiez, et ce qui s’est produit à la place
- depuis quand, et si quelque chose a changé à ce moment-là
La dernière est la plus utile. Un site ne tombe presque jamais en panne tout seul un mardi : il tombe après une mise à jour, un changement d’hébergeur, l’expiration de quelque chose, ou une modification faite par quelqu’un qui n’a pas pensé à le dire.
L’évolution — étendre sans repartir de zéro
C’est la demande la plus fréquente une fois le site installé dans la durée : une page de plus, un champ dans un formulaire, une langue supplémentaire, un raccordement à un outil de gestion.
Chacune est petite. C’est leur accumulation qui pose problème, et elle suit toujours le même chemin : dix demandes traitées au coup par coup, chacune raisonnable, produisent un site que plus personne ne comprend — et la onzième demande devient « il faudrait tout refaire ».
Ce qui l’évite tient en peu de choses. Chaque évolution est reportée depuis une copie de travail, jamais improvisée en ligne. Une demande qui revient deux fois n’est plus un cas particulier mais une fonction manquante, et se traite comme telle. Et une évolution qui contredit la structure du site se signale : mieux vaut une discussion de dix minutes qu’une rustine dont personne ne se souviendra dans un an.
Reprendre un site que nous n’avons pas construit
C’est le cas le plus courant, et il commence par un état des lieux plutôt que par un devis.
On vérifie que le code est récupérable, que les composants reçoivent encore des correctifs, qu’une copie de travail peut être montée à part, et que les accès sont complets. Cet examen dit surtout ce qui n’est pas maintenable : un site reposant sur une extension abandonnée par son auteur ne s’entretient pas indéfiniment, et le dire avant de s’engager vaut mieux que de le découvrir au premier incident.
Quand la reprise est possible, elle commence par appliquer les correctifs en retard. C’est rarement ce que le client attendait, et c’est presque toujours ce dont le site avait besoin.
Questions fréquentes
Intervenez-vous sur un site que vous n'avez pas construit ?
Oui, après un état des lieux qui conditionne la suite. Il faut vérifier que le code est récupérable, que les composants installés reçoivent encore des correctifs, et qu'une copie de travail peut être montée à part. Un site bâti sur une extension abandonnée par son auteur ne s'entretient pas durablement : il vaut mieux l'entendre avant de s'engager qu'au premier incident.
Ajouter une fonction, est-ce de la maintenance ?
Oui, et c'est ce qui distingue notre définition de celle de beaucoup de contrats. Corriger une anomalie remet le site dans l'état promis ; ajouter une page, un champ ou une intégration l'étend. Les deux relèvent de la maintenance chez nous, mais elles ne se traitent pas au même rythme : une anomalie passe devant une évolution, toujours.
Faut-il un contrat, ou peut-on appeler ponctuellement ?
Les deux existent et ne servent pas la même chose. L'intervention ponctuelle convient à un site stable dont on ne touche presque rien. Le forfait a un intérêt que le ponctuel n'a pas : il finance une veille — mises à jour appliquées avant l'incident, échéances surveillées — donc il déplace le travail d'après la panne vers avant.
Une modification peut-elle casser autre chose ?
Oui, et c'est la raison d'être de la copie de travail. Toute intervention se prépare sur un double du site, se vérifie, puis se reporte en production. Modifier directement en ligne fait gagner quelques minutes et expose à une panne visible par vos clients, un jour où personne n'est disponible pour la rattraper.
À explorer dans ce silo
Explorez aussi
Hébergement web
Où vit votre site, et ce qui se passe quand il tombe
Applications mobiles
Ce qui justifie une application plutôt qu'un site
Démarrer