Bonjour,
Première question que je me pose.
Je bosse dans une boite ou l’informatique n’est pas le cœur de métier. Nous sommes, comme ils disent, une direction ressource 
Nous sommes que des Ops car nous ne faisons aucun dev en interne.
Est-ce qu’une culture DevOps est possible dans cette situation ?
Perso j’ai tendance a dire que oui si on passe outre le terme Dev dans DevOps. On peut toujours prendre le coté automatisation (optimisation) des process de l’IT par exemple.
A votre avis ?
Exactement !
En effet les sujets de releases et mise en prod seront moindre dans ton cas cependant ton approche pour la gestion 'de tes ressources informatiques ’ peut totalement s’inspirer des outils qui aident le mouvement (genre pour de la gestion de conf,gestion des users : ansible, pour l’application de compliance ça peut s’orchestrer avec du Jenkins par exemple ! Et tout ça commit/backup dans un repo git !)
Donc oui 
Bonjour
il me semble que l’essence même du devops c’est de rapprocher les devs des d’ops.
s’il manque la moitié de cette population, on peut parler de devs ou d’ops, mais sans doute pas de devops 
Automatiser les déploiement, monitoring, surveillance et autres travaux IT, c’est pas vraiment du devops, C’est de l’ops faite efficacement.
de même “l’infra as code” c’est du devops automatisé, mais ce n’est pas du dev, de mon point de vue.
perso je part du principe qu’a partir du moment ou tu fais des lignes de code, quelque soit le langage, tu fais du DEV
Salutations 
Alors j’aurai tendance à dire que ce n’est pas du DevOps, comme le souligne @guillaume-s le DevOps c’est de rapprocher 2 métiers sur des problématiques. Donc ici ce n’est pas le cas.
Ca ne veut pas dire qu’il n’y a pas de bonnes pratiques ou d’avancé, ça peut-être du lean ou autre, ça reste intéressant et pas mal de paradigme sont proches de ceux des ops présent dans le devops.
D’ailleurs dans ces situations tu as d’autres problématiques qui ne sont pas géré par le DevOps.
Pour ce qui est de considérer la moindre ligne de code comme du dev, je suis à moitié d’accord. Oui, ça doit être géré comme du code : versionné / testé / suivit. Ca n’apporte par pour autant pour tous les petits dev autant de problématique que celle adressées par le DevOps
Salut,
J’aurais une approche plus haut niveau du DevOps, qui de base est la contraction des mots Developments et Operations, donc de 2 étapes, et non pas de 2 métiers. Par conséquent, le but étant de rapprocher 2 étapes dans la conception d’un produit, de la réflexion de celui-ci jusqu’à sa production, et que peux importe dans laquel tu agis, tu es inclus du plus tôt possible, au plus tard possible.
Sachant cela, nous pourrions donc appliquer la culture DevOps à tout métier, même hors tech en fait. En informatique, on aime bien comparé à l’automobile, et on pourrais très bien utiliser cette culture. Nous avons les bureau R&D (Developments), qui pensent la voiture, et ensuite nous avons les chaines de production (Operations), qui la construise. Le but c’est que le gars en fin de chaine, ai pu se préparer, POCé, comprendre ce qu’il fera le plus tôt possible afin de pouvoir sécurisé sa partie au mieux. Mais également la R&D va devoir suivre tout ce qui se passe jusqu’au montage de la dernière pièce. Après nous avons l’itération, car nous avons un client final qui remontera des problèmes, qu’il faudra corrigé pour la prochaine série, et on recommence la boucle.
Tout ça pour dire, que tu peux avoir une culture DevOps sans développeur, car tu as même dans ta partie qui sera automatisation, tu as la partie Development, la partie Operation. Sauf dans le cas où toi tu crée l’automatisation, et que c’est une autre équipe qui clique sur le bouton sans vraiment savoir ce qu’ils font, car là tu n’aurais pas de relation entre le Development et l’**Operation".
ça reste ma vision et ma compréhension de la culture DevOps.