Par Laurent Millotte, développeur et formateur web. Publié le 5 juin 2026, mis à jour le 10 août 2026. Mon expérience en accessibilité numérique et développement web

Article 4 sur 4, série Parcours débutant : du navigateur au serveur

Un serveur web reçoit une requête, puis renvoie une réponse. Ici, vous écrivez votre premier serveur avec Node.js pour l’exécuter et Express pour simplifier l’écriture des routes.

Que fait un serveur, au juste ?

Un serveur web attend une requête, puis renvoie une réponse : c’est tout son travail, répété en boucle.

Quand vous saisissez une adresse dans votre navigateur, celui-ci envoie une requête. Cette requête suit le protocole HTTP (HyperText Transfer Protocol, protocole de transfert hypertexte), un langage commun aux navigateurs et aux serveurs. Le serveur reçoit la requête, choisit quoi renvoyer, puis expédie une réponse.

L’objectif de cet article est d’écrire le programme qui tient ce rôle.

Pourquoi utiliser Express plutôt que Node.js seul ?

Node.js gère le réseau tout seul, mais écrire un serveur avec ses seules fonctions demande du code répétitif : il faut lire l’adresse demandée, la comparer à la main, puis brancher la bonne réponse.

Voici la même route, écrite d’abord avec le module natif de Node.js, puis avec Express.

Avec le module natif http, sans aucune brique externe :

const http = require("http");

const server = http.createServer((req, res) => {
  if (req.url === "/") {
    res.end("Bonjour le monde !");
  }
});

server.listen(3000, () => {
  console.log("Serveur démarré sur http://localhost:3000");
});

Ce code fonctionne, mais il vieillit mal. Ajoutez une deuxième route, et le if se transforme en if / else if / else. Ajoutez-en dix, et le fichier devient difficile à relire.

Avec Express, une brique installable via npm (Node Package Manager, gestionnaire de paquets de Node.js) :

const express = require("express");
const app = express();

app.get("/", (req, res) => {
  res.send("Bonjour le monde !");
});

app.listen(3000, () => {
  console.log("Serveur démarré sur http://localhost:3000");
});

La comparaison des deux blocs montre ce qu’Express change réellement : app.get("/", ...) remplace le test manuel sur req.url. Chaque route s’ajoute alors comme une ligne de plus, sans toucher aux précédentes.

Cet article utilise Express 4, la branche la plus répandue et celle que la commande require("express") suppose. Une version plus récente, Express 5, existe aussi depuis décembre 2025, avec une syntaxe d’import différente. On installe Express ainsi :

npm install express

Un serveur en quelques lignes, décortiqué

Reprenons le code Express ligne par ligne, plutôt que de le copier sans le lire : c’est en comprenant chaque morceau qu’il devient réutilisable dans vos propres projets.

La première ligne importe la brique Express installée précédemment. La deuxième crée l’application.

La méthode app.get définit une route : « lorsqu’un visiteur demande l’adresse /, voici la réponse à lui renvoyer ». La fonction reçoit deux objets par convention, req pour la requête, ce que demande le visiteur, et res pour la réponse, ce qu’on lui renvoie. Ici, la réponse est un simple texte.

Enfin, app.listen(3000, ...) met le serveur à l’écoute sur le port 3000. À partir de cet appel, le serveur attend les visiteurs.

Enregistrez ce code dans un fichier nommé serveur.js, puis lancez-le avec la commande node serveur.js.

Le terminal après le lancement du serveur.

Ouvrez ensuite http://localhost:3000 dans votre navigateur : le message s’affiche. Vous venez de servir une page depuis un programme que vous avez écrit de bout en bout.

Trois pistes pour prolonger ce serveur

Trois évolutions concrètes prolongent ce serveur minimal : une nouvelle route, une réponse structurée pour une interface de programmation applicative, une connexion à une base de données.

Ajouter une route /contact suit exactement le modèle vu plus haut, avec une deuxième instruction app.get :

app.get("/contact", (req, res) => {
  res.send("Écrivez-moi à contact@exemple.fr");
});

