Livrer, sécuriser, opérer

8.1 Le merge est le milieu de la chaîne, pas la fin

Fusionner votre changement dans main donne l'impression d'être la ligne d'arrivée. Ça ne l'est pas. Le merge déploie le code, mais beaucoup de choses arrivent après : le build s'exécute, le déploiement publie, le cache doit parfois être vidé, le schéma doit parfois être migré à part. « Fusionné » n'est pas « en ligne et correct ». Confirmez en ligne.

8.2 Déployer le code n'est pas déployer le schéma

Votre code et votre base de données changent sur des voies différentes. Un déploiement livre du code. Il n'exécute pas votre migration de base de données. Si le nouveau code attend une colonne que la migration n'a pas encore ajoutée, ça casse en production pendant que votre local a l'air parfait. L'ordre compte : en général le changement de schéma passe en premier, et reste rétrocompatible, puis le code. Ne supposez jamais que l'un a emporté l'autre.

8.3 Le cache : le déploiement invisible qui n'a jamais lieu

Vous déployez, vous vérifiez, rien n'a changé. La raison la plus fréquente : un cache, une couche qui sert une copie enregistrée pour aller plus vite, distribue encore l'ancienne version. Sur certaines surfaces, il faut purger le cache après chaque déploiement, sinon les utilisateurs voient le produit d'hier. Le déploiement qui « n'a pas pris » est presque toujours un cache qui n'a pas été vidé.

8.4 Le rollback

Livrer sans chemin de retour est un pari, pas un plan. Avant de déployer quoi que ce soit de difficile à défaire, sachez comment vous l'annuleriez : revenir sur le code, ou avancer avec un correctif, et que faire des données déjà modifiées. Le moment de réfléchir au rollback n'est pas pendant l'incident.

8.5 La sécurité comme surface déclarative

L'essentiel de votre sécurité n'est pas du code astucieux, ce sont quelques déclarations que vous avez faites ou oubliées. Les secrets vivent hors du versionnage, posés chez l'hébergeur. La clé puissante de la base est uniquement côté serveur ; le frontend reçoit la clé publique restreinte. La sécurité au niveau des lignes est active sur chaque table. Les limitations de débit plafonnent les abus. Ce ne sont pas des fonctionnalités qu'on construit une fois puis qu'on admire. Ce sont des surfaces qu'on garde planes. Une seule table sans sécurité, ou une seule clé tout-accès dans le navigateur, et tout le reste de votre soin ne compte plus.

8.6 L'authentification pose deux questions, pas une

L'authentification demande qui vous êtes. L'autorisation demande ce que vous avez le droit de faire. Ce sont deux choses différentes, et les confondre est un trou classique : un utilisateur connecté n'est pas automatiquement un utilisateur autorisé. Vérifiez les deux, à chaque action sensible, côté serveur. Et appliquez le moindre privilège partout : chaque clé, chaque rôle, chaque intégration reçoit le plus petit jeu de permissions qui lui permet de faire son travail, et rien de plus. Le rayon d'explosion d'une fuite est exactement le privilège que vous avez accordé.

Deux réflexes qui ne coûtent rien et vous sauvent : ne journalisez jamais un secret (jetons et clés ne doivent jamais atterrir dans vos logs, où ils vivent éternellement et circulent), et servez tout en HTTPS, toujours.

8.7 Vie privée et données personnelles

Si vous touchez à des données personnelles (un nom, un email, tout ce qui identifie un humain), vous héritez de responsabilités, pas seulement de fonctionnalités. Les bases qu'un builder doit tenir : ne collecter que le minimum nécessaire, savoir où ça vit, pouvoir le supprimer sur demande, et ne jamais stocker plus que ce que vous pouvez protéger. Si vos clients sont en Europe, c'est le rez-de-chaussée du droit de la vie privée, et « nous sommes un petit produit » n'est pas une exemption. La vie privée est une contrainte de conception qu'on porte dès le premier jour, pas une case à cocher avant le lancement.

