DevOps, un mot sur ce que je bricolais déjà

Depuis quelques mois un mot circule, DevOps, lancé après la conférence Velocity de juin 2009 et son fameux “10 deploys a day” sur la coopération entre dev et ops chez Flickr, puis repris aux premiers DevOpsDays de Gand en octobre, autour de Patrick Debois. On le présente un peu partout comme la fin du mur entre ceux qui écrivent le code et ceux qui le font tourner et en lisant les premiers textes j’ai eu la sensation curieuse de reconnaître des choses que je bricolais déjà dans mon coin, sans leur avoir jamais donné de nom.

Ce que je bricolais

Rien de bien sophistiqué et c’est peut-être pour ça que le rapprochement m’amuse. Mon tout premier outillage, c’était une liste d’hôtes, un CSV de variables et une boucle ssh qui poussait des configs rendues par template, avec l’idée, sans doute pas formulée comme ça à l’époque, que l’inventaire est une donnée et que le transport, c’est ssh.

L’étage au-dessus, c’est git et des hooks. Un dépôt pour la configuration, un accès ssh par clef et un hook post-receive qui, à chaque push, va remettre les serveurs dans l’état décrit par le dépôt. Gitolite par-dessus pour gérer les clefs et les droits par dépôt sans alourdir, avec les mêmes hooks bash derrière pour déclencher les déploiements. C’est comme ça que tournent mes serveurs de jeu et de voix, des configs que je peux rejouer, des déploiements que je peux relire et une discipline qui tient dans quelques scripts.

La part honnête, le mur

Je serais tenté de dire que ce fameux mur, je ne l’ai jamais eu, mais il faut être juste sur la raison. Sur mes projets perso, il n’y a pas de mur parce qu’il n’y a personne de l’autre côté, je suis le dev, l’ops et le seul utilisateur à me plaindre quand ça casse, ce qui ne demande aucune vertu particulière. Au travail, en revanche, je côtoie des développeurs et c’est là que le mot prend vraiment son sens, parce que le mur n’y est pas technique, il est organisationnel, deux équipes, deux priorités et la tentation permanente de se renvoyer la balle quand quelque chose tombe. C’est sur ce terrain-là que DevOps m’intéresse, bien plus que sur l’outillage, que chacun finira par construire à sa façon.

Pas de mur, pas de mérite

Le mot est utile parce qu’il met un nom sur une évidence qu’il faut pourtant défendre, dev et ops sont deux faces du même métier et les séparer coûte souvent plus cher que les réunir. Mon mécanisme à base de git et de hooks bash reste rustique et je ne prétends pas qu’il soit autre chose qu’un bricolage qui marche, mais j’y retrouve l’idée de fond, une infrastructure décrite quelque part et rejouée depuis cette description plutôt que tapée à la main. La seule chose qui me fait un peu peur, c’est qu’on finisse par en faire un intitulé de poste, ce qui recréerait un silo de plus là où le mot servait justement à en retirer un.

[edit: 2026] Le bricolage bash et CSV a continué d’évoluer pendant des années, je le raconte dans l’ancêtre d’Ansible . Quant au dépôt git et à ses hooks qui font converger des serveurs, on appellerait ça GitOps aujourd’hui, un mot qui n’apparaîtra qu’en 2017; la version suivante, avec GitLab CI, Terraform et Ansible, est dans GitOps, le mot après la pratique . Et oui, “ingénieur DevOps” est bien devenu un intitulé de poste.