Nous sommes dans une spirale de plateformes. Chaque semaine, un nouvel outil apparaît, toujours plus puissant, plus rapide, plus impressionnant. Claude d’un côté, Figma de l’autre, Notion ailleurs. Des systèmes comme OpenClaw commencent même à sortir du cadre du simple assistant pour agir directement sur nos machines.
Tous ces outils sont puissants, mais ils restent enfermés dans leur propre monde. Ils ne parlent pas vraiment entre eux. On passe de l’un à l’autre, on connecte tant bien que mal avec des APIs ou des protocoles comme MCP. On empile des couches au lieu de construire un système.
Ce constat n’est plus théorique. Il est déjà visible dans ce qui émerge aujourd’hui sous le terme AI-Native OS. Ces systèmes ne se contentent plus d’exécuter des instructions, ils apprennent, s’adaptent et orchestrent des ensembles d’agents capables de collaborer entre eux.
Certaines initiatives restent encore proches de ce que l’on connaît. OpenClaw, par exemple, fonctionne comme un agent capable d’agir dans un environnement réel, d’exécuter des tâches, de naviguer entre différents outils et d’orchestrer des workflows complets. Mais il reste encore une couche posée sur un système existant.
D’autres approches vont plus loin et tentent de repenser l’architecture elle-même. Des projets comme AIOS explorent l’idée que le modèle de langage pourrait devenir le cœur du système, une sorte de noyau capable de gérer mémoire, ressources et exécution d’agents comme le ferait un OS traditionnel.
Et puis il y a des systèmes comme Steve, qui incarnent une étape encore différente. Steve ne se contente pas d’orchestrer des outils, il unifie l’ensemble de l’expérience IA dans un environnement cohérent. Il repose sur une mémoire partagée entre agents, une interaction en langage naturel et une capacité à transformer une intention en workflow complet. Dans Steve, les agents ne travaillent pas en silo. Ils partagent un contexte, apprennent les uns des autres et s’inscrivent dans un système global capable d’optimiser en continu les décisions et les processus. Ce que cela montre est simple : l’OS n’est plus un gestionnaire de fichiers ou de fenêtres, il devient un système décisionnel.
Mais malgré ces avancées, une limite reste évidente. Ces systèmes sont encore des plateformes, souvent orientées entreprise, encore éloignées du système personnel que chacun utilise au quotidien. Ils montrent la direction, mais pas encore la destination.
C’est précisément là que la question devient intéressante. Pourquoi continuer à ajouter de l’intelligence à des systèmes qui n’ont jamais été conçus pour cela, alors que tout indique que c’est le socle lui-même qui doit changer ?
Apple a déjà effleuré cette idée. Il fut un temps où macOS savait dialoguer avec des services et des contenus de manière relativement fluide. Puis la logique de fermeture a pris le dessus. Aujourd’hui, cette stratégie se heurte à une réalité nouvelle : l’intelligence n’est pas compatible avec le cloisonnement.
Apple se retrouve face à une opportunité rare. Non pas ajouter de l’IA à son système, mais redéfinir ce qu’est un système d’exploitation. Non pas un OS avec de l’IA, mais un OS fondé sur l’IA.
Appelons-le System X.
System X n’est pas qu’une interface différente. C’est un environnement cognitif, un AI-native OS. Un espace dans lequel on ne lance plus des applications, mais où des projets vivent, évoluent et interagissent en permanence.
Le matin, lorsque l’on ouvre son ordinateur, rien ne ressemble à ce que l’on connaît. Ce n’est pas un bureau, ni une grille d’icônes. C’est un système qui s’active. Deux espaces coexistent. L’un reste entièrement personnel, sous contrôle direct. L’autre est partagé avec le système, qui observe, comprend et organise en continu.
Ce qui apparaît à l’écran n’est pas une liste d’outils, mais un flux structuré autour de décisions. Chaque élément correspond à quelque chose qui a évolué, qui attend une validation ou qui mérite une attention. Le système ne montre pas tout, il montre ce qui compte.
On ne manipule plus un ordinateur. On oriente un système.
Une simple demande suffit à déclencher des actions complexes. Le système coordonne les agendas, interroge d’autres systèmes si nécessaire, ajuste les contraintes. La synchronisation devient invisible.
Lorsque l’on entre dans un projet, le travail a déjà commencé. Pendant la nuit, des propositions ont été générées, parfois enrichies ailleurs, par d’autres personnes ou d’autres systèmes. Le projet n’est plus un dossier. C’est un système vivant.
Au fil de la journée, le rôle de l’utilisateur change. Il ne produit plus directement. Il sélectionne, ajuste, arbitre. Une multitude d’agents travaillent en parallèle, générant des options, testant des variations, explorant des pistes. Le travail devient une activité de direction.
Progressivement, le système apprend. Une tâche répétée devient un pattern. Ce pattern devient une automatisation. Cette automatisation devient un outil. Les applications ne sont plus conçues à l’avance, elles émergent de l’usage.
Lorsqu’un client entre dans la boucle, une nouvelle couche apparaît. Son propre système analyse, évalue, teste. Les modèles interagissent entre eux. La collaboration ne se limite plus aux humains. Elle devient inter-systèmes.
Évidemment, cette vision peut sembler excessive. Beaucoup pensent que les systèmes actuels évolueront progressivement, qu’il suffira d’ajouter de l’IA, d’améliorer les assistants existants, et que cela suffira.
Mais cette hypothèse repose sur une idée fragile : que l’intelligence peut rester une fonctionnalité parmi d’autres.
Or, l’IA ne se contente plus d’assister. Elle comprend, exécute, coordonne et décide. Elle ne s’intègre pas facilement dans un système existant. Elle le déborde. Les architectures actuelles ont été conçues pour gérer des applications et des fichiers, pas pour orchestrer des agents et des flux de décisions. Ajouter de l’IA revient souvent à empiler une couche supplémentaire, mais cette logique ne tient pas à long terme.
Mais cette vision, aussi séduisante soit-elle, ne peut pas exister sans affronter une série de problèmes fondamentaux.
Le premier, et sans doute le plus critique, est celui des permissions et du contrôle. Aujourd’hui déjà, les agents capables d’agir sur un système posent un problème évident : ils ont souvent trop de pouvoir. Dans de nombreux cas, ces agents fonctionnent avec des permissions proches de celles de l’utilisateur, ce qui signifie qu’une mauvaise interprétation, ou pire, une injection de commande, peut conduire à des actions non désirées.
Le problème est structurel. Un agent ne distingue pas toujours clairement entre une instruction et une donnée. Il peut être manipulé, détourné, ou simplement mal interpréter un contexte. Les protections actuelles, souvent implémentées au niveau applicatif, sont contournables. Cela pousse déjà certains développeurs à explorer des solutions plus radicales, comme des systèmes de permissions directement intégrés au noyau, capables d’imposer des limites impossibles à contourner.
Microsoft, de son côté, commence à expérimenter cette approche avec des environnements isolés pour agents, où chaque agent n’accède qu’à un périmètre restreint du système. Mais cela reste une solution partielle, encore loin d’un modèle réellement maîtrisé.
Le second problème est celui de la fiabilité. Beaucoup de systèmes actuels reposent sur des agents qui restent, dans de nombreux cas, imprévisibles. Ils peuvent échouer silencieusement, boucler, ou produire des résultats incohérents. Construire un système d’exploitation sur cette base revient à bâtir sur un terrain encore instable.
Le troisième problème est celui de l’accès aux systèmes externes. Donner à un agent la capacité d’interagir avec des services réels implique de gérer des authentifications complexes, des APIs, des permissions, des sessions. Même des solutions récentes qui permettent à un agent de réutiliser une session utilisateur existante montrent à quel point cette couche reste fragile et bricolée.
Enfin, il y a un problème plus profond encore, celui de la sécurité globale. Un système capable d’agir, d’apprendre et de s’auto-modifier doit être encadré par des mécanismes beaucoup plus stricts que ceux des OS actuels. Sans cela, il devient une surface d’attaque permanente.
Une objection revient souvent. Pourquoi vouloir faire fonctionner tout cela en local, alors que la puissance du cloud est déjà là ?
Parce que ce que l’on décrit ici n’est pas seulement une question de calcul. C’est une question de contrôle, de latence et de continuité. Un système d’exploitation est un environnement critique. Il doit être instantané, autonome, toujours disponible. Le local garantit cette immédiateté, protège les données et permet au système de fonctionner indépendamment du réseau.
Le cloud ne disparaît pas, mais il change de rôle. Il devient une extension, une capacité supplémentaire, un espace de synchronisation entre systèmes. Le cœur, lui, reste local. C’est cette autonomie qui permet la confiance. Et sans confiance, aucun système de ce type ne peut exister.
Ce qui est en train de se jouer dépasse largement l’évolution des outils. On passe d’un monde d’applications à un monde de systèmes. La question n’est plus de savoir quel outil utiliser, mais quel système construire.
System X n’existe pas encore. J’ai la conviction qu’il finira par exister.