Connecter un logiciel legacy sans API : le cas de l'ERP historique dans les PME

De nombreuses PME allemandes utilisent le même ERP ou logiciel de gestion commerciale depuis vingt ans ou plus. Le système tourne de façon stable, tout le monde connaît les écrans par cœur, mais il n'a jamais reçu d'interface moderne. Vous saisissez les commandes à la main, vous maintenez les données de base écran par écran, vous extrayez les rapports par copier-coller dans Excel. C'est exactement pour combler ce manque qu'a été développée l'automatisation robotisée des processus, ou RPA en abrégé : Power Automate apprend à un collaborateur numérique à utiliser la souris et le clavier comme le ferait un humain, et automatise ainsi même les logiciels totalement dépourvus d'API. À jour en juillet 2026.

Dans ce guide, nous vous montrons comment Power Automate distingue l'automatisation basée sur des API de la RPA basée sur l'interface utilisateur, comment les flux de bureau reconnaissent même des applications Windows très anciennes sans interface moderne, et à quoi ressemble un cas typique en PME où un ERP historique est connecté à des déclencheurs modernes comme l'e-mail ou Excel. À la fin, vous saurez quel mode d'exécution convient à votre système et où se situent les limites de la RPA.

Pourquoi tant de PME utilisent-elles encore des logiciels sans API ?

Les éditeurs de logiciels ne développent généralement une interface que lorsque suffisamment de clients la demandent, et pour un système de gestion commerciale en place depuis des années, cela ne vaut souvent plus la peine pour l'éditeur. La documentation Microsoft résume ainsi la situation de départ : que faites-vous lorsqu'une application existe pour laquelle il n'existe ni connecteur tout fait, ni API permettant d'en construire un vous-même ? C'est exactement là qu'intervient la RPA, car elle vous permet d'automatiser aussi les systèmes plus anciens dépourvus d'API en apprenant à Power Automate à imiter les mouvements de souris et les frappes clavier d'un humain, comme si un robot utilisait l'ordinateur (Microsoft Learn : types d'automatisation des processus). Pour vous, cela signifie que vous n'avez pas besoin d'attendre une mise à jour de l'ERP ou une nouvelle interface pour automatiser la saisie des données.

Quelle est la différence entre l'automatisation basée sur des API et la RPA ?

Power Automate propose deux voies d'automatisation fondamentales. L'automatisation numérique des processus, ou DPA en abrégé, passe par des flux cloud et plus de 380 connecteurs prêts à l'emploi basés sur des API, qui permettent par exemple de connecter SharePoint, Outlook ou Dynamics 365, sans écrire de code. L'automatisation robotisée des processus, ou RPA en abrégé, passe quant à elle par des flux de bureau et utilise les applications comme vous le feriez vous-même à l'écran. Ces deux voies se complètent au lieu de se remplacer :

• Flux cloud (DPA) : utilise une API, reste stable face aux changements visuels de l'application et s'exécute entièrement dans le cloud.
• Flux de bureau (RPA) : ne nécessite aucune API, mais est sensible aux changements de mise en page à l'écran, de noms de champs ou de structure des fenêtres de l'application cible.

C'est précisément cette combinaison qui rend Power Automate intéressant pour les PME : vous connectez les systèmes modernes via des API et vous comblez le manque au niveau de votre ERP historique via la RPA (Microsoft Learn : types d'automatisation des processus).

Comment Power Automate reconnaît-il un ERP historique sans interface moderne ?

Pour qu'un flux de bureau sache quel bouton cliquer ou quel champ remplir, Power Automate capture ce que l'on appelle des éléments d'interface via trois types de sélecteurs possibles. UI Automation, ou UIA en abrégé, est le framework d'accessibilité moderne de Microsoft et fonctionne de manière fiable avec les applications construites en WPF, WinForms ou UWP. Mais de nombreux clients ERP historiques datent d'une époque antérieure à ces frameworks et ont été développés en VB6 ou en Win32 classique ; ils ne fournissent donc aucune information UIA. C'est exactement pour ce cas de figure qu'existe Microsoft Active Accessibility, ou MSAA en abrégé : une technologie d'accessibilité plus ancienne, qui fournit moins de détails qu'UIA, mais qui est souvent le seul moyen d'accéder aux boutons, champs de texte et tableaux dans les applications historiques. Si même MSAA ne suffit pas, Power Automate propose en plus UIA3 Raw, qui expose la structure complète et non filtrée des éléments d'une application, utile pour les interfaces au rendu particulièrement singulier (Microsoft Learn : automatiser à l'aide d'éléments d'interface utilisateur). Lors de l'enregistrement d'un flux de bureau, vous pouvez changer directement de mode de capture, afin de basculer volontairement en mode MSAA pour un ERP historique plutôt que de vous fier au réglage UIA par défaut.

À quoi ressemble le cas de l'ERP historique en pratique

