Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

WhatsApp contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

Faire reprendre un site développé par quelqu’un d’autre

Reprendre un site n’est pas un acte administratif, c’est une décision technique. Avant d’accepter, je regarde trois choses : ce qui a été modifié dans le cœur du logiciel, ce qui n’est documenté nulle part, et ce qui n’est pas à votre nom. Ces trois points décident si la reprise est raisonnable, coûteuse ou déconseillée.

Décrire mon problème Discuter sur WhatsApp

Ce que je lis en premier, et pourquoi

La première question n’est pas « le site fonctionne-t-il », c’est « que se passe-t-il si on le met à jour ». La réponse tient dans un endroit précis : les fichiers du cœur ont-ils été modifiés directement ?

Sur PrestaShop, l’extension propre passe par un module ou un override placé dans le répertoire prévu à cet effet. Sur WordPress, elle passe par une extension ou un thème enfant. Quand ces mécanismes ont été respectés, une montée de version est un travail prévisible. Quand du code a été écrit dans les fichiers d’origine, chaque mise à jour écrase le travail, et personne ne sait ce qui a disparu — parce que rien ne le note.

Vient ensuite la question des traces : existe-t-il un dépôt de sources, un environnement de test, une note quelconque expliquant pourquoi telle chose a été faite ? Un site sans historique ne se modifie pas, il s’explore. Cette exploration est du temps facturé qui ne produit rien de visible, et c’est la partie que les clients ont le plus de mal à accepter — à juste titre, puisqu’ils la paient sans l’avoir causée.

Ce que je vérifie avant de chiffrer quoi que ce soit

  • Les fichiers du cœur, comparés à une installation de référence de la même version. C’est ce qui révèle les modifications directes, y compris celles que personne n’a mentionnées.
  • Le parc de modules et d’extensions : lesquels sont actifs, lesquels sont abandonnés par leur éditeur, lesquels ont été modifiés après installation.
  • L’existence d’un dépôt de sources et d’un environnement de préproduction. Sans eux, toute modification se fait directement en production, ce que je refuse sur une boutique qui vend.
  • Les sauvegardes : leur existence, leur fréquence, et surtout la preuve qu’une restauration a déjà été réalisée. Une sauvegarde jamais restaurée n’est pas une sauvegarde.
  • La version de PHP et celle de la plateforme, pour savoir si l’on travaille sur une base encore corrigée ou sur un socle abandonné.
  • Les accès : qui détient le domaine, l’hébergement, le backoffice, les comptes de paiement et les comptes transporteurs. C’est le point qui réserve le plus de mauvaises surprises.
  • Les tâches planifiées et les connexions vers l’extérieur, souvent invisibles dans l’interface et pourtant vitales : synchronisations, exports comptables, flux marchands.

Comment se déroule une reprise

  1. Sauvegarder avant de toucher à quoi que ce soit

    Fichiers et base, copie récupérée hors du serveur d’origine, restauration vérifiée sur un environnement séparé. Tant que cette copie n’existe pas et ne fonctionne pas, aucune intervention ne commence.

  2. Reproduire le site hors production

    Une copie de travail où l’on peut casser sans conséquence. C’est là que se fait l’exploration, pas sur la boutique qui encaisse. Sans cet environnement, la reprise se transforme en série d’incidents en direct.

  3. Cartographier ce qui a été modifié

    Comparaison avec une installation de référence, inventaire des overrides, liste des modules non standards. Le résultat est un document qui vous appartient, y compris si vous décidez ensuite de travailler avec quelqu’un d’autre.

  4. Rétablir la propriété des accès

    Domaine et hébergement à votre nom, comptes administrateurs recréés, anciens comptes désactivés, clés et jetons d’interface renouvelés. Cette étape est indépendante de la technique et elle est prioritaire.

  5. Décider ensuite, chiffres en main

    Reprendre, remettre en ordre progressivement, ou reconstruire. Cette décision se prend après l’audit, pas avant — et parfois la réponse honnête est de ne pas reprendre.

Pages liées

Questions fréquentes

Faut-il tout refaire quand on change de prestataire ?
Non, et c’est même rarement la bonne réponse. Un site fonctionnel, à jour et construit proprement se reprend sans difficulté particulière. Ce qui déclenche une reconstruction, ce n’est pas le changement d’intervenant : c’est un cœur modifié sans trace, une version abandonnée, ou une modélisation de catalogue fausse à la racine.
Combien coûte l’audit d’entrée ?
C’est une prestation courte et bornée, facturée à la journée, dont le livrable est un document : ce qui a été modifié, ce qui est à risque, ce qui manque en accès, et une hiérarchisation des corrections. Ce document vous reste, y compris si vous décidez de confier la suite à quelqu’un d’autre. C’est volontaire : payer un audit pour se retrouver captif n’aurait aucun sens.
Peut-on reprendre un site sans le code source d’origine ?
Le code est sur le serveur : si vous avez un accès complet à l’hébergement, vous avez le code, même sans dépôt. Ce qui manque, c’est l’historique — pourquoi telle modification a été faite, ce qui a été essayé, ce qui a été abandonné. C’est reconstituable, mais cela se paie en temps d’exploration.
Que faire si l’ancien prestataire garde des accès ?
Les révoquer, sans négociation. Comptes administrateurs supprimés, mots de passe changés, clés d’interface régénérées, accès serveur et bases revus. Un accès resté ouvert n’est pas seulement un risque de sécurité : c’est aussi la garantie qu’une modification pourra survenir sans que personne sache d’où elle vient.
Faites-vous de la maintenance sur un site que vous n’avez pas construit ?
Oui, c’est même le cas de figure le plus fréquent chez moi. La condition est l’audit d’entrée : je n’assure pas la maintenance d’un code que je n’ai pas lu. Un contrat signé sans cette lecture reviendrait à m’engager sur un état que j’ignore, ce qui finit toujours mal, pour vous comme pour moi.

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Qu’attendez-vous en priorité d’un contrat de maintenance ?
Quelle plateforme ?
Le site est-il à jour aujourd’hui ? (facultatif)

Un site en retard de plusieurs versions demande une remise à niveau avant tout contrat.

À quel rythme imaginez-vous les interventions ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Pages liées