Déploiement de fonctionnalités

De nouveaux produits et fonctionnalités sont introduits progressivement sur ces plates-formes cloud. En général, les nouvelles fonctionnalités sont d'abord disponibles dans Test Cloud, puis sont mises à disposition dans Test Cloud pour le secteur public et Test Cloud dédié, sous réserve des exigences de conformité, d'infrastructure et de disponibilité de version. La disponibilité peut donc varier en fonction de la plate-forme Cloud que vous utilisez.

Déploiement des fonctionnalités de Test Cloud

Quand les mises à jour sont-elles disponibles ?

Les mises à jour que nous annonçons dans les notes de publication de Test Cloud sont rendus disponibles de façon progressive, en fonction des éléments suivants :

• votre plan de licence
• la région de votre organisation et de votre locataire.

Par conséquent, le moment où les mises à jour sont disponibles peut varier selon l'utilisateur.

La date à laquelle une modification est annoncée pour la première fois dans les notes de publication est la date à laquelle elle est disponible pour la première fois. Si vous n'avez pas encore remarqué le changement, il est probable qu'il le soit bientôt.

Version Community : les modifications sont d’abord disponibles pour les utilisateurs Community. C’est à ce moment que nous publions les notes de version.

Version Enterprise: si vous êtes un utilisateur Enterprise, le déploiement sera généralement disponible pendant une fenêtre d’une heure à 14 jours après le déploiement dans Community. Dans certains cas, certaines fonctionnalités peuvent nécessiter un temps supplémentaire avant d'être disponibles dans Enterprise. Les locataires de contrôle de validité, qui sont utilisés pour les tests, reçoivent généralement les mises à jour trois jours après leur annonce. Le délai exact à partir duquel ces modifications vous sont accessibles dans la région d’hébergement sélectionnée variera en fonction de la date à laquelle les modifications ont été déployées avec succès dans l’ensemble des régions.

Nous n'annonçons pas les versions Enterprise ou les versions destinées aux différentes régions de façon séparée.

Le tableau suivant donne un exemple du moment où une fonctionnalité devient disponible pour les utilisateurs Community, ainsi que pour les utilisateurs Enterprise :

Date de la note de publication	Date de publication pour Community	Date de publication pour Enterprise
14 juillet 2025	14 juillet 2025	à partir du 14 juillet 2025

Modifications spécifiques aux organisations Enterprise

Si une modification est exclusive au plan Enterprise, nous la signalons en utilisant l'étiquette Enterprise () dans les notes de publication. Pour ce type de modification, la première version est envoyée directement aux utilisateurs Enterprise et Enterprise Trial. Vous pouvez vous attendre à ce que ces modifications soient effectives dès la date des notes de publication, mais cela peut prendre quelques jours avant qu'elles ne soient disponibles dans votre région.

Le tableau suivant sert d'exemple lorsqu'une fonctionnalité devient disponible uniquement pour les utilisateurs Enterprise :

Date de la note de publication	Date de publication pour Community	Date de publication pour Enterprise
14 juillet 2025	S/O	à partir du 14 juillet 2025

Organisations disposant de la fonctionnalité de mise à jour différée

Cette fonctionnalité est disponible pour les clients Enterprise disposant d'une licence Advanced Tier.

Contactez l’équipe commerciale UiPath pour plus d’informations sur la façon de passer client Advanced Tier.

Si votre organisation est hébergée dans une région avec mise à jour différée, vous recevez les mises à jour de Test Cloud et de ses services au moins deux semaines après qu'elles aient impacté d'autres organisations Enterprise, selon les règles décrites précédemment.

Le nombre exact de jours nécessaires pour que les modifications soient répercutées dans votre organisation soumise à mise à jour différée, dans la région d'hébergement choisie, peut être légèrement supérieur à 14 jours, en fonction du moment où nous finissons de déployer les modifications dans toutes les régions.

Vous pouvez utiliser une organisation Enterprise standard comme environnement de préproduction pour tester les mises à jour, et utiliser votre organisation avec mise à jour différée comme environnement de production. Une fois les mises à jour disponibles dans votre organisation Enterprise, vous pouvez tabler sur un délai approximatif de deux semaines pour que les modifications soient répercutées dans votre organisation avec mise à jour différée.

Régions

La fonctionnalité de mise à jour différée est disponible dans les régions d'hébergement des États-Unis et de l' Union européenne .

Services qui bénéficient de mises à jour retardées

