Hasura DDN + PostgreSQL : backend GraphQL fédéré en 1 jour pour PME — guide 2026

L’écart entre l’idée d’une PME et son MVP fonctionnel se mesure souvent en mois de développement backend. Modèles SQL, migrations, CRUD REST, authentification, autorisations par rôle, validation, pagination, recherche full-text : chaque écran de l’interface utilisateur déclenche derrière la scène une cascade de code répétitif que l’équipe doit écrire, tester, maintenir. Hasura DDN renverse cette équation. Le moteur, posé devant une base PostgreSQL, génère automatiquement une API GraphQL fédérée, performante, sécurisée, qui couvre 80 % des besoins backend d’une application moderne sans écrire une seule ligne de resolver. Pour une PME ouest-africaine qui veut réduire de plusieurs mois son temps de mise sur le marché, c’est un changement de paradigme.

Ce guide pose l’architecture complète d’un backend GraphQL Hasura pour PME francophone : choix entre Hasura DDN (la nouvelle architecture distribuée) et le légendaire Hasura GraphQL Engine v2, déploiement Coolify avec PostgreSQL et Redis, modélisation des relations dans la base, exposition automatique en GraphQL, gestion fine des permissions par rôle (admin, commercial, client), authentification JWT, intégration avec un frontend Next.js ou SvelteKit, et déploiement en production avec monitoring. Quatre tutoriels techniques creusent les sujets sensibles : déploiement DDN sur Coolify, permissions row-level, intégration Mobile Money via Action et Event Trigger, réplication Postgres et haute disponibilité.

Pourquoi GraphQL et Hasura plutôt que REST+Express

Le combo classique pour un backend PME : Express ou Fastify côté Node, NestJS pour les plus structurés, Laravel pour les équipes PHP, Django pour les Pythonistes. Tous ces frameworks demandent d’écrire à la main les contrôleurs CRUD, les middlewares d’authentification, les schémas de validation, la pagination, la gestion des relations entre entités. Pour une application avec vingt entités métier, cela représente facilement 5 000 à 10 000 lignes de code répétitif que l’équipe doit développer puis maintenir pendant des années.

Hasura prend une approche radicalement différente. Le moteur introspecte la base PostgreSQL, comprend les tables, les colonnes, les contraintes, les relations clés étrangères, et expose automatiquement un schéma GraphQL complet : queries pour lire (avec filtres, tri, pagination, agrégation), mutations pour créer, mettre à jour, supprimer (avec validation), subscriptions temps réel via WebSocket. Le développeur n’écrit plus que les exceptions — la logique métier vraiment spécifique qui ne se déduit pas de la base de données. Pour la PME, c’est 80 % du backend généré gratuitement.

L’argument économique est massif. Une équipe de deux développeurs full-stack peut livrer en six semaines un MVP qui aurait demandé six mois en stack traditionnelle. Sur le moyen terme, la maintenance reste plus simple — l’évolution du schéma de base déclenche automatiquement la mise à jour de l’API GraphQL, sans casser les clients qui consomment uniquement les champs dont ils ont besoin (force du modèle GraphQL). Le coût d’opportunité de ne pas utiliser Hasura sur un nouveau projet PME est tel que la question devient inversement : dans quels cas faut-il s’en passer ?

DDN vs v2 : quel Hasura choisir en 2026

Hasura existe en 2026 sous deux versions distinctes. Hasura GraphQL Engine v2 (libellé HGE) est le moteur historique open source, monolithique, écrit en Haskell, qui se connecte à PostgreSQL, MS SQL Server, BigQuery, Citus et autres bases via des connecteurs natifs. Sa simplicité d’opération en fait le choix idéal pour une PME qui démarre : un seul conteneur, configuration en console web, performance excellente sur des charges modérées. La version OSS reste 100 % gratuite et continuera d’être maintenue par la communauté.

Hasura DDN (Data Delivery Network) est la nouvelle architecture introduite en 2024 et stabilisée en 2025-2026. Elle remplace le moteur monolithique par une fédération : un routeur GraphQL central reçoit les requêtes et les délègue à des connecteurs spécialisés (NDC pour Native Data Connector) qui s’occupent chacun d’une source de données. Cette architecture permet de fédérer plusieurs bases (PostgreSQL pour le métier, ClickHouse pour l’analytique, MongoDB pour les logs), d’ajouter des sources personnalisées (n’importe quelle API REST ou GraphQL existante), et de scaler horizontalement.

