TEMPLE Cloud Temple SAS vend de la capacité hébergée qui dépend encore des racks, du transit et des fenêtres de réparation

Résumé

• TEMPLE Cloud Temple SAS correspond à une entreprise française de cloud souverain visible: les pages publiques de Cloud Temple décrivent l'IaaS qualifié SecNumCloud, l'IaaS VMware, l'IaaS OpenSource, le stockage objet, le bare metal, le VPC, le backbone privé, l'hébergement et les services de support pour les secteurs réglementés.
• Les pages officielles de conformité indiquent que le périmètre IaaS Secure Temple couvre l'IaaS VMware, l'IaaS OpenSource, le stockage objet S3, le chiffrement HSM-KMS et le Bare Metal, avec une validité SecNumCloud v3.2 indiquée jusqu'au 30 mai 2028; la même page liste PaaS OpenShift séparément.
• Le routage public est réel et actuel: RIPEstat a montré AS33930 annoncé le 12 juillet 2026, avec six préfixes IPv4 et deux préfixes IPv6, des résultats d'origine valide RPKI complets dans la vue vérifiée, et une large visibilité RIS.
• Le risque n'est pas que le fournisseur manque de preuves d'exploitation publiques; le risque est que la certification, la visibilité AS et les étiquettes de produits ne disent toujours pas exactement quel rack, zone de disponibilité, chemin de récupération, niveau de support ou processus de sortie protège une charge de travail spécifique.
• Les acheteurs doivent traiter les preuves publiques de Cloud Temple comme un point de départ solide pour la due diligence, puis vérifier le placement des charges de travail, l'escalade du support, la disponibilité du matériel, les tests de restauration, la responsabilité du circuit client, les effets de facturation et les limites de portabilité des données avant de déplacer des systèmes critiques.

TEMPLE Cloud Temple SAS est le genre d'entreprise de cloud qui peut sembler simple sur une carte d'annuaire et compliquée dès qu'un client demande ce qui doit réellement fonctionner. Le nom fait référence à un fournisseur de cloud souverain avec des bureaux français visibles, des revendications de conformité, un système autonome routé, une offre de support public, une page de statut officielle et des documents techniques décrivant le calcul, le stockage, le réseau, l'hébergement physique et les limites de responsabilité. Cela suffit pour rejeter une lecture faible du statut opérationnel.

Ce n'est pas suffisant pour traiter chaque revendication de disponibilité ou de souveraineté comme auto-exécutoire. L'entreprise vend de la capacité hébergée, mais la capacité dépend encore de l'espace physique réel, de l'alimentation, du câblage, de la sélection des routes, des plateformes des fournisseurs, de la main-d'œuvre de support, de la configuration du client, des tests de restauration et des termes contractuels.

La page« Qui sommes-nous? »de l'entreprise positionne Cloud Temple autour des secteurs sensibles, nommant l'industrie, la finance, la santé et le secteur public comme les marchés où sa promesse est censée compter. Sapage des implantationsliste des bureaux à Paris / La Défense, Lyon, Tours, Caen et Nantes, avec l'adresse Paris / La Défense au Le Belvedere - SPACES, 1-7 Cours Valmy, 92800 Puteaux. C'est une preuve d'identité utile, mais le plan des bureaux n'est pas le plan de l'infrastructure. Un acheteur ne doit pas confondre une adresse de bureau avec le site où s'exécute une machine virtuelle, un blade bare metal, un bucket S3, une passerelle VPC ou un rack physique.

La preuve publique la plus solide est l'empreinte de conformité et de produits. Lapage des procédures de conformitéde Cloud Temple indique que l'entreprise dispose de la certification ISO 27001 pour l'infrastructure depuis 2018 et pour les services gérés depuis 2022, de la certification HDS pour les activités de données de santé, de la qualification SecNumCloud v3.2, du reporting ISAE 3402 et d'autres entrées de conformité européennes. La même page donne la déclaration de périmètre la plus concrète: « IaaS Secure Temple » est listé sous SecNumCloud v3.2 avec une validité jusqu'au 30 mai 2028, et la note de bas de page indique que ce périmètre inclut l'IaaS VMware, l'IaaS OpenSource, le stockage objet S3, le chiffrement HSM-KMS et le Bare Metal. Cela ne rend pas chaque produit identique, mais cela place les principaux produits d'infrastructure à l'intérieur d'un périmètre de qualification publique.

Lapage sur l'approche SecNumCloudde Cloud Temple présente le pitch stratégique: le cloud doit protéger la confiance des entreprises et des organismes publics, et la conception des produits doit s'aligner sur des normes de sécurité européennes exigeantes. La page indique également que la qualification signifie la conformité à plus de 700 exigences et bonnes pratiques de l'ANSSI couvrant les domaines techniques, physiques, contractuels et opérationnels. Cette déclaration compte pour le risque d'infrastructure car elle est explicitement plus large que les contrôles cyber. Il s'agit de la manière dont un fournisseur est géré. Pourtant, même une qualification large n'est pas un document d'architecture par client. Elle ne dit pas à un hôpital, un assureur, une agence publique ou un client industriel si son propre locataire dispose de deux hôtes de calcul, quelle zone de disponibilité contient la copie passive, ou si son changement de pare-feu est couvert par le niveau de support en vigueur.

