todoencloud TODO EN CLOUD SL vend de la capacité hébergée qui dépend encore des baies, du transit et des créneaux de réparation

Résumé

• TodoEnCloud est une entreprise de cloud et de services gérés active à Madrid, pas simplement une coquille juridique ou un enregistrement réseau inactif. Elle déclare exploiter un cloud public depuis 2011; Tessi a enregistré l'acquisition de l'entreprise en 2018; et les registres, certifications, le site web et les preuves de routage actuels indiquent une activité continue.
• Le cloud public espagnol de l'entreprise est présenté comme trois zones dans trois centres de données de la région de Madrid, reliées par un anneau de fibre noire. Un certificat ENS de novembre 2025 identifie les sites comme Interxion au 71 Calle Albasanz, DATA4 au 15 Avenida de la Industria à Alcobendas, et IPCore au 16 Calle Marzo. Il s'agit d'opérateurs de sites indépendants; TodoEnCloud semble détenir ou contrôler les équipements de service et la couche réseau, plutôt que les bâtiments, les sous-stations ou les générateurs.
• AS201346 a annoncé quatre préfixes IPv4 /24 totalisant 1 024 adresses le 12 juillet 2026. Les collecteurs RIPE ont observé trois réseaux amont adjacents, associés à Cogent, Lumen et NEAR IP, et la route testée disposait d'une autorisation RPKI valide. Il s'agit de preuves opérationnelles substantielles, même si l'absence d'IPv6 visible et d'une entrée PeeringDB laisse des lacunes dans le tableau d'interconnexion public.
• Trois installations ne sont utiles que si les composants de calcul, de stockage, de réseau, d'identité, de gestion et de sauvegarde d'un client sont délibérément répartis entre elles. TodoEnCloud ne publie pas le nombre de serveurs installés, la capacité de calcul ou de stockage utilisable, la marge par site, la sursouscription, les performances de récupération, l'historique des incidents ou un tableau des niveaux de service standard. La capacité des installations ne doit donc pas être interprétée comme la preuve que chaque ressource louée survit à la perte d'un site.
• Globalement, les preuves opérationnelles sont solides, tandis que les preuves de récupération publiques sont moyennes. Un acheteur peut vérifier l'entité juridique, la société mère, les sites, les certifications, l'espace d'adressage et le routage actif. Un acheteur a encore besoin d'une architecture spécifique à la charge de travail, des limites d'alimentation et de fibre, des engagements de point et de délai de récupération, des règles de maintenance, de l'escalade du support, de la politique de pièces de rechange et d'un test de sortie chronométré avant de considérer le cloud comme portable ou tolérant aux pannes de site.

Le cloud est concentré dans trois bâtiments madrilènes spécifiques

La proposition de TodoEnCloud est particulièrement utile pour l'analyse d'infrastructure car elle nomme la couche physique sous son cloud. Lapage cloud publicde l'entreprise indique que le service est réparti sur trois centres de données espagnols, reliés par un anneau de fibre à haut débit et faible latence, et présenté aux clients comme trois zones au sein d'une même zone de disponibilité. Sapage centres de donnéescite Digital Realty, DATA4 et IPCore. Le plus décisif, lecertificat ENSde l'entreprise, délivré en novembre 2025, identifie Interxion au 71 Calle Albasanz, DATA4 Group au 15 Avenida de la Industria à Alcobendas, et IPCore centres de données au 16 Calle Marzo à Madrid.

Ces emplacements rendent l'affirmation plus qu'un schéma. Digital Realty répertorie le 71 Calle Albasanz comme sonsite MAD1, un site de 8 280 mètres carrés dans un portefeuille madrilène de quatre installations. Lapage du campus de Madridde DATA4 situe son site MAD01 à la même adresse d'Alcobendas que celle indiquée sur le certificat de TodoEnCloud et décrit un campus disposant de réserves électriques importantes. Ladescription de ses installationspar IPCore situe un bâtiment de 1 200 mètres carrés, neutre vis-à-vis des opérateurs, au 16 Calle Marzo, avec une alimentation et un refroidissement redondants, de multiples entrées de fibre et une assistance à distance 24h/24.

Le schéma physique est donc celui d'un cloud métropolitain madrilène plutôt qu'une couverture nationale répartie sur des régions espagnoles éloignées. Albasanz et Calle Marzo sont dans la ville de Madrid; DATA4 est à Alcobendas, au nord du centre. La séparation au sein d'une métropole peut protéger contre un incendie de baie, une panne de bâtiment, une défaillance de commutateur local ou des travaux sur une connexion électrique.

Elle est moins efficace contre une perturbation régionale des communications, une urgence électrique étendue, une faille logicielle déployée partout, un problème de fournisseur commun ou une erreur opérationnelle propagée par une seule équipe.

Cette distinction n'est pas une critique de la conception métropolitaine. Une faible latence entre les sites peut rendre pratique le stockage synchrone et les services en cluster, tandis qu'une région éloignée introduirait un délai et un coût. Il s'agit d'une déclaration sur la nature de la défaillance assurée. Un cluster madrilène relié par fibre peut être excellent pour survivre à la panne d'une pièce ou d'un bâtiment. Il ne doit pas être présenté comme équivalent à une région de reprise dotée de personnel indépendant à des centaines de kilomètres, à moins que le client n'ait effectivement contracté et testé une telle région.

TodoEnCloud utilise elle-même une formulation inhabituelle: trois zones formant une seule zone de disponibilité. La terminologie du cloud n'étant pas normalisée entre les fournisseurs, les termes seuls ne règlent pas la question technique. Le client doit connaître les règles réelles de placement. Si trois machines virtuelles portant trois étiquettes de zone peuvent néanmoins partager une baie de stockage, un cluster de gestion, une paire de pare-feu ou un catalogue de sauvegarde, les étiquettes surestiment l'isolation.

