Travailler avec un développeur : comment faire pour que le projet se passe au mieux ?

Travailler avec un développeur : comment faire pour que le projet se passe au mieux ?

Faire appel à un développeur pour créer un site internet, une application métier, un logiciel ou automatiser certains processus peut représenter un investissement important pour une entreprise.

On pense souvent que le projet va fonctionner de manière assez simple :

Vous expliquez votre besoin → le développeur code → le logiciel est livré.

Dans la réalité, c'est rarement aussi linéaire.

Un projet informatique implique de nombreux échanges, des décisions, des validations, des données à préparer et parfois beaucoup de questions auxquelles le client ne s'attendait pas forcément.

Je le sais d'autant mieux que mes premières expériences en tant que développeur indépendant m'ont confronté à plusieurs situations de ce type.

Certaines m'ont fait perdre du temps.

Certaines ont créé de la frustration.

Et surtout, elles m'ont appris à mieux cadrer mes projets et à mieux accompagner mes clients.

Cet article n'a donc pas pour objectif de vous expliquer comment devenir chef de projet informatique en une après-midi.

L'objectif est plus simple : vous aider à comprendre comment fonctionne une collaboration avec un développeur et ce que vous pouvez faire, en tant que client, pour mettre toutes les chances de votre côté.

Un développeur ne connaît pas votre entreprise aussi bien que vous

Cela paraît évident.

Et pourtant, c'est probablement l'une des principales sources de malentendus dans un projet logiciel.

Vous connaissez votre entreprise depuis plusieurs années.

Vous connaissez vos clients, vos fournisseurs, vos collaborateurs et vos méthodes de travail.

Vous savez pourquoi telle opération est réalisée avant telle autre.

Vous savez qu'une situation particulière nécessite une procédure différente.

Vous savez qu'un client appartenant à telle catégorie doit être traité différemment.

Et certaines choses sont devenues tellement naturelles que vous ne pensez même plus à les expliquer.

Pour vous, elles sont évidentes.

Pour le développeur, elles ne le sont pas.

Le problème du « c'est évident »

Imaginez que vous expliquiez à un développeur :

« Lorsqu'on reçoit une demande, on vérifie les informations, puis on la traite. »

Cela semble parfaitement clair.

Mais le développeur va probablement commencer à poser des questions :

• Quelles informations faut-il vérifier ?
• Qui réalise cette vérification ?
• Que se passe-t-il si une information manque ?
• Que signifie exactement « traiter » ?
• Existe-t-il plusieurs types de demandes ?
• Y a-t-il des exceptions ?
• Qui valide le traitement ?
• Peut-on modifier une demande après validation ?
• Que se passe-t-il en cas d'erreur ?
• Quelles informations doivent être conservées ?

Ce n'est pas que le développeur ne comprend pas.

C'est justement parce qu'il essaie de comprendre.

Pour automatiser un processus, il faut être capable de décrire suffisamment précisément son fonctionnement.

Et c'est souvent là que la complexité réelle apparaît.

Mon expérience : quand le métier était beaucoup plus complexe que prévu

J'ai rencontré cette situation avec l'un de mes premiers clients.

Son activité était assez spécifique, avec des processus et des règles de fonctionnement propres à son entreprise.

Nous avions échangé sur le projet.

J'avais compris l'objectif général.

Je savais ce que la future solution devait permettre de faire.

J'ai donc commencé le développement.

Mais au fur et à mesure que j'avançais, de nouvelles questions apparaissaient.

Certaines règles métier n'avaient jamais été évoquées.

Certaines situations particulières nécessitaient un traitement spécifique.

Et certaines choses que le client considérait comme parfaitement normales n'avaient simplement jamais été formulées.

Le problème était que le client avait déjà une entreprise à gérer.

Il n'avait pas énormément de temps disponible et pensait probablement que les informations fournies au début du projet étaient suffisantes.

De mon côté, je me retrouvais régulièrement avec de nouvelles questions auxquelles il fallait répondre avant de pouvoir continuer correctement.

Le projet a donc pris du retard.

Pas nécessairement parce que le développement était techniquement difficile.

Mais parce qu'une partie du travail consistait encore à comprendre précisément ce qu'il fallait développer.

Avec le recul, je vois également ma part de responsabilité.

J'aurais pu mieux identifier les zones floues dès le début, poser davantage de questions et organiser des échanges plus réguliers.

