Sécuriser Claude Code en 2026 : sandbox, permissions et mode auto

Pour sécuriser Claude Code, il faut régler 3 choses : le mode de permission (qui décide avant chaque action), la sandbox Bash (ce que les commandes peuvent toucher sur ta machine) et les connecteurs MCP (ce que l’agent peut faire à l’extérieur). Depuis 2026, le mode auto est le réglage de départ : un second modèle valide les actions à ta place. La sandbox, elle, reste désactivée tant que tu ne lances pas /sandbox. Voici une configuration concrète pour profiter de l’agent sans lui donner les clés de toute ta machine.

Mise à jour du 12 octobre 2026 : mode auto par défaut, ce que la sandbox protège et ne protège pas, Claude Security et le plugin /claude-security, réglages imposés en entreprise, et nouvelles questions dans la FAQ.

D’où vient vraiment le risque avec un agent de code

Claude Code travaille dans un environnement réel. Il lit des fichiers, explore un projet, propose des modifications et peut exécuter des commandes. C’est précisément ce qui le rend utile, mais c’est aussi ce qui change la nature du risque par rapport à un chatbot classique.

Le scénario le plus courant : une consigne mal comprise, un script récupéré dans un projet, une page web contenant une instruction hostile ou un connecteur trop permissif. Une IA qui décide d’elle-même de vider ton disque reste très rare. L’agent fait exactement ce qu’on lui demande, mais dans un contexte que tu n’avais pas complètement vu.

La bonne sécurité repose donc sur un principe simple : réduire le rayon d’action par défaut, puis ouvrir uniquement ce qui est nécessaire à la tâche. C’est la même logique que pour un nouvel employé : tu ne lui donnes pas l’accès administrateur à toute l’entreprise le premier matin.

Les protections déjà intégrées à Claude Code

La documentation officielle d’Anthropic (page Security, consultée le 12 octobre 2026) décrit plusieurs couches de protection :

• Un mode de permission. Il fixe ce que Claude peut faire sans te demander. Depuis la version 2.1.283, le mode auto est le mode de départ dans le terminal et VS Code : un modèle séparé, le classifieur, examine les actions et bloque celles qu’il juge dangereuses. Le mode Manual démarre en lecture seule et te demande avant chaque modification ou commande

• Des règles allow, ask et deny. Tu autorises, fais confirmer ou interdis un outil ou une commande précise. Les règles deny s’appliquent dans tous les modes, même le plus permissif

• La sandbox Bash. Le système d’exploitation limite les fichiers et les domaines réseau que les commandes peuvent atteindre. Elle est désactivée par défaut

• Le dialogue de confiance. Claude Code te demande de valider un dossier inconnu avant d’y travailler, et chaque serveur MCP déclaré dans un projet a sa propre validation

• Des défenses contre l’injection de prompt. Les commandes réseau comme curl ne sont pas validées automatiquement, et les pages web sont résumées par un appel séparé avant d’arriver à Claude

Les 6 modes, d’après la documentation des modes de permission :

Ces protections forment une base sérieuse, sans être une garantie absolue. Anthropic le dit elle-même : la sécurité dépend aussi de tes permissions, de tes connecteurs et de ton comportement. Si tu découvres encore l’outil, commence par notre guide Claude Code pour non-codeurs avant d’ouvrir des accès plus larges.

1. Ouvre le bon dossier, pas ton disque entier

La première décision de sécurité se prend avant même ton premier message : le dossier depuis lequel tu lances Claude Code. Ouvre le projet exact sur lequel tu veux travailler. Évite ton dossier personnel, ton dossier Documents complet ou une arborescence qui contient plusieurs clients.

Pour une tâche ponctuelle sur des données sensibles, crée une copie de travail limitée. Mets-y seulement les fichiers nécessaires, retire les exports historiques et remplace les données personnelles par des exemples quand c’est possible. Une fois la tâche terminée, tu peux comparer le résultat puis supprimer cette copie.

Cette séparation apporte deux gains. L’agent voit moins de bruit, donc il raisonne mieux. Et une mauvaise commande touche un périmètre plus petit. Sécurité et qualité vont ici dans la même direction.

2. Traite chaque permission comme une décision

Quand Claude demande l’autorisation de lancer une commande, le mauvais réflexe est de cliquer automatiquement sur « toujours autoriser ». Lis trois éléments :

