Rédiger le brief d'une application mobile avant de recruter un développeur au Liban

La plupart des projets d'application qui tournent mal au Liban ne tournent pas mal dans le code. Ils tournent mal lors de la première réunion, quand le client dit « une app comme Talabat, mais pour notre magasin » et que le développeur acquiesce — chacun imaginant quelque chose de complètement différent. Trois mois plus tard, le développeur livre ce que lui avait imaginé, le client est déçu, et la dispute porte sur l'argent.

Le brief sert à éviter cela. Pas un cahier des charges de cinquante pages — personne ne le lit, et une première version n'en a pas besoin — mais deux ou trois pages qui répondent aux questions auxquelles le développeur répondra sinon à votre place, en silence, de la manière la plus simple pour lui.

Ce guide passe en revue ce qu'il faut y mettre, dans l'ordre où un développeur en a besoin, y compris ce qui est propre à une application destinée à des utilisateurs au Liban.

Commencez par l'usage principal

Écrivez une phrase : qui ouvre cette application, et pour accomplir quoi. « Nos clients réguliers recommandent leur livraison habituelle d'eau et de gaz en moins d'une minute. » « Nos techniciens enregistrent chaque intervention avec photos, et le bureau la voit le jour même. » « Les parents voient où se trouve le bus de leur enfant et reçoivent un message à son arrivée. »

Si vous n'arrivez pas à écrire cette phrase, vous n'êtes pas encore prêt à engager un développeur : vous êtes prêt à engager quelqu'un pour réfléchir avec vous, ou à tester l'idée à moindre coût. Beaucoup de premières versions n'ont pas besoin d'être des applications natives ; un site mobile bien construit ou un outil no-code peut démontrer la demande pour une fraction du prix, et notre guide sur le coût d'une app ou d'un site no-code explique quand c'est le choix le plus judicieux.

Ajoutez ensuite une ligne sur la raison d'une application en particulier. Les notifications, l'appareil photo, la géolocalisation, l'usage hors connexion, une icône sur l'écran d'accueil pour un service utilisé chaque semaine : ce sont de vraies raisons. « Tout le monde a une app » n'en est pas une, et le développeur qui l'entend se demandera, à juste titre, à quoi d'autre vous n'avez pas réfléchi.

Qui l'utilise, et avec quels rôles

Listez chaque type de personne qui touche au système. Les clients, évidemment. Mais aussi le personnel qui reçoit les commandes, le livreur qui confirme la livraison, le responsable qui modifie les prix, et vous-même, quand vous voulez voir ce qui s'est passé aujourd'hui.

C'est là que les budgets doublent sans bruit. Chaque rôle a ses propres écrans et permissions, et celui qu'on oublie est l'espace d'administration : l'endroit où quelqu'un ajoute des produits, répond à une réclamation, rembourse une commande ou bloque un compte abusif. Une application sans back-office, c'est une application où chaque modification passe par un appel au développeur. Précisez dans le brief si vous attendez un tableau de bord web pour l'équipe, ce qu'elle doit pouvoir y faire, et de qui il s'agit.

Décrivez les parcours, puis les écrans

Une liste de « fonctionnalités » produit de mauvais devis, parce que « comptes utilisateurs » peut désigner n'importe quoi, d'un numéro de téléphone avec un code jusqu'à un profil complet avec adresses, moyens de paiement et historique.

Écrivez plutôt les parcours, étape par étape, en langage simple :

1. Un nouveau client télécharge l'application, saisit son numéro, reçoit un code et arrive sur la liste des produits.
2. Il choisit deux articles, un créneau de livraison, confirme son adresse et choisit de payer à la livraison.
3. Le magasin reçoit une notification, accepte la commande, et le client voit « acceptée ».
4. Le livreur la marque comme livrée ; le client est invité à la noter.

