Comment décidez-vous ce qu'il faut figer et comment gardez-vous les dépendances à jour ?

Figez précisément dans le fichier de verrouillage, et gardez les plages déclarées dans pyproject relativement permissives. Cela donne des installations reproductibles sans vous fermer la porte des mises à jour. Automatisez les montées de version avec un bot qui ouvre de petites pull requests, laissez la CI décider si elles sont sûres, et traitez les avis de sécurité comme une voie à part qui double la file au lieu d'attendre le prochain lot.

Deux missions différentes, donc deux réponses différentes. Le fichier de verrouillage fige les versions et les empreintes exactes, et c'est ce que la CI et la production installent, donc les builds sont reproductibles et un pipeline vert hier veut dire quelque chose. Les contraintes déclarées dans pyproject restent larges, en général une borne basse plus une borne haute sur la majeure suivante, pour que les montées de version soient possibles sans éditer chaque ligne. Rester à jour est la moitié la plus difficile. Nous faisons tourner un bot qui ouvre une pull request par dépendance selon un rythme hebdomadaire, et comme elles sont petites et que la suite de tests est correcte, la plupart passent au vert sans qu'un humain se creuse la tête. Les changements de version majeure sont lus sérieusement. Les avis de sécurité contournent complètement la cadence, et pip-audit tourne en CI pour qu'une dépendance transitive vulnérable connue fasse échouer le build au lieu de dormir sans être vue. Le mode d'échec que j'ai vécu est l'inverse : un service gelé pendant deux ans, puis un avis Django critique imposant quatre versions majeures en un week-end.