C'est justement ce que j'ai progressivement appris à améliorer dans ma manière de travailler.

La gestion des exigences peut coûter très cher

Cette problématique n'est d'ailleurs pas spécifique aux freelances ou aux petites entreprises.

Elle est largement documentée dans le monde de la gestion de projet informatique.

Selon le Project Management Institute (PMI), 47 % des projets qui n'atteignent pas leurs objectifs sont associés à une mauvaise gestion des exigences.

Le même organisme estime également que 5,1 % des dépenses des projets sont gaspillées en raison d'une mauvaise gestion des exigences.

Autrement dit, mal comprendre ce qui doit réellement être construit n'est pas simplement un petit problème organisationnel.

Cela peut représenter une perte financière importante lorsque les projets deviennent suffisamment conséquents.

Et cela paraît assez logique.

Si une équipe développe pendant plusieurs semaines une fonctionnalité qui ne correspond finalement pas au besoin réel, il faudra potentiellement :

corriger → redévelopper → tester → déployer → former les utilisateurs.

Tout cela représente du temps.

Et le temps d'un projet informatique représente de l'argent.

Le développement logiciel n'est pas uniquement du code

C'est une autre idée importante à comprendre.

Lorsqu'un développeur annonce qu'il va travailler sur une fonctionnalité, cela ne signifie pas nécessairement qu'il va passer toute la journée à écrire du code.

Il doit parfois :

• comprendre le besoin ;
• analyser le fonctionnement actuel ;
• poser des questions ;
• étudier les données disponibles ;
• concevoir la solution ;
• réfléchir aux cas particuliers ;
• développer ;
• tester ;
• corriger ;
• présenter le résultat ;
• recueillir les retours ;
• modifier la solution.

Le développement logiciel est donc largement un travail de compréhension et de traduction.

Le client connaît le problème métier.

Le développeur doit transformer ce problème en comportement logiciel.

Et cette traduction nécessite des échanges.

Un deuxième exemple : le site e-commerce qui était techniquement prêt

J'ai également vécu une situation différente avec un projet e-commerce.

Le client était très impatient de voir son site en ligne.

Le développement avançait correctement.

La plateforme était prête.

Le site a donc finalement été déployé.

Mais il restait un problème assez important :

le catalogue n'était pas prêt.

Techniquement, j'avais pourtant prévu une solution permettant d'importer les produits à partir d'un fichier CSV.

Le problème venait des données elles-mêmes.

Avant le projet, le client publiait principalement ses produits sur Facebook Marketplace.

Il disposait également d'un fichier Excel, mais celui-ci n'était pas vraiment structuré pour alimenter un site e-commerce :

• les catégories n'étaient pas définies ;
• certaines informations étaient incomplètes ;
• les données n'étaient pas toujours homogènes ;
• les produits n'étaient pas forcément présentés selon une structure adaptée au nouveau système.

Et surtout, nous n'avions jamais clairement défini qui devait préparer le catalogue et effectuer sa mise en ligne.

Dans la tête du client, il était assez logique que le prestataire qui créait le site s'occupe également de mettre les produits en ligne.

De mon côté, j'avais compris ma mission comme la création de la plateforme et la mise en place des outils permettant d'importer le catalogue.

Deux interprétations différentes.

Aucune mauvaise intention.

Mais une zone grise dans le projet.

Et cette zone grise a finalement fait perdre du temps.

Un site terminé n'est pas forcément un projet terminé

C'est une distinction particulièrement importante pour les projets web.

Prenons un site e-commerce.

Le développement peut être terminé, mais il faut encore avoir :

• les produits ;
• les catégories ;
• les descriptions ;
• les images ;
• les prix ;
• les stocks ;
• les variantes éventuelles ;
• les moyens de paiement ;
• les règles de livraison ;
• les informations légales ;
• les contenus marketing.

La technologie peut permettre d'importer 500 produits en quelques minutes.

Elle ne peut pas inventer les 500 produits.

Et surtout, elle ne peut pas forcément deviner que :

« casque », « Casques » et « équipement moto »

doivent finalement correspondre à une seule catégorie.

L'import de données est donc très pratique.

Mais l'import n'est pas la préparation des données.

Cette distinction est importante lorsqu'on planifie un projet.

Les données font partie du projet

C'est un point que je conseille de clarifier très tôt.

