Akinator AI — analyse détaillée du dépôt ihabkhaled/akinator-ai

Claw Administrator@claw-admin

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

Sur cette page

10 min de lecture

Akinator est une couche de connaissances « vivante » du dépôt pour les agents de codage IA (Claude Code, Codex, Cursor), qui force l'agent à lire l'intention du projet avant d'apporter des modifications et à enrichir les connaissances dans le même changement que le code [1].
Slogan du projet : « Un skill. Une commande. Toujours activé. Votre dépôt devient son propre wiki » ; le code répond à la question « comment », tandis qu'Akinator conserve le « quoi, pourquoi, qui, quand, avant, maintenant, après » [2].
L'installation prend environ 30 secondes avec une seule commande, et après le redémarrage de l'agent, rien n'a besoin d'être appelé manuellement — le contexte est fourni automatiquement via des hooks [1].

Qu'est-ce que c'est

Akinator AI est un outil développé par Ihab Khaled, qui transforme un dépôt en un wiki auto-documenté pour les agents IA. Selon la description de l'auteur, il s'agit d'une « couche de connaissances vivante » accompagnant le codage assisté par IA : le système enregistre et révèle les décisions produit, les règles métier, le contexte historique, les erreurs et l'évolution de l'architecture au fur et à mesure que le code change [7].

Malgré son nom, qui fait référence au jeu de devinettes Akinator, ce projet ne devine pas de personnages : il garantit que l'IA connaît le contexte de votre projet avant de modifier des fichiers [1]. Des catalogues externes le décrivent comme un « concept de plugin Akinator pour la gestion des connaissances de la base de code », soulignant l'accent mis sur les connaissances et non sur le jeu [8].

Remarque:

Note : cette analyse est basée sur le README du dépôt publiquement accessible et les documents connexes ; les fichiers internes (dossiers docs, skills, etc.) n'ont pas été extraits dans le cadre de cette étude [3].

Quel problème Akinator résout

Lors du « vibe-coding » (développement via des prompts), l'agent IA ne connaît par défaut ni la logique métier, ni les raisons des décisions passées, ni les exigences actuelles, ni les contraintes architecturales. En conséquence, l'agent perd le contexte entre les sessions, répète des erreurs et peut contredire des décisions prises précédemment [2].

Akinator remédie à cela en maintenant un wiki vivant à l'intérieur même du dépôt, que l'agent lit automatiquement : connaissances sur le produit, le business, les exigences, le drift, l'architecture, les bibliothèques, les décisions, l'historique, les règles, les skills et la mémoire [1]. Comme le formule l'auteur, l'agent doit comprendre non seulement le code, mais aussi le produit et son histoire [7].

Ce qui est précisément suivi (domaines de connaissances)

Selon le README, Akinator gère les connaissances dans onze domaines simultanément avec le code [2].

Domaine	Ce qui est fixé
Product (produit)	Ce que le produit représente, ce qu'il fait et ce qu'il doit faire
Business (business)	Logique métier, règles et motivation
Requirements (exigences)	Exigences actuelles et évolutives
Drift (dérive)	Comment le produit a dévié de l'intention initiale
Architecture (architecture)	Décisions structurelles, patterns, contraintes
Libraries (bibliothèques)	Dépendances, versions et raisons du choix
Decisions (décisions)	Décisions techniques et produit avec justification
History (historique)	Chronologie des changements et leurs raisons
Rules (règles)	Règles de projet pour le code et le comportement
Skills (compétences)	Capacités réutilisables de l'agent
Memory (mémoire)	Contexte persistant entre les sessions

L'auteur décrit davantage la mécanique ainsi : les processus répétitifs se transforment en Skills, les erreurs sont mémorisées, les leçons tirées sont fixées comme Rules, et les changements sont suivis selon le format « avant/après/pourquoi » [7].

Comment cela fonctionne techniquement

Installation

L'installation s'effectue via une seule commande et prend, selon l'auteur, environ 30 secondes [1] :

curl -fsSL https://raw.githubusercontent.com/ihabkhaled/akinator-ai/main/install.sh | sh

Pour Windows (PowerShell 5.1+), une commande similaire irm ... | iex est utilisée, après quoi il faut redémarrer l'agent — et c'est tout, rien n'a besoin d'être appelé, les prompts s'écrivent comme d'habitude [2].

Intégration avec les plateformes

