Comment définir la portée d'un projet logiciel avant d'embaucher un développeur

La raison n°1 pour laquelle les projets logiciels dépassent le budget :la portée n'a pas été définie avant le début du développement.Pas de mauvais développeurs. Pas une mauvaise technologie. Portée peu claire. Une étude PMI de 2024 a révélé que 52 % des projets subissent une dérive de la portée, et que ces projets dépassent en moyenne de 27 % le budget.

Si vous êtes un fondateur sur le point d'embaucher un développeur de logiciels ou une agence, l'activité la plus rentable que vous puissiez faire est de rédiger une portée claire du projet logiciel avant de parler à qui que ce soit des délais ou des prix. Ce document devient le contrat entre ce que vous attendez et ce qui est construit.

Voici le cadre que nous utilisons chez Savi lors de l'exécution de sessions de cadrage de projet avec les clients. Vous pouvez le faire vous-même en 2 à 4 heures.

Ce qu'un document de portée devrait inclure

La portée d’un bon projet logiciel couvre cinq domaines. Si vous manquez l'un d'entre eux, vous obtiendrez des citations qui ne correspondent pas à la réalité.

1. Rôles des utilisateurs.Qui utilise le système ? Une application orientée client avec un rôle coûte bien moins cher qu'une plateforme avec cinq rôles (client, fournisseur, administrateur, agent de support, super-administrateur). Chaque rôle a besoin de ses propres vues, autorisations et règles d'accès aux données. Énumérez chaque rôle, même ceux que vous jugez évidents. « Admin » n'est pas évident ; cela peut signifier 10 niveaux d'autorisation différents.

2. Fonctionnalités par rôle.Pour chaque rôle d'utilisateur, répertoriez les actions spécifiques qu'ils peuvent effectuer. "L'administrateur peut gérer les utilisateurs" est trop vague. "L'administrateur peut afficher tous les utilisateurs, désactiver des comptes, réinitialiser les mots de passe et exporter les données utilisateur au format CSV" est suffisamment spécifique pour être estimé.

3. Intégrations.Tous les systèmes externes touchés par votre produit : passerelles de paiement, fournisseurs de messagerie, API SMS, outils d'analyse, systèmes CRM, logiciels de comptabilité. Chaque intégration ajoute entre 1 000 et 4 000 $ à un projet en fonction de la qualité et de la complexité de l'API.

4. Esquisse du modèle de données.Vous n'avez pas besoin d'un schéma de base de données. Vous avez besoin d'une description en langage simple de vos objets de données de base et de leurs relations. "Un client a plusieurs commandes. Une commande comporte plusieurs éléments de ligne. Chaque élément de ligne fait référence à un produit. Un produit appartient à une catégorie." Cela prend 20 minutes et évite 20 heures de malentendus à mi-projet.

5. Critères de réussite.Comment savez-vous que le projet est terminé ? Pas "ça semble complet". Des résultats mesurables. "Un client peut créer un compte, parcourir les produits, ajouter des articles au panier, payer avec Stripe et recevoir un e-mail de confirmation de commande dans les 3 secondes suivant le paiement." C'est testable. C'est une limite de portée.

Ce qu'un document de portée ne devrait PAS inclure

Les fondateurs précisent souvent trop dans les mauvais domaines. Un document de portée n'est pas une spécification technique. Laissez-les de côté :

Décisions liées à la pile technique.Ne spécifiez pas « utiliser PostgreSQL avec la mise en cache Redis et déployer sur AWS ». C'est le travail du développeur. Vous définissez ce que fait le système ; ils décident comment il le fait. Si vous dictez des choix technologiques sans contexte d'ingénierie, vous limiterez vos options ou paierez pour une pile qui ne répond pas au problème.

Schémas de base de données.L'esquisse de votre modèle de données décrit les relations en langage simple. Le développeur traduit cela en tables, colonnes et index. Écrire un schéma avant d'embaucher un ingénieur, c'est comme dessiner des plans avant d'embaucher un architecte.

Maquettes d'interface utilisateur au pixel près.Les wireframes et les mises en page approximatives sont utiles. Les fichiers Figma au pixel près avant la portée sont prématurés. Vous repenserez 40 % de vos écrans une fois que vous verrez les flux d'utilisateurs en action. Investissez dans la conception détaillée après avoir défini la portée, pas avant.

