Operon Obsidian : guide complet pour gérer vos tâches

Operon est un plugin de gestion des tâches et des projets pour Obsidian. Il réunit dans un même système les cases à cocher intégrées à vos notes et les tâches assez riches pour disposer de leur propre fichier Markdown. Chaque tâche reçoit une identité durable, peut être filtrée, planifiée, affichée dans un calendrier, un Kanban ou une table, puis lue ou modifiée par un humain comme par un agent IA. Sa représentation canonique reste dans le coffre Obsidian, même si les outils de synchronisation ou les modèles IA utilisés autour de lui possèdent leurs propres frontières de données.

Son intérêt ne tient donc pas à une fonctionnalité isolée. Operon devient utile lorsque vos tâches doivent rester reliées aux notes qui les expliquent, changer de forme au fil du travail et apparaître dans plusieurs vues sans être dupliquées. Il va plus loin qu’une simple liste de cases à cocher, tout en conservant vos données dans des fichiers lisibles.

Ce guide présente la configuration minimale que je recommande, les choix qui structurent réellement le système, l’usage mobile, les Daily et Weekly Notes, puis les deux voies agentiques d’Operon : son Agent Runtime natif et son intégration avec Optimike Obsidian MCP.

Dernière vérification : 26 août 2026
Versions documentées : Operon 3.5.3, Operon CLI 1.2.0, Optimike Obsidian MCP 3.1.2 et Optimike Operon Bridge 0.8.2.
Nature de la preuve : documentation officielle, dépôts publics et admission automatisée de la compatibilité MCP.
Limite : les interfaces mobiles décrites ici proviennent de la documentation officielle ; elles n’ont pas toutes été retestées sur chaque combinaison téléphone, thème et version d’Obsidian.

Transparence éditoriale : je contribue au développement d’Operon. Mon intérêt pour le plugin et mon opinion positive ont précédé cette contribution, mais ce lien crée un biais possible. Je distingue donc mon retour d’usage des capacités vérifiées dans la documentation, le code et mon environnement de test.

Operon est-il adapté à votre usage ?

En bref

• Oui si vous voulez piloter dans Obsidian des tâches légères et des travaux riches sans séparer l’action de son contexte.
• Oui, potentiellement pour remplacer un gestionnaire de tâches personnel avancé, même si vous utilisez aujourd’hui ClickUp, Asana ou Trello.
• Non, pas à lui seul si votre outil actuel sert surtout à coordonner plusieurs comptes, permissions, commentaires, notifications et approbations.

Operon est particulièrement pertinent lorsque certaines actions tiennent sur une ligne, tandis que d’autres deviennent des livrables, des recherches ou des travaux qui nécessitent leur propre note. Il peut couvrir statuts, priorités, sous-tâches, dépendances, récurrence, rappels, Calendar, Kanban, Table et suivi du temps.

Le critère de décision n’est pourtant pas le nombre de vues. Demandez-vous : où le statut officiel du travail doit-il vivre, et qui doit pouvoir le consulter ou le modifier ? Si une personne pilote l’essentiel du travail dans Obsidian, Operon peut devenir le système principal. Si plusieurs personnes dépendent d’un état partagé, d’alertes et de droits d’accès, conservez un outil collaboratif pour cette fonction. Le champ assignees peut décrire un responsable ; il ne crée pas à lui seul des comptes, des permissions ou une boîte de réception d’équipe.

Operon apporte aussi une réponse solide aux usages assistés par l’IA. Son Runtime local permet de lire et modifier les tâches à travers des contrats vérifiés, plutôt que de laisser un agent réécrire librement le Markdown. Le MCP Optimike ajoute ensuite une surface MCP gouvernée et relie les tâches au reste du coffre : notes, propriétés, Bases, Canvas, recherche sémantique et documents externes explicitement autorisés.

Operon reste surdimensionné si vous avez seulement besoin de quelques checkboxes ou si vous ne voulez entretenir aucune convention. Dans ces cas, les tâches Markdown natives ou le plugin Obsidian Tasks peuvent rester plus simples. Le guide pour choisir les bons plugins Obsidian permet de replacer ce choix dans l’écosystème complet.

Qu’est-ce qu’Operon dans Obsidian ?

Operon part d’un principe simple : une tâche doit pouvoir vivre là où le travail apparaît. Une action peut naître dans une note quotidienne, un compte rendu de réunion, une fiche projet ou un brouillon. La déplacer immédiatement dans une application séparée ferait perdre une partie de ce contexte.

Le plugin conserve donc les tâches dans le coffre Obsidian, sous forme de Markdown et de propriétés YAML (l’en-tête structuré placé au début d’une note). Il ajoute par-dessus une couche cohérente : identité, statuts, priorités, dates, relations, récurrence, rappels, suivi du temps et vues de planification.

Deux formes de tâches dans un même système

Operon reconnaît deux formes principales.

Une Inline Task est une case à cocher enrichie, placée sur une ligne à l’intérieur d’une note. Elle convient aux actions courtes qui appartiennent naturellement au contexte de cette note : relancer un interlocuteur, vérifier une source, corriger un paragraphe ou préparer un document.

Une File Task est une note Markdown qui est elle-même une tâche. Ses propriétés vivent dans le frontmatter et son corps peut accueillir un brief, des décisions, des liens, des notes de travail, une checklist ou de véritables sous-tâches. Elle convient à un article, une recherche, une migration, un livrable client ou tout travail qui a besoin de son propre espace.

Ces deux formes ne créent pas deux systèmes. Elles utilisent les mêmes champs et apparaissent dans les mêmes filtres, vues Calendar, tableaux Kanban et tables. Vous choisissez la forme adaptée au travail du moment, sans renoncer à une vue globale.

L’operonId donne une identité durable à la tâche

Chaque tâche Operon reçoit un identifiant appelé operonId. Son titre, son fichier, sa ligne ou son statut peuvent changer ; l’identité reste la même.

Cette distinction est essentielle. Sans identifiant durable, un outil doit deviner si une case à cocher déplacée correspond encore à la même action. Avec operonId, Operon peut suivre une tâche à travers ses modifications, ses vues, ses relations, son suivi du temps et ses conversions entre Inline Task et File Task.

L’identifiant doit être traité comme une donnée système. Laissez Operon le créer et utilisez les commandes du plugin pour les transformations structurelles. Copier ou modifier manuellement un operonId peut produire un conflit d’identité, même si Operon possède des mécanismes pour le détecter.

Les vues ne dupliquent pas les tâches

