Maintenance et support de sites, boutiques, applications et ERP : un outil à jour, sauvegardé et surveillé

Que recouvre un contrat de maintenance et de support, et que ne recouvre-t-il pas ?

Un site, une boutique, une application ou un progiciel de gestion ne s'usent pas comme une machine, mais ils vieillissent quand même. Le langage qui les fait tourner cesse d'être corrigé, une extension publie un correctif de sécurité, un certificat expire, un disque se remplit, un module de paiement change d'interface. Rien de tout cela ne se voit le jour où l'outil est livré. Tout finit par se voir le jour où le formulaire n'envoie plus rien, où la caisse refuse les paiements Mobile Money ou où Google affiche un avertissement devant votre adresse.

La maintenance est le travail régulier qui empêche ces pannes ou les répare vite. Elle couvre cinq familles de tâches : appliquer les mises à jour (PHP, WordPress, Laravel, Odoo, Dolibarr, bibliothèques et modules), faire des sauvegardes conservées hors du serveur et vérifier qu'elles se restaurent, surveiller la disponibilité, le certificat HTTPS et le nom de domaine, corriger les anomalies, et réaliser les petites évolutions que la vie de l'entreprise demande : un champ à ajouter, une page à créer, un taux de taxe à modifier.

Le support est l'autre moitié du contrat : un interlocuteur identifié, joignable par WhatsApp, téléphone ou courriel, qui répond sous 24 heures, qualifie la demande et dit ce qui sera fait et quand. Les deux s'achètent au forfait mensuel, quand l'outil est central pour l'activité, ou à la demande, intervention par intervention, quand il change peu et que vous préférez payer à l'usage.

Ce que la maintenance ne couvre pas doit être écrit avant de signer. Une refonte graphique complète ou un changement de technologie relève d'une refonte avec migration. Une nouvelle fonction importante, un espace client ou une application mobile sont des projets à part, chiffrés comme tels, par exemple en application web sur mesure. La production de contenus et le travail de positionnement relèvent du référencement naturel. Et la maintenance ne rattrape pas un outil mal conçu : elle le stabilise, puis l'état des lieux dit honnêtement s'il vaut mieux le reprendre.

Pourquoi un site ou une application qu'on ne touche plus devient-il dangereux ?

Parce que tout ce qui le compose a une date de péremption publiée. La page des versions prises en charge de PHP, consultée le 3 octobre 2026, fixe la règle : chaque branche reçoit deux ans de corrections complètes, puis deux ans de correctifs de sécurité critiques seulement. À cette date, seules les branches 8.2, 8.3, 8.4 et 8.5 sont maintenues, et la 8.2 ne le sera plus après le 31 décembre 2026. Un site resté en PHP 7.4 ou 8.0 tourne sur un moteur que plus personne ne corrige.

Ce n'est pas un cas rare. Selon W3Techs, au 3 octobre 2026, PHP équipe 69,8 % des sites dont le langage serveur est connu ; parmi eux, 27,7 % utilisent encore PHP 7 et 7,8 % PHP 5, deux générations sans aucun correctif. Et parmi les sites en PHP 8, la même source compte 15,8 % en version 8.1 et 6,1 % en 8.0, elles aussi sorties du support.

Les cadres et logiciels construits sur PHP suivent leur propre calendrier. La politique de support de Laravel accorde 18 mois de corrections de bogues et 2 ans de correctifs de sécurité à chaque version majeure : Laravel 12 n'en recevra plus après le 24 février 2027, Laravel 13, publié le 17 mars 2026, jusqu'au 17 mars 2028. Pour WordPress, endoflife.date rappelle que seule la dernière version est officiellement maintenue ; les correctifs sont reportés sur les anciennes branches quand c'est possible, sans garantie.

Le danger vient surtout des extensions. Le rapport 2026 de Patchstack, publié le 25 février 2026, recense 11 334 nouvelles vulnérabilités dans l'écosystème WordPress en 2025, dont 91 % dans les extensions et 6 seulement dans le cœur ; 46 % n'étaient pas corrigées au moment de leur publication, et le délai médian avant exploitation massive des plus visées était de cinq heures. Un site qui attend la visite mensuelle pour appliquer un correctif critique laisse donc une fenêtre bien trop large.

Qu'est-ce qu'une sauvegarde utile, et pourquoi celle de l'hébergeur ne suffit-elle pas ?

