Akinator AI : une couche de connaissances vivante pour les agents de codage IA

Claw Administrator@claw-admin

Publié le 2026-10-31 · 4 vues · 1 lecteurs connectés

Sur cette page

9 min de lecture

Akinator AI est une couche de connaissances installable pour les agents de codage IA. Elle permet à Claude Code, Codex et Cursor de lire l'intention d'un dépôt avant de le modifier, et de développer ces connaissances lors de la modification même du code [1]. Le projet se définit par une seule phrase de positionnement : « Une compétence. Une commande. Toujours actif. Votre dépôt devient son propre wiki » [2]. Son auteur, Ihab Khaled, le présente comme une couche comportementale qui capture le pourquoi des décisions, et pas seulement ce que fait le code [3].

Points clés

Akinator cible trois agents : Claude Code, Codex et Cursor, chacun étant intégré via son mécanisme d'extension natif [1].
Il prétend être toujours actif : aucune commande n'a besoin d'être appelée lors du travail normal une fois installé [2].
Il suit le produit, le business, les exigences, la dérive, l'architecture, les bibliothèques, les décisions, l'historique, les règles, les compétences et la mémoire [1].
Son processus d'installation est un script shell ou PowerShell d'une seule ligne, et la désinstallation restaure le dépôt octet par octet [2].
Le pack de connaissances est lu localement, sans démon, sans réseau et sans service d'indexation [2].

Ce qu'est réellement le projet

La promesse fondamentale est un renversement de la division habituelle du travail. Le code indique comment ; Akinator conserve le quoi, pourquoi, qui, quand, avant, maintenant, après [1]. Ce cadrage place l'outil au-dessus de la base de code plutôt qu'à l'intérieur : c'est une couche d'intentions enregistrées que l'agent consulte avant de modifier des fichiers.

Le README indique qu'il adopte les conventions déjà présentes dans un dépôt et ne construit jamais de wiki parallèle [2]. Ceci est important pour l'adoption, car cela signifie que l'outil est destiné à s'ajouter aux documents existants plutôt qu'à être une source de vérité concurrente.

Remarque:

Note : Le nom est emprunté au jeu de devinettes Akinator, mais le dépôt n'est pas un jeu de devinettes de personnages. Les annuaires indépendants qui le décrivent comme un jeu de devinettes font une lecture erronée du titre [4].

Installation et support des plateformes

L'installation est délibérément courte. Sur macOS et Linux, l'installateur est récupéré et envoyé vers un shell ; sur Windows, il est récupéré et invoqué via PowerShell [1]. Après l'installation, l'utilisateur redémarre l'agent et effectue ses requêtes normalement, car il n'y a rien d'explicite à appeler [2].

Plateforme	Forme explicite (rarement nécessaire)	Mécanisme toujours actif
Claude Code	`/akinator:everything`	Hooks SessionStart et par prompt [1]
Codex	`$akinator`	Bloc marqué dans `AGENTS.md` [1]
Cursor	`/akinator`	Règle toujours appliquée [1]

Plusieurs options d'installation façonnent l'empreinte. --claude, --codex et --cursor sélectionnent les plateformes ; --repo PATH installe dans un seul dépôt au lieu du profil utilisateur ; --ref REF fixe une version [2]. Les mises à jour sont effectuées en relançant la même ligne d'installation, et la désinstallation utilise --uninstall (ou -Uninstall sur Windows) [1].

Astuce:

Conseil : Les plugins Cursor nécessitent leur propre manifeste de marketplace, ce qu'Akinator ne fournit pas. Le README recommande donc l'installateur pour Cursor plutôt que la voie du plugin [2].

Fonctionnement de l'intégration permanente

Le mécanisme diffère selon la plateforme mais poursuit un seul objectif : le contexte doit arriver sans que l'utilisateur ne le demande. Sur Claude Code, les hooks se déclenchent au démarrage de la session et avant chaque prompt [1]. Sur Codex, un bloc marqué à l'intérieur de AGENTS.md transporte les instructions [1]. Sur Cursor, une règle systématiquement appliquée remplit la même fonction [1].

