Exposer les APIs Jupyter & Modèles : Le workflow Data Science Python avec Pagekite

Data science et développement en machine learning se font principalement sur des machines locales ou des stations GPU dédiées. Que vous itériez sur une analyse exploratoire dans un notebook Jupyter, construisiez un prototype avec Streamlit, ou serviez des prédictions via FastAPI, votre environnement local est votre principal atelier.

Un défi récurrent apparaît dès que vous devez partager ce travail. Montrer un modèle interactif à un intervenant distant, tester un webhook entrant d’une passerelle de paiement, ou faire qu’une application mobile atteigne un endpoint tournant sur votre laptop implique généralement de déployer sur un serveur distant — et le déploiement cloud introduit des frictions : surcharge de containerisation, coût, délai de déploiement, et dérives de configuration entre environnements.

C’est là qu’un tunnel localhost est utile. Si ngrok domine dans le développement web général, Pagekite est un projet plus ancien, toujours maintenu, qui vaut la peine de connaître, notamment parce que son client de référence est un simple script Python léger, sans dépendances, plutôt qu’un binaire compilé — une propriété importante dans des environnements réglementés ou sensibles à la sécurité.

La Friction du Développement Local en Data Science Moderne

+-----------------------------------------------------------------------+
|                         Station de Travail Locale                     |
|                                                                       |
|  +-------------------+    +--------------------+    +--------------+  |
|  | JupyterLab / Notebook | | Streamlit / Gradio | | FastAPI / ML |  |
|  |   (Port 8888)     |    |    (Port 8501)     |    | (Port 8000)  |  |
|  +---------+---------+    +---------+----------+    +-------+------+  |
|            |                        |                   |             |
+------------+------------------------+-------------------+-------------+
                                      |
                           ( Bloqué par NAT / Pare-feu )
                                      |
                                      x
                          [ Internet Public / Clients ]

Trois points de blocage apparaissent constamment :

• Démonstration de notebooks interactifs. Un fichier .ipynb partagé par email ou GitHub ne rend que du contenu statique. Offrir une session interactive en direct à un client ou PM implique d’exposer votre serveur Jupyter en cours.
• Test des webhooks et callbacks externes. Bots Slack, déclencheurs GitHub, intégrations Stripe/Twilio ont besoin d’une URL publique pour router les requêtes POST entrantes directement vers votre machine.
• Intégration API distante. Les développeurs frontend construisant contre un endpoint modèle local doivent disposer d’une URL accessible avant que le modèle ne soit déployé.

Provisionner manuellement une instance EC2, créer un tunnel SSH inversé, ou installer un binaire compilé qui déclenche une liste blanche d’applications d’entreprise sont autant de points de friction que le tunnel doit éliminer.

Qu’est-ce que Pagekite ? Architecture d’un Tunnel en Python

Pagekite est un projet de tunneling open-source, initialement écrit par Bjarni Rúnar Einarsson, maintenu par The Beanstalks Project ehf., une société islandaise — le projet existe depuis environ 2010, ce qui en fait un des outils les plus anciens dans l’espace localhost-tunneling, antérieur au lancement public de ngrok. Il crée un tunnel d’un serveur relais public (un « front-end », souvent hébergé sur pagekite.net) vers un service local derrière NAT ou un pare-feu restrictif.

                                ARCHITECTURE PAGEKITE

 +------------------------+              +------------------------+
 |   Machine Locale       |              |  Relais Public Pagekite |
 |                        |              |   (Front-end / Cloud)  |
 | +--------------------+ |              |                        |
 | | App Locale         | |              |                        |
 | | (Jupyter/FastAPI)  | |              |                        |
 | +---------+----------+ |              |                        |
 |           | HTTP Local |              |                        |
 | +---------v----------+ |  Chiffré     |                        |
 | | Client Pagekite    |==============| HTTP/HTTPS Public     |
 | | (pagekite.py)      | |  Tunnel      | Écouteur front-end |
 | +--------------------+ |              +-----------+------------+
 +------------------------+                          |
                                                     |
                                            +--------v--------+
                                            | Client / Web   |
                                            | Navigateur     |
                                            +----------------+

