VERYCLOUD SAS et le dossier public derrière un nom de cloud

Résumé

• VERYCLOUD SAS n'est plus seulement un nom d'hébergement suggestif. Les registres publics français identifient une société parisienne active créée en avril 2025, le fournisseur décrit un transfert depuis un projet antérieur, et les enregistrements RIPE relient le nom à AS198825, qui opérait déjà depuis 2023.
• L'empreinte réseau est inhabituellement inspectable: cinq préfixes IPv4 et deux préfixes IPv6 étaient visibles depuis AS198825 à la date des preuves, chaque origine observée avait un RPKI valide, et les enregistrements de routage publics montraient deux voisins côté amont et deux côté aval. Cela prouve un rôle de routage actif, pas la propriété de chaque adresse, la diversité des chemins physiques ou la disponibilité des applications.
• La limite du service importe plus que le chiffre de disponibilité principal. Les conditions de VeryCloud placent les sauvegardes ordinaires, l'administration du système d'exploitation, la maintenance des applications et une grande partie du travail de récupération à la charge du client, sauf si des services supplémentaires sont achetés. Ses affirmations de localisation française sont significatives, mais les sous-traitants, les systèmes de contrôle, les journaux et les transferts sécurisés nécessitent encore une carte des données spécifique au service.
• Le support fait partie du produit, pas une promesse décorative. Les conditions publiques offrent des tickets 24h/24 pour l'infrastructure VeryCloud, tandis que les avis contiennent à la fois des éloges pour la configuration rapide et des plaintes plus anciennes concernant la suppression de services. Les acheteurs ont besoin de preuves de tickets, de tests de restauration et d'une propriété d'escalade claire avant de considérer un nom de cloud routé comme une garantie opérationnelle.

Commençons par le décalage de dates

Les fournisseurs de cloud se présentent souvent comme si la marque, l'entreprise et l'infrastructure étaient apparues au même moment. La chronologie publique de VeryCloud est plus complexe et, parce qu'elle est plus complexe, plus utile.

Leregistre public des entreprises françaisesenregistre une société active nommée VERYCLOUD, de forme juridique SAS, créée le 18 avril 2025. Il indique le siège social au 60 rue François Ier à Paris, le SIREN 943 573 584, le SIRET du siège 943 573 584 00019 et l'activité principale déclarée comme télécommunications sans fil. Ces détails établissent une contrepartie juridique actuelle. Ils ne montrent pas une société de cloud vieille de dix ans. Ils montrent une jeune entreprise française avec un enregistrement lisible.

La chronologie de l'infrastructure commence plus tôt. Lapropre histoirede VeryCloud indique que le projet a démarré en 2023, a obtenu AS198825 et un /24 IPv4 en mars de la même année, a fondé la SAS en avril 2025 et a transféré ses activités à la société le 26 avril 2025. L'enregistrement RIPE de AS198825date indépendamment l'objet système autonome du 19 avril 2023. L'objet organisation de RIPE pour VERYCLOUD SAS, en revanche, a été créé le 29 avril 2025. Les dates correspondent à l'histoire générale du fournisseur: d'abord le réseau, ensuite la société.

Cela n'a rien d'alarmant en soi. Les projets sont régulièrement constitués en société après une phase expérimentale ou associative. C'est néanmoins un point de diligence important. Un client doit se demander quels actifs, contrats, licences, engagements de support, passifs, enregistrements de surveillance et données clients ont été transférés à la SAS. Le site web indique que les activités ont été transférées. Les sources publiques considérées ici ne comprennent ni un accord de transfert ni un avis client expliquant sa portée.

La chronologie change aussi la façon dont les preuves de marché plus anciennes doivent être lues. Un avis de 2023 décrit le projet antérieur, et non un service fourni par une société qui n'existait pas encore. Il peut éclairer l'historique opérationnel de la marque, mais il ne peut pas établir automatiquement les performances de la SAS actuelle. Inversement, la SAS ne devrait pas revendiquer un historique d'entreprise plus long simplement parce que le domaine et l'ASN sont plus anciens. La formulation honnête est qu'une société française vieille de deux ans poursuit un projet d'hébergement et une identité réseau qui ont commencé en 2023.

Leprofil du répertoire BTWest donc un point de départ plutôt qu'une identité complète. Il identifie un opérateur privé d'infrastructure réseau, mais le registre des sociétés, le site web et les enregistrements RIPE fournissent les connexions décisives: nom légal, lieu, dates et numéro de réseau. Pour un acheteur, ces connexions transforment une marque de cloud générique en une contrepartie identifiable. Elles exposent aussi la première question sans réponse: qu'est-ce qui exactement a continué au-delà de la frontière de 2025?

Le catalogue est vaste, mais l'étendue n'est pas l'intégration

L'offre publique de VeryCloud couvre plusieurs modèles techniques et commerciaux. Ses conditions nomment des serveurs virtuels KVM, des serveurs dédiés bare-metal, de l'hébergement web partagé, de la colocation, des serveurs de jeu préconfigurés et des services réseau. Le site web ajoute le transit IP distant et la protection anti-DDoS. Un acheteur peut donc rencontrer la même marque en tant que locataire d'une machine virtuelle, administrateur d'un serveur physique, client plaçant du matériel dans une installation ou opérateur réseau recevant des routes via un tunnel.

Ce ne sont pas des variations mineures d'un seul produit. Elles répartissent le contrôle différemment.

Sur un VPS, VeryCloud contrôle le matériel sous-jacent, l'hyperviseur et le réseau du fournisseur; le client contrôle normalement le système d'exploitation invité, les identifiants, les applications et les données. Sur un serveur dédié, le client obtient une machine entière et un accès de gestion de plus bas niveau, mais dépend toujours du fournisseur pour l'alimentation, l'intervention physique et la connectivité externe. En colocation, le client peut posséder le serveur tout en dépendant de VeryCloud et de l'installation pour l'accès au rack, l'alimentation et les interconnexions.

