DRP Cloud México après Ebunti: Un cloud souverain doit être plus qu’un catalogue

Résumé

• Le passage de DRP Cloud México à la marque Ebunti est soutenu par l’annonce de l’entreprise, les données actuelles d’enregistrement réseau et des références tierces récentes. Le dossier public laisse néanmoins une question contractuelle importante: les pages juridiques récentes d’Ebunti utilisent « Ebunti México, S.A.P.I. de C.V. » tandis que les enregistrements réseau, universitaires et commerciaux continuent d’identifier DRP CLOUD MEXICO SAPI DE CV.
• Les preuves opérationnelles sont plus substantielles qu’une simple brochure de revendeur. L’entreprise contrôle un système autonome mexicain et un espace d’adressage, publie la télémétrie de ses services, détient une distinction actuelle de partenaire Veeam et expose les conditions contractuelles pour l’infrastructure, la sauvegarde, la reprise et la protection Microsoft 365. Aucun de ces faits, pris isolément, ne prouve l’emplacement des données d’un client, le délai de récupération ou la disponibilité de bout en bout.
• Les documents publics associés à ARTEM n’établissent pas qu’ARTEM est DRP Cloud México, Ebunti, un successeur ou une filiale. ARTEM identifie une entreprise différente, tandis qu’une entrée dans le répertoire Odoo identifie simplement DRP Cloud México comme un client d’Odoo. Le catalogue cloud d’ARTEM et ses capacités Odoo ne peuvent donc pas être attribués en toute sécurité à cette entité.
• Un acheteur peut transformer l’incertitude en avantage d’approvisionnement. Le test décisif est une preuve contractuelle couvrant la contrepartie juridique, les emplacements des charges de travail et des sauvegardes, les chemins réseau, les performances de restauration et de basculement, la propriété du support, le périmètre de sécurité, l’escalade des prix et une sortie répétée — pas une liste de logos de produits.

À 2 h du matin, le nom sur la facture devient infrastructure

Imaginez la panne qui compte. Il est 2 h du matin, un dimanche. Un ransomware a rendu suspectes les machines virtuelles de production d’un client, les réplicas les plus récentes ont peut-être copié les dégâts et l’équipe financière a besoin de son environnement Odoo avant lundi. Le client appelle le numéro de son runbook. Un ingénieur support demande l’identifiant du service. Le portail cloud porte un nom, la facture fiscale un autre, le revendeur possède peut-être la relation commerciale et une plateforme tierce fournit la machinerie de récupération. À ce moment-là, l’architecture de marque cesse d’être un souci marketing.

Elle devient un élément de l’architecture de reprise.

C’est la bonne entrée pour DRP CLOUD MEXICO SAPI DE CV parce que les preuves publiques soutiennent la continuité tout en exposant une lacune qu’un acheteur sérieux ne devrait pas ignorer. Dansune annonce officielle hébergée sur l’ancien domaine DRP México, l’entreprise a déclaré que sa marque commerciale deviendrait Ebunti. Elle a présenté cette décision comme une évolution de la même activité, a donné l’adresse web d’Ebunti et a conservé DRP Cloud México SAPI de CV comme nom pour la facturation et les contrats. L’avis décrivait également une expansion au-delà du Mexique vers le Panama et la Colombie. C’est une preuve inhabituellement utile: elle indique à la fois le pont opérationnel et la distinction entre une marque et l’entreprise qui la sous-tend.

L’enregistrement réseau vivant renforce le pont.L’enregistrement de LACNIC pour AS265618identifie DRP CLOUD MEXICO SAPI DE CV comme déclarant, tandis que son contact technique actuel utilise une adresse@ebunti.comet que son contact abus est nommé pour Ebunti. L’allocation connexe45.190.180.0/22porte la même combinaison. Ce n’est pas simplement un ancien logo redirigeant vers un nouveau site; les données de contact opérationnelles actuelles lient le nom juridique DRP au nom d’exploitation Ebunti sur une ressource Internet réelle. Un rapport de février 2026 de l’unité d’innovation de l’Universidad Politécnica de Chiapas décrit de même une collaboration avec« DRP Cloud México (EBUNTI) ». Ensemble, ces sources soutiennent la conclusion qu’Ebunti est la continuation commerciale de DRP Cloud México.

Elles ne règlent pas le tableau juridique. Lecontrat-cadre actuel d’Ebunti, mis à jour en janvier 2026, identifie l’entité contractante mexicaine comme « Ebunti México, S.A.P.I. de C.V. ». Sonavis de confidentialité mexicain, mis à jour en juillet 2026, utilise ce nom et donne le RFC DCM170329Q19. Pendant ce temps, les ressources LACNIC nomment encore DRP CLOUD MEXICO SAPI DE CV, laliste de conventions 2025 de l’Université de Guadalajaramentionne encore DRP Cloud México SAPI DE CV, et uneentrée commerciale Dunsguideconserve ce nom juridique. Les adresses diffèrent également entre les pages publiques: le contrat pointe vers López Mateos Sur 7000, tandis que l’avis de confidentialité pointe vers une adresse sur Avenida de las Américas.

Plusieurs explications innocentes sont possibles. L’entreprise peut avoir effectué un changement officiel de nom; un document peut être obsolète; une adresse peut être un siège d’exploitation et l’autre une adresse de notification ou de registre. Les sources publiques consultées ne prouvent pas quelle explication est correcte. La conclusion prudente est donc plus étroite que « seul le logo a changé » ou « une toute nouvelle entreprise a pris la relève ». La continuité commerciale et opérationnelle est bien étayée.

La dénomination sociale exacte actuelle, l’adresse de notification, la propriété des ressources réseau et la responsabilité d’un contrat DRP existant doivent être vérifiées pour chaque achat.

Un dossier d’achat devrait contenir la constancia de situación fiscal actuelle, la dénomination sociale et le RFC, la commande signée, l’entité figurant sur les factures, l’entité désignée comme responsable du traitement des données, l’entité exploitant chaque service de centre de données et un échéancier des sous-traitants. Si le système autonome et l’espace d’adressage restent enregistrés au nom de DRP Cloud México tandis qu’Ebunti México signe la commande, le contrat doit indiquer comment le premier met ces ressources à la disposition du second et qui est responsable d’un incident de routage ou d’abus.

Si les noms se réfèrent à la même société renommée, le client doit conserver le document qui prouve le changement. Cette paperasse n’est pas de la bureaucratie autour du cloud. C’est la première dépendance dans le cloud.

Le raccourci ARTEM échoue au test d’identité

L’erreur la plus tentante en recherchant un vaste catalogue cloud local est de relier des entreprises parce que leur vocabulaire se chevauche. « DRP » est aussi une abréviation courante pour disaster recovery planning. Les services Odoo, la sauvegarde, la cybersécurité, l’infrastructure et le langage des centres de données mexicains apparaissent chez de nombreux fournisseurs non liés. Un résultat de recherche peut donc faire ressembler deux catalogues à un même groupe opérationnel alors qu’aucun pont d’entreprise n’existe.

Les documents publics ARTEM consultés pour cet article ne passent pas ce test de pont. Lapage « À propos » d’ARTEMprésente Arquitectos de Tecnología Mouan comme l’entreprise derrière la marque, avec sa propre histoire et son équipe. Son site a utilisé un numéro de téléphone et une présence à Mexico différents des documents Ebunti. Aucun avis d’entreprise, enregistrement réglementaire, annonce client, page partenaire ou enregistrement réseau faisant autorité dans l’ensemble de preuves gelé ne dit qu’ARTEM a acquis DRP Cloud México, est devenu Ebunti, opère pour elle ou appartient au même groupe. Des références croisées au cloud, à la reprise après sinistre, à la sécurité ou à Odoo ne sont pas des preuves de contrôle.

La piste Odoo est encore plus étroite. Le répertoire officiel des clients d’Odoo comporte une page intituléeDRP CLOUD MEXICO. Cette page prouve qu’Odoo a répertorié l’entreprise comme cliente. Elle ne fournit aucun récit de cas, périmètre de mise en œuvre, statut de partenaire, certification, architecture de déploiement ou engagement de support. Elle ne peut pas établir que DRP Cloud México met en œuvre Odoo pour d’autres entreprises, héberge Odoo en production dans le cadre d’un service défini ou fournit les intégrations affichées par ARTEM.

