Une première architecture hybride, pas encore la bonne

TL;DR

Après le hardening du VPS, l'assemblage Docker/Ollama/Hermes, le benchmark CPU et les leçons du mode background, une répartition se dessine entre ce qui reste local et ce qui part au cloud. Je la présente ici parce qu'elle est assez solide pour être écrite noir sur blanc, pas parce qu'elle est terminée : plusieurs questions restent ouvertes, en particulier sur ce que l'agent local peut réellement exécuter sans supervision.

Sommaire

Ce que les articles précédents ont établi
La répartition qui en ressort
Ce que cette architecture ne prouve pas encore
Un point de départ, pas un aboutissement

Ce que les articles précédents ont établi

Sans reprendre les chiffres en détail (ils sont dans les articles concernés), ces six articles ne sont pas six sujets indépendants : chacun découle du précédent, et c'est cet enchaînement qui produit la répartition de cette page.

Le VPS durci (accès uniquement par clé et par Tailscale, filet de sécurité vérifié) a rendu possible d'y installer sans crainte des agents capables d'exécuter des commandes. Docker, Ollama et Hermes assemblés sur ce VPS ont d'abord révélé qu'un modèle « compatible Ollama » n'est pas automatiquement exploitable par un orchestrateur, une leçon de configuration avant d'être une leçon de performance. Le benchmark CPU qui a suivi a donné le vrai verdict : le local est trop lent pour la plupart des usages interactifs, ce qui a forcé la question suivante, pas l'inverse, à savoir que faire de cette lenteur plutôt que de l'ignorer. Le mode background d'Hermes a répondu en partie : c'est un usage réel pour la veille et le batch, mais il a aussi exposé deux limites distinctes, un résultat qui peut varier d'une exécution à l'autre sans qu'on sache toujours pourquoi, et un agent qui peut ne plus savoir s'arrêter tout seul. Ce sont ces limites, plus que la seule lenteur, qui ont motivé la recherche d'un chemin cloud fiable pour tout ce qui reste interactif, et c'est ce chemin (ChatGPT/Codex) que l'article précédent a établi comme le plus simple à brancher sans coût additionnel.

La répartition qui en ressort

                  Hermes
                    |
          +---------+---------+
          |                   |
      Ollama local          Cloud
          |                   |
     tâches simples       tâches complexes
     batch                interactif
     transformations      architecture
     génération répétée   recherche
     faible coût          validation

Côté local : DTO, boilerplate, tests simples, SQL, YAML, CI/CD, transformations, batch. Rien qui exige une réponse rapide, tout ce qui peut attendre le temps que le CPU fasse son travail.

Côté cloud : architecture, analyse complexe, gros refactoring, recherche, validation, debugging difficile, tout ce qui est agentique et complexe. Rien de tout ça n'est spécifique à un fournisseur précis, seulement au constat que ce sont des tâches où attendre plusieurs minutes n'est pas acceptable.

Cette répartition n'a rien d'original en soi : c'est peu ou prou ce qu'on ferait par bon sens sans avoir mesuré quoi que ce soit. Ce qui a de la valeur, ce n'est pas la répartition elle-même, c'est d'avoir des chiffres concrets derrière chaque case plutôt qu'une intuition.

Ce que cette architecture ne prouve pas encore

Cette répartition dit où envoyer une tâche selon sa nature. Elle ne dit rien sur une question plus difficile : une fois qu'une tâche est envoyée au local, est-ce que l'agent peut réellement l'exécuter sans supervision, modifier les bons fichiers, utiliser ses outils correctement, et s'arrêter au bon moment ? Le mode background a déjà montré des signes que la réponse n'est pas automatiquement oui, et je n'ai pas encore fait tourner d'agent local sur une vraie tâche de développement multi-fichiers, avec un vrai projet, un vrai environnement, et un vrai résultat vérifiable sur le disque.

Les premiers essais dans Hermes, tel qu'assemblé jusqu'ici, n'ont d'ailleurs rien prouvé dans un sens ou dans l'autre : le projet n'était même pas monté dans le conteneur.

Un point de départ, pas un aboutissement

Ce que je changerais si cette répartition se révélait fausse, ce n'est probablement pas la case « local » ou « cloud » d'une tâche donnée : c'est la confiance implicite que j'accorde à ce qui se passe une fois qu'une tâche part en local, sans supervision directe. Si les articles qui suivent montrent que cette confiance n'est pas justifiée, ce schéma ne change pas de forme : c'est ce qu'il faut vérifier avant de l'appliquer qui change.