Le transit distant va plus loin: l'équipement du client peut rester ailleurs tandis que les routes et le trafic filtré arrivent via des tunnels GRE, VXLAN ou EoIP.

Lapage de transit distantrend ce dernier modèle particulièrement explicite. Elle annonce des sessions BGP IPv4 et IPv6, des tables de routage par défaut ou complètes, des limites de préfixes sélectionnables et un contact de l'équipe après validation de la commande. Le réseau n'est pas seulement un ingrédient caché derrière l'hébergement web. Il est lui-même une limite de service vendable.

Cette étendue crée deux pièges. Le premier est de supposer qu'une marque commune implique un niveau de service commun. Le contrat de VeryCloud fixe une disponibilité mensuelle cible de 99,99 % pour les VPS et serveurs dédiés, mais de 99,9 % pour l'hébergement partagé. Un tunnel, un serveur physique et un compte partagé peuvent également avoir des dispositions différentes de maintenance, de capacité, de sauvegarde et de réponse. Le formulaire de commande et les conditions particulières importent car la page d'accueil ne peut pas résoudre toutes les variations.

Le deuxième piège est de supposer que l'infrastructure commune crée un point de responsabilité unique pour l'ensemble du système du client. LesConditions de ventede VeryCloud indiquent que le support inclus couvre l'infrastructure et les services du fournisseur: réseau, matériel, disponibilité du serveur et panneaux de contrôle. Sauf achat d'un service géré, cela exclut l'administration du système d'exploitation, la maintenance des applications clientes, le débogage de code, l'optimisation et la récupération des données client. Une application web peut être indisponible alors que le serveur, le réseau et le panneau de contrôle restent conformes au contrat.

C'est la différence entre un catalogue de services et un modèle opérationnel intégré. Le catalogue indique ce qui peut être commandé. Le modèle opérationnel indique qui surveille chaque couche, qui diagnostique une panne transversale et qui est autorisé à la restaurer. Les acheteurs devraient cartographier ces responsabilités avant de comparer les chiffres de processeur, de mémoire ou de bande passante. Un serveur bon marché peut devenir une ambiguïté coûteuse lorsqu'une défaillance applicative franchit la frontière entre l'infrastructure du fournisseur et l'administration du client.

L'automatisation accélère le cas ordinaire

L'attrait d'un petit fournisseur de cloud est souvent l'immédiateté. Sélectionnez un plan, payez, recevez les identifiants et commencez. Le contrat de VeryCloud distingue les services automatisés tels que les VPS et l'hébergement partagé, qui sont déployés en quelques minutes après le paiement réussi, des options de matériel dédié et de colocation qui peuvent nécessiter une configuration manuelle. Son compte contient les abonnements, la facturation et le support. Sa documentation publique fournit des guides en libre-service. Ensemble, ces surfaces forment une chaîne d'automatisation compacte.

Dans le cas ordinaire, cette chaîne supprime le travail. La confirmation de paiement peut déclencher des vérifications de compte, l'allocation de ressources, l'attribution d'adresses, la création d'identifiants et un message au client. Un serveur virtuel apparaît sans qu'un technicien assemble une commande sur mesure. Les tâches répétées deviennent suffisamment cohérentes pour être vendues à des prix d'entrée bas.

Mais l'automatisation ne supprime pas les décisions; elle les déplace. La capacité doit être disponible sur un hyperviseur approprié. L'image sélectionnée doit démarrer. Une adresse doit être attribuée sans collision ni surprise de réputation. Les règles anti-fraude doivent distinguer un acheteur ordinaire d'un usage abusif. Un client qui saisit mal une adresse e-mail ou perd un facteur d'authentification a besoin d'un chemin de récupération. L'état de facturation doit rester aligné sur l'état du service pour qu'une instance payée ne soit pas traitée comme expirée.

Les pages publiques de VeryCloud montrent des signes de cette frontière mobile. Le catalogue VPS propose des liens de commande directs et des configurations répétées. La page des serveurs dédiés, capturée à la date des preuves, montrait certaines configurations indisponibles et une configuration en stock. Elle affichait également un prix de zéro euro pour cette configuration, ce qui est clairement une raison de confirmer la commande réelle plutôt que de traiter une carte rendue comme un devis contractuel. L'état dynamique du catalogue peut être utile; il peut aussi exposer des données incomplètes ou une erreur de publication temporaire.

Le contrat prévoit des exceptions. VeryCloud se réserve le droit de refuser des commandes après des vérifications anti-fraude, d'identité, de sanctions ou de disponibilité. Il indique que des retards importants de stock ou de matériel peuvent entraîner un remplacement, un report ou un remboursement. Les identifiants arrivent par e-mail ou dans l'espace client, et les clients disposent d'un délai limité pour signaler une non-conformité. Rien de tout cela n'est inhabituel. Cela signifie que le service apparent en un clic est soutenu par une file d'attente de travail exceptionnel.

Un acheteur professionnel devrait tester cette file d'attente avant d'en dépendre. Comment un déploiement échoué est-il identifié? Un ticket créé automatiquement porte-t-il les références de paiement et de service? Qui peut annuler une suspension erronée? Une commande provisionnée manuellement est-elle visible dans le même compte? Les administrateurs peuvent-ils exporter une liste d'instances, d'adresses, de propriétaires, de dates de renouvellement et d'état des sauvegardes? Quelle piste d'audit existe pour une reconstruction ou une réinitialisation d'identifiants?

La meilleure mesure de l'automatisation n'est pas la rapidité avec laquelle le cas de réussite se termine. C'est la sécurité avec laquelle le service revient à un état connu après une défaillance partielle. Un fournisseur peut automatiser la création et encore compter sur un travail manuel fragile pour l'annulation, la migration, l'examen des abus ou la récupération. Le dossier public de VeryCloud rend le début de la chaîne visible. Un acheteur sérieux a besoin de preuves du milieu et de la fin.

