Son infrastructure tourne sur les serveurs de l'hyperscaler. En cas de crise, l'hyperscaler ne peut plus commander de nouveaux serveurs GPU — TSMC est à l'arrêt. Il maintient la capacité existante mais ne peut pas l'étendre. Si l'organisation a besoin de scaler (pic d'activité, croissance, incident nécessitant plus de ressources), elle se heurte à un rationnement. Elle est dans la file d'attente — après les besoins propres de l'hyperscaler, après les clients Enterprise Agreement. Sans priorité contractuelle garantie, elle attend.

Elle ne peut pas non plus rapatrier son infrastructure — elle n'a plus les compétences (documenté dans La Novlangue), plus les ingénieurs (−34% de postes Linux), et il faut 6 à 12 mois pour migrer (documenté dans L'Exodus Accompagné).

Son infrastructure tourne sur des serveurs physiques qu'elle possède. Ces serveurs ont été achetés et livrés avant la crise. Leurs puces sont là, fonctionnelles, indépendantes de la production future. En cas de crise, elle peut maintenir son activité normale. Elle peut même acheter du Refurbished supplémentaire sur le marché secondaire — dont la valeur augmente en cas de rareté des puces neuves, mais reste disponible car le parc de serveurs existants dans le monde est massif. Elle est hors file d'attente de rationnement cloud.

Son core infrastructure tourne sur ses propres serveurs — les services critiques, les données sensibles, les workloads de base. Le cloud est utilisé pour les pics d'activité temporaires ou les services non critiques. En cas de crise, elle peut rebasculer ses workloads cloud sur son infrastructure physique. Elle n'est pas totalement dépendante de la file d'attente du fournisseur. C'est le modèle documenté dans "L'Interface Souveraine" — l'Anti-Corruption Layer qui permet de switcher sans réécriture applicative.