Si l'ordonnanceur épingle chaque copie à des bâtiments distincts avec un stockage et des sorties réseau indépendants, les mêmes étiquettes peuvent cacher une conception robuste. C'est l'architecture, et non le vocabulaire, qui détermine le résultat.

TodoEnCloud exploite la couche de service, pas l'ensemble du patrimoine physique

L'identité corporative est claire. Lapolitique de confidentialitédu site web identifie TODOENCLOUD S.L. à Madrid et donne le même numéro de téléphone que celui trouvé dans les annuaires d'entreprises. Les registres commerciaux situent sa création en 2011. Le rapport annuel 2019 de Tessi enregistrel'acquisition de Todo en Cloud en 2018dans le cadre de l'expansion du groupe français vers l'architecture cloud et les services de centres de données. Le site de TodoEnCloud indique désormais que ses services font partie de l'usine numérique Innovation & Trust de Tessi.

Cette affiliation importe dans deux directions. Elle fournit un contexte corporatif plus large que le seul effectif de la filiale espagnole, et l'annonce d'acquisition initiale de Tessi indiquait que l'opération relierait les capacités espagnoles de TodoEnCloud à des plateformes d'hébergement en France. Mais la propriété de la société mère ne prouve pas que la capacité française constitue une destination de basculement active pour les clients espagnols.

À moins qu'un contrat, une conception de réplication et un test de reprise ne désignent un site français, le réseau de la société mère est une option stratégique plutôt qu'une redondance opérationnelle.

Le langage de propriété sur le site web de l'entreprise nécessite la même prudence. TodoEnCloud décrit une « infrastructure propre en Espagne » et fait parfois référence à « nos » centres de données. Pourtant, les bâtiments identifiés sont exploités par Digital Realty, DATA4 et IPCore. La lecture plus précise est que TodoEnCloud possède, loue ou contrôle les serveurs, le stockage, les équipements réseau et les logiciels déployés dans des installations de colocation tierces, et achète l'électricité, l'espace, la sécurité physique et les services du site dans le cadre d'accords avec ces opérateurs.

Elle peut également louer de la fibre tout en l'éclairant avec ses propres équipements optiques.

Cette propriété en couches est normale. Peu de clouds régionaux ont besoin de posséder une sous-station, une coque en béton et des réservoirs de diesel pour fournir un service sérieux. La conséquence est que la responsabilité traverse les contrats. Digital Realty, DATA4 ou IPCore répond à une alarme de bâtiment et entretient les installations du site. Un opérateur ou fournisseur de fibre répare une route externe. TodoEnCloud exploite la plateforme client, la politique réseau et peut-être la couche optique éclairée. Les fournisseurs de matériel fournissent les serveurs, les disques, les cartes réseau et les composants de remplacement.

Tessi contrôle in fine la filiale. Le client possède l'application, le modèle de données, les identifiants et la conception de reprise qu'il a achetée.

Pendant un mois ordinaire, ces frontières sont presque invisibles. Lors d'un incident, elles déterminent qui peut entrer dans la pièce, qui dispose d'une pièce de rechange, qui autorise une réparation de fibre, qui communique avec le client et si un avoir sur niveau de service est dû. Un fournisseur peut être responsable envers le client sans contrôler directement chaque étape de la restauration. La question importante est de savoir si ses contrats, sa surveillance et ses droits d'escalade sont suffisamment solides pour gérer ces dépendances externes sous pression.

Les certificats prouvent un périmètre opérationnel défini, pas une résilience illimitée

TodoEnCloud fournit des preuves de certification exceptionnellement concrètes. Soncertificat ISO 27001actuel couvre les systèmes de gestion de la sécurité de l'information soutenant l'IaaS public et privé au siège madrilène et à deux adresses de centres de données: Albasanz 71 et Avenida de la Industria 15. Il est valable de juillet 2024 à juin 2027. Uncertificat ISO 27701distinct couvre le système de gestion de la vie privée pour la même activité et les deux sites jusqu'en septembre 2027.

Le certificat ENS ultérieur est plus large. Il enregistre les trois centres de données nommés et indique que les systèmes soutenant l'IaaS public et privé ont été audités selon le Schéma National de Sécurité espagnol au niveau Moyen. Cela fournit un pont daté entre le marketing trois sites de l'entreprise et un périmètre d'audit externe. Il résout également une incohérence apparente sur la page sécurité de l'entreprise, qui indique encore que l'ISO 27001 couvre deux centres de données. L'explication la plus plausible est temporelle: les documents ISO répertorient deux sites, tandis que l'audit ENS ultérieur ajoute IPCore.

La certification est précieuse car elle établit une gouvernance, un périmètre défini, un auditeur et une période de validité. Elle ne révèle pas la capacité ni ne rend chaque charge de travail hautement disponible. L'ISO 27001 concerne un système de management de la sécurité de l'information. L'ISO 27701 étend la gestion de la vie privée. Le niveau Moyen ENS impose des contrôles pour les systèmes servant des besoins du secteur public espagnol.

Aucun de ces documents n'indique combien de nœuds de calcul sont actifs dans chaque bâtiment, si les volumes clients sont répliqués de manière synchrone, combien de temps prend le remplacement d'un hôte défaillant, ou comment une base de données particulière s'est comportée lors de la dernière panne.

