Quand une mise à jour Windows paralyse vos robots UiPath : le piège du Patch Tuesday

Une mise à jour Windows peut paralyser vos robots UiPath pendant la nuit sans que personne ne s'en aperçoive. Les robots sans surveillance travaillent pendant les heures où personne n'est au bureau. C'est exactement dans cette fenêtre que la plupart des entreprises planifient également les exécutions de maintenance pour les correctifs du système d'exploitation. Le matin, il n'y a pas d'erreur, juste aucun résultat.

Pourquoi une mise à jour Windows paralyse-t-elle les robots sans surveillance ?

Un robot sans surveillance a besoin de trois choses, et une mise à jour peut modifier les trois : une session Windows active, une interface inchangée de l'application cible et une machine accessible.

Le redémarrage est la partie évidente. La partie moins évidente est la connexion qui suit. UiPath documente plusieurs stratégies de groupe Windows pour les scénarios sans surveillance qui empêchent une connexion automatique. La stratégie „Display information about previous logons during user logon“ génère une fenêtre contextuelle de sécurité lors de la connexion et fait échouer le robot avec le code d'erreur 0x80070520 ; elle doit être définie sur Disabled . De même, „Sign-in and lock last interactive user automatically after a restart“ interfère avec la création de session et ne doit pas être configurée ou désactivée (Source : UiPath Robot, Session troubleshooting).

Quand arrivent les mises à jour ? Le rythme Microsoft en détail

Microsoft publie les mises à jour de sécurité mensuelles pour Windows le deuxième mardi de chaque mois, généralement à 10:00 Pacific Time. Celui qui ne connaît que cette date ne connaît que les deux tiers du cycle.

Selon le propre aperçu de Microsoft du cycle de publication des mises à jour, il y a trois déclencheurs pertinents pour les redémarrages non planifiés (Source : Microsoft Learn, Update release cycle for Windows clients) :

• Mise à jour de sécurité mensuelle : deuxième mardi du mois, cumulative, classée comme obligatoire par la plupart des organisations.
• Mise à jour d'aperçu optionnelle : quatrième mardi du mois, non liée à la sécurité, sert à la validation précoce de la prochaine mise à jour de sécurité.
• Sortie hors bande : selon les besoins, sans date fixe, lorsqu'une vulnérabilité aiguë doit être fermée.

Un calendrier qui ne bloque que le deuxième mardi ne couvre pas le quatrième mardi et les sorties hors bande.

Pourquoi les sélecteurs se cassent-ils après une mise à jour ?

Les sélecteurs identifient un contrôle via ses propriétés dans l'arborescence des fenêtres. Si une mise à jour modifie ces propriétés, le robot ne trouve plus l'élément, même s'il semble inchangé pour un humain.

UiPath énumère plusieurs causes du dépannage des sélecteurs, dont trois sont directement liées aux mises à jour (Source : UiPath, Troubleshooting selectors) :

• Broken selectors after browser updates: Les mises à jour du navigateur modifient la structure de la page rendue. La mise à jour des paquets d'activités est recommandée.
• UI changes in target application: Une mise à jour de fonctionnalité de l'application métier déplace des nœuds ou des attributs. La solution est d'ajuster les nœuds de sélecteur ou d'utiliser Unified Target avec secours de vision par ordinateur.
• Differences in the environment: Test et Production s'exécutent avec une mise à l'échelle différente. UiPath recommande une mise à l'échelle de 100 pour cent partout dans tous les environnements.

Les sélecteurs robustes ne sont donc pas un luxe, mais l'assurance la moins chère contre les jours de correctif. Caractères génériques pour les parties dynamiques, attributs stables comme aaname ou id au lieu d'indices de position, et ancres au lieu de chemins rigides. Le même principe s'applique entre les outils, nous l'avons décrit plus en détail pour la page Microsoft dans sélecteurs robustes et temps d'attente dans Power Automate Desktop.

Comment aligner les fenêtres de mise à jour et le calendrier des robots ?

Les fenêtres de mise à jour et le calendrier des robots ne doivent pas se chevaucher, et la mise à jour doit s'exécuter en premier. Un robot qui démarre à 02:00 alors que le correctif redémarre à 02:30 perd son exécution au milieu de la transaction.

Microsoft recommande pour les machines virtuelles un plan de correctif échelonné qui peut être transféré presque inchangé aux machines robots : Développement le deuxième mardi, Test le deuxième mercredi, Production seulement le deuxième samedi ou le dimanche suivant (Source : Microsoft Learn, Scalable Windows virtual machine patch management). Les jours entre les deux sont la fenêtre de validation.

En pratique, cela signifie : désactiver ou reporter les déclencheurs de la nuit de correctif, placer le redémarrage dans une fenêtre sans jobs en cours d'exécution et lancer un petit processus de vérification avant la première exécution productive.

