Rasmus Lerdorf : PHP et la démocratisation du Web dynamique

Rasmus Lerdorf ne commence pas PHP avec l’ambition de créer un grand langage généraliste. En 1994, il veut savoir qui consulte son CV en ligne, réutiliser des fragments de page et traiter plus facilement les formulaires du Web naissant. Il écrit pour cela quelques programmes en C exécutés par le serveur.

Ces outils répondent à un besoin que rencontrent bientôt des milliers de créateurs : produire une page différente selon une requête, enregistrer une saisie ou interroger une base de données sans construire toute une infrastructure en C ou multiplier les scripts Perl séparés.

PHP devient influent précisément parce qu’il réduit cette distance entre une page HTML et son comportement. Son histoire montre cependant qu’un outil personnel ne devient une plateforme mondiale qu’en changeant d’échelle et d’auteurs. À partir de PHP 3, Andi Gutmans, Zeev Suraski et une vaste communauté réécrivent et étendent profondément le projet initial.

Du Groenland à l’ingénierie des systèmes

Rasmus Lerdorf naît en 1968 au Groenland dans une famille danoise. Il grandit ensuite au Danemark puis au Canada. Il étudie l’ingénierie de la conception de systèmes à l’université de Waterloo et obtient son diplôme en 1993.

Cette formation le place à l’intersection du logiciel, des réseaux et des besoins concrets des utilisateurs. Le World Wide Web est alors très jeune. Une page est le plus souvent un document HTML statique envoyé tel quel par un serveur. Pour répondre à un formulaire ou fabriquer un contenu personnalisé, il faut passer par la Common Gateway Interface, qui lance un programme externe et lui transmet les données de la requête.

CGI ouvre le Web à la programmation, mais son usage reste technique. Le développeur doit analyser les paramètres, produire les en-têtes HTTP, échapper le HTML et connecter lui-même ses outils aux fichiers ou bases de données. Une opération simple demande beaucoup de code périphérique.

Lerdorf s’intéresse moins à la création d’une nouvelle théorie des langages qu’à l’élimination de ce travail répétitif.

Personal Home Page Tools : mesurer et automatiser

En 1994, Lerdorf écrit en C une série de binaires CGI pour son site personnel. Ils enregistrent les visites de son CV en ligne et l’aident à réutiliser des éléments de page. Il les appelle Personal Home Page Tools, ou PHP Tools.

Le besoin s’élargit rapidement. Il ajoute un interpréteur de formulaires capable de récupérer les valeurs envoyées par un navigateur et de les insérer dans une réponse. Un créateur peut alors construire un livre d’or, afficher des données ou adapter une page sans écrire un programme CGI complet pour chaque action.

En juin 1995, Lerdorf publie le code source. Les utilisateurs peuvent installer les outils, corriger des bogues et demander des fonctions. Cette ouverture transforme un dispositif personnel en projet partagé.

Les premières versions portent plusieurs noms — PHP Tools, FI pour Forms Interpreter, puis Personal Home Page Construction Kit. Cette instabilité reflète l’évolution du projet : le suivi d’un site devient progressivement un langage de script incorporé au HTML.

Incorporer le programme dans la page

L’innovation pratique de PHP/FI consiste à placer des instructions dynamiques directement dans un document HTML. Le serveur interprète les zones concernées et envoie au navigateur le résultat final.

Le modèle réduit le nombre de fichiers et de conversions mentales nécessaires. Le développeur commence par une page ordinaire, puis ajoute une condition, une valeur issue d’un formulaire ou une requête de base de données à l’endroit précis où le résultat doit apparaître.

<h1>Bonjour <?= htmlspecialchars($name) ?></h1>

Dans un exemple moderne, la majeure partie du document peut rester du HTML. Le fragment PHP calcule seulement la valeur dynamique. Cette proximité rend le premier résultat très rapide à obtenir.

Elle crée aussi un risque architectural. Lorsque accès aux données, règles métier et présentation s’accumulent dans la même page, le projet devient difficile à tester et à modifier. Les frameworks adopteront plus tard des séparations plus nettes, mais le modèle embarqué reste précieux pour comprendre la réussite initiale : PHP rencontre le créateur de pages dans son fichier existant plutôt que de l’obliger à adopter immédiatement une architecture complète.

PHP/FI 2 : de la boîte à outils au langage

En 1996, Lerdorf réunit et réécrit ses outils sous le nom PHP/FI 2.0. L’ensemble possède désormais des variables, des fonctions définies par l’utilisateur, des conditions, des boucles, des cookies et des connexions intégrées à plusieurs bases de données.

