Vous avez trouvé un bon développeur. Tant mieux. Mais un projet web ne déraille presque jamais à cause du code : il déraille parce que personne ne tient la barre. Des semaines sans nouvelle, un retour qui arrive trois jours après la deadline, une maquette validée à l'oral que plus personne ne retrouve. C'est là que les budgets glissent, pas dans la syntaxe.
Alors parlons de l'autre moitié du travail, celle dont on parle rarement : comment on avance ensemble, concrètement, du premier rendez-vous à la mise en ligne.
Tout commence par un cadre, pas par du code
Avant la première ligne, je veux savoir où on va. Pas une vague intention ("refaire le site"), un objectif mesurable : générer plus de demandes de devis, vendre en ligne, rassurer un acheteur grand compte. De cet objectif découle tout le reste, donc on prend le temps de le poser noir sur blanc.
C'est le rôle du cadrage. Pour les projets à plusieurs intervenants ou avec un budget qui se défend en interne, ça prend la forme d'un cahier des charges qui sert de boussole tout au long de la mission : ce qu'on fait, ce qu'on ne fait pas, dans quel ordre. Ce document n'est pas de la paperasse. C'est ce qui m'évite de vous livrer un truc magnifique mais à côté de votre besoin, et ce qui vous évite de payer trois allers-retours pour le découvrir.
Si vous hésitez encore entre plusieurs profils à ce stade, j'ai détaillé ailleurs comment départager un développeur freelance sérieux d'un autre. Mais une fois le bon choisi, le vrai sujet devient le pilotage.
Un rétroplanning daté, pas une vague estimation
"On en aura pour deux mois environ" ne veut rien dire. Ça n'engage personne et ça ne se vérifie pas.
Un projet qui avance, ce n'est pas de la magie : c'est un rétroplanning daté qu'on tient ensemble, jalon par jalon. Je découpe la mission en phases, chacune avec une date : contenus, maquettes, développement, recette, formation, mise en ligne. Chaque phase a un livrable précis et une date à laquelle on la valide. Vous savez où on en sera la semaine prochaine, et celle d'après.
Ce planning n'est pas gravé dans le marbre par moi tout seul. On le négocie. Si vous me dites que les contenus prendront plus de temps de votre côté (et c'est souvent le cas, soyons honnêtes), on décale la suite en conséquence plutôt que de faire semblant. Un planning qu'on subit est un planning qu'on ne tient pas ; un planning qu'on a construit à deux, on s'y tient.
Concrètement, je pilote mes projets en semaines. Chaque tâche a une échéance, chaque semaine a son lot de livrables, et il y a une colonne dédiée à la mise en production avec sa propre checklist. Rien ne passe à l'étape suivante tant que l'étape d'avant n'est pas validée. Ça paraît évident écrit comme ça. Dans les faits, c'est ce qui sépare un projet qui sort à la date prévue d'un projet qui traîne six mois.
Le retour sous 48h, dans les deux sens
Voici la règle qui change tout, et elle vaut autant pour vous que pour moi : on se répond sous 48 heures.
Quand je vous envoie une maquette, un texte, une fonctionnalité à tester, vous avez deux jours ouvrés pour réagir. Pas besoin d'un rapport détaillé, juste un retour clair : ça me va, ou voilà ce qui coince. De mon côté, même engagement. Vous m'écrivez une question le mardi, vous avez une réponse le mercredi ou le jeudi, pas dans dix jours.
Pourquoi 48h et pas une semaine ? Parce qu'au-delà, on perd le fil. Vous oubliez pourquoi vous aviez demandé telle chose, moi je dois replonger dans un sujet que j'avais en tête à chaud. Les retours qui traînent, ce sont des heures perdues à se remettre dans le bain, des deux côtés. Des retours rapides, c'est un projet qui garde son élan.
Et soyons clairs : si vous n'avez pas le temps de regarder mes livrables, le projet ralentit. Ce n'est pas une menace, c'est mécanique. Le pilotage marche dans les deux sens, donc je vous le dis dès le départ pour qu'on s'organise.
Des points réguliers, courts et utiles
Je n'aime pas les réunions qui s'éternisent pour meubler. Un bon point de suivi, c'est quinze à trente minutes, avec un ordre du jour clair : où on en est sur le planning, ce qui est validé, ce qui est en attente de votre côté, ce qui arrive ensuite.
Sur les projets qui réunissent plusieurs personnes (un dirigeant, un responsable com, parfois une designer ou un partenaire SEO), j'anime ces réunions et j'envoie un compte rendu sous 48h. Qui fait quoi, pour quand. Comme ça, personne ne se réveille trois semaines plus tard en disant "ah, je croyais que c'était toi qui devais envoyer les photos". C'est écrit, c'est partagé, on avance.
Ces points servent aussi à arbitrer. Un projet vivant, c'est un projet où des questions surgissent en cours de route : faut-il ajouter cette page, repenser ce tunnel, intégrer ce nouvel outil ? Je vous présente l'option, le coût, l'impact sur le planning, et on décide ensemble. Vous ne découvrez pas un changement de périmètre sur la facture finale.
Valider chaque jalon ensemble, vraiment
Un jalon validé, ce n'est pas "je t'ai montré, tu as hoché la tête". C'est un moment précis où on regarde le livrable, où vous testez, où vous me dites oui ou vous me listez ce qui manque, et où on acte par écrit avant de passer à la suite.
Cette validation par étapes vous protège. À chaque jalon, vous voyez le projet prendre forme, vous corrigez le cap tant que c'est facile et peu coûteux. Bien plus malin que de tout découvrir à la fin, quand changer quelque chose veut dire détricoter trois semaines de travail. C'est exactement la logique d'un audit qui regarde un parcours utilisateur avant de toucher au code : on valide les choix au bon moment, pas une fois que tout est figé.
Sur un outil métier que j'ai construit pour un organisme de formation, par exemple, on a validé brique par brique : d'abord l'import des documents, puis l'extraction automatique, puis la génération des attestations, puis l'archivage. À chaque étape, le client testait avec ses vrais fichiers et me disait ce qui collait ou pas à sa réalité. Si j'avais tout livré d'un bloc à la fin, on aurait découvert les écarts trop tard, et la facture des corrections aurait piqué.
Et après la mise en ligne ?
Le jour du lancement, je ne disparais pas. La mise en ligne suit une checklist stricte : sauvegarde, redirections en place pour ne perdre aucune position acquise, certificat de sécurité, plan du site envoyé à Google, et un contrôle le lendemain pour vérifier que tout tient debout en conditions réelles.
Ensuite, je reste joignable. Une bonne partie des dirigeants avec qui je travaille reviennent six mois ou un an plus tard avec le projet suivant, ou me confient la maintenance dans la durée. Ça n'arrive pas parce que je facture un contrat d'astreinte : ça arrive parce qu'on a construit une relation de travail où chacun sait à quoi s'attendre. Un projet bien mené, c'est le meilleur argument pour le suivant.
Ce qu'un bon pilotage vous fait gagner
Travailler avec un développeur freelance, ce n'est pas confier un site à une boîte noire et espérer un beau résultat. C'est avoir un interlocuteur unique qui tient le planning, qui vous répond vite, qui vous fait valider à chaque étape, et qui ne lâche pas l'affaire au moment de la mise en ligne.
Le code, franchement, c'est la partie la plus prévisible. Ce qui fait qu'un projet réussit, c'est la rigueur du pilotage autour. Un rétroplanning qu'on tient, des retours qui circulent, des décisions prises ensemble au bon moment : c'est moins spectaculaire qu'une démo flashy, mais c'est ce qui fait sortir un site à la date prévue, dans le budget prévu, et qui fait vraiment le travail qu'on attendait de lui.
Si vous avez un projet en tête et que vous voulez voir comment on le piloterait ensemble, parlons-en directement. Je préfère cadrer une bonne fois au début plutôt que rattraper en route.