Ce qu'on perd à tout automatiser
Un système qui marche tout seul finit par n'être compris de personne. Le problème n'est pas le jour où il marche, c'est celui où il s'arrête.
L’argument pour automatiser est toujours le même, et il est toujours juste : la machine est plus rapide, plus régulière, et elle ne se fatigue pas. Ce que l’argument ne dit pas, c’est ce qu’il advient de la personne qui reste.
Lisanne Bainbridge l’a écrit en 1983, dans un article de quatre pages qui a mieux vieilli que la plupart des livres publiés depuis. Son titre : Ironies of Automation. Sa thèse tient en une phrase : en automatisant tout ce qui peut l’être, on confie à l’humain exactement ce qui ne peut pas l’être.
Les trois ironies
On lui laisse les cas difficiles. L’automatisation prend le régime normal, celui qui se décrit en règles. Reste à l’opérateur l’exception, l’ambiguïté, la panne. C’est-à-dire la partie du travail qui demande le plus de compétence, et c’est précisément celle qu’on lui demande d’exercer sans jamais s’entraîner.
On lui retire l’entraînement. Une compétence qui ne sert plus se perd. La personne chargée de reprendre la main en urgence est celle qui n’a plus repris la main depuis des mois. Elle est supposée faire mieux que la machine, dans la seule situation où la machine a renoncé, avec des réflexes qu’elle n’a plus.
On lui donne le pire des métiers. Surveiller. L’être humain est mauvais à cette tâche, et il ne s’améliore pas avec l’expérience. Rester attentif pendant huit heures à un système qui ne fait rien d’anormal n’est pas un travail léger : c’est un travail épuisant qui ne produit rien de visible tant que rien n’arrive.
Bainbridge en tire une conclusion qui devrait figurer dans tous les dossiers d’automatisation : plus un système est automatisé, plus l’opérateur a besoin de formation, pas moins. C’est l’inverse exact de ce qui est budgété.
Ce que cela donne quarante ans plus tard
Le vocabulaire a changé, la mécanique est identique. Le pipeline de déploiement que personne n’a plus ouvert depuis deux ans. Le tableau croisé dynamique dont l’auteur est parti. Le modèle qui produit une recommandation que personne dans la salle ne sait recalculer à la main.
Le point commun de ces trois situations n’est pas technique. C’est qu’il n’existe plus, dans l’organisation, une seule personne capable de dire pourquoi le résultat est ce qu’il est. Le système n’est pas devenu opaque d’un coup. Il l’est devenu par retrait progressif, un départ à la fois, un raccourci à la fois.
Une automatisation ne se dégrade pas quand elle tombe en panne. Elle se dégrade quand elle continue de fonctionner alors que plus personne ne la comprend. La panne, elle, est presque une bonne nouvelle : elle arrive pendant qu’il reste quelqu’un pour s’en occuper.
L’objection
« On ne va pas garder des gens à faire à la main ce qu’une machine fait mieux. » Non, évidemment. L’argument n’est pas de renoncer à automatiser, il est de compter honnêtement.
Un dossier d’automatisation qui annonce un gain de temps sans annoncer la formation, la documentation et l’exercice périodique qui vont avec n’est pas un dossier économique. C’est un dossier économique amputé de sa moitié la plus coûteuse, et cette moitié sera payée plus tard, par quelqu’un d’autre, au pire moment.
Trois questions avant d’automatiser
- Qui saura le refaire à la main ? Nommez la personne. Si vous ne pouvez pas la nommer, la réponse est personne.
- Comment le saura-t-on quand ça s’arrêtera ? Un système silencieux qui échoue silencieusement n’est pas automatisé, il est abandonné.
- Quand cette compétence sera-t-elle exercée ? Une capacité de reprise en main qui ne s’entraîne jamais n’existe pas. Elle figure dans un document, pas dans l’organisation.
Aucune de ces trois questions n’est technique. C’est bien le problème : elles ne sont posées par personne dans une revue d’architecture.