La gamme de produits montre pourquoi ces détails comptent. L'offre de calcul de Cloud Temple couvre plusieurs modes de consommation. Le site public décritl'IaaS OpenSourcepour une infrastructure virtualisée sur une plateforme souveraine,l'IaaS VMwarepour les environnements VMware dans un environnement cloud qualifié,le Bare Metalpour des serveurs physiques dédiés, et des instances VM en aperçu pour des machines virtuelles de style cloud plus partagées. Les documents publics de l'entreprise pour l'IaaS OpenSource décrivent le calcul Cisco UCS, le stockage par blocs IBM Spectrum Virtualize et IBM FlashSystem, le stockage objet Dell ECS, le réseau Juniper, des blades de calcul et des volumes de stockage dédiés, une tarification à la consommation mensuelle, des concepts de région et de zone de disponibilité, des sauvegardes, des options de réplication et une exploitation par API ou Terraform. Ce n'est pas un catalogue d'hébergement léger. C'est une pile physique et opérationnelle.

La pile a une implication spécifique: la capacité installée et la capacité utilisable ne sont pas la même chose. Une page peut montrer des classes de blades, des classes de stockage et des chiffres de connectivité, tandis qu'un client doit encore demander si la classe exacte est disponible dans la région souhaitée, si l'ajout d'un autre hôte nécessite un stock matériel, si un blade GPU a un délai de livraison, si la deuxième zone de disponibilité a des performances de stockage correspondantes, et si la licence du client permet le basculement en direct.

Les concepts de l'IaaS OpenSource de Cloud Temple listent des classes de blades allant de ECO à PERFORMANCE 4, avec mémoire, nombre de cœurs, connectivité 10 Gbit/s ou 25 Gbit/s et, pour la classe supérieure, des GPU NVIDIA L40S à compter du 1er mai 2024. C'est un détail utile. Cela indique également à un acheteur que la capacité n'est pas abstraite: elle est fournie par des familles de matériel spécifiques avec un inventaire fini.

Le Bare Metal renforce le point. Ladocumentation Bare Metaldécrit des serveurs physiques dédiés connectés à un stockage par blocs distribué, des blades Cisco UCS, un stockage IBM Spectrum Virtualize, un placement en zone de disponibilité, un accès console de type KVM, un mappage ISO, des opérations d'alimentation, un tagging VLAN et deux interfaces réseau dont la vitesse dépend de la classe de blade. Le produit est attractif précisément parce qu'il donne aux clients plus de contrôle sur l'environnement d'exploitation. Mais ce contrôle repousse une partie du risque vers le client. Si un client installe son propre hyperviseur ou système d'exploitation, Cloud Temple peut fournir le blade, le stockage et l'accès à la plateforme, mais le client possède toujours les choix qui transforment le matériel en une application résiliente.

Le côté VMware présente une tension similaire. Les documents de l'IaaS VMware de Cloud Temple décrivent des ressources dédiées en blade, stockage et réseau, la compatibilité vSphere, des VLAN L2, la propagation inter-zone de disponibilité, une latence intra-AZ inférieure à 3 ms et inter-AZ inférieure à 5 ms dans la vue documentée, et une haute disponibilité qui ne fonctionne que si un cluster a la conception d'hôte requise. Les documents publics notent que si une zone de disponibilité ne contient qu'un seul hyperviseur, le redémarrage automatique sur un autre hyperviseur n'est pas possible.

C'est le genre de phrase qui transforme une promesse cloud en réalité d'ingénierie. Un client peut acheter une infrastructure auprès d'un fournisseur qualifié et toujours construire un environnement fragile à hôte unique s'il choisit la mauvaise forme ou reporte le deuxième nœud.

Le stockage nécessite également de la précision. Lapage de stockage objetpublique de Cloud Temple indique que le service est basé sur Dell Elastic Cloud Storage, offre une compatibilité S3 élevée, est qualifié SecNumCloud, certifié HDS et ISO 27001, se réplique automatiquement sur trois zones de disponibilité, utilise le codage d'effacement EC 12+4, supporte TLS 1.2/1.3 ainsi que des options de chiffrement côté serveur, annonce une disponibilité de 99,99 % et une durabilité de 99,999999999 %, et ne facture pas de frais de sortie. Ce sont des affirmations sérieuses pour les acheteurs de stockage de sauvegarde, d'archivage et d'application. Elles doivent encore être mappées sur le devoir du client de définir le cycle de vie, l'immuabilité, la clé et la politique de restauration. Le stockage objet sur trois zones aide à la durabilité de la plateforme; il ne prouve pas en soi qu'un client peut restaurer la bonne version d'objet après un ransomware, une suppression erronée, une mauvaise conception de la rétention ou une compromission de clé d'accès.