Les certifications des installations doivent également être séparées des certifications du fournisseur. La page centres de données de TodoEnCloud fait des déclarations générales sur des installations Tier III+ ou Tier IV, des composants N+1, des sous-stations indépendantes, des batteries et des générateurs, et une disponibilité entre 99,95 et 99,999 pour cent. Celles-ci semblent résumer les capacités des sites parmi les opérateurs choisis. Elles ne constituent pas un accord de niveau de service publié par TodoEnCloud, et la fourchette elle-même couvre des tolérances de temps d'arrêt très différentes.

Sur une année de 365 jours, 99,95 pour cent autorise environ 4 heures 23 minutes d'indisponibilité; 99,999 pour cent autorise environ 5 minutes 15 secondes. Le contrat client doit identifier quel chiffre, point de mesure et exclusions s'appliquent.

Une certification peut également exclure une dépendance que les clients supposent couverte. Les certificats ISO nomment deux CPD alors que le cloud public en décrit désormais trois. Un service AWS ou Azure géré vendu par TodoEnCloud dépend de ces plateformes externes plutôt que du seul cloud espagnol certifié. Un nœud en périphérie dans une usine ou un lampadaire est physiquement en dehors des installations madrilènes. Le propre cluster sur site d'un client possède sa propre limite d'alimentation et de sécurité. Le périmètre doit donc être lu service par service, et non appliqué au logo de l'entreprise comme une propriété universelle.

La capacité installée et la capacité utilisable restent non divulguées

La plus grande lacune dans les preuves publiques est la capacité. TodoEnCloud propose du cloud public, du cloud privé, du bare metal, Kubernetes, des instances GPU, de la sauvegarde, de la reprise d'activité, de la colocation et des opérations gérées. Elle indique que les clients peuvent monter en charge et payer à l'utilisation. Elle ne publie pas le nombre ou la génération des hôtes de calcul, le total de cœurs physiques, la mémoire, l'inventaire des accélérateurs, les supports de stockage, les pétaoctets utilisables, l'utilisation normale, la puissance des baies, la marge réservée ou la répartition par site.

Sans ces chiffres, un acheteur ne peut distinguer la capacité installée de la capacité utilisable. Une baie peut contenir des serveurs mais manquer de puissance électrique engagée suffisante pour tous à pleine charge. Un cluster de stockage peut annoncer une capacité brute de disques, tandis que la parité, la réplication, les snapshots et la réserve consomment une part importante. Un pool de cloud public peut disposer d'un excédent de CPU agrégé mais pas assez de mémoire, de GPU ou de stockage local pour une forme spécifique.

Un fournisseur peut être en mesure de vendre une instance supplémentaire en fonctionnement normal mais manquer de place pour absorber toutes les charges de travail survivantes après une panne de site.

La dernière distinction est la plus importante. La capacité utilisable un jour ordinaire n'est pas nécessairement une capacité tolérante aux pannes. Supposons que trois sites fonctionnent chacun à 60 pour cent de leur charge client sûre. En perdre un laisserait deux sites essayant de porter 90 pour cent chacun, avant de tenir compte des formes de charge inégales, de la localité du stockage ou des limites réseau. Cela pourrait être récupérable. À 80 pour cent d'occupation normale, les deux survivants devraient atteindre 120 pour cent, ce qui est impossible sans délester ou laisser certains services arrêtés.

Ces nombres sont des exemples, pas des estimations de l'utilisation de TodoEnCloud. Ils montrent pourquoi le seul nombre de sites ne peut établir la récupérabilité.

L'inventaire matériel crée une autre lacune. L'offre de cloud privéde TodoEnCloud va de déploiements à trois nœuds à de grands environnements sur mesure, utilisant du matériel client ou des équipements financés par le fournisseur. Sonoffre bare metalpromet un contrôle physique dédié avec une consommation de type cloud. Ces services ne peuvent pas être restaurés en allouant n'importe quelle machine virtuelle générique. La récupération peut nécessiter la même famille de CPU, la même taille mémoire, la même interface réseau, le même accélérateur, le même firmware ou la même connexion de stockage. Un nœud de remplacement qui existe dans un entrepôt n'est pas encore câblé, configuré et intégré au cluster.

La tarification publique est également éparse. Le fournisseur met l'accent sur un modèle de dépenses opérationnelles et la gestion des coûts, mais ne révèle pas de grille tarifaire générale pour le calcul, le stockage, le trafic sortant, la sauvegarde, l'intervention à distance ou la capacité réservée. Cela est compréhensible pour une architecture B2B sur mesure. Cela signifie que l'économie de l'hébergement doit être établie dans une proposition et un contrat.

Les acheteurs devraient demander comment les changements de prix de l'électricité, les coûts de licence, le matériel de remplacement, la capacité d'extension, le trafic inter-sites, le transit externe et la main-d'œuvre hors heures se répercutent sur la facture.

Les opérateurs plus petits peuvent parfois fournir un service plus économique ou plus attentif que les hyperscalers, car ils évitent un vaste catalogue de produits et connaissent chaque environnement. Ils peuvent également faire face à des achats irréguliers. Un contrôleur de stockage défaillant, une ligne de serveur en fin de vie ou une commande de fibre retardée peuvent avoir plus d'importance lorsque la flotte est compacte.

Une discussion crédible sur la capacité nécessite donc à la fois un chiffre et un plan de réapprovisionnement: ressources opérationnelles, ressources vendables en toute sécurité, ressources conservées pour les pannes, délais des fournisseurs et substitutions déjà qualifiées.

Le réseau est visiblement actif et plus diversifié qu'une simple ligne de transit

