Brancher un modèle sur un progiciel sans API

Un progiciel sans API est une application métier qui n’expose aucune interface programmable, et c’est souvent là que se trouvent les données utiles à un assistant d’IA. Une part importante du travail administratif se déroule dans ces applications, et c’est le premier obstacle rencontré dès qu’on quitte la démonstration.

Une API, ou interface de programmation, permet à un autre logiciel de lire ou d’écrire des données de façon contrôlée et documentée. Sans elle, le modèle n’a aucun accès prévu à l’application : il faut construire un pont.

Le schéma est stable d’une organisation à l’autre. Le projet vise un assistant qui répond sur l’état des dossiers. Les dossiers sont dans un progiciel installé il y a douze ans, dont l’éditeur facture cher toute évolution et dont la documentation d’intégration n’existe pas.

Un protocole de branchement comme MCP ne change pas ce constat : il standardise la façon dont un modèle appelle un outil, mais il faut toujours qu’un outil existe de l’autre côté. Trois ponts sont possibles. Ils n’ont ni le même coût, ni la même fragilité, ni le même risque, et le choix se fait sur trois critères simples.

Les trois ponts vers un progiciel sans API sont l’export de fichiers, la lecture directe en base de données et le pilotage de l’écran, du plus robuste au plus fragile. Le tableau suivant les compare sur les critères qui décident en pratique.

Le pont le plus visible en démonstration, le pilotage d’écran, est presque toujours celui qu’il faudrait choisir en dernier.

Presque tous les progiciels savent produire un export, même anciens, et l’export de fichiers est le pont le plus robuste des trois. Il est aussi le plus souvent écarté à tort, parce qu’il paraît rustique.

Le principe est simple : le progiciel produit un fichier chaque nuit, le système l’indexe, l’assistant répond sur cette base. La donnée a jusqu’à vingt-quatre heures de retard.

Ce retard est le seul vrai défaut, et il est acceptable dans la majorité des cas. Une question sur l’historique d’un dossier, sur une procédure, sur une référence produit ne demande pas la donnée de la minute.

Les avantages sont considérables. Aucune dépendance à l’interface, aucun risque pour le progiciel, aucune charge sur sa base, et une reprise triviale en cas d’incident. Je recommande de commencer par là systématiquement, quitte à ajouter un autre pont pour les rares cas qui exigent le temps réel.

La qualité de ce pont dépend du fichier lui-même : colonnes stables, identifiants présents, date d’extraction inscrite. Ce travail sur la matière première décide du reste, comme le rappelle le corpus est le projet.

La lecture directe en base se justifie quand l’assistant a besoin d’une donnée fraîche sur un volume élevé, à condition de rester en lecture seule et de ne jamais toucher la base de production. C’est un pont plus rapide que l’export, mais plus exposé aux changements du progiciel.

Les tables d’un progiciel ne sont pas conçues pour être lues de l’extérieur : noms abrégés, codes internes, règles métier enfouies dans l’application plutôt que dans les données. Une montée de version peut les modifier sans préavis. Quatre conditions encadrent ce pont.

Faire manipuler l’interface par un système fonctionne et constitue le pont le plus fragile, à réserver aux cas où l’export et la lecture en base sont impossibles. Sa fragilité tient à ce qu’il dépend de la disposition visuelle.

Un bouton déplacé lors d’une mise à jour, un message inhabituel, une fenêtre de session expirée : chacun casse le traitement, et souvent sans erreur explicite. Le système croit avoir agi.

Quand ce pont est le seul disponible, il faut l’encadrer strictement : un compte technique aux droits minimaux, un enregistrement de la session, une validation humaine sur tout ce qui est irréversible, et une limite de durée. Le cadre complet figure dans piloter un écran ne vaut pas droit de tout cliquer, et la logique de classement des actions rejoint celle du périmètre d’un agent.

Une précaution supplémentaire s’impose : ce pont doit être réservé à la lecture ou à la recopie d’une donnée dont l’original fait foi ailleurs. Lui confier une écriture qui engage l’organisation revient à parier sur l’interprétation d’une interface graphique.

Trois questions suffisent pour choisir le pont vers un progiciel sans API : quelle fraîcheur est réellement nécessaire, quel volume, et l’action est-elle réversible. Elles donnent le pont dans la quasi-totalité des cas.

1. Si une fraîcheur à vingt-quatre heures convient, l’export de fichiers l’emporte, sans discussion. C’est le cas le plus fréquent, et il est presque toujours sous-estimé parce que les utilisateurs demandent spontanément le temps réel sans en avoir l’usage. C’est le même biais que celui décrit dans combien de cas d’usage faut-il abandonner : la demande exprimée dépasse systématiquement le besoin réel.
2. Si le temps réel est nécessaire en lecture et le volume élevé, la lecture en base s’impose, sur une réplique.
3. Si le progiciel doit être modifié et qu’aucun autre pont n’existe, le pilotage d’écran devient inévitable, avec l’encadrement décrit plus haut.

La question de la fraîcheur mérite d’être posée avec insistance. « Vous en avez besoin à quelle heure ? » donne souvent une réponse très différente de « vous en avez besoin en temps réel ? ».

Un exemple générique illustre la démarche : un service client veut savoir où en est la commande d’un appelant. La commande change d’état quelques fois par jour ; un export toutes les quelques heures couvre l’essentiel, et seuls les cas urgents justifieraient un pont plus coûteux. À l’inverse, un service qui doit saisir des corrections dans le progiciel n’a pas d’autre choix que l’écran, et doit alors l’encadrer.

Quel que soit le pont retenu, il faut une trace de ce qui a été lu et quand, faute de quoi aucune réponse fausse n’est diagnosticable. C’est le point commun aux trois.

La trace minimale comporte trois éléments : la source consultée, l’horodatage de la donnée, et l’identifiant de l’enregistrement. Ils permettent de répondre à la seule question qui compte après un incident : le système a-t-il lu une donnée périmée, ou a-t-il mal interprété une donnée correcte ?

Sans cette distinction, chaque incident produit une enquête sans conclusion, et la confiance dans le système s’érode plus vite que les erreurs ne se corrigent.

Afficher l’horodatage de la donnée dans la réponse elle-même est le geste le plus rentable : l’utilisateur voit immédiatement qu’il consulte l’état d’hier soir, et il ajuste. C’est une application directe du principe développé dans l’observabilité des systèmes IA.

Les erreurs les plus coûteuses en connectant une IA à un progiciel sans API consistent à choisir le pont qui se démontre le mieux plutôt que celui qui tient le plus longtemps. D’autres reviennent régulièrement.

• Réutiliser le compte d’un utilisateur. Le pont hérite alors de tous ses droits, et aucune trace ne distingue l’action humaine de l’action du système.
• Lire la base de production. Une requête mal écrite ralentit l’application pour tous ses utilisateurs.
• Oublier la montée de version. Un export dont une colonne change de nom, ou une table renommée, casse le pont sans prévenir. Un test de contrôle après chaque mise à jour de l’éditeur évite des semaines de réponses fausses.
• Négliger le contrat. Un accès techniquement possible peut être contractuellement interdit, et la question se pose avant la construction.
• Confier une écriture à l’écran sans validation. Une action engageante fondée sur la lecture d’une interface ne doit jamais partir sans contrôle humain.

Ces arbitrages, pont par pont et application par application, font partie de ce qu’examine un audit IA avant tout développement.