FR EN

Votre mise à jour a cassé le site, ou refuse de passer

Vous avez lancé la mise à jour, et depuis, plus rien ne fonctionne comme avant. Ou vous n'avez rien lancé du tout : un module s'est mis à jour de lui-même, votre hébergeur a changé la version de PHP pendant la nuit, et le site en a fait les frais. Il arrive aussi que ce soit l'inverse, que la mise à jour refuse de démarrer parce qu'un module que plus personne ne maintient la bloque depuis des mois.

Parfois rien n'est franchement cassé, et c'est presque pire : le site répond, mais mal, sans le moindre message d'erreur à montrer. Dans tous ces cas le plus dur est de savoir par où commencer, et c'est exactement notre travail. On regarde ce que la mise à jour a changé, on remonte jusqu'à la cause, on sauvegarde avant de toucher et on vous annonce un montant avant d'intervenir.

  • Sauvegarde avant de toucher
  • Montant annoncé avant d'intervenir
  • Rappel en moins de dix minutes

Assistant Mon Site Bug

relais humain en quelques minutes

15:14
15:14

Votre demande concerne :

Trois situations

Qui a lancé la mise à jour

Quel que soit le problème de mise à jour que vous rencontrez, il rentre presque toujours dans un de ces trois cas. Un « j'ai mis à jour tel module et depuis le site est cassé » nous met tout de suite sur la piste. Mais ce n'est pas à vous de trouver la cause.

Décrire ma situation
Vous l'avez faite

Mise à jour de PrestaShop ou de WordPress faite maison

Vous avez lancé la montée de version, ou simplement mis à jour un module, et tout s'est cassé. Si vous savez lequel, dites-le nous, ça nous met directement sur la piste. Sinon on compare l'état d'avant et celui d'après, et on isole le changement responsable. Vous n'avez pas à comprendre ce qui s'est passé.

Votre agence l'a faite

Le chantier est livré, le site ne marche plus comme avant

Le chantier est passé et depuis, le site est cassé, ou il ne fonctionne plus comme il devrait. Ce qui a été touché dépasse souvent la seule mise à jour : un thème retouché au passage, un module désactivé pour que ça passe. On demande la date et le détail, à défaut on le reconstitue. Le rapport qu'on vous remet sert aussi à votre prestataire.

Personne ne l'a faite

La mise à jour automatique, la plus sournoise

Surtout sous WordPress : une extension se met à jour toute seule dans la nuit et fait planter le site. Ça vaut aussi pour la version de PHP que l'hébergeur change sans prévenir. Personne n'a rien touché, personne ne sait quand, et vous n'avez donc rien à nous raconter. La date, elle, est dans les journaux du serveur, et c'est là qu'on va la chercher.

Le cœur du site

La mise à jour de votre CMS

Migrer PrestaShop vers sa dernière version, ou WordPress, c'est changer le cœur du site. Tout ce qui repose dessus doit suivre, et ce qui ne suit pas casse. Voici les cas les plus courants, des couches hautes que voit votre client jusqu'à la machine.

Décrire ma situation Mise à jour : votre site peut casser. Une mise à jour peut introduire des incompatibilités et provoquer des erreurs critiques.

Ce que voit votre client

  1. Le thème

    Il n'était pas prévu pour cette version

    Un thème acheté il y a cinq ans, ou fait sur mesure, s'appuie sur des fonctions que la nouvelle version a retirées. Le site tourne mais s'affiche de travers, parfois seulement sur certaines pages. C'est le symptôme le plus facile à sous-estimer, et le plus visible pour vos clients.

  2. Le sur-mesure

    Ce qui a été écrit pour vous ne survit pas

    Une fonction développée pour votre site, par nous ou par quelqu'un d'autre. Personne ne publiera de correctif puisque ce code n'existe que chez vous. C'est de la reprise de code : on le lit, on comprend l'intention d'origine, et on réécrit ce qui doit l'être.

  3. Les modules

    Ils tombent en série

    En général une boutique en compte une cinquantaine, mais il arrive que ce soit bien plus, genre 170 (si si, vous avez bien lu). Il suffit que trois ou quatre n'aient pas de version prévue pour la nouvelle, et ce sont eux qui font tomber le reste. On les identifie un par un et on tranche pour chacun : mettre à jour, remplacer, ou désactiver le temps de rouvrir la boutique.

  4. La base de données

    Les données ne passent pas

    Entre deux versions majeures, la structure de la base change. Une migration qui s'interrompt laisse des tables à moitié converties : les commandes sont là, mais l'ancien back-office ne sait plus les lire et le nouveau pas encore. C'est le cas où il ne faut surtout rien relancer.

  5. Le cœur du CMS

    La mise à jour refuse de démarrer

    Version de PHP trop ancienne, espace disque insuffisant, droits de fichiers bloquants, ou un module que l'assistant signale comme incompatible. Le site n'est pas cassé, il est figé sur une version qui vieillit, et chaque mois rend la montée plus lourde.

  6. Le serveur et PHP

    La couche change sous vos pieds

    La nouvelle version du CMS réclame un PHP plus récent, l'hébergeur bascule, et du code qui fonctionnait depuis des années s'arrête net. Deux mises à jour se produisent alors le même jour, et la panne vient rarement de celle qu'on croit.

