RepoIntermediate

Sentinel : le gardien qui relit ce que votre IA a écrit (et vous apporte le fix)

Quand vous construisez avec l'IA, la vitesse cache un risque : l'IA écrit en « mode constructeur » — optimiste, imaginant que tout se passe bien — et elle est aveugle à ses propres bugs. Un secret qui part sur git, une requête qui laisse voir les données d'un autre client, un bouton qu'un utilisateur au clavier ne peut pas actionner. Sentinel est un gardien que vous installez dans votre agent et qui relit le code sur 18 fronts, et sa différence avec tout le reste est brutale : il ne se contente pas de pointer le problème, il vous livre le correctif minimal ET le test qui l'empêche de revenir. C'est gratuit, ça vit sur GitHub, et ici je vous apprends quand l'utiliser, pourquoi ça compte et comment l'installer en une commande.

Jun 25, 202612 min

À qui s'adresse ce contenu ?

À quiconque construit des logiciels avec l'IA — même sans savoir programmer. Si vous demandez à une IA de vous créer une app, un backend ou une fonction, elle écrit le code à votre place… mais personne ne vérifie qu'elle n'a pas laissé une faille. Cette ressource vous offre un gardien gratuit qui, lui, la vérifie, et vous l'explique en clair. Pas besoin de vous y connaître en sécurité : le gardien s'y connaît pour vous.

1. Le moment : quand l'IA écrit plus vite que vous ne pouvez relire

Le moment arrive toujours de la même façon. Vous demandez à votre IA « fais-moi le login de mon app », et en trente secondes vous avez du code qui tourne. Vous le testez, ça entre, ça marche. Vous passez à la fonctionnalité suivante. Puis à la suivante. L'IA produit à une vitesse que vous, en tant qu'humain, ne pouvez pas auditer ligne par ligne. C'est le moment exact où apparaît le risque silencieux.

Car l'IA n'écrit pas comme un auditeur méfiant. Elle écrit dans ce qu'on appelle le « mode constructeur » : optimiste, imaginant un seul chemin heureux, focalisée sur « que ça marche ». Et dans ce mode, elle est physiquement incapable de voir ses propres bugs — tout comme vous ne pouvez pas vous chatouiller vous-même. Le code tourne, oui. Mais « ça tourne » et « c'est sûr » sont deux choses différentes.

Imaginez-le ainsi

Construire, c'est comme cuisiner à toute vitesse pour servir un banquet : vous êtes concentré à faire sortir les plats, pas à savoir si vous avez laissé le gaz ouvert. Auditer est l'état d'esprit opposé : entrer dans la cuisine vide, froide, à la recherche de ce qui peut prendre feu. Ce sont deux cerveaux incompatibles. Sentinel est le second cerveau — celui qui entre ensuite, lampe torche à la main, chercher le gaz ouvert que vous, en train de cuisiner, ne pouviez pas voir.

2. La douleur : les bugs que l'IA ne voit pas sont les plus coûteux

La douleur est réelle et honnête — ce n'est pas une apocalypse, c'est un accident qui se paie cher. Voici les défaillances classiques que l'IA laisse involontairement, encore et encore :

Ce que le « mode constructeur » ne voit pas

