Projet web avec un freelance : du devis à la livraison

Ce guide développeur web freelance devis et déroulement de projet répond à une question simple : à quoi ressemble concrètement un projet, de la demande de devis à la livraison finale. Un projet de développement web freelance suit généralement une trame assez stable. Le vocabulaire et le degré de formalisme varient d'un prestataire à l'autre. Connaître ces étapes permet d'anticiper ce qui est attendu de chaque côté. Cela permet aussi de repérer rapidement si un prestataire s'écarte d'un déroulement de projet sérieux.

Un client qui aborde son premier projet web sans connaître cette trame générale se retrouve souvent en position de subir le déroulement du projet plutôt que de le piloter activement, ce qui augmente le risque de malentendus évitables sur les attentes de chaque étape.

Les documents à préparer avant le premier échange.

Un premier échange constructif avec un développeur web freelance se prépare, en réunissant en amont les éléments qui permettront un chiffrage fiable.

Ce qui facilite un premier échange productif.

Une description du besoin, même informelle, qui liste les fonctionnalités attendues. Quelques exemples de sites dont le style ou les fonctionnalités inspirent le projet. Le contenu déjà disponible (textes, images, logo), ou son état d'avancement. Et un budget indicatif, même approximatif. Ces éléments suffisent généralement à cadrer des options réalistes dès le premier échange.

Ces éléments ne doivent pas être parfaits avant le premier contact. Un développeur sérieux aide à les préciser au fil de l'échange, mais leur absence totale allonge inutilement la phase de cadrage.

Étape 1 : le cadrage initial.

Le premier échange sert à clarifier le besoin réel, souvent différent de la demande initiale formulée de façon générale par le client.

Ce qui se passe concrètement lors du cadrage.

• Des questions précises du développeur sur les objectifs et les contraintes du projet.
• Une première estimation du périmètre technique nécessaire.
• L'identification des points qui restent à clarifier avant de chiffrer précisément.

Un développeur qui propose un chiffrage sans poser de questions précises sur le projet mérite une vigilance particulière, ce type de devis reposant rarement sur une compréhension fine du besoin réel.

Étape 2 : le devis détaillé.

Le devis formalise le périmètre convenu lors du cadrage, avec un niveau de détail qui permet de vérifier que les deux parties partagent la même compréhension du projet.

Ce qu'un devis sérieux doit contenir.

• Le détail des fonctionnalités incluses, pas seulement un montant global.
• Le nombre de cycles de retouches prévus avant livraison finale.
• Le délai de livraison estimé, avec les conditions qui pourraient le faire varier.
• Les modalités de paiement (acompte, étapes intermédiaires, solde à la livraison).

Étape de paiement.	Pratique courante.
Acompte au démarrage.	Généralement 30 à 50 % du montant total.
Paiement intermédiaire.	À la validation d'une étape clé (maquette, version de test).
Solde à la livraison.	Réglé après recette et mise en ligne finale.

Étape 3 : la conception et les maquettes.

Avant de coder, un développeur sérieux formalise l'architecture des pages ou de l'application, sous forme de maquettes ou de schémas de navigation, pour valider la structure générale avant d'investir du temps de développement dessus.

Pourquoi cette étape ne doit pas être sautée.

Modifier une structure de navigation une fois le développement bien avancé coûte beaucoup plus cher que d'ajuster une maquette avant le début du code. Cette étape, parfois perçue comme superflue par un client pressé, protège en réalité le budget global du projet.

Étape 4 : le développement.

C'est la phase la plus longue du projet, durant laquelle le développeur construit effectivement le site ou l'application selon le périmètre validé.

Un suivi régulier plutôt qu'un silence jusqu'à la livraison.

• Des points d'étape à intervalles réguliers, même courts.
• Un accès à un environnement de test pour suivre l'avancement concrètement.
• Une communication proactive en cas de difficulté technique rencontrée.

Un développeur qui disparaît pendant plusieurs semaines sans nouvelle avant de livrer un résultat final complet expose le projet à des ajustements tardifs coûteux s'il s'écarte du besoin réel.

Étape 5 : la recette et les tests.

Avant la mise en ligne définitive, une phase de recette permet de vérifier que le site fonctionne conformément aux attentes, sur différents navigateurs et appareils.

Ce que le client doit vérifier lors de la recette.

