Jusqu’au Forum PHP 2026, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

ORM : Puissance, pièges et bonnes pratiques pour une couche données maîtrisée Les ORM (Object-Relational Mapping) sont devenus des outils incontournables pour les développeurs, qu’il s’agisse d’Active Record dans Laravel ou de Data Mapper avec Doctrine. Pourtant, leur utilisation soulève souvent des critiques : requêtes SQL inefficaces, le redoutable problème N+1, ou encore cette impression que l’abstraction éloigne les développeurs de la maîtrise réelle de leur base de données. Et si ces écueils n’étaient pas une fatalité ? Apprenons comment concilier la productivité offerte par les ORM avec la rigueur nécessaire pour éviter leurs pièges. Nous verrons comment optimiser la conception des modèles pour des requêtes performantes, centraliser la logique métier afin de simplifier la maintenance, et allier ORM et SQL natif — via des vues ou des requêtes personnalisées — pour profiter du meilleur des deux approches. Enfin, l’adoption de patterns reconnus, comme Repository ou Query Objects, permet de construire une couche de gestion des données à la fois robuste, évolutive et séparée du reste de l’application. L’objectif ? Vous donner les clés pour concevoir une architecture où la gestion des données devient un atout, et non plus un point de friction.

Joan Clarke - HJK 08/10/2026 14:35-15:15

Ton sujet portera sur les ORM. Pour des applications professionnelles en PHP, Doctrine est-elle, à ton avis, la seule alternative en termes d'ORM ?

Non, Doctrine n’est pas la seule alternative. Pour moi, c’est l’un des ORM les plus matures pour les projets exigeants en terme de scalabilité, de complexité métier ou d’intégration avec des bases de données relationnelles avancées (héritage, associations complexes, etc.). Son écosystème (DQL, migrations, cache, etc.) et son adoption large dans la communauté Symfony en font un choix sûr pour des applications professionnelles.

Il existe aussi d’autres solutions, chacune avec ses forces : Eloquent (Laravel) : Très intuitif et intégré nativement à Laravel, idéal pour des projets où la simplicité et la rapidité de développement sont prioritaires. Son approche Active Record le rend accessible, mais il peut montrer ses limites sur des architectures très découplées ou des requêtes complexes. Cycle ORM : C'est une alternative moderne, performante et flexible, qui se distingue par sa légèreté et son support des patterns Data Mapper et Active Record. Atlas ORM : Moins connu, mais très intéressant pour celles et ceux qui veulent un contrôle fin sur les requêtes SQL tout en gardant une couche d’abstraction légère. Propel : Un ORM historique, toujours maintenu, qui génère des classes à partir du schéma de la base de données, ce qui peut être un atout pour certains workflows.

Mais le "meilleur" ORM dépend toujours du contexte : taille de l’équipe, héritage de la base de code, complexité du projet, besoins en performance et préférences architecturales.

As-tu déjà migré un projet d'un ORM à un autre ?

Non, je n’ai pas encore eu l’occasion de migrer un projet d’un ORM à un autre. En revanche, je travaille régulièrement sur des projets utilisant Eloquent (Laravel) et d’autres utilisant Doctrine, ce qui me permet de comparer leurs forces et leurs limites en situation réelle.

Avec Eloquent, sa simplicité et son intégration native avec Laravel permettent d’accélérer le développement. Son approche Active Record est intuitive, mais elle est complexe à intégrer dans une modélisation objet plus poussée (intégration de repository, typage plus fort des entités). Je trouve aussi qu'avec Eloquent, il est plus facile d'éparpiller les requêtes dans la base de code, mais ça reste possible de forcer une approche en review et à l'usage.

J'utilise Doctrine sur des projets où la robustesse et la scalabilité sont critiques. Son approche Data Mapper permet une meilleure séparation des responsabilités et son Query Builder offre un contrôle fin sur les requêtes SQL générées. En revanche, sa courbe d’apprentissage est plus forte et la maîtrise des concepts avancés est plus complexe.

Travailler avec ces deux ORM m’a permis de comprendre les cas d’usage idéaux pour les patterns latents :

• Active Record est parfait pour des projets agiles, où la rapidité de développement et la simplicité priment.
• Data Mapper est plus adapté aux applications complexes, où la performance, la maintenabilité et la séparation des couches sont essentielles.

Si une migration s’imposait, je m’appuierais sur cette expérience pour identifier les points critiques (ex : adaptation des requêtes, refactorisation des modèles) et anticiper les défis, comme la montée en compétences de l’équipe ou les tests de non-régression.

Est-ce que selon toi l'usage d'un ORM diminue à mesure que la compétence augmente en SQL ou cet outil reste toujours légitime ?

La compétence en SQL et l’usage d’un ORM ne sont pas opposés, mais complémentaires. Un ORM ne remplace pas SQL, il l’abstrait. Si je n'ai pas une bonne vision de SQL, je ne pourrais pas utiliser correctement l'ORM. Selon moi, même avec une maîtrise avancée de SQL, un ORM reste légitime pour : Gagner en productivité : Éviter de réécrire des requêtes CRUD basiques, gérer les mappings entre objets et tables, ou encore automatiser les migrations de schéma ; Outiller : Des outils comme EasyAdmin dans l'écosystème Symfony s'appuient sur l'ORM pour proposer des solutions simples et efficaces de génération d'admin par exemple ; Maintenir une cohérence : Les ORM imposent une structure claire (ex : entités, relations) qui facilite la collaboration en équipe et réduit les risques d’incohérences dans le code ; Sécurité : Ils protègent contre certaines vulnérabilités (ex : injections SQL) en imposant des mécanismes comme les prepared statements.

En parallèle, une bonne maîtrise de SQL reste importante pour :

• Pour optimiser les requêtes : Un ORM peut générer du SQL inefficace (ex : jointures inutiles, problèmes N+1). Savoir analyser et réécrire manuellement les requêtes critiques est crucial ;
• Pour les cas complexes : Certaines opérations (requêtes analytiques, optimisations fines) sont plus simples à écrire directement en SQL ;
• Pour déboguer : Comprendre le SQL généré par l’ORM est primordial pour utiliser les outils comme les profilers qui affichent les requêtes générées.

L'intérêt de mixer les approches est surtout de pouvoir gagner en efficacité. En principe je préfère utiliser l’ORM pour 80% du code (CRUD, relations simples, etc.) et ensuite basculer en SQL natif pour les 20% restants (requêtes complexes, optimisations). Toute la gestion des migrations de schéma est aussi grandement fiabilisée par l'utilisation d'un ORM. Je pense qu'il est vraiment important de former les équipes à la fois sur l’ORM et sur SQL, pour qu’elles sachent quand et comment sortir de l’abstraction.

Au final, plus on maîtrise SQL, mieux on utilise son ORM et mieux on connaît ses limites !

Une conférence présentée par

Stéphane HULARD

Passionné par le web depuis 2006, Sthépane a évolué au cœur de son écosystème, entre innovation et pragmatisme. Après 10 ans en tant que consultant et formateur indépendant, il a lancé CH Studio en 2021 pour accompagner les entreprises dans la réalisation de leurs projets logiciels web, avec une approche centrée sur l’humain et la qualité technique. Son terrain de prédilection ? Les projets legacy : il aime aider les équipes à les apprivoiser, les moderniser et en reprendre le contrôle. Convaincu que la rigueur et l’agilité peuvent coexister, il s’attache à implanter des bonnes pratiques d’ingénierie logicielle sur le web : - Intégration et déploiement continu (CI/CD) - Tests unitaires et fonctionnels - Documentation claire et maintenable Engagé dans l’open source et la communauté PHP, il contribue à des projets et partage ses retours d’expérience pour faire avancer les pratiques et les outils du langage. Adepte du 100 % télétravail, son équipe profite de cette flexibilité, un atout pour allier productivité et ouverture d’esprit.

Autres interviews

• La parole est aux speakers : François Zaninotto
• La parole est aux speakers : Amaury Bouchard
• La parole est aux speakers : Rachel Foucard
• La parole est aux speakers : Jennifer Boï
• La parole est aux speakers : Mathias Arlaud
• La parole est aux speakers : Gaël CRISPYN
• La parole est aux speakers : Antoine Bluchet
• La parole est aux speakers : Guillaume Lours
• La parole est aux speakers : Kévin Martins
• La parole est aux speakers : Pierre Tondereau
• La parole est aux speakers : Kévin Dunglas
• La parole est aux speakers : Jori STEIN
• La parole est aux speakers : Thomas Dutrion
• La parole est aux speakers : Charlotte Chaumet
• La parole est aux speakers : Benjamin Eberlei
• La parole est aux speakers : Alexandre Daubois
• La parole est aux speakers : Michaël Benhaïm
• La parole est aux speakers : Sebastian Bergmann
• La parole est aux speakers : Yoann Blot
• La parole est aux speakers : Niels Ackermann
• La parole est aux speakers : Jean-François Lépine