Déployer sur Deno Deploy : edge global pour l’Afrique 2026

📍 Article principal : Deno 2 en production 2026

Introduction

Une plateforme de transfert d’argent inter-pays UEMOA opérant entre le Sénégal, la Côte d’Ivoire et le Burkina Faso devait servir une API à très basse latence — ses utilisateurs scannaient des QR codes en magasin et attendaient la confirmation de transaction en moins de deux secondes. Le serveur Hetzner FRA1 répondait en 110 ms depuis Dakar, 150 ms depuis Abidjan, 180 ms depuis Ouagadougou — au-dessus du seuil acceptable pour l’expérience cible. Migration de l’API critique vers Deno Deploy : grâce aux PoPs de Lagos et Accra, la latence est tombée à 35 ms à Dakar, 28 ms à Abidjan, 65 ms à Ouagadougou. L’expérience utilisateur s’est transformée, le taux de complétion des transactions a grimpé de 78 % à 94 %. Ce tutoriel décrit le déploiement complet sur Deno Deploy, l’intégration GitHub pour CI/CD automatique, l’utilisation du KV store distribué, les cron triggers, le monitoring intégré, et les optimisations spécifiques pour servir l’Afrique de l’Ouest avec la latence la plus basse possible.

Prérequis

• Compte Deno Deploy (gratuit, création via GitHub OAuth)
• Application Deno fonctionnelle avec Hono ou autre framework
• Dépôt GitHub pour CI/CD automatique
• deployctl installé : deno install -gArf jsr:@deno/deployctl
• Niveau : intermédiaire — Temps : 1 h

Étape 1 — Premier déploiement avec deployctl

Le déploiement le plus simple consiste à pousser un fichier unique vers Deno Deploy via la CLI. La commande deployctl vérifie le code, le bundle si nécessaire, et le déploie globalement en moins de 30 secondes. Pour une application Hono minimaliste de quelques routes, le processus tient en une commande.

// main.ts
import { Hono } from 'jsr:@hono/hono';
const app = new Hono();
app.get('/', (c) => c.text('Hello depuis Deno Deploy edge'));
app.get('/api/ping', (c) => c.json({ ok: true, region: Deno.env.get('DENO_REGION') }));
Deno.serve(app.fetch);

deployctl deploy --project=mon-api main.ts

