Comment briefer un développeur freelance pour votre application : le guide en 7 points

Pour chiffrer et construire votre application, un développeur a besoin de savoir trois choses : quel problème vous voulez résoudre, pour qui, et ce qui doit absolument fonctionner dans la première version. Il n'a pas besoin que vous ayez choisi la technologie, dessiné les écrans, ni rédigé un cahier des charges de cinquante pages. Un brief utile tient en une page, et il travaille d'abord pour vous : chaque question laissée sans réponse au départ devient un aller-retour, une hypothèse prudente dans le devis, ou une fonctionnalité à refaire.

Voici les sept points que je cherche dans un brief, dans l'ordre où je les lis ; vous les remplirez en une heure, sans vocabulaire technique. Si vous hésitez encore entre une application mobile et un site web, commencez par ce comparatif : cette décision-là se prend avant le brief.

1. L'objectif : quel problème l'application résout-elle ?

C'est le point le plus important, et le plus vite expédié. « Je veux une application » n'est pas un objectif ; « je veux arrêter de prendre les rendez-vous par téléphone pendant le service » en est un. La différence décide du reste : un même besoin peut parfois se régler par une page bien faite, ou par un meilleur usage d'un outil que vous payez déjà.

Écrivez donc en une phrase ce qui vous coûte aujourd'hui du temps, de l'argent ou des clients, puis ajoutez celle qu'on oublie presque toujours : à quoi saurez-vous que c'est réussi ? Les commandes arrivent sans ressaisie, les techniciens ne rapportent plus de fiches papier, les clients trouvent leur facture sans appeler. Ce critère n'a pas besoin d'être chiffré, mais d'être vérifiable : il tranchera les hésitations pendant le développement.

2. Les utilisateurs : qui s'en sert, et dans quelles conditions ?

Dites-moi qui prend l'application en main, et surtout où. Assis à un bureau sur grand écran, ou debout dans un entrepôt avec une main occupée ? Dans un sous-sol où le réseau ne passe pas ? Avec un téléphone récent, ou avec de vieux appareils ? Ces détails changent la construction : une saisie qui doit fonctionner sans réseau suppose de stocker les données sur l'appareil et de les synchroniser plus tard, un vrai morceau de travail qu'il vaut mieux prévoir que découvrir.

Comptez ensuite les profils : client, employé, administrateur, comptable qui ne voit que les factures. Chacun ajoute des écrans et des droits d'accès à tester. Ce n'est pas une raison pour les supprimer, mais pour les annoncer : un profil prévu au départ coûte moins cher qu'un profil découvert au milieu du projet.

3. Les parcours clés : trois à cinq scénarios du début à la fin

Voici le point qui fait la plus grosse différence sur un devis. La plupart des briefs arrivent sous forme de liste de fonctionnalités : « notifications », « paiement en ligne », « export ». Une liste se chiffre mal, parce que chaque mot peut recouvrir une journée de travail comme deux mois. « Notifications », est-ce un message quand une commande est validée, ou des rappels programmés, personnalisables, avec historique et centre de préférences ? Personne ne peut le deviner, alors on chiffre large, par prudence — et un devis large, c'est vous qui le payez.

Un parcours, lui, se chiffre bien, parce qu'il ne laisse pas de trou. Racontez une histoire du début à la fin. Par exemple, de façon tout à fait hypothétique : un livreur ouvre l'application le matin, retrouve sa tournée, arrive chez un client, photographie le colis déposé, fait signer sur l'écran, valide ; sans réseau, la validation partira plus tard, et le bureau voit la tournée avancer. En trois lignes, on sait qu'il faut une authentification, une liste synchronisée, l'appareil photo, une signature, un mode hors ligne et une vue côté bureau. Rien n'a été listé, et tout est là.

Trois à cinq parcours suffisent pour une première version, avec les cas qui vous embêtent : client absent, paiement refusé, annulation. Ils font une grande part du travail réel et manquent presque toujours aux briefs. Pour voir à quoi ils ressemblent une fois construits, regardez mes projets.

4. Les contenus et les données : d'où viennent-elles, qui les tient à jour ?

Une application manipule des informations qui existent déjà quelque part : un tableur, un logiciel métier, un fichier client, la tête d'une personne dans l'équipe. Dites-moi lequel, et joignez un export réel : même sale, il en dit plus que la meilleure description. Précisez qui met à jour quoi, et à quelle fréquence : un catalogue modifié une fois par an et un stock qui bouge toutes les heures ne donnent pas la même application. Et si vous voulez changer les textes ou les tarifs vous-même, dites-le, car une interface d'administration se prévoit.

Indiquez enfin quelles données personnelles sont en jeu : noms, adresses, photos, données de santé, données de mineurs. Ni vous ni moi n'avons à jouer au juriste, mais le RGPD demande qu'on sache ce qu'on collecte, pourquoi, où c'est hébergé, combien de temps on le garde et comment on le supprime : des choix de conception qui coûtent peu au départ et cher après coup.

5. Les contraintes techniques : ce qui est imposé, ce qui est ouvert

