Migrer un projet d’un web studio vers un freelance

Comment migrer un projet d’un web studio vers un freelance

Confier un projet d’un web studio à un freelance paraît simple, jusqu’à ce que le premier mot de passe manquant apparaisse. Ensuite, le planning change. Si le site a un CMS, un backend sur mesure et 14 tâches à moitié terminées, la passation doit être structurée, pas optimiste.

L’expression comment migrer un projet d’un web studio vers un freelance décrit un transfert pratique, pas un redémarrage créatif. Elle recouvre aussi des situations où il faut transférer un site web d’un web studio à un freelance sans perdre d’informations critiques. L’objectif est de faire avancer le projet pendant que les intervenants changent. Cela signifie vérifier ce qui existe, ce qui manque et ce que seul le studio sait encore.

1. Évaluer l’état actuel du projet

Commencez par le périmètre. Demandez la liste des tâches en cours, le brief signé, les dernières notes du client et le dernier jalon accepté. Si ces documents se contredisent, notez l’écart. Un projet qui semble “presque terminé” peut encore cacher 9 bugs ouverts et 3 pages oubliées.

Ensuite, examinez le codebase. Vérifiez la structure du dépôt, l’historique des branches, les notes de déploiement et les éventuels scripts personnalisés exécutés lors du build ou de la mise en ligne. Un freelance ne peut pas deviner pourquoi un formulaire de paiement ne casse que sur la préproduction à 2 h du matin. Si le studio utilisait des helpers privés ou des correctifs non documentés, consignez-les.

L’hébergement compte aussi. Identifiez l’hébergeur, le type de serveur, le fournisseur DNS, la source SSL, la configuration e-mail et les tâches cron. Un seul enregistrement DNS oublié peut envoyer le trafic au mauvais endroit. Une sauvegarde manquante peut transformer une simple mise à jour en appel de panique.

Les détails du CMS méritent la même attention. Indiquez la plateforme, la version, les plugins, les champs personnalisés et les rôles d’édition. Si le site utilise un thème sur mesure ou une extension d’administration développée par le studio, précisez-le. Un freelance doit savoir s’il travaille avec WordPress, une base Laravel personnalisée ou un hybride que seul un ancien développeur comprend.

Les fichiers de design font partie de l’état du projet, pas d’une note secondaire. Rassemblez les liens Figma, les fichiers sources, les dossiers d’export, les polices et le système visuel validé. Si le logo n’existe que dans un fil de discussion ou sur l’ordinateur de quelqu’un, documentez-le. Une seule licence de police manquante peut ralentir toute la migration.

Les délais doivent être confrontés au réel. Comparez les dates обещuess avec l’état actuel et les problèmes non résolus. Si le studio dit “mise en ligne la semaine prochaine” alors que le menu mobile échoue encore sur iPhone, cette date n’est pas fiable. Des délais sans preuves signifient souvent une pression supplémentaire pour le freelance dès le premier jour.

Les problèmes ouverts doivent être listés un par un. Incluez les bugs, les contenus en attente, les intégrations inachevées, les liens cassés et toute demande client encore en attente de validation. Cette liste doit montrer l’impact, pas le drame. Si l’inscription à la newsletter est cassée, cela représente des leads perdus. Si une page de catégorie manque, c’est un trou dans la navigation.

2. Identifier les risques et les dépendances

Les dépendances cachées causent la plupart des problèmes de transfert. Commencez par les services tiers : passerelles de paiement, cartes, API de livraison, liaisons CRM, services e-mail et outils d’analytics. Si un service est lié à un compte du studio, ou payé via un abonnement du studio, vérifiez à qui il appartient.

Les licences sont faciles à oublier et coûteuses à ignorer. Un thème acheté, un pack de photos stock, un plugin premium ou une licence de police ne se transfèrent pas forcément automatiquement. Demandez qui possède chaque licence et si le freelance pourra continuer à l’utiliser après la passation de projet web entre studio et freelance. Si la réponse reste floue, considérez le point comme non résolu.

