En février 2015, il y a un mot que j’entends partout: DevOps. Dans les conférences, les articles, les réunions. Pis comme bien des mots à la mode, il s’est tellement fait répéter qu’il a fini par perdre son sens. Tout le monde dit « on fait du DevOps » sans trop savoir ce que ça veut dire concrètement. Alors je veux le démêler sans jargon, parce que dans mon travail d’architecte auprès des dealers, l’idée derrière est franchement utile.

Au fond, DevOps répond à un problème vieux comme le métier: le mur entre ceux qui développent un système pis ceux qui le font rouler en production. Deux gangs, deux mondes, qui se lancent la balle par-dessus une clôture.

Le vieux mur entre deux mondes

Pendant des années, c’était la norme: les développeurs construisent, pis lancent leur livraison « par-dessus le mur » à l’équipe des opérations. Quand ça plante, chacun pointe l’autre.

flowchart LR
    A[Developpeurs<br/>construisent] -->|jettent par-dessus le mur| B[Operations<br/>font rouler]
    B -->|ca plante| C[On se pointe du doigt]
    C --> D["dev: ca marchait chez nous"]
    C --> E["ops: votre code est cassé"]
    D --> F[Personne responsable<br/>du resultat complet]
    E --> F

C’est ce mur-là que DevOps veut abattre. L’idée, dépouillée de son jargon, c’est simple: les gens qui construisent pis les gens qui opèrent travaillent ensemble, partagent la responsabilité, pis automatisent les étapes pénibles entre les deux. Pas deux gangs qui se lancent la balle, mais une équipe responsable du résultat du début à la fin.

Ce que ça change concrètement

Pour mes dealers, ça veut dire des livraisons plus fréquentes, moins risquées, pis moins de nuits blanches quand quelque chose brise. La clé, c’est l’automatisation: ce qu’un humain faisait à la main, lentement pis avec des erreurs, une machine le fait vite pis pareil à chaque fois.

Ce qui me plaît, c’est que DevOps, ce n’est pas d’abord un outil qu’on achète. C’est une culture. On peut acheter tous les logiciels du monde; si les deux gangs continuent de se chicaner par-dessus le mur, on n’a pas fait de DevOps pantoute. On a juste acheté des licences.

Pourquoi je me méfie du mot

Mon malaise avec « DevOps » en 2015, c’est justement qu’il est devenu un mot-valise. Des entreprises engagent un « ingénieur DevOps » en pensant régler le problème avec un titre. Mais si la responsabilité reste séparée, le mur est toujours là, juste avec une nouvelle pancarte dessus.

Comme architecte, mon rôle c’est de ramener le mot à son intention: rapprocher les gens, automatiser le pénible, partager la responsabilité du résultat. Le jargon, je le laisse aux brochures. Ce qui compte, c’est que le système se livre bien pis que personne se réveille la nuit pour éteindre un feu qu’on aurait pu éviter.

Ce que je retiens

En février 2015, DevOps sans le jargon, c’est simplement ça: abattre le mur entre ceux qui construisent pis ceux qui opèrent, partager la responsabilité, pis automatiser tout ce qui est pénible entre les deux. Pas un outil magique, pas un titre de poste — une façon de travailler ensemble.

Pour mes dealers, l’enjeu est concret: des livraisons plus calmes pis plus fiables. Je vais continuer de pousser l’esprit, pas le buzzword. Parce que le jour où on confond le mot avec la chose, on achète des outils en pensant changer une culture — pis ça, ça marche jamais.