Steam : jusqu'à 12 jours ouvrés pour valider un jeu, sans recours formel

Un build prêt, une page magasin remplie, une date de sortie annoncée depuis des semaines. Et un compteur qui tourne. Le 3 novembre 2026, Valve a officiellement admis ce que les développeurs constataient dans leurs tickets : la validation d'un jeu avant publication sur Steam peut désormais prendre "jusqu'à 12 jours ouvrés", contre 3 à 5 jours ouvrés habituellement.

La question qui remonte aussitôt des studios indépendants - dont les studios français, qui ne bénéficient d'aucun traitement particulier - est simple : que peut-on faire quand le build est bloqué ? La réponse honnête tient en deux temps. Il n'existe pas de recours formel. Il existe des leviers opérationnels, et ils se préparent avant l'envoi du build, pas après.

Ce que Valve a réellement annoncé

Dans une note publiée sur Steamworks le 3 novembre, Valve explique avoir constaté "une augmentation significative des soumissions pour la revue des pages magasin et des builds ces derniers mois", et reconnaît être "un peu en retard". L'entreprise attribue "une grande partie" du retard aux re-revues : ces builds renvoyés dans la file parce qu'ils ne passaient pas le premier examen.

C'est une information plus intéressante qu'elle n'en a l'air. Elle déplace la cause du problème : ce n'est pas seulement qu'il y a plus de jeux soumis, c'est que chaque jeu consomme en moyenne plus de cycles de validation qu'avant. Valve ne dit pas seulement "nous sommes débordés par le volume", elle dit aussi "nous validons deux fois le même dossier". Nuance importante, car elle désigne un levier côté développeur.

D'où la révision de la checklist de pré-publication, dont plusieurs exigences sont déjà actives :

1. Lancer le jeu via le client Steam et y jouer au moins cinq minutes. Valve précise, avec une pointe d'agacement perceptible, que certains builds soumis n'avaient "jamais été lancés via Steam" : un exécutable qui démarre en double-clic peut très bien casser à l'installation ou au premier lancement par un joueur.
2. Confirmer les redistributables requis, DirectX ou Visual C++ selon les cas.
3. Vérifier que les succès Steam sont prêts.
4. Pour les jeux compatibles Steam Cloud, faire écrire une sauvegarde dans le cloud par un membre du groupe partenaire.
5. Fournir au moins cinq captures d'écran classées dans la catégorie "gameplay", la classification en cinématiques ou concept art étant désormais possible.
6. Passer en revue les fonctionnalités déclarées comme supportées (manette, cloud, écran partagé...) pour vérifier qu'elles sont bien dans le build, via un rappel affiché dans l'outil.

Valve annonce d'autres améliorations à venir et un enrichissement progressif de la documentation.

L'illusion du recours

Soyons précis sur ce qui n'existe pas. Il n'y a pas de procédure d'appel, pas de second avis, pas de médiateur, pas de délai contractuel opposable avec pénalité. Le seul canal est le ticket au support Steamworks, examiné à la discrétion de Valve.

Les cas documentés cette semaine montrent la limite du dispositif. Le studio Daimon avait soumis son build le 12 octobre pour lancer Food Devils en accès anticipé le 3 novembre. Son directeur, Alfred Kamon, indiquait que le jeu attendait toujours l'approbation, et qu'un ticket envoyé la semaine précédente, marqué comme urgent, était resté sans réponse. L'éditeur 2 Left Thumbs raconte de son côté avoir raté la sortie de Wheel Make It "de près de deux semaines", avec un build recalé parce qu'une "seule option de menu" n'était pas accessible à la manette.

Ce dernier exemple vaut une leçon. Le motif de refus n'est pas un bug de gameplay, c'est un défaut de conformité entre ce que la fiche promet et ce que le build fait. C'est exactement le type de point que la nouvelle checklist cherche à faire vérifier en amont. Et c'est ce qui rend l'analyse de coût intéressante : un refus pour une option de menu inaccessible coûte au studio deux semaines, et coûte à tous les autres studios une place dans la file.

Autrement dit, une re-revue est une externalité négative : celui qui envoie un build incomplet ne paie pas le prix de la congestion qu'il provoque. La réponse de Valve - déplacer une partie du contrôle chez le développeur - est économiquement logique. Elle a aussi un angle moins flatteur : le travail de vérification change de main sans que la commission de 30 % prélevée sur les ventes bouge. On peut comprendre que Valve préfère filtrer en amont plutôt qu'embaucher massivement pour absorber un pic dont on ne sait pas s'il est structurel. On peut aussi noter que son contrôle qualité se transforme en travail gratuit imposé aux studios.

Le vrai coût, c'est le calendrier

Valve recommande, dans sa documentation Steamworks, de soumettre une page magasin "au moins 7 jours ouvrés" avant la mise en ligne souhaitée. Le décalage saute aux yeux : l'entreprise reconnaît simultanément que le pire cas atteint 12 jours ouvrés. Un développeur qui suit le conseil officiel à la lettre peut donc rater sa propre date, sans avoir commis d'erreur.