Renvoyer des données structurées, au lieu d’un texte, prépare le terrain pour une API consommée par une application mobile ou par un autre site. Brancher une base de données ajoute une brique de plus, cherchée et installée de la même façon qu’Express.

Cette série a suivi un chemin volontairement concret : les bases du langage JavaScript, puis Node.js, puis ce serveur. Mon avis : la meilleure étape suivante n’est pas un nouveau cours. Elle est votre prochain projet, même petit.

Si vous préférez être accompagné plutôt qu’avancer seul sur ces bases, une formation JavaScript et Node.js reprend ces notions avec un formateur, à votre rythme.

Node.js est un moteur d’exécution JavaScript côté serveur et permet donc d’exécuter du JavaScript directement sur votre ordinateur ou sur un serveur, sans avoir besoin d’un navigateur.

Node.js est gratuit. En 2026 la Version actuelle de Node.js est la 26.7.0, la dernière LTS (Long-Term Support, en français, support à long terme) est la 24.19.0.

Si, comme moi, vous utilisez JavaScript dans vos développements web, vous savez donc que JS s’exécute généralement dans le navigateur. Cependant, JS est maintenant utilisable au niveau du serveur et ce grâce à Node.js.

Un seul langage pour le développement

L’interêt de Node.js est simple à comprendre.

Un site web est toujours construit sur deux piliers : le front-end et le back-end.

• Le front-end, ou simplement le front, comprend tout ce qui est géré dans le navigateur de l’utilisateur ;
• Le back-end, c’est tout ce qui n’est pas directement visible dans la page : la base de données, la logique métier, l’envoi des e-mails.

Très souvent, dans les stacks classiques, on avait besoin de deux langages différents, par exemple PHP pour le back-end et JS pour le front-end.

Grâce à Node.js, on développe les deux avec un seul langage : JavaScript. Avec un seul langage, on produit l’ensemble de la chaîne. C’est ce qu’on appelle le développement full-stack. Naturellement, le gain est considérable et c’est pourquoi Node.js est très populaire.

Comment ça marche ?

Node.js utilise le moteur open source V8 sur lequel repose aussi le navigateur Chrome.

Le principe de base est que ce moteur a été « sorti » de Chrome pour fonctionner de façon autonome, tout en gardant toute la puissance de JS.

Des outils issus de bibliothèques du C++ permettant de lire des fichiers, d’écouter le réseau ou de communiquer avec une base de données, etc., ont été ajoutés, et on obtient ainsi une plateforme complète pour créer des applications côté serveur.

Hello World

L’installation de Node.js est simple.

Une fois que vous l’avez installé, vous créez un fichier hello.js avec cette ligne de code :

console.log("Salut depuis Node.js");

Puis, dans un terminal, il vous suffit de taper :

node hello.js

Le message « Salut depuis Node.js » s’affichera dans le terminal. On vient de franchir un cap important : on a créé un fichier JS et on l’a interprété en dehors d’un navigateur, sans l’afficher dans une page web.

Le message s’affiche dans le terminal et non dans le navigateur

npm, pour ne pas réinventer la roue

L’autre force de Node.js est le gestionnaire de paquets appelée npm, pour Node Package Manager, et qui peut être considéré comme la bibliothèque géante de Node.js.

C’est un immense catalogue de modules déjà écrits par d’autres développeurs, qu’il est possible d’intégrer à nos projets avec une simple commande.

Cet écosystème géant contient tout ce qui est utile pour démarrer et développer nos projets et qui est parfois pénible à gérer, il faut bien le dire : gestion des dates, génération de mots de passe, création d’un serveur web, etc.

Bien sûr, npm ne contient généralement pas le code spécifique nécessaire au métier de l’application, par exemple la gestion d’un garage ou d’une boutique.

Ainsi, plutôt que de tout réinventer, on assemble des briques validées par la communauté et évolutives, et on se concentre sur la valeur ajoutée du code de l’application.