Cela importe parce qu’une charge de travail Odoo est un excellent test de résilience. Sa disponibilité ne dépend pas seulement de la puissance des machines virtuelles mais aussi de la cohérence PostgreSQL, de la synchronisation du filestore, des tâches planifiées, des relais de messagerie, du DNS, des certificats, de l’identité, des intégrations de paiement et de fiscalité, et d’un ensemble récupérable de modules personnalisés. Un fournisseur qui peut restaurer un disque virtuel n’a pas nécessairement restauré le processus métier. Ebunti est peut-être capable de faire plus; l’entrée publique Odoo ne le prouve tout simplement pas.

En conséquence, le catalogue d’ARTEM est exclu de l’évaluation de DRP CLOUD MEXICO SAPI DE CV. Un acheteur approché sous les deux noms devrait demander au vendeur de documenter la relation, d’identifier l’entité contractante et de séparer le travail sous-traité des services opérés par Ebunti. Jusqu’à ce que ces preuves existent, la frontière sûre est claire: le pont vérifié DRP vers Ebunti peut soutenir une diligence d’approvisionnement; un pont ARTEM vers DRP ne le peut pas.

Le catalogue d’Ebunti décrit des composants, pas encore un système d’exploitation

L’offre publique d’Ebunti a un centre cohérent. Sonsite web actuelregroupe l’infrastructure en tant que service, la sauvegarde en tant que service, la reprise après sinistre en tant que service, la protection Microsoft en tant que service et le stockage compatible S3. Son contrat-cadre définit les mêmes familles et ajoute les services gérés. L’accent est mis sur la continuité plutôt que sur le développement d’applications à usage général: exécuter des machines virtuelles, copier des données, préserver le contenu Microsoft 365, conserver des réplicas récupérables et confier la surveillance à quelqu’un.

Ce centre est renforcé par des preuves de fournisseurs. Veeam a nommé Ebunti sonpartenaire de l’année 2024 pour le cloud et les fournisseurs de services en Amérique latine. Dans des entretiens professionnels, les dirigeants d’Ebunti décrivent l’entreprise comme un fabricant de services pour les partenaires de canal, regroupant la sauvegarde et la reprise basées sur Veeam avec l’infrastructure et le support.L’entretien ITware Latam 2024relie explicitement l’ancien nom DRP México à Ebunti et décrit BaaS, DRaaS, S3, IaaS et la protection Microsoft.Le compte-rendu d’ITsellerprésente une conception similaire axée sur les partenaires. Ce sont des entretiens portant des déclarations de l’entreprise, pas des mesures indépendantes, mais la cohérence et la reconnaissance Veeam rendent la proposition opérationnelle crédible.

Un flux de travail plausible suit. Le client ou son revendeur définit les charges de travail protégées. La connectivité achemine le trafic de sauvegarde vers un référentiel ou une cible de réplication. VMware fournit une partie de la couche de virtualisation; Veeam fournit une grande partie de la politique, du mouvement, du catalogue et de la machinerie de récupération; Ebunti fournit l’infrastructure, la capacité, la surveillance, le travail opérationnel et un chemin de support. Pour Microsoft 365, le système protégé, l’authentification et les destinations de restauration sont différents, mais l’idée commerciale est similaire.

Le stockage S3 peut être une destination ou un service applicatif. Le devis décide quels éléments sont effectivement présents.

La documentation de Veeam montre pourquoi cette distinction importe.L’architecture Cloud Connectpermet à un fournisseur de services d’exposer ses propres ressources de calcul, de stockage et de réseau pour des référentiels hébergés et de la réplication. Laconsole du fournisseur de servicesprend en charge la surveillance centralisée et une hiérarchie de fournisseurs, revendeurs et entreprises gérées. Ce sont des capacités utiles, mais la capacité d’une plateforme n’est pas une déclaration sur le déploiement d’un fournisseur particulier. L’acheteur a encore besoin de savoir où se trouve le serveur de gestion, quelle partie détient les privilèges d’administration, comment les locataires sont séparés, si le référentiel est immuable, où vont les sauvegardes de configuration, quels réseaux transportent le trafic de gestion et comment une identité client compromise est empêchée de supprimer la copie de récupération.

Les témoignages de succès publics ajoutent des signaux d’échelle sans combler ces lacunes. L’étude de casSofttek d’Ebuntiappelle Ebunti l’ancien DRP México et dit que sa protection atteint 14 000 terminaux dans 25 pays. Elle inclut des améliorations de performance et une citation client. C’est un document publié par le fournisseur plutôt qu’un rapport technique vérifié, donc il soutient l’existence d’un engagement substantiel, pas une performance universelle pour un autre client. Les histoires nommées impliquant Softtek, Sí Vale, Carnes Viba et d’autres partenaires montrent des canaux de commercialisation; elles ne divulguent pas les domaines de défaillance, les périodes de conservation ou les objectifs de récupération contractuels.

La différence entre un catalogue et un système d’exploitation est la différence entre des noms et des verbes. « Sauvegarde », « reprise », « S3 », « sécurité » et « support 24/7 » sont des noms. Un système d’exploitation dit qui détecte un travail échoué, qui appelle qui, comment une copie immuable est sélectionnée, comment l’identité est reconstruite, combien de temps prend la restauration, quels contrôles applicatifs déterminent le succès et comment le client sort avec des données utilisables. Ebunti a suffisamment d’infrastructure visible et de preuves de partenaires pour justifier de tester ces verbes.

Le site web seul ne peut pas y répondre.

AS265618 est une preuve concrète — mais pour une seule couche

L’approvisionnement cloud traite souvent les affirmations réseau comme invisibles. DRP Cloud México offre une exception: elle a une identité réseau observable de l’extérieur. Les enregistrements LACNIC attribuentAS265618à DRP CLOUD MEXICO SAPI DE CV, avec un statut actif et une date d’enregistrement originale en décembre 2019. Le registre enregistre également l’allocation 45.190.180.0/22. Les contacts opérationnels actuels lient ces ressources au domaine Ebunti. C’est une preuve plus solide qu’une affirmation générique de « connectivité de classe mondiale ».

Les observateurs de routage ajoutent une vue utile, bien que non autoritaire, du périmètre.bgp.toolsmontre cinq préfixes IPv4 annoncés, y compris les quatre /24 dans l’allocation LACNIC et une route 38.58.140.0/22. Il identifie Alestra et Cogent parmi les fournisseurs d’accès.La page AS265618 d’IPinforapporte de même cinq préfixes IPv4, aucun préfixe IPv6 observé et une autorisation d’origine de route valide pour la route 38.58.140.0/22. Ces instantanés peuvent changer, et les collecteurs de routage ne voient pas chaque connexion privée, donc ils sont une preuve de routage public plutôt qu’un diagramme réseau complet.

Que prouve le système autonome? Il prouve que l’entreprise nommée a une identité de routage Internet durable et que les contacts de marque Ebunti l’exploitent. Cela donne à un acheteur quelque chose de concret à surveiller: changements d’origine, validation de route, diversité des fournisseurs d’accès et accessibilité des préfixes. Cela peut permettre au fournisseur de contrôler la politique de routage plus directement qu’une entreprise qui loue simplement des adresses derrière un seul opérateur.

Que ne prouve-t-il pas? Il ne localise pas une charge de travail. Une étiquette de géolocalisation IP n’est pas une adresse de baie. Il ne montre pas si deux fournisseurs d’accès entrent dans une installation par des gaines diverses, si les routeurs de bord partagent l’alimentation, si la protection contre les dénis de service distribués est en ligne, si le trafic de gestion utilise le même chemin, si des circuits privés existent, ou si un site de reprise après sinistre a une connectivité indépendante. Il ne prouve pas qu’un client recevra des adresses portables.

Il ne prouve pas la durabilité du stockage ou la disponibilité de la virtualisation. L’absence d’annonce IPv6 observée n’établit pas non plus qu’il n’existe pas d’IPv6 interne ou privé, mais c’est un sujet raisonnable pour une question de feuille de route.

Un acheteur devrait convertir la preuve réseau en un test en direct. Premièrement, lister tous les préfixes de production et de reprise et vérifier l’origine attendue. Demander le statut de l’autorisation d’origine de route, le processus de lettre d’autorisation et les règles de notification pour un changement d’origine ou de fournisseur d’accès. Deuxièmement, tracer les chemins depuis les principaux bureaux du client, les utilisateurs distants et les partenaires d’intégration clés à plusieurs moments de la journée.

