📍 Article principal : Deno 2 en production 2026
Introduction
Une équipe technique de Lomé maintient depuis quatre ans une API Node.js qui sert leur plateforme e-commerce de produits artisanaux. Le code fonctionne mais la dette technique s’accumule : configuration TypeScript fragile, dépendances de plus en plus nombreuses dont certaines peu maintenues, posture de sécurité difficile à auditer face aux exigences croissantes de leurs clients institutionnels. La décision est prise en début 2026 de migrer vers Deno 2 pour bénéficier des permissions explicites, du TypeScript natif, et de l’outillage intégré. La migration s’est faite en six semaines à raison de un développeur en parallèle de l’équipe normale, sans interruption de service. Ce tutoriel détaille la méthode utilisée, les pièges rencontrés, et les patterns qui permettent une migration progressive sans gel des features. À la fin, vous avez un plan d’action concret applicable à votre propre projet.
Prérequis
- Projet Node.js 18+ ou 20 LTS fonctionnel en production
- Codebase TypeScript de préférence (la migration JS pur est plus complexe)
- Suite de tests existante avec couverture acceptable
- Deno 2.0+ installé pour expérimenter
- Niveau : intermédiaire avancé — Temps : 6 semaines projet, 2 h pour parcourir ce tutoriel
Étape 1 — Audit du projet existant
Avant toute modification, on inventorie ce qui existe. Trois axes à documenter. Premièrement, la liste exhaustive des dépendances directes et leurs usages : npm list --depth=0 donne la liste, et un scan des imports identifie les vraiment utilisés. Souvent, on découvre des dépendances orphelines à supprimer avant migration. Deuxièmement, les variables d’environnement consommées : un grep sur process.env. donne la liste, qu’on documentera ensuite dans les permissions Deno. Troisièmement, les opérations système effectuées : lectures de fichiers, écritures de logs, appels HTTP sortants, sous-processus shell. Cette cartographie servira à construire le manifeste de permissions Deno précis.
L’audit révèle souvent des opportunités de simplification indépendantes de la migration. Une dépendance lourde pour une seule fonction utilisée peut être remplacée par 5 lignes de code natif. Une opération filesystem pour un cache peut être remplacée par Deno KV. Pour une équipe ouest-africaine qui veut profiter de la migration pour faire le ménage, prévoir 20-30 % du temps total de migration sur cette phase d’audit et de simplification — investissement rentabilisé pendant le reste du projet.
Étape 2 — Stratégie de migration progressive
Trois stratégies coexistent selon le contexte. La migration big-bang réécrit tout en une fois et bascule en production le jour J — risquée, déconseillée sauf cas vraiment simple. La migration côte-à-côte fait tourner Node et Deno en parallèle derrière un reverse proxy, qui route progressivement plus de trafic vers Deno à mesure que les modules sont migrés — la plus sûre. La migration in-place modifie le projet existant pour fonctionner sous Deno, en gardant les imports npm initialement, puis en migrant progressivement vers JSR ou des alternatives Deno-native — bon compromis pour les projets de taille moyenne.
Pour un projet ouest-africain typique (API REST de 30-50 endpoints, codebase 10 000-30 000 lignes), la stratégie côte-à-côte est généralement la meilleure. On déploie Deno sur un sous-domaine ou un préfixe d’URL, on migre un endpoint à la fois, on monitore la latence et le taux d’erreur, et on bascule le trafic petit à petit. En cas de régression, le rollback est trivial : on retire la route du reverse proxy. Cette approche découple le rythme de migration du rythme de livraison des features et permet une coexistence sereine sur plusieurs semaines.
Étape 3 — Configuration Deno initiale
Le projet existant a un package.json, un tsconfig.json, peut-être un jest.config, un .eslintrc, et plusieurs autres fichiers de configuration. Pour la version Deno, on vise la simplicité : un seul fichier deno.json qui regroupe tout. La configuration TypeScript hérite des conventions Deno (strict, ESM modules, target moderne) ; les conventions de lint suivent les règles Deno par défaut ; les tests utilisent le runner Deno test natif.
// deno.json
{
"tasks": {
"dev": "deno run -A --watch server.ts",
"start": "deno run --allow-net --allow-read=./config --allow-env=DATABASE_URL,JWT_SECRET server.ts",
"test": "deno test --allow-all"
},
"imports": {
"hono": "jsr:@hono/hono@^4",
"zod": "npm:zod@^3"
},
"compilerOptions": {
"strict": true
}
}La section imports agit comme une import map : le code utilise import { Hono } from 'hono' sans préfixe, et Deno résout vers JSR ou npm selon la déclaration. Cette indirection facilite la migration : on garde initialement les imports npm, puis on migre progressivement les libs vers leurs équivalents JSR sans toucher au code applicatif.
Étape 4 — Adaptations courantes du code
Trois patterns à adapter selon le code Node existant. Variables d’environnement : process.env.X devient Deno.env.get('X'). Un find-replace global suffit pour la majorité des cas, en n’oubliant pas d’ajouter les permissions --allow-env correspondantes. Lectures de fichiers : fs.readFileSync ou fs.promises.readFile deviennent Deno.readTextFile ou Deno.readFile. La sémantique est similaire mais l’API est plus simple et plus moderne. Serveur HTTP : http.createServer ou les frameworks Express deviennent Deno.serve ou Hono. Pour les frameworks comme Express qui ont des middlewares spécifiques, soit on les remplace par des équivalents Hono, soit on garde Express avec compatibilité Node activée.
Pour les tests, le runner Deno test offre une API similaire à Vitest. La migration des tests Jest vers Deno test prend typiquement quelques heures pour une suite de cinquante tests. Les assertions expect(x).toBe(y) deviennent assertEquals(x, y). Pour les équipes attachées à la syntaxe Jest/Vitest, le module jsr:@std/expect fournit une compatibilité d’API qui réduit la friction de migration.
Étape 5 — Migration des dépendances
L’écrasante majorité des packages npm fonctionnent sous Deno via npm: sans modification. Cas typiques sans souci : Hono, Zod, jsonwebtoken, date-fns, lodash, axios. Cas qui nécessitent attention : packages avec dépendances natives (sharp, bcrypt natif), packages très anciens utilisant des APIs Node legacy, packages spécifiquement Windows. Pour ces cas, on recherche un équivalent JSR ou pure-JS, ou on isole l’opération dans un sous-processus dédié.
Pour les packages clés, on évalue si une version JSR existe et apporte des bénéfices (typage strict, performance améliorée). Hono est par exemple disponible sur JSR avec une expérience meilleure qu’en npm. Cette migration packages-clés vers JSR ne fait pas partie de la migration initiale — on la planifie comme une amélioration ultérieure une fois la stack Deno stable. La règle pratique : ne pas tout migrer en une fois pour éviter d’accumuler les sources de bugs simultanées.
Étape 6 — Validation par tests
Avant de basculer du trafic réel, on s’assure que le comportement est strictement équivalent. Trois niveaux de validation. La suite de tests existante doit passer à 100 % sous Deno après migration. Les benchmarks de performance sur les endpoints critiques doivent montrer une parité ou une amélioration. Les tests d’intégration end-to-end doivent valider que les parcours utilisateurs fonctionnent identiquement. Cette triple vérification donne la confiance nécessaire pour basculer du trafic en production progressivement.
Pour les écarts inévitables (par exemple, une milliseconde de différence sur une opération courante), on documente avant de basculer. Si l’écart est en faveur de Deno, c’est un argument pour accélérer la migration. Si l’écart est défavorable, on investigue avant la bascule pour comprendre la cause — souvent une dépendance non-optimale qui peut être remplacée. Pour un projet ouest-africain typique post-migration, on observe généralement des gains de 10-25 % sur la latence p50 et une réduction de 30-40 % de l’empreinte mémoire serveur.
Étape 7 — Bascule en production
La bascule suit le pattern canary : 5 % du trafic vers Deno pendant 24 heures, monitoring rapproché, puis 25 %, puis 50 %, puis 100 %. Cette progression permet de détecter les régressions sur des cas limites non couverts par les tests, sans impacter la majorité des utilisateurs. Un canari simple côté Caddy ou nginx route le trafic selon un hash IP : map $remote_addr $backend { default node-backend; ~^([0-9]+\.[0-9]+\.[0-9]+\.([0-4][0-9]|50))$ deno-backend; } route 5 % du trafic selon le pattern de l’IP cliente.
Pendant la bascule, on monitore activement la latence, le taux d’erreur, la consommation mémoire CPU des deux serveurs. Tout dépassement d’un seuil prédéfini déclenche un rollback automatique. Cette discipline transforme une migration potentiellement stressante en opération routinière à faible risque. Pour les SaaS qui servent des clients sensibles (fintech, santé), c’est la seule approche acceptable.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| « Permission denied » inattendu en prod | Permission oubliée dans systemd | Auditer le service systemd vs dev local |
| Performance dégradée vs Node | Package npm avec dépendance native lente sous Deno | Trouver alternative pure-JS ou JSR |
| Tests Jest qui échouent | Mocks Jest non compatibles Deno | Migrer vers std/testing/mock ou recoder |
| Imports relatifs qui cassent | Extension .js manquante dans les imports | Ajouter .ts ou .js aux imports relatifs |
| Hooks postinstall ne s’exécutent pas | Deno ignore les postinstall scripts | Reproduire l’effet manuellement ou en prebuild |
| Variables d’env undefined | process.env oublié non remplacé | Grep systématique avant deploy |
Adaptation au contexte ouest-africain
Trois aspects pratiques. Premièrement, pour les agences qui maintiennent plusieurs projets clients en parallèle, la migration vers Deno peut se faire projet par projet selon les opportunités de refactoring naturel — par exemple, lors d’une refonte majeure de l’API ou d’un changement d’hébergement. Cette migration opportuniste évite d’imposer un projet de migration séparé à des clients qui n’en voient pas le bénéfice immédiat. Deuxièmement, pour les SaaS qui ont besoin de présenter une posture de sécurité solide à des régulateurs ou des clients institutionnels, la migration vers Deno apporte un argument concret et démontrable. Le manifeste de permissions explicite est un livrable précieux pour les audits de sécurité. Troisièmement, pour les freelances qui veulent moderniser leur offre technique, ajouter « expertise Deno 2 » à leurs compétences ouvre des opportunités sur le marché international où les startups modernes adoptent rapidement ces nouveaux runtimes.
Pour le retour sur investissement, une migration de six semaines pour un projet de taille moyenne se rentabilise typiquement en quatre à six mois via les gains de productivité (outillage simplifié, configuration centralisée), de sécurité (réduction des risques chaîne d’approvisionnement), et d’infrastructure (empreinte mémoire réduite permettant un VPS plus petit). Pour les structures qui hésitent, le conseil pratique est de commencer par un microservice ou un script utilitaire isolé, mesurer les bénéfices réels sur ce périmètre limité, puis décider d’étendre la migration à plus large échelle.
Tutoriels frères
Pour aller plus loin
- 🔝 Pilier : Deno 2 en production 2026
- Articles : Bun monorepo
- Doc : Deno migration guide
FAQ
Combien de temps prend une migration typique ?
Pour un projet de 10 000 à 30 000 lignes, comptez quatre à huit semaines en parallèle des autres tâches, avec un développeur dédié à 30-50 % de son temps.
Faut-il abandonner totalement Node après migration ?
Non. Pour les outils CLI ou les scripts ponctuels qui n’ont pas besoin du runtime serveur, garder Node reste valide. La migration vise principalement les services en production.
Les performances sont-elles toujours meilleures sous Deno ?
Pas systématiquement. Sur les workloads CPU-bound pures, Node peut être plus rapide grâce à des optimisations V8 plus matures. Sur les workloads I/O-bound (la majorité des API), Deno est généralement équivalent ou meilleur.
Comment justifier la migration en interne ?
Trois arguments principaux : sécurité (permissions explicites = posture défense renforcée), productivité (outillage simplifié = onboarding plus rapide), maintenabilité (configuration centralisée = moins de dette technique).
Trois cas d’études complémentaires
Pour situer la migration dans des contextes variés, voici trois exemples concrets observés dans la communauté ouest-africaine en 2025-2026. Premier cas : une plateforme de réservation de transports inter-villes au Burkina Faso. Stack initiale Node 18 + Express + PostgreSQL, 8 000 utilisateurs actifs quotidiens. Migration vers Deno 2 + Hono + PostgreSQL en cinq semaines avec un développeur senior. Résultat : empreinte serveur réduite de 60 %, temps de démarrage divisé par trois, posture sécurité documentable face aux exigences du régulateur des transports. Deuxième cas : un cabinet de conseil en cybersécurité ivoirien qui développe une suite d’outils internes pour ses missions chez les clients. Migration vers Deno principalement motivée par la sécurité par permissions — chaque outil démarre avec un manifeste précis qui rassure les clients sur la portée exacte des actions effectuées sur leurs systèmes. Troisième cas : un studio de développement web sénégalais qui livre des MVPs pour startups. Adoption de Deno pour les nouveaux projets uniquement, en gardant Node sur les projets existants. Cette stratégie pragmatique évite la migration coûteuse tout en bénéficiant des avantages Deno sur les nouveautés.
Checklist de migration en 15 points
Pour structurer une migration réelle, cette checklist couvre les étapes essentielles dans l’ordre. Premier groupe — préparation : auditer les dépendances et identifier les non-Deno-compatibles, documenter les variables d’environnement et opérations système, établir une baseline de performance et de qualité, planifier la stratégie côte-à-côte ou in-place. Deuxième groupe — adaptation : créer le fichier deno.json avec imports map, adapter les imports Node-spécifiques, remplacer process.env par Deno.env.get, configurer les permissions explicites en dev et prod, migrer la suite de tests vers le runner Deno. Troisième groupe — validation et bascule : valider que tous les tests passent, exécuter les benchmarks comparatifs, déployer en staging avec monitoring, basculer 5 % du trafic, escalader progressivement à 100 %, supprimer la stack Node après stabilisation. Suivre cette checklist garantit qu’aucune étape critique n’est oubliée et facilite la coordination en équipe.