Les fondations dev, en langage clair

Vous n'avez rien à écrire de tout ça. Vous devez le comprendre assez bien pour faire les bons choix et sentir quand ça sent mauvais. Chaque terme se retrouve aussi dans le glossaire.

2.1 Le versionnage, et pourquoi « pas poussé » veut dire « n'existe pas encore »

Le versionnage enregistre l'histoire de votre code : qui a changé quoi, quand, et vous permet de revenir en arrière. Sa maison en ligne est la copie de référence, la sauvegarde et le point de rendez-vous.

Les mots que vous utiliserez vraiment : un dépôt est le projet versionné. Un commit est un instantané daté d'un ensemble de changements, avec un message. Une branche est une ligne de travail parallèle ; la ligne principale s'appelle généralement « main » et c'est votre production. Pousser et tirer envoient vos commits vers le haut et récupèrent ceux des autres. Fusionner replie une branche dans une autre. Une pull request est une demande de fusion, généralement relue avant.

La leçon payée en temps : un commit qui n'est pas poussé ne vit que sur votre machine. Un nouveau clone ou un incident local l'efface. La règle : poussez après chaque unité de travail. Le local est fragile, le push est la sauvegarde. J'ai perdu du travail non poussé deux fois. Récupéré les deux fois, mais ce sont des heures qu'on ne rattrape pas.

Pour le CTO en vous

quand plusieurs comptes partagent une machine, un push peut échouer sur un « repository not found » simplement parce que le mauvais compte est actif. Changez de compte avant de pousser.

2.2 Branches et revue

Le modèle classique : main est la production, sacrée, toujours déployable. Vous travaillez sur une branche, vous vérifiez, puis vous fusionnez dans main. Certaines équipes gardent une branche « préprod » de longue durée : on y pousse, on regarde l'URL de prévisualisation, puis on fusionne dans main. La revue de code est le moment où un pair relit avant la fusion. Avec l'IA, la revue devient deux choses à la fois : vous relisez ce que l'IA a produit, et l'IA fait sa propre passe de revue. Deux lecteurs valent mieux qu'un.

2.3 Environnements, configuration et secrets

Un produit vit dans plusieurs environnements : le local (votre machine, pour construire), la préprod ou staging (une copie en ligne pour valider avant la prod), et la production (ce que voient les vrais utilisateurs). Les variables d'environnement configurent le produit environnement par environnement, comme une adresse d'API ou une clé publique. Deux familles comptent. La configuration non sensible peut vivre dans le code. Les secrets (clés d'API, clés d'accès puissantes, secrets de paiement) ne vont jamais dans le versionnage. Ils se posent à la main dans le tableau de bord de votre hébergeur et survivent aux déploiements.

La règle d'or, à se tatouer : la clé puissante, celle qui a tous les droits sur votre base de données, n'est jamais dans le frontend. Uniquement côté serveur. Le frontend reçoit une clé publique, restreinte, encadrée par les règles de la base. Si une clé tout-accès atteint un jour le navigateur, considérez que la base est ouverte au monde entier.

Tenez une matrice des variables d'environnement : un simple tableau de chaque variable, où elle vit (dans le code, dans un coffre à secrets, dans le tableau de bord de l'hébergeur, dans votre fichier local), et qui la pose. Les variables manquantes se découvrent au moment du déploiement, dans la pire humeur, encore et encore, sauf si vous tenez la carte.

2.4 Les briques du backend

Vous ne les construirez pas de mémoire. Vous les reconnaîtrez, et vous saurez lesquelles une fonctionnalité touche, pour poser les bonnes questions.

Une API est l'interface que le frontend, ou un tiers, utilise pour parler au backend ; une requête atterrit sur un point d'entrée, une URL et une méthode. L'authentification consiste à prouver qui vous êtes, généralement avec un jeton signé envoyé à chaque appel et vérifié par le serveur. Un webhook est un appel qu'un tiers vous adresse quand quelque chose se produit, comme un prestataire de paiement qui annonce « cette facture est réglée ». La limitation de débit plafonne le nombre de requêtes par période pour empêcher les abus. L'idempotence garantit que la même opération jouée deux fois ne double pas son effet, ce qui est vital pour les paiements et les webhooks rejoués. Le chiffrement protège les données sensibles au repos, comme des clés stockées et verrouillées par un secret côté serveur.

2.5 Les dépendances sont un pouvoir et un risque

Chaque paquet que vous installez est un levier que vous n'avez pas eu à construire, et une porte à laquelle vous devez désormais faire confiance. Deux habitudes gardent la chose saine. Verrouillez vos versions : un fichier de verrouillage fige la version exacte de tout, pour que votre build soit identique aujourd'hui et dans six mois, sur votre machine et en production. Et résistez à la correction automatique aveugle : une commande qui « corrige » tous les avertissements de sécurité en montant tout de force cassera joyeusement votre application pour faire taire un avertissement qui ne vous concernait pas. Lisez ce qu'une correction change avant de la lancer. Moins de dépendances, choisies exprès, valent mieux qu'un tas dont vous ne pouvez pas rendre compte.

2.6 Votre produit est un graphe de services

Un produit moderne n'est pas une seule chose, c'est un graphe : une base de données, un prestataire de paiement, un envoyeur d'emails, un modèle d'IA, une intégration de chat, un hébergeur, un exécuteur de tâches. Chaque nœud est un point de valeur et un point de panne. Dessinez la carte, même grossièrement, et pour chaque nœud posez deux questions : qu'arrive-t-il à mes utilisateurs si celui-ci tombe, et combien celui-ci me coûte. Vous n'avez pas à rendre chacun incassable. Vous devez savoir où sont les points de défaillance uniques, pour qu'une panne soit un risque connu et non une surprise.