Le contrat révèle l'architecture réelle

Les pages marketing décrivent des composants. Les contrats révèlent les responsabilités.

LesConditions d'utilisationde VeryCloud définissent le compte client, le contenu hébergé et la relation de service. Elles indiquent que les clients restent responsables des identifiants, des clés API et des clés SSH, avec une authentification à deux facteurs fortement recommandée et obligatoire pour certains services sensibles. Tout compromis suspecté doit être signalé via un ticket, et le fournisseur peut suspendre un compte pour éviter tout préjudice. Cela décrit une frontière d'identité dans laquelle les deux parties ont du travail à faire: le fournisseur gère le système de comptes, tandis que le client régit qui peut l'utiliser.

La frontière de sauvegarde est plus nette. Les Conditions de vente stipulent que, sauf achat explicite d'un service de sauvegarde géré, le client est responsable de la sauvegarde de ses données. VeryCloud peut conserver des sauvegardes techniques pour la continuité, mais celles-ci ne sont pas promises comme un service de restauration à la demande. À la fin du contrat, le client bénéficie d'un délai de grâce pouvant aller jusqu'à sept jours calendaires pour extraire ses données, sous réserve de paiement, après quoi la suppression peut avoir lieu, à l'exception des enregistrements légalement conservés.

Une assistance à la migration peut être facturée séparément.

Ce langage devrait modifier le comportement d'achat. Un client ne peut pas supposer sans risque que le plan de reprise après sinistre du fournisseur inclut des copies récupérables de chaque VPS non géré. La continuité de l'infrastructure et la récupération des données du locataire sont des choses différentes. Une alimentation redondante peut maintenir un hyperviseur en fonctionnement; elle ne protège pas contre un administrateur supprimant une base de données. Un fournisseur peut reconstruire un nœud défaillant; cela ne prouve pas que l'état de l'application d'un client peut être restauré au moment requis.

Le SLA a des limites similaires. VeryCloud s'engage sur une disponibilité mensuelle cible, définit la mesure et les exclusions, et offre des crédits de service lorsque le seuil n'est pas atteint. Les demandes doivent être faites par ticket dans les 30 jours. Les crédits sont plafonnés et constituent le recours normal en cas de violation du SLA. La responsabilité globale du fournisseur est également limitée par les conditions, tandis que la perte de données sans sauvegarde gérée est exclue.

Le point n'est pas que ces conditions soient particulièrement restrictives. Le point est que l'architecture opérationnelle est divisée. Le fournisseur promet certains résultats d'infrastructure; le client conserve des responsabilités majeures pour le contenu, l'administration du système, la santé des applications et la sauvegarde, sauf s'il achète plus. Un tableau de bord indiquant qu'un serveur est en ligne peut donc coexister avec une erreur client irrécupérable. Un chiffre réseau de 99,99 % peut coexister avec un service de connexion défaillant.

Un ticket de support peut recevoir une réponse correcte concluant que le défaut sort du champ inclus.

Pour une entreprise, la réponse devrait être une matrice de responsabilités liée aux preuves. Chaque service a besoin d'un propriétaire pour le système invité, l'application, les données, l'identité, le DNS, le certificat, la surveillance, la sauvegarde et la restauration. La commande devrait identifier quelles options VeryCloud modifient ces affectations. Le client devrait tester une restauration avant la production, pas après la perte. Ce qui ressemble à un détail juridique est en fait la conception du système écrite en prose.

AS198825 est la preuve publique la plus solide

La surface opérationnelle la plus inspectable de VeryCloud est son système autonome. Cela importe car les marques d'hébergement peuvent n'être guère plus que des revendeurs. Un ASN visible ne prouve pas chaque affirmation de service, mais il donne au fournisseur une identité réseau publique que d'autres opérateurs peuvent observer.

L'objet RIPE pour AS198825 nommeVERYCLOUD-SAS, l'associe à l'enregistrement d'organisation pour VERYCLOUD SAS et enregistre un statut assigné. Ses champs de politique de routage nomment AS62000 et AS174 pour l'import et l'export IPv4 et IPv6. Lavue des préfixes annoncésde RIPEstat, capturée le 15 juillet, montrait sept routes visibles pendant tout l'intervalle retourné du 1er au 15 juillet: cinq /24 IPv4 et deux /44 IPv6.

L'ensemble IPv4 était 82.22.2.0/24, 82.22.7.0/24, 82.22.77.0/24, 82.26.157.0/24 et 151.242.39.0/24. L'ensemble IPv6 était 2a0c:b641:af0::/44 et 2a10:4646:2e0::/44. Unevue BGP.Toolsindépendante montrait le même compte de cinq et deux origines et décrivait le réseau comme actif.

Chacune de ces paires de préfixes d'origine a renvoyé un résultat RPKI valide au moment des preuves. Pour les routes IPv4, des autorisations d'origine de route correspondantes autorisaient un /24. Pour les routes IPv6, elles autorisaient des annonces plus spécifiques jusqu'à /48. La validité signifie que l'AS d'origine observé correspondait à une autorisation. C'est un signal d'hygiène significatif car les réseaux effectuant une validation d'origine de route peuvent distinguer ces annonces d'une origine non autorisée.

Ce n'est pas un verdict de sécurité universel. La validité RPKI ne montre pas si une route est atteignable depuis tous les réseaux, si un routeur est correctement configuré, si le trafic suit le chemin physique prévu ou si une application répond. Une route valide peut encore être retirée. Une route valide peut mener à un serveur défaillant. Une route divulguée peut causer des problèmes même lorsque l'information d'origine est correcte. La bonne conclusion est étroite et positive: les origines observées de VeryCloud étaient autorisées au moment de la capture.

