Reprendre un projet web mené par une autre agence est d'abord une question d'ordre, pas de compétence. Sécurisez chaque compte et chaque actif au nom de votre société, consacrez une semaine à cartographier ce qui tourne réellement en production, puis stabilisez pendant trente jours avant de faire évoluer quoi que ce soit de visible. Les passations échouent rarement parce que les gens sont mauvais ; elles échouent parce que cet ordre a été sauté. Cette checklist le déroule étape par étape.
Que sécuriser avant toute chose ?
Avant toute revue de code, transférez la propriété de chaque actif dont le produit dépend : registrar du nom de domaine, DNS, comptes d'hébergement et de cloud, dépôt de code, secrets de CI/CD, sauvegardes de base de données et services tiers. Propriété signifie des comptes au nom de votre société, pas des accès invités dans les comptes de l'agence sortante.
- Registrar : votre compte, votre facturation, verrou de transfert activé.
- Zone DNS : exportée, puis hébergée sous un compte que vous contrôlez.
- Hébergement et cloud : rôle propriétaire à votre nom ; l'agence sortante garde au plus un siège temporaire.
- Dépôt de code : propriété transférée à votre organisation, pas un fork ni une archive zip.
- Secrets CI/CD : inventoriés maintenant, changés dès la fin du transfert.
- Base de données : une sauvegarde prise aujourd'hui et restaurée ailleurs pour prouver qu'elle se restaure.
- Tiers : prestataire de paiement, e-mails transactionnels, analytics, suivi d'erreurs.
Une sauvegarde jamais restaurée est un espoir, pas une sauvegarde. Vérifiez-la avant de valider quoi que ce soit d'autre.
À quoi ressemble l'audit de reprise ?
Une semaine cartographiée, pas une réécriture. L'audit répond à quatre questions : qu'est-ce qui tourne où, sur quelles versions, comment un changement atteint la production, et qu'est-ce qui vous prévient quand quelque chose casse. Le livrable : une carte du système sur une page et une liste de risques hiérarchisée, la même logique carte-d'abord que nous appliquons aux migrations sans coupure.
Les versions comptent dès le début : comparez chaque runtime au calendrier officiel des versions Node.js ; un runtime en fin de vie passe directement en tête de liste. Parcourez ensuite le chemin de déploiement vous-même : si personne de votre côté ne peut livrer un changement, vous ne contrôlez pas encore le produit. Terminez par les dépendances silencieuses : tâches cron, étapes manuelles, ce serveur que personne n'ose redémarrer.
Quels points juridiques et pratiques régler ?
Quatre points à vérifier dans le contrat initial : à qui appartient le code, quelles licences ont été achetées et à quel nom, quelle documentation était due, et si des factures ouvertes bloquent le transfert. La friction d'une passation est presque toujours structurelle : clauses floues et soldes impayés, rarement de la mauvaise foi.
En droit français, payer un développement ne transfère pas automatiquement la propriété intellectuelle : la cession doit être écrite et explicite dans le contrat, relisez donc la clause avant de considérer le code comme le vôtre. Listez chaque licence payante (plugins, polices, abonnements SaaS) et vérifiez lesquelles sont enregistrées au nom de l'agence plutôt qu'au vôtre. Et soldez les factures ouvertes tôt : un impayé est la raison la plus fréquente pour laquelle une passation coopérative devient silencieuse.
Vous héritez d'un projet sans savoir ce que vous contrôlez vraiment ? Décrivez votre système : diagnostic d'une page sous 48 h.
Recevoir mon diagnostic →Comment se déroulent les trente premiers jours ?
Stabiliser avant de faire évoluer. Le premier mois a trois missions : mettre en place la supervision pour voir le système, trier les dépendances pour savoir quelles mises à jour sont urgentes, et livrer un déploiement petit et réversible pour prouver que la chaîne fonctionne de bout en bout. Les nouvelles fonctionnalités attendent que ces trois points soient faits.
La supervision vient en premier parce que toutes les décisions suivantes en dépendent : suivi d'erreurs, contrôles de disponibilité et accès aux logs dès le premier jour. Pour le tri, un passage d'OWASP Dependency-Check sépare les vulnérabilités connues (urgentes) des versions majeures en retard (planifiables). Le déploiement réversible peut être trivial, un changement de texte suffit : ce qu'il prouve, c'est que vous savez livrer et, surtout, revenir en arrière.
Quels signaux d'alerte changent le plan ?
Trois constats imposent une reprise plus prudente : pas d'environnement de staging, des secrets commités dans le dépôt, et un savoir concentré sur une seule personne. Aucun n'est rare, aucun n'est une faute morale ; chacun change simplement l'ordre des opérations avant que le schéma standard des trente jours ne s'applique.
Pas de staging : vous en construisez un avant de toucher à la production, sans exception. Des secrets dans le dépôt : chaque identifiant présent dans l'historique git est compromis par définition ; changez-les tous, puis passez à un coffre-fort en suivant la cheat sheet OWASP sur la gestion des secrets et les bonnes pratiques de sécurité Node.js. Un point de défaillance humain unique : réservez dès maintenant des sessions de passation payées avec cette personne, tant que la bonne volonté existe.
Reprise à chaud ou reprise préparée : qu'est-ce qui change ?
Une reprise à chaud (l'agence précédente est partie ou ne répond plus) et une reprise préparée (une période de recouvrement négociée) suivent la même checklist avec des marges de sécurité très différentes. Si un recouvrement reste possible, même deux semaines de coopération, prenez-le : il transforme plusieurs risques élevés en tâches de routine.
| Dimension de risque | Reprise à chaud | Reprise préparée |
|---|---|---|
| Accès aux comptes | Procédures de récupération, litiges registrar, délais | Transferts de propriété simples |
| Rotation des secrets | Immédiate, sous pression | Planifiée, service par service |
| Transfert de savoir | Lire le code, deviner l'intention | Sessions avec l'équipe sortante |
| Premier déploiement | Risque élevé, chaîne inconnue | Répétition supervisée possible |
| Sécurité des données | Sauvegardes de fraîcheur incertaine | Restauration vérifiée avant bascule |
Comment gardons-nous la prochaine passation facile ?
La réversibilité est une décision d'installation, pas une promesse. Sur les projets que nous reprenons, le dépôt vit dans l'organisation du client, l'infrastructure tourne sur les comptes du client, et la documentation de passation s'écrit dès le premier jour. Une reprise bien faite ne devrait jamais avoir à être refaite pour la même raison.
C'est aussi pourquoi nos missions de modernisation backend commencent par la carte décrite plus haut : l'audit qui permet de reprendre un projet en sécurité est le même que celui qui permet de le faire évoluer ensuite.
La checklist de reprise
- Domaine, DNS, hébergement, dépôt, CI/CD et comptes tiers au nom de votre société.
- Tous les secrets changés une fois le transfert terminé.
- Une sauvegarde restaurée et vérifiée, pas seulement téléchargée.
- Contrat vérifié : propriété du code, licences, documentation due, factures ouvertes.
- Carte du système sur une page, risques hiérarchisés.
- Supervision en place avant tout changement.
- Dépendances triées : vulnérabilités d'abord, majeures planifiées.
- Un petit déploiement réversible livré, puis annulé volontairement.
- Signaux d'alerte consignés, plan réordonné en conséquence.
- Documentation de passation pour l'équipe suivante commencée dès le premier jour.