Tarifs : chaque projet fait l’objet d’un devis

Pourquoi un devis plutôt qu’une grille de prix

En résumé : Deux projets décrits par la même phrase — « un site vitrine », « un agent conversationnel » — peuvent demander un travail sans commune mesure. La phrase ne dit pas le périmètre ; le prix suit le périmètre.

Une grille tarifaire suppose des produits comparables. Un logiciel vendu par licence peut en avoir une : le produit est identique pour tous. Un projet sur mesure n’en a pas, parce que ce qui est livré diffère à chaque fois. « Un site vitrine » peut désigner une page unique alimentée par un texte déjà écrit, ou un ensemble multilingue relié à un système de gestion existant, avec des règles d’accès et une reprise de contenu. Le même intitulé recouvre deux charges de travail qui n’ont rien à voir.

Afficher un prix de départ contourne le problème sans le résoudre. Le chiffre attire, puis le périmètre réel le contredit, et la conversation commence par une correction — mauvaise façon de commencer. L’alternative honnête consiste à dire ce qui fait varier le coût, à le dire avant, et à établir le montant une fois le périmètre écrit.

Un devis n’est pas qu’un prix. C’est le premier document où le périmètre est écrit noir sur blanc : ce qui est inclus, ce qui ne l’est pas, ce qui est fourni par le client et ce qui reste à produire. C’est cette partie-là qui évite les désaccords ultérieurs, bien plus que le montant lui-même.

Ce qui fait varier le coût d’un projet

En résumé : Cinq facteurs expliquent l’essentiel des écarts : l’étendue fonctionnelle, l’existant à reprendre, le contenu et ses langues, les intégrations tierces, et le niveau d’exigence attendu.

L’étendue fonctionnelle est le facteur le plus visible. Une page qui présente une offre et un formulaire de contact ne demande pas le même travail qu’un espace où des utilisateurs se connectent, déposent des documents et déclenchent des traitements. Chaque fonction ajoute son interface, ses cas d’erreur, ses règles d’accès et ses tests — la fonction elle-même est souvent la plus petite part.

L’existant pèse autant, et se sous-estime plus souvent. Repartir d’une page blanche est parfois moins coûteux que reprendre un système en place dont il faut migrer les données, préserver les adresses, respecter les habitudes des utilisateurs et maintenir le service pendant la bascule. Une reprise de données mal documentée peut représenter une part significative de la charge d’un projet, sans rien produire de visible à l’écran.

Le contenu détermine une part du coût que beaucoup découvrent en cours de route. Qui écrit les textes ? Sont-ils prêts ? Combien de langues, et qui valide chacune ? Une traduction n’est pas une conversion mécanique : elle demande une relecture par quelqu’un qui parle la langue et connaît le sujet. Un projet peut être techniquement terminé et rester bloqué faute de contenu.

Les intégrations tierces ajoutent une dépendance à quelque chose qu’on ne contrôle pas : un système de paiement, un logiciel de gestion, un service d’envoi, une source de données. Chacune apporte son authentification, ses limites d’usage, ses pannes possibles et sa documentation plus ou moins fidèle. Le coût d’une intégration se mesure moins à sa mise en place qu’à ce qu’elle impose de prévoir quand elle ne répond pas.

Le niveau d’exigence, enfin, se choisit et se paie. Accessibilité vérifiée, performance mesurée, sécurité revue, couverture de tests, documentation d’exploitation : ce sont des travaux réels, pas des cases à cocher. Ils peuvent être réduits en connaissance de cause ; ce qui coûte cher, c’est de les découvrir après la mise en ligne.

Forfait, temps passé, abonnement : ce que chaque modèle implique

En résumé : Trois modèles de facturation existent, et le choix porte moins sur le prix que sur le partage du risque. Le devis précise lequel s’applique et à quoi.

Le forfait fixe un prix pour un périmètre décrit. Il transfère le risque d’estimation au prestataire, ce qui rassure — à une condition : le périmètre doit être suffisamment précis pour être tenu. Sa contrepartie est la rigidité. Tout ce qui n’est pas décrit sort du forfait, et chaque changement passe par un avenant. Le forfait convient donc à ce qui est stable et bien compris, rarement à une exploration.

La facturation au temps passé convient à l’inverse : un périmètre qui va évoluer parce qu’on apprend en avançant. Elle transfère le risque au client, et n’est acceptable que si elle s’accompagne d’une visibilité réelle — ce qui a été fait, ce qui est en cours, ce qui a été décidé. Sans ce suivi, elle devient une dépense sans gouvernail.

