Comment estimer un projet logiciel : un guide pour les fondateurs non techniques

Demandez à trois équipes de développement d'estimer le coût d'un même projet et vous obtiendrez probablement trois estimations très différentes. L'une est suffisamment basse pour être tentante, une autre se situe dans la moyenne et la dernière semble alarmante. En tant que fondateur sans formation technique, vous vous demandez quelle estimation est la bonne, si l'on peut leur faire confiance et comment établir un budget en fonction de ces estimations. La vérité, aussi frustrante soit-elle, est que l'estimation logicielle est complexe, même pour les experts. Le développement logiciel est une activité créative et basée sur les connaissances, comportant de nombreuses inconnues, et chaque projet est unique. Mais « complexe » ne signifie pas « devinettes ». Il existe des méthodes éprouvées pour produire des estimations fiables, des explications claires quant aux erreurs possibles et des solutions pratiques pour obtenir une estimation sur laquelle vous pouvez vous appuyer pour planifier votre budget. Ce guide les explique en termes simples. Pour des estimations typiques par type de projet, nos guides de coûts fournissent des fourchettes indicatives. Cet article explique comment ces chiffres sont obtenus.

Pourquoi les estimations sont difficiles

Comprendre pourquoi les estimations logicielles sont difficiles vous aide à les interpréter judicieusement.

• Les exigences sont rarement exhaustives. Même des cahiers des charges précis comportent des lacunes, et des détails apparaissent au cours du développement.
• Les inconnues sont cachées. Les intégrations, les particularités des données et les cas limites se révèlent souvent tardivement.
• Rien n'est identique. Contrairement à la construction, chaque projet est différent ; l'expérience passée ne permet donc que de prédire partiellement l'avenir.
• Les individus sont différents. La productivité dépend des individus et de leur capacité à collaborer.
• Le changement est normal. Les utilisateurs donnent leur avis, les marchés évoluent et les priorités changent.
• L'optimisme est humain. On a tendance à imaginer un parcours sans embûches et à sous-estimer le travail qui l'entoure : tests, revues, corrections, déploiement et communication.

Une bonne estimation ne fait pas l'impasse sur ces aspects. Il les reconnaît et les gère.

Estimation, devis et engagement sont différents

Ces trois termes sont souvent utilisés indifféremment, et leur confusion est à l'origine de la plupart des conflits.

• Une estimation est une prévision raisonnée de l'effort et du coût, généralement une fourchette, basée sur les connaissances actuelles.
• Un devis est un prix proposé pour un périmètre défini.
• Un engagement est un accord visant à fournir des résultats spécifiques pour un prix spécifique et à une date spécifique.

Une estimation préliminaire est un outil de planification. Ce n'est pas une promesse. Un prix fixe est possible, mais seulement une fois que le périmètre est suffisamment clairement défini pour établir un prix ferme. Un prix fixe pour des exigences vagues est soit fortement majoré, soit source de litiges ultérieurs.

Comment les professionnels établissent des estimations

Plusieurs méthodes existent, et les bonnes équipes les combinent.

Décomposition du travail

La méthode la plus simple consiste à diviser le projet en petites parties, à estimer chacune d'elles et à additionner les estimations. Il est plus facile d'évaluer des petites parties qu'un produit dans son ensemble. Une ventilation type comprend :

• Découverte et planification
• Conception
• Chaque fonctionnalité ou module
• Intégrations
• Tests et assurance qualité
• Déploiement et transfert
• Gestion de projet et communication

Si une estimation n'inclut pas les derniers éléments, elle est incomplète.

Comparaison avec des projets similaires

Les équipes expérimentées comparent votre projet à ceux qu'elles ont déjà réalisés. « Ce portail ressemble au système de réservation que nous avons livré l'année dernière, avec deux rôles supplémentaires et une intégration de paiement. » Les exemples passés ancrent les estimations dans la réalité, ce qui explique pourquoi l'expérience du secteur est importante ; voir comment choisir une société de développement logiciel.

Utilisation de fourchettes

Les estimations honnêtes sont des fourchettes, telles que « 20 000 $ à 30 000 $ », et non des montants uniques. Une fourchette reflète l'incertitude. Un chiffre précis communiqué dès le départ peut laisser penser à une estimation approximative ou à un prix gonflé.

Les équipes décrivent souvent un scénario optimiste, un scénario probable et un scénario pessimiste, puis travaillent à partir du scénario probable, en prévoyant une marge pour les imprévus.

Intégration d'une marge de sécurité

Comme il existe des inconnues, les estimations responsables incluent une marge de sécurité, généralement de 10 à 25 % selon la précision de la définition du projet. Des exigences plus claires justifient une marge plus réduite. Si une estimation ne prévoit aucune marge de sécurité, le projet risque de dépasser le budget ou de faire l'objet de compromis.

Réestimation au fur et à mesure de l'apprentissage

Les meilleures estimations ne sont pas définitives. Elles sont affinées à chaque étape, gagnant en précision à mesure que l'incertitude diminue. Une phase de découverte, un prototype ou le premier cycle de développement permettent tous de réduire les inconnues et d'améliorer l'estimation suivante.