Filter View, Calendar, Kanban, Table et Task Finder présentent les mêmes tâches sous des angles différents. Une carte Kanban n’est pas une copie de la tâche qui se trouve dans une note. Un événement Calendar n’est pas une seconde version à synchroniser. Chaque surface lit et modifie le même objet identifié.

C’est l’une des différences importantes avec un système assemblé à partir de plusieurs plugins indépendants. Operon coordonne les tâches, les vues et les changements de forme autour d’un modèle commun.

Bien démarrer avec Operon sans complexifier votre coffre

Operon couvre beaucoup de cas d’usage. La mauvaise stratégie consiste à tout configurer avant d’avoir créé une seule tâche. La documentation officielle recommande un point de départ beaucoup plus sain : une tâche et une vue.

Je conseille de construire le système dans cet ordre : installer Operon, décider où les tâches sont créées, créer une première Inline Task, puis bâtir un filtre qui vous montre le travail utile. Calendar, Kanban, Table, récurrence et Agent Runtime viendront ensuite, lorsqu’une friction réelle les justifiera.

Installer Operon

Dans Obsidian, ouvrez Réglages → Plugins communautaires → Parcourir, recherchez Operon, puis installez et activez le plugin. L’interface et la saisie de dates en langage naturel sont disponibles en français. Vous pouvez aussi consulter la page officielle du plugin Operon, son dépôt GitHub et sa documentation complète.

Après l’activation, ouvrez Réglages → Operon. Ne cherchez pas encore à optimiser chaque option. Cinq décisions influencent la majorité du comportement futur.

Créer une première tâche et une première vue

Ouvrez la palette de commandes et lancez Create New Operon Task. Choisissez une Inline Task, donnez-lui une description simple, puis conservez les champs par défaut si vous n’avez pas encore défini votre workflow. Vous pouvez aussi lancer Create or edit inline task sur une ligne vide, un texte ou une checkbox Markdown existante.

Ouvrez ensuite Operon Filter View et construisez une première sélection limitée aux tâches ouvertes. Ajoutez seulement la condition dont vous avez réellement besoin (par exemple un projet, une date ou un statut), puis enregistrez la vue. Vous disposez alors du circuit minimal : capturer une tâche dans son contexte et la retrouver dans une surface de travail.

Cette première boucle doit fonctionner avant d’ajouter Calendar, Kanban ou des automatisations. Si vous ne savez pas encore où une tâche doit être écrite ou comment elle doit réapparaître, les couches avancées amplifieront le flou au lieu de le résoudre.

1. Choisir la destination des Inline Tasks

Le Task Router détermine où une nouvelle Inline Task est écrite lorsqu’aucune destination évidente ne vient du contexte courant. Les destinations possibles incluent notamment la note active, les Daily Notes, les Weekly Notes, un fichier précis ou une demande à chaque création.

Le bon choix dépend du rôle que vous donnez aux notes quotidiennes.

Si vos tâches doivent rester près de la décision ou du contenu qui les a fait naître, la note active constitue un bon point de départ. Si vous capturez surtout des actions datées et les triez ensuite, une Daily Note peut servir d’inbox temporelle. Si vous ne savez pas encore, utilisez une destination simple et réversible plutôt qu’un routage complexe.

2. Définir l’emplacement des File Tasks

Une File Task est un vrai fichier Markdown. Son emplacement compte donc pour la lisibilité, la synchronisation et la maintenance du coffre.

Un dossier unique comme Tasks/ suffit pour commencer. Vous pourrez plus tard router les File Tasks selon leur pipeline, leur parent ou leur état terminal. Évitez de créer une arborescence complète avant de savoir quels dossiers correspondent réellement à des usages distincts.

Le Task Router peut également déplacer certaines File Tasks vers des dossiers de travail ou d’archive. Ce déplacement change l’emplacement du fichier, pas l’identité de la tâche.

3. Vérifier les pipelines et les statuts

Un pipeline décrit le cycle de vie d’une famille de tâches. Ses statuts doivent correspondre à des transitions de travail observables : à clarifier, planifiée, en cours, en attente, terminée ou annulée, par exemple.

N’ajoutez pas un statut pour décrire une nuance qui ne change aucune décision. Si À relire et En validation produisent la même prochaine action, le système n’a probablement pas besoin des deux. Un statut mérite d’exister lorsqu’il modifie au moins un comportement : ce qui apparaît dans une vue, ce qui peut être démarré, ce qui bloque une autre tâche ou ce qui doit être revu.

4. Garder peu de niveaux de priorité

Une priorité doit modifier l’ordre dans lequel vous examinez ou exécutez le travail. Trois niveaux bien définis sont souvent plus utiles que sept degrés émotionnels d’urgence.

Vous pouvez commencer avec une distinction simple : critique, normale et basse. Le vocabulaire importe moins que la règle associée. Si deux priorités ne conduisent jamais à un tri différent, elles ne servent pas encore le système.

5. Stabiliser les Key Mappings

Les Key Mappings relient les champs canoniques d’Operon aux noms visibles dans votre Markdown. Ils permettent par exemple de conserver votre propre convention de propriétés tout en gardant une signification stable pour le plugin.

Si votre coffre possède déjà un schéma cohérent, alignez les mappings avec prudence. Sinon, conservez les valeurs par défaut au départ. Pour un agent ou une automatisation, les identifiants stables et les noms canoniques sont plus fiables que les libellés traduits ou personnalisés.

Ce que je déconseille de configurer immédiatement

Ne commencez pas par multiplier les statuts, les propriétés, les templates, les filtres et les automatisations. Chacune de ces couches ajoute une décision à maintenir.

Ma règle est simple : une propriété, un statut ou une vue ne mérite d’exister que s’il change une décision. Commencez avec le minimum qui rend le travail visible. Ajoutez une couche lorsque son absence crée une friction répétée, pas parce que le réglage existe.

Inline Task ou File Task : laquelle choisir ?

La décision la plus fréquente dans Operon concerne la forme de la tâche. La réponse officielle est saine : commencez inline, puis transformez la tâche en fichier lorsqu’elle a besoin de son propre espace.

Utilisez une Inline Task pour une action atomique

Une Inline Task convient lorsque la description et quelques champs suffisent à comprendre le travail. Elle reste près de la note qui lui donne son contexte et impose très peu de friction à la capture.

Exemples :

• relancer May au sujet d’une validation ;
• vérifier le title SEO d’une page ;
• relire un contrat ;
• ajouter une source à un brief ;
• tester un lien sur mobile.

Ces actions peuvent avoir un statut, une priorité, une date ou une relation sans nécessiter une note séparée.

Passez en File Task lorsque le travail a besoin d’espace

Une File Task devient utile lorsque vous commencez à disperser autour de l’action des informations nécessaires à son exécution. Les signaux les plus fiables sont les suivants :