Avant de commencer un projet qui implique des données existantes, il faut se demander :

Quelles données vont alimenter la nouvelle solution ?

Puis :

Dans quel état sont-elles aujourd'hui ?

Un fichier Excel de 2 000 lignes peut sembler impressionnant.

Mais s'il contient des informations incomplètes, des formats différents, des doublons ou des catégories incohérentes, il faudra probablement prévoir une phase de nettoyage et de préparation.

La technologie peut accélérer énormément le traitement.

Mais elle ne supprime pas le travail métier nécessaire pour déterminer ce que les données doivent réellement contenir.

La qualité des données en entrée conditionne directement la qualité de la solution en sortie.

Ce que j'ai changé dans ma manière de travailler

Ces expériences m'ont également appris quelque chose d'important :

la responsabilité ne repose pas uniquement sur le client.

Si un client oublie de préciser une règle métier, je ne peux pas lui reprocher de ne pas avoir pensé comme un développeur.

C'est également mon travail de poser les bonnes questions.

J'ai donc progressivement mis en place une approche plus structurée.

1. Comprendre le fonctionnement actuel avant de proposer une solution

Avant de réfléchir à l'outil, il faut comprendre le fonctionnement actuel.

Comment travaillez-vous aujourd'hui ?

Quels outils utilisez-vous ?

Quelles étapes sont manuelles ?

Qu'est-ce qui vous fait perdre du temps ?

Quelles informations circulent entre les personnes ?

Où apparaissent les erreurs ?

Quelles tâches sont répétitives ?

Cette analyse permet souvent de découvrir que le problème initial n'est pas forcément celui que l'on pensait.

2. Identifier les personnes qui connaissent réellement le métier

Le dirigeant connaît très bien son entreprise.

Mais il n'est pas toujours la personne qui connaît le mieux chaque processus.

Un collaborateur qui réalise quotidiennement une opération peut avoir énormément d'informations utiles :

• les exceptions ;
• les raccourcis ;
• les problèmes rencontrés ;
• les informations manquantes ;
• les étapes qui ne figurent dans aucun document.

Pour un projet métier, ces personnes peuvent être essentielles.

3. Découper le projet en petites étapes

J'évite autant que possible de partir sur :

« On se revoit dans deux mois quand tout sera terminé. »

Il est beaucoup plus efficace de travailler par étapes.

Par exemple :

Étape 1 : définir le fonctionnement.

Étape 2 : concevoir une première partie.

Étape 3 : développer.

Étape 4 : présenter le résultat.

Étape 5 : recueillir les retours.

Étape 6 : ajuster.

Puis on recommence.

Cette approche permet de détecter beaucoup plus tôt les incompréhensions.

Elle correspond également à l'un des principes fondamentaux des approches agiles : inspecter régulièrement le résultat et adapter la suite du travail.

Pourquoi les retours réguliers sont si importants

Imaginez deux projets.

Projet A

Le développeur travaille pendant six semaines.

À la fin, il présente le résultat.

Le client répond :

« C'est bien, mais nous ne faisons finalement pas comme ça. »

Il faut reprendre une partie du travail.

Projet B

Le développeur montre progressivement le résultat toutes les une à deux semaines.

Après la deuxième semaine :

« Cette partie fonctionne, mais chez nous cette étape doit être différente. »

Le développeur corrige immédiatement.

Le deuxième scénario est généralement beaucoup moins coûteux.

Les retours réguliers permettent donc de déplacer les problèmes vers le début du projet, là où ils sont généralement moins coûteux à corriger.

Ce que j'aimerais que les clients sachent avant de travailler avec un développeur

Si vous envisagez de faire appel à un développeur indépendant, voici quelques conseils simples.

Vous êtes l'expert de votre métier

Ne partez pas du principe que le développeur connaît déjà vos processus.

Expliquez-les.

Même les choses qui vous semblent évidentes.

Surtout celles-là.

Les questions sont normales

Lorsqu'un développeur demande :

« Et si cette situation arrive ? »

ce n'est généralement pas parce qu'il ne comprend rien.

Il essaie de déterminer ce que le logiciel doit faire.

Une bonne question posée au bon moment peut éviter plusieurs heures de développement inutile.

Préparez vos contenus

Pour un site vitrine, cela peut être :

• votre logo ;
• vos textes ;
• vos photos ;
• vos coordonnées ;
• vos services ;
• vos informations légales.

