Qu'est-ce qu'un environnement de développement web ?

Avant d'installer le moindre logiciel, il faut savoir à quoi sert chaque outil et pourquoi il est là. C'est tout l'objet de cette microressource : visiter l'atelier avant de prendre les outils en main.

1. Un site web, ce ne sont que des fichiers texte

C'est le point de départ, et il surprend souvent. Une page web n'est pas un objet mystérieux : c'est un fichier texte, que vous pourriez ouvrir dans le Bloc-notes. Ce qui le rend spécial, c'est que son contenu suit des règles précises — HTML pour la structure, CSS pour l'apparence, PHP pour les traitements — et qu'un navigateur sait lire ces règles pour en faire une page à l'écran.

Autrement dit, vous n'allez pas « fabriquer des pages ». Vous allez écrire du texte selon une convention, et laisser le navigateur le transformer en page. Tout le reste de cette formation découle de cette idée.

2. Traitement de texte ou éditeur de code : la vraie différence

Puisqu'il s'agit de texte, pourquoi ne pas utiliser Word ? Parce que Word et un éditeur de code ne font pas du tout le même métier, même s'ils affichent tous les deux des lettres à l'écran.

Quand vous mettez un mot en gras dans Word, le logiciel enregistre cette mise en forme dans le fichier, sous une forme invisible pour vous. Un fichier .docx n'est donc pas du texte pur : c'est du texte accompagné d'une foule d'instructions cachées. Donnez ce fichier à un navigateur, il n'y comprendra rien.

Un éditeur de code fait l'inverse. Lorsqu'il colore vos balises en bleu et vos textes en orange, il ne modifie pas le fichier : la couleur n'existe que pour vos yeux, à l'écran. Le fichier enregistré, lui, reste exactement le texte que vous avez tapé — ni plus, ni moins. C'est précisément ce que le navigateur attend.

Ce que ça change côté empreinte carbone

Cette différence a une conséquence qu'on n'attend pas : le poids des fichiers. Toutes ces instructions de mise en forme que Word cache dans le document, ça s'accumule. Un fichier .docx, même vide, pèse déjà une dizaine de kilo-octets — parce que c'est en réalité une petite archive compressée contenant plusieurs fichiers d'instructions. La même poignée de mots enregistrée en texte brut tient, elle, dans quelques centaines d'octets : dix à cent fois moins.

Sur votre disque, la différence est invisible. Sur le web, elle ne l'est plus. Chaque octet d'une page est transféré à chaque visite — et une page populaire est demandée des milliers, parfois des millions de fois. Ce transfert consomme de l'électricité : dans les serveurs qui envoient le fichier, dans le réseau qui l'achemine, dans l'appareil qui l'affiche. À contenu égal, un fichier plus léger, c'est moins de données déplacées, donc moins d'énergie et moins de CO₂ émis. C'est le principe de l'éco-conception web : le fichier le plus sobre est celui qui ne transporte que ce qui est nécessaire.

Écrire ses pages en texte brut plutôt qu'en exportant du Word n'est donc pas qu'une question de propreté technique. Servir aux visiteurs des instructions de mise en forme qu'un navigateur ignore de toute façon, ce serait transporter du poids mort — et le faire payer en énergie à chaque consultation.

3. Les deux outils de l'atelier

Un environnement de développement web moderne repose sur deux outils complémentaires. Chacun répond à un besoin que l'autre ne couvre pas.

Ce que l'assistant IA ne fait pas

Claude Code écrira une grande partie du code de cette formation, et c'est voulu. Mais il produit du texte plausible, pas nécessairement du texte juste : il peut se tromper, inventer une fonction qui n'existe pas, ou répondre à côté de votre intention réelle. C'est vous qui validez. D'où une règle qui reviendra tout au long du parcours : ne jamais mettre en ligne un code qu'on n'a pas relu et compris. L'assistant supprime la corvée d'écriture, pas la responsabilité.

4. Les extensions : équiper son atelier

VS Code, à l'installation, est volontairement minimal. On l'enrichit avec des extensions : de petits modules qui ajoutent une capacité précise — comprendre la coloration du PHP, réindenter un fichier d'un raccourci, rafraîchir le navigateur à chaque enregistrement, se connecter à un serveur FTP…

Le principe est le même que pour une perceuse et ses embouts : l'outil de base reste le même, vous y montez ce que votre chantier réclame. Nous installerons les extensions utiles à la microressource 3, une fois VS Code en place.

5. Où se place chaque outil dans la chaîne

Voici le trajet complet d'une page, de votre clavier jusqu'à l'écran d'un visiteur. Chaque étape correspond à un moment de la formation :

1. Vous écrivez

   Dans VS Code, aidé de Claude Code, vous créez les fichiers du site sur votre ordinateur.

2. Vous vérifiez en local

   Vous ouvrez le fichier dans votre navigateur, sur votre poste. La page existe, mais vous seul pouvez la voir.

3. Vous publiez

   Via le FTP, vous copiez ces fichiers sur l'hébergement Infomaniak (module 1.3).

4. Le serveur distribue

   Le serveur envoie la page à quiconque la demande. Pour les pages PHP, il les fabrique à la volée en interrogeant la base MySQL (partie 2).

5. Le visiteur consulte

   La page s'affiche dans son navigateur, où qu'il soit. Le site est en ligne.

Retenez surtout la frontière entre les étapes 2 et 3 : « ça marche sur mon ordinateur » et « c'est en ligne » sont deux choses différentes. Tout le module 1.3 consiste à franchir ce pas, et beaucoup de mauvaises surprises viennent de là.