Mettre à jour une application client sans casser la prod

Pour mettre à jour une application sur votre téléphone : sur iPhone, ouvrez l’App Store, touchez votre photo en haut de l’écran, puis Mises à jour d’apps ; sur Android, ouvrez le Play Store, touchez l’icône du profil, puis Gérer les applications et l’appareil. Cet article vise un autre lecteur : vous, qui faites évoluer l’application web d’un client et qui ne voulez pas qu’une petite modification faite le soir mette son activité à terre le lendemain matin. La démarche repose sur une branche, une pull request, une preview validée par le client et un filet pour revenir en arrière en 30 secondes.

24:13

Pourquoi pousser directement en production finit par coûter un client

Le scénario est banal. Une petite mise à jour, rien de compliqué. Vous êtes pressé, vous envoyez directement en ligne. Ça a toujours marché.

Et dans 90 % des cas, il ne se passe rien. C’est justement le problème : l’habitude s’installe, et elle finit par coûter cher. Une variable d’environnement oubliée, une migration qui part de travers, un conflit que vous n’aviez pas vu. Le site tombe, le client vous appelle à 8 h du matin, il ne peut plus accéder à son back-office et ses utilisateurs voient une page blanche.

Une page qui s’affiche mal ou un composant cassé se répare en 5 minutes en expliquant le problème à Claude. Ce qui ne se répare pas, c’est la base de données : les articles du client, ses utilisateurs, ses commandes. Aucun redéploiement ne les ramène. Le vrai danger est là.

Le code est remplaçable. Les données du client ne le sont pas, et c’est exactement ce que le workflow qui suit protège.

Les 3 mots à connaître : branche, main, pull request

Pas besoin d’être développeur. Tout le workflow repose sur trois notions.

• La branche : une photocopie de tout votre code à un instant donné. Vous travaillez sur la copie, vous ajoutez des fonctionnalités, vous cassez des choses si vous voulez. L’original ne bouge pas.
• main : la branche principale du dépôt GitHub, l’original. C’est ce que votre client utilise en ce moment : son site, son CMS, son CRM, ses données. main, c’est la production.
• La pull request (PR) : le sas. Quand la fonctionnalité est prête sur sa branche, vous ouvrez une PR pour dire « voilà ce que j’ai développé, je veux le fusionner dans main ». C’est là que vous vérifiez, que vous validez, et que vous voyez une preview avant que quoi que ce soit touche la production.

Si ces mots sont nouveaux, le tuto GitHub pas à pas part de la création du compte et va jusqu’à la première pull request.

La règle d’or : main, c’est la prod du client

Avant de toucher un projet client, installez un réflexe. Il ne demande aucune compétence technique, seulement de la discipline.

Prenez une application client typique : un site en Next.js déployé sur Vercel, une base de données sur Supabase, le code versionné sur GitHub. GitHub garde le code, Vercel fait tourner le site, Supabase stocke les données. Avec une autre stack, les principes restent les mêmes.

Dès le début du projet, vous travaillez avec deux bases de données séparées :

• une base de développement, dans votre propre projet Supabase, sur laquelle vous développez et testez ;
• la base de production, qui fait tourner le business du client.

Les deux ne se mélangent jamais. Vous développez sur la base de dev, vous validez en preview, et la base du client ne voit le changement qu’au moment du merge. Jamais avant.

Concrètement :

• vous n’ouvrez jamais le tableau de bord Supabase de production pour modifier quelque chose à la main ;
• vous ne lancez jamais une commande directement contre la base du client ;
• vous ne poussez jamais sur main sans passer par une pull request. Même pour une virgule, même pressé, même quand le client dit que c’est urgent.

Une fois le workflow en place, chaque mise à jour prend 5 minutes. Mais si vous le contournez une seule fois par impatience, le filet ne vous protège plus : la protection ne marche que si elle est absolue.

Mettre à jour une application client, étape par étape

Dans la vidéo, le client s’appelle Novaris, un cabinet de conseil fictif. Vous lui avez déjà livré un site avec un mini CMS : il se connecte à /admin par un lien magique reçu par email, il écrit ses actualités en Markdown et voit le rendu à droite. Il demande une nouvelle fonctionnalité : une catégorie sur chaque article.

1. Créer une branche

En ligne de commande :

git checkout -b feat/article-categorie