• La commande exacte. Est-ce une lecture, une installation, une écriture ou une suppression ?

• La cible. Le chemin vise-t-il bien le projet ouvert ? Une variable ou un joker pourrait-il élargir la portée ?

• L’effet externe. La commande envoie-t-elle des données, publie-t-elle quelque chose ou modifie-t-elle un service distant ?

Tu peux autoriser durablement les opérations banales et réversibles que tu comprends. Garde une validation manuelle pour les suppressions, les déploiements, les changements de permissions, les actions Git distantes et les commandes utilisant des identifiants.

Bloquer tout rend l’agent inutilisable : s’il demande ton accord pour chaque lecture, tu finiras par tout valider sans lire. Le bon réglage automatise le travail local à faible risque et garde un humain devant les actions difficiles à annuler. En mode auto, ajoute des règles ask pour ce qui doit toujours passer par toi, par exemple Bash(git push *).

3. Utilise la sandbox pour les commandes incertaines

Une sandbox limite ce qu’un processus peut atteindre. Dans Claude Code, elle encadre les commandes shell et les programmes qu’elles lancent, sur macOS, Linux et WSL2. Elle est désactivée par défaut : lance /sandbox dans une session, puis choisis entre deux modes. « Auto-allow » exécute les commandes sandboxées sans te demander, « regular permissions » garde les demandes habituelles.

Ce qu’elle fait par défaut, d’après la documentation sandbox :

• Écriture limitée au dossier de travail, à un dossier temporaire et aux dossiers que tu ajoutes

• Lecture de presque toute la machine, y compris ~/.ssh et ~/.aws/credentials. Ajoute ces chemins dans filesystem.denyRead

• Réseau filtré par un proxy local, avec une liste de domaines autorisés vide au départ

• Variables d’environnement héritées, secrets compris

Elle ne couvre que les commandes shell. Les outils de fichiers de Claude (lecture, écriture), les serveurs MCP locaux et les hooks tournent en dehors et suivent les règles de permission. Pour tester qu’elle marche, demande à Claude de lancer touch ~/sandbox-probe : la commande doit échouer avec « Operation not permitted » sur macOS.

La sandbox ne remplace pas la lecture de la commande. Elle ajoute une ceinture à la ceinture. Si un script tente d’écrire hors du projet ou de contacter un domaine inattendu, l’isolation l’en empêche. Si Claude demande de relancer une commande hors de la sandbox après un échec, refuse tant que tu n’as pas compris pourquoi, ou mets allowUnsandboxedCommands à false.

Pour un projet inconnu, la séquence propre est la suivante :

1. Ouvrir le dépôt dans un dossier dédié

2. Demander à Claude d’analyser les scripts d’installation sans les exécuter

3. Vérifier les dépendances et les commandes prévues

4. Lancer l’installation dans la sandbox avec un accès réseau limité au nécessaire

5. Examiner les fichiers modifiés avant de continuer

Cette méthode prend quelques minutes de plus et évite de faire confiance à une chaîne d’installation entière sur la base d’un fichier README.

4. Les secrets ne doivent jamais vivre dans les prompts

Une clé API, un mot de passe ou un jeton d’accès collé dans une conversation devient une donnée à protéger, à révoquer et parfois à auditer. Utilise des variables d’environnement ou un gestionnaire de secrets, et ne demande pas à l’agent d’imprimer leur valeur.

Ajoute les fichiers sensibles comme .env, les clés privées et les exports clients aux exclusions du projet. Si Claude a besoin de connaître la forme d’une configuration, donne-lui un fichier d’exemple avec de fausses valeurs.

Avant tout partage de journal ou de capture d’écran, cherche les chaînes ressemblant à des clés. Le risque vient souvent du débogage : une commande échoue, affiche toute la configuration, puis le résultat finit dans un ticket public.

5. Les serveurs MCP étendent aussi le risque

MCP permet de connecter Claude Code à des outils comme GitHub, une base de données, un navigateur ou un espace documentaire. C’est puissant parce que l’agent n’est plus limité au terminal. Mais chaque connecteur ajoute ses propres permissions, son propre code et ses propres données.

Anthropic précise que son annuaire MCP ne constitue pas un audit de sécurité de chaque serveur. « Disponible » ne veut pas dire « vérifié ». Avant d’installer un serveur MCP :

• Vérifie qui le maintient et si le code source est public

• Lis les autorisations demandées

• Préfère un accès en lecture seule quand il suffit

