Faire cohabiter ses automatisations avec un logiciel métier ancien

Il y a un moment précis où un projet d'automatisation s'arrête net : celui où il faut intégrer un logiciel legacy. Le progiciel de gestion installé il y a douze ans, celui qui fait tourner la production et la facturation, n'expose aucune interface de programmation. Votre outil d'orchestration sait parler à quarante services en ligne, mais pas à celui-là.

Ce cas de figure est la norme, pas l'exception. Dans une PME industrielle ou une entreprise de services établie, le cœur du système d'information a rarement moins de dix ans. Il fonctionne, il est amorti, personne n'a envie d'y toucher. Pourtant, la moitié des automatisations réellement utiles ont besoin d'y lire ou d'y écrire quelque chose.

Il existe quatre familles de solutions pour connecter un vieux logiciel, et elles ne se valent pas du tout en termes de robustesse. Cet article les décrit, les classe par fragilité, et détaille les précautions à prendre, en particulier vis-à-vis du support de l'éditeur, qui peut se retourner contre vous plus vite que prévu.

Pourquoi un logiciel métier sans API bloque autant de projets

Un logiciel conçu avant la généralisation des interfaces web part d'un postulat simple : l'utilisateur est humain, il est assis devant l'écran, et il saisit. La donnée existe, elle est propre, souvent bien structurée, mais elle n'est accessible que par l'écran ou par un module d'édition d'états. Trois conséquences pratiques, que l'on retrouve à peu près partout :

• Pas de point d'entrée documenté. Aucune adresse à appeler, aucun jeton d'authentification, aucune documentation technique publique. Quand une interface existe, elle est parfois réservée à une édition « entreprise » facturée plusieurs milliers d'euros par an.
• Pas de notion d'événement. Le logiciel ne prévient personne quand une commande est validée. Il faut aller regarder, à intervalle régulier, si quelque chose a changé.
• Un modèle de données non contractuel. Les tables, les colonnes et les codes internes peuvent changer à la prochaine montée de version, sans préavis, parce que l'éditeur ne s'est jamais engagé sur leur stabilité.

Ce dernier point est le plus important. Toute la différence entre une intégration qui tient trois ans et une qui casse au premier correctif tient à une question : sur quoi l'éditeur s'est-il engagé par écrit ?

Quatre stratégies pour connecter un vieux logiciel, classées par fragilité

Voici les quatre approches que l'on rencontre sur le terrain, de la plus solide à la plus risquée. La colonne « fragilité » est une note assumée, fondée sur ce qui casse lors des montées de version.

Notez que l'effort initial et la fragilité ne vont pas dans le même sens : l'automatisation d'interface est la moins chère à mettre en place et la plus coûteuse à maintenir. C'est le piège des projets pressés.

1. L'export automatique de données : la voie la plus sûre

Presque tous les logiciels de gestion savent produire un état, un fichier plat ou un tableur, à la demande ou sur planification. C'est la fonction la plus stable qui existe : elle est utilisée quotidiennement par les comptables, et l'éditeur ne peut pas se permettre de la casser. Le schéma est simple : le logiciel dépose chaque nuit un fichier dans un répertoire partagé, votre orchestrateur le lit, le compare à l'état précédent et en déduit les lignes à traiter.

Trois précautions rendent cet export automatique de données fiable :

1. Un fichier témoin. Le traitement ne démarre que si un second fichier, écrit après le premier, est présent. Sans cela, vous lirez un jour un export à moitié écrit.
2. Un horodatage dans le nom. On garde les trente derniers exports : quand une anomalie remonte trois semaines plus tard, vous rejouez la journée concernée.
3. Une alerte sur l'absence de fichier. L'erreur la plus fréquente n'est pas un mauvais fichier, c'est un fichier qui n'arrive pas et que personne ne remarque pendant six jours.

Limite assumée : c'est de la lecture seule, à la fraîcheur du dernier export. Pour un rapport ou une alerte de stock, c'est largement suffisant.

2. La lecture directe de la base de données

Si le logiciel s'appuie sur une base relationnelle standard, vous pouvez l'interroger directement, en lecture, via un pilote générique du type ODBC. La donnée est fraîche, complète, et vous n'attendez rien de l'éditeur.

Trois règles non négociables :

• Un compte en lecture seule, jamais le compte applicatif. On crée un utilisateur dédié, avec les droits strictement limités aux tables nécessaires. Aucune écriture, jamais : les contrôles d'intégrité du logiciel vivent dans son code, pas dans la base, et une écriture directe produit des données incohérentes que personne ne saura rattraper.
• Une réplique, si possible. Interroger la base de production aux heures ouvrées peut dégrader les temps de réponse pour les utilisateurs. Une copie rafraîchie toutes les heures suffit dans la plupart des cas.
• Une couche de vues. On ne requête pas les tables depuis les automatisations : on définit des vues nommées métier, et les automatisations lisent les vues. Quand l'éditeur renomme une colonne, vous corrigez la vue, pas quinze scénarios.

C'est aussi le moment de vérifier ce que vous avez le droit de faire : certains contrats interdisent l'accès direct au schéma, et l'usage de données personnelles depuis un nouvel outil doit figurer à votre registre de traitements.

3. La passerelle applicative dédiée