Lavue des voisins RIPEstatrend également visible une partie de la forme de routage. Elle montrait AS174 et AS62000 du côté amont adjacent, et AS197791 et AS198339 du côté aval. BGP.Tools affichait également AS62000 et AS174 comme amonts. Cette convergence indépendante soutient l'affirmation qu'AS198825 n'est pas un enregistrement isolé.

Pourtant, la visibilité des voisins n'est pas une preuve de circuit. Deux ASN peuvent être atteints via des installations, des ports ou des chemins physiques qui partagent des risques. Un collecteur de routage ne révèle pas la capacité engagée, les obligations de support, les ratios de trafic ou les tests de basculement. Il ne prouve pas non plus l'affirmation du site web selon laquelle le trafic se reroutera en quelques secondes après une défaillance de transporteur.

Un acheteur qui a besoin de résilience devrait demander une topologie à un niveau approprié, la séparation des domaines de défaillance et le résultat d'un exercice de basculement contrôlé.

L'ASN fait donc quelque chose de précieux mais limité. Il prouve que VeryCloud participe au routage sous son propre numéro et origines un ensemble mesurable d'adresses. Il donne aux clients et aux opérateurs extérieurs un endroit pour inspecter les routes. Il ne transforme pas l'identité réseau en une garantie de service de bout en bout.

Originer des adresses n'est pas la même chose que les posséder

Le site réseau de VeryCloud décrit 1 280 adresses IPv4 en allocation, ce qui correspond à cinq /24. Ce calcul est correct pour les routes originées par AS198825. Les enregistrements des registres montrent pourquoi le mot propriété serait trop fort.

Quatre des enregistrements IPv4 décrivent VeryCloud SAS, mais leur statut RIPE estASSIGNED PA, ils pointent vers un autre objet d'organisation et sont maintenus sous un mainteneur tiers. L'espace fournisseur-agrégatable est généralement délégué pour une utilisation sans devenir une propriété portable de l'utilisateur final. Le cinquième bloc, 151.242.39.0/24, estSUB-ALLOCATED PAet est décrit publiquement comme un espace client privé. AS198825 l'origina, mais la page réseau de VeryCloud elle-même ne le présente pas comme le propre pool d'adresses clients de l'entreprise.

Les enregistrements IPv6 portent également des lignées différentes. L'enregistrement 2a0c:b641:af0::/44 nomme VeryCloud SAS et son organisation RIPE. L'enregistrement 2a10:4646:2e0::/44 reste sous une organisation distincte associée au nom du fondateur. Les deux étaient visibles depuis AS198825 et les deux avaient des autorisations d'origine valides. L'utilisation opérationnelle, l'attribution du registre et le contrôle légal sont liés mais distincts.

Cette distinction importe lors d'une migration ou d'un litige. Un client peut recevoir une adresse qui reste partie de l'allocation amont d'un fournisseur. Elle peut fonctionner parfaitement pendant des années mais être difficile à déplacer. Un client annonçant son propre préfixe portable via VeryCloud a une position de sortie différente de celui utilisant une adresse assignée par le fournisseur. Les références de la page de transit distant aux IPv4 et IPv6 portables devraient donc être résolues dans la commande: à qui le préfixe, à qui l'objet de route, à qui la ROA, à qui le geofeed, et que se passe-t-il à la résiliation?

La réputation des adresses ajoute une autre dimension. Les réseaux d'hébergement peuvent hériter des historiques d'abus des utilisateurs précédents d'espace loué. Une route techniquement valide ne garantit pas que chaque adresse est acceptée par les fournisseurs de messagerie, les flux de menaces ou les API tierces. Les clients devraient tester les adresses réellement assignées pour leur charge de travail plutôt que d'inférer la réputation de l'ASN dans son ensemble.

VeryCloud mérite d'être crédité pour avoir publié sa liste de préfixes et son verre de visibilité. Cela rend possibles les vérifications externes. L'interprétation plus mature de ces outils n'est pas que l'entreprise possède un bloc fixe de biens immobiliers numériques. C'est qu'elle coordonne un ensemble de droits de routage, d'assignations et de routes clients. L'assurance vient du maintien de ces couches documentées, à jour et réversibles.

Le DNS montre deux modèles de livraison

L'enregistrement de domaine public relie la chronologie de la marque à son réseau. Les enregistrements AFNIC montrent queverycloud.fra été créé le 8 février 2023, avant la SAS, et est resté actif à la date des preuves. Ses serveurs de noms étaient opérés par Cloudflare. Le DNS public pour le site principal,www, le gestionnaire de compte, la documentation et les noms de statut renvoyaient des adresses périphériques Cloudflare en IPv4 et IPv6.

Cela signifie qu'un lecteur chargeant le site web ne teste pas directement AS198825. Cloudflare termine la périphérie publique et peut absorber, mettre en cache ou proxyer le trafic avant qu'il n'atteigne une origine. L'arrangement peut améliorer la résilience et la sécurité, mais il sépare l'accessibilité de la marque de la visibilité de la route du fournisseur lui-même. Voir le site web via Cloudflare pendant un incident AS198825 ne prouverait pas que les serveurs clients étaient sains. Ne pas atteindre une page frontée par Cloudflare ne prouverait pas, en soi, que le système autonome était en panne.

D'autres noms se connectent plus directement.lg.verycloud.fretlg.as198825.netrésolvaient à 82.26.157.253, à l'intérieur d'un des /24 observés depuis AS198825. L'échangeur de courrier pourverycloud.frétaitmail.as198825.net, qui résolvait à 82.26.157.251 dans le même /24. Ces liens fournissent des preuves pratiques qu'au moins les surfaces de verre de visibilité et de courrier touchent l'espace d'adressage originé par le réseau.

