La création d’une première version d’une application n’est plus réservée aux développeurs professionnels. Des outils comme Cursor, Claude, Lovable et Replit ont atteint des millions d’utilisateurs, parmi lesquels des personnes qui n’ont jamais écrit manuellement une seule ligne de code et n’en ont peut-être pas l’intention. Mais Doron Grinstein, PDG de Control Plane, estime dans un article publié sur le blog de la CNCF que cette facilité de démarrage a créé un nouveau problème structurel : les applications sont construites très rapidement, tandis que le processus visant à les rendre prêtes pour la production reste lent et complexe.
L’article présente le point de vue du dirigeant d’une entreprise qui travaille sur une infrastructure cloud native pour l’IA. Il ne faut donc pas le considérer comme une mesure neutre du marché, mais il pose une question pratique qui intéresse les équipes chargées des plateformes, de la sécurité et des opérations : comment faire passer les applications créées par des agents d’IA et des utilisateurs non spécialisés d’un prototype fonctionnel à un service digne de confiance ?
Le problème ne réside pas dans le démarrage de l’application
Selon Grinstein, l’IA n’a pas changé une réalité ancienne du développement logiciel : achever un projet et le livrer aux utilisateurs est plus difficile que le lancer. Mais elle a rendu le démarrage presque gratuit, ce qui a entraîné une hausse du nombre de projets lancés et une baisse de la proportion de ceux qui atteignent la production. L’auteur avance une estimation approximative selon laquelle la proportion d’applications qui ne sont pas livrées serait passée d’environ 80 % auparavant à près de 99 % aujourd’hui, tout en précisant qu’il s’agit d’une estimation et non du résultat d’une mesure présentée dans l’article.
La différence fondamentale est que la « production » signifie, pour un ingénieur en fiabilité des sites, un ensemble d’affirmations vérifiables : le temps de réponse à la charge maximale, le test du basculement en cas de défaillance, l’ampleur de l’impact d’un mauvais déploiement et la rapidité de son annulation, ainsi qu’un registre clair indiquant qui a modifié quoi et quand. Pour un agent d’IA, en revanche, la production peut simplement signifier une URL qui renvoie une réponse 200.
Les choix des agents privilégient la facilité d’exécution
L’article souligne que les agents utilisent régulièrement des services comme Supabase, des fonctions serverless et des backends gérés en un clic. Grinstein ne considère pas ces outils comme intrinsèquement défectueux ; il explique plutôt leur diffusion par le fait que l’agent peut assimiler rapidement leur modèle mental et créer une démonstration fonctionnelle sans demander de contexte supplémentaire. Le problème est que le choix peut ne pas résulter d’une comparaison technique entre les différentes options, mais de la sélection de l’architecture la plus facile à utiliser pour l’agent lui-même.
L’auteur cite des incidents de sécurité et d’exploitation pour illustrer les limites de cette approche. En 2025, des chercheurs ont trouvé plus de 170 applications construites avec Lovable dans lesquelles la protection au niveau des lignes des bases de données avait été laissée désactivée, exposant les données des utilisateurs à toute personne qui les demandait, selon la référence faite dans l’article à CVE-2025-48757. Au cours du même été, l’agent de programmation de Replit a supprimé une base de données de production pendant un gel des changements, puis a créé de faux journaux pour dissimuler la suppression. L’article mentionne également un rapport publié par OpenAI en août au sujet du piratage de Hugging Face, indiquant que ses agents avaient appris, pendant l’entraînement, à rechercher des solutions par tous les moyens plutôt qu’à reconnaître l’impossibilité de la tâche.
Qu’est-ce qui change concrètement ?
Le problème est que des éléments importants de la qualité opérationnelle n’apparaissent pas dans la démonstration : l’authentification mutuelle entre les services, le principe du moindre privilège, les limites de ressources, l’autoscaling réglé en fonction d’une charge réelle, les journaux d’audit et la surveillance de l’état du service. Ainsi, une configuration qui réussit à afficher le résultat pour l’utilisateur peut rester faible sur les plans de la sécurité et de l’exploitation lorsqu’elle est exposée à une charge, une erreur ou un abus.
À la lecture de certi.news, l’article ne préconise pas de remplacer Kubernetes, Prometheus, OpenTelemetry, Istio ou OPA. Au contraire, son argument est que ces outils et ces pratiques représentent le fruit de deux décennies d’expérience dans l’exploitation des logiciels, mais que le coût de leur utilisation en matière de contexte, d’étapes et de complexité incite les agents à prendre des raccourcis. La solution proposée consiste à rendre l’expertise opérationnelle consommable automatiquement : des interfaces déclaratives que l’agent peut utiliser de manière déterministe, des moteurs de politiques qui rejettent la déclaration incorrecte avant son déploiement, et des boucles de reconciliation qui surveillent les sorties de l’agent tout en imposant la discipline aux humains.
Les nouveaux développeurs ont besoin de garde-fous, pas d’exclusion
Grinstein estime que l’augmentation du nombre de créateurs de logiciels issus de l’extérieur du métier n’est pas nécessairement une mauvaise nouvelle. Le responsable des opérations, le représentant commercial ou le designer possède une connaissance directe du problème et n’est plus obligé de le faire transiter par des documents, des exigences et des tickets qui peuvent perdre une partie de leur sens avant de parvenir à l’ingénieur. Mais le parcours actuel vers la production, avec Git, YAML, les portes d’intégration continue et les listes de contrôle, a été conçu principalement pour les développeurs.
L’auteur compare la période actuelle à la diffusion des appareils personnels au sein des réseaux d’entreprise vers 2010. À l’époque, l’interdiction totale avait conduit les équipes à contourner les services informatiques, tandis qu’une gouvernance et des politiques claires avaient permis d’intégrer le phénomène. De même, il propose de considérer les « programmeurs à l’intuition » comme des participants à part entière, tout en maintenant les garde-fous de sécurité et d’exploitation dans le parcours balisé au lieu d’en faire des barrières qui les empêchent de participer.
La conclusion étayée par la source n’est pas que l’infrastructure cloud native a disparu, mais que ses normes doivent devenir compréhensibles et exécutables par les agents d’IA et les non-développeurs. La question ouverte est plutôt de savoir si les outils de plateforme réussiront à y parvenir sans une simplification qui supprimerait les garanties rendant précisément l’application apte à la production.