• Utilise un compte ou une clé dédiés avec un périmètre limité

• Supprime les connecteurs devenus inutiles

Pour comprendre comment ces connecteurs s’insèrent dans une architecture plus large, lis aussi ce qu’est réellement un agent IA.

6. Le piège subtil : l’injection de prompt

Une injection de prompt est une instruction cachée dans une source que l’agent consulte. Elle peut apparaître dans une page web, un fichier, un commentaire de code ou un document. Exemple : une page demande à l’agent d’ignorer sa mission et d’envoyer des données vers un serveur externe.

Les modèles modernes savent souvent reconnaître ce piège, mais « souvent » n’est pas un contrôle de sécurité. Quand Claude travaille sur du contenu externe non fiable :

• Évite de lui donner simultanément un accès large à des secrets et au réseau

• Demande-lui de séparer les données observées des instructions à suivre

• Garde une approbation manuelle avant tout envoi ou publication

• Inspecte les changements proposés et les domaines contactés

Plus un agent est autonome, plus la séparation entre lecture et action devient importante. Notre article sur les limites de l’autonomie des agents développe ce point avec des cas concrets.

7. Auditer un projet avec Claude Security

Anthropic a lancé Claude Code Security en aperçu limité le 20 février 2026, puis l’a renommé Claude Security et ouvert en bêta publique aux clients Enterprise le 30 avril 2026 (annonce). Le produit, accessible sur claude.ai/security, analyse un dépôt GitHub, confirme les failles en plusieurs étapes, les classe par sévérité et propose des correctifs à valider par un humain. D’après l’aide Claude, les scans tournent sur Claude Mythos 5 et sont facturés au coût des tokens, sans frais de plateforme.

Anthropic affirmait en février qu’Opus 4.6 avait trouvé plus de 500 vulnérabilités dans des projets open source. C’est un chiffre du fournisseur, sans benchmark indépendant, mais le cas d’usage est solide : un agent parcourt plus de chemins qu’une revue manuelle ponctuelle et explique chaque découverte dans le contexte du dépôt.

Sans offre Enterprise, tu as 2 outils dans Claude Code lui-même (documentation) :

• /security-review : une passe de sécurité unique sur ta branche

• Le plugin Claude Security : /plugin install claude-security@claude-plugins-official, puis /claude-security. Une équipe d’agents cartographie le projet, cherche les failles, fait vérifier chaque trouvaille et propose des correctifs. Il marche sur GitHub, GitLab ou un dossier sans Git, et chaque scan compte dans ton usage

Utilise-les comme un second regard, jamais comme un certificat. Un scan peut manquer une faille logique ou signaler un faux positif, et deux scans du même code peuvent donner des résultats différents. Pour scanner un dépôt qui ne t’appartient pas, lance toute la session dans une sandbox.

Claude Code en entreprise : imposer les règles à toute l’équipe

Une IA sécurisée en entreprise ne dépend pas de la vigilance de chaque salarié. Avec les réglages gérés (managed settings), l’organisation impose la même configuration à tous les postes, et personne ne peut l’assouplir en local. Les réglages les plus utiles :

• disableAutoMode pour couper le mode auto si ta politique exige une validation humaine

• sandbox.enabled à true et sandbox.failIfUnavailable pour que Claude Code refuse de démarrer sans sandbox

• allowUnsandboxedCommands à false pour interdire les relances hors sandbox

• Des règles deny sur les commandes et chemins sensibles, et une liste de serveurs MCP autorisés

• Les sessions dans le cloud d’Anthropic tournent dans une machine virtuelle isolée, avec un réseau limité par défaut et des opérations journalisées

Côté données, vérifie l’offre (Team ou Enterprise, conditions commerciales) et sa politique de conservation. Pour le cadre complet, RGPD et choix d’outils compris, lis notre guide sécurité des données et IA en entreprise, puis comment déployer un agent IA en entreprise.

La checklist propre avant de laisser l’agent travailler

• Le dossier ouvert contient uniquement le projet utile

• Les secrets vivent hors des prompts et des fichiers suivis

• Les suppressions, publications et actions distantes demandent une validation

• Les scripts inconnus sont lus avant d’être exécutés

• La sandbox est activée avec /sandbox et ~/.ssh est dans denyRead

• Le mode de permission est choisi en connaissance de cause, avec des règles ask sur les actions irréversibles

