Un agent IA toujours actif est un agent qui peut rester responsable d’un travail quand aucune conversation n’est ouverte. Il peut conserver l’état d’une mission, attendre que le temps passe ou que le monde extérieur change, reprendre dans un environnement adapté et rendre la main quand la décision suivante revient à une personne.
« Toujours actif » ne veut pas dire qu’un grand modèle de langage réfléchit en continu. Cela ne veut pas dire qu’un ordinateur doit consommer des ressources à plein régime jour et nuit. Et cela ne devrait pas vouloir dire qu’un agent envoie sans cesse des messages ou agit sans autorisation. La promesse utile, c’est la continuité : la responsabilité reste vivante même quand l’essentiel du système dort.
Programmer un prompt ou conserver l’historique d’un chat ne répond pas aux questions pratiques : qu’est-ce qui survit à un redémarrage, qu’est-ce qui réveille l’agent, où continue-t-il à travailler et comment un utilisateur peut-il l’arrêter ? Ce sont les réponses à ces questions qui font de « 24/7 » une propriété du système plutôt qu’un slogan.
Être toujours actif, c’est une affaire de continuité, pas de disponibilité technique
Le temps de fonctionnement indique si un processus tourne. La continuité indique si le travail a toujours un responsable et une prochaine étape valable.
Imaginez que vous demandiez à un agent de guetter le retour d’un contrat signé, de mettre à jour une checklist de lancement quand il arrive et de vous préparer la décision suivante. Le contrat peut revenir demain ou la semaine prochaine. Pendant cette attente, aucun raisonnement utile n’a lieu. L’agent n’a besoin ni d’un chat ouvert, ni d’une session de modèle maintenue à chaud, ni d’un navigateur qui rafraîchit la boîte de réception chaque minute. Il a besoin d’une trace durable de la responsabilité et d’un moyen fiable pour que l’événement concerné la remette en mouvement.
La différence saute aux yeux en cas de panne. Un processus peut tourner en continu et pourtant perdre la mission après un plantage. Un autre système peut descendre à zéro pendant des heures, puis reconstruire son état et reprendre correctement quand un événement arrive. C’est le second qui est toujours actif au sens qui compte.
C’est pourquoi l’infrastructure des agents durables sépare l’attente du calcul. L’actuelle Durable Extension d'Agent Framework de Microsoft décrit par exemple des agents qui conservent leur état d’une exécution de worker à l’autre, se mettent en pause sans consommer de calcul ni de tokens de modèle et reprennent à partir d’événements externes. Le guide de Google sur les agents de longue durée qui reprennent sur événement illustre le même principe avec des checkpoints persistants et des webhooks. Les détails d’implémentation diffèrent, mais la leçon d’architecture reste la même : une responsabilité toujours active n’exige pas un modèle toujours en marche.
Les six conditions d’un agent toujours actif crédible
Aucune fonction ne rend à elle seule un agent toujours actif. Cette propriété apparaît quand six conditions fonctionnent ensemble.
Une identité continue porte la responsabilité
Le système a besoin d’une identité stable à laquelle rattacher messages, événements, autorisations, tâches et attentes de l’utilisateur. Si chaque conversation crée un agent sans lien avec les autres et sans contexte de fonctionnement partagé, les événements ultérieurs n’ont personne à réveiller et personne n’est responsable de poursuivre le travail.
Une identité continue n’exige pas une mémoire illimitée. Elle signifie que l’utilisateur peut revenir vers le même agent et que le système sait quelles responsabilités lui appartiennent. Les informations personnelles, l’historique des conversations et l’état des tâches peuvent garder des durées de vie et des contrôles différents.
L’état de travail survit aux périodes d’inactivité
Une mission doit conserver plus que son prompt de départ. L’état nécessaire pour reprendre peut inclure le résultat visé, les actions terminées, les éléments de travail, les contraintes, le blocage actuel et la prochaine étape valable.
Cet état doit être assez durable pour survivre aux interruptions ordinaires : un navigateur fermé, un ordinateur en veille, une mise à jour déployée, le redémarrage d’un worker ou le passage de plusieurs jours. Une transcription peut aider à reconstituer ce qui s’est passé, mais reconstituer n’est pas récupérer. Un système crédible sait quel état fait foi, au lieu de demander à un modèle de déduire la vérité d’une longue conversation à chaque réveil.
Le mécanisme plus profond qui permet de porter une mission à travers ses dépendances est une autre question que la définition de la catégorie. À ce niveau, le test est plus simple : le système peut-il conserver assez d’état valable pour continuer sans nouveau briefing ?
Le temps et les événements peuvent réintégrer le système
Le travail dans le monde extérieur n’avance pas seulement quand un utilisateur envoie un message. Les échéances arrivent. Les fichiers changent. Des réponses tombent. Un appareil revient en ligne. Une approbation est enregistrée dans une autre application.
Un agent toujours actif a donc besoin de plus qu’une zone de saisie interactive. Il lui faut un chemin pour qu’un minuteur ou un événement externe atteigne la responsabilité qu’il concerne. Ce chemin peut être un webhook, une file de messages, une planification, un connecteur ou un processus de surveillance au périmètre étroit. L’essentiel est que l’événement puisse être associé au bon agent et au bon état.
Cela ne veut pas dire que chaque événement mérite une exécution complète de raisonnement. Le fonctionnement guidé par les événements a de la valeur précisément parce que l’essentiel du système peut rester silencieux tant qu’il n’y a pas de travail à évaluer. Décider si un événement donné doit réveiller l'agent principal, et si ce réveil doit interrompre une personne, est une question de politique distincte de la définition du système toujours actif lui-même.
Un environnement d’exécution est disponible quand le travail reprend
Se souvenir de la prochaine étape ne suffit pas si l’agent n’a nulle part où l’accomplir. Une partie du travail peut passer par une API. Une autre exige un navigateur, un ordinateur cloud, une machine locale ou un runtime d’agent spécialisé. L’environnement doit être disponible quand la responsabilité redevient active, avec les fichiers, outils et autorisations que demande l’étape suivante.
« Disponible » ne veut pas dire allumé en permanence. Un ordinateur cloud peut dormir tout en conservant son stockage, puis se réveiller au besoin. Une machine locale peut rester déconnectée jusqu’à ce qu’une tâche en ait besoin. L’important est que l’agent sache identifier l’environnement requis et gérer honnêtement son absence.
Les limites de l’environnement font aussi partie de la justesse. La documentation sur les appareils de Comma précise que Salix ne déplace pas discrètement le travail d’un appareil hors ligne vers un autre ordinateur. La requête peut échouer et être relancée quand cet appareil revient. C’est moins magique que de prétendre que tous les ordinateurs sont interchangeables, mais cela préserve le lieu, l’accès et les conditions d’exécution dont dépend le travail.
La reprise après incident fait partie du fonctionnement normal
Un système toujours actif finira par rencontrer un redémarrage, un événement en double, un service indisponible, un identifiant expiré ou une connexion coupée. La fiabilité ne peut donc pas dépendre d’un processus qui resterait parfait pour toujours.
Le système a besoin d’un chemin de reprise : un état persistant, des checkpoints ou une source de vérité équivalente ; des nouvelles tentatives en nombre limité ; un moyen d’éviter de répéter une action externe ; et un état d’échec visible quand la reprise automatique n’est plus sûre. Un redémarrage qui oublie en silence ce qui avait été confirmé n’est pas une reprise. Une boucle de tentatives infinie qui consomme des ressources sans changer le résultat non plus.
La documentation des Loops de Comma en donne un exemple concret. Une Loop peut enregistrer un checkpoint et le recevoir quand elle redémarre. Après une panne, Salix la relance depuis ce checkpoint dans le cadre d’une politique de tentatives limitée ; des échecs répétés arrêtent la Loop et préviennent l’agent. L’implémentation complète, avec les événements durables, la déduplication, le placement et les limites de capacités, est expliquée dans Des boucles d'événements programmables pour notre harnais d'agents distribué. Pour évaluer un produit, vérifiez que l’interruption et la reprise sont des états prévus, et non des surprises.
L’utilisateur peut voir et encadrer la continuité
La persistance rend le contrôle plus important. Un chat ponctuel se termine de lui-même. Une responsabilité en arrière-plan a besoin d’un périmètre compréhensible, d’un état visible et d’un interrupteur qui fonctionne vraiment.
Les utilisateurs doivent pouvoir savoir de quoi l’agent est responsable, quelles sources il surveille, quel environnement il peut utiliser et de quelle autorité il y dispose. Ils doivent pouvoir mettre en pause ou terminer la responsabilité, révoquer l’accès et récupérer le travail déjà produit. Le système doit faire remonter les échecs et les décisions lourdes de conséquences, au lieu de prendre le silence pour la preuve que tout va bien.
C’est aussi pourquoi « toujours actif » et « autonome » ne sont pas synonymes. La persistance dit que le système peut rester disponible. L’autonomie décrit les décisions ou actions qu’il peut prendre sans demander. Un agent peut être très persistant et volontairement prudent : il peut préparer, vérifier, organiser et attendre tout en renvoyant à l’utilisateur les engagements externes et les choix irréversibles.
Quatre modes de fonctionnement, pas une exécution sans fin
L’expression « toujours actif » évoque une activité unique et continue. En pratique, un agent utile passe d’un mode à l’autre.
Il peut être au travail, un modèle et des outils faisant avancer une mission. Il peut être en attente, parce qu’un moment, un événement, un environnement ou une décision humaine n’est pas encore arrivé. Un veilleur léger peut surveiller une condition étroite sans réveiller l’agent principal. Ou la responsabilité peut être arrêtée, parce que l’utilisateur y a mis fin ou qu’une panne a dépassé la politique de reprise sûre.
Ces modes comptent autant pour le coût et l’attention que pour la fiabilité. L’inférence du modèle, le calcul cloud, la réception d’événements, le stockage et les API tierces peuvent être facturés de façons différentes. Un produit ne devrait pas les fondre dans une affirmation sans nuance du type « l’agent tourne 24/7 ». Une responsabilité calme en arrière-plan peut utiliser du stockage et des ressources de surveillance sans consommer un seul token d’un grand modèle ; une tâche active peut consommer à la fois du modèle et du calcul ; une responsabilité arrêtée ne devrait consommer ni l’un ni l’autre au-delà de l’état conservé.
Comma reflète cette séparation dans son propre runtime. Salix fait tourner l’agent en dehors d’un sandbox maintenu à chaud en permanence. Quand un travail sur ordinateur est nécessaire, il peut réveiller une machine virtuelle cloud dont le stockage persiste entre deux utilisations. Pour l’attention continue, de petites Loops peuvent surveiller des événements sans garder active la boucle principale de l’agent. La boucle principale ne s’exécute que lorsqu’une Loop estime que l’agent est nécessaire.
Cette architecture est l’implémentation de Comma, pas la définition universelle. Un autre produit peut utiliser des workflows durables, des files, des fonctions serverless ou des workers de longue durée. Le test consiste à savoir si l’ensemble du système préserve la responsabilité pendant les périodes d’inactivité, pas s’il utilise un runtime particulier.
Toujours actif, planifié et de longue durée sont des promesses différentes
Une automatisation planifiée exécute une instruction à un moment connu. Elle peut être très utile sans maintenir une identité d’agent continue ni réagir à des changements imprévus. Si une tâche quotidienne génère un rapport à partir d’éléments fixes, une planification suffit peut-être.
Un workflow de longue durée peut conserver son état sur plusieurs étapes et attendre un signal. Il devient agentique quand des modèles participent à l’interprétation des informations, au choix des outils ou à l’adaptation du plan. Il devient toujours actif au sens qui compte quand ce workflow durable appartient à un agent continu capable de recevoir de nouveaux événements pertinents et d’agir dans des limites gouvernées par l’utilisateur.
Un chatbot peut aussi se souvenir de conversations passées et proposer des rappels. Ces fonctions améliorent la continuité pour l’utilisateur, mais elles ne prouvent pas à elles seules que le travail persiste en dehors du chat. La question décisive n’est pas de savoir si le système se souvient de quelque chose à votre sujet. C’est de savoir si une responsabilité active peut attendre, reprendre, se rétablir et atteindre un environnement autorisé sans être recréée à la main.
Cette distinction évite aussi de trop construire. Toutes les demandes n’ont pas besoin d’un agent toujours actif. Une explication ponctuelle, une réécriture, un calcul ou un brainstorming sont souvent mieux servis par un modèle interactif. Le fonctionnement toujours actif justifie sa complexité quand le résultat dépend du temps, de changements extérieurs, de plusieurs environnements de travail ou d’une responsabilité qui reste ouverte une fois la conversation terminée.
Un test de continuité pratique
Pour évaluer un produit « toujours actif », confiez-lui une responsabilité réaliste qui comporte un temps d’attente. Demandez-lui de surveiller une condition définie, de préparer l’étape suivante et de s’arrêter avant une action lourde de conséquences.
Examinez ensuite ce que le produit peut vous montrer. Où la mission est-elle stockée une fois l’interface fermée ? Quelle condition précise la remet en mouvement ? Sait-il quel environnement contient les éléments de travail ? Peut-il reprendre après un redémarrage sans répéter les actions déjà faites ? Que se passe-t-il si l’événement arrive en double ou si l’appareil nécessaire est hors ligne ? Pouvez-vous mettre la surveillance en pause, révoquer l’accès ou terminer la mission sans effacer tout votre historique ?
Enfin, regardez ce qui vous parvient. Un système qui transmet chaque événement a construit un tuyau de notifications, pas forcément un agent. Un système qui agit à chaque événement a confondu disponibilité et autorité. Un agent toujours actif utile relie un changement à une responsabilité existante, fait le travail déjà autorisé et ne sollicite votre attention que lorsqu’elle change le résultat.
Comment Comma reste disponible sans faire de bruit
Comma est un agent personnel gratuit et open source, conçu autour d’un seul agent continu d’une conversation et d’un appareil à l’autre. Les questions rapides peuvent rester dans le chat, tandis que les responsabilités plus importantes deviennent des Tasks. Comma peut travailler dans les apps et fichiers connectés, sur un Mac ou un appareil Linux rattaché, ou sur un ordinateur cloud qui se réveille au besoin.
Sa couche toujours active, c’est Salix. Un agent Comma peut créer une Loop pour surveiller une source bien délimitée, comme une boîte de réception, un dépôt, un flux, une API ou un webhook. La Loop tourne à part de la boucle principale de raisonnement, peut tenir à jour un petit checkpoint et peut prévenir l’agent quand le travail l’exige. Comme l’agent principal n’a pas à examiner chaque période calme, « toujours disponible » ne devient pas « toujours en train de consommer des tokens de modèle ». Une Loop peut tout de même appeler un modèle de décision rapide ou un autre service, si bien que le travail en arrière-plan n’est pas gratuit pour autant ; le coût dépend de ce que fait réellement la Loop.
Cette continuité reste soumise au contrôle de l’utilisateur. Les ordinateurs rattachés démarrent en lecture seule tant que l’utilisateur n’autorise pas les opérations, et l’accès aux appareils peut être révoqué. Les Loops ont des limites de capacités et de réveils. Une Task plus importante peut revenir à À valider quand une décision appartient à la personne. Comma peut aussi être auto-hébergé, mais l’opérateur prend alors en charge la disponibilité, les mises à jour, les sauvegardes, la configuration du modèle et le reste de l’infrastructure nécessaire pour faire tourner cette instance.
L’approche de Comma est une réponse au problème central de la catégorie : laisser la responsabilité persister tout en laissant le calcul coûteux, les modèles et l’attention de l’utilisateur au repos jusqu’à ce qu’on en ait vraiment besoin.
Questions fréquentes
Un agent IA toujours actif fait-il tourner un modèle 24/7 ?
Non. Un système bien conçu peut conserver son état et guetter des minuteurs ou des événements pendant que le modèle principal est inactif. Le modèle tourne quand le système a besoin de raisonner ou de générer. La surveillance légère, le stockage et les services externes peuvent malgré tout consommer des ressources pendant que l’agent attend.
Un agent toujours actif est-il la même chose qu’un agent autonome ?
Non. « Toujours actif » décrit la continuité et la disponibilité dans le temps. L’autonomie décrit ce que l’agent peut décider ou faire sans approbation humaine. Un agent toujours actif peut fonctionner avec une autorité étroite et renvoyer à l’utilisateur les décisions lourdes de conséquences.
Une tâche IA planifiée est-elle un agent toujours actif ?
Pas forcément. Une planification peut lancer un prompt sans état à heure fixe. Un agent toujours actif conserve en plus la responsabilité et l’état pertinent, peut réagir aux événements externes appropriés, se rétablit après les interruptions et continue dans le cadre de contrôles utilisateur persistants.
L’ordinateur de l’agent doit-il rester allumé ?
Cela dépend de l’environnement nécessaire. Le travail dans le cloud ou côté serveur peut continuer pendant qu’un ordinateur portable personnel est fermé. Le travail qui dépend de fichiers ou d’applications présents uniquement sur un appareil local précis doit attendre cet appareil. Certains environnements cloud peuvent dormir entre deux actions tout en conservant leur stockage.
Que se passe-t-il quand un agent toujours actif tombe en panne ?
Le système doit reprendre depuis un checkpoint connu ou un état durable, éviter de répéter les actions externes déjà réalisées et utiliser des tentatives en nombre limité. S’il ne peut pas reprendre en toute sécurité, il doit s’arrêter de façon visible et indiquer à l’agent ou à l’utilisateur ce qui a échoué, au lieu de réessayer indéfiniment ou d’abandonner la responsabilité en silence.
Peut-on éteindre un agent toujours actif ?
Vous devez pouvoir mettre en pause ou terminer une responsabilité en arrière-plan et révoquer l’accès qu’elle utilise. « Toujours actif » doit vouloir dire disponible quand c’est autorisé, pas impossible à arrêter. Dans Comma, les Loops peuvent être mises en pause ou supprimées, et l’accès aux appareils connectés peut être révoqué.
L’agent peut dormir ; la responsabilité ne peut pas disparaître
Un agent IA toujours actif ne se définit pas par une activité continue du modèle. Il se définit par une chaîne de responsabilité continue : un responsable stable, un état durable, un chemin pour que le temps et les événements comptent, un environnement d’exécution disponible, un fonctionnement récupérable et des contrôles qui restent entre les mains de l’utilisateur.
Quand ces éléments existent, l’essentiel du système peut rester silencieux la plupart du temps. Le modèle peut s’arrêter. L’ordinateur cloud peut dormir. L’utilisateur peut fermer l’app. Le travail reprend parce que la responsabilité est toujours intacte, et non parce que quelqu’un a pensé à taper « continue ».
