Migration CodeIgniter → Symfony ou Laravel — Sortez votre Application PHP du Legacy

#CodeIgniter 2/3 en 2026 — Pourquoi Migrer Maintenant

CodeIgniter a été l'un des frameworks PHP les plus populaires entre 2006 et 2014. Léger, rapide à prendre en main, avec une documentation claire — il a permis à des milliers de développeurs PHP de structurer leurs applications au-delà du PHP procédural. Mais en 2026, les applications CodeIgniter 2 et 3 encore en production sont des héritages d'une époque révolue du développement PHP.

#Statut de maintenance — Résumé factuel

CodeIgniter 2 : dernière release 2.2.6 en octobre 2015. Plus aucune maintenance depuis. Le dépôt GitHub est archivé. CodeIgniter 3 : dernière release 3.1.13 en mars 2022. Mode maintenance minimale — corrections de sécurité critiques uniquement, sans engagement de calendrier. Pas de développement fonctionnel. PHP 8.1+ introduit des incompatibilités avec CI3 que la communauté corrige au cas par cas mais sans release officielle. CodeIgniter 4 : framework actif mais réécriture complète (namespaces PSR-4, architecture MVC revisitée, nouveau ORM, nouveau CLI). Aucune compatibilité ascendante avec CI2/CI3 — la migration vers CI4 est un projet de réécriture au même titre qu'une migration vers Symfony ou Laravel.

#Problèmes techniques concrets des applications CodeIgniter 2/3

Pas d'injection de dépendances. Les contrôleurs et modèles CodeIgniter chargent leurs dépendances via $this->load->model('user_model') et $this->load->library('email'). Ce pattern rend les classes non testables unitairement (impossible de mocker les dépendances sans hacks), crée des couplages forts entre couches, et empêche toute architecture hexagonale ou Domain-Driven Design.

Pas d'ORM avec migrations. L'Active Record de CodeIgniter est un query builder basique — pas un ORM. Il ne gère ni les relations (hasMany, belongsTo), ni le lazy/eager loading, ni les migrations de schéma versionnées. Les modifications de base de données sont appliquées manuellement (scripts SQL, phpMyAdmin) sans traçabilité ni rollback.

Sécurité implémentée manuellement. Les mécanismes de sécurité (protection CSRF, échappement XSS, validation d'input, gestion des sessions, hashing des mots de passe) sont implémentés via des helpers CodeIgniter ou du code custom. Chaque implémentation est un risque de faille si le développeur oublie un cas ou fait une erreur.

Autoloading pré-PSR-4. Les classes CodeIgniter 2/3 ne suivent pas les standards PSR-4 — l'autoloading est géré par le framework via ses propres conventions de nommage. Conséquence : impossible d'utiliser des packages Composer modernes sans adaptateurs, incompatibilité avec les outils d'analyse statique (PHPStan, Psalm) sans configuration lourde.

PHP 8.x incompatibilités. CodeIgniter 2 ne fonctionne pas sur PHP 8.x (erreurs fatales sur les constructeurs de classe). CodeIgniter 3 fonctionne sur PHP 8.0 et 8.1 avec des warnings, mais les versions PHP 8.2+ cassent des fonctionnalités (propriétés dynamiques dépréciées, paramètres null implicites supprimés). Rester sur PHP 7.4 ou 8.0 pour faire tourner CodeIgniter bloque l'accès aux améliorations de performance et de sécurité de PHP 8.3 et 8.4.

#Symfony 7 ou Laravel 11 — Critères de Choix Objectifs

La question 'Symfony ou Laravel ?' revient systématiquement dans nos discussions avec les DSI qui migrent depuis CodeIgniter. Voici les critères objectifs que nous utilisons chez Nehos pour recommander l'un ou l'autre.

#Quand choisir Symfony 7

Symfony est recommandé quand l'application a une logique métier complexe avec des workflows (machine à états, processus d'approbation multi-étapes), quand l'architecture doit être explicite et strictement typée (Domain-Driven Design, CQRS, Event Sourcing), quand les intégrations sont lourdes et variées (bus de messages RabbitMQ/Amazon SQS, connecteurs ERP custom, APIs SOAP legacy), quand l'équipe interne valorise la rigueur architecturale et la séparation des responsabilités. Symfony impose une discipline architecturale : injection de dépendances explicite, autowiring configurable, service container strict, events/listeners/subscribers clairement séparés. Cette rigueur a un coût d'apprentissage initial mais produit des applications plus maintenables à long terme pour les équipes de 5 développeurs et plus.

