Elixir Phoenix LiveView : web app temps-réel — tutoriel 2026

Introduction

Imaginez une interface de suivi de commandes Mobile Money qui se met à jour en temps réel dès qu’un paiement est confirmé, sans que l’utilisateur n’ait à rafraîchir la page, sans WebSocket custom à maintenir, sans framework JavaScript lourd à maîtriser côté front. C’est exactement ce que Phoenix LiveView rend possible dès aujourd’hui, en 2026, avec une fraction du code qu’exigeraient React ou Vue pour un résultat équivalent.

Phoenix LiveView est une bibliothèque du framework Elixir Phoenix qui permet de construire des interfaces web interactives et temps-réel en écrivant uniquement du code serveur Elixir. La magie tient à un mécanisme simple : LiveView maintient une connexion WebSocket persistante entre le navigateur et le serveur. Lorsque l’état côté serveur change — un nouveau message arrive, un compteur s’incrémente, une transaction est validée — LiveView calcule un diff minimal du DOM et l’envoie au navigateur, qui applique uniquement les changements nécessaires. Zéro rechargement de page, zéro sérialisation JSON manuelle, zéro state management côté client à synchroniser.

La puissance sous-jacente vient de la BEAM, la machine virtuelle Erlang sur laquelle tourne Elixir. La BEAM a été conçue dans les années 1980 pour les télécommunications : elle gère des millions de processus légers (acteurs) en parallèle, avec une tolérance aux pannes et une latence remarquablement stables sous charge. Chaque connexion LiveView est un processus BEAM isolé, léger (~2 KB de mémoire à l’état de repos), supervisé automatiquement. Si un processus plante, il redémarre sans affecter les autres connexions. Cette architecture fait de Phoenix l’un des frameworks les plus adaptés aux applications à haute concurrence, comme les dashboards temps-réel, les salles de chat, les notifications push ou les interfaces de suivi de livraison.

Ce tutoriel vous guide de l’installation à la mise en production en sept étapes concrètes. À la fin, vous disposerez d’une application Phoenix LiveView opérationnelle, avec PubSub multi-utilisateurs, formulaires validés et image Docker prête à déployer sur un VPS Hetzner. Durée estimée : 50 minutes.

Prérequis

Avant de commencer, assurez-vous que votre environnement remplit les conditions suivantes. Elixir 1.16 ou supérieur est requis — vérifiez avec elixir --version. Si vous partez de zéro, le gestionnaire de versions asdf avec le plugin Erlang et le plugin Elixir est la méthode recommandée sur Linux et macOS : il gère proprement les dépendances OTP. Phoenix 1.7+ sera installé via Mix lors de la création du projet. Vous aurez également besoin de PostgreSQL 14 ou supérieur en local (ou d’une instance distante accessible), car Phoenix utilise Ecto et Postgres par défaut pour la persistance. Node.js 18+ est requis uniquement pour compiler les assets via esbuild — Phoenix le gère automatiquement, vous n’aurez pas à toucher directement au toolchain JavaScript. Enfin, Docker et Docker Compose sont nécessaires pour l’étape de déploiement finale. Le niveau attendu est intermédiaire : une connaissance basique d’Elixir (fonctions, modules, pattern matching) facilite la lecture, mais les explications sont suffisamment détaillées pour un développeur venant d’un autre langage fonctionnel ou orienté objet. Durée estimée : 50 minutes en suivant le tutoriel pas à pas.

Étape 1 — LiveView vs React/Vue : comprendre le positionnement

Avant d’écrire la première ligne de code, il est important de comprendre pourquoi vous choisiriez LiveView plutôt que l’approche classique API REST + SPA React ou Vue. Ce n’est pas une question de mode ou de préférence syntaxique : c’est un choix architectural aux conséquences concrètes sur la complexité de votre stack, la maintenabilité du code et les performances sous charge.

Avec une SPA React, vous gérez deux applications distinctes qui doivent rester synchronisées : le frontend React (état local, hooks, routing côté client, gestion des erreurs réseau) et le backend API (endpoints REST ou GraphQL, sérialisation JSON, gestion de l’auth stateless, éventuellement WebSockets séparés pour le temps-réel). Pour une équipe de deux développeurs dans une PME à Dakar ou Abidjan, maintenir ces deux couches en parallèle représente une charge cognitive et une surface de bugs significative. Chaque nouvelle fonctionnalité temps-réel exige de coordonner un changement backend et un changement frontend, souvent avec des décalages de version.

