4 800 lignes dans un seul fichier fonctions.php : c’est le chiffre relevé sur une extension de gestion d’adhésions associatives, développée initialement par une seule personne sur plus de deux ans. Tant que cette personne restait seule aux commandes, le choix n’avait rien d’absurde : tout le code métier se trouvait au même endroit, une recherche par mot-clé suffisait à retrouver n’importe quelle fonction, et aucun système de modules n’était nécessaire pour un projet de cette taille.
Le problème est apparu le jour où une deuxième développeuse a rejoint le projet pour ajouter une fonctionnalité de relance automatique des cotisations impayées. Ce que l’on observe dans ce genre de situation, et une découpe minimale qui suffit généralement à désamorcer le problème sans tomber dans l’excès inverse d’une architecture surdimensionnée.
Ce qu’on observe : des conflits de fusion systématiques
Dès que deux personnes modifient le même fichier volumineux, même sur des fonctions totalement indépendantes, les outils de gestion de version signalent des conflits à chaque tentative de fusion. Le fichier étant unique, Git ne peut pas distinguer une modification portant sur la gestion des cotisations d’une modification portant sur l’envoi d’e-mails : toute ligne ajoutée ou déplacée à proximité d’une autre modification déclenche un conflit à résoudre manuellement.
$ git merge feature/relance-automatique
Auto-merging fonctions.php
CONFLICT (content): Merge conflict in fonctions.php
Automatic merge failed; fix conflicts and then commit the result.Sur ce projet précis, la résolution de ces conflits a fini par occuper une part non négligeable du temps de développement, pour un travail qui n’apportait aucune valeur au produit final : simplement réconcilier deux versions d’un même fichier trop large.
Pourquoi c’est un problème, au-delà des conflits Git
Le problème dépasse la seule mécanique de fusion. Un fichier de plusieurs milliers de lignes devient également difficile à ouvrir et à naviguer dans un éditeur de code, ralentit l’indexation de certains outils d’analyse statique, et rend la relecture d’une modification bien plus coûteuse : un correctif de trois lignes se retrouve noyé dans un diff qui semble toucher un fichier entier, simplement parce que l’éditeur a reformaté l’indentation au passage.
Il complique aussi la compréhension du périmètre de chaque fonctionnalité : rien dans la structure du projet n’indique où commence et où finit le code lié aux cotisations, par opposition à celui lié aux e-mails ou à la génération de reçus fiscaux. Tout est mélangé au même niveau, dans l’ordre chronologique d’écriture plutôt que dans un ordre logique.
Une découpe minimale suffisante
La correction n’exige pas de réécrire l’extension avec une architecture élaborée. Une découpe minimale, en quelques fichiers regroupés par domaine fonctionnel, suffit à résoudre l’essentiel du problème :
extension-adhesions/
├── extension-adhesions.php // point d'entrée, chargement des fichiers
├── inc/
│ ├── cotisations.php
│ ├── relances.php
│ ├── recus-fiscaux.php
│ └── emails.php
└── inc/admin/
└── ecran-reglages.phpLe fichier principal se limite à charger les autres fichiers, sans contenir lui-même de logique métier :
require_once __DIR__ . '/inc/cotisations.php';
require_once __DIR__ . '/inc/relances.php';
require_once __DIR__ . '/inc/recus-fiscaux.php';
require_once __DIR__ . '/inc/emails.php';
require_once __DIR__ . '/inc/admin/ecran-reglages.php';Cette découpe reste volontairement simple : pas de conteneur d’injection de dépendances, pas de couche d’abstraction supplémentaire, juste une séparation par fichier qui permet à deux développeurs de travailler sur des fonctionnalités distinctes sans se marcher dessus dans le même fichier.
Le signal qui doit alerter avant que ça n’arrive
Il n’est pas nécessaire d’attendre qu’un deuxième développeur rejoigne le projet pour agir. Un fichier qui dépasse environ mille lignes mérite déjà d’être examiné : à ce stade, il est encore facile de repérer les frontières naturelles entre fonctionnalités, avant qu’elles ne deviennent trop enchevêtrées pour être séparées sans risque de régression.
- Surveiller la taille des fichiers avec un simple
wc -l inc/*.phplors des revues périodiques. - Découper dès qu’une frontière fonctionnelle claire apparaît, sans attendre qu’elle devienne difficile à identifier.
- Éviter l’excès inverse : découper à outrance une petite extension de quelques centaines de lignes n’apporte souvent aucun bénéfice réel.
La bonne taille de fichier n’est pas une valeur absolue à respecter partout : c’est le point où deux développeurs peuvent encore travailler côte à côte sans se gêner en permanence.
En résumé
Un fichier unique n’est pas un mauvais choix en soi pour un développeur solo sur un petit projet. Il devient un problème structurel dès que le projet grandit, en taille de code ou en nombre de personnes qui y contribuent. Une découpe minimale, par domaine fonctionnel plutôt que par couche technique, suffit généralement à éviter la spirale des conflits de fusion sans nécessiter une refonte complète de l’architecture.