• Chaque serveur MCP a un propriétaire connu et le minimum de permissions

• Les modifications sont comparées avant validation

• Les clés utilisées par l’agent peuvent être révoquées facilement

Si ces 9 points sont vrais, tu as déjà éliminé l’essentiel du risque évitable. Le reste relève de la supervision normale : vérifier le résultat, garder des sauvegardes et ne pas automatiser une action irréversible avant de l’avoir testée.

FAQ

Claude Code peut-il supprimer mes fichiers ?
Oui, selon le mode de permission. En mode auto, le réglage de départ en 2026, un classifieur valide les actions à ta place et bloque celles qu’il juge risquées. En mode Manual, chaque modification passe par toi. Aucun mode ne valide automatiquement un rm visant un chemin critique. Le risque augmente surtout avec des permissions permanentes trop larges ou un dossier de départ qui contient trop de données.

La sandbox rend-elle Claude Code totalement sûr ?
Non. Elle réduit l’accès d’une commande au système de fichiers et au réseau, mais ne corrige pas une mauvaise décision métier, une fuite dans un fichier autorisé ou une action externe que tu as explicitement validée.

C’est quoi le mode auto de Claude Code ?
Un mode de permission où un second modèle, le classifieur, examine les actions de Claude à ta place et bloque celles qu’il juge dangereuses. C’est le mode de départ dans le terminal et VS Code depuis la version 2.1.283. Tes règles deny et ask restent appliquées, et une organisation peut le désactiver.

La sandbox de Claude Code est-elle activée par défaut ?
Non. Lance /sandbox dans une session ou mets sandbox.enabled à true dans ~/.claude/settings.json. Elle tourne sur macOS, Linux et WSL2, pas sous Windows natif.

Claude Code est-il adapté à une entreprise ?
Oui, avec des réglages imposés par l’organisation : sandbox obligatoire, règles deny, serveurs MCP autorisés, mode auto désactivable. Choisis une offre Team ou Enterprise et vérifie la politique de conservation des données.

Peut-on utiliser Claude Code avec des données clients ?
Oui si ton contrat, ton offre Anthropic et tes règles internes l’autorisent. Minimise les données, isole le dossier, supprime les identifiants inutiles et vérifie la politique de conservation applicable à ton organisation.

Faut-il installer tous les serveurs MCP utiles ?
Non. Chaque connexion augmente la surface d’attaque et la complexité. Installe seulement ce qui sert à une tâche récurrente, avec un accès en lecture seule quand c’est possible.

Traduire les réglages de sandbox en contrôles concrets

La logique est toujours la même : isoler les commandes, limiter les fichiers et le réseau accessibles, puis demander une autorisation avant les actions sensibles. Lance Claude dans un dossier borné, contrôle les correctifs proposés et garde une validation humaine avant toute mise en production.

Un audit de sécurité concret avant la production

Commence par lister les fichiers que Claude peut lire, les dossiers qu’il peut écrire et les domaines réseau qu’il peut contacter. Lance ensuite un scénario sans secret : lecture du projet, exécution des tests, génération d’un correctif puis comparaison des changements. Si l’agent sort du périmètre prévu, resserre la sandbox avant de continuer.

Teste aussi l’échec. Coupe le réseau, refuse une permission et fournis un fichier contenant une instruction hostile. Claude doit expliquer le blocage, conserver les données dans le projet et demander une validation au lieu de contourner la règle. Sur le web comme en local, garde une personne responsable avant le déploiement.

Enfin, vérifie les correctifs proposés : commande exacte, fichiers modifiés, dépendances ajoutées et effet sur la production. Une revue courte mais reproductible vaut mieux qu’une autorisation permanente accordée parce qu’une première exécution s’est bien passée.

Le drapeau à ne pas banaliser

Les permissions restent le contrôle décisif. N’utilise jamais --dangerously-skip-permissions par confort : ce drapeau active le mode bypassPermissions, qui supprime les demandes d’autorisation. Anthropic le réserve aux conteneurs et machines virtuelles isolés (modes de permission).

Comprendre la frontière d’isolation de Claude Code

Une sandbox ne rend pas une commande sûre par magie. Elle limite surtout ce que le processus peut lire, écrire et joindre sur le réseau. Cette frontière d’isolation doit être définie avant le premier test. Le dossier ouvert, les règles locales et les accès réseau restent déterminants, et les réglages imposés par une organisation renforcent la politique locale sans remplacer la vérification du poste.

