Hermes Agent : quand rester en local et quand passer par un provider externe

À ce stade de la série, tu as un setup Hermes Agent qui tient debout. L’installation est propre, un modèle local tourne via llama.cpp, ta config est lisible, tes tools sont cadrés, MCP n’est plus un mystère, tu as une première skill utile, une routine de travail au quotidien, tu sais débugger une session qui déraille, et tu gardes l’ensemble léger. Tu as un agent qui marche.

Et c’est précisément maintenant qu’une question finit toujours par arriver : est-ce que tu dois vraiment tout faire en local, ou est-ce qu’il y a des moments où il est plus intelligent de passer par un provider externe ?

Ce tuto règle exactement ça. Ce n’est ni un plaidoyer pour le local, ni une pub déguisée pour le cloud. C’est un article d’arbitrage. L’idée est simple : le bon choix dépend de la tâche, pas d’une posture.

Ce que tu auras à la fin
Une vision claire de ce que le local apporte vraiment, de ce qu’un provider externe apporte vraiment, des critères concrets pour choisir tâche par tâche, et l’idée qu’un setup Hermes peut être hybride sans être incohérent.

Pour qui est ce tuto
Tu as suivi les tutos précédents. Ton setup local fonctionne. Tu commences à te demander si tu dois t’y tenir à tout prix, ou s’il y a des situations où ce n’est tout simplement pas la bonne réponse.

Pourquoi la question finit toujours par arriver

Quand on démarre avec Hermes Agent, on a envie que tout tourne chez soi. C’est sain. Le local force à comprendre son setup, à assumer ses contraintes, à ne pas dépendre d’un service qui peut changer ses prix ou ses conditions du jour au lendemain. La plupart des tutos de cette série partent de là pour de bonnes raisons.

Mais à l’usage, tu finis toujours par tomber sur des tâches qui passent moins bien. Pas parce que ton setup est mauvais, mais parce qu’une machine, même bien dimensionnée, a des limites. Un contexte trop long, une tâche qui demande un modèle plus gros que ce que ta VRAM tolère, un pic ponctuel où tu aurais besoin de plus de capacité pendant une heure, un besoin de qualité que ton modèle local ne tient pas proprement sur ce cas précis.

À l’inverse, certains réflexes “cloud par défaut” deviennent absurdes quand on y regarde de près : envoyer dehors des données qu’on n’a aucune raison de sortir de sa machine, payer à la requête pour un besoin récurrent qu’un modèle local couvre déjà très bien, transformer une tâche banale en dépendance externe permanente.

La question n’est donc pas idéologique. Elle est pratique. Et elle revient inévitablement dès que ton usage d’Hermes dépasse le simple test.

Ce que le local apporte vraiment

Le local, ce n’est pas qu’un argument moral. C’est une série d’avantages concrets qu’il faut savoir nommer pour comprendre quand ils comptent vraiment.

Le premier, c’est le contrôle. Tu sais ce que tu fais tourner, tu sais quel modèle tu utilises, tu sais quand il change, et il ne change que quand tu le décides. Aucun provider externe ne peut te retirer ton modèle du jour au lendemain ou modifier silencieusement son comportement.

Le deuxième, c’est la confidentialité. Ce qui reste sur ta machine reste sur ta machine. Pour certaines tâches, c’est accessoire. Pour d’autres, c’est non négociable. Des notes personnelles, des brouillons, des documents internes, des éléments sensibles par nature : il n’y a aucune raison que ça sorte de chez toi, et le local règle le problème sans avoir à faire confiance à un intermédiaire.

Le troisième, c’est l’autonomie. Pas d’abonnement qui expire, pas de quota mensuel, pas de dépendance à une connexion stable. Une fois ton setup en place, il tourne. Ça change la façon dont tu l’utilises : tu n’as plus cette petite friction mentale du “est-ce que ça vaut le coup de lancer une requête pour ça”.

Le quatrième, souvent sous-estimé, c’est la cohérence de l’environnement. Ton modèle local, ta config, tes tools, tes skills, tout vit dans le même espace. Quand tu débugges, tu as tout sous la main. Quand tu ajustes, tu ajustes une seule stack.

Et le dernier, plus diffus mais bien réel, c’est le confort mental du “ça tourne chez moi”. Ce n’est pas rien. Un setup local bien posé te rend plus libre dans tes expérimentations parce que tu n’as plus à calculer chaque appel.

Ce qu’un provider externe apporte vraiment

L’inverse est tout aussi vrai, et il faut le dire honnêtement, sinon l’arbitrage devient bancal.

Un provider externe, c’est d’abord de la puissance que tu n’as pas chez toi. Des modèles plus gros, des contextes plus larges, des capacités que ton hardware ne tiendra jamais, quelle que soit ta VRAM. Si ton besoin ponctuel dépasse ce que ta machine peut honnêtement gérer, le provider externe te donne accès à cette capacité sans que tu aies à surdimensionner toute ta stack pour un cas rare.

C’est ensuite moins de friction matérielle. Pas de refroidissement à surveiller, pas de modèle à recharger, pas de VRAM saturée, pas de pilote à remettre en ordre. Pour certains usages très ponctuels, la friction du local dépasse clairement le bénéfice qu’il apporte.

