Comment mettre un prototype créé par IA en production

Pour mettre un prototype IA en production, il faut combler l'écart entre « ça marche quand je l'essaie » et « ça continue de marcher quand d'autres l'utilisent ». Concrètement, cela passe par cinq points : tester les parcours principaux à chaque modification, verrouiller qui peut voir et modifier quoi, être prévenu des erreurs avant que vos utilisateurs ne vous les signalent, sauvegarder les données et prouver que vous savez les restaurer, et garder l'application assez rapide sur un téléphone. Rien de tout cela n'exige une réécriture : c'est une liste de contrôle à parcourir avec la même IA qui a construit le prototype.

Prototype ou production : ce qui change vraiment

Un prototype a un seul utilisateur attentif : vous. Vous savez quels boutons appuyer, vous saisissez des données cohérentes et, si quelque chose casse, vous haussez les épaules et demandez à l'IA de corriger. La production, c'est de nombreux utilisateurs peu soigneux, quelques curieux et parfois un utilisateur malveillant. Le code n'a pas besoin de devenir « d'entreprise » ; il doit gérer les situations qu'un prototype ne rencontre jamais.

Le reste de ce guide reprend chaque ligne de ce tableau.

Étape 1 : Figer le périmètre et lister les parcours principaux

Avant de renforcer quoi que ce soit, décidez ce qu'est la version un. Listez trois à six parcours essentiels, par exemple « s'inscrire, créer un projet, inviter un collègue, payer ». Ils deviennent votre script de test, vos cibles de surveillance et les points à vérifier après chaque modification.

Tout ce qui n'est pas sur la liste est soit retiré, soit clairement indiqué comme bêta. Il est bien plus facile de fiabiliser quatre parcours que quatorze.

Étape 2 : Tester comme un inconnu, puis rendre le test reproductible

Les outils de création par IA produisent bien du code qui fonctionne dans le cas nominal. Les problèmes de production surviennent dans les cas non prévus. Testez chaque parcours principal avec :

• Des saisies incorrectes : champs obligatoires vides, un nom de 5 000 caractères, une adresse e-mail sans @, une quantité négative, une date passée.
• Actualisations et bouton retour : rechargez la page en pleine commande ; revenez en arrière après l'envoi d'un formulaire. Est-ce que quelque chose est créé deux fois ?
• Deux onglets, deux utilisateurs : connectez-vous avec deux comptes différents et essayez d'ouvrir les pages de l'autre en modifiant l'identifiant dans l'URL.
• Lent et petit : un écran de téléphone et une connexion bridée (les outils de développement du navigateur peuvent la simuler).
• États vides : un compte tout neuf sans donnée. Les prototypes sont souvent construits avec des données d'exemple et semblent cassés sans elles.

Ensuite, rendez le test reproductible. Au minimum, gardez une liste de contrôle écrite et exécutez-la avant chaque mise en ligne. Mieux encore, demandez à l'IA d'écrire des tests automatisés pour les parcours les plus importants :

Ajoute des tests automatisés de bout en bout pour ces parcours : inscription par e-mail, création d'un projet, invitation d'un second utilisateur, et paiement complet en mode test de Stripe. Ajoute aussi des tests qui confirment qu'un utilisateur ne peut pas voir ni modifier le projet d'un autre en changeant l'URL.

Les tests qui prouvent qu'un utilisateur ne peut pas faire quelque chose sont justement ceux qui manquent le plus souvent aux prototypes.

Étape 3 : Les bases de la sécurité que les prototypes oublient

La plupart des problèmes de sécurité des applications créées par IA ne sont pas exotiques. Ce sont des contrôles manquants. Parcourez cette liste, et consultez la liste de contrôle de sécurité pour les applications créées par IA pour aller plus loin :

• Autorisations côté serveur. Masquer un bouton n'est pas une sécurité. Chaque requête qui lit ou modifie des données doit vérifier, côté serveur, que l'utilisateur connecté en a le droit. Si votre application utilise une base de données avec des règles au niveau des lignes, vérifiez qu'elles sont activées et testées.
• Secrets hors du navigateur. Les clés d'API pour les paiements, les e-mails ou les fournisseurs d'IA doivent rester dans les variables d'environnement côté serveur, jamais dans le code front-end. Si vous ne savez pas ce que cela signifie, lisez ce que sont les variables d'environnement et les secrets.
• Validation côté serveur. Le navigateur peut être contourné : répétez sur le serveur toute vérification importante.
• Connexion bien faite. Utilisez une bibliothèque ou un service d'authentification éprouvé plutôt qu'un stockage de mots de passe fait maison. Notre guide sur l'ajout d'une connexion à votre application présente les options.
• Limitation du nombre de requêtes sur la connexion, l'inscription, la réinitialisation du mot de passe et tout ce qui envoie un e-mail ou appelle une API payante.
• Messages d'erreur discrets. Les utilisateurs doivent voir « une erreur est survenue » ; les détails vont dans vos journaux, pas à l'écran.
• Renouveler tout secret qui a fuité. Si une clé active a déjà été collée dans un chat, un commit ou une capture d'écran, remplacez-la chez le fournisseur.