• la tâche nécessite un brief ou un plan ;
• elle rassemble plusieurs sources ;
• des décisions doivent être conservées ;
• son contenu évolue sur plusieurs sessions ;
• elle comporte de véritables sous-tâches ;
• son résultat est un livrable qui mérite son propre fichier.

Rédiger cet article sur Operon est un bon exemple de File Task. La tâche a besoin d’un plan, de sources, d’arbitrages éditoriaux, d’un historique et de plusieurs étapes de validation. À l’inverse, « ajouter le lien vers la documentation mobile » reste une Inline Task.

La tâche peut changer de forme sans changer d’identité

Operon peut convertir une Inline Task en File Task, puis une File Task en Inline Task. Le plugin conserve les informations canoniques et l’operonId lorsque la conversion passe par ses commandes officielles.

Cette réversibilité évite de suranalyser la forme initiale. Une tâche peut commencer légère, gagner un espace lorsqu’elle grossit, puis être réduite si ce contexte n’est plus nécessaire.

La conversion d’une File Task vers une Inline Task demande toutefois de l’attention : le fichier source est envoyé dans la corbeille Obsidian après la conversion. Vérifiez que son corps ne contient pas d’information à conserver avant de confirmer l’opération.

Règle pratique Optimike
Action atomique → Inline Task.
Travail qui nécessite son propre contexte → File Task.

Structurer vos tâches sans construire une usine à gaz

La puissance d’Operon peut encourager à modéliser chaque détail. Le bon système ne cherche pourtant pas à décrire parfaitement le travail. Il doit rendre visibles les décisions qui changent ce travail.

Construisez des pipelines autour de transitions réelles

Un statut doit répondre à une question concrète : la tâche est-elle prête ? Quelqu’un travaille-t-il dessus ? Attend-elle une réponse ? Peut-elle être terminée ?

Commencez par observer votre flux actuel. Les points de friction récurrents indiquent les états utiles. Une colonne Kanban ne doit pas exister uniquement parce qu’elle est agréable à regarder. Elle doit permettre de savoir ce qui peut avancer et ce qui bloque.

Pour les agents, cette discipline devient encore plus importante. Un agent ne doit pas deviner qu’un libellé comme À suivre autorise une modification alors qu’un autre comme Référence l’interdit. Les statuts doivent avoir un sens stable, documenté et relié à une politique d’action.

Utilisez les priorités pour ordonner, pas pour dramatiser

Une priorité sert à comparer deux tâches concurrentes. Elle ne remplace ni une date, ni un statut, ni une décision de planification.

Une tâche importante mais non prête ne doit pas nécessairement apparaître dans la vue « Maintenant ». Une tâche urgente qui dépend d’un tiers doit plutôt être visible dans une surface d’attente. Plus les champs ont des rôles distincts, plus les vues et les agents peuvent les utiliser correctement.

Distinguez les libellés visibles des identifiants stables

Les noms de pipelines, de statuts et de priorités peuvent être traduits ou renommés. Les automatisations doivent utiliser les identifiants fournis par la configuration live d’Operon plutôt que supposer qu’un libellé français ou anglais restera inchangé.

Cette règle peut sembler technique. Elle évite pourtant un problème simple : une vue ou un agent qui cesse de fonctionner parce que En cours a été renommé Actif. L’humain lit le libellé ; l’automatisation s’appuie sur l’identité stable.

Utilisez une checklist pour les étapes internes

Une checklist simple convient aux étapes qui n’ont pas besoin d’être planifiées ou retrouvées séparément.

Pour une File Task « Publier le guide Operon », la checklist peut contenir :

• vérifier les liens ;
• compresser les images ;
• relire la meta description ;
• contrôler le rendu mobile.

Ces éléments servent à terminer la tâche principale. Ils n’ont pas nécessairement besoin d’un statut, d’une priorité ou d’une place dans le Calendar.

Créez une sous-tâche pour un travail pilotable séparément

Une sous-tâche Operon est une tâche complète reliée à son parent par identité. Elle peut vivre ailleurs dans le coffre, avoir sa propre date, sa propre priorité, ses propres relations et apparaître dans les vues globales.

Créez une sous-tâche lorsque l’étape peut être confiée, planifiée, bloquée, suivie ou terminée indépendamment. L’indentation aide à la lecture, mais c’est le champ parentTask qui porte réellement la relation.

Ne transformez pas un projet entier en tâche géante

Une File Task peut porter un livrable riche. Elle ne doit pas absorber automatiquement tout un projet composé de plusieurs résultats indépendants.

Je préfère conserver le projet comme note de contexte et de pilotage, puis relier les tâches qui produisent ses résultats. Une tâche maître peut agréger une partie du travail, mais elle ne doit pas devenir un conteneur opaque où décisions, documentation et dizaines d’actions se confondent.

Dans ÉLYSIA, je garde une frontière stricte : la note de projet porte le cap, les décisions, les résultats attendus et les preuves durables. Une création porte le contenu qui doit continuer d’exister au-delà de son exécution. Operon porte l’engagement exécutable : ce qui doit être fait, dans quel état et selon quelles relations. Autrement dit, un projet organise le sens ; une tâche organise l’exécution.

Choisir la bonne vue pour la bonne décision

Les vues d’Operon ne sont pas des fonctionnalités à collectionner. Chacune répond à une question différente. Le bon critère n’est donc pas « quelle vue est la plus puissante ? », mais « quelle décision dois-je prendre maintenant ? ».

Filter View : que dois-je faire ?

Filter View affiche une sélection de tâches correspondant à des conditions : état, priorité, date, parent, dossier, tag ou propriété. C’est la meilleure surface quotidienne pour réduire l’index complet à une liste actionnable.

Créez quelques filtres correspondant à des moments réels de travail : maintenant, cette semaine, en attente, à clarifier ou projet courant. Plusieurs filtres focalisés sont plus faciles à maintenir qu’une requête universelle censée répondre à toutes les situations.

Task Finder : où est cette tâche ?

Task Finder sert à retrouver rapidement une tâche précise lorsque vous vous souvenez de son contenu, mais pas de son fichier ou de sa vue. Il répond à une intention de recherche, alors qu’un filtre répond à une intention de sélection.

Cette différence se retrouve dans le Runtime agentique : une requête filtre un ensemble connu ; le Finder applique le comportement de recherche et de classement d’Operon.

Calendar : quand vais-je le faire ?

Calendar place les tâches dans le temps. Il aide à distinguer une échéance d’un bloc réellement planifié et peut réunir travail prévu, événements externes et temps suivi selon le preset utilisé.