Là où la mise à jour entre

Le cas le plus fréquent

La mise à jour d'un module ou d'une extension

C'est le cas le plus fréquent chez nous, près d'une fois sur deux*. Un seul composant suffit à faire tomber un site entier quand il touche au panier, au paiement ou à l'affichage. L'avantage, c'est que le coupable est unique et qu'on l'isole vite.

  1. Vous avez mis à jour un module et tout s'est cassé

    Le scénario classique. Dites-nous lequel et on va droit au but : on revient à la version qui fonctionnait, ou on corrige l'incompatibilité quand revenir en arrière rouvrirait une faille de sécurité.

  2. Le module s'est mis à jour tout seul

    La mise à jour automatique est la règle sous WordPress, l'exception sous PrestaShop. Une extension se met à jour dans la nuit, le site plante au matin, et vous n'avez rien fait. Les dates de modification des fichiers disent lequel a bougé.

  3. La licence a expiré

    On le rencontre régulièrement. Un module payant cesse de recevoir ses mises à jour quand l'abonnement s'arrête, souvent sans que personne s'en aperçoive. Il continue de fonctionner, jusqu'au jour où le CMS bouge.

  4. Deux modules se marchent dessus

    Chacun fonctionne seul, les deux ensemble non. Après une mise à jour, deux extensions se disputent le même hook ou la même page. On les isole en les désactivant une à une, méthode lente mais sûre.

  5. Vous ne savez plus lequel

    Vous avez cliqué sur « tout mettre à jour », ou rien du tout, et le site est cassé depuis. C'est le cas normal et il ne pose pas de problème : les journaux du serveur et les dates de fichiers disent ce qui a bougé et quand.

* Chiffres tirés de nos statistiques d'intervention réelles, figées au 30 aout 2026.

L'assistant est en haut de page

Vous vous reconnaissez dans un de ces cas ?

Décrivez-le en deux lignes. Un technicien vous rappelle en moins de dix minutes, et le premier quart d'heure de recherche est offert.

Avant, pendant, après

Où en est la mise à jour

Dites-nous laquelle est la vôtre, ça nous fait gagner le premier quart d'heure de recherche.

Décrire ma situation

Elle est allée au bout, et le site fonctionne mal

Rien n'est franchement cassé, mais quelque chose ne va pas. Des lenteurs, une fonction qui répond une fois sur deux, un affichage qui saute. C'est le cas le plus difficile à décrire, et souvent celui qu'on laisse traîner le plus longtemps.

Elle s'est arrêtée en cours de route

Le processus a coupé au milieu : temps d'exécution dépassé, mémoire insuffisante, connexion perdue. Le site se retrouve dans un état intermédiaire, ni l'ancienne version ni la nouvelle. C'est réparable, mais il ne faut surtout pas relancer la mise à jour par-dessus.

Vous l'avez annulée après un échec

Vous avez fait marche arrière et le site est reparti, sauf que des morceaux de la nouvelle version sont restés en place. Tables en trop, fichiers orphelins, cache incohérent. Ça tient jusqu'à la prochaine tentative.

Vous avez restauré une sauvegarde à la place

Décision raisonnable dans l'urgence : le site remarche comme avant. Reste que la mise à jour est toujours à faire, et que les commandes passées entre la sauvegarde et la restauration ont peut-être disparu. On vérifie les deux.

Questions qu'on nous pose

C'est le cas le plus courant. Beaucoup de demandes arrivent avec « le site ne marche plus » et rien d'autre. Chercher la cause fait partie du travail : vous décrivez ce que vous voyez, on remonte jusqu'à l'origine dans les journaux du serveur et les dates de modification des fichiers.

Non, pas avant qu'on ait regardé. Relancer par-dessus un état intermédiaire est le geste qui transforme une panne réparable en base de données incohérente. Laissez le site tel quel, même s'il est moche, on part de là.

Rarement. Une mise à jour corrige presque toujours des failles de sécurité, et l'annuler les rouvre. On préfère réparer la compatibilité. Si la restauration reste la seule option raisonnable, on vous le dit avant, pas après.

Possiblement, celles passées entre la sauvegarde et la restauration. On compare les deux états et on vous dit ce qui manque, avant même de reparler de la mise à jour elle-même.