Les outils propres à un prestataire peuvent verrouiller le projet. Certains studios construisent avec leurs propres scripts de déploiement, des outils de synchronisation de contenu sur mesure ou des systèmes de préproduction privés. Un freelance ne peut travailler avec ces outils que si l’accès et les instructions existent. Sinon, le projet dépend du studio pour chaque mise en ligne, ce qui est l’inverse d’une vraie passation.

Les restrictions d’accès doivent être cartographiées tôt. Vérifiez si le panneau d’hébergement autorise plusieurs administrateurs, si le dépôt utilise des permissions d’organisation et si le compte analytics peut être partagé en sécurité. Si le studio dit “on peut vous envoyer des captures d’écran à la place”, ce n’est pas un accès. C’est un retard.

Les dépendances cachées incluent aussi les personnes. Un account manager peut connaître le style de validation du client, tandis qu’un développeur peut connaître le bug de panier qui apparaît seulement après deux utilisations d’un code promo. Notez ces informations tant que le studio est encore disponible. Si la connaissance n’existe que dans les mémoires, documentez-la.

Pour les projets soumis à des règles de conformité, confirmez les limites avant le transfert. Un formulaire médical, un espace membre ou un site traitant des données personnelles peut exiger des journaux d’accès et des traces d’autorisation spécifiques. Le freelance ne doit pas découvrir ces contraintes après avoir modifié le premier champ.

Appliquez la même rigueur que pour comment engager un freelance en toute sécurité. Le but n’est pas la paranoïa. Le but est de réduire le nombre de surprises à un niveau qu’un humain peut gérer.

3. Préparer la checklist de passation

Une checklist de passation transforme un transfert flou en processus maîtrisé. Rassemblez le code source, les liens du dépôt, les identifiants, les assets de marque, les accès administrateur, les accès analytics, les sauvegardes, les contrats et l’historique du support. Si un élément manque, notez-le et indiquez qui doit le fournir.

Commencez par le code. Enregistrez le dépôt principal, les dépôts associés, les noms de branches, les branches de déploiement et la documentation d’installation locale. Si le studio utilise des sous-modules privés ou un dépôt de configuration séparé, incluez-les aussi. Un seul dépôt manquant peut bloquer le freelance dès le premier jour.

Viennent ensuite les identifiants. Listez les noms de connexion pour l’hébergement, le CMS, le registrar du domaine, la base de données, l’e-mail, le FTP ou SFTP, les analytics, le tag manager et tout autre outil tiers. Ne collez pas les mots de passe dans un simple message. Utilisez la méthode approuvée la plus sûre possible et consignez ce qui a été partagé.

Les assets de marque doivent être complets. Cela signifie logos, icônes, bibliothèques d’images, fichiers de polices, decks de contenu, guidelines de ton et références de couleurs validées. Si le studio ne remet que des PNG exportés, les fichiers de travail manquent. Un freelance peut avancer plus vite quand les originaux existent.

Les sauvegardes doivent être vérifiées avant tout transfert. Confirmez la date, l’emplacement, le format et la méthode de restauration. Si la dernière sauvegarde ne peut pas être restaurée, ce n’est pas une sauvegarde au sens utile du terme. C’est juste un fichier.

Les contrats et l’historique du support aident le freelance à comprendre les limites du projet. Recherchez les périodes de garantie, les engagements de maintenance, les conditions de correction de bugs et les obligations du client. Si ces conditions ne sont pas clairement écrites, notez-le. Un projet transféré conserve ses anciennes promesses.

Pour les équipes qui travaillent avec des tags et des catégories sur la plateforme, la page avec tous les tags sur la place de marché freelance peut aider à trouver des sujets et services connexes. C’est utile si le transfert inclut du nettoyage de contenu, du SEO ou un audit technique par un freelance qui a besoin d’un contexte plus large.

