TL;DR. Personne n'a gagné la course à l'agent d'IA personnelle. Les cinq produits les plus observés échouent chacun sur un point différent. La raison plus profonde, c'est que presque tout le monde résout le mauvais problème. Le goulet d'étranglement n'est pas le modèle, et ce n'est pas le matériel. C'est de savoir si l'agent est branché sur votre flux de travail, avec accès à vos données réelles. C'est le problème autour duquel Ostler est construit.
Personne n'a encore gagné
La newsletter Creator Economy de Peter Yang a récemment testé cinq des agents d'IA personnelle les plus observés au regard de dix capacités dont un véritable agent personnel a besoin : gérer l'e-mail, le calendrier et les documents ; exécuter des tâches récurrentes ; se souvenir de vous ; fonctionner sur le web et sur mobile ; la voix ; la personnalité ; le contrôle de l'ordinateur ; la fiabilité ; la sécurité (source).
La conclusion est brutale. Personne ne coche toutes les cases.
- OpenClaw est le plus souple et le plus puissant, avec une messagerie et une voix solides. Le prix à payer, c'est la fiabilité. Environ un dixième du temps que l'auteur passe avec lui sert à le maintenir en état de marche.
- Hermes troque la souplesse contre la stabilité. Il est plus fiable, communique les tâches plus clairement et exécute des flux de travail par lui-même. Il paraît moins vivant que ses rivaux, mais il tient debout.
- Claude Code a la meilleure personnalité et le raisonnement le plus solide, 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 superbe application de bureau, des quotas d'usage généreux et le meilleur contrôle du navigateur et de l'ordinateur des cinq. Il n'a pas d'application mobile, ce qui, selon l'estimation de l'auteur, retire environ quatre-vingts pour cent de la façon dont il voudrait réellement utiliser un agent.
- Gemini est le mieux placé 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, c'est qu'il ne peut pas modifier Google Docs, Sheets ou Slides, les produits mêmes à côté desquels il est installé.
Chacun échoue sur un point différent. Le cadre qu'emploie l'article n'est pas cloud contre local. C'est la fiabilité contre la souplesse contre l'interface contre la disponibilité contre l'exhaustivité fonctionnelle.
La phrase qui frappe le plus fort dans l'article est le critère que l'auteur s'est fixé : “Une fois que vous disposez d'un agent disponible 24 h/24 et 7 j/7 et capable d'abattre réellement du travail pour vous, vous ne reviendrez plus jamais à une interface de discussion IA ordinaire.”
C'est la barre. Aucun des cinq ne la franchit.
Un échec de forme différente, même cause profonde
Un article paru sur XDA la même semaine prend la question par l'autre bout, celui du développeur qui construit une pile locale. Son argument est simple et très utile (source).
Le goulet d'étranglement n'est pas le GPU.
Le goulet 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 goulets 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 données réelles, et la manière dont l'opérateur structure et utilise le système. Un modèle sans lien avec votre vie, c'est, selon les mots de l'article, “le véritable goulet d'étranglement n'est pas la vitesse à laquelle l'IA pense ; c'est ce qu'elle sait de votre monde à vous.”
Mettez les deux articles côte à côte et vous obtenez un diagnostic net. Les cinq agents les plus observés manquent chacun d'une chose différente en surface, mais la pièce manquante en dessous est la même : un agent qui vit véritablement à l'intérieur de la journée de l'opérateur, avec ses données, ses outils et ses habitudes, disponible en permanence.
Construisez quelque chose qui pense vite mais qui vit dans un onglet de discussion et vous avez, selon l'image de l'auteur de XDA, un moteur qui tourne au ralenti.
Ce qu'Ostler en fait
Ostler est bâti sur la réponse autour de laquelle tournent les deux articles. Un agent local qui vit sur le Mac du client, ingère ses données réelles et s'intègre à ses flux de travail réels.
Une courte liste de ce que cela signifie en pratique.
- Le Hub tourne sur un Mac que le client possède déjà, Apple Silicon M1 ou plus récent. Aucun parc à gérer, aucune seconde machine. La mémoire unifiée d'Apple Silicon est réellement utile ici pour l'inférence locale, mais elle est un second rôle, pas la tête d'affiche.
- Une ingestion profonde des données qui comptent vraiment dans la journée d'une personne. iMessage, WhatsApp, l'e-mail, Photos, Calendrier, l'historique de navigation Safari, les notes vocales. On ne demande pas à l'agent d'agir sur une vie qu'il ne peut pas voir.
- Une pile locale accordée à ce travail. Mon propre Hub, après des mois d'utilisation, contient environ 148 000 embeddings de ma vie dans Qdrant et près de deux millions de triplets RDF dans Oxigraph ; une installation client neuve démarre vide et grandit à partir des données propres à 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 le disque) et nomic-embed-text pour les embeddings. Whisper assure la transcription de la parole. SQLCipher garde la base de données chiffrée au repos. Un runtime d'agent en Rust pilote l'ensemble. Un compilateur MkDocs transforme le graphe en wiki privé.
- Une architecture mono-machine assumée. Un Mac, une installation, un seul endroit où vivent les données. La complexité est dans le pipeline, pas dans le déploiement.
- Des chemins réseau désactivés par défaut. Tout ce qui quitte la machine relève d'une adhésion explicite et reste désactivable. La position par défaut est que vos données ne sortent pas.
- Une app iOS pour les moments où 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, caché là-dedans, un argument sur l'architecture du financement. Un produit qui tourne entièrement sur la machine du client est malaisé à construire si votre table de capitalisation exige que vous facturiez au token. Un produit qui doit ingérer la vie entière d'une personne est malaisé à construire si vous lui demandez en même temps de la téléverser sur vos serveurs. Ostler a la forme qu'il a en partie parce qu'il est financé comme il l'est.
La barre à franchir
La barre que fixe Yang est la bonne : un agent disponible en permanence et qui abat réellement du travail pour vous. Les deux articles sont honnêtes sur la distance qui sépare la production actuelle de cette barre. Celui de Yang parce qu'aucun des cinq acteurs cités ne coche les dix cases. Celui 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 le chemin pour y arriver est celui qui n'est pas à la mode. Mettre l'agent sur une machine que l'opérateur possède déjà. Lui donner accès aux données qui décrivent réellement sa vie. Le brancher sur les outils qu'il utilise déjà. Garder des réglages par défaut privés. Faire du pipeline le produit.
L'installeur du Hub est signé, notarisé, agrafé et prêt. L'app iOS est distribuée par l'App Store. L'architecture ci-dessus est ce que vous obtenez en l'achetant.
The world DOES revolve around you.™