Comment faire passer un prototype IA en production

Pour faire passer un prototype IA en production, vous comblez l'écart entre « ça fonctionne quand j'essaie » et « ça continue de fonctionner quand d'autres l'utilisent ». Concrètement, cela signifie cinq choses : tester les parcours principaux à chaque modification, verrouiller qui peut voir et modifier quoi, vous assurer d'être informé des erreurs avant que vos utilisateurs ne vous en parlent, sauvegarder les données et prouver que vous pouvez les restaurer, et garder l'application assez rapide sur un téléphone. Rien de tout cela ne nécessite une réécriture : c'est une liste de vérification que vous parcourez avec la même IA qui a construit le prototype.

Prototype ou production : ce qui change vraiment

Un prototype n'a qu'un utilisateur prudent : vous. Vous savez sur quels boutons appuyer, vous saisissez des données raisonnables, et si quelque chose brise, vous haussez les épaules et demandez à l'IA de corriger. La production compte de nombreux utilisateurs distraits, 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 parcourt chaque ligne du tableau.

Étape 1 : Figez la portée et notez les parcours principaux

Avant de renforcer quoi que ce soit, décidez de ce que sera la première version. Listez les trois à six parcours qui comptent le plus, par exemple « s'inscrire, créer un projet, inviter un coéquipier, payer ». Ces parcours deviennent votre script de test, vos cibles de surveillance et les éléments à vérifier après chaque modification.

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

Étape 2 : Testez comme un inconnu, puis rendez le test reproductible

Les créateurs par IA produisent bien du code qui fonctionne dans le cas idéal. Les problèmes de production se trouvent dans les cas non prévus. Testez chaque parcours principal avec :

• Mauvaises entrées : champs obligatoires vides, un nom de 5 000 caractères, un courriel sans @, une quantité négative, une date passée.
• Actualisations et bouton précédent : rechargez en plein milieu d'un paiement; appuyez sur précédent après avoir soumis un formulaire. Est-ce que quelque chose se crée 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 la taille d'un téléphone et une connexion limitée (les outils de développement du navigateur peuvent en simuler une).
• États vides : un compte tout neuf sans données. Les prototypes sont souvent construits avec des données d'exemple et paraissent cassés sans elles.

Rendez ensuite le test reproductible. Au minimum, conservez une liste de vérification écrite et exécutez-la avant chaque mise en production. Mieux encore, demandez à l'IA d'écrire des tests automatisés pour les parcours qui comptent le plus :

Ajoute des tests automatisés de bout en bout pour ces parcours : inscription par courriel, 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 ou modifier le projet d'un autre en changeant l'URL.

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

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

La plupart des problèmes de sécurité dans les applications créées par IA ne sont pas exotiques. Il manque simplement des vérifications. Parcourez cette liste, et consultez la liste de contrôle de sécurité pour applications créées par IA pour une version complète :

• Autorisation côté serveur. Cacher un bouton n'est pas de la sécurité. Chaque requête qui lit ou modifie des données doit vérifier, côté serveur, que l'utilisateur connecté a le droit de le faire. 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, le courriel ou les fournisseurs d'IA doivent se trouver dans des variables d'environnement côté serveur, jamais dans le code frontal. 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 donc côté serveur toute vérification qui compte.
• Connexion bien faite. Utilisez une bibliothèque ou un service d'authentification bien éprouvé plutôt qu'un stockage de mots de passe maison. Notre guide sur l'ajout d'une connexion à votre application présente les options.
• Limites de débit sur la connexion, l'inscription, la réinitialisation du mot de passe et tout ce qui envoie des courriels ou appelle une API payante.
• Messages d'erreur conviviaux. Les utilisateurs doivent voir « une erreur s'est produite »; les détails vont dans vos journaux, pas à l'écran.
• Renouvelez tout ce qui a fuité. Si une clé réelle a été collée dans un clavardage, un commit ou une capture d'écran, remplacez-la chez le fournisseur.

Une invite qui couvre beaucoup de terrain à la fois :

Examine cette application pour la sécurité en production. Vérifie que chaque route d'API confirme 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 entrées sont validées côté serveur, et que la connexion et la réinitialisation du mot de passe sont limitées en débit. Dresse la liste de ce que tu trouves avant de rien modifier.

Demander d'abord une liste vous permet de voir les problèmes et de décider de l'ordre, au lieu de recevoir un seul changement massif.

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

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

1. Journaux serveur. Assurez-vous que les erreurs sont enregistrées avec assez de contexte pour les reproduire : quelle route, quel identifiant d'utilisateur (ni mot de passe ni carte), quelle forme de saisie. Demandez à l'IA d'ajouter une journalisation structurée si l'application ne fait qu'afficher des messages dans la console.
2. Suivi des erreurs. Un service comme Sentry ou un outil semblable capte les exceptions frontales et dorsales, les regroupe et vous envoie un courriel. Pour une petite application, les forfaits gratuits de ces services suffisent souvent; vérifiez les limites actuelles sur leurs sites.
3. Vérifications 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 de plus : après chaque mise en production, ouvrez l'application en direct et parcourez votre liste de parcours principaux sur l'URL réelle, et non seulement dans l'aperçu.

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