La passerelle est un petit service que vous écrivez et que vous hébergez. Il parle au vieux logiciel avec les moyens disponibles (base, fichiers, parfois un module d'échange ancien), et expose vers l'extérieur une interface propre et stable, avec un vocabulaire métier : clients, commandes, articles.

C'est l'option la plus coûteuse au départ et la plus rentable dès qu'il y a plus de deux ou trois automatisations en jeu. Toute la connaissance sale (les codes internes, les tables mal nommées, les conventions bizarres) est concentrée dans un seul composant, testé et versionné. Les automatisations, elles, restent lisibles. C'est la même logique que celle décrite dans notre article sur la façon de connecter son CRM aux autres outils : on centralise la complexité au lieu de la répandre.

4. L'automatisation d'interface, en dernier recours

Quand rien d'autre n'est possible, il reste à piloter le logiciel comme le ferait un opérateur : ouvrir la fenêtre, cliquer, saisir, valider. C'est le domaine des outils d'automatisation robotisée de processus, dont la documentation de Power Automate décrit bien le principe, jusqu'aux émulateurs de terminal.

Cette approche fonctionne, et elle est parfois la seule qui permette d'écrire dans le logiciel sans corrompre ses données, puisqu'elle passe par les mêmes contrôles que la saisie humaine. Mais elle est fragile par nature :

• Une fenêtre déplacée, un champ renommé, un message de mise à jour qui s'affiche, et le scénario échoue.
• Le robot occupe une session : il faut une machine dédiée, allumée, avec un compte utilisateur nominatif et une politique de mot de passe compatible.
• Le débit est faible : quelques dizaines d'opérations par heure, pas des milliers.

Si vous prenez cette voie, ancrez les repères sur des identifiants d'éléments plutôt que sur des coordonnées d'écran, prévoyez une capture d'écran à chaque échec, et traitez la reprise sur erreur comme un sujet à part entière. Notre article sur la façon de gérer les erreurs dans les workflows automatisés s'applique ici avec une acuité particulière.

Ce qu'il faut vérifier côté éditeur avant de brancher quoi que ce soit

Le risque principal n'est pas technique, il est contractuel. Un éditeur qui découvre un accès direct à sa base peut refuser d'intervenir sur un incident, au motif que l'installation a été modifiée. Quatre questions à poser par écrit, et à faire répondre par écrit :

1. L'accès en lecture à la base est-il autorisé, et sous quelles conditions ? Beaucoup d'éditeurs l'acceptent volontiers si vous vous engagez à ne rien écrire.
2. Le schéma de données est-il documenté et stable entre versions mineures ? Une réponse négative ne disqualifie pas l'approche, mais impose de tester chaque montée de version sur un environnement de recette.
3. Existe-t-il un module d'échange, même ancien et payant ? Un import et export au format plat, un connecteur comptable, un service d'échange de fichiers : c'est souvent moins cher que trois semaines de développement de contournement.
4. Quel est le calendrier des mises à jour ? Vous voulez savoir à l'avance quand vos intégrations vont devoir être retestées.

Gardez ces réponses avec votre documentation technique. C'est exactement le type d'information qui disparaît avec le départ de la personne qui avait posé la question, comme nous l'évoquions à propos de la nécessité de documenter ses automatisations.

Les précautions qui font tenir une intégration dans la durée

Quelle que soit la stratégie retenue, cinq réflexes changent la vie de l'équipe qui reprendra le sujet dans deux ans :

• Une seule direction d'écriture. Décidez qui est la source de vérité pour chaque donnée. Une synchronisation bidirectionnelle sur un logiciel sans horodatage fiable finit toujours par un conflit que personne ne sait arbitrer.
• Un environnement de test, même bricolé. Une copie de la base restaurée sur une machine séparée coûte une journée et évite d'apprendre en production que la colonne a changé de type.
• Une surveillance de fraîcheur. Une alerte quand la dernière donnée reçue date de plus de N heures : c'est le seul contrôle qui détecte les pannes silencieuses.
• Un périmètre volontairement étroit au départ. Un seul flux, une seule direction, un seul objet métier. Comme pour tout premier chantier, mieux vaut suivre la logique décrite dans notre guide sur les processus à automatiser en premier.

Intégrer un logiciel legacy : par où commencer concrètement

Reprenez votre besoin et posez-le en une phrase : quelle donnée, dans quel sens, à quelle fraîcheur. Puis descendez la liste dans l'ordre. Un export planifié suffit-il ? Si oui, arrêtez-vous là, c'est la solution la plus stable et la moins chère. Sinon, la lecture de base est-elle contractuellement possible ? Si oui, faites-la, avec un compte en lecture seule et des vues. Si vous avez besoin d'écrire, chiffrez une passerelle avant d'envisager l'automatisation d'interface, qui reste un choix par défaut, pas une cible.

Intégrer un logiciel legacy n'est donc pas une question d'outillage mais de discipline : accepter la fraîcheur la plus basse qui rende le service, écrire ce qui a été autorisé par l'éditeur, et concentrer la complexité en un seul endroit. Une intégration ennuyeuse qui tourne depuis trois ans vaut mieux que la plus élégante des synchronisations temps réel qui casse à chaque correctif.