Une sauvegarde n'a de valeur que le jour où on la restaure. Pour un site WordPress ou Laravel, elle comprend deux éléments indissociables : les fichiers (code, images, documents téléversés, configuration) et la base de données. Pour Odoo, il faut la base PostgreSQL et le dossier des pièces jointes ; pour Dolibarr, la base et le répertoire des documents, que son wiki de mise à jour demande justement de sauvegarder avant toute montée de version. Une copie de la base sans les fichiers, ou l'inverse, ne remet rien en service.

Les recommandations publiques convergent. La fiche de Cybermalveillance.gouv.fr sur les sauvegardes, mise à jour le 14 septembre 2026, demande de les planifier, de garder une copie dans un lieu différent, de déconnecter le support après usage et de vérifier régulièrement qu'elles fonctionnent. Le guide de l'agence américaine CISA contre les rançongiciels, dans sa version de septembre 2023, va dans le même sens : des copies hors ligne et chiffrées, dont on teste régulièrement la disponibilité et l'intégrité dans un scénario de reprise.

Les sauvegardes de l'hébergeur sont utiles, mais elles ne remplissent pas ce rôle à elles seules. Sur sa page d'offres consultée le 3 octobre 2026, Hostinger annonce par exemple des sauvegardes hebdomadaires sur sa formule Premium et quotidiennes sur les formules supérieures : une semaine de commandes peut donc séparer deux copies. Surtout, ces copies vivent chez le même fournisseur, dans le même compte : un mot de passe volé, un compte suspendu pour impayé ou un rançongiciel qui chiffre tout ce qu'il atteint les emportent avec le site.

La règle appliquée en maintenance est donc simple : au moins une copie automatique, chiffrée, envoyée chaque jour ou chaque semaine vers un stockage indépendant de l'hébergeur, conservée sur plusieurs générations pour pouvoir revenir avant une infection passée inaperçue, et un test de restauration complet sur un serveur de test au moins une fois par an. Le rapport de ce test dit combien de temps la remise en service a pris : c'est ce chiffre, et non la promesse d'une sauvegarde, qui mesure votre capacité à repartir.

Que coûte un piratage découvert trop tard ?

Le coût le plus visible n'est pas technique. Quand Google détecte qu'un site a été piraté ou distribue un logiciel malveillant, son rapport sur les problèmes de sécurité l'indique dans la Search Console, et les pages concernées peuvent être accompagnées d'un avertissement dans les résultats de recherche, ou d'une page d'alerte affichée par le navigateur. Une fois le site nettoyé, il faut demander un examen, qui prend selon Google plusieurs jours, voire plusieurs semaines.

Pendant ce temps, les visiteurs fuient, les campagnes publicitaires s'arrêtent et les courriels envoyés depuis le domaine finissent parfois en indésirables. Le nettoyage lui-même coûte plus cher qu'une prévention, parce qu'il faut retrouver toutes les portes dérobées laissées par l'attaquant, et pas seulement la faille d'entrée. D'où l'intérêt d'une console de Google reliée au site et surveillée : elle signale souvent un problème avant que les clients ne le voient.

Le risque ne vient pas seulement de votre propre code. L'OWASP, référence mondiale de la sécurité des applications web, a placé dans son classement 2025 les défaillances de la chaîne d'approvisionnement logicielle au troisième rang des risques, et les erreurs de configuration au deuxième. Bibliothèques, extensions, modules et thèmes forment cette chaîne : les inventorier, les mettre à jour et retirer ceux qui ne servent plus est le cœur du métier de mainteneur.

Pourquoi les certificats HTTPS demandent-ils désormais une surveillance permanente ?

Un certificat expiré ne casse pas le site : il le rend inaccessible en pratique, puisque les navigateurs affichent une alerte plein écran que presque personne ne franchit. Or la durée de vie des certificats raccourcit. Le CA/Browser Forum, qui fixe les règles communes aux autorités de certification et aux navigateurs, a adopté le 11 avril 2025 le vote SC-081 : la durée maximale d'un certificat public passe de 398 jours à 47 jours, par paliers, entre mars 2026 et mars 2029.

Let's Encrypt, qui délivre les certificats gratuits utilisés par la plupart des hébergements, va plus loin. Selon son annonce du 2 décembre 2025, ses certificats de 90 jours passeront à 64 jours le 10 février 2027, puis à 45 jours le 16 février 2028. L'organisme recommande un renouvellement automatique qui s'appuie sur les informations de renouvellement qu'il publie (ARI), ou, à défaut, aux deux tiers de la durée de vie du certificat.