L’abonnement couvre ce qui ne s’arrête pas : maintenance, mises à jour de dépendances, surveillance, corrections, évolutions régulières. Il correspond à une réalité que le mode projet masque — un site n’est pas un objet livré puis achevé. Le point à clarifier dans un abonnement est toujours le même : ce qu’il inclut, ce qu’il exclut, et ce qui se passe quand une demande dépasse son cadre.

Ces modèles se combinent souvent sur un même projet : un forfait sur la partie stable, du temps passé sur ce qui reste à explorer, un abonnement une fois en ligne. Ce qui compte n’est pas le modèle retenu, mais qu’il soit nommé et que ses limites soient écrites.

Ce qu’il faut réunir pour obtenir un devis exploitable

En résumé : Un devis vaut ce que vaut la description qui l’a précédé. Quatre éléments suffisent à passer d’une estimation vague à un chiffrage sérieux.

Le premier est l’objectif, formulé en résultat et non en solution. « Nous voulons un site » décrit un moyen. « Nous voulons que les demandes de rendez-vous arrivent sans appel téléphonique » décrit un résultat, et laisse ouverte la question de savoir si un site est bien la meilleure réponse. Un objectif exprimé en résultat permet aussi de vérifier plus tard s’il a été atteint.

Le deuxième est l’existant : ce qui est déjà en place, ce qui doit être conservé, ce qui peut être abandonné. Adresses actuelles, comptes, outils utilisés au quotidien, données à reprendre. C’est la partie que les demandes de devis omettent le plus souvent, et celle qui explique le plus d’écarts entre une estimation et un coût final.

Le troisième est la contrainte, quelle qu’elle soit : une enveloppe budgétaire, une échéance imposée par un événement extérieur, une obligation réglementaire, un outil imposé. Annoncer une enveloppe n’affaiblit pas votre position — cela permet d’ajuster le périmètre plutôt que de recevoir une proposition hors sujet.

Le quatrième est la décision : qui valide, et sur quoi. Un projet qui n’a pas de décideur identifié avance jusqu’au premier arbitrage, puis s’arrête. Nommer cette personne au moment du devis est le geste le moins coûteux et le plus souvent oublié.

Comment comparer deux devis

En résumé : Comparer les montants avant les périmètres n’a aucun sens. Le devis le moins cher est souvent celui qui décrit le moins, ce qui n’est pas la même chose que celui qui coûtera le moins.

Commencez par mettre les périmètres côte à côte, pas les totaux. Un écart de prix s’explique presque toujours par un écart de contenu : l’un prévoit la reprise des données, l’autre non ; l’un inclut les tests et la recette, l’autre les laisse au client ; l’un chiffre trois langues, l’autre une. Tant que les périmètres diffèrent, les montants ne sont pas comparables.

Regardez ensuite ce qui est explicitement exclu. Un devis sérieux contient une liste d’exclusions ; son absence n’indique pas que tout est inclus, mais que la question n’a pas été tranchée. Les exclusions les plus fréquentes portent sur le contenu, les traductions, l’hébergement, les licences tierces et la formation.

Vérifiez enfin les clauses qui n’ont pas de prix mais un coût : à qui appartiennent le code produit et les comptes créés, où sont hébergées les données, ce qui vous est remis à la fin, et ce qui se passe si la collaboration s’arrête. Ces points ne se négocient bien qu’avant la signature. Après, ils se subissent.

Ce que le prix de départ ne couvre pas

En résumé : La mise en ligne n’est pas la fin des dépenses. Hébergement, noms de domaine, dépendances logicielles et contenu continuent d’exister après la livraison.

Un site en ligne consomme des ressources : hébergement, nom de domaine, certificats, parfois des services tiers facturés à l’usage. Ces postes sont généralement modestes rapportés au projet, mais ils sont récurrents, et un renouvellement oublié met un site hors ligne aussi sûrement qu’une panne.

Les dépendances logicielles vieillissent. Les bibliothèques utilisées publient des correctifs, y compris de sécurité, et un projet laissé sans mise à jour devient progressivement difficile à reprendre : plus l’écart s’accumule, plus la remise à niveau coûte. C’est la dépense la plus facile à repousser et la plus coûteuse à repousser longtemps.

Le contenu, enfin, se démode plus vite que le code. Une offre change, un service disparaît, une page reste. La question à poser au moment du devis n’est pas seulement « qui construit ? » mais « qui met à jour, et comment ? » — parce qu’un site que personne ne peut modifier sans intervention technique finit par ne plus être modifié du tout.