Brancher un modèle sur un progiciel sans API

Une part importante du travail administratif se déroule dans des applications qui n'exposent aucune interface programmable, et c'est là que se trouvent les données utiles. C'est le premier obstacle rencontré dès qu'on quitte la démonstration.

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.

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.

Presque tous les progiciels savent produire un export, même anciens, et c'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.

Faire manipuler l'interface par un système fonctionne et constitue le pont le plus fragile, à réserver aux cas où les deux autres 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.

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 : 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.

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.

Si le temps réel est nécessaire en lecture et le volume élevé, la lecture en base s'impose, sur une réplique.

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 ? ».

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.