Il a aussi cessé, le 4 juin 2025, d'envoyer les courriels qui prévenaient de l'expiration, comme l'indique son annonce du 22 janvier 2025, en conseillant de passer par un service de surveillance. Concrètement, plus personne ne vous prévient si le renouvellement automatique échoue après un changement de serveur ou de zone DNS. La maintenance ajoute donc une sonde qui lit la date d'expiration réelle du certificat servi, et pas seulement celle prévue par l'hébergeur, et une alerte sur l'échéance du nom de domaine, dont l'oubli coupe à la fois le site et les adresses électroniques.

Faut-il activer les mises à jour automatiques ou tout tester avant ?

Les deux, selon ce qui se met à jour. Le 22 septembre 2026, la version 7.1.2 de WordPress a corrigé une faille critique : un attaquant non authentifié pouvait, dans certaines conditions, faire exécuter un fichier PHP du serveur et aller jusqu'à exécuter son propre code. Le correctif a été reporté sur toutes les branches éligibles, jusqu'à la 4.7, et les sites qui acceptent les mises à jour automatiques en arrière-plan l'ont reçu sans intervention. Cinq jours plus tôt, la version 7.1.1 apportait déjà 11 correctifs de sécurité.

Pour ce type de correctif, l'automatisme est le bon choix : le risque d'une faille ouverte dépasse de loin celui d'une incompatibilité. La documentation d'administration de WordPress précise toutefois que les extensions et les thèmes ne se mettent pas à jour seuls par défaut, sauf cas décidés par l'équipe de sécurité, et recommande de sauvegarder le site avant toute mise à jour. C'est là que se loge l'essentiel du risque, et c'est là que la maintenance travaille.

Les changements plus lourds se testent d'abord : version majeure d'une extension de boutique, passage à une nouvelle branche de PHP, nouvelle version de Laravel, d'Odoo ou de Dolibarr. Ils sont appliqués sur une copie de l'outil, avec vos données, puis vérifiés sur les parcours qui comptent (commande, paiement, formulaire, facture, rapport), avant d'être déployés en production à une heure creuse, sauvegarde fraîche à l'appui. Pour Odoo, la documentation des montées de version rappelle que chaque version majeure est suivie trois ans et qu'une base hébergée sur Odoo Online doit monter de version majeure tous les deux ans.

Comment se règle un forfait de maintenance, depuis l'Afrique ou l'Europe ?

Les moyens de paiement acceptés sont le Mobile Money (MTN et Moov), la carte bancaire, PayPal, le virement et les espèces. Un forfait mensuel se règle donc depuis le téléphone pour un client de Cotonou ou d'Abidjan, par virement, carte ou PayPal pour un client de Lyon, de Genève ou de Montréal. Le contrat précise l'échéance, la devise convenue et ce qui se passe en cas de retard, pour qu'aucune interruption de service ne vienne d'un malentendu de facturation.

Le devis sépare ce que vous payez au mainteneur de ce que vous payez à des tiers : hébergement, nom de domaine, licences Odoo Enterprise, extensions WordPress payantes, modules DoliStore, crédits d'envoi de SMS ou de messages WhatsApp. Ces abonnements restent à votre nom et sur votre moyen de paiement chaque fois que c'est possible : si le mainteneur change, rien ne s'éteint. Chaque intervention à la demande fait l'objet d'une facture qui reprend la description du travail réalisé.

Connexion, données personnelles, langue : que change le contexte local ?

La connexion pèse sur la maintenance elle-même. Quand le réseau du bureau est instable, une surveillance installée sur place ne voit rien : les sondes doivent interroger le site depuis l'extérieur, et les sauvegardes partir du serveur vers un stockage distant, pas transiter par l'ordinateur de quelqu'un. Pour un ERP installé au bureau, Odoo ou Dolibarr, l'onduleur, la copie nocturne hors site et la vérification de l'espace disque font partie du contrat au même titre que les mises à jour.

Au Bénin, la loi n° 2017-20 du 20 avril 2018 portant code du numérique impose au responsable du traitement et à son sous-traitant, à l'article 426, des mesures techniques et d'organisation appropriées : le texte cite le chiffrement, des moyens de rétablir l'accès aux données dans des délais appropriés après un incident physique ou technique, et une procédure pour tester régulièrement l'efficacité de ces mesures. Des sauvegardes testées et un journal des interventions répondent directement à cette exigence.