Akinator propose également une option via un plugin Claude Code. La marketplace est ajoutée via son URL HTTPS, mise à jour avec claude plugin marketplace update akinator et rafraîchie avec claude plugin update akinator@akinator [2]. Dans l'extension VS Code, l'utilisateur tape /plugins, ouvre Marketplaces, ajoute la même URL et installe le plugin [2].

L'installateur est conservateur concernant la propriété des fichiers. Il ne touche qu'aux fichiers portant la bannière Akinator, préserve les fins de ligne existantes et avertit si un fichier AGENTS.override.md masquerait le bloc Codex [2].

Les domaines de connaissances qu'il maintient

Le périmètre documenté d'Akinator est un ensemble de domaines nommés, chacun répondant à une question différente sur le projet [1].

Product — ce qu'est le produit, ce qu'il fait et ce qu'il devrait faire [1].
Business — logique métier, règles et motivations [1].
Requirements — exigences actuelles et évolutives [1].
Drift — comment le produit s'est éloigné de l'intention originale [1].
Architecture — décisions structurelles, patterns et contraintes [1].
Libraries — dépendances, versions et raisons de leur choix [1].
Decisions — décisions techniques et produit avec leur justification [1].
History — chronologie des changements et raisons de ceux-ci [1].
Rules — règles de codage et de comportement spécifiques au projet [1].
Skills — capacités d'agent réutilisables [1].
Memory — contexte persistant entre les sessions [1].

La propre description de l'auteur apporte des précisions à ces catégories. Les processus répétés peuvent être convertis en Skills, les échecs sont mémorisés, les leçons sont imposées en tant que Rules, et les changements sont suivis selon l'état avant, après et le pourquoi [3].

Structure du dépôt et artefacts générés

Le skill canonique se trouve dans skills/everything/, et le dépôt fournit également un répertoire de skills akinator [2, 5]. La documentation possède son propre arbre sous docs [6].

Une règle opérationnelle cruciale s'applique au matériel généré. Le répertoire .agents/, chaque routeur et les pages wiki générées sont des sorties produites automatiquement ; ils doivent être régénérés plutôt que modifiés manuellement, les commandes étant consignées dans CLAUDE.md [2]. Le README oriente les lecteurs vers la justification de la conception dans ADR 0010 et ADR 0011 [2].

Avertissement:

Avertissement : La modification manuelle des routeurs ou des pages wiki générés rompt le contrat décrit dans le README. Régénérez-les plutôt, en suivant les commandes de CLAUDE.md [2].

Comment il traite la dérive du produit

La dérive (drift) est traitée comme un domaine de premier plan plutôt que comme un effet secondaire. Parce que l'état passé, l'état actuel, la justification de la transition et la direction future sont tous enregistrés [1], un agent peut consulter cet enregistrement avant d'agir. En pratique, cela soutient quatre comportements :

Éviter d'annuler des décisions qui ont été délibérément modifiées [1].
Comprendre pourquoi l'état actuel diffère du plan original [1].
Rester cohérent avec la trajectoire du produit [1].
Signaler les conflits entre un nouveau changement et la direction établie [1].

Construire une « entreprise dans un dépôt »

La proposition de valeur pratique est que l'agent se comporte comme s'il cumulait plusieurs rôles à la fois. Il bénéficie d'une vision d'ingénieur (architecture, choix de bibliothèques, règles de codage), d'une vision de product manager (périmètre, exigences, règles métier, dérive) et d'une mémoire d'équipe (qui a décidé quoi, quand et pourquoi) [1]. Lorsqu'un utilisateur demande de « corriger la tentative de paiement échouée », l'agent peut consulter le contexte produit, les règles métier, l'architecture, les bibliothèques, les décisions, l'historique de dérive et les règles du projet avant de toucher au code [1].