Utilisez-le lorsque la contrainte principale est temporelle : répartir une charge, préparer une journée ou comparer le plan avec le temps réellement passé.

Kanban : où en est le travail ?

Kanban représente les statuts sous forme de colonnes. Il convient aux flux où le passage d’un état à un autre est plus important que la date précise.

Un bon Kanban doit rendre les blocages et la charge en cours visibles. S’il devient une galerie de cartes que personne ne déplace, le problème vient souvent du pipeline, pas de la mise en page.

Table : que dois-je comparer ?

Table affiche les tâches en lignes et leurs propriétés en colonnes. Elle devient utile lorsque vous devez comparer plusieurs dimensions : échéances, priorités, parents, durées, responsables ou champs personnalisés.

Elle convient aussi aux audits et aux revues de portefeuille. Pour l’exécution quotidienne, une Filter View plus étroite restera souvent plus rapide.

Un même filtre peut alimenter plusieurs vues

Un filtre enregistré peut servir de périmètre à une liste, un Calendar, un Kanban ou une Table. Vous pouvez donc observer le même ensemble de tâches sans reconstruire sa logique dans chaque surface.

Cette architecture réduit un risque classique d’Obsidian : créer plusieurs dashboards qui finissent par exprimer des règles différentes. Définissez le périmètre une fois, puis choisissez la vue selon la décision à prendre.

Utiliser Operon sur mobile

Operon ne se contente pas d’afficher une interface desktop rétrécie. Le plugin possède des adaptations pensées pour le téléphone : création rapide, dialogues tactiles, toolbar mobile, Calendar compact et Kanban à navigation horizontale.

L’usage humain des tâches fonctionne donc sur mobile. La frontière se situe plus loin : l’Agent Runtime, la Developer API et les opérations Operon du MCP Optimike exigent une instance Obsidian Desktop en cours d’exécution.

Capturer une tâche depuis votre téléphone

Operon affiche un bouton + flottant qui ouvre le Task Creator depuis les surfaces mobiles. Vous pouvez déplacer ce bouton et choisir de le masquer dans Calendar ou Kanban s’il gêne la navigation.

Cette capture rapide est particulièrement utile lorsque le téléphone sert d’entrée et le desktop de surface d’organisation. Le Task Router continue d’appliquer les mêmes règles de destination : note active, Daily Note, Weekly Note ou autre cible configurée.

Rechercher et modifier avec une interface tactile

Task Creator, Task Finder et Task Editor s’ouvrent dans des dialogues adaptés à la taille du téléphone. Ils suivent l’ouverture du clavier virtuel afin de conserver le champ actif et les résultats visibles.

Le Task Editor possède une toolbar mobile configurable. Gardez sous le pouce les champs et actions que vous utilisez réellement, puis masquez le reste. Cette personnalisation concerne l’interface mobile et ne modifie pas le layout desktop.

Planifier avec le Calendar mobile

Calendar propose quatre modes mobiles : Agenda, Day, 2 Days et 3 Days. Vous pouvez choisir lesquels apparaissent dans le cycle de navigation et associer un preset différent à chaque mode.

Une configuration simple consiste à utiliser Agenda pour lire l’horizon à venir, Day pour une journée détaillée et 2 Days pour répartir une charge courte. Le mode 3 Days donne davantage de portée, au prix d’une densité plus forte sur petit écran.

Piloter un Kanban au tactile

Le Kanban mobile affiche le même board avec un comportement adapté à la largeur disponible. Le défilement peut s’aligner sur une colonne complète, ce qui évite de rester entre deux statuts. Lors d’un déplacement, approcher une carte du bord permet de passer à la colonne suivante.

Les swimlanes deviennent un rail compact pour laisser davantage de place aux cartes. Les chips restent visibles, mais certaines interactions sont simplifiées afin de préserver les gestes de navigation et de drag.

Mobile ne signifie pas Runtime agentique mobile

Sur téléphone, vous pouvez capturer, consulter, modifier et planifier vos tâches. En revanche, le Runtime live d’Operon vit dans le plugin chargé par Obsidian Desktop. La CLI officielle et la Developer API ont besoin de cette instance.

Le MCP Optimike possède des modes headless pour d’autres opérations sur un coffre ou une copie synchronisée, mais une mutation Operon ne s’appuie jamais sur un snapshot obsolète ou headless. Pour les tâches agentiques Operon, considérez donc le desktop live comme une condition d’exécution.

Enfin, Operon ne remplace pas votre solution de synchronisation. Le coffre doit parvenir sur le téléphone par Obsidian Sync ou par la méthode de synchronisation que vous avez choisie et sécurisée.

Utiliser Daily et Weekly Notes avec Operon

Les notes périodiques donnent un emplacement naturel au travail daté. Operon peut utiliser une Daily Note pour les actions du jour et une Weekly Note pour les engagements qui doivent rester visibles sur un horizon hebdomadaire.

Le Task Router choisit la destination. Les réglages Daily et Weekly déterminent ensuite le format, le dossier, le template et le comportement de création de la note.

Utilisez les Daily Notes pour le travail rattaché à une date

Les Daily Notes conviennent aux actions du jour, aux suivis de réunion, aux captures temporelles et aux tâches qui apparaissent pendant l’exécution.

Vous pouvez laisser Operon gérer leur format et leur template, ou utiliser la configuration du plugin natif Daily Notes lorsque la gestion Operon est désactivée.

Utilisez les Weekly Notes pour planifier et revoir la semaine

Les Weekly Notes fonctionnent comme un horizon de pilotage. Elles peuvent accueillir des revues, des engagements, des tâches prévues et des regroupements par jour.

Operon gère leur format, leur dossier et leur template directement. Une tâche routée vers une Weekly Note peut être placée sous le heading correspondant à sa date réelle, plutôt que sous le seul lundi qui identifie la semaine.

Choisissez si la note périodique devient une File Task

L’option Create as Operon Task permet à une nouvelle Daily ou Weekly Note de devenir une File Task minimale. La note périodique peut alors servir de parent aux Inline Tasks créées à l’intérieur.

Ce choix est utile si vous voulez traiter chaque journée ou semaine comme un conteneur identifié avec ses propres relations. Il n’est pas obligatoire. Une note périodique peut rester un fichier Markdown ordinaire et recevoir des tâches sans devenir elle-même une tâche.

Operon n’adopte pas silencieusement une note existante. Si une Daily Note ordinaire existe déjà, le plugin peut y ajouter la nouvelle tâche sans convertir la note ni lui attribuer un rôle de parent périodique.

Le rescheduling ne déplace pas automatiquement le Markdown

