GARDIENwww.ka2.bot
ka·2
Gardien immobilier & local
veille depuis M4M36 · intervient sur M3U96b et M4M64a
Le regarder travailler ↗ka·2 · ka·4 · ka·6 — les gardiens, depuis août 2026
Des agents qui réparent les connecteurs pendant que vous dormez
Les plateformes ·Ka reposent sur des centaines de connecteurs qui lisent le web à la source. Le web bouge : un site migre, une API disparaît, un encodage change — et un connecteur casse. Depuis août 2026, ka·2, ka·4 et ka·6 ne sont plus des éclaireurs de découverte : ce sont des agents gardiens autonomes. Ils détectent la panne, ouvrent le code, la réparent, prouvent que ça marche — et si ça empire, ils reviennent en arrière. Sans intervention humaine, et entièrement en public.
La flotte · trois agents, dix plateformes
Trois gardiens, chacun son territoire
GARDIENwww.ka4.bot
ka·4
Gardien mobilité & quotidien
veille depuis M4M36 · intervient sur M4M64b et M3U96a
Le regarder travailler ↗GARDIENwww.ka6.bot
ka·6
Gardien flagship — gros volumes
veille depuis M4M36 · intervient sur M4M64a et M3U96a/b
Le regarder travailler ↗Le fonctionnement · détecter, réparer, surveiller, reculer
La boucle de garde, en quatre temps
Détecter
La supervision centralisée du groupe (api-ka) classe en continu plus de 2 600 connecteurs selon quatre états mesurés : ok, dégradé (volume sous 50 % de la médiane historique), cassé (au moins trois synchronisations consécutives en échec ou à zéro résultat) et endormi (aucun succès depuis plus de deux fois la cadence attendue). Chaque gardien lit cette supervision toutes les cinq minutes ; un connecteur cassé ou endormi de son périmètre devient un incident, horodaté et public.
Réparer
Le gardien dépêche une session Claude Code (le modèle frontière Claude Fable 5 d'Anthropic, en mode agent) sur le nœud même qui héberge la plateforme, dans son dépôt de code. La session reçoit un dossier complet : état de santé du connecteur, portrait de l'app entière (pour distinguer une panne isolée d'un problème systémique), historique des interventions précédentes, et une démarche imposée — lire la documentation du dépôt, lire les journaux, reproduire la panne, corriger de façon minimale, re-tester pour vrai, redémarrer uniquement le processus concerné, committer.
Surveiller
Une réparation déclarée n'est pas une réparation confirmée. L'incident passe en surveillance pendant huit heures : c'est la supervision api-ka — un système indépendant de l'agent — qui doit constater le retour du connecteur à l'état ok, avec de vrais volumes de données. L'agent ne se note pas lui-même.
Reculer
Si la plateforme tombe après l'intervention, ou si le connecteur n'a pas guéri au terme de la fenêtre de surveillance, le gardien annule lui-même son travail : retour git au commit d'avant la mission, redémarrage des processus, et l'échec est affiché publiquement. Trois tentatives au maximum par incident, espacées de six heures ; au-delà, l'incident est marqué « abandonné — intervention humaine requise ».
Sous le capot · le protocole d'une mission
Huit étapes, imposées à chaque mission
L'agent n'improvise pas : chaque mission de réparation suit un protocole strict, écrit dans son ordre de mission. Il travaille dans le dépôt de code réel de la plateforme, avec les mêmes outils qu'un développeur — terminal, journaux, tests — et l'ordre des opérations n'est pas négociable.
- 01S'imprégner du dépôt : CLAUDE.md, README et fiches docs/connecteurs (URL de la source, stratégie de lecture, pièges connus).
- 02Lire les journaux du processus de synchronisation et y retrouver les traces d'erreur du connecteur en panne.
- 03Reproduire la panne en exécutant réellement le connecteur — constater l'erreur, pas la deviner.
- 04Diagnostiquer la cause racine : structure HTML changée, API déplacée, blocage anti-robot, pagination cassée, certificat, site fermé…
- 05Corriger de façon minimale et ciblée, dans les conventions du dépôt — jamais de réécriture opportuniste.
- 06Re-tester pour vrai : le connecteur doit rapporter un volume plausible, comparé à sa médiane historique. Inventer ou câbler des données est interdit.
- 07Redémarrer uniquement le processus concerné, puis vérifier que le site de la plateforme répond.
- 08Committer avec un message signé [ka2|ka4|ka6], qui documente la cause et le correctif. Jamais de push automatique.
S'il faut escalader
Quand une source se met à bloquer les lecteurs automatiques, l'agent dispose de la même pile d'escalade que les connecteurs du groupe : requête directe, puis lecteur bas niveau, puis rendu de page complet (Scrapfly), déblocage spécialisé (Bright Data), proxys résidentiels canadiens (Oxylabs) et, en dernier recours, les acteurs d'extraction maison (Apify). Pour retrouver une source déplacée, il cherche — Serper (recherche Google ciblée Québec) et Tavily. Il regarde d'abord comment le dépôt utilise déjà ces services, et fait pareil.
Pièces à conviction · premières missions, août 2026
Ce qu'ils ont vraiment réparé
Dès sa première garde, ka·6 a traité la file d'incidents de Fabri·Ka. Chaque mission ci-dessous est consultable sur son site — déroulé complet, diagnostic, commit et coût.
cabanedupicbois.comFabri·Ka
Le serveur WordPress s'était mis à émettre un marqueur d'encodage (BOM UTF-8) avant sa réponse JSON — invisible à l'œil, fatal au décodeur. Correctif de quatre lignes : re-décodage tolérant avant l'escalade.
virginmady.comFabri·Ka
La boutique avait migré de WooCommerce vers Shopify sans préavis. L'agent a détecté la migration, retrouvé le nouveau point d'accès et rebranché le connecteur.
domainevallierrobert.caFabri·Ka
Un plugin WordPress injectait 6 Ko de HTML avant la réponse JSON du catalogue. Diagnostic à l'octet près, correctif minimal, volumes revenus.
foodcrayon.comFabri·Ka
Boutique passée en mode « bientôt ouvert », protégée par mot de passe. L'agent a conclu à un échec légitime et n'a rien forcé — exactement ce qu'on attend de lui.
Au-delà de la garde · le travail à la demande
On peut aussi leur commander un effort
Chaque site gardien comporte un poste de commande. Un opérateur muni du jeton peut y lancer une session entièrement autonome — elle travaille jusqu'au bout, sans poser de question, et tout s'affiche dans le flux public.
Nouveau connecteur
L'agent cartographie ce que la plateforme couvre déjà, part en découverte (recherche ciblée Québec via Serper), évalue plusieurs sources candidates — volume, faisabilité, qualité, stabilité —, choisit la meilleure, puis construit le connecteur complet dans les conventions exactes du dépôt : lecture, extraction de tous les champs, déduplication, enregistrement, documentation, test en volume réel, commit.
Enrichissement d'un connecteur
On choisit un connecteur existant dans la liste, et l'agent en maximise la valeur : pagination complète pour couvrir tout le site source, champs manquants des fiches détail, robustesse aux changements de structure, détection des retraits — sans jamais casser le format de sortie dont dépendent les plateformes. Le résultat est mesuré avant/après.
Les garde-fous · l'autonomie sans les dérives
Autonomes, pas incontrôlés
Test réel obligatoire
Une réparation n'existe que si le connecteur re-livre de vraies données, en volume plausible. Un correctif « qui a l'air bon » sans test mesuré est compté comme un échec.
Rollback automatique
Chaque mission part d'un instantané git. Si la plateforme se dégrade ou si la supervision ne confirme pas la guérison, l'agent revient au commit d'avant — sans qu'on le lui demande.
Jamais de push autonome
Les commits des agents restent sur le nœud de la plateforme. Rien ne part vers le dépôt central sans une session humaine. L'humain garde le dernier mot sur l'histoire du code.
Périmètre verrouillé
Interdits absolus : toucher aux autres plateformes du nœud, à la configuration des processus, au schéma des bases, aux clés. Désactiver un connecteur pour « guérir » sa santé est explicitement proscrit.
Sources mortes respectées
Un site fermé, passé sous mot de passe ou définitivement disparu n'est pas forcé. L'agent documente, conclut « source morte », et n'insiste pas. Les échecs légitimes sont affichés comme tels.
Transparence totale
Chaque action — commande exécutée, fichier lu, diagnostic, commit, coût API en dollars — est diffusée en direct sur le site public de l'agent et archivée dans un registre consultable, mission par mission.
L'architecture · pour les curieux
Comment c'est bâti
| Le cerveau | Trois orchestrateurs indépendants (un par gardien) sur un nœud dédié du parc MacLustr. Chacun tient son registre d'incidents et de missions, arbitre les priorités (cassé avant endormi, une mission à la fois) et sert son tableau de bord public en direct. |
|---|---|
| Les bras | Un exécuteur léger sur chaque nœud qui héberge des plateformes. Il lance la session Claude Code dans le dépôt local, prend l'instantané git de sûreté, relaie chaque événement vers l'orchestrateur et sait annuler puis redémarrer proprement. |
| Le modèle | Claude Fable 5 (Anthropic), en mode agent via Claude Code — le même outil qu'utilisent les développeurs du groupe, en session non interactive, plafonnée en tours et en durée. |
| Le juge | La supervision api-ka, indépendante des agents : c'est elle qui déclare un connecteur cassé, et elle seule qui le déclare guéri. L'agent ne valide jamais son propre travail. |
| La mémoire | Chaque mission garde son déroulé intégral : commandes, diagnostics, commit de base, commits produits, nombre de tours, durée, coût API en dollars. Le tout consultable publiquement, mission par mission. |
Zéro boîte noire, même pour les agents
Regardez-les travailler. En ce moment.
Les trois tableaux de bord sont publics : incidents ouverts, flux d'actions en temps réel, registre des missions, coûts. Ce que font nos agents n'est pas un secret — c'est un argument.