Caractéristiques architecturales clés

• Client de référence en Python simple. pagekite.py est un script Python unique, sans extensions C compilées, Rust ou Go nécessaires pour le rôle back-end/client. Si vous utilisez votre propre relais front-end plutôt que le service pagekite.net, la terminaison TLS sur ce relais nécessite OpenSSL et Python 3 moderne ou le module pyOpenSSL — donc “zéro dépendances” signifie vraiment “zéro dépendances pour le cas client courant.”
• Support Python 3 aujourd’hui. La page d’accueil pagekite.net indique l’installation avec python3 pagekite.py 80 yourname.pagekite.me. Certaines anciennes pages wiki du projet (le “QuickStart” pour la version 0.3.x/0.4.x) mentionnent encore Python 2.x — c’est une documentation obsolète laissée par les premières années du projet, pas une indication que l’outil est réservé à Python 2 ; le support Python 3 a été ajouté dans une version PyPagekite il y a plusieurs années.
• Polyvalence du protocole. Au-delà de HTTP/HTTPS, Pagekite tunnelise TCP brut, SSH, et autres services TCP.
• Auto-hébergement réel et natif. Vous pouvez utiliser le relais hébergé sur pagekite.net, ou faire tourner votre propre front-end (pagekitefront) dans votre infrastructure — le code relais est libre, pas une fonctionnalité payante derrière une clé de licence.
• DNS dynamique intégré. Le client supporte la mise à jour native des fournisseurs DNS dynamiques (dyndns.org, no-ip.com, ou un endpoint HTTP(S) personnalisé), pour que le nom public pointe toujours vers votre IP actuelle.
• Un écosystème plus large que le script Python seul. Au-delà de pagekite.py, le projet maintient aussi libpagekite, une implémentation en C pour haute performance ou embarqué, et upagekite, une version MicroPython pour microcontrôleurs ESP32 — pertinent si votre « service local » est plutôt un capteur qu’un ordinateur portable.

Correction de la licence : c’est l’AGPL, pas la GPLv2/Apache

pagekite.py est publié sous la GNU Affero General Public License (AGPL), copyright Bjarni Rúnar Einarsson et The Beanstalks Project ehf. La documentation est sous CC BY-SA 3.0, et les fichiers de configuration exemples sont dans le domaine public. La double licence Apache-2.0-ou-AGPL que vous pouvez voir référencée concerne libpagekite, la bibliothèque C séparée — pas le client Python que la majorité des développeurs utilisent. En matière de sécurité, cette distinction est importante : la clause réseau de l’AGPL est plus stricte qu’une licence permissive comme Apache, et c’est cette licence qui s’applique au script tournant sur votre machine.

Avantages de la Stack Native Python

Fonctionnalité	Avantage pour ML / Data Teams
Pas de runtime compilé à installer	Le client est un seul fichier .py — à mettre dans un venv, une image Docker, ou à côté de vos scripts d’entraînement, sans binaire à vérifier
Auditabilité du code	Le code source Python non compilé permet à la sécurité informatique de vérifier précisément ce que fait le tunnel avant approbation
Intégration au niveau processus	Lancer et gérer le tunnel depuis un script d’entraînement ou de service avec les bibliothèques standard de processus Python
Compatible environnement virtuel	Le script n’a pas de système de packaging propre — il s’exécute dans n’importe quel venv/conda avec Python 3 déjà installé

Correction importante : il n’y a pas de pip install pagekite

Le brouillon initial de cet article (et d’autres écrits en ligne) suggérait pip install pagekite. À ce jour, il n’existe aucun package pagekite maintenu activement sur PyPI correspondant à cet outil — le nom le plus proche est un package statique appelé pagekit. La documentation officielle du projet recommande plutôt ces méthodes d’installation :

