La panne de déploiement d'octobre 2026 chez Vercel : ce que montre leur propre page de statut

Le 12 octobre 2026, la propre page de statut de Vercel a enregistré un incident intitulé « Increased build and deployment failures », d’une durée de 13 h 35 UTC à 20 h 11 UTC — un peu plus de six heures et demie, classé en sévérité majeure. Ce billet passe en revue exactement ce que dit le journal d’incidents de Vercel, sans rien enjoliver, puis aborde le vrai point architectural : ce que ça signifie quand votre pipeline de build et de déploiement est un seul système partagé que vous ne contrôlez pas, par rapport à un serveur qui vous appartient.

Ce que montre la propre page de statut de Vercel

Chaque horodatage et citation de cette section vient directement du registre d’incidents de Vercel sur vercel-status.com, lu via son API publique d’incidents — pas d’une couverture secondaire ni de spéculation.

13 h 35 UTC — Investigation : « We’ve identified an issue where some customers may experience build failures or deployments that fail to start. »

14 h 08 UTC — Identifié : « We have identified the issue and are working on a fix. »

14 h 57 UTC — Identifié : « Build and deployment failure rates have decreased, but some builds remain queued and are taking longer to start. » C’est le moment où il devient clair que l’incident n’était pas un simple accroc — les taux d’échec s’étaient améliorés, mais il restait un arriéré assez important pour mériter sa propre mise à jour.

16 h 10 UTC — Identifié : « We are continuing to work on a fix. Due to an upstream incident at GitHub, some builds and deployments for GitHub-connected projects are still failing. » C’est la ligne la plus importante pour comprendre ce qui s’est réellement passé : une défaillance d’un système en amont que Vercel n’exploite pas (GitHub) s’est ajoutée à l’incident propre de Vercel, précisément pour le cas très courant des projets qui déploient depuis un dépôt GitHub connecté.

19 h 56 UTC — Surveillance : « The backlog of deployment events has been processed. We will continue to monitor and provide additional updates. » Près de six heures et demie après le premier signalement, l’incident actif était terminé, mais il restait un arriéré d’événements de déploiement à traiter.

20 h 11 UTC — Résolu : « This incident has been resolved. »

Durée totale : environ 6 heures et 36 minutes, du début à la résolution. La propre classification de sévérité de Vercel pour cet incident était majeure. Le registre d’incidents ne précise pas quelle fraction des clients a été touchée, ni si des sites déjà en ligne et servant du trafic sont tombés — le langage tout au long est spécifiquement centré sur les builds et déploiements qui échouent ou ne démarrent pas, pas sur des déploiements existants qui tombent hors ligne. C’est une distinction importante à préciser : c’était un incident dans le pipeline qui livre du nouveau code, pas nécessairement dans l’infrastructure servant les sites déjà déployés.

Pourquoi les builds et déploiements de Vercel ont-ils échoué?

D’après les propres mises à jour de Vercel, deux choses se sont produites en même temps. D’abord, quelque chose à l’intérieur de la propre infrastructure de build et de déploiement de Vercel s’est dégradé dès 13 h 35 UTC, indépendamment de toute cause externe — le propre langage de Vercel (« we’ve identified an issue », « we have identified the issue and are working on a fix ») décrit ça comme leur propre problème de système avant même que GitHub soit mentionné. Ensuite, environ deux heures et demie plus tard, un incident sans rapport chez GitHub a aggravé le problème spécifiquement pour les projets connectés à GitHub, prolongeant le rétablissement pour ce sous-ensemble de clients même pendant que le propre correctif de Vercel réglait le reste pour les autres. La mise à jour de statut de Vercel est explicite : c’était un facteur contributif, pas la seule cause — les 2 heures et 35 premières minutes d’impact n’avaient rien à voir avec GitHub.

Ce qu’un pipeline de build partagé vous coûte réellement

C’est la partie qui mérite réflexion, parce qu’elle ne concerne pas vraiment cet incident précis — elle concerne ce qui est structurellement vrai de toute plateforme où votre pipeline de build et de déploiement est le propre système partagé et multi-locataire de la plateforme.

Quand vous déployez via Vercel, Netlify, ou toute plateforme qui construit votre code sur une infrastructure qu’elle possède et exploite, votre capacité à livrer un changement est couplée à la santé de cette flotte de build partagée à ce moment précis — pour chaque client simultanément. Une dégradation dans ce système partagé ne fait pas de tri; elle met en file d’attente les builds de plusieurs milliers de projets non liés qui déploient en même temps, et un arriéré qui prend six heures et demie à résorber est un arriéré qui a retardé chacun d’entre eux, peu importe si le code, le dépôt ou la configuration d’un client donné avait quoi que ce soit de défectueux. Si vous deviez livrer un correctif urgent pendant cette fenêtre — un correctif de sécurité, un flux de paiement brisé, n’importe quoi de sensible au temps — votre seul levier était d’attendre, parce que la file dans laquelle vous étiez coincé n’était pas la vôtre à vider.

