ONAS — Dossier de livraison

Ce document s’adresse au service informatique de l’ONAS. Il répond à quatre questions, dans cet ordre :

1. Comment fonctionne le site (ce n’est pas un CMS PHP/MySQL — la différence change tout).
2. De quoi l’ONAS a besoin pour l’héberger, et ce qu’il doit configurer.
3. Ce que Levell livre exactement, artefact par artefact.
4. Comment mettre en service le site avec son contenu déjà en place.

Cadrage — à lire avant tout

Le site est terminé et ne sera pas modifié. Levell livre l’application ; l’ONAS l’héberge et l’exploite. Levell n’assure pas l’hébergement.

Conséquence : les contraintes techniques ci-dessous ne sont pas négociables — c’est l’environnement d’accueil qui doit s’y conformer, pas l’application qui sera réécrite. Ces contraintes sont peu nombreuses et standard (un serveur Linux, Node.js ou Docker, un disque persistant), mais elles excluent l’hébergement mutualisé PHP de type cPanel classique.

---

1. Ce qu’est le site, en une minute

Le site est une application Node.js (Next.js 16 + Payload CMS 3) : un processus qui tourne en permanence sur le serveur et répond sur un port TCP. Ce n’est pas un ensemble de fichiers .php déposés par FTP dans un www/.

Chez vous, d’habitude	Ici
PHP exécuté par Apache/Nginx à chaque requête	Processus Node.js 24 permanent, écoute sur le port 3000
Base MySQL/MariaDB + phpMyAdmin	SQLite : la base est un seul fichier (payload.db, 760 Ko) — aucun serveur de base de données à installer
wp-content/uploads/	Dossier public/media sur un disque persistant
Back-office WordPress	Back-office Payload, à l’URL /admin
Déploiement par FTP	Déploiement par image Docker (ou git pull + npm run build + redémarrage du service)
Apache sert le HTTPS	Reverse proxy (Nginx/Traefik/Caddy) devant le port 3000, qui porte le certificat TLS

Trois conséquences pratiques :

• Il faut un service qui redémarre automatiquement le processus (Docker restart: unless-stopped, ou une unité systemd).
• Il faut un reverse proxy HTTPS devant : l’application ne gère pas les certificats.
• Il faut un disque persistant : c’est le point le plus important, expliqué juste en dessous.

---

2. Comment sont stockées les images — le point clé

Le site contient deux familles d’images qui ne vivent pas au même endroit et ne se sauvegardent pas de la même façon. Confondre les deux est la principale source d’incident au déploiement.

	🎨 Images permanentes (habillage du site)	🗂️ Médias du back-office (contenu éditorial)
Exemples	photos des bannières, décors, icônes, logos ONAS et partenaires	photos des projets, illustrations des actualités, PDF des appels d’offres et publications
Emplacement	public/images/ — dans le code source	public/media/ — sur un volume/disque persistant, hors du code
Volumétrie actuelle	86 fichiers, 278 Mo (dont photos/ 260 Mo, decor/ 13 Mo, audit/ 4,7 Mo, logos/ 708 Ko, partners/ 112 Ko, icons/ 52 Ko)	279 fichiers, 793 Mo (63 médias : 38 JPEG, 9 PNG, 16 PDF)
URL publique	https://<domaine>/images/…	https://<domaine>/media/…
Qui peut les modifier	Levell uniquement (nouveau build + redéploiement)	L’ONAS lui-même, depuis /admin
Voyage avec…	le code source / l’image Docker (elles sont embarquées dans le build)	la sauvegarde du volume — jamais avec le code
Sauvegarde	assurée par le dépôt Git (rien à faire)	à la charge de l’ONAS : payload.db + dossier media/

Deux règles à retenir

Règle n°1 — payload.db et media/ sont indissociables

Chaque fichier du dossier media/ a une ligne correspondante dans la base payload.db (nom de fichier, dimensions, texte alternatif, et le lien vers le projet ou l’actualité qui l’utilise).

• Restaurer la base sans les fichiers → le site affiche des images cassées.
• Restaurer les fichiers sans la base → le back-office est vide, les fichiers sont orphelins.