Les services UiPath peuvent prendre en charge les mises à jour différées aux États-Unis ou au sein de l’Union européenne. Pour voir quels services prennent en charge les mises à jour différées dans ces régions, consultez la page Régions cloud à l'échelle mondiale .

Page de statut

Pour rester au courant de la disponibilité de tous les services UiPath®, des périodes de maintenance planifiées ou des incidents, consultez la page Statut.

Déploiement de fonctionnalités de Test Cloud pour le secteur public

Notre approche d’introduction de nouvelles fonctionnalités ou mises à jour dans Test Cloud pour le secteur public est conçue pour vous garantir une transition transparente et efficace.

À quoi s'attendre

1. Notes de publication: après avoir finalisé le développement et le test des nouvelles fonctionnalités ou mises à jour, nous les annonçons via des notes de publication. Ces notes de publication sont accessibles à l’ adresse suivante : https://docs.uipath.com/fr/.
2. Transparence: nos notes de publication sont conçues pour être transparentes et informatives. Ils détaillent les conséquences de cette nouvelle fonctionnalité et des changements qu’elle apporte aux fonctionnalités existantes.
3. Calendrier : les utilisateurs devraient pouvoir accéder aux nouvelles fonctionnalités ou mises à jour peu de temps après la publication des notes de publication. Si le calendrier précis peut varier en fonction de la complexité de la fonctionnalité ou de la mise à jour, notre objectif est de les rendre accessibles dès que possible après leur annonce.

Pour rester au courant de la disponibilité de tous les services UiPath®, des périodes de maintenance planifiées ou des incidents, consultez la page Statut.

Déploiement de fonctionnalités de Test Cloud dédié

L’un des principaux avantages de Test Cloud dédié est la possibilité de contrôler les mises à niveau. Il répond à des exigences spécifiques pour la mise à jour de vos applications UiPath essentielles, en vous permettant de tirer parti des aspects clés tels que les suivants :

• Planification du moment où votre plate-forme et vos services UiPath peuvent subir des mises à jour, évitant ainsi toute interruption de l'activité. Par exemple, vous pouvez éviter les mises à jour pendant les hautes disponibilités telles que les vacances de fin de l'année.
• Détermination du calendrier de déploiement des nouvelles fonctionnalités sur votre plate-forme. Cela vous permet de planifier la validation des automatisations et des nouvelles fonctionnalités dans les environnements de test et de production.

Processus de publication

Cette page explique comment les mises à jour sont livrées, contrôlées et communiquées entre les environnements dans Test Cloud Dedicated, à l'aide d'un modèle de déploiement basé sur des cercles.

Vue d'ensemble de la version

Des versions dédiées à Test Cloud sont générées toutes les deux semaines. Chaque sprint fournit une charge utile qui inclut : de nouvelles fonctionnalités et améliorations, des correctifs de sécurité, une infrastructure, des mises à jour de configuration et des corrections de bogues.

Toutes les mises à jour suivent une stratégie de déploiement basée sur le cercle régie par un plan de déploiement de service.

Calendrier de déploiement et environnements

Le cycle de vie du déploiement de Test Cloud dédié comprend les composants suivants :

• Cadence de publication : les publications suivent un calendrier de publication d’une fois par deux semaines. Chaque sprint comprend des mises à jour cumulatives, telles que de nouvelles fonctionnalités, des améliorations, des correctifs de sécurité et des corrections de bogues.
• Déploiement basé sur des cercles : les versions progressent par plusieurs environnements à la fois, Sandbox étant le premier environnement. Les environnements suivants dépendent de votre planification et de votre architecture de déploiement préférées. L’environnement Sandbox est une instance partagée que vous pouvez utiliser pour valider les mises à jour à l’avance. C'est à ce moment que les notes de version sont publiées.
  Remarque :

  Le flux de déploiement exclut les fenêtres invalides et les périodes de gel.

Types de versions

Test Cloud dédié vous fournit deux types de mises à jour :

• Version standard : déploiement régulier de mises à jour du produit, de l'infrastructure et de la configuration toutes les deux semaines.
• Versions de correctif : correctif d’urgence pour les vulnérabilités de sécurité ou les bogues à fort impact.

Correctifs et versions d'urgence

Pour les correctifs de haute priorité, le cycle de vie du déploiement suit les exceptions suivantes :

• Les versions sont suivies rapidement dans tous les processus.
• Les délais de sonnerie, les fenêtres de maintenance et les fenêtres d’indisponibilité peuvent être ignorés en fonction de l’urgence.
  Remarque :

  Seules les régressions du précédent comportement de Test Cloud dédiés sont éligibles pour les correctifs.

Commandes de mise à niveau