La distinction est analytiquement utile. Le domaine public combine une périphérie externe avec des points de terminaison réseau directs. C'est une livraison hybride normale, mais la surveillance devrait le refléter. Un contrôle devrait observer le site web tel qu'un utilisateur le voit via Cloudflare. Un autre devrait tester les dépendances côté origine. Des contrôles séparés devraient couvrir la zone de compte, le DNS, le courrier, le verre de visibilité et les services clients. Une seule page d'accueil verte ne peut pas représenter tous ces chemins.

Aucun enregistrement DS n'a été retourné pourverycloud.frdans l'instantané du 15 juillet. Ce n'est qu'une observation de délégation. Cela ne signifie pas que le DNS n'est pas authentifié à tous les niveaux, ni n'annule les autres contrôles de Cloudflare. Cela identifie une question spécifique: si DNSSEC est intentionnellement non déployé au parent, en cours d'introduction ou considéré comme inutile pour ce domaine. Pour une entreprise vendant des services réseau, une décision documentée est plus rassurante qu'une supposition.

Le DNS place également une limite sur les affirmations de localisation. Une adresse périphérique appartient au réseau de livraison, pas nécessairement au pays d'origine. Une adresse directe révèle la route, pas le serveur physique ou la base de données derrière. Les acheteurs devraient utiliser le DNS comme preuve des dépendances et des points de contrôle, jamais comme une carte complète de localisation des données.

La localisation française est significative, mais elle a besoin d'un nom

VeryCloud répète que les données clients sont hébergées exclusivement en France à Telehouse 3 à Magny-les-Hameaux. Le contrat est plus prudent: il indique que les données sont hébergées en France par défaut et prévoit des transferts réglementés en dehors de l'Union européenne le cas échéant. Ces déclarations peuvent coexister si elles se réfèrent à différentes catégories de données, mais les catégories ont besoin de noms.

Les données de charge de travail client sur un VPS sont une catégorie. L'identité du compte, les factures, les jetons de paiement, les messages de support, les rapports d'abus, la télémétrie de sécurité, les événements de surveillance et les sauvegardes du fournisseur en sont d'autres. Un hôte de calcul français peut utiliser un processeur de paiement externe. Une plateforme de tickets peut traiter les métadonnées de support ailleurs. Un système anti-fraude peut évaluer les informations de compte via un autre sous-traitant. Un service de surveillance peut conserver les adresses IP et les horodatages d'événements en dehors du pays du serveur.

Les conditions de VeryCloud reconnaissent la scission. Pour les données clients traitées via les services d'hébergement, le client agit en tant que responsable du traitement et VeryCloud en tant que sous-traitant. Pour les données de relation client telles que les enregistrements d'inscription, de facturation, de support et de sécurité, VeryCloud agit en tant que responsable du traitement. Le fournisseur indique qu'un accord de traitement des données est disponible et que sa liste de sous-traitants est disponible sur demande. Il indique également que les clients recevront des informations sur les modifications dans le cadre du DPA.

Ce cadre est plus utile qu'un drapeau sur une fiche produit, car il demande qui peut agir sur chaque ensemble de données. Un acheteur devrait demander le DPA, la liste actuelle des sous-traitants, les emplacements, le mécanisme de transfert, les périodes de conservation, le processus de suppression et la voie de notification des violations. Il devrait demander si les sauvegardes gérées restent en France, si les journaux du plan de contrôle suivent la même règle, et si le personnel de support en dehors de la France peut accéder aux systèmes clients.

Lapage Telehouse pour Magny-Les-Hameauxconfirme indépendamment une installation substantielle avec alimentation redondante, générateurs, dispositions UPS, accès sécurisé et certifications de gestion au niveau de l'installation. Cela soutient l'affirmation de VeryCloud que le site nommé existe et dispose de contrôles physiques sérieux.

Cela ne certifie pas VeryCloud SAS. Un locataire hérite des avantages du bâtiment mais doit encore configurer ses racks, identifiants, réseau, sauvegardes et procédures. Les gardiens de l'installation n'empêchent pas un administrateur client de supprimer un disque virtuel. L'alimentation redondante ne prouve pas que la séquence de récupération d'un fournisseur a été testée. Une certification d'installation peut couvrir le système de gestion de l'opérateur sans couvrir chaque processus de locataire ou charge de travail client.

La souveraineté des données n'est donc pas atteinte en disant France assez souvent. Elle est atteinte en gardant les droits de décision, l'accès, les copies et les sorties attribuables. La localisation de VeryCloud est une ancre crédible et commercialement pertinente. Le travail restant est d'attacher chaque nom important à elle: données de production, sauvegarde, journal, ticket, compte, clé et image de récupération.

La disponibilité a besoin d'une mémoire publique

VeryCloud annonce une disponibilité de 99,99 % pour les services VPS et dédiés. Exprimé sur un mois de 30 jours, cet objectif n'autorise que quelques minutes d'indisponibilité comptée. Mais le contrat, pas la décimale, détermine ce qui est compté.

Les conditions excluent ou traitent séparément la maintenance planifiée, les défauts causés par le client et les défaillances hors de la responsabilité du fournisseur. Elles définissent la mesure et les crédits de service, et exigent un ticket dans les 30 jours suivant un incident. Cela signifie que les clients ont besoin de leur propre surveillance. Sans un enregistrement externe horodaté, il peut être difficile d'établir quand un service est devenu indisponible, quelle couche a défailli et si l'événement répondait à la définition contractuelle.

VeryCloud maintient unepage de statut publique, ce qui est une surface de responsabilité positive. À la date des preuves, la page en direct exposait un moniteur VeryCloud via HetrixTools. Un instantané de recherche de la même période décrivait encore une ancienne page Uptime Kuma avec une liste de composants plus longue. Cette transition apparente peut simplement refléter une refonte de la surveillance. Elle montre aussi pourquoi une page de statut devrait préserver la continuité lorsque les outils changent.