Ils se sauvegardent et se restaurent toujours ensemble, au même instant.

Règle n°2 — le dossier media/ doit être sur un stockage persistant

Le dossier media/ ne fait pas partie de l’image Docker. Il est monté depuis l’extérieur (volume Docker ou dossier de l’hôte).

Si le conteneur est recréé sans que ce volume soit monté, les 793 Mo de médias disparaissent : le back-office se retrouve vide et le site affiche des trous. C’est également pour cette raison que les plateformes à système de fichiers éphémère (Vercel, et les offres « serverless » en général) ne conviennent pas en l’état.

Détail utile : un upload = jusqu’à 4 fichiers

À chaque image envoyée depuis le back-office, l’application génère automatiquement trois déclinaisons en plus de l’original :

Déclinaison	Dimensions	Usage
thumbnail	400 × 300	vignettes du back-office et des listes
card	768 × 1024	cartes projets / actualités
tablet	1024 × (proportionnel)	affichage tablette

C’est ce qui explique l’écart entre 63 médias déclarés et 279 fichiers sur le disque (543,8 Mo d’originaux → 793 Mo au total). Ce redimensionnement est effectué par la bibliothèque sharp (module natif) au moment de l’upload — d’où le besoin d’un peu de CPU et de RAM sur le serveur.

Détail important : aucune image n’est servie telle quelle

Les deux familles d’images ci-dessus ne sont jamais envoyées directement au navigateur. Elles transitent par l’optimiseur intégré à Next.js, qui les recompresse à la volée en AVIF ou WebP à la taille exacte demandée, puis met le résultat en cache.

Concrètement, une page ne contient pas <img src="/images/photos/hero.png"> mais :

/_next/image?url=%2Fimages%2Fphotos%2Fhero.png&w=1920&q=100
                                                 ↑        ↑
                                             largeur   qualité

Il y a donc deux URL différentes derrière chaque image, et elles peuvent tomber en panne indépendamment — ce qui est la clé du diagnostic :

URL	Rôle	Si elle échoue
/images/… ou /media/…	le fichier source sur le disque	fichier absent, volume non monté, droits
/_next/image?url=…	l’optimiseur qui le transforme	le fichier est bien là, mais refusé ou non transformable

Piège — une qualité non déclarée rend l’image invisible

Depuis Next.js 15.3, images.qualities (dans next.config.ts) est une liste blanche stricte, dont la valeur par défaut ne contient que 75.

Toute image demandée avec une qualité absente de cette liste reçoit une réponse HTTP 400 et n’est jamais affichée — alors que le fichier source, lui, est parfaitement accessible. À l’écran : un emplacement vide, sans message d’erreur.

Le site utilise les qualités 75, 80, 85, 90, 92 et 100. La configuration livrée les déclare toutes :

next.config.ts

images: {
  qualities: [75, 80, 85, 90, 92, 100],
}

Ne pas réduire cette liste, et ne pas déployer l’application sans son next.config.ts : sans ce fichier, seules les images en qualité 75 s’affichent, toutes les autres disparaissent.

Bonne nouvelle : ce réglage se corrige sans reconstruire le site

next.config.ts est relu à chaque démarrage de l’application. Corriger la liste des qualités ne demande donc ni npm run build, ni redéploiement : il suffit de rétablir le fichier et de redémarrer le service.

(À l’inverse, patcher les fichiers de .next/ — required-server-files.json, images-manifest.json — est sans effet : ce n’est pas là que la valeur est lue.)

---

3. Ce dont l’ONAS a besoin

3.1 Le serveur

Ressource	Minimum	Recommandé	Pourquoi
CPU	2 vCPU	2–4 vCPU	Redimensionnement d’images (sharp) au moment des uploads
RAM	2 Go	4 Go	Le processus consomme ~300 Mo au repos ; la construction de l’application (npm run build) demande davantage
Disque	10 Go	20 Go	Image Docker ~2,25 Go + médias 793 Mo + croissance éditoriale + sauvegardes
OS	Linux 64 bits (Ubuntu/Debian/RHEL…)	Ubuntu 22.04+ / Debian 12+	—
Exécution	Docker + Docker Compose (recommandé) ou Node.js 24 LTS	Docker	Docker évite d’installer Node, de gérer les versions et le service
Stockage	Disque persistant obligatoire pour data/ et media/	—	Voir Règle n°2 ci-dessus

