TL;DR. Personne n'a gagné la course à l'agent IA personnel. Les cinq produits les plus regardés échouent chacun sur quelque chose de différent. La raison plus profonde est que presque tout le monde résout le mauvais problème. Le goulot d'étranglement n'est pas le modèle, et n'est pas le matériel. C'est de savoir si l'agent est câblé dans votre flux de travail avec accès à vos vraies données. C'est le problème sur lequel Ostler est construit.

Personne n'a encore gagné

La newsletter Creator Economy de Peter Yang a récemment testé cinq des agents IA personnels les plus regardés par rapport à dix capacités dont a besoin un véritable agent personnel : gérer les e-mails, le calendrier et les documents ; exécuter des tâches récurrentes ; se souvenir de vous ; travailler sur le web et le mobile ; la voix ; la personnalité ; le contrôle informatique ; la fiabilité ; la sécurité (source).

La conclusion est brutale. Aucun ne coche toutes les cases.

  • OpenClaw est le plus flexible et le plus puissant, avec de solides fonctions de messagerie et de voix. Le coût est la fiabilité. Environ un dixième du temps de l'auteur passé avec lui est consacré à le maintenir en état de marche.
  • Hermes échange la flexibilité contre la stabilité. Il est plus fiable, communique les tâches plus clairement et exécute les flux de travail par lui-même. Il semble moins vivant que ses rivaux, mais il reste opérationnel.
  • Claude Code a la meilleure personnalité et le raisonnement le plus fort, et c'est un plaisir de travailler avec lui. Il a aussi des limites de débit et des problèmes de disponibilité qui empêchent de compter sur lui.
  • Codex livre une belle application de bureau, une utilisation généreuse et le meilleur contrôle du navigateur et de l'ordinateur des cinq. Il n'a pas d'application mobile, ce qui, selon l'auteur, supprime environ quatre-vingts pour cent de la façon dont il voudrait réellement utiliser un agent.
  • Gemini est le mieux positionné pour le grand public parce qu'il vit déjà à l'intérieur de Google Workspace et gère bien la voix et la vidéo. Le trou est qu'il ne peut pas éditer Google Docs, Sheets ou Slides, les produits mêmes à côté desquels il se trouve.

Chacun échoue sur quelque chose de différent. Le cadre utilisé par l'article n'est pas cloud contre local. C'est la fiabilité contre la flexibilité contre l'interface contre la disponibilité contre l'exhaustivité des fonctionnalités.

La ligne qui frappe le plus dans l'article est la norme que l'auteur a fixée : « Une fois que vous avez un agent disponible 24/7 et qui peut réellement faire le travail pour vous, vous ne reviendrez jamais à une interface de chat IA classique. »

C'est la barre. Aucun des cinq ne la franchit.

Un échec de forme différente, même cause racine

Un article sur XDA de la même semaine examine la question de l'autre côté, du développeur qui construit une pile locale. Son argument est simple et très utile (source).

Le goulot d'étranglement n'est pas le GPU.

Le goulot d'étranglement n'est pas du tout la vitesse brute. C'est le système autour du modèle. L'article nomme trois véritables goulots d'étranglement, et aucun n'est matériel : la façon dont le flux de travail est conçu, le fait que le modèle ait ou non accès à vos vraies données, et la façon dont l'opérateur structure et utilise le système. Un modèle sans connexion à votre vie est, selon les mots de l'article, « le véritable goulot d'étranglement n'est pas la vitesse à laquelle l'IA pense ; c'est ce qu'elle sait de votre monde spécifique. »

Mettez les deux articles côte à côte et vous obtenez un diagnostic clair. Les cinq agents les plus regardés manquent chacun de quelque chose de différent en surface, mais la pièce manquante en dessous est la même : un agent qui vit véritablement dans la journée de l'opérateur, avec ses données, ses outils et ses habitudes, disponible tout le temps.