LiveView rompt ce pattern en déplaçant tout l’état et toute la logique côté serveur. Le navigateur devient un terminal d’affichage intelligent : il reçoit des patches DOM et renvoie des événements (clics, saisies). Cette approche convient idéalement aux applications dont la logique métier est complexe et doit rester sur le serveur — typiquement les dashboards analytiques, les interfaces de gestion de commandes, les formulaires multi-étapes avec validation complexe, et les applications collaboratives en temps réel. Elle convient moins bien aux interfaces très riches nécessitant des animations complexes pilotées par le DOM (comme une application de dessin vectoriel) ou aux applications offline-first — dans ces cas, React/Vue restent plus adaptés.

Sur le plan des performances réseau, LiveView envoie uniquement les diffs DOM minimaux via WebSocket, une connexion déjà établie. Une mise à jour typique représente quelques dizaines d’octets de JSON morphpatch, contre une requête HTTP avec ses headers qui pèse facilement 500 à 1000 octets. Sur une connexion 3G limitée à 1 Mbit/s en zone périurbaine, cette différence est perceptible. Enfin, du point de vue SEO, Phoenix LiveView génère du HTML côté serveur dès la première requête HTTP (avant que la connexion WebSocket ne s’établisse), ce qui signifie que les moteurs de recherche voient le contenu sans avoir besoin d’exécuter JavaScript — un avantage net par rapport aux SPA classiques.

Étape 2 — Créer le projet avec mix phx.new

Phoenix propose un générateur de projet intégré à Mix (le gestionnaire de build et de dépendances d’Elixir). La commande mix phx.new crée l’arborescence complète d’une application Phoenix, avec tous les fichiers de configuration, le routeur, les superviseurs OTP et les assets préconfigurés. L’option --live n’est plus nécessaire depuis Phoenix 1.7 (LiveView est activé par défaut), mais elle est encore acceptée pour compatibilité ascendante. Commençons par installer le générateur Phoenix si ce n’est pas déjà fait :

# Installer le générateur Phoenix via Mix (une seule fois)
mix archive.install hex phx_new

# Créer le projet mon_app avec LiveView et Postgres
mix phx.new mon_app --live

# Accéder au répertoire du projet
cd mon_app

# Créer la base de données Postgres locale
mix ecto.create

La commande mix phx.new mon_app --live télécharge les dépendances Elixir via Hex (le gestionnaire de paquets Elixir) et installe les dépendances Node.js pour la compilation des assets. La structure générée suit les conventions Phoenix : lib/mon_app/ pour le contexte métier (logique Elixir pure), lib/mon_app_web/ pour la couche web (routeur, controllers, LiveViews, templates), priv/repo/migrations/ pour les migrations Ecto. La commande mix ecto.create crée la base de données PostgreSQL définie dans config/dev.exs — par défaut mon_app_dev sur localhost avec l’utilisateur postgres. Si Postgres n’est pas encore configuré sur votre machine, ajoutez l’utilisateur postgres avec le mot de passe présent dans config/dev.exs avant de lancer cette commande. Une fois mix ecto.create retourné avec succès, lancez le serveur de développement via mix phx.server et ouvrez http://localhost:4000 — vous devriez voir la page d’accueil Phoenix par défaut avec le numéro de version affiché en bas.

Étape 3 — Premier LiveView : le compteur

Le compteur est le « Hello World » de LiveView : il illustre le cycle de vie complet d’un composant temps-réel en moins de 20 lignes. Avant d’écrire le code, comprenons la structure d’un module LiveView. Tout LiveView est un module Elixir qui use le behaviour Phoenix.LiveView. Il implémente au minimum deux callbacks : mount/3 qui initialise l’état lors de la connexion, et render/1 qui retourne le template HTML. L’état du composant est stocké dans un struct %Socket{} dans la clé assigns — c’est la donnée que LiveView surveille et dont il calcule les diffs. Créez le fichier lib/mon_app_web/live/counter_live.ex :

defmodule MonAppWeb.CounterLive do
  use MonAppWeb, :live_view

  # mount/3 est appelé lors de la connexion WebSocket initiale
  # socket contient les assigns (état), on initialise count à 0
  def mount(_params, _session, socket) do
    {:ok, assign(socket, count: 0)}
  end

  # render/1 retourne le HTML — LiveView surveille les assigns utilisés
  def render(assigns) do
    ~H"""
    

      
Compteur : <%= @count %>
      + 1
      - 1
      Remettre à zéro
    
    """
  end