3.2 Le réseau

Flux	Sens	Détail
80/tcp, 443/tcp	entrant	Accès public au site (le proxy redirige vers le port 3000 en interne)
443/tcp vers api.brevo.com	sortant	Envoi des e-mails transactionnels (accusés de réception des formulaires)
443/tcp vers Let’s Encrypt	sortant	Uniquement si le certificat TLS est émis automatiquement
3000/tcp	interne	Ne doit pas être exposé publiquement

3.3 Les services externes

Besoin	Détail	Qui le fournit
Nom de domaine	Le domaine officiel ONAS (ex. www.onas.sn) + accès à la zone DNS pour créer l’enregistrement A vers l’IP du serveur	ONAS
Certificat TLS	Let’s Encrypt (gratuit, automatique) ou certificat de l’ONAS installé sur le reverse proxy	ONAS
Compte d’envoi d’e-mails	Une clé API Brevo (ou Resend) + une adresse d’expédition vérifiée sur ce compte	ONAS
Reverse proxy	Nginx, Traefik ou Caddy devant le port 3000	ONAS

Point d’attention sur les e-mails

L’application envoie ses e-mails par API HTTPS (Brevo ou Resend). Elle n’implémente pas SMTP. Un serveur SMTP interne ONAS ne pourra donc pas être utilisé tel quel.

Deux options :

1. Recommandé — l’ONAS ouvre un compte Brevo (offre gratuite suffisante pour ce volume), vérifie une adresse d’expédition à son nom (ex. no-reply@onas.sn) et fournit la clé API.
2. À défaut, le site peut démarrer avec la clé Brevo de Levell — mais les e-mails partiront alors d’une adresse Levell, ce qui n’est pas souhaitable durablement.

Sans clé API valide, le site fonctionne normalement : les formulaires sont bien enregistrés en base et consultables dans le back-office ; seuls les e-mails de notification ne partent pas.

3.4 Ce que l’ONAS n’a pas besoin de fournir

• ❌ Serveur MySQL/MariaDB/PostgreSQL — la base est un fichier SQLite.
• ❌ PHP, Apache avec mod_php, cPanel/Plesk.
• ❌ Serveur SMTP.
• ❌ Stockage objet / CDN (les médias sont servis par l’application).
• ❌ Licence logicielle — l’ensemble de la pile est open source.

---

4. Ce que l’ONAS doit configurer

Toute la configuration tient dans un fichier .env à la racine du projet, plus deux actions hors application (DNS et compte administrateur).

4.1 Le fichier .env

# ── Sécurité ─────────────────────────────────────────────────────────
# Clé de signature des sessions du back-office.
# À REGÉNÉRER par l'ONAS : openssl rand -hex 32
PAYLOAD_SECRET=<chaîne aléatoire de 32 octets>

# ── Base de données ──────────────────────────────────────────────────
# Chemin du fichier SQLite. Doit pointer vers le disque persistant.
DATABASE_URI=file:/app/data/payload.db

# ── E-mails ──────────────────────────────────────────────────────────
# Rien à renseigner ici : depuis le 12 août 2026, l'envoi se configure
# entièrement dans le back-office (voir l'encadré ci-dessous).

L’envoi d’e-mails se configure dans le back-office, plus dans le .env

/admin → Configuration e-mail. Cette page pilote la méthode d’envoi, l’expéditeur et les 7 adresses de service. Les modifications prennent effet en une quinzaine de secondes, sans redémarrage.

Le .env ne sert plus que de repli historique : le paquet livré à l’ONAS n’y contient aucune variable e-mail. Tant que le back-office n’est pas renseigné, aucun message ne part — mais les demandes sont enregistrées, et l’abandon est tracé dans Journaux emails.

Configuration en vigueur (relevée le 13 août 2026) :