Modifier dateScheduled peut conserver, détacher ou réaligner la relation avec un conteneur Daily ou Weekly vérifié. Cela ne déplace pas physiquement la ligne de tâche dans un autre fichier.

Cette distinction évite les déplacements implicites difficiles à suivre. La date représente la planification ; l’emplacement du Markdown représente la provenance et le contexte de capture. Si vous voulez réellement déplacer la tâche, utilisez une opération de relocalisation distincte.

Utiliser Operon avec une IA

Operon est conçu pour les humains et les agents. Ce positionnement ne repose pas uniquement sur le fait que les tâches sont en Markdown. Le plugin possède un Agent Runtime local qui expose la configuration, les tâches, les relations, le contexte et les mutations à travers des interfaces versionnées.

Deux voies existent : l’édition directe des fichiers et le Runtime. Elles répondent à des niveaux de risque différents.

Pourquoi les données Operon conviennent aux agents

Quatre propriétés rendent le système exploitable par une IA.

Les tâches restent d’abord lisibles en texte. Un agent peut comprendre leur description et leur contexte sans dépendre d’une base opaque.

Elles possèdent ensuite une identité durable. L’agent peut revenir vers la même tâche après un déplacement ou un changement de forme.

Les champs ont une signification canonique. Statut, priorité, date, relation et récurrence ne changent pas de sens selon la vue.

Enfin, la configuration peut être lue par la machine. L’agent peut découvrir les pipelines, les priorités, les mappings et les politiques du coffre au lieu de les inventer.

Téléchargez la documentation Operon dans votre coffre

Operon permet de télécharger ou mettre à jour sa documentation officielle dans Operon/Docs. Ces pages Markdown peuvent être consultées dans Obsidian, copiées comme dossier autonome ou fournies à un assistant IA. Elles décrivent la syntaxe, les concepts et les contrats officiels d’Operon.

Elles ne décrivent pas automatiquement les conventions propres à votre coffre. Vos pipelines, identifiants de statuts, priorités, Key Mappings et politiques doivent être lus dans la configuration réellement chargée. Je recommande donc de donner la documentation à l’agent pour le modèle général, puis de lui imposer la configuration live comme source de vérité opérationnelle.

Cette combinaison réduit deux risques différents : inventer le fonctionnement d’Operon et appliquer correctement une règle officielle avec les mauvais identifiants locaux.

Voie 1 : lire ou modifier directement le Markdown

Un agent doté d’un accès aux fichiers peut lire et éditer les tâches sans installer la CLI. Cette voie est légitime pour une opération simple, visible et supervisée.

Elle ne fournit cependant aucun contrat de version, signal de santé ou plan vérifié. L’agent doit comprendre les mappings, préserver l’identité, éviter les duplications et ne pas écrire pendant un index instable. Une modification syntaxiquement valide peut rester sémantiquement incorrecte.

Utilisez donc l’édition directe pour un cas ponctuel dont vous inspectez immédiatement le diff. Pour une intégration répétable, autonome ou plus sensible, préférez le Runtime.

Voie 2 : utiliser l’Agent Runtime

Le Runtime expose deux surfaces officielles.

operon-cli s’adresse aux humains, scripts et agents qui travaillent depuis un terminal ou un sous-processus. Il utilise la CLI officielle d’Obsidian pour joindre Operon dans une instance Desktop ouverte.

La Developer API in-process s’adresse aux autres plugins Obsidian. Le plugin appelant est identifié par le registre live d’Obsidian et doit demander des capacités précises. C’est cette voie qu’utilise l’Optimike Operon Bridge.

Les deux surfaces partagent la même logique de santé, de capacités, de lecture, de mutation, de reçu et de récupération. Elles n’utilisent simplement pas les mêmes frontières de confiance ni les mêmes références de plan. Elles restent locales : Operon n’expose pas de compte Runtime ni d’endpoint distant. Cette limite ne rend pas automatiquement toute votre stack privée ; votre solution de synchronisation et le modèle IA éventuellement appelé dans le cloud conservent leurs propres frontières.

Au 26 août 2026, la documentation de la CLI classe macOS comme supporté. Windows 11 natif et Linux natif sont en bêta publique avec support best-effort, tandis que WSL n’est pas pris en charge pour le transport live. Cette matrice concerne operon-cli et doit être revérifiée lorsque votre environnement change.

Commencez par lire les conventions du coffre

Avant de demander une tâche, l’agent doit lire le Catalog ou son équivalent via la Developer API. Il y découvre les pipelines, les statuts, les priorités, les Key Mappings, les politiques et les filtres disponibles.

Cette première lecture évite les instructions fragiles comme « passe la tâche en En cours » sans vérifier quel identifiant correspond à ce libellé dans le coffre actuel.

Choisissez la lecture la plus étroite possible

Le Runtime propose plusieurs niveaux de lecture.

Pour une tâche connue, lisez-la par operonId. Pour une référence imprécise, commencez par la résoudre. Pour un ensemble défini par des champs, utilisez une requête bornée. Pour une recherche textuelle classée, utilisez le Finder. Pour comprendre les dépendances, lisez les relations.

Le Context Pack intervient lorsqu’une décision a besoin du voisinage d’une tâche, d’un arbre de projet ou d’une charge de travail. Il assemble un paquet borné adapté à une intention : lecture, analyse, planification, création ou préparation d’une mutation.

Ne demandez pas systématiquement toutes les notes, tous les liens et tous les champs. Un contexte plus large coûte davantage, expose plus de données et augmente le bruit. Le bon paquet est celui qui suffit à la décision courante.

Les modifications passent par un plan vérifié

Le modèle d’écriture du Runtime suit quatre étapes :

preview → sealed plan → apply → receipt

L’agent décrit une intention. Operon calcule ce qui changerait et scelle ce résultat dans un plan lié à l’état observé. L’application porte sur ce plan exact, pas sur une nouvelle interprétation de l’instruction. Un reçu et une vérification postérieure indiquent ensuite ce qui s’est produit.

Si la tâche change entre la preview et l’application, le Runtime refuse d’écraser l’état plus récent. Les actions destructives demandent une confirmation liée à la cible et aux pertes annoncées.

Lorsqu’une opération a peut-être été appliquée mais que son résultat ne peut pas être prouvé, Operon renvoie outcome-unknown. Ce statut ne signifie ni échec ni succès. Il interdit un nouveau retry aveugle : la seule voie correcte consiste à récupérer le même plan.

Utiliser Operon avec le MCP Optimike

Vous n’avez pas besoin du MCP Optimike pour rendre Operon compatible avec les agents. Operon possède déjà sa CLI et sa Developer API.