Il y a une seconde couche spécifique à cet incident : même les parties du pipeline que vous ne considérez pas comme « la plateforme » peuvent devenir une dépendance que vous n’avez pas choisie. Un flux de travail de déploiement connecté à GitHub signifie qu’une panne chez GitHub devient aussi une panne dans votre capacité à livrer, acheminée par une plateforme que vous payez précisément pour ne pas avoir à penser à l’infrastructure de build. Ce n’est pas une critique de l’ingénierie de Vercel — des pannes en cascade à travers une dépendance en amont arrivent à des infrastructures gérées par de très bonnes équipes, et les propres mises à jour de Vercel montrent une équipe travaillant activement le problème en temps réel, pas en l’ignorant. C’est un fait structurel sur le fait de dépendre du pipeline partagé de quelqu’un d’autre : ses dépendances deviennent les vôtres, invisiblement, jusqu’au jour où elles ne s’alignent plus.

Déployer sur un serveur que vous possédez change ce couplage précis, pas tous les risques. Si vous construisez votre propre image Docker dans votre propre CI (y compris un palier gratuit de GitHub Actions, ou un exécuteur auto-hébergé), un arriéré de file d’attente du genre Vercel n’est tout simplement pas un système par lequel vous êtes acheminé — votre build tourne sur une infrastructure provisionnée pour vous, pas partagée avec le nombre de clients qui déploient à 13 h 35 UTC ce mardi-là. Vous pouvez quand même avoir une mauvaise journée : votre propre fournisseur de CI peut avoir une panne, votre propre serveur peut manquer d’espace disque, votre propre Dockerfile peut avoir un bogue. La différence, c’est que ce sont des défaillances dans un pipeline dimensionné pour un seul client — vous — pas une file partagée absorbant la charge de tout le monde simultanément, où l’échéancier du correctif dépend des ingénieurs d’une seule entreprise travaillant à travers un arriéré qui inclut du travail qui n’est pas le vôtre.

Ça vaut aussi la peine d’être honnête sur ce qu’on y perd. Une plateforme comme la flotte de build partagée de Vercel signifie que vous ne gérez pas d’infrastructure de build du tout — pas d’exécuteurs CI à provisionner, pas de cache de build à ajuster, pas de planification de capacité pour votre propre pipeline. C’est une vraie valeur, et c’est toute la raison d’être de plateformes comme celle-ci. Le compromis que cet incident illustre n’est pas « l’infrastructure partagée, c’est mauvais » — c’est que la commodité et un domaine de défaillance partagé sont la même décision, et ça vaut la peine de savoir laquelle vous avez prise.

Ce que ça signifie pour vous

• Si votre pipeline de déploiement dépend entièrement d’une plateforme que vous n’exploitez pas, sachez quel est votre plan de secours quand ce pipeline est dégradé — même un chemin de déploiement manuel documenté (construire localement, pousser une image, se connecter en SSH) vaut mieux que de découvrir pendant un incident qu’il n’y en a pas.
• Un flux de travail de build connecté à GitHub a deux dépendances en amont, pas une seule — votre plateforme d’hébergement, et GitHub lui-même. Les deux peuvent indépendamment ou conjointement retarder un déploiement, comme cet incident l’a montré.
• Vérifiez l’historique de statut public d’une plateforme avant d’en dépendre pour quoi que ce soit de sensible au temps — pas pour éviter toute plateforme ayant des incidents (toutes en ont), mais pour comprendre la fréquence réelle et la durée typique des dégradations de build/déploiement précisément, ce qui est la mesure qui compte si vous devez un jour livrer en urgence.
• « Sévérité majeure, 6,5 heures, build et déploiement précisément » est un point de données utile et vérifiable — lu directement depuis l’historique d’incidents d’une page de statut, qui est public pour essentiellement chaque plateforme de cette catégorie, Railyard y compris.

Voyez la comparaison complète : Railyard contre Vercel, et le parcours de migration complet : Migrer depuis Vercel.

Foire aux questions

Pourquoi Vercel a-t-elle eu des échecs de build et de déploiement le 12 octobre 2026? La propre page de statut de Vercel attribue l’incident à un problème interne dans son infrastructure de build et de déploiement à partir de 13 h 35 UTC, aggravé environ deux heures et demie plus tard par un incident sans rapport en amont chez GitHub qui a touché spécifiquement les projets connectés à GitHub.

Combien de temps a duré la panne de Vercel? Selon la propre page de statut de Vercel, de l’identification à 13 h 35 UTC jusqu’à la résolution à 20 h 11 UTC le 12 octobre 2026 — environ 6 heures et 36 minutes, classée en sévérité majeure.

La panne a-t-elle fait tomber des sites déjà déployés, ou seulement de nouveaux builds? Les mises à jour d’incident de Vercel décrivent des builds qui échouent ou ne démarrent pas, et des déploiements en file d’attente — le langage porte précisément sur le pipeline de build/déploiement, pas sur des déploiements existants et déjà en ligne qui tombent hors ligne.

Déployer sur son propre serveur évite-t-il ce genre de panne? Ça élimine le couplage précis à une seule flotte de build partagée et multi-locataire et à ses dépendances en amont. Ça n’élimine pas tout risque — votre propre fournisseur de CI ou votre propre serveur peut quand même avoir une mauvaise journée — mais une défaillance dans votre propre pipeline ne se retrouve pas en file d’attente derrière les builds de tous les autres clients en même temps.

Sources

• Vercel Status — historique des incidents — propre page de statut de Vercel
• API des incidents de Vercel Status — propres données publiques d’incidents de Vercel, « Increased build and deployment failures », créé le 2026-10-12T13:35:07Z, résolu le 2026-10-12T20:11:12Z, impact : majeur