Une suite de tests peut afficher une bonne couverture et rater un bug évident. Pour mesurer la qualité réelle, je regarde quatre axes complémentaires, avec un audit simple à appliquer sur un projet existant.
Bonjour, je suis Mathias 👋
Salut ! C’est ici que je partage mes pensées et mes notes sur tout ce qui me passionne et sur lequel je bosse en ce moment. J’espère vraiment y rencontrer des gens qui pensent comme moi. Salut ! Je voulais juste te dire que… J’aimerais vraiment avoir de tes nouvelles !
Je t’invite à jeter un œil à mes derniers articles de blog, juste en dessous.
Deux releases le même jour, à vingt minutes d’intervalle : v1.0.1 puis v1.0.2. Les deux font le même travail — durcir pi-secured-setup lui-même. C’est un billet court pour expliquer ce qui a changé et pourquoi ça compte, parce qu’un outil de sécurité qui traîne ses propres vulnérabilités perd toute crédibilité.
Si vous découvrez le projet, l’article de présentation pose les bases : Guards, Scanners, audit trail.
v1.0.1 — amélioration qualité
Trois axes :
Une fois la spec posée, je répartis le travail entre humain, IA et outils déterministes. Le test critique ne vient pas toujours du même auteur que le code, et le critic-agent compte souvent plus qu'un writer-agent.
La première étape du workflow IA est la spécification. Cet article montre comment transformer une user story floue en spec exploitable par un humain et un agent, avec Gherkin, exemples typés et propriétés.
Une base de connaissance Markdown pensée pour durer plusieurs années, avec un agent IA et une recherche vectorielle. Sept choix de conception sont documentés avec leurs coûts.
La promesse implicite des assistants de code IA était que les tests deviendraient une corvée du passé. La réalité documentée par Kent Beck, ThoughtWorks et plusieurs études de 2025 est l'inverse : avec l'IA, les tests deviennent indispensables — mais le travail s'est déplacé.
pi en mode YOLO, c’est le filesystem sans frein, n’importe quelle commande exécutée, zéro garde-fou. Le créateur a fait ce choix sciemment. Mais quand votre projet contient des .env, des clés SSH ou un production.yaml, ce choix vous met en danger.
J’ai présenté pi-secured-setup il y a quelques jours. Guards, Scanners, audit trail, branchés dans l’agent. Depuis, j’ai regardé une autre extension : pi-permission-system, par MasuRii. Les deux sécurisent pi. Pas de la même façon.
Dans l’article précédent, j’ai présenté pi-secured-setup — une extension pi qui ajoute des Guards, des Scanners et un audit trail à votre agent de code IA. Elle est livrée avec des defaults pertinents : application de frontière, globbing de chemins protégés, classification de commandes bash, rédaction de secrets, vérification de skills.
Mais chaque projet a des risques uniques. Un shop Terraform n’a pas les mêmes règles qu’un monorepo Node.js. Une équipe avec des exigences de conformité strictes n’a pas la même granularité d’audit qu’un développeur solo.
Il y a quelques jours, je présentais Greywall — un sandbox kernel-level qui contient pi grâce à une approche deny-by-default. C’est votre mur extérieur. Mais qu’en est-il des menaces à l’intérieur de la frontière ? L’agent qui écrit accidentellement dans le mauvais projet, le fichier .env qui se retrouve dans le contexte LLM, le skill dont le SKILL.md a été silencieusement modifié. C’est un problème différent, qui nécessite un outil différent.
Les agents de code IA comme pi sont devenus des compagnons indispensables au quotidien. Mais par défaut, pi fonctionne en mode YOLO : accès complet au filesystem, exécution de n’importe quelle commande, aucune restriction. C’est un choix délibéré de son créateur, mais cette liberté a un coût réel. Aujourd’hui, je vous propose de découvrir Greywall, un outil qui permet de sandboxer pi grâce à une approche deny-by-default au niveau kernel.