Après OpenClaw, pourquoi la plupart des gens sentent-ils encore qu'il y a un fossé

Écrire : Cercle de réflexion approfondie

Vous êtes-vous déjà demandé pourquoi OpenClaw est si populaire, mais après l’avoir utilisé, la majorité des utilisateurs ressentent que — c’est intelligent, mais il manque quelque chose ?

Ce n’est pas que le modèle n’est pas assez puissant, ni que les fonctionnalités sont insuffisantes. C’est qu’il résout le problème de « penser », mais pas celui de « faire ».

Vous lui donnez une tâche à exécuter, il tourne dans le terminal, écrit dans l’IDE, fait des inférences dans la boîte de dialogue. Mais entre « jugement terminé » et « tâche réellement accomplie », il y a un chemin — changer de fenêtre, chercher dans le système, copier-coller, cliquer sur confirmer — c’est encore vous qui faites ce trajet.

Ce n’est pas une erreur de conception d’OpenClaw, mais un problème structurel actuel de l’écosystème des agents IA : la perception et le raisonnement sont déjà très matures, mais la couche d’exécution est presque vide.

La variable sous-estimée

Ces deux dernières années, la discussion sur l’infrastructure IA s’est concentrée sur deux axes :

1. La capacité du modèle — taille des paramètres, vitesse d’inférence, fenêtre de contexte — des progrès visibles sur ce front.

2. Le cadre d’agent — LangChain, AutoGPT, OpenClaw, représentant la capacité d’orchestration et de planification des tâches — aussi beaucoup d’investissements.

Mais il existe une variable que presque personne ne traite systématiquement : l’infrastructure d’exécution au niveau du poste de travail.

Qu’est-ce que l’infrastructure d’exécution au niveau du poste ?

Simplement, c’est ce qui permet à l’agent de « passer à l’action » dans votre environnement de travail concret — pas dans un environnement sandbox, pas dans son propre conteneur, mais sur votre écran réel, avec vos outils réels, dans votre système réel.

Pourquoi cette étape est-elle difficile ?

Parce que la complexité du contexte de travail réel dépasse de loin toute simulation sandbox. Beaucoup d’entreprises utilisent encore des systèmes hérités sans API, de nombreux flux de travail nécessitent de passer par cinq ou six outils différents, et le contexte de nombreuses tâches est dispersé dans plusieurs fenêtres, sans interface standardisée pour l’appeler.

Cette complexité ne peut pas être résolue simplement en rendant le modèle plus intelligent. Elle requiert une capacité de perception et d’exécution plus fondamentale — voir l’écran réel, comprendre l’état entre plusieurs fenêtres, manipuler directement la souris et le clavier.

C’est précisément là que réside le véritable goulot d’étranglement pour la mise en œuvre concrète des agents, et c’est aussi la variable que la plupart sous-estiment systématiquement lorsqu’ils discutent des agents IA.

Ce que fait Violoop

Récemment, un projet appelé Violoop a attiré mon attention.

Il s’agit d’un matériel IA natif avec écran tactile intégré, connecté à un ordinateur via HDMI + Type-C, supporté par Mac et Windows. Visuellement, ce n’est pas impressionnant. Mais ce qu’il fait, pointe justement vers cette variable sous-estimée évoquée plus haut.

Il collecte trois types de données : flux vidéo (perception visuelle globale de l’écran), API système (signaux d’état du système d’exploitation), permissions HID (contrôle bas niveau de la souris et du clavier). Ces trois couches combinées forment un runtime perception-jugement-exécution au niveau du poste.

Ce qui est encore plus crucial, c’est son mode de fonctionnement : il ne s’agit pas d’un exécuteur passif attendant des instructions, mais d’un runtime actif qui perçoit en continu l’état du travail, juge quand intervenir, et agit en conséquence.

Il regarde quel fenêtre vous avez changé, combien de temps vous restez sur une page, à quel rythme la tâche progresse — puis décide lui-même s’il doit agir ou non. Cette logique de conception est fondamentalement différente du mode « réponse passive » de tous les outils IA actuels.

La valeur structurelle de la couche d’exécution

Je souhaite expliquer un peu pourquoi l’absence de cette couche d’exécution est un problème structurel, et pas seulement un manque fonctionnel.

L’organisation en couches des outils d’agent IA peut être grossièrement comprise ainsi :

• Couche modèle : responsable du raisonnement, déjà très mature.

• Couche cadre : responsable de l’orchestration des tâches, en rapide convergence.

• Couche outils : pour renforcer des scénarios spécifiques, très homogène.

• Couche d’exécution : pour la perception au niveau du poste et l’exécution inter-outils, presque inexistante.

L’absence de cette couche d’exécution ne se limite pas à rendre l’utilisation de l’agent « moins bonne ». Elle limite plus profondément la capacité de l’agent : ses capacités sont artificiellement confinées par le contexte.

Par exemple, la capacité de Cursor se limite à l’IDE. Celle de Claude Code à un terminal. Dans leur conteneur, ils sont puissants, mais tout ce qui se passe en dehors, ils ne le voient pas, ni ne peuvent y répondre.

Cela signifie que, fondamentalement, les agents IA actuels ne sont qu’un « renforcement local » — ils améliorent votre capacité dans un outil précis, mais ne renforcent pas votre flux de travail global.

Pour que l’agent soit réellement opérationnel, il faut une perception et une exécution capables de franchir ces frontières de conteneur. Il faut un système IA capable de voir le global, de le manipuler.

Le point d’entrée de Violoop est précisément ici.

Quelques décisions de conception méritant réflexion

Plusieurs choix dans l’architecture de Violoop, je pense, ne sont pas seulement des options fonctionnelles, mais reflètent une compréhension profonde du problème.

