Reprise de site web existant : l'audit avant d'accepter

La reprise d’un site web existant se décide sur un audit en quatre points, avant tout devis : qui possède le code et les contenus, qui détient les accès, dans quel état est le code, et quelle dette technique il traîne. Si l’un de ces points reste flou, le prix et le délai annoncés reposent sur des suppositions. L’audit dit aussi s’il faut rattraper l’existant ou repartir de zéro.

La demande arrive souvent sous la forme « mon agence ne répond plus » ou « je viens de rompre le contrat, qu’est-ce que je fais du site ? ». Ce guide suit l’ordre dans lequel un prestataire sérieux mène la reprise d’un projet web existant laissé par une autre agence.

Reprise de site web existant : les quatre vérifications

L’ordre compte. Un client encore en contrat avec son agence n’a pas les mêmes leviers qu’un client dont le prestataire a disparu. Dans ce second cas, la démarche pour récupérer un site après la disparition d’un prestataire est plus centrée sur la preuve de propriété que sur la négociation.

Reprise d’un projet web existant d’une agence : qui possède le code

C’est le point que les clients négligent le plus, et celui qui coûte le plus cher en cas de litige. La cession de droits d’exploitation désigne l’acte par lequel l’auteur d’une œuvre (code source, maquettes, textes, visuels) transfère à un tiers le droit de l’utiliser, de la modifier et de l’exploiter. L’article L131‑3 du Code de la propriété intellectuelle exige que chacun des droits cédés fasse l’objet d’une mention distincte (Légifrance, Titre III du CPI).

Concrètement : sans contrat écrit qui prévoit cette cession, le client qui a payé un site n’est pas automatiquement titulaire des droits sur le code ni sur les créations graphiques. Un cabinet spécialisé le résume ainsi : quand le devis se limite à une ligne « création de site internet » sans clause de fin de contrat, chaque camp lit le silence à son avantage (Kohen Avocats, septembre 2026).

Le même article cite une décision qui montre le coût d’une rupture mal préparée. Dans un litige sur un logiciel standard, le client reprochait des manquements au prestataire mais avait lui-même refusé le paramétrage et la collaboration prévus. La cour d’appel de Lyon a ramené l’indemnité de résiliation de 69 093,51 euros à 35 000 euros, sans lui donner raison sur le fond (CA Lyon, 3e chambre A, 13 mars 2025, RG 21/08684).

Avant d’accepter une reprise, demandez ces trois documents :

Sans ces documents, la reprise reste possible techniquement mais fragile juridiquement. Le détail de ce que « posséder » un site veut dire, poste par poste, est traité dans notre audit de la propriété réelle d’un site.

Les accès : domaine, hébergement, comptes d’administration

Un contrat clair ne sert à rien si personne n’a la main sur les accès. Voici ceux à obtenir avant de signer :

• Registrar du domaine : accès direct ou transfert de titularité confirmé.
• DNS : accès à la zone, souvent séparé du registrar.
• Hébergement : panel (cPanel, Plesk) ou SSH, pas un simple FTP limité.
• Base de données : identifiants complets, pas une lecture seule.
• CMS ou back-office : compte administrateur, pas éditeur.
• Comptes tiers : envoi d’emails, paiement, Google Analytics, Search Console.
• Certificat SSL : possibilité d’en émettre un nouveau sur le nouvel hébergement.

Rattachez chaque compte principal à une adresse générique de l’entreprise, pas à celle d’un salarié de l’agence, et notez pour le domaine le nom, le registraire et la date d’expiration (Satellite WP). Les questions précises à poser à l’agence sortante sont dans notre article sur les accès à exiger d’une agence web.

Si l’agence reste titulaire d’un domaine en .fr et refuse de le rendre, l’Afnic propose SYRELI, une procédure de résolution des litiges facturée 250 euros HT au demandeur, sans remboursement possible depuis le 1er janvier 2023 (Afnic). La procédure Recover désigne ensuite l’opération par laquelle le registrar finalise auprès de l’Afnic le transfert du domaine, grâce à un code transmis par l’Afnic après la décision favorable (OVHcloud). Mieux vaut ne jamais en arriver là.

L’audit de reprise du code

La reprise de code commence par une question simple : le code qu’on vous remet est-il bien celui qui tourne en production ? L’audit couvre cinq points.

1. Les accès au code. Un export ZIP envoyé par email ne suffit pas. Il faut l’accès au dépôt (GitHub, GitLab, Bitbucket) avec les droits d’administration, ou son transfert sur un compte du client. Demandez aussi les accès aux environnements de préproduction s’ils existent.