Ou avec le skill /branche du plugin des 6 Claude Code skills, qui crée la branche à partir d’un main à jour, avec un nom qui suit les conventions (feat/ pour une fonctionnalité, fix/ pour une correction). Si vous avez oublié de la créer avant de développer, lancez /branche après coup : il s’en occupe.

À ce stade, la branche n’existe que sur votre machine. Rien n’est parti sur GitHub, rien sur Vercel.

2. Développer et tester en local, sur la base de dev

Je demande la fonctionnalité à Claude Code en mode plan, avec le skill /interroge : cinq ou six questions, puis il développe. Le serveur tourne en local, sur localhost:3000, et il est branché sur la base de dev, pas sur celle du client.

Premier signe que la séparation fonctionne : en local, la page des actualités affiche quatre articles de test ; en production, le client en a trois, les siens. Deux bases, deux contenus.

Chaque changement de la base de données ajoute un fichier dans supabase/migrations/. Le premier fichier créait l’application de départ ; le nouveau ajoute la catégorie. Ce fichier SQL doit d’abord tourner sur la base de dev :

Lance la migration Supabase sur ma base de dev.

Puis vous testez comme le client le fera : dans l’admin, un nouveau champ Rubrique apparaît, vous classez un article en « Intelligence artificielle », vous enregistrez, et l’article apparaît bien dans cette catégorie sur le site.

3. Pousser la branche et ouvrir la pull request

Demandez à Claude de faire le commit et de pousser la branche. Sur GitHub, un bandeau orange annonce la nouvelle branche : cliquez sur Compare & pull request, puis Create pull request. En bas de la page, GitHub montre chaque fichier modifié : en vert le code ajouté, en rouge le code retiré.

Le skill /livre fait les trois d’un coup : commit, push, pull request. Il récupère aussi ce qui a changé sur main entre-temps, par exemple un bug corrigé pendant que vous développiez, pour que la correction ne se perde pas au merge.

4. La preview : un vrai site et une base jetable

Dès que la PR est ouverte, deux choses se passent toutes seules :

• Vercel construit une URL de preview : un vrai domaine, différent de celui de production, pas un localhost.
• Supabase crée une base de données preview, jetable, avec toutes vos migrations appliquées.

La base de production de Novaris n’a pas bougé. Dans Supabase, le menu des branches montre main en production et une branche feat/article-categorie liée à la preview de Vercel. À chaque pull request, une copie du serveur et une copie de la base : rien ne touche la production.

Vous envoyez l’URL de preview au client. Il teste la fonctionnalité sur un vrai site, sans risque pour le sien.

5. Le feu vert du client, puis le merge

Quand le client valide, ouvrez la pull request sur GitHub, descendez et cliquez sur Merge pull request, ajoutez un message si vous voulez, confirmez.

Le code passe sur main, Vercel met à jour le serveur de production, Supabase applique la migration à la base de production. En quelques secondes, la catégorie est en ligne sur le site du client. Les branches de preview de Vercel et de Supabase disparaissent d’elles-mêmes. Côté GitHub, supprimez la branche fusionnée (Delete branch) pour garder le dépôt propre.

Restez additif : la migration qui détruit les données

Le client a validé la preview, vous allez merger. C’est là que la plupart des gens baissent la garde : si la preview est propre, le merge le sera aussi. Pas forcément.

Au merge, les migrations s’appliquent à la base de production. Si l’une d’elles supprime une colonne, renomme un champ ou change le type d’une donnée existante, elle le fait sur les vraies données du client. La preview était propre parce qu’elle tournait sur une base jetable, avec des données de test. La production contient des mois de données accumulées.

La règle de survie : rester additif.

• Ajouter une colonne categorie à la table des articles : aucun risque, les données existantes restent intactes.
• Supprimer une colonne parce qu’elle ne sert plus : vous venez peut-être de détruire des données que vous ne pouviez même pas voir en preview.

Cette règle s’écrit une fois dans le CLAUDE.md du dépôt, le fichier que Claude lit avant de toucher quoi que ce soit (le guide complet de Claude Code explique où il se range) :

## Base de données
- Migrations additives uniquement : ajouter des colonnes et des tables.
- Jamais de DROP ni de RENAME sans backup validé.
- La base de production ne reçoit jamais de modification à la main : tout passe par une pull request et le merge.
- Jamais de push direct sur main.