Troisièmement, provoquer la panne de connectivité convenue: désactiver le tunnel ou circuit principal, mesurer la reconvergence, confirmer que la surveillance remarque l’événement et vérifier que les charges de travail restaurées sont joignables par le chemin secondaire. Quatrièmement, distinguer l’Internet public, la connectivité privée, la réplication et les réseaux de gestion. Un fournisseur peut avoir deux opérateurs Internet tandis qu’un client a encore un seul chemin de reprise fragile.

La démarcation commerciale importe autant que la topologie. Le SLA d’Ebunti exclut les pannes au-delà de sa démarcation et de nombreuses causes tierces. Si un revendeur fournit le circuit, un pare-feu de bureau termine le tunnel et Ebunti fournit la machine virtuelle, une seule panne peut tomber entre trois files d’attente de support. La commande devrait nommer le point de démarcation, la partie responsable, la source de preuve et l’horloge pour chaque couche. AS265618 est précieux précisément parce qu’il rend une partie de cette chaîne observable. Il devrait être le début de la diligence, pas la fin.

La souveraineté des données mexicaine est une carte, pas une adresse

Ebunti commercialise une infrastructure au Mexique et au Panama et s’adresse à des clients recherchant un service local. Cela peut être précieux. La capacité locale peut réduire la latence, simplifier les visites sur site et la facturation, maintenir les connaissances opérationnelles dans le même fuseau horaire et donner au client une alternative pratique à l’exportation de chaque charge de travail vers une région lointaine. Mais « souverain » et « local » ne sont pas des attributs binaires conférés par un bureau mexicain ou une adresse IP.

Ce sont des propriétés d’un flux de données particulier, d’un arrangement juridique et d’une conception de contrôle.

La première raison est visible dans le propreavis de confidentialité mexicain d’Ebunti. Il énumère des fournisseurs de technologie notamment Microsoft, Google, AWS, Veeam et Wasabi, ainsi que des filiales d’Ebunti en Colombie, au Panama et aux États-Unis, parmi les destinataires ou sous-traitants possibles. Ce n’est pas une preuve que le contenu des charges de travail des clients est régulièrement envoyé à tous. Les avis de confidentialité couvrent généralement un large ensemble de processus métier, y compris les ventes, le support, l’analyse et l’administration. Cela montre pourquoi une promesse générale selon laquelle « les données restent au Mexique » doit être décomposée.

Pour chaque service, l’acheteur a besoin d’une matrice de localisation. Où sont les disques virtuels primaires? Où sont les blocs de sauvegarde, les réplicas et les copies d’archives? Où sont les clés de chiffrement, les bases de données du plan de gestion, les catalogues de tâches, les métriques de surveillance, les pièces jointes des tickets, les enregistrements de support et les journaux d’administration? À partir de quels pays le personnel privilégié peut-il se connecter? Un fournisseur reçoit-il des bundles de diagnostic? Un revendeur voit-il les métadonnées des locataires?

Si la réplication S3 est activée, le deuxième emplacement physique est-il au Mexique ou dans un autre pays? Une charge de travail peut rester à Guadalajara tandis que ses données de support, son service d’identité ou ses métadonnées de reprise traversent une frontière.

La loi mexicaine sur la protection des données rend les contrôles et la transparence conséquents sans transformer chaque charge de travail du secteur privé en mandat de localisation universel. LaLoi fédérale sur la protection des données personnelles détenues par des particuliers, publiée en 2025 et modifiée depuis, exige que les responsables maintiennent des mesures de sécurité administratives, techniques et physiques et notifient les personnes concernées en cas de violations importantes. Elle réglemente également les transferts de données et l’avis de confidentialité. Les obligations exactes dépendent des rôles, des données et du secteur, donc un acheteur devrait obtenir un avis juridique pour sa situation plutôt que de se fier à un slogan cloud. Lanorme de confidentialité cloud NMX-I-27018 du Mexiqueoffre un point de référence supplémentaire pour la protection des données personnelles dans le traitement cloud public, mais l’existence d’une norme n’est pas une preuve que Ebunti y est certifié.

La deuxième raison est la concurrence. Les grands fournisseurs mondiaux proposent désormais des régions mexicaines.AWS a ouvert sa région Mexico Centralen janvier 2025 avec trois zones de disponibilité. Microsoft a annoncé l’exploitation de sarégion cloud Mexico Centralen 2024, etGoogle Cloud a ouvert une région à Querétaroplus tard la même année. La substitution locale n’est plus un simple choix entre un fournisseur mexicain et une région étrangère à des milliers de kilomètres. C’est un choix entre une capacité physique locale, différents plans de contrôle, différentes structures de support et différents leviers contractuels.

La distinction potentielle d’Ebunti n’est donc pas un drapeau planté sur un serveur. C’est la possibilité de combiner une infrastructure mexicaine, un réseau local visible, une continuité centrée sur Veeam, un support opérationnel en espagnol et des relations de canal en un service qu’une PME peut effectivement exploiter. Cela peut être plus utile pour une entreprise avec trois administrateurs qu’un vaste catalogue hyperscale. Cela peut aussi introduire de la concentration: le même fournisseur peut exploiter l’environnement de production, le référentiel de sauvegarde, le site de reprise et le support de premier niveau.

Une défaillance de contrôle ou un différend commercial peut alors toucher chaque copie.

La solution pour l’acheteur n’est pas de rejeter automatiquement la concentration. C’est de définir la souveraineté dans des déclarations testables. Les données de production seront stockées sur des sites mexicains nommés. Les données de sauvegarde resteront dans les juridictions déclarées. L’accès privilégié sera journalisé et limité à des emplacements de support nommés. Les sous-traitants seront listés, les changements notifiés et les transferts transfrontaliers documentés. Des clés détenues par le client seront utilisées là où c’est faisable.

Au moins une copie de reprise ou un chemin d’exportation sera en dehors du domaine de défaillance administrative du fournisseur. Ces déclarations appartiennent à la commande et au planning d’architecture. Sans elles, « cloud mexicain » décrit une position de marché, pas un contrôle.

La reprise est une chorégraphie chronométrée, pas un logo de sauvegarde

L’histoire commerciale la plus forte d’Ebunti est la reprise, et la reprise est là où les affirmations générales deviennent mesurables. Sapage Sauvegarde en tant que servicedécrit l’automatisation basée sur Veeam, les tâches surveillées, le chiffrement et les options de restauration. Sapage Reprise après sinistre en tant que servicepromeut le basculement, le retour arrière et les tests automatisés, avec une reprise mesurée en minutes plutôt qu’en heures. Sapage protection Microsoftdécrit une protection par utilisateur pour Microsoft 365. Lapage S3promeut un stockage compatible, le chiffrement et une revendication de durabilité très élevée. Ce sont des descriptions utiles de l’intention. Ce ne sont pas une conception de reprise pour un client nommé.

La conception commence par deux horloges. L’objectif de point de reprise demande la quantité de données récentes qui peuvent être perdues; l’objectif de temps de reprise demande combien de temps un service défini peut rester indisponible. Les deux nécessitent un périmètre. Un point de reprise de cinq minutes pour une base de données est sans signification si son filestore est copié toutes les quatre heures. Un temps de reprise d’une heure pour les machines virtuelles n’est pas un temps de reprise d’une heure pour le processus de commande à encaissement.

Le chronomètre peut démarrer lorsque la panne se produit, lorsque la surveillance la détecte, lorsque le client ouvre un ticket de gravité un valide ou lorsque le fournisseur accepte une déclaration de sinistre. Chaque interprétion produit un service différent.

Veeam fournit des blocs de construction crédibles, mais sa documentation expose aussi des choix de conception. Un fournisseur Cloud Connect peut offrir des référentiels hébergés et des ressources de réplication à partir de ses propres ressources de calcul, de stockage et de réseau. Les directives de Veeam sur lesréférentiels clouddécrivent la séparation logique des locataires et les options de référentiel. L’immuabilité est configurée pour un référentiel, avec des conséquences pour les locataires le partageant. Leslimitations de Cloud Connectde Veeam identifient des restrictions autour des opérations de récupération, des appliances réseau et des types de charge de travail protégés. Sesdirectives d’immuabilité du stockage objetexpliquent que, pendant la fenêtre de rétention, les données protégées ne peuvent pas simplement être supprimées — même par le personnel de support ayant accès.

