Quand une application n’a pas d’API : faut-il confier son interface à un agent ?

Rétrospective · semaine du 28 septembre 2026

Votre équipe recopie chaque semaine des informations dans un logiciel ancien. Aucun connecteur évident ne permet de l'intégrer au reste des outils. La tentation est alors simple : demander à un agent de cliquer à la place d'une personne. Avant de choisir cette voie, il faut comprendre ce que le processus exige vraiment et comment vérifier son résultat.

Une possibilité supplémentaire, pas un raccourci universel

Le 29 septembre, OpenAI ajoute un navigateur hébergé à l'Agents API ; l'application gère les approbations d'accès. Source : journal officiel.

Cette évolution invite à réexaminer certains travaux d'interface, sans présumer de leur faisabilité dans votre logiciel. L'analyse qui suit est une méthode de cadrage : elle ne constitue ni une garantie de compatibilité ni une recommandation de contourner une restriction du fournisseur. Une interface accessible à un salarié n'autorise pas automatiquement tous les usages automatisés.

Examiner quatre voies, dans cet ordre

Première voie : vérifier l'existence d'une API documentée ou d'un connecteur officiel adapté à l'action précise. « Connecté » peut signifier lecture seule ; cela ne prouve pas qu'une modification est possible. Demandez quels champs et quelles opérations sont réellement couverts.

Deuxième voie : rechercher un export et un import structurés. Pour une mise à jour hebdomadaire, un fichier contrôlé peut être plus simple à superviser qu'une série de clics. Il faut néanmoins examiner les doublons, les erreurs de format et le compte rendu d'import.

Troisième voie : tester l'interface, uniquement dans le périmètre autorisé. Identifiez les écrans, les validations et la preuve attendue après chaque opération. Une fenêtre qui disparaît n'est pas, à elle seule, une preuve que l'enregistrement a réussi.

Quatrième voie : conserver une étape manuelle. Si le volume est faible ou si l'erreur a des conséquences importantes, préparer les données pour une personne peut être un meilleur premier projet que d'automatiser toute la séquence.

Exemple illustratif : mettre à jour une référence interne

Imaginons un outil fictif sans API adaptée. Le besoin consiste à reporter une référence de dossier dans une fiche déjà identifiée. Le test commence avec des données fictives, une seule fiche et une valeur facilement reconnaissable. Il vérifie l'identifiant avant la saisie, puis relit la fiche après l'enregistrement.

Le scénario doit aussi couvrir une fiche introuvable, deux résultats similaires et une session expirée. Dans ces cas, l'agent s'arrête et transmet le contexte utile. Il ne choisit pas au hasard et ne cherche pas à éviter une demande d'authentification. Cet exemple décrit un protocole de démonstration, pas une intégration déjà réalisée par SWM.

Écrire les conditions d'arrêt avant de démarrer

Listez les changements qui imposent une intervention : écran inattendu, permission supplémentaire, avertissement, identité de fiche incertaine ou absence de confirmation. Fixez également ce qui reste exclusivement humain, notamment les validations engageantes non autorisées.

Prévoyez une trace opérationnelle proportionnée, sans stocker inutilement les données affichées. Après une coupure, la reprise doit commencer par une vérification de l'état réel. Répéter une saisie parce que le système ne sait pas si elle a abouti transforme un incident technique en erreur métier.

Mesurer le travail évité et le travail déplacé

Évaluez le temps de supervision, les blocages et la facilité de correction, pas seulement les clics économisés. Désignez la personne chargée de revoir le test lorsque le logiciel change. Si personne ne peut maintenir le scénario, mieux vaut revoir son périmètre.

Un projet d'automatisation commence ainsi par le choix d'une méthode vérifiable. Le conseil IA aide à poser cette décision avant d'engager une intégration fragile.

Étudions les possibilités de votre logiciel métier avant de choisir une méthode d'automatisation.