Plateforme	Forme explicite (rarement nécessaire)	Fonctionnement permanent via
Claude Code	`/akinator:everything`	Hooks SessionStart et à chaque prompt
Codex	`$akinator`	Bloc marqué dans `AGENTS.md`
Cursor	`/akinator`	Règle toujours appliquée

Le mécanisme clé réside dans les hooks automatiques : le hook SessionStart charge les connaissances au début de la session, tandis que le hook à chaque prompt réinjecte le contexte pertinent avant chaque requête de l'utilisateur [1]. La seule commande optionnelle pour forcer le contexte complet est /akinator:everything [7].

Mise à jour et suppression

Pour la mise à jour — il suffit de répéter la même commande d'installation.
Pour la suppression — ajouter le flag --uninstall (sous Windows -Uninstall) ; le dépôt est restauré octet par octet.
Les options --claude, --codex, --cursor permettent de choisir les plateformes, et --repo PATH — un chemin de dépôt non standard [2].

Astuce:

Conseil : grâce à la désinstallation octet par octet, l'outil est non invasif — on peut l'essayer sans risque de modifier irréversiblement le dépôt [2].

Comment Akinator guide l'IA vers un meilleur codage

Sans Akinator, l'agent reçoit un prompt tel que « ajoute un rate limiting aux exports » et édite les fichiers à l'aveugle, sans savoir pourquoi les exports existent et quels patterns sont adoptés dans le projet. Avec Akinator, l'agent lit d'abord le contexte produit, les règles métier, les décisions architecturales, l'historique du drift et les bibliothèques choisies — et ce n'est qu'ensuite qu'il agit [1].

C'est ainsi qu'est mis en œuvre le principe de « compréhension de l'intention avant l'action » : les connaissances sont mises à jour dans le même changement que le code, le contexte ne devient donc pas obsolète [2]. Selon l'auteur, cela maintient la cohérence entre le code généré par l'IA et la logique produit réelle, en particulier à mesure que la base de code s'accroît [7].

Drift produit, attentes et changements de logique métier

Le drift produit est l'écart entre l'intention initiale et ce que le produit est devenu avec le temps. Akinator suit le drift comme un domaine de connaissances à part entière : l'état passé, l'état actuel, la justification de la transition et la direction future sont enregistrés [1].

En cas de modification des exigences ou des règles métier, une « piste d'audit des intentions » est créée : le changement lui-même entre dans l'historique, sa justification dans les décisions, l'écart par rapport à l'ancienne logique dans le drift, et la nouvelle logique dans les domaines métier et règles, et tout cela est lu automatiquement par l'agent avant l'action suivante [2]. La description externe du projet mentionne également un cycle structuré de traitement de chaque interaction avec la base de code, avec la fixation de la logique métier, de l'intention produit et des procédures opérationnelles directement dans le dépôt [8].

Grâce à cela, l'agent peut :

ne pas annuler des décisions qui ont été modifiées intentionnellement ;
comprendre pourquoi l'état actuel diffère des plans initiaux ;
maintenir la cohérence avec la trajectoire du produit ;
remarquer les conflits entre un nouveau changement et la direction établie.

Support du contexte IA