Un secret (une clé d'API, un mot de passe) écrit directement dans le code et poussé sur git — où il reste pour toujours, même si vous l'effacez ensuite.

Une requête à la base de données qui oublie de filtrer par utilisateur → un client peut voir les données d'un autre. La faille la plus coûteuse dans toute app à plusieurs utilisateurs.

Un endpoint sans protection d'accès : n'importe qui avec l'URL entre.

Un bouton qui fonctionne à la souris mais reste invisible pour qui navigue au clavier ou avec un lecteur d'écran (défaut d'accessibilité, et parfois d'ordre légal).

Des données personnelles (emails, téléphones) écrites dans les logs par inadvertance.

Ce qui fait mal, ce n'est pas le bug en lui-même : c'est le moment où vous l'apprenez. Vous l'apprenez quand un utilisateur se plaint, quand quelqu'un fuit les données, quand une amende tombe. À ce moment-là, c'est déjà en production. Le coût d'un bug croît avec le temps qu'il met à être découvert — et ceux que l'IA ne voit pas sont justement ceux qui mettent le plus de temps à surgir.

Le chiffre qui l'explique

Un agent qui réussit 85 % du temps à chaque étape a l'air bien… jusqu'à ce que vous enchaîniez 8 étapes : 0,85⁸ ≈ 27 % de réussite de bout en bout. L'erreur n'est pas de ne pas utiliser l'IA — c'est de ne pas avoir un second cerveau qui relise ce que le premier a laissé passer. C'est ça, Sentinel.

3. L'habitude : relire n'est pas une fois, c'est à chaque fois que l'IA touche au code

Voici la clé qui change le comportement, et pas seulement le savoir : Sentinel n'est pas quelque chose qu'on utilise une fois et puis c'est tout. C'est une habitude. Chaque fois que votre IA écrit ou modifie du code important, vous demandez à Sentinel de le relire avant de le valider. Comme attacher votre ceinture : vous ne le faites pas « quand vous y pensez », vous le faites toujours, automatiquement.

Les moments où vous devriez TOUJOURS passer Sentinel :

Les 4 moments de l'habitude

Avant de mettre votre app en production (que le monde la voie) → « est-ce que c'est sûr, ça ? ».

Quand l'IA a touché à quelque chose de sensible : login, paiements, base de données, données d'utilisateurs.

En relisant un changement avant de l'accepter (une PR, une nouvelle branche).

De temps en temps, une revue générale — car ce qui était sûr hier a pu casser avec un changement d'aujourd'hui.

La règle d'or de Sentinel

Sentinel ne s'arrête pas à « voilà un problème, bonne chance ». Il suit une règle qui vaut pour toute l'ingénierie sérieuse : « sans test, le fix n'est pas fait ». C'est pourquoi, pour chaque bug réel qu'il confirme, il vous apporte deux choses : le correctif minimal ET un test de régression — une petite preuve qui garantit que ce bug ne revienne jamais. Attraper le bug, c'est la moitié ; le blinder pour toujours, c'est l'autre moitié.

4. Ce qu'il vérifie exactement : 18 fronts

Sentinel scanne selon 18 dimensions, réparties en deux grands groupes. Vous n'avez pas à toutes les comprendre — mais les voir vous donne la mesure de ce qu'il fait pour vous :

8 de sécurité classique : secrets dans le code, endpoints sans protection, requêtes qui contournent le filtre par utilisateur, configurations de base de données qui deviennent extrêmement lentes à grande échelle, en-têtes de sécurité mal placés, données personnelles dans les logs, entrées non validées, et dépendances comportant des vulnérabilités connues.

10 « angles morts du mode constructeur » : les bugs récurrents que l'IA commet encore et encore en construisant des interfaces et de la logique — raccourcis clavier qui volent la touche Entrée au chat, boutons invisibles au clavier, fuites de mémoire subtiles, identifiants dupliqués, erreurs avalées en silence. Ce second groupe est l'ingrédient secret : il naît d'un protocole de qualité affiné au fil de nombreuses rondes d'audit réel, et non d'une liste générique piochée sur internet.

Ce qui le rend fiable (et non bruyant)

La crainte, avec tout scanner, c'est qu'il vous noie sous les fausses alertes. Sentinel fait quelque chose de différent : pour chaque soupçon, il tente de le réfuter lui-même avant de le signaler (serait-ce un faux positif ? ce « secret » n'est-il qu'un exemple ? cette requête est-elle vraiment multi-utilisateur ?). Il ne vous signale que ce qui survit à ce doute. Mieux vaut 5 trouvailles réelles que 20 bruyantes.

5. Comment l'installer : une commande

Sentinel est une skill pour Claude Code (l'assistant IA qui travaille dans votre terminal ou éditeur). Il s'installe en une commande, et reste disponible dans tous vos projets. Si vous utilisez Claude Code, voici la seule chose que vous tapez :

bash

/plugin marketplace add MentexDev/neuralos-sentinel
/plugin install neuralos-sentinel@neuralos-sentinel

Vous utilisez un autre assistant (Cursor, Codex, Gemini CLI) ? Sentinel suit le standard ouvert des skills, il fonctionne donc aussi là avec npx skills add MentexDev/neuralos-sentinel. Une fois installé, vous ne l'invoquez pas avec une commande obscure : vous parlez normalement à votre IA.

Le plus simple : parlez-lui, tout simplement

Une fois installé, vous ne mémorisez rien. Vous dites à votre IA des choses comme : « scanne ce projet avec Sentinel », « est-ce que ce code est sûr avant de le pousser ? » ou « relis ce changement à la recherche de bugs de sécurité ». L'IA reconnaît l'intention et active le gardien toute seule. Aussi simple que ça.

6. Le prompt prêt à copier

Pour que vous n'ayez pas à réfléchir à quoi dire, voici le prompt complet, de bout en bout. Collez-le dans votre agent (avec Sentinel déjà installé), remplissez les [crochets], et laissez le gardien faire son travail :

Auditer mon code avec Sentineltext

Je veux que tu scannes mon code avec la skill neuralos-sentinel, en mode read-only (ne change rien sans mon OK).

Cible à examiner : [tout le projet / ce dossier / ce fichier / le dernier changement que tu as fait]
Stack / technologie : [ex. Next.js + base de données PostgreSQL, ou « je ne suis pas sûr, regarde le code »]
Contexte : [ex. « c'est une app à plusieurs utilisateurs/clients, donc les données NE doivent PAS se mélanger » · « il y a un login et des paiements » · ce que tu sais]

Suis la procédure de Sentinel : scanne les 18 dimensions, VÉRIFIE chaque trouvaille (écarte les faux positifs), et remets-moi un rapport trié par gravité. Pour chaque problème réel : dis-moi en clair de quoi il s'agit, dans quel fichier il se trouve, pourquoi ça compte, le correctif proposé et le test qui le blinde. À la fin, une section « ce que j'ai examiné et écarté » pour que j'aie confiance que tu n'as pas inventé d'alertes.

N'applique AUCUN changement pour l'instant : montre-moi d'abord le rapport et je déciderai quoi corriger.

7. Le chemin facile : qui fait quoi

Comme Sentinel vit à l'intérieur de votre agent de code, il vaut mieux savoir clairement ce qui se passe dans le chat et ce que vous faites. C'est plus simple qu'il n'y paraît :

Ce que l'agent fait tout seul (dans le chat)

Lire tout votre code et le scanner sur les 18 fronts.

Vérifier chaque trouvaille pour ne pas vous donner de fausses alertes.

Vous rédiger le rapport clair, avec le fix et le test de chaque problème réel.

Ce que vous décidez, vous (un clic / un « oui »)

Approuver quels correctifs vous voulez qu'il applique (Sentinel est read-only : il ne touche à rien sans votre autorisation).

Faire vraiment tourner un secret qui a été exposé (ça se fait dans le panneau du fournisseur, via le web).

Décider si une trouvaille s'applique à votre cas ou non (c'est vous qui connaissez votre activité).

Honnêteté : ce que Sentinel n'est PAS

Ce n'est ni de la magie ni un antivirus qui attrape tout. C'est un filet de haute confiance pour les défaillances les plus courantes et coûteuses — il ne remplace pas un audit de sécurité professionnel pour une banque. Et comme l'analyse est faite par votre agent d'IA, le code est traité là où tourne cet agent (comme toute requête que vous lui adressez). Sentinel n'ajoute aucun canal de sortie vers des tiers : ce qu'il trouve reste dans votre session.

8. Le dépôt (gratuit, MIT, mettez-lui une étoile)

Sentinel est open source et gratuit pour toujours. Il vit ici — entrez, regardez-le, installez-le, et s'il vous attrape un bug, laissez-lui une étoile pour que plus de gens le trouvent :

MentexDev/neuralos-sentinel

REPO

Le gardien de sécurité de votre code avec IA. Il attrape le bug sur 18 dimensions (sécurité + builder-mode) et vous apporte le fix avec son test de régression. Read-only par défaut.

MarkdownMITView on GitHub

Chez NeuralOS…

Sentinel est né de la même discipline avec laquelle NeuralOS se construit : détecter le problème, apporter le correctif, le blinder avec un test. C'est le premier d'une famille de gardiens — de petits alliés d'IA qui veillent sur votre produit et vous proposent le correctif, sans rien toucher tout seuls. L'idée de fond : que l'IA ne se contente pas de construire, mais qu'elle prenne aussi soin de ce qu'elle construit.