La répartition des responsabilités n'est pas cachée. Lapage de responsabilité partagéede Cloud Temple renvoie les lecteurs aux matrices RACI pour l'IaaS, les instances VM, le stockage objet, le réseau et d'autres services. Lamatrice de responsabilité IaaSindique que Cloud Temple est responsable et redevable de la mise en œuvre des centres de données physiques, de l'infrastructure de calcul, de l'infrastructure de stockage, de la connectivité backbone, des licences logicielles essentielles de la plateforme, de la configuration de base du locataire et de la configuration initiale de la sauvegarde. Elle indique également que le client est responsable et redevable de la définition de l'architecture globale, du nombre de locataires, du nombre de zones de disponibilité, de la stratégie de continuité et de reprise, du dimensionnement du calcul, du stockage, du réseau et de la sauvegarde, de la création et de la maintenance des machines virtuelles, de l'association de chaque VM à des plans de sauvegarde et de reprise cohérents, et de la réalisation de tests périodiques de sauvegarde et de restauration.

Cette division est probablement le fait le plus important de tout le dossier. Elle signifie que l'entreprise peut être un fournisseur d'infrastructure qualifié tout en laissant des décisions de conception critiques au client. Si le client sous-dimensionne un locataire, omet les tests de sauvegarde, ne répartit pas les charges de travail entre les zones, conserve une règle de pare-feu cassée, perd l'accès administrateur ou maintient un seul nœud d'application au sein d'une plateforme par ailleurs résiliente, la panne ne se comportera pas comme une simple panne de fournisseur.

Ce sera une panne d'architecture conjointe avec seulement certaines couches couvertes par les engagements du fournisseur. La question de risque de l'article n'est donc pas « TEMPLE Cloud Temple SAS est-elle une véritable entreprise de cloud? » La réponse est oui. La question est « Quelle partie de ce système client se trouve à l'intérieur du périmètre responsable de Cloud Temple, et quelle partie relève toujours de la propre conception du client? »

La même division apparaît dans le réseau. Ladocumentation du backbone privéde Cloud Temple indique que le produit fournit des réseaux privés L2 VPLS entre les zones de disponibilité, des composants d'accès Internet privé, l'adressage IP, une protection anti-DDoS native, des ports pour la connectivité externe, des circuits 1G/10G et des liaisons privées sur deux chemins optiques diversifiés pour les produits de circuit dédié. Lapage des concepts Internetindique que Cloud Temple exploite son propre AS, propose deux chemins de transit et deux points d'échange parisiens, supporte BGP4, fournit des IPv4 publiques à l'unité et des préfixes IPv6, réserve la bande passante Internet par incréments de 100 Mbit/s et facture sur la base du 95e percentile plutôt que du volume sortant. Ce sont des faits de conception réseau matériels, pas des affirmations décoratives.

Mais encore une fois, la limite compte. Lamatrice de responsabilité réseauindique que le client est responsable et redevable de souscrire à la connectivité de l'opérateur pour accéder à un centre de données physique de Cloud Temple, et de gérer les incidents, les problèmes et la capacité sur les propres liaisons de l'opérateur du client. Cloud Temple prend la responsabilité du backbone, des points de collecte et des points d'interconnexion du centre de données, et pour l'hébergement physique, la responsabilité commence à l'équipement en haut du rack. Cette limite est exactement l'endroit où de nombreux incidents deviennent douloureux. Une charge de travail peut être saine à l'intérieur de Cloud Temple, mais un site client peut encore échouer à cause d'une liaison MPLS d'entreprise, d'un circuit d'accès opérateur, d'une mauvaise modification IPsec, d'un pare-feu local, d'une erreur DNS ou d'une limite de capacité côté client.

Les preuves de routage public soutiennent l'idée que l'entreprise exploite un réseau réel. Le RDAP de RIPE pourAS33930nomme CLOUD-TEMPLE et liste Cloud Temple SAS comme entité déclarante, avec l'adresse de l'organisation au Le Belvedere, 1 Cours Valmy, 92800 Puteaux. L'aperçu ASde RIPEstat a identifié le titulaire comme CLOUD-TEMPLE Cloud Temple SAS et a montré l'AS comme annoncé au moment de la requête du 12 juillet 2026. Lavue des préfixes annoncésde RIPEstat a montré huit annonces actives dans la fenêtre se terminant le 12 juillet 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 et 2a02:668:9000::/36.

Ce dossier de routage est plus solide qu'une empreinte purement marketing. Lavue du statut de routagede RIPEstat a montré six préfixes IPv4, deux préfixes IPv6, 6 656 adresses IPv4 annoncées, 8 192 IPv6 /48, 54 voisins observés et une visibilité RIS quasi complète dans l'instantané vérifié. La vue de cohérence de routage de RIPEstat a montré les préfixes AS33930 annoncés présents à la fois dans les sources BGP et de politique de route RIPE, sans liste de préfixes incohérents dans la sortie vérifiée. La validation RPKI a retourné « valide » pour les huit paires préfixe-origine AS33930 vérifiées. Ces faits ne disent pas à un client à quel point un service particulier est redondant, mais ils montrent que la couche réseau est visible, maintenue et pas simplement un résidu hérité.

Les preuves de transit et de peering sont également utiles, bien qu'elles doivent être lues avec précaution. Les remarques RDAP de RIPE pour AS33930 mentionnent les demandes de peering, les détails des points d'échange France-IX et Equinix Paris. Lapage réseau Cloud Templede PeeringDB liste le réseau comme Cloud Temple, avec l'ancien nom aka d'Intrinsec, une politique de peering général ouverte et une date de mise à jour en avril 2025. La vue d'échange public de PeeringDB montre des entrées France-IX Paris et Equinix Paris IX à 10 Gbit/s, tandis que sa vue des installations liste Telehouse Paris 2, Telehouse Paris 3, Equinix PA6, Digital Realty Paris PAR7 et DATA4 Paris Marcoussis - PAR1 comme installations associées au profil réseau. Cela corrobore l'interconnexion sur le marché parisien, mais c'est toujours un profil de peering public, pas une carte contraignante du placement des charges de travail clients.