# Télécharger le script directement (méthode officielle)
curl -O https://pagekite.net/pk/pagekite.py
chmod +x pagekite.py

# Ou, sur Debian/Ubuntu, via le dépôt apt du projet

echo "deb http://pagekite.net/pk/deb/ pagekite main" | sudo tee -a /etc/apt/sources.list
sudo apt-get update && sudo apt-get install pagekite

Debian et Ubuntu proposent aussi pagekite dans leurs dépôts officiels (sudo apt install pagekite), mais le projet indique que leur version est souvent plus récente que celle fournie par la distribution.

Comment exposer un Notebook Jupyter avec Pagekite

Exposer un environnement Jupyter interactif à des collaborateurs distants nécessite connectivité et contrôle d’accès — une session Jupyter non authentifiée avec une URL publique donne à quiconque la trouve un contrôle total sur votre machine.

                  FLUX DE TRAVAIL JUPYTER SÉCURISÉ

+----------------------+     +----------------------+     +----------------------+
| 1. Configurer Jupyter |     | 2. Démarrer le serveur|    | 3. Créer un tunnel   |
|    Définir un token fort |--->|    Lier à 127.0.0.1   |--->|    Pagekite sécurisé |
|    ou mot de passe     |     |    Port 8888         |     |    https://...       |
+----------------------+     +----------------------+     +----------------------+

Étape 1 : Obtenir le client Pagekite

curl -O https://pagekite.net/pk/pagekite.py
chmod +x pagekite.py

Étape 2 : Sécuriser Jupyter avant de créer le tunnel

jupyter notebook --generate-config
jupyter notebook password

Ou lancer avec un token explicite et lier uniquement en boucle locale :

jupyter lab --ip=127.0.0.1 --port=8888 --NotebookApp.token='votre_token_sécurisé_12345'

Étape 3 : Lancer le tunnel

python3 pagekite.py 8888 monnotebook.pagekite.me

La première fois, vous devrez créer un compte gratuit ou vous connecter, et un clé d’authentification sera stockée dans ~/.pagekite.rc. En cas de succès, vous verrez une sortie terminal confirmant que le port local est accessible via https://monnotebook.pagekite.me/.

Étape 4 : Sécuriser davantage le tunnel

Les versions précédentes de ce guide utilisaient des flags comme --allow=<ip> ou --opt/basicauth=user:pass, qui ne sont pas des options officielles de Pagekite. La vraie méthode de contrôle d’accès est via des flags + ajoutés à la définition du kite :

# Autoriser un IP spécifique (ou sous-réseau /24)
python3 pagekite.py 8888 monnotebook.pagekite.me +ip/203.0.113.45=ok

# Exiger une authentification HTTP Basic en plus ou à la place du token Jupyter
python3 pagekite.py 8888 monnotebook.pagekite.me +password/admin=ComplexPassword123!

Plusieurs flags +ip/ ou +password/ peuvent être empilés. Depuis la version 0.5, pagekite.py inclut un pare-feu simple qui bloque par défaut certains chemins d’attaque (comme /wp-admin/), qu’on peut désactiver avec --insecure globalement ou +insecure par kite. Ce paramètre se désactive automatiquement si vous utilisez +password/ ou +ip/.

Exposer des Endpoints Modèle avec FastAPI & Streamlit

Cas A : Un tableau de bord Streamlit

streamlit run app.py --server.port 8501 --server.address 127.0.0.1

Pour forcer HTTPS côté public, préfixez le protocole au nom du kite — il n’y a pas de flag --service=https séparé :

python3 pagekite.py 8501 https:votre-analytics.pagekite.me

Cas B : Un endpoint d’inférence FastAPI lancé par code

Au lieu de deux fenêtres terminal, vous pouvez lancer le tunnel en processus enfant de votre serveur ASGI :

import subprocess
import time
import uvicorn
from fastapi import FastAPI