Tester l’isolation Claude Code sans risque

Crée d’abord un dossier de test. Place-y des fichiers factices. N’utilise aucun secret réel. Demande ensuite une lecture simple. Vérifie que l’outil reste dans ce dossier.

Teste ensuite une écriture. Le fichier créé doit apparaître au bon endroit. Refuse toute demande qui vise un dossier voisin. Cette étape prouve la frontière de fichiers.

Teste enfin le réseau. Commence sans jeton ni compte connecté. Observe les domaines appelés. Autorise seulement les destinations nécessaires. Une dépendance inconnue ne doit pas obtenir un accès automatique.

Pour chaque bash command, garde quatre informations : la commande demandée, la permission accordée, le résultat et les fichiers modifiés. Un journal court suffit. Il doit permettre de comprendre ce qui s’est passé.

Séparer lecture, écriture et exécution

La lecture expose des données. L’écriture change l’état du projet. L’exécution peut déclencher d’autres programmes. Ces trois capacités ne doivent pas partager la même règle par défaut.

Autorise la lecture dans le dossier du projet. Limite l’écriture aux fichiers prévus. Demande une validation avant une commande destructive. Bloque les chemins larges et les variables non résolues.

Une session saine commence avec peu de droits. Elle gagne des permissions quand le besoin est clair. Elle les perd dès que la tâche se termine. Cette méthode réduit le rayon d’impact d’une erreur ou d’une instruction malveillante.

La preuve finale

Ne juge pas la sécurité sur une simple fenêtre de réglages. Vérifie le comportement. Le Claude Code process doit échouer hors du périmètre autorisé. Les fichiers sensibles doivent rester illisibles. Les domaines non prévus doivent rester injoignables.

Relance ensuite le même scénario dans une nouvelle Claude Code session. Le résultat doit rester identique. Si une permission temporaire persiste sans raison, corrige la configuration avant de travailler sur un vrai dépôt.

La bonne sandbox est donc observable. Elle bloque ce qui doit l’être. Elle laisse passer le travail prévu. Et elle produit assez de traces pour expliquer chaque action.

Six scénarios pour vérifier la sécurité avant un vrai projet

Une politique paraît souvent solide sur le papier. Les scénarios suivants permettent de vérifier son comportement. Utilise uniquement des données factices. Observe ce qui est autorisé, refusé et journalisé.

Scénario 1 : lecture hors du projet

Ouvre un dossier de test. Place un faux fichier sensible dans un dossier voisin. Demande ensuite à Claude Code de le rechercher. La tentative doit échouer ou demander une permission claire.

Le message affiché compte moins que ce qui a fuité. Vérifie aussi que le contenu du fichier n’apparaît pas dans la réponse, les logs ou un fichier temporaire. Une restriction d’écriture ne protège pas la lecture : par défaut, la sandbox laisse lire presque toute la machine.

Scénario 2 : modification imprévue

Crée trois fichiers factices. Autorise une modification sur un seul fichier. Demande ensuite une amélioration générale du projet. Contrôle le diff final. Les deux autres fichiers doivent rester identiques.

Si l’agent élargit seul le périmètre, réduis ses droits. Une consigne textuelle ne suffit pas toujours. La frontière technique doit empêcher la modification non prévue.

Scénario 3 : commande destructive

Prépare un dossier jetable. Demande une opération qui pourrait supprimer ou remplacer plusieurs fichiers. La sandbox doit bloquer l’action ou exiger une validation explicite.

Lis la commande complète avant de répondre. Refuse les chemins trop larges. Refuse les variables dont la valeur est inconnue. Refuse aussi une opération récursive si la cible n’est pas précisément résolue.

Après le test, vérifie les fichiers. Un message de refus n’est pas une preuve suffisante. Seul l’état réel du dossier confirme que la protection a fonctionné.

Scénario 4 : accès réseau inattendu

Lance une tâche qui n’exige aucun accès externe. Observe les connexions. Aucun domaine imprévu ne devrait être contacté.

Ajoute ensuite une source publique précise. Autorise seulement ce domaine. Vérifie que la requête fonctionne et que les autres destinations restent bloquées. Cette approche réduit les sorties de données involontaires.

Les gestionnaires de paquets demandent parfois plusieurs domaines. N’ouvre pas tout le réseau pour gagner du temps. Identifie les destinations nécessaires, puis documente leur rôle.