Non, et c'est la raison de la première étape : on sauvegarde fichiers et base avant de toucher à quoi que ce soit. Quoi qu'il arrive ensuite, l'état dans lequel vous nous confiez le site reste récupérable.

Ça dépend de ce qui a cassé, et on vous le dit après le diagnostic, pas avant. En revanche l'ordre est toujours le même : on rétablit d'abord l'accès et la vente, on termine le reste ensuite. Un site qui encaisse à nouveau ne peut pas attendre la correction parfaite.

C'est notre quotidien. Trois issues possibles : le rendre compatible nous-mêmes, le remplacer par un équivalent maintenu, ou retirer la fonction quand elle ne sert plus à personne. On vous dit laquelle, et ce qu'elle coûte, avant de commencer.

C'est l'objectif. Réparer sans lever le blocage vous laisserait sur une version qui vieillit, et le problème reviendrait à la mise à jour suivante en pire. Le rapport de fin d'intervention indique ce qui reste à surveiller pour la prochaine.

Pas systématiquement. Elles corrigent des failles, les couper vous expose. Ce qui se règle, en revanche, c'est de ne plus les subir : une sauvegarde qui part avant chaque mise à jour, et une préproduction pour les montées de version majeures. On vous dit ce qui est raisonnable dans votre cas.

Pour du débogage, oui. Une panne se reproduit rarement ailleurs que là où elle se produit, alors on va la chercher là où elle est. Pour une montée de version majeure en revanche, on monte une préproduction et on ne bascule qu'une fois que vous avez vu le résultat.

On ne le fixe pas avant. On regarde d'abord, gratuitement pendant un quart d'heure, puis on annonce un montant. Vous validez ou vous refusez, et ce montant ne bouge plus : si l'intervention prend plus de temps que prévu, l'écart est pour nous.

On traite à peu près tout ce qui existe, quel que soit le CMS ou le framework, à une condition : avoir accès au code source. Un site fermé, hébergé sur une plateforme qui ne donne pas la main sur ses fichiers, est le seul cas qu'on ne peut pas prendre.

Une mise à jour vous bloque depuis ce matin ?

Décrivez la situation en deux lignes. Un technicien vous rappelle en moins de dix minutes, et la recherche de l'origine est offerte pendant un quart d'heure.

Obtenir un diagnostic gratuit

ou appelez-nous au 01 84 20 89 46

Avis clients sur nos dépannages de mise à jour Des avis Google laissés après une intervention réelle.

  • Google

    Nous travaillons avec MonSiteBug depuis un moment maintenant, et c'est un vrai bonheur de pouvoir compter sur eux. Leur professionnalisme, leur extrême réactivité et la qualité de leur travail nous facilitent tellement la vie.. Que ce soit Youssef avec ses solutions adaptées à nos besoins ou le reste de l'équipe extraordinaire qui nous fournit un travail de qualité, nous pouvons réellement nous appuyer sur MonSiteBug et leur faisons une confiance aveugle. Fouad, qui s'occupe de notre suivi, ne se contente pas de résoudre les bugs qu'on lui signale : dès qu'il repère une erreur ou un point d'amélioration, il prend les devants et nous propose des solutions concrètes pour simplifier notre quotidien avec tout notre écosystème informatique. C'est cette réactivité et cet esprit d'initiative qui font toute la différence. On sent qu'il s'imprègne vraiment notre fonctionnement et qu'il anticipe nos besoins plutôt que d'attendre qu'on lui demande. Un service technique de qualité, doublé d'un vrai sens du service client. Merci Fouad et toute l'équipe MonSiteBug, nous vous recommandons sans aucune hésitation! L'équipe Pro Sprayer

    PRO SPRAYER
    PRO SPRAYER
    il y a 1 mois
  • Google

    Super écoute, réparation rapide et efficace, très pro!!!

    Patrick Doisneau
    Patrick Doisneau
    il y a 5 mois
  • Google

    Support et réalisation super efficace et rapide. Equipe très compétente et serviable. Tarifs tout à fait correctes. Super expérience !

    Tea and More Luxembourg
    Tea and More Luxembourg
    il y a 6 mois
  • Google

    Absolument parfait. Erreur fatale sur mon site suite à la mise à jour d'un module, corrigée en moins d'une heure par Youssef et son équipe. Quel plaisir de travailler avec des professionnels aussi efficaces. Je recommande les yeux fermés.

    Radio Ham Electronic
    Radio Ham Electronic
    il y a 6 mois
  • Google

    Merci à mon site bug pour leur service d'entretient et de réparation de site internet. Encore un dépannage réussit. Et des conseils avisés

    stéphane Prévot
    stéphane Prévot
    il y a 8 mois
  • Google

    Au top! Communication fluide et résolution instantanée.

    Muriel BOUHET
    Muriel BOUHET
    il y a 9 mois