Pour une PME qui démarre avec une seule base PostgreSQL, HGE v2 reste le choix recommandé en 2026. La courbe d’apprentissage est plus douce, l’opération plus simple, les ressources requises plus faibles. Pour une ETI ou une PME en croissance qui prévoit plusieurs sources de données et plusieurs équipes contributrices, DDN devient pertinent grâce à sa modularité et son écosystème de connecteurs. Ce guide se concentre sur HGE v2 pour la simplicité et précise quand DDN apporte une valeur supplémentaire.

Architecture cible pour une PME

L’architecture qui fonctionne en production combine cinq éléments. Le moteur Hasura central, conteneurisé, exposé en HTTPS via un sous-domaine dédié (par exemple api.masociete.sn). PostgreSQL 16 ou 17 LTS comme base de données primaire, avec sa propre instance dédiée pour ne pas mélanger avec d’autres applications. Redis pour le cache des permissions et des résultats de queries fréquentes (option performance, gain typique de 50 % à 80 % sur les requêtes répétitives). Un service d’authentification — Keycloak self-hosted ou Auth0 cloud — qui émet des JWT signés que Hasura valide pour autoriser les requêtes. Un frontend (Next.js, SvelteKit, Astro) qui consomme l’API GraphQL via Apollo Client, urql ou TanStack Query.

Pour une TPE de 10 à 30 utilisateurs, tout cela tient sur un seul VPS Hetzner CCX13 (4 vCPU, 16 Go RAM) à 30 € par mois. Pour une PME de 50 à 200 utilisateurs, monter à un CCX23 ou répartir Hasura et PostgreSQL sur deux VPS distincts. Au-delà, basculer sur PostgreSQL répliqué et plusieurs instances Hasura derrière un load-balancer : cette montée en charge est l’objet du tutoriel HA dédié.

Côté sécurité, trois couches s’empilent. La première : TLS sur tous les ports exposés, certificat Let’s Encrypt automatique via Caddy. La deuxième : l’authentification JWT avec une clé HS256 ou RS256 partagée entre Hasura et le service d’auth. La troisième : les permissions Hasura par rôle (anonymous, user, admin, commercial, client_premium) qui filtrent ligne par ligne les données accessibles. Cette défense en profondeur empêche qu’un client compromis n’ait accès qu’à ses propres données — pas celles des autres clients.

Modélisation et exposition automatique

Le démarrage typique d’un projet Hasura ressemble à ceci. Le développeur conçoit le modèle de données dans PostgreSQL avec ses tables, colonnes, contraintes, clés primaires et étrangères. Une migration SQL classique (gérée par Atlas, Sqitch, Liquibase ou les migrations Hasura natives) applique le schéma sur la base. Le développeur ouvre la console Hasura, suit l’onglet Data, voit ses tables détectées, clique sur Track All. En moins d’une minute, l’API GraphQL est opérationnelle : queries pour chaque table, filtres complexes, pagination, agrégations, relations imbriquées suivies automatiquement.

Exemple concret pour une PME e-commerce. La table orders liée à customers et à order_items donne immédiatement la possibilité d’écrire une requête GraphQL qui retourne les commandes avec le client associé et la liste des produits, avec filtre sur le statut, tri par date, pagination : tout cela en une seule requête, traduite par Hasura en une seule requête SQL optimisée avec JOIN. Le développeur frontend ne se soucie ni de N+1, ni de la pagination, ni des relations — Hasura les gère.

Les mutations suivent la même logique. Insérer une commande avec ses lignes en une seule mutation atomique : Hasura valide les contraintes, exécute en transaction, retourne l’objet complet créé. La validation côté base (NOT NULL, CHECK, UNIQUE) et côté Hasura (permissions, validation custom) se cumulent. Le frontend reçoit une erreur structurée si quelque chose échoue, sans avoir à parser des messages textuels — la machine comprend la machine.

Permissions row-level par rôle

