Du prototype IA à l'application en production

Vous avez construit quelque chose avec Lovable, Bolt, v0, Replit ou Cursor. La démo est convaincante, vos proches sont impressionnés, et l'un d'eux vous a demandé s'il pouvait payer pour l'utiliser.

C'est précisément le moment auquel cet article s'adresse — parce que « ça marche quand je vous le montre » et « je peux facturer ça » sont séparés par un travail précis, fini, et étonnamment ingrat. L'essentiel n'a rien à voir avec des fonctionnalités.

La bonne nouvelle : c'est une checklist, pas un mystère. Et la parcourir revient presque toujours moins cher que de repartir de zéro.

D'abord, définir la cible

« La production » n'est pas une impression. C'est un ensemble de promesses faites à un client payant :

• C'est disponible — et quand ça ne l'est pas, vous l'apprenez avant lui.
• Ses données sont protégées — des autres clients, des attaquants, et de vous qui pourriez les supprimer par accident.
• Ça peut évoluer — vous corrigez un bug le mardi sans casser le mercredi.
• Ça vous survit — quelqu'un d'autre que l'auteur initial peut y travailler.

Un prototype ne tient aucune de ces promesses. Ce n'est pas un défaut : c'est l'intérêt même d'un prototype. Le travail qui suit consiste simplement à les tenir une par une.

Étape 1 : reprendre la main sur le code

Avant tout, répondez à une question : pouvez-vous récupérer le code ?

Certains outils IA vous donnent un dépôt que vous possédez réellement. D'autres vous gardent à l'intérieur de leur plateforme, où « votre application » est un projet dans le produit de quelqu'un d'autre. Acceptable pour un prototype, dangereux pour une entreprise — changements de tarifs, limites de fonctionnalités et fermetures échappent tous à votre contrôle.

Minimum praticable :

• Le code vit dans un dépôt Git qui vous appartient.
• La base de données est la vôtre, avec des identifiants que vous détenez et pouvez faire tourner.
• Vous savez lancer l'application en local, depuis un clone vierge, avec une procédure documentée.

Si vous ne cochez pas les trois, faites-le avant d'écrire une fonctionnalité de plus. Tout le reste de cette liste le présuppose.

Étape 2 : avoir plus d'un environnement

La plupart des projets construits avec l'IA ont exactement un environnement, et c'est la production. Chaque modification est testée sur de vrais utilisateurs.

Il en faut au moins deux — un environnement de préproduction qui reflète la production, et la production elle-même — plus un déploiement déclenché depuis votre branche principale plutôt que par un clic. C'est ce seul changement qui transforme « j'ai peur d'y toucher » en « je livre le vendredi ».

Étape 3 : combler les failles de sécurité

Deux problèmes concentrent l'essentiel des découvertes sérieuses dans les bases de code générées :

1. Contrôles de propriété absents. L'application vérifie que vous êtes connecté, mais pas que l'enregistrement demandé est le vôtre. Changez un identifiant dans une URL et vous pourriez voir les données d'un autre client.
2. Secrets exposés. Clés d'API et identifiants de services placés dans du code côté client, où n'importe qui peut les lire depuis son navigateur.

Les deux se corrigent vite et coûtent cher si on les laisse. Nous approfondissons — avec les trois autres points qui cèdent sous charge réelle — dans ce qui casse à 1 000 utilisateurs.

Ensuite le socle : limitation de débit sur la connexion et les endpoints coûteux, HTTPS partout, dépendances à jour, et toute interface d'administration derrière un vrai contrôle d'accès.

Étape 4 : rendre la base de données modifiable

Les prototypes font évoluer leur schéma à la main : quelqu'un ouvre une interface de base de données et ajoute une colonne. Cela fonctionne exactement jusqu'au jour où vous avez des données que vous ne pouvez pas perdre et un second environnement à garder synchronisé.

Il vous faut des migrations : les changements de schéma sous forme de code, versionnés dans Git, appliqués à l'identique en préproduction et en production. Sans elles, chaque évolution future risque une divergence silencieuse entre environnements — l'une des catégories de bugs les plus pénibles à traquer.

Tant que vous y êtes : des sauvegardes automatiques, et — c'est l'étape que tout le monde saute — une restauration que vous avez réellement effectuée. Une sauvegarde non testée est un espoir, pas un plan.

Étape 5 : décider ce que l'on garde

Vient la question stratégique : consolider l'existant, ou réécrire ?

Soyez honnête, et raisonnez avec une grille plutôt qu'à l'instinct. Réécrivez quand :

• Le modèle de données est fondamentalement inadapté à ce que le produit est devenu.
• Les parcours centraux sont dupliqués à plusieurs endroits avec une logique différente à chaque fois.
• Personne ne peut ajouter une petite fonctionnalité sans en casser deux autres.

Consolidez quand l'application est globalement cohérente et que les problèmes sont ceux de cette liste. C'est la majorité des cas, et cela représente généralement une à quatre semaines de travail contre trois mois ou plus pour une réécriture.

La décision la plus coûteuse à ce stade est de jeter un produit qui fonctionne parce qu'il n'est pas beau à l'intérieur. Moche et rentable vaut mieux qu'élégant et jamais lancé.

Étape 6 : savoir quand c'est cassé

Ne lancez rien de tout cela sans un moyen d'apprendre les incidents autrement que par l'e-mail d'un client :

• Un suivi des erreurs qui capture les exceptions avec assez de contexte pour déboguer.
• Une supervision de disponibilité sur vos parcours critiques, avec alerte là où vous la verrez.
• Des logs structurés, consultables quand quelque chose d'étrange s'est produit à 3 h du matin.

C'est ce que « qui surveille l'application ? » signifie concrètement. Ce n'est pas une personne devant un tableau de bord : c'est une instrumentation qui vous prévient, et quelqu'un qui a accepté de répondre quand elle le fait.

Étape 7 : la liste ingrate du lancement

Vraiment faciles à oublier, vraiment ennuyeux à manquer :

• Un vrai nom de domaine, avec la délivrabilité e-mail configurée (SPF, DKIM, DMARC) pour que vos réinitialisations de mot de passe n'atterrissent pas en spam.
• Politique de confidentialité et conditions d'utilisation, surtout si vous encaissez des paiements ou servez l'UE.
• Des analytics, pour apprendre quelque chose du trafic que vous avez gagné.
• Un parcours de facturation testé, cas d'échec compris — cartes refusées, résiliations, remboursements.
• Un front rapide et accessible. La vitesse est un facteur de conversion et de classement, pas un supplément — voir pourquoi la vitesse d'un site est un levier de croissance.

Ce que cela coûte réellement

Pour un MVP construit avec l'IA en état correct, l'industrialisation représente une à quatre semaines de développement concentré. Sécurité et intégrité des données d'abord, fiabilité ensuite, finitions en dernier.

C'est nettement moins qu'une reconstruction, et c'est l'argent le plus rentable que vous investirez dans le produit — parce que tout ce qui vient après (marketing, ventes, levée de fonds) présuppose que ça fonctionne.

Les outils vous ont mené presque au bout. Voici le reste du chemin. Si vous préférez confier cela à une agence qui le fait chaque semaine, c'est exactement notre métier : découvrez notre approche du développement SaaS et produit, ou envoyez-nous votre dépôt et nous reviendrons avec une liste priorisée de ce qu'il faut corriger.