J’ai créé un produit avec l’IA — comment l’améliorer sans casser ce qui fonctionne

Pour en savoir plus sur le travail avec les modèles, consultez la documentation Ailoot.

Pourquoi le travail le plus coûteux commence-t-il après le lancement ?#

Vous avez créé une application en une soirée, publié un lien et l’avez envoyé à vos amis. Elle fonctionne. Puis, une semaine plus tard, la première vraie personne arrive, clique au mauvais endroit et la moitié des fonctionnalités cesse de fonctionner. Vous demandez à Claude de réparer le problème : il en corrige un et en casse un autre. Ça vous dit quelque chose ?

C’est là que se pose la question principale : que faire après le lancement d’un produit, une fois passée l’euphorie du premier prototype fonctionnel, alors qu’il faut quand même le maintenir ? On pourrait appeler cela le vibe coding pour adultes. La création apporte de l’enthousiasme et de la vitesse. La maintenance exige de garder la tête froide : comprendre ce que l’on modifie et garder le contrôle. La plupart des gens échouent à cette deuxième étape parce que personne ne les y prépare.

Une étude sectorielle a analysé plus d’un million de modifications de code provenant de 2 444 équipes et calculé où va réellement l’argent consacré au développement par l’IA. Voici le résultat :

Le guide « Le coût caché du vibe coding » explique ces chiffres plus en détail. Il y était question de ce que vous payez. Ici, la question est différente : 44 cents sur chaque dollar servent à corriger des bugs — et cet article explique comment éviter que cette part augmente. Le travail qui consiste à la maîtriser s’appelle la maintenance.

La différence entre quelqu’un qui pratique le vibe coding pour adultes et quelqu’un qui se contente de garder un réseau neuronal à l’œil apparaît après le lancement. La base de code de la première personne grandit, elle apporte des améliorations et rien ne casse. Un mois plus tard, le produit de la deuxième est devenu un bricolage qui fuit, qu’elle n’ose plus toucher. Voici comment rejoindre le premier groupe.

Ce qui casse réellement : 5 catastrophes après le lancement#

Voici des retours d’expérience publics sur de vrais produits créés avec l’IA, avec des chiffres et des dates. Imaginez une carte d’un champ de mines : chaque mine a déjà explosé chez quelqu’un, et on connaît le moyen de l’éviter.

Les cinq cas ont la même cause fondamentale. Par défaut, l’IA fait en sorte que les choses fonctionnent maintenant, mais pas qu’elles restent sûres un mois plus tard sous forte charge. On ne voit pas la différence pendant le développement sur son ordinateur. Elle devient évidente quand arrive le premier inconnu mal intentionné.

Le problème n’est pas de ne pas écrire le code à la main : beaucoup de gens travaillent ainsi. Le problème, c’est de ne pas demander : « La base de données est-elle sécurisée ? » Voici un prompt qui posera cette question à votre place.

Le premier filet de sécurité, c’est Git et la possibilité de revenir à « l’état d’hier »#

Quand Claude casse quelque chose, il vous faut un bouton « Remets-le comme hier ». Techniquement, ce bouton s’appelle Git, et c’est plus simple que ça en a l’air.

Trois termes que les non-programmeurs doivent comprendre :

1. Dépôt — le dossier de votre projet enregistré dans le cloud (généralement sur GitHub). Une copie de tout votre code qui ne se trouve pas uniquement sur votre ordinateur.
2. Commit — un point de retour. En pratique, vous dites au code : « enregistre cet état ». Chaque commit est un repère auquel vous pouvez revenir.
3. Déploiement — un transfert. Le code était en local, sur votre ordinateur, et ne fonctionnait que pour vous. Le déploiement l’envoie vers un serveur externe pour que tout le monde puisse l’utiliser.

Tant que vous disposez de points de commit récents, vous pouvez annuler toute casse avec une seule phrase. Littéralement.

J’ai cassé quelque chose : tout fonctionnait hier, mais aujourd’hui, ce n’est plus le cas. Trouve le dernier commit où tout allait bien, montre-moi ce qui a changé depuis et rétablis le projet dans cet état.