Deux éléments différents doivent être protégés, et il est facile de les confondre.

• Le code. Conservez le projet dans un système de gestion de versions afin que toute modification puisse être annulée. Plusieurs créateurs par IA conservent des points de contrôle de vos fichiers; la synchronisation avec un dépôt Git vous donne une copie hors du créateur.
• Les données. Revenir à une version antérieure du code ne restaure pas la base de données. Une mauvaise migration ou un bouton de suppression bogué peut détruire des lignes qu'aucun point de contrôle du code ne ramènera.

Pour les données, mettez en place des sauvegardes régulières stockées ailleurs que sur l'hébergement de l'application — pour une base Postgres, un pg_dump planifié vers un stockage distinct est l'approche courante, et plusieurs hébergeurs de bases de données gérées offrent des sauvegardes automatiques ou une restauration à un point dans le temps. Faites ensuite l'étape que la plupart des gens sautent : restaurez une sauvegarde dans une base de données temporaire et vérifiez que les données s'y trouvent.

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 : Une performance qui tient 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 :

• Chargez des données de taille réelle. Demandez à l'IA d'ajouter quelques milliers de lignes et voyez quelles pages ralentissent. Les listes exigent habituellement une pagination, et la base de données a généralement besoin d'index sur les colonnes que vous filtrez et triez.
• Réduisez les images. Des images trop volumineuses 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.
• Mesurez. Exécutez Lighthouse dans les outils de développement de Chrome sur l'URL en direct en mode mobile. Les Core Web Vitals de Google sont une cible raisonnable : Largest Contentful Paint en moins de 2,5 secondes, Interaction to Next Paint de 200 ms ou moins, et Cumulative Layout Shift de 0,1 ou moins.
• Surveillez 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; sachez simplement 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 pour les colonnes que nous filtrons et trions, et affiche un état de chargement pendant le chargement de la page suivante.

Étape 7 : Bases opérationnelles

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

• Un domaine personnalisé avec HTTPS. Voir comment connecter un domaine personnalisé.
• Courriels transactionnels envoyés depuis un domaine vérifié pour les confirmations d'inscription et la réinitialisation des mots de passe, expliqués dans comment envoyer des courriels depuis votre application.
• Une politique de confidentialité et des conditions qui décrivent ce que vous recueillez réellement. Ne copiez pas des déclarations de conformité que vous n'avez pas méritées.
• Un moyen de soutien : même une adresse courriel surveillée.
• Des clés de test et des clés réelles distinctes pour les paiements et le courriel, et une note claire indiquant quel environnement utilise quelle clé.

Étape 8 : Une passation propre

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

• Un README qui explique comment la faire fonctionner, quelles variables d'environnement elle requiert (noms seulement, jamais les valeurs), et comment la déployer.
• La liste de vérification des parcours principaux et les tests automatisés.
• Une courte note d'architecture : frontal, dorsal, base de données, services tiers, et l'endroit où chacun est hébergé.
• Liste d'accès : qui a un accès administrateur au domaine, à l'hébergement, à la base de données, aux comptes de paiement et de courriel. Placez ces comptes sous une adresse courriel d'entreprise, et non personnelle.
• Le code dans Git, idéalement synchronisé avec un dépôt que vous possédez. Si vous pourriez 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 la majeure partie de cela 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 technologique, comment la faire fonctionner localement, chaque variable d'environnement lue (noms et utilité seulement), comment le schéma de la base de données est organisé, et comment la déployer.

Liste de vérification de préparation à la production

• Parcours principaux écrits et testés, y compris « impossible d'accéder aux données d'un autre utilisateur »
• Autorisation et validation côté serveur sur chaque route de données
• Aucune clé secrète dans le code frontal; clés qui ont fui renouvelées
• Limites de débit sur l'authentification et tout ce qui coûte de l'argent
• Suivi des erreurs et alertes de disponibilité dirigées vers une boîte de réception que vous consultez
• Sauvegardes de base de données 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
• Domaine personnalisé, domaine d'envoi vérifié, politique de confidentialité
• README et liste d'accès pour la personne qui prendra la relève

Faire cela avec Mythex

Si vous avez créé le prototype dans Mythex, la plupart de ces étapes sont des invites dans le même projet. Tapez /test et Mythex parcourt l'aperçu en direct comme un utilisateur et signale les parcours brisés — voir Tests d'application. Les clés vont dans les secrets du projet plutôt que dans le clavardage; chaque tour d'agent réussi enregistre un point de contrôle de vos fichiers auquel vous pouvez revenir, et la publication vous donne une URL en direct avec l'hébergement et la base de données facturés à partir du même solde de crédits (limites d'hébergement explique comment les applications et les bases de données se mettent en veille et se réveillent). Les points de contrôle couvrent les fichiers, non les lignes de la base de données; prévoyez donc tout de même vos sauvegardes de données. Avec le forfait Pro, vous pouvez connecter un domaine personnalisé et exporter le code ou le synchroniser avec votre propre dépôt GitHub pour une passation.

Questions