Pour un e-commerce :

• vos produits ;
• vos catégories ;
• vos prix ;
• vos images ;
• vos descriptions ;
• vos stocks ;
• vos règles de livraison.

Plus ces éléments sont disponibles tôt, plus le projet peut avancer rapidement.

Prévoyez du temps pour le projet

Faire appel à un développeur ne signifie pas que vous pouvez complètement sortir du projet.

Vous devrez probablement :

• répondre à des questions ;
• prendre des décisions ;
• valider des propositions ;
• fournir des informations ;
• tester ;
• faire des retours.

Ce temps doit être considéré comme une véritable composante du projet.

Définissez clairement ce qui est inclus

C'est probablement l'une des meilleures façons d'éviter les mauvaises surprises.

Demandez-vous :

• Qui fournit les contenus ?
• Qui prépare les données ?
• Qui saisit les produits ?
• Qui réalise les tests ?
• Qui valide les fonctionnalités ?
• Qui s'occupe des comptes et abonnements nécessaires ?
• Qui assure la mise en ligne ?
• Qui forme les utilisateurs ?
• Que se passe-t-il après la livraison ?

Plus ces éléments sont clairs, moins il y a de place pour les interprétations.

Mais faut-il tout savoir avant de commencer ?

Non.

C'est également un piège.

On pourrait penser qu'un bon projet nécessite un cahier des charges de 200 pages qui décrit absolument tout avant d'écrire la moindre ligne de code.

Ce n'est pas nécessairement le cas.

Certains projets sont suffisamment complexes pour que l'on découvre de nouvelles choses en cours de route.

Les utilisateurs peuvent avoir des besoins auxquels personne n'avait pensé.

Certaines hypothèses peuvent être incorrectes.

Une fonctionnalité peut se révéler inutile.

Une autre peut devenir prioritaire.

C'est normal.

L'objectif n'est donc pas forcément de tout connaître avant de commencer.

L'objectif est de réduire progressivement l'incertitude.

C'est pour cette raison que les échanges réguliers, les prototypes, les démonstrations et les validations intermédiaires sont aussi importants.

Le développeur doit aussi apprendre à mieux communiquer

Cette réflexion m'a également fait évoluer dans ma propre manière de travailler.

Je ne peux pas simplement attendre que le client me donne toutes les informations.

Je dois aller les chercher.

Au lieu de demander uniquement :

« Qu'est-ce que vous voulez ? »

il est souvent plus intéressant de demander :

« Comment faites-vous aujourd'hui ? »

« Pourquoi faites-vous cette étape ? »

« Qui s'en occupe ? »

« Que se passe-t-il avant ? »

« Que se passe-t-il après ? »

« Qu'est-ce qui arrive dans les cas particuliers ? »

« Qu'est-ce qui vous fait perdre le plus de temps ? »

« Qu'est-ce qui vous pose le plus de problèmes aujourd'hui ? »

« Comment saurez-vous que la nouvelle solution est réellement meilleure ? »

C'est à ce moment que le développeur ne se contente plus d'être un exécutant.

Il devient progressivement un interlocuteur capable d'analyser le besoin.

Client et développeur doivent construire un langage commun

Le client parle métier.

Le développeur parle technique.

Et aucun des deux ne devrait attendre de l'autre qu'il maîtrise parfaitement son vocabulaire.

Le client n'a pas besoin de savoir ce qu'est une API REST, une architecture hexagonale ou un système de cache.

Le développeur, lui, doit pouvoir comprendre ce que signifie réellement une « commande », un « dossier », une « validation » ou un « client » dans l'entreprise concernée.

Le véritable objectif est donc de construire un langage commun.

Le client explique le problème et le fonctionnement métier.

Le développeur traduit ces informations en solution technique.

Les deux vérifient régulièrement que cette traduction correspond bien à la réalité.

Un projet informatique est une collaboration

Au final, un projet informatique ressemble beaucoup moins à une commande de restaurant qu'on pourrait l'imaginer.

Vous ne dites pas simplement :

« Je voudrais un site e-commerce. »

Puis quelques semaines plus tard :

« Merci, voici votre site. »

Entre les deux, il faut comprendre le problème, définir les objectifs, analyser le fonctionnement actuel, structurer les données, prendre des décisions, développer, tester, recueillir des retours et préparer le lancement.

