Résumé

  • HYCU a annoncé le 8 septembre la disponibilité générale de R-Cloud pour Azure DevOps, avec une protection étendue aux éléments de travail, aux définitions de livraison et aux paramètres d'organisation.
  • Microsoft dispose déjà de sauvegardes de continuité et de mécanismes de récupération limités. Le test du nouveau service porte sur une restauration utilisable et contrôlée par le client.

Une équipe peut retrouver son code sans pouvoir reprendre ses livraisons. Une définition de processus manquante ou une connexion à des paramètres extérieurs suffit à distinguer une collection de fichiers d'un environnement de travail. C'est à cette différence que HYCU s'attaque avec sa nouvelle intégration Azure DevOps. L'objet commercial à protéger devient le système de livraison, pas seulement le dépôt.

Dans son annonce du 8 septembre, HYCU présente R-Cloud pour Azure DevOps comme disponible sur sa place de marché. Le périmètre déclaré comprend éléments de travail et historique, tableaux et requêtes, définitions de livraison, wikis, plans de test et paramètres d'organisation. Les modèles de processus et types d'éléments personnalisés sont inclus, avec une restauration possible à plusieurs niveaux.

Ce sont des capacités annoncées, non le résultat d'une évaluation indépendante. La possibilité revendiquée de restaurer sur place sans interrompre les équipes non touchées est importante. Le communiqué ne fournit cependant pas de test comparable mesurant le retour effectif d'un processus représentatif avec toutes ses dépendances.

La protection native n'est pas inexistante

Présenter ce lancement comme la solution à une absence totale de sauvegarde serait faux. La documentation de Microsoft décrit les sauvegardes à un instant donné du stockage et des bases sous-jacentes, la reprise après sinistre régional et la récupération d'organisations ou de projets supprimés pendant 28 jours.

Elle distingue aussi ces copies de continuité d'un service général de restauration des actifs que les clients suppriment accidentellement. Cela ne signifie pas que tous les mécanismes natifs propres à certains objets disparaissent. La question est celle du contrôle : quel objet ou état antérieur le client peut-il choisir de retrouver, et pendant combien de temps ?

HYCU propose de conserver les copies dans le stockage, le compte et la région du client, avec une rétention indépendante des fenêtres natives. Son explication produit décrit également l'immutabilité au niveau du stockage et l'isolement vis-à-vis des identifiants Azure DevOps. Ces propriétés méritent vérification ; elles ne rendent pas automatiquement sûre toute configuration de droits, toute politique ou toute administration du compte de sauvegarde.

Retrouver les dépendances

Le produit vise des liens qui dépassent le fichier visible. Une définition de livraison dépend de groupes de variables, de connexions de service et de files d'agents répartis entre différents périmètres. Un wiki associe un dépôt Git à un enregistrement de service. Les éléments de travail nécessitent leurs définitions de processus. Capturer chacun de ces objets ne démontre pas qu'ils fonctionneront de nouveau ensemble.

Une réception pertinente du service pourrait donc choisir un processus représentatif, restaurer ses composants nécessaires et vérifier son utilisation sans endommager le travail non concerné. Il s'agit d'un test proposé à l'acheteur, pas d'une expérience réalisée ici. Les annonces ne donnent ni durée de récupération mesurée pour un client ni calcul de coût comparable.

HYCU affirme aussi capturer et exporter les historiques de construction et de publication, les exécutions de tests et les journaux d'audit. Cette capacité pourrait prolonger la disponibilité des preuves. Elle ne garantit pas leur acceptation par un auditeur. La valeur économique dépend de l'état utilisable retrouvé et du sens conservé par les traces, pas seulement de la longueur de l'inventaire sauvegardé.