Resumen
- TEMPLE Cloud Temple SAS corresponde a un negocio francés de nube soberana visible: las páginas públicas de Cloud Temple describen IaaS cualificado SecNumCloud, IaaS VMware, IaaS OpenSource, almacenamiento de objetos, metal desnudo, VPC, red troncal privada, alojamiento y servicios de soporte para sectores regulados.
- Las páginas oficiales de cumplimiento indican que el alcance IaaS Secure Temple cubre IaaS VMware, IaaS OpenSource, almacenamiento S3, cifrado HSM-KMS y metal desnudo, con validez SecNumCloud v3.2 hasta el 30 de mayo de 2028; la misma página lista PaaS OpenShift por separado.
- El enrutamiento público es real y actual: RIPEstat mostró AS33930 anunciado el 12 de julio de 2026, con seis prefijos IPv4 y dos prefijos IPv6, resultados de origen RPKI válidos en la vista verificada y amplia visibilidad RIS.
- El riesgo no es que el proveedor carezca de evidencia operativa pública; el riesgo es que la certificación, la visibilidad del AS y las etiquetas de producto aún no le dicen a un cliente exactamente qué rack, zona de disponibilidad, ruta de recuperación, nivel de soporte o proceso de salida protege una carga de trabajo específica.
- Los compradores deben tratar la evidencia pública de Cloud Temple como un punto de partida sólido para la diligencia debida, y luego verificar la colocación de la carga de trabajo, la escalada de soporte, la disponibilidad de hardware, las pruebas de restauración, la responsabilidad del circuito del cliente, los efectos de facturación y los límites de portabilidad de datos antes de mover sistemas críticos.
TEMPLE Cloud Temple SAS es el tipo de empresa de nube que puede parecer simple desde una tarjeta de directorio y complicada en cuanto un cliente pregunta qué tiene que funcionar realmente. El nombre apunta a un proveedor de nube soberana con oficinas francesas visibles, reclamaciones de cumplimiento, un sistema autónomo enrutado, una oferta de soporte pública, una página de estado oficial y documentos técnicos que describen cómputo, almacenamiento, red, alojamiento físico y límites de responsabilidad. Eso es suficiente para rechazar una lectura de estado operativo débil.
No es suficiente para tratar cada afirmación de disponibilidad o soberanía como algo que se cumple automáticamente. La empresa vende capacidad alojada, pero la capacidad aún depende de espacio físico real, energía, cableado, selección de rutas, plataformas de proveedores, mano de obra de soporte, configuración del cliente, pruebas de restauración y términos contractuales.
La propia página"Quiénes somos"de la empresa posiciona a Cloud Temple en torno a sectores sensibles, mencionando industria, finanzas, salud y el sector público como los mercados donde su promesa debe importar. Supágina de ubicacioneslista oficinas en París/La Défense, Lyon, Tours, Caen y Nantes, con la dirección de París/La Défense en Le Belvedere - SPACES, 1-7 Cours Valmy, 92800 Puteaux. Eso es evidencia de identidad útil, pero el mapa de oficinas no es el mapa de infraestructura. Un comprador no debe confundir una dirección de oficina con el sitio donde se ejecuta una máquina virtual, un blade de metal desnudo, un bucket S3, una puerta de enlace VPC o un rack físico.
La evidencia pública más sólida es el cumplimiento y la huella de productos. Lapágina de procedimientos de cumplimientode Cloud Temple dice que la empresa tiene certificación ISO 27001 para infraestructura desde 2018 y para servicios gestionados desde 2022, certificación HDS para actividades de datos de salud, cualificación SecNumCloud v3.2, informes ISAE 3402 y otras entradas de cumplimiento europeas. La misma página ofrece la declaración de alcance más concreta: "IaaS Secure Temple" figura bajo SecNumCloud v3.2 con validez hasta el 30 de mayo de 2028, y la nota al pie dice que ese alcance incluye IaaS VMware, IaaS OpenSource, Almacenamiento S3, cifrado HSM-KMS y Metal Desnudo. Eso no hace que todos los productos sean idénticos, pero sí coloca los principales productos de infraestructura dentro de un perímetro de cualificación público.
Lapágina del enfoque SecNumCloudde Cloud Temple presenta la propuesta estratégica: la nube debe proteger la confianza de empresas y organismos públicos, y el diseño de productos debe alinearse con estándares de seguridad europeos exigentes. La página también dice que la cualificación implica el cumplimiento de más de 700 requisitos y mejores prácticas de ANSSI en áreas técnicas, físicas, contractuales y operativas. Esa declaración es importante para el riesgo de infraestructura porque es explícitamente más amplia que los controles cibernéticos. Se trata de cómo se gestiona un proveedor. Sin embargo, incluso una cualificación amplia no es un documento de arquitectura por cliente. No le dice a un hospital, aseguradora, agencia pública o cliente industrial si su propio inquilino tiene dos hosts de cómputo, qué zona de disponibilidad contiene la copia pasiva, o si su cambio de firewall está cubierto por el nivel de soporte vigente.
La línea de productos muestra por qué esos detalles importan. La oferta de cómputo de Cloud Temple abarca varios patrones de consumo. El sitio público describeIaaS OpenSourcepara infraestructura virtualizada en una plataforma soberana,IaaS VMwarepara entornos VMware en un entorno de nube cualificado,Metal Desnudopara servidores físicos dedicados, y VM Instances en vista previa para máquinas virtuales más compartidas al estilo nube. Los documentos públicos de la empresa para IaaS OpenSource describen cómputo Cisco UCS, almacenamiento en bloque IBM Spectrum Virtualize e IBM FlashSystem, almacenamiento de objetos Dell ECS, redes Juniper, blades de cómputo y volúmenes de almacenamiento dedicados, precios de consumo mensual, conceptos de región y zona de disponibilidad, copias de seguridad, opciones de replicación y operación mediante API o Terraform. Eso no es un catálogo de alojamiento ligero. Es una pila física y operativa.
La pila tiene una implicación específica: la capacidad instalada y la capacidad utilizable no son lo mismo. Una página puede mostrar clases de blades, clases de almacenamiento y cifras de conectividad, mientras que un cliente aún tiene que preguntar si la clase exacta está disponible en la región deseada, si agregar otro host requiere stock de hardware, si un blade GPU tiene un plazo de entrega, si la segunda zona de disponibilidad tiene rendimiento de almacenamiento equivalente, y si la licencia del cliente permite conmutación por error en vivo.
Los conceptos de IaaS OpenSource de Cloud Temple listan clases de blades desde ECO hasta PERFORMANCE 4, con memoria, recuentos de núcleos, conectividad de 10 Gbit/s o 25 Gbit/s y, para la clase superior, GPU NVIDIA L40S a partir del 1 de mayo de 2024. Eso es un detalle útil. También le dice al comprador que la capacidad no es abstracta: se entrega mediante familias de hardware particulares con inventario finito.
El metal desnudo agudiza el punto. Ladocumentación de Metal Desnudodescribe servidores físicos dedicados conectados a almacenamiento en bloque distribuido, blades Cisco UCS, almacenamiento IBM Spectrum Virtualize, ubicación en zona de disponibilidad, acceso a consola estilo KVM, mapeo ISO, operaciones de encendido, etiquetado VLAN y dos interfaces de red cuya velocidad depende de la clase de blade. El producto es atractivo precisamente porque da a los clientes más control sobre el entorno operativo. Pero ese control traslada parte del riesgo al cliente. Si un cliente instala su propio hipervisor o sistema operativo, Cloud Temple puede proporcionar el blade, almacenamiento y acceso a la plataforma, pero el cliente aún posee las decisiones que convierten el hardware en una aplicación resiliente.
El lado de VMware tiene una tensión similar. El material de IaaS VMware de Cloud Temple describe recursos dedicados de blade, almacenamiento y red, compatibilidad con vSphere, VLAN L2, propagación entre zonas de disponibilidad, latencia intra-AZ por debajo de 3 ms e inter-AZ por debajo de 5 ms en la vista documentada, y alta disponibilidad que solo funciona si un clúster tiene el diseño de host requerido. Los documentos públicos señalan que si una zona de disponibilidad contiene solo un hipervisor, el reinicio automático en otro hipervisor no es posible. Ese es el tipo de frase que convierte una promesa de nube en realidad de ingeniería.
Un cliente puede comprar infraestructura de un proveedor cualificado y aún así construir un entorno frágil de un solo host si elige la forma incorrecta o pospone el segundo nodo.
El almacenamiento también requiere precisión. Lapágina de almacenamiento de objetosde Cloud Temple dice que el servicio se basa en Dell Elastic Cloud Storage, ofrece alta compatibilidad S3, está cualificado SecNumCloud, certificado HDS e ISO 27001, se replica automáticamente en tres zonas de disponibilidad, usa codificación de borrado EC 12+4, soporta TLS 1.2/1.3 más opciones de cifrado del lado del servidor, lista disponibilidad del 99.99% y durabilidad del 99.999999999%, y no cobra tarifas de salida. Esas son afirmaciones serias para compradores de almacenamiento de respaldo, archivo y aplicaciones. Aún necesitan asignarse al propio deber del cliente de establecer políticas de ciclo de vida, inmutabilidad, claves y restauración. El almacenamiento de objetos en tres zonas ayuda con la durabilidad de la plataforma; no prueba por sí mismo que un cliente pueda restaurar la versión correcta de un objeto después de un ransomware, eliminación errónea, mal diseño de retención o compromiso de claves de acceso.
La división de responsabilidades no está oculta. Lapágina de responsabilidad compartidade Cloud Temple remite a los lectores a matrices RACI para IaaS, VM Instances, almacenamiento de objetos, red y otros servicios. Lamatriz de responsabilidad de IaaSdice que Cloud Temple es responsable de implementar centros de datos físicos, infraestructura de cómputo, infraestructura de almacenamiento, conectividad troncal, licencias de software de plataforma esenciales, configuración base del inquilino y configuración inicial de copia de seguridad. También dice que el cliente es responsable de definir la arquitectura general, el número de inquilinos, el número de zonas de disponibilidad, la estrategia de continuidad y recuperación, el dimensionamiento de cómputo, almacenamiento, red y copia de seguridad, crear y mantener máquinas virtuales, asociar cada VM con planes de copia de seguridad y recuperación coherentes, y realizar pruebas periódicas de copia de seguridad y recuperación.
Esa división es probablemente el hecho más importante de todo el registro. Significa que la empresa puede ser un proveedor de infraestructura cualificado mientras deja decisiones críticas de diseño en manos del cliente. Si el cliente dimensiona incorrectamente un inquilino, omite pruebas de copia de seguridad, no distribuye cargas de trabajo entre zonas, mantiene una regla de firewall rota, pierde acceso de administrador o mantiene un nodo de aplicación único dentro de una plataforma por lo demás resiliente, la falla no se comportará como una simple interrupción del proveedor.
Será una falla de arquitectura conjunta con solo algunas capas cubiertas por los compromisos del proveedor. Por lo tanto, la pregunta de riesgo del artículo no es "¿Es TEMPLE Cloud Temple SAS una empresa de nube real?" La respuesta es sí. La pregunta es "¿Qué parte de este sistema del cliente está dentro del perímetro responsable de Cloud Temple y qué parte sigue siendo diseño propio del cliente?"
La misma división aparece en redes. Ladocumentación de la Red Troncal Privadade Cloud Temple dice que el producto proporciona redes privadas L2 VPLS entre zonas de disponibilidad, componentes de acceso a Internet privado, direccionamiento IP, protección anti-DDoS nativa, puertos para conectividad externa, circuitos de 1G/10G y enlaces privados en dos rutas ópticas diversificadas para productos de circuito dedicado. Lapágina de conceptos de Internetdice que Cloud Temple opera su propio AS, ofrece dos rutas de tránsito y dos puntos de intercambio en París, soporta BGP4, proporciona IPv4 pública por unidad y prefijos IPv6, reserva ancho de banda de Internet en incrementos de 100 Mbit/s y factura en percentil 95 en lugar de volumen de salida. Estos son hechos de diseño de red materiales, no afirmaciones decorativas.
Pero nuevamente, el límite importa. Lamatriz de responsabilidad de reddice que el cliente es responsable de suscribir conectividad de operador para acceder a un centro de datos físico de Cloud Temple, y de gestionar incidentes, problemas y capacidad en los enlaces del operador del cliente. Cloud Temple asume la responsabilidad de la red troncal, los puntos de recolección y los puntos de interconexión del centro de datos, y para el alojamiento físico, la responsabilidad comienza en el equipo del tope del rack. Ese límite es exactamente donde muchos incidentes se vuelven dolorosos. Una carga de trabajo puede estar saludable dentro de Cloud Temple, pero un sitio de cliente aún puede fallar debido a un enlace MPLS empresarial, un circuito de acceso de operador, un cambio IPsec incorrecto, un firewall local, un error de DNS o un límite de capacidad del lado del cliente.
La evidencia de enrutamiento público respalda la idea de que la empresa opera una red real. RIPE RDAP paraAS33930nombra a CLOUD-TEMPLE y lista a Cloud Temple SAS como entidad registrante, con la dirección de la organización en Le Belvedere, 1 Cours Valmy, 92800 Puteaux. Lavisión general de ASde RIPEstat identificó al titular como CLOUD-TEMPLE Cloud Temple SAS y mostró el AS como anunciado en el momento de la consulta del 12 de julio de 2026. Lavista de prefijos anunciadosde RIPEstat mostró ocho anuncios activos en la ventana que finaliza el 12 de julio de 2026: 91.223.207.0/24, 45.15.212.0/22, 185.56.204.0/22, 194.6.240.0/24, 93.187.40.0/21, 80.75.152.0/21, 2a02:668::/36 y 2a02:668:9000::/36.
Ese registro de enrutamiento es más fuerte que una huella solo de marketing. Lavista de estado de enrutamientode RIPEstat mostró seis prefijos IPv4, dos prefijos IPv6, 6.656 direcciones IPv4 anunciadas, 8.192 /48 IPv6, 54 vecinos observados y visibilidad RIS casi completa en la instantánea verificada. La vista de consistencia de enrutamiento mostró los prefijos anunciados de AS33930 presentes tanto en BGP como en fuentes de política de ruta de RIPE, sin lista de prefijos inconsistentes en la salida verificada. La validación RPKI devolvió "válido" para los ocho pares prefijo-origen de AS33930 verificados. Estos hechos no le dicen a un cliente cuán redundante es un servicio particular, pero muestran que la capa de red es visible, mantenida y no simplemente un residuo heredado.
La evidencia de tránsito e interconexión también es útil, aunque debe leerse con cuidado. Los comentarios de RIPE RDAP para AS33930 mencionan solicitudes de interconexión, detalles de France-IX y Equinix París. Lapágina de red de Cloud Temple en PeeringDBlista la red como Cloud Temple, con el nombre anterior de Cloud Temple como Intrinsec, una política de interconexión general abierta y una fecha de actualización en abril de 2025. La vista de intercambio público de PeeringDB muestra entradas de France-IX París y Equinix París IX a 10 Gbit/s, mientras que su vista de instalaciones lista Telehouse París 2, Telehouse París 3, Equinix PA6, Digital Realty París PAR7 y DATA4 París Marcoussis - PAR1 como instalaciones asociadas con el perfil de red. Esto corrobora la interconexión en el mercado parisino, pero sigue siendo un perfil de interconexión público, no un mapa vinculante de la colocación de cargas de trabajo del cliente.
La página de estado público agrega otro ángulo. Lapágina de estadode Cloud Temple expone componentes bajo FR1, incluyendo etiquetas de AZ como PA6, PAR7, TH3, PAR7S, TH3S y AZ07, junto con categorías para OpenIaaS, Object Storage, PaaS OpenShift, Bare Metal, VPC, servicios de borde e interfaces públicas. Una página de estado es valiosa porque da a los clientes un lugar público para observar incidentes y mantenimiento. No responde por sí sola la pregunta más profunda: ¿cuál de esas zonas de disponibilidad, servicios y componentes usa realmente este cliente, y sobrevive la propia aplicación del cliente si uno de ellos se degrada?
Las rutas de falla se vuelven más claras cuando la línea de productos se lee como un sistema. Una falla de rack o instalación afecta el cómputo, almacenamiento, red y alojamiento de manera diferente según la ubicación. Una falla de enlace ascendente o ruta afecta los servicios orientados a Internet, prefijos de cliente, acceso VPN y visibilidad de soporte de manera diferente según el diseño BGP. Una falla de stock de hardware afecta el metal desnudo, blades GPU, expansión de almacenamiento, dispositivos de firewall y hosts de reemplazo. Una falla de soporte afecta de manera diferente bajo los niveles Standard, Premium y Company.
Una falla de facturación o pedido puede retrasar el aprovisionamiento o la expansión. Una falla de migración puede dejar varadas las cargas de trabajo incluso cuando la plataforma está saludable. Ninguno de estos riesgos significa que el proveedor sea débil. Significan que el contrato de nube debe leerse como infraestructura, no como una abstracción mágica.
Los términos de soporte son parte de esa infraestructura. Lapágina de niveles de soportede Cloud Temple lista soporte Standard, Premium y Company con tarifas mensuales del 5, 7 y 10 por ciento de la facturación del servicio, niveles mínimos de facturación mensual, diferentes accesos a Technical Account Manager, objetivos de respuesta P1 de 2 horas, 30 minutos y 15 minutos, y monitoreo e intervención 24/7 para incidentes de nube. También dice que los ingenieros están disponibles 24/7 para incidentes de nube, mientras que las solicitudes de soporte tienen canales en horario laboral, con soporte en Francia en francés e inglés. La diferencia importa. Un incidente de producción del que Cloud Temple es responsable no es lo mismo que una solicitud de asistencia general, un cambio de configuración del lado del cliente, una pregunta de planificación de migración o una solicitud de una tarea no incluida en el catálogo.
La página de soporte también remite a la matriz de responsabilidad para incidentes con impacto en producción de los que Cloud Temple es responsable. Ese calificador no es letra pequeña en la práctica. Si la VM de un cliente está activa en la capa de hipervisor pero la aplicación está caída porque el sistema operativo invitado está roto, la ruta de soporte cambia. Si la VPC de un cliente está saludable pero el circuito de operador local está caído, la ruta de soporte cambia. Si existe una copia de seguridad pero el cliente nunca realizó pruebas de restauración, la ruta de soporte cambia.
Un buen soporte puede ayudar en todos estos casos, pero el límite contractual y el nivel pagado deciden velocidad, canal y responsabilidad.
Los documentos de SLA publicados refuerzan el mismo punto con números. ElSLA de VM Instancesdefine un compromiso de disponibilidad mensual del 99.95% para cada VM Instance activa facturada, equivalente a 21.9 minutos de indisponibilidad mensual permitida. Pero mide la indisponibilidad en la capa de infraestructura subyacente de Cloud Temple, excluye SO invitado, software del cliente, configuración de red del cliente, fallos de aplicación, mantenimiento programado, componentes de gestión faltantes, comportamiento abusivo y fuerza mayor, y requiere un ticket de soporte dentro de los 30 días calendario para reclamar créditos de servicio. Esa es una estructura de nube normal. También es una advertencia: el SLA no es una garantía de tiempo de actividad de la aplicación.
ElSLA de VPCes igualmente específico. Ofrece disponibilidad mensual del 99.99% para el plano de datos de VPC y 99.9% para el plano de control, con cinco minutos como umbral de indisponibilidad contado. Cubre componentes de VPC gestionados por Cloud Temple como el enrutador, redes privadas, puerta de enlace externa, NAT, DNAT y IPs flotantes. Excluye reglas de filtrado del cliente, direccionamiento incorrecto, fallos de cómputo conectados, conectividad a Internet externa más allá de la demarcación de Cloud Temple, mantenimiento programado, comportamiento abusivo y fuerza mayor. Esas exclusiones no son fallos en el documento; son cómo se dibuja el límite operativo real.
El almacenamiento de objetos tiene un perfil de salida y recuperación diferente. La página de producto público dice que los clientes pueden recuperar objetos mediante acceso compatible con S3 y que Cloud Temple no cobra tarifas de salida. Lamatriz de responsabilidad S3dice que Cloud Temple es responsable de mantener y asegurar la plataforma S3, acceso al servicio, registros, monitoreo, incidentes, problemas, capacidad y cambios de servicio. Dice que el cliente es responsable de crear objetos, crear claves de acceso, gestionar el ciclo de vida de los objetos, gestionar los derechos de los objetos, gestionar la seguridad lógica, copias de seguridad de los datos, pruebas de restauración periódicas, planes de continuidad de la aplicación y ejecución de la reversibilidad. Eso significa que la ausencia de tarifa de salida es útil, pero la portabilidad aún requiere planificación del cliente, credenciales, ancho de banda, lógica de retención y un destino probado.
La migración es donde la capacidad alojada a menudo revela su costo real. Los productos de Cloud Temple son explícitamente compatibles con ecosistemas familiares: entornos VMware, acceso S3, IaaS OpenSource estilo OpenStack, operación basada en API, aprovisionamiento basado en Terraform y BGP para prefijos de cliente. Esas son señales de interoperabilidad. Reducen el bloqueo en comparación con una pila propietaria cerrada.
Sin embargo, una salida de la plataforma sigue siendo un proyecto: imágenes de servidor, volúmenes de almacenamiento, buckets de objetos, reglas de firewall, derechos de acceso, enrutamiento, claves, DNS, monitoreo, acuerdos de soporte y ventanas de reversión deben alinearse. El RACI de IaaS dice que el cliente es responsable de planificar la reversibilidad, elegir la infraestructura de destino, ejecutar las operaciones de transición y gestionar los efectos de calidad de servicio durante la transferencia, mientras que Cloud Temple maneja el desmantelamiento de configuraciones y el borrado seguro después del fin del contrato.
La facturación y los pedidos no son problemas secundarios. La página de soporte dice que la facturación mínima de soporte comienza cuando los recursos están aprovisionados. Los documentos de red dicen que las direcciones IPv4 públicas se entregan dentro del stock disponible, el ancho de banda de Internet se reserva en incrementos de 100 Mbit/s, los circuitos privados pueden tener compromisos de 36 meses, y el alojamiento dedicado o los servicios de manos y ojos pueden tener plazos de 12 o 36 meses según el artículo.
Los precios del almacenamiento de objetos se basan en el uso, mientras que el metal desnudo y el alojamiento están ligados a unidades físicas. Esta mezcla afecta la resiliencia. En una emergencia, un cliente puede descubrir que la acción urgente no es solo un comando técnico; puede ser un nuevo pedido, una solicitud de soporte, un presupuesto de circuito, una entrega dependiente de stock o una modificación de contrato.
Los canales de adquisición añaden otra capa operativa. Las páginas de IaaS y Metal Desnudo de Cloud Temple dirigen a los compradores de los sectores público y de salud hacia rutas de compra pública como UGAP y CAIH. Eso importa porque puede facilitar que organizaciones que no pueden comprar infraestructura mediante negociación ad hoc adopten al proveedor. También significa que la planificación de la resiliencia puede estar moldeada por términos marco, entradas de catálogo preaprobadas, formularios de pedido, compromisos mínimos y tiempos de contratación pública.
Un comprador público puede pedir un servicio cualificado más fácilmente, pero aún necesita saber si una expansión de capacidad posterior, un circuito urgente, un cambio de soporte premium o una solicitud de asistencia de migración encajan en la misma ruta de compra.
Esta es una razón por la cual la economía de la capacidad alojada no debería reducirse a un precio unitario mensual. Un cliente que se muda de su propia sala de servidores a TEMPLE Cloud Temple SAS está trasladando costos de capital, carga de personal y riesgo de instalaciones a un proveedor con infraestructura especializada. Eso puede ser racional, especialmente para clientes regulados que no pueden construir fácilmente controles de grado SecNumCloud por sí solos.
Pero el cliente también acepta una nueva forma de costo: ancho de banda reservado, porcentajes de nivel de soporte, consumo de almacenamiento, direcciones IP, circuitos privados, tiempo de manos y ojos, asistencia profesional, términos de alojamiento físico y ancho de banda de salida. La factura de la nube no es solo cómputo y almacenamiento. También es el precio de las decisiones tomadas antes de una falla.
La afirmación de ausencia de tarifa de salida en el almacenamiento de objetos es un buen ejemplo de un término amigable para el comprador cuyo significado operativo depende del contexto. Si un cliente puede recuperar todos los objetos mediante acceso compatible con S3 sin cargos de salida, la barrera comercial para la salida es más baja que en muchos acuerdos de hiperescala. Pero mover muchos terabytes o petabytes aún consume tiempo, ancho de banda, control de claves de acceso, capacidad de destino, disciplina de nombres de objetos y conocimiento de la política de retención.
Si Entidad Lock está habilitado, el cliente también debe respetar sus propias decisiones de inmutabilidad. La ausencia de una tarifa de salida no elimina la necesidad de una ventana de migración, un diseño de destino y un proceso de copia verificado.
La página de estado público debe usarse de la misma manera práctica. Es valiosa porque nombra componentes que los clientes pueden monitorear durante un incidente, y señala que Cloud Temple ha hecho visible parte de su estado operativo. Sin embargo, un componente de estado solo es útil si el cliente sabe cómo se asigna a su servicio. Si un cliente ve un elemento para FR1 Object Storage o una etiqueta de zona de disponibilidad específica, ¿puede decir si su bucket, inquilino, puerta de enlace VPC o blade de metal desnudo está afectado? ¿El puente de incidentes del cliente incluye a alguien que entienda esas etiquetas?
¿El nivel de soporte ha prometido un canal de comunicación para la gravedad en cuestión? La visibilidad ayuda solo cuando está conectada al runbook y los registros de propiedad del cliente.
También hay una dependencia silenciosa en el propio borde público del proveedor. Una consulta DNS puntual observó cloud-temple.com en el espacio de direcciones de Cloud Temple, servidores de nombres Gandi, protección de correo de Microsoft, la consola en otra dirección de Cloud Temple y el nombre de host de estado a través de Atlassian Statuspage y CloudFront. Esas son opciones normales y no debilitan la evidencia central de la plataforma. Sin embargo, muestran que la comunicación con el cliente puede depender de capas más allá de AS33930.
En un incidente grave, el sitio web del proveedor, la consola, la página de estado, la ruta de correo, el soporte telefónico y el inquilino del cliente pueden fallar o sobrevivir en diferentes combinaciones. Los clientes deben mantener más de un canal de escalado y no esperar hasta una interrupción para probarlos.
La categoría global asignada a este artículo también necesita matices. Los servicios en la nube pueden comprarse y alcanzarse globalmente, y AS33930 tiene visibilidad de enrutamiento mundial. Pero la historia de soberanía pública de Cloud Temple es principalmente francesa y europea, con lenguaje de producto FR1, oficinas francesas, equipos de soporte franceses, cualificación ANSSI, relevancia HDS, interconexión en París y señales del mercado de instalaciones francés. Para un cliente fuera de Francia, la dependencia puede seguir siendo atractiva si el objetivo es la localidad de datos francesa o europea.
También significa que la latencia, los circuitos de acceso del cliente, las expectativas legales y las horas de soporte operativo deben evaluarse contra la base de usuarios real. Una población de usuarios global servida desde una nube soberana francesa puede necesitar almacenamiento en caché adicional, diseño de acceso regional o tolerancia a nivel de aplicación.
La soberanía también puede crear una falsa sensación de completitud si el cliente la trata como un sustituto de la arquitectura. Un proveedor francés cualificado puede reducir la exposición a ciertas preocupaciones legales, operativas y de seguridad, pero no puede decidir la clasificación de datos del cliente, la conmutación por error de ruta, el agrupamiento de aplicaciones, los derechos de inquilino, la rotación de claves, la frecuencia de restauración o la prioridad de salida. La documentación pública de Cloud Temple es inusualmente clara en que muchos de esos elementos permanecen en manos del cliente. Esa claridad es una buena noticia.
Da a los compradores la oportunidad de hacer explícita la división antes de la producción. El riesgo es que un comprador lea el titular de la certificación e ignore la tabla de responsabilidades.
La pregunta de adquisición más limpia es, por lo tanto, una tabla de demarcaciones, no una pregunta de confianza binaria. Para cada carga de trabajo, el cliente debe anotar el servicio de cómputo, servicio de almacenamiento, servicio de red, zonas de disponibilidad, destino de copia de seguridad, propietario de restauración, nivel de soporte, circuito del cliente, prefijo público, administrador de identidad, propietario de claves, propietario de facturación, contacto de mantenimiento y destino de salida.
Luego debe pedir a TEMPLE Cloud Temple SAS que confirme qué elementos son operados por el proveedor, cuáles son operados por el cliente, cuáles están en el alcance de SecNumCloud, cuáles son relevantes para HDS, cuáles están fuera de áreas cualificadas, cuáles están en vista previa y cuáles necesitan asistencia profesional por separado. Ese ejercicio es mundano, pero es donde la resiliencia de la nube se vuelve visible.
El alojamiento físico es el recordatorio más concreto de que la nube tiene bordes. Ladocumentación de Alojamientode Cloud Temple describe alojamiento físico por unidad de rack en racks compartidos o por rack dedicado de 42U, dos cadenas eléctricas para racks compartidos, límites de potencia por U, unidades de 2U orientadas a servidores con alimentación C19, racks dedicados con 3 kW sobre dos cadenas eléctricas de 16A, incrementos adicionales de 2 kW, una masa máxima de equipo de 1.000 kg, PDUs monitoreados, puertos de red de cobre o fibra, conectividad de sala de reuniones y servicios de manos y ojos. También dice que los racks dedicados están en espacio de alojamiento compartido fuera del área SecNumCloud. Esa última distinción es importante: "alojamiento de Cloud Temple" e "IaaS Secure Temple cualificado" no son frases intercambiables.
Para algunos clientes, el alojamiento es un puente. Un equipo heredado, un sistema adyacente a mainframe, un almacenamiento propietario, un HSM, un firewall o un servidor de preparación de migración pueden necesitar estar cerca de los recursos de la nube mientras una carga de trabajo regulada se mueve. Eso puede ser sensato. También puede crear una arquitectura de dos perímetros: parte nube cualificada, parte alojamiento físico no cualificado, parte equipo propiedad del cliente, parte red gestionada por Cloud Temple, parte circuito de operador.
Si el cliente asume que todo tiene la misma cualificación, respuesta de soporte y mecánica de recuperación, el diseño puede volverse engañoso. Los documentos de alojamiento son útiles precisamente porque obligan al comprador a hablar sobre unidades de rack, vatios, puertos, rutas ópticas, respuesta de manos y ojos y escalado de soporte.
El argumento de soberanía de datos es, por lo tanto, más sólido cuando se mantiene concreto. Las páginas de Cloud Temple hacen una afirmación de soberanía creíble en torno a la operación francesa, la cualificación SecNumCloud, HDS, ISO 27001, equipos de soporte en Francia y productos diseñados para sectores regulados. La página de almacenamiento de objetos enfatiza las necesidades regulatorias francesas y europeas. La página de soporte dice que los equipos de soporte están basados en Francia y operan desde Francia. La página de cumplimiento lista fechas de validez oficiales y alcances. Pero la soberanía no es solo una etiqueta nacional.
También es ubicación, acceso de soporte, evidencia de subcontratistas, custodia de claves, comunicación de incidentes, ruta de exportación, prueba de eliminación y divulgación de riesgo residual. Un cliente debe preguntar dónde se encuentra cada copia de datos, copia de seguridad, flujo de registros, artefacto de soporte e intervención de soporte.
La huella de red pública ofrece una lección similar. AS33930 tiene prefijos visibles, autorización de origen de ruta válida en la vista verificada, participación en intercambios y listados de instalaciones. Eso es mejor que ver solo un frontend de revendedor en la red de otra persona. Significa que Cloud Temple tiene superficie de enrutamiento directa y una historia de interconexión pública.
Aun así, la evidencia de enrutamiento no revela qué inquilino de cliente usa qué prefijo, cómo se dirige la mitigación de DDoS durante un ataque, si todas las rutas están igualmente disponibles durante el mantenimiento, qué preferencias de ruta se aplican a los prefijos propiedad del cliente, o qué tan rápido puede un cliente mover la identidad IP fuera de la plataforma. Un registro BGP sólido es necesario para algunas cargas de trabajo, no suficiente para todas.
Los clientes más afectados son aquellos a los que Cloud Temple se dirige: organismos del sector público, proveedores de salud, empresas financieras, operadores industriales, editores de software y otras organizaciones que necesitan tanto garantía de cumplimiento como continuidad operativa. En esos entornos, una interrupción de la nube rara vez es solo una molestia. Puede retrasar la atención médica, congelar informes regulados, detener sistemas adyacentes a la planta, bloquear servicios ciudadanos, interrumpir el acceso a la identidad o impedir que un editor de software sirva a clientes downstream.
La pregunta correcta de diligencia debida no es "¿Puede Cloud Temple alojar una VM?" Claramente puede. La pregunta es "¿Coincide el diseño de servicio elegido con el daño operativo si esta aplicación se detiene?"
Para una agencia pública, la respuesta puede involucrar el alcance de SecNumCloud, la segregación de inquilinos, el nivel de soporte, la comunicación de incidentes y la reversibilidad. Para un proveedor de salud, puede involucrar el alcance de HDS, las pruebas de restauración de copias de seguridad, el acceso de soporte, la retención de bloqueo de objetos y si la evidencia de subcontratistas cubre cada ruta. Para un equipo de finanzas, puede involucrar evidencia de auditoría, diversidad de rutas, archivo inmutable, cifrado, custodia de claves y planificación de salida estilo DORA.
Para una empresa industrial, puede involucrar enlaces de baja latencia, proximidad de instalaciones, diseño de red troncal privada, ventanas de mantenimiento y respaldo operativo local. Una sola etiqueta de producto no puede responder esas preguntas. El cliente debe convertir la evidencia pública en una revisión de diseño específica para la carga de trabajo.
La ruta de falla que más vale la pena probar es la compuesta: un incidente que cruza infraestructura del proveedor, configuración del cliente y proceso de soporte. Imagine un cliente ejecutando IaaS VMware en dos zonas de disponibilidad con un par de firewalls, copias de seguridad S3, un prefijo propiedad del cliente, una ruta de fibra local y un nivel de soporte Premium. Si una zona se degrada, la aplicación puede depender de la configuración de HA, replicación de almacenamiento, estado del firewall, comportamiento de DNS, convergencia de ruta, disponibilidad de S3 y un ticket que se clasifique correctamente.
Si el propio circuito de operador del cliente también tiene problemas, la red troncal de Cloud Temple puede no ser el cuello de botella. Si la política de copia de seguridad del cliente fue mal diseñada, el almacenamiento de objetos en tres zonas puede preservar los datos incorrectos. Es por eso que la responsabilidad compartida debe ejercerse antes de la interrupción, no solo citarse durante ella.
Las ventanas de mantenimiento merecen la misma atención. El lenguaje del SLA excluye el mantenimiento programado notificado bajo el contrato de soporte del cliente. Eso es normal, pero traslada la planificación práctica al cliente. ¿Quién recibe los avisos de mantenimiento? ¿Se enrutan al equipo que posee la aplicación? ¿Sabe el cliente si una actualización del hipervisor puede desencadenar un reinicio? ¿Entiende que algunas actualizaciones del SO del hipervisor pueden ser una decisión del cliente porque Cloud Temple no conoce todas las restricciones específicas de la carga de trabajo?
¿Están presentes los equipos de copia de seguridad, monitoreo y firewall durante la ventana? Un evento de mantenimiento es rutinario para el proveedor solo si también es rutinario para el cliente.
Las ventanas de reparación y el stock de hardware son más difíciles de verificar a partir de fuentes públicas. Los documentos revelan clases de blades, límites de almacenamiento, puertos de red y unidades de alojamiento físico, pero no publican recuentos de blades de repuesto, repuestos de controladores de almacenamiento, inventario de GPU, plazos de entrega por clase o práctica exacta de reemplazo por zona de disponibilidad. Eso no significa que el stock esté ausente. Significa que la investigación pública no puede probarlo.
La solicitud correcta del cliente es simple: mostrar el proceso de reserva de capacidad, expansión y reemplazo para el servicio elegido. Si la aplicación necesita cuatro blades GPU más durante una emergencia, o un host de reemplazo después de una falla de blade, o rendimiento adicional de almacenamiento de objetos durante una recuperación, el cliente debe saber si la respuesta es inmediata, programada, dependiente de pedido o dependiente de presupuesto.
Lo mismo se aplica a la prueba de restauración. La plataforma cualificada de Cloud Temple, la redundancia S3 y la arquitectura de copia de seguridad crean un punto de partida más sólido que un host genérico. Pero las matrices de responsabilidad de IaaS y S3 colocan repetidamente la coherencia del plan de copia de seguridad y las pruebas de restauración periódicas con el cliente, a veces con consulta a Cloud Temple. Eso debería cambiar el lenguaje de adquisición.
Los compradores deben preguntar no solo "¿Está incluida la copia de seguridad?" sino "¿Quién escribe el plan de restauración, quién ejecuta la prueba, quién registra el resultado, qué sucede si la restauración no cumple el objetivo y qué nivel de soporte se aplica durante una recuperación real?" Una restauración no probada sigue siendo una aspiración incluso cuando el almacenamiento subyacente está bien construido.
Por lo tanto, el grado de evidencia para TEMPLE Cloud Temple SAS debería ser mejor que la advertencia de huella ligera de la asignación, pero aún no absoluto. El registro público es amplio, actual y específico: las páginas oficiales identifican posicionamiento en sectores regulados, oficinas francesas, alcance SecNumCloud y HDS, familias de productos, niveles de soporte, arquitectura de almacenamiento de objetos, diseño de red troncal privada, términos de SLA de VPC y VM, límites físicos de alojamiento, enrutamiento de AS33930, validez RPKI, puntos de intercambio y componentes de estado público. Esa es una huella sustancial.
La evidencia faltante es más estrecha pero decisiva: ubicación específica del cliente, asignación exacta de operador de instalación para cada carga de trabajo, inventario de repuestos, historial de rendimiento de soporte, resultados de pruebas de restauración, concentración de clientes, comunicaciones de mantenimiento y ejecución real de salida.
Para los compradores, la conclusión práctica es tratar a TEMPLE Cloud Temple SAS como una dependencia de nube soberana creíble que aún necesita prueba a nivel de carga de trabajo. Pedir un diagrama que nombre la región, zonas de disponibilidad, hosts o clases de cómputo, clases de almacenamiento, buckets S3, políticas de copia de seguridad, puertas de enlace VPC, salidas a Internet, circuitos de cliente, contactos de soporte y rutas de escalado. Preguntar qué compromisos están cubiertos por el alcance de SecNumCloud, cuáles son HDS, cuáles son alojamiento ordinario, cuáles están en vista previa y cuáles son propiedad del cliente.
Preguntar cómo se reclaman los créditos de servicio y qué no cubren. Preguntar cómo sale una carga de trabajo, cómo se borran los datos, cómo se manejan las claves y cómo se comporta el soporte fuera del horario laboral.
Para los lectores de infraestructura, la lección es más amplia. Un proveedor de nube soberana puede ser genuinamente operativo y aun así depender de la física mundana de la capacidad. TEMPLE Cloud Temple SAS vende una combinación atractiva: infraestructura francesa cualificada, plataformas empresariales reconocibles, enrutamiento visible, almacenamiento de objetos en tres zonas de disponibilidad, soporte en Francia y matrices de responsabilidad explícitas. Pero el cliente no compra "soberanía" en abstracto.
Compra un inquilino particular, clase de blade, nivel de almacenamiento, ruta de red, nivel de ticket, calendario de mantenimiento y acuerdo de salida. Esas son las piezas que decidirán si la capacidad alojada sobrevive a un evento de rack, evento de enlace ascendente, escasez de hardware, cola de soporte, fricción de facturación, presión de migración o falla de contrato del proveedor.