Un service de statut public utile fait plus qu'afficher vert ou rouge. Il définit les composants, enregistre les heures de début et de récupération des incidents, distingue l'investigation de l'atténuation et conserve les résumés post-incident. Les clients devraient pouvoir s'abonner sans rejoindre un chat communautaire. La maintenance devrait rester visible après sa fin. Un fournisseur peut masquer les détails sensibles tout en expliquant le service affecté, la cause générale, le chemin de restauration et le travail de prévention.

Les données de routage publiques peuvent compléter cet historique, mais pas le remplacer. RIPEstat montrait les sept préfixes visibles pendant tout l'intervalle de deux semaines retourné. Cela soutient la continuité des routes au niveau du collecteur. Cela ne dit rien sur les défaillances d'hyperviseur, la latence de stockage, l'accès au compte, la billetterie ou une instance client unique. De même, une page d'accueil verte frontée par Cloudflare ne prouve pas que le parc VPS est sain.

La hiérarchie des preuves devrait donc être stratifiée. Les moniteurs de routage globaux observent les préfixes. Les sondes externes observent les ports et les transactions. La surveillance de l'hyperviseur et du stockage observe l'infrastructure. Les vérifications d'application observent la tâche de l'utilisateur. Les tickets enregistrent l'impact et la propriété. Les tests de restauration prouvent la récupérabilité. Les pages de statut communiquent une version organisée de ces faits.

VeryCloud publie le début de cette hiérarchie: routes, un verre de visibilité et un moniteur public. Avant de déplacer une charge de travail critique, un acheteur devrait demander le reste sous une forme appropriée confidentielle: calculs de disponibilité, historique de maintenance, exemple de communication d'incident, succès des sauvegardes, tests de restauration et délais d'escalade. Le but n'est pas de prendre le fournisseur en défaut sur une décimale. C'est de savoir si les deux parties reconnaîtront le même incident.

Les avis clients montrent le problème avant-après

La page Trustpilot de VeryCloud est plus grande que ne le suggère la brève entrée du répertoire. Le 15 juillet, elle affichait 123 avis, un score de 4,4, 82 % d'avis cinq étoiles et 11 % d'avis une étoile, avec 56 avis au cours des 12 mois précédents. Le profil a été revendiqué en août 2023, et Trustpilot a indiqué que la société invite les clients à donner leur avis. Il a également indiqué que la société n'avait pas répondu aux avis négatifs.

Ces chiffres sont un signal de marché, pas un audit de performance. Trustpilot précise qu'il ne vérifie pas les opinions des évaluateurs, bien qu'il utilise un filtrage et puisse vérifier qu'une interaction a eu lieu. Les invitations peuvent changer qui répond. Une distribution d'étoiles ne contrôle pas le produit, la charge de travail, la compétence du client, l'ancienneté du service ou la gravité de l'incident.

Les avis positifs visibles identifient néanmoins des thèmes utiles à tester. Les évaluateurs ont décrit un provisionnement rapide, une documentation accessible, une surface de gestion utilisable et un support réactif. Ces observations correspondent aux affirmations de VeryCloud concernant l'automatisation et le support. Elles suggèrent que la rapidité et l'aide humaine font partie de la valeur perçue du fournisseur, pas seulement les spécifications du processeur.

Les avis négatifs visibles dans la page capturée étaient concentrés en 2023 et alléguaient des services supprimés et des problèmes de remboursement. Une plainte visible était marquée comme vérifiée. Ce sont des allégations sérieuses de la part d'utilisateurs individuels, pas des conclusions établies. Leur date est tout aussi importante: elles concernent le projet précoce, deux ans avant la création de la SAS. Une évaluation équitable ne les efface ni ne les attribue mécaniquement à la société ultérieure.

La bonne question est de savoir ce qui a changé. Le transfert de 2025 a-t-il apporté des contrôles de facturation plus clairs, des avertissements de suppression, des enregistrements de compte et des voies de recours? Les conditions actuelles et l'espace client empêchent-ils le modèle de défaillance allégué dans les anciens avis? Le fournisseur a-t-il commencé à conserver les preuves d'état de service et de paiement suffisamment bien pour résoudre les litiges? Répond-il en privé via des tickets tout en laissant les avis publics sans réponse, ou les retours négatifs restent-ils sans suite?

Le volume positif récent peut indiquer une amélioration, mais un score ne peut pas répondre à ces questions de processus. L'entreprise pourrait renforcer l'assurance en répondant aux avis négatifs substantiels sans divulguer les données clients, en publiant le cycle de vie pour la suspension et la suppression, et en enregistrant comment les litiges sur l'état de paiement sont escaladés. Les clients peuvent également se protéger en conservant les factures, les avis de renouvellement, les exportations de tickets, les identifiants de service et les sauvegardes indépendantes.

Les avis sont plus utiles lorsqu'ils produisent un test. Le provisionnement rapide peut être testé avec une instance à faible risque. La qualité du support peut être testée avec une question technique de prévente. L'annulation peut être testée avant un renouvellement critique. L'extraction de données peut être répétée. Les plaintes plus anciennes concernant des suppressions devraient conduire à un exercice de sortie, pas à un verdict basé sur une poignée de publications.

Le travail de support est la limite de capacité cachée

VeryCloud promet un support technique 24 heures sur 24, 7 jours sur 7 via les tickets de l'espace client, avec e-mail ou chat dans certains cas. Sa page de serveurs dédiés propose également un support en français via tickets et Discord. Le contrat réduit le travail inclus à l'infrastructure, au matériel, au réseau, à la disponibilité du serveur et aux panneaux de contrôle du fournisseur.

C'est une limite sensée. Cela signifie aussi qu'un petit nombre de personnes qualifiées peuvent se trouver au point de convergence de nombreuses lignes de produits. Un ticket concernant une application inaccessible peut nécessiter la connaissance de l'état de la facturation, de la santé de l'hyperviseur, de l'attribution d'adresse, de la visibilité des routes, du filtrage, de la configuration de l'invité et de l'historique du client avant que le répondant ne puisse localiser la responsabilité. L'automatisation peut ouvrir et acheminer le cas, mais le diagnostic est un travail humain.