4. Choisir le bon freelance

Le bon freelance n’est pas seulement “disponible maintenant”. Vérifiez d’abord l’adéquation technique. Si le projet est développé en Vue, le freelance doit avoir une vraie expérience Vue, pas seulement une landing page de 2021. Si le site dépend de Laravel, WooCommerce ou d’une API personnalisée, demandez des exemples précis.

La disponibilité compte presque autant. Un freelance excellent mais indisponible pendant 3 semaines peut bloquer le projet au moment exact où le studio se retire. Demandez la vraie date de démarrage, le délai de réponse et la capacité hebdomadaire par écrit.

Le style de communication est facile à sous-estimer. Certains freelances écrivent des notes de suivi courtes et avancent vite. D’autres envoient de longues explications à chaque correctif. Les deux peuvent fonctionner, mais il faut que cela corresponde au projet. Si le client attend des réponses le jour même et que le freelance travaille en cycles de 48 heures, l’écart apparaîtra vite.

L’expérience des migrations similaires est utile, mais n’acceptez pas des affirmations vagues. Demandez si le freelance a repris un projet d’une autre équipe, corrigé du code non documenté ou restauré un processus de déploiement cassé. Un court examen de portfolio vaut mieux qu’une promesse bien présentée.

Demandez ce qui sera fait pendant les 72 premières heures. Un bon freelance devrait pouvoir nommer les premiers contrôles : lancer le site en local, inspecter les erreurs, tester le parcours de connexion, vérifier l’accès au déploiement et lire le backlog actuel. Si la réponse est seulement “je regarderai”, ce n’est pas suffisant.

Certains responsables de projet consultent aussi des signaux de profil comme les avis sur le freelance avant de faire leur choix final. Les avis ne sont pas une preuve, mais ils peuvent montrer si le freelance gère les révisions, la pression et les passations compliquées sans drame.

Un freelance ayant travaillé sur des projets de freelance pour designers peut aussi comprendre comment préserver la continuité visuelle pendant un transfert. C’est important lorsque le site se trouve à mi-chemin entre validation graphique et mise en ligne.

5. Transférer les accès et la documentation

Le transfert des accès doit se faire dans un ordre maîtrisé. Commencez par les systèmes les moins risqués, puis passez aux plus sensibles. Par exemple, partagez d’abord l’accès à la préproduction avant l’accès à la production, si la configuration le permet. Gardez une trace de chaque connexion, changement de permission et date de transfert.

Utilisez des comptes nominatifs lorsque c’est possible. Les comptes partagés compliquent l’identification des modifications. Si le panneau d’hébergement, l’administration du CMS et le dépôt autorisent des comptes séparés, créez-les. Une piste d’autorisations propre sera utile plus tard, surtout si quelque chose casse après le départ du studio.

La documentation doit accompagner l’accès. Le freelance a besoin des instructions d’installation, des notes de déploiement, des variables d’environnement, des logs d’erreur, de l’historique de validation et de tout document de processus rédigé par le studio. Si la documentation n’existe que dans des discussions de chat, exportez-la ou signalez les manques.

Conservez un tableau d’inventaire. Listez le système, le responsable, l’état actuel et l’action de transfert exacte. Exemple : “L’accès admin de l’hébergement de production a été transféré au freelance mardi.” Ce type d’enregistrement compte si un litige de paiement ou une enquête sur une panne survient ensuite.

La sécurité ne doit pas être théâtrale. Changez les mots de passe, faites tourner les clés API, désactivez les comptes du studio qui n’ont plus besoin d’accès et confirmez que le freelance peut encore travailler après les modifications. Si un token cesse de fonctionner après le transfert, mieux vaut le savoir le jour même qu’après un déploiement raté.