C’est pourquoi un projet Node.js démarre souvent avec la commande d’initialisation de npm :

npm init -y

Cette commande crée un fichier package.json, qui liste les modules npm que vous installez et devient ainsi une véritable carte d’identité du projet : son nom, sa version et la liste des modules externes utilisés.

Ainsi, on possède désormais les deux ingrédients clés : JavaScript qui tourne côté serveur et une bibliothèque de modules pour réutiliser du code existant.

Dans un prochain article, nous les combinerons pour fabriquer quelque chose de concret : un véritable serveur web.

Article 2/4 — Parcours débutant : du navigateur au serveur

Dans le premier article, nous avons situé JavaScript comme le langage du comportement d’une page web. Place maintenant aux deux outils que vous utiliserez dans absolument tous vos programmes : les variables et les fonctions.

Ranger une information : la variable

Une variable est une étiquette posée sur une information pour pouvoir la retrouver plus tard. On en déclare une avec le mot-clé const ou let :

const prenom = "Laurent";
let age = 30;

La différence tient en une règle de bon sens. On utilise const (pour constante) quand l’information ne changera pas, et let quand elle est appelée à évoluer. Le réflexe sain consiste à choisir const par défaut, et à ne passer à let que si l’on a une raison de modifier la valeur. Cela rend le code plus lisible : un lecteur sait, d’un coup d’œil, ce qui bouge et ce qui est figé.

Quelques types de données

Une variable peut contenir différentes natures d’information. Les plus courantes au départ sont le texte (la chaîne de caractères, entre guillemets), les nombres, et les booléens — c’est-à-dire les valeurs true (vrai) ou false (faux), pratiques pour répondre à une question par oui ou non.

const nom = "Dupont";    // texte
const score = 42;         // nombre
const estConnecte = true; // booléen

Écrire une action réutilisable : la fonction

Une fonction est un bloc d’instructions auquel on donne un nom, pour pouvoir le rejouer à volonté sans le réécrire. Pensez-y comme à une recette : on la définit une fois, puis on l’exécute autant de fois qu’on le souhaite, éventuellement avec des ingrédients différents.

function saluer(nom) {
  return "Bonjour " + nom;
}

saluer("Laurent"); // renvoie "Bonjour Laurent"
saluer("Marie");   // renvoie "Bonjour Marie"

Le mot nom entre parenthèses est un paramètre : une information que l’on fournit à la fonction au moment de l’appeler. Le mot return indique le résultat que la fonction renvoie.

JavaScript moderne propose une écriture plus compacte, la fonction fléchée, que vous rencontrerez partout :

const saluer = (nom) => "Bonjour " + nom;

C’est exactement la même recette, présentée plus brièvement. Inutile de chercher à mémoriser cette syntaxe par cœur dès aujourd’hui : elle deviendra naturelle à force de l’écrire.

Avec ces deux notions — stocker une information, exécuter une action — vous tenez déjà l’ossature de la quasi-totalité des programmes. Dans le prochain article, nous ferons sortir JavaScript du navigateur pour découvrir Node.js.

Article 1/4 — Parcours débutant : du navigateur au serveur

Si vous avez déjà cliqué sur un bouton qui déroule un menu, vu un formulaire signaler une erreur sans recharger la page, ou fait glisser une carte sous votre souris, vous avez croisé JavaScript. C’est le langage qui rend les pages web vivantes.

Trois piliers, trois rôles

Pour situer JavaScript, il faut le replacer auprès de ses deux compagnons. Une page web repose sur trois technologies aux rôles bien distincts.

Le HTML (HyperText Markup Language, langage de balisage hypertexte) fournit la structure : les titres, les paragraphes, les images, les liens. C’est le squelette de la page.

Le CSS (Cascading Style Sheets, feuilles de style en cascade) gère l’apparence : couleurs, polices, espacements, disposition. C’est le vêtement posé sur le squelette.

JavaScript, lui, apporte le comportement : ce qui réagit, calcule, change, communique avec un serveur. C’est, si l’on file la métaphore, le système nerveux. Sans lui, une page reste un document que l’on lit ; avec lui, elle devient une application avec laquelle on dialogue.

