Les fourchettes de prix publiées en ligne ne servent pratiquement à rien hors contexte. Ce qui compte, ce sont les variables qui font bouger le chiffre — et la façon de lire un devis pour comparer réellement la même chose d'un prestataire à l'autre.
Tout article sur le sujet finit par afficher un tableau de fourchettes de prix. Ces fourchettes sont assez larges pour être vraies de presque n'importe quel projet, et c'est précisément pour cela qu'elles ne disent rien du vôtre. Une question plus utile est de savoir quelles variables font réellement bouger le chiffre, car une fois que vous les voyez, vous pouvez à la fois planifier sensément et lire un devis d'un œil critique.
Ce qui pèse vraiment sur le coût
Le nombre de processus distincts
Pas les fonctionnalités — les processus. Un système où cinq rôles suivent chacun un chemin différent à travers les mêmes données représente nettement plus de travail qu'un système où tout le monde fait la même chose avec davantage d'options. Chaque rôle multiplie la logique de permissions, les états d'interface et les tests. Au cadrage, comptez les parcours distincts plutôt que les écrans.
Les intégrations avec des systèmes que vous ne contrôlez pas
C'est le poste le plus systématiquement sous-estimé du métier. Se connecter à un logiciel de comptabilité, à un transporteur ou à un prestataire de paiement n'est presque jamais l'après-midi annoncée. La documentation sera incomplète, le bac à sable se comportera autrement que la production, les limites de débit apparaîtront sous charge réelle, et il faudra gérer l'échec partiel pour qu'un dépassement de délai ne duplique pas une commande. Prévoyez deux à trois fois ce que l'intégration semble exiger.
La reprise de données
Si des données existantes doivent être reprises, c'est leur qualité qui décide du coût. Quinze ans d'enregistrements aux formats incohérents, avec doublons et champs libres là où un code était attendu, prendront plus de temps à migrer proprement que le nouveau système n'en prend à construire. Cela mérite d'être examiné avant que quiconque ne chiffre, pas après.
Le degré de certitude des besoins
Un processus documenté avec des règles convenues se chiffre sans difficulté. « On le saura quand on le verra » n'est pas une estimation, et tout prix ferme qu'on y attache contient une provision importante — que vous payez, qu'elle serve ou non. Réduire l'incertitude avant le chiffrage est le moyen le plus efficace de réduire le coût.
Les exigences de conformité et de réglementation
Traiter des données de santé, des coordonnées de paiement ou des informations financières réglementées ajoute des pistes d'audit, des exigences de chiffrement, des règles de conservation, des contrôles d'accès et fréquemment une évaluation externe. Ce n'est pas une majoration en pourcentage ; c'est du travail supplémentaire avec son propre calendrier.
Pourquoi deux devis pour un même cahier des charges divergent autant
- Ils n'ont pas cadré la même chose. L'un incluait la reprise de données, la formation et trois mois de support après la mise en ligne ; l'autre a chiffré la construction seule. C'est ce qui explique la plupart des grands écarts.
- Modèle de prestation différent. Une équipe délocalisée à faible taux journalier face à une équipe locale à taux plus élevé — la comparaison qui vaut est le coût total, charge de pilotage comprise, et non le taux.
- L'un chiffre ce que vous avez demandé, l'autre ce dont vous avez besoin. Un devis plus élevé traduit parfois un prestataire qui a repéré une exigence que vous n'aviez pas formulée.
- Provision différente. Un prix ferme porte un risque, et le prestataire facture ce risque. Un cahier des charges flou produit une provision plus grosse.
- L'un compte gagner sur le prix et se rattraper sur les avenants. C'est assez répandu pour qu'on y prenne garde : vérifiez ce que le contrat prévoit en cas d'évolution du périmètre.
Les modèles de facturation, et ce que chacun vous fait
| Modèle | Fonctionne bien quand | Le risque que vous portez |
|---|---|---|
| Prix ferme | Le périmètre est réellement bien défini | Le changement coûte cher ; le prestataire peut rogner la qualité pour protéger sa marge |
| Régie | Le périmètre va évoluer et vous pouvez piloter chaque semaine | Les coûts sont ouverts sans pilotage actif |
| Prix ferme par phase | La plupart des projets logiciels d'entreprise | Exige de la discipline pour tenir le périmètre dans une phase |
| Équipe dédiée | Développement continu sur plusieurs trimestres | Vous pilotez de fait l'équipe : il vous faut la capacité de le faire |
Le prix ferme par phase est le dispositif que nous utilisons le plus, parce qu'il vous donne un chiffre sûr pour un travail défini et un véritable point de décision à chaque frontière — y compris la décision d'arrêter. Un prix ferme unique pour tout un programme semble plus sûr et ne l'est généralement pas : il force les deux parties à négocier chaque changement contre un contrat plutôt que contre l'objectif.
Comment nous arrivons à un chiffre
Nous ne publions pas de grille tarifaire, car un chiffre produit avant que quiconque ait lu vos besoins est une supposition déguisée en devis. La séquence que nous suivons est volontairement lente au début :
- Nous recueillons les besoins — ce que le système doit faire, qui l'utilise, avec quels outils existants il doit fonctionner, et ce qui doit être vrai pour que la première version vaille la peine.
- Nous en établissons le périmètre et nous l'écrivons, y compris ce qui est délibérément exclu et ce qui est reporté à une phase ultérieure. Se mettre d'accord sur les exclusions compte autant que sur le travail.
- Nous préparons un devis initial sur ce périmètre écrit, avec les hypothèses qui le sous-tendent énoncées, pour que vous voyiez de quoi le chiffre dépend réellement.
- Nous reprenons ensuite les besoins et le chiffrage avec vous, point par point. C'est là que se produit l'essentiel du mouvement : le périmètre se resserre, une exigence se révèle plus ferme ou plus souple qu'à la première lecture, et le chiffre suit.
- Une fois le périmètre arrêté et plus rien de significatif en suspens, nous confirmons le coût final du projet pour cette phase et le travail démarre sur cette base.
Le coût que l'on oublie
Un logiciel n'est pas un achat immobilisé qui reste ensuite immobile. Budgétez la partie récurrente dès le départ, car elle arrive que vous l'ayez prévue ou non.
- L'hébergement et les services tiers — généralement modestes, mais mensuels et permanents.
- Les correctifs de sécurité et les mises à jour de dépendances. Des dépendances non maintenues deviennent des vulnérabilités, et l'écart se creuse : un framework en retard de deux versions majeures est un projet à lui seul, pas une tâche.
- Les évolutions liées aux changements de l'entreprise. Tout système réellement utilisé génère des demandes d'évolution, et c'est un signe de réussite plutôt qu'un défaut de cadrage.
- Le support des utilisateurs, particulièrement les premiers mois.
- Prévoyez la partie récurrente comme une ligne permanente du budget plutôt que comme une surprise occasionnelle. Son montant dépend de l'intensité d'usage du système et de la vitesse à laquelle l'entreprise autour de lui évolue : mieux vaut en convenir au moment du cadrage de la construction qu'après la mise en ligne.
Comment réduire le coût honnêtement
- Réduisez le périmètre plutôt que la qualité. Un système plus petit construit correctement vaut mieux qu'un grand construit à bas coût — le second devient impossible à maintenir et se remplace plus tôt.
- Construisez d'abord un processus complet et mettez-le en usage réel. Vous découvrirez lesquelles de vos autres exigences n'étaient que des hypothèses.
- Documentez votre processus avant de demander des devis. Les prestataires facturent l'incertitude, et vous la supprimez à moindre coût qu'eux.
- Utilisez des produits existants pour les fonctions banalisées. Paiements, e-mail, authentification et statistiques sont des problèmes résolus ; payer pour les reconstruire se justifie rarement.
- Nettoyez vos données avant la migration, avec vos propres équipes qui les comprennent.
- Soyez honnête sur ce qui est réellement indispensable à la première version. « Phase deux » est une réponse légitime et généralement la bonne.
Et méfiez-vous du devis le plus bas quand il est très en dessous des autres. Cela indique généralement que le prestataire n'a pas compris le cahier des charges, ce qui veut dire que l'écart réapparaîtra plus tard sous forme d'avenants — ou d'un système à reconstruire.
C'est le type de travail que nous faisons. Si cela concerne un projet que vous préparez, notre page logiciel sur mesure explique notre approche, ou bien vous pouvez décrire le projet et nous vous dirons ce que nous en pensons.