end

L’attribut phx-click est la clé : il indique à LiveView d’envoyer un événement nommé (ici « increment », « decrement » ou « reset ») au serveur via la connexion WebSocket lorsque l’utilisateur clique sur le bouton. Côté serveur, ces événements sont interceptés par le callback handle_event/3. Le template utilise la syntaxe ~H (HEEx — HTML + Embedded Elixir) qui valide le HTML à la compilation. Ensuite, déclarez la route LiveView dans lib/mon_app_web/router.ex à l’intérieur du scope live_session :

scope "/", MonAppWeb do
  pipe_through :browser
  live "/compteur", CounterLive
end

Visitez http://localhost:4000/compteur — vous verrez le compteur affiché. Les boutons sont présents mais ne font rien encore : il manque les handlers d’événements, que nous ajoutons à l’étape suivante. C’est voulu : cette étape valide que le composant se monte correctement, que le rendu initial fonctionne, et que la route est bien déclarée.

Étape 4 — handle_event et gestion de l’état

Le callback handle_event/3 est le coeur de l’interactivité LiveView. Il reçoit trois arguments : le nom de l’événement (une chaîne correspondant à la valeur de phx-click ou phx-change), les paramètres éventuels (un map avec les valeurs du formulaire ou des data-attributes), et le socket courant. Il doit retourner {:noreply, socket} avec le socket potentiellement mis à jour. LiveView compare les nouveaux assigns avec les anciens, calcule le diff DOM minimal, et envoie uniquement ce qui a changé au navigateur. Ajoutez ces clauses dans CounterLive, après la fonction render/1 :

  # Clause pour l'événement "increment"
  def handle_event("increment", _params, socket) do
    {:noreply, update(socket, :count, &(&1 + 1))}
  end

  # Clause pour l'événement "decrement"
  def handle_event("decrement", _params, socket) do
    {:noreply, update(socket, :count, &(&1 - 1))}
  end

  # Clause pour l'événement "reset"
  def handle_event("reset", _params, socket) do
    {:noreply, assign(socket, count: 0)}
  end

La fonction update/3 est un raccourci Phoenix qui applique une fonction anonyme à la valeur courante d’un assign : &(&1 + 1) signifie « prendre la valeur actuelle et y ajouter 1 ». L’alternative assign/3 remplace directement la valeur. Les deux retournent un nouveau socket avec les assigns mis à jour — et Elixir étant immutable, le socket original n’est pas modifié. Retournez dans le navigateur et cliquez sur les boutons : le compteur se met à jour instantanément, sans rechargement de page. Si vous ouvrez l’onglet Network de votre inspecteur, vous verrez uniquement des messages WebSocket de quelques octets passer — aucune requête HTTP n’est émise. Voilà le cycle LiveView complet : événement utilisateur → handle_event → mise à jour assigns → diff → patch DOM navigateur.

Étape 5 — PubSub broadcast multi-utilisateurs

Un compteur qui n’est visible que par un seul utilisateur est rarement utile dans un contexte professionnel. La vraie puissance de LiveView s’exprime quand plusieurs utilisateurs voient la même interface se mettre à jour en temps réel. Phoenix PubSub est le système de messagerie publish/subscribe intégré au framework, reposant sur la BEAM. Chaque processus LiveView peut s’abonner à un topic (une chaîne arbitraire) et recevoir des messages broadcastés sur ce topic. Lorsqu’un utilisateur clique sur « + 1 », au lieu de simplement mettre à jour son propre état, le serveur publie le nouvel état sur le topic partagé — tous les abonnés (donc tous les navigateurs connectés) reçoivent la mise à jour simultanément.

Voici l’implémentation complète du compteur collaboratif. Remplacez le contenu de CounterLive par :

defmodule MonAppWeb.CounterLive do
  use MonAppWeb, :live_view
  alias Phoenix.PubSub

  @topic "counter:global"

  def mount(_params, _session, socket) do
    # S'abonner au topic si la connexion WebSocket est établie
    if connected?(socket), do: PubSub.subscribe(MonApp.PubSub, @topic)
    {:ok, assign(socket, count: 0)}
  end

  def render(assigns) do
    ~H"""
    

      
Compteur partagé : <%= @count %>
      + 1
      Remettre à zéro
    
    """
  end

  def handle_event("increment", _params, socket) do
    new_count = socket.assigns.count + 1
    # Broadcaster le nouvel état à tous les abonnés du topic
    PubSub.broadcast(MonApp.PubSub, @topic, {:count_updated, new_count})
    {:noreply, assign(socket, count: new_count)}
  end

  def handle_event("reset", _params, socket) do
    PubSub.broadcast(MonApp.PubSub, @topic, {:count_updated, 0})
    {:noreply, assign(socket, count: 0)}
  end

  # Recevoir les messages broadcastés par d'autres processus LiveView
  def handle_info({:count_updated, new_count}, socket) do
    {:noreply, assign(socket, count: new_count)}
  end