Les preuves réseau constituent le signal opérationnel indépendant le plus fort. RIPE a attribuéAS201346à TODO EN CLOUD SL en novembre 2014. L'entreprise détient également l'allocation IPv4 active 185.77.132.0 à 185.77.135.255. Le 12 juillet 2026, lavue de l'état du routage de RIPEstatmontrait quatre préfixes /24 annoncés, 1 024 adresses IPv4 annoncées, une visibilité complète sur ses pairs IPv4 de déclaration et aucun espace IPv6 annoncé.

Lesdonnées des voisins observésde RIPE montraient trois réseaux du côté amont de AS201346: AS174, associé à Cogent; AS3356, associé à Lumen; et AS49600, NEAR IP. Un /24 représentatif disposait d'uneautorisation de route RPKI valide. Le CIDR Report voyait également AS201346 annoncer l'équivalent d'un /22 via les chemins Cogent et Lumen. Ces observations étayent un hébergement actif et une diversité de routage de manière plus convaincante qu'une simple page produit.

Elles nécessitent néanmoins des limites. Un collecteur BGP peut montrer que trois systèmes autonomes amont propagent les routes de TodoEnCloud. Il ne peut pas montrer que chaque site dispose d'entrées physiquement séparées vers les trois, que chaque opérateur peut prendre la totalité de la charge de trafic, ou que les circuits évitent un conduit partagé, une salle de rencontre ou une plateforme optique. Deux contrats d'opérateur peuvent converger sur un même chemin de fibre métropolitain. Trois routes peuvent aboutir sur un seul châssis de périphérie.

Une coupure de fibre noire peut isoler un site même si les préfixes publics restent joignables depuis un autre.

La politique de routage enregistrée de l'entreprise semble également plus ancienne que le réseau observé. Son objet aut-num RIPE nomme AS35699 et AS201942 dans les déclarations d'import et d'export, tandis que les observations en direct montrent Cogent, Lumen et NEAR IP. Les objets de politique de registre sont souvent en retard sur les arrangements opérationnels, mais la discordance est un avertissement utile contre le fait de traiter un texte administratif comme une carte topologique en direct.

Un client exigeant une assurance de routage devrait obtenir le diagramme réseau actuel et tester le basculement, et non le déduire d'un objet vieux de dix ans.

Aucune entrée AS201346 n'a été retournée par la requête de réseau public de PeeringDB. Cette absence n'implique pas une mauvaise connectivité. PeeringDB est un annuaire opérationnel volontaire, et un réseau axé sur le transit peut fonctionner sans y figurer. Elle supprime un moyen courant de vérifier la présence dans les installations, la participation aux échanges, la politique de trafic et les contacts réseau publics. Les pages de l'entreprise annoncent des liens vers des points d'échange Internet et plusieurs opérateurs, mais ne nomment pas les ports d'échange ou les capacités pour AS201346.

L'absence d'IPv6 visible est une question de service plus directe. Quatre routes IPv4 actives soutiennent l'hébergement conventionnel, mais les clients construisant des services publics modernes peuvent nécessiter une double pile native. La traduction d'adresses réseau au niveau du fournisseur ou un amont séparé peut parfois fournir de l'IPv6 sans route AS201346, mais cette conception doit être explicite.

Un acheteur devrait demander si l'IPv6 est disponible pour les machines virtuelles et les serveurs bare metal, comment les adresses sont routées pendant le basculement de site, et si la protection DDoS traite les deux familles de protocoles de manière égale.

Un anneau de fibre réduit certaines pannes et crée son propre problème de réparation

TodoEnCloud indique que ses sites sont interconnectés par un anneau de fibre noire redondant éclairé par l'entreprise. C'est une base plausible pour un cloud métropolitain. La fibre noire donne à l'opérateur le contrôle de l'équipement optique et de la capacité, plutôt que de forcer chaque réplication de stockage ou flux est-ouest à travers un transit Internet mesuré. Un anneau peut envoyer le trafic dans l'autre sens après la rupture d'un segment, à condition que la topologie, la commutation et la capacité restante fonctionnent comme prévu.

Le mot « anneau » n'est pas le test de récupération. Les questions utiles commencent en dessous. Les deux chemins sont-ils dans des conduits et des rues distincts? Entrent-ils dans chaque bâtiment par des colonnes montantes différentes? Les dispositifs optiques sont-ils alimentés par des alimentations indépendantes? La commutation de chemin est-elle automatique? Combien de temps prennent la détection des pannes et la reconvergence? Le côté survivant peut-il supporter la réplication de pointe plus le trafic client? La maintenance programmée ouvre-t-elle parfois un côté de l'anneau, laissant une seconde coupure capable de partitionner le cloud?

Il y a également une distinction entre posséder la lumière et posséder le verre. Un fournisseur peut louer de la fibre non éclairée à un opérateur et installer ses propres transpondeurs. Cela donne le contrôle sur l'équipement de longueur d'onde tout en laissant la réparation civile au propriétaire de la fibre. Une rupture de câble peut nécessiter un accès à la rue, des permis, des équipes de jonction et une coordination entre une installation, l'opérateur et la ville. Le délai de réparation est physique même lorsque le service est appelé cloud.

La latence et la perte inter-sites affectent le comportement du stockage avant de produire une panne totale. La réplication synchrone attend un accusé de réception distant et peut ralentir lorsqu'une liaison se dégrade. La réplication asynchrone peut continuer localement mais augmente la quantité de données récentes à risque. Une protection contre le split-brain peut délibérément arrêter un côté plutôt que de laisser deux copies accepter des écritures conflictuelles. Du point de vue du client, un arrêt prudent du stockage reste un temps d'arrêt, mais il peut s'agir du choix correct pour protéger la cohérence.

