En mode IA-first, produire ne coûte presque plus rien — c'est valider qui devient le goulot

Le jour où produire est devenu la partie facile

La première fois que j'ai bâti une maquette fonctionnelle complète en une soirée au lieu d'une semaine, j'ai compris que mon métier venait de changer de centre de gravité. Pas l'outil — le métier. Longtemps, l'essentiel de mon travail a consisté à produire : dessiner, coder, rédiger, assembler. La production était le goulot, et tout mon processus était organisé pour la protéger. On planifiait longuement, on validait le brief, on visait juste du premier coup, parce qu'une deuxième version coûtait cher.

En mode IA-first, ce calcul s'effondre. Produire une première version ne coûte presque plus rien. Et quand la production devient quasi gratuite, ce n'est pas la vitesse qui change vraiment — c'est l'endroit où se trouve le travail. Il glisse en aval, vers le jugement, la sélection et la validation. C'est là, maintenant, que la qualité se gagne ou se perd.

L'unité de travail n'est plus le livrable, c'est l'itération

Dans un modèle classique, on avance en ligne droite : on planifie, on exécute, on livre. Comme chaque version demande du temps et de l'énergie, on cherche à éviter l'erreur avant de produire. Tout le monde a déjà vécu le PRD de quinze pages écrit avant la moindre ligne de code — le document qui tente de prévoir ce qu'on ne saura vraiment qu'en construisant.

En IA-first, on inverse l'ordre. Le coût d'une première version chute au point qu'il devient plus rapide de la fabriquer que de la décrire. On ne planifie plus d'abord pour éviter les erreurs, mais pour tester vite, comparer plusieurs pistes et apprendre. L'unité de travail n'est plus le livrable final : c'est l'itération. Et ce n'est pas un gain de productivité parmi d'autres — ça change ce qu'on optimise. C'est le même basculement que je décrivais à propos des sites statiques contre WordPress : l'IA ne se contente pas d'accélérer l'ancien processus, elle en change la logique.

Ce qui change concrètement

Le prototype devient un outil de réflexion, pas juste de production

Dans une approche classique, on rédige un document, un brief, un PRD, puis on construit. En IA-first, on génère plusieurs versions fonctionnelles d'une idée avant même d'avoir toutes les réponses. Le prototype cesse d'être l'aboutissement du processus pour en devenir le moteur.

Quand j'ai construit mon app de gestion de dépenses avec Claude Code, je n'ai pas attendu le PRD parfait pour commencer. J'ai laissé le prototype trancher les questions que le document n'arrivait pas à fermer. Au lieu de décrire longuement une solution hypothétique, on la rend visible assez tôt pour la critiquer, l'améliorer ou l'abandonner. Et abandonner une maquette d'une soirée ne fait pas mal ; abandonner trois semaines de travail, oui — c'est là qu'on s'entête sur une mauvaise idée juste parce qu'elle a coûté cher.

On explore en largeur avant d'aller en profondeur

Le travail classique pousse à choisir une direction, puis à l'approfondir, parce qu'on n'a les moyens d'en creuser qu'une seule. L'IA-first permet d'explorer plusieurs pistes en parallèle : différents concepts, plusieurs maquettes, diverses structures de page, plusieurs tonalités de contenu.

Le piège, c'est de confondre cette largeur avec du progrès. Générer dix directions ne vaut rien si on est incapable d'en éliminer huit rapidement. La compétence qui devient rare, ce n'est plus la capacité à produire — c'est la capacité à choisir. Savoir tuer une bonne option parce qu'une autre est meilleure, voilà le travail. La valeur se déplace de la main vers l'œil.

Le rôle passe de producteur à directeur

Avec l'IA, j'écris moins à partir de zéro, je code moins à partir de zéro, je conçois moins devant une page blanche. Ça ne diminue pas le rôle humain ; ça le déplace. Le travail glisse vers le cadrage, la direction, la critique, la cohérence, la décision. Il faut savoir quoi demander, quoi garder, quoi corriger, quoi jeter.

Le vrai danger n'est pas que l'IA produise du mauvais travail. C'est qu'elle produise du travail plausible — propre, crédible, convaincant — et qu'on lui délègue le jugement par-dessus le marché. L'IA génère, propose, accélère, mais elle n'a aucune responsabilité réelle ni aucune compréhension complète du contexte. Si le résultat est faux, ce n'est pas elle qui répond au client. Déléguer l'exécution, d'accord ; déléguer le jugement, jamais. C'est la ligne que je refuse de franchir.

La vérification devient le vrai goulot