C’est aussi, parfois, une meilleure qualité brute sur une tâche précise. Il faut avoir l’honnêteté de le reconnaître : sur certains exercices, un gros modèle hébergé donne un résultat plus propre que ce que tient un modèle local raisonnable, et aucun discours sur le local ne change ça. L’inverse est aussi vrai selon les tâches, mais le réflexe “le local c’est forcément aussi bien” est tout aussi faux que son contraire.

Enfin, un provider externe apporte du confort immédiat dans certains cas. Quand tu n’as pas envie de monter une stack, quand tu fais une tâche une fois dans l’année, quand tu veux juste un résultat vite sans réveiller toute ta machine, le provider externe est simplement l’outil adapté.

Rien de tout ça n’annule les avantages du local. Mais rien de tout ça ne mérite d’être méprisé non plus.

Quand rester en local est le bon choix

Le local devient clairement le bon réflexe dans plusieurs cas, et ces cas sont plus fréquents qu’on ne le pense.

Dès que les données sont sensibles, la question ne se pose même pas. Tout ce qui touche à des informations personnelles, à des documents internes, à des notes que tu ne confierais pas à un tiers, reste en local. Ce n’est pas une question de paranoïa, c’est une question de principe : tu ne sors pas de chez toi ce qui n’a aucune raison d’en sortir.

Le local est aussi le bon choix dès qu’une tâche devient fréquente et répétée. Si tu fais la même chose trente fois par semaine, ce besoin récurrent s’accommode très mal d’un provider externe. Pas seulement pour le coût, mais pour la fluidité. Un truc que tu fais souvent doit tenir sur un outil disponible, prêt, sans la moindre friction d’usage.

Troisième cas : quand ton environnement est déjà prêt. Si ton modèle local tient la tâche honnêtement, si tes tools et tes skills sont déjà branchés dessus, sortir du local n’est plus un gain de confort, c’est souvent une régression. Tu quittes un environnement maîtrisé pour un environnement plus flou, juste pour un gain marginal.

Enfin, le local est aussi le bon choix quand tu veux un comportement stable dans le temps. Un modèle que tu fais tourner chez toi ne changera pas tout seul. C’est exactement ce que tu veux pour des usages que tu as calibrés avec soin.

Quand passer par un provider externe devient plus pertinent

À l’inverse, il y a des situations où s’entêter à rester en local devient une posture, pas une décision.

C’est le cas quand une tâche dépasse honnêtement les capacités de ton setup. Un contexte énorme, un besoin de qualité que ton modèle local ne tient pas sur cet exercice précis, une demande ponctuelle qui voudrait un modèle bien plus gros que ce que ta VRAM autorise. À ce moment-là, insister sur le local n’est plus de l’autonomie. C’est du sabotage.

C’est aussi le cas pour les besoins ponctuels de puissance. Si une fois tous les deux mois tu as une tâche qui demande beaucoup plus que ton quotidien, ce n’est pas une raison pour refaire toute ta stack autour de ce cas exceptionnel. Un provider externe est exactement fait pour ça : absorber les pics sans que tu surdimensionnes ton matériel en permanence.

Quand tu es sous contrainte de temps, aussi. Il y a des moments où tu n’as pas trente minutes à passer à relancer un modèle local, ajuster ta config, vérifier que tout se comporte bien. Si le résultat est attendu vite et que la tâche ne contient rien de sensible, le provider externe est simplement l’outil rationnel.

Enfin, il y a les cas où la tâche est tellement rare que tout investissement matériel dédié serait absurde. Si tu as besoin d’un truc une fois dans l’année, tu n’optimises pas ta machine pour ce cas-là : tu sors juste, cette fois-là, et tu reviens en local le reste du temps.

Pourquoi le meilleur choix est souvent hybride

L’erreur la plus fréquente, quand on se pose cette question, c’est d’imaginer qu’il faut trancher une bonne fois pour toutes. Tout en local, ou tout en externe. Choisir un camp. Dans la pratique, ce n’est presque jamais la bonne réponse.

Un setup Hermes intelligent est souvent hybride, et assumé comme tel. Le quotidien reste en local parce que c’est là qu’il est le plus fluide, le plus privé et le plus autonome. Les cas rares, lourds ou exceptionnels passent par un provider externe quand ils le justifient. Les deux cohabitent sans se marcher dessus.

Ce qui compte, ce n’est pas la pureté du setup, c’est sa lisibilité. Tu dois pouvoir dire, en une phrase, ce qui est traité en local et ce qui sort. Si tu ne peux pas, ce n’est pas un setup hybride : c’est un setup confus qui se cache derrière le mot.

L’hybride propre, c’est un choix conscient, tâche par tâche. Pas un choix par humeur du jour.

Les vrais critères pour arbitrer

Plutôt qu’une règle absolue, voici les critères sur lesquels tu t’appuies, tâche par tâche. Aucun n’est décisif tout seul, mais pris ensemble ils suffisent à cadrer la décision.