Le MCP Optimike répond à un besoin différent. Le Model Context Protocol (MCP) permet à un client IA d’appeler des outils structurés. Optimike Obsidian MCP expose ainsi les capacités utiles à travers des opérations bornées, relie les tâches au reste du coffre et ajoute une politique d’exécution adaptée aux agents. Cette page dédiée explique aussi comment choisir un MCP pour Obsidian au-delà du seul cas Operon.

Ce que le MCP Optimike ajoute

Optimike Obsidian MCP fournit une surface commune au-dessus de plusieurs capacités : notes, frontmatter, tags, Bases, Canvas, recherche sémantique, documents externes autorisés et tâches Operon.

Un agent peut ainsi partir d’une tâche, retrouver les notes qui l’expliquent, consulter une source autorisée, préparer un changement puis revenir vers la tâche sans disposer d’un accès d’écriture général au coffre.

Le serveur expose actuellement vingt-cinq outils operon_*. Ils appartiennent au serveur MCP principal ; il n’existe pas un second serveur Operon séparé.

Architecture de l’intégration

La chaîne live est la suivante :

Client MCP → Optimike Obsidian MCP → Optimike Operon Bridge → Operon Developer API → Operon → Markdown du coffre

Le Bridge fonctionne comme une frontière entre le serveur Node et le plugin chargé dans Obsidian. Il négocie le contrat, vérifie les capacités, transmet les intentions typées et conserve les références nécessaires au suivi ou à la récupération.

Aucune opération Operon du MCP ne retombe silencieusement sur une édition Markdown brute, une API privée ou une commande de l’interface. Si la capacité officielle n’est pas disponible, l’outil renvoie une indisponibilité structurée.

Utilisez le profil tasks, pas la surface complète par défaut

Optimike Obsidian MCP propose plusieurs profils d’outils. Le profil standard couvre le travail général sur le coffre. Le profil tasks expose les workflows Tasks et Operon avec une surface plus ciblée. Le profil full active la surface complète et doit rester un choix explicite.

Dans la version 3.1.2, le profil tasks expose trente-trois outils sur un runtime live/hybrid complet, dont les vingt-cinq outils Operon. Le profil full en expose soixante-douze. Pour un agent principalement chargé de piloter Operon, démarrez donc avec tasks :

node dist/stdio-proxy.js --tool-profile tasks

Le principe est le moindre privilège. Ne donnez pas soixante-douze outils à un agent si trente-trois suffisent à son rôle, et ne passez pas en full simplement parce que le mode existe.

Configuration locale minimale

Le chemin live actuel suppose Node.js >=22.7.5, Obsidian Desktop, Operon, l’Optimike Operon Bridge et la configuration locale décrite dans le dépôt du MCP. Local REST API reste nécessaire aux opérations live du serveur qui passent par cette surface. Activez seulement les intégrations dont vous utilisez réellement les capacités et approuvez les grants Operon exacts lorsqu’ils sont demandés.

Pour un agent local, le transport stdio (une communication directe entre le processus client et le serveur) et le runtime live constituent le chemin recommandé. Une configuration minimale ressemble à ceci :

[mcp_servers.optimike-obsidian-mcp-stdio]
command = "node"
args = [
  "/chemin/vers/optimike-obsidian-mcp/dist/stdio-proxy.js",
  "--tool-profile",
  "tasks"
]

[mcp_servers.optimike-obsidian-mcp-stdio.env]
OBSIDIAN_VAULT = "/chemin/vers/le-coffre"
OBSIDIAN_RUNTIME_MODE = "live"
OBSIDIAN_BASE_URL = "http://127.0.0.1:27123"
OBSIDIAN_API_KEY = "<cle-local-rest-api>"
MCP_WRITE_MODE = "readonly"

Commencez en readonly. Vérifiez d’abord l’état, la configuration et les lectures Operon. Les chemins réels, les clés API et les journaux ne doivent pas être publiés dans un dépôt ou un coffre distribuable.

Pour activer les mutations, trois conditions distinctes doivent être réunies :

1. le Bridge doit autoriser les mutations dans ses réglages ;
2. l’environnement doit contenir OPERON_MUTATIONS_ENABLED=true ;
3. MCP_WRITE_MODE doit autoriser l’opération demandée.

Le mode guarded couvre les mutations courantes admises, comme la création, certaines mises à jour, les transitions, les relations ou la relocalisation inline. Le mode full ajoute notamment les opérations plus sensibles comme certaines conversions, la récurrence et la récupération d’un résultat incertain.

Les vingt-cinq outils, regroupés par intention

La liste complète est documentée dans le contrat MCP Operon. Pour l’usage quotidien, il est plus utile de les comprendre par fonction.

Comprendre le runtime : statut, configuration, diagnostics et validation.

Retrouver le travail : liste, lecture exacte, requête, filtre sauvegardé, Finder et résolution d’une référence.

Construire le contexte : relations, Context Pack et état du timer.

Agir : adoption d’une checkbox, création, création Daily/Weekly, mise à jour, transition, relations, récurrence, conversion et relocalisation.

Récupérer : inventaire des plans incertains et récupération du même plan.

Cette surface ne couvre volontairement pas tout ce que la CLI peut faire. La suppression, les rappels, le pin et le contrôle du timer restent notamment des opérations côté opérateur.

Pourquoi le MCP n’est pas un simple wrapper de la CLI

Un passthrough de commandes offrirait une surface trop large et obligerait l’agent à interpréter les effets de chaque commande. Le MCP n’admet une opération que lorsqu’elle possède un contrat sémantique borné et les garanties nécessaires.

Les mutations utilisent notamment :

• un dryRun par défaut ;
• une expectedRevision pour éviter d’écrire sur une tâche périmée ;
• une idempotencyKey durable pour empêcher une double application ;
• une vérification postflight dans l’index live ;
• un journal ;
• une récupération du plan exact après un résultat incertain.

La présence d’un outil ne prouve pas que la capacité est disponible. L’agent doit aussi vérifier l’état live, l’index, les grants, la politique d’écriture et la compatibilité du Bridge.

Le workflow Operon + MCP que je recommande

Le MCP devient utile lorsqu’il encadre une boucle de décision, pas lorsqu’il transforme chaque phrase en tâche. Le workflow suivant réduit les mutations inutiles et rend les résultats vérifiables.

1. Qualifier l’intention

Commencez par déterminer si l’utilisateur demande une analyse, un plan, une création ou une modification réelle.

« Prépare les tâches nécessaires » peut signifier produire une proposition sans écrire dans le coffre. Un plan ou une liste ne constitue pas automatiquement une autorisation de création.

2. Lire l’état et la configuration live

Appelez operon_status, puis operon_get_configuration lorsque la décision dépend des pipelines, statuts, priorités, chemins ou capacités.

