Comment rédiger une demande de développement qui avance vite
Une demande de développement est un besoin exprimé avec assez de contexte pour qu'une équipe le cadre sans vous rappeler : qui a le problème, ce qu'il essaie de faire, ce que ça change, et comment vérifier que c'est fait. Pour les clients d'une équipe en abonnement : quatre éléments, trois exemples, et comment découper.
Pourquoi la façon d'écrire une demande décide de sa vitesse
« Il faudrait qu'on puisse exporter les données. » Neuf mots, et déjà trois questions : quelles données, pour qui, dans quel format ? Le temps que ces questions fassent l'aller-retour, la demande a perdu deux jours sans qu'une ligne de code soit écrite. Dans un modèle où une équipe réalise vos demandes une à la fois, la vitesse ne se joue pas dans le code. Elle se joue dans la demande.
Une demande de développement, c'est un besoin exprimé avec assez de contexte pour qu'une équipe puisse le cadrer sans vous rappeler, et assez de liberté pour qu'elle choisisse la meilleure façon de le réaliser. Ni un cahier des charges, ni un message en une ligne. Voici comment l'écrire, comment la découper, et comment la faire avancer une fois déposée. Les exemples viennent de Figue Unlimited ; les principes valent pour n'importe quelle équipe.
Quels sont les quatre éléments d'une bonne demande ?
Pas de gabarit obligatoire : chez Figue, une demande vocale de quarante secondes peut être meilleure qu'un document de trois pages. Ce qui compte, c'est que quatre informations soient là, dans n'importe quel ordre.
01
Qui a le problème
Un client, un membre de votre équipe, vous. « Les commerciaux » n'est pas un utilisateur ; « Léa, qui prépare les devis chaque matin » en est un. Ce détail change les choix d'écran, de raccourcis et de priorités.
02
Ce qu'il essaie de faire, et ce qui l'en empêche
Le geste, pas la fonctionnalité. « Retrouver les commandes d'un client pour répondre à une réclamation, et aujourd'hui elle ouvre trois onglets » dit plus que « ajouter un filtre ».
03
Ce que ça change si c'est fait
Du temps gagné, une erreur qui disparaît, un client qui ne relance plus, une vente qui se conclut. C'est ce qui permet à l'équipe de proposer parfois une solution plus simple que celle imaginée, et à vous de décider si ça vaut sa place dans la file.
04
Comment vous saurez que c'est fait
Une phrase que vous pourrez vérifier sur la preview. « Léa retrouve les commandes d'un client en tapant son nom, depuis la page d'accueil, sans quitter la page. » Si vous ne savez pas l'écrire, la demande n'est pas encore prête.
03
Trois exemples : avant, après
Les mêmes besoins, écrits deux fois. À gauche, ce qu'on reçoit souvent ; à droite, ce qui part en réalisation sans un seul aller-retour.
La même demande, avant et après
Situation
Avant
Après
Un export
Il faudrait qu'on puisse exporter les données.
Marc, notre comptable, ressaisit chaque mois les factures dans son logiciel. Il lui faut un export des factures du mois, en CSV, avec numéro, client, montant HT et TVA, depuis la page Factures. Il saura que c'est fait quand le fichier s'ouvre dans son outil sans retouche.
Une notification
Ajouter des notifications.
Les clients ne voient pas que leur commande est expédiée et écrivent au support. Envoyer un email au client quand la commande passe en Expédiée, avec le numéro de suivi. C'est fait quand un client test reçoit l'email dans la minute.
Un agent IA
Mettre de l'IA dans le support.
Le support reçoit 40 emails par jour, dont la moitié sont des questions de suivi de commande. Un agent lit chaque email, répond seul aux questions de suivi avec les données de la commande, et transmet le reste à un humain avec un résumé. C'est fait quand une semaine d'emails de test est triée sans erreur de transmission.
Remarquez ce que les versions « après » ne disent pas : ni comment, ni avec quoi. Elles disent qui, quoi, pourquoi, et le test de fin. Tout le reste est du cadrage, et le cadrage est le travail de l'équipe.
04
Comment découper une demande pour qu'elle avance vite ?
Dans une file traitée une demande à la fois, une demande de trois semaines bloque tout le reste pendant trois semaines. La même demande découpée en cinq étapes de trois jours livre quelque chose de vérifiable chaque semaine, et vous laisse réordonner la suite entre deux étapes. Le découpage n'est pas une contrainte du modèle ; c'est son principal levier.
La règle qu'on applique chez Figue : une étape doit être livrable seule, testable seule, et utile seule, même si la suite n'arrive jamais. Un espace client se découpe en « se connecter et voir ses commandes », puis « télécharger ses factures », puis « modifier son adresse ». Pas en « base de données », « API », « écrans ».
Une fois déposée, qu'est-ce qui la fait avancer ou attendre ?
Une demande déposée passe par trois états. Elle attend dans la file, elle est en cours, ou elle attend quelque chose de vous. Ce troisième état est celui qui coûte le plus de temps sans que personne ne s'en rende compte.
Chez Figue, une demande qui attend votre réponse est marquée « En attente de toi » et ne prend pas de slot : l'équipe passe à la suivante. Mais c'est aussi le moment où votre demande n'avance pas. Une question laissée trois jours, c'est trois jours de plus, quelle que soit la vitesse de l'équipe.
“Le délai d'une demande, c'est le temps de réalisation plus le temps que vous mettez à répondre. Le premier dépend de nous. Le second, de vous.”
Trois habitudes qui font la différence : répondre aux questions de cadrage dans la journée, valider les previews dans les quarante-huit heures, et donner les accès (comptes, APIs, données de test) dès le dépôt de la demande plutôt qu'au moment où l'équipe les demande.
06
Déposer depuis votre IA : la demande sans formulaire
Depuis 2026, Figue Studio est connecté aux assistants IA via MCP. Concrètement : vous racontez le besoin à Claude ou ChatGPT comme vous le raconteriez à un collègue, l'assistant le met en forme avec les quatre éléments ci-dessus, et le dépose dans votre file. Vous relisez, vous ajustez, c'est parti.
Ça ne remplace pas le cadrage par l'équipe ; ça le prépare. L'assistant pose les questions qui manquent avant que la demande parte, et vous évite l'aller-retour du lendemain. Il peut aussi lire l'état de votre file, réordonner, et vous dire ce qui attend votre réponse.
Ce que les clients nous demandent la première semaine.
Faut-il un cahier des charges ?
Non. Un cahier des charges décrit une solution ; une demande décrit un besoin et un résultat vérifiable. Le cadrage, qui transforme l'un en l'autre, est le travail de l'équipe. Si vous avez déjà des maquettes ou des contraintes, joignez-les, elles aident ; mais ne bloquez pas une demande parce qu'elles manquent.
Combien de demandes puis-je déposer ?
Autant que vous voulez. La file n'a pas de limite. Ce qui est limité, c'est le nombre de demandes en cours en même temps : une par slot. Déposez tout ce qui vous passe par la tête, puis ordonnez.
Que se passe-t-il si ma demande est trop grosse ?
L'équipe vous propose un découpage en étapes livrables lors du cadrage, et vous choisissez l'ordre. Une grosse demande est d'abord découpée. Si elle relève d'un produit entier, on vous le dit et on propose un devis.
Puis-je déposer un bug comme une demande ?
Oui, et c'est le même format : qui, ce qu'il essayait de faire, ce qui s'est passé à la place, et comment reproduire. Une capture ou une vidéo vaut dix lignes. Un bug bloquant passe en tête de file si vous le décidez.
Et si je ne sais pas ce que je veux ?
Déposez le problème sans la solution : « les clients abandonnent le paiement, je ne sais pas pourquoi ». La première étape sera d'instrumenter et de regarder ; la deuxième découlera de ce qu'on aura vu. C'est une demande comme une autre.