Un langage qui a débordé de son cadre

JavaScript est né en 1995 pour animer les pages dans le navigateur, et rien d’autre. C’était sa seule maison. Mais le langage a tellement gagné en maturité qu’il s’est mis à tourner ailleurs : sur les serveurs, dans les applications mobiles, jusque dans les objets connectés.

Cette expansion explique pourquoi JavaScript est aujourd’hui l’une des compétences les plus recherchées : un seul langage permet de travailler à la fois sur ce que voit l’utilisateur (le front-end) et sur la machinerie cachée derrière (le back-end). Nous y reviendrons dans les articles suivants.

Faut-il être informaticien pour s’y mettre ?

Non. JavaScript a la rare qualité de produire un résultat visible presque immédiatement : quelques lignes suffisent pour qu’un bouton réagisse. Cette gratification rapide en fait un excellent premier langage, à condition d’accepter une règle simple : on progresse en construisant de petites choses qui fonctionnent, pas en cherchant à tout mémoriser d’avance.

C’est précisément l’esprit de cette série. Dans le prochain article, nous poserons les briques de base du langage : comment stocker une information, et comment écrire une instruction réutilisable.

Le pair programming (programmation en binôme) est une vieille pratique : deux développeurs, un clavier, un dialogue permanent qui muscle la qualité du code. L’arrivée des assistants IA (Claude, ChatGPT, Copilot) en propose une variante asynchrone et toujours disponible. Encore faut-il s’en servir comme d’un coéquipier, pas comme d’un distributeur de solutions.

Choisir son rôle dans le binôme

La règle d’or tient en une question : qui tient le clavier ?

Quand vous tenez le clavier, l’IA joue le rôle du navigator — elle commente, propose, alerte, mais c’est vous qui écrivez. Vous restez le pilote, vous gardez la mécanique en main. C’est la configuration la plus formatrice.

Quand l’IA tient le clavier — c’est-à-dire quand vous copiez son code tel quel — vous devenez navigateur. C’est utile pour les tâches répétitives ou un terrain que vous maîtrisez déjà, dangereux sur un sujet que vous découvrez. Coller un bloc de 80 lignes que vous ne pourriez pas réécrire seul, c’est creuser une dette de compréhension qui vous tombera dessus au premier bug.

Alternez les deux rôles consciemment, en sachant lequel vous jouez à chaque instant.

Bien formuler ses demandes

Une IA n’a pas accès à votre contexte : ni votre projet, ni vos conventions, ni l’erreur exacte que vous avez en tête. Quatre éléments font passer une demande médiocre à une demande utile :

• Le contexte : « projet Node.js / Express, base PostgreSQL », pas « j’ai un site ».
• L’intention : ce que vous cherchez à faire, et pourquoi.
• Ce que vous avez déjà tenté : ça évite les suggestions que vous avez déjà éliminées.
• Le format attendu : explication courte, code commenté, comparaison de deux approches.

Plus la question est précise, plus la réponse est exploitable. Une question floue produit une réponse générique — exactement comme avec un collègue humain.

Les bons usages

Certains usages tirent vraiment parti de l’IA. Débloquer une situation : vous tournez en rond sur un message d’erreur, l’IA propose trois pistes, l’une d’elles relance la machine. Explorer une API inconnue : plutôt que d’éplucher la documentation seul, vous demandez un exemple minimal et vous lisez le code obtenu. Relire son propre code : « voici ma fonction, qu’est-ce qui peut mal tourner ? » donne souvent des retours pertinents. Traduire une intention en code de départ : utile pour amorcer, à condition de retravailler ce qui sort.

Les pièges à éviter

Le premier piège est la confiance aveugle. Une IA produit du code plausible, pas nécessairement correct. Elle peut inventer une fonction qui n’existe pas, utiliser une syntaxe obsolète, ou résoudre un problème voisin du vôtre sans le dire. Testez tout ce qu’elle propose.