Ces capacités créent les bonnes questions pour Ebunti. Le référentiel de sauvegarde principal du client est-il immuable, et pour combien de temps? L’immuabilité est-elle appliquée à une couche de stockage en dehors des identifiants utilisés pour administrer la production? Un administrateur locataire peut-il raccourcir la rétention? Les sauvegardes de configuration et les clés de chiffrement sont-elles protégées séparément? La cible de reprise est-elle déjà provisionnée ou assemblée après la déclaration? Comment les catastrophes client qui se chevauchent sont-elles priorisées?

La planification de la capacité suppose-t-elle qu’un locataire tombe en panne, qu’un site tombe en panne ou qu’un événement régional affecte de nombreux locataires? Quels types de charge de travail ne peuvent pas utiliser le chemin de reprise annoncé?

Un environnement Odoo montre pourquoi les questions sont pratiques. Le test devrait commencer par une sauvegarde cohérente au niveau applicatif de PostgreSQL et du filestore, plus le code personnalisé, la configuration, les secrets et les points d’intégration exacts requis par cette version. L’équipe devrait enregistrer une transaction, introduire un événement de corruption contrôlé et restaurer dans un réseau isolé.

Les utilisateurs devraient se connecter, localiser la transaction, en créer une nouvelle, envoyer un message de test, générer un rapport et exercer une intégration fiscale ou de paiement critique via un point de terminaison de test sûr. Ensuite, le DNS, les certificats et l’identité devraient passer à l’environnement de reprise. Enfin, l’équipe devrait effectuer un retour arrière sans perdre les transactions créées pendant la reprise.

Cet exercice mesure plus que le stockage. Il mesure si le service desk peut identifier le bon point de restauration, si la politique réseau suit la charge de travail, si une base de données et un filestore restent cohérents, si les licences survivent à des identifiants matériels modifiés, si les listes blanches tierces acceptent les adresses de reprise et si le client a suffisamment de connaissances applicatives pour déclarer le succès. Il révèle également des lacunes de responsabilité.

Si Ebunti restaure les machines virtuelles mais que le partenaire Odoo valide les modules, le runbook doit indiquer quand l’horloge de reprise s’arrête et quelle partie possède la coordination.

Les PME sont particulièrement vulnérables à la distinction entre « sauvegarde terminée » et « activité récupérée ». Elles peuvent ne pas avoir de deuxième équipe d’infrastructure, d’environnement d’identité de rechange ou de carte applicative récente. La reprise gérée peut être précieuse parce qu’elle fournit la répétition et l’expertise que le client ne peut pas conserver économiquement. Cela rend les preuves de tests antérieurs plus importantes, pas moins.

L’acheteur devrait demander des rapports de réussite des tâches, la fréquence des tests de restauration, la gestion des exceptions, les preuves de reprise, la propriété nommée du runbook et un exemple de rapport post-test. Un tableau de bord vert de sauvegarde est une entrée. Un exercice réussi, chronométré et validé au niveau applicatif est le produit.

Le langage public devrait également être séparé en durabilité, disponibilité et récupérabilité. La page S3 d’Ebunti présente une revendication de « onze neuf », une formulation couramment associée à la durabilité annuelle des objets. Ce n’est pas onze neuf de disponibilité de service, ne garantit pas qu’une application peut lister ou récupérer un objet à tout moment, et ne définit pas les domaines de défaillance derrière un bucket particulier. La commande devrait identifier la métrique applicable, la méthode de mesure, la politique de réplication, le versioning, l’immuabilité, la protection contre la suppression et le crédit.

De même, une promesse de reprise en minutes a besoin d’un niveau de charge de travail, d’un volume de données, d’une condition de départ et d’un résultat de test. Sinon, les verbes les plus convaincants du site restent des aspirations.

La page de statut publique change la conversation de diligence

De nombreux fournisseurs régionaux publient peu de preuves opérationnelles. Lapage de statut publique d’Ebuntiest donc un signal positif significatif. Elle expose des moniteurs pour l’infrastructure mexicaine et panaméenne, un portail VMware et un service S3. Un acheteur peut voir que l’entreprise est prête à placer au moins une partie de la santé de ses services en vue publique.

La même page rend les affirmations simplistes de disponibilité plus difficiles à accepter. Au gel des preuves du 18 juillet 2026, la page indiquait que certains services étaient en panne. Sur sa fenêtre de 90 jours affichée, elle montrait environ 99,587 % pour Mexico POD-1, 96,804 % pour Mexico POD-2, 98,477 % pour Panama POD-1, 99,962 % pour le portail VMware Mexico et 98,894 % pour S3 Mexico. La page montrait une interruption de plusieurs heures pour Mexico POD-2 le 17 juillet et plusieurs interruptions S3 antérieures.

Selon l’intervalle de surveillance, un résultat de 96,804 % sur 90 jours correspond à environ 69 heures en dehors de l’état de réussite du moniteur.

Ces chiffres ne doivent pas être présentés comme des résultats SLA clients. Un moniteur public peut tester un point de terminaison, être affecté par la maintenance, rester actif après une migration de service ou tomber en panne alors que les charges de travail des clients continuent. Inversement, un point de terminaison vert peut manquer une latence de stockage, une panne partielle de locataire, une perte de paquets, une tâche de sauvegarde échouée ou une panne applicative.

Les archives d’incidents publics d’Ebunti n’affichaient aucun récit d’incident pour plusieurs périodes pendant lesquelles l’historique du moniteur montrait des temps d’arrêt. Cela peut refléter la différence entre les événements du moniteur et les incidents déclarés, mais l’absence d’explications empêche un acheteur externe de concilier les deux.

Lecontrat de niveau de servicecrée une autre couche. Il énonce un objectif de disponibilité mensuel d’au moins 99,5 % pour les services couverts. Pourtant, son tableau de crédits commence par une bande en dessous de 99,9 % et au-dessus ou égal à 99,0 %, un décalage apparent qui devrait être clarifié dans la commande. Il définit l’indisponibilité de manière étroite: toutes les instances ou tâches en cours d’exécution d’un client doivent simultanément manquer de connectivité externe. Un ralentissement de stockage, une machine virtuelle en panne, une panne du portail de gestion, une sauvegarde manquée ou une panne applicative peuvent ne pas correspondre à cette définition.

Les crédits sont appliqués aux paiements futurs plutôt que remboursés, et le client doit soumettre une réclamation détaillée via le portail de support avant la fin du deuxième cycle de facturation après l’événement. Le SLA exclut les événements hors du contrôle raisonnable d’Ebunti, les conditions Internet hors de sa démarcation, les actions du client et des tiers, certaines technologies tierces et les suspensions autorisées par le contrat. Les crédits sont le seul recours déclaré en cas de non-respect du niveau de service.

Un client qui ne conserve pas les horodatages, les tickets et les preuves pourrait subir une panne réelle mais ne recevoir aucun crédit.

L’arithmétique donne au contrat une signification pratique. Un objectif mensuel de 99,5 % permet environ trois heures et 39 minutes d’indisponibilité dans un mois moyen avant que l’objectif ne soit manqué. Que cela soit adapté dépend de l’application. Une archive de paie peut le tolérer. Un système de point de vente ou de contrôle logistique peut ne pas le tolérer. Plus important encore, la définition contractuelle peut compter moins de pannes que celles que l’entreprise subit.

Un acheteur compétent ne devrait pas utiliser la page publique pour condamner le fournisseur, ni l’ignorer. Il devrait demander à Ebunti de mapper chaque moniteur à un service et un emplacement, d’expliquer les conditions de juillet 2026, de divulguer le traitement de la maintenance programmée et de fournir des rapports de disponibilité spécifiques au client. La commande devrait ajouter des mesures de composants et de charges de travail là où nécessaire: achèvement des tâches de sauvegarde, âge du point de restauration, latence de stockage, accès au portail, décalage de réplication et succès des tests de reprise.

Le rapport d’incident devrait indiquer la gravité, le service affecté, la chronologie, la cause, l’action corrective et si l’horloge SLA a tourné. Publier la télémétrie est la première moitié de la transparence. Expliquer ce qu’elle mesure et ce qui a changé est la seconde.

Le support fait partie du plan de contrôle d’Ebunti

Pour une PME, le support peut être la principale raison de choisir Ebunti plutôt qu’une infrastructure autogérée. Un cloud mondial peut fournir une automatisation approfondie et une documentation extensive, mais le client possède toujours l’architecture, la surveillance et une grande partie de la coordination des incidents. La proposition d’Ebunti est qu’un spécialiste local et son canal peuvent absorber davantage de cette charge opérationnelle.

