Extensions VS Code : l'essentiel pour tout développeur

Les bonnes extensions VS Code transforment l'éditeur d'un simple outil de texte en un environnement de développement complet, au cœur de votre travail quotidien. Depuis des années, je transporte la même configuration en passant d'un projet web à un serveur de jeu ou à un bot ; dans cet article, je présente les extensions que j'utilise réellement, celles qui améliorent visiblement la productivité, et pourquoi elles méritent leur place. L'objectif n'est pas de tout lister, mais de montrer où chacune s'insère dans un flux de travail réel.

Les fondations d'abord : rendre l'éditeur fluide

Certaines extensions ne se font jamais remarquer, mais elles facilitent chaque fichier que vous ouvrez. Voici les premières que j'installe en rejoignant un projet :

• EditorConfig for VS Code — Si le dépôt contient un fichier .editorconfig, il applique automatiquement l'indentation, les fins de ligne et l'encodage. C'est le moyen le moins coûteux d'aligner toute l'équipe sur le même style.
• Path Intellisense — Complète la structure des dossiers lorsque vous écrivez des import et des chemins de fichiers, mettant fin aux minutes perdues à cause d'un mauvais chemin.
• Code Spell Checker — Repère les fautes de frappe dans les noms de variables et les commentaires. Écrire receive au lieu de recieve est salvateur lorsqu'on fait un grep plus tard.

Formatage et linting : le duo qui clôt le débat

Maintenir le style de code cohérent à la main, c'est de l'énergie gaspillée. Pour confier cette tâche à l'outillage, les extensions VS Code auxquelles je fais le plus confiance sont Prettier et ESLint :

• Prettier — Reformate votre code selon ses propres règles à l'enregistrement. Il élimine totalement les questions d'indentation, de guillemets et de points-virgules.
• ESLint — Signale les vrais problèmes en JavaScript/TypeScript pendant que vous tapez, comme les variables inutilisées et les références non définies. Prettier s'occupe du format, ESLint de la logique ; les deux travaillent ensemble.

Pour exécuter Prettier automatiquement à l'enregistrement, j'ajoute ceci à mes paramètres utilisateur ou d'espace de travail :

{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  }
}

Ainsi, chaque enregistrement formate le fichier et corrige automatiquement les problèmes qu'ESLint sait réparer. Pour un formateur propre à un langage, vous pouvez le configurer par type de fichier avec des blocs comme "[python]": { "editor.defaultFormatter": "..." }.

Gérer Git sans quitter l'éditeur

La prise en charge native de Git dans VS Code est bonne, mais deux extensions la portent à un autre niveau :

• GitLens — Affiche qui a modifié chaque ligne, quand et dans quel commit, juste à côté (blame en ligne). Lorsqu'on cherche l'origine d'un bug, on peut parcourir l'historique du fichier, l'historique de la ligne et les détails du commit dans l'éditeur.
• Git Graph — Dessine les branches, les fusions et l'arbre des commits sous forme de graphe visuel. Comprendre l'état avant un rebase ou un merge délicat est bien plus rapide qu'en lisant le terminal.

Ces deux extensions brillent sur les projets de longue durée : regarder une ligne et répondre en quelques secondes à « pourquoi avons-nous fait ainsi » transforme l'archéologie du code en vrai travail.

Développement à distance et en conteneur

Quand une grande partie du travail se fait non pas sur votre machine locale mais sur un VPS ou dans un conteneur Docker, la famille Remote de Microsoft devient indispensable :

• Remote - SSH — Connectez-vous à un serveur distant en SSH et modifiez les fichiers comme s'ils étaient locaux ; les extensions et le terminal s'exécutent sur la machine distante. Modifier un serveur de jeu ou une installation Laravel directement sur le VPS supprime la corvée de copier des fichiers entre local et distant.
• Dev Containers — Ouvre le projet dans un conteneur basé sur une définition devcontainer.json. Toute l'équipe travaille avec la même version de PHP/Node et les mêmes dépendances système, ce qui élimine largement les soucis du type « ça marchait chez moi ».
• WSL — Se connecte directement aux fichiers du sous-système Linux sous Windows. Les trois extensions partagent le même modèle « Remote Explorer ».

Prise en charge spécifique au langage et au framework

En plus des extensions générales, il est judicieux d'en ajouter quelques-unes ciblées selon votre stack. Celles que j'utilise souvent :

• PHP Intelephense — Offre une autocomplétion rapide, des indications de type et le « aller à la définition » dans les projets Laravel et PHP pur.
• Tailwind CSS IntelliSense — Complète les noms de classes Tailwind et affiche le CSS généré au survol.
• Docker — Propose la coloration, l'autocomplétion et la gestion des conteneurs pour les fichiers Dockerfile et compose.

Le principe ici : garder la base légère et ajouter les extensions de langage qui apportent réellement de la valeur au projet du moment. Trop d'extensions qui se chevauchent peuvent ralentir l'éditeur, et deux formateurs faisant le même travail peuvent entrer en conflit.

Garder sa configuration portable

Pour choisir vos extensions une seule fois plutôt que de les installer à la main sur chaque machine, il existe deux approches. La fonction native Settings Sync de VS Code synchronise extensions, paramètres et raccourcis clavier avec un compte. Vous pouvez aussi placer des recommandations propres au projet dans le dépôt :

// .vscode/extensions.json
{
  "recommendations": [
    "esbenp.prettier-vscode",
    "dbaeumer.vscode-eslint",
    "eamodio.gitlens"
  ]
}

Grâce à ce fichier, quiconque ouvre le projet voit les extensions recommandées et peut les installer en un clic. Pour la cohérence d'équipe, c'est plus fort que Settings Sync, car la recommandation est liée au projet, pas à la personne.

Questions fréquentes

Trop d'extensions ralentissent-elles VS Code ?

Oui, surtout celles qui s'activent à chaque lancement et analysent les fichiers en arrière-plan peuvent ralentir le démarrage. La commande Developer: Startup Performance indique le temps passé par chaque extension, ce qui permet de désactiver celles que vous n'utilisez pas dans certains espaces de travail.

Prettier et ESLint entrent-ils en conflit ?

Pas s'ils sont bien configurés. Si vous désactivez les règles de mise en forme d'ESLint et laissez le formatage à Prettier, les deux fonctionnent proprement ensemble ; le paquet eslint-config-prettier existe précisément pour éviter ce conflit.

Faut-il installer les extensions par espace de travail ou globalement ?

Gardez les outils généraux (GitLens, Prettier) en global ; activez dans l'espace de travail concerné les extensions de langage qui n'ont de sens que dans certains projets. Ainsi l'éditeur ne porte que la charge dont vous avez besoin pour chaque projet.

Envie d'accélérer votre propre flux de développement ? Je peux vous aider à mettre en place une chaîne d'outils cohérente et un flux de travail propre sur un projet web, serveur ou d'automatisation — contactez-moi.