app = FastAPI(title="API d’inférence ML locale")

@app.get("/")
def read_root():
    return {"status": "en ligne", "model": "RandomForestClassifier_v2"}

@app.post("/predict")
def predict(features: dict):
    processed_val = sum(features.values()) if features else 0
    return {"prediction": processed_val * 1.5, "confidence": 0.94}

def start_pagekite_tunnel(port: int, subdomain: str):
    """Lance pagekite.py en arrière-plan, lié au port local."""
    cmd = ["python3", "pagekite.py", str(port), f"https:{subdomain}.pagekite.me"]
    print(f"[*] Démarrage du tunnel Pagekite sur le port {port}...")
    process = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
    time.sleep(2)  # attendre que le tunnel soit établi
    print(f"[+] Tunnel en ligne : https://{subdomain}.pagekite.me")
    return process

if __name__ == "__main__":
    PORT = 8000
    SUBDOMAIN = "mon-api-ml"

    tunnel_process = start_pagekite_tunnel(port=PORT, subdomain=SUBDOMAIN)
    try:
        uvicorn.run(app, host="127.0.0.1", port=PORT)
    finally:
        print("[*] Arrêt du processus Pagekite...")
        tunnel_process.terminate()

Ce n’est pas une SDK dédiée, mais une gestion de processus — Pagekite ne fournit pas de bibliothèque Python officielle séparée du script CLI, donc l’intégration programmatique consiste à lancer et superviser le même script, pas à appeler une API spécifique.

Pagekite vs ngrok : Comparatif Data Science

Critère	Pagekite	ngrok
Langage client	Python pur (client)	Go
Licence client	GNU AGPL (pagekite.py)	SaaS fermé
Installation	Script curl ou paquet apt/rpm — pas de package PyPI officiel	Binaire précompilé
Auto-hébergement	Natif — votre propre front-end, code libre	Non disponible sur plans grand public ou équipe
Domaines personnalisés	CNAME supporté directement ; support racine/domaine apex non clairement documenté	Sous-domaines via CNAME sur plan payant, pas de support racine sur tous plans
Protocoles supportés	HTTP, HTTPS, TCP brut, SSH	HTTP, HTTPS, TCP, tunnels TLS
Modèle tarifaire	Pay-what-you-want (suggestion 3$/mois), gratuit pour usage FOSS, plans à partir de 5.99$/mois, bulk blanc à 199.95$/mois (jusqu’à 500 appareils)	Gratuit limité, Hobbyiste à 10$/mois, plans payants évolutifs

Points de comparaison réellement pertinents

Binaire vs script. ngrok fournit un binaire compilé en Go ; Pagekite est un script Python inspectable. En environnement où la liste blanche bloque les exécutables non signés, c’est une différence pratique réelle.

Auto-hébergement. Si vos données incluent des PII ou des dossiers réglementés, la capacité de faire tourner votre propre relais Pagekite dans votre infrastructure est réelle et documentée — ce n’est pas une option payante, c’est le même code libre.

Forme du tarif, pas seulement le prix. Les plans gratuits et Hobbyist de ngrok sont métrés par bande passante et nombre d’endpoint. Pagekite propose un modèle “pay what you want” avec un minimum suggéré, plus des abonnements fixes, plutôt que des surcharges par GB. Une philosophie tarifaire différente, à connaître avant de supposer que c’est forcément moins cher ou plus cher.

Bonnes pratiques de sécurité pour un reverse proxy basé sur Pagekite

