Reintroduire de la friction n’est pas un bug. C’est un choix politique.

Un choix couteux : ca ralentit, ca complique. Rarement fait – sauf quand on comprend que le cout de la friction est inferieur au cout de la fragilite.

Quelques propositions

1) Preserver des zones non automatisees : Pas par nostalgie, mais pour l’hygiene cognitive. Des espaces ou l’on continue a faire les choses soi-meme, a se tromper, a comprendre pourquoi ca casse. L’enjeu est un choix de competence, pas un retard technologique.

2) Organiser des exercices d’incendie cognitifs : Regulierement, debrancher l’agent et rejouer a la main. Verifier qu’on sait encore faire. C’est fastidieux, c’est lent, mais c’est precisement pour ca que c’est utile.

3) Etablir un droit a l’incomprehension : Non pas un droit a tout comprendre, c’est impossible. Mais un droit a exiger une justification avant d’approuver. “L’agent dit que…” ne peut pas etre un argument suffisant.

4) Evaluer les agents sur la recoverabilite, pas sur les resultats : Un bon outil est un outil qu’on peut debrancher. Si l’agent tombe demain, combien de temps avant que le collectif soit operationnel ? Si la reponse est “plusieurs semaines”, il y a un probleme de conception.

5) Documenter les arbitrages, pas seulement les resultats : Quand on configure un agent, on fait des choix. Ces choix doivent etre tracables, explicites, contestables, et non enfouis dans un prompt que personne ne relit.

Le ralentissement pourrait etre le prix a payer

Ces mesures ralentissent. Elles exigent du temps improductif, c’est-a-dire du temps politique. C’est precisement pour ca qu’elles ne seront pas prises par defaut.

La friction n’est pas un obstacle a l’efficacite. C’est le prix de la resilience.