Lorsque le site touche des services cloud, comparez la configuration aux pratiques de l’informatique en nuage si cela fait partie de votre stack. La plateforme exacte importe moins que l’enregistrement de qui possède chaque compte et qui peut révoquer l’accès.

6. Définir le plan de travail initial du freelance

Le premier plan doit être court. Le jour 1 sert à stabiliser le projet, pas à le réécrire. Demandez au freelance de confirmer que le site fonctionne, d’identifier les fonctions cassées, d’examiner les changements récents et de lister les blocages. Si le plan prévoit une refonte complète dès la première semaine, c’est trop.

Les priorités doivent être classées. Les fonctions critiques passent d’abord : connexion, paiement, formulaires, recherche et tout parcours orienté client qui génère du chiffre d’affaires ou des tickets de support. Si cela est stable, le freelance peut passer aux corrections mineures. L’ordre compte, car une page de paiement cassée peut causer des pertes immédiates.

Demandez une petite liste de tests. Un freelance peut vérifier le déploiement, le chargement des pages, l’envoi des formulaires, le comportement mobile et les logs d’erreur pendant les premiers jours. Cette liste doit correspondre aux vraies faiblesses du projet. Si le site échouait sur Safari avant, Safari doit être testé maintenant.

Les jalons doivent être notés avec des dates confirmées par écrit. Évitez les expressions floues comme “bientôt” ou “le plus vite possible”. Si le premier jalon consiste à restaurer l’accès administrateur, nommez l’étape exacte et le responsable exact. Plus les 3 premières tâches sont claires, moins le temps se perd en réunions de suivi.

Demandez au freelance de signaler tout travail dépendant encore d’une contribution du studio. Un formulaire peut nécessiter une décision de contenu ; une passerelle de paiement peut exiger la validation du marchand ; un script de migration peut nécessiter l’explication de l’ancien développeur. Ces dépendances doivent être visibles dès le jour 1, pas découvertes au jour 7.

Si le projet comporte une section très riche en connaissances ou en contenu, une référence comme la création d’un site wiki peut aider à penser la structure de documentation. L’idée est pratique : le freelance doit disposer d’un endroit unique où trouver les informations.

7. Suivre la transition et clôturer le studio

Si possible, prévoyez une courte période de chevauchement. Même 2 ou 3 jours peuvent éviter des erreurs, car le studio peut répondre aux dernières questions pendant que le freelance commence à travailler. Pendant ce chevauchement, comparez l’ancienne configuration avec la nouvelle liste d’accès et vérifiez que le freelance peut réaliser les actions de base sans aide.

Validez les livrables avant de fermer quoi que ce soit. Vérifiez que les fichiers ont bien été reçus, que les mots de passe ont été modifiés, que les sauvegardes sont stockées et que le freelance peut déployer ou modifier le projet comme convenu. Si un livrable a été promis mais non reçu, notez-le et gardez le studio impliqué jusqu’à résolution.

La propriété doit être confirmée en langage clair. Les fichiers de marque, le code, l’hébergement, les analytics et le contrôle du domaine doivent tous être attribués à la bonne partie. Toute conclusion juridique ou contractuelle doit être vérifiée avec soin. Cela inclut les périodes de garantie, les factures finales et le fait que le studio doive encore ou non assurer le support d’un défaut déjà signalé.

Ne clôturez pas la relation avec le studio tant que les conséquences ne sont pas claires. Si le projet perd plus tard l’accès à un domaine ou à un asset parce que le transfert de propriété n’a jamais été effectué, le freelance héritera d’un problème qui aurait dû être réglé plus tôt. Cela s’évite avec un dernier contrôle documentaire.

Terminez la transition par une dernière note écrite : ce qui a été transféré, ce qui reste ouvert et qui possède chaque élément restant. Si un seul problème de paiement ou de licence est encore en attente, laissez-le visible. Un transfert de projet fonctionne mieux lorsque le dernier point non résolu reste visible jusqu’à sa résolution effective.