L’ère des usines à code et le futur du SRE

À l’origine, c’était un modeste texte que je n’avais partagé qu’avec mon entourage, mais comme les retours ont été plutôt bons, je le partage aussi sur Geeknews pour entendre les idées et points de vue d’autres personnes. Si cela vous semble être un article promotionnel, n’hésitez pas à me le signaler !

---

Résumé

• Les fondements du software engineering sont en train d’être restructurés par la montée fulgurante de l’IA et de l’automatisation. Cette transformation a atteint un niveau irréversible, et les pratiques ainsi que les workflows existants sont en train d’être réévalués en profondeur
• La condition dans laquelle l’IA remplacerait complètement les développeurs humains traditionnels dans l’industrie n’est pas simplement que l’IA écrive mieux le code que les humains, mais qu’une capacité de production autonome de l’IA soit supérieure à la combinaison humain + IA. Cet avenir n’arrivera pas si vite
• Les workflows centrés sur l’humain, les best practices et les modèles de collaboration existants (TDD, système Git/PR, etc.) doivent être réexaminés à l’ère de l’IA
• Ce qu’on peut créer facilement avec le vibe coding n’offre, par définition, que peu d’avantage concurrentiel. Dans les projets sérieux, même avec l’automatisation par l’IA, des processus d’ingénierie fins (gestion du contexte des LLM, automatisation de la validation, gestion du code, etc.) restent essentiels
• Grâce à l’IA, tout le monde peut désormais créer du logiciel, mais l’exploitation réelle des services (SRE/DevOps) reste difficile à automatiser. Vercel/Supabase deviennent coûteux à grande échelle, AWS/Kubernetes sont complexes, et configurer la supervision et les alertes est encore plus difficile
• Plus l’IA accélère l’écriture du code, plus la charge SRE/DevOps/exploitation augmente au contraire. Ce domaine est stateful, le coût des hallucinations y est élevé, et il nécessite le traitement de métriques/logs en temps réel, ce qui se prête mal à une résolution par les seuls LLM
• Intégrer un agent LLM dans une instance EC2 pour le laisser exploiter le système de manière autonome revient à peu près à donner à un LLM de simples instantanés de caméra pour lui demander de faire de la conduite autonome : c’est une idée irréaliste, et une approche plus fondamentale est nécessaire
• Comme pour les niveaux 2→4→5 de la conduite autonome, l’« exploitation autonome » des services nécessite elle aussi une approche technique distincte, un « modèle système », avec des éléments tels que le sensing (logs/métriques) et un world model (architecture virtuelle/simulation de trafic)

[joellim]

J’ai bien lu l’article, mais comme vous l’avez mentionné dans le corps du texte, il ressemble à un contenu promotionnel et ne semble pas correspondre à l’esprit de GeekNews.

[roxie]

Comme première étape vers cet objectif, je vais bientôt lancer un MVP adapté à l’ère de l’Agentic Coding, offrant un déploiement simple de conteneurs et de l’observabilité (monitoring, métriques, alertes, etc.). J’y ajouterai ensuite tout ce qui est utilisé pour exploiter de vrais services, par exemple des infrastructures stateful comme les DB et les MQ, ainsi que des sites web statiques. Au départ, cela commencera comme un PaaS, mais je lancerai rapidement un produit qui s’installe sur le compte et le système des utilisateurs afin d’augmenter le chiffre d’affaires et d’obtenir de bons investissements.

Et, à terme, je veux parvenir à une exploitation entièrement autonome des opérations/SRE/DevOps.

J’ai l’impression que c’est là le point clé : qu’est-ce qui vous fait penser que vous pourrez faire mieux qu’AWS et Vercel ?

[dopeflamingo]

Je suis tout à fait d’accord et je partage une réflexion similaire. En réalité, c’est un fait que tous ceux qui font du développement logiciel à un niveau professionnel connaissent déjà... aujourd’hui, c’est presque un consensus dans la communauté logicielle.

[dopeflamingo]

Je pense que le point de bascule, c’est simplement que les non-développeurs peuvent désormais concrétiser en logiciel des idées qu’ils n’arrivaient pas à mettre en œuvre jusque-là, ne serait-ce que sous forme de prototype.

Et que les développeurs logiciel professionnels de niveau senior ou au-dessus peuvent, seuls, pousser leur productivité à l’extrême et accélérer énormément la vitesse de développement d’un service (mais il y a néanmoins des goulets d’étranglement à cause de l’architecture, de la revue de code et des points que vous avez expliqués plus haut).

À la base, même vercel fait tourner son service en y injectant énormément de main-d’œuvre…

[geekbini]

Est-ce qu’on ne verra pas aussi arriver des solutions capables d’automatiser le SRE/DevOps avec l’IA ? (Cela pourrait même devenir une nouvelle idée de business.) Je me dis aussi que les acteurs déjà présents sur ce marché sont probablement en train de développer des solutions d’IA en interne.

[dongho42]

https://github.com/HolmesGPT/holmesgpt J’avais déjà vu il y a quelque temps quelques outils similaires à celui-ci, donc j’imagine qu’à l’heure qu’il est il en existe probablement encore davantage. Surtout, quand je regarde les gens autour de moi qui travaillent en entreprise, chacun fabrique directement toutes sortes de choses en interne dans sa boîte. À la base, c’est aussi devenu une époque où l’IA crée ce genre de choses de nos jours.

[bungker]

À bien y réfléchir, moi aussi j’en fabrique tous les week-ends. En me disant que ça, personne ne l’a encore fait.

[jameslee9506]

Personnellement, compte tenu de la vitesse de progression de l’IA, je me dis qu’on pourrait un jour regarder cela en arrière et se dire qu’on s’est complètement trompé.