Voici le cœur de l'affaire. Quand produire devient extrêmement rapide, ce n'est plus la création qui ralentit le travail. C'est la validation. Le goulot ne disparaît pas : il se déplace d'un cran en aval, là où, justement, on le surveille moins.

Le texte est-il exact ? Le code est-il sécuritaire ? Le design tient-il d'un écran à l'autre ? La solution répond-elle au besoin, ou seulement à la demande ? Le prototype peut-il devenir un produit viable, ou s'effondre-t-il dès qu'on le pousse ? Chacune de ces questions exige un humain capable de juger — et ce travail-là ne s'est pas accéléré au même rythme que la génération.

C'est pour ça que l'audit, la revue, les tests et la mise en production prennent encore plus de valeur en IA-first, pas moins. Ce n'est pas parce qu'il est devenu facile de produire dix fois plus qu'il faut baisser les exigences. C'est l'inverse : plus le volume monte, plus la capacité à dire « non, ça ne passe pas » devient précieuse.

Le contexte devient l'actif principal

Dans un modèle classique, la valeur est collée au livrable : une page, une maquette, un document, une campagne. En IA-first, une grande part de cette valeur migre vers le contexte réutilisable — les prompts système, les conventions, le design system, les composants, les modèles de PRD, les règles de marque, les exemples validés, les bases de connaissances.

C'est exactement le glissement que je décrivais en passant du prompt engineering au context engineering : ce n'est plus la formule magique d'un prompt qui fait la qualité, mais tout l'environnement qu'on structure autour du modèle. C'est aussi pourquoi je passe autant de temps à donner à Claude le design system et la voix de mes clients plutôt qu'à corriger chaque sortie à la main. On ne bâtit plus seulement des livrables : on bâtit des systèmes capables d'en produire d'autres, plus vite et avec plus de cohérence.

Mais — et c'est la nuance que trop de gens ratent — plus de contexte n'est pas toujours mieux. Empiler les directives finit souvent par produire l'effet inverse de celui qu'on cherche. Au-delà d'un certain point, trop de contraintes enferment le modèle dans des réponses prévisibles, répétitives, sans relief. L'objectif n'a jamais été de fournir le maximum d'informations, mais les bonnes. Construire du contexte, ce n'est pas accumuler : c'est calibrer.

La qualité des données devient stratégique

L'IA s'appuie entièrement sur ce qu'on lui donne. Si les données sont incomplètes, contradictoires ou mal structurées, les résultats héritent de ces défauts — sans prévenir. À l'inverse, quelques exemples bien choisis et représentatifs battent souvent une montagne d'informations vaguement pertinentes. L'enjeu n'est pas la quantité de données, mais leur qualité, leur fraîcheur et leur adéquation à l'objectif. Je préfère cinq exemples impeccables à cinquante exemples tièdes : le modèle apprend la moyenne de ce qu'on lui montre.

Le vrai risque : beaucoup de mouvement, aucune direction

Le mode IA-first a un défaut de structure. Il rend tellement facile de générer des idées, des textes, des interfaces et des prototypes qu'on peut accumuler des dizaines de versions sans jamais savoir laquelle est réellement meilleure. Du mouvement, beaucoup de mouvement — mais pas forcément une direction.

S'ajoute un deuxième piège, plus sournois : croire qu'en ajoutant toujours plus de règles, de contexte et de directives, on obtiendra mécaniquement de meilleurs résultats. Dans les faits, ça enferme souvent l'IA dans des schémas répétitifs et étouffe l'exploration des solutions neuves.

La discipline qui sauve tient là : définir les critères avant de générer. Sans critère décidé d'avance, on ne compare pas des options, on accumule des possibilités — et on se raconte que c'est du travail.

En résumé : on ne cherche plus la bonne version, on cherche à la trouver plus vite

Le travail classique cherche à réduire l'erreur avant de produire. Le travail IA-first accepte l'erreur comme une étape normale, mais la rend rapide, visible et peu coûteuse. Ce n'est pas une permission de baisser la garde : c'est un déplacement de l'endroit où on met sa rigueur.

L'IA peut exploiter énormément de données et de contexte, mais la performance ne dépend pas de la quantité d'informations qu'on déverse. Elle dépend de la qualité du cadrage, de la pertinence du contexte et de la capacité humaine à évaluer ce qui sort. La machine a rendu la production presque gratuite ; elle n'a pas rendu le jugement optionnel.

La différence de fond tient en une phrase : on ne travaille plus pour produire une bonne version, on travaille pour bâtir un système qui aide à trouver la bonne version plus vite — sans jamais perdre le jugement nécessaire pour distinguer ce qui est réellement utile de ce qui est seulement facile à générer.