TodoEnCloud annonce des services séparés detransit IP, DDoS et VPN. Cela peut simplifier la responsabilité car un seul fournisseur peut gérer à la fois le calcul et la connectivité. Cela peut aussi concentrer la défaillance si la même périphérie, la même équipe de support, le même état de compte ou la même automatisation réseau les contrôle tous. Une conception résiliente devrait identifier un chemin d'accès hors bande et un canal de communication qui reste utilisable lorsque le réseau de production ou le panneau client est indisponible.

La résilience électrique s'arrête au chemin réel de la baie du client

Les trois opérateurs d'installations décrivent des systèmes électriques sérieux. La page madrilène de Digital Realty liste un refroidissement N+1 à MAD1. DATA4 décrit un grand campus madrilène avec une capacité électrique significative. IPCore annonce une alimentation sans interruption (ASI) 2N, un générateur diesel de secours et un refroidissement redondant. TodoEnCloud résume ses installations sélectionnées comme ayant des sous-stations indépendantes, des chemins séparés, des ASI, des batteries et des générateurs.

Ces caractéristiques améliorent le point de départ, mais l'alimentation doit être tracée de la grille à la charge de travail. Un bâtiment peut avoir deux arrivées électriques tandis qu'une cage particulière n'a qu'un seul chemin de distribution. Une baie peut recevoir des alimentations A et B tandis qu'un serveur n'a qu'une seule alimentation. Un serveur à double cordon peut connecter les deux cordons au même panneau amont par erreur. Un générateur peut supporter la charge critique tandis que le refroidissement ou les zones non critiques suivent une priorité différente. La maintenance peut temporairement retirer un composant redondant.

La densité de puissance limite également le matériel utilisable. Les produits GPU et bare metal peuvent consommer bien plus de puissance par baie que les anciens serveurs à usage général. Une installation avec un espace au sol inutilisé peut ne pas avoir les kilowatts, le refroidissement ou la capacité de bus livrables pour un autre déploiement dense. Les nouvelles pages GPU de TodoEnCloud annoncent des ressources NVIDIA L4 et L40 à la demande, mais n'indiquent pas l'inventaire, la densité des baies ou si la capacité des accélérateurs existe sur un ou plusieurs sites.

Les clients doivent traiter la mise à l'échelle instantanée comme une promesse commerciale limitée par la flotte installée.

Les générateurs d'installation introduisent des dépendances de carburant et de redémarrage. Un bref événement sur le réseau peut être supporté par les batteries jusqu'à ce que les générateurs se stabilisent. Un événement plus long nécessite un stock de carburant, un ravitaillement réussi et un refroidissement continu. Après une perte totale d'alimentation, les systèmes de calcul, de stockage et de réseau nécessitent un redémarrage ordonné. Le stockage doit établir un quorum, les services de contrôle doivent revenir et les instances clients peuvent rivaliser pour la capacité hôte.

Le temps de restauration électrique d'un bâtiment n'est pas le même que le temps de récupération d'une application.

Le point de mesure contractuel importe. Si l'installation fournit de l'énergie à la baie de TodoEnCloud mais que l'alimentation d'un serveur tombe en panne, le bâtiment peut être dans son engagement de service tandis que le client est en panne. Si le serveur fonctionne mais qu'un volume de stockage est indisponible, une mesure de disponibilité du calcul dit peu. L'acheteur a besoin d'une définition de service de bout en bout pour la ressource achetée, avec la maintenance planifiée, les travaux d'urgence et les exclusions amont clairement indiqués.

Le stockage, la sauvegarde et la reprise d'activité sont des produits différents

Le catalogue de services espagnol de TodoEnCloud inclut la sauvegarde et la reprise d'activité, ce qui est un signe positif car il ne prétend pas que le calcul hautement disponible rend la sauvegarde inutile. Sapage de services cloudindique que les sauvegardes peuvent être stockées dans différents centres de données et accessibles via une interface compatible S3. La même page présente la reprise d'activité en tant que service destiné à restaurer les données, systèmes et applications critiques.

Les clients doivent néanmoins savoir si ces protections sont incluses dans la ressource de base ou vendues séparément. Une machine virtuelle répliquée entre hôtes peut survivre à une panne de serveur tout en conservant une suppression accidentelle ou un ransomware sur chaque copie. Un snapshot dans le même cluster de stockage peut aider à la restauration mais échouer avec le cluster. Une seconde copie dans un autre bâtiment est plus solide, bien qu'elle puisse rester exposée à un seul ensemble d'identifiants ou à un seul plan de gestion. Une copie immuable ou hors ligne protège contre une classe différente de défaillance.

L'objectif de point de récupération et l'objectif de temps de récupération transforment ces produits en engagements mesurables. Le point de récupération détermine la quantité de données récentes pouvant être perdues. Le temps de récupération détermine combien de temps l'entreprise peut attendre. Ni l'un ni l'autre ne doivent être déduits de l'expression « sauvegarde automatique » ou du nombre d'installations. Une base de données répliquée de manière synchrone peut viser une perte de données quasi nulle mais s'arrêter pendant une partition.

Une sauvegarde nocturne peut restaurer après une perte de bâtiment mais sacrifier une journée de transactions. Les deux conceptions peuvent être rationnelles pour différentes charges de travail.

Le test de restauration est la preuve qui compte. Il doit inclure les identifiants, les clés de chiffrement, la politique réseau, les dépendances de domaine, l'ordre des applications et la capacité requise sur le site de récupération. Un objet de sauvegarde n'est pas un service récupéré. Si la restauration dépend du même système d'identité, de la même console de gestion ou du même magasin de documentation qui a échoué, la copie nominalement séparée peut être inaccessible au moment critique.