Son site web présente répétément une couverture 24 heures, et ses entretiens avec des partenaires mettent l’accent sur l’habilitation des revendeurs qui peuvent ne pas avoir leur propre plateforme de sauvegarde ou de reprise.

Le contrat-cadre révèle la frontière la plus importante. Un client direct contracte avec Ebunti. Un client de canal contracte avec le partenaire autorisé, et le contrat dit qu’Ebunti n’a aucune relation directe de facturation, de garantie ou de support avec ce client final à moins qu’un accord écrit séparé ne stipule le contraire. Cela peut être une structure de distribution sensée, mais cela change la chaîne de reprise. Le client final peut croire qu’Ebunti exploite son service alors que la première obligation contractuelle repose sur un revendeur.

Chaque commande devrait donc nommer le propriétaire du support pour chaque tâche. Qui surveille les tâches échouées? Qui reçoit une alerte automatique? Qui peut déclarer un sinistre? Qui a l’autorisation de démarrer un basculement? Qui valide une application? Qui coordonne Veeam ou VMware? Qui communique avec l’entreprise? Un organigramme des responsabilités devrait inclure Ebunti, le revendeur, le client, l’implémenteur logiciel et tout fournisseur de connectivité. Il devrait identifier un seul chef d’incident pour le service combiné.

La définition du service devrait rendre « 24/7 » mesurable. Une fonction d’exploitation dotée en personnel surveille-t-elle l’environnement en continu, ou un appelant peut-il simplement ouvrir un ticket à toute heure? Quels sont les intervalles de réponse, d’engagement et de mise à jour pour chaque gravité? Une escalade téléphonique est-elle disponible? Des ingénieurs hispanophones sont-ils disponibles toute la nuit? Quelles conditions permettent un accès administratif à distance? Comment les modifications d’urgence sont-elles approuvées et enregistrées?

Lorsqu’un problème appartient à un fournisseur, Ebunti reste-t-elle responsable de la coordination ou donne-t-elle un numéro de dossier au client?

La mise en œuvre mérite une spécificité égale. Le client devrait recevoir un résultat de découverte, une carte des dépendances, une conception réseau et d’identité, une politique de protection, un plan de copie initiale complète, une estimation de bande passante, un runbook de reprise et un test d’acceptation. Les transferts de sauvegarde initiaux importants peuvent nécessiter un ensemencement; la restauration rapide peut nécessiter un support physique ou une capacité locale. Ebunti fait la publicité de ces options, mais la commande doit définir la logistique, la garde, le chiffrement et le calendrier.

Un service bien supporté après activation peut échouer parce que l’intégration a omis une base de données, un module personnalisé ou un identifiant d’administrateur.

La meilleure preuve serait opérationnelle: des échantillons de rapports anonymisés, une démonstration d’escalade de ticket, un exercice de reprise observé et des références de clients avec des charges de travail comparables. Les déclarations d’effectifs et de bureaux peuvent indiquer une capacité mais ne prouvent pas la couverture. Le support devient un plan de contrôle seulement lorsque les responsabilités, l’autorité et les preuves couvrent le fournisseur, le canal et le client. Sinon, c’est une autre entrée de catalogue.

La grille tarifaire publique est le début du coût, pas le prix

Le site web d’Ebunti comprend un calculateur inhabituellement accessible libellé en dollars américains. Au gel des preuves, il montrait des minimums indicatifs de 99 $ par mois pour BaaS, 150 $ pour IaaS, 30 $ pour la protection Microsoft et 25 $ pour S3. Les valeurs unitaires affichées incluaient 0,23 $ par gigaoctet et 11 $ par machine virtuelle pour BaaS; 16 $ par CPU virtuel, 13 $ par gigaoctet de mémoire, 0,12 $ par gigaoctet de stockage haute vitesse et 10 $ par IP publique pour IaaS; 2,90 $ par utilisateur pour la protection Microsoft; et 0,23 $ par gigaoctet pour S3.

Le calculateur lui-même avertit que le prix final varie en fonction du volume, de la durée et des exigences.

Ces chiffres sont utiles pour l’orientation, mais le devis signé fait foi. Un acheteur doit savoir si la capacité protégée est mesurée avant ou après compression et déduplication, si le chiffre de stockage est mensuel, quel trafic et quelles opérations sont facturés, quelles licences sont incluses, combien de tests de restauration sont couverts et si le support, l’intégration ou les services professionnels sont séparés. Les chiffres publics peuvent sinon produire des combinaisons qui semblent précises tout en cachant les principaux facteurs de coût.

Lecontrat-cadrefournit la gravité commerciale. Il stipule que la durée initiale est d’au moins 12 mois sauf indication contraire dans une commande. Les services se renouvellent pour des périodes égales sauf si un préavis est donné au moins 60 jours avant l’expiration. Ebunti peut augmenter les prix de renouvellement jusqu’à huit pour cent avec préavis; une augmentation plus élevée nécessite un consentement. Pendant une durée, un client peut réduire une ressource individuelle d’au plus 20 pour cent, et une réduction n’abaisse pas l’engagement minimum. Les augmentations sont autorisées sous réserve de disponibilité.

La sortie anticipée est plus conséquente. Si un client résilie pour commodité, le contrat rend les frais restants pour la durée exigibles. Ebunti peut résilier pour commodité avec un préavis de 30 jours, tandis que la résiliation pour cause par un client est liée à des conditions spécifiques et des périodes de réparation. Le non-paiement peut entraîner une suspension après 15 jours et une accélération de l’engagement restant après 30 jours. Après la résiliation, le client dispose de 30 jours pour télécharger son contenu avant que le fournisseur ne puisse le supprimer.

Pour les services mexicains, le plafond général de responsabilité est les frais payés au cours des trois mois précédents, sous réserve des détails du contrat et de la loi applicable.

Ces conditions ne rendent pas le service particulièrement peu attrayant; les engagements, les recours par crédit et les plafonds de responsabilité sont courants dans les contrats cloud. Elles créent néanmoins une asymétrie qui devrait être évaluée. Un client peut devoir près d’un an de frais restants, n’avoir qu’un mois pour extraire les données et ne récupérer tout au plus qu’une petite fraction des dépenses annuelles pour de nombreuses réclamations. Pendant ce temps, le déplacement d’un important corpus de sauvegarde ou la reconstruction d’un environnement de reprise peut prendre plus de 30 jours.

La comparaison pertinente est le coût total de la continuité. Il comprend l’infrastructure, le stockage, les licences, le transfert réseau, les adresses publiques, la surveillance, le support, l’ensemencement initial, les exercices de reprise périodiques, le travail professionnel d’urgence et la sortie. Il comprend également la main-d’œuvre du client. Un service géré peut rester moins cher que d’embaucher suffisamment de personnes pour bien l’exploiter, même si son prix unitaire dépasse la capacité hyperscale brute. Inversement, un faible taux de stockage peut être coûteux si les restaurations, le trafic et l’assistance sont exclus.

Avant de signer, un acheteur devrait négocier une grille tarifaire complète et trois scénarios: l’état d’équilibre, un sinistre déclaré et la sortie. Il devrait plafonner ou définir les augmentations de renouvellement, aligner la fenêtre de non-renouvellement sur le budget, permettre la réduction lorsque les charges de travail disparaissent, prolonger la période d’exportation lorsque le volume de données le nécessite et indiquer les formats, la bande passante et l’assistance.

Il devrait exiger un accès en lecture continu pendant un différend de facturation de bonne foi et protéger les données de reprise contre la suppression pendant la résolution d’un différend. Le prix n’est pas le nombre à côté d’un gigaoctet. C’est le coût de la conservation du choix opérationnel.

Les badges de sécurité ne peuvent pas remplacer un planning de contrôle

Le site actuel d’Ebunti affiche des signaux de sécurité et de gestion de services, notamment une revendication à l’ISO/IEC 20000-1:2018 et une relation Platinum avec Veeam. La récompense régionale Veeam est indépendamment visible sur le site du fournisseur et indique une participation significative à cet écosystème. Ce sont des raisons légitimes de prendre le fournisseur au sérieux. Elles répondent à des questions plus étroites que ce qu’un acheteur peut supposer.