Le cas classique en PME se déroule en deux couches. Un flux cloud prend en charge le déclencheur : il détecte un e-mail de commande entrant, une nouvelle ligne dans un tableau Excel ou un formulaire sur votre site web. Le flux cloud appelle ensuite un flux de bureau enregistré, qui prend en charge le travail proprement dit dans l'ERP historique, ouvre l'écran correspondant, saisit le numéro client, l'article et la quantité via des sélecteurs MSAA, puis valide l'opération, exactement comme le ferait sinon une collaboratrice à la main. La documentation Microsoft cite elle-même comme exemple typique la saisie de données dans un système ERP par les collaborateurs d'une grande entreprise, ainsi que l'automatisation d'émulateurs de terminal pour des systèmes plus anciens (Microsoft Learn : introduction aux flux de bureau). Concrètement, cela signifie que vous ne modifiez rien à l'ERP historique lui-même ; le collaborateur numérique se contente d'utiliser l'interface existante, telle qu'elle est en service depuis des années.

Assisté ou non assisté : quel mode convient à votre ERP historique ?

Deux modes sont disponibles pour l'exécution d'un flux de bureau, et le choix dépend fortement de la façon dont vous utilisez votre ERP historique. En mode assisté, l'automatisation s'exécute sur l'ordinateur d'une collaboratrice pendant qu'elle est connectée ; elle peut observer le déroulement et intervenir en cas de question. En mode non assisté, Power Automate se connecte de façon autonome sur une machine enregistrée, exécute le flux de bureau sans spectateur, puis se déconnecte à nouveau, idéal pour un traitement groupé nocturne sur votre ERP historique. Sur le plan des licences, ce n'est pas un détail : la licence Power Automate Premium inclut un bot assisté pour le mode assisté, tandis que les exécutions non assistées nécessitent une licence Process avec son propre bot non assisté, et si vous souhaitez automatiser sans machine dédiée, vous vous tournez vers la licence Hosted Process pour un bot hébergé dans Azure (Microsoft Learn : types de licences Power Automate). Avec un collaborateur numérique qui utilise votre ERP historique en mode assisté, vous automatisez les clics tout en gardant le contrôle sur chaque validation et chaque exception.

Quelles sont les limites de la RPA sur un ERP historique ?

La RPA ne remplace pas une véritable interface, elle constitue un pont tant qu'aucune n'existe. Contrairement à une API, que les éditeurs de logiciels maintiennent volontairement stable, un flux de bureau est sensible au moindre changement visuel : un champ déplacé, un bouton renommé ou une nouvelle fenêtre pop-up peuvent faire échouer un sélecteur. Vous devez donc, lors de la configuration, définir précisément ce que le collaborateur numérique doit faire, par exemple s'il doit toujours sélectionner la cellule B3 ou la première cellule vide d'une colonne, car la RPA ne fait que ce que vous lui avez réellement appris, pas ce que vous vouliez réellement dire (Microsoft Learn : types d'automatisation des processus). Si vous ne voulez pas assumer seul cet effort, notre conseil Power Automate vous aide à construire des sélecteurs MSAA robustes et à sécuriser proprement les exécutions assistées et non assistées contre les cas exceptionnels.

Questions fréquentes

La RPA remplace-t-elle une véritable interface vers l'ERP historique ?

Non. Un flux de bureau utilise l'interface existante de votre ERP historique, mais ne crée pas d'API lui-même. Si le système finit par disposer d'une interface structurée, il vaut généralement la peine de passer à un flux cloud avec le connecteur correspondant, car celui-ci fonctionne nettement plus stable et demande moins de maintenance qu'une automatisation d'interface utilisateur.

Comment Power Automate reconnaît-il les éléments d'un ancien écran ERP sans prise en charge UIA ?

Via Microsoft Active Accessibility, ou MSAA en abrégé. Cette technologie d'accessibilité plus ancienne fournit certes moins de détails que le framework UIA moderne, mais elle rend visibles les boutons, champs de texte et listes dans les applications construites avec des technologies plus anciennes comme VB6 ou Win32 classique. Vous sélectionnez le mode MSAA directement dans le sélecteur d'éléments d'interface ou lors de l'enregistrement du flux de bureau.

Assisté ou non assisté : lequel convient le mieux pour automatiser un ERP historique ?

Pour les tâches impliquant des questions aux collaborateurs, ou des processus destinés à s'exécuter en parallèle du travail normal, le mode assisté convient mieux. Pour les traitements groupés planifiables en dehors des heures de bureau, comme l'import nocturne de toutes les commandes du jour, le mode non assisté est le choix le plus adapté, car personne n'a besoin d'être connecté.

De quelle licence avez-vous besoin pour la RPA non assistée sur un ERP historique ?

La licence Power Automate Premium seule ne suffit pas pour une exécution non assistée. Vous avez besoin en plus d'une licence Process, qui inclut un bot non assisté et est attribuée à une machine, ou bien d'une licence Hosted Process si le flux de bureau doit s'exécuter sur une machine hébergée par Microsoft dans Azure plutôt que sur votre propre matériel.