Une consigne qui couvre beaucoup de terrain à la fois :

Examine cette application du point de vue de la sécurité en production. Vérifie que chaque route d'API contrôle que l'utilisateur connecté est propriétaire de l'enregistrement qu'elle lit ou modifie, qu'aucune clé secrète n'est envoyée au navigateur, que les données sont validées côté serveur, et que la connexion et la réinitialisation du mot de passe sont limitées en nombre de requêtes. Liste ce que tu trouves avant de modifier quoi que ce soit.

Demander d'abord une liste permet de voir les problèmes et de décider de l'ordre des corrections, au lieu de recevoir une modification massive.

Étape 4 : Savoir quand ça casse — journalisation et surveillance

Dans l'aperçu, vous voyez les erreurs au moment où elles surviennent. En production, il faut que l'application vous prévienne. Trois niveaux, du moins coûteux au plus utile :

1. Journaux serveur. Assurez-vous que les erreurs sont journalisées avec assez de contexte pour les reproduire : quelle route, quel identifiant utilisateur (jamais son mot de passe ni sa carte), quelle forme de saisie. Si l'application ne fait qu'écrire dans la console, demandez à l'IA d'ajouter une journalisation structurée.
2. Suivi des erreurs. Un service comme Sentry ou un outil similaire capture les exceptions front-end et back-end, les regroupe et vous envoie un e-mail. Pour une petite application, les offres gratuites de ces services suffisent souvent ; vérifiez les limites actuelles sur leurs sites.
3. Contrôles de disponibilité. Un service externe qui charge votre page d'accueil et une route d'API clé toutes les quelques minutes et vous alerte en cas d'échec. Cela détecte les problèmes qui empêchent l'application de journaliser quoi que ce soit.

Ajoutez une habitude : après chaque mise en ligne, ouvrez l'application réelle et parcourez votre liste de parcours principaux sur l'URL en production, pas seulement sur l'aperçu.

Étape 5 : Sauvegardes et possibilité de revenir en arrière

Deux éléments distincts doivent être protégés, et on les confond facilement.

• Le code. Gardez le projet sous contrôle de version pour que toute modification puisse être annulée. Beaucoup d'outils de création par IA conservent des points de restauration de vos fichiers ; la synchronisation avec un dépôt Git vous donne une copie hors de l'outil.
• Les données. Revenir en arrière sur le code ne restaure pas la base de données. Une mauvaise migration ou un bouton de suppression défectueux peut détruire des lignes qu'aucun point de restauration du code ne remettra en place.

Pour les données, mettez en place des sauvegardes régulières stockées ailleurs que chez l'hébergeur de l'application : pour une base Postgres, un pg_dump planifié vers un stockage séparé est l'approche courante, et de nombreux hébergeurs de bases gérées proposent des sauvegardes automatiques ou une restauration à un instant donné. Faites ensuite l'étape que la plupart des gens sautent : restaurer une sauvegarde dans une base de test et vérifier que les données sont bien là.

Demandez aussi à l'IA de rendre les actions destructrices plus sûres : une étape de confirmation pour les suppressions, et une « suppression douce » (marquer les lignes comme supprimées plutôt que de les effacer) pour tout ce que les utilisateurs pourraient vouloir récupérer.

Étape 6 : Des performances qui tiennent sur un téléphone

Les prototypes semblent rapides parce que vous êtes le seul utilisateur et que les données sont minuscules. Avant le lancement :