Réglage	Valeur
Méthode d’envoi	Serveur SMTP
Serveur	mail.infomaniak.com, port 587, STARTTLS
Identifiant	no-reply@onas.sn
Expéditeur	Service Commercial ONAS <no-reply@onas.sn>
Destinataires	clients@onas.sn pour six formulaires, onas_branchement@onas.sn pour les branchements

Chez Infomaniak, l’expéditeur doit être identique à l’identifiant

Toute autre adresse d’expédition est rejetée par le relais avec un 550 5.7.1 Sender mismatch. Et ne pas cocher « certificat auto-signé » : le certificat de mail.infomaniak.com est valide.

Les 7 destinataires sont la décision la plus structurante

Ils déterminent quel service ONAS reçoit quelle demande citoyenne. C’est le seul point qui demande une décision métier, pas technique. Les modifier ne demande aucune intervention sur le code — seulement l’édition de la page Configuration e-mail.

4.2 Hors application

Action	Détail
DNS	Créer un enregistrement A : www.onas.sn → adresse IP publique du serveur. Prévoir la redirection de l’apex (onas.sn) vers www, ou un second enregistrement A.
TLS	Installer le certificat sur le reverse proxy (Let’s Encrypt automatique, ou certificat fourni par l’ONAS).
Compte administrateur	Le back-office est livré avec un seul compte (technique, Levell). L’ONAS crée ses propres comptes depuis /admin → Utilisateurs, puis supprime le compte Levell après la recette.
Sauvegardes	Planifier la copie quotidienne de payload.db et du dossier media/ (voir §8).

---

5. Ce que Levell livre

#	Artefact	Format	Taille	Contenu
1	Code source complet	Dépôt Git privé (accès accordé à l’ONAS) ou archive .tar.gz	~400 Mo	Application, et les 278 Mo d’images d’habillage (public/images/)
2	Fichiers de déploiement	Dockerfile, docker-compose.yml, entrypoint.sh, next.config.ts	—	Inclus dans le code — la construction est reproductible en une commande. next.config.ts doit rester présent à la racine de l’application en production : il est relu à chaque démarrage et conditionne l’affichage des images (§2) et les redirections d’URL
3	Modèle de configuration	.env.example commenté	—	Toutes les variables du §4, documentées
4	Base de données peuplée	payload.db	760 Ko	Tout le contenu éditorial actuel (voir §6)
5	Médias du back-office	onas-media.tar.gz	~790 Mo	Les 279 fichiers de public/media/ (photos + PDF, originaux et déclinaisons)
6	Runbook de mise en service	Ce document, §7	—	Commandes exactes, dans l’ordre
7	Guide du back-office	Document / session de prise en main	—	Comment l’ONAS publie une actualité, un projet, un appel d’offres

Les artefacts 4 et 5 sont ceux qui évitent un site vide

Le code seul produit un site fonctionnel mais sans contenu. Ce sont payload.db et onas-media.tar.gz qui portent les 11 projets, 10 actualités, 9 documents et 63 médias déjà saisis. Ils doivent être restaurés avant le tout premier démarrage (voir l’avertissement du §7.1).

Ce que Levell ne livre pas

• L’hébergement, la supervision et l’exploitation du serveur.
• Le nom de domaine, le certificat TLS, le compte d’envoi d’e-mails — ce sont des actifs de l’ONAS.
• Les identifiants ou accès à l’infrastructure Levell.

---

6. Le contenu déjà en base

Le site n’arrivera pas vide. La base livrée contient l’intégralité du contenu saisi en phase de production, réparti sur 19 collections :

Collection	Entrées	Collection	Entrées
Projets	11	Documents & publications	9
Actualités	10	FAQ	12
Appels d’offres	7	Produits	2
Partenaires	9	Albums photo	1
Médias (images + PDF)	63	Vidéos	1
Utilisateurs (admin)	1	Journal d’e-mails	8

Les collections de demandes citoyennes (contacts, branchements, dépotage, analyses, appui aux promoteurs, produits dérivés, cahiers des charges) sont vides — c’est normal : elles se remplissent avec les soumissions réelles du public une fois le site en ligne.

---

7. Mise en service — procédure