Deux règles à mettre en place immédiatement, avant que d’autres personnes découvrent le produit :

• Le dépôt doit être privé. Pas public. Sinon, n’importe qui peut lire votre code et tout ce qu’il contient.
• Ajoutez le fichier de secrets à la liste des fichiers ignorés. Les clés, mots de passe et identifiants d’accès à la base de données se trouvent dans un fichier séparé (généralement .env), qui ne doit jamais entrer dans le dépôt. Ajoutez une ligne pour .env dans .gitignore afin que les secrets restent avec vous.

Un guide distinct explique comment annuler des modifications en toute sécurité dans Claude Code : Comment annuler des modifications dans Claude Code. Sans points de retour, vous marchez sur une corde raide sans filet, et vous finirez par tomber.

Que restaure /rewind et que ne restaure-t-il pas ?#

Claude Code prend un instantané de l’état du projet avant chaque modification qu’il apporte. La commande /rewind (ou deux pressions sur Échap) restaure les fichiers et la conversation à un point choisi. C’est pratique : si vous avez cassé une fonctionnalité il y a cinq minutes, vous pouvez revenir cinq minutes en arrière.

Mais un piège peut faire perdre des données aux débutants. /rewind ne restaure pas tout :

Anthropic le dit clairement : les instantanés sont un bouton « annuler » local, tandis que Git conserve l’historique permanent. Les instantanés complètent le contrôle de version, mais ne le remplacent pas.

En pratique, pour un non-programmeur, cela signifie que /rewind vous sauvera si « Claude vient de casser une fonctionnalité ». Mais s’il a réussi à supprimer une ligne de la base de données ou à envoyer du code dans le cloud, seuls Git et une sauvegarde de la base de données pourront le restaurer. Gardez donc ces deux niveaux : les instantanés pour les retours arrière rapides, les commits pour l’historique permanent du projet.

Comment apporter des améliorations sans casser ce qui fonctionne déjà ?#

Une personne sur deux se retrouve prise dans cette boucle. Vous demandez à l’IA de corriger un petit bug. Elle propose une modification raisonnable. Cette modification casse autre chose. Vous lui demandez de régler le nouveau problème, et deux autres apparaissent. Et ainsi de suite.

Cette boucle se produit parce que le vibe coding est non déterministe. Le même prompt vous donne deux fois des codes différents. Chaque modification peut donc changer discrètement la logique environnante : le seuil de remise passe de 10 à 12 %, ou une règle de validation change de comportement, sans que vous vérifiiez quoi que ce soit et sans le moindre avertissement. C’est ce qu’on appelle la dérive logique. Elle détériore silencieusement précisément ce qui rapporte de l’argent : les prix, les accès et les paiements.

Une règle permet de se prémunir contre cette dérive, et elle est assez simple pour être affichée au mur : ne validez aucun code que vous ne pourriez pas expliquer mot pour mot à quelqu’un d’autre.

En pratique, cela devient un texte prêt à l’emploi à utiliser avant toute modification d’un code fonctionnel. Il oblige l’IA à avancer par petites étapes et à vous montrer exactement ce qui a changé.

Avant de modifier le code, procède comme suit :

Enregistre l’état fonctionnel actuel comme point de retour distinct (commit).

Décris en toutes lettres ce que tu prévois de modifier et dans quels fichiers.

Fais la modification la plus petite possible : uniquement ce qui résout ma tâche, rien de plus.

Montre-moi ce qui a changé et explique chaque modification afin que je puisse l’expliquer à quelqu’un d’autre.
Ne touche pas à la logique des prix, des accès ou des paiements, sauf si je te l’ai demandé.

Autre principe qui permet d’économiser des semaines : respecter les limites de la tâche. Un problème, une modification, une mise en œuvre rapide. Ne demandez pas à l’IA de réécrire la moitié du projet dans un seul prompt. Des développeurs professionnels commencent parfois à construire un Uber complet alors qu’il leur fallait juste un bouton — et y passent des mois. Vous n’en avez pas besoin.