• Charger des données de taille réelle. Demandez à l'IA d'insérer quelques milliers de lignes et voyez quelles pages ralentissent. Les listes ont généralement besoin de pagination, et la base a généralement besoin d'index sur les colonnes utilisées pour filtrer et trier.
• Réduire les images. Des images trop lourdes sont la cause la plus fréquente de lenteur. Demandez des images redimensionnées, compressées et un chargement différé sous la ligne de flottaison.
• Mesurer. Lancez Lighthouse dans les outils de développement de Chrome sur l'URL en production, en mode mobile. Les Core Web Vitals de Google sont une cible raisonnable : Largest Contentful Paint en dessous de 2,5 secondes, Interaction to Next Paint de 200 ms ou moins, et Cumulative Layout Shift de 0,1 ou moins.
• Surveiller les délais de « réveil ». Un hébergement qui s'endort lorsqu'il est inactif fait économiser de l'argent, mais rend la première visite après une période calme plus lente. C'est souvent un compromis acceptable pour une nouvelle application, à condition de savoir que cela se produit.

La page des projets est lente avec 5 000 lignes. Ajoute une pagination côté serveur (25 par page), ajoute des index de base de données sur les colonnes que nous filtrons et trions, et affiche un état de chargement pendant le chargement de la page suivante.

Étape 7 : Les bases de l'exploitation

Quelques petites choses séparent une application de loisir d'une application en laquelle les gens ont confiance :

• Un nom de domaine personnalisé en HTTPS. Voir comment connecter un nom de domaine personnalisé.
• Un e-mail transactionnel envoyé depuis un domaine vérifié, pour les confirmations d'inscription et les réinitialisations de mot de passe, expliqué dans comment envoyer des e-mails depuis votre application.
• Une politique de confidentialité et des conditions qui décrivent ce que vous collectez réellement. Ne recopiez pas des engagements de conformité que vous n'avez pas remplis.
• Un moyen de support : même une adresse e-mail surveillée.
• Des clés de test et des clés réelles séparées pour les paiements et les e-mails, et une note indiquant quel environnement utilise quelles clés.

Étape 8 : Une passation propre

Tôt ou tard, quelqu'un d'autre travaillera sur l'application : un freelance, un nouveau cofondateur, ou vous dans six mois. Facilitez-le :

• Un README qui explique comment la lancer, quelles variables d'environnement elle requiert (noms et rôles uniquement, jamais les valeurs), et comment la déployer.
• La liste des parcours principaux et les tests automatisés.
• Une courte note d'architecture : front-end, back-end, base de données, services tiers, et l'hébergement de chacun.
• Une liste d'accès : qui a les droits administrateur sur le domaine, l'hébergement, la base de données, les comptes de paiement et d'e-mail. Placez ces comptes sous une adresse e-mail professionnelle, pas personnelle.
• Le code dans Git, idéalement synchronisé avec un dépôt qui vous appartient. Si vous envisagez de changer d'hébergement plus tard, lisez comment exporter une application créée par IA et l'héberger soi-même.

L'IA peut rédiger l'essentiel de cette documentation pour vous :

Rédige un README pour ce projet, destiné à un développeur qui ne l'a jamais vu : ce que fait l'application, la pile technique, comment la lancer en local, chaque variable d'environnement lue (noms et rôle uniquement), comment le schéma de la base est organisé, et comment la déployer.

Liste de contrôle de mise en production

• Parcours principaux écrits et testés, y compris « impossible d'accéder aux données d'un autre utilisateur »
• Autorisations et validation côté serveur sur chaque route de données
• Aucune clé secrète dans le code front-end ; clés compromises renouvelées
• Limitation du nombre de requêtes sur l'authentification et sur tout ce qui coûte de l'argent
• Suivi des erreurs et alertes de disponibilité envoyées vers une boîte que vous lisez
• Sauvegardes de la base hors de l'hébergement de l'application, avec une restauration de test réussie
• Pagination et index vérifiés avec des données réalistes
• Nom de domaine personnalisé, domaine d'envoi vérifié, politique de confidentialité
• README et liste d'accès pour la personne qui prendra le relais

Travailler avec Mythex

Si vous avez construit le prototype dans Mythex, la plupart de ces étapes se font par des consignes dans le même projet. Tapez /test et Mythex parcourt l'aperçu en direct comme un utilisateur et signale les parcours cassés : voir App Testing. Les clés vont dans les secrets du projet plutôt que dans le chat ; chaque tour réussi de l'agent enregistre un point de restauration de vos fichiers auquel vous pouvez revenir ; et la publication vous donne une URL en ligne, avec l'hébergement et la base de données facturés sur le même solde de crédits (limites d'hébergement explique comment les applications et les bases se mettent en veille puis se réveillent). Les points de restauration couvrent les fichiers, pas les lignes de la base : prévoyez quand même vos sauvegardes de données. Sur le forfait Pro, vous pouvez connecter un nom de domaine personnalisé et exporter le code ou le synchroniser avec votre propre dépôt GitHub pour une passation.

Questions