• Le fonctionnement de toutes les fonctionnalités prévues au devis.
• L'affichage correct sur mobile et sur les principaux navigateurs.
• Les temps de chargement en conditions réelles.
• La cohérence du contenu final avec ce qui avait été fourni ou validé.

Cette phase de recette structurée évite de découvrir des problèmes après la mise en ligne, moment où les corriger devient souvent plus visible et plus urgent pour l'entreprise.

Étape 6 : la mise en ligne et la passation.

La mise en ligne ne clôt pas seulement le développement, elle s'accompagne d'une passation qui garantit l'autonomie du client sur son propre site.

Ce qu'une bonne passation doit inclure.

• L'accès complet aux identifiants (hébergement, nom de domaine, back-office).
• Une documentation minimale sur la gestion courante du site.
• Les modalités de suivi post-livraison, maintenance ponctuelle ou contrat récurrent.

Un développeur qui garde pour lui certains accès sans les transmettre clairement au client crée une dépendance qui devient problématique en cas de fin de collaboration.

Étape 7 : le suivi après la mise en ligne.

La livraison du site ne signifie pas nécessairement la fin de la relation avec le développeur. La plupart des projets prévoient une période de garantie ou un contrat de suivi qui prend le relais juste après la mise en ligne.

Ce qui se passe généralement dans les premières semaines.

• Une période de correctifs gratuits sur les bugs découverts après la mise en ligne réelle.
• Un point de bilan avec le client sur les premiers retours utilisateurs.
• La mise en place, si prévue, d'un contrat de maintenance pour la suite.

Cette phase transitoire, souvent négligée dans les échanges initiaux, mérite d'être clarifiée dès le devis pour éviter une ambiguïté sur ce qui reste couvert gratuitement et ce qui relève déjà d'une nouvelle prestation facturée.

Les malentendus les plus fréquents entre client et développeur.

Certains points reviennent régulièrement comme source de tension, souvent parce qu'ils n'ont pas été clarifiés explicitement dès le début du projet.

Le périmètre exact des retouches incluses.

Un client qui multiplie les demandes de modification en pensant qu'elles entrent dans le forfait initial, alors que le devis ne prévoyait qu'un nombre limité de cycles de retouches, crée une tension évitable si ce point avait été précisé dès le devis.

La propriété du code et des accès.

Un client doit clarifier dès le devis qu'il sera propriétaire du code et des accès à la livraison, un point qui semble évident mais qui mérite d'être écrit noir sur blanc plutôt que présumé implicitement par l'une ou l'autre des parties.

La disponibilité réelle du développeur pendant le projet.

Un développeur qui gère plusieurs missions en parallèle doit être transparent sur sa disponibilité réelle pour le projet en cours, plutôt que de laisser croire à une disponibilité exclusive qui ne correspond pas à la réalité de son planning.

Comment un client peut piloter activement son propre projet.

Un client n'a pas besoin de compétences techniques pour bien piloter un projet web, mais quelques réflexes simples améliorent nettement le déroulement global.

• Répondre rapidement aux questions du développeur pour ne pas ralentir l'avancement.
• Centraliser les retours dans un seul document plutôt que les disperser sur plusieurs canaux.
• Prioriser clairement les demandes plutôt que de tout présenter comme urgent.
• Poser des questions dès qu'un point du devis ou du planning n'est pas clair.

Ces habitudes simples réduisent considérablement le nombre d'allers-retours inutiles et contribuent à un projet livré dans les délais annoncés au départ.

Ce qui distingue un projet bien mené d'un projet chaotique.

Sur un projet bien mené, le cadrage initial repose sur des questions précises et un périmètre clarifié par écrit. Un projet chaotique démarre au contraire sur un devis flou basé sur une demande générale. Le suivi pendant le développement se traduit par des points d'étape réguliers d'un côté, par un silence jusqu'à la livraison finale de l'autre. La recette avant mise en ligne est structurée et documentée dans un cas, expédiée sans vérification formelle dans l'autre. Et la passation finale transmet des accès complets et clairs dans un projet bien mené. Un projet mal mené, lui, laisse le client dépendant du développeur pour des accès jamais réellement transmis.

Avant de lancer une consultation, l'article cahier des charges site web : obtenir un devis fiable aide à préparer un cahier des charges qui limite les mauvaises surprises de périmètre. Sur les technologies concrètement mobilisées pendant le développement, la référence MDN Web Docs permet de mieux suivre les choix techniques du prestataire.