Pourquoi la communication fait souvent la différence dans un projet web

Le projet à 80 000 euros qui a échoué

En agence, j'ai vu un projet à 80 000 euros partir en fumée. L'équipe était solide : des développeurs seniors, une stack moderne, un planning bien ficelé. Sur le papier, tout était réuni pour que ça marche.

Ça n'a pas marché.

Le problème n'était pas technique. Le cahier des charges faisait 45 pages. Très détaillé, très précis. Le développeur lead l'a lu, l'a pris au pied de la lettre, et a codé exactement ce qui était écrit. Sauf que ce qui était écrit ne correspondait pas à ce que le client voulait vraiment. Le commercial avait reformulé le besoin avec ses mots. Le chef de projet avait rajouté sa couche d'interprétation. Et personne n'avait demandé au client : "Concrètement, c'est quoi le problème que vous essayez de résoudre ?"

Le code était propre. L'architecture, solide. Mais le produit final ne servait à rien parce qu'il répondait à une question que personne n'avait posée.

Le projet à 12 000 euros qui a tout bien fait

Quelques mois plus tard, un autre projet. Budget modeste : 12 000 euros. Le développeur n'était pas senior. Mais il posait des questions. Beaucoup de questions. Des questions parfois naïves. "Pourquoi vous avez besoin de cette fonctionnalité ?", "C'est qui concrètement qui va utiliser cet écran ?", "Quand vous dites 'reporting', vous imaginez quoi exactement ?"

Le client était un peu surpris au début. Il s'attendait à ce qu'on prenne sa demande et qu'on livre. Mais au bout de deux semaines, il a compris. Les specs ont été simplifiées. Deux fonctionnalités prévues ont été supprimées parce qu'en creusant, elles ne servaient à personne. Le projet a été livré en avance, sous budget, et le client l'utilise encore aujourd'hui.

La variable entre ces deux projets n'était ni l'expérience, ni la stack technique, ni le budget. C'était la communication.

Ce que "bien communiquer" veut dire en pratique

Ce n'est pas envoyer des comptes-rendus de 3 pages après chaque réunion. Ce n'est pas multiplier les points d'avancement. C'est beaucoup plus simple et beaucoup plus rare que ça.

Bien communiquer, c'est d'abord poser les bonnes questions avant d'écrire une seule ligne de code. Pas "quelle fonctionnalité vous voulez" mais "quel problème vous essayez de résoudre". Pas "quelles pages vous voulez" mais "qui va utiliser ce produit au quotidien et pour faire quoi". Pas "quel design vous préférez" mais "à quoi ressemble un projet réussi pour vous, dans 3 mois".

Ces questions semblent évidentes. Elles ne sont presque jamais posées. J'ai vu des projets entiers lancés sans que personne n'ait clarifié le critère de succès. Comment savoir si on a bien livré si personne ne sait ce que "bien livré" veut dire ?

Bien communiquer, c'est aussi oser dire non. Ou du moins oser proposer des alternatives. Un client me demande une fonctionnalité complexe, je prends le temps de comprendre pourquoi. Parfois la réponse est "oui, il faut exactement ça". Mais souvent, il y a une approche plus simple qui résout le même problème en deux fois moins de temps. Le client connaît son métier mieux que moi. Mon rôle, c'est d'apporter le regard technique pour qu'on trouve ensemble la meilleure solution. Pas de hocher la tête et de facturer des jours.

Et puis il y a le truc le plus efficace que j'ai appris : montrer au lieu de décrire. Une démo de 5 minutes remplace un email de 200 lignes. Quand le client voit son produit en action, même incomplet, le feedback est immédiat et concret. "Ah non, ce bouton devrait être là", "En fait quand je disais reporting, je pensais plutôt à ça". On ajuste en temps réel. On ne découvre pas les malentendus trois semaines plus tard.

Le test pour choisir votre prochain freelance

Voici un truc simple que j'ai remarqué. Quand vous évaluez un développeur freelance, demandez-lui de vous parler de son dernier projet.

S'il commence par le contexte du client, le problème à résoudre et le résultat obtenu, c'est quelqu'un qui pense en termes de valeur. Il comprend que le code est un moyen, pas une fin. S'il commence par les choix techniques, le framework, l'architecture, c'est un passionné, et c'est très bien. Mais l'idéal, c'est quelqu'un qui sait faire les deux. Quelqu'un qui peut avoir une conversation business à 10h et une conversation technique à 14h.

Méfiez-vous du développeur qui dit oui à tout sans poser de questions. Ce n'est pas de la flexibilité, c'est un drapeau rouge. Les meilleurs développeurs que j'ai côtoyés en agence étaient ceux qui challengeaient le besoin. Pas pour être pénibles, mais parce qu'ils savaient que comprendre le vrai problème est la moitié du travail.

Comment je fonctionne

Je commence chaque collaboration par un échange de 30 minutes où on ne parle pas de technique. On parle de votre contexte, vos contraintes, vos priorités. Je veux comprendre pourquoi ce projet existe avant de réfléchir à comment le construire.

Ensuite, c'est un fonctionnement simple : un point chaque semaine pour faire le bilan, une démo toutes les deux semaines pour voir ce qui avance concrètement, et un canal direct entre nous (Slack, WhatsApp, email, ce que vous préférez) pour les questions du quotidien. L'objectif est de rester alignés sans que ça devienne une charge administrative pour vous.

La compétence technique est essentielle, évidemment. Mais ce qui fait qu'un projet se passe vraiment bien, dans mon expérience, c'est toujours la qualité des échanges. Comprendre le besoin. Communiquer clairement. Construire ensemble.

Envie d'en discuter ? Réservez un créneau de 15 min. Vous verrez vite si le courant passe.