Réponse en bref
La fenêtre d'une offre décrit le travail du prestataire, pas votre date de lancement. Ce que les décisions, les textes, les accès et l'acceptation y ajoutent, et pourquoi Product Build se chiffre en semaines.
De quoi un délai est fait : la réponse courte
Un délai, ce sont quatre segments mis bout à bout : la fenêtre de construction du prestataire, vos décisions, votre matière et l'acceptation. Écrire du code occupe une part plus petite du calendrier que d'attendre une question que personne n'a encore accepté de porter.
La page de développement de VITON13 annonce des fenêtres précises : 1-2 jours ouvrés, 2 jours ouvrés, 3-5 jours ouvrés, 2-3 semaines et un cycle mensuel. Chacune décrit le travail du prestataire. Une date de lancement apparaît une fois vos propres intervalles ajoutés.
C'est pourquoi une même offre produit deux dates différentes pour deux clients. La construction est identique, mais la file de validation, l'état de préparation des textes et la vitesse de remise des accès ne le sont pas, et cet écart déplace le calendrier.
La suite expose ce qui se cache derrière chaque fenêtre, quelles actions de votre côté la maintiennent en place, et pourquoi Product Build se chiffre en semaines quand les autres offres se chiffrent en jours ouvrés. La différence n'est pas cosmétique.
Ce que chaque offre annonce réellement
Site Fix Pack coûte 70 $ et prend 1-2 jours ouvrés : jusqu'à cinq corrections convenues, une vérification sur mobile et sur ordinateur, et une liste avant/après à la remise. Un tour de révision. Les nouvelles pages, la refonte et les migrations restent hors de l'offre.
Launch Site coûte 380 $ et prend 3-5 jours ouvrés : une construction adaptable, la connexion du CMS ou des données de base et la configuration du déploiement. Deux tours avant le lancement. Le contenu et les traductions sont fournis par le client, car le prestataire ne les rédige pas.
Launch Site Express coûte 520 $ et prend 2 jours ouvrés : le même périmètre en file prioritaire, avec des compilations quotidiennes, une liste de contrôle de lancement et un appel de remise. Un tour après la première construction complète. Le contenu, la photographie et le support continu sont exclus.
Product Build coûte 880 $ et prend 2-3 semaines : livraison de fonctionnalités, logique d'états et de routes, tests et durcissement. Deux tours par fonctionnalité livrée. Les applications mobiles natives et les licences de paiement sont exclues. Ongoing Dev Support coûte 290 $/mois en cycle mensuel avec 30 jours de préavis pour l'arrêter.
Pourquoi Product Build se chiffre en semaines
Les jours ouvrés sont une unité honnête quand le périmètre est connu d'avance. Cinq corrections, ou une construction adaptable, s'écrivent sous forme de liste ; la fenêtre peut donc être annoncée avant le démarrage puis tenue sans renégociation.
La livraison de fonctionnalités ne se décrit pas ainsi. La logique d'états et de routes se déploie à mesure qu'elle se construit : un écran en implique un deuxième, et vérifier les cas limites renvoie le travail d'un pas en arrière. Une semaine absorbe ces retours, une journée non.
Les tests et le durcissement vivent dans ces mêmes 2-3 semaines. Ils sont une part nommée de l'offre plutôt que le temps qui reste une fois que les fonctionnalités commencent à compiler, et ils produisent une part de reprise qu'une grille quotidienne ne peut pas contenir.
La conséquence pratique est simple : ne convertissez pas discrètement 2-3 semaines en dix ou quinze jours ouvrés pour planifier sur cette grille. La formulation en semaines a été choisie délibérément, et il vaut la peine de la conserver telle quelle dans votre propre correspondance.
Les décisions : la file des choix non tranchés
Les calendriers sont consommés par des questions sans responsable plutôt que par des lignes de code. Laquelle des deux directions de page d'accueil retenir, combien de niveaux comporte le menu, ce qui se passe après l'envoi d'un formulaire : chacune attend que quelqu'un la referme.
Tant qu'une question reste ouverte, le travail ne s'arrête pas ; il contourne la zone litigieuse. Ce détour coûte du temps deux fois, une fois pour la décision provisoire et une seconde quand cette décision provisoire est remplacée par la vraie réponse.
Ce qui aide, c'est une personne nommée plutôt qu'une réponse rapide. Un validateur unique ayant le dernier mot raccourcit le cycle plus sûrement qu'un groupe large où tout le monde commente, personne ne referme la question et la discussion revient en boucle.
Convenez à l'avance par quel canal arrivent les questions et sous quel délai on y répond. Cet intervalle appartient à votre côté de la date de lancement, et il mérite la même attention de planification que la construction elle-même.
Le contenu et les traductions viennent du client
Launch Site le dit franchement : le contenu et les traductions sont fournis par le client. Express répète la même ligne et y ajoute la photographie. VITON13 ne rédige pas vos textes et ne les traduit pas ; c'est une frontière du service, pas une clause en petits caractères.
Une ligne de départ en découle. Les trois à cinq jours ouvrés ne commencent pas à la signature ; ils commencent une fois que la matière existe. Des blocs vides ne se remplissent pas après coup sans un second passage sur la mise en page et une seconde relecture.
Les textes peuvent s'écrire en parallèle de la construction si la structure des pages est figée d'abord. Donnez au rédacteur la liste des blocs et une limite de longueur, et la matière arrive exactement au moment où la construction en a besoin.
Un lancement multilingue demande son propre plan : la traduction démarre une fois que le texte source a cessé de bouger. Modifier une phrase dans la langue source renvoie toutes les versions linguistiques dans la file, pas seulement l'une d'elles.
Les tours de relecture occupent le calendrier
Les tours de révision diffèrent selon l'offre, et la différence retombe sur le calendrier. Fix Pack a un tour. Launch Site a deux tours avant le lancement. Express a un tour après la première construction complète. Product Build a deux tours par fonctionnalité livrée.
Un tour est une liste rassemblée, pas un flux de messages séparés. Vingt commentaires envoyés en un seul document coûtent un passage ; les mêmes vingt envoyés un à un sur une semaine coûtent une semaine entière de travail.
Pour Ongoing Dev Support, aucun nombre de tours n'est annoncé. Ce qui est annoncé à la place, c'est que le volume est convenu au début de chaque cycle. Ne reportez pas un chiffre venu d'une autre offre : les conditions ne se transfèrent pas.
Réservez la fenêtre d'acceptation comme une réunion : qui relit, sur quels appareils, et pour quelle heure la liste est envoyée. Sans cela, un tour s'étire exactement autant que dure la collecte des avis à l'intérieur de votre équipe.
Accès, comptes et tiers extérieurs
La configuration du déploiement fait partie de Launch Site, mais elle dépend de ce que vous remettez : le domaine, le DNS, l'hébergement et les identifiants. Tant que les accès n'existent pas, le travail peut être terminé alors que le lancement, en pratique, n'a pas eu lieu.
Une partie de ces accès est délivrée par des organisations extérieures à leur propre rythme. Un bureau d'enregistrement, une banque, un prestataire de paiement ou un service informatique interne répond selon son calendrier, et aucun prestataire ne peut le comprimer pour vous.
Réunissez les identifiants dès le premier jour plutôt que le jour du lancement. La liste est courte et connue d'avance ; elle avance donc confortablement en parallèle de la construction et ne bloque rien pendant que vous la traitez point par point.
Les licences de paiement sont exclues de Product Build. Là où un produit doit encaisser, le volet juridique et le travail avec le prestataire restent de votre côté et se planifient séparément des 2-3 semaines de développement.
Les bords du périmètre : ce qui tient une fenêtre et ce qui la déplace
Une fenêtre est maintenue en place par une liste. « Jusqu'à cinq corrections convenues » est cette liste, et c'est pourquoi 1-2 jours ouvrés reste une promesse réaliste. Une sixième correction n'étire pas l'offre ; elle devient un travail distinct.
Fix Pack exclut les nouvelles pages, la refonte et les migrations. Ce n'est pas une formalité : déplacer des données et retravailler une mise en page vivent dans une autre unité de temps, et les forcer dans une fenêtre de deux jours casse la fenêtre elle-même.
Product Build exclut les applications mobiles natives. Une construction web et une application native sont deux corps de travail différents, et échanger l'un contre l'autre change la composition du service plutôt que sa date de fin.
Vérifiez la formulation du périmètre avant le démarrage plutôt qu'à mi-parcours. La question de savoir si quelque chose est compris coûte une minute au début et plusieurs jours une fois la construction lancée et le planning convenu.
Tests, performance et accessibilité
Les tests et le durcissement sont nommés à l'intérieur de Product Build, ce qui signifie qu'ils sont nommés à l'intérieur des mêmes 2-3 semaines. Ils occupent leur propre place dans le calendrier, pas le temps qui reste une fois les fonctionnalités écrites et remises.
La performance se vérifie par la mesure plutôt que par l'impression. La documentation de performance de MDN Web Docs décrit ce que le navigateur expose et quelles étapes de chargement méritent d'être observées ; ces vérifications prennent des heures, et ces heures ont leur place dans le plan.
L'accessibilité fonctionne de la même manière. La référence rapide du W3C pour WCAG 2.2 liste les critères de succès contre lesquels une interface se vérifie, et parcourir cette liste est une tâche planifiée plutôt qu'un dernier coup d'œil avant publication.
Les deux vérifications coûtent moins avant le lancement qu'après. Ce qui est trouvé pendant la construction se corrige à l'intérieur d'un tour ; la même chose trouvée après le lancement arrive comme un travail distinct et se chiffre séparément de l'offre.
Jours ouvrés contre jours calendaires
1-2 jours ouvrés, 2 jours ouvrés et 3-5 jours ouvrés sont annoncés en jours ouvrés, précisément. Un départ le jeudi sur une fenêtre de 3-5 jours ouvrés repousse la fin au-delà du week-end, et c'est de l'arithmétique contenue dans la formulation, pas un retard du côté du prestataire.
Les 2-3 semaines de Product Build sont annoncées autrement, en semaines. Il n'y a pas lieu de convertir : l'unité a été choisie pour correspondre au caractère du travail, pas pour la commodité d'un tableur de projet partagé.
Les jours fériés de votre pays et de celui du prestataire peuvent ne pas coïncider. Nommez-les avant le démarrage, car cela coûte moins cher que d'expliquer l'écart au moment où une date a déjà été promise au marché.
Pour obtenir une date de lancement, additionnez trois intervalles : la fenêtre de l'offre, vos propres intervalles pour les décisions et la matière, et la fenêtre d'acceptation. Cette somme est la date que vous pouvez répéter sans risque hors de l'équipe projet.
Express : acheter une place dans la file
Launch Site Express coûte 520 $ contre 380 $ pour le Launch Site ordinaire, et il prend 2 jours ouvrés contre 3-5. L'écart de prix achète une file prioritaire plutôt qu'un travail différent.
Express ajoute des compilations quotidiennes, une liste de contrôle de lancement et un appel de remise. Une compilation quotidienne signifie que vos commentaires atterrissent chaque jour sur une version qui tourne, et cela resserre la boucle de retour entre les deux côtés du projet.
Il y a ici un tour de révision, et il vient après la première construction complète. Cela change votre préparation : les commentaires partent en un seul document à une heure convenue, sinon une fenêtre de deux jours ouvrés perd son intérêt.
Le contenu, la photographie et le support continu sont exclus d'Express. Une file prioritaire accélère le prestataire, pas la rédaction de vos propres textes ; la matière doit donc exister avant même que la fenêtre ne s'ouvre.
Après le lancement : un cycle mensuel plutôt qu'une date
Ongoing Dev Support coûte 290 $/mois et fonctionne en cycle mensuel avec 30 jours de préavis pour l'arrêter. L'unité ici n'est ni une tâche ni une journée, mais un cycle, et la planification suit des cycles plutôt que des dates ponctuelles.
L'offre couvre des mises à jour prioritaires, un rythme hebdomadaire de publication et la maintenance technique. Le rythme hebdomadaire achète de la prévisibilité : un changement entre dans la publication suivante au lieu d'attendre une nouvelle conversation sur le moment où il pourrait sortir.
Pour le support, aucun nombre de tours n'est annoncé. Ce qui est annoncé à la place, c'est que le volume est convenu au début de chaque cycle. C'est cela, le mécanisme de planification : vous convenez du contenu d'un mois, pas d'un quota de reprises.
Une nouvelle construction ou une refonte est exclue du support et se chiffre séparément. La séparation est utile : le cycle mensuel tient le site en fonctionnement, tandis qu'un travail plus lourd reçoit sa propre fenêtre et ses propres tours.
Checklist pratique
- Désignez un seul validateur ayant le dernier mot et fixez le délai de réponse aux questions.
- Réunissez le domaine, le DNS, l'hébergement et les identifiants dès le premier jour, pas le jour du lancement.
- Figez la structure des pages avant que le rédacteur ne commence à écrire pour elles.
- Rassemblez les commentaires dans un seul document et envoyez-les en un tour, à une heure convenue.
- Vérifiez les exclusions de l'offre : nouvelles pages, migrations, applications mobiles natives, licences de paiement.
- Convertissez la fenêtre de l'offre en date de calendrier avec les week-ends et jours fériés des deux côtés.
Questions et réponses
Combien de temps prend la construction d'un site de lancement ?
Launch Site coûte 380 $ et prend 3-5 jours ouvrés. La fenêtre couvre une construction adaptable, la connexion du CMS ou des données de base, la configuration du déploiement et deux tours de révision avant le lancement. Le contenu et les traductions sont fournis par le client.
Pourquoi Product Build est-il chiffré en semaines plutôt qu'en jours ouvrés ?
L'offre coûte 880 $ et s'annonce en 2-3 semaines parce qu'elle couvre la livraison de fonctionnalités, la logique d'états et de routes, ainsi que les tests et le durcissement. Ce travail se déploie au fur et à mesure qu'il se construit ; l'unité hebdomadaire est donc délibérée et n'a pas à être convertie en jours.
Peut-on accélérer un lancement en payant davantage ?
En partie. Launch Site Express coûte 520 $ et prend 2 jours ouvrés : le même périmètre en file prioritaire, avec des compilations quotidiennes, une liste de contrôle de lancement et un appel de remise. Un tour de révision vient après la première construction complète, et le contenu, la photographie et le support continu sont exclus.
Que comprend le Site Fix Pack, et sur quelle fenêtre ?
70 $ et 1-2 jours ouvrés : jusqu'à cinq corrections convenues, une vérification sur mobile et sur ordinateur, une liste avant/après à la remise et un tour de révision. Les nouvelles pages, la refonte et les migrations ne font pas partie de l'offre.
Comment se compte le délai du support technique ?
Ongoing Dev Support coûte 290 $/mois et fonctionne en cycle mensuel avec un préavis de 30 jours pour l'arrêter. Aucun nombre de tours de révision n'y est annoncé ; ce qui est annoncé, c'est que le volume est convenu au début de chaque cycle. Une nouvelle construction ou une refonte se chiffre séparément.