Construisez quelque chose qui pense vite mais qui vit dans un onglet de chat et vous avez, selon l'image de l'auteur de XDA, un moteur qui tourne au ralenti.

Ce qu'Ostler fait à ce sujet

Ostler est construit sur la réponse vers laquelle les deux articles gravitent. Un agent local qui vit sur le Mac du client, ingère ses vraies données et s'intègre à ses vrais flux de travail.

Une courte liste de ce que cela signifie en pratique.

  • Le Hub fonctionne sur un Mac que le client possède déjà, Apple Silicon M1 ou plus récent. Aucune flotte à gérer, aucune deuxième machine. La mémoire unifiée d'Apple Silicon est véritablement utile ici pour l'inférence locale, mais c'est du soutien, pas la vedette.
  • Ingestion profonde des données qui comptent réellement pour la journée d'une personne. iMessage, WhatsApp, e-mail, Photos, Calendrier, historique de navigation Safari, notes vocales. L'agent n'est pas invité à agir sur une vie qu'il ne peut pas voir.
  • Une pile locale ajustée à ce travail. Mon propre Hub, après des mois d'utilisation, contient environ 148 000 embeddings de ma vie dans Qdrant et environ deux millions de triples RDF dans Oxigraph ; une nouvelle installation client commence vide et grandit à partir des données propres de chaque client. Redis fait tourner le cache et le bus de messages. Ollama fait tourner le modèle de raisonnement local Qwen3 9B (environ 6,6 Go sur disque) et nomic-embed-text pour les embeddings. Whisper gère la parole en texte. SQLCipher garde la base de données chiffrée au repos. Un runtime d'agent Rust pilote le tout. Un compilateur MkDocs transforme le graphe en un wiki privé.
  • Architecture mono-machine opinionnée. Un Mac, une installation, un seul endroit où vivent les données. La complexité est dans le pipeline, pas dans le déploiement.
  • Chemins réseau désactivés par défaut. Tout ce qui quitte la machine est opt-in et commutable. La position par défaut est que vos données ne quittent pas.
  • Une app iOS pour quand vous n'êtes pas à votre bureau. Le Hub fait le gros du travail. Le téléphone est la télécommande.

Deux brevets provisoires ont été déposés sur le pipeline.

Il y a aussi un argument d'architecture de financement caché ici. Un produit qui fonctionne entièrement sur la propre machine du client est délicat à construire si votre table de capitalisation a besoin que vous facturiez au jeton. Un produit qui a besoin d'ingérer la vie entière d'une personne est délicat à construire si vous lui demandez aussi de la téléverser sur vos serveurs. Ostler est façonné comme il l'est en partie parce qu'il est financé comme il l'est.

La barre à franchir

La barre que Yang fixe est la bonne : un agent qui est disponible tout le temps et qui fait réellement le travail pour vous. Les deux articles sont honnêtes sur la distance qui sépare la cuvée actuelle de cette barre. L'article de Yang parce qu'aucun des cinq acteurs nommés n'obtient les dix cases. L'article de XDA parce que le modèle brut et le silicium brut n'ont jamais été le problème au départ.

Nous pensons que la manière d'y arriver est la démodée. Mettez l'agent sur une machine que l'opérateur possède déjà. Donnez-lui accès aux données qui décrivent réellement sa vie. Câblez-le dans les outils qu'il utilise déjà. Gardez les paramètres par défaut privés. Faites du pipeline le produit.

L'installeur Hub est signé, notarisé, agrafé et prêt. L'app iOS est livrée via l'App Store. L'architecture ci-dessus est ce que vous obtenez quand vous l'achetez.

Le monde tourne BEL ET BIEN autour de toi.™

Sources citées : Peter Yang, « The race to build a personal AI agent » (Creator Economy, mai 2026) ; XDA Developers, « The real bottleneck of a self-hosted LLM stack is not the GPU » (mai 2026).