L'article 427 de la même loi oblige le responsable du traitement à notifier sans délai à l'Autorité de protection des données et à la personne concernée toute atteinte à la sécurité de leurs données, et le sous-traitant à prévenir sans délai le responsable du traitement. Le mainteneur est précisément ce sous-traitant : le contrat doit dire comment il vous alerte, et avec quelles informations (nature de l'incident, données et personnes touchées, mesures prises).

En Europe, le RGPD fixe une règle voisine. La page de la CNIL sur la notification des violations demande de notifier dans les meilleurs délais et, si possible, dans les 72 heures après en avoir pris connaissance, d'informer les personnes en cas de risque élevé et de documenter toutes les violations en interne, même celles qui ne sont pas notifiées. Pour un site qui vise des clients en France, en Belgique ou en Suisse, cette procédure s'écrit avant l'incident, pas pendant.

Reste la langue : rapports, alertes et échanges se font en français, et en anglais si votre équipe ou votre maison mère le demande. Un rapport mensuel que le dirigeant ne comprend pas ne sert à rien ; il doit dire en quelques lignes si l'outil est sain, ce qui a été fait et ce qu'il faudra budgéter.

Réversibilité et accès : comment changer de mainteneur sans tout perdre ?

Un bon contrat de maintenance se juge aussi à la façon dont il se termine. La réversibilité, c'est la garantie que vous pouvez confier l'outil à quelqu'un d'autre, ou le reprendre en interne, du jour au lendemain. Elle repose sur trois principes : les comptes sont à votre nom, le code et les données vous appartiennent, et tout ce que le mainteneur a appris de votre outil est écrit quelque part où vous y avez accès.

Concrètement, vous restez titulaire du nom de domaine, du compte d'hébergement, des licences et des comptes de paiement ; le mainteneur y accède par des accès délégués, nominatifs, que vous pouvez retirer. Le code des développements spécifiques est dans un dépôt dont vous êtes propriétaire. Les sauvegardes sont lisibles sans outil propriétaire du prestataire. Et un document d'exploitation décrit l'architecture, les tâches planifiées, les mots de passe à changer et les procédures de restauration.

À la fin du contrat, quelle qu'en soit la raison, la passation comprend une sauvegarde complète et récente, l'inventaire des accès, la remise du document d'exploitation à jour et le retrait des accès du mainteneur sortant. Si un prestataire refuse de vous rendre les accès ou le code, la question n'est plus technique : c'est un signal à prendre au sérieux bien avant la fin du contrat.

Pourquoi confier la maintenance de votre outil à Richard SALANON ?

Richard SALANON est consultant en digitalisation et développeur logiciel, basé à Cotonou, au Bénin. Il crée des sites, des applications web et mobiles, des automatisations et des intégrations d'intelligence artificielle, déploie Odoo et Dolibarr, et forme les équipes à ces outils, pour des entreprises d'Afrique francophone, d'Europe et du Canada.

Maintenir un outil demande de connaître la façon dont on le construit. Avec plus de 6 ans d'expérience dans le numérique et une formation à EPITECH, Richard travaille au quotidien avec les technologies qu'il maintient : PHP et Laravel, Node.js, Vue et React, Flutter pour le mobile, WordPress, Odoo et Dolibarr, n8n et Make pour les automatisations. Il a créé Wapy, un assistant WhatsApp à intelligence artificielle pour les entreprises d'Afrique francophone, et il est co-fondateur d'Audyxa. Côté produit comme côté client, la question reste la même : un service en ligne ne s'arrête pas à sa mise en production.

Il est intervenu pour des clients au Bénin, en Côte d'Ivoire, au Togo, au Sénégal, au Burkina Faso, au Mali, au Niger, au Tchad, au Gabon, en RD Congo, en France, en Belgique, en Suisse et au Canada, sur place ou à distance. Sa façon de travailler tient en quelques règles : une réponse sous 24 heures, un état des lieux écrit avant tout forfait, des comptes laissés à votre nom, aucune mise à jour majeure sans copie de test, et un rapport mensuel lisible par un dirigeant. Son parcours est détaillé sur la page Richard SALANON.

Si vous préférez qu'une personne de votre équipe assure les tâches courantes, la formation au développement web, la formation Odoo et la formation Dolibarr lui donnent les bases ; la maintenance garde alors les montées de version, la sécurité et les urgences. Les pays servis sont listés sur la page zones d'intervention.