À partir de tels parcours, un bon développeur ou un designer UI/UX d'applications peut déduire les écrans, et vous voyez tous deux ce qui manque. Joignez des croquis si vous en avez — la photo de rectangles tracés au stylo sur une feuille est réellement utile — et citez deux ou trois applications existantes dont vous aimez une manière précise de faire, en disant laquelle.

Arabe, anglais, ou les deux : décidez maintenant

Si une partie de vos utilisateurs se servira de l'application en arabe, écrivez-le dès la première page du brief, pas en post-scriptum.

Une interface arabe n'est pas une interface anglaise dont on a remplacé le texte. Toute la mise en page s'inverse : navigation, icônes orientées, barres de progression, ordre des champs, gestes de balayage. Le texte arabe exige des polices qui s'affichent correctement en petite taille, et les lignes mixtes — une phrase en arabe contenant un nom de marque en anglais et un numéro de téléphone — demandent du soin pour s'afficher dans le bon ordre. Une application conçue en anglais et « traduite plus tard » doit généralement voir ses écrans refaits, ce qui est la manière la plus coûteuse de procéder.

Indiquez donc les langues au lancement, la langue par défaut, et si l'utilisateur change de langue dans l'application ou si celle-ci suit le réglage du téléphone. Si le français compte pour votre public, dites-le aussi. Et décidez qui rédige les textes de l'interface dans chaque langue : c'est peu de texte, mais c'est ce que les utilisateurs lisent vraiment.

Comment circule l'argent, s'il circule

Le paiement est la partie du brief où la réalité libanaise pèse le plus, et où les suppositions coûtent le plus cher.

Écrivez précisément comment vos clients vous paient aujourd'hui et comment vous aimeriez qu'ils paient dans l'application : en espèces à la livraison, par carte via un prestataire de paiement, par un transfert via un portefeuille électronique qu'ils utilisent déjà, ou aucun paiement dans l'application. Laissez ensuite le développeur confirmer, pour votre activité et votre banque, ce qui est réellement disponible et ce que son intégration implique — la disponibilité dépend de la structure de votre entreprise et de votre prestataire, pas de ce que fait une application dans un autre pays.

Deux points encore ont leur place ici. Si vous comptez vendre du contenu numérique ou des abonnements consommés dans l'application, les stores ont leurs propres règles sur les achats intégrés, et votre développeur doit vous expliquer comment elles s'appliquent avant toute conception. Et si le paiement à la livraison suffit au lancement, dites-le clairement : cela peut retirer un jalon entier de la première version.

Connexions faibles et téléphones anciens

Vos utilisateurs ne sont pas tous sur une fibre rapide avec un téléphone récent. Les données mobiles décrochent, les coupures de courant emportent le Wi-Fi, et beaucoup de gens utilisent des Android de milieu de gamme ou anciens.

Inscrivez-le dans le brief comme des exigences, pas comme des vœux. Qu'est-ce qui doit continuer à fonctionner si la connexion tombe au milieu d'une action — la commande est-elle perdue, ou attend-elle pour partir ? Quels écrans doivent se charger à partir de ce que le téléphone a déjà en mémoire ? Faut-il compresser les photos à l'envoi pour qu'un technicien dans un village puisse les transmettre ? Quel est le plus ancien téléphone que vous voulez prendre en charge ? Ces décisions changent la manière de construire l'application, et elles coûtent bien moins cher avant le développement qu'après les premiers mauvais avis.

Comptes et propriété : à votre nom, dès le premier jour

C'est le paragraphe qui protège tout le reste. Écrivez-le dans le brief comme une condition :

• Le compte Apple Developer Program et le compte Google Play Console sont ouverts au nom de votre entreprise, par vous, et payés par vous. Au moment où nous écrivons, Apple facture 99 dollars par an et Google des frais d'inscription uniques de 25 dollars. Pour un compte d'organisation, Apple demande un numéro D-U-N-S pour votre entreprise, dont l'obtention peut prendre du temps : commencez tôt.
• Le serveur, la base de données et les éventuels comptes cloud sont ouverts à votre nom, le développeur y étant ajouté comme utilisateur.
• Le code source vit dans un dépôt dont vous êtes propriétaire, et le développeur y pousse son travail tout au long du projet, pas seulement à la fin.
• Tous les services payants dont dépend l'application — cartes, messagerie, e-mail, statistiques — sont également à votre nom.