Le cône d'incertitude

Un modèle mental utile consiste à considérer que les premières estimations sont intrinsèquement larges et qu'elles se resserrent au fur et à mesure que le projet avance. Au stade de l'idée, le coût réel pourrait être deux fois plus élevé ou deux fois supérieur à la première estimation. Une fois les exigences définies, la fourchette de prix se resserre considérablement. Après la réalisation d'un prototype fonctionnel ou plusieurs cycles de développement, elle se resserre encore davantage.

C'est pourquoi un prix fixe dès le départ est risqué pour les deux parties, et pourquoi le travail par étapes, où chaque étape est estimée séparément, est courant pour les produits évolutifs. Nous décrivons cette approche par étapes dans Qu'est-ce qu'un MVP ?.

Quels sont les facteurs déterminants du prix ?

Quelle que soit la méthode utilisée, quelques facteurs clés influencent fortement le résultat. Les connaître vous permet de comprendre les différences entre les devis.

• Périmètre. Nombre et complexité des fonctionnalités.
• Rôles des utilisateurs. Chaque type d'utilisateur nécessite ses propres écrans, autorisations et tests.
• Intégrations. Chaque système externe ajoute du travail et des risques.
• Niveau de conception. Interfaces standard ou conception entièrement personnalisée.
• Plateformes. Web, iOS, Android, ordinateur ou plusieurs.
• Sécurité et conformité. Les données sensibles et les secteurs réglementés requièrent une attention particulière.
• Migration des données. Transfert des enregistrements existants vers un nouveau système.
• Échelle et performances. Nombre d'utilisateurs et volume de données.
• Exigences de qualité. Niveau de test et documentation.
• Expérience de l'équipe. Les équipes expérimentées coûtent plus cher à l'heure, mais souvent moins cher au résultat.

Si deux devis diffèrent considérablement, comparez d'abord ces facteurs. La différence réside généralement dans les hypothèses relatives au périmètre, et non dans les compétences ou le prix. Les articles sur le coût des applications mobiles (blog/mobile-app-development-cost-what-drives-the-price) et le coût des logiciels personnalisés (custom-software-development-cost.php) montrent comment ces facteurs interviennent dans des cas concrets.

Comment aider les développeurs à estimer avec précision

Vous influencez la qualité de l'estimation plus que vous ne le pensez. Plus vous décrivez clairement vos besoins, plus les réponses seront précises et comparables.

Préparation :

1. Le problème et l'objectif. Qu'est-ce qui ne va pas et que faut-il améliorer ?
2. Les utilisateurs. Qui sont-ils et que doivent-ils faire ?
3. Les fonctionnalités indispensables et les fonctionnalités secondaires. Ce dont la première version a besoin et ce qui peut attendre.
4. Des exemples. Captures d'écran, croquis ou produits concurrents illustrant vos propos.
5. Intégrations et systèmes existants. Tout ce à quoi le logiciel doit se connecter.
6. Contraintes. Délai, budget, préférences technologiques et réglementations.
7. Décideurs. Qui approuve quoi et dans quels délais.

Un cahier des charges concis et clair, comme décrit dans Comment rédiger un document de spécifications logicielles, est souvent suffisant. Indiquer une fourchette budgétaire est également utile. Ce n'est pas un piège. Cela permet à une équipe de proposer la meilleure solution en fonction de votre budget, au lieu de vous proposer un prix que vous ne pouvez pas vous permettre.

Comment lire un devis

À la réception d'une proposition, ne vous contentez pas du montant total.

Le périmètre est-il clair ?

La description précise-t-elle ce qui est inclus et ce qui ne l'est pas ? Les descriptions vagues masquent les risques. Recherchez les fonctionnalités, les plateformes, les intégrations, la conception, les tests et le déploiement.

Les hypothèses sont-elles énoncées ?

Une bonne estimation précise ses hypothèses : « Un seul fournisseur de paiement est requis », « Le contenu est fourni par vos soins », « L’API existante est documentée ». Les hypothèses indiquent les points de variation du prix.

S’agit-il d’une fourchette de prix, et la justification est-elle fournie ?

Une fourchette de prix accompagnée d’explications est plus fiable qu’un prix unique sans explication.

Qu’est-ce qui est inclus en plus du développement ?

Vérifiez la présence des tests, de la gestion de projet, du déploiement, de la documentation, de la formation et d’une période de support. Ces éléments sont souvent absents des devis les moins chers.

Comment les modifications sont-elles gérées ?

Il doit exister un processus clair pour l'estimation et l'approbation des modifications.

Quelles sont les modalités de paiement ?

Les paiements liés à la réalisation d'étapes clés vous protègent mieux que des sommes importantes versées d'avance.

Qui réalise le travail ?

L'expérience et la taille de l'équipe influent à la fois sur le coût et la qualité.

Pourquoi le devis le moins cher est rarement le projet le moins cher

Un devis très bas signifie généralement l'une des quatre choses suivantes :

