Le code est devenu bon marché. La production, non.
James Annett
Introduction
Je suis arrivé au travail et un collègue m’a demandé de relire du code Terraform qu’il avait écrit. Le module généré par Claude semblait propre et suffisamment correct. J’ai commencé à passer en revue mes questions habituelles. Combien de cibles potentielles de déploiement existent ? Existe-t-il des modules officiels qui encapsulent déjà ce regroupement de ressources et qui sont versionnés ? Une documentation est-elle fournie à ceux qui devront le maintenir ? Puis-je déployer ceci localement et dans le cloud avec la même chaîne d’outils ? Le projet était assez peu risqué pour que, bien que beaucoup de ces questions soient considérées comme des "problèmes à traiter plus tard", cela m’a fait réfléchir.
Dans ce contexte, le module Terraform généré par l’IA était simplement un moyen d’atteindre un objectif : une manière pragmatique et rapide de démarrer un MVP tout neuf et livrer du code au client. De mon point de vue, il posait peut-être les bases.
Alors que les administrateurs système sont devenus des scripteurs et des programmeurs, et que les devs full-stack touchent davantage l’infrastructure via les clouds publics en libre-service, je suis parfois surpris par les façons imprévisibles dont pratiques et choix technologiques convergent, ainsi que là où opinions et priorités divergent fortement. À mesure que nous nous dirigeons rapidement vers l’IA, cela m’amène à réfléchir aux perspectives particulières des ops dans la discussion.
Les deux courbes de coûts
Les préoccupations des devs tendent à être : livrer à temps, exhaustivité des fonctionnalités et abstraction DRY cohérente. Les devs compétents et expérimentés sont fiers d’impulser dans leur codebase la discipline d’un code efficace, lisible, testé, écrit dans un style conventionnel avec des usages cohérents. Les questions cruciales sont "Est-ce que ça fonctionne comme prévu ?", "Est-ce que c’est logiquement cohérent ?", "Est-ce facile à saisir par un nouveau membre de l’équipe ?", "Ses dépendances sont-elles faciles à gérer ?", "Est-ce qu’on réinvente la roue ?". "Une fois ceci fonctionnel, le problème est-il réglé ?".
Du point de vue des ops, les préoccupations principales sont des recettes de construction uniformes et répétables, des points d’entrée et une instrumentation cohérents, la portabilité entre environnements, des hypothèses de performance appuyées par du benchmarking et la scalabilité. Les questions cruciales sont "Comment cela va-t-il se comporter sous charge ?", "Quels sont ses modes de défaillance constatés ou probables ?", "Qui va l’opérer ?" et "Combien cela coûtera-t-il dans le temps ?". Ou plus précisément, "Les coûts opérationnels sont-ils proportionnels au ROI attendu ?".
Ces préoccupations divergentes reflètent aussi des courbes de coûts différentes :
- Courbe d’auteur = le coût d’écriture du code
- Courbe opératoire = le coût de faire fonctionner, observer, sécuriser et faire évoluer ce que devient ce code EN PRODUCTION
D’une certaine façon, peu importe qu’une personne seule, une équipe dédiée, une équipe cross-fonctionnelle ou un agent s’occupe d’une ou plusieurs préoccupations tant que ces préoccupations ne sont pas confondues.
Maintenant que les agents écrivent et relisent le code, la nécessité de stewardship développeur semble remise en question, avec le coût comme arbitre. Si une machine peut écrire, refactorer et tester du code à moindre coût, qui se soucie de sa beauté ou interprétabilité ? L’exhaustivité des fonctionnalités, dans ce contexte, peut être validée par un utilisateur, ce qui prévaut sur le style propre, du moins c’est l’argument. On peut "corriger au mixage", pour ainsi dire.
Ce que DevOps est réellement devenu
Lorsque les débats sur les choix technologiques se séparent en camps et deviennent polémiques, je le vois moins comme du bikeshedding ou une préférence utilisateur, et plus comme un conflit de priorités entre différentes préoccupations.
Parfois ces divergences concernent l’ownership et reflètent le déplacement du "mur" entre développement et production : qui débug les tests CI quand ils bloquent le build ? Qui est immédiatement tagué quand un pod échoue au démarrage à cause d’une mauvaise config ? Un compromis fréquent mais décevant est l’émergence des ops comme département d’outillage ou de services. Ici, le problème du "mur" ne disparaît pas — il se déplace et se rebrand. Les équipes dev ont gagné des outils infra en libre-service et les ops sont devenus une équipe plateforme qui les débloque. Le mur n’est pas tombé ; il a eu un portail.
D’autres fois, il s’agit de vision architecturale, et le mécanisme structurel est étonnamment banal : les ops ne sont souvent pas présents lors des décisions d’architecture. La réunion de planification, le RFC, la relecture du design doc — tout cela a lieu côté produit ou engineering, et l’équipe plateforme est appelée pour provisionner l’infrastructure de décisions déjà actées. Résultat : les ops arrivent pour exécuter l’architecture, pas la façonner. Quand ils sont dans la pièce, les choix sont faits — le data model, le vendeur, les hypothèses de déploiement. C’est ainsi qu’on se retrouve avec plusieurs datastores, des migrations de schéma inachevées, une observabilité greffée après coup et des runbooks que personne n’écrit car personne ne prévoyait d’être celui qui le ferait tourner.
Ces décisions ont des conséquences concrètes, souvent coûteuses en aval. Le support multi-région, la résidence des données, l’isolation des tenants — de plus en plus crucial pour les entreprises attentives à la conformité — sont des propriétés architecturales, pas des features à ajouter en fin de sprint. La courbe opératoire se moque que le choix ait été fait dans une pièce où personne n’y pensait. Les coûts s’accumulent quoi qu’il en soit.
Ce que le codage assisté par IA change — ou pas
La courbe d’auteur s’effondre. Écrire, refactorer et tester du code coûte moins cher — ce qui prenait un sprint prend un après-midi. La démocratisation qui s’ensuit est réelle : plus de personnes peuvent désormais façonner le design produit, peu importe leur background en code, et c’est une bonne chose.
Mais la courbe opératoire ne fonctionne pas de la même manière. Faire tourner, observer, sécuriser et faire évoluer ce que devient ce code en production ne coûte pas moins cher simplement parce que le code a été écrit à moindre coût. Au contraire, la surface s’étend : plus de code signifie plus de modes de défaillance, plus d’options de configuration, plus de choses à monitorer. Le coût migre, il ne disparaît pas.
Dans le contexte IA, il est utile de penser en termes de personas et workflows. L’IA peut être un assistant, un collègue, un planificateur, un architecte — et entrer plus tôt dans le processus, avant que les choix soient verrouillés. Le contexte compte toutefois. Je n’engagerais pas mon assistant personnel pour réparer ma plomberie ou mon électricité. Même logique : IA-coder n’est pas IA-architecte, et les confondre coûte cher.
Le risque n’est pas la confusion du rôle chez l’agent — mais chez les humains qui le dirigent. Si vous utilisez une IA pour livrer plus vite sans changer l’endroit où l’on considère la courbe opératoire dans le processus, vous avez juste bâti le mur plus vite. Les choix restent verrouillés tôt. Les ops ne sont toujours pas dans la pièce.
Ce qui résout le problème structurel, ce n’est pas l’IA qui génère du code. C’est l’IA impliquée plus tôt dans l’architecture — la planification, le test des hypothèses avant le verrouillage des choix. Qu’une personne, une équipe ou un agent ait la propriété d’un souci importe moins que sa représentation. L’outil n’est pas le remède. Le workflow, si.
La nouvelle forme du rôle
À mesure que la courbe d’auteur se dissout, un questionnement s’installe dans l’industrie sur ce qui vaut vraiment la peine d’être construit. Le no/low-code comme proposition de valeur est moins convaincant.
J’aimerais voir DevOps évoluer vers un véritable département R&D produit plutôt qu’un service pour équipes dev. Les programmes de crash test n’absorbent pas seulement l’impact ; ils génèrent des données qui changent la conception avant que la voiture soit construite.
Nous avons besoin de plateformes conçues pour la collaboration, pas pour le libre-service. Pour reprendre une analogie du jeu vidéo : les jeux qui récompensent les réflexes individuels rapides ou le déblocage d’achievements sont moins intéressants aujourd’hui. Les jeux qui récompensent la pensée à long terme, la construction de coalitions et le discernement de quand ne pas bouger sont ceux qui correspondent à ce qui est vraiment difficile. La rapidité n’est qu’une base. Ce que vous gérez, c’est un système avec beaucoup de pièces mobiles, peu de visibilité, et des décisions qui s’accumulent. Le jeu que joue votre équipe est déterminé par ce que vous récompensez — et la plupart des systèmes d’incitation récompensent encore les réflexes.
Les questions que j’ai posées lors de cette relecture — cibles de déploiement, versioning, maintenabilité, parité des environnements — n’étaient pas des questions sur le code. Elles n’ont pas été répondues par la qualité du Terraform généré. Elles l’ont été — ou non — par les décisions prises avant que quelqu’un n’ouvre un prompt.
Voilà ce qui reste. Le code est devenu bon marché. Les questions, non. Ce qu’il faut se demander, ce n’est pas si l’IA peut écrire le module — mais si votre workflow fait entrer la courbe opératoire dans la pièce avant que les choix soient déjà faits.