autonomie

En profondeur

L’autonomie se lit sur trois axes qu’on gagne à ne pas confondre. Le premier est l’étendue des actions permises, car lire, écrire, envoyer et payer ne se délèguent pas au même prix. Le deuxième est le déclenchement : agir sur demande, agir quand un événement survient, ou agir de sa propre initiative. Le troisième est la réversibilité, et c’est le plus décisif, puisqu’une action qu’on peut défaire supporte une latitude qu’une action définitive n’autorise pas. Un système bien réglé est souvent très libre sur le premier axe et très contraint sur le troisième.

Le curseur se règle donc risque par risque, et non système par système. La question utile n’est jamais « fait-on confiance à ce système » mais « que se passe-t-il si cette action précise se révèle fausse, et combien coûte la réparation ». Une action réversible, peu coûteuse et détectable peut être largement déléguée, quitte à corriger après coup. Une action irréversible, coûteuse ou invisible réclame un accord humain avant exécution, quelle que soit la qualité observée jusque-là. C’est la mise en pratique de ce raisonnement qu’on appelle human in the loop.

Le premier piège est l’autonomie par défaut : un système obtient un droit parce qu’il était plus simple de le lui donner que de le restreindre, sans que personne ne l’ait décidé. Le deuxième est l’autonomie qui dérive, quand les validations deviennent lassantes, qu’on les retire une à une et que le périmètre s’étend sans qu’aucune décision ne soit tracée. Le troisième est la confusion avec la performance, car un système plus juste ne devient pas pour autant plus légitime à décider seul : la justesse est une mesure, la délégation est un choix. Régler le curseur sérieusement suppose donc trois choses : une liste explicite des actions permises, des traces qui rendent l’exercice vérifiable, et une révision périodique.