Boxi

Le besoin

Boxi est l’ERP d’Atout-Box, acteur du self-stockage : devis, contrats, facturation, encaissements, contrôle d’accès aux sites. L’entreprise grandit vite — plus de sites, plus de clients, plus d’utilisateurs. Or Boxi est un monolithe PHP de plusieurs centaines de milliers de lignes, en grande partie sans tests, avec une interface qui ne colle plus aux usages.

Le diagnostic

• Mesurer avant de décider. Inventaire chiffré de l’existant : plus de 1 000 fichiers et plus de 300 000 lignes de code historique, plusieurs bases de données, un frontend sans typage.
• Ne pas réécrire d’un coup. Une réécriture complète gèlerait le produit pendant des mois, pour une bascule finale à haut risque. Hors de question pour une entreprise qui doit continuer à vendre et à facturer.
• Garder les idées, pas le code. Une tentative de refonte antérieure divergeait trop pour être fusionnée : ses bons concepts sont repris, pas son implémentation.

La stratégie : strangler fig

Comme le figuier étrangleur qui pousse autour de son arbre hôte, le nouveau socle grandit autour de l’ancien jusqu’à le remplacer :

• Les deux systèmes cohabitent. Le nouveau socle tourne à côté du monolithe ; une couche d’aiguillage envoie chaque fonctionnalité vers l’un ou l’autre.
• Une bascule par module. Dès qu’un domaine est prêt, son trafic passe sur le nouveau code. Le reste continue de tourner sur l’ancien, sans interruption pour les utilisateurs.
• Un risque borné. Chaque bascule ne touche qu’un périmètre limité ; tant que l’ancien chemin existe, on peut y revenir.
• L’ancien code disparaît. Une fois le module stabilisé, le code historique correspondant est supprimé. Le monolithe rétrécit à chaque étape, jusqu’à disparaître.

Repenser, pas porter

Recopier l’existant dans un nouveau framework ne ferait que déplacer la dette. Chaque module suit le même cycle :

1. Inventaire de l’existant : écrans, règles, données, tâches planifiées.
2. Tests qui fixent ce que le métier attend : montants, états, droits.
3. Document de conception : modèle de domaine, invariants, droits, volumes, parcours revus avec les utilisateurs.
4. Revue par le lead dev et un référent métier. Aucun code n’est écrit avant.
5. Implémentation par l’IA, en petites étapes relues.
6. Reprise des données, bascule, puis suppression de l’ancien code.

Un module pilote, sans risque métier, valide toute la chaîne avant d’attaquer les domaines sensibles.

Choix d’architecture

• Un module par domaine métier — clients, catalogue, ventes, facturation, encaissements, contrôle d’accès… Les modules ne se parlent que par des contrats publics et des événements, et ces frontières sont vérifiées automatiquement.
• Conçu pour la croissance. Chaque donnée est rattachée à une société et à un site ; les traitements longs passent en file d’attente ; le reporting s’appuie sur des agrégats ; la concurrence et les rejeux sont traités explicitement (attribution d’un box, numérotation des factures, notifications de paiement).

L’IA dans un cadre

Le code est produit par des agents IA, quel que soit l’outil : règles, procédures et garde-fous vivent dans le dépôt, dans des formats standard. Une règle qui peut devenir un test le devient — le test vaut pour tous les modèles, le texte non. Chaque changement est relu par un autre modèle puis par un humain, et chaque évolution reste traçable, du ticket à la version livrée.