Comment je décide ce qui tourne sur ma machine et ce qui part dans le cloud, ce que ça coûte réellement, et les quatre choses que ça m'a apprises.
Brahim Bousnguar · septembre 2026
Un Mac mini posé sur une étagère. Un fil Telegram sur mon téléphone. Entre les deux, dix-sept agents qui font chacun une chose.
Chaque agent a un rôle, une mémoire, des outils et un fil de discussion à lui. On ne « change pas de prompt » : on change d'interlocuteur.
La passerelle, les agents, la mémoire et les outils tournent chez moi. Seule l'inférence part — parfois.
4 448 tours d'agent depuis mai 2026. Ça tourne, ça tombe en panne, ça se répare un dimanche soir.
Cette présentation porte sur la seule décision qui structure tout le reste : qu'est-ce qui a le droit de quitter la maison.
Une passerelle, des canaux, des agents, des outils. Rien d'exotique — et c'est ce qui le rend copiable.
OpenClaw fait tenir ensemble trois choses qui, sans lui, seraient trois projets distincts :
Telegram, Signal. Un compte par agent, donc un fil de discussion par agent. C'est l'interface : je n'ouvre pas de terminal pour parler à un agent.
16 comptes Telegram
Un dossier, une identité, une mémoire, un modèle, une politique d'outils. Ajouter un agent, c'est ajouter un dossier — pas déployer un service.
17 agents actifs
Des serveurs MCP maison qui exposent mes propres applications, plus les outils intégrés : shell, fichiers, navigateur, tâches planifiées.
4 serveurs MCP
La bonne façon d'y penser : ce n'est pas « une IA ». C'est un standard téléphonique qui met en relation un canal, un agent, un modèle et des outils.
Environ 273 Go/s de bande passante mémoire. C'est cette bande passante, pas le nombre de cœurs, qui décide de la vitesse d'un modèle local.
Il tient un modèle de 21 Go en mémoire et continue de faire tourner des conteneurs, une base, des webapps.
Un modèle de 35 milliards de paramètres tourne confortablement. Le plafond, c'est le débit : un seul agent local à la fois travaille correctement.
D'où la conséquence directe : le local est une ressource rare, à réserver à ce qui la justifie.
C'est le point que je n'avais pas compris au début. Je croyais choisir entre « gratuit » et « payant ». Je choisissais en fait entre deux ressources rares différentes : ma machine, ou mon budget.
Pour chaque agent, une seule question : est-ce que cette conversation a le droit de quitter la maison ?
Tout tourne chez moi — la passerelle, les agents, la mémoire, les outils. La seule chose qui part, quand elle part, c'est le contenu de la conversation envoyé au modèle. Toute la décision est là.
Notes personnelles et suivis du quotidien : tout ce qui touche à ma vie privée plutôt qu'à mon travail ou à mon code.
ollama/qwen3.6:35b-mlx21 Go en mémoire
Ces données ne doivent pas quitter la maison. Pas parce qu'un fournisseur serait malveillant — parce que la question ne devrait pas avoir à se poser.
Le coût nul et la latence stable sont des bonus. Ils n'auraient pas suffi à justifier le choix.
Cet agent est moins bon que les agents cloud. Il suit moins bien les instructions longues, il se perd plus vite dans un enchaînement d'outils, et il occupe 21 Go de mémoire en permanence. J'ai accepté ces trois choses en échange d'une seule : le texte reste ici.
Les questions ouvertes, la recherche, la rédaction, l'administration de la flotte elle-même. C'est l'agent à qui je parle quand je ne sais pas encore à qui parler.
anthropic/claude-sonnet-5
Un généraliste passe son temps sur des tâches ouvertes, longues, avec beaucoup d'outils. C'est exactement là qu'un modèle local décroche.
Et le contenu — de la doc, du code public, des questions générales — n'a aucune raison de rester à la maison.
Le test que j'applique : « si ce message fuitait demain, est-ce que ça me poserait un problème ? » Si la réponse est non, la question du local ne se pose pas — on prend le meilleur modèle.
Prototypes, corrections dans mes dépôts, explorations techniques. Il travaille dans un worktree git dédié et son livrable est toujours la même chose : une pull request.
Le code est l'usage le plus exigeant qui soit : contexte long, outils enchaînés, zéro tolérance à l'approximation. Un modèle local y échoue de façon coûteuse — il produit du code plausible et faux.
Ce sont mes dépôts perso, publics ou destinés à l'être. Aucun code client ne passe par là — c'est une règle, pas une intention.
Tant que Spark « corrigeait des choses », je ne pouvais pas lui faire confiance. Depuis qu'il doit produire une branche, un worktree, une PR — quelque chose que je relis avant de fusionner — je peux le laisser travailler sans surveiller. La contrainte n'est pas dans le modèle, elle est dans le processus.
| 🏠 Local | ☁ Cloud | |
|---|---|---|
| Le critère | Le contenu ne doit pas sortir | Le contenu peut sortir, la tâche est exigeante |
| Qualité du modèle | Correcte sur du dialogue, fragile sur les enchaînements d'outils | La meilleure disponible |
| Coût marginal | Zéro euro | Facturé — ou inclus dans un abonnement |
| Coût réel | 21 Go de mémoire immobilisés, un seul agent à la fois | Une dépendance réseau et un fournisseur |
| Latence | Stable, prévisible | Variable, dépend d'un tiers |
| Quand ça tombe | Ça tombe avec la machine | Ça tombe avec le fournisseur |
Sur 17 agents, 4 tournent en local et le reste en cloud. La proportion n'est pas un objectif : c'est simplement le nombre d'agents qui touchent à des données privées.
Les chiffres réels, y compris celui que je ne peux plus mesurer.
Depuis que la flotte est passée sur un abonnement, mon tableau de bord de dépense est aveugle : l'abonnement ne remonte pas de coût par jeton. Je peux vous dire ce que j'ai payé avant, et ce que je paie maintenant. Je ne peux pas vous dire ce que la même activité coûterait aujourd'hui à l'usage — ce serait une extrapolation, pas une mesure.
75 € sur cinq mois, c'est peu. Ce n'est pas le coût qui m'a fait bouger vers l'abonnement : c'est de ne plus avoir à y penser à chaque expérimentation.
Le local ne coûte pas d'euros. Il coûte trois autres choses, et il faut les avoir en tête avant de choisir.
21 Go immobilisés tant que le modèle est chargé. Sur une machine qui fait aussi tourner des conteneurs et des bases, ce n'est pas neutre.
Un agent local à la fois travaille correctement. Deux conversations locales simultanées, et les deux ralentissent. Le cloud, lui, est parallèle par nature.
C'est le coût le plus élevé et le moins visible. Un modèle local se trompe différemment : il reste plausible plus longtemps.
J'ai voulu passer un agent local sur un modèle plus gros, en pensant « plus de paramètres, meilleur agent ». C'était un modèle dense : il activait tous ses paramètres à chaque jeton. Les tours sont passés à une vingtaine de minutes et les ventilateurs ne s'arrêtaient plus. Le modèle que j'utilise aujourd'hui est plus petit en apparence mais à activation partielle : il n'active qu'une fraction de ses paramètres, et il est plusieurs fois plus rapide.
La leçon générale : pour un agent local, la question n'est pas « combien de paramètres », c'est combien de paramètres actifs par jeton.
Quatre leçons payées en pannes réelles, un dimanche soir, avec les agents en rade.
Un agent local devait créer une note. L'outil a réussi — vingt fois. Le modèle n'a pas su lire ses propres résultats d'outil : il relançait l'appel, obtenait un succès, ne le reconnaissait pas, et recommençait. J'ai retrouvé vingt notes identiques.
Pas le modèle seul : le modèle sans repli. Cet agent n'avait aucun modèle de secours. Quand le local décroche, il décroche jusqu'au bout.
C'est la même leçon que pour les serveurs d'outils : un succès qui ne change rien est pire qu'une erreur. En local, sans filet, ça se paie vingt fois.
Un an d'incidents. Voici ce qui tombait réellement :
| Le symptôme | La cause réelle |
|---|---|
| « L'agent ne répond plus » | Un processus de passerelle bloqué. À tuer, pas à redémarrer en entier. |
« L'outil renvoie fetch failed » | Le service n'écoutait que sur une interface, l'URL pointait sur une autre. |
| « Tout est cassé depuis la mise à jour » | Application de bureau et passerelle sur deux versions incompatibles. |
| « La tâche planifiée ne part plus » | Un identifiant d'agent renommé, et trois fichiers de configuration restés sur l'ancien nom. |
| « L'agent sort en erreur immédiatement » | Node en dessous de la version minimale exigée. Rien à voir avec l'IA. |
Autrement dit : c'est de l'exploitation. Réseau, versions, processus, nommage. Les compétences qui servent ici sont celles qu'on a déjà — pas des compétences « IA ».
Un agent « intelligent » à qui je demandais de consulter mes données. Il proposait des commandes, je les copiais, je lui recollais la sortie. J'étais devenu son terminal.
Quatre serveurs MCP maison qui exposent mes propres applications. L'agent appelle un outil typé, reçoit un résultat calculé, et agit. Je ne suis plus dans la boucle.
4 serveurs MCPapplications maison
Le saut de qualité n'est jamais venu d'un meilleur modèle. Il est venu, à chaque fois, d'un meilleur outil : un outil qui répond à une intention métier au lieu d'exposer une table, et qui refuse une entrée invalide au lieu de l'ignorer.
Dix-sept fils de discussion, c'est dix-sept endroits où quelque chose peut attendre une réponse. J'en ai supprimé plusieurs qui ne servaient plus — et c'est la meilleure décision de maintenance que j'aie prise.
Chaque agent a des consignes, une mémoire, des compétences. Elles vieillissent. Un agent qu'on ne relit jamais finit par appliquer des règles qui ne sont plus vraies.
Renommer un agent touche sa configuration, ses tâches planifiées, ses sessions et tout script qui code son identifiant en dur. Ça m'a coûté une soirée entière, une fois.
Le bon réflexe : avant d'ajouter un agent, se demander si un agent existant ne devrait pas simplement recevoir un outil de plus. La réponse est oui plus souvent qu'on ne le croit.
J'ai créé des agents en espérant que la spécialisation suffirait. Ce qui manquait, c'étaient des outils — pas des personnalités.
« Plus gros » m'a coûté des tours de vingt minutes. La bonne question était l'activation par jeton, pas le nombre de paramètres.
Plusieurs tâches planifiées produisaient du bruit que je ne lisais plus. Je les ai supprimées. Une automatisation qu'on ignore est une dette, pas un gain.
C'est un choix de confidentialité. Présenté comme une économie, il déçoit — parce qu'on paie en qualité ce qu'on économise en euros.
Un labo personnel n'est pas une architecture d'entreprise. Trois choses se transposent quand même.
La première question n'est pas « quel modèle », c'est « qu'est-ce qui a le droit de sortir ». Une fois cette frontière tracée, le choix du modèle devient une conséquence, pas un débat.
Un agent devient acceptable quand sa sortie entre dans un processus de revue qui existe déjà. Une PR se relit. Un « c'est fait » ne se relit pas.
Le budget d'un projet d'agents part dans l'exposition propre des systèmes existants, pas dans le choix du modèle. C'est du travail d'API, et il se capitalise.
Chez moi, quand ça casse, ça ne casse que pour moi. Une flotte d'agents en entreprise a besoin de supervision, d'astreinte, de traçabilité et d'une gestion des identités — c'est-à-dire de tout ce que je me suis autorisé à ne pas faire.
Pas un choix économique. On paie en qualité, en mémoire et en débit ce qu'on gagne à ne pas transporter le texte.
Pour tout ce dont la fuite ne poserait pas de problème, prendre le meilleur modèle est la décision évidente.
Aucun saut de qualité n'est venu d'un modèle. Tous sont venus d'un meilleur outil, mieux typé, plus proche de l'intention.
Réseau, versions, processus, nommage. Les compétences nécessaires sont celles qu'on a déjà — pas des compétences « IA ».
Les slides et les notes du présentateur sont en ligne.
heybrahim.com/talks/openclawLa passerelle qui fait tenir tout ça ensemble.
heybrahim.com/talks/mcp — pourquoi MCP change la donne.
Brahim Bousnguar