Angle
Un Product Manager outillé d'un assistant de code produit en quatre jours ce qui lui aurait pris un mois, et cette vitesse ne dit rien de ce qu'il a le droit de construire. Ce qui le dit est l'état du terrain sur lequel il pose son travail : un catalogue d'API internes à jour lui épargne les détours qui fabriquent l'incohérence ; des tests qui portent l'intention métier lui rendent une prise sur un code qu'il n'a pas lu ; une codebase dont le langage métier est lisible décide seule s'il compose avec des briques existantes ou bricole à côté du produit ; et des contrôles de sécurité automatiques tiennent la seule exigence qui ne se négocie ni avec l'enjeu ni avec le délai. Là où ces quatre pièces manquent, la même personne, avec la même compétence et le même outil, ne produit que des objets qu'elle ne saura ni expliquer ni dépanner — et sa compétence technique, quand elle en a, ne fait que retarder le moment où cela se voit. Le terrain fixe donc à la fois le périmètre autorisé et la vitesse atteignable, ce qui range l'ouverture du code aux profils produit parmi les décisions d'architecture avant d'en faire une question d'habilitation.
Synthèse
Les notes prises séparément décrivent chacune une pièce du problème : la vitesse, les défauts que l'assistant crée seul, l'autorisation, la revue, les tests, les rails, le rôle des développeurs. Ce qu'elles font apparaître ensemble est un déplacement du paramètre de décision. La discussion courante porte sur la personne — a-t-elle assez de bagage technique, faut-il un niveau minimum, faut-il l'interdire aux profils non techniques. Chaque note, prise par son bout, renvoie ailleurs : vers ce qui a été préparé avant elle.
Le mécanisme est le même à chaque fois, et il tient à une propriété de l'assistant : il ne devine pas ce qui n'est écrit nulle part. Il ignore les volumétries réelles, donc il conçoit pour le jeu de test. Il ne connaît pas les points d'entrée légitimes, donc il en invente. Il ne retient pas ce qu'on lui a repris hier, donc il recommence. Aucun de ces manques ne se comble par la compétence de celui qui pilote ; tous se comblent par une information posée dans l'environnement — et c'est ce qui fait basculer la responsabilité du côté de ceux qui tiennent cet environnement.
Une conséquence moins attendue suit. La compétence technique de celui qui pilote reste utile, mais son emploi change : elle ne sert plus à produire, elle sert à détecter — voir un fichier qui grossit trop, sentir une couche qui se mélange à une autre, reconnaître une réponse d'API qui ne tiendra pas la charge. Cette capacité de détection n'a aucun substitut automatique, et c'est la seule chose que le terrain ne fournit pas. Elle explique pourquoi la question du périmètre ne disparaît pas : un terrain excellent élargit ce qui est faisable sans rendre l'opérateur capable d'évaluer ce qu'il produit.
Reste ce que cet angle coûte à l'organisation. Déplacer la décision vers le terrain revient à dire que l'ouverture du code à d'autres fonctions se paie d'abord en travail d'architecture — API propres, conventions tenues, environnements sûrs, contrôles automatiques —, c'est-à-dire en dépenses sans livrable visible pour le client. C'est la ligne la plus facile à couper, et c'est pourtant celle qui décide si l'ouverture produit du soulagement ou du bricolage. La question « les Product Managers peuvent-ils développer ? » n'a donc pas de réponse générale : elle en a une par entreprise, et cette réponse a été écrite avant qu'on la pose, dans l'état de sa codebase.
Tensions / contradictions
Ces notes ne s'accordent pas sur le poids réel de la compétence individuelle. Celles qui déplacent la décision vers le terrain supposent que les manques de l'assistant se comblent par l'environnement ; celle qui décrit l'exploitation d'un outil rappelle que savoir diagnostiquer une panne ne s'écrit dans aucun catalogue d'API. Si cette part est grande, le terrain n'est qu'une condition nécessaire et la compétence reste le facteur limitant.
Un désaccord plus net oppose deux lectures de l'accélération. L'angle défendu ici traite la vitesse comme un bénéfice à encadrer, et considère que les mécanismes perdus se réinstallent par le terrain. La lecture développée ailleurs sur la fabrication de la compétence soutient que certains de ces mécanismes — l'erreur analysable, la première marche, le prix du geste — ne se réinstallent pas par un outillage, parce qu'ils exigeaient d'avoir été responsable du résultat. Rien ici ne tranche : un terrain qui supprime les détours supprime aussi les occasions d'apprendre à les reconnaître.
Enfin, l'exigence de sécurité non graduée et l'allègement de la revue sur les objets jetables cohabitent mal en pratique : elles demandent à la même organisation de relâcher un contrôle humain et de tenir un contrôle automatique, ce qui suppose un outillage que les organisations qui relâchent la revue n'ont souvent pas.
Questions
- Quelle part du terrain doit être construite avant d'ouvrir, et quelle part se construit en réponse aux premiers usages, au risque de laisser passer les objets fabriqués entre-temps ?
- Un terrain conçu pour les assistants et un terrain conçu pour les développeurs humains divergent-ils, et à quel moment faut-il en tenir deux ?
- Comment une organisation évalue-t-elle l'état de son propre terrain avant d'ouvrir, autrement qu'en constatant après coup ce qui a été produit ?
- Sur quoi se fonde la décision d'investir dans ce travail d'architecture, quand son bénéfice se mesure en incohérences qui ne se sont pas produites ?