Idée principale

Évaluer des sorties probabilistes, tenir une mémoire produit consultable, écrire une documentation exploitable par une machine autant que par un humain, garder un dépôt lisible, formuler des critères d'acceptation nets, orchestrer les enchaînements d'outils : rien de tout cela n'est nouveau. Ces travaux existaient, dispersés, tenus par qui avait le temps, et personne ne perdait grand-chose à les négliger.

Dès qu'une équipe fait travailler des agents, ils cessent d'être périphériques. La qualité du contexte fourni détermine la qualité de ce qui est produit, et un contexte que personne ne maintient dégrade toutes les sorties à la fois. Ce qui relevait du soin devient une condition de fonctionnement.

Ces besoins ne deviennent pas forcément des postes. Ils deviennent des responsabilités qu'il faut attribuer — et la question posée à une équipe outillée n'est plus « qui fait quoi ? » mais « qui juge, qui construit, qui garantit, qui évalue, qui maintient la mémoire, qui orchestre ? ».

Pourquoi c'est important

Cela explique pourquoi deux équipes équipées des mêmes outils obtiennent des résultats très différents : l'écart ne se joue pas sur l'outil, il se joue sur ce que personne n'avait la charge de tenir.

Et cela donne une liste de responsabilités à attribuer explicitement avant de constater leur absence, plutôt qu'après une sortie fausse passée en production.

Nuances et limites

Rendre ces responsabilités visibles ne dit pas comment les doter. Une équipe qui les attribue sans dégager le temps correspondant obtient une liste de propriétaires nominaux et le même abandon qu'avant.

Et certaines de ces charges sont transitoires : la fiabilité des outils progresse, et une responsabilité d'évaluation dimensionnée pour l'état actuel des modèles peut devenir disproportionnée.

Questions ouvertes

• Lesquelles de ces responsabilités gagnent à être tenues par une personne dédiée, et lesquelles se dégradent dès qu'on les sort de l'équipe qui produit ?