La page de statut public ajoute un autre angle. Lapage de statutde Cloud Temple expose des composants sous FR1, incluant des étiquettes AZ telles que PA6, PAR7, TH3, PAR7S, TH3S et AZ07, ainsi que des catégories pour OpenIaaS, Object Storage, PaaS OpenShift, Bare Metal, VPC, services de périphérie et interfaces publiques. Une page de statut est précieuse car elle donne aux clients un endroit public pour observer les incidents et les maintenances. Elle ne répond pas à elle seule à la question plus profonde: laquelle de ces zones de disponibilité, services et composants ce client utilise-t-il réellement, et l'application du client survit-elle si l'un d'eux est dégradé?

Les chemins de défaillance deviennent plus clairs lorsque la gamme de produits est lue comme un seul système. Une panne de rack ou d'installation affecte le calcul, le stockage, le réseau et l'hébergement différemment selon le placement. Une panne en amont ou de route affecte les services accessibles sur Internet, les préfixes clients, l'accès VPN et la visibilité du support différemment selon la conception BGP. Une panne de stock matériel affecte le bare metal, les blades GPU, l'extension de stockage, les appliances pare-feu et les hôtes de remplacement. Une panne de support affecte différemment les niveaux Standard, Premium et Company.

Une panne de facturation ou de commande peut retarder le provisionnement ou l'extension. Une panne de migration peut bloquer les charges de travail même lorsque la plateforme est saine. Aucun de ces risques ne signifie que le fournisseur est faible. Ils signifient que le contrat cloud doit être lu comme une infrastructure, pas comme une abstraction magique.

Les conditions de support font partie de cette infrastructure. Lapage des niveaux de supportde Cloud Temple liste les supports Standard, Premium et Company avec des taux mensuels de 5, 7 et 10 % de la facturation du service, des niveaux de facturation mensuelle minimale, un accès différent au Technical Account Manager, des objectifs de réponse P1 de 2 heures, 30 minutes et 15 minutes, et une surveillance et intervention 24/7 pour les incidents cloud. Elle indique également que les ingénieurs sont disponibles 24/7 pour les incidents cloud, tandis que les demandes de support ont des canaux aux heures ouvrables, avec un support basé en France en français et en anglais. La différence compte. Un incident de production pour lequel Cloud Temple est responsable n'est pas la même chose qu'une demande d'assistance générale, une modification de configuration côté client, une question de planification de migration ou une demande de tâche hors catalogue.

La page de support renvoie également à la matrice de responsabilité pour les incidents ayant un impact sur la production pour lesquels Cloud Temple est responsable. Cette qualification n'est pas une petite ligne en pratique. Si la VM d'un client est opérationnelle au niveau de l'hyperviseur mais que l'application est en panne parce que le système d'exploitation invité est défectueux, le chemin de support change. Si le VPC d'un client est sain mais que le circuit opérateur sur site est en panne, le chemin de support change. Si une sauvegarde existe mais que le client n'a jamais effectué de tests de restauration, le chemin de support change.

Un bon support peut aider dans tous ces cas, mais la limite contractuelle et le niveau payant décident de la vitesse, du canal et de la responsabilité.

Les documents SLA publiés font le même point avec des chiffres. LeSLA des instances VMdéfinit un engagement de disponibilité mensuelle de 99,95 % pour chaque instance VM active facturée, équivalent à 21,9 minutes d'indisponibilité mensuelle autorisée. Mais il mesure l'indisponibilité au niveau de l'infrastructure Cloud Temple sous-jacente, exclut le système d'exploitation invité, les logiciels clients, la configuration réseau du client, les pannes d'application, les maintenances planifiées, les composants de gestion manquants, les comportements abusifs et la force majeure, et nécessite un ticket de support dans les 30 jours calendaires pour réclamer des crédits de service. C'est une structure cloud normale. C'est aussi un avertissement: le SLA n'est pas une garantie de disponibilité de l'application.

LeSLA VPCest tout aussi spécifique. Il donne une disponibilité mensuelle de 99,99 % pour le plan de données VPC et de 99,9 % pour le plan de contrôle, avec cinq minutes comme seuil d'indisponibilité comptabilisé. Il couvre les composants VPC gérés par Cloud Temple tels que le routeur, les réseaux privés, la passerelle externe, le NAT, le DNAT et les IP flottantes. Il exclut les règles de filtrage client, le mauvais adressage, les défaillances de calcul connecté, la connectivité Internet externe au-delà de la démarcation de Cloud Temple, les maintenances planifiées, les comportements abusifs et la force majeure. Ces exclusions ne sont pas des échecs du document; elles sont la manière dont la limite opérationnelle réelle est tracée.

