Choisir votre parcours de départ en ingénierie assistée par IA
Choisissez entre Claude Code et Cowork, puis suivez le parcours Start, Build ou Scale adapté à votre rôle et à votre problème opérationnel actuel.
Aller au résumé ↓
Florian BruniauxTL;DR
Le glossaire d’abord. Avant tout plugin, serveur MCP ou config copiée chez quelqu’un, je lis le glossaire, et je pense que la plupart des personnes qui débutent avec Claude Code devraient faire pareil. Ensuite, je ne passe au déploiement dans une équipe qu’une fois qu’un workflow fonctionne pour une personne et que je peux montrer où il échoue.
| Sujet | Détails |
|---|---|
| Premier choix | Claude Code pour le travail sur un repository dans un terminal ; Cowork pour les tâches intellectuelles dans Claude Desktop |
| Démarrer | Terminer une vraie tâche en préservant compréhension et contrôle |
| Développer | Transformer les éléments utiles en contexte, workflow et vérification reproductibles |
| Passer à l’échelle | Ajouter contrôles partagés, mesures, responsabilité et gouvernance lorsque la coordination le demande |
| Configuration Claude Code | Suivre le guide de configuration niveau par niveau plutôt que reconstruire la procédure à partir de cet article |
La semaine dernière, quelqu’un m’a envoyé un message sur Slack :
“Hi Florian. I’m trying to get Claude Code up and running to improve my productivity. I started a week ago, but I’ve been using other agentic AI tools at work for months. I have a solid backend/QA background. After seeing your message I’ll admit I’m a bit lost with all the features, plugins, etc. Where would you suggest I start?”
Traduction fidèle : « Salut Florian. J’essaie de mettre Claude Code en route pour améliorer ma productivité. J’ai commencé il y a une semaine, mais j’utilise d’autres outils IA agentiques au travail depuis des mois. J’ai un solide parcours backend/QA. Après avoir vu ton message, j’avoue être un peu perdu parmi toutes les fonctionnalités, plugins, etc. Par quoi me conseillerais-tu de commencer ? »
J’ai immédiatement reconnu le profil, pour l’avoir vu plus de 20 fois. Développeur expérimenté, des mois d’IA agentique derrière lui, mais Claude Code semble différent de tout ce qu’il a utilisé. Face à une mer de fonctionnalités, sans carte.
Je lui ai envoyé la même réponse qu’à chaque fois : un bloc de liens avec de brèves descriptions, assez pour s’orienter, pas assez pour expliquer pourquoi l’ordre compte.
Cet article est la couche d’orientation de cette réponse. Il aide à choisir un produit, un parcours de lecture et une étape d’adoption. Si le choix est Claude Code, le guide de configuration niveau par niveau est la procédure d’implémentation de référence.
Choisir le produit selon la tâche
Utilisez Claude Code lorsque le travail se fait dans un repository et nécessite commandes de terminal, changements de fichiers, tests ou gestion de versions. Sa couche de configuration comprend fichiers CLAUDE.md, hooks, skills, serveurs MCP et commandes.
Utilisez Cowork pour des tâches principalement axées sur la recherche, les documents, la synthèse, la préparation ou une autre activité intellectuelle dans Claude Desktop. Un contributeur non technique n’a pas besoin d’adopter un workflow de terminal pour bénéficier d’une tâche bornée et d’une review explicite.
Les deux parcours peuvent coexister. Choisissez selon la tâche et les contrôles requis. Aucun produit n’est une étape supérieure.
Pourquoi Claude Code semble différent
La plupart des outils IA s’insèrent dans un workflow existant. Vous ouvrez une fenêtre de chat, décrivez un problème, obtenez une réponse. Claude Code se rapproche d’un environnement de développement avec sa propre couche de configuration : fichiers CLAUDE.md, hooks, skills, serveurs MCP, commandes slash, gestion du contexte. Le périmètre est beaucoup plus large, et le modèle d’interaction suppose des choix délibérés sur son comportement.
Cet écart explique pourquoi même des ingénieurs expérimentés se perdent. Le prérequis implicite est de comprendre ce qu’il est possible de configurer avant de configurer utilement.
La présentation officielle de l’architecture décrit une boucle qui rassemble le contexte, agit via des outils et vérifie les résultats. Les résultats des outils alimentent les décisions suivantes. Comprendre cette boucle est plus utile ici que mémoriser un nombre fixe d’outils ou supposer que chaque tour repart indépendamment.
Après avoir observé de nombreux onboardings, j’utilise cet ordre : vocabulaire, orientation, première config, puis extensions. Sauter les deux premières étapes produit souvent une installation impressionnante qui ne change pas votre façon de travailler.
Commencer par le vocabulaire
J’ai passé ma première vraie semaine avec Claude Code à modifier un fichier de configuration trouvé sur GitHub. Il avait l’air correct, venait de quelqu’un dont je respectais l’installation, et j’ai passé une soirée à l’adapter. Deux jours plus tard, j’ai compris que je modifiais les mauvaises sections, pour de mauvaises raisons, sans comprendre la moitié des champs. La configuration était plus longue, pas plus utile.
L’heure finalement passée sur le glossaire a changé plus de choses que cette soirée entière. C’est de la documentation de référence : elle a rendu « hook », « skill » et « MCP server » concrets plutôt que de vagues mots pour des choses mal comprises. Le reste de la documentation a cessé d’être un mur de jargon. Savoir que la fenêtre de contexte concerne les informations disponibles dans une conversation aide à la distinguer des limites d’usage du compte et des réglages de facturation. La capacité disponible dépend du modèle et du produit actuels ; un pourcentage fixe n’est pas un seuil universel de qualité.
Commencez par le glossaire cc.bruniaux.com. Puis, si vous êtes visuel, les diagrammes cc.bruniaux.com. Ils montrent les liens en pratique : déclenchement d’un hook, invocation d’un skill, relation entre session et tâche. Voir le système dessiné avant d’y toucher est plus rapide que d’en découvrir la structure en cassant des choses.
Pour le comportement actuel, consultez la documentation Claude Code sur les coûts et l’usage et les réglages d’usage des offres payantes. Activer l’usage payant supplémentaire est une décision de dépense, pas une étape d’onboarding par défaut.
Choisir l’étape d’adoption, puis utiliser le guide de configuration
Les noms Start, Build et Scale décrivent votre problème opérationnel actuel. Ce ne sont pas des scores et ils n’imposent pas un déploiement linéaire.
| Étape | À utiliser lorsque | Prochaine destination |
|---|---|---|
| Démarrer | Vous devez terminer une vraie tâche de repository sans perdre compréhension ni contrôle | Exécuter le prompt d’onboarding personnalisé, puis suivre les premiers niveaux du guide de configuration Claude Code |
| Développer | Votre pratique individuelle est utile, mais sa répétabilité dépend de la mémoire ou d’étapes manuelles | Utiliser le même guide pour structurer CLAUDE.md, l’hygiène des sessions et un contrôle de vérification avant d’ajouter des extensions |
| Passer à l’échelle | Plusieurs contributeurs ou repositories nécessitent responsabilité partagée, auditabilité, contrôles de coût ou gouvernance | Commencer par les rôles, méthodologies et mesures d’équipe |
L’orientation la plus rapide pour Claude Code reste cette commande :
claude "Fetch and follow the onboarding instructions from: https://raw.githubusercontent.com/FlorianBruniaux/claude-code-ultimate-guide/main/tools/onboarding-prompt.md"Elle demande votre profil, niveau et objectif, puis sélectionne la documentation pertinente. Une fois Claude Code choisi, poursuivez dans le guide de configuration niveau par niveau. C’est lui qui définit la séquence d’implémentation, d’un petit CLAUDE.md aux hooks et à l’hygiène des sessions. Cet article ne répète pas ces étapes.
Utilisez le catalogue complémentaire seulement quand une tâche crée le besoin. Les fiches récapitulatives fournissent des références compactes, les exemples des artefacts réutilisables et les livres blancs couvrent sécurité, coût, confidentialité et rôles d’équipe. Installer serveurs MCP ou hooks copiés avant que le workflow de base fonctionne rend les échecs plus difficiles à localiser.
Choisir le parcours selon votre profil
Backend / QA
Commencez par une tâche de repository et le guide de configuration Claude Code. Pour un profil QA, les hooks de test et exemples SonarCloud deviennent pertinents à l’étape Build, une fois que la tâche de base et le parcours de review fonctionnent. L’article UVAL traite de l’écart entre décrire du code généré et l’expliquer ; la référence d’implémentation est sur cc.bruniaux.com/learning.
Engineering manager / team lead
Commencez par les rôles et méthodologies, puis déterminez si le problème actuel est l’onboarding individuel, la répétabilité ou la gouvernance partagée. L’article sur la vélocité rapporte sept mois de gains et de dette à l’échelle d’une équipe. Le live couvre la configuration d’équipe et l’onboarding d’un contributeur non technique jusqu’à la production en dix jours.
Créateur solo / founding engineer
Commencez par le guide de configuration niveau par niveau et ouvrez le guide complet quand une tâche nécessite davantage de profondeur. Les contrôles de coût et de confidentialité peuvent devenir pertinents avant l’adoption en équipe si vous traitez des données de production ou utilisez un mécanisme de repli vers une API payante.
Contributeur non technique
Commencez par le cas d’Augustin si l’objectif est de contribuer au logiciel. Pour de la recherche, des documents, de la synthèse ou de la préparation, utilisez le guide Cowork plutôt que d’hériter d’une installation centrée sur le terminal que le travail n’exige pas.
Passer à l’échelle après avoir rendu le parcours individuel observable
Quand un outil paraît utile, le réflexe est de le déployer immédiatement dans toute l’équipe. Je l’ai fait chez Méthode Aristote et passé deux semaines à nettoyer des configurations qui ne correspondaient à l’installation réelle de personne. La personne qui déploie l’outil a besoin de preuves sur ses réussites et ses échecs avant de bien le configurer pour les autres.
Passez de l’usage individuel au déploiement d’équipe quand vous pouvez reproduire un workflow utile, expliquer sa configuration et ses permissions, montrer comment les échecs sont détectés et comment on reprend après un échec, et nommer le responsable des mises à jour. Ces conditions de sortie sont observables, pas temporelles. Différents workflows peuvent les atteindre à différents moments, et un cas plus risqué peut demander un nouveau passage par Build avant Scale.
Un exemple concret d’« understanding where it breaks » (traduction : « comprendre où cela casse ») : un collègue avait activé par accident le repli API sur son compte. Je l’ai détecté plusieurs jours trop tard, une fois qu’un usage normal avait généré une facture de 300 à 400 €. Examiner les réglages de compte et de repli dans le contrôle de préparation aurait mis ce risque précis en évidence avant le déploiement. Cela n’empêcherait pas toute erreur de facturation.
Les configs par profil facilitent la transmission. Au lieu de donner à tous le même CLAUDE.md, vous générez des configurations adaptées au rôle, à l’OS et au workflow de chacun. Le profil d’Augustin produisait 289 lignes. Le mien, 703. Cet écart de 59 % comptait : les sections sans rapport de ma config étaient du bruit pour quelqu’un sous Windows qui n’avait jamais ouvert un terminal, et trop de contexte perturbe tout autant le modèle.
Pour le suivi continu, cc.bruniaux.com/team-metrics couvre les mesures à prendre, et ccboard est le tableau de bord que j’ai créé pour les voir en direct, coût, état des hooks et statut MCP au même endroit. Le flux RSS cc.bruniaux.com/rss.xml couvre les versions Claude Code et mises à jour du guide sans vérification manuelle répétée.
Une fois Claude Code choisi
La réponse est peu spectaculaire : le glossaire d’abord. Pas les plugins, serveurs MCP ou fichiers de configuration de développeurs que je respecte, seulement le glossaire.
J’ai passé les premières semaines à construire sur un vocabulaire que je devinais. Tout prenait plus longtemps parce que je corrigeais des hypothèses fausses tout en essayant de livrer. Les 45 minutes finalement passées sur le glossaire ont réorganisé ma compréhension de tout l’outil. J’ai maintenant vu cela chez assez de personnes pour être raisonnablement confiant que ce n’est pas propre à mon installation. La configuration devient abordable quand les mots cessent d’être flous.
Les extensions sont vraiment utiles, souvent plus que la config de base une fois les bonnes trouvées. Faites simplement fonctionner la config avant de les ajouter.
Une fois le vocabulaire compris et le premier CLAUDE.md en place, la couche suivante est naturellement la mécanique : fonctionnement de la boucle d’agent, poids de la config, ce que les hooks imposent ou non. Claude Code sous le capot couvre l’ensemble : boucle d’agent, gestion du contexte, frontières de permissions et portée des contrôles imposés par les hooks.
Le guide de configuration parcourt chaque couche dans l’ordre, du premier CLAUDE.md de dix lignes aux hooks et à l’hygiène des sessions, avec le mode d’échec corrigé à chaque niveau.
La décision d’orientation
Choisissez Claude Code pour le travail sur repository ou Cowork pour le travail intellectuel. Dans Claude Code, utilisez Start pour la première tâche maîtrisée, Build pour le contexte et les vérifications reproductibles et Scale pour les contrôles partagés. Le guide de configuration définit la procédure ; cet article indique à chaque lecteur son point d’entrée.
Si vous êtes la personne qui a envoyé ce message : je suis curieux de savoir quelle condition de préparation vous a bloqué après le premier workflow utile. Envoyez-moi un message ou laissez un commentaire, et j’actualiserai l’article avec ce que j’apprends. Même proposition pour toute personne dans la même situation.
Toutes les ressources liées ici sont sur cc.bruniaux.com. Le guide est open source sur github.com/FlorianBruniaux/claude-code-ultimate-guide.
YSNK
(Ce que vous devriez maintenant savoir)
- Contexte de conversation, limites de compte et usage payant supplémentaire sont des contrôles séparés ; lisez les réglages actuels du compte
- Capacité de contexte et politiques d’usage dépendent du produit, du modèle et de l’offre actuels ; aucune réserve ni fréquence de remise à zéro fixe n’est supposée ici
- Claude Code convient au travail sur repository avec terminal, fichiers, tests et gestion de versions ; Cowork aux tâches intellectuelles dans Claude Desktop
- Start, Build et Scale décrivent le problème opérationnel actuel plutôt qu’un rang de l’utilisateur ou une obligation de déploiement linéaire
- Le guide de configuration niveau par niveau est la procédure d’implémentation de référence une fois Claude Code choisi
Pour aller plus loin dans le guide Claude Code
Des ressources pratiques sélectionnées pour prolonger ce sujet.
Galaxie open source