Ce que coûte un logiciel sur mesure, et ce qui détermine vraiment le chiffre

Nous ne publierons pas de grille tarifaire, et vous devriez vous méfier de ceux qui le font. Un chiffre qui n'a pas rencontré vos besoins est un chiffre marketing, et son but est d'amorcer une conversation, pas d'être exact. Ce que nous pouvons faire, c'est expliquer ce qui fait bouger le chiffre, pour que vous sachiez lire les devis reçus et distinguer un devis bon marché d'un devis incomplet.

Pourquoi un même cahier des charges reçoit des devis très différents

Trois raisons, et une seule concerne les tarifs.

Le premier est l'interprétation du périmètre. « Un CRM pour notre équipe commerciale » peut être une liste de prospects avec des rappels, ou un système avec génération de devis, circuit de validation, intégration téléphonique et reporting par territoire. Les deux lectures sont honnêtes. Les devis diffèrent d'un facteur dix.

Le deuxième est ce que le prix inclut. Certains devis couvrent le développement seul. D'autres incluent le cadrage, la migration des données, le fonctionnement en parallèle, la formation, le déploiement, une période de support et les correctifs qui suivent le premier contact avec de vrais utilisateurs. Le second est généralement le plus gros chiffre et presque toujours le plus petit total, parce que le travail exclu doit quand même avoir lieu.

Le troisième est le tarif, et c'est celui qui compte le moins des trois. Une équipe à moitié prix qui met trois fois plus de temps n'est pas moins chère, et un développement à refaire n'est bon marché à aucun tarif.

Les sept facteurs qui pèsent le plus sur le chiffre

1. Le nombre de rôles utilisateurs distinctsChaque rôle est un ensemble distinct d'écrans, de permissions et de tests. Un système à un rôle est une fraction du même système à cinq rôles, même si les données sous-jacentes sont identiques. C'est généralement le plus grand facteur isolé et il est presque toujours sous-estimé dans le cahier des charges.
2. Les intégrations, et qui les contrôleUne intégration avec une API moderne documentée est un travail prévisible. Une intégration avec un système hérité, une base non documentée, un éditeur avec qui il faut prendre rendez-vous, ou un portail sans API du tout, est le travail le moins prévisible du projet. Deux intégrations portant le même nom peuvent différer d'un facteur dix.
3. Migration des donnéesMigrer des données propres depuis un système est une routine. Migrer une décennie de tableurs avec des codes incohérents, des tiers en double et des exceptions dont personne ne se souvient est un chantier archéologique. Le travail est dans les exceptions, et personne ne sait combien il y en a tant que personne n'a regardé.
4. Exigences hors ligne et mobiles« Ça devrait aussi marcher sur téléphone » peut signifier une mise en page adaptative, qui est presque gratuite, ou une application fonctionnant hors ligne avec un modèle de conflit de synchronisation, qui est un projet à part entière. Les deux s'écrivent dans la même phrase et se chiffrent très différemment.
5. Exigences de conformité et d'auditLes déclarations réglementaires, les pistes d'audit, la localisation des données, les règles de conservation et la journalisation des accès sont de l'ingénierie réelle, pas de la paperasse. Elles contraignent aussi l'architecture, ce qui les rend bien plus coûteuses découvertes tard que connues au départ.
6. À quel point les besoins vont changerCe n'est pas un défaut — c'est une propriété. Si le domaine est bien compris et stable, un périmètre fixe est atteignable. Si vous construisez quelque chose de vraiment nouveau, le périmètre bougera, et un contrat à prix fixe sera soit gonflé pour le couvrir, soit source de conflit. Les deux valent moins que d'être honnête à ce sujet dès le départ.
7. Performance et charge, si réellement nécessairesLa plupart des systèmes de gestion ont une charge modeste et ne doivent pas être conçus comme si ce n'était pas le cas. Mais s'il vous faut une vraie concurrence d'accès, de gros volumes de données ou des temps de réponse stricts, c'est de l'architecture, de l'infrastructure et des tests — et cela doit être connu avant la première décision de conception.

Ce qui pèse moins sur le chiffre qu'on ne le croit

Le nombre d'écrans. Les écrans sont la partie visible et donc celle que les cahiers des charges énumèrent, mais une application bien structurée partage entre eux l'essentiel de sa mécanique. Vingt écrans sur un modèle de données propre coûtent bien moins que huit écrans sur quatre systèmes en désaccord.

Le design visuel, dans une certaine mesure. Une interface réfléchie et cohérente bâtie sur un système de design n'est pas la partie coûteuse. Une identité visuelle sur mesure avec illustration et animation propres peut l'être, mais c'est une décision distincte que vous pouvez prendre indépendamment.

Le choix d'une technologie courante. Les débats sur les frameworks changent rarement le total. Ce qui change le total, c'est de savoir si les gens qui le construisent connaissent bien la pile et si celui qui la maintiendra ensuite la connaît aussi.

Comment obtenir une estimation fiable

• Apportez les documents réels, pas une description. Votre vraie grille tarifaire, une facture réelle, un tableur en usage, le rapport que votre responsable réclame chaque lundi. Vingt minutes avec de vrais documents valent mieux qu'une heure à les décrire.
• Nommez les trois choses qui doivent être vraies pour que le projet vaille la peine. Ce sont vos exigences. Tout le reste du cahier des charges est négociable, et savoir ce qui est quoi permet de cadrer un devis au lieu de le gonfler.
• Demandez ce que le devis exclut. La réponse en dit plus que le chiffre. La migration, la formation, le fonctionnement en parallèle et la période de correction après mise en service sont les omissions habituelles.
• Demandez-le par phases, avec quelque chose en production tôt. Un plan par phases fait apparaître les erreurs d'estimation tant qu'elles sont petites — et vous donne l'option d'arrêter.
• Demandez quelle est l'hypothèse la plus risquée. Qui a réellement estimé le travail répond immédiatement. Qui affirme qu'il n'y a aucun risque n'a pas regardé.

Prix fixe, régie, ou plafonné

Le prix fixe convient à un périmètre bien compris et transfère le risque au prestataire, qui le facture. Cela fonctionne, et le coût en est que les changements deviennent des événements contractuels — ce qui rend tout le monde défensif au moment précis où le projet a besoin de souplesse.

La régie convient au travail exploratoire et c'est le modèle honnête quand le périmètre bougera, mais elle exige de la confiance et ne vous donne aucun plafond si vous n'en imposez pas un.

Un modèle plafonné par phase en est généralement le meilleur compromis : un chiffre ferme pour une phase dont le périmètre est réellement compris, réestimé à chaque frontière de phase avec ce qui a été appris. Vous obtenez de la prévisibilité là où elle est possible et de la souplesse là où elle ne l'est pas.

L'erreur coûteuse la moins chère

Choisir sur le seul prix et tout refaire dix-huit mois plus tard. C'est assez fréquent pour être le résultat par défaut des premiers acheteurs. Les signaux sont constants : un devis nettement inférieur aux autres sans explication, aucun cadrage avant le chiffre, aucune question sur vos données, et une date de livraison qui suppose que rien ne sera appris pendant le développement.

Un devis plus bas parce que le prestataire comprend le domaine et a déjà construit quelque chose de similaire est réellement un meilleur prix. Un devis plus bas parce qu'il omet la migration, les tests et le fonctionnement en parallèle est le même prix, payé plus tard, dans un ordre moins favorable.