Les pages publiques de TodoEnCloud ne publient pas le succès global des restaurations, la rétention standard, les intervalles de réplication inter-sites, les options de copie immuable ou les temps de récupération testés. Cela ne signifie pas que les fonctionnalités sont absentes; son offre est sur mesure. Cela signifie que le client doit insister pour que ces détails passent de la conversation de conception à un calendrier de service et à un test d'acceptation.

La main-d'œuvre de support fait partie de la capacité

La promesse commerciale centrale de l'entreprise est une architecture et des opérations attentives. Son site propose des options de support de 8x5 à 24x7, un service de surveillance 24 heures, de l'administration système, une aide à la migration et des contacts techniques dédiés. Les témoignages de clients soulignent la réactivité. Pour un fournisseur régional, cette couche humaine peut être un avantage réel par rapport à une file d'attente de tickets qui ne sait rien de l'application du client.

La capacité humaine est également limitée. Le remplacement d'un disque par un après-midi calme est différent d'un incident de site affectant de nombreux locataires. La surveillance peut détecter des centaines d'alertes en même temps. Les ingénieurs doivent distinguer la cause de la conséquence, se coordonner avec le personnel de l'installation, protéger la cohérence des données, communiquer l'état et prioriser la récupération. Une petite équipe peut être hautement compétente et être néanmoins saturée par des défaillances corrélées.

Le matériel public n'indique pas les effectifs par équipe, la profondeur de l'astreinte, la réponse à l'escalade, les définitions de gravité des incidents ou les engagements d'intervention à distance. Les estimations de LinkedIn et des données d'entreprise suggèrent une entreprise espagnole modeste, bien que ces chiffres soient incomplets et ne doivent pas être traités comme un effectif audité.

La question pertinente pour l'acheteur n'est pas le nombre total d'employés; c'est combien de personnes qualifiées peuvent agir sur ce service à 3h00, à quelle vitesse une deuxième personne les rejoint, et qui a l'autorité pour appeler un site ou un opérateur en urgence.

Le stock de réparation relie la main-d'œuvre au matériel. Les interventions à distance peuvent réinsérer un câble ou remplacer une unité défaillante connue uniquement lorsque la pièce et la procédure existent. Les contrôleurs de stockage d'entreprise, les disques appariés, les émetteurs-récepteurs propriétaires et les composants GPU peuvent avoir de longs délais de livraison. La compatibilité du micrologiciel peut rendre un remplacement nominal inutilisable.

Un fournisseur vendant du cloud privé géré devrait divulguer quels composants sont conservés sur site, lesquels sont couverts par la réponse du fournisseur, et quelle dégradation temporaire est acceptable pendant qu'un cluster attend une réparation complète.

Les fenêtres de maintenance créent le risque le plus subtil. L'application de correctifs aux hyperviseurs, au stockage, aux routeurs et aux équipements optiques est nécessaire, mais chaque action consomme de la redondance. Une mise à niveau progressive des hôtes est à faible risque si les charges de travail peuvent se déplacer et qu'une capacité de réserve existe. Elle est plus risquée lorsqu'un site est déjà dégradé ou lorsqu'un chemin de fibre est en maintenance. Les clients ont besoin de règles de préavis, de périodes d'interdiction et d'une déclaration indiquant si les travaux planifiés comptent dans la disponibilité.

La facturation et le contrôle du compte peuvent empêcher une machine saine d'être utile

La défaillance du cloud n'est pas toujours électrique. Un litige de facturation, un moyen de paiement expiré, une erreur de quota, un problème de licence ou une suspension de compte erronée peuvent rendre une capacité par ailleurs saine indisponible. TodoEnCloud met l'accent sur un point de contact unique et une facture unique pour les services gérés. Cela simplifie l'approvisionnement, mais peut aussi faire de la relation de compte une dépendance commune au calcul, à la connectivité, à la sauvegarde et au support.

Lesconditions généralesgénérales du site web indiquent que des contrats de produit ou de service supplémentaires peuvent s'appliquer et prévaloir. C'est important: les conditions du site web ne sont pas le SLA du cloud. Un client devrait examiner le bon de commande signé, le calendrier de service, les conditions de traitement des données et les règles d'utilisation acceptable pour connaître les déclencheurs de suspension, les préavis, les périodes de correction, le calcul des avoirs, la rétention des données après résiliation et le traitement d'une facture contestée.

Le quota est un autre contrôle commercial. Un langage de paiement à l'usage peut impliquer une expansion illimitée, mais aucun cloud régional n'a de serveurs infinis. Une demande d'API peut échouer parce qu'un quota de locataire est bas, qu'une forme matérielle demandée est indisponible ou que la capacité est réservée à quelqu'un d'autre. Une architecture de récupération qui suppose pouvoir créer des centaines d'instances après l'incident peut échouer précisément parce que tout le monde a besoin de capacité de réserve en même temps. La capacité de récupération réservée coûte de l'argent parce qu'elle ne peut pas être vendue deux fois.

Un contrat solide sépare l'élasticité ordinaire de la réserve de reprise. Il indique quelles ressources sont garanties, lesquelles sont au mieux des efforts, à quelle vitesse un quota peut être augmenté et si un site de récupération conserve une capacité correspondante disponible. Il identifie également le recours. Les avoirs de service peuvent compenser une partie d'un abonnement mensuel, mais ils couvrent rarement les ventes perdues du client, l'exposition réglementaire ou la main-d'œuvre de récupération. L'architecture doit donc prévenir les pertes plutôt que de compter sur des avoirs pour les rembourser.

L'emplacement espagnol est significatif, mais la souveraineté est une pile

