Pourquoi les skills overkill produisent du workslop, pas du deep work

Je cherche en permanence à optimiser mon process. Et honnêtement, c’est exactement ce comportement qui me mène au workslop aujourd’hui.

Le mot n’est pas de moi. Des chercheurs de BetterUp Labs et du Social Media Lab de Stanford l’ont forgé dans la Harvard Business Review en septembre 2025, pour désigner un travail généré par l’IA qui a l’air soigné mais ne porte rien qui fasse avancer la tâche. Leur enquête relève que 40 % des employés de bureau américains en ont reçu, et qu’il faut environ deux heures pour réparer chaque cas.

Je teste beaucoup de plugins et de skills. Les workflows RPI, gstack, le setup Claude Code de Garry Tan, vingt-trois skills qui jouent le CEO, le designer, l’eng manager, le QA lead et le release engineer. J’ai même construit mon propre skill decision-ledger. Il y a des cas où rien de tout ça n’est productif, et des cas où ça ajoute activement de la complexité.

Rembobinons deux ans en arrière, avant l’arrivée de l’IA. J’étais un de ces développeurs qui bossaient pour des grands groupes. Et un de ces développeurs qui n’ont jamais compris pourquoi il fallait dix personnes dans une réunion pour décider de la couleur d’un bouton.

Aujourd’hui, je me surprends à agir comme ces gens-là. Pour deux raisons :

• Je sais que l’IA a besoin d’un workflow, sinon on récolte du slop et des décisions hors contexte.
• Je crois que mon process doit être parfait dès la première ligne de spec, sinon le projet aura l’air généré et le code sera à jeter.

Les deux sont vraies, jusqu’à un certain point. Je les ai vécues.

La douleur de lancer un SaaS avec l’IA quand on est développeur

J’ai lancé Getzatjob, mon premier SaaS IA, pour répondre à un besoin précis : identifier mes forces et mes faiblesses pour une candidature, et trouver le positionnement de CV qui passe les ATS. Avec le recul, le projet était mon bac à sable. Il est rapidement devenu un tas de fonctionnalités codées par l’IA que je n’ai jamais eu envie de lire, et au début je me répétais « tant pis ». Ça, c’est du vrai vibe coding, et honnêtement, c’est douloureux. Et l’UI, arggg, pas terrible.

Développer en balançant une pile de prompts sans jamais rien vérifier, avec « ça marche » comme seul argument — jusqu’à la première vague de bugs qui m’a fait comprendre que le produit était un chantier, et qu’il fallait le refactorer depuis la toute première ligne de code.

Alors quand j’ai décidé de construire Getzatjob V2, devenu Applyzi, je me suis mis à gstack et je lui ai donné beaucoup plus d’informations sur ma façon de coder. Ma devise était la suivante : je veux un produit dont je comprends le code, codé comme je l’aurais codé, et assez soigné pour qu’un recruteur d’une boîte IA le regarde et se dise : ce type sort un produit avec la qualité qu’on voudrait de notre propre équipe. Comme ça, j’avais plaisir à y travailler.

L’autre grande différence, c’était le rythme de livraison. Avec Getzatjob, j’avais 80 % du projet en surface en moins de 24 heures. C’est la promesse qu’on voit passer sur les réseaux. Super. Après quoi j’ai passé des semaines à empiler des fonctionnalités et à dupliquer du code pourri par-dessus des prompts paresseux.

Avec Applyzi, il a fallu trois à quatre semaines à planifier et contrôler chaque fonctionnalité, à dépenser plus de crédits pour rendre mes composants React réutilisables. Exactement comme je faisais avant. Ça m’a coûté plus de temps au départ, mais trois mois plus tard le projet est maintenable et scalable, et je n’ai pas peur d’en recoder des morceaux moi-même.

Quand le workslop entre en scène

J’avais une fonctionnalité à développer sur un projet que je suis depuis 2021 pour une entreprise — avant l’IA, donc. Ajouter des données à un écran existant, et ajouter un écran de plus. Cinq, peut-être six fichiers impactés. Mon workflow actuel quand c’est de la simple intégration d’interface : je prends une capture Figma — pas de Figma premium ici, donc pas de MCP — et je la donne à Claude.

Ensuite je vais dans mon historique git sous VS Code, je regarde les fichiers modifiés, je les lis, j’ajoute mes corrections à la main, et c’est fini. Trente minutes : dix d’IA, vingt de finition. Contre une heure si je l’avais fait à la main.

