Automatiser les processus métier avec Power Automate — flux cloud, flux de bureau et gestion robuste des erreurs

« Chaque matin, quelqu’un rassemble les CSV accumulés dans un dossier partagé, les compile dans Excel et envoie le résultat par e-mail à sa hiérarchie. » « Des valeurs sont recopiées à la main depuis plusieurs systèmes métier juste pour produire un récapitulatif. » Nous recevons régulièrement ce genre de demandes : automatiser ce type de tâche avec Power Automate.

Le premier petit flux se met en général à fonctionner en quelques dizaines de minutes. La difficulté commence après. Une fois le flux en production depuis un moment, il s’arrête parfois avec une erreur. Un simple changement mineur dans la mise en page de l’écran du système cible suffit à casser le flux. Personne n’a tranché où stocker le mot de passe, alors il reste écrit en clair, tel quel, dans une variable d’entrée « pour l’instant ». Il existe bien un « flux qui fonctionne », mais quand quelque chose tourne mal, personne n’est vraiment capable de le réparer — nous avons vu ce schéma se répéter plusieurs fois.

Power Automate a un coût d’apprentissage faible et permet de démarrer en no-code / low-code. C’est justement cette facilité qui fait qu’il est facile de laisser la conception de côté et de se retrouver malgré tout en production. Cet article aborde, dans l’ordre où l’on trébuche le plus souvent en pratique : la différence entre flux cloud et flux de bureau, la répartition des rôles avec PowerShell et VBA, la gestion des erreurs, la façon de stabiliser l’automatisation de l’interface utilisateur, le traitement des informations d’identification, la gouvernance et l’exploitation, et enfin comment repérer le moment où l’on dépasse le périmètre de Power Automate.

1. L’essentiel à retenir

• Power Automate se divise globalement en deux familles : les flux cloud (qui relient des services cloud via des connecteurs) et les flux de bureau (une RPA qui automatise les opérations d’écran et les applications Windows). Déterminer d’abord lequel des deux est réellement nécessaire est la première décision de conception.
• Si l’objectif se limite à automatiser une « tâche répétitive sur PC », PowerShell est souvent un meilleur point de départ que Power Automate Desktop. Tant que les clics ou les saisies à l’écran ne sont pas indispensables, PowerShell est généralement plus facile à maintenir et s’intègre mieux à la gestion de versions.
• Power Automate prend toute sa valeur lorsqu’il faut opérer l’écran d’un système existant peu ou pas relié à une API, ou lorsqu’on veut construire rapidement des flux de notification et d’approbation autour des connecteurs Microsoft 365 (Outlook, SharePoint, Teams, etc.).
• Avant de passer en production, quatre points doivent être intégrés dès la conception, et non ajoutés après coup : la gestion des erreurs (On Block Error), la stabilisation des sélecteurs d’interface, la gestion sécurisée des informations d’identification, et la gouvernance via les politiques DLP.¹²
• L’exécution non supervisée (unattended) nécessite une licence et des prérequis différents de l’exécution supervisée (attended). Reporter la conception de la licence expose au risque qu’un flux fonctionnant en environnement de test ne puisse pas être déployé en production.³⁴

2. La forme générale de Power Automate

Power Automate n’est pas tant un produit unique qu’une plateforme regroupant plusieurs mécanismes d’automatisation.