La description de l’ISO pour ISO/IEC 20000-1:2018concerne les exigences pour un système de gestion de services. Ce n’est pas la même norme queISO/IEC 27001, qui traite d’un système de management de la sécurité de l’information. Une bonne gestion de services peut améliorer les processus d’incident, de changement et de fournisseur, mais un logo ne dit pas à un acheteur quelle entité juridique et quels sites ont été certifiés, le périmètre des services, l’organisme de certification, le statut actuel du certificat ou les exclusions. Aucun certificat public portant ces détails n’a été localisé dans les sources gelées. L’acheteur devrait le demander et vérifier l’émetteur, l’accréditation, le périmètre, le titulaire, la validité et la surveillance la plus récente.

Le planning de contrôle devrait ensuite traiter les voies de menace réelles du client. L’accès administratif nécessite une authentification multifacteur résistante au hameçonnage, une séparation des rôles, des privilèges limités dans le temps et une journalisation. Le personnel du fournisseur ne devrait pas utiliser le même domaine d’identité ou les mêmes identifiants qu’un ransomware peut compromettre chez le client. La suppression des sauvegardes, les changements de rétention et l’accès aux clés devraient nécessiter des contrôles plus stricts que le travail de restauration de routine.

La gestion réseau, la gestion de la virtualisation, le stockage et l’orchestration de sauvegarde devraient occuper des zones de confiance séparées. Les journaux devraient quitter le système qu’ils surveillent et être conservés suffisamment longtemps pour enquêter sur une intrusion.

L’immuabilité mérite une précision particulière. Une fonctionnalité compatible Veeam ou un verrouillage d’objet S3 ne peut résister à la suppression que dans ses conditions configurées. L’acheteur a besoin de la fenêtre de rétention, de la source d’horloge, du paramètre de gouvernance ou de conformité, des capacités de l’administrateur, du type de référentiel et de la preuve d’une tentative de suppression délibérée. Il devrait déterminer si un administrateur de stockage, un administrateur cloud et un administrateur de sauvegarde peuvent colluder via un seul système d’identité.

Au moins une copie devrait résister à la compromission des voies d’administration de production et de sauvegarde ordinaires.

La clause d’incident doit relier les opérations techniques aux obligations de confidentialité mexicaines et aux obligations sectorielles. Elle devrait définir quand Ebunti notifie le client, quelles informations suivent, comment les preuves sont préservées et comment les sous-traitants participent. L’avis de confidentialité promet des mesures raisonnables et identifie de vastes finalités de traitement, mais il ne fournit pas d’architecture de sécurité spécifique au client.

Un acheteur réglementé peut également avoir besoin de résumés de tests de pénétration, de fenêtres de correction des vulnérabilités, de contrôle du personnel, d’élimination sécurisée des supports, de résultats de continuité d’activité et de preuves d’assurance cyber.

Les services de cybersécurité créent une frontière supplémentaire. Un fournisseur peut revendre ou gérer des produits de sécurité sans assumer la responsabilité de la sécurité globale du client. La commande devrait séparer la sécurité du cloud d’Ebunti des services de sécurité optionnels fournis au client. Elle devrait indiquer quelles alertes sont surveillées, qui enquête, quelle réponse est incluse et où résident les journaux. Un langage vague comme « protégé par une technologie de pointe » ne peut pas définir la responsabilité.

La conclusion juste n’est pas qu’Ebunti manque de contrôles. Les preuves publiques sont insuffisantes pour les évaluer au niveau nécessaire pour une charge de travail critique. Le statut de partenaire, un réseau enregistré, la télémétrie publiée et une norme de gestion de services affirmée sont des points de départ crédibles. Un pack de certificats, un atelier d’architecture, des preuves de contrôle et un test de reprise en direct doivent compléter le tableau.

La substitution locale concurrence désormais trois régions hyperscale mexicaines

L’arrivée des infrastructures AWS, Microsoft et Google au Mexique modifie la question concurrentielle d’Ebunti. Un acheteur peut rechercher une résidence des données locale auprès d’une plateforme mondiale, souvent dans plusieurs zones de disponibilité, tout en conservant l’accès à de vastes services d’identité, de sécurité, d’analyse et d’automatisation. Ebunti ne peut pas gagner simplement en disant que le cloud étranger est éloigné.

Elle peut concurrencer sur une unité de valeur différente. Une petite entreprise veut rarement une zone de disponibilité; elle veut que la paie fonctionne après une attaque. Elle peut valoriser une équipe hispanophone qui connaît son parc VMware, un partenaire de canal qui soutient déjà ses bureaux, un package de reprise prévisible et la possibilité de parler aux personnes qui exploitent la plateforme. L’ASN visible d’Ebunti, sa spécialisation Veeam et son mix de services peuvent soutenir cette position. Son histoire de fournisseur avec Softtek suggère également une expérience de travail avec des partenaires à une échelle significative.

Le compromis est la largeur et la concentration. Un hyperscaler offre plus de régions, une automatisation plus profonde, un choix de place de marché plus large et un investissement de sécurité important, mais peut laisser l’architecture et le contrôle des coûts au client. Ebunti peut assembler et exploiter une pile plus étroite, mais le client peut dépendre d’un seul fournisseur pour l’infrastructure, la sauvegarde, la reprise, le réseau et l’escalade. La région locale d’un hyperscaler peut encore reposer sur des services de gestion mondiaux; un fournisseur régional peut encore utiliser des fournisseurs mondiaux et un support transfrontalier.

Aucune étiquette ne répond à elle seule à la souveraineté.

Une comparaison sérieuse devrait utiliser la même charge de travail et le même test d’acceptation. Évaluer l’environnement de production, la copie immuable, le deuxième domaine de défaillance, la surveillance, le support et deux exercices de reprise annuels sur les deux voies. Mesurer la latence des utilisateurs réels et des intégrations. Tester la reprise à partir d’identifiants compromis. Identifier la personne qui coordonne l’ensemble de l’incident. Cartographier tous les emplacements de données et de gestion. Calculer le temps et les frais de sortie.

La conception gagnante peut être Ebunti, un hyperscaler avec un partenaire géré, ou un hybride dans lequel l’un détient la production et l’autre une copie indépendante.

Cet hybride mérite l’attention. Si Ebunti exécute la production et que le seul référentiel de reprise est également sous son administration, le client a une concentration de fournisseur. Si la production s’exécute ailleurs et qu’Ebunti détient une copie protégée et une cible de reprise, Ebunti devient une alternative de continuité locale plutôt qu’une substitution complète. Inversement, un client peut utiliser l’infrastructure d’Ebunti tout en exportant une copie de reprise indépendante. La proposition de cloud local la plus forte n’est peut-être pas « remplacer tout ».

Elle peut être « créer un chemin opérationnel mexicain récupérable qui ne partage pas chaque panne avec l’opérateur historique ».

Les coûts de changement se cachent dans le chemin de reprise

La sortie du cloud est souvent réduite au transfert de données. Pour un client d’Ebunti, le coût de changement peut s’accumuler à plus d’endroits. Les machines virtuelles peuvent être conçues autour de VMware. L’historique des sauvegardes, les catalogues et les chaînes de rétention peuvent dépendre de Veeam. La politique de pare-feu, les adresses publiques, le DNS et les circuits partenaires peuvent pointer vers l’infrastructure du fournisseur. Les applications compatibles S3 peuvent reposer sur un comportement qui diffère aux marges entre les implémentations.

Les permissions de restauration et les choix de rétention Microsoft 365 peuvent résider dans une console gérée par le fournisseur. Les runbooks de reprise peuvent exister principalement dans la tête des personnes qui les exploitent.

Le client ne possède pas AS265618 simplement parce que son service utilise une adresse annoncée par ce réseau. Le déménagement peut nécessiter de nouvelles adresses publiques et des mises à jour des listes blanches, du DNS, des certificats, des systèmes partenaires et des règles de sécurité. Si un environnement Odoo a des modules personnalisés, des pièces jointes et des intégrations, exporter uniquement sa base de données ne suffit pas. Si les clés de chiffrement ou les métadonnées de sauvegarde sont inaccessibles, une copie des blocs de stockage peut ne pas être facilement récupérable ailleurs.

La période de téléchargement de 30 jours après résiliation du contrat rend ces dépendances concrètes. Un corpus de plusieurs téraoctets sur une liaison limitée peut consommer une grande partie de cette fenêtre. Restaurer l’intégralité de l’historique de rétention dans un autre environnement Veeam peut nécessiter des versions compatibles, un accès au référentiel et une assistance opérationnelle. Une politique de rétention immuable peut compliquer le calendrier de suppression même lorsque le client a besoin d’exportations utilisables.