Un accès 24h/24 n'est pas la même chose qu'une profondeur 24h/24. Le dossier public ne montre pas l'effectif actuel du support, le modèle de quarts, la couverture linguistique, la distribution de la première réponse ou l'organigramme d'escalade. Il ne dit pas si la personne répondant à un message Discord peut effectuer un changement de routeur, autoriser un remboursement ou remplacer du matériel. Il ne révèle pas comment les incidents simultanés sont priorisés.

Pour les clients ordinaires, Discord peut être utile. Les membres de la communauté répondent aux questions simples, et une équipe visible peut rendre un petit fournisseur accessible. Pour les décisions de sécurité, de facturation et d'état de service, le ticket devrait rester faisant autorité. Les messages de chat peuvent être modifiés, perdus dans le volume ou vus par le mauvais public. Un ticket peut porter l'identité du compte, les horodatages, les pièces jointes et l'état d'escalade dans un enregistrement contrôlé.

La main-d'œuvre locale importe également sur le site. Un répondant distant peut inspecter la télémétrie, mais le matériel défaillant, le câblage et les alimentations peuvent nécessiter des mains à Magny-les-Hameaux. La division entre le personnel de VeryCloud, les sous-traitants et le personnel de Telehouse détermine qui peut entrer dans l'espace, remplacer un composant et confirmer la récupération. Une promesse de support humain devrait relier ces rôles plutôt que de laisser le client les coordonner.

Avant un déploiement critique, les acheteurs devraient poser des questions opérationnelles qui révèlent la capacité sans exiger d'informations personnelles: Quel est l'objectif de réponse par gravité? Qui peut déclarer un incident majeur? Y a-t-il un ingénieur réseau d'astreinte? Comment les interventions matérielles sont-elles demandées? Le support conserve-t-il un historique complet des tickets? Un client peut-il désigner plusieurs contacts autorisés? Existe-t-il un chemin d'urgence si le portail de compte est indisponible?

Les réponses importent car VeryCloud vend à la fois de l'automatisation et de l'intervention. Les serveurs peuvent être créés automatiquement, mais les exceptions s'accumulent autour de la facturation, des abus, de la migration, du routage et de la récupération. Le produit n'est fiable que si la file d'attente humaine a suffisamment d'autorité et de temps pour résoudre ces exceptions.

Un acheteur devrait évaluer la sortie, pas seulement l'entrée

VeryCloud concurrence avec des ensembles de ressources attractifs et un récit d'hébergement français. Le prix mensuel visible n'est qu'une partie de la décision commerciale. Le coût réel comprend l'administration, la sauvegarde, la surveillance, la portabilité des adresses, le travail incident et la migration.

Un VPS non géré transfère une charge de travail substantielle au client. Quelqu'un doit patcher le système d'exploitation, sécuriser SSH, surveiller l'espace disque, renouveler les certificats d'application, tester les sauvegardes, répondre aux rapports d'abus et diagnostiquer les défaillances logicielles. VeryCloud peut fournir une machine virtuelle saine tandis que le service du client reste vulnérable par une administration négligée. Une faible facture de serveur peut être rationnelle si l'acheteur possède déjà cette capacité. Elle est trompeuse si le travail manquant est traité comme gratuit.

L'économie de la sauvegarde est particulièrement facile à sous-estimer. Le contrat exclut la restauration ordinaire sans option gérée, et l'assistance à l'exportation en fin de contrat peut être facturée. Un acheteur devrait évaluer les copies indépendantes, le stockage, le transfert, la rétention et les tests de restauration. Il devrait savoir combien de temps prend une exportation complète et si le service reste accessible en écriture pendant la migration. Sept jours de grâce post-contrat peuvent suffire pour un client préparé et dangereusement courts pour un client non testé.

L'adressage affecte également le coût de sortie. Les charges de travail liées aux adresses IPv4 assignées par le fournisseur peuvent nécessiter des modifications DNS, des mises à jour des listes autorisées, un réchauffement de réputation et une communication client lors du déplacement. Les préfixes portables et les sessions BGP peuvent réduire certaines dépendances mais ajoutent une expertise en routage, un travail de registre et des obligations de sécurité.

Le transit distant peut préserver les adresses lors d'un changement d'hébergement uniquement si le client contrôle réellement les ressources pertinentes et que le chemin de remplacement est prêt.

La proposition de localisation des données en France a également un prix. Elle peut simplifier l'approvisionnement pour les clients recherchant une installation nationale et un lieu juridique familier. Elle ne supprime pas la nécessité d'évaluer les sous-traitants ou de construire une récupération en dehors d'un seul domaine de défaillance. Un client qui nécessite une résilience géographique peut avoir besoin d'un deuxième site français, d'une autre région européenne ou d'un emplacement de sauvegarde indépendant, selon la politique et le risque.

Enfin, les recours contractuels ont des limites économiques. Les crédits SLA compensent une partie d'un frais mensuel; ils correspondent rarement au coût commercial d'une panne. Les plafonds de responsabilité et les exclusions signifient que le client reste l'assureur de nombreuses conséquences. La criticité devrait donc déterminer l'architecture. Un serveur de loisir peut accepter un arrangement simple. Un système générateur de revenus peut nécessiter un DNS multi-fournisseur, des données répliquées, une configuration portable, une surveillance externe et un playbook testé.

VeryCloud peut encore être le choix économique après ces ajouts. Le point est de comparer les coûts opérationnels complets. Le prix d'entrée répond à ce qu'il en coûte pour démarrer. Le prix de l'assurance répond à ce qu'il en coûte pour rester récupérable et pour partir.

À quoi ressemblerait une preuve plus solide

