Idée principale

Quand une équipe produit, support ou métier se met à fabriquer des écrans et des outils avec un assistant, le réflexe est de concevoir pour elle un régime propre : sa charte, ses règles, son processus de validation, son niveau d'exigence. Ce réflexe fabrique un deuxième système, parallèle au premier, qui devra être tenu à jour séparément et qui divergera.

Or l'outillage existe déjà, et il a été construit exactement pour ce problème : intégration continue, scanners de sécurité, conventions de dépôt, règles de qualité, environnements cadrés, et de plus en plus des fichiers d'instructions, des prompts et des skills que les développeurs écrivent pour leur propre usage. Rien de tout cela n'a besoin d'être réinventé pour des profils non développeurs ; il faut seulement que leur production y passe.

Le travail d'encadrement est donc un travail de raccordement — quels dépôts, quels environnements, quels contrôles automatiques s'appliquent à cette production — et non un travail d'invention normative.

Pourquoi c'est important

Cela change la nature de la question posée à l'équipe technique. « Que faut-il exiger d'un Product Manager qui code ? » appelle une réponse longue et discutable ; « à quoi le branche-t-on ? » appelle une réponse opérationnelle et déjà largement disponible.

Cela évite aussi une asymétrie absurde, où une production faite par un profil produit serait soumise à des règles écrites pour l'occasion, plus strictes ou plus floues que celles qui s'appliquent au code de l'équipe.

Nuances et limites

Le raccordement suppose que l'outillage existe et soit en bon état. Dans une organisation où les contrôles automatiques sont faibles, il n'y a rien à quoi brancher, et le sujet redevient la construction de cet outillage — pour tout le monde, pas seulement pour les nouveaux entrants.

Certains points ne se raccordent pas et doivent bien être décidés : le périmètre des dépôts accessibles, les droits d'écriture sur les données, la propriété des objets produits.

Questions ouvertes

• Quelle part de l'outillage écrit par les développeurs pour eux-mêmes reste inutilisable par un non-développeur, faute de vocabulaire commun plutôt que faute de droits ?