La première exécution de deployctl demande une authentification GitHub OAuth, crée le projet si nécessaire, et déploie. Le binaire affiche l’URL du déploiement (typiquement https://mon-api-abc123.deno.dev). Cette URL est immédiatement accessible globalement, servie par le PoP le plus proche du visiteur. Tester depuis un terminal Africain : curl https://mon-api-abc123.deno.dev/api/ping doit retourner la région du PoP qui a servi la requête, généralement Lagos ou Accra pour les utilisateurs ouest-africains.

Étape 2 — Intégration GitHub pour déploiement automatique

Plutôt que déployer manuellement à chaque modification, on configure l’intégration GitHub native qui déploie automatiquement sur push. Dans le tableau de bord Deno Deploy, on lie le projet à un dépôt GitHub, on choisit la branche de production (généralement main), et on indique le fichier d’entrée. Les pushs sur cette branche déclenchent désormais un déploiement automatique en moins d’une minute.

Pour les workflows plus avancés (tests avant déploiement, déploiement multi-environnement), on configure un workflow GitHub Actions qui appelle deployctl explicitement. Cette approche permet de lancer la suite de tests Deno avant chaque déploiement, et de déployer vers staging ou production selon la branche. Le secret DENO_DEPLOY_TOKEN, généré dans les paramètres du compte Deno Deploy, authentifie le workflow.

Pour la majorité des SaaS ouest-africains qui démarrent, l’intégration GitHub native suffit largement. Elle élimine la complexité Docker et l’orchestration Kubernetes, permettant à des équipes de deux ou trois développeurs de déployer en production avec une fiabilité comparable aux grandes équipes.

Étape 3 — Environnements multiples : production, staging, preview

Deno Deploy supporte trois environnements distincts par projet. Production déploie sur push de la branche principale, accessible sur le domaine personnalisé configuré. Preview déploie chaque pull request sur une URL unique générée automatiquement, idéal pour réviser visuellement les changements avant merge. Staging permet de mettre en place un environnement de pré-production sur une branche dédiée, avec ses propres variables d’environnement et son propre KV store.

Cette séparation par environnement est gratuite sur le plan Free dans les limites des quotas globaux. Pour un projet typique, prévoir que les preview deployments consomment quelques centaines de requêtes par jour pour les revues humaines. Pour les agences qui livrent à des clients, montrer les preview deployments dans les revues de PR fluidifie considérablement la communication avec les clients non-techniques.

Étape 4 — Deno KV : base de données distribuée

Deno KV est une base de données clé-valeur distribuée intégrée à Deno Deploy, gratuite jusqu’à un volume modeste. Elle est répliquée automatiquement sur tous les PoPs avec cohérence éventuellement consistente — adaptée au cache, sessions, configurations dynamiques, compteurs analytiques. Pour des données nécessitant cohérence forte (paiements, transactions financières), on combine KV avec une base PostgreSQL externe via Hyperdrive ou Neon.

const kv = await Deno.openKv();

// Écriture
await kv.set(['users', 'usr_123', 'session'], { token: 'abc...', expire: Date.now() + 3600000 });

// Lecture
const result = await kv.get(['users', 'usr_123', 'session']);
if (result.value) {
  const session = result.value as { token: string; expire: number };
  if (session.expire > Date.now()) return c.json({ ok: true });
}

// Compteur atomique
await kv.atomic()
  .sum(['stats', 'visits', '2026-04-27'], 1n)
  .commit();

Le pattern atomic permet des opérations cohérentes sans verrou explicite — utile pour incrémenter des compteurs ou implémenter de la file d’attente. Pour les SaaS ouest-africains qui ont besoin de stocker des sessions utilisateurs ou des données de contexte chaud, KV remplace efficacement Redis avec l’avantage d’être déjà intégré et globalement répliqué.

Étape 5 — Cron Triggers

Deno Deploy expose des Cron Triggers natifs pour exécuter du code à intervalles réguliers sans nécessiter de serveur dédié. La déclaration se fait directement en code via Deno.cron. Le runtime appelle la fonction aux moments programmés, sans aucune configuration externe ni serveur de tâches à provisionner.

Deno.cron("Envoi digest quotidien", "0 6 * * *", async () => {
  console.log("Envoi des digests à 6h GMT...");
  const utilisateurs = await chargerUtilisateurs();
  for (const u of utilisateurs) await envoyerDigest(u);
});

Deno.cron("Synchronisation tarifs", "*/15 * * * *", async () => {
  await synchroniserTaux();
});

Pour les tâches plus longues qui dépassent le timeout de requête (50 secondes par défaut), on découpe le travail en chunks ou on utilise une queue externe. Deno Deploy supporte aussi les Queue Triggers en version beta pour les tâches asynchrones. Pour une plateforme logistique qui calcule chaque nuit les rapports journaliers, la combinaison Cron + KV + queue couvre 90 % des besoins sans infrastructure additionnelle.

Étape 6 — Optimiser la latence pour l’Afrique de l’Ouest

Le réseau global de Deno Deploy inclut un PoP majeur à Lagos depuis fin 2023 et un autre à Accra depuis 2024. Pour les utilisateurs au Nigeria, Ghana, Bénin, Togo, la latence sub-50 ms est désormais la norme. Pour Sénégal, Côte d’Ivoire, Mali, Burkina Faso, le routing va parfois vers Lagos (50-90 ms) ou vers les PoPs européens (95-130 ms) selon la topologie réseau du fournisseur d’accès local. Pour optimiser la latence, on configure le DNS via Cloudflare avec géolocalisation, ce qui assure que chaque visiteur est dirigé vers le PoP physiquement le plus proche.

Pour les workloads sensibles à la latence (validation de QR code de paiement, recherche autocomplete), on minimise les appels base externes en cachant agressivement dans Deno KV. Une requête qui ne touche pas la base distante reste sub-50 ms partout. Pour les requêtes qui doivent atteindre la base (PostgreSQL Hetzner par exemple), on utilise Neon ou Hyperdrive comme couche de cache distribuée qui réduit la latence DB de 100 ms à 5-10 ms côté Deno Deploy.

Étape 7 — Monitoring et logs

Deno Deploy expose un dashboard intégré avec métriques par déploiement : nombre de requêtes par minute, latence p50/p95/p99 par région, erreurs avec stack traces, consommation CPU. Ces métriques sont gratuites et persistantes. Pour les équipes qui veulent agréger ces données dans leur stack observabilité existante (Grafana, Datadog), Deno Deploy expose une API qui exporte les métriques vers Prometheus ou un endpoint webhook.

Pour les logs applicatifs, console.log et console.error sont automatiquement capturés et accessibles dans le dashboard avec recherche full-text. Pour des besoins plus avancés (centralisation, rétention longue), on configure un transport vers Better Stack, Axiom, ou Loki via fetch dans un middleware. Le surcoût en latence est minime (quelques ms en mode fire-and-forget) et permet une observabilité production de niveau enterprise.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Trois leviers spécifiques. Premièrement, pour les services qui ciblent principalement le marché Nigeria-Ghana-Bénin-Togo, Deno Deploy est aujourd’hui l’option offrant la latence la plus basse — souvent 30-40 ms p50, contre 100+ ms pour un VPS européen. Pour les SaaS B2C où chaque milliseconde compte (gaming, paris sportifs, trading), c’est un avantage compétitif net. Deuxièmement, le coût total inclut le tier gratuit généreux (100 000 requêtes/jour) puis un plan Pro à 20 dollars couvrant 5 millions de requêtes mensuelles — souvent suffisant pour scaler à plusieurs dizaines de milliers d’utilisateurs actifs. Troisièmement, l’absence d’administration serveur libère les équipes ouest-africaines des coûts cachés du sysadmin (mise à jour, sécurité, sauvegardes) qui pèsent disproportionnellement sur les petites structures sans dédié infra.

Pour les architectures hybrides courantes en 2026, le pattern recommandé est Deno Deploy en frontal pour les endpoints temps-réel (latence critique), couplé à un VPS Hetzner pour les jobs lourds et la base de données PostgreSQL. Cette combinaison donne le meilleur des deux mondes : edge global pour l’expérience utilisateur, contrôle total et coût maîtrisé pour les workloads complexes.

Tutoriels frères

• Maîtriser les permissions Deno 2
• Publier sur JSR depuis Deno
• Migrer Node vers Deno 2

Pour aller plus loin

• 🔝 Pilier : Deno 2 en production 2026
• Articles : Hono Cloudflare Workers
• Doc : Deno Deploy · Deno KV

FAQ

Quelle est la limite de bundle pour Deno Deploy ?
Environ 10 Mo. Largement suffisant pour la majorité des apps Hono ou Fresh. Pour les apps avec dépendances très lourdes, on délègue à un microservice externe.

Peut-on utiliser PostgreSQL depuis Deno Deploy ?
Oui via le driver postgres-js. Pour réduire la latence, on configure une instance proche d’un PoP utilisé (par exemple Neon EU pour servir l’Europe et l’Afrique de l’Ouest).

Comment gérer les WebSockets sur Deno Deploy ?
Supporté nativement via Deno.upgradeWebSocket. Idéal pour les chats temps-réel, notifications push, dashboards live.

Migration depuis Cloudflare Workers vers Deno Deploy ?
Le code Hono est portable presque sans modification. Les bindings Workers (KV, R2, D1) sont remplacés par leurs équivalents Deno (KV intégré, fetch vers S3, base externe).

Configurer un domaine personnalisé

Pour la production, on remplace l’URL générée mon-api.deno.dev par un domaine personnalisé comme api.example.sn. La configuration tient en deux étapes. Dans le dashboard Deno Deploy, on ajoute le domaine personnalisé au projet et l’interface affiche les enregistrements DNS à créer (un CNAME pointant vers le projet). Côté DNS (Cloudflare, OVH, ou registrar), on crée l’enregistrement et on attend la propagation. Le certificat HTTPS est obtenu automatiquement par Deno Deploy via Let’s Encrypt, sans intervention manuelle.

Pour les domaines apex (sans sous-domaine), Deno Deploy supporte les enregistrements ALIAS ou ANAME selon le fournisseur DNS. Cloudflare gère cela nativement via les CNAME flatten. Pour les domaines achetés sur des registrars locaux ouest-africains qui ne supportent pas ces enregistrements modernes, on utilise Cloudflare DNS (gratuit) en intermédiaire — le NS du domaine pointe vers Cloudflare, qui gère ensuite les CNAME flatten et autres particularités.

Rollback et gestion des incidents

Pour gérer les incidents de production, Deno Deploy conserve l’historique de tous les déploiements et permet le rollback en un clic. Si une nouvelle version cause une régression critique, on retourne au déploiement précédent en moins de 30 secondes. Cette propriété est cruciale pour les SaaS qui ne tolèrent pas une heure d’indisponibilité — un incident détecté à minuit peut être résolu en quelques minutes par un astreinte qui clique sur « Rollback » dans le dashboard mobile.

Pour les déploiements à fort risque (modification de schéma DB, refactoring majeur), on déploie d’abord sur preview, on teste avec du trafic réel via header personnalisé, puis on bascule production. Cette discipline réduit les incidents de production sans ralentir significativement la livraison. Pour les équipes qui adoptent un mode « deploy souvent », la combinaison preview + rollback rapide donne la confiance nécessaire pour accélérer la cadence.