Stack technique type migration CI → Symfony 7 : Symfony 7 + Doctrine ORM + API Platform (si API REST/GraphQL) + Symfony Messenger (bus de messages) + Twig (templates) ou découplage frontend Next.js. Tests : PHPUnit + Symfony Profiler + PHPStan niveau 8.

#Quand choisir Laravel 11

Laravel est recommandé quand l'application est principalement CRUD (création, lecture, mise à jour, suppression d'entités), quand la vélocité de développement est prioritaire (startup, MVP, itérations rapides), quand l'équipe est junior ou mid-level (Laravel est plus accessible), quand l'application est un SaaS B2B standard (multi-tenant, facturation, dashboard). Laravel offre un écosystème intégré : Eloquent ORM (Active Record évolué), Blade templates, Laravel Sanctum (authentification API), Laravel Horizon (monitoring Redis queues), Laravel Forge/Vapor (déploiement). La convention prime sur la configuration — les développeurs sont productifs rapidement.

Stack technique type migration CI → Laravel 11 : Laravel 11 + Eloquent ORM + Laravel API Resources + Laravel Horizon + Blade ou Inertia.js (React/Vue). Tests : Pest PHP + Laravel Dusk (E2E) + PHPStan.

#Stratégie de Migration Progressive — Le Strangler Fig Pattern

