You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
Activity
blafourcade commentedon Sep 4, 2026
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é
CLAUDE.mdqui 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.Comment ton outil marche
Ce qui marche bien
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
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.