Common Gateway Interface

Le Web des premières années ressemblait à une immense bibliothèque figée. Consulter une page revenait à feuilleter un livre : on pouvait lire, mais impossible d'interagir. Cette situation changea radicalement quelques années plus tard quand les utilisateurs commencèrent à réclamer davantage. Ils voulaient remplir des formulaires, rechercher des informations, personnaliser leur expérience. Les pages statiques atteignaient déjà leurs limites.

Rob McCool travaillait au National Center for Supercomputing Applications sur le serveur web NCSA HTTPd. En 1993, il imagina une solution élégante pour résoudre ce problème : créer un pont entre le serveur web et des programmes externes. Cette idée donna naissance au Common Gateway Interface, plus connu sous l'acronyme CGI. Le terme gateway (passerelle) reflétait parfaitement sa vocation : relier deux mondes jusqu'alors séparés.

Le génie de CGI tenait dans sa simplicité. Quand un visiteur cliquait sur un lien ou envoyait un formulaire, le serveur ne se contentait plus de retourner un fichier existant. Il lançait un programme sur le serveur qui générait une réponse sur mesure, puis transmettait cette réponse au navigateur. Soudain, le Web devenait vivant. Les développeurs pouvaient écrire leurs scripts dans le langage de leur choix, pourvu qu'il respecte quelques règles de base.

Ces règles définissaient un protocole de communication standardisé. Le serveur transmettait les informations de la requête via des variables d'environnement baptisées méta-variables. Le script récupérait ces données, les traitait, et générait une réponse conforme au protocole HTTP. Cette approche universelle fonctionnait avec n'importe quel langage de programmation, de C à Python en passant par Perl.

Perl justement devint le champion de CGI. Sa capacité à manipuler le texte, sa syntaxe permissive et sa disponibilité sur toutes les plateformes séduisirent les développeurs web. Les premiers scripts traitaient les formulaires HTML, interrogeaient des bases de données et assemblaient des pages personnalisées. L'époque était aux expérimentations.

Ces expérimentations donnèrent naissance à des collections de scripts partagés. Matt Wright, lycéen dans le Colorado, créa en 1995 le « Matt's Script Archive », qui devint une référence incontournable. Son script FormMail permettait d'envoyer le contenu des formulaires par e-mail et fut téléchargé des milliers de fois. Problème : Wright était jeune, inexpérimenté, et ses scripts comportaient des failles de sécurité béantes. La communauté Perl réagit en créant « Not Matt's Scripts », proposant des alternatives plus robustes.

Car la sécurité posait un défi constant. Chaque script CGI représentait une porte d'entrée potentielle vers le système. Les développeurs devaient valider scrupuleusement les données d'entrée, éviter les débordements de mémoire et se prémunir contre l'injection de code malveillant. Les administrateurs confinaient généralement ces scripts dans un répertoire spécial, le fameux cgi-bin, pour limiter les dégâts en cas de problème.

L'architecture de CGI souffrait d'un défaut congénital : chaque requête déclenchait le lancement d'un nouveau processus. Sur un serveur peu fréquenté, cela passait inaperçu. Mais dès que le trafic augmentait, les performances s'effondraient. La machine passait plus de temps à créer et détruire des processus qu'à traiter les requêtes elles-mêmes.

Des solutions émergèrent pour contourner cette limitation. FastCGI gardait les processus en vie entre les requêtes, éliminant le surcoût de lancement. Mod_perl intégrait l'interpréteur Perl directement dans Apache, transformant les scripts en modules persistants. Ces optimisations redonnèrent une seconde jeunesse à CGI.

Pendant ce temps, d'autres approches gagnaient du terrain. PHP, créé en 1994 par Rasmus Lerdorf, proposait une intégration native au serveur web. Plus besoin de processus externes : le code s'exécutait directement dans Apache. Microsoft développait ASP pour ses serveurs IIS, tandis que Sun travaillait sur JSP pour l'univers Java. Chacun cherchait sa voie vers la programmation web dynamique.

Ces nouvelles technologies n'effaçaient pas l'héritage de CGI. Elles en reprenaient les concepts fondamentaux : séparation entre serveur et logique applicative, transmission d'informations via l'environnement, modèle requête-réponse. CGI avait tracé la route, d'autres l'élargissaient.

L'évolution s'accéléra au tournant des années 2000. Les frameworks web modernes apportaient des abstractions de plus haut niveau, une gestion d'état sophistiquée, des architectures orientées services. Ruby on Rails révolutionna le développement web en 2004, Django fit de même pour Python. Ces outils rendaient CGI obsolète pour la plupart des usages.

Pourtant, CGI refusait de disparaître complètement. Sa standardisation officielle dans la RFC 3875 en 2004 reconnaissait son importance historique. Cette spécification codifiait dix ans d'expérience pratique, détaillant chaque aspect technique de l'interface. Apache et d'autres serveurs continuaient de la supporter, préservant la compatibilité avec d'anciennes applications.

Cette longévité s'explique par la robustesse du modèle conceptuel de CGI. L'idée d'une interface standard entre serveur web et programmes externes reste pertinente aujourd'hui. Les architectures de microservices modernes et d'API REST reprennent ce principe à plus grande échelle, dont la philosophie stateless.