Ce qui se passe quand votre application construite par IA atteint la production

Un agent qui écrit du code fonctionnel rapidement n’écrit pas automatiquement du code sûr à faire tourner en production — ce sont deux compétences différentes, et la plupart des agents de codage aujourd’hui n’ont que la première. L’écart ne se voit pas tant que l’application tourne sur un ordinateur portable. Il apparaît au moment où elle devient accessible depuis internet avec de vraies données derrière, exactement le moment où c’est le plus difficile à remarquer.

Où se trouve vraiment l’écart

Ce n’est presque jamais la logique applicative. Ce sont les choses autour qu’un agent n’a aucune raison de considérer à moins qu’on le lui demande explicitement : où vit le mot de passe de la base de données, si un identifiant de déploiement peut aussi supprimer la base de données, si un point d’accès public expose discrètement une route d’administration que personne n’avait l’intention de publier. Rien de tout ça n’est un bug dans le code généré — c’est un contexte manquant sur la production qui n’a jamais fait partie du prompt.

Ce que la plateforme gère au lieu d’espérer que l’agent l’ait fait

• Les secrets ne restent jamais en texte clair. env_vars, build_secrets, git_token et registry_password sont chiffrés au repos (chiffrement Active Record, pas une rustine ajoutée après coup). Une application générée qui lit ENV["DATABASE_PASSWORD"] de la façon évidente reçoit la même protection qu’une écrite à la main — le chiffrement est une propriété de la plateforme qui stocke la valeur, pas du soin apporté au code.
• Les secrets générés sont vraiment aléatoires, à chaque fois. Quand une application a besoin d’un SECRET_KEY_BASE ou équivalent, il est généré avec SecureRandom, pas un espace réservé qu’un agent pourrait laisser dans un .env.example commité et oublier de faire tourner.
• L’accès propre d’un agent est limité, pas ambiant. Si vous laissez Claude Code, Cursor, ou n’importe quel autre agent opérer l’application déployée ensuite, le serveur MCP de Railyard lui donne un jeton à un palier précis — lecture, déploiement, ou écriture — jamais un accès général, et les deux actions vraiment destructrices (retirer une variable, supprimer l’application) ne s’exécutent jamais depuis un agent. Elles créent une demande d’approbation qu’un humain doit traiter. Un agent avec un jeton en lecture ne peut physiquement pas être convaincu de déployer quoi que ce soit, peu importe ce qu’on lui demande.

La question qui mérite d’être posée avant de publier

Pas « est-ce que l’agent a écrit du code sécurisé » — c’est le mauvais cadrage, parce que « sécurisé » n’est pas vraiment une propriété de quelques centaines de lignes écrites en un après-midi. La meilleure question : si ce code fait quelque chose de mal, quel est le vrai rayon de l’explosion? Un DATABASE_URL qui a fuité mais qui ne sert que pour cette seule base de données, c’est une mauvaise journée. Un identifiant de déploiement qui peut aussi toucher la facturation, d’autres applications, ou un compte fournisseur, c’est un tout autre genre d’incident. C’est une réponse au niveau de la plateforme, pas de l’ingénierie de prompt.

Ce que ça ne remplace pas

Rien de tout ça ne révise la logique applicative elle-même — un agent peut toujours générer une route sans vérification d’autorisation, ou un formulaire sans validation des entrées, et la plateforme n’a aucun moyen de savoir que c’est mauvais toute seule. Les secrets chiffrés et les jetons de déploiement à portée limitée ferment les modes de défaillance au niveau de l’infrastructure; ils ne remplacent pas la lecture réelle de ce qui a été généré avant que ça ne parte en production.

Référence complète sur l’accès des agents : MCP pour les agents IA.