La commande devrait donc préciser ce que signifie « télécharger »: fichiers de sauvegarde natifs, images de disque virtuel, dumps de base de données, versions d’objets, exportations de configuration, journaux, clés et documentation.

Un test de sortie devrait avoir lieu avant la production et ensuite chaque année. Exporter une machine représentative, une base de données, un ensemble de données S3 et un élément Microsoft 365 via le chemin prévu par le client. Les dans un environnement non contrôlé par Ebunti. Mesurer le temps, les frais et le travail du fournisseur. Vérifier que le client peut obtenir sa configuration et son historique de reprise. Confirmer comment les données sont détruites de manière sécurisée après les périodes de rétention et de conservation légale, et demander une preuve de destruction.

Le coût de changement n’est pas intrinsèquement mauvais. Il peut être le résidu d’une intégration précieuse et d’une expertise gérée. Il devient dangereux lorsqu’il est découvert lors d’un différend ou d’une panne. Un acheteur qui évalue et répète la sortie peut accepter un engagement long en toute connaissance de cause. Celui qui se fie à un langage générique de portabilité a transféré plus de contrôle que la facture ne le révèle.

Une preuve de 30 jours peut transformer les affirmations d’Ebunti en un service

Les preuves soutiennent un pilote discipliné plutôt qu’un oui ou non immédiat. Trente jours suffisent pour tester la chaîne avec une charge de travail représentative si le fournisseur et le client préparent les données, l’accès et les décideurs à l’avance.

Pendant les jours un à cinq, régler l’identité et le périmètre. Le vendeur devrait fournir le document corporatif mexicain actuel, le RFC, l’avis et les adresses de service, la preuve de la relation de nom DRP vers Ebunti, et une explication de l’entité qui détient ou exploite AS265618. Le projet de commande devrait identifier les entités contractante, de facturation, de traitement des données, d’exploitation de l’infrastructure et de support. Si un revendeur est impliqué, il devrait signer un planning de responsabilités avec Ebunti et le client.

ARTEM ne devrait pas apparaître dans le périmètre à moins qu’une relation documentée et une responsabilité précise ne soient fournies.

La même phase devrait figer la définition de la charge de travail. Sélectionner une application avec une base de données, des fichiers, une authentification, une intégration externe et un objectif de reprise significatif. Un déploiement Odoo serait approprié si le client l’utilise effectivement, mais Odoo ne devrait pas être inclus simplement parce que le répertoire liste DRP Cloud México comme client. Inventorier le volume de données, le changement quotidien, les transactions de pointe, les dépendances, les ports requis, les identités, les certificats, les versions logicielles, les licences et les étapes de validation métier.

Définir le point de reprise et le temps de reprise de l’événement métier au service accepté, pas simplement de l’acceptation du ticket à la machine virtuelle sous tension.

Pendant les jours six à dix, cartographier l’architecture et la souveraineté. Ebunti devrait fournir un diagramme spécifique au client montrant la production, les référentiels, les cibles de réplication, les systèmes de gestion, les réseaux, les chemins de support et les fournisseurs externes. Chaque composant devrait avoir un pays, un site ou une région, un opérateur, un contrôleur juridique, un état de chiffrement et un domaine de défaillance. Le diagramme devrait distinguer les privilèges du client, du revendeur, d’Ebunti et des fournisseurs.

Le client devrait le comparer avec la liste des fournisseurs de l’avis de confidentialité et documenter tout accès aux données ou support en dehors du Mexique.

Les tests réseau devraient s’exécuter en parallèle. Vérifier l’origine de la route publique, l’autorisation de route, les fournisseurs d’accès attendus et les points de terminaison du client. Mesurer la latence, la gigue, la perte de paquets et le débit depuis des emplacements réels. Désactiver un tunnel principal ou un circuit convenu et observer le basculement, la surveillance et la création de ticket. Confirmer si le réseau de reprise utilise un chemin indépendant.

Si IPv6 importe pour l’application ou la politique d’approvisionnement, obtenir une conception prise en charge ou une feuille de route datée plutôt que de supposer que l’observation publique de l’ASN raconte toute l’histoire.

Pendant les jours onze à vingt, attaquer les hypothèses de reprise. Ensemencer la charge de travail, enregistrer la durée de sauvegarde de base et confirmer que les pannes créent des alertes exploitables. Tenter un changement de rétention et une suppression non autorisés en utilisant les rôles les plus susceptibles d’être compromis. Créer des transactions connues, corrompre ou isoler la production, et demander à l’équipe de service de sélectionner un point de restauration propre. Récupérer dans un réseau ségrégué sans faire confiance au système d’identité de production compromis.

Tester l’application, les intégrations et le reporting par rapport à un script d’acceptation écrit.

Ensuite, déclarer un événement de reprise. Mesurer séparément la détection, l’accusé de réception, l’engagement de l’ingénieur, la restauration des données, le basculement réseau, la validation applicative et l’acceptation métier. Continuer à fonctionner suffisamment longtemps pour créer de nouvelles transactions sur le site de reprise. Effectuer un retour arrière et prouver que ces transactions survivent. Enregistrer le point et le temps de reprise atteints, chaque dépendance manuelle, contrainte de capacité et droit de décision.

Répéter une étape échouée après avoir changé une personne sur le quart de travail de support; un runbook qui fonctionne uniquement avec son auteur n’est pas résilient.

Pendant les jours vingt et un à vingt-cinq, tester le support et la sécurité. Ouvrir des tickets de faible, haute et critique gravité via les canaux que le contrat couvre effectivement. Escalader un après l’intervalle promis. Demander au revendeur et à Ebunti séparément qui possède l’action suivante et comparer les réponses. Inspecter les journaux d’accès pour l’exercice de reprise, les attributions de rôles privilégiés, les contrôles multifacteur, les enregistrements d’approbation et la preuve que les chemins de gestion et de sauvegarde sont séparés.

Examiner le certificat ISO/IEC 20000-1 revendiqué plutôt qu’un logo: titulaire, périmètre, sites, émetteur, accréditation, validité et surveillance. Obtenir un pack de contrôles de sécurité approprié au risque, incluant la gestion des vulnérabilités, la notification d’incident, la gouvernance des sous-traitants, l’élimination des supports et les tests de continuité. Vérifier l’immuabilité du référentiel avec un résultat technique, pas un nom de produit. Si un service de surveillance de cybersécurité est inclus, injecter une alerte de test sûre et la suivre de la détection à la communication client.

Pendant les jours vingt-six à trente, tester l’économie et la sortie. Concilier le calculateur public avec un devis signé pour la consommation mesurée du pilote. Ajouter les licences, le transfert, le support, les exercices de reprise, l’intégration et le travail professionnel. Évaluer un sinistre déclaré et une sortie anticipée. Demander au fournisseur d’exporter une machine virtuelle représentative, une base de données, un ensemble d’objets, une configuration et un pack de journaux. Les en dehors de son administration. Mesurer le taux de transfert et calculer si l’ensemble complet peut partir dans la fenêtre contractuelle.

La feuille d’acceptation finale devrait être binaire là où possible. L’identité juridique concorde ou ne concorde pas. Les emplacements des données sont nommés ou ne le sont pas. Une tentative de suppression a échoué pour la fenêtre immuable convenue ou a échoué. Une reprise a respecté l’horloge métier ou ne l’a pas fait. Un deuxième chemin réseau a fonctionné ou n’a pas fonctionné. La chaîne de support a atteint un ingénieur responsable ou ne l’a pas fait. L’exportation était utilisable ailleurs ou ne l’était pas.

L’incertitude résiduelle peut ensuite être évaluée, assurée, atténuée avec une copie indépendante ou transformée en condition avant la production.

Cette preuve n’est pas un approvisionnement hostile. Elle donne à Ebunti la chance de démontrer l’avantage opérationnel que sa marque promet. Un fournisseur géré local devrait être capable de surpasser un catalogue générique en matière de coordination, de contexte et de pratique de reprise. Le pilote mesure exactement ces forces.

Les preuves se répartissent dans quatre catégories différentes

