Oui, une autre agence peut reprendre un site web développé par quelqu’un d’autre, code sur mesure compris : ce qui bloque une reprise, ce sont les accès et les droits, pas le code lui‑même. La reprise se passe en trois temps : un audit, la récupération de ce qui manque, puis un plan chiffré qui choisit entre maintenir, migrer ou refaire. Aucun devis sérieux ne devrait précéder cet audit.
L’audit de reprise tient en quatre questions : 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
| Bloc | Question à trancher | Ce qu’on demande |
|---|---|---|
| Juridique | Le client a‑t‑il les droits sur le code et les créations ? | Contrat, facture acquittée, clause ou attestation de cession |
| Accès | Qui a la main sur le domaine, l’hébergement, les comptes ? | Identifiants administrateur, accès registrar et DNS |
| Code | Le code récupéré est‑il complet, versionné, à jour ? | Dépôt Git, versions, licences, sauvegardes |
| Dette technique | Combien coûte chaque évolution future ? | Rapport qui sépare ce qui se rattrape de ce qui se refait |
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 :
| Document | Ce qu’il doit prouver |
|---|---|
| Contrat ou devis signé | Une clause de cession de droits d’exploitation |
| Facture finale acquittée | Le paiement intégral du prestataire sortant |
| Attestation de cession (si absente du contrat) | L’accord écrit de l’agence sortante |
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.
Reprise de code et d’application web sur mesure : le cas Symfony
Une application web sur mesure (espace client, outil métier, plateforme de réservation) se reprend comme un site, mais l’audit de reprise de code y pèse plus lourd : aucun éditeur de CMS ne fournit les mises à jour, tout repose sur le code écrit par l’agence sortante. Aux cinq points ci‑dessus s’ajoutent quatre vérifications :
- L’installation : peut‑on monter l’application sur un poste neuf à partir du seul dépôt et de sa documentation ? Si ce n’est pas le cas, c’est le premier livrable à exiger.
- La configuration : variables d’environnement, clés d’API, tâches planifiées et files de messages, souvent réglées sur le serveur et absentes du dépôt.
- Les migrations de base de données : leur historique doit permettre de reconstruire le schéma de production.
- Les tests automatisés : leur présence et leur état. Sans tests, chaque correction se vérifie à la main.
Pour une application Symfony, l’audit relève la version du framework et la confronte à la politique de maintenance officielle. La dernière version mineure de chaque branche (5.4, 6.4…) est une version à support long, avec trois ans de corrections de bugs et quatre ans de correctifs de sécurité, contre huit mois pour les autres versions (symfony.com, processus de release). Fin octobre 2026, la liste officielle des versions maintenues compte 6.4, 7.4 et 8.1, et 5.4 ne reçoit plus que des correctifs de sécurité (symfony.com, versions). Une application restée sur une version absente de cette liste, Symfony 4 ou une version intermédiaire comme 6.2, ne reçoit plus aucun correctif : la montée de version se chiffre dès l’audit, avant toute nouvelle fonctionnalité.
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).
| Type de dette | Symptômes | Décision |
|---|---|---|
| Acceptable | Code daté mais stable, pas de tests automatisés, quelques extensions à mettre à jour | Rattraper progressivement |
| Bloquante | Régressions à chaque modification, CMS hors support, mise en production risquée | Migration ou refonte à chiffrer |
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) :
| Version | Fin de support |
|---|---|
| Drupal 7 | 5 janvier 2025 |
| Drupal 9 | 1er novembre 2023 |
| Drupal 10 | 9 décembre 2026 |
| Drupal 11 | Pas de date annoncée à ce jour |
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 :
- La liste des accès obtenus, ceux qui manquent et le plan pour les récupérer.
- L’état de la propriété juridique, avec les documents manquants.
- Le rapport d’audit du code : dépôt, versions, licences, sauvegardes testées.
- 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. Si vous cherchez un prestataire pour mener cet audit puis la reprise elle‑même, notre page reprise de site web détaille ce que Peechy prend en charge : récupération des accès et du nom de domaine, audit, documentation, maintenance.
FAQ
Qui peut reprendre un site web développé par quelqu'un d'autre ?
Toute agence web ou tout développeur qui maîtrise la technologie du site (WordPress, Drupal, Symfony ou autre). Ce qui limite la reprise, ce n’est pas le code mais ce qui l’entoure : les accès administrateur, le dépôt de code et une cession de droits écrite. Avec ces trois éléments, un prestataire compétent peut reprendre le site.
Une agence peut‑elle reprendre le code d'une autre agence ?
Oui. Elle commence par un audit de reprise de code : accès au dépôt, écart entre le dépôt et la production, versions, licences, sauvegardes. Sur le plan juridique, il faut que vous déteniez les droits d’exploitation sur ce code, d’où la vérification du contrat et de la clause de cession avant de démarrer.
Que faut‑il récupérer avant de changer de prestataire ?
Les accès au registrar et à la zone DNS, à l’hébergement, à la base de données et au back‑office en administrateur, le dépôt de code, les comptes tiers (emails, paiement, Analytics, Search Console), la liste des licences payantes et une sauvegarde complète dont la restauration a été testée. Côté documents : le contrat, la facture finale acquittée et la cession de droits.
Comment se passe la reprise d'un site web existant ?
Elle commence par un audit en quatre blocs : propriété juridique, accès, état du code, dette technique. Viennent ensuite la récupération des accès et des droits, puis un plan chiffré qui choisit entre maintien, migration ou refonte. Aucun devis sérieux ne précède cet audit.
Peut‑on reprendre un projet web existant sans l'accord de l'agence ?
Techniquement, si vous détenez les accès au domaine et à l’hébergement, oui. Juridiquement, sans cession de droits écrite sur le code et les créations graphiques, l’agence sortante conserve ses droits d’auteur, même après paiement intégral. C’est un risque à évaluer avant de migrer.
Que vérifier lors d'une reprise de code ?
Cinq points : l’accès au dépôt avec les droits d’administration, la correspondance entre le dépôt et la production, les versions du CMS, de PHP et des dépendances, les licences payantes et leur titulaire, et des sauvegardes dont la restauration a été testée.
Un site Drupal 7 peut‑il encore être repris ?
Oui, mais Drupal 7 n’a plus de support officiel depuis le 5 janvier 2025. Il faut soit souscrire un support étendu auprès d’un prestataire certifié, soit migrer vers Drupal 11. La migration est un chantier à part entière, à chiffrer dès l’audit.
Faut‑il refaire un site plutôt que le reprendre ?
Pas forcément. On commence par l’option la plus légère : sécuriser et mettre à jour l’existant. La refonte se justifie quand la dette est bloquante : régressions à chaque modification, version hors support, architecture qui n’accepte plus d’évolution simple.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout, hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy
