Comment connecter un agent IA à un logiciel ancien qui n'a pas d'API ?

Six voies, à tester dans cet ordre : l'API non documentée que le logiciel utilise déjà en interne, la lecture directe en base de données, l'import-export de fichiers structurés, le connecteur payant de l'éditeur, la capture d'impression, et en dernier recours l'automatisation d'interface. Les cinq premières sont plus rapides à mettre en œuvre et beaucoup plus stables dans le temps.

Le RPA est-il une bonne solution pour intégrer l'IA à un logiciel métier ?

C'est la solution qui fonctionne toujours et celle qui casse le plus souvent. Elle dépend de l'apparence de l'interface : une mise à jour qui déplace un bouton suffit à l'arrêter. Elle se justifie quand aucune autre voie n'existe, à condition de budgéter un à deux jours de maintenance par an et par automatisation et d'ajouter un contrôle de cohérence sur ce que le robot a saisi.

Peut-on lire directement la base de données d'un logiciel métier ?

Techniquement oui dans la plupart des cas, via ODBC ou une connexion native selon le moteur (SQL Server, PostgreSQL, Firebird, HFSQL). Trois précautions : rester en lecture seule, utiliser un compte dédié aux droits limités, et vérifier que votre contrat de licence l'autorise. L'écriture directe en base court-circuite les règles de gestion du logiciel et produit des incohérences difficiles à détecter.

Combien de temps pour connecter un agent IA à un ERP sans API ?

De 1 à 3 jours par la lecture en base, 3 à 8 jours par l'import-export de fichiers, 5 à 15 jours par l'automatisation d'interface. À quoi s'ajoute, dans ce dernier cas seulement, une charge de maintenance récurrente qu'il faut inscrire au budget dès la première année.

Qu'est-ce qu'un serveur MCP et à quoi ça sert dans une entreprise ?

Le protocole MCP permet d'exposer à un modèle un jeu d'actions nommées, avec leurs paramètres et leurs règles, plutôt que de le laisser manipuler directement des tables ou des écrans. Concrètement, un serveur MCP sur mesure traduit votre logiciel métier en actions du type « consulter le stock », « créer une commande », « vérifier l'encours ». Si la voie d'accès technique change ensuite, seul ce serveur est à reprendre.

Faut-il prévenir l'éditeur du logiciel avant de le connecter ?

Oui, et par écrit. Beaucoup autorisent la lecture en base, certains la facturent, quelques-uns l'interdisent. Un éditeur prévenu peut aussi vous signaler une API existante ou un module d'interopérabilité que le commercial n'avait pas mentionné. Un montage réalisé contre les conditions du contrat vous prive du support au pire moment.

Comment savoir si un logiciel a une API non documentée ?

S'il a une interface web, ouvrez les outils de développement du navigateur, onglet réseau, et effectuez l'action manuellement. Les appels effectués apparaissent avec leurs adresses, leurs paramètres et leur format de réponse. Trente minutes suffisent généralement à savoir si cette voie est exploitable, avant de mobiliser un budget de développement.

Quel est le coût de maintenance d'une automatisation par RPA ?

Comptez un à deux jours d'intervention par an et par automatisation en régime normal, plus une reprise complète à chaque montée de version majeure du logiciel piloté. Sur trois ans, cette charge dépasse fréquemment le coût d'une licence de connecteur officiel, quand elle existe.

Connecter un agent IA à un logiciel métier qui n'a pas d'API

En résumé. Six voies existent pour faire parler un agent avec un logiciel qui n’expose pas d’API, et elles n’ont ni le même coût ni la même durée de vie. La lecture directe en base de données demande 1 à 3 jours et ne casse presque jamais. L’automatisation d’interface, le fameux RPA, demande 5 à 15 jours et casse à chaque changement d’écran, ce qui représente une charge récurrente à budgéter. Entre les deux : l’API non documentée, l’import-export de fichiers, la capture d’impression et le connecteur payant de l’éditeur. Testez les voies dans cet ordre, pas dans l’ordre inverse.

Les six voies, classées