Un snapshot stale peut aider à diagnostiquer un problème. Il ne doit jamais servir de preuve pour une mutation. Si la source n’est pas operon-live, si l’index n’est pas prêt ou si la capacité manque, restez en lecture.

3. Résoudre la tâche et lire le contexte minimal

Utilisez operon_resolve_task pour transformer une référence imprécise en tâche exacte, puis operon_get_task pour obtenir sa révision.

Lisez les relations uniquement si elles influencent la décision. Construisez un Context Pack lorsqu’un projet, un blocage ou une charge de travail l’exige. N’hydratez pas tout le coffre par défaut.

4. Produire un dry-run explicite

Toute mutation doit d’abord être prévisualisée. Le résultat présenté à l’humain doit distinguer :

• l’état actuel ;
• la demande ;
• le changement prévu ;
• les effets secondaires ;
• les avertissements ;
• ce qui restera inchangé.

Pour une tâche existante, utilisez l’expectedRevision lue juste avant le plan et une clé d’idempotence propre au dry-run.

5. Obtenir la validation appropriée

Une validation humaine est nécessaire lorsque l’opération modifie une référence durable, crée plusieurs tâches, change des relations, convertit un fichier ou comporte un risque difficilement réversible.

La validation doit porter sur le changement concret, pas sur une intention vague donnée plusieurs messages plus tôt.

6. Relire avant d’appliquer

Entre le dry-run et l’application, la tâche peut avoir changé. Relisez-la et comparez sa révision. Si elle diffère, arrêtez ou produisez un nouveau plan à partir de l’état actuel.

Utilisez une nouvelle clé d’idempotence pour l’application. La requête de dry-run et la requête d’apply ne sont pas le même objet canonique.

7. Appliquer, relire et prouver

Après l’application, relisez la tâche et les relations concernées. Appelez operon_validate lorsque la mutation affecte la cohérence du système.

Ne concluez pas au succès parce que l’appel n’a pas levé d’exception. Le succès doit correspondre à un état final relu et conforme à l’intention.

8. Récupérer le même plan en cas d’incertitude

Si la réponse indique outcome-unknown, ne rejouez pas la mutation initiale et ne créez pas un nouveau plan de remplacement. Inventoriez les opérations concernées avec operon_list_pending_recoveries, puis utilisez operon_recover_mutation avec le recoveryRef du même plan.

Cette règle protège contre le scénario le plus dangereux : une première écriture réussit, sa confirmation se perd, puis un retry crée une seconde tâche ou applique le changement deux fois.

Exemple pédagogique : préparer les tâches de publication d’un article

Supposons que vous demandiez :

Prépare les tâches nécessaires pour publier cet article. Ne crée rien avant validation.

L’agent peut d’abord lire la configuration, puis analyser le document et proposer trois tâches : intégrer le contenu, produire les visuels et réaliser la QA finale. À ce stade, aucune tâche n’est créée.

Après votre validation, l’agent vérifie de nouveau la configuration et la destination, lance les créations en dry-run, vous montre les champs et les relations prévues, puis applique les plans approuvés. Il relit ensuite les nouvelles tâches et valide qu’elles apparaissent dans la surface attendue.

Ce scénario est volontairement pédagogique. Le nombre de tâches, leur pipeline et leur destination doivent venir de votre configuration live, pas d’un modèle universel.

ÉLYSIA comme couche avancée, pas comme prérequis

Le dépôt du MCP Optimike publie un profil portable elysia.tasks et une skill elysia-task-gouverneur. Ils ajoutent des conventions d’usage : identifiants stables, filtres canoniques, politiques de création, dry-run, validation et preuve après application.

Cette couche montre comment gouverner un système de tâches agentique. Elle ne constitue pas la configuration obligatoire d’Operon. Vous pouvez utiliser Operon et le MCP avec vos propres pipelines, à condition que leurs rôles soient explicites et que l’agent lise la configuration réelle.

Operon peut-il remplacer ClickUp ou un outil collaboratif ?

Oui, si l’outil actuel vous sert surtout à organiser votre propre travail. Non, s’il constitue le lieu où une équipe coordonne officiellement ses engagements.

ClickUp, Asana, Trello, Linear ou Monday.com organisent les tâches et les projets à travers plusieurs surfaces. Selon le produit, leur valeur collaborative comprend aussi les comptes, les accès, les responsables, les notifications, les discussions, les approbations et la consolidation de la charge d’équipe. Les pages officielles de ClickUp, Asana et Trello illustrent cette couche collaborative.

Operon part d’un autre centre de gravité : le travail reste dans les fichiers et les notes du coffre Obsidian. Le plugin ajoute identité, propriétés, relations, vues et automatisation autour de ces fichiers. Cette architecture convient particulièrement à une personne qui pilote principalement son propre système, veut rapprocher l’exécution du contexte, garder ses fichiers sous contrôle local et faire intervenir des agents sur un périmètre gouverné.

Operon peut remplacer un gestionnaire personnel avancé

Le remplacement est crédible lorsque vous utilisez aujourd’hui un outil comme ClickUp ou Trello pour :

• capturer vos propres actions ;
• suivre des statuts et des priorités ;
• décomposer un livrable en tâches et sous-tâches ;
• visualiser votre travail dans une liste, un Calendar, un Kanban ou une Table ;
• gérer des dépendances, une récurrence, des rappels ou du temps suivi ;
• centraliser le contexte d’exécution autour de documents que vous possédez.

Dans ce scénario, Operon peut supprimer une duplication pénible : les notes dans Obsidian d’un côté, les tâches dans une application séparée de l’autre. Une File Task peut réunir l’action et son contexte de travail, tandis que les vues globales gardent l’ensemble pilotable.

Operon ne remplace pas nativement la coordination multi-utilisateur

Le remplacement n’est pas équivalent lorsque votre outil sert à :

• inviter des collaborateurs, clients ou prestataires avec des droits différents ;
• attribuer une tâche à un compte qui reçoit ses propres notifications ;
• conserver des commentaires, mentions, décisions et approbations attachés au travail ;
• fournir une boîte de réception partagée ou des alertes de changement ;
• mesurer la charge, la capacité ou la performance d’une équipe ;
• produire des tableaux de bord destinés au management ;
• connecter un grand nombre d’applications métier à une source centrale ;
• administrer la sécurité, les accès et l’historique au niveau de l’organisation.

Operon possède des propriétés comme assignees pour représenter des responsables, mais une propriété ne crée ni identité utilisateur, ni permission, ni notification. Synchroniser des fichiers entre plusieurs personnes ne recrée pas non plus automatiquement les règles de coordination d’un outil collaboratif en ligne.