Le stockage objet a un profil de sortie et de reprise différent. La page produit publique indique que les clients peuvent récupérer les objets via un accès compatible S3 et que Cloud Temple ne facture pas de frais de sortie. Lamatrice de responsabilité S3indique que Cloud Temple est responsable de la maintenance et de la sécurisation de la plateforme S3, de l'accès au service, des journaux, de la surveillance, des incidents, des problèmes, de la capacité et des modifications de service. Elle indique que le client est responsable de la création d'objets, de la création de clés d'accès, de la gestion du cycle de vie des objets, de la gestion des droits sur les objets, de la gestion de la sécurité logique, des sauvegardes des données, des tests de restauration périodiques, des plans de continuité applicative et de l'exécution de la réversibilité. Cela signifie que l'absence de frais de sortie est utile, mais que la portabilité nécessite toujours une planification client, des identifiants, de la bande passante, une logique de rétention et une destination testée.

La migration est l'endroit où la capacité hébergée révèle souvent son coût réel. Les produits de Cloud Temple sont explicitement compatibles avec des écosystèmes familiers: les environnements VMware, l'accès S3, l'IaaS OpenSource de type OpenStack, l'exploitation par API, le provisionnement par Terraform et le BGP pour les préfixes clients. Ce sont des signaux d'interopérabilité. Ils réduisent le verrouillage par rapport à une pile propriétaire fermée.

Pourtant, une sortie de la plateforme reste un projet: les images de serveur, les volumes de stockage, les buckets d'objets, les règles de pare-feu, les droits d'accès, le routage, les clés, le DNS, la surveillance, les accords de support et les fenêtres de retour arrière doivent tous être alignés.

Le RACI IaaS indique que le client est responsable de la planification de la réversibilité, du choix de l'infrastructure cible, de l'exécution des opérations de transition et de la gestion des effets sur la qualité de service pendant le transfert, tandis que Cloud Temple gère le démantèlement des configurations et l'effacement sécurisé après la fin du contrat.

La facturation et la commande ne sont pas des problèmes secondaires. La page de support indique que la facturation minimale du support commence lorsque les ressources sont provisionnées. Les documents réseau indiquent que les adresses IPv4 publiques sont fournies dans la limite du stock disponible, la bande passante Internet est réservée par incréments de 100 Mbit/s, les circuits privés peuvent supporter des engagements de 36 mois, et les services d'hébergement dédié ou de « hands-and-eyes » peuvent avoir des durées de 12 ou 36 mois selon l'élément.

La tarification du stockage objet est basée sur l'utilisation, tandis que le bare metal et l'hébergement sont liés à des unités physiques. Ce mélange affecte la résilience. En cas d'urgence, un client peut découvrir que l'action d'urgence n'est pas seulement une commande technique; elle peut être une nouvelle commande, une demande de support, un devis de circuit, une livraison dépendante du stock ou un avenant contractuel.

Les canaux d'achat ajoutent une autre couche opérationnelle. Les pages IaaS et Bare Metal de Cloud Temple orientent les acheteurs des secteurs public et de la santé vers des voies d'achat public telles que l'UGAP et le CAIH. Cela compte car cela peut faciliter l'adoption du fournisseur pour les organisations qui ne peuvent pas acheter d'infrastructure par négociation ad hoc. Cela signifie également que la planification de la résilience peut être façonnée par les conditions du cadre, les entrées de catalogue pré-approuvées, les bons de commande, les engagements minimaux et les délais d'achat public.

Un acheteur public peut être en mesure de commander un service qualifié plus proprement, mais il doit encore savoir si une extension de capacité ultérieure, un circuit urgent, un changement de support premium ou une demande d'assistance à la migration s'inscrit dans le même chemin d'achat.

C'est l'une des raisons pour lesquelles l'économie de la capacité hébergée ne doit pas être réduite à un prix unitaire mensuel. Un client qui passe de sa propre salle serveur à TEMPLE Cloud Temple SAS transfère le coût en capital, la charge de personnel et le risque d'installation à un fournisseur disposant d'une infrastructure spécialisée. Cela peut être rationnel, en particulier pour les clients réglementés qui ne peuvent pas facilement construire seuls des contrôles de niveau SecNumCloud.

Mais le client accepte également une nouvelle forme de coût: bande passante réservée, pourcentages de niveau de support, consommation de stockage, adresses IP, circuits privés, temps « hands-and-eyes », assistance professionnelle, conditions d'hébergement physique et bande passante de sortie. La facture cloud n'est pas seulement le calcul et le stockage. C'est aussi le prix des choix effectués avant une panne.

La mention de l'absence de frais de sortie sur le stockage objet est un bon exemple de condition favorable à l'acheteur dont le sens opérationnel dépend du contexte. Si un client peut récupérer tous les objets via un accès compatible S3 sans frais de sortie, la barrière commerciale à la sortie est plus basse que dans de nombreux arrangements hyperscale. Mais déplacer plusieurs téraoctets ou pétaoctets consomme toujours du temps, de la bande passante, du contrôle des clés d'accès, de la capacité de destination, de la discipline de nommage des objets et de la conscience de la politique de rétention.

Si Entité Lock est activé, un client doit également respecter ses propres choix d'immuabilité. L'absence de frais de sortie n'efface pas le besoin d'une fenêtre de migration, d'une conception de destination et d'un processus de copie vérifié.

