PHP a été mon langage de prédilection pendants des années et il reste aujourd'hui l'un des langages les plus utilisés dans le monde pour le développement web côté serveur. Les frameworks modernes comme Laravel ou Symfony ont largement contribué à structurer des bases de code maintenables, et la maturité de l'écosystème est un vrai atout. Pourtant, un nombre croissant d'équipes s'interrogent sur la pertinence de continuer à choisir PHP pour de nouveaux projets, en particulier lorsque les exigences de fiabilité et de performance sont élevées.
J'ai pour ma part fait cette transition il y a près de 5 ans maintenant, et je suis vraiment satisfait d'avoir fait ce choix. Dans cet article, je vous parle de quelques points en faveur de cette transition, en détaillant des aspects spécifiques à la migration PHP -> Rust (J'essaierai de faire d'autres articles concernant le passage de Node à Rust, puisque c'est aussi une transition que j'ai faite).
La plupart des problèmes de production en PHP n'ont pas de lien avec les compétences de l'équipe. Ils viennent de la nature même du langage : les erreurs de type, les valeurs nulles non gérées, les injections SQL qui passent entre les mailles d'une validation incomplète — tout cela n'apparaît qu'à l'exécution, en production, devant de vrais utilisateurs.
Or, chaque incident de ce type a un coût : le temps de mobilisation de l'équipe pour la réparation des bugs (et de leurs conséquences), parfois une dette technique supplémentaire introduite dans la précipitation du correctif, ainsi que la perte de confiance des utilisateurs et de l'équipe.
À cela s'ajoute la complexité de l'environnement d'exécution. Un projet PHP embarque un runtime, un gestionnaire de dépendances, parfois plusieurs versions de bibliothèques en conflit. Reproduire fidèlement l'environnement de production sur tous les postes de développeurs et dans les pipelines CI/CD est un travail en soi, qui mobilise du temps et génère des incidents difficiles à reproduire.
Rust déplace une grande partie de la détection d'erreurs du moment de l'exécution vers le moment de la compilation. Concrètement : si le code compile, une classe entière de bugs — déréférencement de pointeurs nuls, accès concurrents non protégés, fuites mémoire — est garantie absente. Ce n'est pas une question de discipline de l'équipe ou de revue de code plus rigoureuse. C'est une propriété du langage, vérifiée mécaniquement à chaque build.
Pour un décideur, cela se traduit directement : moins d'incidents en production et moins de temps passé à déboguer des cas limites. Les équipes qui ont effectué cette transition rapportent systématiquement une réduction du temps consacré au débogage et à la maintenance corrective, ainsi qu'une confiance bien plus importante dans leur code et leur capacité à le maintenir.
Le déploiement est également simplifié. Un projet Rust compilé produit un binaire autonome : pas de runtime à installer, pas de dépendances à synchroniser entre les environnements. Le binaire qui passe les tests en CI est exactement celui qui tourne en production. Pour les équipes qui déploient fréquemment ou sur des infrastructures contraintes, c'est un gain opérationnel concret.
Les gains de performance de Rust sur PHP ne sont pas marginaux. À infrastructure équivalente, un service Rust typique traite entre cinq et dix fois plus de requêtes qu'un service PHP avec framework. En termes de décision d'infrastructure, cela signifie concrètement repousser un scaling horizontal de plusieurs mois, voire d'un ou deux ans selon la trajectoire de croissance du trafic. Sur des hébergements cloud facturés à la ressource, la réduction de coût est proportionnelle.
Ce n'est pas l'argument principal pour migrer, la fiabilité l'est davantage à mon sens, mais c'est un bénéfice mesurable qui entre directement dans un calcul de retour sur investissement.
Le framework Rust Rocket, associé au moteur de templates Handlebars via la crate rocket_dyn_templates, offre un modèle de développement qui ne dépayse pas les équipes habituées au rendu serveur. Les routes sont déclarées de façon lisible, les templates Handlebars sont proches de ce que proposent Twig ou Blade, et la structure d'un projet reste reconnaissable pour un chef de projet ou un architecte qui connaît l'écosystème PHP.
Cela signifie qu'une migration n'implique pas de tout réécrire simultanément. Il est tout à fait envisageable de migrer service par service, en commençant par les parties les plus critiques en termes de fiabilité ou de charge, tout en maintenant le reste en PHP le temps de la transition.
J'ai remarqué que la courbe d'apprentissage de Rust est systématiquement un sujet. Il est vrai que Rust a une courbe d'apprentissage assez dure. Un développeur PHP expérimenté aura besoin de quatre à huit semaines pour être autonome, et plusieurs mois pour maîtriser les concepts avancés du langage. Le compilateur est exigeant (mais extrêmement bien fait), et cette exigence demande un effort initial.
Mais ce qu'il faut mettre en regard de cet investissement, c'est qu'une fois cette période passée, les équipes rapportent non seulement une expérience de développement vraiment supérieure, mais aussi qu'elles produisent du code plus "propre" et dans lequel elles ont beaucoup plus confiance. Et c'est normal, car l'exigence du compilateur devient un filet de sécurité permanent.
Il faut donc retenir que si la formation initiale a un coût ponctuel, les bénéfices eux sont récurrents.
En conclusion, selon moi aujoud'hui il n'y a pas de raison d'utiliser PHP putôt que Rust. L'argument systèmatique qui est de dire que l'équipe n'est pas formée est un non sens selon moi, en particulier à l'heure de l'IA (qui par ailleurs est capable de produire du très bon code Rust, notamment puisque tout est typé). Certes il y a un investissement initial, mais non seulement les développeurs apprécient réellement ce langage, mais en plus Rust permet de faire du code bien plus maintenable et plus sûr en production.