+-------------------------------------------------------------------+
|                  STRATÉGIE DE SÉCURITÉ DU TUNNEL                   |
|                                                                   |
|  [ Internet Public ]                                              |
|         |                                                         |
|         v                                                         |
|  +-------------------------------------------------------------+  |
|  | Couche 1 : Chiffrement transport (préfixer avec https:)     |  |
|  +------------------------------+------------------------------+  |
|                                 |                                 |
|                                 v                                 |
|  +-------------------------------------------------------------+  |
|  | Couche 2 : Contrôle d’accès (+ip/ et +password/)            |  |
|  +------------------------------+------------------------------+  |
|                                 |                                 |
|                                 v                                 |
|  +-------------------------------------------------------------+  |
|  | Couche 3 : Authentification applicative (Token Jupyter / clés API) |  |
|  +------------------------------+------------------------------+  |
|                                 |                                 |
|                                 v                                 |
|  [ Application / Notebook / FastAPI locale ]                     |

1. Forcer HTTPS. Prefixer le nom du kite : python3 pagekite.py 8888 https:votre-notebook.pagekite.me.
2. Restreindre par IP si possible. +ip/203.0.113.45=ok (adresse unique) ou +ip/203.0.113=ok (/24).
3. Ajouter une authentification HTTP Basic au tunnel. +password/admin=MotDePasseComplexe123! — utile comme second facteur.
4. Faire tourner le service local sans privilèges. Ne pas faire tourner Jupyter/FastAPI en root, éviter les dossiers avec .env ou clés SSH — Pagekite transmet ce que le port local sert, la hygiène du processus local reste importante.

Gérer de gros payloads

Si FastAPI retourne des JSON ou images volumineux, activer la compression des réponses avant que les données ne traversent le tunnel :

from fastapi import FastAPI
from fastapi.middleware.gzip import GZipMiddleware

app = FastAPI()

# Notez la majuscule : c’est GZipMiddleware, pas GzipMiddleware
app.add_middleware(GZipMiddleware, minimum_size=500)

Maintenir des tunnels persistants en arrière-plan

nohup python3 pagekite.py --logfile=/var/log/pagekite.log 8888 monnotebook.pagekite.me &

Pour tout ce qui doit survivre aux redémarrages, encapsulez dans une unité systemd plutôt que nohup seul.

Dépannage des problèmes de connexion

Symptôme	Cause probable	Solution
“Connection Refused”	Le service local n’écoute pas sur le port spécifié	Vérifier avec curl http://127.0.0.1:PORT ou netstat avant de blâmer le tunnel
“Sous-domaine indisponible”	Le nom name.pagekite.me est déjà pris	Choisir un autre préfixe, ou vérifier que vos identifiants kite sont dans ~/.pagekite.rc
Réponses lentes	Taille du payload ou problème NAT/MTU	Activer la compression (voir ci-dessus) ou réduire la taille du payload

Intégrer Pagekite dans des pipelines MLOps

                        PIPELINE D’INTÉGRATION MLOps

 +-------------------+     +--------------------+     +---------------------+
 | Actions GitHub /  |     | Déclencher un modèle éphémère |     | Lancer le tunnel Pagekite |
 | Runner local      |----->| containerisé |----->| pour exposer webhook |
 +-------------------+     +--------------------+     +----------+----------+
                                                                 |
                                                                 v
 +-------------------+     +--------------------+     +---------------------+
 | Détruire le tunnel |     | Vérifier le webhook |<----| Service de test externe |
 | /rapporter rE9sultats |<---| livraison de la charge utile |     |                     |
 +-------------------+     +--------------------+     +---------------------+

Dans les tests d’intégration end-to-end qui doivent vérifier qu’un service externe peut atteindre un webhook interne, lancer un kite à nom unique (test-run-$GITHUB_RUN_ID.pagekite.me) dans le runner, déclencher l’appel externe, vérifier la réception, puis détruire le tunnel évite de payer un environnement de staging permanent.

Au-delà du client Python : libpagekite et upagekite

Deux composants moins connus du projet Pagekite méritent d’être connus si votre travail dépasse notebooks et APIs, pour des appareils embarqués ou à ressources limitées :

• libpagekite est une implémentation en C du même protocole, conçue pour haute performance ou embarqué, où lancer un interpréteur Python n’est pas pratique.
• upagekite est une version MicroPython pour microcontrôleurs ESP32, permettant à un capteur ou IoT de faire son propre kite sans OS général.

