L’IA n’a pas réduit ma charge de travail. Elle a réduit le nombre d’interlocuteurs.

Six gabarits de pages web. Deux versions de chacun — une annotée qui explique les choix, une propre qui se lit comme une vraie page. Un pied de page à reproduire à l’identique, deux menus déroulants à recopier au pixel, l’alternance des fonds à contrôler sur douze pages.

Une journée.

Avant, c’était un designer, un intégrateur, et une semaine. Mais je ne vais pas écrire ici que l’IA m’a fait gagner quatre jours, parce que ce n’est pas ce qui s’est passé.

L’IA n’a pas réduit ma charge de travail. La journée est restée une journée pleine. Ce qui a disparu, c’est autre chose : les briefs à rédiger, les allers-retours, les temps d’attente, les réunions d’alignement, les malentendus à rattraper. La coordination.

Ce que la production ne coûte plus

Reproduire un pied de page existant à l’identique, avec ses cinq colonnes et ses logos. Recopier un menu déroulant en respectant l’ombre portée, le retrait, la graisse et le comportement au survol. Vérifier que l’alternance des fonds tient sur l’enchaînement complet des sections, et pas seulement à l’endroit qu’on vient de modifier.

Ce sont des tâches précises, longues, et sans aucune valeur ajoutée intellectuelle. Elles ne coûtent presque plus rien.

La conséquence évidente, c’est qu’on produit plus vite. La conséquence intéressante est ailleurs.

Ce qui baisse, c’est le coût d’un refus

Si la personne qui doit valider ces maquettes décide finalement de ne rien faire, j’ai perdu une journée. Avant, j’aurais perdu une semaine et mobilisé deux personnes.

Ça ne me rend pas plus rapide. Ça change ce que j’ose proposer.

Quand une proposition coûte une semaine et deux prestataires, on ne la formule que si on est raisonnablement sûr qu’elle passera. On arrondit les angles, on présente ce qui sera accepté, on garde les idées risquées pour plus tard. Quand elle coûte une journée, on peut se permettre de proposer quelque chose qui sera refusé — et un refus argumenté fait souvent plus avancer une réflexion qu’une validation molle.

C’est le premier effet d’organisation, et il ne se voit dans aucun tableau de productivité.

Ce que j’ai dû rattraper

Voici la liste exacte des corrections que j’ai apportées au fil de la journée.

• Un menu déroulant entier manquait.
• Le second existait, mais ne ressemblait pas à celui du site : bordure visible, fond au survol, largeur trop étroite.
• Le formulaire avait des libellés au-dessus des champs alors que l’original utilise des placeholders, et un encadré blanc qui n’existe pas.
• L’alternance des fonds était cassée. Deux fois : la première correction n’avait traité qu’une jointure, pas la chaîne complète.
• Le pied de page n’était pas celui du site.
• Un point à la place d’un deux-points dans une phrase reprise à l’identique.
• Et l’ordre de navigation des maquettes contredisait le récit du document qui les accompagnait.

Aucune de ces erreurs n’a été détectée par l’IA. Elle les a produites. Toutes ont été rattrapées par mon œil.

Or je traîne vingt-cinq ans de web derrière moi. Je sais qu’une bordure ne devrait pas être là. Je sais qu’un formulaire en placeholders n’est pas un formulaire à libellés. Je repère une alternance de fonds cassée en faisant défiler une page.

Un Product Manager sans ce bagage aurait livré la première version sans voir les écarts. Et c’est là que se trouve le vrai sujet.

Le designer n’apportait pas que de l’exécution

J’ai sorti un designer et un intégrateur de la boucle. C’est un fait, et il est tentant d’en conclure qu’on peut se passer d’eux.

Ce serait une erreur de lecture. Ils n’apportaient pas seulement de la production : ils apportaient un jugement. Le fait que je m’en sois passé tient à ce que je porte une partie de ce jugement moi-même, par accident de parcours — pas parce que la machine l’a remplacé.

Quand on retire un rôle d’une boucle, on ne retire pas seulement ses tâches. On retire aussi le contrôle qu’il exerçait sans qu’on le lui demande. Si personne ne reprend ce contrôle, on ne produit pas plus vite : on produit plus vite du travail qui ne sera pas vu.

C’est la même logique que celle que je décrivais à propos de la vérification : je délègue l’exécution, jamais le contrôle. À l’échelle d’une équipe, la question devient : qui porte le contrôle que l’on vient de retirer, et est-ce explicite ou implicite ?

Où le goulot s’est déplacé

À la fin de cette journée, le document que j’ai envoyé se terminait par quatre questions. Qui relit et valide les contenus spécialisés. Qui s’engage à les actualiser dans un an. Laquelle de deux informations contradictoires présentes sur le site fait foi. Et laquelle de deux listes d’engagements est la bonne.

Aucune de ces quatre questions ne peut être tranchée par moi, ni par une IA. Toutes bloquent la suite.

Produire les déclinaisons suivantes ne coûte presque plus rien. Décider si elles doivent exister, si.

Le risque bascule avec le goulot. Tant que produire était lent, le danger était d’aller trop lentement. Quand produire devient quasi gratuit, le danger devient l’inverse : décliner à l’identique une même page en dix exemplaires, sans que personne n’ait tranché ce qui les distingue réellement. Google sait très bien reconnaître ce type de production, et la sanctionne.

Ce que ça change pour une équipe produit

Mon cas était solitaire. Une équipe produit fonctionne autrement : un PM, des développeurs, un designer, des cycles qui s’enchaînent. Le raccourci que je décris ne s’y applique pas partout.

Il ne remplace pas le delivery. Il remplace l’amont — le prototype de discovery qu’on faisait fabriquer avant d’avoir décidé quoi que ce soit.

Et si c’est bien là que ça se joue, alors la conséquence n’est pas celle qu’on annonce partout. Ce qui change n’est pas la taille de l’équipe. C’est le moment où elle est engagée.

Plus tard. Sur des décisions déjà prises, des hypothèses déjà testées, des options déjà écartées. Une équipe qui démarre sur un périmètre tranché plutôt que sur une intuition à explorer.

Trois conséquences pratiques, que je formule comme des hypothèses parce que je ne les ai pas encore vérifiées à l’échelle d’une équipe :

• Le PM produit moins de spécifications et prend plus de décisions. Ce qu’il apporte en entrée de cycle n’est plus un document à interpréter, c’est une chose à regarder — et une question tranchée.
• Le rôle du designer se déplace de la production vers le jugement. Ce déplacement doit être organisé explicitement, pas supposé. Sinon il ne se produit pas : le rôle disparaît simplement, et le jugement avec lui.
• Le temps gagné ne revient pas à l’équipe, il revient à la décision. Si l’organisation ne sait pas trancher plus vite, elle ne fera qu’accumuler des prototypes en attente d’arbitrage.

Ce que je retiens

Un prototype fait seul en une journée ne remplace pas une équipe. Il déplace le moment où elle intervient, et il déplace le goulot d’étranglement vers l’endroit où il était déjà — la décision.

La question qu’un Head of Product devrait se poser n’est donc pas « combien de personnes puis-je économiser ». C’est : qui, dans mon organisation, portait le jugement que je m’apprête à retirer de la boucle, et où va-t-il se loger maintenant ?

Sur la manière dont je conduis une équipe produit au quotidien — rituels, arbitrages, relation aux parties prenantes —, j’ai détaillé ma pratique dans piloter une équipe produit.

Et chez vous, à quel moment l’équipe est-elle engagée ? Partagez vos retours en commentaire.