La page de statut public doit être utilisée de la même manière pratique. Elle est précieuse car elle nomme des composants que les clients peuvent surveiller pendant un incident, et elle signale que Cloud Temple a rendu une partie de son état opérationnel visible. Pourtant, un composant de statut n'est utile que si le client sait comment il correspond à son service. Si un client voit un élément pour FR1 Object Storage ou une étiquette de zone de disponibilité spécifique, peut-il dire si son bucket, son locataire, sa passerelle VPC ou son blade bare metal est affecté? Le pont d'incident du client inclut-il quelqu'un qui comprend ces étiquettes?

Le niveau de support a-t-il promis un canal de communication pour la gravité en cours? La visibilité n'aide que lorsqu'elle est connectée au runbook et aux registres de propriété du client.

Il existe également une dépendance silencieuse dans la propre périphérie publique du fournisseur. Une recherche DNS ponctuelle a observé cloud-temple.com sur l'espace d'adressage de Cloud Temple, les serveurs de noms Gandi, la protection de messagerie Microsoft, la console sur une autre adresse Cloud Temple et le nom d'hôte du statut via Atlassian Statuspage et CloudFront. Ce sont des choix normaux, et ils n'affaiblissent pas les preuves de la plateforme centrale. Ils montrent cependant que la communication avec le client peut dépendre de couches au-delà d'AS33930.

En cas d'incident grave, le site web du fournisseur, la console, la page de statut, le chemin de messagerie, le support téléphonique et le locataire client peuvent tomber en panne ou survivre dans différentes combinaisons. Les clients doivent conserver plus d'un canal d'escalade et ne pas attendre une panne pour les tester.

La catégorie globale attribuée à cet article nécessite également une nuance. Les services cloud peuvent être achetés et atteints mondialement, et AS33930 a une visibilité de routage mondiale. Mais l'histoire de souveraineté publique de Cloud Temple est principalement française et européenne, avec un langage produit FR1, des bureaux français, des équipes de support françaises, une qualification ANSSI, une pertinence HDS, un peering parisien et des signaux du marché français des installations. Pour un client hors de France, la dépendance peut encore être attractive si l'objectif est une localité des données française ou européenne.

Cela signifie également que la latence, les circuits d'accès client, les attentes juridiques et les heures de support opérationnel doivent être évalués par rapport à la base d'utilisateurs réelle. Une population d'utilisateurs mondiale servie depuis un cloud souverain français peut nécessiter une mise en cache supplémentaire, une conception d'accès régional ou une tolérance au niveau applicatif.

La souveraineté peut également créer un faux sentiment de complétude si le client la traite comme un substitut à l'architecture. Un fournisseur français qualifié peut réduire l'exposition à certaines préoccupations juridiques, opérationnelles et de sécurité, mais il ne peut pas décider de la classification des données du client, du basculement de route, du clustering applicatif, des droits de locataire, de la rotation des clés, de la fréquence de restauration ou de la priorité de sortie. La documentation publique de Cloud Temple est exceptionnellement claire sur le fait que bon nombre de ces éléments restent avec le client.

Cette clarté est une bonne nouvelle. Elle donne aux acheteurs la chance de rendre la répartition explicite avant la production. Le risque est qu'un acheteur lise le titre du certificat et ignore le tableau de responsabilité.

La question d'achat la plus propre est donc un tableau de démarcations, pas une question de confiance binaire. Pour chaque charge de travail, le client doit noter le service de calcul, le service de stockage, le service réseau, les zones de disponibilité, la cible de sauvegarde, le propriétaire de la restauration, le niveau de support, le circuit client, le préfixe public, l'administrateur d'identité, le propriétaire de la clé, le propriétaire de la facturation, le contact de maintenance et la destination de sortie.

Ensuite, il doit demander à TEMPLE Cloud Temple SAS de confirmer quels éléments sont opérés par le fournisseur, lesquels sont opérés par le client, lesquels sont dans le périmètre SecNumCloud, lesquels sont pertinents HDS, lesquels sont en dehors des zones qualifiées, lesquels sont en aperçu et lesquels nécessitent une assistance professionnelle distincte. Cet exercice est banal, mais c'est là que la résilience du cloud devient visible.

L'hébergement physique est le rappel le plus concret que le cloud a des limites. Ladocumentation sur l'hébergementde Cloud Temple décrit l'hébergement physique par unité de rack dans des racks partagés ou par rack dédié 42U, deux chaînes électriques pour les racks partagés, des limites de puissance par U, des unités 2U orientées serveur avec alimentation C19, des racks dédiés avec 3 kW sur deux chaînes électriques 16A, des incréments supplémentaires de 2 kW, une masse maximale d'équipement de 1 000 kg, des PDU surveillés, des ports réseau cuivre ou fibre, une connectivité de salle de rencontre et des services « hands-and-eyes ». Elle indique également que les racks dédiés sont situés dans un espace d'hébergement partagé en dehors de la zone SecNumCloud. Cette dernière distinction est importante: « Hébergement Cloud Temple » et « IaaS Secure Temple qualifié » ne sont pas des expressions interchangeables.

