Tedix : déléguer le travail aux assistants IA et ne récupérer que les décisions qui vous concernent

À qui cela s'adresse

Tedix s'adresse à ceux qui utilisent régulièrement des assistants IA, veulent déléguer en bloc le travail récurrent et n'intervenir personnellement qu'aux points de décision clés. Le positionnement officiel : une fois le travail confié, Tedix ne vous ramène que les décisions qui exigent votre arbitrage, classées par importance, et traite le reste. Autrement dit, la question n'est pas de savoir si l'IA peut être appelée, mais quels dossiers méritent votre regard. Si vous faites déjà avancer vos tâches dans Claude, ChatGPT ou Codex et voulez alléger les allers-retours de suivi, cela mérite un essai.

Côté clients, la prise en charge officielle couvre Claude, ChatGPT et Codex ; les autres clients compatibles MCP se connectent via le MCP gateway. Savoir si des assistants hors de cette liste se branchent sans difficulté n'est pas tranché par les preuves : à vérifier vous-même.

Le prérequis pour démarrer est une chaîne d'outils locale : Git, Bun et Node.js 22+, avec une insistance officielle sur un vrai Node, pas un shim Bun. Ce chemin local n'exige ni compte ni identifiants cloud ; le coût de l'essai tient surtout à la préparation de l'environnement. Son adaptation aux types de travail de votre domaine n'est pas non plus documentée : validez d'abord avec des tâches à faible risque.

Cas non adaptés pour l'instant : qui ne veut qu'un service cloud prêt à l'emploi et refuse d'installer une chaîne d'outils locale. Tedix Cloud n'ouvre pas encore les inscriptions et fonctionne sur invitation ; sans invitation et sans environnement local, il n'y a pour l'instant aucun moyen d'essayer. Les équipes avec un besoin ferme de cloud ont intérêt à obtenir d'abord une invitation, puis à évaluer.

Une première tentative en 3 minutes

Le chemin principal recommandé est le mode démo local : il lance l'application en local avec des données d'exemple, ne dépend pas du cloud et ne demande aucun compte ni identifiants cloud.

Première étape, vérifier les prérequis : installez Git, Bun et Node.js 22+. Si cet ensemble de dépendances ne s'installe pas localement, ce chemin ne fonctionnera pas.

Deuxième étape, cloner le dépôt et lancer la démo :

git clone https://github.com/tedix-hq/tedix.git && cd tedix
bun run-local --demo

Troisième étape, observer les signaux de réussite : l'application démarre en local et charge les données d'exemple. La description officielle s'arrête là ; les opérations réellement proposées dans l'interface de démo et le contenu des données d'exemple ne sont pas documentés — observez et confirmez en local. Pour un premier essai, mieux vaut se limiter à l'observation, sans soumettre de vraies tâches, et n'aller plus loin une fois le comportement conforme aux attentes.

Deux rappels : d'une part, cette étape est une exécution locale qui ne touche aucune donnée d'identification cloud ; d'autre part, la lecture éventuelle d'autres données locales ou la connexion au réseau ne sont pas documentées — ne présumez pas d'une absence d'impact. Ces deux points n'empêchent pas la première tentative, mais pèsent sur votre décision de continuer.

Les autres modes d'accès officiels ne sont que des références secondaires, sans parité avec le chemin principal : les agents compatibles Agent Skills peuvent ajouter les skills de Tedix via npx skills add tedix-hq/tedix-plugins ; hors les clients nommés officiellement, les clients qui parlent MCP se connectent via le MCP gateway. La configuration requise par chacun de ces modes n'est pas donnée.

Cas d'usage

Cas un : sans cloud, comprendre son mécanisme de décision avec les données d'exemple. Scénario : vous voulez juger si le mode de travail « ne ramener que les décisions qui vous concernent » vous convient, sans fournir aucune donnée réelle. Démarche : terminer le clonage ci-dessus, puis exécuter bun run-local --demo. Résultat attendu : l'application démarre en local avec les données d'exemple, sans compte ni identifiants cloud à aucun moment ; les opérations proposées par la démo et les sorties obtenues ne sont pas listées — fait foi ce que vous verrez localement.

Cas deux : ajouter les skills Tedix à un agent que vous avez déjà. Scénario : votre agent du quotidien lit les Agent Skills et vous voulez lui donner la capacité de Tedix à traiter le travail. Démarche : exécuter npx skills add tedix-hq/tedix-plugins. Résultat attendu : officiellement, tout agent qui lit les Agent Skills peut ainsi ajouter les skills de Tedix ; les skills réellement fournis après l'ajout et leurs modes d'appel ne sont pas documentés et invérifiables jusqu'au détail exécutable — consultez-les après l'ajout et faites d'abord un essai avec une tâche sans importance.

Limites d'usage

• Lecture ou écriture : parmi les capacités exposées par le mode démo et le MCP gateway, ce qui relève de la lecture seule et ce qui écrit un état local ou distant n'est pas documenté ; clarifiez l'impact avant d'exécuter une action, et une écriture locale ne doit pas être traitée comme une simple lecture.
• Identifiants et données : pour le chemin local principal, la position officielle est claire — ni compte ni identifiants cloud ; l'étendue des fichiers locaux lus, l'éventuelle connexion au réseau et le traitement des données restent non confirmés.
• Écart avec le cloud : Tedix Cloud fonctionne sur invitation, sans inscription ouverte ; les capacités respectives de la démo locale et du service cloud, et l'ampleur de leur écart, ne sont pas documentées.
• Cohérence entre clients : l'égalité des fonctionnalités entre les clients nommés officiellement et ceux connectés via le MCP gateway n'est pas confirmée.
• Annulation et conservation : les preuves ne mentionnent ni procédure d'annulation, ni quotas d'usage, ni conservation des données ; l'absence de mention ne vaut pas absence de limite — avant les opérations critiques, référez-vous à la documentation officielle. L'étendue du contenu des données d'exemple est tout aussi peu documentée.