Cairn : un moteur de recherche dans un espace d'états, validé sur le pentest

Le problème : un chemin inconnu entre une origine et un objectif connus

Le README pose la thèse du projet en une phrase : le pentest est une recherche dirigée dans un espace d'états quasi infini. L'origine est connue (une IP, un système), l'objectif est défini (un shell, un flag), le chemin ne l'est pas. Cairn est présenté comme un moteur pour cette classe de problèmes, et le pentest comme le premier domaine sur lequel il a été validé. La formulation compte : le projet ne se présente pas comme un outil de sécurité à qui on ajouterait des capacités générales, mais comme un moteur général dont le pentest est un cas d'usage éprouvé. Le public visé est donc double. D'un côté des équipes offensives qui veulent automatiser une exploration sans écrire de playbook. De l'autre des développeurs qui ont un problème en forme d'origine vers objectif et cherchent un moteur de recherche, pas un scanner. Le README cite la recherche de vulnérabilités, la preuve mathématique et les challenges CTF comme relevant de la même structure. Cette généralité est une revendication, pas une démonstration : le matériel fourni ne documente de validation que sur le pentest.

Trois primitives et un tableau noir : le mécanisme réel

L'architecture repose sur ce que le README appelle une Blackboard Architecture, avec un graphe explicite de faits et d'intentions. Trois primitives suffisent. Un Fact est une constatation objective et confirmée, écrite sur le tableau. Un Intent est une direction d'exploration déclarée mais pas encore exécutée. Un Hint est un jugement humain injecté à tout moment, que les agents absorbent à leur prochaine lecture. Le graphe grandit de origin vers goal : chaque Fact est un point d'appui, chaque Intent un pas dans l'inconnu. Les agents, appelés Agent Workers, tournent en boucle OODA (Observer, Orienter, Décider, Agir) et écrivent leurs résultats sous forme de nouveaux Facts. Ils n'ont pas de rôle fixe. Les tâches sont générées à l'exécution à partir de l'état courant du graphe, pas à partir de fiches de poste. La coordination passe exclusivement par le tableau partagé, ce que le README nomme Stigmergy : aucune communication directe entre agents, donc aucun silo d'information. Trois types de tâches existent, toutes exécutées par le même Worker. Bootstrap tente de résoudre le problème directement au démarrage et produit un Fact, éventuellement un Complete. Reason lit le graphe entier, vérifie si l'objectif est atteint et décide quoi explorer, produisant un Complete, de nouveaux Intents, ou rien. Explore réclame un Intent, l'exécute et rapporte un Fact unique.

Serveur, dispatcher, conteneurs : qui écrit quoi

Le schéma du README sépare trois responsabilités. Le Cairn Server maintient uniquement la cohérence du graphe : Facts, Intents, Hints, exposés par une API de lecture et d'écriture. Le Cairn Dispatcher lit le graphe, planifie les tâches, crée et détruit les conteneurs de workers, et se présente comme le seul écrivain du protocole. Chaque projet obtient son propre Worker Container, dans lequel plusieurs Agent Workers tournent en parallèle. Ces workers reçoivent un prompt et renvoient une sortie structurée, rien de plus. Cette séparation a une conséquence pratique : le serveur ne connaît pas le domaine, et le dispatcher ne connaît pas la logique métier. Ajouter un domaine revient à changer ce qu'on met dans les prompts et la façon dont les Facts sont interprétés, pas à modifier le serveur. Les backends de worker supportés sont cités nommément : Claude Code, Codex et Pi. Le README indique aussi que les workers peuvent tourner directement sur l'hôte du dispatcher au lieu de conteneurs par projet, en local mode, sans Docker. C'est une option de déploiement documentée, pas un mode dégradé décrit comme tel.

Mise en route : images, fichier de configuration, compose

Les prérequis annoncés sont macOS ou Linux, Python 3.12 ou plus récent, et Docker pour l'exécution en conteneurs seulement, le mode local s'en passant. Deux commandes de récupération d'images sont données. La première est obligatoire dans les deux méthodes d'installation, car elle fournit l'image des workers : docker pull --platform=linux/amd64 ghcr.io/oritera/cairn-worker-container:latest. La seconde ne concerne que Docker Compose, qui reconstruit Cairn sur une base uv : docker pull ghcr.io/astral-sh/uv:python3.13-trixie. Entre les deux, il faut créer la configuration locale du dispatcher et y renseigner les points de terminaison LLM et les clés d'API, avec cp dispatch.example.yaml dispatch.yaml. Le lancement se fait ensuite par docker compose up --build, ce qui démarre cairn-server sur le port 8000, puis cairn-dispatcher une fois le health check du serveur passé. Le dispatcher monte dispatch.yaml depuis la racine du projet. Le README renvoie à une section Local mode pour l'exécution sans Docker, mais le texte fourni s'interrompt avant d'en détailler les commandes. C'est un manque réel du matériel dont je dispose, pas une omission du projet.