Comment savez-vous qu'un robot s'arrête avant que le client ne le remarque ?

L'Orchestrator signale un robot comme Unresponsive si le robot et l'Orchestrator n'ont pas communiqué entre eux au cours des deux dernières minutes (Source : UiPath Orchestrator, Robot Statuses). Ce signal est là, il doit juste arriver à quelqu'un.

L'Orchestrator connaît les niveaux de gravité Info, Success, Warn, Error et Fatal et remet les messages par quatre voies : la bannière dans l'interface, le panneau Alertes, la page Alertes et les résumés par e-mail. Important pour les exécutions nocturnes est la différence entre les deux formats de courrier : Le résumé de dix minutes ne contient que les alertes des niveaux Fatal et Error, le résumé quotidien collecte tous les événements abonnés à partir de 10h00 heure locale (Source : UiPath Orchestrator, Alerts).

Celui qui n'a que le résumé quotidien abonné n'apprend une panne à 02:00 que le matin au plus tôt. Pour les exécutions nocturnes, le résumé de dix minutes est le bon choix, complété par un contrôle métier : un job techniquement vert qui n'a déplacé zéro enregistrements est l'erreur qu'aucune alarme système ne détecte.

Dans nos projets d'automatisation, c'est exactement l'écart le plus courant : la surveillance technique est en place, mais le contrôle de succès métier fait défaut. Ce que NordFlux prend en charge concrètement, figure sur notre page de Conseil UiPath et sur notre page d'Automatisation des processus en général.

Qu'y a-t-il dans l'environnement de test et la restauration ?

Un environnement de test pour RPA n'est utile que s'il a le même niveau de patch et la même mise à l'échelle d'écran que la production. Sinon, vous testez un système différent et manquez exactement la déviation qui casse le sélecteur.

Le chemin de restauration doit être défini avant le premier jour du correctif. Trois points suffisent comme équipement minimum :

• Snapshot avant la mise à jour : Pour les machines robots virtuelles, un point de contrôle immédiatement avant la fenêtre de maintenance. C'est le moyen le plus rapide de revenir à un état fonctionnel.
• Conserver la version de l'automatisation : La dernière version du processus exécutée avec succès reste disponible dans l'Orchestrator, afin qu'un retour en arrière ne soit pas entravé par un paquet manquant.
• Chemin de remplacement manuel : Pour chaque processus critique pour l'entreprise, il doit être documenté comment il s'exécute un jour sans robot. Sans ce plan, un problème de correctif devient un problème de livraison.

Questions fréquemment posées

Quand exactement est le Patch Tuesday ?

Microsoft publie les mises à jour de sécurité mensuelles pour Windows le deuxième mardi de chaque mois, généralement à 10:00 Pacific Time, ce qui correspond à la fin de l'après-midi en Allemagne. En outre, le quatrième mardi, il y a une mise à jour d'aperçu optionnelle sans contenu de sécurité et, si nécessaire, des sorties hors bande sans date fixe.

Puis-je simplement désactiver les mises à jour Windows sur les machines robots ?

Non, cela ne fait que déplacer le problème et crée un risque de sécurité. Les mises à jour de sécurité mensuelles sont cumulatives, un rattrapage ultérieur apporte tous les changements manqués à la fois et donc un plus grand risque de rupture qu'une petite étape régulière. Un plan échelonné avec une fenêtre de maintenance fixe est judicieux, pas une suspension.

Comment savoir si un sélecteur est cassé par une mise à jour ?

Typiquement, c'est une erreur lors de la détection de l'élément qui se produit pour la première fois exactement après une fenêtre de maintenance et se produit toujours au même endroit du processus. UiPath cite comme causes, entre autres, les mises à jour du navigateur, les interfaces modifiées de l'application cible et la mise à l'échelle différente entre le test et la production. Vérifiez d'abord si l'erreur se produit sur toutes les machines ou seulement sur celles déjà corrigées.

La notification par e-mail de l'Orchestrator suffit-elle comme surveillance ?

Pour le niveau technique, oui, pour le niveau métier, non. Le résumé de dix minutes signale rapidement les alertes des niveaux Fatal et Error, mais ne signale pas quand un job s'exécute techniquement correctement et traite zéro transactions. Par conséquent, complétez-le par une vérification de la quantité qui compare le nombre réel traité à une valeur attendue.

Quelle est la première étape si les robots s'arrêtent régulièrement après les mises à jour ?

Placez la fenêtre de maintenance et le calendrier des robots côte à côte par écrit et vérifiez si la mise à jour est complète avant la première exécution. Le plus souvent, l'ordre est le problème, pas l'automatisation. Ce n'est qu'après cela que l'effort pour des sélecteurs plus robustes en vaut la peine.