Tout ce que je décris repose sur un point : la gestion du contexte. Pour empêcher l’IA de casser la logique voisine, elle doit se souvenir des règles de votre projet.

Comment vérifier une modification avant de la publier ?#

Entre « ça fonctionne sur mon ordinateur » et « ça fonctionne pour tout le monde », il y a une étape intermédiaire que les débutants sautent : une copie de test. C’est un instantané distinct de votre environnement de production, où vous vérifiez une modification avant que de vraies personnes ne la voient. Le cycle de travail se déroule ainsi :

1. Créez la modification et vérifiez-la vous-même (développement).
2. Déployez-la en staging, une copie de la production sans utilisateurs réels.
3. Exécutez les scénarios essentiels et vérifiez que rien n’a changé.
4. Ce n’est qu’ensuite que vous la déployez en production.

Pourquoi est-ce important après le lancement ? Chaque mise en production comporte un risque. Une petite modification du code peut empêcher la connexion à un compte. Un seul paramètre manquant peut mettre tout le produit hors service. Le staging repère ces problèmes sans conséquence ; en production, vous perdez des clients.

Pour éviter de tout vérifier manuellement à chaque fois, donnez à l’IA un prompt lui demandant de comparer le comportement de la nouvelle version avec l’ancienne dans les domaines critiques.

Je m’apprête à déployer une modification. Parcours les scénarios essentiels du produit dans l’ordre et vérifie que chacun fonctionne toujours comme avant :

Inscription et connexion d’un nouvel utilisateur.

Paiement et accès accordé après le paiement.

Droits d’accès : un utilisateur ordinaire ne peut voir ni les données d’une autre personne ni la zone d’administration.

Les principaux chiffres de la logique métier (prix, remises, limites) n’ont pas changé.
Si quelque chose se comporte différemment de la version précédente, arrête-toi et montre-moi précisément ce qui a changé.

Où sont vos secrets ? La plus grande faille des débutants#

Je vais expliquer en détail le principal piège, car il met à terre plus de produits que tout autre. Quand l’IA écrit du code, le plus simple est de placer une clé là où elle fonctionnera immédiatement : directement dans le code de la page ouverte dans le navigateur. Vous ne remarquerez pas la différence pendant le développement. Mais n’importe qui peut lire tout ce qui arrive dans le navigateur en ouvrant les outils de développement.

Le fondateur dont les clients ont été débités de $87,500 a déclaré par la suite qu’un seul prompt aurait pu éviter cela. Les débits ont finalement été annulés, mais les frais non remboursables et la perte de tranquillité d’esprit, eux, sont restés. Voici ce prompt.

Vérifie l’ensemble du projet et assure-toi qu’aucune clé secrète ne se retrouve dans le navigateur :

Trouve toutes les clés de la base de données, du système de paiement et des services externes.

Assure-toi que chacune est stockée uniquement sur le serveur, dans des variables d’environnement, et pas dans le code de la page.

Vérifie l’historique du projet : une clé s’y est-elle retrouvée par erreur auparavant ?
Dresse la liste de tous les endroits où tu as trouvé des secrets et indique ce qu’il faut faire pour chacun.

L’autre piège courant consiste à vérifier les droits d’accès uniquement côté navigateur. Si votre produit décide dans le code de la page s’il doit « afficher la zone d’administration », n’importe qui peut contourner cette décision. Les droits d’accès doivent toujours être vérifiés sur le serveur. La base de données ne doit renvoyer les données qu’aux personnes autorisées : c’est le rôle de la sécurité au niveau des lignes (RLS), qui doit être activée sur chaque table.

Avant de vendre des accès ou de laisser entrer d’autres personnes, effectuez un audit de sécurité général du produit.

Passe le projet au crible comme le ferait un attaquant et cherche les failles de sécurité :

Des clés secrètes sont-elles stockées dans du code envoyé au navigateur ou dans l’historique du projet ?