Le second est la dilution de la compréhension. Si à la fin d’une session vous avez un code qui fonctionne mais que vous ne sauriez pas expliquer ligne à ligne, vous avez livré du code et perdu l’apprentissage. Sur un sujet que vous voulez maîtriser, imposez-vous de tout retaper à la main.

Le troisième est la perte d’initiative. Réflexe à entretenir : essayer de résoudre seul pendant 15 minutes avant d’appeler le binôme. Sinon, on perd l’habitude de penser, et c’est précisément ce que les années pratiquent.

Un coéquipier, pas un oracle

La meilleure manière de se positionner : traiter l’IA comme un collègue compétent mais qui ne connaît pas votre projet. Vous ne lui livreriez pas votre code en aveugle, vous ne croiriez pas chacune de ses affirmations sans vérification, vous ne lui délègueriez pas vos décisions d’architecture. La même prudence professionnelle s’applique. À cette condition, c’est un binôme remarquable.

Dans un projet JavaScript fullstack — typiquement React, Vue ou Next.js côté front, Node.js côté back — il est tentant de considérer HTML et CSS comme des détails que le framework gérera. C’est précisément l’erreur qui produit des interfaces lourdes, inaccessibles et pénibles à maintenir. Le framework rend le HTML, mais c’est vous qui décidez de sa qualité.

HTML : redonner du sens aux balises

Le réflexe <div> partout est le marqueur d’un projet front en dérive. HTML5 propose un vocabulaire riche : <header>, <nav>, <main>, <article>, <section>, <aside>, <footer>, <button>, <figure>. Chacune porte un sens que les navigateurs, les moteurs de recherche et les lecteurs d’écran exploitent.

La règle pratique : avant de poser une <div>, demandez-vous si une balise plus précise existe. Une zone cliquable qui déclenche une action est un <button>, pas une <div> avec un onClick. Un lien qui mène ailleurs est un <a>, pas un <span> stylé. Ce n’est pas du purisme : un <button> est focusable au clavier, déclenchable avec Entrée, annoncé comme bouton par les outils d’accessibilité. Vous n’avez rien à coder pour ça — à condition d’avoir choisi la bonne balise.

L’accessibilité, justement, n’est pas une couche qu’on ajoute à la fin. Quelques réflexes suffisent à 80 % du travail : un attribut alt sur chaque <img> significative, des <label> reliés à leurs champs de formulaire, une hiérarchie de titres <h1> à <h6> cohérente, un contraste suffisant entre texte et fond. Le reste s’apprend au fil des projets.

CSS : maîtriser le poids et l’éparpillement

Le problème classique d’un projet fullstack JS n’est pas l’écriture du CSS — c’est sa prolifération. Chaque composant tend à embarquer ses propres styles, et au bout de quelques mois, personne ne sait plus ce qui sert encore.

Trois principes limitent les dégâts.

Choisir une stratégie de scoping, et s’y tenir. Scoping signifie limiter la portée d’une règle CSS pour qu’elle n’affecte que son composant. Les options courantes sont les CSS Modules (un fichier .module.css par composant, classes localisées automatiquement), les styled-components ou équivalents (CSS écrit dans le JavaScript), et les frameworks utilitaires comme Tailwind (classes prédéfinies appliquées directement dans le HTML). Aucune n’est universellement meilleure ; la mauvaise décision est de les mélanger sans raison sur un même projet.

Séparer les variables des règles. Couleurs, espacements, tailles de police, rayons de bordure : tout ce qui se répète doit vivre dans des custom properties CSS (--couleur-primaire, --espace-md). Cela coûte une heure au démarrage et économise des semaines lors d’un changement de charte graphique. C’est aussi la base d’un mode sombre propre.

Penser mobile d’abord. Écrivez d’abord les styles pour le petit écran, puis ajoutez les ajustements pour les plus grands via des media queries. L’inverse — concevoir pour le bureau puis « adapter » — produit presque toujours une expérience mobile médiocre.

Les ponts entre back et front