Pour certains clients, l'hébergement est un pont. Un équipement legacy, un système adjacent à un mainframe, un boîtier de stockage propriétaire, un HSM, un pare-feu ou un serveur de préparation de migration peut avoir besoin de se trouver à proximité des ressources cloud pendant qu'une charge de travail réglementée se déplace. Cela peut être sensé. Cela peut aussi créer une architecture à deux périmètres: une partie cloud qualifié, une partie hébergement physique non qualifié, une partie équipement appartenant au client, une partie réseau géré par Cloud Temple, une partie circuit opérateur.

Si le client suppose que tout a la même qualification, la même réponse de support et les mêmes mécanismes de reprise, la conception peut devenir trompeuse. Les documents d'hébergement sont utiles précisément parce qu'ils obligent l'acheteur à parler d'unités de rack, de watts, de ports, de chemins optiques, de réponse « hands-and-eyes » et d'escalade de support.

L'argument de la souveraineté des données est donc le plus solide lorsqu'il est maintenu concret. Les pages de Cloud Temple font une revendication de souveraineté crédible autour de l'exploitation française, de la qualification SecNumCloud, de HDS, de l'ISO 27001, des équipes de support en France et des produits conçus pour les secteurs réglementés. La page de stockage objet met l'accent sur les besoins réglementaires français et européens. La page de support indique que les équipes de support sont basées en France et opèrent depuis la France. La page de conformité liste les dates de validité officielles et les périmètres.

Mais la souveraineté n'est pas seulement une étiquette nationale. C'est aussi le placement, l'accès au support, les preuves de sous-traitance, la garde des clés, la communication d'incident, la route d'exportation, la preuve de suppression et la divulgation du risque résiduel. Un client doit demander où se trouve chaque copie de données, sauvegarde, flux de journaux, artefact de support et intervention de support.

L'empreinte réseau publique donne une leçon similaire. AS33930 a des préfixes visibles, une autorisation d'origine de route valide dans la vue vérifiée, une participation aux échanges et des listes d'installations. C'est mieux que de ne voir qu'un front-end revendeur sur le réseau de quelqu'un d'autre. Cela signifie que Cloud Temple a une surface de routage directe et une histoire d'interconnexion publique.

Pourtant, les preuves de routage ne révèlent pas quel locataire client utilise quel préfixe, comment la mitigation DDoS est orientée pendant une attaque, si tous les chemins sont également disponibles pendant la maintenance, quelles préférences de route s'appliquent aux préfixes appartenant au client, ou à quelle vitesse un client peut déplacer l'identité IP loin de la plateforme. Un enregistrement BGP solide est nécessaire pour certaines charges de travail, pas suffisant pour toutes.

Les clients les plus touchés sont ceux que Cloud Temple cible elle-même: les organismes publics, les prestataires de soins de santé, les entreprises financières, les opérateurs industriels, les éditeurs de logiciels et d'autres organisations qui ont besoin à la fois d'assurance de conformité et de continuité opérationnelle. Dans ces contextes, une panne de cloud est rarement une simple gêne. Elle peut retarder les soins, bloquer les rapports réglementaires, arrêter les systèmes adjacents aux usines, bloquer les services aux citoyens, interrompre l'accès à l'identité ou empêcher un éditeur de logiciels de servir ses clients en aval.

La bonne question de due diligence n'est pas « Cloud Temple peut-il héberger une VM? » Il le peut clairement. La question est « La conception de service choisie correspond-elle au préjudice opérationnel si cette application s'arrête? »

Pour une agence publique, la réponse peut impliquer le périmètre SecNumCloud, la ségrégation des locataires, le niveau de support, la communication d'incident et la réversibilité. Pour un prestataire de soins de santé, elle peut impliquer le périmètre HDS, les tests de restauration de sauvegarde, l'accès au support, la rétention d'Entité Lock et la couverture des preuves de sous-traitance pour chaque chemin. Pour une équipe financière, elle peut impliquer les preuves d'audit, la diversité des routes, l'archive immuable, le chiffrement, la garde des clés et la planification de sortie de type DORA.

Pour une entreprise industrielle, elle peut impliquer des liaisons à faible latence, la proximité des installations, la conception du backbone privé, les fenêtres de maintenance et le repli opérationnel local. Une seule étiquette de produit ne peut pas répondre à ces questions. Le client doit transformer les preuves publiques en une revue de conception spécifique à la charge de travail.

Le chemin de défaillance le plus intéressant à tester est le composé: un incident qui traverse l'infrastructure du fournisseur, la configuration du client et le processus de support. Imaginez un client exploitant l'IaaS VMware sur deux zones de disponibilité avec une paire de pare-feu, des copies de sauvegarde S3, un préfixe appartenant au client, un chemin fibre sur site et un niveau de support Premium. Si une zone se dégrade, l'application peut dépendre de la configuration HA, de la réplication du stockage, de l'état du pare-feu, du comportement DNS, de la convergence de route, de la disponibilité S3 et d'un ticket correctement classifié.

Si le propre circuit opérateur du client a également des problèmes, le backbone de Cloud Temple peut ne pas être le goulot d'étranglement. Si la politique de sauvegarde du client a été mal conçue, le stockage objet sur trois zones peut préserver les mauvaises données. C'est pourquoi la responsabilité partagée doit être exercée avant la panne, pas seulement citée pendant celle-ci.

