Haha, j'aurais été tenté de répondre comme toi, Kevin (http://www.mypersonnaldata.eu/shaarli/?oBPM7A), mais en fait non. Je vais argumenter.
Le sysadmin code aussi, mais il ne fait pas que ça.

Il code car il doit créer l'infrastructure qu'il souhaite la plus jetable possible. Le but c'est d'être capable de recréer toute l'infrastructure from scratch depuis son code. C'est ce qu'on appele l'infrastructure as code. TOUT est code, de la taille des machines à leur nombre de disque en passant par les règles firewall et les membres d'un loadbalancer. Cette infra est le plus souvent écrite dans un DSL propre au logiciel de gestion de configuration utilisé.
Pour Saltstack, c'est majoritairement du yaml qui décrit l'état des services (states). On retrouve du jinja pour la partie templating et pour ajouter un peu de logique dans les states. On peut également avoir besoin de faire du python pour développer des modules spécifiques.

Enfin de manière générale, on utilise beaucoup python et bash pour l'administration, le monitoring ou pour des tâches lancées via cron sur les serveurs.

Le problème c'est que peu de monde comprend le métier de sysadmin (ou Ops comme ils disent aux states). Mêmes certains devs ignorent ce qu'on fait au jour le jour. Est-ce qu'on peut dire que ce sont de mauvais dev? Peut-être mais la direction d'une entreprise a d'abord un vrai rôle à jouer pour que tout ce petit monde coopère et puisse bosser ensemble.

La réalité c'est que le métier de sysadmin n'est pas mis en valeur car leur produit, l'infrastructure, n'est pas directement "visible". On ne pense aux sysadmins que quand le service tombe ou quand celui-ci est lent. Et c'est justement tout l'enjeu de notre métier que cela ne se produise jamais.

On parle de "DevOps"[1] pour justement améliorer la communication entre les équipes, qu'on arrête de considérer les sysadmins comme des larbins et pour que la communication se fasse dans les 2 sens. Car les sysadmins sont avant tout des architectes. Des architectes ayant l'expérience de la montée en charge, de savoir quel RDBMS il est préférable d'utiliser plutôt qu'un autre, de connaître le comportement d'un redis en production, de savoir sur quels axes on pourrait améliorer les performances d'une application, etc.. Bref, au même titre que les developpeurs, les sysadmins doivent être impliqués le plus tôt possible dans les choix techniques.

[1] Le problème de ce mot "DevOps", c'est qu'il est galvaudé. Certains chasseurs de tête l'utilisent pour désigner des titres de poste alors qu'il ne s'agit que d'un état d'esprit. Un état d'esprit visant à dire que moi developpeur je ne connais pas tout ; alors je vais aller poser des questions aux sysadmins. Et inversement.