Dans un projet fullstack, vous générez parfois du HTML côté serveur (rendu Express avec un moteur de templates, ou Server-Side Rendering avec Next.js) et parfois côté client. Deux pièges à garder en tête.

D’abord, ne jamais injecter du contenu utilisateur dans du HTML sans l’échapper. Une chaîne <script>alert('xss')</script> venue d’un formulaire et collée brute dans une page ouvre une faille XSS (Cross-Site Scripting, injection de scripts entre sites). Les moteurs de templates sérieux échappent par défaut ; encore faut-il ne pas désactiver cette protection sans raison forte.

Ensuite, rendre côté serveur ce qui doit être visible immédiatement et indexable. Un titre, une description, le contenu principal d’un article doivent apparaître dans le HTML initial — pas être ajoutés par JavaScript après le chargement. C’est essentiel pour le référencement et pour les utilisateurs aux connexions lentes.

Le test qui ne ment pas

Une bonne pratique se vérifie facilement : désactivez CSS dans votre navigateur, naviguez sur votre site. Si la structure reste lisible — titres clairs, ordre logique, formulaires utilisables — votre HTML fait son travail. Désactivez maintenant JavaScript. Si la page d’accueil et les contenus principaux restent accessibles, votre fullstack est bien architecturé.

Ces deux tests prennent trente secondes. Ils en disent plus long sur la santé d’un projet que beaucoup d’outils sophistiqués.

Par Laurent Millotte, développeur et formateur web. Publié le 21 mai 2025, mis à jour le 10 août 2026. Mon expérience en accessibilité numérique et développement web

Un ERP (Enterprise Resource Planning, système de gestion intégré) centralise les données d’une organisation : clients, stocks, employés, dans un seul outil. Un ERP léger fait la même chose sans le superflu d’un outil standard : aucun module qui ne sert jamais, un framework PHP rapide à déployer plutôt qu’un logiciel long à installer et à former les équipes.

Pourquoi construire un ERP plutôt qu’en acheter un ?

Un ERP du marché coûte cher et impose souvent des fonctions dont une petite structure n’a pas l’usage. C’est précisément ce qui rend un ERP « léger » : pas de module qui dort sans être utilisé, pas de formation à payer sur des écrans que personne n’ouvre.

Une association ou une petite entreprise n’a parfois besoin que de trois choses :

• Suivre ses membres ou ses clients
• Encaisser des paiements
• Garder une trace de qui a fait quoi

Construire cet outil sur mesure, en PHP, coûte moins cher à l’usage qu’un abonnement à un ERP généraliste, à condition d’accepter de ne couvrir que les besoins réels, pas tout ce qu’un ERP du marché propose par défaut.

Une architecture modulaire, pour quoi faire ?

Une architecture modulaire sépare chaque fonction de l’ERP en un morceau de code indépendant, pour que corriger l’un ne casse pas les autres.

Concrètement, cela veut dire :

• Un module pour la gestion des membres
• Un module pour la facturation
• Un module pour le suivi des paiements

Chaque module peut évoluer seul. J’ai vu l’intérêt de cette séparation sur un projet réel : le site du Réseau Sage-Femme Paris Île-de-France, développé en 2015 sous CodeIgniter 3 pour gérer les inscriptions et les cotisations de l’association. Le module de paiement était alors distinct du module d’inscription, ce qui a permis, en 2024, de remplacer uniquement la partie paiement, sans toucher au reste du site.

Quel framework PHP choisir : Laravel ou Symfony ?

Les deux frameworks les plus utilisés pour ce type de projet sont Laravel et Symfony, et le choix dépend surtout de la taille prévue de l’ERP.

• Laravel mise sur la rapidité de mise en route. Son ORM (Object-Relational Mapping, correspondance entre objets et base de données) nommé Eloquent simplifie l’écriture des requêtes, et son système de gabarits Blade accélère la construction des pages. La version actuelle est Laravel 13, dont la dernière mise à jour stable date du 4 août 2026.
• Symfony demande un peu plus de mise en place au départ, mais son architecture est pensée pour rester lisible même quand le projet grossit beaucoup. La version actuelle est Symfony 8.1, avec une branche à support long, la 7.4, pour qui préfère moins de mises à jour.

