Workflow de l'ingénieur pro
Comment chaque boîte tech au monde livre du code
⏱ Estim. ~13 min
01 · Lire
Tu as appris chaque compétence individuelle : terminal, fichiers, git, serveur web, API, Claude Code, debug, déploiement. Maintenant on les combine dans le workflow que chaque équipe de dev professionnelle suit.
Les outils varient — certaines équipes utilisent GitLab au lieu de GitHub, certaines déploient sur AWS au lieu de Render, certaines utilisent des langages différents. Mais le workflow est toujours le même. Apprends ce workflow et tu peux entrer dans n'importe quelle boîte tech et comprendre comment ils livrent du logiciel.
💡 Imagine çaLes compétences individuelles, c'est comme apprendre à dribbler, passer, tirer. Le workflow pro, c'est le vrai match — comment combiner ce que tu as appris dans une séquence coordonnée qui produit des résultats. Comprendre le workflow, c'est la différence entre savoir coder et pouvoir livrer.
02 · Étape par étape
Le cycle de développement complet. Chaque fonctionnalité, correction de bug, amélioration suit cette boucle exacte.
1. ISSUE
Quelqu'un signale un bug ou demande une fonctionnalité. C'est suivi dans GitHub Issues, Jira board, ou une simple liste de tâches. Chaque travail commence par un problème ou un objectif clairement décrit.
2. BRANCH
Crée une branche : git checkout -b fix-login-bug. Ne travaille jamais directement sur main. Les branches isolent tes changements pour que tu puisses expérimenter sans rien casser.
3. CODE
Implémente le correctif ou la fonctionnalité avec Claude Code. Décris clairement ce que tu veux, examine ce qui est produit, itère jusqu'à ce que ce soit bon. C'est là où la construction se passe.
4. TEST
Vérifie en local que ça marche. Vérifie les cas limites. As-tu cassé autre chose ? Essaie des entrées bizarres, des champs vides, des scénarios inattendus. S'il y a des tests automatiques, lance-les.
5. REVIEW
Lance git diff. Examine tes changements ligne par ligne. Tu approuverais ça si quelqu'un d'autre l'avait écrit ? Cherche les console.log oubliés, les valeurs en dur, ou ce qui ne devrait pas être là.
6. COMMIT
Stage et commit avec un message descriptif. Un changement logique = un commit. 'Fix login validation to reject empty passwords' raconte une histoire. 'Fixed stuff' non.
7. PUSH
Push ta branche sur GitHub : git push -u origin fix-login-bug. Rend tes changements visibles pour que les autres puissent les voir et les reviewer.
8. PULL REQUEST
Crée une PR sur GitHub. Décris ce que tu as changé et pourquoi. C'est là où tes coéquipiers (ou toi dans le futur) review le code avant qu'il soit live. Inclus du contexte : c'était quoi le bug ? Comment l'as-tu corrigé ? Comment les autres testent ?
9. MERGE
Après review et approbation, merge dans main. La branche de feature a fait son travail et peut être supprimée. Tes changements font maintenant partie officielle de la base de code.
10. DEPLOY
Si le déploiement automatique est configuré (comme Render), ton changement part automatiquement en ligne quand il est mergé dans main. Sinon, déclenche un déploiement manuel. Dans tous les cas, le cycle est complet — de l'idée à la fonctionnalité live.
03 · Lire
On va parcourir les étapes git clés de ce workflow ensemble. Tu as un projet qui n'est pas encore suivi par git — on l'initialise, on crée une branche de feature, on fait un changement, on le stage.
04 · Pratique terminal
Chaque projet commence par git init. Ça transforme un dossier ordinaire en repository git pour que tu puisses suivre les changements.
(Cette section est interactive — active JavaScript pour l'utiliser.)
05 · Pratique terminal
Étape 1 : BRANCH — crée une nouvelle branche de feature. Ne travaille jamais directement sur main. Les branches te laissent expérimenter en sécurité.
(Cette section est interactive — active JavaScript pour l'utiliser.)
06 · Pratique terminal
Étape 2 : CODE — fais un changement au projet. On ajoute un formulaire de login au fichier HTML.
(Cette section est interactive — active JavaScript pour l'utiliser.)
07 · Pratique terminal
Étape 3 : COMMIT — stage le fichier et commit avec un message descriptif. Un bon message de commit explique ce qui a changé et pourquoi.
(Cette section est interactive — active JavaScript pour l'utiliser.)
08 · Lire
Mi-temps — BRANCH → CODE → COMMIT terminé
Tu viens de parcourir les trois premières étapes du quotidien d'un ingénieur pro : créer une branche → écrire du code → commiter avec un message descriptif. Ce trio est fait par chaque équipe, peu importe la taille du projet.
Il reste pour la seconde mi-temps : PR (pull request) → code review → merge — comment proposer que ta branche soit intégrée dans la branche principale de l'équipe.
Pourquoi ne pas merger directement dans main ? Parce que sans review, les bugs passent sans que personne ne les arrête. La PR permet à tes coéquipiers de voir tes changements, donner leur avis, et confirmer que tout va bien avant de laisser passer. Cette couche de processus est au cœur de l'ingénierie pro.
Points clés
- Trio : branch / code / commit (terminé)
- Trois étapes restantes : push / pull request / code review + merge
- Le message de commit explique ce qui a changé et pourquoi — toi dans le futur remerciera toi d'aujourd'hui
09 · Quiz
Dans le workflow pro, qu'est-ce que tu crées avant de commencer à coder ?
- Un nouveau repo
- Une base de données
- Une nouvelle branche
- Une issue GitHub qui décrit le travail
10 · Compléter
Une fois la fonctionnalité finie, tu crées une pull _____ pour proposer le merge de tes changements.
11 · Lire
Félicitations. Tu viens de suivre le même workflow que Google, Stripe, Shopify et toutes les autres boîtes tech utilisent. L'échelle diffère, mais le workflow est le même : issue, branch, code, test, review, commit, push, PR, merge, deploy.
Les grosses boîtes bouclent ce cycle des centaines de fois par jour. Maintenant toi aussi.
12 · Quiz
Tu viens de finir d'écrire un correctif de bug sur une branche de feature. Que dois-tu faire avant de commiter ?
- Lancer git diff pour examiner tes changements ligne par ligne
- Push directement sur main
- Créer une pull request
- Supprimer la branche et recommencer
13 · Compléter
Dans le workflow pro, chaque travail commence par une _____ clairement décrite — un rapport de bug ou une demande de fonctionnalité.
Autres leçons de ce chapitre
⚠ L'expérience interactive complète nécessite JavaScript. Active-le et recharge la page.
※ Ce site est un projet éducatif indépendant — pas un produit officiel d'Anthropic. Claude™ est une marque déposée d'Anthropic, PBC.