Qu'est-ce qui détermine vraiment le coût d'un site Webflow ?

Cet article ne contient pas de prix, délibérément. Tout chiffre avancé sans connaître le projet est soit une supposition, soit un ancrage, et les deux sont pires qu'inutiles pour qui cherche à budgéter. Ce qui est réellement transposable d'un projet à l'autre, c'est la liste de ce qui fait bouger le chiffre, et l'ampleur de chaque facteur. Lisez ceci comme un moyen d'interroger un devis reçu, y compris la possibilité de demander à un studio pourquoi le sien diffère d'un autre, conversation généralement plus révélatrice que le prix lui-même.

Pourquoi le nombre de pages prédit-il si peu ?

Parce que la plupart des pages d'un site bien construit sont assemblées à partir de composants existants : la dixième page d'un type donné coûte une fraction de la première. Ce qui consomme réellement du temps, c'est le nombre de types de pages distincts, chacun exigeant sa mise en page, son comportement responsive, ses états vides et son modèle de contenu. Un site de quarante pages bâti sur six gabarits est un chantier plus petit qu'un site de douze pages toutes sur mesure. Quand un devis est chiffré à la page, il gonfle la partie répétitive ou sous-estime la partie distincte, et il vaut la peine de demander laquelle.

Plus que tout le reste côté technique, et cela croît de façon non linéaire. Un blog avec des articles et rien d'autre, c'est une collection et un après-midi. Un site où les articles ont des auteurs, les auteurs des profils, les articles des catégories, les catégories des pages d'atterrissage et les études de cas des références vers les prestations utilisées, c'est un ensemble de relations, et les relations sont là où les heures s'accumulent. Le coût n'est pas de créer des collections : il est dans chaque gabarit qui doit les afficher, chaque filtre qui doit les interroger, et chaque écran d'édition qu'une personne non technique devra comprendre ensuite. Esquissez le modèle avant de demander un devis et le devis devient bien plus juste.

Qu'ajoutent réellement les intégrations ?

Chacune ajoute une dépendance que vous ne contrôlez pas, et c'est là le coût, pas la connexion elle-même. Brancher un formulaire sur un système client est en général simple. Ce qui prend du temps, c'est de décider ce qui se passe quand l'autre bout est indisponible, quelle est la solution de repli, qui est alerté, comment les doublons sont traités, et comment quelqu'un découvrira plus tard que les soumissions ont cessé d'arriver. Les équipes chiffrent le chemin heureux puis dépensent le dépassement sur les cas d'échec. Demandez à tout studio chiffrant une intégration ce qui se passe quand elle échoue : la qualité de la réponse vous dit si le chiffre inclut ce travail.

Pourquoi une deuxième langue représente-t-elle plus du double du travail ?

Parce que la traduction est la partie visible et la plus petite. Chaque chaîne a besoin d'une place dans une structure qui garde les versions ensemble, sinon elles divergent silencieusement dès que quelqu'un en modifie une en oubliant l'autre. Les mises en page doivent survivre à des textes de longueurs différentes. Les langues de droite à gauche demandent un vrai travail au-delà de l'inversion de direction, car animations, images recadrées et positionnement absolu conservent tous leur orientation d'origine. Puis vient le coût permanent : chaque édition future devient deux éditions, ou trois. Le build est l'endroit où cela se chiffre, la maintenance celui où cela se paie.

L'animation sur mesure fait-elle beaucoup bouger le chiffre ?

Moins que les clients ne le pensent et plus que les studios ne l'admettent, et l'écart tient au test plutôt qu'à la construction. Faire bouger quelque chose est rapide. Le faire bouger correctement sur un téléphone milieu de gamme, se dégrader proprement selon les préférences de réduction de mouvement, éviter de bousculer la mise en page pendant l'exécution et ne pas rendre flou le texte en dessous : c'est là que passe le temps. Un site avec un seul moment signature réfléchi coûte en général moins cher et fonctionne mieux qu'un site où le mouvement est partout. Si un devis comporte une ligne animation, demandez ce qu'elle devient sur un appareil lent : la réponse sépare un build réfléchi d'une démo.

Quelle est la première source de dépassement ?

Les décisions encore ouvertes au démarrage du build, et le contenu est là où la plupart se cachent. Un projet chiffré sur un plan de site et une planche d'ambiance est chiffré sur une intention, et l'écart entre intention et spécification se comble pendant l'exécution, au moment le plus coûteux. Les textes manquants sont le coupable habituel, car les décisions de mise en page ne peuvent se figer autour d'un texte inexistant, et le travail se fait deux fois. La chose la moins chère qu'un client puisse faire pour réduire un devis est d'arriver avec le contenu écrit, ou de convenir explicitement que l'écrire fait partie du périmètre.

Que doit contenir un devis pour être comparable ?

Assez de structure pour voir quelles hypothèses diffèrent, car deux devis très éloignés décrivent en général deux projets différents plutôt que deux tarifs différents. Cherchez le nombre de types de pages distincts plutôt que de pages, le modèle de contenu en grandes lignes, les intégrations incluses et ce qui se passe en cas d'échec, le nombre de langues, qui rédige les textes, ce qui se passe après le lancement et pendant combien de temps, et ce qui est explicitement exclu. Un devis qui nomme ses exclusions est plus fiable que celui qui n'en nomme aucune, car tout ce qui n'est pas nommé est une conversation que vous aurez plus tard, à un plus mauvais moment.