Pour un ERP qui restera petit, je penche plutôt vers Laravel. Pour un ERP amené à grandir sur plusieurs années, Symfony tient mieux la distance. C’est mon avis, construit sur des projets PHP menés depuis 2007, pas une règle universelle.

Comme je l’ai précisé, le site du Réseau Sage-Femme Paris Île-de-France n’a été construit ni avec Laravel ni avec Symfony, mais avec CodeIgniter 3, un choix qui avait ses arguments en 2015. Ce framework existe toujours, dans une version plus récente, mais je le recommande moins aujourd’hui pour un projet neuf, à mon avis. Le principe de séparation en modules, lui, ne dépend d’aucun framework en particulier.

Comment sécuriser l’accès aux données ?

Un ERP touche des informations sensibles, employés, finances, clients, donc l’accès doit être limité à ce que chaque utilisateur a le droit de voir.

L’authentification et les rôles vont ensemble. Un jeton JWT (JSON Web Token, un format de jeton qui vérifie l’identité d’un utilisateur sans repasser par un mot de passe à chaque requête) confirme qui se connecte, puis un système de rôles, administrateur, employé, client, décide de ce que cette personne a le droit de voir une fois connectée. Le chiffrement des données sensibles, mots de passe et informations financières en tête, complète l’ensemble : même en cas d’accès non autorisé à la base de données, ces informations restent illisibles.

Sur le site du Réseau Sage-Femme, toujours sous CodeIgniter 3, la version de 2015 gérait déjà les rôles, membre et responsable d’association, avec des droits différents. L’authentification JWT est arrivée plus tard, en 2024, avec le passage du système de paiement ComNPay vers l’API HelloAsso. Ce n’était pas prévu dès le départ : c’est l’évolution du site qui a rendu ce changement nécessaire, pas un choix fait à l’avance.

Un tableau de bord, pour quoi faire ?

Un tableau de bord donne une vue d’ensemble des métriques qui comptent pour l’organisation, sans avoir à ouvrir chaque module séparément.

En PHP, des bibliothèques comme Chart.js ou ApexCharts affichent ces données sous forme de graphiques. Le piège, à mon avis, est d’ajouter un tableau de bord avant de savoir précisément quelles métriques l’organisation regarde vraiment chaque semaine. Un tableau de bord rempli de chiffres que personne ne consulte n’aide personne, il ralentit juste chaque page où il apparaît.

Le site du Réseau Sage-Femme en a un, plus simple que ce que les bibliothèques citées plus haut permettraient :

• Un décompte des adhérentes inscrites
• La liste des inscriptions en attente de validation

Deux informations, pas dix, mais ce sont les deux que les responsables de l’association regardent réellement.

Comment tester et maintenir cet ERP dans la durée ?

La qualité du code décide si l’ERP reste stable après plusieurs années d’usage, pas seulement au moment de la livraison.

• Tests unitaires : un par fonction, ils vérifient qu’un module fait ce qu’il est censé faire.
• Tests d’intégration : ils vérifient que les modules ne se marchent pas dessus une fois assemblés.
• Documentation : même courte, elle rend le projet reprenable par un autre développeur si besoin.

Le site du Réseau Sage-Femme illustre aussi ce point : il tourne depuis 2015, avec une seule évolution majeure en neuf ans, ce qui n’aurait probablement pas été possible sans une architecture assez claire pour qu’on puisse encore la comprendre en 2024.

Si vous préférez déléguer ce travail plutôt que le mener seul, je développe ce type d’applications métier sur mesure, annuaires, espaces adhérents, cotisations en ligne compris. Une formation PHP et MySQL reste une autre option, si vous préférez construire cet ERP vous-même avec un accompagnement.

