La réponse en 30 secondes
Claude Code n'est pas un assistant qui suggère du code : c'est un outil qui lit votre dépôt, modifie des fichiers et exécute des commandes.
Cette différence commande toute la formation. Un outil de complétion se juge sur la pertinence de ses propositions ; un outil qui agit sur le disque se juge d'abord sur ce qu'on l'autorise à faire et sur la façon dont on relit son travail. La compétence à transmettre est celle du cadrage et de la revue, pas celle de la formulation.
Surfaces disponibles : terminal, VS Code, JetBrains, application de bureau, navigateur, mobile.
Ligne de commande suffit à l'installer — et l'outil se met à jour tout seul ensuite.
Ligne de code qui doit partir en production sans avoir été relue par un humain.
Commandes et périmètre relevés le 31 août 2026 dans la documentation officielle Claude Code.
Installer : trois commandes selon le poste
L'installation native est la voie recommandée. Elle place l'exécutable dans votre environnement et le maintient à jour en arrière-plan, sans intervention.
macOS, Linux et WSL
curl -fsSL https://claude.ai/install.sh | bashWindows, dans PowerShell
irm https://claude.ai/install.ps1 | iexAvec Homebrew
brew install --cask claude-codeDeux pièges classiques sous Windows
Le message « The token '&&' is not a valid statement separator » signifie que vous êtes dans PowerShell alors que vous avez saisi la commande destinée à l'invite de commandes classique — et « 'irm' is not recognized » l'inverse. Repère simple : votre invite affiche PS C:\ en PowerShell, et C:\ sans le PS dans l'invite classique. Par ailleurs, sur un poste Windows natif, installez Git pour Windows : sans lui, Claude Code se rabat sur PowerShell au lieu d'un interpréteur de commandes complet. Les postes sous WSL n'en ont pas besoin.
Où il tourne, et lequel choisir
En formation, ne présentez qu'une seule surface le premier jour : le terminal si l'équipe y est à l'aise, l'extension de l'éditeur sinon. Multiplier les entrées le premier jour dilue l'apprentissage sur des différences d'interface au lieu de la méthode de travail, qui est identique partout.
Notez au passage que la ligne de commande et les extensions VS Code et JetBrains acceptent aussi des fournisseurs tiers — une souplesse qui compte si votre direction technique a déjà arbitré son hébergement de modèles.
Les modes de permission : le réglage qui compte
C'est le sujet à traiter en premier avec une équipe, avant même la première tâche. L'outil ne fonctionne pas en tout ou rien : il existe plusieurs régimes d'autorisation, et le mode dans lequel une session démarre dépend de votre offre, de la surface employée et des réglages de votre organisation.
Trois détails à connaître, et qui rassurent utilement une direction technique inquiète.
La frontière du dossier de travail. En mode manuel, l'outil n'écrit que dans le dossier depuis lequel il a été lancé et ses sous-dossiers : il ne modifie pas un répertoire parent sans autorisation explicite, et il demande avant même de lire en dehors de cette frontière. C'est l'argument le plus efficace face à la crainte du « il va se promener partout sur le poste ».
Les commandes réseau ne sont pas approuvées d'office. Les commandes qui vont chercher du contenu sur le web ne bénéficient d'aucune approbation automatique par défaut : elles demandent comme n'importe quelle autre commande non triviale. Cela limite l'un des vecteurs classiques d'injection d'instructions par du contenu extérieur.
Un bac à sable existe. Il isole les commandes du système de fichiers et du réseau, ce qui permet paradoxalement de réduire le nombre de demandes d'autorisation tout en restant plus sûr : on définit une zone où l'outil travaille librement sans pouvoir en sortir.
La phrase à retenir de la documentation officielle
L'outil ne dispose que des permissions que vous lui accordez, et il vous revient de relire le code et les commandes proposés avant de les approuver. Autrement dit, les garde-fous techniques ne transfèrent pas la responsabilité : ils la rendent tenable.
Le fichier de consignes : ce qui rend l'outil reproductible
Chaque session démarre avec une fenêtre de contexte vierge. Sans mécanisme de mémoire, vos développeurs réexpliquent les mêmes conventions tous les matins — et obtiennent des résultats différents selon qui a lancé la session.
Deux mécanismes complémentaires existent, et la distinction est importante en formation. Le fichier de consignes du projet est écrit par vous : il contient les règles et les conventions. La mémoire automatique est écrite par l'outil : il y consigne ce qu'il apprend de vos corrections. Le premier se relit et se versionne dans le dépôt ; la seconde s'inspecte et se corrige.
Ce qu'il faut mettre dans le fichier de projet, par ordre de rentabilité :
- Les commandes réelles pour installer, tester, construire et lancer. C'est ce qui évite le plus d'allers-retours, et c'est presque toujours oublié.
- Les conventions non devinables : nommage, structure de dossiers, style de messages de validation, bibliothèques imposées ou interdites.
- Les zones à ne pas toucher : fichiers générés, migrations passées, code sous contrainte réglementaire.
- Le contexte métier minimal : ce que fait le produit et pour qui, en trois lignes. Un outil qui ignore la finalité produit du code techniquement correct et fonctionnellement à côté.
Pour une équipe qui grandit, des règles peuvent être appliquées à certains chemins seulement, et une organisation peut déployer un fichier de consignes commun à tous ses dépôts. C'est la voie à privilégier dès que plusieurs équipes travaillent en parallèle : la connaissance cesse d'être dans la tête de celui qui a configuré son poste en premier.
La nuance qui évite un malentendu coûteux
La documentation est explicite : ces fichiers sont traités comme du contexte, pas comme une configuration contraignante. Écrire « ne touche jamais au dossier de production » rend l'action improbable, pas impossible. Pour réellement interdire une action quoi qu'il arrive, il faut un mécanisme d'interception qui s'exécute avant l'outil — pas une phrase dans un fichier de consignes. À dire clairement en formation, sous peine de fausse sécurité.
Les garde-fous, c'est le vrai contenu de la formation
Un outil qui exécute des commandes sur un poste de développement doit être encadré comme tel. Trois règles suffisent, et elles se transmettent en une demi-heure.
Toujours sur une branche, jamais sur la principale. C'est la protection la plus efficace et la moins coûteuse : tout ce qui est produit reste isolé et se relit dans une demande de fusion, exactement comme le travail d'un renfort ponctuel.
Écrire les consignes du projet dans le dépôt. Un fichier de contexte à la racine — conventions de nommage, commandes de test, ce qu'il ne faut pas toucher — évite de réexpliquer la même chose à chaque session et rend le comportement de l'outil reproductible d'un développeur à l'autre. C'est le premier réflexe d'équipe à installer.
Relire les différences, pas la conversation. L'erreur classique du débutant est de juger le travail sur la qualité de l'échange. Ce qui compte est le diff. Une modification qui semble raisonnable dans la discussion peut avoir touché un fichier de configuration au passage.
La règle qui résume les trois
Traitez la production de l'outil exactement comme celle d'un développeur qui viendrait d'arriver : compétent, rapide, mais sans connaissance de vos usages internes ni de l'historique de vos choix. Vous ne fusionneriez pas son travail sans le lire — la règle ne change pas ici.
Par quoi commencer, et ce qu'il faut éviter
Les bons premiers chantiers
- Écrire les tests manquants sur du code existant
- Comprendre et documenter un module que plus personne ne connaît
- Les migrations répétitives : renommer partout, changer une signature
- Reproduire un bug à partir d'un rapport d'incident
- Les corvées d'outillage : scripts, configuration d'intégration continue
Ce qu'il vaut mieux ne pas confier tout de suite
- Une décision d'architecture structurante
- Du code de sécurité ou de paiement sans relecture experte
- Une intervention directe en production
- Un domaine métier que personne dans l'équipe ne maîtrise — vous ne pourrez pas juger la réponse
Le dernier point mérite d'être souligné, parce qu'il est contre-intuitif. La tentation est d'employer l'outil là où l'équipe est faible : c'est précisément là qu'il est le plus risqué, faute de pouvoir évaluer ce qu'il rend. Le gain est maximal là où vous êtes compétent mais lent — pas là où vous êtes ignorant.
Cet arbitrage rejoint celui que nous décrivons pour les agents en général dans notre guide des agents IA en entreprise. Pour le cadrage de l'accès et de la charte, voyez notre guide de démarrage Claude en entreprise.
.jpg){kind=link}