Voie	Délai de mise en œuvre	Robustesse	Ce qui la casse
API non documentée	2 à 5 jours	bonne	une refonte majeure du logiciel
Lecture directe en base	1 à 3 jours	très bonne en lecture	un changement de schéma
Import / export de fichiers	3 à 8 jours	très bonne	rien, c’est le format le plus stable
Connecteur de l’éditeur	variable	bonne	la politique tarifaire de l’éditeur
Capture d’impression	3 à 6 jours	moyenne	une modification des états imprimés
Automatisation d’interface (RPA)	5 à 15 jours	faible	toute mise à jour de l’interface

L’ordre de ce tableau est aussi l’ordre dans lequel il faut chercher. La plupart des projets commencent par le bas, parce que le RPA se démontre bien en réunion, et découvrent le coût de maintenance six mois plus tard.

Voie 1 : l’API qui existe sans être documentée

Un logiciel avec une interface web moderne parle presque toujours à un serveur, et cette conversation est une API. Le fait qu’elle ne soit pas documentée ne la rend pas inaccessible : elle se lit dans les outils de développement du navigateur, onglet réseau, en effectuant l’action à la main.

Ce que vous y trouvez : les points d’entrée, le format des données, le mécanisme d’authentification. Souvent en trente minutes.

Les limites sont réelles. L’éditeur ne s’engage sur rien, il peut modifier ces points d’entrée sans préavis, et vos conditions contractuelles peuvent l’interdire. À vérifier avant, pas après.

Cette voie est excellente sur les logiciels métier en ligne dont l’éditeur vend une API payante et n’a aucune envie de vous la donner gratuitement, ce qui est fréquent.

Voie 2 : lire directement la base de données

C’est la voie la plus sous-utilisée et souvent la meilleure.

La plupart des logiciels installés sur un serveur local stockent leurs données dans une base accessible : SQL Server, PostgreSQL, MySQL, Firebird, HFSQL pour les applications Windev, ou un fichier propriétaire lisible via ODBC. Une connexion en lecture seule vous donne accès à tout, en temps réel, sans dépendre de l’interface.

Trois règles à ne pas transgresser.

Lecture seule, jamais écriture. Écrire directement en base court-circuite toutes les règles de gestion du logiciel, et vous découvrirez le problème sur des données incohérentes trois mois plus tard. Pour écrire, utilisez une autre voie.

Un compte dédié, avec les seuls droits nécessaires. Pas le compte administrateur du logiciel.

Prévenez l’éditeur. Beaucoup l’autorisent en lecture. Certains le facturent. Quelques-uns le refusent contractuellement.

Sur un ERP ancien de type AS/400 ou une application Windev de quinze ans, cette voie livre en deux jours ce que le RPA mettrait trois semaines à approcher.

Voie 3 : l’import-export de fichiers

Presque tous les logiciels métier savent exporter en CSV ou en XML et importer dans le même format. Ces fonctions ont été conçues pour les reprises de données et les échanges comptables, pas pour un flux quotidien, mais rien n’empêche de les utiliser ainsi.

Le montage classique : un export planifié la nuit vers un dossier partagé ou un SFTP, l’agent lit le fichier, produit un fichier d’import en retour, le logiciel l’ingère à heure fixe.

Le défaut est le décalage. Vous ne travaillez pas en temps réel mais par lots. Pour la plupart des automatisations de PME, ce décalage n’a aucune importance : une commande intégrée à minuit plutôt qu’à 17 h ne change rien à la livraison.

L’avantage compense largement : c’est la voie la plus stable qui existe. Un format d’import CSV ne change quasiment jamais, alors qu’une interface graphique change à chaque version.

Voie 4 : le connecteur de l’éditeur

Beaucoup d’éditeurs proposent un module d’interopérabilité en option payante. Chez les acteurs français de la gestion comme Sage, Cegid ou EBP, ces modules existent sous des noms variables.

Avant de développer quoi que ce soit, demandez trois choses à votre éditeur : le prix du module, la documentation technique, et un contact qui a déjà fait ce que vous voulez faire.

