Automatisation de navigateur indépendante du modèle : ne reconstruis plus jamais parce qu'un fournisseur a changé
Pourquoi le modèle devrait être un simple paramètre, comment garder un workflow portable entre cloud et local, et ce que coûte la dépendance à un fournisseur.
L'automatisation de navigateur indépendante du modèle garde le workflow, les outils, le contexte et les validations séparés du modèle qui raisonne dessus. Le modèle devient un paramètre par tâche plutôt que l'architecture elle-même, si bien qu'un changement de prix, une limite de débit ou une API dépréciée ne peuvent pas forcer une reconstruction. Melaya prend en charge les fournisseurs cloud connectés, les modèles locaux Ollama et LM Studio, et les abonnements CLI comme Claude Code et Codex.
Ce que coûte la dépendance à un fournisseur en pratique
Un agent de navigateur lié à un seul modèle hérite du tarif, des limites de débit, de la disponibilité régionale, de la politique de contenu et de la feuille de route de ce fournisseur. Rien de tout cela n'est sous ton contrôle, et tout cela change. Le workflow est l'actif. Le modèle est un composant qui devrait être remplaçable.
Le coût, ce n'est rarement la licence. C'est la reconstruction : quand les conditions changent, l'intégration, les prompts, le câblage des outils et les validations doivent tous être refaits contre une surface différente.
- Les hausses de prix s'appliquent au travail que tu as déjà construit
- Les limites de débit arrêtent un workflow qui tournait bien avant
- Une version de modèle dépréciée change un comportement que tu avais réglé
- Des restrictions régionales ou de politique peuvent supprimer l'accès entièrement
Séparer le workflow du modèle
Garde quatre choses indépendantes du modèle : les outils qu'un agent peut appeler, le contexte avec lequel il travaille, les points de validation et le registre de ce qui s'est passé. Si tout cela vit dans le runtime plutôt que dans le produit d'un fournisseur, changer de modèle devient un menu déroulant, pas un projet.
Melaya est construit ainsi. La même tâche de navigateur tourne sur un fournisseur cloud connecté, sur un modèle local via le Melaya Runner, ou via une route Claude Code ou Codex, avec les mêmes connecteurs, le même contexte permanent, la même portée d'onglet et les mêmes validations autour.
Quand les modèles locaux rendent un workflow gratuit à la marge
Un modèle local sur ta propre machine n'a pas de compteur hébergé au message. Pour un travail de navigateur récurrent, cela change l'économie du calcul : le coût marginal d'une exécution, c'est ton électricité, pas une facture au jeton. L'inférence locale reste limitée par ton matériel, la fenêtre de contexte du modèle, sa vitesse et les droits de ton plan Melaya, donc ce n'est pas littéralement illimité.
Le schéma pratique est mixte : un modèle hébergé rapide pour l'extraction de routine, un modèle hébergé plus puissant pour une page difficile, et un modèle local pour la tâche répétitive qui tourne chaque jour.
Questions fréquentes
Puis-je faire tourner l'automatisation de navigateur avec un modèle local gratuit ?
Oui. Connecte le Melaya Runner et choisis un modèle servi par Ollama ou LM Studio. Il n'y a pas de compteur hébergé au message, même si les exécutions restent limitées par ton matériel, le contexte du modèle et ton plan.
Puis-je changer de modèle sans reconstruire la tâche ?
Oui. Les outils, les connecteurs, le contexte permanent et les validations vivent dans le runtime, le modèle est donc un choix par tâche.
Le choix du modèle change-t-il ce que l'agent peut faire dans le navigateur ?
Les actions de navigateur disponibles sont les mêmes. Un modèle plus puissant gère plus fiablement les pages ambiguës et les tâches longues à plusieurs étapes.