Le contexte habituel du codage IA est éphémère et disparaît à la fin de la session. Akinator crée un contexte permanent à trois niveaux : le niveau de session (hooks SessionStart et sur le prompt), le niveau du dépôt (les connaissances se trouvent dans des fichiers à l'intérieur du dépôt et sont versionnées avec le code) et le niveau inter-session (domaines Memory, History et Decisions) [1].

L'effet pratique : une nouvelle session commence avec une connaissance complète du projet, et non à partir d'une page blanche. Dans l'exemple du README, il suffit de dire à l'agent « répare l'échec de la répétition du paiement » ou « pourquoi ce service utilise-t-il Redis ? » — et il répond en s'appuyant sur les connaissances factuelles du dépôt [2].

Le « vibe-coding » comme une entreprise entière

Akinator élève le vibe-coding du niveau de l'édition de fichiers au niveau d'un codage « informé de l'entreprise », en donnant à l'agent le contexte qu'auraient simultanément un ingénieur, un product manager et un architecte [1] :

Connaissances d'ingénierie : patterns architecturaux, raisons du choix des bibliothèques, règles de codage.
Connaissances du product manager : périmètre et identité du produit, exigences actuelles, règles métier, historique de la dérive.
Connaissances de l'architecte : décisions structurelles, historique des contraintes, raisons du choix ou du rejet de patterns.
Mémoire de l'équipe : qui a décidé quoi et quand, historique des changements, compétences réutilisables.

Par conséquent, l'agent « code comme s'il travaillait dans votre équipe depuis le premier jour » [2].

Scénarios d'utilisation pratiques

Onboarding du développeur : le prompt « explique comment fonctionne notre système d'exportation » — la réponse s'appuie sur le contexte réel du projet, et non sur des suppositions générales.
Ajout d'une fonctionnalité : « ajoute un rate limiting aux exportations » — l'implémentation prend en compte la logique existante, les règles et les contraintes d'architecture.
Correction de bug : « répare l'échec de la répétition du paiement » — la correction ne casse pas le comportement intentionnel documenté dans les décisions et l'historique.
Question d'architecture : « pourquoi ce service utilise-t-il Redis ? » — l'agent explique la justification factuelle.
Continuité entre les sessions : une migration commencée dans une session se poursuit dans la suivante sans perte de contexte [2].

Résumé des avantages

Avantage	Mécanisme
Élimination du « démarrage à froid »	Le hook SessionStart charge tout le contexte
Prévention des changements contradictoires	L'agent lit les décisions et la dérive avant d'agir
Préservation des connaissances institutionnelles	Les domaines History et Memory sont persistants
Alignement du code avec l'intention métier	Les domaines Business et Product guident les changements
Moins d'« hallucinations » sur le projet	L'agent lit les connaissances factuelles du dépôt
Multiplateforme	Claude Code, Codex, Cursor
Non-invasivité	La désinstallation restaure le dépôt octet par octet
Zéro modification du flux de travail	Prompts habituels, les hooks font le reste
Connaissances versionnées	Vivent à l'intérieur du dépôt et croissent avec le code [1]

Comment cela s'intègre-t-il avec les autres projets d'Ihab Khaled

Ihab Khaled développe également ClawAI — une plateforme d'orchestration d'IA locale et open-source qui exécute des modèles ouverts sur la machine de l'utilisateur et coordonne les principaux fournisseurs de LLM avec un routage des prompts et un espace de travail sécurisé pour le chat, la mémoire, le contexte et les connecteurs [5]. Le projet évolue : dans la version 0.2.0, il est passé d'un monolithe à neuf microservices NestJS indépendants avec des instances PostgreSQL distinctes, RabbitMQ pour l'échange asynchrone et Nginx en tant que passerelle API, tandis que les services Memory et File ont ajouté une mémoire persistante, des embeddings et l'indexation de fichiers [6].

Les projets se complètent : ClawAI détermine quel modèle est orchestré et comment, tandis qu'Akinator garantit que le modèle comprenne votre projet avant de commencer à agir [1]. Dans l'écosystème ChatGPT, l'auteur propose également les plugins Akinator et AI Psychiatry [9].

Avertissement:

Avertissement : certaines descriptions externes d'Akinator sont de nature conceptuelle ou catalytique et peuvent ne pas refléter l'état actuel exact du code ; la seule source faisant autorité est le README et les fichiers du dépôt lui-même [8].

Ce qui n'est pas documenté publiquement

À l'issue de la recherche, les détails suivants ne sont pas divulgués dans le README public [2] :

la structure interne des fichiers des domaines de connaissances (il existe des dossiers docs et skills/akinator, mais leur contenu n'a pas été extrait) [4] ;
le format exact de stockage des connaissances (JSON, Markdown ou YAML) ;
la mise à jour automatique ou manuelle des connaissances et la méthode d'extraction du contexte ;
l'impact des hooks sur la latence des prompts, la prise en charge des monorepos et la collaboration d'équipe ;
le licensing, les tarifs et l'intégration avec CI/CD.

Pour répondre à ces questions, l'étude des fichiers du dépôt au-delà du README sera nécessaire [3].

Vue d'ensemble

Akinator AI incarne le passage du paradigme « l'IA comme générateur de code » à « l'IA comme membre de l'équipe avec mémoire ». En intégrant les connaissances du projet directement dans le dépôt et en les fournissant automatiquement aux agents, l'outil lutte contre une limitation fondamentale du codage par LLM : la perte de contexte [1].

C'est particulièrement précieux pour les domaines soumis à une réglementation stricte et à une logique métier complexe : comprendre pourquoi le système fonctionne de telle manière avant d'apporter des modifications réduit les risques de non-conformité, les problèmes d'intégrité des données et les erreurs de régression [7].