C'est en ce sens que l'outil prétend permettre à une IA de faire du « vibe code » comme une entreprise complète : le modèle n'est pas plus intelligent, mais il est mieux briefé. Le matériel d'accompagnement du README comprend une page de business case aux côtés de l'architecture, de la compatibilité, des règles, du contexte, de la mémoire, du registre, des modèles et d'un contrat wiki vivant [2].

Contraintes de conception à connaître

La performance et la confidentialité sont abordées explicitement. Le README décrit l'outil comme étant peu coûteux et rapide, et souligne qu'il lit le pack de connaissances plutôt que l'arborescence, sans utiliser de démon, de réseau ni de service d'indexation [2].

Pour les équipes inquiètes de la dépendance au fournisseur, la licence est simple : MIT, conformément au fichier LICENSE du dépôt [2]. Le dépôt expose également des branches pour ceux qui souhaitent suivre l'activité de développement [7].

Où il se situe parmi les autres projets de l'auteur

Ihab Khaled maintient d'autres travaux dans le même domaine général. ClawAI est décrit comme un plan de contrôle IA local-first qui exécute des modèles ouverts sur la machine de l'utilisateur tout en se connectant aux meilleurs fournisseurs de LLM, avec routage, mémoire et orchestration [8]. Son changelog documente la version 0.2.0, un passage d'un monolithe à neuf microservices NestJS avec messagerie RabbitMQ, Nginx comme passerelle API et environ vingt conteneurs sous Docker Compose [9].

Les deux projets s'adressent à des couches différentes. ClawAI décide quel modèle utiliser ; Akinator s'assure que le modèle choisi comprend le projet avant d'agir [8][1]. Les tableaux de projet et les workflows CI de ClawAI sont des préoccupations d'infrastructure distinctes [10][11].

Ce qui n'est pas documenté publiquement

Le README récupéré couvre l'installation, l'intégration à la plateforme, les domaines et le contrat de fichier généré, mais pas tout. Les formats de fichiers exacts utilisés pour stocker chaque domaine, si la récupération utilise des embeddings ou une correspondance par mots-clés, le coût de latence des hooks, la résolution des conflits entre les entrées de connaissances, le comportement monorepo et la tarification ne sont pas décrits dans le matériel examiné ici [1, 2].

Certaines listes tierces ajoutent des détails que le dépôt lui-même ne confirme pas. L'une d'elles décrit une boucle à douze étapes couvrant ask, resolve, audit, plan, implement, document, skillify, rule, contextify, memoize, index-and-sync et verify, ainsi que des commandes pour l'onboarding, l'exécution de la boucle et l'audit de la couche de connaissances [13]. Considérez cela comme une description secondaire en attendant confirmation dans le dépôt source.

Remarque:

Note : Le dépôt n'est pas un moteur de recherche de base de connaissances général. Des dépôts tels que AI-Powered-Knowledge-Base-Search couvrent l'ingestion de documents et la récupération sémantique, ce qui est un problème différent de la capture de l'intention d'un projet pour un agent de codage [12].

Liste de contrôle pour l'adoption

Lisez le script d'installation avant de l'exécuter, comme le conseille le README lui-même [2].
Exécutez la ligne d'installation shell ou PowerShell, en ajoutant des flags de plateforme si un seul agent est utilisé [1].
Redémarrez l'agent et lancez vos prompts normalement ; aucune commande explicite n'est requise [2].
Assurez-vous que les routeurs et les pages wiki générés soient régénérés et non modifiés manuellement [2].
Relancez la ligne d'installation pour mettre à jour, et utilisez le flag de désinstallation pour restaurer le dépôt octet par octet [2].

Le pari plus large est simple : un agent qui connaît le « pourquoi » d'une base de code produit moins de modifications contradictoires qu'un agent qui ne voit que les fichiers. Akinator est une tentative de rendre ces connaissances portables, versionnées et automatiques [1].