Procédure pour l’option Docker, recommandée. (Une variante Node.js + systemd + Nginx est fournie sur demande.)

7.1 Installation initiale

L’ordre est impératif

L’application détecte au démarrage si la base est absente ou vide. Dans ce cas, elle initialise une base neuve — et le site démarre alors sans le contenu ONAS.

Il faut donc restaurer payload.db et media/ AVANT le tout premier démarrage (étape 3 avant l’étape 4). Ce n’est pas irréversible — il suffit de recommencer dans le bon ordre — mais cela évite une fausse alerte « le site est vide ».

# 1. Déposer le code sur le serveur
git clone <dépôt-privé> /opt/onas-web    # ou : tar -xzf onas-web.tar.gz -C /opt
cd /opt/onas-web

# 2. Configurer
cp .env.example .env
openssl rand -hex 32                      # générer PAYLOAD_SECRET
nano .env                                 # renseigner les variables du §4.1

# 3. Créer les volumes et y RESTAURER le backend peuplé (AVANT tout démarrage)
docker volume create onas-web_onas_data
docker volume create onas-web_onas_media

docker run --rm -v onas-web_onas_data:/dest -v "$PWD":/src alpine \
  cp /src/payload.db /dest/payload.db

docker run --rm -v onas-web_onas_media:/dest -v "$PWD":/src alpine \
  tar -xzf /src/onas-media.tar.gz -C /dest

# 4. Construire et démarrer
docker compose build            # ~5 à 10 min au premier build
docker compose up -d

# 5. Vérifier
docker compose logs -f          # attendre "Ready" — pas de message d'initialisation
curl -I http://localhost:3000   # doit répondre 200

Puis configurer le reverse proxy pour transmettre www.onas.sn → 127.0.0.1:3000, avec les en-têtes habituels (Host, X-Forwarded-Proto, X-Forwarded-For) et un corps de requête autorisé d’au moins 50 Mo (client_max_body_size côté Nginx) pour permettre l’upload des PDF et photos depuis le back-office.

7.2 Recette après mise en ligne

Vérification	Attendu
https://www.onas.sn	Page d’accueil complète, images de bannière visibles (= public/images OK)
Page « Projets »	11 projets avec leurs photos (= volume media + base OK)
Page « Documents »	Les PDF se téléchargent
https://www.onas.sn/admin	Connexion au back-office
Formulaire de contact	Soumission → visible dans /admin, et e-mail reçu par le service concerné
Cadenas TLS	Certificat valide, redirection HTTP → HTTPS active

---

8. Exploitation courante

Modifier le carrousel de la page d’accueil

/admin → Contenu du site → Carrousel d’accueil. Chaque slide expose :

Champ	Rôle
Étiquette	Repère dans la liste, et description de l’image pour les lecteurs d’écran
Titre	Une ligne par entrée — chaque ligne est animée séparément
Texte de présentation	Le paragraphe sous le titre. Deux à trois lignes : au-delà, il concurrence le titre
Texte / Lien du bouton	Une page du site commence par / (ex. /projets), un lien externe par https://
Image — ordinateur	Paysage, 2400 × 1350 px minimum
Image — mobile	Portrait, 1200 × 1600 px minimum. Facultatif — sinon l’image ordinateur est recadrée, souvent mal
Ordre d’affichage	Du plus petit au plus grand
Visible	Décocher retire le slide du site sans le supprimer

Tant qu’aucune image n’est téléversée, le visuel d’origine livré avec le site reste affiché. Dès qu’une image est déposée, elle prend le dessus.

Deux choses qui font croire à tort que la modification n’a pas marché

1. La page d’accueil se régénère au plus une fois par minute. Après avoir enregistré, attendre 60 secondes et recharger deux fois : le premier rechargement déclenche la régénération, le second montre le résultat. Ce fonctionnement est voulu — il garde la page instantanée pour les visiteurs.

2. Seul le premier slide est présent au chargement. Les suivants n’apparaissent qu’à la rotation (~12 s) ou en cliquant sur leur barre de progression. Modifier le slide 3 et regarder le haut de la page ne montre rien : c’est le slide 1 qui est affiché.