Listez ce qui existe déjà et qu'il faudra connecter : votre site, un logiciel de caisse, un outil de comptabilité, une messagerie, un agenda. Pour chacun, une question à poser à votre éditeur actuel : existe-t-il une API, ou au moins un export automatisable ? La réponse change l'estimation : un outil fermé impose des contournements.

Ajoutez les obligations : hébergement en France ou dans l'Union européenne, charte graphique, exigences d'accessibilité, contraintes de votre secteur. Puis séparez deux colonnes : ce qui est réellement imposé, et ce qui est une habitude — beaucoup de contraintes réputées non négociables sont en fait des préférences héritées.

Ce que vous n'avez pas à décider, c'est la technologie : ce choix relève du prestataire, qui en assume les conséquences pendant des années. Si le sujet vous intéresse, j'explique dans cet article comment je le tranche entre deux options courantes — mais c'est ma cuisine, pas votre travail.

6. Le budget et le délai : deux informations qui vous font gagner du temps

Annoncer une fourchette de budget n'est pas signer un chèque en blanc : c'est permettre qu'on vous propose la bonne solution au lieu de la deviner. Le même besoin se traite presque toujours à plusieurs niveaux d'ambition — une version minimale qui règle le parcours principal, une version complète, une version qui automatise tout.

Le délai fonctionne pareil : « le plus tôt possible » ne dit rien, une date butoir réelle dit tout. Un salon professionnel, une saison qui démarre, une échéance réglementaire : ces dates changent les priorités et méritent d'être annoncées dès le premier échange.

C'est la logique du périmètre ajustable : ce qui bouge, c'est le contenu de la première version, jamais la qualité de ce qui est livré. On peut sortir sans l'export comptable, sans le second profil, sans les statistiques ; on ne sort pas avec un formulaire qui perd les données. Une fonctionnalité repoussée se rattrape, un travail bâclé se paie deux fois.

7. L'après : qui maintient, qui héberge, qui possède ?

Une application n'est pas un livrable qu'on pose sur une étagère : les systèmes d'exploitation évoluent, les magasins d'applications changent leurs règles. Demandez donc, dès le brief, qui corrige les anomalies après la mise en ligne, qui met à jour, qui héberge, et selon quelles modalités. Surtout, réglez la question de la propriété avant de commencer, quand tout le monde est de bonne humeur.

Ce que vous devez posséder	Au nom de qui	Pourquoi c'est vital
Le nom de domaine	Votre entreprise	Sans lui, vous ne contrôlez ni votre site ni vos adresses e-mail
Les comptes développeur Apple et Google	Votre entreprise	L'application publiée reste la vôtre, sans intermédiaire
Le dépôt de code	Votre entreprise	C'est le projet lui-même ; un autre prestataire doit pouvoir reprendre
L'hébergement et les services connectés	Votre entreprise	Vos données et vos factures restent sous votre contrôle

Le prestataire, moi compris, doit être invité sur ces comptes, pas propriétaire. Posez ensuite la question franchement : si nous arrêtons de travailler ensemble, que me remettez-vous, et sous quelle forme ? Une bonne réponse mentionne le code, les accès, une documentation d'installation et un passage de relais. Un prestataire sérieux n'est pas gêné par cette question, il l'attend.

Un modèle de brief en une page

Voici le canevas à copier et à remplir : une ou deux phrases par ligne suffisent. Les blancs comptent aussi, ils disent où nous devrons réfléchir ensemble.

• Le projet en une phrase — ce que l'application permet de faire, et à qui.
• Le problème — ce que cela coûte aujourd'hui en temps, en argent ou en clients.
• Réussite — à quoi nous saurons que c'était une bonne idée.
• Utilisateurs — les profils, et pour chacun : où, quand, sur quel appareil, avec ou sans réseau.
• Parcours 1 à 5 — trois à cinq scénarios racontés du début à la fin, cas d'échec compris.
• Données — ce qui existe déjà, qui les met à jour, à quelle fréquence.
• Données personnelles — lesquelles sont en jeu, et les exigences particulières s'il y en a.
• Existant à connecter — site, caisse, comptabilité, messagerie, agenda, autres outils.
• Imposé / ouvert — les contraintes réelles d'un côté, les préférences de l'autre.
• Budget — une fourchette, même large.
• Délai — la date butoir, ce qui la justifie, et ce qui doit être prêt pour elle.
• Après la mise en ligne — qui maintient, qui héberge, qui possède les comptes et le code.
• Ce que vous ne voulez surtout pas — les mauvaises expériences passées, les outils que votre équipe refuse d'utiliser.

Cette dernière ligne est mon petit secret : elle en apprend souvent plus que toutes les autres réunies.

Pour aller plus loin

Un brief n'est ni un contrat ni un examen, mais un document de travail : il sera discuté, corrigé, parfois retourné. Son mérite est d'avoir posé les bonnes questions avant que la première ligne de code ne les rende coûteuses.

Si vous voulez un regard extérieur sur le vôtre, ou si vous préférez en parler plutôt que de l'écrire, écrivez-moi. Je relis volontiers un brief et je vous dis ce qui manque, même si nous ne travaillons pas ensemble ensuite.