Si vous utilisez déjà Pagekite pour une API data science et que vous souhaitez plus tard récupérer de la télémétrie depuis une carte ESP32, c’est la même infrastructure sous-jacente, pas un fournisseur différent.

Pagekite en 2026 : Toujours une Bonne Option ?

Honnêtement, en toute transparence : le blog de pagekite.net n’a pas publié de mise à jour publique depuis octobre 2021, et le dépôt GitHub du client Python indique qu’il est “en développement actif” mais “peut parfois être instable.” La cadence est plus lente que ngrok ou des outils plus récents comme zrok ou Pinggy, qui publient régulièrement leurs changelogs.

Cela dit, le service principal est toujours opérationnel, le téléchargement et l’inscription fonctionnent, Python 3 est la voie recommandée, et les pages FAQ/prix sont à jour — cela ressemble moins à un projet abandonné qu’à une infrastructure mature, maintenue par une petite équipe. Pour un environnement d’entreprise où un tunnel scriptable, auto-hébergé, et auditables est la priorité, cette stabilité peut être un compromis acceptable. Pour des équipes recherchant support actif, tableau de bord, ou des releases fréquentes, les outils plus modernes évoqués dans cette série seront plus adaptés.

Simplifier la pile de tunneling Python

Un tunnel localhost résout un vrai goulot d’étranglement : relier développement local et web public sans déployer une infrastructure cloud pour une démo. La proposition de Pagekite — un client scriptable, auto-hébergeable, sous licence AGPL, géré par un opérateur islandais depuis 2010 — est réellement différente du modèle SaaS fermé de ngrok, et cette différence est tangible même après correction des affirmations incorrectes. Le choix dépend plus de votre priorité : auditabilité et auto-hébergement ou vitesse de développement et fonctionnalités.

---

Changelog éditorial (vérifié le 6 sept. 2026)

Corrections apportées au brouillon original :

• Licence : corrigée de “GPLv2/Apache” inventé à la véritable GNU AGPL sous laquelle pagekite.py est publié (la double licence Apache-2.0/AGPL concerne uniquement la bibliothèque C séparée, libpagekite, pas le client Python).
• Installation : supprimé la fausse commande pip install pagekite — il n’existe pas de package PyPI maintenu pour cet outil ; remplacé par les méthodes d’installation officielles (téléchargement direct du script via curl, dépôt apt du projet, ou paquets distro).
• Python 2 vs 3 : précisé que certaines anciennes pages wiki mentionnent encore Python 2.x, mais la page d’accueil et les notes de version PyPagekite confirment le support Python 3.
• Syntaxe CLI pour HTTPS : supprimé le flag inventé --service=https ; remplacé par le préfixe du protocole dans le nom du kite (https:name.pagekite.me).
• Syntaxe CLI pour la sécurité : supprimé les flags inventés --allow=<ip> et --opt/basicauth=user:pass ; remplacés par les flags documentés +ip/ et +password/, et précisé que le pare-feu intégré depuis la version 0.5 se désactive automatiquement si des contrôles d’accès sont configurés.
• Correction de code : GzipMiddleware corrigé en GZipMiddleware.
• Ajout d’informations tarifaires : le brouillon initial n’avait pas de section prix ; ajout des modèles pay-what-you-want, abonnements, et tarifs en volume de Pagekite, et ajustement de la comparaison avec ngrok.
• Attribution : mention de Bjarni Rúnar Einarsson et The Beanstalks Project ehf. (Islande).
• Contexte écosystème : mention de libpagekite © et upagekite (MicroPython/ESP32).
• Évaluation de la maintenance : mention que le blog est silencieux depuis 2021, mais que le service et les téléchargements sont actifs.
• Prise en compte de la documentation : la prise en charge du domaine racine n’est pas clairement documentée, reformulation prudente.
• Suppression de la meta description (standard pour cette série).