Sensibilité des données. Si elles ne doivent pas sortir, elles ne sortent pas. C’est le critère qui, quand il s’applique, écrase les autres.
Fréquence du besoin. Plus c’est récurrent, plus le local devient rationnel. Plus c’est exceptionnel, plus le provider externe se défend.
Puissance réellement nécessaire. Pas la puissance fantasmée “au cas où”, la puissance que la tâche demande vraiment. C’est souvent bien moins que ce qu’on imagine.
Confort d’usage. Une tâche qui doit être fluide ne supporte pas la friction. Choisis l’outil qui rend cette tâche naturelle, pas celui qui te donne bonne conscience.
Latence perçue. Ce n’est pas la latence mesurée au millième, c’est celle que tu ressens en usage réel. Les deux ne sont pas toujours corrélées.
Coût global. Pas uniquement le coût d’appel d’un provider, mais aussi le coût matériel et le coût de temps d’un setup local mal dimensionné pour la tâche.
Stabilité attendue. Si tu veux un comportement figé dans le temps, le local gagne. Si tu veux profiter d’améliorations continues, l’externe a un argument.
Lisibilité du setup. Si ajouter une option rend ton setup flou, elle coûte plus qu’elle ne rapporte, même si elle semblait gratuite.

Ces critères ne donnent pas une réponse automatique. Ils te donnent une grille pour trancher honnêtement au lieu de trancher par réflexe.

Les erreurs les plus fréquentes

Quelques pièges reviennent souvent chez les gens qui ont un bon setup Hermes et qui se posent cette question.

Le premier, c’est de vouloir tout faire en local par principe. L’ambition est respectable, le résultat l’est souvent moins. Tu finis par faire tenir à ta machine des tâches pour lesquelles elle n’est pas taillée, à dégrader la qualité de tes résultats, ou à passer plus de temps à contourner les limites du setup qu’à l’utiliser.

Le deuxième, symétrique, c’est de sortir du local au moindre inconfort. Tu rencontres une petite friction, tu bascules sur un provider externe, et très vite tu as transformé un setup autonome en dépendance permanente à un service que tu n’as pas vraiment choisi consciemment.

Le troisième, c’est de confondre puissance brute et confort réel. Un modèle plus gros n’est pas automatiquement un meilleur outil pour ton besoin. Parfois, un modèle plus modeste, bien branché, bien configuré, donne un résultat plus utile qu’un modèle énorme mal intégré à ton workflow.

Le quatrième, c’est de sous-estimer le coût mental d’un setup mal dimensionné. Un setup trop ambitieux pour tes vrais besoins te pèse, même s’il ne te coûte rien en argent. Tu passes du temps à le maintenir au lieu de l’utiliser.

Le cinquième, c’est de croire qu’un provider externe résout tous les problèmes. Il en résout certains, il en crée d’autres : dépendance, coût récurrent, boîte noire, données qui sortent de chez toi, comportement qui peut changer sans prévenir.

Et le dernier, c’est de croire qu’un setup hybride est incohérent par nature. Un setup hybride assumé, documenté, clair sur ses règles, est souvent plus propre qu’un setup dogmatique qui force la réalité à rentrer dans une case.

Ce que tu ne dois pas faire

Quelques lignes à ne pas franchir, pour garder un arbitrage sain.

Ne transforme pas cette question en débat de camp. Il n’y a pas de “vrais” users du local contre des “faux” users du cloud. Il y a des gens qui essaient d’obtenir un résultat de façon propre, et c’est tout.

Ne choisis pas par ego de setup. Si ta seule raison de rester en local est de pouvoir dire que tu es en local, ce n’est plus une décision technique.

Ne dimensionne pas toute ta stack autour d’un besoin exceptionnel. Si tu investis dans du matériel taillé pour un cas que tu rencontres deux fois par an, tu paies en permanence un confort dont tu ne profites presque jamais.

N’envoie pas dehors ce qui devrait rester chez toi. C’est la seule règle non négociable. Tout le reste est une question d’équilibre.

Ne force pas le local sur des tâches qu’il ne tient pas proprement. Un résultat médiocre rendu en local n’est pas une victoire.

Et ne perds jamais de vue l’objectif réel : obtenir un bon résultat, de manière saine, avec l’outil qui rend cette tâche la plus naturelle possible.

La suite logique

Tu as maintenant une grille d’arbitrage claire entre le local et l’externe. C’est exactement ce qu’il fallait pour que la suite de la série ait du sens : à partir du moment où tu sais quoi faire tourner où, les tutos suivants peuvent se concentrer sur les cas d’usage concrets sans avoir à justifier à chaque fois pourquoi on reste en local ou pourquoi on sort.

Le prochain tuto prendra le relais sur ce terrain : des cas d’usage concrets autour d’Hermes Agent, traités avec cette même logique d’arbitrage pratique plutôt que d’idéologie d’outil. Un bon arbitrage local / externe rend tout ce qui vient après beaucoup plus crédible, parce que le lecteur sait enfin pourquoi telle tâche est traitée d’une façon et telle autre d’une autre.

C’est exactement comme ça qu’un setup Hermes mûrit : il ne devient pas “plus local” ou “plus externe”, il devient plus juste.