Skip to content

Rendu: RecognAIze #46

Open
Open

Description

@Nanaki

Édition

LAIVEL UP (28 au 31 août 2026)

Pseudo Discord

sebastien_nicolas

Lien de ton dépôt

https://github.com/Nanaki/recognAIze

Comment on lance ton outil

Build

npm ci --ignore-scripts
npm run build

Utilisation CLI

node dist/cli.js analyze fixtures/profiles/bohort # node dist/cli.js analyze

Output dans /recognaize-cli-out -> ouverture du report.html dans un browser

Utilisation SKILL

claude # Dans le projet
/recognaize-agentic fixtures/profiles/arthur # /recognaize-agentic

Output dans /recognaize-out-final -> ouverture du report.html dans un browser

Lien de ta vidéo ou de ton GIF

https://fromsmash.com/recognAIze

Ton approche en trois lignes

  • Une CLI d'analyse statique
  • Un skill qui s'appuie sur la même méthodologie, les mêmes données en entrée, ainsi que le résultat de la CLI et qui confronte les résultats. (On fait tout pour le garder le plus déterministe possible)
  • 5 axes (les 4 du sujet + ownership)
  • Pour modéliser les critères qui permettent d'atteindre un niveau (appelé "rang"), j'ai utilisé ces données comme référentiel :
    manisfest AIDD + courses AIDD + trainings AIDD + sujet
  • De ces données, j'ai pu brainstormer des signaux ordonnés pour chaque axe (Ex: O1, 02, etc pour l'axe Ownership). Le découpage a été fait en fonction de ce qui est attendu pour chaque rang
  • Etablissement d'une corrélation entre le niveau de signal attendu pour chaque axe, afin d'atteindre un rang
  • Classer les sources de données d'un profil par ordre d'importance
  • Gestion de l'incertitude. Seule la certitude permet de conclure à un rang
  • Historisation des runs (permet de comparer les diffs entre plusieurs run, lorsqu'on modifiera le paramétrage des signaux afin de tester ce qui fonctionne le mieux

Avant d'envoyer

  • Aucune clé d'API n'est présente dans le code ni dans l'historique Git
  • Mon dépôt est public et sous licence MIT

Activity

  1. blafourcade commented on Sep 4, 2026

    @blafourcade
    Contributor

    Merci pour ce rendu. Voici ce qu'on en a retenu, après l'avoir installé, lancé
    sur les huit profils dans un conteneur isolé, et lu de bout en bout.

    Ce qu'on a regardé

    • Vidéo. Ton lien fromsmash. Quinze minutes, chaque partie détaillée. Le dépôt contient aussi un scénario court de deux minutes, marqué non enregistré.
    • Dépôt. 405 fichiers, licence MIT, un README qui donne l'usage, les quatre codes de retour, les options, les 48 contrôles et ce que tu ne fais pas.
    • Documentation. Ta note de méthode, ton référentiel expliqué, un guide pour comprendre le verdict, tes décisions numérotées, l'installation, les limites connues et sept fiches de mémoire.
    • Harnais. Un CLAUDE.md qui charge ta mémoire projet, une règle de fiabilité que ton code applique à la lettre, un skill qui décrit un second chemin vers le même verdict, un pre-commit.
    • Intégration continue. Deux systèmes, deux versions de Node, et un job dédié qui télécharge un scanner de secrets, vérifie son empreinte, puis parcourt tout ton historique.
    • Tests. 1 380, tous verts hors réseau, plus une suite d'évaluations qui sert de seconde porte.
    • Interface. Pas d'écran à ouvrir. Un rapport HTML autonome par profil, ouvert dans le navigateur, onglets et dépliants parcourus.
    • Le calcul. Lu ligne par ligne, et ton dossier de passages testé dans ses trois états.
    • Un dossier abîmé exprès, pour voir comment il réagit.

    Comment ton outil marche

    • Un contrôle produit des preuves typées. Identifiant, source, sens, force, citation chiffrée.
    • Quand plusieurs sources ne disent pas la même chose, un ordre de priorité tranche, et le désaccord est publié à part.
    • Chaque axe porte trois lectures. Ce qui est prouvé, ce qui est seulement suggéré, et jusqu'où on pourrait aller sans preuve contraire. D'où un rang prouvé, un rang affiché, et une fourchette.
    • Un rang n'est retenu que si toutes les marches de ce rang sont atteintes, sur leur propre axe.
    • Sans aucune preuve d'usage de l'IA, tu rends « indéterminé », fourchette complète, confiance zéro. Une donnée qui manque n'est jamais un zéro.
    • Les seuils du référentiel vivent dans un fichier, avec l'échelle, l'ordre de priorité et le crédit accordé à chaque source. Une tolérance de couverture reste dans le code, et tu la documentes comme une dette.
    • Tu ajoutes un cinquième axe hors grille. Il ne fait jamais monter, et il ne peut faire descendre que d'un cran, en le disant.

    Ce qui marche bien

    • Ton référentiel est une donnée, pas du code. Et une garde automatique refuse tout nombre écrit en dur dans les contrôles.
    • Le déclaratif ne peut pas peser. Quel que soit son sens, il sert seulement à comparer ce qui est déclaré et ce qui est observé.
    • « Ce qui manque pour trancher » nomme le signal exact et le fichier attendu. On sait précisément quoi fournir.
    • Ton rapport publie ses désaccords entre sources, ta règle de priorité, et les champs que tu as lus puis écartés avec la raison.
    • La qualité du code est affichée mais marquée « n'entre dans aucun calcul », ce qui évite la confusion la plus fréquente.
    • Ton rapport HTML ne contient pas une ligne de JavaScript. Les onglets sont faits en CSS, ton référentiel est inclus dans la page, et le pied de page porte une empreinte qui rend deux rapports comparables.
    • Ton dossier de passages garde chaque exécution et l'écart avec la précédente, dans un fichier à part pour ne pas casser le résultat.

    Ce qu'on a préféré

    La séparation entre le rang prouvé et le rang affiché, encadrés par une fourchette. Dire ce qu'on pense sans prétendre l'avoir démontré.

    Et surtout ta méthode. Un jeu d'épreuves écrit et figé avant tout réglage de seuil, jamais rouvert jusqu'à la fin. Plus un test qui retire chaque pièce du profil et vérifie que ni le rang ni la confiance ne montent. On l'a lancé, il est vert. C'est de la méthode appliquée, pas une intention.

    Ce qu'on améliorerait

    • Une preuve contraire faible se lit comme une marche atteinte. Sur un profil, deux réponses négatives suffisent à afficher une marche haute du harnais et « aucune marche bloquante », alors que les marches du milieu sont inconnues. Conséquence directe sur ce profil : remplacer sa session par celle d'un autre développeur, ou par deux lignes de bonjour, donne exactement le même verdict et la même fourchette. Seule la présence d'un tour de conversation est lue. Sépare l'indice pour de l'indice contre, et le reste suit.
    • Ta garde d'antériorité n'a pas de quoi travailler sur l'historique livré. Elle compare la date de ton jeu d'épreuves à celles de ton référentiel, pour établir qu'aucun seuil n'a bougé après coup. L'idée est excellente. Mais le dépôt arrive avec dix-neuf commits datés du même jour, et ton référentiel y est commité vingt-huit secondes avant ton jeu d'épreuves. Elle s'arrête donc avant d'avoir comparé quoi que ce soit, et rend vert. Tes textes de méthode citent d'ailleurs des commits absents de cet historique. Livre l'historique de travail et la garde retrouve tout son sens.
    • Le titre de ton rapport et le champ de ton fichier de résultat ne disent pas la même chose dès que la fourchette dépasse deux crans. Le titre dit « indéterminé » pendant que le champ porte un rang. Les deux se défendent, mais un lecteur et un script en tirent des conclusions opposées.
    • Tes avertissements n'existent que dans le fichier de résultat. Qui lit le rapport ne sait pas qu'une pièce était illisible. Ta propre règle écrite dit l'inverse.
    • Ta confiance globale est le plus bas des axes. Un axe sans preuve met le total à zéro alors qu'un autre est à 0,64. Affiche le minimum avec sa cause, ou pondère.

    En résumé

    Une ligne de commande déterministe et sans réseau. Un référentiel de seuils sorti du code, un rapport HTML autonome sans une ligne de JavaScript, une intégration continue qui scanne aussi tout ton historique à la recherche de secrets, et une suite d'évaluations qui vérifie ton jugement lui-même.

    Ta méthode est écrite et versionnée. Une règle de fiabilité que ton code applique à la lettre, des décisions numérotées et justifiées, une mémoire projet, et un skill qui décrit un second chemin vers le même verdict.

    Sur le profil le moins renseigné, tu ne plantes pas et tu ne tranches pas non plus. Tu rends un rang prouvé, un rang affiché et une fourchette, au lieu d'un niveau sec. Sur les huit profils, tes verdicts correspondent aux niveaux qu’on avait fixés à l’avance, tolérances comprises. Et ton jeu d'épreuves écrit avant tout réglage, avec le test qui retire chaque pièce et vérifie que rien ne monte, est exactement la bonne façon de contrôler un outil qui juge des gens.

    Ce qu'on garde

    Le jeu d'épreuves écrit avant tout réglage, et le principe qu'il protège. Un outil ne doit jamais monter quand on lui retire de l'information. Et l'idée de livrer, avec son outil, de quoi le casser.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    renduProjet rendu

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions