Frameworks Backend

Vous savez écrire du PHP. Vous savez interroger une base, traiter un formulaire, échapper une sortie. Un framework ne vous apprend rien de tout cela : il vous évite de le réécrire, et surtout de l’oublier.

Ce qu’il apporte

Ce qu’il coûte

Une dépendance, une courbe d’apprentissage, et des fichiers. Beaucoup de fichiers. Mesurés le 16 août 2026, pour un projet réduit à la même chose dans les trois — une route, un contrôleur, un ORM, un gabarit :

ci4          27M   33 paquets   2767 fichiers PHP
symfony      28M   54 paquets   3545 fichiers PHP
laravel      86M  109 paquets   8023 fichiers PHP

Ils font le même métier et ne se ressemblent pas. Versions relevées le 16 août 2026, à la source — chacune installée pour cette page.

php bin/console --version    # Symfony
php artisan --version        # Laravel
php spark --version          # CodeIgniter

Symfony v8.1.4 (env: dev, debug: true)
Laravel Framework 13.25.0
CodeIgniter v4.7.4

Symfony

Une collection de composants indépendants, et un squelette qui n’impose presque rien. On ajoute ce dont on a besoin — l’ORM, les gabarits — et rien d’autre. C’est le plus explicite des trois : tout se configure, donc tout se lit. Beaucoup d’autres projets s’appuient sur ses composants, Laravel compris.

Laravel

Le plus fourni. L’ORM, les gabarits, l’authentification, les files d’attente, les tests : tout est là au premier jour, avec une syntaxe qui cherche l’agrément. C’est aussi le plus opiniâtre — il propose une façon de faire, et s’en écarter demande un effort.

CodeIgniter 4

Le plus léger et le plus proche du PHP nu. Peu de magie, peu de conventions imposées, une prise en main courte. C’est le framework de ce site — et la section suivante en montre le code.

La page que vous lisez est servie par un framework. Voici ses pièces, telles qu’elles sont sur le disque — pas un exemple, le code réel.

La route

<?php
// app/Config/Routes.php
$routes->get('/composer', 'Php\ComposerCours::index');
$routes->get('/wordpress', 'Cms\WordpressCours::index');
$routes->get('/ci4-gestion-contenu', 'Cms\Ci4GestionContenu::index');

Le contrôleur

<?php
// app/Controllers/Php/ComposerCours.php
namespace App\Controllers\Php;

class ComposerCours extends \App\Controllers\BaseController
{
    public function index()
    {
        return view('templates/php/composer');
    }
}

Une route nomme une classe et une méthode ; la méthode rend une vue. C’est tout ce qui sépare une adresse d’une page — et c’est le même principe dans les trois frameworks, aux conventions près.

Une même question — « quelle classe répond à /articles ? » — et trois réponses de forme différente.

Symfony : l’attribut, sur la méthode

<?php
// src/Controller/ArticleController.php
#[Route('/articles', name: 'article_index')]
public function index(ArticleRepository $articles): Response
{
    return $this->render('article/index.html.twig', [
        'articles' => $articles->findPublished(),
    ]);
}

La route vit AVEC le code qu’elle appelle. Rien à tenir à jour ailleurs, et rien à ouvrir pour savoir quelle adresse mène ici — mais aucune vue d’ensemble non plus, sauf à demander la liste à la console.

Laravel : le fichier de routes

<?php
// routes/web.php
use App\Http\Controllers\ArticleController;

Route::get('/articles', [ArticleController::class, 'index']);

CodeIgniter : le fichier de routes, lui aussi

<?php
// app/Config/Routes.php
$routes->get('/articles', 'Articles::index');

C’est ici que la différence de philosophie se voit le mieux : comment le contrôleur obtient-il ce dont il a besoin ?

Symfony : on le lui donne

<?php
public function index(ArticleRepository $articles): Response
{
    return $this->render('article/index.html.twig', [
        'articles' => $articles->findPublished(),
    ]);
}

Le dépôt arrive en paramètre. Le contrôleur ne sait pas le construire, et n’a pas à le savoir : le conteneur de services s’en charge, en lisant le TYPE déclaré. C’est l’injection de dépendances, et c’est ce qui rend la classe testable sans base de données.

Laravel : il va le chercher

<?php
public function index()
{
    return view('articles.index', [
        'articles' => Article::published()->get(),
    ]);
}

Article::published() ne ressemble pas à une méthode statique par hasard : ce n’en est pas une. Laravel intercepte l’appel et le relaie à une instance. C’est court à écrire, et c’est un pas de plus entre ce qu’on lit et ce qui s’exécute.

CodeIgniter : il le construit

<?php
public function index()
{
    return view('articles/index', [
        'articles' => (new ArticleModel())->getPublishedArticles(),
    ]);
}

Le plus simple à lire : on voit exactement ce qui se passe. Et le plus difficile à tester isolément, puisque le contrôleur décide lui-même de ce qu’il utilise.

Un ORM fait correspondre des lignes de base à des objets PHP. Il y a deux façons de s’y prendre, et les trois frameworks se répartissent entre elles.

Active record : l’objet SAIT s’enregistrer

L’objet porte à la fois les données et l’accès à la base. C’est l’école de Laravel (Eloquent) et de CodeIgniter.

<?php
// Laravel — app/Models/Article.php
class Article extends Model
{
    protected $fillable = ['title', 'slug', 'content', 'status', 'published_at'];

    public function scopePublished($query)
    {
        return $query->where('status', 'published')
                     ->orderByDesc('published_at');
    }
}

<?php
// CodeIgniter — app/Models/ArticleModel.php
class ArticleModel extends Model
{
    protected $table = 'articles';
    protected $allowedFields = ['title', 'slug', 'content', 'status', 'published_at'];

    public function getPublishedArticles()
    {
        return $this->where('status', 'published')
                    ->orderBy('published_at', 'DESC')
                    ->findAll();
    }
}

Data mapper : un objet, et quelqu’un pour l’enregistrer

L’entité ne connaît pas la base. Une autre classe — le dépôt — sait l’aller chercher, et un gestionnaire sait l’écrire. C’est l’école de Doctrine, l’ORM de Symfony.

<?php
// src/Entity/Article.php — l'entité ne parle JAMAIS à la base
#[ORM\Entity(repositoryClass: ArticleRepository::class)]
class Article
{
    #[ORM\Column(length: 255)]
    private string $title;

    public function getTitle(): string { return $this->title; }
    public function setTitle(string $t): static { $this->title = $t; return $this; }
}

<?php
// src/Repository/ArticleRepository.php — lui seul interroge
public function findPublished(): array
{
    return $this->createQueryBuilder('a')
        ->andWhere('a.status = :statut')
        ->setParameter('statut', 'published')
        ->orderBy('a.publishedAt', 'DESC')
        ->getQuery()
        ->getResult();
}

La même sortie, dans les trois

Voici la preuve que ces trois écritures font bien la même chose. Le jeu d’essai est identique — trois articles publiés — et la commande demande les articles publiés, du plus récent au plus ancien.

php bin/console app:peupler   # Symfony
php artisan tinker            # Laravel
php spark app:peupler         # CodeIgniter

3 article(s)
  - Premier article (premier-article)
  - Deuxième article (deuxieme-article)
  - Troisième article (troisieme-article)

Trois fois la même sortie, à la ligne près. C’est ce que « faire le même métier » veut dire.

La boucle d’affichage, dans les trois moteurs. Chacune produit exactement les mêmes lignes.

Twig — Symfony

{% for article in articles %}
    - {{ article.title }} ({{ article.slug }})
{% endfor %}

Blade — Laravel

@foreach ($articles as $article)
    - {{ $article->title }} ({{ $article->slug }})
@endforeach

PHP — CodeIgniter

<?php foreach ($articles as $article): ?>
    - <?= esc($article['title']) ?> (<?= esc($article['slug']) ?>)
<?php endforeach ?>

C’est le meilleur argument des moteurs dédiés : ils rendent le geste sûr par défaut, et le geste dangereux visible.

Aucun de ces trois frameworks n’est meilleur que les autres. Ils répondent à des contraintes, et la bonne question n’est jamais « lequel est le meilleur ? » mais « lequel pour CE projet, avec CETTE équipe ? ».

La grille

Ce qui ne doit pas décider

• La popularité seule : elle mesure une communauté, pas l’adéquation à votre problème.
• Un banc d’essai de performance : la différence entre les trois est négligeable devant une requête SQL mal écrite.
• La mode : les trois seront là dans cinq ans.

Aller plus loin

Le site propose un cours complet sur CodeIgniter 4 — modèle, migration, contrôleurs, CRUD et gabarits, jusqu’au projet d’un blog. C’est la suite naturelle de cette page.

• 🏗️ CodeIgniter 4 — gestion de contenu
• 📦 Composer