Les développeurs habitués aux clients sérieux s'y attendent et ne discutent pas. Nos articles sur la propriété du travail livré et sur le recrutement d'un développeur d'application mobile expliquent pourquoi une application logée dans le compte de quelqu'un d'autre ne vous appartient pas vraiment.

Ce qui entre dans la version 1, et ce qui attend

Répartissez chaque fonctionnalité en trois colonnes : indispensable au lancement, souhaitable peu après, et plus tard. Soyez impitoyable avec la première. Points de fidélité, codes de parrainage, messagerie, plusieurs agences, mode sombre : toutes sont des idées raisonnables, très peu décident du succès d'une première version.

Cet exercice fait plus pour votre budget que n'importe quelle négociation. Il autorise aussi le développeur à vous dire honnêtement ce que coûte chaque élément, puisqu'il est clair que vous choisissez au lieu de tout exiger.

Budget, calendrier et jalons

Donnez une fourchette de budget. Les clients hésitent de peur de tirer le prix vers le haut, mais un brief sans budget reçoit des devis pour trois applications différentes. Sur Furrsati, un MVP simple multiplateforme, avec un back-end et des fonctionnalités limités, se facture généralement 2 500 à 7 500 dollars le projet, et une interface complète d'environ 10 à 20 écrans ou plus, conçue par un spécialiste UI/UX, généralement 1 500 à 4 000 dollars. Notre analyse du coût d'une application au Liban explique ce qui fait passer un projet d'un bout à l'autre de ces fourchettes.

Indiquez une date dont vous avez réellement besoin, et pourquoi — une saison, un événement, une discussion avec un financeur — pour que le développeur vous dise ce qui est tenable.

Demandez ensuite des jalons qui se terminent chacun par quelque chose que vous pouvez voir et tester sur votre propre téléphone : maquettes validées, puis parcours principal fonctionnel dans une version de test, puis paiement et espace d'administration, puis soumission aux stores. Concevoir d'abord et développer ensuite coûte presque toujours moins cher que de découvrir à la huitième semaine que les écrans sont à repenser. Si vous voulez une courte animation pour la fiche du store ou le lancement, c'est une petite mission distincte pour un motion designer, généralement 80 à 300 dollars pour 15 à 30 secondes, et elle n'a pas à attendre le développeur.

Notre guide pour définir des jalons explique comment les dimensionner.

Un modèle d'une page

Pour démarrer, répondez à ces points sous forme de rubriques : vous aurez un brief sur lequel la plupart des développeurs peuvent chiffrer.

1. L'usage principal : qui l'utilise, pour faire quoi, et pourquoi il faut une application.
2. Les rôles : chaque type d'utilisateur, équipe et administration compris.
3. Les parcours : trois à six parcours étape par étape, en langage simple.
4. Les langues : lesquelles, laquelle par défaut, qui rédige les textes.
5. Le paiement : comment circule l'argent au lancement, puis plus tard.
6. Les conditions : connexion, appareils, ce qui doit fonctionner hors ligne.
7. La propriété : comptes des stores, serveur, code et services à votre nom.
8. La version 1 : indispensable, souhaitable, plus tard.
9. Les références : applications que vous aimez, et ce que vous aimez précisément dans chacune.
10. Budget, date et jalons.

C'est la même discipline que pour un brief de site web, avec davantage d'attention aux rôles, aux appareils et aux comptes.

Engager et payer sans risque

Envoyez le même brief à plusieurs candidats et comparez leur manière de répondre, pas seulement leur prix. Les bons posent des questions sur vos parcours, signalent un oubli et proposent de supprimer une fonctionnalité. Les risqués répondent avec un prix en dix minutes. Demandez à chacun de vous montrer une application qu'il a construite et qui est en ligne sur les stores, et de vous dire ce qu'il développerait en premier.

