Un ERP léger, sur mesure en PHP
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.