Le même délai d’une minute s’applique aux actualités, projets et appels d’offres publiés depuis le back-office.

Sauvegarde (quotidienne, à planifier)

#!/bin/sh
# /opt/onas-web/backup.sh — à mettre en cron quotidien
DEST=/backup/onas/$(date +%F)
mkdir -p "$DEST"

# Base ET médias, ensemble (voir Règle n°1)
docker run --rm -v onas-web_onas_data:/src -v "$DEST":/out alpine \
  cp /src/payload.db /out/payload.db
docker run --rm -v onas-web_onas_media:/src -v "$DEST":/out alpine \
  tar -czf /out/media.tar.gz -C /src .

Volume à prévoir : ~800 Mo par sauvegarde complète (les médias dominent). Une rétention de 7 jours + une archive mensuelle est un bon compromis.

Restauration

Arrêter le service (docker compose down), remplacer payload.db et le contenu de media/ par la même sauvegarde datée, redémarrer (docker compose up -d).

Mise à jour du site (évolution livrée par Levell)

Procédure en vigueur depuis le 13 août 2026

Le site est hébergé chez Infomaniak, sur une offre « site Node.js » sans Docker. Les mises à jour passent par le deploy-kit : voir Déployer chez un hébergeur client pour la procédure complète, les garanties et le retour arrière.

Côté Levell, une mise à jour tient en deux commandes :

cd /home/sidy/deploy-kit
./deploy.sh onas --no-health     # compile ici, transfère l'artefact (~3 s)
#   → Manager Infomaniak → Node.js → Redémarrer
./deploy.sh onas --health-only   # contrôle de santé

Si la mise à jour touche au schéma de la base, exécuter ./migrate-db.sh onas avant le déploiement, et prévenir l’ONAS : l’opération ouvre une fenêtre de moins d’une minute pendant laquelle une saisie au back-office serait perdue.

La base (data/payload.db), les médias du back-office (public/media/) et le fichier .env ne sont jamais touchés. Ce n’est pas une précaution d’usage : l’archive est relue avant tout envoi et le déploiement s’interrompt si l’un de ces chemins s’y trouve. Interruption de service : le temps du redémarrage.

Où regarder en cas de problème

Symptôme	Piste
Le site ne répond pas	docker compose ps puis docker compose logs --tail=100
Images du back-office cassées	Le volume media n’est pas monté (Règle n°2) ou a été restauré sans la base
Certaines images ne s’affichent pas, d’autres oui (bannières, slider, hero)	Qualité d’image non déclarée — voir la procédure ci-dessous. Ce n’est pas un fichier manquant.
Back-office vide alors que le site était peuplé	La base a été réinitialisée — restaurer la dernière sauvegarde
Les formulaires n’envoient pas d’e-mail	Ouvrir Journaux emails dans /admin : le statut donne la cause. skipped = méthode d’envoi ou destinataire non configuré ; failed + 535 = identifiants SMTP refusés ; failed + 550 = expéditeur non autorisé (chez Infomaniak, l’adresse d’expédition doit être identique à l’identifiant SMTP). Les demandes restent enregistrées dans /admin.
Upload d’un gros PDF en erreur	client_max_body_size du reverse proxy trop bas

Diagnostic : « une partie des images a disparu »

Quand des images manquent alors que le reste de la page s’affiche normalement, le réflexe est de chercher un fichier absent. C’est presque toujours une fausse piste : le fichier est là, c’est l’optimiseur qui refuse de le servir (voir §2).

Le diagnostic tient en deux commandes. Prendre l’URL d’une image manquante dans l’inspecteur du navigateur (onglet Réseau), puis :

# 1. Le fichier source est-il servi ?
curl -sI "https://<domaine>/images/photos/30-ans-ONAS.png" | head -3

# 2. L'optimiseur le sert-il ?
curl -s "https://<domaine>/_next/image?url=%2Fimages%2Fphotos%2F30-ans-ONAS.png&w=1920&q=100" | head -c 200