flowchart TB
    PA[Power Automate]
    PA --> Cloud[Flux cloud]
    PA --> Desktop[Flux de bureau / RPA]
    PA --> Process[Exploration de processus]
    PA --> Builder[AI Builder]

    Cloud --> Auto[Flux automatisé<br/>déclenché par un événement]
    Cloud --> Sched[Flux planifié<br/>exécution périodique]
    Cloud --> Instant[Flux instantané<br/>démarrage manuel / bouton]
    Cloud --> Connectors[Connecteurs<br/>SharePoint / Outlook / Teams / SQL, etc.]

    Desktop --> Attended["Supervisé (attended)<br/>exécuté devant l'utilisateur"]
    Desktop --> Unattended["Non supervisé (unattended)<br/>exécuté sur un serveur/PC dédié"]
    Desktop --> UIAuto[Automatisation de l'interface utilisateur<br/>opération d'écran, intégration d'applications existantes]

• Le flux cloud est un mécanisme qui relie des services cloud entre eux via des connecteurs. Selon le type de déclencheur, il se divise en flux automatisé (à un événement), flux planifié (exécution périodique) et flux instantané (démarrage manuel).
• Le flux de bureau est une RPA (Robotic Process Automation) qui opère directement les applications et les écrans sous Windows. Il peut être appelé depuis un flux cloud ou s’exécuter de façon autonome.⁵
• Le flux de bureau se divise en outre en exécution supervisée (attended), qui s’exécute avec une personne devant l’écran, et exécution non supervisée (unattended), qui s’exécute sur un PC ou un serveur dédié sans intervention humaine.⁴

Une « machine dédiée » pour l’exécution non supervisée ne signifie pas simplement qu’elle ne doit pas être verrouillée. Sous Windows 10/11, l’exécution non supervisée échoue si la session de n’importe quel utilisateur subsiste, même verrouillée, indépendamment du fait qu’il s’agisse ou non de l’utilisateur utilisé pour la connexion. Sous Windows Server, le périmètre est un peu plus restreint : l’exécution est bloquée si une session verrouillée du même utilisateur que celui utilisé pour la connexion subsiste. Après une opération de maintenance ou une connexion RDP par un autre administrateur, on a tendance à se contenter de « verrouiller » ou de « déconnecter » la session, mais il faut impérativement que tout le monde se déconnecte (sign out).⁶

Lors d’une consultation, nous commençons toujours par distinguer « s’agit-il de relier des services cloud entre eux, ou d’opérer un écran ? ». Cela suffit déjà à clarifier une bonne partie du sujet.

3. Flux cloud, flux de bureau, PowerShell et VBA : comment les répartir

Même sous l’étiquette commune d’« automatisation », ces quatre outils excellent dans des domaines assez différents.

Une idée reçue fréquente en pratique consiste à penser que « vouloir automatiser » signifie automatiquement « utiliser Power Automate ». Opérer via l’interface d’un système qui dispose déjà d’une API avec Power Automate Desktop est typiquement un cas où appeler directement cette API depuis PowerShell ou .NET serait plus stable. À l’inverse, lorsqu’il faut opérer l’écran d’un ancien système métier sans API ou d’une application Win32, l’automatisation de l’interface utilisateur d’un flux de bureau devient un choix réaliste.

Remarque : les contraintes d’Excel et de VBA, ainsi que la façon d’envisager leur remplacement, sont détaillées séparément dans « Qu’est-ce que VBA - limites, avenir, et schémas de migration réalistes », qui aborde également la combinaison d’Office Scripts et de Power Automate pour les flux métier sur Microsoft 365.⁷

4. Comprendre les licences

Les licences de Power Automate se répartissent globalement entre licences par utilisateur et licences par flux (processus).³

Ce qui complique les choses ici, c’est que le modèle de licence applicable dépend non pas de « qui a créé le flux », mais de « comment il s’exécute ». Les flux automatisés et les flux planifiés s’exécutent dans le contexte de licence du propriétaire du flux, tandis qu’un flux instantané déclenché par bouton s’exécute dans le contexte de licence de l’utilisateur qui l’a appelé. Si l’exécution non supervisée fait partie du plan, vérifier les exigences de licence dès la phase de validation évite de se retrouver bloqué juste avant le passage en production. Notons par ailleurs que l’ancien « module complémentaire d’exécution non supervisée (Unattended RPA add-on) » est désormais considéré comme legacy et a été remplacé par la licence Power Automate Process. Les modules complémentaires existants sont désormais traités comme équivalents à une licence Process, mais toute nouvelle attribution doit utiliser la licence Process.³⁸⁴

Un point à surveiller : une licence Process / Hosted Process seule ne remplace pas une licence utilisateur. Attribuer une licence Process à une machine (nécessaire pour l’exécution non supervisée) suppose que cette machine ait déjà été enregistrée par un utilisateur titulaire d’une licence Power Automate Premium. De même, lorsqu’un flux cloud appelle un flux de bureau en exécution supervisée ou non supervisée, l’utilisateur de la connexion utilisée pour l’exécution doit lui aussi détenir une licence Premium (ou une autre licence incluant le droit d’exécuter des flux de bureau). Se contenter de provisionner de la capacité Process sans tenir compte des licences utilisateur nécessaires à l’exploitation mène tout droit à un blocage au stade des tests fonctionnels.³

5. Conception pratique — agréger les CSV d’un dossier partagé dans un rapport Excel et l’envoyer par e-mail

Prenons comme exemple concret la tâche courante de « production d’un rapport quotidien ».

Objectif

1. Collecter les CSV du jour dans un dossier partagé
2. Agréger leur contenu et l’écrire dans un modèle de rapport Excel
3. Enregistrer le rapport dans un dossier désigné
4. Notifier les parties prenantes par e-mail
5. En cas d’échec, notifier le responsable et consigner la cause dans un journal

flowchart TD
    Start([Déclenchement planifié 06:30]) --> Block[[On Block Error : traitement d'agrégation]]
    Block --> List[List files in folder<br/>récupérer les CSV du jour]
    List --> Check{Fichiers trouvés ?}
    Check -- Non --> NoticeEmpty[Enregistrer l'absence de fichiers et terminer]
    Check -- Oui --> Read[Read from CSV file<br/>boucle fichier par fichier]
    Read --> Agg[Agréger les valeurs dans des variables]
    Agg --> Excel[Launch Excel<br/>ouvrir le modèle]
    Excel --> Write[Write to Excel worksheet<br/>écrire les valeurs agrégées]
    Write --> Save[Enregistrer et fermer Excel]
    Save --> Mail[Send an email<br/>envoyer le rapport aux destinataires]
    Mail --> Log[Ajouter le résultat au fichier journal]
    Log --> End([Fin normale])
    Block -. erreur .-> Handler[Gestionnaire d'erreur]
    Handler --> CloseExcel[Fermer Excel si une instance reste ouverte]
    CloseExcel --> LogErr[Enregistrer l'erreur dans le journal]
    LogErr --> Notify[Notifier l'administrateur]
    Notify --> End2([Enregistré comme une exécution en échec])

Voici les principales actions et leur rôle.

Plutôt que de construire tout le flux comme une seule longue liste d’actions, le découper en sous-flux — « récupération des fichiers », « agrégation », « écriture Excel », « notification », « journalisation » — facilite les corrections ultérieures et les réexécutions isolées. Déclencher sur une planification depuis un flux cloud tout en déléguant le traitement réel à un flux de bureau appelé est également une structure qui reste facile à exploiter dans la durée.⁵

6. Concevoir la gestion des erreurs

Power Automate Desktop propose l’action On Block Error, qui permet de configurer la gestion des erreurs pour tout un bloc à la fois. Plutôt que de définir le « comportement en cas d’erreur » action par action, elle applique une gestion des erreurs commune à toutes les actions contenues dans le bloc.¹

[On Block Error] Bloc de traitement d'agrégation
  ├─ List files in folder
  ├─ Read from CSV file (boucle)
  ├─ Launch Excel / Write to Excel worksheet
  └─ Save Excel / Close Excel

[Gestionnaire d'erreur]
  ├─ Récupérer le détail de l'erreur (nom, lieu, action concernée, message détaillé) dans une variable avec l'action Get last error
  ├─ Fermer l'instance Excel si elle est restée ouverte (ne pas sauter le nettoyage justement en cas d'échec)
  ├─ Enregistrer dans le journal avec Write text to file (Append)
  ├─ Notifier l'administrateur avec Send an email (V2)
  └─ Choisir « reprendre depuis la fin du bloc » ou « arrêter l'exécution du flux »

Voici quelques points à bien avoir en tête.

• La gestion des erreurs d’une action individuelle est prioritaire sur celle du bloc, donc si une action précise doit se comporter différemment, configurez-la individuellement, et laissez On Block Error couvrir tout le reste.¹
• « Retry action if an error occurs » permet de retenter automatiquement une action, un nombre de fois et à un intervalle définis, pour des erreurs transitoires (latence réseau, fichier verrouillé, etc.). Faire de chaque erreur une candidate à la nouvelle tentative fait perdre du temps inutilement ; distinguez donc les erreurs qui méritent une nouvelle tentative de celles qui n’en méritent pas (incohérence de données, par exemple).¹
• Pour consulter, à l’intérieur du gestionnaire d’erreur, le détail de l’erreur qui vient de se produire, placez explicitement une action Get last error. Elle renvoie une variable dotée de six propriétés — nom, emplacement, action concernée, sous-flux d’appartenance, détail et message de l’erreur — et n’est pas mise à disposition automatiquement comme une variable implicite. Pour éviter qu’une même valeur d’erreur soit réutilisée par erreur plus tard, il est plus sûr de l’effacer ensuite avec l’option « Clear error ».¹
• Les journaux ne doivent pas se limiter à « succès/échec » : consignez aussi le nombre d’éléments traités, le nom du fichier concerné et le message d’erreur. Après coup, le journal est souvent le seul indice permettant de comprendre « pourquoi ça s’est arrêté ».
• Comme traitement après le bloc, choisissez explicitement entre « reprendre depuis la fin du bloc » et « arrêter l’exécution du flux ». S’arrêter en laissant une instance Excel ouverte conduit à des incidents comme un processus qui reste actif à l’exécution suivante ; c’est précisément en cas d’erreur qu’il faut penser au nettoyage (fermeture des instances).¹¹

Pour qui est habitué à try/catch/finally en PowerShell, il est utile de se représenter le « bloc » d’On Block Error comme un try, le gestionnaire d’erreur comme un catch, et la séquence de nettoyage comme un finally — cette image facilite la conception.

7. Stabiliser l’automatisation de l’interface utilisateur

La principale cause d’instabilité d’un flux de bureau tient le plus souvent à la façon dont les éléments d’interface sont identifiés (le sélecteur).

• Par défaut, le sélecteur d’éléments d’interface enregistre un élément d’écran sous forme de sélecteur (une combinaison d’attributs). Si ce sélecteur inclut des attributs fragiles face aux mises à jour d’application ou aux changements d’affichage (un index séquentiel, un identifiant généré dynamiquement, etc.), le flux peut se casser même si l’écran paraît identique.¹²
• Remplacer Equals par Contains ou une expression régulière pour les attributs dont la valeur change, et transformer en variables les valeurs dépendant du résultat d’une action précédente, produit des sélecteurs plus dynamiques et moins susceptibles de se casser.¹²
• Configurer plusieurs sélecteurs permet un repli automatique vers le suivant si le premier échoue. Prévoir un sélecteur de secours pour toute opération importante améliore la stabilité.¹²
• Lorsqu’un sélecteur se casse, la fonction Repair selector peut générer automatiquement des candidats de réparation. Cela vaut la peine de l’essayer avant de tout reconstruire manuellement.¹²
• Les transitions d’écran et les lancements d’application prennent un temps variable. Plutôt que de vous fier uniquement à un Wait fixe, combinez des actions d’attente conditionnelle telles que « attendre une fenêtre » ou « attendre qu’un élément d’interface soit trouvé », et configurez en parallèle une nouvelle tentative automatique lorsque l’élément n’est pas trouvé.¹³
• Pour une cible d’automatisation qui refuse obstinément de se stabiliser (écran virtualisé, mise en page qui change fréquemment, etc.), ne vous entêtez pas sur l’opération d’interface : vérifiez d’abord s’il n’existe pas un mode d’intégration plus stable — API, échange de fichiers, accès à une base de données.

Faire fonctionner une automatisation de l’interface une première fois n’a rien de difficile en soi. Mais qu’elle fonctionne encore sans casse six mois plus tard dépend presque entièrement de la façon dont les sélecteurs ont été construits.

8. Gérer les informations d’identification en toute sécurité

Dans l’automatisation métier, c’est la gestion des informations d’identification (mots de passe, clés d’API, chaînes de connexion, etc.) qui est la source d’incidents la plus fréquente.

• Évitez d’écrire un mot de passe ou des informations de connexion directement comme valeur dans une variable d’entrée du flux. L’action Get credential permet de récupérer une information d’identification en toute sécurité depuis un « identifiant Power Automate » adossé à un coffre de secrets externe tel qu’Azure Key Vault ou CyberArk ; la valeur récupérée est marquée comme sensible et n’apparaît pas dans les journaux d’exécution du flux.¹⁴¹⁵
• Utiliser Azure Key Vault comme emplacement de stockage des secrets permet de centraliser côté Power Automate les informations de connexion vers Key Vault, évitant de disperser les informations d’identification flux par flux.¹⁵
• Pour l’exécution non supervisée, prévoyez un compte dédié dont le périmètre est réduit au strict nécessaire, plutôt que de réutiliser le compte qu’une personne utilise au quotidien. Plus les droits d’un compte sont étendus, plus l’impact potentiel d’un bug ou d’une erreur de configuration dans le flux s’étend lui aussi.
• Écrire un mot de passe en clair « temporairement, pour que ça marche » et poursuivre la validation ainsi a tendance à laisser cette valeur telle quelle jusqu’en production. Il est plus sûr de prendre l’habitude d’utiliser l’action Get credential dès la phase de validation.

9. Gouvernance et exploitation

Lorsque les flux créés par des individus ou de petites équipes se multiplient, un contrôle à l’échelle de l’organisation devient nécessaire.

• Les politiques de prévention de la perte de données (DLP) classifient les connecteurs utilisables dans les flux et les applications en catégories telles que « données métier uniquement », « données métier interdites » ou « bloqué », et empêchent qu’un même flux combine un connecteur de données métier avec un connecteur interdit aux données métier. C’est la première couche de gouvernance à mettre en place, car c’est elle qui empêche une fuite involontaire des données de l’organisation vers un service externe.¹⁶
• Les actions des flux de bureau peuvent elles aussi être classifiées et bloquées dans le même cadre de politiques DLP, mais cette couverture n’est pas activée par défaut. Il faut d’abord activer une fois le paramètre de locataire « Show desktop flow actions in DLP policies » dans le centre d’administration Power Platform, et ce paramètre ne peut plus être désactivé ensuite. Même après activation, seuls les modules et actions explicitement classifiés par une politique sont réellement contrôlés : avoir créé une politique DLP ne signifie donc pas que l’ensemble des flux de bureau est sous contrôle.²
• Regroupez les machines dédiées à l’exécution non supervisée en groupes de machines, afin de savoir clairement quel flux s’exécute sur quelle machine.
• L’historique d’exécution est consultable depuis l’écran d’administration et l’historique d’exécution de Power Automate. Intégrer une alerte en cas d’échec (notification Teams ou par e-mail) directement dans le traitement du flux permet de remarquer une anomalie sans que quelqu’un doive aller vérifier manuellement.
• Pour qu’un flux cloud accède à une ressource sur site inaccessible directement depuis le cloud — une base de données ou un partage de fichiers du réseau interne, par exemple — utilisez la passerelle de données locale (on-premises data gateway). Elle ne nécessite l’ouverture d’aucun port entrant côté cloud, et fait le pont en toute sécurité via une simple connexion sortante.¹⁷
• Séparer les environnements de validation et de production, et cloisonner les flux de bureau et les informations de connexion par environnement, évite qu’une modification en cours de validation n’affecte les flux en production.

10. Les limites de Power Automate, et quand escalader

Power Automate est puissant, mais pas universel. Dans les situations suivantes, envisagez de basculer vers PowerShell ou une application .NET.

Quand on sent que « ce qu’on a construit avec Power Automate a grandi et est devenu trop complexe », plutôt que de continuer à étendre le flux de force, il est souvent plus judicieux, à terme, d’extraire le traitement principal vers .NET ou PowerShell, et de réserver Power Automate au déclenchement et à la notification. Un exemple concret d’automatisation de l’investigation et de l’archivage des journaux avec PowerShell est présenté dans un autre article, « PowerShell avancé — automatiser en toute sécurité l’investigation, l’archivage et le reporting des journaux ».

11. Conclusion

Power Automate est étonnamment simple jusqu’au premier pas. Mais cette facilité a un revers : « même en bâclant la conception, ça finit par fonctionner, au moins une fois ». Qu’un flux mis en production reste maintenable sur la durée dépend presque entièrement du nombre de décisions discrètes réglées dès le départ.

Choisir entre flux cloud et flux de bureau, et identifier quels traitements il vaut mieux confier à PowerShell ou à .NET : faire ce tri en amont réduit considérablement les reprises ultérieures. Gestion des erreurs, sélecteurs d’interface, informations d’identification, licences, politiques DLP — pour chacun de ces sujets, « les intégrer dès le départ » revient nettement moins cher que « les corriger une fois que ça a cassé ». Et être capable, lorsqu’un flux grandit et se complexifie, de faire le choix de basculer le traitement vers .NET ou PowerShell plutôt que de continuer à l’étendre de force, détermine tout autant s’il restera utilisable durablement.

Il existe un tel écart de conception entre « un flux qui fonctionne, tant bien que mal » et « un flux auquel on peut se fier en toute tranquillité ». Plus l’automatisation touche à des systèmes métier existants ou à des actifs Excel / VBA, plus les décisions de conception prises au départ pèsent lourd sur le coût de maintenance à long terme.

Articles connexes

• Qu’est-ce que VBA - limites, avenir, et schémas de migration réalistes
• PowerShell avancé — automatiser en toute sécurité l’investigation, l’archivage et le reporting des journaux
• Comment créer une sortie de rapport Excel - tableau de décision entre l’automatisation COM, Open XML et l’approche par modèles

Domaines de conseil associés

KomuraSoft LLC accompagne les projets d’automatisation et de modernisation progressive qui préservent les actifs métier Excel / VBA / Windows existants, ainsi que les revues de conception de plateformes d’automatisation incluant Power Automate.

• Valorisation et migration des actifs existants
• Conseil technique et revue de conception
• Développement d’applications Windows
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Comment choisir entre flux cloud et flux de bureau ?

Le flux cloud est un mécanisme qui relie des services cloud entre eux via des connecteurs ; il convient aux flux d'approbation, aux notifications, à l'intégration SaaS et aux flux métier autour de Microsoft 365. Le flux de bureau est une RPA qui opère directement les applications et les écrans sous Windows ; c'est un choix réaliste lorsqu'il faut opérer l'écran d'un ancien système métier sans API ou d'une application Win32. Lors d'une consultation, commencer par distinguer « s'agit-il de relier des services cloud entre eux, ou d'opérer un écran ? » clarifie déjà beaucoup les choses.

Faut-il utiliser Power Automate ou PowerShell ?

Si l'objectif est simplement d'automatiser une tâche répétitive sur un PC et que les clics ou saisies à l'écran ne sont pas indispensables, PowerShell est souvent plus facile à maintenir et s'intègre mieux à la gestion de versions avec Git. Opérer l'interface d'un système qui dispose déjà d'une API est normalement plus stable en appelant directement cette API depuis PowerShell ou .NET. Le traitement de données à l'échelle de centaines de milliers de lignes, une logique complexe nécessitant des tests automatisés, ou un traitement résident à haute fréquence relèvent également plutôt de PowerShell ou .NET. Si un flux devient trop complexe, en extraire le traitement principal et réserver Power Automate au déclenchement et à la notification rend l'ensemble plus facile à maintenir.

Quelle licence faut-il pour exécuter des flux de bureau en mode non supervisé ?

L'exécution non supervisée nécessite une licence différente de l'exécution supervisée : la licence Power Automate Process, qui se rattache à un flux ou à une machine plutôt qu'à une personne. L'ancien module complémentaire d'exécution non supervisée est désormais considéré comme legacy et a été remplacé par la licence Process. Par ailleurs, la licence Process seule ne remplace pas une licence utilisateur : l'enregistrement de la machine nécessite un utilisateur titulaire d'une licence Power Automate Premium. Enfin, sous Windows 10/11, l'exécution non supervisée échoue si la session de n'importe quel utilisateur reste verrouillée ; il faut donc que tout le monde se déconnecte complètement (sign out).

Pourquoi l'automatisation de l'interface utilisateur d'un flux de bureau devient-elle instable ?

La cause principale tient le plus souvent à la façon dont les éléments d'interface sont identifiés (le sélecteur). Si le sélecteur inclut des attributs fragiles face au changement, comme un index séquentiel ou un identifiant généré dynamiquement, le flux peut se casser même si l'écran paraît identique. En pratique, il convient de remplacer Equals par Contains ou une expression régulière pour les attributs dont la valeur change, de configurer plusieurs sélecteurs pour permettre un repli automatique, et d'utiliser la fonction Repair selector pour générer des candidats de réparation en cas de rupture. Il est également important de ne pas se fier uniquement à des attentes fixes (Wait) et de les combiner avec des actions d'attente conditionnelle. Que le flux fonctionne encore sans casse six mois plus tard dépend presque entièrement de la façon dont les sélecteurs ont été construits.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.