Mode d’apprentissage par enregistrement d’écran : réponse positive à la « réalité sans API »

Beaucoup d’entreprises utilisent encore des systèmes hérités sans aucune API. Ce n’est pas un problème de dette technique, mais une contrainte réelle — ces systèmes ne disparaîtront pas à court terme, et n’ouvriront pas d’interfaces soudainement.

Le mode d’apprentissage par enregistrement d’écran de Violoop, basé sur l’apprentissage par renforcement pour construire un modèle de structure de tâche, plutôt que de simplement enregistrer et rejouer des coordonnées fixes. La décision derrière ce choix est que l’environnement de travail réel est dynamique, et toute automatisation basée sur un chemin fixe échouera si l’UI change. Seule la compréhension de l’intention de la tâche permet de maintenir une stabilité élevée dans un contexte changeant.

Ce jugement est correct, et c’est aussi la raison fondamentale pour laquelle les outils RPA traditionnels atteignent un plafond en échelle.

Division entre côté terminal et cloud : répondre simultanément aux coûts d’inférence et aux limites de confidentialité

Le traitement multimodal à haute fréquence (perception d’écran, compréhension visuelle, nettoyage de données sensibles) est effectué sur le chip local, tandis que l’inférence complexe se fait dans le cloud.

Ce découpage résout deux problèmes : d’une part, le coût — l’inférence multimodale étant la principale source de coût d’exécution, la localiser réduit considérablement le prix par exécution ; d’autre part, la confidentialité — les données sensibles étant filtrées avant d’être envoyées dans le cloud, respectant ainsi la gouvernance des données.

Plus important encore, cette architecture permet à Violoop d’être réellement en veille 24/7 — combiné au mécanisme Wake-on-LAN, il peut réveiller automatiquement la machine à une heure donnée, exécuter la tâche, puis la remettre en veille. Ce que seul un logiciel agent ne peut pas faire.

Isolation matérielle des permissions : réponse à « risque d’exécution autonome » en mode ingénierie

Une puce de sécurité indépendante gère la vérification des permissions, physiquement isolée du processeur principal. Toute opération à haut risque doit passer par une confirmation matérielle, impossible à contourner par logiciel, et en cas de déconnexion physique, tout s’arrête.

Je trouve ce design particulièrement intéressant, car il montre que l’équipe a une compréhension claire du « risque d’exécution autonome » : ce risque ne peut pas être simplement contrôlé par des prompts ou des prompts système, mais nécessite des contraintes matérielles en runtime. C’est une décision que seul une équipe ayant déployé un agent en environnement de production peut prendre.

Pourquoi cette direction apparaît maintenant

Une question à se poser : l’absence de couche d’exécution n’est pas un problème nouveau, alors pourquoi un projet comme Violoop apparaît-il maintenant ?

Je pense que plusieurs conditions ont mûri simultanément récemment :

1. La capacité de raisonnement multimodal en périphérie a atteint un niveau permettant de traiter en temps réel les signaux visuels de l’écran. Les hardware plus anciens ne pouvaient pas faire cela.

2. La compréhension des tâches par les grands modèles est suffisamment forte pour rendre possible la « compréhension de l’intention » plutôt que simplement « enregistrer une séquence d’actions ». C’est la condition de la viabilité du mode d’apprentissage par enregistrement d’écran.

3. La vague OpenClaw a mis en lumière le manque de couche d’exécution, rendant la demande du marché pour cette direction visible.

La maturité simultanée de ces trois conditions ouvre une fenêtre auparavant inexistante.

L’équipe de Violoop, dans une certaine mesure, confirme cette analyse — le CEO Jaylen He est un entrepreneur en série, ayant mené une équipe en YC, le CTO King Zhu est diplômé du MIT EECS, un génie ayant terminé ses études en 3,5 ans, avec une expérience chez Microsoft Xbox, HoloLens, Surface, et déployé en périphérie dans des entreprises du Fortune 500 depuis 2023. Ce n’est pas une équipe qui s’est lancée dans l’IA hardware parce que OpenClaw a explosé, mais qui explorait déjà cette voie avant.

De plus, Violoop a levé deux tours de financement en un mois, la deuxième étape en une semaine entre rencontre et signature, et une troisième en cours — ce rythme montre que le capital valide aussi cette direction.

Signaux vraiment importants à suivre

Le produit sera lancé en crowdfunding sur Kickstarter en avril. Le projet n’est pas encore en production, beaucoup de capacités doivent encore être validées en environnement réel. La généralisation du mode d’apprentissage par enregistrement d’écran, la pérennité du système Skill, la stabilité du hardware en production — autant de questions qui nécessitent du temps et des données utilisateur réelles pour y répondre.

Mais une chose me semble déjà claire :

La couche d’exécution est une infrastructure fondamentale que l’écosystème des agents doit impérativement compléter dans les deux ou trois prochaines années. Pas parce qu’un produit a connu un succès, mais parce que sans cette couche, tous les investissements dans la perception et le raisonnement ne se traduiront pas en gains d’efficacité tangibles pour l’utilisateur dans son travail quotidien.

Ce positionnement, tôt ou tard, sera pris par quelqu’un.

Le vrai enjeu n’est pas « si la couche d’exécution est importante », mais « qui la construira, comment, et quand ».

Violoop est actuellement l’un des rares projets à avoir une compréhension claire du problème et une architecture qui lui est propre.

Le succès d’OpenClaw a montré le potentiel des agents. Mais le véritable tournant pour leur déploiement ne viendra probablement pas du jour où un nouveau modèle sera lancé, mais du jour où l’infrastructure d’exécution sera complétée.

C’est cela, le signal vraiment porteur derrière cette vague de popularité.