Après la brèche Vercel : ce que j'ai changé dans mes recommandations d'hébergement
Un incident n'est pas une raison. Il est l'occasion de revoir une longue chaîne de décisions que j'avais cessé d'interroger — et de publier ce que j'en conclus, avec l'inconfort que cela suppose.
Le 9 avril, une dépendance de build a exfiltré les variables d'environnement de plusieurs projets hébergés sur une plateforme que je recommandais sans réserve. Aucun de mes clients n'était concerné. La chance n'est pas une architecture.
J'ai longtemps défendu l'idée qu'externaliser le déploiement était un gain net : moins de surface à maintenir, plus de temps pour le travail visible. C'est vrai — jusqu'au jour où la surface que vous ne maintenez pas devient la surface par laquelle vous êtes atteint.
Ce qu'on achète vraiment
On croit acheter de la simplicité. On achète surtout une dépendance dont on ne mesure le prix qu'au moment de partir — et ce prix n'est pas uniforme. Il est faible si l'on est resté sur des primitives standards ; élevé si l'on a épousé les abstractions propriétaires.
La question n'est donc pas « cloud ou pas cloud ». Elle est : combien de mes décisions sont réversibles ?
La souveraineté n'est pas l'autarcie. C'est la réversibilité.
la.vision · manifeste §1
Concrètement, j'héberge désormais le rendu et les données sur une infrastructure que je peux décrire en entier, en quelques lignes, et reproduire ailleurs en une commande. Le reverse-proxy tient dans un fichier :
# un domaine, TLS automatique, rien de plus
la.vision {
encode zstd gzip
root * /srv/la-vision/public
file_server
reverse_proxy /api/* localhost:3000
}Je ne sais pas encore si cette position tient à l'échelle d'une équipe. Pour une personne, elle tient. Je publierai la suite quand je l'aurai vécue — pas avant.
— jg. · Genève · 46.20°N · CC BY-NC 4.0