L’aspect le plus sous-estimé de Hasura est son moteur de permissions. Pour chaque table, on définit pour chaque rôle (anonymous, user, commercial, admin) ce qui est autorisé en SELECT, INSERT, UPDATE, DELETE. La granularité descend jusqu’au niveau de la ligne et de la colonne. Exemple : un client peut SELECT ses propres commandes (filtre customer_id = X-Hasura-User-Id), peut UPDATE l’adresse de livraison de ses commandes uniquement si le statut est pending (filtre composé), ne peut jamais voir le coût d’achat (colonne masquée).

Cette logique declarative remplace des centaines de lignes de code de contrôle d’accès traditionnellement éparpillées dans les contrôleurs REST. Le code centralisé dans Hasura est plus lisible, plus auditable, et — surtout — testable. On change une règle de permissions et on observe immédiatement l’effet sur l’API exposée. Pour une PME soumise à des règles de protection des données (RGPD européen pour les clients UE, lois CEDEAO), cette centralisation des contrôles d’accès simplifie radicalement la conformité et l’audit.

Actions et Event Triggers : la logique métier custom

Tout backend a une part irréductible de logique métier qui ne se déduit pas de la base : appel à un service externe (Mobile Money, SMS, OCR, calcul fiscal), traitement asynchrone (génération de PDF, envoi d’email, ETL), validation métier complexe. Hasura prévoit deux mécanismes pour ces cas. Les Actions exposent dans le schéma GraphQL une mutation ou une query custom dont la logique est implémentée dans un endpoint HTTP externe (un petit service Node.js, Python ou Go que l’équipe maintient).

Les Event Triggers déclenchent un webhook quand un événement survient dans la base — INSERT, UPDATE, DELETE sur une table donnée. Hasura garantit la livraison avec retry exponentiel et persistance dans une queue interne : aucun événement n’est perdu même si le service consommateur est temporairement indisponible. C’est exactement ce qu’il faut pour intégrer Hasura à un broker de messages comme Redpanda ou NATS, ou pour déclencher des jobs asynchrones via Inngest ou Temporal.

Cette combinaison — Hasura pour le CRUD générique, Actions pour la logique custom, Event Triggers pour l’intégration asynchrone — couvre 95 % des besoins backend d’une application moderne. Les 5 % restants concernent typiquement des microservices très spécifiques (calcul intensif, rendu graphique, machine learning) qui s’orchestrent autour de Hasura sans le remplacer.

Tutoriels techniques de cette série

• Déployer Hasura GraphQL Engine v2 sur Coolify avec PostgreSQL 17 — installation production, console sécurisée, console v3 vs v2, premières migrations.
• Permissions row-level Hasura : filtrer les données par utilisateur connecté — JWT custom claims, X-Hasura-User-Id, règles avancées avec _and/_or, audit.
• Intégrer Mobile Money à Hasura via Actions et Event Triggers — webhook Paydunya, mutation Action, Event Trigger sur invoice.paid, retry et idempotence.
• Haute disponibilité Hasura : réplication PostgreSQL et load-balancing — Patroni, PgBouncer, multi-instance Hasura, failover automatique.

Adaptation au contexte ouest-africain

Trois ajustements spécifiques. D’abord, prévoir l’authentification flexible. Beaucoup de clients ouest-africains n’ont pas d’e-mail mais un numéro de téléphone : l’authentification par OTP SMS via Twilio, Vonage ou un opérateur local devient le mécanisme principal, complété par un backup mot de passe pour les comptes sédentaires. Hasura accepte n’importe quel JWT bien formé donc l’intégration avec une SMS-OTP custom service est triviale. Ensuite, optimiser pour les connexions intermittentes. Le frontend doit gérer le mode offline-first via TanStack Query ou Apollo Cache, avec resynchronisation automatique au retour en ligne. Hasura supporte cela via les subscriptions WebSocket robustes qui reprennent automatiquement après une coupure.

Enfin, prévoir la souveraineté des données. Pour les services qui touchent à des données personnelles sensibles (santé, légal, finance), héberger PostgreSQL et Hasura sur un VPS local au Sénégal ou en Côte d’Ivoire (Wagaden, Sonatel Cloud) plutôt qu’en Europe. La performance reste excellente — la base et le moteur sont sur la même machine, donc la latence applicative est interne. Le surcoût de l’hébergement local par rapport à Hetzner est de 30 à 50 %, justifiable quand les exigences réglementaires ou contractuelles l’imposent.

