Il y a trois raisons pour automatiser un protocole : une tâche contrôlée et répétée souvent, une tâche contrôlée nécessitant un haut niveau de reproductibilité indépendamment de sa fréquence et une tâche plus coûteuse en ressource humaine qu'en automate à résultat identique.
Les trois nécessitent que le protocole soit préalablement industrialisé, c'est ce qui lui donne son statut contrôlé.
Ça marche très bien dans l'industrie lourde parce qu'elle a le temps de se préparer pendant que des talents résolvent les points de blocage technologiques mais ça coince un peu dans l'industrie des produits dématérialisés. Le domaine de l'informatique de service est assez intéressant à ce niveau-là d'ailleurs parce qu'il souffre d'une dématérialisation complète d'une part (à la différence des milieux bancaires où les compteurs à billets existent depuis des lustres) et d'autre part de ce que j'appellerais la culture du druide émanant du mythe que l'informatique, c'est un truc de nerd hippie qui tire du câble dans son garage. En conséquence, on cumule une culture de pompier avec une absence de réflexe de documentation dans un des domaines pourtant les plus faciles et les moins coûteux à automatiser. Du coup, la mode actuelle, principalement initiée par les clouds publics, AWS en tête parce qu'ils ont poussé le facteur d'échelle dans ses derniers retranchements, des trucs-ops à toute les sauces provoquent des craintes de la part des opérationnels parce qu'ils ont peur de se faire virer.
Pourquoi ont-ils peur ? Parce qu'ils ne sont pas prêts, que leurs connaissances "druidiques" vont être documentées par d'autres qu'eux (les automaticiens, parce qu'ils en ont besoin) et que ça va diluer leur expertise au sein de l'entreprise en transverse. Dans les faits, c'est toujours plus ou moins ce qui se passe dans tous les domaines, mais cette peur a tendance à braquer certains opérationnels de l'informatique de service qui, se sentant en danger, se retranchent dans leur zone de confort et refusent d'améliorer leurs ou d'acquérir de nouvelles compétences. Ceux-là finissent par se faire virer et c'est dommageable aussi bien à eux qu'à l'entreprise, mais ce faisant, il sont confortés dans leur peur qu'ils transmettent à d'autres et c'est la merde.
Si tu ne prépares pas les gens, aussi bien ceux que tu remplaces que ceux à qui tu supprimes une relation humaine rassurante (un automate n'est a priori pas capable de compenser les insuffisances de son pilote/utilisateur et tu peux difficilement reporter la faute sur un système à la mémoire courte mais infaillible et qui peut reproduire à l'identique une action en prouvant que c'est toi qui a merdé), le risque est de créer un super outillage automatisé que personne n'utilisera, ou alors pas comme prévu ce qui engendrera des coûts et des charges de formation et d'évolution qui réduiront d'autant les bénéfices de l'automatisation.
On a souvent tendance à ignorer ce point, parce qu'on est finalement qu'une bande de gros cons qui travaillons principalement avec des machines ou des systèmes et qu'on n'est jamais très doués pour gérer des systèmes qui n'écrivent pas de log ou qui ont des sentiments qui perturbent leurs capacités comme le sont les êtres humains (une bécane fonctionne pareil que tu viennes de la racker ou que tu te prépares à la mettre au rebut parce qu'elle arrive en fin de garantie).
Brayf, l'automatisation est un outil qui doit servir la société, pas la façonner, entre autres raisons parce que sinon les gens flippent et un être humain qui a peur est un système défaillant qui fait n'importe quoi, y compris utiliser la borne d'y McDo en dépit du bon sens.