
Cloudflare annonce la disponibilité générale de Python Workers et la prise en charge de frameworks comme Flask, Django et FastAPI. Pour votre application hébergée, la question pratique reste de savoir si son environnement réel fonctionne sur la destination envisagée. Ce guide vous aide à constituer une preuve avant de déplacer le trafic.
1. Faire l'inventaire de ce que l'application utilise
Préparez une fiche avec la version de Python, le framework, les dépendances verrouillées et la commande de démarrage actuelle. Travaillez à partir du déploiement qui sert réellement votre site, car le portable d'un développeur peut utiliser des versions différentes.
Ajoutez les ressources extérieures : base de données, service mail, stockage des fichiers reçus, tâches planifiées et appels à d'autres API. Pour chacune, indiquez le propriétaire, le mode d'authentification et un test sans effet sur les clients.
Cloudflare précise que Python Workers repose sur Pyodide et WebAssembly. Les extensions natives doivent disposer d'une compilation compatible. Une bibliothèque disponible sur votre VPS n'est donc pas une preuve de compatibilité avec ce runtime. Marquez chaque dépendance native comme vérifiée, à remplacer ou encore inconnue, sans déduire son état du seul nom du framework.
2. Construire une petite répétition isolée
Déployez une copie avec des données fictives et des identifiants réservés au test. Utilisez le connecteur adapté à la destination : l'annonce décrit les interfaces WSGI et ASGI de Workers. Votre ancienne commande de serveur n'est pas, à elle seule, une procédure de migration.
Faites ensuite passer quatre contrôles concrets :
- Une page répond et produit le contenu attendu.
- Une requête lit puis écrit une donnée de test dans la base dédiée.
- Un fichier envoyé reste accessible après un nouveau déploiement selon le stockage prévu.
- Une tâche différée termine et laisse une trace consultable.
Notez le résultat, l'heure et la version testée. Vérifiez également un échec volontaire, par exemple une ressource de test absente : l'application doit présenter une réponse compréhensible sans exposer de secret.
3. Décider à partir des écarts observés
Comparez les fonctionnalités, pas seulement le temps de réponse de la page d'accueil. Un import réussi ne valide ni les connexions à la base, ni les fichiers persistants, ni le traitement en arrière-plan. Rejouez le parcours qui représente vraiment votre activité.
Pour chaque écart, choisissez une adaptation précise ou conservez le déploiement actuel. Avant toute bascule, désignez la personne qui rétablit le trafic et expliquez comment traiter les écritures reçues pendant l'essai. Un retour vers une ancienne application ne doit pas faire disparaître des commandes récentes.
Votre livrable est une fiche de compatibilité et un résultat reproductible. L'annonce présente des capacités de plateforme ; seule cette répétition vous permet de décider pour votre application.
Sources : Cloudflare.