Ce que vous payez vraiment
Une application web sur mesure n’a pas de prix unitaire. Il n’y a pas de boîte sur une tablette ni de coût de matériaux digne de mention. Ce que vous payez, c’est du temps : les heures des personnes qui la planifient, la conçoivent, la développent, la testent et la mettent en ligne. Toute soumission honnête, ce sont ces heures, réparties entre des rôles, multipliées par le taux de chaque rôle, avec une fourchette autour du total parce qu’un logiciel n’est jamais entièrement connu d’avance.
C’est pourquoi deux soumissions pour ce qui semble être la même application peuvent être très éloignées. Un studio a supposé une page de connexion et un formulaire par courriel; l’autre, une authentification unique, des rôles, un journal d’audit et un tableau de bord pour le personnel. Aucun n’a tort. Ils chiffrent deux applications différentes qui portent le même nom. Le moyen le plus rapide de les comparer est de demander les heures par rôle et la liste des hypothèses derrière.
Ce guide passe en revue les rôles d’une application web typique, ce qui fait augmenter ou diminuer les heures de chacun, et trois exemples chiffrés à partir de notre grille tarifaire à l’ouverture de la page. Nous n’écrivons jamais de prix dans le texte d’un guide, parce que les taux et les prix des fournisseurs changent. Les exemples ci-dessous sont toujours à jour.
Les rôles d’une application web, et ce que fait chacun
Un projet n’a pas besoin de chaque rôle à temps plein, et sur une petite application une même personne peut en couvrir deux. Mais chaque rôle ci-dessous fait un travail qui doit se faire quelque part. Si une soumission en oublie un, demandez qui fera ce travail à sa place.
| Rôle | Ce qu’il fait | Ce qui fait augmenter ses heures |
|---|---|---|
| Chargé de projet | Tient le plan, les étapes, les approbations et les demandes de modification. Votre interlocuteur principal. | Plus de personnes à coordonner, plus d’intervenants de votre côté, plus d’étapes, un travail réglementé avec des registres formels. |
| Architecte logiciel | Choisit la structure, le modèle de données et la façon dont les parties communiquent. Révise les décisions difficiles. | Les intégrations avec d’autres systèmes, le temps réel, une sécurité stricte ou la résidence des données, de nombreux types d’utilisateurs. |
| Designer produit | Transforme le mandat en parcours, en maquettes fonctionnelles et en écrans finis, et les valide auprès de vos utilisateurs. | Le nombre d’écrans, le degré de personnalisation, un système de marque complet, l’accessibilité à un niveau précis. |
| Développeurs frontaux | Construisent ce qui tourne dans le navigateur : écrans, formulaires, état, accessibilité, mise en page adaptative. | Le nombre d’écrans, les interactions complexes, les mises à jour en temps réel, plus d’une langue, le fonctionnement hors ligne. |
| Développeurs dorsaux | Construisent le serveur, la base de données, les règles d’affaires, les intégrations et les outils d’administration. | Les paiements, les rôles et permissions, les intégrations, la recherche, la gestion de fichiers, les rapports. |
| Analyste en assurance qualité | Écrit et exécute les tests, vérifie chaque étape avant que vous la voyiez et suit les défauts. | Les paiements et la manipulation d’argent, les données réglementées, de nombreux navigateurs et appareils, de nombreux rôles. |
| Ingénieur DevOps | Met en place l’hébergement, le déploiement, les sauvegardes, la surveillance et le chemin d’un commit jusqu’à la production. | Une disponibilité plus élevée, plus d’environnements, un fournisseur infonuagique plus complexe, la journalisation exigée par la conformité. |
| Rédacteur technique | Rédige la documentation de transfert : comment l’exploiter, l’administrer, comment elle est construite. | Plus de fonctions d’administration, plus d’intégrations, un transfert à votre propre équipe plutôt qu’à la nôtre. |
Nos estimations montrent aussi une ligne appelée Développement. Elle couvre les fondations : l’ossature du projet, les écrans et formulaires standards, les interfaces entre les parties et les suites de tests. Les rôles seniors nommés la révisent et gardent pour eux les parties critiques, comme le modèle de données, les paiements et la sécurité.
Ce qui fait varier les heures
Sept décisions font bouger l’estimation plus que tout le reste. La plupart vous appartiennent, ce qui veut dire que la plus grande partie du prix est entre vos mains.
- 01
Le nombre d’écrans
Chaque page ou écran demande du design, du développement frontal et des tests. Un écran, ce n’est pas qu’une mise en page : c’est aussi son état vide, son état d’erreur, son état de chargement et son affichage sur un téléphone. Compter honnêtement les écrans est la meilleure chose à faire pour obtenir une soumission juste.
- 02
Les fonctions derrière les écrans
La connexion avec des rôles, les paiements, un volet d’administration, les avis, la recherche et le téléversement de fichiers apportent chacun leurs propres heures de développement dorsal et d’assurance qualité. Les paiements surtout demandent des tests soignés, parce qu’un bogue à cet endroit coûte de l’argent et pas seulement de la patience.
- 03
Les intégrations
Se brancher sur un ERP, un CRM, un logiciel comptable ou l’API d’un partenaire, c’est là que les estimations dérapent le plus souvent, parce que la documentation, l’environnement de test et les bizarreries de l’autre système échappent à tout le monde. Nommez chaque intégration dès le départ.
- 04
Le temps réel et le multilingue
Les mises à jour en direct (un tableau de bord qui bouge, un clavardage, un éditeur partagé) changent la façon de construire le serveur. Offrir l’anglais et le français veut dire que chaque texte, date, nombre et courriel existe deux fois et se teste deux fois.
- 05
Le degré de design
Utiliser votre système de design existant coûte le moins d’heures de design. Une apparence propre et standard coûte un peu plus. Un design sur mesure, et au-dessus un système de marque complet avec illustrations et animations, coûte le plus d’heures de designer, et quelques heures de développement frontal de plus pour le reproduire fidèlement.
- 06
La conformité
Les renseignements personnels apportent un travail de confidentialité : consentement, conservation, demandes d’accès et journalisation soignée. Les données réglementées (santé, finance, gouvernement) ajoutent des registres formels, un contrôle d’accès plus strict et plus de tests, et touchent chaque rôle, pas seulement les développeurs.
- 07
L’urgence
Une échéance serrée veut dire plus de personnes en parallèle, donc plus de coordination. Se presser ne rend jamais un logiciel moins cher; une date souple le rend habituellement un peu moins cher.
Trois applis web, chiffrées selon la grille
Les exemples ci-dessous montrent la fourchette selon notre grille tarifaire d’aujourd’hui, avec les heures par rôle et l’échéancier de paiement. Ils sont chiffrés à l’ouverture de la page : ils ne sont donc jamais périmés. Ouvrez-en un dans l’estimateur pour changer un choix et voir les heures bouger.
Exemple chiffré en direct
Une petite application web : un outil interne
Six écrans, une connexion pour le personnel, un volet d’administration simple et un design standard et propre. Le genre d’outil qui remplace un tableur partagé pour une équipe.
- Développement
- ≈ 23 900 USD à 36 600 USD, livré en 12 semaines au plus34 100 $ CA à 52 100 $ CA
Les prix dans votre devise sont des estimations au taux du jour de la Banque du Canada. Toute la facturation se fait en CAD ou en USD.
Effort estimé par rôle
- Développement
- 139 à 212 h
- Développeur frontal
- 23 à 36 h
- Gestionnaire de projet
- 20 à 31 h
- Développeur dorsal principal
- 19 à 29 h
- Développeur dorsal
- 18 à 28 h
- Concepteur de produits
- 15 à 23 h
- Développeur frontal principal
- 14 à 21 h
- Ingénieur assurance qualité
- 14 à 21 h
- Ingénieur principal
- 10 à 16 h
- Concepteur de produits principal
- 10 à 16 h
- Architecte logiciel
- 10 à 15 h
- Développeur frontal junior
- 9 à 14 h
- Développeur dorsal junior
- 9 à 14 h
- Ingénieur DevOps
- 5 à 7 h
- Rédacteur technique
- 2 à 4 h
Modalités de paiement
- Acompte 30 %
- 10 230 $ CA à 15 630 $ CA
- Découverte 6,6 %
- 2 250,60 $ CA à 3 438,60 $ CA
- Maquettes approuvées 6,6 %
- 2 250,60 $ CA à 3 438,60 $ CA
- Fonctions principales 20 %
- 6 820 $ CA à 10 420 $ CA
- Développement complet 13,3 %
- 4 535,30 $ CA à 6 929,30 $ CA
- Tests et corrections 6,6 %
- 2 250,60 $ CA à 3 438,60 $ CA
- Mise en ligne 6,9 %
- 2 352,90 $ CA à 3 594,90 $ CA
- Retenue, 30 jours après la mise en ligne (10 %)
- 3 410 $ CA à 5 210 $ CA
Exemple chiffré en direct
Une application web moyenne : un portail client avec paiements
Seize écrans, une connexion client, des paiements par carte, des avis par courriel, la recherche, le téléversement de documents et un design sur mesure, avec des renseignements personnels.
- Développement
- ≈ 59 300 USD à 90 700 USD, livré en 17 semaines au plus84 400 $ CA à 129 100 $ CA
Les prix dans votre devise sont des estimations au taux du jour de la Banque du Canada. Toute la facturation se fait en CAD ou en USD.
Effort estimé par rôle
- Développement
- 337 à 516 h
- Concepteur de produits
- 59 à 90 h
- Développeur frontal
- 54 à 82 h
- Développeur dorsal principal
- 47 à 72 h
- Développeur dorsal
- 46 à 70 h
- Concepteur de produits principal
- 39 à 60 h
- Ingénieur assurance qualité
- 39 à 60 h
- Développeur frontal principal
- 32 à 49 h
- Gestionnaire de projet
- 32 à 49 h
- Ingénieur principal
- 25 à 39 h
- Architecte logiciel
- 24 à 37 h
- Développeur dorsal junior
- 23 à 35 h
- Développeur frontal junior
- 22 à 33 h
- Ingénieur DevOps
- 8 à 12 h
- Rédacteur technique
- 7 à 11 h
Modalités de paiement
- Acompte 20 %
- 16 880 $ CA à 25 820 $ CA
- Découverte 7,7 %
- 6 498,80 $ CA à 9 940,70 $ CA
- Maquettes approuvées 7,7 %
- 6 498,80 $ CA à 9 940,70 $ CA
- Fonctions principales 23,3 %
- 19 665,20 $ CA à 30 080,30 $ CA
- Développement complet 15,5 %
- 13 082,00 $ CA à 20 010,50 $ CA
- Tests et corrections 7,7 %
- 6 498,80 $ CA à 9 940,70 $ CA
- Mise en ligne 8,1 %
- 6 836,40 $ CA à 10 457,10 $ CA
- Retenue, 30 jours après la mise en ligne (10 %)
- 8 440 $ CA à 12 910 $ CA
Exemple chiffré en direct
Une grande application web : une plateforme réglementée
Quarante écrans en français et en anglais, un design de marque complet, des intégrations avec d’autres systèmes, des mises à jour en direct, de l’analytique et des données réglementées, sur une infrastructure infonuagique plus grande avec un plan de soutien.
- Développement
- ≈ 140 000 USD à 215 000 USD, livré en 30 semaines au plus199 800 $ CA à 305 600 $ CA
Les prix dans votre devise sont des estimations au taux du jour de la Banque du Canada. Toute la facturation se fait en CAD ou en USD.
Effort estimé par rôle
- Développement
- 718 à 1098 h
- Concepteur de produits
- 223 à 342 h
- Concepteur de produits principal
- 149 à 228 h
- Développeur frontal
- 122 à 187 h
- Développeur dorsal principal
- 92 à 141 h
- Ingénieur assurance qualité
- 88 à 134 h
- Développeur dorsal
- 87 à 133 h
- Développeur frontal principal
- 73 à 112 h
- Gestionnaire de projet
- 59 à 90 h
- Ingénieur principal
- 54 à 82 h
- Développeur frontal junior
- 49 à 75 h
- Architecte logiciel
- 49 à 75 h
- Développeur dorsal junior
- 44 à 67 h
- Ingénieur DevOps
- 21 à 32 h
- Rédacteur technique
- 16 à 24 h
Modalités de paiement
- Acompte 20 %
- 39 960 $ CA à 61 120 $ CA
- Découverte 7,7 %
- 15 384,60 $ CA à 23 531,20 $ CA
- Maquettes approuvées 7,7 %
- 15 384,60 $ CA à 23 531,20 $ CA
- Fonctions principales 23,3 %
- 46 553,40 $ CA à 71 204,80 $ CA
- Développement complet 15,5 %
- 30 969 $ CA à 47 368 $ CA
- Tests et corrections 7,7 %
- 15 384,60 $ CA à 23 531,20 $ CA
- Mise en ligne 8,1 %
- 16 183,80 $ CA à 24 753,60 $ CA
- Retenue, 30 jours après la mise en ligne (10 %)
- 19 980 $ CA à 30 560 $ CA
Comment lire la répartition par rôle
Comparez les trois exemples rôle par rôle plutôt que par le total. Quelques tendances reviennent dans presque tous les projets web.
- La gestion de projet grandit avec le projet, mais pas proportionnellement. Un plus gros projet a plus d’étapes et plus de personnes à coordonner, mais le cœur de la planification et des comptes rendus est là dès la première semaine.
- Le design bondit avec le degré de design, pas seulement avec le nombre d’écrans. Passer d’une apparence standard à un système de marque complet change davantage les heures du designer que l’ajout de quelques écrans.
- Les heures de développement dorsal suivent les fonctions. Un petit outil interne, ce sont surtout des écrans; un portail avec paiements et téléversements, ce sont surtout des règles, des données et des cas limites.
- L’assurance qualité grimpe en flèche avec les paiements et les données réglementées. Tester un parcours de paiement, c’est tester les remboursements, les échecs, les nouvelles tentatives et ce que voit le client quand sa carte est refusée.
- L’architecture et le DevOps sont modestes sur une petite application et essentiels sur une grande. Une plateforme avec des intégrations et du temps réel a besoin de quelqu’un qui décide comment les parties s’emboîtent avant que quiconque les construise.
Si une soumission que vous recevez ne montre presque pas d’assurance qualité, ou pas de gestion de projet, ce travail n’a pas disparu. Il vous a été transféré, habituellement après la mise en ligne.
Où couper, et où ne pas couper
La plupart des budgets sont plus serrés que la première estimation. C’est normal, et il y a de bonnes et de mauvaises façons de combler l’écart.
| Habituellement une bonne coupe | Habituellement une mauvaise coupe |
|---|---|
| Moins d’écrans dans la première version, le reste planifié pour plus tard | Moins de tests sur les paiements ou tout ce qui touche à l’argent |
| Un design standard et propre plutôt qu’un système de marque complet, pour un outil interne | Aucun travail d’accessibilité sur un site public |
| Une seule langue au lancement si vos utilisateurs sont vraiment dans une seule langue | Pas de sauvegardes, pas de surveillance, pas de moyen de restaurer |
| Un outil existant pour un besoin secondaire, comme un centre d’aide, plutôt que de le construire | Sauter la documentation de transfert, si bien que seule l’équipe d’origine peut l’exploiter |
| Une date de lancement souple | Retirer la revue de sécurité avant le lancement |
L’accessibilité mérite un mot à part. Les Règles pour l’accessibilité des contenus Web du W3C définissent trois niveaux de conformité, A, AA et AAA [1], et AA est le niveau que visent la plupart des organisations. Le viser dès le départ coûte bien moins cher que de l’ajouter après coup, et c’est habituellement ce qui arrive quand on le coupe.
La sécurité, c’est pareil. L’Application Security Verification Standard de l’OWASP est une liste publiée d’exigences pour tester les contrôles de sécurité d’une application web [2]. Demandez à n’importe quel studio sur quelles parties il s’appuie, et à quel moment. Une soumission moins chère qui laisse la sécurité pour la fin, c’est un projet plus cher.
Parfois, la bonne coupe est de ne rien construire. Si votre besoin est une simple page de réservation, un formulaire ou une boutique en ligne, un produit hébergé vous coûtera moins cher qu’une application sur mesure pendant des années. Nous vous le dirons quand c’est vrai. Le logiciel sur mesure vaut son prix quand votre façon de faire est votre avantage, ou quand aucun produit n’y convient.
Ce qui n’est pas dans le prix de développement
Le développement est un coût ponctuel. Trois autres types de coûts s’y ajoutent, et une bonne estimation les nomme tous.
- L’hébergement, chaque mois : les serveurs, la base de données, le stockage et les sauvegardes, chez le fournisseur que vous choisissez, plus notre gestion si nous l’exploitons pour vous.
- Le soutien et la maintenance, chaque mois si vous le souhaitez : mises à jour de sécurité, mises à niveau des dépendances, petites corrections et quelqu’un à appeler quand quelque chose brise.
- Les coûts de tiers : envoi de courriels, frais de traitement des paiements, cartes, textos et licences. Ils sont facturés au coût et sont souvent modestes, mais ils grandissent avec l’usage.
Notre guide sur ce que coûte un logiciel après sa mise en ligne passe ces coûts récurrents en revue avec ses propres exemples.
Comparer les soumissions de différents studios
- 01
Demandez les heures par rôle
Un total seul ne dit rien de ce qui a été supposé. Les heures par rôle montrent si le design, les tests et la gestion de projet sont dans le prix ou discrètement laissés de côté.
- 02
Demandez les hypothèses
Les écrans, les fonctions, les intégrations et le degré de design sur lesquels chaque soumission repose. Deux soumissions ne se comparent que si leurs hypothèses concordent.
- 03
Demandez ce qui est exclu
L’hébergement, le soutien, les frais de tiers, la saisie de contenu et la migration de données sont les suspects habituels.
- 04
Demandez comment les changements sont chiffrés
Chaque projet change. Un processus clair de demande de modification compte plus qu’un premier chiffre bas.
- 05
Demandez à qui appartient le code
Il devrait être à vous dès qu’il est payé, dans votre propre dépôt, avec les comptes à votre nom.
Un acompte, des paiements par étape et une retenue après la mise en ligne, c’est ainsi que nous répartissons le risque d’un projet à prix fixe. Les échéanciers ci-dessus montrent chaque étape des exemples, et notre guide sur les paiements explique pourquoi c’est organisé ainsi.