Résumé
- Certit Hosting Handelsbolag est lié à AS43021 dans les enregistrements RIPE. Le RDAP de RIPE indique que le nom du système autonome est
certit-hosting, et le résumé AS de RIPEstat mentionne le titulaire comme certit-hosting Certit Hosting Handelsbolag. - Les preuves de routage public actuelles sont faibles. Le statut de routage de RIPEstat pour AS43021 n’a signalé aucun pair RIS v4 ou v6 voyant des annonces au moment de la requête, et les préfixes annoncés de RIPEstat n’ont renvoyé aucun préfixe actuel pour AS43021.
- Les ressources réseau historiques sont importantes mais ne doivent pas être surinterprétées. Les enregistrements RIPE lient 193.200.208.0/24 et 2001:678:cbc::/48 à l’organisation Certit, tandis que l’historique de RIPEstat montre que ces ressources ont été vues dans le passé et que le statut de routage de dernière observation de RIPEstat pointe vers le préfixe IPv6 en avril 2026.
- Le récit des services destinés aux clients est divisé.
www.certit.seexpose encore des pages Certit Hosting pour l’hébergement cPanel et la messagerie KerioConnect, tandis que le domaine racinecertit.sesert du contenu Ayaa IT-konsult pour l’informatique gérée, l’hébergement web, les VPS, la sauvegarde, les services réseau et le support depuis Borlange. - La question du risque opérationnel n’est pas de savoir si la marque a déjà vendu de l’hébergement. Il s’agit de savoir si les charges de travail actuelles des clients disposent d’un placement actif dans les installations, d’une diversité de transit, de matériel de rechange, de tests de restauration, de voies d’escalade et de portabilité des données qui peuvent survivre à une défaillance de rack, d’amont, de support, de facturation ou de migration.
- Le niveau de preuve réseau est Faible. Le registre public établit l’identité et l’exploitation historique, mais la visibilité BGP publique actuelle ne prouve pas une capacité d’hébergement en direct.
La facture cloud se termine toujours par un rack
Une facture d’hébergement peut donner l’impression que l’infrastructure est propre. Elle transforme les serveurs, le stockage, les systèmes d’exploitation, les panneaux de contrôle, les files d’attente de courrier électronique, les adresses IP, la surveillance, les sauvegardes et le travail de support en un seul service commercial. L’utilisateur se connecte, télécharge des fichiers, crée des boîtes aux lettres, démarre un serveur virtuel ou demande au support de restaurer des données.
En dessous, le service dépend toujours de sites physiques, d’alimentation électrique, de racks, de disques, de ports de routeur, de réseaux amont, d’administration de domaine et de personnes autorisées à agir.
C’est la bonne façon de lire Certit Hosting Handelsbolag. Le registre public est suffisamment réel pour être étudié. Le RDAP de RIPE listeAS43021avec le nomcertit-hostinget une entité d’enregistrement pour Certit Hosting Handelsbolag. Lerésumé ASde RIPEstat donne le titulaire comme certit-hosting Certit Hosting Handelsbolag. Ces enregistrements ancrent l’identité.
Ils ne prouvent pas, en eux-mêmes, qu’un client d’hébergement web particulier se trouve dans une salle de données suédoise aujourd’hui. Ils ne disent pas si le service actuel est toujours transporté via AS43021, via l’espace d’adressage d’un fournisseur amont, via une plateforme tierce, ou via une pile de services gérés sous la marque Ayaa. Les données de routage public nous indiquent par où commencer à poser des questions, pas où s’arrêter.
Cette distinction est centrale car l’empreinte publique actuelle de Certit est mixte. Le site Certit plus ancien àwww.certit.seprésente encore une marque Certit Hosting et des liens vers l’hébergement, KerioConnect, à propos et contact. Sapage d’hébergementdécrit un hébergement basé sur cPanel, des comptes de messagerie, des contrôles d’accès, des domaines, la gestion de fichiers, des bases de données MySQL, des utilitaires de journaux et des forfaits d’hébergement annuels avec stockage, transfert et limites de boîtes aux lettres. Sapage KerioConnectdécrit la messagerie et la collaboration hébergées, y compris le chiffrement SSL, S/MIME, l’antispam, l’antivirus et une sauvegarde biquotidienne de toutes les données.
Parallèlement, le domaine racinecertit.sesert une page Ayaa IT-konsult. Le contenu Ayaa décrit des services informatiques d’entreprise, Microsoft 365, la sauvegarde, l’hébergement web, les VPS, les services réseau et le support personnalisé depuis Borlange; le même site Ayaa propose des pages dédiées pour l’hébergement web, lesVPS, lasauvegarde, leréseau en tant que serviceet lescoordonnées. Cela ne prouve pas une transaction d’entreprise, une migration ou une plateforme d’exploitation partagée. Cela montre pourquoi un acheteur ne peut pas traiter le nom sur l’ASN, l’ancien site d’hébergement Certit et le site de services Ayaa comme une preuve ininterrompue de capacité d’hébergement actuelle sans un contrat en vigueur et un plan technique.
Le risque est ordinaire mais important. Un petit fournisseur peut fournir un bon service s’il est honnête sur ses dépendances, garde une capacité de réserve, teste les restaurations et escalade rapidement. Un grand fournisseur peut décevoir les clients s’il cache des arrangements physiques fragiles derrière un portail poli. Certit appartient au premier type de question: les preuves publiques sont suffisamment minces pour qu’un acheteur vérifie les mécanismes avant de se fier à l’abstraction.
Ce que les pages de l’entreprise disent, et ce qu’elles ne disent pas
L’ancienne page d’hébergement Certit est spécifique sur les fonctions destinées aux clients. Elle indique que le service d’hébergement utilise cPanel comme panneau de contrôle. Elle décrit la création de comptes de messagerie, le transfert, les répondeurs automatiques et le filtrage; la protection par mot de passe des répertoires, les listes de contrôle d’accès au niveau IP, SSL/TLS et GnuPG; les sous-domaines, domaines additionnels, domaines parqués et gestion DNS; la gestion de fichiers; la création de bases de données MySQL et l’administration phpMyAdmin; et la visibilité des journaux Webalizer et AWStats.
La même page liste les tailles de forfaits: plans petit, moyen et grand avec différents stockages, domaines, boîtes aux lettres, transferts et comptes MySQL.
Ces détails sont importants car ils décrivent la surface de dépendance du client. Un client d’hébergement cPanel ne dépend pas seulement d’un serveur web. Le client dépend du DNS, de la messagerie, du stockage de bases de données, de la gestion des certificats TLS, de l’état du compte, de la disponibilité du panneau de contrôle, de la conservation des journaux, de la politique de sauvegarde et de l’accès au support.
Si l’une de ces couches tombe en panne, le client peut percevoir la panne comme « le site web est hors ligne » même si la véritable pièce défaillante est une file d’attente de messagerie, un disque de base de données, une règle de pare-feu, un compte suspendu ou un chemin de renouvellement de certificat.
La page KerioConnect ajoute une deuxième surface de dépendance: la messagerie et les outils collaboratifs hébergés. Elle décrit la messagerie, les contacts, les calendriers, les rappels et le webmail sur tous les appareils, plus le chiffrement, l’antispam, l’antivirus et les sauvegardes deux fois par jour. C’est plus sensible qu’un hébergement web statique. Une plateforme de messagerie contient la correspondance professionnelle, l’état du calendrier, les contacts, les avis juridiques, les chemins de réinitialisation de mot de passe et parfois les files d’attente de support client.
Si elle échoue, le rayon d’impact s’étend bien au-delà d’une page d’accueil.
Les pages Ayaa élargissent l’offre. Lapage d’accueild’Ayaa présente l’informatique gérée, le réseau, Microsoft 365, la sécurité, la sauvegarde, l’IA, le développement de systèmes et l’hébergement web. Lapage d’hébergement webrépète une proposition d’hébergement cPanel et indique que le service inclut une exploitation suédoise, une sauvegarde quotidienne et un support personnalisé. Lapage VPSdécrit des serveurs virtuels avec une disponibilité de 99,9 %, un pare-feu, des sauvegardes automatiques, une protection DDoS, une surveillance, des options gérées ou non gérées, un accès root, un stockage SSD et des ressources dédiées. Lapage de sauvegardeindique qu’Ayaa utilise Acronis Cyber Protect, mentionne la sauvegarde de serveur, d’environnement virtuel, de NAS, de serveur de fichiers et de postes clients, et encadre la récupération via RTO et RPO. Lapage de services réseaudécrit les pare-feu gérés, le WiFi, la surveillance, les mises à jour et un arrangement de service mensuel.
Cette collection est utile, mais il s’agit encore de textes commerciaux. Elle ne nomme pas le centre de données. Elle ne publie pas un nombre de racks. Elle ne précise pas si des serveurs appartenant à Certit, des racks loués, un hébergement revendeur, un cloud hyperscale ou un autre fournisseur d’infrastructure suédois héberge chaque produit. Elle ne montre pas une carte de chemin BGP, des contrats amont actuels, la diversité des interconnexions, les alimentations électriques, l’emplacement des pièces de rechange, la taille du cluster d’hyperviseurs ou une preuve de restauration de sauvegarde.
Un acheteur doit la traiter comme un menu de services prétendus, puis demander la preuve opérationnelle derrière le service qu’il a l’intention d’acheter.
Ce n’est pas une critique propre à Certit. La plupart des petits et moyens fournisseurs informatiques ne publient pas de schémas d’installation sur un site web public. Le point est qu’un article sur l’hébergement ne doit pas combler ce silence par des hypothèses. Si une page dit « sauvegarde quotidienne », la bonne question suivante est la portée de la restauration, la rétention, l’isolement, la cadence de test et le temps d’export.
Si une page dit « disponibilité de 99,9 % », la question suivante est de savoir si cela s’applique au calcul VPS, au panneau de contrôle, au stockage, à l’accessibilité réseau, à la réponse du support ou à tout cela ensemble.
AS43021 est une ancre d’identité utile, pas une preuve de capacité actuelle
AS43021 est l’identifiant réseau qui rend Certit visible dans les bases de données de routage publiques. Le RDAP de RIPE pourAS43021montre un statut actif, le nomcertit-hosting, un enregistrement en 2007 et des données modifiées pour la dernière fois en 2018. Lavue whoisde RIPEstat ajoute des lignes de politique de routage: importations depuis AS13189 et AS8473 acceptant tout, plus des importations depuis AS9088, AS15893, AS39708 et AS16117; les exportations annoncent AS43021 à ces ASN. Elle montre également le statut comme attribué et la même référence à l’organisation Certit.
Ces lignes d’importation et d’exportation sont importantes mais datées. Elles indiquent une politique de routage déclarée dans la base de données publique de RIPE, pas nécessairement la topologie commerciale ou physique actuelle. Un fournisseur peut laisser une ancienne politique de routage inchangée après avoir changé d’amont, cessé les annonces publiques, déplacé des clients vers un autre opérateur ou transféré la livraison sur un réseau fournisseur. C’est pourquoi la politique de routage doit être comparée à la visibilité BGP actuelle.
La vérification de visibilité actuelle est faible. Lestatut de routagede RIPEstat n’a signalé aucun pair RIS v4 ni v6 voyant AS43021 au moment de la requête, avec zéro préfixes v4 annoncés, zéro /48 v6 annoncés et zéro voisins observés. Lespréfixes annoncésde RIPEstat ont renvoyé une liste vide pour la période de deux semaines la plus récente. Lesvoisins ASNde RIPEstat n’ont également montré aucun voisin visible dans la vue la plus récente. La requêteASNde PeeringDB n’a renvoyé aucune entité réseau pour AS43021.
Cela ne signifie pas qu’il n’y a pas de service. Une société d’hébergement peut servir des clients en utilisant des adresses issues d’un fournisseur amont, des adresses à l’intérieur du réseau d’un opérateur de centre de données, une plateforme cloud, ou une pile gérée appartenant à un fournisseur. Le BGP public ne révèle pas toujours la livraison par revendeur. Mais cela signifie qu’AS43021 ne doit pas être cité comme preuve que Certit exploite actuellement une capacité de périmètre internet orientée client sous son propre ASN visible.
Pour les acheteurs, cela modifie le test d’approvisionnement. Au lieu de demander « le fournisseur a-t-il un ASN? », demandez « quel ASN transporte ma charge de travail aujourd’hui, quels préfixes seront annoncés, qui les origines, qu’arrive-t-il si ce chemin amont échoue, et quels contrôles d’origine de route existent? » Si la réponse est « nous n’utilisons pas AS43021 pour ce produit », cela peut convenir. Le client a alors besoin des mêmes preuves pour l’opérateur et la plateforme réels.
Les ressources IPv4 et IPv6 montrent l’historique et les limites
La ressource IPv4 associée à l’organisation Certit est193.200.208.0/24. Le RDAP de RIPE nomme le réseaugong-networks, le marque comme espace d’adressage indépendant du fournisseur attribué, et inclut Certit Hosting Handelsbolag comme organisation. Lavue whoisde RIPEstat pour le préfixe montre le pays SE, la même référence d’organisation, créé en 2007 et modifié pour la dernière fois en 2016. Lerésumé du préfixede RIPEstat indique cependant que le préfixe n’est actuellement pas annoncé dans la vue publique vérifiée.
La ressource IPv6 est2001:678:cbc::/48. Le RDAP de RIPE la nommeSE-LIDEN-20200312, la marque comme espace IPv6 indépendant du fournisseur attribué, et inclut Certit Hosting Handelsbolag comme organisation. Lavue whoisde RIPEstat pour le préfixe IPv6 montre le pays SE, la référence d’organisation Certit et une date de création en 2020. Lerésumé du préfixede RIPEstat indique également que le préfixe n’est actuellement pas annoncé dans la vue filtrée, tout en notant qu’une route à faible visibilité a été filtrée. Une vérification publique secondaire àbgp.toolsa également rapporté que le préfixe IPv6 n’était pas dans la table de routage mondiale et listait AS43021 avec une date de dernière observation en avril 2026.
RPKI ajoute une autre limite. La validation de l’origine de route RIPEstat pour193.200.208.0/24 origé par AS43021a renvoyé un état inconnu sans ROA de validation. Il en était de même pour2001:678:cbc::/48 origé par AS43021. Inconnu n’est pas la même chose qu’invalide, et une route qui n’est pas actuellement visible ne peut pas être jugée de la même manière qu’une route de production en direct. Néanmoins, si un fournisseur a l’intention d’originer à nouveau ces ressources pour le service client, l’autorisation d’origine de route devrait faire partie des exigences de préparation.
L’historique est donc crédible mais insuffisant. L’historique de routagede RIPEstat montre une longue visibilité historique pour le /24 IPv4 et une visibilité ultérieure pour le /48 IPv6. Le statut de routage de RIPEstat montre une première activité AS43021 avec 193.200.208.0/24 en 2007 et un dernier élément pour 2001:678:cbc::/48 en avril 2026. C’est une preuve que les ressources numériques de Certit ont existé et ont été observées au fil du temps. Ce n’est pas une preuve que les charges de travail des clients sont actuellement joignables, redondantes ou récupérables via ces ressources.
En termes d’infrastructure, c’est la différence entre l’historique installé et la capacité utilisable. Un /24 dans un registre est un actif utile. Une attribution IPv6 /48 peut prendre en charge une architecture double pile moderne. Mais le client n’en bénéficie que si ces ressources sont actives, surveillées, autorisées, routées via des amonts suffisants et connectées aux serveurs qui hébergent la charge de travail. Les ressources dormantes ou à faible visibilité sont une raison de vérification, pas un substitut.
La diversité du transit doit être actuelle, pas héritée
Les lignes de politique de routage RIPE publiques pour AS43021 nomment plusieurs contreparties potentielles. Sur le papier, cela semble plus large qu’un réseau mono-hébergé. En pratique, la vue actuelle des voisins RIPEstat ne montre aucun voisin visible. La différence compte car la politique de routage peut rester dans une base de données après que la topologie physique et commerciale a changé.
Il existe quatre types de diversité qu’un client devrait séparer. La diversité de route signifie que le plan de contrôle BGP dispose de chemins alternatifs. La diversité de transporteur signifie que ces chemins sont avec des fournisseurs commerciaux distincts. La diversité physique signifie que les câbles, les interconnexions de salle de rencontre, les entrées de bâtiment, les blocs d’alimentation et les étagères de routeur ne tombent pas en panne ensemble. La diversité de capacité signifie que le chemin restant peut supporter la charge du client après la défaillance du premier chemin. Un objet AS public prouve rarement les quatre.
Pour Certit, la politique de routage déclarée peut raconter une histoire historique sur les amonts et pairs antérieurs. Elle ne prouve pas que les produits d’hébergement actuels de Certit ou Ayaa disposent de deux amonts actifs, de deux routeurs, de deux installations ou d’un engagement de réserve suffisant pour surmonter une panne. L’absence actuelle de voisins publics signifie que la lecture la plus sûre est « non vérifié ».
C’est là que les normes de sécurité de routage fournissent un contexte utile. LaRFC 7454décrit les pratiques opérationnelles pour la sécurité et le filtrage BGP. LaRFC 6811décrit la validation de l’origine de route. LeMANRSencadre la sécurité du routage comme un ensemble d’engagements opérationnels pour les opérateurs de réseau. Ces sources ne certifient pas Certit. Elles expliquent pourquoi un acheteur devrait demander des filtres de préfixe, une validation d’origine de route, une diversité amont, des contacts d’incident et des contrôles de fuite si le fournisseur doit transporter des charges de travail de production.
La diversité du transit a également une composante de support. Si le fournisseur utilise l’espace d’adressage d’un amont plutôt que son propre ASN, le client doit savoir qui peut ouvrir un ticket d’opérateur, qui peut demander un réacheminement, qui peut voir la télémétrie de perte de paquets et qui décide si une panne est à l’intérieur du fournisseur, de l’opérateur, du centre de données ou de la propre configuration du client. Un petit fournisseur avec une bonne escalade peut surpasser un grand fournisseur avec une chaîne confuse. Mais cette force doit être démontrée, pas déduite.
Le test pratique est simple. Demandez les préfixes publics actuels, les ASN d’origine, les fournisseurs amont, les preuves de surveillance de route ou de miroir, l’état RPKI, la politique de fenêtre de changement et le dernier test de basculement réussi. Si le fournisseur ne peut pas partager tous les détails publiquement, il peut toujours les partager sous contrat. S’il ne peut pas les partager du tout, le client doit considérer le service comme une couche de commodité, pas comme une couche de résilience critique.
Les preuves d’installation et d’alimentation sont le maillon manquant
La lacune publique la plus importante est le placement des installations. Les pages Certit donnent des coordonnées suédoises. L’anciennepage à proposliste Certit Hosting Handelsbolag, une adresse à Borlange et le numéro d’organisation 969730-3809. L’anciennepage de contactliste Certit Hosting, Box 811, 781 28 Borlange etinfo@certit.se. Lapage de contactd’Ayaa liste Vattugatan 3, 784 33 Borlange, un numéro de téléphone et un cadre de support. Ces détails aident à situer l’entreprise en Suède et à Borlange. Ils ne situent pas les serveurs.
Pour l’hébergement web et les VPS, les faits d’installation décident du délai de réparation. Un disque défaillant n’est pas une abstraction cloud; c’est une pièce qui doit être remplacée ou contournée. Un commutateur de tête de rack défaillant peut déconnecter de nombreux clients à la fois. Une interconnexion défaillante peut rendre un serveur sain inaccessible. Un contrôleur de stockage défaillant peut casser à la fois les fichiers web et les bases de données. Une alimentation électrique défaillante peut révéler si la redondance est réelle ou seulement un langage de brochure.
Le matériel public de Certit et Ayaa ne dit pas si les charges de travail des clients fonctionnent dans une salle appartenant à l’entreprise, un rack loué, une armoire de colocation, une plateforme de revendeur, un locataire cloud hyperscale ou un environnement d’hébergement géré par un fournisseur. Chaque arrangement peut être raisonnable. Chacun a un chemin de panne différent. Les racks appartenant à l’entreprise créent une responsabilité directe pour les pièces de rechange, l’accès et l’alimentation. La colocation louée crée une dépendance à l’égard de l’opérateur de l’installation et des mains à distance.
L’hébergement revendeur crée une dépendance à l’égard de la plateforme et de la relation contractuelle d’un fournisseur amont. La livraison cloud crée une dépendance à l’égard du choix de la région, de l’accès au plan de contrôle, de l’état de facturation et de la discipline de configuration.
Le client devrait demander la limite de l’installation en langage clair. Où se trouve la charge de travail principale? Où se trouve la sauvegarde? Où se trouve le plan de gestion? À qui appartiennent les serveurs? À qui appartiennent les commutateurs? À qui appartiennent les adresses IP utilisées par mon service? Quelles parties Certit ou Ayaa peuvent réparer directement, et lesquelles nécessitent un ticket fournisseur? Quel est le pire délai crédible entre l’alarme et les mains qualifiées sur le composant défaillant?
Cet ensemble de questions n’est pas excessif pour un hébergement de petite entreprise. Une petite entreprise qui utilise la messagerie hébergée, des bases de données hébergées ou un VPS pour la comptabilité, les réservations, le commerce électronique ou le support client peut être matériellement lésée par une longue panne. Plus l’empreinte publique est petite, plus les preuves privées sont importantes.
La capacité installée n’est pas la même que la capacité utilisable
Les anciens forfaits d’hébergement Certit décrivent le stockage, les domaines, les boîtes aux lettres, le transfert de données et les comptes MySQL. Les pages Ayaa décrivent les ressources VPS, le stockage SSD, l’accès root, le pare-feu, la surveillance et la maintenance gérée. Ce sont des unités de service, pas des preuves de capacité. Un client voit les limites du forfait; le fournisseur doit gérer la sursouscription, le stockage de sauvegarde, les cibles de sauvegarde, la file d’attente de support et l’inventaire de réparation derrière ces limites.
La capacité installée est ce qui existe dans des conditions normales. La capacité utilisable est ce qui reste après la défaillance d’un composant. La capacité récupérable est ce qui peut être restauré dans les délais du client. Un hôte peut avoir suffisamment de disque pour les opérations normales mais pas assez de matériel de rechange pour évacuer rapidement un nœud défaillant. Il peut avoir des sauvegardes mais pas assez de bande passante de restauration pour récupérer plusieurs clients à la fois. Il peut avoir deux amonts nominaux mais pas assez d’engagement sur le second pour gérer le trafic de pointe.
Il peut avoir une promesse de support mais une seule personne autorisée à effectuer le changement clé.
Pour Certit, les preuves réseau publiques actuelles ne montrent pas de périmètre ASN en direct, et les preuves sur le site web ne montrent pas la plateforme d’hébergement derrière les plans. Cela signifie que la question installé vs utilisable doit être résolue par la documentation opérationnelle actuelle. Un acheteur devrait demander les pools de ressources actuels: le cluster d’hyperviseurs s’il achète un VPS, le pool de stockage s’il achète un hébergement web, la topologie du magasin de courrier s’il achète Kerio ou un autre service de messagerie hébergé, et la cible de sauvegarde s’il achète une sauvegarde gérée.
Il est également important de demander si la capacité est locale, régionale ou externalisée. Un service suédois peut utiliser un support suédois mais un stockage non suédois. Une adresse de contact à Borlange peut ne pas signifier une salle de données à Borlange. Un service cPanel peut être sur un serveur d’hébergement partagé contrôlé par un tiers. Un VPS peut être une machine virtuelle sur la propre plateforme du fournisseur, un nœud loué ou une instance cloud. Le client n’a pas besoin de rejeter aucune de ces options. Il doit savoir laquelle il achète.
La couche du panneau de contrôle mérite une attention particulière. cPanel peut rendre la gestion des comptes efficace, mais il peut aussi devenir un point unique de dépendance pour le client. Si cPanel est indisponible, le support peut-il encore restaurer des fichiers, faire pivoter des identifiants, exporter des bases de données, modifier le DNS ou désactiver une boîte aux lettres compromise? Si le compte est suspendu ou si la facturation est contestée, le client peut-il toujours récupérer ses données? Si le serveur est compromis, les sauvegardes sont-elles suffisamment isolées pour éviter d’être écrasées?
Ces questions transforment la taille du forfait en résilience. Le nombre le plus important n’est pas le nombre de boîtes aux lettres d’un forfait. C’est la quantité de capacité propre et testée qui reste disponible lorsque la première partie de la pile est cassée.
Les affirmations de sauvegarde nécessitent des preuves de restauration
La page Certit KerioConnect indique que les sauvegardes de toutes les données sont effectuées deux fois par jour. La page de sauvegarde d’Ayaa parle d’Acronis Cyber Protect, de sauvegarde de serveur et d’environnement virtuel, de sauvegarde NAS et serveur de fichiers, de sauvegarde de postes clients, de sauvegarde cloud, de stratégie 3-2-1, de chiffrement, de surveillance centralisée, de RTO, de RPO, d’archivage à long terme et de planification de reprise après sinistre.
Ce sont les bons sujets pour un article sur les dépendances de l’hébergement car la sauvegarde est l’endroit où les affirmations marketing rencontrent le plan de survie du client.
Mais les sauvegardes ne sont pas de la résilience tant qu’elles n’ont pas été restaurées. Un planning de sauvegarde biquotidienne indique quelque chose sur les points de récupération possibles. Il ne dit pas si la sauvegarde est hors site, immuable, chiffrée, séparée des identifiants de production, testée, complète, assez rapide pour être restaurée, ou disponible après la résiliation du contrat. Une description 3-2-1 est solide en principe, mais le client a toujours besoin de savoir où se trouve chaque copie et qui peut y accéder.
Le cas de la messagerie est particulièrement important. La récupération de la messagerie n’est pas seulement la récupération de fichiers. Une restauration de messagerie peut nécessiter des boîtes aux lettres, l’état des dossiers, les entrées du calendrier, les contacts, les listes de distribution, les enregistrements DNS, les paramètres d’authentification, les règles de filtrage anti-spam et la configuration du client. Une restauration partielle peut maintenir le serveur en marche tout en empêchant les utilisateurs de travailler.
La promesse de sauvegarde doit donc être accompagnée d’un exercice de restauration incluant le travail réel des utilisateurs.
Le cas VPS est différent. Une sauvegarde VPS peut restaurer une image entière, des fichiers sélectionnés ou des données d’application. Le client doit savoir si une restauration renvoie la même adresse IP, si des modifications DNS sont nécessaires, si les règles de pare-feu et les instantanés sont préservés, si les bases de données sont cohérentes en cas de panne ou cohérentes au niveau de l’application, et combien de temps il faut pour passer du support de sauvegarde à un service en cours d’exécution. La réponse peut varier selon le plan.
Le cas de l’hébergement web est encore différent. La sauvegarde cPanel peut être pratique, mais le client doit savoir si elle inclut la messagerie, les bases de données, les fichiers, les fichiers de zone DNS, les certificats SSL, les tâches cron et les paramètres au niveau du compte. Il doit également savoir si la restauration peut être effectuée si l’instance cPanel elle-même est indisponible.
C’est là qu’un petit fournisseur peut montrer du sérieux. Un court rapport de restauration a plus de valeur qu’une grande affirmation de disponibilité. Il peut dire: ce qui a été restauré, quand, à partir de quelle sauvegarde, par qui, combien de temps cela a pris, ce qui a échoué, ce qui a été exclu et ce que le client a dû faire après la restauration. Sans cette preuve, la sauvegarde reste une affirmation.
La localité des données n’est pas résolue par le code pays
La région d’attribution est la Suède, et les enregistrements publics soutiennent une identité suédoise. Les anciennes pages Certit listent des coordonnées à Borlange et un numéro d’organisation suédois. Les enregistrements de préfixe RIPE pour 193.200.208.0/24 et 2001:678:cbc::/48 montrent le pays SE et une référence à l’organisation Certit. Les pages d’Ayaa présentent des services informatiques gérés en suédois depuis Borlange.
Pourtant, la localité des données n’est pas résolue par le code pays dans un registre ou une adresse postale sur un site web. Les données des clients peuvent être réparties entre fichiers web, bases de données, magasins de courrier, sauvegardes, tickets de support, journaux, fournisseurs DNS, services de surveillance, plateformes de sécurité et systèmes de facturation. Certains peuvent être en Suède, d’autres ailleurs dans l’UE, et d’autres sur des plateformes mondiales. Une entreprise peut fournir un support suédois tout en utilisant un référentiel de sauvegarde non suédois ou un fournisseur de filtrage de courrier électronique tiers.
Pour les clients ayant des exigences de souveraineté des données, la matrice de placement doit être explicite. Où les données de production sont-elles stockées? Où les sauvegardes sont-elles stockées? Où les journaux sont-ils stockés? Où les tickets de support sont-ils stockés? Quels sous-traitants peuvent accéder aux systèmes des clients? Quelle entité juridique signe le contrat? Quelle juridiction régit les litiges et l’accès aux données? Que se passe-t-il si le client demande la suppression, l’exportation ou une preuve de destruction?
L’ancien PDF des conditions générales de Certit est lié depuis la page à propos de Certit àAllmanna_villkor.pdf. Son existence publique est importante car les conditions de service contiennent souvent la répartition réelle des responsabilités: utilisation acceptable, paiement, suspension, données client, responsabilité, support et résiliation. Un acheteur devrait examiner les conditions actuelles directement avec le fournisseur, car un lien PDF modifié pour la dernière fois en 2009 et un site web mis à jour en 2024 peuvent ne pas refléter l’arrangement opérationnel actuel.
La portabilité des données fait partie de la localité. Il ne suffit pas de savoir où les données sont stockées pendant que le service est sain. Le client doit savoir comment partir. Peut-il exporter les boîtes aux lettres dans des formats standard? Peut-il exporter les comptes cPanel, les bases de données, les zones DNS, les matériels SSL et les journaux? Peut-il obtenir une image VPS complète ou seulement des données au niveau des fichiers? Combien de temps après la résiliation l’accès reste-t-il? Que se passe-t-il si le compte est suspendu pour des raisons de facturation alors que le client a encore besoin de ses données?
La réponse décide si la capacité hébergée est un service ou un piège. Un fournisseur peut être petit et digne de confiance, mais le client ne devrait pas découvrir sa voie de sortie pendant une panne.
Le support fait partie de l’infrastructure
Les pages publiques d’Ayaa mettent répétément l’accent sur le service personnalisé, une personne de contact dédiée et un support rapide. La page de contact d’Ayaa mentionne les heures de semaine et indique qu’il existe un support 24/7 pour les systèmes critiques. L’ancienne page de contact Certit indique que le moyen le plus rapide de joindre Certit est le courriel. Les deux signaux sont pertinents sur le plan opérationnel car le support n’est pas séparé de l’infrastructure. C’est le mécanisme qui transforme la surveillance en réparation.
Le chemin de support doit être cartographié avant un incident. Qui reçoit l’alarme? Qui peut se connecter? Qui peut appeler l’opérateur du centre de données? Qui peut approuver un changement d’urgence? Qui peut restaurer une sauvegarde? Qui peut communiquer avec les clients si le service de messagerie lui-même est en panne? Qui peut déverrouiller un compte si l’état de facturation bloque l’accès? Si la réponse dépend d’une seule personne, le client doit comprendre les congés, les maladies et la couverture après les heures de travail.
Le support détermine également si le fournisseur peut distinguer les pannes. Une panne de site web peut être un problème DNS, un problème de base de données, un problème TLS, un problème de stockage, un problème de routage, un problème de pare-feu, un compte compromis ou une suspension de paiement. Un support rapide n’est pas seulement une réponse rapide; c’est une classification rapide et une autorité pour agir.
Pour Certit, l’empreinte publique ne publie pas de page de statut, d’historique d’incident, de matrice d’escalade ou de détail de niveau de service. C’est normal pour de nombreux petits fournisseurs, mais cela augmente l’importance des preuves de support contractuel. Les clients devraient demander les méthodes de contact, les définitions de gravité des incidents, les objectifs de réponse et de restauration, l’escalade après les heures de travail, l’escalade fournisseur, la politique de notification de maintenance et les rapports post-incident.
Ce n’est pas de la bureaucratie pour elle-même. Les services hébergés échouent souvent à la frontière administrative. Un domaine expire, une boîte aux lettres est verrouillée, un litige de facture suspend un compte, un mot de passe de panneau de contrôle est perdu, un ticket fournisseur est mal aiguillé, ou la personne qui connaît l’environnement est indisponible. Ces échecs sont aussi réels que des disques cassés.
Le plus grand avantage d’un petit fournisseur est la connaissance locale. Un consultant dédié qui connaît le client peut résoudre les problèmes plus rapidement qu’une file d’attente anonyme. Le risque le plus faible d’un petit fournisseur est la concentration. La même connaissance personnelle peut devenir un point unique de défaillance. Une bonne conception du support garde le premier avantage sans accepter le second.
Les principaux chemins de panne sont ordinaires et testables
Les chemins de panne les plus probables pour la capacité hébergée de type Certit ne sont pas exotiques. Le premier est une panne de rack ou de plateforme: un nœud hôte, une étagère de stockage, un commutateur, une alimentation électrique ou une pile de virtualisation tombe en panne. Le deuxième est une panne amont ou de route: le trafic ne peut pas atteindre le service parce qu’un opérateur, un préfixe, une session BGP ou un chemin de pare-feu se brise. Le troisième est une panne de stock de matériel: une pièce cassée peut être identifiée mais pas remplacée rapidement.
Le quatrième est une panne de support: la bonne personne ou le bon fournisseur ne peut pas être joint à temps. Le cinquième est une panne de facturation ou de compte: un service est suspendu, un domaine n’est pas renouvelé ou une relation fournisseur est interrompue. Le sixième est une panne de migration: le client essaie de partir ou de déménager pendant une période de stress et découvre que les exports sont incomplets, lents ou indisponibles.
Chaque chemin a un test correspondant. Le risque de rack et de plateforme peut être testé avec des exercices de panne de nœud, de la marge de capacité et des preuves de pièces de rechange. Le risque de route peut être testé avec une surveillance de préfixe actuelle, un basculement amont et l’état RPKI. Le risque de stock de matériel peut être testé avec un inventaire de rechange et des arrangements de mains à distance. Le risque de support peut être testé avec des exercices d’escalade et un contact après les heures de travail. Le risque de facturation peut être testé avec des règles de continuité de compte et la clarté du contrat fournisseur.
Le risque de migration peut être testé avec des exports réels et une restauration dans un environnement séparé.
Les preuves publiques autour d’AS43021 rendent le test de route particulièrement important. Si Certit n’utilise plus AS43021 pour l’hébergement actuel, l’acheteur devrait demander quel réseau transporte le service. S’il utilise AS43021 de manière intermittente ou pour des ressources sélectionnées, l’acheteur devrait demander pourquoi les collecteurs de route publics actuels ne montrent pas d’annonces stables et comment la joignabilité de production est surveillée. S’il prévoit de réannoncer le /24 IPv4 ou le /48 IPv6, l’acheteur devrait demander des ROA, des filtres, une confirmation amont et un plan de changement.
Les preuves publiques autour des pages de service rendent le test de restauration tout aussi important. cPanel, KerioConnect, les VPS et la sauvegarde sont tous des services à forte composante de restauration. Un client ne devrait pas accepter « nous avons des sauvegardes » comme réponse finale. Il devrait demander la preuve qu’une boîte aux lettres, un site web, une base de données et un serveur virtuel peuvent être restaurés dans les délais promis.
Les preuves publiques autour de la transition ou de la surface parallèle d’Ayaa rendent la frontière contractuelle importante. Si le client signe avec Ayaa pour un service historiquement associé à Certit, il devrait savoir quelle entité juridique, marque, bureau de support, plateforme et conditions régissent le service. Cette clarté importe quand les choses vont bien, et elle devient décisive lorsqu’un fournisseur doit agir sous pression.
Qui est affecté en cas de panne
Les parties affectées dépendent du produit. Un petit compte d’hébergement web peut affecter le site web d’une entreprise locale, les soumissions de formulaires, les pages de rendez-vous et la messagerie liée à un domaine. Un compte cPanel avec des boîtes aux lettres peut affecter les réinitialisations de mot de passe, les factures, le support client, la livraison de newsletters et les opérations internes. Un compte KerioConnect peut affecter les calendriers, les contacts et la collaboration. Un VPS peut affecter une application sur mesure, une API, une base de données, un environnement de développement ou un back-end de commerce électronique.
Un service de sauvegarde géré peut affecter la capacité du client à se remettre d’un rançongiciel ou d’une perte matérielle.
Ces éléments ne sont pas tous égaux. Une panne de site web marketing peut être toélérable pendant des heures. Une panne de messagerie pendant une journée de travail peut bloquer les opérations rapidement. Une panne de VPS pour une application métier peut être critique en quelques minutes. Une panne de sauvegarde peut ne pas être remarquée jusqu’au jour où elle est nécessaire, ce qui la rend particulièrement dangereuse. Le fournisseur ne devrait pas vendre une seule histoire de résilience générique à tous les clients.
Le client devrait classer les charges de travail par dépendance. Quels services sont publics? Lesquels détiennent des données réglementées ou sensibles? Lesquels sont nécessaires pour communiquer pendant une panne? Lesquels ont une solution de contournement manuelle? Lesquels peuvent être reconstruits à partir du code et de la configuration, et lesquels contiennent des données irremplaçables générées par l’utilisateur? Quelles exportations ont été testées? Un petit fournisseur peut bien soutenir cette classification s’il connaît l’environnement du client, mais il doit écrire les hypothèses.
Le fournisseur devrait également indiquer quelles pannes échappent à son contrôle. Si le client contrôle le DNS, le fournisseur peut ne pas être en mesure de corriger un mauvais changement DNS. Si un centre de données amont contrôle les mains à distance, le fournisseur peut ne pas être en mesure de raccourcir une réparation physique au-delà de la file d’attente du fournisseur. Si une plateforme cloud tierce héberge le VPS, le fournisseur peut coordonner plutôt que réparer directement. Les déclarations honnêtes de limites ne sont pas de la faiblesse; elles sont la base d’une récupération réaliste.
Pour Certit, les preuves publiques soutiennent une conclusion prudente. L’identité de l’entreprise et l’historique des services sont visibles. Le signal de routage public actuel est faible. Les pages de service indiquent des offres d’hébergement, de messagerie, de VPS, de sauvegarde et de support, mais pas les preuves d’installation et de réseau sous-jacentes. Les clients affectés par une panne devraient donc exiger des preuves de résilience actuelles et spécifiques au produit avant de considérer le service comme une infrastructure critique.
Ce qui améliorerait la confiance
Le niveau de preuve pourrait s’améliorer avec un petit ensemble de preuves publiques ou contractuelles. Premièrement, des preuves de route actuelles: préfixes origines actifs, ASN d’origine, amonts, ROA RPKI, filtres de route et surveillance indépendante. Deuxièmement, des preuves d’installation: l’arrangement opérationnel pour l’hébergement et les VPS, que les charges de travail fonctionnent dans des racks appartenant à l’entreprise, en colocation, chez un revendeur ou sur une plateforme cloud, et où se trouvent les données principales et de sauvegarde.
Troisièmement, des preuves de redondance: conception à deux chemins, tests de basculement, marge de capacité et ce qui reste utilisable après la première panne. Quatrièmement, des preuves de restauration: tests de restauration réussis récents pour les fichiers web, les bases de données, les boîtes aux lettres et les images VPS. Cinquièmement, des preuves de support: contacts d’escalade, couverture après les heures de travail, escalade fournisseur et processus de communication des incidents. Sixièmement, des preuves de portabilité: formats d’exportation de données, délais, coûts et accès après résiliation.
Aucune de ces informations ne nécessite de publier des diagrammes sensibles sur Internet. Un fournisseur peut partager des détails précis sous contrat et garder les pages publiques simples. Le point important est que le client reçoive des preuves actuelles, pas un confort hérité d’un enregistrement ASN de 2007 ou d’une page d’hébergement actualisée en 2024.
Le registre public actuel suggère également des tâches de surveillance. Surveillez le résumé AS43021 de RIPEstat et son statut de routage. Surveillez 193.200.208.0/24 et 2001:678:cbc::/48 pour les annonces et l’état RPKI. Surveillez siwww.certit.sereste une surface WordPress Certit Hosting pendant quecertit.sereste une surface Ayaa. Surveillez si les conditions, les pages de contact et les pages de service convergent, redirigent ou changent. Surveillez si PeeringDB gagne un profil ou si les collecteurs de route publics commencent à voir des amonts stables à nouveau.
Ces tâches de surveillance ne prouvent pas la sécurité du client par elles-mêmes. Elles aident à détecter un changement de preuve. Si l’ASN revient à une annonce stable, la question passe de « y a-t-il un routage public actuel? » à « le routage est-il sécurisé et redondant? » Si les pages de service se consolident sous Ayaa, la question passe de « quelle marque est actuelle? » à « quelle plateforme et quelles conditions régissent le client? » Si les pages de sauvegarde et de VPS publient plus de détails, la question passe de « qu’est-ce qui est prétendu? » à « qu’est-ce qui a été testé? »
Le meilleur résultat pour un petit fournisseur est la modestie transparente. Il n’a pas besoin de prétendre être un cloud hyperscale. Il peut dire exactement ce qu’il exploite, ce qu’il loue, ce qu’il surveille, ce qu’il sauvegarde, ce qu’il peut restaurer et où le client doit encore posséder le risque. C’est une meilleure histoire de résilience que de sur-vendre une capacité invisible.
Conclusion: des affirmations de service utiles, une preuve réseau faible
Certit Hosting Handelsbolag doit être traité comme un véritable sujet d’hébergement et de services informatiques suédois avec un historique de service public, pas comme une coquille vide. Les pages Certit décrivent un hébergement cPanel, une messagerie et une collaboration hébergées, et des coordonnées. Les pages Ayaa décrivent un portefeuille informatique géré plus large qui inclut l’hébergement web, les VPS, la sauvegarde et les services réseau depuis Borlange. Les enregistrements RIPE lient l’organisation Certit à AS43021 et à des ressources IPv4 et IPv6.
Les mêmes preuves limitent également l’affirmation. Les vérifications RIPEstat actuelles ne montrent pas AS43021 comme activement annoncé. La liste des préfixes annoncés est vide. La vue des voisins est vide. PeeringDB n’a pas d’entité réseau pour l’ASN. Les résumés de préfixe pour les ressources IPv4 et IPv6 liées ne sont actuellement pas annoncés dans la vue publique filtrée. La validation RPKI pour les deux préfixes historiques est inconnue car aucun ROA de validation n’a été trouvé dans les résultats vérifiés.
Cette combinaison indique un niveau de preuve réseau actuel Faible. Cela ne signifie pas que les clients sont hors ligne. Cela signifie que les preuves publiques ne prouvent pas une capacité d’hébergement redondante et en direct sous le propre ASN visible de Certit. Tout client envisageant le service pour la production devrait demander où la charge de travail fonctionne, quel réseau la transporte, comment elle bascule, où se trouvent les sauvegardes, comment les restaurations sont testées, qui peut intervenir après les heures de travail et comment les données peuvent être exportées.
La capacité hébergée est toujours une capacité physique. Pour Certit Hosting Handelsbolag, l’histoire publique est la plus utile lorsqu’elle est lue de cette façon: une marque d’hébergement, une surface de services informatiques suédois, des ressources numériques historiques, et un besoin actuel de vérification directe des racks, du transit, de l’alimentation, des fenêtres de réparation et des chemins de migration avant que le service ne soit considéré comme une infrastructure fiable.