La syntaxe s’inspire de C et de Perl afin de paraître familière à des programmeurs Unix. Les données des formulaires sont rendues directement accessibles, et les opérations courantes du Web disposent de fonctions prêtes à l’emploi.

PHP/FI est volontairement pratique, mais son architecture reste celle d’un projet développé en grande partie par une personne. À mesure que les utilisateurs construisent des applications plus ambitieuses, le parseur, les performances et la cohérence du langage atteignent leurs limites.

Lerdorf ne cherche pas à défendre chaque détail comme une œuvre intangible. Il accepte que le projet soit repris et réécrit lorsqu’une meilleure implantation apparaît. Cette disposition compte autant que le code initial dans la survie de PHP.

PHP 3 : la réécriture qui change l’échelle du projet

En 1997, les étudiants israéliens Andi Gutmans et Zeev Suraski utilisent PHP/FI pour une application de commerce électronique universitaire. Ils rencontrent des limitations et commencent à réécrire le parseur.

Ils contactent Lerdorf, puis les trois décident de collaborer sur un langage indépendant qui conserve la base d’utilisateurs et l’approche de PHP/FI. La nouvelle version reçoit une syntaxe plus cohérente, une architecture extensible, un support objet initial et des modules capables de relier de nombreuses bases, protocoles et API.

Le nom PHP demeure, mais sa signification devient l’acronyme récursif PHP: Hypertext Preprocessor. Il ne décrit plus un ensemble de pages personnelles ; il affirme un outil général de traitement côté serveur.

PHP 3.0 est publié officiellement en juin 1998 par une équipe de développement internationale. À ce stade, attribuer le langage entier à Lerdorf seul devient inexact. Il fournit le projet initial, la direction pragmatique et une part de la nouvelle conception ; Gutmans, Suraski et des dizaines de contributeurs construisent la plateforme extensible.

Le registre officiel des crédits PHP rend cette histoire visible en attribuant séparément moteur, API d’extensions, plateformes, pilotes et bibliothèques à leurs auteurs.

Le modèle de requête qui facilite le déploiement

PHP adopte historiquement un modèle adapté au Web classique : pour chaque requête, l’application charge son contexte, produit une réponse puis libère l’essentiel de son état. Les données durables résident dans une base, un fichier, un cache ou une session externe.

Ce cycle offre une forme de simplicité opérationnelle. Une variable oubliée ne reste généralement pas en mémoire pour contaminer la requête suivante. Le serveur peut répartir les requêtes entre plusieurs processus et remplacer un processus défaillant.

Le coût est la répétition du démarrage et du chargement. PHP compense par son intégration aux serveurs, ses caches d’opcodes et l’optimisation de son moteur. Le modèle fonctionne particulièrement bien pour des pages dont le calcul est court et indépendant.

Les architectures persistantes modernes — workers durables, WebSockets ou calculs asynchrones longs — demandent davantage de précautions. Des outils PHP les prennent en charge, mais ils s’éloignent du cycle sans état qui a façonné de nombreuses bibliothèques.

L’impact de Lerdorf vient en partie de cet alignement : au lieu d’imposer un modèle d’application général au Web, les premiers PHP épousent la structure concrète d’une requête HTTP et d’une page à produire.

Le Zend Engine et la transformation en plateforme

Après PHP 3, Gutmans et Suraski réécrivent encore le cœur pour améliorer performances et modularité. Leur moteur, nommé Zend à partir de leurs prénoms, devient la base de PHP 4 en 2000.

PHP 4 améliore la gestion des sessions, la mise en mémoire tampon de la sortie et l’intégration à différents serveurs. PHP 5, publié en 2004 avec Zend Engine II, renforce le modèle objet, les exceptions et les interfaces avec les bases de données.

Les versions ultérieures poursuivent l’évolution : espaces de noms, traits, générateurs, améliorations du typage, gains de performance de PHP 7, puis attributs, types union et compilation JIT dans PHP 8.

Lerdorf reste un contributeur, conférencier et représentant important, notamment sur les performances et la sécurité. Il n’est toutefois pas l’architecte unique de ces générations. La continuité du nom masque une succession de moteurs, d’équipes et de processus de décision.

Cette évolution collective confirme une idée essentielle du logiciel libre : le créateur peut donner l’impulsion sans devoir rester le goulot d’étranglement de chaque fonction future.

LAMP : une pile accessible pour publier une idée

PHP se diffuse avec Linux, le serveur Apache et les bases MySQL ou PostgreSQL. L’acronyme LAMP résume plus tard cette combinaison de logiciels libres ou largement disponibles.