Erreurs fréquentes

FAQ

Hasura est-il vraiment gratuit ?

Hasura GraphQL Engine v2 est sous licence Apache 2.0, totalement gratuit et open source. La version DDN propose une édition Community gratuite et une édition Enterprise commerciale. Pour 95 % des PME, la version OSS suffit largement.

Quelle alternative à Hasura ?

Trois alternatives sérieuses en 2026 : PostgREST qui expose une API REST automatique (plus simple mais moins flexible que GraphQL), Supabase qui offre Hasura-like + auth + storage en plateforme intégrée (mais hébergé), et Postgraphile qui est un concurrent open source direct de Hasura avec une approche légèrement différente. Hasura reste leader pour les PME francophones.

Peut-on utiliser Hasura avec une base existante ?

Oui parfaitement. C’est même un cas d’usage privilégié : brancher Hasura sur la base PostgreSQL d’un système existant (Dolibarr, Odoo, application interne) pour exposer instantanément une API moderne consommable par un nouveau frontend mobile ou web.

Hasura supporte-t-il MySQL ?

HGE v2 supporte officiellement PostgreSQL, MS SQL Server, BigQuery et Citus. MySQL/MariaDB est en preview limitée. Pour une PME qui démarre, PostgreSQL reste le choix standard recommandé en 2026 — meilleur pour les requêtes complexes, JSON natif, recherche full-text supérieure.

Migration depuis un backend REST existant

Pour les PME qui ont déjà une API REST en production avec Express, NestJS ou Laravel, la migration vers Hasura n’est pas un big bang. La pratique recommandée consiste à brancher Hasura sur la même base PostgreSQL en parallèle de l’API existante. Hasura expose immédiatement un GraphQL complet basé sur le schéma de base, le frontend peut commencer à consommer GraphQL pour les nouveaux écrans tout en conservant les appels REST pour l’existant. Au fil des semaines, chaque nouvelle feature passe par GraphQL, et le code REST historique se réduit progressivement aux endpoints contenant de la vraie logique métier (paiement, calculs complexes, intégrations externes).

Cette migration progressive a un avantage majeur : zéro risque de régression sur le trafic existant. Le code REST reste là tant qu’on en a besoin. Au bout de six à douze mois, l’équipe constate que 70 à 80 % des appels passent désormais par GraphQL et le code REST a fondu à quelques endpoints critiques. La PME a alors le choix : garder ces endpoints en REST (parfaitement légitime) ou les migrer en Actions Hasura pour homogénéiser. Les deux approches sont valides — le pragmatisme prime sur la pureté technique.

Subscriptions GraphQL temps réel

Une fonctionnalité souvent sous-exploitée de Hasura est le support natif des subscriptions GraphQL. Sans ligne de code supplémentaire, n’importe quel champ exposé en query devient disponible en subscription temps réel. Le frontend ouvre une WebSocket vers Hasura, formule une subscription au lieu d’une query, et reçoit en push toutes les modifications de données qui répondent au filtre. Cela permet de construire en quelques jours un dashboard live, un chat interne, une vue collaboration multi-utilisateurs — sans serveur WebSocket dédié, sans Redis pub-sub, sans architecture événementielle complexe.

Pour une PME qui veut différencier son produit avec du temps réel (stock à jour, notifications instantanées, vue collaborative sur un document), Hasura subscriptions divisent le coût de développement par dix par rapport à une stack Socket.IO maison. La performance tient jusqu’à plusieurs milliers de connexions concurrentes par instance Hasura — largement suffisant pour les usages PME. Au-delà, monter en cluster avec plusieurs instances Hasura derrière un load-balancer et Redis comme backend de subscription distribué.

Sécurité avancée et audit trail

Hasura propose plusieurs mécanismes de sécurité avancée souvent ignorés des nouveaux utilisateurs. Allow-list opérationnel : en production, n’autoriser que les requêtes GraphQL explicitement enregistrées dans une liste blanche, refusant tout le reste — protection radicale contre les attaques d’introspection malveillante. Rate limiting par utilisateur : limiter à 60 requêtes/minute par X-Hasura-User-Id pour éviter qu’un compte compromis sature le serveur. Query depth limit : rejeter automatiquement les requêtes GraphQL trop imbriquées (par exemple plus de 6 niveaux), préventif contre les DoS par requêtes coûteuses.