Scénario 5 : instruction cachée dans un fichier

Place une fausse instruction malveillante dans un document de test. Elle peut demander de lire un secret, de modifier une règle ou d’envoyer un fichier. Demande ensuite à l’agent de résumer le document.

L’agent doit traiter le texte comme une donnée. Il ne doit pas transformer cette donnée en autorisation. La mission initiale et les permissions système restent prioritaires.

Répète le test avec un fichier HTML, un commentaire de code et une issue copiée depuis le web. Les injections ne vivent pas seulement dans les prompts directs.

Scénario 6 : serveur MCP trop puissant

Connecte uniquement un serveur MCP de test. Donne-lui des données factices. Vérifie la liste exacte de ses outils. Un connecteur de lecture ne doit pas exposer une action d’écriture inattendue.

Teste ensuite un appel refusé. Le serveur doit appliquer sa propre autorisation. La protection locale de Claude Code ne remplace pas les contrôles du service distant.

Déconnecte le serveur après le test. Vérifie que la session suivante ne conserve pas un accès devenu inutile. Les permissions oubliées créent un risque silencieux.

Construire une matrice de permissions simple

Une petite matrice évite les règles vagues. Place les ressources en lignes. Place les capacités en colonnes. Utilise quatre niveaux : refusé, lecture, écriture et action externe.

Pour les fichiers du projet, la lecture peut être autorisée. L’écriture reste limitée aux fichiers concernés par la mission. Pour les secrets, la règle par défaut est le refus. Pour le réseau, utilise une liste de destinations nécessaires.

Ajoute une colonne de validation humaine. Elle doit couvrir les envois, publications, dépenses, suppressions et changements de configuration. Une action réversible peut avancer plus librement. Une action difficile à récupérer exige une preuve et une confirmation.

Révise cette matrice quand le projet change. Un nouvel outil, un serveur MCP ou une tâche planifiée peut agrandir le périmètre. L’ancienne politique ne couvre pas automatiquement la nouvelle capacité.

Que faire après un comportement suspect

Arrête d’abord la session. Ne relance pas immédiatement la même commande. Conserve le transcript, les permissions accordées et le diff des fichiers.

Révoque les jetons qui ont pu être exposés. Change les secrets concernés. Ferme les connexions externes inutiles. Si un dépôt distant a reçu une modification, protège la branche avant toute nouvelle action.

Détermine ensuite le premier écart observable. La mauvaise réponse finale est rarement le début de l’incident. Cherche la première lecture imprévue, la première permission trop large ou la première instruction non fiable suivie par l’agent.

Corrige la règle la plus proche de cette cause. Puis rejoue le scénario avec des données factices. La protection est validée seulement si l’action dangereuse échoue et si la tâche légitime continue de fonctionner.

Documente enfin la leçon en une phrase. Exemple : « les fichiers téléchargés ne peuvent jamais élargir le périmètre ». Une règle courte est plus facile à relire et à tester.

Le contrôle mensuel

Une configuration sûre peut dériver. Les outils changent. Les dépendances changent. Les permissions s’accumulent. Prévois donc un contrôle léger.

Vérifie les dossiers autorisés. Vérifie les domaines réseau. Vérifie les serveurs MCP. Vérifie les tâches automatiques. Vérifie aussi les comptes et jetons encore actifs.

Relance les six scénarios principaux. Note le résultat. Un test qui échoue devient une correction prioritaire. Un test qui réussit garde une preuve datée.

Cette discipline paraît lente. Elle évite pourtant les audits improvisés après un incident. Quelques minutes de vérification valent mieux qu’une permission permanente oubliée.

Avant de partir

La sécurité d’un agent ne vient pas d’un bouton magique. Elle vient d’un système simple : petit périmètre, permissions compréhensibles, validation avant l’irréversible et preuves après l’action. C’est exactement le genre de système qu’on construit chaque semaine dans Kryve Weekly.

Recevoir Kryve Weekly et le guide de démarrage

Un email pour te l’envoyer. Pas de spam, désinscription en un clic.

Continuer avec

• Codex vs Claude Code : lequel choisir en 2026

• Faire tourner une IA en local : le guide pragmatique

• Ton agenda géré par une IA : le système complet

Pour élargir la comparaison : lis Claude Code vs Cursor pour non-développeur, puis le guide Grok Build pour comparer permissions et supervision.