La pile réduit les coûts d’entrée. Un hébergeur peut installer un serveur mutualisé et offrir à chaque client un répertoire où déposer des fichiers PHP. Le développeur n’a pas à administrer un processus applicatif permanent ni négocier un déploiement complexe.

Des systèmes de gestion de contenu comme WordPress, Drupal et Joomla, ainsi que des forums et boutiques, rendent cette accessibilité multiplicative. Un utilisateur peut installer une application PHP sans écrire lui-même le langage ; des développeurs créent ensuite thèmes et extensions.

Cette distribution par l’hébergement compte autant que les qualités syntaxiques. Un langage disponible par défaut, documenté par des exemples copiables et relié à une base courante gagne des utilisateurs qui n’auraient pas installé une plateforme séparée.

L’écosystème crée aussi un héritage immense. Les hébergeurs doivent maintenir plusieurs versions, les applications anciennes retardent certaines migrations et une faille dans un module populaire peut toucher de nombreux sites.

Une conception guidée par les cas réels

Lerdorf décrit volontiers PHP comme un outil construit pour résoudre des problèmes plutôt que comme un langage issu d’un grand plan. Cette démarche explique sa force : les fonctions apparaissent parce qu’un site doit décoder une requête, produire une image ou parler à une base.

Elle explique également l’irrégularité historique de l’API. Les noms de fonctions, l’ordre des arguments et les valeurs de retour ne suivent pas toujours une règle uniforme. Des bibliothèques ont été intégrées à différentes périodes par différents auteurs, souvent avec priorité à la compatibilité.

Un langage conçu d’abord sur papier aurait pu obtenir davantage de symétrie. Il aurait peut-être aussi manqué le moment où des millions de pages avaient besoin d’une solution immédiatement installable.

L’histoire de PHP n’oppose donc pas une bonne théorie à une mauvaise pratique. Elle montre un arbitrage : résoudre aujourd’hui le cas rencontré, puis payer plus tard le coût de normalisation et de compatibilité.

Les versions modernes ajoutent des API plus cohérentes et déprécient certains comportements, mais elles ne peuvent pas renommer librement tout ce que le Web utilise depuis vingt ans.

Sécurité : la facilité ne supprime pas les frontières de confiance

La rapidité avec laquelle PHP permet d’utiliser les paramètres d’une requête a parfois encouragé un mélange dangereux entre entrée utilisateur, requête SQL, chemin de fichier et commande système.

Les premières configurations ont aussi proposé des automatismes comme register_globals, qui transformait des paramètres HTTP en variables globales. Pratique pour un petit script, ce comportement rendait difficile l’identification de la provenance d’une valeur et a été supprimé des versions modernes.

Le problème général n’est pas qu’un langage web serait intrinsèquement incapable d’être sûr. Il vient de la confusion entre donnée et instruction. Les requêtes préparées, l’échappement selon le contexte, la validation, les mots de passe hachés et des permissions minimales permettent d’écrire des applications robustes.

PHP a progressivement amélioré ses valeurs par défaut, sa cryptographie, ses pilotes de base de données et ses diagnostics. Les frameworks modernes imposent davantage de structure. L’écosystème doit néanmoins entretenir d’innombrables applications anciennes dont le code précède ces pratiques.

Cette histoire rappelle une limite de la démocratisation : rendre une action facile doit s’accompagner d’une manière tout aussi facile de l’accomplir sûrement.

Des frameworks à la professionnalisation de l’écosystème

À mesure que les applications grandissent, les développeurs séparent routage, contrôleurs, modèles, vues et services. Des frameworks comme Symfony et Laravel fournissent des conventions, un conteneur de dépendances, des migrations et des protections communes.

Composer, lancé par la communauté au début des années 2010, organise les dépendances et permet aux bibliothèques de coopérer hors d’un framework unique. Les standards du PHP Framework Interop Group harmonisent chargement automatique, interfaces et style entre projets.

Ces outils ne renient pas le fichier PHP incorporé au HTML. Ils répondent à une autre échelle. Un formulaire personnel et une application entretenue par plusieurs équipes n’ont pas besoin du même niveau d’architecture.

Le parcours de PHP va ainsi de la réduction de la cérémonie au rétablissement volontaire de structures lorsque la complexité le justifie. La maturité consiste à conserver une entrée accessible sans prétendre qu’une page unique convient à tous les systèmes.

Lerdorf après la création initiale

Lerdorf travaille dans plusieurs entreprises du Web, notamment Yahoo!, WePay et Etsy. Il s’intéresse aux performances de grandes plateformes, au profilage et à la sécurité, et continue de contribuer à des extensions et infrastructures PHP.

