Et pour ceux qui ont un ordinateur au bureau, dieu inventa VNC.

C'est leur moyen informatisé de séparer le prix du jeu pour pouvoir faire apparaître les frais de précommande, qui n'en sont pas.

Ce post est une non tautologie.

Mon dieu, l'inflation existe ? et donc la déflation ? Ca s'appelle des variations de prix et ça n'a aucun lien avec la précommande intrinsèquement. Le jeu est juste passé à 49€ pour certaines enseignes, tout simplement, à un instant donné. J'ai précommandé sur Amazon au moment où le jeu était à 55€. J'ai reçu la boîte hier, ma facture est à hauteur de 49€. Je n'ai payé que 49€ (au moment de l'envoi, ils prennent le nouveau prix, c'est dans les conditions) et j'ai précommandé (accès ce soir ou demain théoriquement). Ce contre exemple suffit à lui-même.

Il y a du vrai et du faux dans ce que l'un et l'autre disent. Il n'y a pas de vérité absolue à ce niveau et les conventions ne sont pas clairement établies. Tout dépend de plusieurs facteurs, dont les délais et majoritairement le budget. Dans un contexte idéal, les stress test ne sont pas au moment de monter l'application sur l'environnement de PRODUCTION. On distingue 5 types d'environnement, le plus classiquement 4. DEVELOPPEMENT, INTEGRATION, RECETTE, [HOMOLOGATION], PRODUCTION. Les trois premiers environnements servent aux déploiements progressives dans l'unique but de: DEVELOPPEMENT : comme son nom l'indique, développer et tester; INTEGRATION: comme son nom l'indique, intégrer. A savoir, pouvoir avoir une vue d'ensemble de l'application déployée en tant qu'artefact et permettre les premiers tests d'intégration/de charge (même si ce n'est pas le but premier); RECETTE: cet environnement n'est utile que lorsqu'il y a délégation de la partie test à une équipe n'appartenant pas à son organisation (typiquement un client externe); HOMOLOGATION: stress test purement et simplement, environnement de pré-production ne servant qu'à ça. On martyrise les applications déployées un maximum et on travaille à un équilibre de charge meilleur si cela ne respecte pas les spécifications techniques à ce niveau (issu du Market, hein, évidemment. "Nous on veut plus de clients !"). Il est malheureusement optionnel dans bien des cas; PRODUCTION: on met réellement en production l'application, i.e la release FINALE. Elle doit être exempt de défauts ou le cas échéant (car c'est une utopie) donner lieu à des patchs correctifs/évolutifs. Donc, il y a du vrai dans le sens où la release ne DEVRAIT pas servir à un stress test et d'ailleurs, Bioware l'a confirmé dans un autre post. L'échantillonnage d'accès ne servirait qu'à répartir équitablement les joueurs sur les serveurs. Néanmoins, les environnements d'homologation ont un coût élevé et certaines organisations préfèrent déployer petit à petit en faisant office de "release déguisée". Cela dit, avec des phases de BETA précédentes, ils ne devraient pas en avoir besoin. Evidemment, puisqu'au moins l'un de vous deux est dans le monde de l'informatique, je ne vais pas vous apprendre votre boulot. Cela dit, je me permets de le faire car mon boulot à moi est de gérer une équipe technique de développeurs , ce que je suis également, par voie de conséquence.

C'est réfléchi, mais malheureusement, ça ne marche pas comme ça dans la gestion de projet Informatique. A ton/tes clients, tu lui fournis un délai/planning, un devis lorsqu'il y a lieu très tôt dans le cycle de vie d'une application, bien avant la livraison et ce, même si ceux-ci s'avèrent (car il ne faut pas se leurrer, c'est toujours le cas pour des raisons de budgétisation serrée en ce qui concerne le temps consacré à l'étude/l'analyse) faux. Le client exige, tel est le paradigme bien connu. Le fournisseur ne fait que négocier les changements mais doit tenir ses délais/coûts/qualité. Dans le cas contraire, c'est pour la pomme du fournisseur.

Que l'on soit bien clair, serveur "FULL" n'est qu'un état à un instant "t" d'un serveur, sûrement calculé d'ailleurs de manière automatique avec des règles de gestion propres à l'architecture technique mise en place. Si les architectes logiciels ont fait correctement leur boulot, nous devrions avoir une gestion de pool de joueurs dynamique et configurable très rapidement (les propriétés de paramétrage le sont sur toutes les applications bien conçues). Tout ça pour dire: "Wait & See".

Non, ça signifie: "Plus qu'une !".