En hybride, choisissez une seule source de statut officiel

Pour une agence, un collectif ou une équipe, le meilleur montage peut être hybride. Par exemple, un indépendant peut conserver ClickUp pour les validations et commentaires du client, tout en utilisant Operon pour son contexte de travail et ses actions internes :

• l’outil collaboratif conserve les engagements partagés, responsables, échéances, commentaires et validations ;
• Obsidian conserve les sources, décisions, briefs et notes de travail ;
• Operon pilote les actions personnelles ou contextuelles qui vivent réellement dans le coffre ;
• un transfert explicite relie les deux lorsque c’est nécessaire.

Le garde-fou est simple : ne dupliquez pas aveuglément chaque tâche et chaque statut dans les deux systèmes. Dès que deux applications prétendent faire foi sur la même action, les écarts deviennent inévitables. Définissez un propriétaire pour chaque information : l’outil d’équipe pour l’engagement collectif, Operon pour l’exécution locale et le contexte, ou l’inverse dans une organisation réellement centrée sur Obsidian.

Avant de migrer, posez cinq questions :

1. Où une personne autre que moi doit-elle voir le statut officiel ?
2. Les commentaires, mentions ou approbations font-ils partie du processus ?
3. Ai-je besoin de rôles, de permissions ou d’un accès invité ?
4. Le management attend-il une vue de charge ou un rapport consolidé ?
5. Une notification manquée peut-elle bloquer quelqu’un d’autre ?

Si ces fonctions sont centrales, Operon doit compléter l’outil collaboratif plutôt que le remplacer. Si elles sont secondaires et que le coffre Obsidian constitue déjà votre environnement principal, un remplacement devient beaucoup plus plausible.

Operon, Obsidian Tasks ou TaskNotes : quel modèle choisir ?

Cette comparaison porte sur le modèle de tâche à l’intérieur d’Obsidian, pas sur la collaboration multi-utilisateur. Ces trois plugins peuvent gérer des tâches dans un coffre, mais ils ne partent pas du même objet canonique.

Choisissez Obsidian Tasks pour enrichir vos checkboxes

Le plugin Tasks pour Obsidian suit les cases à cocher dans tout le coffre, ajoute des dates, des statuts, de la récurrence et un langage de requête. Il reste un excellent choix si la tâche est fondamentalement une ligne et si vos notes portent déjà le contexte. Sa documentation officielle détaille son langage de requête et ses conventions.

Pour comparer plusieurs approches de pilotage, consultez aussi les plugins pour gérer les tâches dans Obsidian.

Choisissez TaskNotes si la tâche est d’abord une note

TaskNotes suit le principe « one note per task ». Chaque tâche canonique est un fichier Markdown avec frontmatter, et ses vues sont alimentées par Obsidian Bases. Le plugin propose aussi des intégrations inline pour faciliter la capture, mais la note reste le record principal.

Ce modèle convient lorsque vous voulez que chaque tâche soit immédiatement un document extensible et que Bases soit la couche de requête et de présentation.

Choisissez Operon pour réunir les deux formes

Operon est le plus distinct lorsque vous refusez de choisir une forme unique pour toutes les tâches. Les actions courtes restent inline. Les travaux riches deviennent des fichiers. Les deux partagent l’identité, les champs, les relations et les vues.

Son Agent Runtime constitue un second différenciateur pour les workflows où des scripts, plugins ou agents doivent lire et modifier les tâches à travers une frontière vérifiée.

Aucun de ces plugins n’est universellement supérieur. Le meilleur choix dépend du coût que vous voulez éviter : trop de fichiers, pas assez de contexte, plusieurs systèmes parallèles ou une surface agentique insuffisamment contrôlée.

Comment j’ai adopté Operon dans ÉLYSIA

Je n’ai pas basculé mon système d’un seul geste. Operon est d’abord entré dans un laboratoire séparé : j’ai comparé son modèle à celui que j’utilisais, vérifié les capacités réelles, préparé un retour arrière, puis testé les mutations en dry-run avant toute adoption.

Ce pilote a corrigé une mauvaise intuition : migrer ne voulait pas dire transformer chaque micro-action en tâche autonome. Dans ce périmètre précis, treize engagements maîtres ont été adoptés par Operon, tandis que vingt-sept micro-actions sont restées de simples sous-puces de progression. Ces nombres décrivent ce pilote, pas une proportion universelle. Le critère utile reste l’autonomie de l’action : doit-elle être planifiée, retrouvée, bloquée ou suivie indépendamment ?

Après stabilisation, Obsidian Tasks et TaskNotes ont été désactivés dans ce périmètre, tout en restant disponibles comme voie de retour pendant la transition. La compatibilité facilite une migration ; elle ne remplace pas le choix d’une source de vérité unique.

FAQ sur Operon

Mon verdict sur Operon

Operon est l’un des choix les plus cohérents pour gérer des tâches dans Obsidian lorsque le travail alterne entre actions légères et objets riches. Son modèle évite deux extrêmes : réduire tout le travail à des lignes sans espace, ou créer un fichier pour la moindre action.

Je le recommande comme système personnel d’exécution centré sur Obsidian. Il peut remplacer un ClickUp ou un Trello utilisé principalement en solo. Il doit plutôt compléter un outil d’équipe lorsque comptes, permissions, discussions, notifications et reporting collectif font partie du processus.

Sa valeur augmente encore lorsque des agents entrent dans la boucle. L’identité durable, la configuration lisible et le Runtime vérifié donnent une base plus fiable qu’une édition libre du coffre. Le MCP Optimike ne remplace pas ce Runtime : il l’expose à des clients MCP et l’intègre à un système plus large de notes, de sources, de permissions et de validation.

Commencez sans agent et sans architecture complexe. Créez une Inline Task, construisez une Filter View et vérifiez que le Task Router place le travail au bon endroit. Lorsque cette boucle vous aide déjà humainement, ajoutez Calendar, Kanban, mobile, puis le Runtime ou le MCP selon la friction rencontrée.

Ressources pour aller plus loin

• Documentation officielle d’Operon
• Dépôt GitHub d’Operon
• Dernière release d’Operon
• Vue d’ensemble de l’Agent Runtime
• Documentation mobile d’Operon
• Dépôt Optimike Obsidian MCP
• Contrat MCP Operon
• Fonctionnalités collaboratives de ClickUp
• Gestion du travail en équipe avec Asana
• Permissions et contrôles d’équipe dans Trello
• Guide complet d’Obsidian sur Optimike
• Guide Obsidian et intelligence artificielle
• Formation Obsidian : choisir le bon parcours