Oui, je développe des sites WordPress sur mesure. Mais je ne m’arrête pas là. Je suis aussi développeur PHP, ce qui me permet d’aller beaucoup plus loin que la simple personnalisation de thèmes ou l’installation de plugins.

Un site qui ne se limite pas à ce que permet WordPress par défaut

WordPress est construit en PHP. Maîtriser ce langage me permet de :

• Créer des fonctionnalités sur mesure, là où les plugins ne suffisent pas
• Optimiser les performances avec un code propre et léger
• Intégrer des systèmes ou APIs externes (paiement, CRM, réservation, etc.)
• Développer des plugins ou des thèmes entièrement personnalisés

En clair : je ne me contente pas d’assembler des blocs. Je développe des solutions adaptées à vos besoins réels.

Pourquoi c’est important pour vous ?

Parce que chaque projet est unique. Peut-être que vous avez besoin d’un espace membre sécurisé, d’une logique métier spécifique, ou d’un back-office ultra simplifié. Avec une vraie expertise PHP, je ne suis pas limité aux outils « tout faits » : je peux créer exactement ce qu’il vous faut.

C’est aussi un gage de durabilité : un site bien développé, c’est un site qui dure dans le temps, qui se met à jour facilement et qui reste performant, même quand votre activité évolue.

WordPress ou développement sur mesure : on choisit ensemble

WordPress n’est pas toujours la réponse à tout — et je ne vous le vendrai pas s’il ne correspond pas à vos besoins. Mon approche, c’est d’écouter, analyser, puis proposer la solution la plus adaptée :

• WordPress ? Parfait pour un site vitrine, un blog, une boutique en ligne rapide à mettre en place.
• PHP personnalisé ? Idéal si vous avez besoin d’une application web avec des logiques spécifiques, ou d’un projet technique sur mesure.

Je conçois des sites performants, évolutifs et pensés pour durer — avec WordPress quand c’est pertinent, et avec PHP quand c’est nécessaire.

Besoin d’un site qui va au-delà des standards ? Parlons-en.

WordPress est bien plus qu’un simple outil de création de sites : c’est un véritable écosystème. Utilisé par plus de 40 % des sites web dans le monde, il séduit aussi bien les indépendants que les grandes entreprises. Pourquoi cet engouement ? Parce que WordPress allie simplicité, puissance et liberté.

Un outil flexible, pour tous les besoins

Que vous ayez besoin d’un site vitrine, d’un blog professionnel, d’un portfolio ou d’une boutique en ligne, WordPress s’adapte à vos objectifs. Grâce à une vaste bibliothèque de thèmes et de plugins, il est possible de construire un site sur mesure, sans repartir de zéro.

Mais un bon site ne se limite pas à l’apparence. C’est pourquoi je vais au-delà du simple “thème prêt à l’emploi”. En tant que développeur WordPress, je crée des solutions personnalisées, propres au code, sécurisées et pensées pour évoluer avec votre activité.

Performance, sécurité, référencement

Un site lent ou mal référencé peut nuire à votre image. C’est pourquoi j’accorde une attention particulière aux performances, à l’optimisation SEO et à la sécurité.
Chaque site que je développe est :

• Rapide et optimisé pour les mobiles
• Compatible avec les bonnes pratiques SEO (balises, sitemap, structure claire…)
• Sécurisé contre les attaques courantes (mises à jour, pare-feu, sauvegardes)

Une gestion simple, même sans être technicien

L’un des grands avantages de WordPress, c’est sa simplicité d’utilisation. Une fois votre site en ligne, vous restez autonome : ajouter une page, modifier un texte ou publier un article se fait en quelques clics. Et si besoin, je propose également des formations personnalisées pour vous aider à prendre en main votre site.

Choisir WordPress, c’est faire le choix d’une solution fiable, pérenne et évolutive. Choisir un développeur WordPress dédié, c’est vous assurer d’un accompagnement sur mesure, de la conception à la mise en ligne, et bien au-delà.

Vous avez un projet ? Discutons-en ! Ensemble, donnons vie à un site qui vous ressemble, et qui atteint vos objectifs.