Le DevOps n'est plus l'affaire d'une équipe à part

Le prix de la vitesse

Sur NX, je déploie souvent. Le site, le serveur MCP, tout tourne sur des jobs automatisés pour build mon code, le tester et le déployer. Je code plus vite depuis que je m’appuie sur l’IA pour designer, écrire, développer. Résultat : je pousse plus souvent. Et pourtant, je n’ai presque jamais de rollback à faire. Le site tient, le serveur MCP tourne en continu.

Ce n’est pas un hasard. À force de développer, de faire du DevOps et de casser deux-trois prods au passage, j’ai fini par intégrer certains réflexes. Ma CI fait son travail et mes environnements ressemblent à la prod.

Un collègue, chez Scaleway, construit en ce moment une plateforme d’exercices. L’idée est bonne (vraiment bonne). Mais il a tout vibe codé, et à chaque modification, il pousse directement en prod. Pas d’environnement de dev, pas de test avant. Résultat : sa facture grimpe, son environnement est instable et il perd du temps à comprendre pourquoi ça casse.

Je ne le juge pas. J’ai été exactement à sa place. À mes débuts, je poussais direct en prod. Mes réflexes ne sont pas tombés du ciel, ils sont sortis de ces ratés-là.

Vous vous reconnaissez peut-être dans l’un des deux profils. Même outil (l’IA), même vitesse de production. Mais un seul des deux a la boîte à outils pour l’encaisser.

---

La vitesse ne dispense pas de la rigueur

On pourrait croire l’inverse. Que l’IA rend tout la partie DevOps et tests has-been. Puisqu’elle écrit le code à votre place, les tests, la CI, les environnements iso-prod deviennent des détails de plomberie qu’on peut ignorer.

C’est l’inverse qui est vrai.

Avant, produire du code prenait du temps. Ce temps servait de garde-fou naturel. On réfléchissait plus longtemps avant de pousser, parce que chaque ligne coûtait cher à écrire. Ce frein a disparu. L’IA écrit vite (parfois trop vite) et rien ne vous empêche de pousser une modification en quelques secondes après l’avoir générée.

Sans CI pour vérifier automatiquement, sans environnement de test qui ressemble à la prod, vous ne faites que déplacer le problème. Vous ne le résolvez plus en amont (en réfléchissant avant d’écrire), vous le découvrez en aval (en prod, devant les utilisateurs, ou devant la facture).

Plus on va vite, plus la rigueur en amont compte. Pas moins.

---

Les quelques briques qui changent tout

Pas besoin de tout savoir. Une brique suffit à condition de commencer par la bonne.

Un environnement de dev et de test iso-prod. Le même OS, les mêmes versions, la même architecture réseau que ce qui tourne en vrai. Sans ça, “ça marche chez moi” redevient la norme sauf que maintenant, c’est l’IA qui vous le dit avec assurance, pas un collègue qui doute. Reproduire la prod, c’est le point de départ. Le reste vient répondre à cette exigence.

Une CI qui vérifie avant vous. Reproduire la prod ne sert à rien si vous ne rejouez pas la vérification à chaque modification. La CI, c’est ça : le filet systématique qui attrape ce que l’IA (ou vous) laisse passer tels qu’un test cassé, un lint qui hurle, une régression silencieuse. Pas pour la couverture parfaite. Pour que rien ne touche la prod sans être repassé au même tamis.

Des notions de cloud public. Un environnement qui ressemble à la prod tourne quelque part. Savoir déployer, comprendre les briques de base (compute, stockage, réseau), c’est ce qui vous évite de dépendre d’un tutoriel généré ou d’une IA qui invente une configuration plausible mais fausse.

Un minimum de sécurité réseau. Et dès que vous reproduisez le réseau, vous butez sur la question : qu’est-ce qui doit être isolé, qu’est-ce qui doit être exposé et pourquoi ? Un VPC mal configuré, un port ouvert par erreur, une IA qui propose une solution “qui marche” sans isoler ce qui doit l’être. Ce n’est pas de la paranoïa. C’est savoir ce que vous exposez.

Quatre briques, mais une seule porte d’entrée. Prenez l’iso-prod au sérieux, et les trois autres suivent — dans l’ordre, au moment où vous en avez besoin.

---

Donner à l’IA le bon bac à sable

Il y a quelque chose qu’on oublie souvent. l’IA ne travaille pas dans le vide. Elle travaille dans votre environnement avec vos outils et vos contraintes.

Une IA à qui vous donnez accès à un environnement de test iso-prod, avec une CI qui valide chaque modification, va itérer plus vite et plus juste. Elle peut se tromper, se corriger, retester, mais sans risque, parce que le filet est là. Une IA à qui vous ne donnez que la prod comme terrain de jeu fait pareil : elle itère, elle se trompe, elle corrige. Sauf que chaque erreur, c’est un incident réel.

Ce n’est pas l’IA qui manque de rigueur. C’est l’environnement qu’on lui donne qui n’en a pas.

C’est là que la boîte à outils DevOps change de rôle. Elle n’est plus seulement pour vous. Elle devient l’environnement de travail de l’IA elle-même. Plus il est solide, plus elle peut y être utile.

---

Ce n’est plus un métier à part

Pendant longtemps, le DevOps a été vu comme une spécialité. Un métier à côté, avec ses propres experts, sa propre équipe, ses propres tickets. Vous codiez, quelqu’un d’autre déployait, un troisième surveillait la prod.

Cette séparation s’efface. Pas parce que le métier de SRE ou de DevOps disparaît, mais parce que ses réflexes cessent d’être l’affaire d’une équipe à part pour devenir l’affaire de chaque développeur qui ship du code régulièrement.

L’IA accélère ce mouvement plus qu’elle ne le freine. Elle vous permet de produire seul ce qui demandait plusieurs personnes il y a encore deux ans. Mécaniquement, les équipes se resserrent, les rôles se combinent, et le développeur d’aujourd’hui hérite d’une partie de ce qui appartenait hier au DevOps ou au SRE (souvent sans avoir eu le temps de l’apprendre correctement).

Vous n’avez pas besoin d’avoir passé une décennie en SRE pour vous en sortir. Vous avez besoin de connaître les quelques bases qui évitent la facture surprise ou l’incident du vendredi soir, parce que, de plus en plus, il n’y aura personne d’autre pour les connaître à votre place.

Je prépare des fiches techniques sur ces sujets (CI, environnements iso-prod, bases du cloud, sécurité réseau) pour NX. Peut-être un cours, si le format s’y prête. En attendant, si une seule chose est à retenir : la vitesse ne remplace jamais la rigueur. Elle la rend juste plus urgente.