La plupart des bugs ERPZEN que je reçois commencent par la même phrase : « L'autre prestataire a modifié le core. » C'est là que les ennuis commencent vraiment. Parce qu'à la mise à jour suivante, tout saute. Et on m'appelle.
La règle d'or : on ne touche pas au core
Je travaille sur ERPZEN depuis des années, et j'ai une ligne que je ne franchis jamais : on ne modifie pas le cœur de l'application. Tout passe par des modules, des hooks et des overrides propres. Ce qui veut dire que votre installation reste à jour, sécurisée et maintenable — même dans cinq ans, même par quelqu'un d'autre.
Modifier directement un fichier de application/ donne l'illusion d'aller vite. En réalité, vous venez de signer une dette : la prochaine mise à jour de ERPZEN écrasera votre fichier, ou pire, le conservera et créera une incohérence silencieuse. Dans les deux cas, c'est un appel au support quelques mois plus tard.
Pourquoi les mises à jour cassent tout
ERPZEN est un produit vivant : corrections de sécurité, nouvelles fonctionnalités, compatibilité PHP. Chaque montée de version remplace les fichiers du core. Si votre personnalisation vit dans ces fichiers, elle disparaît ou entre en conflit. La seule personnalisation pérenne est celle qui vit en dehors du core.
Comment faire proprement : hooks et modules
ERPZEN (CodeIgniter 3) expose un système de hooks riche. Au lieu de patcher une vue ou un contrôleur, on s'y branche depuis un module isolé :
// modules/mon_module/mon_module.php
hooks()->add_action('after_invoice_added', 'mon_module_sync_compta');
function mon_module_sync_compta($invoice_id)
{
$CI =& get_instance();
$CI->load->model('mon_module/sync_model');
// Logique métier isolée — le core reste intact.
$CI->sync_model->push($invoice_id);
}
// Override d'une vue SANS toucher au core :
// modules/mon_module/views/ + app_init pour réécrire le rendu.Le module est autonome : on l'active, on le désactive, on le déplace d'une installation à l'autre. Le core, lui, ne sait même pas qu'il existe — et c'est exactement ce qu'on veut.
Ce que je prends en charge
- Debug de modules — les vôtres, ceux du marketplace, ou ceux laissés par un ex-prestataire.
- Audit de sécurité complet — OWASP, isolation des données client, conformité PHP 8.x, anti-IDOR.
- Développement sur mesure — SIRH, e-invoicing Factur-X, passerelles de paiement africaines, modules sectoriels.
- Optimisation des performances — requêtes, cache, élimination des N+1.
- Reprise de dette technique — remettre d'aplomb une installation devenue ingérable.
Ma méthode : zéro surprise en production
Méthode BMAD, zéro régression, livraisons fichier par fichier, validation à chaque étape. On comprend le besoin, on modélise, on dessine l'intégration, puis seulement on code. Chaque migration de module est idempotente et réversible. Aucune montée de version ERPZEN ne doit vous prendre en otage.
Conclusion
Un CRM, c'est un actif. Le traiter avec discipline — modules, hooks, overrides propres — c'est la différence entre une installation qui vieillit bien et une bombe à retardement qui explose à chaque update. Si vous cherchez quelqu'un qui code vite sans réfléchir, je ne suis pas la bonne personne. Si vous cherchez quelqu'un qui règle le problème une bonne fois pour toutes, écrivez-moi.