1. Un périmètre plus restreint que les autres, avec des éléments que vous pensiez inclus omis.
2. Des personnes moins expérimentées, qui coûtent moins cher à l'heure et prennent souvent plus de temps.
3. Un travail de moindre qualité, moins de tests, une documentation plus succincte, plus de bogues.
4. Des demandes de modification attendues, avec un prix initial bas et des augmentations ultérieures.

Comparez ce qui est réellement inclus avant de comparer le total. Si un devis représente la moitié des autres, demandez-en la raison par écrit.

Méthodes de maîtrise du budget

Vous ne pouvez pas éliminer l'incertitude, mais vous pouvez la gérer.

Commencez par la phase de découverte

Une courte phase de découverte rémunérée, permettant de définir clairement le périmètre du projet, de créer des maquettes fonctionnelles ou un plan technique, réduit l'incertitude avant le développement principal. Elle vous permet également de tester la collaboration.

Développez par étapes

Découpez le projet en étapes, chacune avec ses propres estimations et livrables. Engagez-vous sur une étape à la fois et ajustez-vous en fonction des enseignements tirés.

Priorisez sans relâche

Établissez une liste claire des éléments « indispensables » pour la première version et une liste des éléments « à réaliser ultérieurement » pour les suivantes. Réduire le périmètre est le moyen le plus efficace de réduire les coûts.

Choisissez un modèle de tarification adapté :

• Périmètre fixe lorsque les exigences sont claires.
• Jalons échelonnés lorsqu'elles sont susceptibles d'évoluer.
• Équipe dédiée pour les projets de longue durée ; voir embaucher une équipe de développement logiciel dédiée.

Organisez des revues régulières

Une démonstration à la fin de chaque cycle permet de constater les progrès et de corriger les malentendus à un coût abordable.

Suivez les modifications de périmètre de manière transparente

Convenez que tout ajout a un coût et un compromis visibles. Ajouter un élément implique d'en supprimer un autre ou d'augmenter le budget. La transparence évite les surprises liées aux dérives de périmètre.

Erreurs d'estimation courantes

1. Considérer une estimation préliminaire comme une promesse. Les premières estimations ne sont que des fourchettes.
2. Comparer les totaux sans comparer le périmètre.
3. Oublier les tâches hors développement, telles que les tests, la conception, la communication et le déploiement.
4. Aucune marge de manœuvre. Il y a toujours des imprévus.
5. Ignorer la maintenance. Le coût de la compilation n'est pas le seul ; voir coûts de maintenance logicielle.
6. Laisser les exigences évoluer sans les examiner.
7. Faire pression sur l'équipe pour obtenir un chiffre inférieur. La charge de travail ne diminue pas ; la qualité, si.
8. Ne pas impliquer les personnes qui réaliseront le travail. Les estimations faites par les commerciaux seuls sont souvent erronées.
9. Décider seul. Impliquez les utilisateurs et les parties prenantes dès le début pour que les exigences soient correctes.

Questions à se poser concernant toute estimation

• Qu'est-ce qui est exactement inclus et exclu ?
• Sur quelles hypothèses est-elle basée ?
• Quels sont les principaux risques et comment affectent-ils le prix ?
• Quel montant de contingence est prévu ?
• Comment saurons-nous si nous dépassons le budget ?
• Comment les modifications sont-elles estimées et approuvées ?
• Que se passe-t-il après le lancement et quel est le coût ?
• Qui réalisera le travail et à quel niveau d'expérience ?
• Que pourrions-nous supprimer pour réduire les coûts ?

Une approche de planification simple pour les fondateurs

Si vous avez besoin d'un chiffre pour planifier, cette approche fonctionne pour la plupart des projets.

1. Rédigez un document d'une page couvrant les objectifs, les utilisateurs, les éléments indispensables et les contraintes.
2. Demandez à deux ou trois équipes des fourchettes de prix, avec leurs hypothèses.
3. Comparez d'abord la portée, puis le prix.
4. Choisissez l'équipe en laquelle vous avez le plus confiance, et non pas simplement celle dont le prix est le plus bas.
5. Commencez par une phase exploratoire ou une première étape, afin que votre estimation réelle s'affine au fur et à mesure que les données sont recueillies.
6. Prévoyez une marge de sécurité d'au moins 15 à 20 % au-dessus du montant probable.
7. Planifiez les coûts de fonctionnement dès le premier jour.

Conclusion

Une estimation est comme une carte dessinée avant le départ. Elle ne sera pas parfaite, mais une estimation réfléchie vous mènera à destination et vous indiquera les points de passage où le trajet pourrait changer. Les équipes les plus compétentes ne sont pas celles qui promettent un chiffre exact d'emblée, mais celles qui posent les bonnes questions, expliquent leurs hypothèses et vous aident à définir le périmètre du projet en fonction de votre budget.

Si vous souhaitez une estimation réalisée de cette manière, décrivez-nous votre projet. Nous commencerons par vous poser les bonnes questions, puis nous vous fournirons une fourchette de prix avec ses hypothèses détaillées et nous vous indiquerons les options qui pourraient l'augmenter ou la diminuer.