Ses conférences utilisent souvent l’histoire du projet pour insister sur l’écosystème plutôt que sur le culte du créateur. Il souligne que PHP a grandi parce qu’un besoin existait et que des centaines de développeurs se sont rassemblés autour de la solution initiale.

Cette position est cohérente avec la genèse du projet. Lerdorf publie ses outils pour que d’autres les modifient, accepte la réécriture de PHP/FI et partage la conception de PHP 3 au lieu de préserver son implantation comme référence définitive.

Son apport personnel reste décisif : avoir reconnu tôt que le Web avait besoin d’une couche de programmation placée au plus près de la page, puis avoir choisi une forme assez accessible pour être copiée et adaptée.

Pourquoi Rasmus Lerdorf compte encore

PHP a permis à des étudiants, associations, petites entreprises et développeurs isolés de passer d’un document statique à une application reliée à des données. Son impact ne se mesure pas seulement aux grands sites, mais au nombre d’idées modestes qui ont pu être publiées sans équipe d’infrastructure.

Le langage porte les traces de cette ouverture. Sa syntaxe et sa bibliothèque ont parfois privilégié la disponibilité immédiate à l’élégance générale. Les critiques sur leur incohérence sont fondées, mais elles deviennent incomplètes si elles ignorent le problème historique résolu.

Lerdorf montre également qu’un créateur peut laisser son projet devenir collectif. PHP 3 et le Zend Engine ne sont pas des annexes : ils constituent la base des versions qui ont conquis le Web. Reconnaître Gutmans, Suraski et les autres contributeurs donne une image plus exacte de l’innovation.

L’héritage de PHP tient finalement à un principe : une technologie change le monde lorsqu’elle abaisse suffisamment le coût entre une intention et sa mise en ligne. Le défi suivant est de faire grandir cette technologie sans perdre l’accessibilité qui l’a rendue utile.

Chronologie

• 1968 : naissance de Rasmus Lerdorf au Groenland.
• 1993 : diplôme en ingénierie de la conception de systèmes à l’université de Waterloo.
• 1994 : création des premiers binaires CGI destinés à son site personnel.
• Juin 1995 : publication du code source de PHP Tools.
• 1995 : évolution vers Forms Interpreter puis retour au nom PHP.
• 1996 : publication de PHP/FI 2.0, qui prend la forme d’un langage incorporé au HTML.
• 1997 : début de la réécriture du parseur avec Andi Gutmans et Zeev Suraski.
• Juin 1998 : publication officielle de PHP 3 par la nouvelle équipe de développement.
• 2000 : PHP 4 adopte le Zend Engine et améliore performances et modularité.
• 2004 : PHP 5 renforce le modèle objet avec Zend Engine II.
• 2015 : PHP 7 apporte une amélioration majeure des performances et de la mémoire.
• 2020 : PHP 8 introduit notamment les attributs, les types union et un compilateur JIT.
• Années 2000–2020 : Lerdorf poursuit ses travaux sur performance, sécurité et écosystèmes web dans plusieurs entreprises et au sein du projet.

Questions fréquentes

Rasmus Lerdorf voulait-il créer un langage de programmation ?

Pas au départ. Il construisait des outils CGI pour suivre les visites de son site, réutiliser du contenu et traiter des formulaires. Les besoins des utilisateurs ont progressivement transformé cette boîte à outils en langage.

Rasmus Lerdorf a-t-il créé seul le PHP moderne ?

Non. Il a créé PHP Tools et PHP/FI, puis collaboré à PHP 3. Andi Gutmans et Zeev Suraski ont réécrit le parseur et conçu ensuite le Zend Engine ; de très nombreux contributeurs ont construit les versions, extensions et plateformes modernes.

Que signifie PHP aujourd’hui ?

PHP signifie « PHP: Hypertext Preprocessor », un acronyme récursif. Le nom initial renvoyait à « Personal Home Page Tools », devenu trop étroit lorsque le projet s’est transformé en langage général côté serveur.

Pourquoi PHP s’est-il autant répandu ?

Il permettait d’ajouter du comportement à une page HTML avec très peu d’installation, offrait un accès direct aux formulaires et bases de données, et était disponible chez de nombreux hébergeurs. Les CMS libres ont ensuite multiplié cette diffusion.

PHP est-il adapté seulement aux petits sites ?

Non. Des frameworks, outils de dépendances, analyseurs statiques et améliorations du moteur permettent de construire de grandes applications. Son entrée très simple ne dispense toutefois pas d’une architecture, de tests et de pratiques de sécurité lorsque le projet grandit.