Blog / Histoire de Freelance
Développeur Web Freelance : comment se déroule un projet, du devis à la livraison
Un projet de développement web freelance suit une trame assez stable, du premier échange au devis jusqu'à la livraison - la connaître permet d'anticiper ce qui est attendu de chaque côté. Un développeur qui chiffre sans poser de questions précises sur le projet mérite une vigilance particulière.
Un projet de développement web freelance suit généralement une trame assez stable, même si 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é, et 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, listant les fonctionnalités attendues
- Des 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
- Un budget indicatif, même approximatif, pour cadrer les options réalistes
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
| Étape | Projet bien mené | Projet chaotique |
|---|---|---|
| Cadrage initial | Questions précises, périmètre clarifié par écrit | Devis flou basé sur une demande générale |
| Suivi pendant le développement | Points d'étape réguliers | Silence jusqu'à la livraison finale |
| Recette avant mise en ligne | Phase structurée et documentée | Livraison directe sans vérification formelle |
| Passation finale | Accès complets transmis clairement | Dépendance au développeur pour des accès non transmis |
Combien de temps dure en moyenne le cadrage avant un devis ?
Cela varie selon la complexité du projet, mais un premier échange suivi d'un devis sous une à deux semaines reste une durée courante pour un projet de taille standard.
Un devis peut-il évoluer après avoir été accepté ?
Oui, si le périmètre change en cours de projet. Cette évolution donne lieu à un avenant chiffré séparément, plutôt qu'une renégociation globale du devis initial.
Faut-il exiger un accès à l'environnement de test pendant le développement ?
C'est une bonne pratique, elle permet de suivre l'avancement réel du projet et de signaler tôt d'éventuels écarts par rapport aux attentes, plutôt que de découvrir des problèmes à la toute fin.
Que faire si le développeur ne respecte pas le délai annoncé ?
Une communication claire sur les raisons du retard reste le signal le plus rassurant. Un développeur qui prévient à l'avance d'un retard justifié inspire davantage confiance qu'un silence jusqu'à l'échéance dépassée.
Le client doit-il valider chaque étape avant de passer à la suivante ?
C'est recommandé pour les étapes structurantes (maquette, architecture générale), mais un contrôle systématique sur chaque détail ralentit inutilement le projet sans apporter de valeur proportionnelle.
Que couvre généralement la période de garantie après la mise en ligne ?
Le plus souvent, les bugs liés au périmètre initial du devis, découverts après la mise en ligne. Les demandes de nouvelles fonctionnalités, même mineures, sortent en général de cette garantie et relèvent d'une prestation complémentaire.
Comment éviter les malentendus sur le nombre de retouches incluses ?
En le précisant explicitement dans le devis, avec un nombre de cycles défini plutôt qu'une formulation vague comme des retouches raisonnables, qui prête à des interprétations différentes selon les parties.