La sécurité au niveau des lignes (RLS) est-elle activée sur chaque table de la base de données, et les droits d’accès sont-ils vérifiés sur le serveur plutôt que seulement dans le navigateur ?

Une sauvegarde automatique de la base de données est-elle configurée, et ai-je déjà vérifié que je pouvais la restaurer ?

La base de données de production est-elle isolée de l’environnement où s’exécute l’agent IA ?
Pour chaque point, indique-moi si tout est en ordre ou ce qu’il faut précisément corriger.

Il existe un guide complet distinct sur la sécurité du vibe coding : Comment sécuriser une application créée par vibe coding. La règle est simple : considère que tout ce que l’IA a fait par défaut n’est pas sécurisé, jusqu’à preuve du contraire.

Où héberger votre produit : les étapes de l’hébergement#

Vous n’avez pas besoin de louer immédiatement votre propre serveur et de le configurer manuellement : au début, c’est une tâche compliquée qui vous fera perdre du temps. Vous pouvez gravir les étapes à mesure que le produit grandit :

1. Hébergement gratuit (par exemple, Vercel) : pour vous-même, les tests et les petits projets. Cela convient si la plateforme est accessible à votre public et si vous ne stockez pas de données personnelles.
2. Une plateforme avec déploiement en une commande (Railway) : lorsque vous avez un backend et une base de données. Le déploiement se fait en une commande, sans avoir à configurer de serveur. La prise en main est très simple.
3. Votre propre serveur dédié : quand la charge est élevée et que vous avez besoin d’un contrôle complet. Passez-y plus tard, lorsque vous aurez atteint les limites de la plateforme.

Pour un non-programmeur qui vient de lancer son produit, la solution la plus simple est une plateforme avec déploiement en une commande, sans configuration manuelle du serveur. Passez à votre propre serveur plus tard. Pour suivre cette démarche avec un exemple concret, consultez le guide sur le déploiement d’un projet créé par vibe coding sur votre propre serveur avec Coolify.

Quand séparer l’application, la base de données et les sauvegardes ?#

Il ne faut pas mettre trois choses dans le même panier : l’application, la base de données et les sauvegardes. Tant qu’il y a peu d’utilisateurs, tout peut rester ensemble, et c’est très bien. Mais un signal clair vous indique quand il est temps de séparer ces éléments.

• Placez l’application et la base de données sur des machines différentes. Le signal : aux heures de pointe, l’utilisation du processeur et de la mémoire reste au-dessus de 70–80 %, les requêtes ralentissent et l’application et la base de données se disputent les mêmes ressources. Une fois séparées, vous pouvez renforcer la base de données sans toucher à l’application, et inversement.
• Appliquez la règle de sauvegarde 3-2-1. Trois copies des données, sur deux types de supports différents, dont une hors site. Cela protège contre les pannes matérielles et les rançongiciels. L’essentiel est que les sauvegardes soient automatiques.

La fréquence des sauvegardes dépend du coût de la perte de plusieurs heures de données. Pour un service d’abonnement où perdre une heure de paiements est inacceptable, l’intervalle doit être inférieur à une heure, ou il faut des journaux de transactions et une restauration à un instant donné (PITR) vérifiés. Choisissez selon la perte de données maximale tolérée et testez séparément la durée de restauration du service. Pour un blog, une sauvegarde par jour suffit. Le principe est simple : déterminez combien de données vous pouvez vous permettre de perdre et configurez les sauvegardes en conséquence.

Aide-moi à décider s’il est temps de passer à une infrastructure plus sérieuse pour mon produit. Vérifie chaque point et pose-moi des questions à son sujet :

Quelle est la charge du processeur et de la mémoire aux heures de pointe ? Leur utilisation reste-t-elle au-dessus de 70–80 % ou non ?

La base de données et l’application se trouvent-elles sur la même machine ou sur des machines différentes ?

Une sauvegarde automatique de la base de données est-elle configurée, et ai-je testé sa restauration ?

Existe-t-il une copie distincte de l’environnement (staging) pour effectuer des vérifications avant le déploiement ?
À partir des résultats, donne-moi une recommandation claire : que laisser en l’état, quoi séparer en premier et pourquoi.

