Il y a une question autour de laquelle je tourne depuis presque toute ma carrière : comment déployer TypeScript et les technologies web à grande échelle ?
Je ne parle pas de démarrer un projet. Cela n’a jamais été aussi simple. Je parle de construire quelque chose qui survive à la production, au travail en équipe et à cinq années de maintenance, sans finir enseveli sous le poids de ses propres conventions.
Si cette question revient sans cesse, c’est parce que je réécris sans cesse la même plomberie : les mêmes fondations à consolider avant de pouvoir bâtir quoi que ce soit de sérieux, les mêmes bonnes pratiques à réinstaller de zéro, à chaque projet. Ce travail occupe une place étrange dans notre industrie. Nous le recommençons constamment sans même le remarquer, et les entreprises n’en soupçonnent pas l’existence — jusqu’au jour où un incident majeur frappe la production et où il faut soudain tout régler, vite et sans casse.
Pour comprendre pourquoi la réponse nous échappe encore, il faut remonter un peu le temps.
J’ai débuté à l’époque où chaque plateforme exigeait sa propre stack
J’écris du code depuis plus de quinze ans. J’ai commencé par le C et le C++, avant de passer à Java aux débuts d’Android, vers 2012.
Pour les projets sur lesquels la plupart d’entre nous travaillaient, le web offrait peu de choix. Côté frontend, c’était HTML et CSS, surmontés d’un peu de JavaScript pas franchement sûr. jQuery si l’on voulait de l’aide — et presque tout le monde en voulait. Flash si l’on se sentait courageux, ou si l’on avait récemment fait la paix avec l’idée de planter le navigateur. Sur le serveur, PHP régnait en maître. Voilà comment WordPress a conquis le monde si complètement que nous cherchons encore le moyen de nous en débarrasser.
Les logiciels plus proches de la machine avaient chacun leur royaume. Android, c’était Java et XML, que le problème ait besoin de XML ou non. Apple, c’était Objective-C et Xcode, que Xcode soit de bonne humeur ou non. Une entreprise sous Windows — c’est-à-dire encore la majorité — travaillait avec le bon vieux .NET, où la solution à une dépendance Microsoft consistait généralement à en ajouter une autre.
Android, où l’interface était en XML, que le problème le veuille ou non. 
L’iPhone, qui décidait aussi quel type d’ordinateur vous deviez posséder. 
Windows, où livrer signifiait fournir un installateur et parier sur le runtime déjà présent. 
Le navigateur, qui exigeait le moins et, au début, offrait le moins.
Aucune de ces plateformes n’était mauvaise simplement parce qu’elle était différente. Le problème, c’est que chaque cible amenait son langage, sa chaîne d’outils, son runtime et sa propre réponse au déploiement. Une entreprise qui développait pour Android, iPhone, Windows et le navigateur ne livrait pas quatre fois le même produit. Elle maintenait quatre produits apparentés en espérant qu’ils continueraient à raconter la même histoire.
La fragmentation nous a donné un mot pour renoncer
Cette fragmentation a façonné le paysage dans lequel nous vivons encore. La plupart des entreprises ont quelque part en production un ERP de 2012 que plus personne ne maintient, et mettre à jour son installation Windows donne l’impression de migrer un centre de données. Un Mac en parfait état de marche peut perdre dix ans de logiciels 32 bits en une seule mise à jour du système d’exploitation.
Tout cela porte un nom bien connu, entendu mille fois et face auquel nous avons religieusement appris à ne rien faire : le legacy.
Mais « legacy » ne veut pas dire « local ». Certaines applications vivent sur la machine de l’utilisateur parce que personne n’a trouvé le budget pour les remplacer. D’autres y vivent parce que c’est là que se trouve leur travail : les fichiers, les polices, la carte graphique, le port série, le réseau d’un hôpital volontairement coupé d’Internet, ou cette note qui devrait s’ouvrir sans demander la permission à un serveur situé sur un autre continent.
Une application locale n’est pas legacy simplement parce qu’elle s’exécute en local.
Le véritable héritage encombrant, c’était de devoir choisir entre la portée du web et les capacités de la machine.
Puis le web a rattrapé son retard
La compatibilité entre navigateurs restait un champ de mines, et monter un backend revenait à devenir administrateur système à mi-temps. Docker n’avait pas encore atteint sa première version stable, et Kubernetes n’existait pas.
Puis Node.js a amené JavaScript sur le serveur. AngularJS, puis React, nous ont donné des modèles applicatifs crédibles dans le navigateur. Pour la première fois, une équipe pouvait écrire toute une solution métier dans un seul langage et la livrer sur presque n’importe quel appareil. Mieux encore, l’utilisateur n’avait plus à se soucier du runtime choisi par les développeurs. Rien à installer, aucune dépendance système à mettre à jour, aucun débat sur la version de .NET présente sur la machine. On envoyait un lien. Le navigateur faisait le reste.
Ce mode de distribution était si puissant que nous avons discrètement confondu deux idées distinctes : les technologies web étaient devenues un moyen universel de construire une interface, donc le logiciel lui-même devait vivre sur un serveur. Seule la première idée avait été démontrée.
Le web s’est imposé comme interface. Nous y avons vu, à tort, la preuve que toute application devait vivre sur un serveur.
Nous avons tout envoyé sur le serveur, puis en avons rapatrié la moitié
Tout ce que nous installions autrefois sur l’appareil de l’utilisateur vivait désormais sur une machine située ailleurs, héritage direct des années PHP côté backend. Ouvrir une note dans son application exigeait donc plusieurs allers-retours vers un serveur à l’autre bout de la planète. Passer à la note suivante ? Rebelote. Et si le train entrait dans un tunnel, vos notes cessaient apparemment d’exister.
Il est devenu évident qu’il fallait supprimer ces allers-retours. Dieu merci, React était là pour nous sauver. Vive les applications client-first ! Désormais, pour ouvrir la même application de notes, on attendait le téléchargement de ce qui ressemblait à 50 Mo de JavaScript. Mais au moins, un joli spinner nous tenait compagnie et, une fois le chargement terminé, tout paraissait instantané. Presque natif.
Le modèle s’est vite répandu, y compris dans des logiciels critiques en production. Et même si, dans ma jeunesse, je détestais Java et adorais React, ouvrir mon client de messagerie était devenu une source permanente d’agacement à bas bruit. Je pouvais revenir à l’affreuse interface desktop, dont le designer avait manifestement été envoyé par Satan en personne, ou rester sur le superbe client web qui plantait toutes les cinq minutes lorsqu’il n’était pas paralysé par une boucle useEffect.
Nous en sommes arrivés à vivre avec des logiciels défaillants. À trouver cela normal.
Nous n’avons pas réparé les logiciels. Nous sommes simplement devenus meilleurs pour les attendre.
Puis les choses se sont réellement améliorées. Cache, CDN, stockage hors ligne, bases de données local-first, interfaces optimistes et infrastructure edge ont rendu le web plus rapide et plus résilient. Mais une partie de ces efforts ne soignait que le symptôme : nous avions éloigné le logiciel de la machine, découvert que la distance et les coupures posaient problème, puis inventé des mécanismes toujours plus sophistiqués pour faire comme s’il était encore à portée de main.
Le desktop n’a pas disparu non plus. Souvent, nous l’avons reconstruit avec des technologies web en livrant un navigateur entier avec chaque application : un pont raisonnable, mais pas franchement économique. La question n’était plus de savoir si les technologies web avaient leur place sur le desktop. Il fallait savoir si nous pouvions les y ramener sans ressusciter la fragmentation et les douleurs d’installation dont le web nous avait débarrassés.
V8 a fait de JavaScript une infrastructure
Rien de tout cela n’aurait pris la même ampleur sans V8. Google a livré la partie de Chrome qui analyse et exécute JavaScript séparément des API du navigateur qui l’entourent, ce qui permettait de l’embarquer ailleurs. Node a sorti le moteur de Chrome et l’a entouré d’API serveur. On l’a ensuite retrouvé dans des téléviseurs, des appareils embarqués et d’autres runtimes.
Voilà la véritable percée. JavaScript n’était plus attaché à un document dans un navigateur : un environnement hôte pouvait donner accès aux fichiers, aux sockets, aux processus ou au matériel, tandis que V8 prenait en charge le langage. WebAssembly a encore élargi la voie de sortie. JavaScript n’avait pas besoin de tout faire. Il devait seulement devenir le langage dans lequel tout pouvait se rencontrer.
Le problème suivant n’a donc jamais été de désigner le langage vainqueur. Il fallait combiner les bons langages sans recréer la fragmentation à laquelle nous venions tout juste d’échapper.
TypeScript a corrigé le langage, pas la discipline
Pendant que tout cela se mettait en place, une révolution plus discrète avait déjà pris racine.
Heureusement, nous avons des légendes vivantes comme Anders Hejlsberg, l’homme derrière Turbo Pascal, Delphi et C#, à qui nous devons TypeScript.
On peut voir TypeScript comme une tentative de plus pour dissimuler la nature chaotique et dynamique de JavaScript sous un système de types sophistiqué, au lieu de corriger les défauts de conception du langage. Ce n’est pas une lecture injuste. Mais l’intention était plus maligne. Quand TypeScript est apparu, le web avait déjà gagné et n’allait clairement plus disparaître. Remplacer JavaScript n’était plus un projet sérieux ; il fallait le rendre viable à grande échelle.
Angular a porté cette idée au cœur des entreprises. Google a abandonné AtScript, son propre surensemble typé, pour construire Angular 2 avec TypeScript. Les équipes d’entreprise ont ainsi reçu un frontend qui ressemblait aux backends qu’elles maintenaient déjà : typage fort, injection de dépendances et structure imposée plutôt que laissée à assembler. Pendant des années, les équipes Java n’avaient eu aucune réponse web crédible. Angular leur en a donné une que leurs architectes pouvaient réellement approuver.
TypeScript a réparé le langage que tout le monde avait déjà choisi, sans exiger son remplacement. Ce détail allait compter davantage encore que le système de types lui-même.
Angular avait la discipline, et a quand même perdu
Angular s’était déjà tiré une balle dans le pied avant même la sortie de sa version TypeScript. À ng-europe en 2014, l’équipe a présenté Angular 2 comme une réécriture complète : plus de $scope, plus de contrôleurs, plus d’objets de définition de directives et, dans l’annonce initiale, aucune voie de migration pour les applications AngularJS déjà en production.
Google a corrigé les décisions les plus brutales. ngUpgrade est arrivé, AngularJS a gagné un modèle de composants, la migration progressive est devenue officielle. Personne ne se souvient du correctif. Tout le monde se souvient de l’annonce : le framework sur lequel vous avez standardisé votre développement peut être remplacé, et vous l’apprendrez pendant une conférence.
Puis il y avait la courbe d’apprentissage. TypeScript, décorateurs, injection de dépendances, modules et observables RxJS — autant de notions souvent indispensables avant même de pouvoir livrer un formulaire. React demandait bien moins : une bibliothèque plutôt qu’un framework, JSX plutôt qu’un énième langage de templates, et un premier écran réalisable en un après-midi. Moi aussi, j’ai choisi React, précisément pour cette raison.
React a ensuite préservé son modèle de composants avec une retenue inhabituelle. Les API périphériques ont évolué et certaines fonctionnalités historiques ont disparu, mais jamais une équipe n’a reçu l’ordre de remplacer son application pour continuer à bénéficier du framework. Le plus frustrant, c’est qu’Angular s’est amélioré : les composants standalone ont rendu les modules facultatifs, et les signaux ont débarrassé l’état des composants de l’essentiel du cérémonial des observables. Mais à ce stade, le débat était déjà clos. Angular avait la discipline. React avait la confiance.
La liberté est un atout, jusqu’à ce que le code devienne énorme
L’industrie a donc choisi la bibliothèque sans opinion. C’est précisément cette liberté qui m’a attiré vers React : composer soi-même sa stack, son arborescence, ses conventions et ses bibliothèques. Sur un petit projet indépendant, l’idée paraît merveilleuse. Dans une grosse application en production, elle perd son intérêt à une vitesse remarquable.
On pourrait soutenir que React n’est tout simplement pas destiné aux logiciels sérieux. Malheureusement, la réalité raconte tout autre chose. Microsoft a livré des interfaces fondées sur React au cœur de Windows et de Teams. L’absence d’architecture n’a pas tenu React éloigné des systèmes critiques. Elle a obligé chaque équipe à fournir elle-même l’architecture manquante.
Le problème n’a jamais été React. Le problème, c’est que React n’a pas d’opinion.
Expo prouve que les développeurs ne rejetaient pas les choix tranchés. C’est un framework mobile mature, doté d’une excellente expérience développeur, d’un solide écosystème officiel et d’une manière de construire bien plus cadrée. La documentation de React Native elle-même recommande désormais de commencer avec un framework comme Expo. Expo a réussi là où Angular avait échoué : il a ajouté ses décisions par-dessus une technologie déjà adoptée, au lieu de demander aux équipes d’abandonner ce qu’elles avaient construit.
Même médicament, mais un seul a été avalé. L’industrie ne refuse pas une bonne architecture. Elle refuse la réécriture qui l’accompagne.
La même question, une génération plus tard
Voilà où le web a atterri. Pour construire un logiciel destiné à presque n’importe quel écran, le choix par défaut est une bibliothèque qui refuse délibérément d’avoir une opinion sur la manière de construire un logiciel. Chaque équipe comble les blancs depuis zéro et baptise le résultat « stack ».
Nous voici donc face à la même question que Hejlsberg. Il ne pouvait pas remplacer JavaScript ; personne ne le pouvait. Il a donc construit une couche par-dessus pour rendre le langage plus sûr, sans demander à quiconque d’abandonner son code. On ne répare pas un standard en prétendant qu’il a perdu. On le rejoint là où il se trouve déjà.
La décennie suivante a vu naître une vague de projets qui avaient compris la leçon ; ils seront le sujet de la prochaine partie. Le web était devenu incontournable. Il restait à rendre ce standard rapide, observable, durable et capable de s’exécuter partout où le travail a réellement lieu.
Poursuivez avec Comment la stack web a gagné en maturité.
Sources
- 1Le premier serveur web du CERN — Coolcaesar, CC BY-SA 3.0commons.wikimedia.org
- 2Documentation de V8 — Documentation officielle du moteur JavaScript et WebAssembly embarquablev8.dev
- 3Anders Hejlsberg à la PDC 2008 — DBegley, CC BY 2.0commons.wikimedia.org
- 4Présentation d’Angular 2.0 à ng-europe 2014 — Enregistrement de la conférenceyoutube.com