Une licence à 2 000 € par an peut sembler chère, jusqu’à ce que vous la compariez au coût de maintenance d’un montage RPA qui casse quatre fois par an. Le calcul penche souvent en faveur du module officiel, et il apporte un support en prime.

Voie 5 : la capture d’impression

Un logiciel qui ne sait rien exporter sait toujours imprimer. En installant une imprimante virtuelle qui produit un PDF au lieu de papier, chaque édition devient un fichier exploitable, que le modèle lit ensuite comme n’importe quel document.

C’est une solution de contournement, mais elle a un intérêt réel sur les états de synthèse, les listings et les journaux. Elle ne fonctionne qu’en lecture, et la mise en page de l’état imprimé devient une dépendance.

Voie 6 : l’automatisation d’interface, en dernier

Le RPA consiste à piloter le logiciel comme le ferait un humain : ouvrir la fenêtre, cliquer dans le champ, saisir, valider. Les outils sont matures, de UiPath à Power Automate Desktop, et Playwright fait le même travail sur les applications web.

Cette voie a un avantage décisif : elle fonctionne toujours. Si un humain peut le faire, le robot peut le faire.

Elle a un défaut décisif : elle dépend de l’apparence de l’interface. Une mise à jour qui déplace un bouton, une fenêtre de nouveauté qui s’affiche au démarrage, un écran plus lent que d’habitude, et le robot échoue. Parfois bruyamment, ce qui est le bon cas. Parfois silencieusement, en saisissant dans le mauvais champ, ce qui est nettement pire.

Si vous partez sur cette voie, budgétez la maintenance dès le départ. Comptez un à deux jours d’intervention par an et par automatisation, plus une reprise à chaque montée de version majeure du logiciel. Et prévoyez un contrôle de cohérence en sortie : le robot doit vérifier que ce qu’il a saisi correspond à ce qu’il voulait saisir.

Les quatre questions à poser avant de développer

Posez-les à l’éditeur, par écrit, avant d’engager un développement.

Existe-t-il une API, même payante, même partielle ? La réponse est plus souvent oui qu’on ne le croit.
La lecture directe en base est-elle autorisée par mon contrat ? Et si oui, existe-t-il une documentation du schéma ?
Quels formats d’import et d’export sont supportés, et sont-ils garantis entre versions ?
Quelle est la fréquence des mises à jour d’interface ? Cette réponse chiffre directement le coût de maintenance d’un montage RPA.

Un éditeur qui ne répond à aucune des quatre vous dit quelque chose sur ce que sera la vie du projet.

Une fois la voie choisie

L’accès brut ne suffit pas. Un agent a besoin d’une couche qui lui expose des actions compréhensibles plutôt que des tables ou des écrans : consulter le stock d’une référence, créer une commande, vérifier l’encours d’un client.

Cette couche s’écrit une fois, au-dessus de la voie d’accès retenue, et présente au modèle un jeu d’actions nommées avec leurs paramètres. Le protocole MCP sert exactement à ça et devient un standard de fait pour cet usage. L’intérêt pratique : si la voie d’accès change plus tard, seule cette couche est à reprendre, pas l’agent.

C’est une pièce que je développe et que j’ai déjà livrée, au même titre que le reste d’une mission d’automatisation. Elle n’est pas obligatoire : sur un besoin simple et figé, une intégration directe suffit et coûte moins cher. Le serveur MCP se justifie quand plusieurs agents doivent taper dans le même logiciel, ou quand vous prévoyez d’en ajouter d’autres ensuite.

Quand la réponse est de ne pas connecter

Trois situations où la meilleure décision est de laisser le logiciel tranquille.

Le logiciel doit être remplacé dans les dix-huit mois. Connectez-vous au futur, pas au passé.

Le volume ne le justifie pas. Créer trente commandes par mois à la main prend deux heures. Aucun montage ne se rembourse là-dessus.

L’action à automatiser est irréversible et le contrôle impossible. Un robot qui valide des paiements dans une interface sans possibilité de vérification derrière est un risque, pas un gain.

Les délais indiqués sont des ordres de grandeur pour un périmètre simple, hors règles métier complexes. Vérifiez toujours vos conditions de licence avant d’accéder à une base de données ou à une API non documentée.