La localisation des données est au cœur de l'offre de TodoEnCloud. L'entreprise déclare que ses centres de données de cloud public sont en Espagne et qu'elle ne transfère pas d'informations en dehors de l'Europe. Le certificat ENS situe les systèmes IaaS audités dans trois installations de la région de Madrid. L'entité juridique espagnole et la société mère Tessi sont identifiables. Pour les acheteurs recherchant un emplacement opérationnel espagnol, ce sont des avantages concrets par rapport à une vague étiquette de région européenne.

L'emplacement ne répond pas à toutes les questions de souveraineté. Les fournisseurs de matériel peuvent être étrangers. Les logiciels de support, la billetterie, la télémétrie, les services de domaine et le renseignement sur les menaces peuvent impliquer d'autres juridictions. Un service multicloud géré peut administrer des charges de travail sur AWS, Azure ou Google Cloud. Les métadonnées de sauvegarde peuvent voyager différemment des données utiles. Une société mère française peut avoir un accès de gouvernance ou de support même lorsque les serveurs restent à Madrid.

Aucune de ces conditions n'annule automatiquement la souveraineté; chacune appartient à la carte des flux de données.

Lapolitique de sécuritéde l'entreprise aligne son périmètre sur les normes ISO et le Schéma National de Sécurité espagnol. LeDécret Royal 311/2022espagnol exige que la sécurité soit traitée comme un processus intégral et inclut la continuité, la réponse aux incidents, la protection des informations stockées et transmises, et l'audit. La certification ENS de niveau Moyen est donc plus substantielle qu'un simple slogan de localité auto-déclaré. Elle reste une évaluation de catégorie et de périmètre, pas un avis juridique spécifique au client.

Les acheteurs devraient documenter où résident les données primaires, les réplicas, les sauvegardes, les journaux et les enregistrements de support; qui peut y accéder; quelles clés de chiffrement les protègent; et quelle loi régit chaque fournisseur. Ils devraient également distinguer la résidence des données de l'autonomie opérationnelle. Une charge de travail stockée à Madrid peut encore dépendre d'un dépôt logiciel distant, d'un serveur de licences ou d'un fournisseur d'identité. Une conception souveraine peut choisir ces dépendances consciemment et fournir des alternatives lorsque l'entreprise l'exige.

La concentration physique à Madrid crée un compromis. Elle offre une résidence espagnole claire et une conception multi-site à faible latence. Elle ne fournit pas une large dispersion géographique. Les clients confrontés à une exigence de copie distante peuvent avoir besoin d'une autre région espagnole, d'une cible sur site, de la capacité de Tessi ailleurs en Europe ou d'un second fournisseur. Ce choix doit être dicté par le modèle de menace et le besoin juridique, et non par le seul mot souverain.

Les logiciels ouverts aident à la sortie, mais la migration reste un transfert physique

TodoEnCloud déclare que plus de 90 % de son cœur est basé sur des logiciels open source et présente un accès API, Terraform et OpenTofu. Son servicehybride et multicloudmet l'accent sur des méthodes documentées, des charges de travail distribuées et une dépendance réduite à un seul fournisseur. Ces choix peuvent améliorer la portabilité en utilisant des images, des orchestrations et des interfaces objet familières plutôt que des formats propriétaires uniques.

Ils ne rendent pas la sortie instantanée. Un client doit exporter les disques virtuels, les bases de données, les magasins d'objets, les snapshots, la politique d'accès, les définitions réseau, les secrets et l'historique de surveillance. Les grands volumes de données sont limités par la vitesse de la liaison et peuvent prendre des jours ou des semaines. Les applications peuvent dépendre de répartiteurs de charge, de catalogues de sauvegarde, de comportements de pare-feu ou d'opérations gérées spécifiques au fournisseur.

Une image source peut être ouverte tandis que la connaissance opérationnelle nécessaire pour l'exécuter réside chez les ingénieurs de TodoEnCloud.

La Loi sur les Données de l'UE rend cette question particulièrement opportune.L'explication du Data Actpar la Commission européenne indique que les clients du cloud et de la périphérie devraient pouvoir changer de fournisseur et que les frais de changement, y compris les frais de sortie de données pour le processus de changement, doivent être supprimés à partir du 12 janvier 2027. Le règlement exige des informations contractuelles sur les procédures, les formats, les restrictions et le délai estimé, et attend des fournisseurs d'infrastructure qu'ils facilitent des résultats fonctionnellement équivalents lorsque cela est possible.

La loi peut supprimer les obstacles contractuels; elle ne peut pas abroger la bande passante ou la complexité de l'application. Une sortie propre nécessite toujours un inventaire actuel des actifs, une exportation lisible par machine, une capacité de destination, un transfert sécurisé des clés, une synchronisation finale, une validation et une décision de retour en arrière. Si le matériel appartient au client et est colocalisé, le plan nécessite également la libération physique, l'emballage, l'expédition et l'assurance. Si TodoEnCloud possède le matériel, le client a besoin d'images et de données plutôt que du serveur lui-même.

Le meilleur test de portabilité est une migration partielle effectuée avant la résiliation. Exporter une charge de travail représentative, la restaurer ailleurs, mesurer le taux de transfert, identifier les dépendances non documentées et confirmer que l'ancienne copie peut être supprimée après acceptation. Ce test révèle également si une sauvegarde est utilisable en dehors de la plateforme propre du fournisseur. Un plan de sortie écrit seulement après que la qualité de service a décliné est déjà trop tard.

Les chemins de défaillance pratiques sont corrélés