8.8 L'observabilité : comment vous savez que la production va bien

On ne répare pas ce qu'on ne voit pas. Trois couches. Les logs : le registre de ce qui s'est passé, que vous pouvez diffuser en direct pour observer un problème pendant qu'il se produit. Le suivi d'erreurs : un service qui capture chaque plantage avec son contexte, pour que vous appreniez l'existence d'un bug par un tableau de bord plutôt que par un utilisateur furieux. Les alertes : un signal qui vous atteint quand un chiffre clé dérape, avant que les clients ne le remarquent. Au début, on découvre souvent qu'une chose a cassé parce que quelqu'un l'a dit. Refermer cet écart, passer de « un utilisateur m'a prévenu » à « mon tableau de bord m'a prévenu », est l'une des premières montées en gamme qui séparent un jouet d'un produit.

8.9 Le playbook d'incident et de rollback

Des choses casseront en production. La panique est la partie coûteuse. Ayez un plan avant d'en avoir besoin. Quand ça casse : arrêtez d'abord l'hémorragie (revenez à la dernière version connue bonne, ou désactivez la fonctionnalité derrière son interrupteur), puis diagnostiquez calmement, puis corrigez en avançant avec une vraie correction et son contrôle de régression (Loi 4). Décidez à l'avance ce que « revenir en arrière » signifie chez vous : revenir sur le code est facile, mais les données déjà modifiées peuvent exiger leur propre annulation. Un rollback répété est un haussement d'épaules. Un rollback improvisé est une panne.

Deux soupapes de sécurité peu coûteuses facilitent tout ça. Mettez vos chemins risqués, tout ce qui touche à l'argent ou aux webhooks tiers, derrière un interrupteur, pour pouvoir les couper d'un geste sans redéployer. Et séquencez vos mises en ligne pour valider avant de promouvoir : prouvez que la chose fonctionne avant de construire les pages marketing qui y envoient les gens. Valider, puis promouvoir, jamais l'inverse.

8.10 Versionnage et mises en ligne

Donnez des noms et une histoire à vos versions. Le versionnage sémantique est la convention courante : une version du type majeure.mineure.correctif, où les nombres signalent l'ampleur du changement (un correctif répare, une mineure ajoute, une majeure casse). Étiquetez chaque version, et tenez un changelog : la liste datée et lisible de ce qui est sorti. Pendant une bêta, vous pouvez suffixer la version pour marquer la phase. Le but n'est pas le cérémonial, c'est de pouvoir dire exactement ce qu'il y a en production et de revenir volontairement à n'importe quel point antérieur.

8.11 Le coût est une préoccupation de premier plan

Un builder qui ignore le coût livre un produit incapable de survivre à son propre succès. Trois lignes à surveiller. L'infrastructure : ce que votre hébergeur, votre base et vos services facturent à mesure que l'usage grandit. Les coûts tiers à l'usage : paiements, emails, et surtout les appels aux modèles d'IA, facturés au jeton et qui montent plus vite qu'on ne le croit. Et votre propre métrique de prix : si vous facturez une unité liée à l'usage, vous devez savoir ce que chaque unité vous coûte à délivrer, sinon vous vendez à perte sans le voir. Le coût n'est pas un sujet qu'on refile au financier. C'est une donnée de conception, au même titre que la vitesse ou la sécurité.

8.12 Annoncer que c'est en ligne

Livrer n'est pas fini tant que vous n'avez pas raconté l'histoire. Une bonne note de version répond à : ce qui est sorti (la valeur, pas la liste technique), pourquoi (le problème résolu), une démo ou une capture, et la suite. Les formats qui marchent : un changelog daté et orienté valeur, une courte démo du vrai trajet, du build in public en chemin, une note à l'équipe sur ce qui change pour elle. Vous parlez valeur et impact, pas jargon. Le glossaire existe précisément pour traduire le technique en langage clair à ce moment-là.