C'est là que se concentre le risque réel pour un studio indépendant, et il est très inégalement réparti. Un éditeur avec un portefeuille encaisse un décalage de deux semaines. Une équipe de deux ou trois personnes qui a calé sa communication, sa campagne de presse, ses clés pour les créateurs de contenu et parfois un dépôt de garantie sur un événement encaisse le même décalage comme un trou de trésorerie. Le coût n'est pas la validation. Le coût, c'est la fenêtre de lancement ratée et l'attention déjà dépensée.

Il faut ajouter un effet de calendrier bien connu des vétérans de la plateforme : les files s'allongent autour des grands rendez-vous. Le Steam Next Fest d'octobre 2026 a réuni 7 240 jeux, soit 65,2 % de plus que l'édition de juin selon les données de How To Market A Game. Les démos affluent, les pages se créent, les builds se soumettent, et tout le monde veut sortir dans la foulée. Se placer dans cette vague, c'est choisir la file la plus longue.

L'hypothèse de l'IA : plausible, pas établie

La plupart des articles publiés cette semaine ont accolé le mot "IA" à l'annonce de Valve. Il faut remettre les couches dans le bon ordre.

Valve parle d'afflux de soumissions et de re-revues. Point. Ce sont les développeurs concernés et les journalistes qui avancent l'hypothèse du "slop" généré à la chaîne. Alfred Kamon écrit lui-même : "On ne peut que supposer que la file est bouchée par du slop IA." C'est une supposition assumée, pas un chiffre.

Les données de volume, elles, sont réelles. Selon Quartz, plus de 4 000 jeux sont sortis sur Steam en octobre, contre environ 1 700 par mois depuis janvier. Un utilisateur de Reddit a calculé que 49,9 % des jeux sortis depuis que Valve exige, en 2024, une déclaration d'usage de l'IA en comportent une. Et Itch.io a signalé un doublement du nombre de pages de jeux créées par jour en deux mois.

Ces chiffres disent une chose et une seule : la production de jeux a explosé, y compris sur des plateformes sans validation lourde. Le lien de causalité avec les re-revues reste une conjecture raisonnable, mais une conjecture. Un afflux de primo-éditeurs, moins familiers des exigences de conformité, produirait exactement le même symptôme sans qu'une seule ligne de code ne soit générée par une machine. La coïncidence temporelle entre la vague d'outils génératifs et la hausse des sorties est frappante ; elle ne prouve pas que ce sont les mêmes dossiers qui bloquent la file.

D'ailleurs, les nouvelles règles filtrent-elles vraiment le "slop" ? Un jeu généré à la chaîne peut parfaitement être lancé cinq minutes via Steam, avec des succès configurés et cinq captures d'écran estampillées "gameplay". Les exigences relèvent le plancher de sérieux ; elles ne distinguent pas le jeu médiocre du jeu frauduleux. Tant que la validation humaine reste le goulot, le volume gagnera.

Ce qu'un studio français peut réellement faire

Il n'existe aucune donnée propre aux développeurs français, et il serait malhonnête d'inventer un cas tricolore. La file est mondiale, l'interface est en anglais, le support répond en anglais, et un studio basé à Lyon ou à Montréal attend dans la même colonne. Aucune autorité française ne débloquera un build : la relation reste contractuelle avec Valve, qui décide de ce qu'elle publie sur sa boutique.

Ce qui change, concrètement, c'est la marge de sécurité à intégrer :

• La page magasin d'abord, très tôt. Trois semaines avant la date visée plutôt que le minimum officiel de sept jours ouvrés, tant que la consigne reste en dessous du pire cas reconnu. Une page validée tôt évite d'empiler deux files.
• Le build ensuite, avec un cycle de correction budgété. Deux semaines pleines de marge, et l'hypothèse d'un refus. La checklist se lit comme une liste de causes de rejet : autant la cocher point par point, captures d'écran comprises.
• Un ticket factuel, pas émotionnel. Le support traite des dossiers, pas des urgences. Un ticket qui dit "build soumis le X, identifiant Y, voici les six points de checklist vérifiés, pouvez-vous confirmer que le dossier est complet" a plus de chances d'obtenir une réponse qu'un message expliquant que la sortie est dans trois jours. Et il ne faut rien en attendre : l'absence de garantie est la règle, pas l'exception.
• Une date de sortie traitée comme une hypothèse. La repousser sur Steamworks est possible ; communiquer à l'avance sur ce report l'est aussi. Les développeurs qui ont raté leur lancement cette semaine n'ont pas seulement manqué une date : ils ont perdu le contrôle du récit.

Sur Steam, le seul levier réel dont dispose un développeur est le temps qu'il s'accorde. Le reste - ticket, urgence, relance - relève de la politesse, pas du recours. La nouvelle checklist ne crée aucun droit : elle déplace la charge de la preuve vers celui qui soumet, avec l'espoir, côté Valve, que la file se remette à avancer dans le bon ordre.