aiedit cache certaines lignes de code à l'agent IA : 5 niveaux et 857 tests

L'éditeur aiedit verrouille pour l'agent IA non pas des fichiers, mais des lignes précises, et il le fait au niveau du code, pas par une consigne dans le prompt. Le projet a été écrit par un développeur débutant : il apprend Python depuis la fin septembre 2026, et c'est Claude qui a écrit le code sous sa direction. Le résultat : environ 11 000 lignes de code, environ 10 000 lignes de tests et 857 tests, qui passent aussi bien sur PySide6 que sur PyQt6. La licence est MIT, les requêtes vers les modèles sont de simples requêtes HTTPS sans SDK, ce qui convient à Anthropic, à OpenAI et à tout serveur compatible OpenAI.

Pourquoi les fichiers ignore ne protègent pas

L'idée est née des faiblesses des outils existants. La documentation de Cursor indique noir sur blanc que les commandes du terminal et les outils MCP « peuvent lire » les fichiers listés dans .cursorignore.

Cline a carrément supprimé .clineignore : selon le projet, ce fichier « n'a jamais été conçu comme une interdiction d'accès », et ses auteurs ne veulent pas donner un faux sentiment de sécurité. De plus, ces fichiers ne fonctionnent qu'à l'échelle de fichiers entiers.

Si l'on divise le projet entre « accessible à l'IA » et « interdit », l'agent travaille à l'aveugle. aiedit laisse le projet intact et verrouille de façon ciblée : la formule de calcul d'un prix ou la gestion des paiements, par exemple. Le reste, le modèle le voit et peut le modifier.

Cinq niveaux et une chaîne de cinq protections

Les lignes se verrouillent directement dans la zone de numérotation des lignes. Voici les niveaux d'accès :

• hidden : le modèle reçoit seulement un marqueur du type <<ai-hidden:0:5 lines>>. Il sait donc qu'il y a quelque chose à cet endroit, et combien de lignes ;
• interface : noms et signatures sans le corps des fonctions (pour Python) ;
• readonly : tout le code est visible, mais toute modification est rejetée ;
• confirm : tout le code est visible, les modifications ne passent qu'avec l'accord de l'auteur ;
• explain : le modèle explique ce code.

Sur ces niveaux s'appuie une chaîne de vérifications :

• le modèle n'a pas de terminal, seulement les outils de l'éditeur (lire, chercher, modifier), et les dossiers verrouillés n'existent pas pour lui ;
• chaque modification est vérifiée par un diff : si elle touche une ligne verrouillée, elle est rejetée, et rien n'est écrit sur le disque sans validation ;
• les tests et le programme s'exécutent sous bubblewrap sur une copie du projet où le code verrouillé est physiquement absent, sans réseau, sans dossier personnel et sans clés. Même un affichage de tous les fichiers en base64 ne révélerait rien ;
• un filtre sortant recherche les clés, les mots d'une liste et les lignes verrouillées collées dans le chat, et propose de les masquer, de les envoyer ou d'annuler ;
• un journal local consigne les fichiers envoyés, le nombre de lignes masquées et le nombre de caractères transmis, et tout travail appliqué par l'IA peut être annulé.

Il existe par ailleurs un pipeline multimodèle : un modèle écrit le code, l'éditeur lance lui-même les tests dans le bac à sable, puis un modèle d'un autre éditeur cherche les erreurs et les failles. L'auteur ne voit les changements qu'à l'issue de ce processus, avec le résultat réel des tests, et non un simple « tout fonctionne ».

Comment la protection a cassé le code écrit par le modèle

L'auteur présente sa comparaison avec Claude Code sans fard. Sur la tâche « application simple en Flask », le code a été écrit par Claude Opus 5.5 aussi bien dans aiedit que dans Claude Code, mais dans aiedit, les modifications étaient en plus vérifiées par GLM 5.

3, et le résultat s'est révélé moins bon. Le journal a permis d'en trouver la cause. Le modèle avait écrit "password": "secret123" dans les tests, le filtre de secrets l'a pris pour un vrai mot de passe, et dans le bac à sable la ligne s'est transformée en raise NotImplementedError, en plein milieu du dictionnaire.

Le fichier n'était plus du Python valide. Sur 22 exécutions dans le bac à sable, 13 ont échoué, et pytest n'est jamais parvenu jusqu'aux tests eux-mêmes. Le modèle n'a pas compris la cause et a écrit six fichiers de tests supplémentaires pour contourner le problème.

Le correctif : seule la valeur est désormais remplacée, "password": "<hidden>", et la syntaxe est préservée. L'auteur n'a pas relancé de test sur des modèles en conditions réelles : le correctif est validé par un test qui reproduit le cas. Avec les modèles locaux, les résultats sont aussi inégaux : qwen2.5-coder 7B n'a pas tenu le format d'appel des outils, la version 32B a réussi les tâches simples, mais n'a pas terminé la tâche multifichier en 14 étapes.

La relecture du code a aussi révélé deux failles, toutes deux corrigées. Quand un fichier était renommé ou copié en dehors de l'éditeur, les zones se perdaient ; désormais, le code verrouillé est reconnu grâce aux hachages de lignes. Quant au projet installé dans son propre .venv via pip install ., il s'y trouvait en entier, et une commande dans le bac à sable pouvait le lire ; ces copies sont donc désormais masquées.

Où s'arrête la protection et ce qu'il faut en retenir

L'auteur énumère honnêtement les limites. Le filtre n'attrape que ce qu'il peut comparer : les motifs de clés, les mots d'une liste et les lignes verrouillées collées telles quelles ; un secret reformulé passera. Une signature comme calc_discount_for_client_x() dans la zone interface en révèle déjà le sens.

Tout ce qui n'est pas verrouillé part chez le fournisseur du modèle. L'éditeur ne reconnaît pas une copie modifiée du code verrouillé. Les hachages dans *.

aimarks.json sont sans sel, si bien qu'une ligne courte comme rate = 0.15 peut être retrouvée par force brute, et ces fichiers ne doivent pas être publiés dans un dépôt public.

Le bac à sable fonctionne pleinement sous Linux ; sous macOS, il est expérimental et n'a pas été testé sur un vrai Mac, et sous Windows, il n'est disponible que via WSL.

La leçon pratique pour les équipes qui donnent à des agents l'accès à du code commercial : la protection doit vivre dans la couche d'outils, pas dans le texte du prompt. Priver l'agent de terminal, utiliser un bac à sable avec une copie sans secrets, vérifier les modifications par diff et filtrer les envois sortants offrent des garanties vérifiables. L'effet secondaire est lui aussi visible : plus le masquage est agressif, plus le risque de casser la validité du code augmente, et les journaux de requêtes deviennent le principal outil de débogage. Le code est disponible sur GitHub et GitFlic, et l'auteur demande qu'on lui envoie les moyens de contourner la protection.