Resumen
- TEMPLE Cloud Temple SAS se corresponde con un negocio visible de nube soberana francesa: las páginas públicas de Cloud Temple describen IaaS con cualificación SecNumCloud, IaaS VMware, IaaS OpenSource, almacenamiento de objetos, bare metal, VPC, red troncal privada, housing y servicios de soporte para sectores regulados.
- Las páginas oficiales de cumplimiento indican que el alcance de IaaS Secure Temple cubre IaaS VMware, IaaS OpenSource, almacenamiento de objetos S3, cifrado HSM-KMS y Bare Metal, con validez SecNumCloud v3.2 hasta el 30 de mayo de 2028; la misma página enumera 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 comprobada y una 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 sólido punto de partida para la debida diligencia, y luego verificar la ubicació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 en la facturación y los límites de portabilidad de datos antes de trasladar sistemas críticos.
TEMPLE Cloud Temple SAS es el tipo de empresa de nube que puede parecer simple en una ficha 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, declaraciones 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 computación, almacenamiento, red, alojamiento físico y límites de responsabilidad. Eso es suficiente para rechazar una lectura débil del estado operativo.
No es suficiente para tratar cada afirmación de disponibilidad o soberanía como autoejecutable. 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 propiapá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 está destinada a importar. Supágina de ubicacionesenumera oficinas en París / La Defense, Lyon, Tours, Caen y Nantes, con la dirección de París / La Defense en Le Belvedere - SPACES, 1-7 Cours Valmy, 92800 Puteaux. Esa es una 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 bare-metal, un bucket S3, una puerta de enlace VPC o un rack físico.
La evidencia pública más sólida es la huella de cumplimiento y de producto. Lapágina de procedimientos de cumplimientode Cloud Temple indica 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 de objetos S3, cifrado HSM-KMS y Bare Metal. Eso no hace que todos los productos sean idénticos, pero sitúa los principales productos de infraestructura dentro de un perímetro de cualificación pública.
Lapágina de enfoque SecNumCloudde Cloud Temple hace la propuesta estratégica: la nube debe proteger la confianza de empresas y organismos públicos, y el diseño del producto debe alinearse con los exigentes estándares de seguridad europeos. La página también dice que la cualificación significa el cumplimiento de más de 700 requisitos y mejores prácticas de ANSSI en áreas técnicas, físicas, contractuales y operativas. Esa afirmació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, organismo público o cliente industrial si su propio tenant tiene dos hosts de computación, qué zona de disponibilidad tiene la copia pasiva, o si el cambio de su firewall está cubierto por el nivel de soporte vigente.
La línea de productos muestra por qué esos detalles importan. La oferta de computación 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,Bare Metalpara servidores físicos dedicados, y VM Instances en vista previa para máquinas virtuales más compartidas al estilo de la nube. La documentación pública de la empresa para IaaS OpenSource describe computación Cisco UCS, almacenamiento en bloque IBM Spectrum Virtualize e IBM FlashSystem, almacenamiento de objetos Dell ECS, redes Juniper, blades de computación 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. No es un catálogo de hosting 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 añadir otro host requiere stock de hardware, si un blade GPU tiene un plazo de entrega, si la segunda zona de disponibilidad tiene un rendimiento de almacenamiento equivalente y si la licencia del cliente permite la conmutación por error en vivo.
Los conceptos de IaaS OpenSource de Cloud Temple enumeran clases de blades desde ECO hasta PERFORMANCE 4, con memoria, recuento de núcleos, conectividad de 10 Gbit/s o 25 Gbit/s y, para la clase superior, GPUs NVIDIA L40S a partir del 1 de mayo de 2024. Es un detalle útil. También le dice al comprador que la capacidad no es abstracta: se entrega mediante familias de hardware específicas con un inventario finito.
El bare metal agudiza el punto. Ladocumentación de Bare Metaldescribe 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 energía, etiquetado VLAN y dos interfaces de red cuya velocidad depende de la clase de blade. El producto es atractivo precisamente porque otorga a los clientes más control sobre el entorno operativo. Pero ese control devuelve parte del riesgo al cliente. Si un cliente instala su propio hipervisor o sistema operativo, Cloud Temple puede proporcionar el blade, el almacenamiento y el acceso a la plataforma, pero el cliente sigue siendo dueño de las decisiones que convierten el hardware en una aplicación resiliente.
El lado 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, VLANs L2, propagación entre zonas de disponibilidad, latencia intra-AZ por debajo de 3 ms y latencia 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. La documentación pública señala 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 a 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 necesita precisión. Lapágina de almacenamiento de objetospública de Cloud Temple dice que el servicio se basa en Dell Elastic Cloud Storage, ofrece alta compatibilidad con S3, está cualificado SecNumCloud, certificado HDS e ISO 27001, se replica automáticamente en tres zonas de disponibilidad, utiliza codificación de borrado EC 12+4, admite TLS 1.2/1.3 más opciones de cifrado del lado del servidor, enumera una disponibilidad del 99,99 por ciento y una durabilidad del 99,999999999 por ciento, y anuncia que no hay tarifas de salida. Esas son afirmaciones serias para los compradores de almacenamiento de respaldo, archivo y aplicaciones. Aún necesitan ser mapeadas a la propia obligación 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; por sí solo no prueba que un cliente pueda restaurar la versión correcta del objeto después de un ransomware, una eliminación errónea, un mal diseño de retención o un compromiso de la clave de acceso.
La división de responsabilidades no está oculta. Lapágina de responsabilidad compartidade Cloud Temple dirige a los lectores a matrices RACI para IaaS, VM Instances, almacenamiento de objetos, red y otros servicios. Lamatriz de responsabilidad IaaSdice que Cloud Temple es responsable y rinde cuentas de implementar centros de datos físicos, infraestructura de computación, infraestructura de almacenamiento, conectividad de red troncal, licencias de software de plataforma esenciales, configuración de línea base del tenant y configuración inicial de copias de seguridad. También dice que el cliente es responsable y rinde cuentas de definir la arquitectura general, el número de tenants, el número de zonas de disponibilidad, la estrategia de continuidad y recuperación, el dimensionamiento de computación, almacenamiento, red y copias de seguridad, crear y mantener máquinas virtuales, asociar cada VM con planes coherentes de copia de seguridad y recuperación, 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 y aún así dejar decisiones críticas de diseño en manos del cliente. Si el cliente subdimensiona un tenant, omite pruebas de copia de seguridad, no distribuye las cargas de trabajo entre zonas, mantiene una regla de firewall rota, pierde el acceso de administrador o mantiene un único nodo de aplicación dentro de una plataforma por lo demás resiliente, el fallo no se comportará como una simple interrupción del proveedor.
Será un fallo de arquitectura conjunto 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 del sistema de este cliente está dentro del perímetro de responsabilidad de Cloud Temple, y qué parte sigue siendo diseño propio del cliente?”
La misma división aparece en redes. Ladocumentación de Private Backbonede Cloud Temple dice que el producto proporciona redes privadas L2 VPLS entre zonas de disponibilidad, componentes de acceso privado a Internet, 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, admite BGP4, proporciona IPv4 público por unidad y prefijos IPv6, reserva ancho de banda de Internet en incrementos de 100 Mbit/s, y cobra sobre la base del percentil 95 en lugar de por volumen de salida. Estos son hechos materiales de diseño de red, no afirmaciones decorativas.
Pero de nuevo, el límite importa. Lamatriz de responsabilidad de reddice que el cliente es responsable y rinde cuentas de suscribir la conectividad del operador para acceder a un centro de datos físico de Cloud Temple, y de gestionar incidencias, problemas y capacidad en los enlaces propios 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 de la parte superior del rack. Ese límite es exactamente donde muchas incidencias se vuelven dolorosas. Una carga de trabajo puede estar en buen estado dentro de Cloud Temple, pero un sitio del cliente aún puede fallar a través de un enlace MPLS empresarial, un circuito de acceso de operador, un mal cambio de IPsec, un firewall local, un error de DNS o un límite de capacidad en el lado del cliente.
La evidencia de enrutamiento público respalda la idea de que la empresa opera una red real. RIPE RDAP paraAS33930nombra 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. Elresumen 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 sólido 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 una visibilidad RIS casi completa en la instantánea comprobada. La vista de consistencia de enrutamiento de RIPEstat mostró los prefijos AS33930 anunciados presentes tanto en fuentes BGP como de política de rutas de RIPE, sin lista de prefijos inconsistentes en la salida comprobada. La validación RPKI devolvió “válido” para los ocho pares prefijo-origen AS33930 comprobados. Esos hechos no le dicen a un cliente cuán redundante es un servicio en particular, pero sí muestran que la capa de red es visible, mantenida y no meramente un residuo heredado.
La evidencia de tránsito y peering también es útil, aunque debe leerse con cuidado. Los comentarios de RIPE RDAP para AS33930 mencionan solicitudes de peering, detalles de intercambio de France-IX y Equinix Paris. Lapágina de red de Cloud Templeen PeeringDB enumera la red como Cloud Temple, con el nombre anterior (alias) de Cloud Temple, Intrinsec, una política de peering 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 Paris y Equinix Paris IX a 10 Gbit/s, mientras que su vista de instalaciones enumera Telehouse Paris 2, Telehouse Paris 3, Equinix PA6, Digital Realty Paris PAR7 y DATA4 Paris Marcoussis - PAR1 como instalaciones asociadas al perfil de red. Esto corrobora la interconexión en el mercado de París, pero sigue siendo un perfil de peering público, no un mapa vinculante de la ubicación de las cargas de trabajo del cliente.
La página de estado pública añade 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 ofrece a los clientes un lugar público para observar incidencias y mantenimiento. No responde por sí sola a la pregunta más profunda: ¿cuál de esas zonas de disponibilidad, servicios y componentes utiliza realmente este cliente, y la propia aplicación del cliente sobrevive si uno de ellos se degrada?
Las rutas de fallo se vuelven más claras cuando la línea de productos se lee como un solo sistema. Un fallo de rack o de instalación afecta a la computación, el almacenamiento, la red y el alojamiento de manera diferente según la ubicación. Un fallo de origen o de ruta afecta a los servicios orientados a Internet, los prefijos del cliente, el acceso VPN y la visibilidad del soporte de manera diferente según el diseño BGP. Un fallo en el stock de hardware importa para bare metal, blades GPU, expansión de almacenamiento, appliances de firewall y hosts de reemplazo.
Un fallo de soporte importa de manera diferente según los niveles Standard, Premium y Company. Un fallo de facturación o de pedido puede retrasar el aprovisionamiento o la expansión. Un fallo de migración puede dejar varadas las cargas de trabajo incluso cuando la plataforma está en buen estado. 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 enumera los soportes 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, diferente acceso a Technical Account Manager, objetivos de respuesta P1 de 2 horas, 30 minutos y 15 minutos, y monitoreo e intervención 24/7 para incidencias de nube. También dice que los ingenieros están disponibles 24/7 para incidencias de nube, mientras que las solicitudes de soporte tienen canales en horario comercial, con soporte basado en Francia en francés e inglés. La diferencia importa. Una incidencia de producción de la 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 para una tarea no catalogada.
La página de soporte también remite a la matriz de responsabilidad para incidencias con impacto en producción de las 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 del 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á en buen estado pero el circuito del 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 de pago deciden la velocidad, el canal y la responsabilidad.
Los documentos de SLA publicados hacen el mismo punto con números. ElSLA de VM Instancesdefine un compromiso de disponibilidad mensual del 99,95 por ciento 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 el SO invitado, el software del cliente, la configuración de red del cliente, los fallos de aplicación, el mantenimiento programado, la falta de componentes de gestión, el comportamiento abusivo y la fuerza mayor, y requiere un ticket de soporte dentro de los 30 días naturales 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. Otorga un 99,99 por ciento de disponibilidad mensual para el plano de datos de VPC y un 99,9 por ciento para el plano de control, con cinco minutos como umbral de indisponibilidad contabilizada. Cubre los componentes de VPC gestionados por Cloud Temple, como el enrutador, las redes privadas, la puerta de enlace externa, NAT, DNAT y las IPs flotantes. Excluye las reglas de filtrado del cliente, el direccionamiento incorrecto, los fallos de computación conectada, la conectividad a Internet externa más allá de la demarcación de Cloud Temple, el mantenimiento programado, el comportamiento abusivo y la fuerza mayor. Esas exclusiones no son fallos en el documento; son la forma en que se traza el límite operativo real.
El almacenamiento de objetos tiene un perfil de salida y recuperación diferente. La página pública del producto dice que los clientes pueden recuperar objetos a través de 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, el acceso al servicio, los registros, el monitoreo, las incidencias, los problemas, la capacidad y los 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, las copias de seguridad de los datos, las pruebas de restauración periódicas, los planes de continuidad de la aplicación y la 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 verdadero costo. 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: las imágenes de servidor, los volúmenes de almacenamiento, los buckets de objetos, las reglas de firewall, los derechos de acceso, el enrutamiento, las claves, el DNS, el monitoreo, los acuerdos de soporte y las ventanas de retroceso tienen que 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 en la calidad del servicio durante la transferencia, mientras que Cloud Temple se encarga de desmantelar las configuraciones y el borrado seguro después de la finalización del contrato.
La facturación y los pedidos no son cuestiones secundarias. La página de soporte dice que la facturación mínima del soporte comienza cuando se aprovisionan los recursos. La documentación de red dice 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 los servicios de alojamiento dedicado o de manos-a-la-obra pueden tener términos de 12 o 36 meses según el elemento.
El precio del almacenamiento de objetos está orientado al uso, mientras que el bare metal y el alojamiento están vinculados a unidades físicas. Esta mezcla afecta a la resiliencia. En un apuro, un cliente puede descubrir que la acción de emergencia no es solo un comando técnico; puede ser un nuevo pedido, una solicitud de soporte, una cotización de circuito, una entrega dependiente del stock o una modificación del contrato.
Los canales de contratación añaden otra capa operativa. Las páginas de IaaS y Bare Metal de Cloud Temple dirigen a los compradores del sector público y de la salud hacia rutas de compra pública como UGAP y CAIH. Eso es importante porque puede facilitar la adopción del proveedor para organizaciones que no pueden comprar infraestructura mediante negociación ad hoc. También significa que la planificación de la resiliencia puede estar condicionada por los términos del marco, las entradas de catálogo preaprobadas, los formularios de pedido, los compromisos mínimos y los plazos de la contratación pública.
Un comprador público puede ser capaz de pedir un servicio cualificado de manera más limpia, pero aún necesita saber si una expansión de capacidad posterior, un circuito urgente, un cambio a soporte premium o una solicitud de asistencia para la migración se ajusta a la misma ruta de compra.
Esta es una de las razones por las que la economía de la capacidad alojada no debería reducirse a un precio unitario mensual. Un cliente que traslada su propia sala de servidores a TEMPLE Cloud Temple SAS está desplazando el costo de capital, la carga de personal y el riesgo de las instalaciones a un proveedor con infraestructura especializada. Eso puede ser racional, especialmente para clientes regulados que no pueden construir fácilmente controles de nivel SecNumCloud por sí solos.
Pero el cliente también está aceptando una nueva estructura de costos: ancho de banda reservado, porcentajes de nivel de soporte, consumo de almacenamiento, direcciones IP, circuitos privados, tiempo de manos-a-la-obra, asistencia profesional, términos de alojamiento físico y ancho de banda de salida. La factura de la nube no es solo computación y almacenamiento. También es el precio de las decisiones tomadas antes de un fallo.
La afirmación de no tener tarifas de salida en el almacenamiento de objetos es un buen ejemplo de un término favorable para el comprador cuyo significado operativo depende del contexto. Si un cliente puede recuperar todos los objetos a través de acceso compatible con S3 sin cargos de salida, la barrera comercial para salir es menor 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 nomenclatura de objetos y conciencia de la política de retención.
Si Entidad Lock está habilitado, el cliente también tiene que respetar sus propias elecciones 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ública debe usarse de la misma manera práctica. Es valiosa porque nombra componentes que los clientes pueden monitorear durante una incidencia, 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 mapea 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, tenant, puerta de enlace VPC o blade bare-metal está afectado? ¿El propio puente de incidencias del cliente incluye a alguien que entienda esas etiquetas?
¿Ha prometido el nivel de soporte un canal de comunicación para la gravedad en cuestión? La visibilidad ayuda solo cuando está conectada al runbook y a 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 de 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 elecciones 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 una incidencia grave, el sitio web del proveedor, la consola, la página de estado, la ruta del correo, el soporte telefónico y el tenant del cliente pueden fallar o sobrevivir en diferentes combinaciones. Los clientes deben mantener más de un canal de escalado y no deben 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 pública de soberanía de Cloud Temple es principalmente francesa y europea, con lenguaje de producto FR1, oficinas francesas, equipos de soporte franceses, cualificación ANSSI, relevancia HDS, peering en París y señales del mercado de instalaciones francés. Para un cliente fuera de Francia, la dependencia aún puede ser 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 frente a 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, la agrupación de aplicaciones, los derechos del tenant, 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 con el cliente. Esa claridad es una buena noticia.
Ofrece 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 del certificado e ignore la tabla de responsabilidades.
La pregunta de contratación más limpia es, por lo tanto, una tabla de demarcaciones, no una pregunta de confianza de sí o no. Para cada carga de trabajo, el cliente debe anotar el servicio de computación, el servicio de almacenamiento, el servicio de red, las zonas de disponibilidad, el destino de la copia de seguridad, el propietario de la restauración, el nivel de soporte, el circuito del cliente, el prefijo público, el administrador de identidad, el propietario de la clave, el propietario de la facturación, el contacto de mantenimiento y el 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 las á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 Housingde Cloud Temple describe el 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 servidor con alimentación C19, racks dedicados con 3 kW a través de dos cadenas eléctricas de 16A, incrementos adicionales de 2 kW, una masa máxima de equipo de 1.000 kg, PDUs monitoreadas, puertos de red de cobre o fibra, conectividad de sala de encuentro y servicios de manos-a-la-obra. También dice que los racks dedicados están en espacio de alojamiento compartido fuera del área SecNumCloud. Esa última distinción es importante: “housing de Cloud Temple” y “IaaS Secure Temple cualificado” no son frases intercambiables.
Para algunos clientes, el housing es un puente. Un appliance heredado, un sistema adyacente a un mainframe, una caja de almacenamiento propietario, un HSM, un firewall o un servidor de preparación para la migración pueden necesitar estar cerca de los recursos de la nube mientras se mueve una carga de trabajo regulada. 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ánicas de recuperación, el diseño puede volverse engañoso. Los documentos de housing son útiles precisamente porque obligan al comprador a hablar sobre unidades de rack, vatios, puertos, rutas ópticas, respuesta de manos-a-la-obra y escalado de soporte.
El argumento de la soberanía de datos es, por lo tanto, más fuerte cuando se mantiene concreto. Las páginas de Cloud Temple hacen una afirmación creíble de soberanía 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 tienen su base en Francia y operan desde Francia. La página de cumplimiento enumera fechas de validez oficiales y alcances. Pero la soberanía no es solo una etiqueta nacional.
También es la ubicación, el acceso al soporte, la evidencia de subcontratistas, la custodia de claves, la comunicación de incidencias, la ruta de exportación, la prueba de eliminación y la divulgación de riesgos residuales. 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 da una lección similar. AS33930 tiene prefijos visibles, autorización de origen de ruta válida en la vista comprobada, participación en intercambios y listados de instalaciones. Eso es mejor que ver solo una fachada de revendedor en la red de otra persona. Significa que Cloud Temple tiene superficie de enrutamiento directo y una historia de interconexión pública.
Aún así, la evidencia de enrutamiento no revela qué tenant de cliente utiliza 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 con qué rapidez 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 la propia 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 un inconveniente. Puede retrasar la atención, congelar los informes regulados, detener los sistemas adyacentes a la planta, bloquear los servicios a los ciudadanos, interrumpir el acceso a la identidad o impedir que un editor de software sirva a sus clientes posteriores.
La pregunta correcta de diligencia debida no es “¿Puede Cloud Temple alojar una VM?” Claramente puede. La pregunta es “¿El diseño del servicio elegido coincide con el daño operativo si esta aplicación se detiene?”
Para una agencia pública, la respuesta puede implicar el alcance de SecNumCloud, la segregación de tenants, el nivel de soporte, la comunicación de incidencias y la reversibilidad. Para un proveedor de salud, puede implicar el alcance de HDS, las pruebas de restauración de copias de seguridad, el acceso al soporte, la retención de entidad-lock y si la evidencia de subcontratistas cubre cada ruta. Para un equipo financiero, puede implicar evidencia de auditoría, diversidad de rutas, archivo inmutable, cifrado, custodia de claves y planificación de salida al estilo DORA.
Para una empresa industrial, puede implicar enlaces de baja latencia, proximidad de las instalaciones, diseño de red troncal privada, ventanas de mantenimiento y respaldo operativo local. Una sola etiqueta de producto no puede responder a esas preguntas. El cliente tiene que convertir la evidencia pública en una revisión de diseño específica para la carga de trabajo.
La ruta de fallo que más vale la pena probar es la compuesta: una incidencia que cruza la infraestructura del proveedor, la configuración del cliente y el proceso de soporte. Imagine un cliente que ejecuta IaaS VMware en dos zonas de disponibilidad con un par de firewalls, copias de seguridad en 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, la replicación del almacenamiento, el estado del firewall, el comportamiento de DNS, la convergencia de rutas, la disponibilidad de S3 y un ticket que se clasifique correctamente.
Si el propio circuito del 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 copias de seguridad del cliente fue mal diseñada, el almacenamiento de objetos en tres zonas puede conservar los datos incorrectos. Es por eso que la responsabilidad compartida debe ejercerse antes de la interrupción, no solo citarse durante la misma.
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 desplaza la planificación práctica al cliente. ¿Quién recibe los avisos de mantenimiento? ¿Se enrutan al equipo propietario de 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 copias 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. La documentación revela clases de blades, límites de almacenamiento, puertos de red y unidades de alojamiento físico, pero no publica el recuento de blades de repuesto, repuestos de controladores de almacenamiento, inventario de GPU, plazos de entrega por clase o la 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: muestre 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 un fallo 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 un pedido o dependiente de una cotización.
Lo mismo se aplica a la prueba de restauración. La plataforma cualificada de Cloud Temple, la redundancia de S3 y la arquitectura de copias 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 copias de seguridad y las pruebas periódicas de restauración en el cliente, a veces con consulta a Cloud Temple. Eso debería cambiar el lenguaje de contratación.
Los compradores deben preguntar no solo “¿Está incluida la copia de seguridad?” sino “¿Quién redacta el plan de restauración, quién ejecuta la prueba, quién registra el resultado, qué sucede si la restauración no alcanza 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.
La calificación de la evidencia para TEMPLE Cloud Temple SAS debería ser, por lo tanto, mejor que la cautela de la asignación de huella escasa, pero aún no absoluta. El registro público es amplio, actual y específico: las páginas oficiales identifican el posicionamiento en sectores regulados, oficinas francesas, alcance de 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 del housing, enrutamiento de AS33930, validez de RPKI, puntos de intercambio y componentes de estado público. Esa es una huella sustancial.
La evidencia faltante es más limitada pero decisiva: la ubicación específica del cliente, la asignación exacta del operador de la instalación para cada carga de trabajo, el inventario de repuestos, el historial de rendimiento del soporte, los resultados de las pruebas de restauración, la concentración de clientes, las comunicaciones de mantenimiento y la ejecución real de la salida.
Para los compradores, la conclusión práctica es tratar a TEMPLE Cloud Temple SAS como una dependencia creíble de nube soberana que aún necesita pruebas a nivel de carga de trabajo. Pida un diagrama que nombre la región, las zonas de disponibilidad, los hosts o clases de computación, las clases de almacenamiento, los buckets S3, las políticas de copias de seguridad, las puertas de enlace VPC, las salidas a Internet, los circuitos del cliente, los contactos de soporte y las rutas de escalado.
Pregunte qué compromisos están cubiertos por el alcance de SecNumCloud, cuáles por HDS, cuáles son housing ordinario, cuáles están en vista previa y cuáles son propiedad del cliente. Pregunte cómo se reclaman los créditos de servicio y qué no cubren. Pregunte cómo sale una carga de trabajo, cómo se borran los datos, cómo se gestionan las claves y cómo se comporta el soporte fuera del horario comercial.
Para los lectores de infraestructura, la lección es más amplia. Un proveedor de nube soberana puede ser tanto genuinamente operativo como dependiente 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 tenant particular, una clase de blade, un nivel de almacenamiento, una ruta de red, un nivel de ticket, un calendario de mantenimiento y un acuerdo de salida. Esas son las piezas que decidirán si la capacidad alojada sobrevive a un evento de rack, un evento ascendente, una escasez de hardware, una cola de soporte, una fricción de facturación, una presión de migración o un fallo del contrato del proveedor.