Le jour où vous devez vraiment supprimer une colonne, c’est une opération à part, avec un backup validé, jamais dans la même PR que la fonctionnalité. Pour aller plus loin que la consigne, un hook peut bloquer avant toute écriture les fichiers sensibles comme la configuration de production : voir les Claude Code hooks.

Le filet : revert ou rollback en 30 secondes

La PR est fusionnée, la catégorie est en ligne, et quelque chose cloche : un bug absent de la preview, une page qui ne se charge plus. Ça arrive, même avec ce workflow. C’est pour ça qu’il y a un filet, en deux options.

Option 1 : le revert, par une pull request

Sur la PR que vous venez de fusionner, GitHub affiche un bouton Revert. Il crée une nouvelle pull request qui annule les changements. Vous la fusionnez, Vercel redéploie l’ancienne version du code.

Ce filet marche grâce à la règle additive. Le revert annule le code, pas la base de données. La colonne categorie reste en place, mais l’ancien code l’ignore : elle ne gêne personne. Si vous aviez supprimé une colonne, le revert ne vous sauverait pas : les données seraient déjà parties. La règle additive et le filet vont ensemble.

Option 2 : Instant Rollback sur Vercel

Pour arrêter l’hémorragie encore plus vite, Vercel garde l’historique des déploiements. Dans l’onglet Deployments, les trois points (⋮) à côté de l’ancienne production, puis Instant Rollback (dans la vidéo, j’utilise Redeploy ; Instant Rollback remet en ligne l’ancien déploiement tel quel). Le site repart sur la version précédente en quelques secondes, sans terminal.

Deux points vérifiés dans la documentation de Vercel le 27 octobre 2026 :

• En Hobby, le rollback ne revient qu’au déploiement immédiatement précédent ; en Pro, vers n’importe quel déploiement déjà passé en production.
• Après un rollback, Vercel coupe la mise en ligne automatique : vos prochains push sur main ne remplacent plus la version restaurée. Faites la PR de revert juste après, pour que main corresponde à ce qui tourne, puis cliquez sur Undo Rollback dans la tuile du déploiement de production pour rétablir le fonctionnement normal.

Le site est revenu, le client respire. Reste à trouver la cause sans empiler les correctifs : c’est la méthode de debug avec Claude Code en 4 phases.

Personne ne peut promettre qu’une mise à jour ne cassera jamais. Avec ce filet, si ça casse, vous reprenez la main en 30 secondes, au lieu de passer 2 heures à déboguer en production pendant que le client attend.

Le setup : 5 étapes, une fois par projet client

Une fois en place, le workflow tourne tout seul à chaque pull request. Le setup se fait une fois par dépôt client.

1. Activer le branching Supabase sur le projet de production. Dans Project Settings, puis Integrations, section GitHub Integration : autorisez GitHub, choisissez le dépôt, indiquez le dossier qui contient supabase/, et activez le déploiement en production au merge. Chaque PR crée alors une base preview jetable, sans données, avec vos migrations appliquées. Le branching n’existe pas sur le plan Free : il demande un plan payant, et chaque branche coûte 0,01344 $ par heure de fonctionnement (tarifs Supabase relevés le 27 octobre 2026). Pour un projet client, le plan payant se justifie de toute façon par les sauvegardes automatiques quotidiennes, absentes du plan Free.
2. Connecter Vercel et Supabase par l’intégration officielle. Dès qu’une PR est ouverte, Supabase pousse les variables de la base preview dans l’environnement Preview de Vercel : votre site de preview pointe vers la bonne base.
3. Protéger main sur GitHub. Settings, puis Rules, puis Rulesets : une règle qui bloque les push directs sur main et exige une pull request. C’est gratuit sur un dépôt public, payant sur un dépôt privé. C’est une protection qui vous évitera bien des bêtises.
4. Autoriser les adresses de preview pour la connexion. Sans ça, le lien magique ne fonctionne pas sur les previews. Dans la vidéo, l’intégration Vercel s’en charge ; vérifiez-le dans Supabase, Authentication, puis URL Configuration. S’il manque, la documentation de Supabase donne le motif à ajouter aux Redirect URLs : https://*-<votre-equipe>.vercel.app/**.
5. Déposer le CLAUDE.md dans le dépôt, avec les règles de la section précédente : migrations additives, jamais de modification de la base de production à la main, tout passe par une PR.

Le projet tourne sur le compte Vercel du client, à son nom : le guide de Vercel détaille pourquoi et comment, Hobby ou Pro compris.