La migration CodeIgniter → Symfony ou Laravel ne se fait pas en big bang. On utilise le Strangler Fig Pattern (nommé d'après les figuiers étrangleurs qui poussent autour d'un arbre hôte jusqu'à le remplacer). Le principe : la nouvelle application Symfony/Laravel coexiste avec l'ancienne CodeIgniter, un reverse proxy route le trafic vers l'une ou l'autre selon la route, et on migre module par module jusqu'à décommissionner complètement CodeIgniter.

#Architecture de coexistence

Concrètement, un reverse proxy nginx se place devant les deux applications. La configuration nginx route les URLs migrées vers l'application Symfony/Laravel (nouvelle stack) et les URLs non encore migrées vers l'application CodeIgniter (legacy). Les sessions utilisateur sont partagées via un store externe (Redis) pour que les utilisateurs ne soient pas déconnectés en passant d'une route migrée à une route non migrée. La base de données est partagée — les deux applications lisent et écrivent dans le même schéma, ce qui impose de synchroniser les migrations de schéma.

Cette coexistence permet de migrer module par module en production, avec validation métier à chaque sprint, sans jamais interrompre le service. Les utilisateurs ne voient pas la transition — chaque URL fonctionne, que ce soit CodeIgniter ou Symfony/Laravel qui la serve.

#Ordre de migration recommandé

Nous migrons en commençant par les modules les plus autonomes et les moins couplés au reste de l'application. En pratique : (1) les modules utilitaires (authentification, profil utilisateur, paramètres) qui sont isolés et servent de base à tout le reste, (2) les modules CRUD simples (gestion de listes, annuaires, référentiels) qui permettent de valider la stack technique sans risque métier, (3) les modules à forte valeur métier (commandes, facturation, workflows) qui justifient le plus la migration mais sont aussi les plus complexes, (4) les modules d'intégration (connecteurs ERP, imports/exports) en dernier car ils dépendent souvent des modules métier.

#Migration de la Couche Données — Active Record → Doctrine/Eloquent

Le passage de l'Active Record CodeIgniter à un ORM mature (Doctrine pour Symfony, Eloquent pour Laravel) est l'un des gains architecturaux les plus significatifs de la migration.

Avec Doctrine (Symfony) : les entités sont des classes PHP pures (POPO) avec des annotations/attributs de mapping. Les relations sont typées (OneToMany, ManyToMany). Les migrations de schéma sont générées automatiquement par Doctrine Migrations (diff entre l'état des entités et l'état de la base). Le Repository Pattern sépare la logique de requêtes de la logique métier. Le DQL (Doctrine Query Language) ou le QueryBuilder offrent des requêtes complexes typées.

Avec Eloquent (Laravel) : les modèles sont des classes qui étendent Eloquent Model. Les relations sont déclarées comme méthodes. Les migrations sont scriptées dans des fichiers PHP versionnés (artisan make:migration). Les scopes, accessors, et mutators permettent d'encapsuler la logique de requête. Le seeding et les factories facilitent la création de données de test.

Dans les deux cas, le gain par rapport à l'Active Record CodeIgniter est massif : relations gérées proprement, migrations de schéma versionnées et rejouables, requêtes sûres (plus de SQL injection via concaténation de chaînes), testabilité (mocking du repository ou du modèle dans les tests unitaires).

#Migration de la Sécurité — Helpers Manuels → Composants Standardisés

La sécurité est le domaine où les applications CodeIgniter legacy présentent le plus de risques. Chaque application CodeIgniter implémente la sécurité différemment, avec plus ou moins de rigueur.

Authentification : CodeIgniter n'a pas de système d'authentification intégré. Les applications CI utilisent des librairies tierces (Ion Auth, Community Auth) ou du code maison. La migration vers Symfony Security (voters, firewalls, providers) ou Laravel Sanctum/Fortify apporte un système d'authentification standardisé, audité par la communauté, avec gestion native des tokens API, du 2FA, et du rate limiting.

Protection CSRF : les helpers CSRF de CodeIgniter sont basiques et souvent contournés par les développeurs pressés. Symfony et Laravel intègrent la protection CSRF nativement dans les formulaires — elle est active par défaut, pas en option.

Validation d'input : les règles de validation CodeIgniter ($this->form_validation->set_rules()) sont fonctionnelles mais limitées. Symfony Validator (avec annotations/attributs sur les DTO) et Laravel Validation (Form Requests) offrent une validation déclarative, typée, et réutilisable.

Gestion des sessions : les sessions CodeIgniter stockées en fichier ou en cookie sont fragiles en environnement scalé. La migration vers Redis sessions (natif Symfony et Laravel) apporte la scalabilité horizontale et la persistance fiable.

#Tests — De 0 % à 70 %+ de Couverture

La majorité des applications CodeIgniter legacy ont une couverture de tests proche de 0 %. Le framework CodeIgniter 2/3 ne facilite pas les tests unitaires (pas d'injection de dépendances, couplage fort aux classes framework). La migration est l'occasion de construire une couverture de tests solide.

Stratégie Nehos en 4 couches. Couche 1 — Tests E2E (Playwright ou Cypress) : instrumenter l'application CodeIgniter existante pour capturer les parcours critiques. Ces tests servent de filet de non-régression pendant toute la migration. Couche 2 — Tests d'intégration (PHPUnit avec base de données de test) : pour chaque module migré, valider que les endpoints HTTP retournent les bonnes réponses avec les bonnes données. Couche 3 — Tests unitaires (PHPUnit ou Pest) : pour la logique métier pure (services, value objects, calculateurs). Le typage strict de Symfony/Laravel rend ces tests plus faciles à écrire et plus fiables. Couche 4 — Analyse statique (PHPStan niveau 6 minimum, puis montée progressive vers niveau 8) : détection des bugs potentiels sans exécution du code. PHPStan détecte les types incompatibles, les null non gérés, les appels de méthodes sur des types ambigus — des bugs que l'absence de typage dans CodeIgniter masquait.

#Méthodologie Nehos — Phases et Calendrier

Phase 0 — Audit application CodeIgniter (5 à 8 jours, à partir de 864 € HT déductibles). Inventaire des modules (controllers, models, libraries, helpers). Cartographie des dépendances et des couplages entre modules. Analyse de la base de données (schéma, procédures stockées, triggers). Mesure de la complexité cyclomatique (via PHP Mess Detector). Identification des failles de sécurité évidentes. Recommandation Symfony vs Laravel argumentée. Output : plan de migration module par module avec estimation T-shirt.

Phase 1 — Socle Symfony/Laravel (2 à 3 semaines). Initialisation du projet cible (Symfony 7 ou Laravel 11). Configuration CI/CD (GitHub Actions : lint, PHPStan, tests PHPUnit/Pest, build). Mise en place du reverse proxy nginx pour la coexistence CI + Symfony/Laravel. Configuration Redis sessions partagées. Premiers tests E2E Playwright sur l'application CodeIgniter existante.

Phase 2 — Migration module par module (8 à 20 semaines selon complexité). Sprints de 2 semaines. Chaque sprint migre 1 à 2 modules. Chaque module migré est couvert par des tests d'intégration et unitaires avant merge. Routing nginx mis à jour à chaque sprint pour router les nouvelles routes vers Symfony/Laravel. PHPStan niveau progressif (commence à 4, monte vers 8 au fil de la migration).

Phase 3 — Bascule finale et décommission CodeIgniter (1 à 2 semaines). 100 % des routes servies par Symfony/Laravel. Suppression du reverse proxy de coexistence. Suppression du code CodeIgniter. Tests de charge. Documentation technique et formation équipe.

#ROI — Cas Application Métier B2B CodeIgniter → Symfony

Cas client de référence : ETI logistique, application métier CodeIgniter 3 de gestion des expéditions (45 000 lignes), en production depuis 2013, 180 utilisateurs internes. Enjeux initiaux : bugs fréquents en production (pas de tests, pas de typage), temps de développement d'une nouvelle fonctionnalité multiplié par 3 à cause de la dette technique, PHP 7.2 bloqué (incompatible PHP 8.x), failles XSS identifiées lors d'un pentest, impossibilité d'exposer une API REST propre pour le nouveau TMS.

Mission Nehos : migration vers Symfony 7 en 6 mois (Strangler Fig Pattern). Audit Phase 0 (6 jours). Socle Symfony + reverse proxy (2 semaines). Migration 14 modules en 10 sprints de 2 semaines. Bascule finale (1 semaine). Investissement total : à partir de 48 k€ HT. Résultats à 3 mois post-bascule : bugs production réduits de 72 % (couverture tests 68 %), vélocité développement nouvelles fonctionnalités +55 %, PHP 8.3 en production (gains performance 15-20 %), 0 faille XSS (Symfony Security + validation DTO), API REST exposée via API Platform pour le TMS en 2 semaines (vs estimation 2 mois sur CodeIgniter).

#Tarification — 1,5 k€ HT

Trois fourchettes selon la complexité de l'application CodeIgniter.

Application CI simple (20 000 à 40 000 lignes, CRUD standard, peu d'intégrations) : 1,5 k€ HT sur 3 à 4 mois.

Application CI intermédiaire (40 000 à 70 000 lignes, logique métier significative, intégrations ERP ou API tierces) : 8,5 k€ HT sur 4 à 6 mois.

Application CI complexe (70 000+ lignes, multi-tenant, workflows métier complexes, intégrations lourdes) : 50 à 111 k€ HT sur 6 à 8 mois.

Tous les tarifs incluent l'audit initial Phase 0. Estimation précise en 30 minutes via RDV : Calendly migration CodeIgniter.