Comment définir les rôles et les flux des utilisateurs

Utilisez ce modèle pour chaque fonctionnalité de votre document d'exigences logicielles :

Exemples :

• En tant quecliente, je peux filtrer les produits par catégorie et gamme de prix afin de trouver ce dont j'ai besoin en moins de 10 secondes.
• En tant queadministratrice, je peux exporter toutes les commandes des 30 derniers jours au format CSV afin de pouvoir les réconcilier avec mon logiciel de comptabilité.
• En tant quefournisseuse, je peux définir mes propres prix de produits et inventaires afin de contrôler ma vitrine sans contacter l'assistance.

Ce format force la spécificité. "En tant qu'administrateur, je peux gérer des produits" ne dit rien au développeur. "En tant qu'administrateur, je peux créer, modifier, archiver et supprimer des produits avec des images, des descriptions, des prix et des inventaires" leur indique exactement quoi créer.

Écrivez 10 à 30 de ces déclarations. C'est votre liste de fonctionnalités. C'est ce que vous envoyez aux développeurs lorsque vous demandez des devis.

Comment prioriser les fonctionnalités : la méthode MoSCoW

Vous ne construirez pas tout en même temps. Vous ne devriez pas. La méthode MoSCoW divise votre liste de fonctionnalités en quatre catégories :

Indispensable :Le produit ne fonctionne pas sans ces éléments. Si vous créez une boutique de commerce électronique, le paiement est indispensable. L'authentification des utilisateurs est indispensable. La liste des produits est un incontournable.

Doit avoir :Important mais le produit peut se lancer sans eux. Suivi des commandes, notifications par e-mail, alertes d'inventaire. Ils améliorent l’expérience, mais les clients peuvent toujours acheter des choses sans eux.

Aurait pu :C'est agréable à avoir si le temps et le budget le permettent. Listes de souhaits, critiques de produits, programmes de parrainage. Ces fonctionnalités augmentent l'engagement mais n'affectent pas les fonctionnalités de base.

N'aura pas (ce tour):Fonctionnalités que vous avez décidé de reporter à une phase ultérieure. Application mobile, support multilingue, modèle Marketplace. Il est important de les écrire ; il empêche la dérive de la portée en rendant la limite explicite.

Un MVP bien défini ne contient que les éléments indispensables et 1 à 2 éléments indispensables à fort impact. Tout le reste entre dans la phase 2. Cette approche maintient votre première construction sous le budget et vous permet de commercialiser plus rapidement, afin que vous puissiez recueillir de véritables commentaires des utilisateurs avant d'en construire davantage.

Comment gérer les intégrations

Les intégrations sont la partie la plus souvent sous-estimée de la planification de projets logiciels. Chaque système externe auquel votre produit se connecte ajoute de la complexité, des coûts et des points de défaillance potentiels.

Pour chaque intégration, documentez trois spécificités :

• Quel système :Stripe, SendGrid, Twilio, Google Analytics, QuickBooks, etc.
• Quelles données circulent où :"Les informations de paiement du client sont transmises à Stripe. Stripe renvoie un webhook confirmant le paiement. Notre système met à jour le statut de la commande et déclenche un e-mail de confirmation via SendGrid."
• Que se passe-t-il en cas d'échec :"Si Stripe est en panne, affichez un message d'erreur au client et enregistrez son panier. Réessayez le paiement dans 5 minutes."

La plupart des fondateurs énumèrent les deux premiers et sautent le troisième. La gestion des erreurs représente 20 à 30 % du travail d'intégration. Si vous ne le définissez pas dans le cadrage, le développeur l'ignore (mauvais) ou devine ce que vous voulez (également mauvais).

Définir des critères de réussite

"Le projet est terminé quand il fonctionne" n'est pas un critère de réussite. C'est une recette pour des révisions sans fin. Définir des résultats mesurables avant le début du développement :

• Un nouvel utilisateur peut s'inscrire et finaliser son premier achat en moins de 3 minutes.
• Le tableau de bord d'administration charge toutes les commandes des 90 derniers jours en moins de 2 secondes.
• Le système gère 500 utilisateurs simultanés sans temps de réponse dépassant 1 seconde.
• Toutes les transactions de paiement sont enregistrées avec des horodatages et peuvent être exportées pour audit.
• L'application obtient un score de 90+ sur Google Lighthouse pour ses performances et son accessibilité.