Les faits vérifiés sont significatifs. DRP Cloud México a officiellement annoncé la marque Ebunti. Les enregistrements LACNIC actuels lient le nom juridique DRP et les contacts Ebunti à AS265618 et à une allocation d’adresse mexicaine. Un matériel universitaire indépendant utilise encore DRP Cloud México aux côtés d’Ebunti. Veeam a publiquement reconnu Ebunti comme un partenaire de premier plan en Amérique latine pour les fournisseurs de services. Ebunti publie des conditions juridiques, un SLA, une télémétrie de service et des pages produit identifiables.

Ces faits établissent une véritable activité avec des ressources réseau et une proposition centrée sur la continuité.

Les déclarations de l’entreprise forment un deuxième seau. Ebunti décrit de multiples emplacements en Amérique latine, un support 24 heures sur 24, des caractéristiques d’infrastructure spécifiques, une reprise rapide, une grande durabilité des objets, des pratiques de sécurité et des résultats clients. Ses études de cas et entretiens avec les dirigeants ajoutent des détails, et certains apportent un contexte client ou fournisseur nommé. Elles restent des déclarations qui doivent être testées pour le service de l’acheteur. Une capacité sur un site ou pour un client ne peut être présumée pour chaque devis.

Les inférences raisonnées forment le troisième seau. La combinaison d’un réseau enregistré, d’un statut Veeam, d’une structure de produit et de moniteurs de statut suggère qu’Ebunti exploite plus qu’un catalogue de revente sur papier. Son approche par canal pourrait donner aux PME une voie gérée pratique vers la sauvegarde et la reprise. Son contrôle de plusieurs couches pourrait accélérer la coordination des incidents. La même combinaison pourrait augmenter la concentration et le coût de changement. Ce sont des conclusions tirées des preuves jointes, pas des déclarations directes d’un régulateur ou d’un contrat client.

Les inconnues sont le programme d’approvisionnement. Les preuves publiques ne réconcilient pas la dernière dénomination juridique avec tous les enregistrements plus anciens et actuels. Elles ne prouvent pas une relation ARTEM. Elles ne montrent pas une implémentation Odoo ou une compétence d’hébergement.

Elles ne divulguent pas les sites de centre de données nommés et les domaines de défaillance pour chaque service, les emplacements de données spécifiques au client, la certification de sécurité complète, la politique de sursouscription, la capacité de reprise lors d’événements corrélés, le personnel de support exact, les récits de cause première pour l’historique visible du moniteur, ou la portabilité d’une chaîne de rétention complète.

Garder les seaux séparés empêche deux erreurs opposées. L’une est de rejeter un fournisseur régional parce qu’il manque du volume de divulgation d’un hyperscaler public. L’autre est de convertir chaque badge de partenaire et page produit en un contrôle supposé. Ebunti a fourni suffisamment de preuves pour mériter une diligence technique directe. L’acheteur doit fournir la discipline pour empêcher que ce qui est observé, affirmé, inféré et inconnu ne s’effondre en une seule histoire de vente.

Surveillez le nom, les moniteurs et l’indépendance de la copie de reprise

Le premier point de surveillance est l’identité corporative. Les factures futures, les avis juridiques, les enregistrements LACNIC et les annonces de partenaires devraient converger vers une dénomination documentée. Une mise à jour formelle du déclarant réseau, ou la preuve que DRP Cloud México reste le détenteur d’actifs tandis qu’Ebunti México contracte, changerait l’analyse des risques. La divergence continue n’est pas une preuve de mauvaise conduite, mais elle augmente le coût de l’application des responsabilités.

Le deuxième est la transparence opérationnelle. La page de statut d’Ebunti devrait être observée dans le temps. Les acheteurs devraient rechercher une disponibilité améliorée, des récits d’incidents durables et une cartographie claire entre les moniteurs et les services contractuels. Des archives silencieuses aux côtés de périodes rouges visibles sont moins utiles qu’une explication franche. Les modifications de l’objectif de 99,5 % du SLA, du seuil de crédit de 99,9 % et de la définition étroite de la connectivité simultanée seraient également importantes.

Le troisième est la maturité du réseau. AS265618 fournit une base pour surveiller les origines des préfixes, l’autorisation de route, les changements de fournisseurs d’accès et l’adoption d’IPv6. La croissance des préfixes n’est pas automatiquement une amélioration, et deux fournisseurs d’accès visibles ne sont pas automatiquement une diversité physique. Le signal pertinent est de savoir si le client peut vérifier des chemins indépendants et une réponse documentée aux incidents de routage.

Le quatrième est l’indépendance de la reprise. Étant donné que les ransomwares ciblent de plus en plus l’administration des sauvegardes, les acheteurs devraient surveiller si Ebunti publie des preuves plus claires sur l’immuabilité, l’identité isolée, la capacité intersite et les exercices de reprise. Une copie stockée dans une autre baie mais contrôlée par les mêmes identifiants compromis n’est pas un chemin de reprise indépendant. Un fournisseur régional qui peut démontrer une séparation administrative et géographique aura une réponse plus forte que celui qui ajoute simplement du stockage.

Le cinquième est l’adaptation concurrentielle. Les régions hyperscale mexicaines réduisent la force de la seule résidence. Ebunti devra montrer pourquoi sa couche d’exploitation gérée, sa chaîne de support et sa pratique de reprise surpassent l’alternative d’un client. Une documentation de service claire, des contrôles spécifiques au site, des prix transparents et une reprise portable pourraient devenir plus importants que l’ajout de logos supplémentaires au catalogue.

Enfin, surveiller un pont ARTEM documenté. Si un dépôt corporatif fiable, un avis d’acquisition, un partenariat signé ou une déclaration de service faisant autorité relie finalement ARTEM à DRP Cloud México ou Ebunti, son rôle peut être évalué à ce moment-là. Jusqu’à ce point, les affirmations cloud et Odoo d’ARTEM affaiblirait plutôt qu’enrichirait les preuves.

Le contrat est le produit cloud souverain

DRP CLOUD MEXICO SAPI DE CV n’est pas un nom vide derrière un site web. La transition DRP vers Ebunti est soutenue par une annonce officielle, des contacts réseau actifs, des références tierces et une activité de reprise cohérente. AS265618, la télémétrie de service publique et la reconnaissance Veeam donnent aux acheteurs des poignées observables que de nombreux fournisseurs locaux n’exposent pas.

Les questions ouvertes sont également réelles. Le nom juridique exact actuel n’est pas cohérent entre les registres publics. Le SLA mesure une condition plus étroite que ce que la plupart des entreprises entendent par disponibilité. Le contrat donne au devis une importance énorme et rend l’engagement, les réclamations et la sortie conséquents. La page de statut montre des conditions qui méritent une explication. Les pages produit décrivent une reprise rapide, un stockage durable et une sécurité sans divulguer l’architecture spécifique au client qui rend ces déclarations vraies.

ARTEM et Odoo ne peuvent pas être utilisés pour combler les lacunes.

Cette combinaison produit un verdict plus utile qu’une note. Ebunti est suffisamment crédible pour être testée et insuffisamment transparente pour être achetée sur le seul catalogue. Pour une PME mexicaine, son plus grand avantage possible n’est pas des CPU virtuels moins chers. C’est un service intégré dans lequel l’infrastructure locale, les copies récupérables, le contrôle réseau et les personnes qui répondent au téléphone réduisent le travail de survie à une perturbation. Son plus grand risque est que ce même service intégré concentre le contrôle technique et contractuel tout en laissant les frontières implicites.

Un acheteur peut résoudre une grande partie de cette tension avant la production. Concilier la contrepartie juridique. Joindre l’architecture et la carte de localisation des données. Transformer le langage de reprise en un exercice applicatif chronométré. Mapper AS265618 au chemin réel du client. Mettre le revendeur et Ebunti dans un seul planning de responsabilités. Vérifier le périmètre de sécurité et la séparation immuable. Concilier l’historique du moniteur public avec le SLA. Évaluer le sinistre et répéter la sortie.

Si Ebunti peut passer ces tests, le changement de marque représentera plus qu’une nouvelle présentation commerciale. Il décrira un opérateur de continuité mexicain dont le réseau local, la pratique de reprise et le support rendent la dépendance au cloud plus gérable. Si ce n’est pas le cas, l’acheteur se retrouve avec un vaste catalogue et un changement de nom. Dans l’approvisionnement en cloud souverain, la différence ne se décide pas sur la page d’accueil. Elle est écrite dans le contrat, démontrée dans la salle de reprise et préservée dans la copie que le client peut encore restaurer après que le fournisseur n’est plus là.