Test Cloud dédié offre davantage de flexibilité lors du déploiement des mises à jour. Vous pouvez configurer votre environnement de production à l'aide des types de contrôle de mise à niveau suivants :

• Publication différée : diffère les mises à jour pendant 30 jours.
• Fenêtre d’indisponibilité : empêche les déploiements pendant une période fixe. Les règles d'une période d'indisponibilité sont les suivantes :
  • Peut durer au maximum 30 jours consécutifs.
  • Doit être suivi d’une période ouverte de 10 jours avant qu’une autre période d’indisponibilité ne puisse être appliquée.
  • Doit être soumis au moins cinq jours ouvrables à l’avance.
  • Impossible de bloquer les planifications de déploiement au cours des prochaines 48 heures. Par exemple, vous pouvez prolonger une fenêtre d'indisponibilité qui se termine dans moins de deux jours, mais vous pouvez ajuster une fenêtre d'indisponibilité qui se termine dans plus de cinq jours.
• Période de maintenance : vérifiez que les mises à niveau ont lieu en dehors des heures ouvrables. La fenêtre de maintenance est généralement planifiée entre 15 h et 9 h EST. Une fenêtre continue de 6 heures est recommandée pour les mises à niveau dans tous les environnements de production.
  Remarque :

  L'environnement Sandbox est exclu des périodes d'indisponibilité et de maintenance.

Communications et responsabilité des utilisateurs

Pour vous assurer que les versions sont déployées dans votre organisation dédiée à Test Cloud, vous devez consulter les ressources suivantes :

• Notes de publication : Publié le même jour, l’environnement Sandbox est mis à niveau.
• Notifications de page de statut : utilisées pour tout temps d'arrêt, avec au moins sept jours.

En tant qu'utilisateur dédié à Test Cloud, vous devez effectuer les opérations suivantes :

1. Vérifiez régulièrement les notes de publication et les mises à jour de la page de statut.
2. Examinez les notes de version une fois publiées.
3. Validez les modifications dans la Sandbox et tous les autres environnements approuvés.
4. Ouvrez un ticket d'assistance pour suspendre la version de production si vous constatez des régressions ou des problèmes de performances.

Exemple de déploiement

Par exemple, si une version de sprint est déployée dans la Sandbox le 7 juillet et que le délai de production est de 30 jours, le calendrier sera le suivant :

1. Mise à niveau de la Sandbox effectuée le 7 juillet.
2. Notes de publication publiées le 7 juillet.
3. Mise à niveau de production effectuée le 9 août.

À propos des contrôles de mise à niveau

Nous proposons deux types de contrôles :

1. Version différée : Cela vous permet de reporter les mises à jour jusqu'à 30 jours.
2. Fenêtre d’indisponibilité : nous garantissons qu’aucune mise à jour n’a lieu pendant une période spécifique avec une fenêtre d’indisponibilité allant jusqu’à 30 jours.

Pour garantir que les organisations Test Cloud restent informées, nous avons appliqué les restrictions suivantes :

• Les fenêtres d’indisponibilité ne peuvent fonctionner que pendant une période continue de 30 jours. Cela permet de tenir compte d'une période de gel de 30 jours pour vos besoins de fin de l'année.
• Chaque fenêtre d’indisponibilité doit être suivie d’une pause d’au moins 10 jours, ce qui permet à UiPath de disposer de suffisamment de temps pour déployer les mises à jour après une longue période d’indisponibilité.
• Toute modification de la fenêtre d’indisponibilité doit être soumise via un ticket 5 jours ouvrables avant la modification prévue.
• Vous n'êtes pas autorisé à implémenter des modifications qui entraîneraient le blocage du temps dans les prochaines 48 heures, qui avait été précédemment débloquées.

La section suivante présente quelques exemples pour vous aider à mieux comprendre ces directives :

• Si vous êtes dans une fenêtre d’indisponibilité qui se termine par 5 jours, vous pouvez soit étendre, soit réduire cette fenêtre car elle ne bloquera aucune nouvelle période.
• Si la fenêtre d’indisponibilité se termine dans 1 jour, elle ne peut pas être étendue car le jour suivant serait alors bloqué.
• S'il n'y a pas de fenêtre d'indisponibilité actuelle et que vous souhaitez en établir une qui commence dans 1 jour, une telle fenêtre ne peut pas être créée.

Gestion des contrôles de mise à niveau

Pour configurer les deux contrôles de mise à niveau disponibles dans Test Cloud, vous devez contacter notre équipe d'assistance et créer des tickets d'assistance.