Autre question : base de données gérée ou autogérée ? Pour une petite équipe, une base gérée est presque toujours préférable : votre propre base coûte moins cher côté matériel, mais elle vous prend des heures de maintenance. Si vous travaillez seul et que votre produit n’est pas une infrastructure, ces heures coûtent davantage que la différence de prix du serveur.

Comment automatiser la maintenance ?#

La maintenance manuelle est épuisante. Deux moyens permettent de vous en décharger : la surveillance et un agent de ronde.

La surveillance s’appuie sur deux outils différents pour deux tâches différentes :

1. « Le site est-il en ligne ? » — un outil de surveillance de disponibilité (par exemple, UptimeRobot). Il vérifie le produit toutes les quelques minutes et envoie une alerte s’il tombe en panne. Une offre gratuite est disponible.
2. « Qu’est-ce qui a précisément cassé ? » — un outil de suivi des erreurs (par exemple, Sentry). Il collecte les erreurs dans l’application et indique où et pourquoi un problème s’est produit.

Le premier détecte la panne du produit. Le deuxième montre quelle fonctionnalité a échoué et pourquoi. Ensemble, ils répondent à la question : « Serai-je informé d’une panne avant qu’un client écrive au support ? »

La deuxième étape de l’automatisation est un agent de ronde. Imaginez une agence immobilière : à sept heures du matin, un agent IA lit les demandes reçues sur le site, constate que le formulaire de réservation est cassé, en trouve la cause dans le code et vous apporte une correction prête à être appliquée, avec une explication. Vous l’examinez et dites « oui » : elle est déployée. L’ordre est important : commencez par résoudre le problème de l’utilisateur (accorder l’accès, présenter des excuses), puis examinez la cause et l’argent.

Une dernière règle concernant l’accès de l’IA à la base de données de production : donnez-lui un utilisateur en lecture seule et masquez les données personnelles derrière une couche intermédiaire, afin que l’agent voie « nom » au lieu du véritable nom d’une personne. Ainsi, même en cas d’erreur, il ne pourra physiquement ni supprimer ni corrompre les données de production. L’incident du tableau ci-dessus, où un agent a effacé la base de données de production, illustre précisément l’absence de cette restriction. Le guide Que faire si l’IA a supprimé votre base de données explique comment réagir si la catastrophe a déjà eu lieu.

Quand faut-il arrêter un produit ?#

La partie la plus sous-estimée de la maintenance consiste à savoir quand arrêter de maintenir un produit. Toute personne qui crée beaucoup de choses a un cimetière de projets : elle en a créé un, l’a bricolé, puis l’a abandonné. C’est normal, et ce n’est pas un échec. L’échec, c’est de traîner pendant des mois quelque chose que personne n’utilise, par regret du temps investi.

Voici des seuils qui peuvent aider à prendre une décision :

1. Deux semaines — assez de temps pour voir si une idée fonctionne. Si les premiers vrais utilisateurs reviennent, continuez. Le silence est une réponse.
2. Trois mois — la limite stricte. Si le produit n’a pas décollé au bout de trois mois, arrêtez-le. Avec la vitesse du vibe coding, passer six mois à tester une seule idée, c’est trop long.

Fermer un projet est difficile sur le plan psychologique. Considérez cela comme une décision, pas comme un sentiment. Abandonner un projet dans lequel vous avez investi ressemble au licenciement d’un employé qui ne fait pas le travail : c’est désagréable, mais le garder coûte plus cher que le laisser partir.

La maintenance, c’est le travail qui permet à un produit de rester vivant et utile aux gens. Tout le reste — Git, sauvegardes, surveillance — n’est qu’un outil pour parvenir au moment où le produit commence à travailler pour vous chaque jour.

Créer un produit avec l’IA en une soirée, c’est la moitié du travail. Le garder en vie et sécurisé à mesure qu’il grandit : voilà ce que signifie le vibe coding pour adultes.

Pour la suite, rendez-vous sur Ailoot.