Le dossier public soutient déjà plusieurs conclusions avec confiance. VERYCLOUD est une SAS française active. Elle présente un catalogue de services cohérent et des conditions juridiques actuelles. AS198825 est actif et visible avec des origines IPv4 et IPv6. Les autorisations d'origine de route étaient valides à la date des preuves. Le DNS public relie la marque à la fois aux services frontés par Cloudflare et aux adresses directes dans l'espace AS198825. L'installation Telehouse nommée est réelle. Un dossier d'avis clients non trivial existe.

Le niveau d'assurance suivant n'exige pas que l'entreprise publie des diagrammes sensibles. Il nécessite des preuves qui peuvent être partagées avec un acheteur sous des conditions appropriées.

Pour l'identité et la continuité, cela signifie un compte clair du transfert de 2025, l'entité contractante sur les factures, et la situation actuelle en matière d'assurance et financière le cas échéant. Pour les services, cela signifie une description de commande définitive qui remplace les cartes de catalogue transitoires. Pour la résilience du réseau, cela signifie les préfixes prévus, les ROA actuelles, la propriété des dépendances, les domaines de défaillance physiques et les résultats de basculement récents.

Pour les données, l'acheteur a besoin du DPA, de la liste des sous-traitants, des emplacements par service, du modèle d'accès, du chiffrement et de la propriété des clés, de la conservation, de la suppression et de la conception de la sauvegarde. Pour la disponibilité, il a besoin du calcul du SLA, des performances mesurées récentes, de l'historique de maintenance et d'un exemple de communication d'incident. Pour la récupération, il a besoin de preuves que les sauvegardes sont surveillées et que les restaurations ont été effectuées dans l'objectif requis.

Pour le support, les mesures utiles ne sont pas des slogans mais des distributions: première réponse par gravité, délai avant prise en charge technique, délai de restauration, cas réouverts et escalades non résolues. Un petit fournisseur n'a pas besoin d'exploiter un vaste centre d'appels. Il doit montrer que le travail urgent atteint quelqu'un d'autorisé à agir.

Le client a des obligations réciproques. Il doit maintenir des contacts précis, sécuriser son compte, patcher ce qu'il administre, classer ses données, conserver du matériel de récupération indépendant, surveiller les transactions et soumettre des tickets en temps utile. Le fournisseur ne peut pas restaurer une charge de travail qu'il n'a jamais été contractuellement tenu de sauvegarder. Le client ne peut pas diagnostiquer un réseau qu'il ne peut pas observer. L'assurance est un ensemble de responsabilités conjointes, pas un badge acheté à la caisse.

Les preuves publiques de VeryCloud sont les plus solides là où les opérations Internet sont naturellement publiques: enregistrement ASN, origines de routes et DNS. Elles sont plus faibles là où les résultats de service sont privés: gestion des incidents, récupération de stockage, capacité de support et configuration client. Ce schéma n'est pas inhabituel. C'est exactement pourquoi un acheteur devrait utiliser les preuves publiques solides pour poser de meilleures questions privées, plutôt que de traiter l'absence de détail public comme une preuve d'échec ou une permission de supposer le succès.

Un nom routé, pas un verdict final

VERYCLOUD SAS a plus derrière elle que ce que l'étiquette mince du répertoire révèle initialement. Il y a une société française active, une transition publiée depuis un projet antérieur, un contrat défini, une revendication d'installation réelle et un réseau qui peut être observé de l'extérieur. AS198825 origina cinq préfixes IPv4 et deux IPv6, avec des autorisations d'origine de route valides à la date des preuves. C'est une preuve substantielle pour un jeune fournisseur.

C'est une preuve d'identité et de participation au réseau. Ce n'est pas une preuve que chaque charge de travail restera disponible, que chaque octet reste dans une seule juridiction, que chaque sauvegarde est restaurable ou que chaque ticket urgent atteint le bon ingénieur. Les pages produits publiques compressent parfois des distinctions que le contrat rétablit: continuité de l'infrastructure versus récupération client, hébergement français versus la chaîne de sous-traitants plus large, accès 24h/24 versus champ administratif inclus, et disponibilité cible versus recours réel du client.

Le dossier de marché mitigé renforce le point. Les évaluateurs récents font souvent l'éloge de la rapidité et du support, tandis que les plaintes visibles du projet antérieur soulèvent des questions sur la suppression et l'état de paiement. Aucun côté ne devrait être transformé en une histoire universelle. Les contrôles actuels du fournisseur devraient être testés contre les modes de défaillance que l'ancien dossier expose.

Pour un client potentiel, la séquence sensée est simple. Vérifiez la SAS sur la commande. Identifiez la limite exacte du service. Confirmez le modèle d'adressage et de routage. Demandez le DPA et la liste des sous-traitants. Décidez qui possède chaque sauvegarde et restauration. Surveillez de l'extérieur. Mettez la sécurité, la facturation et la communication d'incident dans les tickets. Répétez la migration avant qu'elle ne soit urgente.

Cette séquence ne diminue pas la valeur du réseau de VeryCloud. Elle remet le réseau à sa juste place. Un ASN visible est une meilleure fondation qu'une identité de revendeur anonyme. Un RPKI valide est meilleur que des origines ambiguës. Un verre de visibilité public est meilleur que de demander aux clients de faire confiance à un diagramme. Ce sont des signes d'un opérateur prêt à exposer une partie de son travail à l'examen.

L'assurance opérationnelle commence après que ces signes ont été lus correctement. Elle émerge lorsque l'identité légale, les routes, les contrats, les contrôles de données, les enregistrements de statut, les tests de récupération et l'autorité humaine pointent vers le même service. VERYCLOUD SAS peut déjà être identifiée et observée. La question restante pour chaque acheteur est de savoir si les preuves privées derrière une commande spécifique sont aussi cohérentes que le nom réseau public.