Trois développeurs qui chiffrent le même cahier des charges à 40,000, 90,000 et 250,000 ne sont généralement pas en désaccord sur leurs tarifs. Ils chiffrent trois produits différents, parce que le cahier des charges permettait trois interprétations.
Pourquoi un tel écart
Un cahier des charges qui indique que « les utilisateurs peuvent importer des documents » laisse toutes les décisions coûteuses en suspens. Quelle taille maximale ? Quels formats ? Un antivirus est-il prévu ? Prévisualisation dans le navigateur ou téléchargement uniquement ? Gestion des versions ? Qui peut voir les fichiers des autres utilisateurs ? Quelle durée de conservation et quelles modalités de suppression ?
Un développeur qui chiffre prudemment part de l’interprétation simple. Celui qui chiffre de manière défensive part de l’interprétation complexe et l’intègre dans son prix. Tous deux agissent de manière raisonnable. L’acheteur conclut que le devis le plus élevé est excessif, choisit le moins cher et découvre l’écart pendant le développement — à ce moment-là, il devient une demande de modification.
Les cinq éléments à définir précisément
- Les rôles des utilisateurs et les actions autorisées pour chacun. Il ne suffit pas de parler d’« administrateur et utilisateur » : il faut établir la liste des actions par rôle. La logique des autorisations représente une part importante du travail dans la plupart des applications métier, et elle est invisible dans une liste de fonctionnalités.
- Les principaux processus, étape par étape. Décrivez la séquence que suit réellement un utilisateur, y compris ce qui se passe lorsqu’un problème survient — paiement refusé, session expirée ou soumission en double.
- Les données. Ce qui est stocké, ce qui est obligatoire, les règles de validation applicables et la durée de conservation. Une liste de champs est plus utile qu’une description des écrans, car les écrans changent, contrairement aux données.
- Les dépendances externes. Paiement, messagerie, cartes, systèmes existants auxquels se connecter. Chacune implique un délai d’approbation et une gestion des erreurs à prévoir dans le budget.
- Les critères d’acceptation. La manière dont vous déciderez que le produit est terminé. C’est la section la plus souvent omise et celle qui évite le plus de désaccords.
Le volume et les performances, exprimés en chiffres
« Doit être rapide » et « doit prendre en charge beaucoup d’utilisateurs » ne peuvent être ni chiffrés ni testés. Les chiffres, eux, le peuvent :
- Nombre d’utilisateurs attendus la première année et nombre d’utilisateurs simultanés en période de pointe.
- Nombre d’enregistrements attendu dans la table la plus volumineuse après un an.
- Temps de réponse acceptable pour l’opération courante la plus lente.
- Taille des fichiers et capacité totale de stockage.
Ces éléments modifient l’architecture. Une application conçue pour 200 utilisateurs et une autre conçue pour 200,000 utilisateurs diffèrent par la conception de la base de données, la mise en cache et le coût de l’hébergement ; construire la seconde alors que vous avez besoin de la première gaspille de l’argent qui aurait pu être consacré aux fonctionnalités.
Ce qu’un cahier des charges ne devrait pas contenir
Deux éléments rendent les cahiers des charges moins efficaces :
Les choix technologiques, sauf en cas de contrainte réelle. Imposer un framework parce qu’il a été recommandé empêche le développeur de proposer une solution mieux adaptée. S’il existe une véritable contrainte — un système existant ou une équipe interne qui doit assurer la maintenance — indiquez la contrainte plutôt que la conclusion.
Une conception au niveau du pixel dans une spécification fonctionnelle. Il est préférable de séparer la conception et les fonctionnalités. Une spécification qui les mélange rend les deux plus difficiles à examiner et transforme chaque préférence visuelle en modification fonctionnelle.
Les sections qui provoquent des désaccords par la suite
De manière récurrente, dans l’ordre :
- Les rapports. Les « rapports » mentionnés dans un cahier des charges deviennent une semaine de travail par rapport dès que les champs, les filtres, le regroupement et le format d’export sont connus.
- Les notifications. Les e-mails, SMS, notifications push et notifications intégrées à l’application sont quatre implémentations différentes, avec quatre coûts différents. « Le système avertit l’utilisateur » ne précise aucune d’entre elles.
- La recherche. Rechercher dans un seul champ est trivial ; rechercher dans des enregistrements liés avec un classement constitue un projet à part entière.
- La migration. Importer les données existantes est presque toujours plus difficile que prévu, car les anciennes données sont incohérentes d’une manière que personne n’a documentée.
Nommer explicitement ces quatre éléments dans le cahier des charges, même brièvement, les fait passer du statut d’hypothèses à celui de périmètre défini.
Une approche pratique
Pour un petit projet, un cahier des charges utile compte généralement cinq à quinze pages : liste des rôles, descriptions des processus, champs de données, liste des intégrations, chiffres non fonctionnels, critères d’acceptation et section explicite des éléments hors périmètre.
Cette dernière section a un impact plus important que ne le laisse penser sa longueur. Écrire que « les rapports autres que ceux des trois écrans listés sont hors périmètre pour cette phase » prend une ligne et élimine toute une catégorie de désaccords ultérieurs.
Services Manboo associés
- Développement d’applications Flutter pour les MVP iOS et Android.
- Développement de logiciels métier pour les CRM, les systèmes de réservation, de gestion des stocks et de processus.
- Développement de panneaux d’administration pour les tableaux de bord opérationnels et la gestion du back-end.
- Intégration d’API d’IA lorsque votre produit est prêt pour la recherche intelligente, le chat ou l’automatisation.
- Demander un examen du périmètre et une estimation du projet lorsque vous êtes prêt à planifier la première version.