Ces critères donnent à vous et à votre développeur une ligne d'arrivée claire. Lorsque chaque élément de cette liste réussit, le projet est terminé. Pas de débat subjectif sur la question de savoir si un bouton « semble bien ». Des résultats mesurables, pas des sentiments.

Erreurs de cadrage courantes

Après avoir exécuté des centaines de sessions de cadrage de projet, voici les modèles qui conduisent systématiquement à des dépassements de budget :

Écrire un roman au lieu d'une liste de contrôle.Un document d'exigences de 40 pages ne rend pas un projet plus clair. Cela rend l’estimation plus difficile. Les développeurs parcourent de longs documents. Ils lisent des listes de contrôle. Conservez votre document de portée sur 5 pages avec des puces, des témoignages d'utilisateurs et une liste de fonctionnalités prioritaires.

Spécification de l'interface utilisateur avant les flux."Je veux un tableau de bord avec une barre latérale et trois graphiques" décrit un écran et non une fonction. Commencez par les flux d’utilisateurs : que doit accomplir l’administrateur ? Décidez ensuite quelle interface utilisateur prend en charge ces flux. Ce sont les écrans qui viennent des flux, et non l'inverse.

Oublier les besoins d’administration et de backend.Les fondateurs sont obsédés par l’expérience client et oublient que quelqu’un doit la gérer. Gestion de contenu, modération des utilisateurs, exécution des commandes, tableaux de bord analytiques, outils d'assistance. Le panneau d'administration prend souvent 30 à 40 % du temps total de développement. Si votre document de périmètre décrit uniquement l'expérience client, votre devis sera 30 à 40 % trop bas.

Ne pas définir les états d'erreur.Que se passe-t-il en cas d'échec d'un paiement ? Lorsqu'un utilisateur saisit un e-mail invalide ? Lorsque le téléchargement du fichier dépasse 10 Mo ? Quand l'API renvoie une erreur 500 ? Chaque état d'erreur nécessite un comportement défini. Les laisser indéfinis ne permet pas de gagner du temps ; cela crée des bugs qui coûtent plus cher à corriger après le lancement.

Un modèle de cadrage simple

Utilisez cette liste de contrôle comme point de départ lors de la rédaction des exigences logicielles pour votre prochain projet :

Que se passe-t-il après la définition de la portée

Une fois votre document de portée terminé, vous êtes prêt à obtenir des devis. Envoyez le même document à 2 à 4 agences ou développeurs. Un champ d’application clair vous permet de comparer les propositions de manière concrète. Si une agence propose 8 000 $ et une autre 25 000 $ pour la même portée, vous pouvez poser des questions spécifiques sur les raisons.

Voici la séquence typique :

1. Envoyez votre document de portéeaux agences ou aux indépendants présélectionnés. Incluez votre calendrier et votre fourchette de budget si vous en avez un. La transparence accélère le processus.

2. Examinez les propositions.Comparez sur trois dimensions : le prix, le calendrier et qui fait le travail. Un devis de 10 000 $ d'un ingénieur senior expédié en 4 semaines bat un devis de 7 000 $ d'une équipe junior expédié en 12 semaines. Apprenez-en davantage sur l’évaluation des agences dans notre guide surcomment embaucher une agence de développement.

3. Clarifiez les hypothèses.Chaque proposition contient des hypothèses. "Suppose Stripe pour les paiements." "Suppose jusqu'à 3 cycles de révision pour la conception." "Suppose que le client fournisse des photographies de produits." Faites-les apparaître avant de signer. Les hypothèses non formulées deviennent ensuite des controverses.

4. Commencez le développement.Avec une portée claire et une proposition convenue, le développement démarre sur des bases solides. Des changements auront toujours lieu, mais il s’agira de petits ajustements, et non de changements d’orientation fondamentaux qui feront exploser le budget.

Vous voulez comprendre comment la portée du projet affecte les prix ? Lisez notre répartition decoûts de développement de logiciels personnalisés. Si vous êtes prêt à rédiger un document complet sur les exigences du produit, consultez notreGuide des modèles PRD.

Questions fréquemment posées