Développeur web freelance : vendre une mission clairement délimitée
Un client demande rarement une technologie pour elle-même. Il veut remettre un site en service, simplifier un parcours, livrer une fonctionnalité ou rendre un outil maintenable. Pour un développeur web, front-end, fullstack ou intégrateur, la proposition commerciale gagne à partir de cette situation avant de détailler la pile technique.
Transformer la demande en périmètre
« Refaire le site » ne suffit pas à estimer une mission. Demandez quelles pages et quels parcours sont concernés, qui fournit les contenus, quels systèmes sont connectés et comment la livraison sera acceptée. Une refonte visuelle, une migration de données et une réécriture complète impliquent des travaux différents.
Pour une mission JavaScript, React, Vue.js, Angular, PHP ou WordPress, identifiez aussi les versions et extensions déjà utilisées, l’environnement de test et les contraintes d’hébergement. Cette prise de connaissance sert à chiffrer les incertitudes, sans promettre une compatibilité avant d’avoir examiné le projet.
Présenter un cas de travail lisible
Votre portfolio doit expliquer votre contribution. Montrez le problème initial, une décision technique, la manière de vérifier le résultat et ce qui a été transmis à l’équipe. Une capture esthétique ne démontre pas la qualité du code ; un dépôt public sans explication ne raconte pas forcément le besoin résolu.
Si vous utilisez une démonstration personnelle, dites-le. Pour un projet client, obtenez les autorisations nécessaires avant de publier du code, des captures ou des mesures. La preuve peut rester utile sous une forme reconstruite qui ne révèle aucune information confidentielle.
Estimer par lots vérifiables
Découpez le travail en prise en main, réalisation, tests, corrections et transmission. Pour chaque lot, indiquez ses dépendances : contenu disponible, maquettes validées, accès ou réponse d’un tiers. Une journée de développement bloquée par une décision ne doit pas disparaître de l’analyse du calendrier.
Exemple hypothétique : une fonctionnalité estimée à quatre jours de réalisation peut aussi nécessiter un jour de préparation et deux jours de tests et de corrections. À 600 € HT par jour, sept jours représentent 4 200 € HT. Il s’agit d’un budget d’exemple, pas d’un tarif de marché ni d’une durée standard.
Définir la recette avant la livraison
Listez les parcours à vérifier, les environnements attendus et les erreurs bloquantes. Précisez qui teste et comment les remarques sont consolidées. Une demande nouvelle apparue pendant la recette doit être distinguée d’un écart par rapport au périmètre initial.
Convenez également du traitement après livraison : corrections prévues, maintenance éventuelle, transfert des accès et documentation. Une garantie de résultat formulée sans critères peut créer une attente impossible à mesurer. Préférez des engagements observables et réalisables.
Prospecter avec une offre concrète
Présentez une intervention que le client peut comprendre : fiabiliser un parcours de commande, préparer une migration ou reprendre une fonctionnalité documentée. Les partenaires de design, de contenu et d’exploitation peuvent constituer des relais si les responsabilités sont claires. Pour fixer votre base commerciale, appuyez-vous sur le calcul du TJM, puis ajustez le devis au risque et au travail réels.