La réussite d'un projet dépend donc de plusieurs éléments :

un besoin compris, des responsabilités claires, des échanges réguliers, des données préparées, des validations fréquentes et une vision partagée du résultat attendu.

Et cette collaboration commence bien avant la première ligne de code.

Ce que mes premiers clients m'ont appris

Mes premières expériences en tant que développeur indépendant m'ont surtout appris que mon métier ne consiste pas simplement à écrire du code.

Je dois aussi savoir écouter.

Questionner.

Reformuler.

Identifier les zones floues.

Anticiper les blocages.

Structurer les échanges.

Faire valider régulièrement.

Et surtout, expliquer clairement au client ce dont j'ai besoin pour pouvoir faire correctement mon travail.

De leur côté, les clients doivent comprendre qu'un développeur ne peut pas deviner les règles propres à leur entreprise.

Même avec Internet.

Même avec l'intelligence artificielle.

Même avec quinze onglets ouverts et une quantité inquiétante de café.

Certaines connaissances ne sont tout simplement disponibles que dans l'entreprise elle-même.

Et plus un projet cherche à automatiser ou digitaliser le fonctionnement interne d'une entreprise, plus cette connaissance métier devient importante.

Finalement, le meilleur projet n'est pas celui où le client donne toutes les réponses au développeur

C'est celui où le client et le développeur construisent progressivement les bonnes réponses ensemble.

Un bon projet ne repose donc pas uniquement sur un bon développeur.

Il repose sur une collaboration efficace entre les personnes qui connaissent le métier et celles qui vont transformer ce métier en solution numérique.

Et parfois, la meilleure chose qu'un développeur puisse faire avant d'écrire du code est simplement de poser une bonne question.

FAQ

Dois-je avoir un cahier des charges complet avant de contacter un développeur ?

Non. Un cahier des charges peut être très utile, mais vous n'avez pas besoin de connaître la solution technique ni de rédiger un document de plusieurs dizaines de pages. Une description claire de votre problème, de votre fonctionnement actuel, de vos objectifs et de vos contraintes constitue déjà une excellente base pour commencer.

Combien de temps dois-je prévoir pour échanger avec le développeur ?

Cela dépend fortement du projet. Plus le logiciel touche directement à votre activité, plus les échanges seront importants. Prévoyez au minimum du temps pour les réunions de cadrage, les validations, les réponses aux questions et les tests. Ces échanges font partie du projet et permettent généralement d'éviter des erreurs coûteuses.

Le développeur doit-il s'occuper de saisir mes produits ou mes données ?

Pas nécessairement. Cela dépend de ce qui est prévu dans la prestation. La préparation, le nettoyage, la saisie et l'import des données sont des tâches différentes. Il est donc important de définir clairement avant le projet qui est responsable de chacune de ces étapes.

Pourquoi un développeur pose-t-il autant de questions ?

Parce qu'un logiciel doit fonctionner également dans les situations qui ne sont pas évidentes. Le développeur cherche notamment à comprendre les règles métier, les exceptions, les données nécessaires et les différents cas possibles. Plus les réponses sont précises, plus la solution pourra correspondre à votre fonctionnement réel.

Est-ce grave si mes besoins évoluent pendant le projet ?

Non, c'est assez courant. En revanche, une modification importante peut avoir un impact sur le délai, le budget ou les fonctionnalités prévues. Le plus important est de signaler rapidement ces changements afin qu'ils puissent être évalués et intégrés correctement au projet.

Comment éviter les malentendus avec un développeur ?

Le plus efficace est de définir clairement les responsabilités de chacun, de prévoir des échanges réguliers et de faire valider progressivement les différentes parties du projet. Il est également utile de demander explicitement ce qui est inclus dans la prestation et ce qui ne l'est pas.

Que dois-je préparer avant de lancer un projet informatique ?

Commencez par rassembler les informations sur votre fonctionnement actuel, vos objectifs, vos données existantes, vos contenus, vos contraintes et les personnes qui devront participer au projet. Vous n'avez pas besoin de connaître la solution technique : c'est justement le rôle du développeur de vous aider à la définir.

Vous avez un projet de site, de logiciel ou de digitalisation et vous souhaitez savoir par où commencer ? Contactez-moi, nous pourrons échanger sur votre besoin et identifier ensemble la solution la plus adaptée.