Chapitre 13.3 — Cas d’usage & si ça te concerne
⏱️ TL;DR — Honnêtement : en tant que développeur, Cowork ne sera pas ton outil quotidien — ton goulot est le code, et c’est Claude Code (tout ce playbook). Mais il peut servir la périphérie non-code de ton activité : préparer une présentation client, compiler un rapport, organiser des documents, une veille planifiée. À l’échelle, la grande majorité de l’usage de Cowork n’est d’ailleurs pas du développement. Verdict : bon à connaître, à sortir ponctuellement pour du travail de bureau — pas un remplacement de Claude Code.
🎯 Objectifs
- Connaître les cas d’usage typiques de Cowork.
- Situer honnêtement son intérêt pour un dev.
- Repérer les rares moments où il t’aiderait vraiment.
Les cas d’usage typiques
Cowork brille sur le travail de bureau multi-étapes, par exemple :
- Décks et rapports périodiques : construire un deck de suivi hebdo à partir de données éparses.
- Préparation de réunion / brief client : synthétiser des fils de mails, des transcriptions et des actus récentes en une note de briefing.
- Organisation documentaire : trier et classer des contrats, des documents juridiques, des dossiers.
- Tableurs & données : compiler, nettoyer, extraire des données (y compris depuis des images).
- Synthèse de recherche : produire un livrable formaté à partir d’une recherche.
- Tâches récurrentes planifiées : un briefing généré automatiquement chaque lundi à 6h, sans intervention.
Le fil rouge : des tâches répétitives, multi-outils, à faible création mais chronophages — exactement ce qu’un knowledge worker délègue volontiers.
L’usage réel : surtout pas du code
Fait éclairant : à l’échelle, la grande majorité de l’usage de Cowork n’est pas du développement logiciel — c’est du travail de bureau (opérations, contenu, analyse). La presse a parlé d’une part de code de l’ordre de moins de 10 %.
📚 Aller plus loin — Ce chiffre (« ~90 % non-code ») provient de reprises de presse à partir de données d’Anthropic ; considère-le comme un ordre de grandeur communiqué, pas une statistique exacte à citer au pourcent près. Le message qualitatif est solide : Cowork est massivement utilisé hors développement — cohérent avec son public cible non-technique.
Alors, en tant que dev, ça te concerne ?
Sois lucide : ton goulot, c’est le code, et l’outil du code, c’est Claude Code. Cowork ne remplace rien de ce playbook. Mais il y a une périphérie non-code dans la vie d’un dev (surtout freelance / à son compte) où il peut aider :
Cas où il t’aiderait vraiment :
- Tu es freelance et tu passes du temps sur des propositions, rapports clients, suivis — Cowork peut absorber ce travail de bureau pendant que Claude Code fait le tien.
- Tu dois produire une présentation ou un document formaté soigné à partir de matière brute.
- Tu veux automatiser une tâche de bureau récurrente (un rapport hebdo).
Cas où il ne t’aidera pas : tout ce qui est du code, du refactor, du debug, du git — reste dans Claude Code.
⚠️ Piège — Se sentir obligé d’« adopter Cowork » parce qu’il existe. Non : adopte un outil pour un goulot réel. Si ta périphérie non-code est mince (tu es salarié, quelqu’un d’autre gère l’admin), tu n’en as tout simplement pas besoin — et c’est très bien. Le playbook qui te sert au quotidien, c’est celui de Claude Code.
🧭 Sur TaskFlow — Zéro rôle de Cowork dans le développement de TaskFlow. Le seul scénario plausible : si tu voulais un jour présenter ou vendre TaskFlow (deck, page produit, rapport), Cowork pourrait préparer ces livrables non-code pendant que tu continues à coder avec Claude Code. Deux outils, deux goulots — tu sais maintenant lequel pour quoi.
✏️ Exercices
Exercice 1 — Ta périphérie. Estime le temps que tu passes par semaine sur du non-code (propositions, rapports, admin, présentations, veille). Est-ce assez pour que Cowork vaille le coup, ou marginal ?
✅ Solution
Pour un salarié en équipe, c’est souvent marginal (→ pas besoin de Cowork). Pour un freelance / indépendant, ça peut représenter plusieurs heures (→ Cowork peut aider). Le critère est le volume réel de travail de bureau, pas la curiosité pour l’outil.
Exercice 2 — Le bon partage. Prends une vraie semaine type et répartis tes tâches en deux colonnes : Claude Code (code) vs Cowork (bureau). Le partage te confirme-t-il que Claude Code reste ton outil central ?
✅ Solution
Pour un dev, la colonne Claude Code domine largement — ce qui confirme le message de cette partie : Cowork est un complément ponctuel pour la périphérie non-code, pas le centre. Tu peux le garder « dans ta poche » sans en faire un outil quotidien.
🧠 Quiz de révision
1. Cite trois cas d’usage typiques de Cowork.
Par exemple : décks/rapports périodiques, préparation de réunion/brief client, organisation documentaire. Aussi : tableurs & extraction de données, synthèse de recherche, tâches récurrentes planifiées.
2. À l’échelle, l’usage de Cowork est-il surtout du code ?
Non : la grande majorité de l’usage est hors développement (ordre de grandeur ~90 % non-code, chiffre de presse à prendre comme approximatif). Cohérent avec son public non-technique.
3. En tant que dev, Cowork remplace-t-il Claude Code ?
Non. Ton goulot est le code → Claude Code (tout ce playbook). Cowork peut servir la périphérie non-code (propositions, rapports, présentations, veille), surtout en freelance.
4. Quand Cowork aiderait-il vraiment un dev ?
Quand la périphérie non-code est volumineuse : freelance avec beaucoup de propositions/rapports clients, production de présentations soignées, automatisation d’un rapport récurrent. Sinon, marginal.
5. Quel est le bon critère d’adoption ?
Un goulot réel, pas l’existence de l’outil. Si ta périphérie non-code est mince, tu n’as pas besoin de Cowork — et c’est très bien. Ton outil central reste Claude Code.
Fin de la Partie 13. Retour à l’essentiel : les ressources copiables du Cookbook.