Pour l’expérience, j’ai lancé la méthode RPI à la place. Research → Plan → Implement, avec une porte de validation à chaque phase. Sur le papier, c’est un bon workflow. En pratique, sur mes six fichiers, c’était l’overkill parfait. Elle a passé des minutes à identifier des « points de douleur » dans le projet, lu le codebase en entier, contredit ses propres conclusions en chemin, et fini par me tendre un plan cinquante fois plus gros que les quelques lignes que je devais ajouter.

Regardez ce que la phase de recherche lance vraiment : un requirement parser, un product manager, un UX designer, un CTO advisor technique, un senior software engineer, un rédacteur de documentation. Six rôles. Pour ajouter des données à un écran.

J’ai pris du recul et je me suis dit : c’est la réunion à dix pour la couleur d’un bouton. Pas comme métaphore. Littéralement la même salle, avec des agents à la place des collègues. C’est du workslop, et cette fois je le voyais se produire. Lire le rapport de l’IA était plus pénible qu’écrire le code moi-même.

Et pour être clair, je ne dis pas que l’outillage est mauvais. Le workflow RPI ou gstack sont des équipes d’ingénierie virtuelles, et une équipe d’ingénierie virtuelle, c’est exactement ce qu’il faut à une refonte complète de produit. C’est ce qui a fait marcher Applyzi. Six fichiers ne sont pas une refonte de produit. Même cérémonie, mauvaise taille de problème.

Boris Cherny, le créateur de Claude Code, dit qu’il fait désormais globalement confiance au modèle pour lancer les bonnes commandes et faire les bonnes modifications, et qu’il regarde simplement le résultat final. Faire confiance à l’IA.

Mais lisez les mêmes fils jusqu’au bout, et le conseil le plus important est toujours le même : assurez-vous que Claude a un moyen de vérifier son travail. La confiance n’exclut donc pas le contrôle. Elle veut juste dire que le contrôle, c’est la vérification, pas un plan de cinquante pages écrit avant la moindre ligne de code.

Les process IA sont non déterministes, comme l’IA elle-même. Il n’y a pas une seule façon de travailler qui convienne à tous les projets — ça vient de l’équipe Claude Code aussi, et Boris décrit son propre setup comme « étonnamment vanilla ». La personne qui a construit l’outil le personnalise à peine. Pendant ce temps, j’empilais RPI sur des skills sur des plugins pour un changement de six fichiers.

Mon projet de 2021, construit à la main sans IA, n’a pas besoin de grand-chose comme workflow IA. Il a besoin d’un prompt, d’une capture d’écran, et d’un contrôle humain avant le commit.

Deep Work a plus de sens aujourd’hui que le jour de sa sortie

Le livre de Cal Newport frappe plus fort maintenant qu’à sa parution. Les gens font plus que ce qu’ils étaient censés faire, et plus que ce qu’ils sont réellement capables de faire.

Le meilleur exemple, c’est LinkedIn. Ouvrez votre fil, regardez les cinq derniers posts, et dites-moi combien ont été écrits à la main et portent une vraie information venant de quelqu’un qui maîtrise son sujet. L’IA donne aux gens l’illusion de la productivité : des posts IA, du « partage d’expertise ».

Comme je le disais plus haut, les dix personnes dans la salle pour la couleur d’un bouton n’ont pas eu besoin de l’IA pour en arriver là. Mais l’IA élargit le terrain de jeu de ce genre de travail.

Rien de tout ça ne veut dire que l’IA n’ajoute que du bruit. Elle me permet aussi de construire des choses que je n’aurais jamais lancées avant, parce qu’elles coûtaient trop de temps. Un motion design pour expliquer une fonctionnalité de mon SaaS, par exemple, grâce à hyperframes. Je ne me serais jamais lancé dans le format court si l’IA ne pouvait pas m’aider à écrire le script et générer le motion design. Cette partie-là est réelle, et ce n’est pas du workslop.

La bonne question à se poser est celle-ci : la tâche que je fais avec l’IA sera-t-elle encore là dans trente jours ? Est-ce que je fais quelque chose que j’aurais fait sans l’IA ? Prenez du recul sur la façon dont vous construisez le projet, et demandez-vous en même temps pourquoi vous le construisez.

Sources

• Kate Niederhoffer, Gabriella Rosen Kellerman, Angela Lee, Alex Liebscher, Kristina Rapuano et Jeffrey T. Hancock, AI-Generated “Workslop” Is Destroying Productivity, Harvard Business Review, 22 septembre 2025 — l’étude menée par BetterUp Labs avec le Social Media Lab de Stanford.
• Shan Raisshan, claude-code-best-practice — le workflow RPI, et les compilations de conseils de Boris Cherny citées plus haut.
• Garry Tan, gstack.
• Cal Newport, Deep Work, Grand Central Publishing, 2016.
• HeyGen, hyperframes.

Illustrations générées pour cet article.