end

Le guard connected?(socket) dans mount/3 est important : lors du rendu HTTP initial (avant que le WebSocket ne soit établi), connected? retourne false — on évite ainsi de s’abonner deux fois. Une fois la connexion WebSocket établie, mount est rappelé avec connected? à true, et l’abonnement est effectif. Ouvrez deux onglets pointant vers /compteur et cliquez dans l’un : les deux se mettent à jour en temps réel. Sur un serveur multi-nœuds, Phoenix PubSub fonctionne également en mode distribué via pg (Erlang process groups) ou via des adaptateurs comme Phoenix.PubSub.Redis pour des topologies plus complexes.

Étape 6 — Formulaires avec changesets

Les formulaires sont au cœur de la plupart des applications métier. LiveView s’intègre naturellement avec Ecto Changesets — le système de validation et de transformation de données d’Elixir — pour offrir une expérience de formulaire temps-réel : validation instantanée à chaque frappe, retours d’erreurs sans rechargement de page, protection contre les soumissions multiples. Supposons que vous gérez des produits dans votre boutique. Créez d’abord un schema Ecto minimal dans lib/mon_app/catalogue/produit.ex :

defmodule MonApp.Catalogue.Produit do
  use Ecto.Schema
  import Ecto.Changeset

  schema "produits" do
    field :nom, :string
    field :prix, :decimal
    field :description, :string
    timestamps()
  end

  def changeset(produit, attrs) do
    produit
    |> cast(attrs, [:nom, :prix, :description])
    |> validate_required([:nom, :prix])
    |> validate_length(:nom, min: 3, max: 100)
    |> validate_number(:prix, greater_than: 0)
  end
end

Dans le LiveView du formulaire, créez un changeset vide au montage et réagissez aux événements phx-change (validation temps-réel) et phx-submit (soumission finale). L’attribut phx-change sur le formulaire envoie un événement "validate" à chaque modification d’un champ, permettant d’afficher les erreurs de validation immédiatement. L’attribut phx-submit envoie un événement "save" lors de la soumission. Avec cette approche, la validation côté client disparaît complètement — toute la logique de validation vit dans le changeset Ecto côté serveur, en Elixir pur, testable unitairement. Les erreurs apparaissent dans le formulaire sans rechargement de page et sans dupliquer la logique en JavaScript.

Étape 7 — Déploiement avec mix release et Docker

Phoenix recommande mix release pour la production : cette commande (disponible depuis Elixir 1.9 via Mix) compile l’application Elixir, ses dépendances et le runtime BEAM en une archive autonome qui n’a pas besoin d’Elixir ou d’Erlang installés sur le serveur cible. C’est le mode de déploiement le plus robuste et le plus répandu pour Phoenix en production. Voici un Dockerfile multi-stage optimisé pour une image finale légère :

# Étape 1 : build — utilise l'image officielle Elixir avec Erlang/OTP
FROM elixir:1.16-otp-26-alpine AS build
WORKDIR /app

# Installer les dépendances système nécessaires à la compilation
RUN apk add --no-cache build-base npm git

# Variables d'environnement pour la compilation en mode production
ENV MIX_ENV=prod

# Installer Mix et Hex
RUN mix local.hex --force && mix local.rebar --force

# Copier les fichiers de dépendances et les installer
COPY mix.exs mix.lock ./
RUN mix deps.get --only prod
RUN mix deps.compile

# Copier les assets et les compiler
COPY assets assets
RUN npm install --prefix assets && npm run deploy --prefix assets
RUN mix phx.digest

# Copier le reste du code source et compiler
COPY lib lib
COPY priv priv
COPY config config
RUN mix compile

# Générer la release autonome
RUN mix release

# Étape 2 : image de production — alpine sans outils de build
FROM alpine:3.19 AS app
WORKDIR /app

RUN apk add --no-cache libstdc++ openssl ncurses-libs

# Copier uniquement la release compilée depuis l'étape build
COPY --from=build /app/_build/prod/rel/mon_app ./