Les fenêtres de maintenance méritent la même attention. Le langage SLA exclut les maintenances planifiées notifiées dans le cadre du contrat de support du client. C'est normal, mais cela déplace la planification pratique vers le client. Qui reçoit les avis de maintenance? Sont-ils acheminés vers l'équipe qui possède l'application? Le client sait-il si une mise à jour d'hyperviseur peut déclencher un redémarrage? Comprend-il que certaines mises à jour du système d'exploitation de l'hyperviseur peuvent être une décision client parce que Cloud Temple n'a pas connaissance de chaque contrainte spécifique à la charge de travail?

Les équipes de sauvegarde, de surveillance et de pare-feu sont-elles présentes pendant la fenêtre? Un événement de maintenance est routinier pour le fournisseur uniquement s'il est également routinier pour le client.

Les fenêtres de réparation et le stock matériel sont plus difficiles à vérifier à partir de sources publiques. Les documents révèlent des classes de blades, des limites de stockage, des ports réseau et des unités d'hébergement physique, mais ils ne publient pas le nombre de blades de rechange, les pièces de rechange du contrôleur de stockage, l'inventaire GPU, les délais de livraison par classe ou la pratique de remplacement exacte par zone de disponibilité. Cela ne signifie pas que le stock est absent. Cela signifie que la recherche publique ne peut pas le prouver.

La bonne demande client est simple: montrer le processus de réservation de capacité, d'extension et de remplacement pour le service choisi. Si l'application a besoin de quatre blades GPU supplémentaires pendant une urgence, ou d'un hôte de remplacement après une panne de blade, ou d'un débit de stockage objet supplémentaire pendant une reprise, le client doit savoir si la réponse est immédiate, planifiée, dépendante d'une commande ou dépendante d'un devis.

La même chose s'applique à la preuve de restauration. La plateforme qualifiée de Cloud Temple, la redondance S3 et l'architecture de sauvegarde créent un point de départ plus solide qu'un hôte générique. Mais les matrices de responsabilité IaaS et S3 placent à plusieurs reprises la cohérence du plan de sauvegarde et les tests de restauration périodiques avec le client, parfois avec consultation de Cloud Temple. Cela devrait changer le langage d'achat. Les acheteurs devraient demander non seulement « La sauvegarde est-elle incluse?

» mais aussi « Qui rédige le plan de restauration, qui exécute le test, qui enregistre le résultat, que se passe-t-il si la restauration manque la cible, et quel niveau de support s'applique pendant une reprise réelle? » Une restauration non testée reste une aspiration même lorsque le stockage sous-jacent est bien construit.

La note de preuve pour TEMPLE Cloud Temple SAS devrait donc être meilleure que la prudence de faible empreinte de l'affectation, mais toujours pas absolue. Le dossier public est large, actuel et spécifique: les pages officielles identifient le positionnement dans les secteurs réglementés, les bureaux français, le périmètre SecNumCloud et HDS, les familles de produits, les niveaux de support, l'architecture de stockage objet, la conception du backbone privé, les conditions SLA VPC et VM, les limites physiques de l'hébergement, le routage AS33930, la validité RPKI, les points d'échange et les composants de statut public.

C'est une empreinte substantielle. Les preuves manquantes sont plus étroites mais décisives: placement spécifique au client, affectation exacte de l'opérateur d'installation pour chaque charge de travail, inventaire des pièces de rechange, historique des performances du support, résultats des tests de restauration, concentration des clients, communications de maintenance et exécution réelle de la sortie.

Pour les acheteurs, la conclusion pratique est de traiter TEMPLE Cloud Temple SAS comme une dépendance cloud souveraine crédible qui nécessite encore une preuve au niveau de la charge de travail. Demandez un diagramme qui nomme la région, les zones de disponibilité, les hôtes ou classes de calcul, les classes de stockage, les buckets S3, les politiques de sauvegarde, les passerelles VPC, les sorties Internet, les circuits clients, les contacts de support et les chemins d'escalade.

Demandez quels engagements sont couverts par le périmètre SecNumCloud, lesquels sont HDS, lesquels sont de l'hébergement ordinaire, lesquels sont en aperçu et lesquels sont détenus par le client. Demandez comment les crédits de service sont réclamés et ce qu'ils ne couvrent pas. Demandez comment une charge de travail quitte, comment les données sont effacées, comment les clés sont gérées et comment le support se comporte en dehors des heures ouvrables.

Pour les lecteurs d'infrastructure, la leçon est plus large. Un fournisseur de cloud souverain peut être à la fois véritablement opérationnel et toujours dépendant de la physique banale de la capacité. TEMPLE Cloud Temple SAS vend une combinaison attrayante: infrastructure française qualifiée, plateformes d'entreprise reconnaissables, routage visible, stockage objet sur trois zones de disponibilité, support en France et matrices de responsabilité explicites. Mais le client n'achète pas la « souveraineté » dans l'abstrait.

Il achète un locataire particulier, une classe de blade, un niveau de stockage, un chemin réseau, un niveau de ticket, un calendrier de maintenance et un arrangement de sortie. Ce sont les pièces qui décideront si la capacité hébergée survit à un événement de rack, un événement en amont, une pénurie matérielle, une file d'attente de support, un frottement de facturation, une pression de migration ou une défaillance du contrat du fournisseur.