C'est là que Furrsati retire le risque. Vous publiez votre projet, comparez les propositions de freelances vérifiés, financez un jalon et ne libérez le paiement qu'une fois le travail approuvé, les fonds du jalon étant conservés par Stripe jusqu'à ce que vous les libériez. Les frais de service sont prélevés côté freelance : seuls les frais habituels de traitement de carte s'ajoutent à votre facture, et les jalons financés par le portefeuille n'en supportent aucun. Les freelances vérifient leur identité avant de pouvoir retirer ; en tant que client, aucune vérification ne vous est demandée. Les paiements parviennent au freelance au Liban par OMT, Whish, virement bancaire ou USDT.

Votre prochaine étape

Écrivez aujourd'hui la phrase de l'usage principal et les trois parcours les plus importants, avant de parler à qui que ce soit. Ouvrez cette semaine les comptes développeur Apple et Google au nom de votre entreprise, car la vérification peut être lente. Transformez ensuite le reste du modèle en deux pages et, quand vous êtes prêt, recrutez un développeur d'application mobile sur Furrsati — ou commencez par un designer UI/UX d'applications si vous voulez que les écrans soient arrêtés avant de faire chiffrer le développement.

Foire aux questions

Que doit contenir le brief d'une application mobile ?

L'usage principal de l'application et pour qui, chaque type d'utilisateur y compris l'équipe et l'administration, trois à six parcours étape par étape, les langues au lancement, le mode de paiement, les exigences pour les connexions faibles et les téléphones anciens, la condition que tous les comptes des stores, du serveur et du code soient à votre nom, une liste indispensable/souhaitable/plus tard, des applications de référence, ainsi que votre budget, votre date et vos jalons.

Quelle longueur doit faire un brief d'application ?

Deux ou trois pages suffisent pour une première version. Son rôle est de répondre aux questions auxquelles un développeur répondrait sinon à votre place. Un long cahier des charges rédigé avant d'avoir parlé à qui que ce soit fige souvent les mauvais détails ; un brief court et clair suscite de meilleures questions et des devis comparables.

Faut-il indiquer un budget dans le brief ?

Oui. Sans fourchette, les développeurs chiffrent des applications très différentes et vous ne pouvez pas les comparer. Sur Furrsati, un MVP simple multiplateforme se situe généralement entre 2 500 et 7 500 dollars, et une interface complète de 10 à 20 écrans ou plus entre 1 500 et 4 000 dollars. Une fourchette permet aux développeurs de vous dire honnêtement ce qui y tient.

À qui doivent appartenir les comptes App Store et Google Play ?

À votre entreprise, dès le premier jour. Ouvrez le compte Apple Developer Program (99 dollars par an au moment où nous écrivons) et le compte Google Play Console (25 dollars une seule fois) au nom de votre entreprise, et ajoutez le développeur comme utilisateur. Gardez aussi à votre nom le serveur, le dépôt de code et les services payants.

Faut-il prévoir l'arabe dès le départ ?

Si des utilisateurs se serviront de l'application en arabe, oui. Une interface arabe inverse toute la mise en page de droite à gauche et exige des polices adaptées ainsi qu'une gestion correcte des textes mêlant arabe, anglais et chiffres. Une application conçue uniquement en anglais puis traduite doit généralement voir ses écrans retravaillés, ce qui coûte plus cher que de concevoir les deux dès le départ.

Faut-il engager d'abord un designer ou un développeur ?

Pour la plupart des applications, un designer UI/UX d'abord. Des écrans et des parcours arrêtés donnent aux développeurs une base précise à chiffrer, et une modification coûte bien moins cher dans une maquette que dans le code. Certains développeurs proposent les deux ; dans ce cas, faites des maquettes validées le premier jalon, avant tout développement.