EXPOSE 4000
ENV PHX_HOST=votre-domaine.com
ENV PORT=4000

CMD ["bin/mon_app", "start"]

Ce Dockerfile utilise le pattern multi-stage : la première image (basée sur elixir:1.16-otp-26-alpine) contient tous les outils de compilation (Elixir, Node.js, npm, build-base) qui sont nécessaires à la build mais ne doivent pas se retrouver en production. La seconde image (alpine:3.19 nu) ne contient que les bibliothèques système minimales et la release compilée — l’image finale pèse typiquement entre 30 et 50 MB selon les dépendances. Pour déployer, construisez l’image avec docker build -t mon_app:latest ., exportez-la sur votre VPS avec docker save ou via un registry privé, puis lancez avec docker run -d -p 4000:4000 --env-file .env mon_app:latest. Les variables DATABASE_URL et SECRET_KEY_BASE doivent être passées via le fichier .env — ne les encodez jamais dans le Dockerfile.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Phoenix LiveView est particulièrement bien adapté aux contraintes de l’Afrique de l’Ouest, et ce pour plusieurs raisons structurelles qui méritent d’être détaillées.

Concurrence massive sur infrastructure modeste. La BEAM peut gérer des centaines de milliers, voire un million de connexions WebSocket simultanées sur un seul serveur si la logique applicative est légère. Un Hetzner CX22 (2 vCPU, 4 GB RAM, environ 4,35 €/mois en 2026) peut tenir 50 000 à 200 000 connexions LiveView simultanées pour une application de suivi de commandes simple où chaque processus LiveView ne fait que recevoir des broadcasts PubSub. C’est une estimation raisonnable basée sur les benchmarks publiés par la communauté Phoenix et les caractéristiques de la BEAM — chaque processus LiveView connecté consomme en repos environ 10 à 20 KB de mémoire (socket, assigns, processus BEAM). Pour un dashboard de suivi Mobile Money servant 10 000 utilisateurs actifs simultanément, un CX22 est largement suffisant, là où un équivalent Node.js ou Python nécessiterait plusieurs serveurs derrière un load balancer.

Dashboard Mobile Money temps-réel. Le cas d’usage le plus concret pour les PME d’Afrique de l’Ouest est le dashboard de paiement temps-réel : un opérateur voit les transactions Orange Money, Wave ou MTN Mobile Money apparaître et se mettre à jour en temps réel dès que la confirmation arrive du webhook. Avec LiveView et PubSub, l’architecture est simple : le webhook de l’opérateur poste sur un endpoint Phoenix Controller qui publie sur un topic PubSub (transactions:nouvelle), et tous les dashboards connectés reçoivent la mise à jour en quelques millisecondes. Pas de polling toutes les N secondes, pas de WebSocket custom à implémenter, pas d’état à synchroniser entre frontend et backend.

Hot code reload pour le développement. Phoenix et la BEAM permettent le rechargement de code à chaud (hot code reload) : en mode développement, sauvegardez un fichier Elixir et le changement est pris en compte sans redémarrer le serveur ni perdre les connexions WebSocket actives. Pour un développeur solo à Cotonou ou Bamako qui teste son application sur une connexion partagée, ne pas avoir à recharger la page après chaque modification est un gain de productivité réel.

WebSocket compact et bande passante limitée. Sur les réseaux 3G ou les connexions ADSL partagées courantes en zone semi-urbaine, la légèreté du protocole LiveView est un avantage concret. Un diff DOM typique (mise à jour d’un badge de notification, rafraîchissement d’un solde) pèse entre 20 et 100 octets dans le protocole Phoenix LiveView. À titre de comparaison, un polling HTTP toutes les 5 secondes avec sa requête et sa réponse JSON pèse facilement 1 à 3 KB par cycle. Sur une journée de travail avec 500 mises à jour, la différence représente plusieurs Mo de données économisées — non négligeable quand les forfaits data sont facturés à la consommation.

Tutoriels frères

• Rust Axum : API REST haute performance — tutoriel 2026 — construire une API REST zero-cost avec Rust et le framework Axum, déploiement sur VPS abordable.
• Go Fiber : API REST rapide pour microservices — tutoriel 2026 — framework Go inspiré d’Express.js, idéal pour les microservices légers et les APIs mobiles à haute fréquence.

Pour aller plus loin