Résultat	Interprétation	Correction
1 → 404	Fichier réellement absent	Volume media non monté, ou build incomplet
1 → 200, 2 → 400 avec "q" parameter (quality) of … is not allowed	Qualité non déclarée	Rétablir qualities: [75, 80, 85, 90, 92, 100] dans next.config.ts, puis redémarrer
1 → 200, 2 → 200	L’image est servie : problème d’affichage (cache navigateur, CSS)	Recharger en vidant le cache (Ctrl+Shift+R)

Lire le corps de la réponse 400, pas seulement le code

L’optimiseur nomme lui-même la cause dans le corps de sa réponse ("q" parameter (quality) of 100 is not allowed). C’est l’information la plus rapide du diagnostic — un curl -I, qui n’affiche que les en-têtes, la fait manquer.

Attention à l’auto-protection de l’hébergeur en test

Enchaîner rapidement des dizaines de requêtes curl vers le site peut déclencher la limitation de débit de l’hébergeur, qui répond alors des 301 sur des URL parfaitement valides. Ces 301 sont un artefact de la mesure, pas une panne : reconfirmer tout lot d’échecs avec des requêtes espacées avant de conclure.

Après correction, l’application doit être redémarrée — pas reconstruite (§2).

---

9. Répartition des responsabilités

Sujet	Levell	ONAS
Développement du site	✅ Fait, figé	—
Livraison du code, de la base et des médias	✅	—
Runbook et transfert de compétences	✅	—
Serveur, système d’exploitation, Docker	—	✅
Reverse proxy, certificat TLS	—	✅
Nom de domaine et DNS	—	✅
Compte d’envoi d’e-mails (Brevo)	—	✅
Destinataires métier des formulaires	Conseil	✅ Décision
Sauvegardes et restauration	Procédure fournie	✅ Exécution
Publication du contenu au quotidien	—	✅

---

10. Cas Infomaniak — le serveur de l’ONAS convient-il ?

L’ONAS dispose d’un hébergement Infomaniak avec accès SSH.

« On a un accès SSH » ne répond pas à la question

Infomaniak commercialise quatre familles de produits très différentes, et le SSH est disponible sur presque toutes, y compris l’hébergement mutualisé. Savoir qu’il y a du SSH ne dit donc rien sur la compatibilité.

Ce qui tranche, c’est : y a-t-il un accès root (donc Docker), et l’application peut-elle tourner en processus permanent avec un disque persistant ?

10.1 Les offres Infomaniak et ce qu’elles permettent

Offre Infomaniak	Root / Docker	Verdict pour le site ONAS
VPS Cloud / VPS Lite	✅ Root complet, Docker installable	🟢 Idéal — c’est le scénario nominal du §7
Public Cloud (OpenStack) / Jelastic Cloud	✅ Root possible	🟢 Convient
Serveur Cloud Managé	❌ Pas de root, pas de Docker	🟡 À étudier — Node.js peut être installé manuellement, mais Infomaniak précise alors que « le site ne fonctionnera pas avec les ressources garanties du Cloud Managé »
Hébergement Web + « site Node.js »	❌ Pas de root	🟡 Probablement jouable — voir 10.3
Hébergement Web PHP seul (Starter/Essentiel classique)	❌	🔴 Incompatible — il faut basculer sur une autre offre

Première action, la plus rapide : demander à l’ONAS le nom exact de l’offre telle qu’elle apparaît dans son Manager Infomaniak (ou une capture d’écran de la page « Hébergements »). Cela suffit souvent à trancher en une minute.

10.2 Le diagnostic à faire exécuter en SSH

Pour une réponse certaine, faire exécuter ce script par l’ONAS sur le serveur cible, puis nous renvoyer toute la sortie. Il est 100 % en lecture seule : il n’installe rien, ne modifie aucune configuration, et peut tourner sans risque sur un serveur en production.

curl -O https://docs.levell.cloud/onas-diagnostic.sh
sh onas-diagnostic.sh

(Le script est également fournissable par e-mail en pièce jointe si le serveur ne peut pas télécharger depuis l’extérieur.)

Il vérifie, en 11 points : identité de la machine · privilèges root/sudo · présence et accessibilité de Docker · version de Node.js · possibilité de faire tourner un processus permanent (systemd) · CPU / RAM / disque · droit d’écriture persistante · accès réseau sortant (npm et Brevo) · possibilité d’écouter sur le port 3000 · reverse proxy déjà en place · outils de compilation.