Ce que le tableau noir coûte en fiabilité

Le choix de supprimer les rôles fixes a un revers que le README n'aborde pas. Si les tâches naissent de l'état du graphe, la qualité de l'exploration dépend entièrement de la qualité des Facts déjà écrits et des Intents déjà déclarés. Un Fact erroné n'est pas corrigé par une étape dédiée : il devient un point d'appui pour la suite, et le graphe grandit autour de lui. La seule soupape visible dans le matériel est le Hint, c'est-à-dire une intervention humaine. Cela déplace la question de la supervision : le système est autonome dans son exécution, pas dans son contrôle. Deuxième contrainte, le déterminisme. Les tâches Reason et Explore sont confiées à des agents LLM, avec un backend parmi Claude Code, Codex ou Pi. Deux exécutions sur le même graphe de départ ne produiront pas le même parcours. Pour un audit où l'on doit rejouer une finding, c'est un obstacle sérieux. Troisième point, le périmètre. Le README annonce un moteur général, mais la seule validation décrite porte sur le pentest, lors de la Tencent Cloud Hackathon. Pour un problème hors sécurité, vous êtes sur un moteur dont la généralité est argumentée et non éprouvée. Ce n'est pas disqualifiant, c'est une hypothèse à tester soi-même.

Face à un agent à rôles fixes

L'alternative la plus directe est l'agent outillé à rôles prédéfinis, du type orchestrateur plus sous-agents spécialisés (reconnaissance, exploitation, post-exploitation), chacun avec sa liste d'outils. La différence n'est pas cosmétique. Dans ce modèle, le découpage du travail est décidé à l'écriture du prompt système, et le chemin d'exécution suit une séquence prévue. Cairn déplace cette décision à l'exécution : le dispatcher lit le graphe et génère la tâche suivante, sans savoir à l'avance si elle ressemblera à de la reconnaissance ou à de l'exploitation. Le README insiste sur l'absence de rôles prédéfinis et sur le fait que les workers n'ont pas de description de poste. La contrepartie est nette. Un agent à rôles fixes est plus facile à auditer, à journaliser et à limiter en portée, parce que chaque rôle a un périmètre connu. Cairn échange cette lisibilité contre la capacité à explorer des chemins que l'auteur du workflow n'avait pas anticipés. Si votre besoin est de reproduire une procédure stable, l'agent à rôles fixes est le bon outil. Si votre besoin est de trouver un chemin que vous ne savez pas décrire, le tableau noir a un avantage structurel.

Maintenance, versionnement et licence AGPL-3.0

Le dépôt n'est pas archivé et le dernier push date du 7 septembre 2026. Trois versions sont listées : v0.1.0 le 3 mai 2026, v0.2.0 le 5 mai, v0.2.1 le 10 mai. Deux releases en une semaine, puis quatre mois sans nouvelle version publiée alors que le dépôt continue de recevoir des commits. Ce rythme indique un projet en développement actif mais dont les étiquettes de version ne suivent pas le travail réel, ce qui complique le choix d'une révision stable pour un déploiement. Le coût de mise à jour ne se limite pas au code : les images sont tirées avec le tag latest (ghcr.io/oritera/cairn-worker-container:latest), donc rien ne garantit qu'un déploiement reconstruit demain utilise la même base qu'aujourd'hui. Épingler un digest est la seule parade, et le README ne la mentionne pas. Sur la licence, Cairn est publié sous AGPL-3.0. La conséquence pratique à vérifier avant toute intégration : si vous modifiez le logiciel et le mettez à disposition d'utilisateurs sur un réseau, l'AGPL impose de leur fournir le code source correspondant. Un usage strictement interne ne déclenche pas cette obligation de la même manière, mais je ne donne pas d'avis juridique : faites relire le texte de la licence par qui de droit. Le point à retenir est que ce n'est pas une licence permissive, et que cela se décide avant l'installation, pas après.

Conclusion éditoriale

Cairn convient aux équipes qui savent écrire un dispatch.yaml et accepter un raisonnement non déterministe sur un graphe de faits. Il ne convient pas à qui veut un scanner reproductible ou un agent à rôles fixes. Avant d'adopter, vérifiez deux points dans le dépôt : la licence AGPL-3.0 et ses conséquences si vous exposez le serveur en réseau, puis la liste réelle des backends acceptés par le dispatcher, car le README n'en cite que trois.

Sources officielles

1. Issues
2. License: AGPL-3.0
3. oritera/Cairn on GitHub
4. README
5. Releases