• Retour au pilier : Frameworks backend 2026 pour PME francophone : Rust Axum, Go Fiber, Elixir Phoenix — vue d’ensemble comparative des trois frameworks, critères de choix selon le contexte.
• Documentation officielle Phoenix : phoenixframework.org/docs — guides officiels couvrant le router, les contextes, Ecto, PubSub et les LiveViews.
• Référence API Phoenix LiveView : hexdocs.pm/phoenix_live_view — documentation exhaustive des callbacks, assigns, components, JavaScript hooks et LiveComponents.
• Prochain tutoriel suggéré : une fois l’application de base opérationnelle, l’étape naturelle suivante est d’explorer les LiveComponents — des composants LiveView réutilisables et isolés — et Channels pour les cas d’usage temps-réel qui dépassent le modèle requête/réponse.

FAQ

Q : Phoenix LiveView remplace-t-il totalement React dans tous les projets ?

Non. LiveView excelle pour les applications dont la logique métier est principalement côté serveur et qui nécessitent du temps-réel sans offline-first. Pour une Progressive Web App avec fonctionnement hors-ligne, une application de dessin/animation complexe entièrement pilotée par le DOM, ou un projet où l’équipe frontend est très expérimentée en React, LiveView n’est pas nécessairement le meilleur choix. La décision doit être guidée par les exigences du projet et les compétences de l’équipe, pas par la technologie en vogue.

Q : Faut-il maîtriser Elixir avant de se lancer avec LiveView ?

Une connaissance basique suffit pour commencer : les fonctions anonymes, le pattern matching, les modules et les pipes (|>). Le livre gratuit Elixir School (elixirschool.com) couvre ces bases en une journée. Phoenix impose un style de code très structuré (contexts, schemas Ecto, callbacks nommés) qui guide naturellement même un développeur novice en Elixir. L’investissement dans l’apprentissage d’Elixir est rentable rapidement : le code Phoenix est remarkablement lisible et les outils de débogage de la BEAM (observer, iex, remote shells) sont parmi les plus puissants du monde backend.

Q : Comment gérer l’authentification dans une application LiveView ?

Phoenix génère automatiquement un système d’authentification complet en exécutant mix phx.gen.auth Accounts User users. Cette commande crée les schémas Ecto, les routes, les controllers et les LiveViews d’authentification (inscription, connexion, reset de mot de passe) conformes aux meilleures pratiques de sécurité. La session utilisateur est disponible dans les LiveViews via le paramètre session de mount/3, et les routes protégées se déclarent avec live_session :authenticated, on_mount: MonAppWeb.UserAuth dans le routeur.

Q : Phoenix peut-il tenir la charge en production sur un petit VPS ?

Oui, à condition que la logique applicative soit asynchrone et non-bloquante. La BEAM gère la concurrence via des processus légers (green threads) : des opérations I/O lentes (appels de base de données, appels HTTP externes) ne bloquent pas les autres processus. Sur un Hetzner CX22, une application Phoenix bien écrite peut servir plusieurs milliers de requêtes par seconde et maintenir des dizaines de milliers de connexions WebSocket simultanées. Le principal goulot d’étranglement est généralement la base de données Postgres, pas Phoenix lui-même — dimensionner le pool Ecto (pool_size dans la config) et optimiser les requêtes sont les premières actions à prendre lors d’un passage à l’échelle.

Q : Peut-on utiliser du JavaScript avec LiveView si nécessaire ?

Oui, via les JavaScript Hooks. LiveView expose des points d’ancrage (phx-hook) qui permettent d’exécuter du JavaScript arbitraire lors du montage, de la mise à jour ou du démontage d’un élément DOM. Cela permet d’intégrer des bibliothèques JavaScript tierces (graphiques, cartes, éditeurs de texte riche) tout en conservant l’état principal côté serveur. La communication se fait via pushEvent (JS → serveur) et handleEvent côté hook (serveur → JS). C’est une soupape de sécurité utile pour les cas où le pur serveur-side rendering ne suffit pas.

Q : Phoenix LiveView fonctionne-t-il avec d’autres bases de données que PostgreSQL ?

Ecto, la couche de persistance d’Elixir utilisée par Phoenix, supporte officiellement PostgreSQL, MySQL/MariaDB et SQLite3 via des adaptateurs séparés. Pour le développement et les projets légers en production, ecto_sqlite3 est une excellente option — une seule base de données fichier, zéro configuration serveur, parfait pour un prototype ou une application avec peu d’utilisateurs simultanés. Pour la production à grande échelle en Afrique de l’Ouest, PostgreSQL sur Hetzner (en offre managée ou auto-hébergé) reste la recommandation standard.