10.3 Comment lire le résultat

Ce que montre le diagnostic	Verdict	Ce que Levell livre alors
docker présent et démon accessible	🟢 Compatible, cas nominal	Le paquet Docker complet du §5, runbook du §7 tel quel
Pas de Docker, mais root/sudo + systemd	🟢 Compatible	Soit on installe Docker, soit livraison Node.js + service systemd + Nginx
Pas de root, mais Node.js ≥ 24, écriture persistante OK, port d’écoute autorisé	🟡 Compatible sous conditions	Livraison pré-construite (voir encart ci-dessous)
RAM < 2 Go ou disque libre < 5 Go	🟡 Insuffisant	Demander un redimensionnement de l’offre
Pas de systemd, écriture refusée, port 3000 impossible	🔴 Incompatible	Basculer sur un VPS Cloud Infomaniak (même fournisseur, migration simple)

La parade si l’offre est limitée : livrer le site déjà construit

Le principal obstacle sur une offre bridée n’est pas de faire tourner le site (~290 Mo de RAM au repos) mais de le construire : npm run build est l’étape gourmande.

Comme le site est figé, cette étape n’a besoin d’être faite qu’une seule fois — et nous pouvons la faire chez nous. Nous livrons alors l’application déjà compilée (dossier .next + dépendances), que l’ONAS n’a plus qu’à démarrer. Cela ramène le besoin réel à : Node.js 24, un processus qui reste en vie, un disque persistant, un port d’écoute. C’est précisément ce que propose la fonctionnalité « site Node.js » des hébergements Web Infomaniak (tableau de bord start / stop / restart, choix de la version de Node, port d’écoute et commandes de build configurables, accès SSH et npm).

Points à valider dans ce cas via le diagnostic : version de Node 24 disponible, quota disque ≥ 5 Go (le site pèse ~1,1 Go hors dépendances, dont 278 Mo d’habillage + 793 Mo de médias), et persistance du dossier media/ entre deux redéploiements.

10.4 À vérifier en plus, propre à Infomaniak

1. Le domaine onas.sn est-il géré chez Infomaniak ? Si oui, le raccordement DNS + certificat TLS se fait en quelques clics dans le Manager, sans intervention externe.
2. Y a-t-il déjà un site en production sur cet hébergement ? Le site ONAS doit cohabiter sans écraser l’existant.
3. Quel est le quota disque réellement disponible, et non la taille du disque de la machine (sur les offres mutualisées, le quota est par compte).
4. Les sauvegardes automatiques Infomaniak couvrent-elles le dossier des médias, ou faut-il mettre en place le script du §8 ?

---

11. Informations à obtenir du service IT ONAS

Au-delà du diagnostic automatisé du §10, ces réponses permettent de figer le format de livraison et le runbook définitif :

1. Le serveur cible dispose-t-il de Docker et Docker Compose ? Sinon, quelle distribution Linux, et Node.js peut-il y être installé ?
2. Quel est l’espace disque disponible et le stockage est-il persistant (pas de conteneur éphémère) ?
3. Un reverse proxy est-il déjà en place (Nginx, Apache, HAProxy) ? Qui l’administre ?
4. Qui gère la zone DNS du domaine, et quel nom exact doit porter le site ?
5. Le certificat TLS sera-t-il Let’s Encrypt automatique ou fourni par l’ONAS ?
6. Les connexions sortantes HTTPS depuis le serveur sont-elles autorisées (nécessaires pour l’envoi d’e-mails) ?
7. L’ONAS ouvre-t-il un compte Brevo à son nom, et quelle adresse d’expédition utiliser ?
8. Quelles adresses de service doivent recevoir chacun des 7 types de demandes citoyennes ?
9. Quelle est la politique de sauvegarde en vigueur, et peut-elle intégrer les deux artefacts (fichier base + dossier médias) ?
10. Le serveur est-il exposé sur Internet ou derrière un pare-feu nécessitant une ouverture de flux ?