Côté audit, Hasura supporte le logging structuré de chaque requête avec le user_id, l’opération demandée, le temps de traitement, l’éventuelle erreur. Acheminer ces logs vers Loki, Elasticsearch ou Datadog construit un audit trail exploitable. Pour les services réglementés (finance, santé), cet audit est non négociable — il prouve qui a accédé à quoi et quand, et facilite la réponse à toute requête d’enquête.

Outillage de développement

L’écosystème Hasura propose plusieurs outils qui transforment la productivité de l’équipe. La CLI hasura permet de gérer les migrations SQL et la configuration GraphQL en versionning Git, exactement comme on versionne du code applicatif. Chaque modification de schéma passe par une migration nommée, datée, qui peut être rejouée sur n’importe quel environnement. Cette discipline rend les déploiements reproductibles et permet le rollback en cas de problème.

L’outil hasura-cli intègre aussi un mode Console Mode qui ouvre la console web localement avec sauvegarde automatique des modifications dans des fichiers de migration. Le développeur clique pour modifier les permissions ou ajouter une relation, le fichier de migration est généré automatiquement, il commite dans Git. Cette boucle gomme la friction entre interface graphique et infrastructure as code, principal écueil des outils low-code traditionnels.

Côté frontend, plusieurs IDE proposent une intégration native avec Hasura. VS Code avec l’extension GraphQL fournit l’autocomplétion sur le schéma fédéré, la navigation entre types, la validation des queries en temps réel. Apollo DevTools dans le navigateur affiche en live toutes les requêtes envoyées, leur durée, leur cache hit ratio. Cette tooling moderne accélère significativement la phase de développement et facilite le debugging.

Pricing total et comparaison TCO

Pour fixer les ordres de grandeur, comparons trois scénarios de backend pour une PME de 50 utilisateurs. Premier scénario, stack traditionnelle Express + PostgreSQL maison : 6 mois de développement initial à deux développeurs (≈ 8 millions XOF de salaires), 200 heures/an de maintenance évolutive (≈ 2 millions XOF/an), VPS 30 €/mois (≈ 240 000 XOF/an). Total trois ans : 14 millions XOF.

Deuxième scénario, Hasura self-hosted PostgreSQL : 2 mois de développement initial (≈ 2,7 millions XOF), 50 heures/an de maintenance (≈ 500 000 XOF/an), VPS 30 €/mois. Total trois ans : 4,9 millions XOF — soit une économie de plus de 9 millions XOF, équivalent au coût de plusieurs nouveaux postes commerciaux pour développer le business. Troisième scénario, Hasura Cloud Confluent : même développement, 200 USD/mois en hosting, support inclus. Total trois ans : 7,2 millions XOF.

L’écart en faveur de Hasura self-hosted reste significatif sur trois ans. Pour une PME en phase d’amorçage, c’est la différence entre embaucher une équipe commerciale dédiée ou rester limité par la capacité technique. La technologie n’est pas neutre — elle conditionne directement la trajectoire de croissance.

Pour aller plus loin

Documentation officielle Hasura : hasura.io/docs, image Docker officielle : hub.docker.com/r/hasura/graphql-engine, communauté Discord : discord.gg/hasura. Pour démarrer concrètement, le tutoriel suivant guide pas à pas le déploiement Hasura sur Coolify avec PostgreSQL 17, depuis l’installation jusqu’au premier query GraphQL fonctionnel sur une vraie table métier.

L’investissement initial dans Hasura paie sur la durée d’autant plus que l’équipe est petite. Une PME avec deux développeurs full-stack peut maintenir et faire évoluer une plateforme qui aurait demandé une équipe backend dédiée de cinq à dix personnes en stack traditionnelle. Cette efficacité libère des ressources pour le développement frontend, l’expérience utilisateur et le marketing — trois leviers de croissance bien plus significatifs que la maîtrise complète du backend pour une PME ouest-africaine en phase d’amorçage et de scaling.