L'architecture à trois sites de TodoEnCloud offre plusieurs moyens de limiter un incident, mais l'impact sur le client dépend de l'endroit où la corrélation persiste.

Une panne de baie peut arrêter un hôte ou une étagère de stockage. Les clients avec des instances sur une autre baie peuvent ne voir aucune interruption; un locataire bare metal unique peut attendre la réparation. Un événement d'alimentation ou de refroidissement du bâtiment peut supprimer une zone entière. Les clients répartis sur des sites alimentés indépendamment peuvent continuer, tandis que les ressources d'un seul site ne le peuvent pas. Une coupure de fibre peut isoler le trafic de stockage ou de gestion même lorsque chaque bâtiment reste alimenté.

La protection en anneau n'aide que si le chemin alternatif a de la capacité et que la couche optique reconverge.

Une défaillance amont peut changer l'accessibilité sans endommager les serveurs. Trois fournisseurs observés sont encourageants, mais un défaut de périphérie ou de politique de routage partagé peut tous les affecter. Un bogue logiciel de stockage peut se propager entre les sites si la même version et l'automatisation sont utilisées partout. Un identifiant d'administrateur compromis peut contourner la diversité physique. Une mise à jour défectueuse peut faire tomber un plan de contrôle commun. La redondance géographique est la plus faible contre les défaillances délibérément répliquées pour la cohérence.

La rareté du matériel allonge la réparation lorsqu'un nœud spécialisé tombe en panne. La saturation du support allonge le diagnostic lors d'un événement étendu. Les erreurs de facturation ou d'identité peuvent refuser l'accès à travers des installations saines. Une sauvegarde conservée sous les mêmes identifiants peut être supprimée avec la production. Une migration peut caler parce que la capacité de destination ou le temps de sortie n'a jamais été réservé. Chaque chemin traverse des couches techniques et contractuelles.

Qui est affecté varie également. Un client avec une seule machine virtuelle peut perdre un site web et ses utilisateurs. Un client de cloud privé géré peut perdre une application d'entreprise, l'accès du personnel et les fournisseurs dépendants. Un organisme public utilisant un service couvert par l'ENS peut avoir des obligations de rapport et de continuité. TodoEnCloud fait face aux coûts de réparation, aux avoirs et aux dommages à la réputation. Les opérateurs d'installations et d'opérateurs font face à leurs propres engagements de service. Tessi porte le risque commercial au niveau du groupe.

L'incident est un événement, mais les conséquences sont réparties sur la chaîne.

Ce qui rendrait le dossier de résilience complet

TodoEnCloud a déjà divulgué plus d'infrastructures vérifiables que de nombreuses petites marques de cloud. Un acheteur peut nommer le fournisseur juridique et la société mère, visiter trois adresses d'installations, inspecter les certificats actuels, observer l'espace d'adressage routé et identifier plusieurs réseaux amont actifs. Ces faits justifient une évaluation de preuve opérationnelle solide.

Le travail restant est spécifique au client. Avant de traiter un déploiement comme résilient aux pannes de site, l'acheteur devrait obtenir une carte des composants montrant où le calcul, le stockage, le contrôle, l'identité, le pare-feu, la sauvegarde, la surveillance et les systèmes de support s'exécutent. La carte devrait identifier l'opérateur de l'installation, le chemin d'alimentation, le chemin de l'opérateur et l'entrée de fibre sur chaque site sans exposer de détails de sécurité sensibles. Elle devrait indiquer quels éléments sont actif-actif, actif-passif ou sur un seul site.

Les preuves de capacité devraient réconcilier les ressources installées, vendables et de récupération. Elles devraient montrer la marge par site pour les formes contractées, la réserve de stockage après réplication, la capacité réseau après une panne de segment ou d'opérateur, et les délais de livraison pour le matériel de remplacement. Le fournisseur n'a pas besoin de publier l'économie de la flotte au monde entier, mais le client qui compte sur la récupération a besoin d'une allocation défendable.

Le calendrier de service devrait définir la disponibilité au niveau de la ressource achetée, et pas simplement citer les niveaux des installations. Il devrait spécifier la mesure, la maintenance, les exclusions, la réponse du support, la priorité de restauration, les avoirs de service, la rétention des données et les garanties de suspension de compte. Les conditions de sauvegarde devraient indiquer l'emplacement, l'immutabilité, la rétention, la propriété du chiffrement, le point de récupération et le temps de récupération.

La section de sortie devrait énumérer les formats, les interfaces, la capacité de sortie, l'assistance et la preuve de suppression.

Enfin, les parties devraient tester. Simuler la perte d'un hôte, d'un chemin de stockage, d'un fournisseur de transit et d'une liaison de centre de données. Restaurer une charge de travail à partir de la sauvegarde séparée. Joindre le support via le canal secondaire. Exporter un service représentatif vers un autre environnement. Enregistrer le temps et les étapes manuelles. Un test réussi est une meilleure preuve qu'un autre adjectif de disponibilité.

L'attrait de TodoEnCloud est qu'elle offre une alternative espagnole visible à un cloud mondial impersonnel, avec des personnes proches de l'architecture et trois installations madrilènes réelles en dessous. Cette proximité peut être précieuse. Elle rend également le compromis sous-jacent plus facile à voir: les clients n'achètent pas du calcul en apesanteur, mais une revendication gérée sur des baies, de l'énergie, de la fibre, des stocks et une attention qualifiée. Le service est résilient lorsque ces revendications sont séparées, réservées et répétées.

Jusqu'à ce que la conception spécifique au client le prouve, la plateforme à trois sites est une capacité crédible avec des options de récupération, et non une garantie automatique que chaque charge de travail survivra à chaque défaillance.