2. Le dépôt. On compare le dépôt et les fichiers en production. Un écart signale des corrections faites directement sur le serveur, jamais reportées dans le dépôt. On vérifie aussi que les fichiers de verrouillage des dépendances sont présents. Pour un projet PHP, la documentation de Composer explique que versionner le fichier composer.lock garantit que chacun installe exactement les mêmes versions des dépendances (getcomposer.org).

3. Les versions. On relève la version du CMS, celle de PHP et celle des modules ou plugins, puis on les confronte aux calendriers officiels. Exemple côté Drupal : Drupal 10 exige au moins PHP 8.1 et Drupal 11 au moins PHP 8.3 (drupal.org, exigences PHP). Côté PHP, la branche 8.2 reçoit des correctifs de sécurité jusqu’au 31 décembre 2026 (php.net). Un site bloqué sur une version ancienne impose souvent une montée de version avant toute nouvelle fonctionnalité.

4. Les licences. Le cœur de Drupal est distribué sous licence GNU GPL version 2 ou ultérieure, et les modules et thèmes distribués en sont des œuvres dérivées soumises à la même licence (drupal.org, licence). Le vrai risque est ailleurs : thèmes et extensions premium achetés au nom de l’agence. Si la licence est révoquée, les mises à jour s’arrêtent. Listez chaque licence payante et son titulaire.

5. Les sauvegardes. Une sauvegarde complète comprend les fichiers et la base de données. Elle n’est utile que si elle a été restaurée au moins une fois avec succès. Faites cette restauration sur un environnement de test avant de toucher à la production.

Ajoutez à cette liste les intégrations sur mesure (connecteur CRM, module de réservation, passerelle de paiement configurée à la main) et les comptes tiers créés sous l’email de l’agence. Leur logique n’est souvent documentée nulle part.

La dette technique : ce qui se rattrape, ce qui se refait

La dette technique désigne l’ensemble des défauts de qualité interne d’un logiciel (raccourcis, code dupliqué, dépendances obsolètes) qui rendent chaque modification plus longue qu’elle ne devrait l’être. Martin Fowler en décrit le mécanisme : l’effort supplémentaire pour ajouter une fonctionnalité correspond aux « intérêts » payés sur cette dette, et le terme a été introduit par Ward Cunningham en 1992 (martinfowler.com).

Les trois voies d’un plan de reprise sont le maintien, la migration ou la refonte, en commençant par l’option la plus légère (ChallengeMyProject). Mais un audit honnête dit aussi quand refaire coûte moins cher que rattraper.

Reprise d’un site Drupal : la dette liée aux versions

Sur un site Drupal, la dette technique tient d’abord à la version majeure. Le calendrier officiel de drupal.org est sans appel (drupal.org, calendrier des versions) :

Drupal 12 doit sortir la semaine du 7 décembre 2026, selon la même page. Un site en Drupal 10 repris aujourd’hui a donc environ deux mois de support devant lui : la montée en Drupal 11 fait partie du devis de reprise, pas d’une phase ultérieure.

Pour Drupal 7, le cas est plus lourd. Depuis le 5 janvier 2025, il ne reçoit plus de mises à jour de sécurité ni de compatibilité de la part du projet. Drupal.org cite deux prestataires certifiés pour un support étendu payant, HeroDevs et Tag1 Consulting (drupal.org, fin de vie de Drupal 7). La même page présente la migration vers la dernière version de Drupal comme la voie qui garantit le support et les mises à jour de sécurité. Dans une reprise de site Drupal, cette migration se chiffre à part, dès l’audit.

Les livrables avant de chiffrer un devis

Un audit de reprise qui tient la route produit quatre livrables avant tout chiffrage :

1. La liste des accès obtenus, ceux qui manquent et le plan pour les récupérer.
2. L’état de la propriété juridique, avec les documents manquants.
3. Le rapport d’audit du code : dépôt, versions, licences, sauvegardes testées.
4. Le rapport de dette technique, avec un chiffrage pour chaque scénario (maintien, migration, refonte).

Si la reprise change l’hébergement, le CMS ou la structure des URL, la conservation des URL existantes et les redirections 301 conditionnent le trafic déjà acquis. La marche à suivre est détaillée dans notre guide pour changer d’agence sans tout casser. Pour confier la reprise à une agence : reprise de site web.