Chapitre 9
2000

Le XXI^e siècle a débuté dans le tumulte. Les attentats du 11 septembre 2001 ont secoué notre monde jusque dans ses fondements. Du jour au lendemain, la vision du numérique s’est transformée. Les gouvernements ont durci leur approche de la sécurité informatique, les infrastructures vitales se sont blindées, et les communications ont été placées sous surveillance. À Washington, le Patriot Act a remodelé notre rapport à la vie privée numérique.

Internet s’est démocratisé comme jamais auparavant. Nous avons vu naître ce qu’on a baptisé le Web 2.0, une mutation où l’internaute agit. MySpace et Facebook ont créé de nouveaux territoires sociaux virtuels. Twitter a changé notre rapport à l’actualité. Les blogs personnels ont fleuri partout grâce à WordPress, donnant voix à qui le souhaitait. Ce bouillonnement a redéfini notre manière d’exister en ligne.

L’économie du numérique a traversé une tempête salvatrice. L’éclatement de la bulle Internet a balayé les projets les plus fragiles. Les survivants ont dû prouver leur valeur réelle. Google s’est imposé comme le cartographe de ce nouvel univers informationnel grâce à son algorithme PageRank. Amazon a révolutionné le commerce en créant une expérience d’achat entièrement repensée.

La mobilité a pris une place centrale dans notre quotidien. Les premiers smartphones ont commencé à transformer nos habitudes. L’iPhone en 2007 provoqua une rupture totale. La façon dont nous touchions, manipulions les appareils ne serait plus jamais la même. Les réseaux sans fil se sont multipliés, le Wi-Fi est devenu omniprésent, et la 3G nous a offert Internet dans notre poche.

Le commerce en ligne a mûri et les systèmes de paiement se sont sécurisés, inspirant confiance aux consommateurs les plus réticents. L’analyse des données a permis aux sites marchands de nous connaître parfois mieux que nous-mêmes, suggérant des produits avec une précision troublante. Pour répondre à cette explosion des usages, les centres de données ont dû se réinventer, devenir plus efficaces, moins énergivores.

L’expérience nouvelle du partage s’est produite avec l’émergence des technologies peer-to-peer. Napster a ébranlé l’industrie musicale, alors que BitTorrent a transformé nos modes de partage. Les majors du disque ont d’abord résisté avant de s’adapter. Last.fm et Spotify ont inventé de nouvelles façons d’écouter de la musique, annonçant la révolution du streaming vidéo à venir.

Dans les entreprises, le travail s’est métamorphosé. Le haut débit et les outils collaboratifs ont rendu possible le télétravail. Les organisations ont massivement investi dans leurs systèmes d’information, déployant des solutions ERP et CRM pour mieux gérer leurs activités et leurs relations clients.

L’open source a gagné ses lettres de noblesse. Linux, autrefois considéré comme un projet marginal, s’est installé dans les salles serveurs des grandes entreprises. Firefox a prouvé qu’un navigateur libre pouvait tenir tête aux géants. Des communautés passionnées se sont formées autour de ces projets, montrant la puissance du développement collectif.

La fracture numérique a préoccupé les gouvernements du monde entier. Des programmes d’équipement des écoles ont été lancés. L’accès à Internet est devenu un enjeu d’égalité sociale. En Asie, la Chine et l’Inde ont bâti des industries technologiques puissantes en un temps record, transformant l’équilibre mondial du secteur.

Dans les datacenters, la virtualisation a explosé et changé la donne. Un seul serveur physique pouvait héberger plusieurs machines virtuelles. Cette évolution a fait émerger le cloud computing. Les DSI ont commencé à externaliser leurs infrastructures, gagnant en agilité.

La cybersécurité est devenue un sujet majeur. Les attaques informatiques se sont multipliées et sophistiquées. Les virus ont évolué en ransomwares et malwares complexes. Face à cette menace grandissante, les solutions de protection ont dû s’adapter en permanence. La criminalité s’est organisée en ligne, ciblant les données bancaires et personnelles.

Dans les écoles, le numérique a fait son entrée. Les tableaux blancs interactifs ont remplacé la craie. Les Environnements Numériques de Travail ont créé de nouveaux liens entre enseignants, élèves et parents. Les ressources pédagogiques se sont enrichies, diversifiées, numérisées.

La recherche scientifique a franchi des paliers décisifs grâce à la puissance de calcul croissante. Les supercalculateurs ont rendu possibles des simulations climatiques précises, des avancées en génomique, des découvertes en physique fondamentale. Les scientifiques ont appris à travailler avec des systèmes de calcul distribués pour résoudre des problèmes toujours plus complexes.

L’automatisation s’est intensifiée dans tous les secteurs. Les systèmes embarqués sont devenus plus intelligents, plus communicants. La robotique industrielle a franchi un cap, rendant les usines plus productives mais posant aussi des questions sociales importantes.

La conscience environnementale a fait son apparition dans le monde informatique. La consommation électrique des datacenters est devenue un sujet de préoccupation. Le Green IT a émergé comme une nécessité, non plus seulement comme un argument marketing.

De nouvelles formes de collaboration ont vu le jour. Wikipédia, lancée en 2001, a montré la voie d’une intelligence véritablement collective. Les wikis et autres outils collaboratifs ont transformé la manière dont les équipes travaillaient ensemble, partageaient leurs connaissances.

Nos appareils électroniques ont convergé vers un écosystème connecté. Téléviseurs, appareils photo, chaînes Hi-Fi : tout est devenu « intelligent » et interconnecté. Cette convergence a nécessité de nouveaux standards pour que nos équipements puissent communiquer entre eux.

Cette décennie a façonné notre monde numérique actuel. Ce n’était pas une simple évolution technologique, mais une transformation de notre société. Nous avons changé notre manière de communiquer, de travailler, de nous divertir. La période 2000-2010 restera dans l’histoire comme celle où l’humanité s’est véritablement mise en réseau, où notre monde est devenu irrémédiablement connecté.

Haut de page

C#

Anders Hejlsberg débarque chez Microsoft en 1996 avec une solide réputation : il a développé le compilateur Turbo Pascal et dirigé la création de Delphi chez Borland. Microsoft lui confie alors une mission ambitieuse : concevoir un nouveau langage de programmation pour sa future plateforme .NET. Ce langage, d’abord baptisé « Cool » durant sa conception, deviendra C#. L’objectif était clair : offrir une alternative moderne à Java, en évitant ses écueils tout en reprenant ses meilleures idées.

Le C# se différencie d’emblée par son système de types unifié. Tous les types, même les plus basiques comme int ou double, héritent d’un type racine unique appelé object. Cette architecture simplifie la manipulation des données, quelle que soit leur nature. Le langage intègre aussi la collecte automatique de la mémoire, qui récupère l’espace occupé par les objets devenus inutiles, et une gestion structurée des erreurs par exceptions.

Chaque nouvelle version a enrichi le langage de fonctionnalités substantielles. La version 2.0 introduit les génériques, qui renforcent la réutilisabilité du code et la sécurité des types. Les délégués anonymes élargissent les possibilités en programmation événementielle. Avec la version 3.0 arrivent les fonctionnalités LINQ (Language Integrated Query), qui transforment radicalement la façon d’interroger et de manipuler les données.

Hejlsberg et son équipe ont accordé une attention particulière à la compatibilité des versions. Les applications existantes devaient continuer à fonctionner avec les nouvelles versions des bibliothèques. Cette préoccupation transparaît dans plusieurs choix de conception : les modificateurs virtual et override restent distincts, les règles de résolution des surcharges de méthodes sont clairement définies. Cette rigueur garantit la pérennité des programmes.

La recherche chez Microsoft a joué un rôle déterminant dans l’évolution du langage. Don Syme et Andrew Kennedy, chercheurs à Microsoft Research Cambridge, ont développé un prototype baptisé Gyro pour expérimenter les génériques avant leur intégration dans C#. Cette collaboration entre recherche et développement illustre bien l’approche pragmatique retenue : tester les idées nouvelles dans des projets exploratoires avant de les incorporer dans le langage de production.

Le C# s’est progressivement ouvert à la programmation fonctionnelle. L’inférence de types, les expressions lambda, tous ces concepts issus de langages comme Haskell ou ML ont été intégrés au fil du temps. Cette évolution suit une tendance générale dans l’industrie : les paradigmes de programmation se mélangent pour offrir aux développeurs plus de souplesse. Le langage reste néanmoins accessible aux débutants, une caractéristique pensée dès sa conception.

La question de l’intégration avec les bases de données revient constamment. Les développeurs doivent souvent jongler entre C# et SQL, ce qu’Hejlsberg appelle une « disparité d’impédance » entre ces deux univers. LINQ répond à cette problématique en unifiant l’interrogation de diverses sources de données directement dans le code C#, avec une syntaxe cohérente.

Microsoft a fait évoluer en parallèle C# et Visual Basic .NET, deux langages qui partagent de nombreuses fonctionnalités tout en conservant leurs spécificités. Cette stratégie visait à répondre aux préférences distinctes de leurs communautés respectives. L’équipe de développement maintient aussi des échanges réguliers avec les chercheurs travaillant sur F#, le langage fonctionnel de la plateforme .NET, pour explorer de nouvelles pistes.

La normalisation ECMA-334 et ISO/IEC 23270 a établi des standards techniques garantissant la cohérence des implémentations. Cette standardisation a renforcé la portabilité des applications C# et leur indépendance vis-à-vis de Microsoft.

Le C# adopte résolument une orientation composant. Le langage propose des constructions syntaxiques spécifiques pour créer et utiliser des modules logiciels autonomes et autodocumentés. Cette approche modulaire facilite le développement d’applications complexes et leur maintenance à long terme.

La communauté des développeurs C# s’est considérablement élargie, créant un écosystème riche en bibliothèques, outils et bonnes pratiques. Microsoft a su maintenir le langage à la pointe tout en préservant sa stabilité et sa compatibilité ascendante. Le passage vers des styles de programmation plus déclaratifs se poursuit : les développeurs décrivent leurs objectifs plutôt que les détails d’implémentation, laissant au compilateur le soin d’optimiser l’exécution.

Le C# s’est adapté aux besoins changeants de l’industrie sans renier ses principes fondateurs de simplicité et de productivité. Guidé par une vision claire et nourri par la recherche, son développement continu en fait un outil incontournable du développement logiciel moderne.

Haut de page

FLAC

Josh Coalson lance le développement du FLAC en 2000. Son ambition ? Créer un format libre pour la compression audio sans perte, face aux solutions propriétaires qui dominent alors le marché. Les mélomanes comme les professionnels du son cherchent des alternatives aux formats destructifs tel le MP3, et Coalson va répondre à cette attente.

La compression sans perte du FLAC ramène un fichier audio à 50 ou 60% de sa taille d’origine, sans perdre le moindre bit d’information sonore. Un fichier Broadcast Wave Format de 300 Mo mincit en un fichier de 100 Mo après compression. Une fois décodé, le résultat est strictement identique à l’original sur le plan acoustique. Cette capacité distingue radicalement le FLAC des formats à perte qui sacrifient des informations pour gagner de l’espace.

Le projet rejoint la fondation Xiph.Org en 2003. Cette organisation à but non lucratif héberge déjà des formats multimédia libres comme Vorbis, Opus ou Theora. L’intégration du FLAC dans cet écosystème de standards ouverts renforce sa légitimité. La version 1.2.1 sort en 2007 et marque une forme de maturité : les spécifications n’ont depuis connu aucune modification majeure. Les outils de référence continuent leur évolution, la version 1.3.2 paraît en janvier 2017.

Les concepteurs du FLAC ont privilégié une approche pragmatique. Le format consomme peu de mémoire au décodage et repose uniquement sur des opérations en nombres entiers. Ces choix techniques autorisent son déploiement sur des systèmes aux ressources modestes. Le flux de données s’organise en métadonnées suivies de trames audio. Chaque trame contient un en-tête avec un code de synchronisation de 14 bits, des sous-trames, des octets de bourrage et un pied de trame.

Le format, flexible, accepte jusqu’à 8 canaux audio et des échantillons codés entre 4 et 32 bits. Pour la stéréo, quatre modes d’encodage coexistent : indépendant, gauche/côté, droite/côté et milieu/côté. La compression s’adapte donc à la nature du signal sonore traité.

L’industrie musicale adopte le FLAC par étapes successives. D’abord cantonné aux cercles d’audiophiles et plateformes alternatives, le format gagne du terrain avec l’émergence du streaming haute qualité. TIDAL et Deezer Elite lancent leurs services en 2014, Qobuz suit le mouvement. La distribution en ligne évolue parallèlement : 7digital et Bandcamp proposent désormais le téléchargement en FLAC.

Le support natif par les systèmes d’exploitation représente une étape décisive. Android l’intègre dès la version 3.1, Windows 10 emboîte le pas. Apple maintient sa stratégie propre avec l’ALAC, d’abord propriétaire puis libéré en 2011. Les navigateurs web récents, Chrome 56 et Firefox 51, lisent directement les fichiers FLAC.

La préservation numérique trouve dans le FLAC des atouts considérables. Chaque fichier embarque dans son en-tête une empreinte MD5 des données audio originales pour vérifier leur intégrité. Des sommes de contrôle CRC identifient les trames corrompues lors de la transmission en flux. Ces mécanismes de validation intégrés confèrent au FLAC un avantage sur le format WAV qui nécessite des vérifications externes.

Les institutions patrimoniales s’intéressent au potentiel du format. La division audio et vidéo de la Bibliothèque du Congrès américain envisage son usage pour la consultation des enregistrements sonores dès 2005. L’Internet Archive l’emploie dans ses Archives de Musique Live, où concerts et sessions figurent souvent en FLAC et WAV. L’Union Européenne de Radio-Télévision l’utilise pour distribuer des enregistrements de concerts via Musipop : les fichiers WAV originaux sont convertis en FLAC avant leur transmission par satellite.

Des outils spécialisés accompagnent l’essor du format. VLC, Clementine ou Foobar2000 assurent la lecture sur différentes plateformes. Des utilitaires de conversion comme dbPowerAMP ou FFmpeg facilitent les échanges avec d’autres formats. Mp3tag ou Kid3 gèrent les métadonnées.

L’Internet Engineering Steering Group approuve en 2016 la création du groupe de travail CELLAR pour formaliser les spécifications du FLAC. Cette démarche vise à établir un standard officiel et renforcer la pérennité du format dans le paysage audio numérique.

Un projet libre comme FLAC peut s’imposer comme standard de fait dans son domaine. L’absence de brevets ou de redevances sur son utilisation favorise son adoption par l’industrie musicale et les institutions culturelles. Ce format reste un choix pertinent pour l’archivage numérique et la distribution de musique haute qualité.

Haut de page

JSON

Douglas Crockford travaillait chez State Software et cherchait un moyen simple de faire communiquer un serveur avec un navigateur web. Il remarqua que JavaScript possédait une syntaxe pratique pour représenter les objets : des paires clé-valeur entre accolades. L’idée lui vint d’extraire cette notation du langage pour en faire un format d’échange de données à part entière.

En 2001, Crockford formalisa ce sous-ensemble de JavaScript sous le nom de JSON, pour JavaScript Object Notation. Il publia la spécification sur json.org et proposa des implémentations dans plusieurs langages. Le format tenait en quelques règles : six types de données suffisaient (chaînes de caractères, nombres, booléens, tableaux, objets et la valeur nulle) pour représenter des structures complexes. Cette simplicité brutale tranchait avec la verbosité de XML, omniprésent dans les échanges de données.

La standardisation officielle arriva en 2006 avec la RFC 4627 de l’IETF. Le document établissait le type MIME application/json et définissait la syntaxe précise. D’autres versions suivirent : RFC 7158 en 2013, RFC 7159 en 2014, puis RFC 8259 en 2017. Chaque révision clarifiait des points techniques et ajustait la spécification aux besoins qui émergeaient sur le terrain.

JSON s’est imposé parce qu’il répondait à des besoins concrets. Sa syntaxe minimaliste restait lisible pour un humain tout en étant facile à analyser par une machine. L’absence de balises réduisait la taille des messages échangés. Et surtout, il se mariait naturellement avec JavaScript, le langage qui dominait déjà le développement web côté client. Les développeurs n’avaient rien de nouveau à apprendre car ils utilisaient des structures qu’ils manipulaient quotidiennement.

Les géants du web l’adoptèrent les uns après les autres. Yahoo! figura parmi les premiers à l’intégrer dans ses services, suivi par Google, Facebook et Twitter. Cette adoption massive transforma JSON en standard de fait pour les API web. Les architectures REST, qui devenaient la norme pour concevoir des services web, s’accordaient parfaitement avec ce format léger.

L’écosystème autour de JSON se développa à une vitesse étonnante. Des bibliothèques apparurent dans tous les langages majeurs. Des variantes spécialisées émergèrent : GeoJSON pour les données géographiques, JSON Schema pour valider la structure des documents. Les bases de données NoSQL comme MongoDB ou CouchDB l’adoptèrent comme format de stockage natif, étendant son influence au-delà du simple transport de données.

Les frameworks JavaScript modernes comme Angular ou React manipulaient JSON de manière native. Le développement mobile tira parti de sa légèreté pour économiser la bande passante. JSON devint progressivement un composant invisible mais omniprésent de l’infrastructure web, présent dans presque chaque échange entre applications.

Cette simplicité révéla aussi ses limites. L’impossibilité d’ajouter des commentaires gênait la documentation. La représentation des nombres posait des questions de précision liées aux calculs en virgule flottante. L’absence de format standard pour les dates obligeait les développeurs à établir leurs propres conventions. Des variantes comme JSON5 ou JSONC apparurent pour combler ces manques, au risque de fragmenter l’écosystème.

Une analyse récente des fichiers JSON publics montre que les développeurs exploitent intensivement la capacité du format à représenter des structures imbriquées. Les objets contenus dans des tableaux eux-mêmes nichés dans d’autres objets sont devenus courants. Cette flexibilité autorise une grande expressivité tout en maintenant une certaine régularité qui facilite le traitement automatisé.

JSON a modifié les pratiques de développement. Il a favorisé l’essor d’architectures découplées où les composants communiquent par des interfaces bien définies. Sa facilité de manipulation a encouragé l’adoption de paradigmes fonctionnels et réactifs. Les outils de développement ont intégré des fonctionnalités spécifiques pour travailler avec ce format, de la coloration syntaxique à la validation automatique.

La spécification de JSON est volontairement minimaliste. Ses concepteurs ont choisi de préserver la simplicité originelle plutôt que d’ajouter des fonctionnalités. Les besoins spécifiques sont couverts par des extensions et des outils complémentaires qui n’affectent pas la compatibilité de base. Cette stabilité assure la pérennité du format dans un environnement technologique qui évolue constamment.

Le format n’a pas été imposé par un organisme de standardisation mais adopté naturellement parce qu’il répondait à un besoin réel. Sa réussite tient à son adéquation avec les pratiques existantes et à sa capacité à rester simple quand tant d’autres solutions cherchaient la complexité. JSON est devenu un pilier de l’infrastructure web moderne, un de ces éléments qu’on ne remarque plus tant ils paraissent évidents.

Haut de page

BitTorrent

Début 2000, Internet montrait certaines limites. Transférer un fichier volumineux relevait du parcours du combattant : le courrier électronique saturait, les serveurs FTP s’effondraient sous la charge. Bram Cohen avait eu son compte des startups de la bulle Internet. Ces boîtes promettaient monts et merveilles, brûlaient l’argent des investisseurs, puis disparaissaient avant d’avoir publié quoi que ce soit. Il décida de prendre les choses en main.

Son expérience professionnelle lui avait appris une chose : fragmenter les fichiers pour les stocker de manière sécurisée marchait bien. Cette idée le taraudait. Et si on appliquait ce principe au partage de données ? Au lieu qu’un serveur unique distribue un fichier à des centaines d’utilisateurs, pourquoi ne pas découper ce fichier en morceaux et laisser chacun partager ce qu’il possède localement ?

C’est ainsi que naquit BitTorrent en 2001. Le concept tenait en quelques lignes : un fichier se découpe en segments. Vous téléchargez ces segments depuis plusieurs sources à la fois. Pendant ce temps, vous partagez déjà les morceaux que vous avez reçus avec d’autres. Plus il y a de monde, mieux ça marche. Cohen baptisa ce mécanisme de réciprocité tit-for-tat, un nom qui résume bien l’esprit : donnant-donnant.

L’été 2001 vit sortir la première version bêta. Cohen présenta son protocole l’année suivante lors d’une conférence. Son ambition initiale était de distribuer des distributions Linux. Pourtant, l’architecture technique cachait une vraie finesse. Les fichiers .torrent contiennent juste les métadonnées : nom du fichier, taille, découpage, adresse du tracker. Ce tracker coordonne les échanges entre participants sans jamais stocker le moindre octet de contenu.

Deux algorithmes firent la différence. Le premier, dit rarest first, privilégie les segments les moins répandus dans le réseau. Le second, le choking, régule les transferts en favorisant ceux qui partagent activement. Ces mécanismes garantissent qu’un fichier reste disponible quand des milliers d’utilisateurs le téléchargent simultanément.

Le succès fut au rendez-vous. Dès 2005, BitTorrent représentait une part conséquente du trafic Internet mondial. Certains l’utilisèrent pour des contenus piratés, comme avec tous les protocoles de partage avant lui. D’autres y virent une aubaine. Opera intégra BitTorrent dans son navigateur cette année-là et s’en servit pour diffuser ses mises à jour. Blizzard Entertainment l’adopta pour distribuer les correctifs de World of Warcraft. L’Internet Archive suivit en 2012 pour rendre accessibles ses collections numériques.

Côté mécanique interne du protocole, les fichiers se découpent en blocs de 256 Ko. Chaque bloc reçoit un identifiant unique via un hachage SHA-1 qui garantit son intégrité. Le système maintient une liste dynamique des pairs connectés et ajuste en permanence les transferts selon les performances de chaque connexion. Cette décentralisation assure robustesse et capacité à passer à l’échelle.

Cohen avait visé juste : un système pair-à-pair pouvait résoudre les problèmes de distribution massive. Les économies de bande passante séduisirent les entreprises. Distribuer une mise à jour logicielle de plusieurs gigaoctets à des millions d’utilisateurs coûtait une fortune avec l’approche traditionnelle. BitTorrent changeait la donne.

Le code source ouvert favorisa l’émergence d’une communauté de développeurs. La simplicité relative du protocole accéléra son adoption. Les mécanismes d’incitation au partage garantirent son efficacité pratique. Ces trois éléments expliquent pourquoi BitTorrent s’imposa aussi largement.

Plus de vingt ans après, le protocole tourne toujours. Les usages ont évolué, les technologies concurrentes se sont multipliées, mais BitTorrent est encore pertinent pour distribuer des fichiers lourds. Une idée née de la frustration face aux limites techniques peut transformer durablement l’usage d’Internet.

Haut de page

Apple Mac OS X

Apple traversait une période difficile dans les années 1990. Son système d’exploitation Mac OS, né en 1984 avec le premier Macintosh, accusait un retard technique face à la concurrence. Conçu à l’origine pour un ordinateur de 128 Ko de mémoire, il ignorait le multitâche préemptif et la protection mémoire. Le MultiFinder, arrivé en 1988, n’apportait qu’une forme rudimentaire de multitâche coopératif. L’architecture vieillissait mal. Vers le milieu des années 1990, Apple s’appuyait sur un code vieux de dix ans, initialement écrit pour les processeurs Motorola 68000, tant bien que mal adapté aux PowerPC. Une partie du noyau tournait même dans un émulateur 68K, ce qui n’arrangeait rien aux performances.

Apple lance alors en 1994 le projet Copland, avec l’ambition de créer un système moderne qui garderait l’interface et la compatibilité Mac OS. La société multiplie les présentations aux développeurs, publie des documentations, mais Copland ne parvient jamais à une stabilité acceptable. Le projet s’arrête en 1996. Apple se retrouve dans l’urgence.

La solution vient d’ailleurs, par le rachat de NeXT, la société que Steve Jobs avait fondée après son départ d’Apple en 1985. NeXT avait bâti NEXTSTEP, un système remarquable basé sur le micronoyau Mach de l’université Carnegie Mellon. NEXTSTEP mariait ce noyau moderne avec une couche BSD et proposait dès 1989 le multitâche préemptif, la protection mémoire, le support de plusieurs architectures processeur et un environnement de développement orienté objet en Objective-C.

Transformer NEXTSTEP en Mac OS X demande un travail considérable. Apple actualise le code Mach 2.5 vers la version 3.0, met à jour la partie BSD avec du code de 4.4BSD et FreeBSD, ajoute le support des systèmes de fichiers HFS et des protocoles réseau Apple. L’équipe développe I/O Kit, un nouveau système de pilotes qui remplace l’ancien DriverKit. Cette couche, écrite dans un sous-ensemble du C++, autorise une approche orientée objet pour gérer les périphériques.

L’architecture de Mac OS X repose sur la modularité. Le noyau XNU (X is not UNIX) combine trois composants : Mach gère les ressources système, BSD assure la compatibilité UNIX et les services réseau, I/O Kit s’occupe des pilotes. Cette organisation facilite la maintenance et les évolutions. Les pilotes se chargent dynamiquement sous forme de KEXTs (Kernel Extensions), des modules qu’on ajoute sans recompiler le noyau.

Pour la transition des applications, Mac OS X propose plusieurs environnements. Cocoa, héritier des bibliothèques OpenStep de NeXT pour créer des applications natives. Carbon offre une version modernisée des API Mac OS classiques et facilite le portage des logiciels existants. Un environnement Classic exécute les anciennes applications Mac OS sans modification.

Les innovations vont au-delà du noyau. Le système introduit Mach-O, un format binaire universel capable de contenir du code pour différentes architectures dans un fichier. Cette caractéristique simplifie la distribution des logiciels et prépare les transitions matérielles futures. Le démarrage s’appuie sur OpenFirmware pour les PowerPC, puis sur EFI pour les processeurs Intel, apportant des capacités étendues par rapport au BIOS traditionnel.

La gestion mémoire témoigne du soin apporté aux performances. Sur les systèmes x86, Mac OS X adopte une approche 4/4 où l’espace utilisateur et le noyau ne sont pas mappés simultanément, contrairement à la répartition classique 3/1 ou 2/2 Go. Cette conception tire mieux parti de la mémoire disponible.

Le passage aux processeurs Intel en 2005-2006 démontre la souplesse de l’architecture. La technologie Rosetta, basée sur QuickTransit de Transitive, exécute les applications PowerPC sur les nouveaux processeurs x86 par recompilation dynamique. Le noyau 32 bits continue de fonctionner sur les machines 64 bits en mode de compatibilité, préservant la compatibilité avec les extensions existantes tout en donnant accès aux fonctionnalités 64 bits.

L’influence de Mac OS X dépasse les ordinateurs de bureau. Le système sert de base à iOS pour l’iPhone et l’iPod touch, en adaptant le noyau XNU et certains composants à l’architecture ARM. Cette réutilisation du code donne à Apple une cohérence technologique entre ses plateformes.

La publication du code source de Darwin, le cœur de Mac OS X, sous licence Apple Public Source License en 1999 marque un tournant dans la stratégie d’Apple. Cette ouverture autorise les développeurs à étudier l’implémentation du système et à y contribuer. Des projets comme PureDarwin montrent qu’on peut créer des systèmes dérivés.

Mac OS X réalise une synthèse entre l’héritage UNIX, les innovations de NeXT et le savoir-faire d’Apple en matière d’interfaces. Le système a permis à Apple de moderniser sa plateforme en préservant la compatibilité avec les applications existantes. Cette base technique solide a soutenu l’expansion d’Apple vers de nouveaux marchés et continue d’évoluer avec les besoins des utilisateurs et les avancées technologiques.

Haut de page

SHA-256

La fin des années 1970 marque les débuts des fonctions de hachage cryptographique. Ces algorithmes, qui transforment n’importe quelle donnée en une empreinte numérique de taille fixe, allaient devenir des briques majeures de la sécurité informatique.

En 1976, Whitfield Diffie et Martin Hellman publient leur article fondateur sur la cryptographie à clé publique. Ils y expliquent qu’une fonction de hachage à sens unique est nécessaire pour construire des signatures numériques. Les premiers travaux concrets arrivent peu après : Michael Rabin propose une conception basée sur le chiffrement DES qui produit un résultat de 64 bits. Gideon Yuval démontre qu’on peut trouver des collisions en exploitant le paradoxe des anniversaires avec une complexité de 2^(n/2). Ralph Merkle établit quant à lui les exigences de base : résistance aux collisions, aux pré-images secondaires et aux pré-images.

Les années 1980 voient fleurir de nombreuses propositions. La communauté cryptographique réalise l’importance de ces primitives pour sécuriser les communications numériques. Ivan Damgård formalise en 1987 la définition de la résistance aux collisions. Deux ans plus tard, Moni Naor et Moti Yung introduisent une variante appelée Universal One Way Hash Functions.

Au tournant des années 1990, Ronald Rivest crée MD5, une évolution de MD4 optimisée pour le logiciel. Cette fonction connaît un succès rapide : elle s’avère environ dix fois plus rapide que DES en implémentation logicielle. Surtout, MD5 échappe aux restrictions d’exportation qui pèsent sur les algorithmes de chiffrement et peut être utilisée librement.

La National Security Agency développe alors la famille SHA (Secure Hash Algorithm). Le NIST publie SHA-0 en 1993. Mais l’agence découvre une vulnérabilité deux ans plus tard et sort une version corrigée baptisée SHA-1. En 2001, face aux progrès de la cryptanalyse et à la montée en puissance des ordinateurs, la NSA conçoit la famille SHA-2. SHA-256 en fait partie.

SHA-256 produit une empreinte de 256 bits et travaille sur des mots de 32 bits. L’algorithme traite les messages par blocs de 512 bits après un padding spécifique. Le processus comprend une expansion de message et une compression itérative basée sur une fonction de Merkle-Damgård. Cette construction garantit que la sécurité de la fonction de compression s’étend à celle de la fonction de hachage complète.

Les premières fissures dans MD5 apparaissent en 1992. Den Boer et Bosselaers trouvent des collisions pour la fonction de compression. En 1996, Hans Dobbertin découvre des collisions pour MD5 avec une valeur initiale aléatoire. Ces résultats n’inquiètent pas encore vraiment la communauté.

Tout bascule en 2004. L’équipe de Xiaoyun Wang réalise une percée en perfectionnant la cryptanalyse différentielle. Leurs travaux permettent de trouver des collisions pour MD5 en quelques millisecondes. Les techniques développées par Wang réduisent considérablement la marge de sécurité de SHA-1. La communauté cryptographique se lance dans une vague de recherches.

Le 31 décembre 2008, Alexander Sotirov et son équipe frappent un grand coup. Ils créent un certificat CA malveillant qui exploite les collisions de MD5. Cette attaque permet théoriquement d’usurper l’identité de n’importe quel site web. L’industrie comprend qu’il faut abandonner MD5, malgré sa présence massive dans les systèmes existants.

Le NIST lance en novembre 2007 une compétition pour sélectionner SHA-3, un nouvel algorithme de hachage standard. L’objectif : diversifier les options disponibles et préparer le remplacement de SHA-2 si besoin. La compétition attire 64 soumissions dont 51 sont retenues pour le premier tour. En juillet 2009, 14 candidats accèdent au second tour.

Pendant ce temps, SHA-256 tient bon. Les meilleures attaques connues ne compromettent qu’un nombre limité d’étapes de l’algorithme. SHA-256 résiste aux techniques qui ont cassé MD5 et affaibli SHA-1. Cette solidité explique son adoption croissante dans de nombreux protocoles et applications de sécurité.

L’arrivée de Bitcoin en 2009 donne une dimension inattendue à SHA-256. La preuve de travail de la cryptomonnaie repose sur la recherche de collisions partielles, exploitant la résistance aux préimages de la fonction. Cette application démontre la polyvalence de SHA-256.

On retrouve aussi SHA-256 dans l’Internet des objets, les systèmes embarqués distribués, la génération de nombres aléatoires et le chiffrement de données. Cette diversification témoigne de sa maturité et de la confiance qu’il inspire.

Cette histoire montre qu’il faut toujours disposer d’alternatives fiables quand des faiblesses apparaissent dans les standards existants. Elle rappelle l’intérêt de maintenir des options standardisées. La longévité de SHA-256 prouve qu’une conception rigoureuse anticipe les évolutions de la cryptanalyse et de la puissance de calcul disponible.

Haut de page

Microsoft .NET Framework

Lors de la Professional Developers Conference de Microsoft en 2000, la société dévoila alors .NET, un nouveau framework pour Windows qui allait redéfinir la manière dont on construisait les logiciels sur sa plateforme. Ce projet, qui avait démarré sous l’appellation peu évocatrice de « Next Generation Windows Services », représentait plus qu’une simple mise à jour des outils existants. Les développeurs reçurent dès cette année-là les premières versions bêta de .NET 1.0.

Microsoft voulait résoudre plusieurs problèmes à la fois. D’une part, Java gagnait du terrain et la société de Redmond avait besoin d’une réponse crédible. D’autre part, le développement sur Windows restait fragmenté entre différentes technologies qui ne communiquaient pas toujours bien entre elles. L’idée était de créer quelque chose de plus cohérent, qui simplifierait vraiment le travail des programmeurs. Au cœur de cette nouvelle plateforme se trouvait le Common Language Runtime, un environnement d’exécution qui prenait en charge automatiquement des tâches auparavant complexes comme la gestion de la mémoire ou les aspects de sécurité.

La première mouture commerciale arriva en 2002 avec Visual Studio .NET et le framework 1.0. Cette version posait les bases d’une architecture qui allait traverser les années suivantes : une bibliothèque de classes commune, un système de types unifié, et la possibilité d’écrire du code dans plusieurs langages comme C# ou Visual Basic .NET. La version 1.1 suivit en 2003, apportant son lot d’améliorations de performances et de nouvelles fonctionnalités.

Avec Visual Studio 2005 et le framework 2.0, les choses prirent une autre dimension. Les génériques firent leur apparition, autorisant les développeurs à écrire du code plus robuste et réutilisable. Cette version consolida .NET comme une plateforme incontournable. L’année 2008 marqua un nouveau tournant avec le « multi-targeting », qui donnait la liberté de cibler simultanément différentes versions du framework – la 2.0, la 3.0 et la 3.5.

Les versions se succédèrent ensuite à un rythme régulier. Visual Studio 2010 intégra .NET 4.0, puis la version 2012 accueillit la 4.5. Cette progression permit à la plateforme de s’adapter aux exigences nouvelles du développement logiciel, entre autres dans le web et le cloud.

L’architecture technique de .NET repose sur un empilement de couches bien pensées. À la base, le CLR exécute le code et gère automatiquement la mémoire grâce à son ramasse-miettes. Au-dessus viennent les bibliothèques de classes, qui fournissent tout le nécessaire pour bâtir des applications. Selon les besoins, le framework propose différents environnements : applications console pour les traitements sans interface, Windows Forms pour les logiciels de bureau classiques, ASP.NET pour le web.

Le modèle de compilation de .NET se distingue par une approche originale. Le code source ne se transforme pas directement en langage machine. Il passe d’abord par une étape intermédiaire, le MSIL (Microsoft Intermediate Language). Cette stratégie offre quelques bénéfices : le code est portable entre différentes architectures, on peut l’optimiser au moment de l’exécution, et les langages de programmation sont interopérables.

Cette interopérabilité entre langages constitue d’ailleurs l’un des atouts de .NET. Au-delà de C# et Visual Basic .NET, la plateforme accueille F#, Iron Python ou encore Iron Ruby. Le Common Type System définit comment déclarer et utiliser les types de données, tandis que le Common Language Specification établit les règles garantissant que tous ces langages peuvent travailler ensemble.

Anders Hejlsberg a joué un rôle déterminant dans cette histoire. Architecte en chef de C#, il avait auparavant travaillé chez Borland sur Turbo Pascal et Delphi. Cette expérience nourrit la conception du framework. Sous son impulsion, C# devint le langage phare de .NET, intégrant régulièrement des innovations comme LINQ qui permettait d’écrire des requêtes directement dans le code.

L’influence de .NET sur l’industrie du logiciel fut massive. La plateforme transforma la façon dont les entreprises développaient leurs applications Windows, en leur donnant un environnement réellement productif et moderne. La transition vers le web devint plus simple avec ASP.NET, qui rendait moins ardue la création d’applications web solides.

Le framework introduisit des concepts avancés que peu de plateformes offraient à l’époque. La programmation orientée aspect, la réflexion, les attributs : autant d’outils qui autorisaient la construction d’applications plus sophistiquées. La gestion automatique de la mémoire libéra les programmeurs de tâches ingrates et sources d’erreurs. Le déploiement devint moins problématique grâce à l’installation automatique des composants nécessaires.

Microsoft enrichit progressivement .NET pour suivre les évolutions technologiques. Le support du cloud computing, le développement mobile, les applications universelles Windows : la plateforme s’adapta continuellement aux nouveaux paradigmes et aux attentes des développeurs.

La création de .NET représenta un investissement colossal. Des centaines d’ingénieurs y travaillèrent pendant des années. Cet effort paya : le framework devint un standard de fait pour le développement sur Windows, adopté par des millions de développeurs à travers le monde. Son influence perdure avec .NET Core, sa version moderne et multiplateforme.

Haut de page

Mozilla Firefox

En 1993, le navigateur Mosaic voit le jour au National Center for Supercomputing Applications. Son succès ne tarde pas. Marc Andreessen, l’un des créateurs, fonde l’année suivante Netscape Communications Corporation. Le nouveau navigateur, Netscape Navigator, s’empare du marché du Web.

Microsoft réplique en développant Internet Explorer qu’il intègre directement à Windows 95. La stratégie fonctionne. Netscape perd progressivement du terrain. Face à ce recul, l’entreprise prend en 1998 une décision audacieuse : elle rend public le code source de son navigateur à travers le projet Mozilla. L’organisation mozilla.org naît pour coordonner ce développement communautaire.

La situation se complique en 1999 quand AOL rachète Netscape. L’intégration se passe mal. Mitchell Baker, juriste chez Netscape puis chez AOL, dirige mozilla.org avec le titre plutôt original de « Chief Lizard Wrangler ». Son équipe continue le développement tout en gardant son autonomie face à AOL.

Après quatre ans de travail, Mozilla sort en 2002 dans sa première version stable. Le navigateur regorge de fonctionnalités : onglets, blocage des pop-ups, gestionnaire de téléchargements. Mais son interface trop chargée rebute le grand public. Une petite équipe décide alors de repartir sur des bases plus simples.

Le nouveau projet passe par plusieurs noms : Phoenix, Firebird, avant de devenir Firefox pour éviter des conflits de marques. La version 1.0 débarque en novembre 2004. Le succès est immédiat. Firefox apporte des innovations qui vont faire école : les onglets intégrés nativement, un système d’extensions modulaire, une interface épurée. L’approche tranche avec ce qui existe alors.

AOL abandonne Netscape Navigator en 2003. Mozilla se transforme en fondation indépendante à but non lucratif, avec 2 millions de dollars d’AOL comme capital de départ. La Mozilla Foundation peut ainsi développer Firefox en toute liberté, fidèle aux principes du logiciel libre et d’un Web ouvert.

Le navigateur arrive au bon moment. Internet Explorer stagne techniquement. Firefox propose une vraie alternative, plus sûre, qui respecte mieux la vie privée. Son développement ouvert attire une communauté mondiale de contributeurs. La fondation signe des accords avec des moteurs de recherche, notamment Google, ce qui génère des revenus sans compromettre l’indépendance du projet.

De 2004 à 2008, Firefox grignote des parts de marché à Internet Explorer. Il atteint 20% du marché mondial en 2008. Un projet open source concurrence frontalement un logiciel propriétaire dominant. Firefox pousse les standards du Web et l’interopérabilité, là où Microsoft favorisait son écosystème fermé.

Google Chrome apparaît en 2008. Ce navigateur, basé d’abord sur WebKit puis sur Blink, s’impose peu à peu. Firefox conserve toutefois ses utilisateurs fidèles, attachés à sa vision d’un Web ouvert et respectueux des libertés individuelles.

L’explosion du mobile amène Mozilla à lancer Firefox OS en 2013. Ce système d’exploitation mobile, construit sur les technologies Web, veut offrir une alternative ouverte à iOS et Android. Malgré des partenariats avec des fabricants, Firefox OS ne décolle pas. Le projet s’arrête en 2015.

En 2024, Firefox compte environ 200 millions d’utilisateurs. Le navigateur innove toujours sur la protection de la vie privée, les performances, le respect des standards. La Mozilla Foundation poursuit son combat pour un Internet ouvert et accessible à tous.

Firefox montre qu’un projet open source peut bousculer un marché dominé par des géants commerciaux. Le navigateur a prouvé l’importance d’une gouvernance transparente et d’une communauté engagée. Le modèle économique de Mozilla fait cependant figure d’exception. La fondation tire des revenus substantiels de ses partenariats avec les moteurs de recherche sans renier sa mission non lucrative. Cet équilibre reste rare dans le monde du logiciel.

Haut de page

Apple Xserve

En mai 2002, Apple revient sur le marché des serveurs avec le Xserve, un ordinateur pensé pour les baies de serveurs. L’entreprise n’avait plus tenté l’aventure depuis l’échec cuisant de ses Network Servers dans les années 1990. À cette époque, les Mac équipaient bon nombre d’entreprises du Fortune 500, mais ils restaient aux portes de leurs départements informatiques, sans jamais vraiment y pénétrer.

Le Xserve adopte un format 1U compact de 4,4 cm de hauteur. La première génération embarque des processeurs PowerPC G4 à 1 GHz et de la mémoire DDR, une première chez Apple. L’architecture du système repose sur quatre baies de disques durs extractibles à chaud, chacune disposant de son propre bus Ultra ATA-100. Ces modules propriétaires existent en 60 ou 120 Go, soit atteindre 480 Go en tout au maximum.

Côté connectique, l’appareil propose deux ports Ethernet Gigabit, trois ports FireWire, deux USB et un port série pour les connexions en terminal. Le panneau avant affiche en couleur l’activité des disques, la charge des processeurs et l’état du réseau. Apple lance deux versions : 2 999 dollars pour le monoprocesseur, 3 999 dollars pour le biprocesseur, licence illimitée de Mac OS X Server comprise.

La machine évolue vite. Dès 2004, le Xserve G5 prend le relais avec des PowerPC G5 montant jusqu’à 2 GHz. Cette montée en puissance impose une refonte complète du châssis pour évacuer la chaleur, ce qui réduit le nombre de baies. Cette version introduit la mémoire ECC, une nouveauté dans le catalogue Apple, et passe aux disques SATA.

Apple complète son offre avec le Xserve RAID, un système de stockage en rack 3U. Ce périphérique accueille 14 modules de 180 Go et dialogue avec le serveur via des canaux Fibre Channel à 2 Gb/s, pour des débits de 400 Mo/s. Son prix défie la concurrence : en 2004, le coût par gigaoctet s’établit à 3,14 dollars, loin derrière Dell (9,05 dollars) et HP (11,39 dollars).

La bascule vers Intel intervient en 2006. Le Xserve adopte des Xeon 64 bits grimpant jusqu’à 3 GHz, multipliant par cinq les performances du G5. Ces processeurs dégagent moins de chaleur, ce qui autorise l’ajout d’alimentations redondantes et fait grimper la capacité de stockage à 2,5 To. Les options se multiplient : graveur DVD double couche, 32 Go de RAM, carte RAID intégrée.

Les dernières déclinaisons sortent entre 2008 et 2009 avec des Xeon quadricœurs de série 5400. Ces machines atteignent des sommets grâce à leur conception aboutie : bus frontaux indépendants à 1 600 MHz, mémoire DDR2 ECC à 800 MHz, connecteurs PCI Express 2.0. Le stockage franchit un cap avec des disques SAS à 15 000 tr/min avec un débit de 125 Mo/s et des temps d’accès de 3,5 ms.

Mac OS X Server constitue l’atout majeur du Xserve. Ce système certifié UNIX intègre partage de fichiers et d’imprimantes, hébergement web, messagerie, streaming multimédia. La version 10.5 Leopard Server enrichit les fonctions collaboratives avec iCal Server pour les calendriers, Wiki Server pour le travail d’équipe et Podcast Producer pour publier automatiquement des contenus multimédias.

Le support technique s’adapte aux besoins des entreprises : assistance téléphonique et e-mail disponible jour et nuit. Des kits de pièces détachées permettent aux techniciens d’intervenir sur site. L’application Server Monitor surveille en continu les composants critiques : températures, ventilateurs, alimentations, disques durs, interfaces réseau.

Apple cesse la commercialisation du Xserve RAID en février 2008, lui préférant des solutions Promise Technology certifiées pour Xsan 2. Le serveur Xserve disparaît en janvier 2011 mais il reste un bel exemple de savoir-faire technique dans le domaine des serveurs d’entreprise. La société recommande alors d’utiliser des Mac mini ou Mac Pro configurés en serveurs. Ce retrait traduit un changement de priorités chez Apple, qui se tourne davantage vers le grand public et les professionnels que vers les départements informatiques. Durant neuf années, Xserve a proposé une alternative élégante aux solutions classiques, mariant performances, simplicité d’usage et encombrement réduit.

Haut de page

Tor

Dans les années 1990, le Naval Research Laboratory américain travaillait sur un problème qui semblait assez éloigné des préoccupations du grand public : comment protéger les communications de ses agents à travers le monde ? La solution trouvée s’appelait « Onion Routing », le routage en oignon. Personne n’imaginait alors que cette technologie militaire deviendrait l’un des outils les plus importants pour défendre la vie privée sur Internet.

Le principe technique est ingénieux. Chaque message traverse plusieurs serveurs intermédiaires, chiffré en couches successives comme les pelures d’un oignon. À chaque étape, un serveur retire une couche et transmet le paquet au relais suivant, sans jamais connaître ni l’origine ni la destination finale. Un observateur qui intercepte le trafic ne voit qu’un nœud parmi d’autres, incapable de remonter la chaîne complète.

Cette époque voyait aussi l’émergence des cypherpunks, ces technologues libertariens convaincus que le chiffrement représentait un rempart contre la surveillance étatique. La rencontre entre ces militants et les chercheurs militaires, lors d’un séminaire universitaire, a créé une alliance improbable. Les militaires avaient besoin d’un vaste réseau d’utilisateurs civils pour noyer leurs communications sensibles dans un trafic abondant. Les cypherpunks voulaient démocratiser les technologies de protection de la vie privée. Chacun y trouvait son compte.

En 2002, le protocole a été réimplémenté pour le grand public et publié sous licence libre. Cette transparence du code source comptait beaucoup : comment faire confiance à un outil de sécurité financé par le département d’État américain sans pouvoir vérifier son fonctionnement ? La communauté pouvait désormais l’auditer librement.

Les débuts ont soulevé des questions techniques épineuses. Fallait-il ajouter ces données factices qui masquent les véritables communications ? La sécurité théorique y gagnait, mais les connexions devenaient d’une lenteur insupportable. Les développeurs ont tranché : un réseau trop lent ne séduirait jamais assez d’utilisateurs. Or la force de Tor repose justement sur le nombre : plus les profils sont variés, mieux les communications sensibles se fondent dans la masse du trafic quotidien.

Cette philosophie a guidé toute l’évolution du projet. Tor devait rester accessible au plus grand nombre tout en maintenant un haut niveau de sécurité. Le pari a fonctionné. Journalistes protégeant leurs sources, militants des droits humains dans des régimes autoritaires, entreprises soucieuses de leurs secrets industriels, simples citoyens refusant le traçage publicitaire : tous ont trouvé dans ce réseau une réponse à leurs besoins.

Le réseau permet aussi d’héberger des services cachés, reconnaissables à leurs adresses en « .onion ». L’emplacement physique de ces sites est masqué, ce qui soulève des controverses. Silk Road, cette place de marché illégale fermée par le FBI, utilisait Tor. Mais réduire le réseau à ses usages criminels serait malhonnête. Les révélations d’Edward Snowden en 2013 ont montré que la NSA échouait à compromettre Tor à grande échelle, confirmant sa robustesse technique face à l’adversaire le plus puissant du monde.

L’architecture repose sur des milliers de serveurs volontaires dispersés à travers le monde. Des individus, des associations, parfois des universités, font tourner ces relais par conviction : préserver un Internet libre. Cette infrastructure décentralisée constitue un rempart technique contre la surveillance généralisée. Elle illustre aussi qu’une gouvernance alternative des réseaux est possible, en dehors des logiques commerciales ou étatiques.

L’innovation majeure de Tor ne concerne pas tant le chiffrement des contenus que la protection des métadonnées. Qui parle à qui, quand, combien de fois ? Ces informations révèlent souvent plus que le contenu des messages eux-mêmes. En s’attaquant à ce problème structurel, le réseau a inspiré de nombreux autres projets de protection de la vie privée.

La pérennité de Tor tient à un paradoxe fécond. Le département d’État américain continue de financer son développement pour promouvoir la liberté d’expression dans les pays censurant Internet. Des militants l’utilisent parfois pour échapper à la surveillance occidentale. Cette dualité, loin d’affaiblir le projet, renforce sa légitimité et sa résilience. Servir simultanément des intérêts étatiques et citoyens n’est pas une contradiction mais une condition de survie.

Face aux limites des modèles mathématiques abstraits, les développeurs ont privilégié l’observation empirique des menaces réelles et des usages concrets. Cette approche pragmatique a produit un système imparfait mais efficace contre la surveillance de masse. Les défis techniques initiaux ont forgé cette méthode : mieux vaut un outil utilisable qu’une solution théoriquement parfaite mais inutilisable en pratique.

Le projet montre qu’une infrastructure alternative peut émerger des marges d’Internet pour devenir un pilier de la liberté d’expression en ligne. Des communautés techniques peuvent créer des outils servant l’intérêt général, en dehors des circuits habituels. Le routage en oignon né dans un laboratoire militaire est devenu un bien commun numérique.

Haut de page

Apple iTunes

En 2000, l’industrie musicale traverse une crise sans précédent. Le partage illégal de fichiers MP3 sur Internet explose, les grandes maisons de disques s’accrochent à leurs vieux modèles, et les utilisateurs désertent les magasins de disques. Steve Jobs, de retour chez Apple depuis 1997, y voit une opportunité : celle de créer un écosystème cohérent autour de la musique numérique.

L’histoire commence véritablement en 2001 avec le premier iPod. Ce baladeur élégant avait besoin d’un logiciel pour que les gens puissent y transférer leur musique. iTunes naît de cette nécessité pratique : offrir aux possesseurs de Mac un moyen simple de convertir leurs CD en fichiers numériques et de les synchroniser avec leur appareil. Rien de nouveau en soi, mais une solution qui fonctionnait vraiment.

Deux ans plus tard, en 2003, tout bascule. Apple lance l’iTunes Store, une boutique en ligne où l’on achète des morceaux à l’unité pour 99 cents. Le concept était audacieux à l’époque. Les maisons de disques vendaient des albums complets, pas des chansons isolées. Jobs doit négocier ferme avec les cinq majors du disque. Son argument ? La simplicité d’utilisation et le prix attractif détourneront les gens du piratage. Les patrons des labels, sceptiques mais dos au mur, finissent par accepter.

Le succès dépasse toutes les attentes. Un million de morceaux vendus en une semaine. Les utilisateurs apprécient de pouvoir écouter un extrait avant d’acheter, de ne payer que pour les chansons qu’ils veulent vraiment. L’interface est intuitive, sans fioritures inutiles. iTunes introduit des listes de lecture intelligentes, des classements, des suggestions personnalisées qui changent la façon dont les gens découvrent de la musique.

En octobre 2003, Apple fait un choix surprenant : adapter iTunes pour Windows. La firme de Cupertino abandonne son exclusivité habituelle et ouvre ses portes à des millions de nouveaux utilisateurs. Cette décision stratégique élargit l’audience du service bien au-delà des aficionados de Mac. N’importe qui possédant un PC peut désormais acheter de la musique en ligne et synchroniser son iPod.

Entre 2004 et 2006, le catalogue musical s’enrichit constamment. Les accords avec des labels indépendants multiplient l’offre disponible. iTunes ne se contente plus de vendre de la musique : la plateforme accueille des podcasts, puis des séries télévisées, enfin des films. Le logiciel devient peu à peu un hub multimédia complet, loin de sa vocation première de simple gestionnaire de bibliothèque musicale.

L’App Store voit le jour en 2008, destiné aux applications pour iPhone et iPod Touch. iTunes se transforme en carrefour numérique où convergent musique, vidéos, applications, livres numériques. Le système de paiement unifié et la synchronisation automatique entre appareils séduisent toujours plus d’utilisateurs. Apple a réussi son pari : créer un écosystème dont on a du mal à sortir une fois qu’on y est entré.

L’impact sur l’industrie musicale est difficile à mesurer, mais quelques chiffres parlent d’eux-mêmes. En 2010, iTunes est le plus grand vendeur de musique aux États-Unis, devant Walmart. Les ventes physiques continuent de s’effondrer, certes, mais les revenus de la distribution numérique compensent une partie des pertes. Le service a légitimé l’achat de musique en ligne et établi un modèle économique viable pour l’ère numérique.

La technologie évolue en même temps que les usages. L’utilisateur accède à sa bibliothèque depuis n’importe quel appareil grâce au stockage dans le cloud, introduit avec iTunes Match en 2011. Des fonctionnalités de streaming apparaissent progressivement, répondant aux nouveaux modes de consommation musicale. Le format AAC choisi par Apple offre une meilleure qualité sonore que le MP3 pour une taille de fichier comparable. La protection numérique FairPlay, moins contraignante que celle des concurrents, autorise la lecture sur plusieurs appareils tout en rassurant les maisons de disques.

En 2019, Apple annonce la fin d’iTunes. Le logiciel sera séparé en applications distinctes pour la musique, les podcasts et la vidéo sur macOS. iTunes a prouvé qu’une interface soignée, associée à un modèle commercial adapté, satisfait les consommateurs sans sacrifier les intérêts des créateurs de contenus. La plateforme a redéfini la distribution de contenu numérique et inspiré d’innombrables services qui ont suivi.

Haut de page

Skype

Nous sommes en 1998. Niklas Zennström travaille pour Tele2, un opérateur téléphonique suédois, lorsqu’il propose à sa direction un projet de téléphonie par Internet. L’idée ne trouve pas preneur sur le moment, mais elle continue de travailler l’esprit de Zennström. Avec le Danois Janus Friis, il lance d’abord Kazaa, ce logiciel de partage de fichiers en peer-to-peer qui fera parler de lui, avant de revenir à son projet initial : la téléphonie sur Internet.

En 2000, le portail Everyday.com rassemble une équipe au sein de laquelle Zennström et Friis y retrouvent trois développeurs estoniens : Jaan Tallinn, Ahti Heinla et Priit Kasesalu. Toivo Annus les rejoint bientôt. Ces développeurs viennent de Bluemoon, une société estonienne où ils ont acquis leur savoir-faire technique en créant des jeux vidéo à l’époque soviétique. Le groupe forme le noyau qui donnera naissance à Skype.

La technologie peer-to-peer, celle que l’équipe a rodée avec Kazaa, devient le cœur du système. Les utilisateurs communiquent directement entre eux, sans transiter par des serveurs centraux. Les coûts d’infrastructure fondent, la qualité des communications grimpe. Le nom Skype vient de Sky peer-to-peer, d’abord pensé comme « Skyper », puis raccourci quand ils constatent que le nom de domaine n’est pas disponible.

Trouver des financements s’avère ardu. Les controverses juridiques qui entourent Kazaa ont écorné la réputation des fondateurs. Il faut attendre juillet 2002 pour que le fonds Draper Richards accepte d’investir 250 000 dollars contre 5% du capital. Une valorisation modeste qui se révélera, par la suite, un placement spectaculaire.

Le 29 août 2003, Skype ouvre ses portes au public. Une vingtaine de personnes ont développé ce logiciel qui propose des appels gratuits d’ordinateur à ordinateur. La simplicité d’usage et la qualité sonore séduisent d’emblée. Le premier jour, 10 000 personnes téléchargent l’application. Quelques mois plus tard, elles sont un million.

L’entreprise cultive un style bien à elle. Les bureaux n’affichent aucune enseigne, héritage des déboires juridiques de Kazaa qui ont appris aux fondateurs la discrétion. À Tallinn, une piscine gonflable trône dans la salle de réunion. L’équipe code au fil de l’eau : dès qu’une fonctionnalité est conçue, elle est intégrée au logiciel.

En 2004, Skype lance SkypeOut. Le service s’ouvre aux appels vers les téléphones fixes et mobiles, à prix cassés. Les appels entre utilisateurs Skype restent gratuits, mais c’est le début de la monétisation. Les investisseurs se pressent. L’entreprise lève 18 millions de dollars auprès d’Index Ventures et Bessemer Venture Partners, entre autres.

La croissance fulgurante attire les géants. En septembre 2005, eBay met la main sur Skype pour 2,6 milliards de dollars. Les développeurs estoniens sont millionnaires du jour au lendemain, mais la culture d’entreprise commence à se fissurer. Les tensions montent entre les équipes de Tallinn et celles de Londres. L’intégration d’une startup dans une grande entreprise montre ses limites et les relations se dégradent vite. Les fondateurs ont conservé la propriété intellectuelle de la technologie peer-to-peer via leur société Joltid, ce qui crée une situation inextricable. Microsoft rachète finalement Skype en 2011 pour 8,5 milliards de dollars. Une nouvelle page se tourne.

Sous la houlette de Microsoft, Skype évolue. Les révélations d’Edward Snowden en 2013 montrent que le service, autrefois réputé pour sa confidentialité, collabore désormais avec les agences de renseignement. La startup rebelle est devenue un acteur institutionnel du monde numérique.

L’impact de Skype sur les télécommunications reste massif. Le service a rendu les appels internationaux gratuits accessibles à tous, popularisé la vidéoconférence. En 2012, Skype gère 167 milliards de minutes d’appels internationaux, plus que tous les opérateurs télécoms traditionnels réunis.

Les fondateurs ont pris des chemins différents. Jaan Tallinn investit dans des projets liés à la survie de l’humanité ; il considère désormais le temps plus précieux que l’argent. L’équipe estonienne, malgré sa fortune, garde une certaine modestie. Pas de dépenses ostentatoires, des investissements réfléchis.

Skype a transformé un projet technique ambitieux en outil de communication universel. Le service a montré la puissance du peer-to-peer et l’importance d’une interface simple. Une technologie peut évoluer, passant de l’innovation de rupture à l’institutionnalisation, tout en restant utile à des millions de personnes chaque jour.

Haut de page

WordPress

En 2003, un logiciel baptisé b2/cafelog connaît une fin brutale. Son créateur abandonne le projet, laissant derrière lui un code source libre que deux développeurs, Matt Mullenweg et Mike Little, décident de reprendre. Mullenweg n’a alors que 19 ans et ses compétences en programmation viennent d’un apprentissage autodidacte, loin des cursus universitaires traditionnels. De cette initiative naît WordPress, qui deviendra l’un des systèmes de gestion de contenu les plus utilisés au monde.

Les premières versions du logiciel affichent deux priorités : le respect des standards du web et une installation simple. L’équipe met au point le Famous Five Minute Installation, un processus d’installation qui ne demande que cinq minutes là où les concurrents exigent souvent plus d’une demi-heure. Cette philosophie d’accessibilité trouve ses racines dans les valeurs du logiciel libre : offrir à chacun les libertés d’utiliser, d’étudier, de modifier et de distribuer le programme. À l’opposé des logiciels propriétaires qui verrouillent leur code, WordPress s’ouvre complètement.

L’évolution technique suit un rythme soutenu. En 2004, la version 1.2 introduit les plugins, ces extensions qui permettent d’ajouter des fonctionnalités sans toucher au cœur du système. L’année suivante, les thèmes et les pages statiques font leur apparition dans la version 1.5, avant que la 2.0 n’apporte la mise en cache et une interface d’administration repensée.

L’année 2007 voit s’enchaîner les améliorations. La version 2.1 intègre l’auto-sauvegarde et la vérification orthographique. Les widgets arrivent avec la 2.2, facilitant la personnalisation des barres latérales. La 2.3 introduit les tags et refond le système de taxonomie, rendant la classification des contenus plus souple.

En 2008, l’agence Happy Cog conçoit une nouvelle interface d’administration pour la version 2.5. Le tableau de bord se dote de widgets modulables et une API de shortcodes voit le jour. Quelques mois plus tard, la version 2.7 améliore l’ergonomie générale, ajoute les mises à jour automatiques et simplifie l’installation des plugins. La gestion des commentaires en fils de discussion enrichit les interactions entre auteurs et lecteurs.

Parallèlement au développement technique, Matt Mullenweg fonde Automattic, l’entreprise commerciale qui héberge WordPress.com, la version en ligne du système. L’organisation adopte un modèle de travail inhabituel : les équipes sont entièrement distribuées, sans bureau central. En 2014, Automattic dépasse le milliard de dollars de valorisation avec plus de 300 employés répartis dans 37 pays.

Le succès de WordPress repose sur plusieurs piliers. Le système de plugins compte aujourd’hui plus de 35 000 extensions, couvrant des besoins aussi variés que le commerce en ligne, la sécurité ou l’optimisation des performances. L’architecture du logiciel séduit les développeurs qui peuvent s’appuyer sur ses composants pour créer des applications web complexes, bien au-delà du simple blog.

La communauté s’organise autour des WordCamps, des conférences locales qui essaiment dans le monde entier. Ces rencontres créent des liens entre utilisateurs, développeurs et entreprises, nourrissant un écosystème dynamique où s’échangent connaissances et bonnes pratiques.

Les grandes organisations finissent par adopter la plateforme. Le New York Times, le Wall Street Journal ou le Washington Post l’utilisent pour leurs sites web. WordPress propulse environ 23% des sites mondiaux, prouvant sa capacité à répondre aux exigences les plus diverses, de l’artisan local au média international.

Les versions suivantes continuent d’enrichir le système. La 3.0 en 2010 apporte les types de contenus personnalisés et la gestion multi-sites. Le responsive design s’intègre naturellement, s’adaptant aux smartphones et tablettes qui envahissent le marché. L’éditeur visuel s’améliore, le support des emojis arrive, les icônes de site s’intègrent directement dans l’interface.

WordPress évolue vers une plateforme d’applications complète. Les développeurs exploitent ses API pour transformer un simple blog en système de réservation, en boutique en ligne ou en portail d’apprentissage.

Le modèle économique joue sur deux tableaux : le logiciel reste libre et gratuit, mais des services comme l’hébergement, le support technique ou les fonctionnalités premium génèrent des revenus. Cette approche garantit la pérennité du projet sans sacrifier son accessibilité.

Le recrutement chez Automattic reflète cette culture particulière. Les candidats passent par des tests pratiques et des périodes d’essai, les compétences réelles comptant plus que les diplômes. Cette méthode s’inscrit dans les valeurs du logiciel libre, où la contribution effective l’emporte sur les qualifications formelles.

En démocratisant la création de sites web, WordPress a permis à des millions de personnes d’exister et de s’exprimer en ligne. Son modèle de développement collaboratif inspire d’autres projets libres, démontrant qu’une communauté mondiale peut créer et maintenir des outils professionnels de grande envergure.

La gestion du projet suit une ligne pragmatique. Les décisions techniques répondent aux besoins réels des utilisateurs plutôt qu’aux modes passagères. Cette stabilité rassure les entreprises qui choisissent WordPress pour leurs projets stratégiques, sachant que la plateforme évoluera sans rupture brutale.

WordPress est devenu une plateforme web universelle. Cette transformation s’est faite en préservant les principes fondateurs de simplicité et d’ouverture, tout en intégrant les innovations nécessaires à sa croissance. Le logiciel a su grandir sans renier ses origines, restant fidèle à l’esprit qui animait ses deux créateurs en 2003.

Haut de page

Xen

En 1999, au laboratoire d’informatique de l’Université de Cambridge, le Dr. Ian Pratt et son équipe lancent le projet XenoServers. Leur vision : bâtir une infrastructure de serveurs répartis sur Internet où des individus ou des organisations, une fois authentifiés, pourraient acheter des ressources informatiques à la demande. L’idée n’était pas nouvelle dans son principe, mais sa mise en œuvre technique s’annonçait ambitieuse. Le nom XenoServers fait référence au grec xenos, l’étranger auquel on offre l’hospitalité sans pour autant lui accorder une confiance aveugle.

Les premiers pas du projet s’orientent vers l’utilisation de machines virtuelles Java pour exécuter le code des clients. Cette solution se heurte à une contrainte rédhibitoire qui oblige à réécrire toutes les applications en Java. L’équipe change alors de cap et vise plus haut : virtualiser directement le matériel x86 pour faire tourner des systèmes d’exploitation complets. À l’époque, virtualiser l’architecture x86 relève du défi technique. Les approches disponibles reposent sur l’émulation d’instructions et la réécriture binaire, des méthodes qui dégradent les performances de manière notable.

Face à ces limitations, les chercheurs inventent la paravirtualisation. Le principe consiste à modifier légèrement les systèmes d’exploitation invités pour qu’ils collaborent avec un hyperviseur, tout en laissant les applications s’exécuter sans retouche. Keir Fraser, doctorant dans l’équipe, se charge de concrétiser cette idée. Il développe le cœur de l’hyperviseur et adapte Linux 2.2 à cette nouvelle architecture. L’hyperviseur reçoit le nom de Xen, qui condense celui du projet initial.

L’un des paris techniques de Xen tient dans sa capacité à héberger des machines virtuelles appartenant à différents clients sur le même serveur physique. L’isolation doit être totale : un client ne peut ni accéder aux données d’un autre, ni perturber son fonctionnement, et chacun reçoit exactement les ressources qu’il paie. Les concepteurs aiment illustrer cette exigence par un exemple parlant : vendre simultanément des services à Coca-Cola et Pepsi en leur garantissant une confidentialité absolue.

Les années qui suivent voient le projet gagner en ampleur. Des laboratoires comme Intel Research et HP Labs apportent leur soutien financier et technique. En 2003, la première version libre de Xen sort sous double licence : GPLv2 pour l’hyperviseur, BSD pour les composants intégrés aux systèmes d’exploitation. Ce choix de licence BSD n’est pas anodin : il simplifie le portage vers des systèmes propriétaires. Microsoft Research s’intéresse au projet, Paul Barham dirigeant un prototype de portage de Windows XP.

La publication de l’article « Xen and the Art of Virtualization » lors de la conférence ACM SOSP marque la consécration académique du projet. Des fournisseurs d’accès Internet commencent à déployer Xen commercialement, exploitant ses capacités de virtualisation du calcul, du réseau et du stockage.

Christian Limpach contribue en 2004 au portage de NetBSD sur Xen avant de rejoindre l’équipe de Cambridge. Sous l’impulsion de Pratt, la communauté open source autour de Xen s’étoffe. RedHat, SuSE, Sun, IBM, AMD : tous adaptent leurs systèmes d’exploitation ou portent Xen sur leur matériel.

Les chercheurs réalisent qu’étendre l’architecture x86 rendrait la virtualisation plus simple et plus performante, tout en réduisant la quantité de code privilégié nécessaire. Une collaboration avec Intel aboutit au développement du mode HVM de Xen, qui tire parti des extensions VTx d’Intel. Ce mode évite certaines modifications paravirtualisées des systèmes d’exploitation, tout en conservant la paravirtualisation là où elle apporte un gain réel. Le support d’AMD-V arrive ensuite.

L’année 2004 voit aussi les principaux contributeurs créer XenSource face aux demandes croissantes de services de conseil. Financer une entreprise basée sur l’open source au Royaume-Uni et en Europe reste un parcours semé d’embûches, ces modèles économiques y étant peu établis. Ian Pratt recontacte Simon Crosby, ancien collègue universitaire, et part dans la Silicon Valley où XenSource décroche un premier tour de financement de 8 millions de dollars auprès de KPCB et Sevin Rosen.

La première année de XenSource se concentre sur le développement open source. La stratégie initiale ? Fournir des outils de gestion et collaborer avec les distributions Linux. Mais quand ces dernières annoncent leurs propres solutions, cette approche montre ses limites. Fin 2005, Peter Levine et Frank Artale rejoignent l’entreprise via Accel Ventures. Leur vision commerciale réoriente XenSource vers une confrontation directe avec VMware. Un partenariat stratégique avec Microsoft en 2006 renforce la crédibilité de l’entreprise.

En 2007, Citrix rachète XenSource. Déçu par l’entrée de VMware sur le marché de la virtualisation de postes de travail, qui concurrence directement son activité de virtualisation d’applications, Citrix voit dans cette acquisition l’opportunité de disposer d’une plateforme compatible avec Microsoft.

Pendant ce temps, Amazon bâtit son infrastructure cloud sur Xen à partir de fin 2005. Avec des millions de machines virtuelles déployées, Amazon est le plus grand utilisateur de Xen, et probablement celui qui en tire le plus grand bénéfice financier. La capacité d’Amazon à virtualiser Windows repose sur l’adoption de plateformes Intel dotées d’extensions de virtualisation. Depuis, chez AWS, Xen a laissé progressivement sa place à Nitro, la solution maison.

En septembre 2022, après l’acquisition de Citrix par Vista Equity Partners et Evergreen Coast Capital, XenServer devient une unité commerciale indépendante au sein du Cloud Software Group. Cette réorganisation ouvre un nouveau chapitre pour une technologie née dans un laboratoire universitaire britannique.

Le succès de Xen témoigne du rôle de l’open source dans l’innovation technologique et de la capacité des projets universitaires à produire des solutions qui marquent durablement l’industrie.

Haut de page

Apache Cassandra

Les géants du web se heurtent à un mur. Facebook, qui compte des centaines de millions d’utilisateurs, doit gérer une fonctionnalité apparemment simple : la recherche dans la messagerie. Mais derrière cette simplicité se cache un défi technique redoutable. Chaque jour, des milliards d’écritures affluent dans les systèmes, et la croissance ne montre aucun signe de ralentissement. Les bases de données traditionnelles, conçues dans les années 1970, montrent leurs limites face à ces volumes.

Avinash Lakshman et Prashant Malik s’attellent à la création d’une nouvelle solution pour palier au problème. Lakshman n’arrive pas les mains vides, il a participé chez Amazon à la conception de Dynamo, un système de stockage distribué qui fait référence. Leur intuition consiste à croiser deux approches jusqu’alors distinctes. D’un côté, les principes architecturaux de Dynamo qui ont fait leurs preuves chez Amazon. De l’autre, le modèle de données de BigTable, la solution maison de Google. De cette rencontre naît Cassandra, baptisée d’après la prophétesse de la mythologie grecque.

En juillet 2008, Facebook prend une décision qui va changer la donne. Plutôt que de garder jalousement son code, comme le font Google et Amazon qui se contentent de publier des articles décrivant leurs architectures, le réseau social libère l’intégralité du code source de Cassandra sous licence Apache. Le geste marque une rupture dans les pratiques des entreprises technologiques. L’année suivante, le projet intègre l’incubateur de la fondation Apache, avant d’accéder en février 2010 au statut convoité de projet de premier niveau.

L’architecture de Cassandra rompt avec les schémas établis. Là où les bases de données classiques s’organisent selon une hiérarchie maître-esclave, Cassandra adopte un modèle où tous les nœuds jouent le même rôle. Aucun chef d’orchestre, aucun point de défaillance unique. Les données se répartissent automatiquement entre les machines participantes, et le système grandit horizontalement sans qu’un administrateur ait besoin d’intervenir. Cette décentralisation totale garantit une disponibilité continue, y compris quand certains nœuds tombent en panne.

La redondance des données s’inscrit dans l’ADN du système. Cassandra duplique automatiquement les informations sur plusieurs nœuds. L’administrateur se contente d’indiquer le nombre de copies souhaitées, le reste se fait tout seul. Si une machine lâche, les données restent accessibles ailleurs. Cette approche simple dans son principe s’avère efficace dans la pratique.

Netflix offre un exemple parlant de ce que Cassandra rend possible. En 2011, le service de streaming déploie un cluster de 288 instances dans le cloud. Le système encaisse 1,1 million d’écritures par seconde venues directement des clients. Avec la réplication sur trois zones de disponibilité différentes, ce chiffre grimpe à 3,3 millions d’écritures par seconde. Ces performances auraient été inimaginables quelques années plus tôt avec les technologies conventionnelles.

L’arrivée du langage CQL facilite grandement l’adoption. Sa syntaxe rappelle celle du SQL que connaissent des millions de développeurs dans le monde. Un programmeur habitué aux bases relationnelles est capable de prendre en main Cassandra sans tout réapprendre. Certes, des différences subsistent : pas de jointures par exemple, ce qui reflète le modèle de données dénormalisé du système. Mais le seuil d’entrée baisse considérablement.

La communauté grossit à vue d’œil. En 2012, plus de 1 000 déploiements en production tournent déjà, de eBay à Disney en passant par Netflix. Les outils se multiplient, les intégrations avec Hadoop, Spark ou Solr enrichissent l’écosystème. Le monde du big data trouve en Cassandra un pilier fiable.

DataStax voit le jour en 2010 et apporte une dimension commerciale au projet. L’entreprise embauche les principaux contributeurs et propose une version entreprise avec des fonctionnalités supplémentaires, du support technique et des outils d’administration comme OpsCenter. Le modèle open source trouve là son pendant économique viable.

Les chiffres parlent d’eux-mêmes. Une étude comparative présentée à la conférence Very Large Database en 2012 met Cassandra face à HBase. Les temps de latence en lecture s’avèrent jusqu’à 100 fois plus rapides, le débit huit fois supérieur. Ces résultats ne sortent pas de nulle part : ils découlent directement des choix architecturaux initiaux.

Les versions se succèdent et apportent leur lot d’améliorations. La 1.0 en 2011 optimise les performances et compresse les données. La 2.0 en 2013 introduit des transactions légères via le protocole Paxos. La 3.0 en 2015 ajoute les vues matérialisées. La 4.0 en 2021 déploie le streaming sans copie et supporte Java 11. Chaque itération pousse un peu plus loin les capacités du système.

Instagram, racheté par Meta, s’appuie sur Cassandra pour gérer les données de plus d’un milliard d’utilisateurs actifs chaque mois. Les cas d’usage se diversifient : séries chronologiques, analyse temps réel, gestion de contenus multimédias, commerce électronique. Partout où les volumes explosent et où l’indisponibilité coûte cher, Cassandra trouve sa place.

L’impact dépasse la seule dimension technique. Cassandra démontre qu’une base de données peut conjuguer haute disponibilité, montée en charge linéaire et performances élevées. Ces trois piliers répondent exactement aux besoins des applications web contemporaines, où chaque minute d’arrêt se compte en millions et où les données ne cessent de croître.

Cassandra trouve un terrain favorable dans le déploiement hybride et multi-cloud. Le système fonctionne de façon transparente sur plusieurs centres de données ou fournisseurs cloud différents. Tout en gardant leurs données cohérentes, les entreprises échappent ainsi à la dépendance vis-à-vis d’un unique prestataire.

D’autres projets s’inspirent de Cassandra. ScyllaDB intègre ses concepts en C++ pour gagner encore en performances. L’architecture décentralisée et le modèle de cohérence ajustable servent désormais de référence dans le domaine du stockage distribué.

Vingt ans après sa naissance, Apache Cassandra demeure une pièce maîtresse de l’écosystème NoSQL. Son histoire raconte la maturation des architectures distribuées et leur capacité à s’adapter aux exigences toujours plus élevées des applications modernes. Ce qui commença comme une solution interne chez Facebook est devenu un standard de facto pour quiconque doit gérer des données massives avec des garanties de disponibilité strictes.

Haut de page

Google Gmail

En 2001, le marché de la messagerie électronique gratuite se résumait à trois acteurs installés : Microsoft Hotmail, Yahoo! Mail et AOL. Chacun proposait à peu près la même chose, quelques mégaoctets d’espace où stocker ses messages. Les utilisateurs passaient leur temps à faire le tri, supprimaient régulièrement leurs anciens courriers pour ne pas dépasser la limite imposée. C’était la norme, personne ne s’en plaignait vraiment, probablement à cause de la gratuité.

Chez Google, une employée finit par exprimer sa frustration. Elle en avait assez de cette corvée permanente, ces 4 mégaoctets qui l’obligeaient sans cesse à archiver, classer, effacer. Paul Buchheit, ingénieur dans l’entreprise, entendit cette remarque. À cette époque, Google ne faisait que de la recherche web. Développer un service de messagerie représentait un virage complet pour l’entreprise, une sortie de son territoire habituel.

Buchheit n’en était pas à sa première tentative dans le domaine. Avant de rejoindre Google, il avait travaillé sur un prototype de messagerie web qui n’avait jamais vu le jour. Fort de cet échec, il décida cette fois d’aller vite. En une seule journée, il créa une première version en recyclant du code existant, celui de Google Groups qui servait à fouiller dans les archives Usenet. Ce premier jet ne faisait qu’une chose : chercher dans ses propres e-mails. Rien de plus, mais c’était un début.

La vraie rupture technique résidait dans l’utilisation de JavaScript et de l’objet XMLHttpRequest. JavaScript avait mauvaise réputation chez Google, associé aux publicités envahissantes qui polluaient le web. Pourtant, cette technologie s’avérait indispensable pour bâtir une interface réactive, sans ces rechargements de page qui cassaient l’expérience utilisateur. L’association de JavaScript et de XMLHttpRequest, qui prendrait plus tard le nom d’AJAX, permit de créer quelque chose qui ressemblait vraiment à un logiciel installé sur l’ordinateur.

Le développement se fit pas à pas, chaque nouvelle fonction testée d’abord par les employés de Google. Les retours arrivaient directement, les améliorations suivaient immédiatement. L’une des idées marquantes fut d’organiser les messages en conversations plutôt qu’en courriers isolés. Cette présentation reprenait la logique des groupes de discussion Usenet, où suivre un fil d’échanges se faisait naturellement.

La question de l’argent se posa. Marissa Mayer, qui supervisait le développement des produits, penchait pour le modèle classique : un espace gratuit limité, une formule payante pour ceux qui voulaient plus. Buchheit proposa autre chose : afficher des publicités liées au contenu des messages. L’idée fit débat, on parla de respect de la vie privée, de confidentialité. Mais cette approche donna naissance à AdSense, qui devint l’une des principales sources de revenus de Google.

Le 1^er avril 2004, Google annonça Gmail avec une promesse incroyable : 1 gigaoctet de stockage gratuit. Deux cent cinquante fois plus que la concurrence. La date de l’annonce et l’ampleur de l’offre semèrent le doute. Google adorait les canulars du 1^er avril, et proposer autant d’espace paraissait techniquement impossible, économiquement absurde. Beaucoup crurent à une blague.

Le service démarra en envoyant des invitations. Les premiers utilisateurs reçurent quelques invitations à distribuer, créant un système de diffusion virale. Cette rareté artificielle permit une montée en charge progressive des serveurs tout en construisant une image de service élitiste, désirable. Les invitations Gmail se négociaient même sur eBay.

Gmail transforma Google. L’entreprise prouva qu’elle savait faire autre chose que de la recherche web, qu’elle pouvait créer des services web sophistiqués. Les techniques mises au point pour Gmail, notamment cette fameuse utilisation d’AJAX, devinrent des standards du développement web. Google publia d’ailleurs en 2005 le Google Web Toolkit, un framework qui permettait à d’autres développeurs d’utiliser ces technologies.

La phase bêta dura cinq ans. Gmail en sortit en 2009, après avoir intégré progressivement de nouvelles fonctions : le chat, la vérification orthographique, la détection des pourriels, les connexions avec Calendar et Drive. L’interface évolua mais garda ses principes d’origine, cette simplicité qui faisait sa force.

L’impact dépassa largement le cadre de la messagerie. Gmail redéfinit ce qu’on pouvait attendre d’une application web. Microsoft et Yahoo! durent revoir leurs copies, augmenter drastiquement leur espace de stockage. Plus largement, le service montra qu’une application web pouvait rivaliser avec un logiciel installé sur le disque dur.

Gmail reflète la façon dont Google aborde l’innovation. Une approche par essais et erreurs, des itérations rapides, une attention portée aux besoins réels. Cette méthode mêle réflexion technique et observation du terrain. Le service continue sa mue en intégrant de l’intelligence artificielle pour trier automatiquement les messages, suggérer des réponses, détecter les tentatives d’hameçonnage.

Haut de page

Scala

Martin Odersky lance le développement de Scala en 2001 au sein du laboratoire des méthodes de programmation de l’École Polytechnique Fédérale de Lausanne. Sa démarche répond à une question précise : comment mieux supporter les logiciels à base de composants dans les langages de programmation ?

Trois ans plus tard, en janvier 2004, la première version publique de Scala voit le jour sur la plateforme Java Virtual Machine. Une mouture pour .NET suit en juin. Le nom retenu, « Scala », contracte scalable language : un langage extensible qui s’adapte aux besoins de ses utilisateurs. Cette idée d’adaptabilité traverse toute la conception : des petits scripts jusqu’aux grands systèmes, l’outil doit pouvoir suivre.

L’originalité de Scala tient dans sa manière de fusionner la programmation orientée objet et la programmation fonctionnelle sous un typage statique. Là où d’autres langages maintiennent ces paradigmes séparés, Scala les unit. Son système de types intègre des concepts avancés comme les types abstraits et les types dépendants de chemins, hérités du calcul υObj. La composition modulaire repose sur des mixins et des traits. Les vues offrent quant à elles une adaptation modulaire des composants.

La compatibilité avec Java structure fortement la conception. Scala reprend une bonne part de la syntaxe et du système de types de Java. Un développeur Java retrouve ses repères. Les bibliothèques Java s’utilisent directement dans Scala, et inversement. Les classes Scala héritent des classes Java et implémentent leurs interfaces. Cette interopérabilité autorise l’insertion du code Scala dans des projets Java existants sans tout réécrire.

Mars 2006 marque la sortie d’une seconde version majeure. Le système de types gagne en robustesse, les mécanismes de composition de classes se précisent. La syntaxe reste volontairement classique, mais cache une sophistication technique qui autorise l’expression de concepts complexes en peu de lignes.

Les influences de Scala sont multiples. Du côté objet, Simula et Smalltalk inspirent le modèle objet uniforme. L’imbrication universelle — cette capacité à imbriquer presque toutes les constructions les unes dans les autres — vient d’Algol, de Simula, puis de Beta. L’approche fonctionnelle rappelle la famille ML avec SML, OCaml ou F#. Les paramètres implicites trouvent leur racine dans les classes de types de Haskell, adaptées ici au monde objet classique. La bibliothèque de concurrence basée sur les acteurs doit beaucoup à Erlang.

Plutôt que d’imposer un ensemble figé de constructions, Scala mise sur l’extensibilité. Les programmeurs créent leurs propres abstractions. Cette philosophie évoque le bazar plutôt que la cathédrale, selon la métaphore d’Eric Raymond : le langage grandit par l’ajout de constructions inventées par ses utilisateurs, pas par des modifications de son noyau.

Les apports techniques de Scala se remarquent dans plusieurs domaines. Le traitement uniforme des types génériques et des types abstraits sort des sentiers battus. La composition de classes via les traits propose une voie originale. Le mécanisme d’extraction autorise la correspondance de motifs indépendamment de la représentation. Ces innovations ont fait l’objet de présentations dans diverses conférences spécialisées.

L’industrie a saisi l’intérêt de Scala, surtout pour les applications distribuées et le traitement de données massives. Apache Spark, écrit en Scala, montre les capacités du langage sur des systèmes complexes de traitement de données. La syntaxe concise réduit la taille du code comparé à Java — jusqu’à 50% dans des cas courants.

Le Fonds National Suisse, Microsoft Research, le Centre de Compétences en Recherche MICS, le projet européen PalCom et la Fondation Hasler ont soutenu le développement. La communauté des développeurs participe activement avec des retours d’expérience et des contributions au code.

L’évolution de Scala traduit une approche pragmatique. Pas question de construire un système parfait et rigide. L’adaptabilité et l’extensibilité priment. Cette stratégie donne aux développeurs les moyens d’enrichir le langage selon leurs besoins, créant un écosystème vivant de bibliothèques et de frameworks.

En 2025, Scala poursuit sa route en gardant ses principes fondateurs : l’unification de la programmation orientée objet et fonctionnelle, l’extensibilité, l’interopérabilité avec les plateformes établies. Le langage nourrit les réflexions sur la conception des langages de programmation et l’architecture des systèmes logiciels.

Haut de page

NGINX

Igor Sysoev avait un problème. En 2002, cet ingénieur russe travaillait pour Rambler, un portail internet qui voyait affluer des centaines de milliers de connexions simultanées. Les serveurs peinaient. Apache, la solution dominante de l’époque, montrait ses failles : chaque connexion réclamait ses propres ressources système, créant une lourdeur qui devenait insoutenable quand le trafic grimpait. Sysoev cherchait autre chose, une approche différente pour gérer cette avalanche de requêtes.

Il se lance alors dans l’écriture d’un nouveau serveur web, qu’il baptise NGINX (prononcé engine-x). Son architecture rompt avec les conventions : au lieu d’allouer un processus ou un thread par connexion, le logiciel adopte un modèle asynchrone et événementiel. Un processus maître supervise l’ensemble, quelques processus enfants se répartissent le travail, et cette poignée de composants suffit à traiter des milliers de requêtes en parallèle, pour une économie de ressources spectaculaire.

En octobre 2004, Sysoev publie la version 0.1.0. Il choisit cette date en référence au lancement de Spoutnik, clin d’œil au premier satellite artificiel. Le code est distribué sous licence BSD, libre d’accès. Les premiers à tenter l’aventure sont des sites estoniens et russes comme rate.ee ou zvuki.ru, qui utilisent NGINX pour servir leurs fichiers MP3. La nouvelle recrue fait ses preuves.

Le logiciel gagne du terrain, d’abord dans la sphère russophone, puis au-delà. Les administrateurs système découvrent ses talents : servir du contenu statique avec une vélocité remarquable, jouer le rôle de proxy inverse, répartir la charge entre plusieurs serveurs, gérer le cache ou encore servir de passerelle FastCGI. NGINX se montre polyvalent, fiable, rapide. Sa réputation traverse les frontières.

Sept ans après la première version publique, en 2011, Sysoev et Maxim Konovalov fondent NGINX, Inc. L’idée ? Proposer du support commercial et des fonctionnalités avancées tout en préservant la version open source. Les investisseurs réagissent vite : BV Capital et Runa Capital injectent 3 millions de dollars dès octobre 2011. D’autres levées suivent : 10 millions en 2013, 20 millions en 2014, 43 millions en 2018. L’entreprise développe NGINX Plus, une offre payante qui complète la version communautaire avec des capacités étendues de monitoring et d’analyse.

F5 Networks rachète NGINX en mars 2019 pour 670 millions de dollars, validation éclatante de l’importance du logiciel dans l’infrastructure web contemporaine. Mais l’histoire prend une tournure inattendue en décembre de la même année : une perquisition frappe les bureaux moscovites de NGINX. Rambler, l’ancien employeur de Sysoev, revendique la propriété intellectuelle du code. L’affaire se dénoue grâce à l’intervention de Sberbank, actionnaire de Rambler, mais l’épisode laisse des traces.

Sur le terrain technique, NGINX continue d’évoluer. Il intègre HTTP/2, affine ses mécanismes de compression et de cache, manipule les en-têtes avec souplesse. La mémoire partagée sert à stocker le cache, gérer la persistance des sessions, contrôler le débit. Cette efficacité séduit : en 2022, plus de 33% des sites web mondiaux tournent sur NGINX, dépassant Apache dans différentes « catégories. Des plateformes comme WordPress.com lui font confiance. Le logiciel s’adapte aux architectures modernes, microservices et cloud compris.

Janvier 2022 : Sysoev annonce son départ de NGINX et F5. Il laisse derrière lui un projet qui a redessiné l’infrastructure du web. Son dernier né, NGINX Unit, lancé en 2017, vise les environnements multilingues et les architectures en microservices. L’héritage demeure.

De Rambler aux serveurs du monde entier, le logiciel a grandi pendant que le web changeait de visage. Son succès tient à des choix architecturaux astucieux, une approche pragmatique des questions de performance, et un équilibre réussi entre code ouvert et modèle économique viable.

Haut de page

OAuth

En 2006, Blaine Cook travaillait sur l’API de Twitter et se heurtait à un problème qui devenait récurrent chez les développeurs web. Il cherchait un moyen de connecter Twitter à Flickr, le service de partage de photos. La seule solution disponible était de demander aux utilisateurs de confier leurs identifiants Flickr à Twitter. Une aberration en matière de sécurité, mais c’était la norme à l’époque.

Cette impasse technique a poussé Cook et d’autres développeurs de grandes plateformes web à se réunir. Google avait AuthSub, Yahoo utilisait BBAuth, AOL proposait OpenAuth, et Flickr disposait de sa propre API. Chacun bricolait sa solution dans son coin. Il fallait sortir de ce morcellement. En octobre 2007, leur collaboration aboutit à OAuth 1.0, un protocole ouvert destiné à résoudre ce casse-tête : comment autoriser une application tierce à accéder aux données d’un utilisateur sans jamais manipuler son mot de passe ?

Le mécanisme repose sur un principe simple mais efficace. Imaginons un service d’impression en ligne qui veut accéder aux photos stockées sur un autre site. Au lieu de réclamer les identifiants du compte photos, il obtient un jeton d’accès spécifique, limité aux seules opérations nécessaires. L’utilisateur garde le contrôle : il autorise explicitement l’accès depuis une interface sécurisée du site hébergeant ses photos. Le service d’impression ne connaît jamais le mot de passe.

Les premières failles de sécurité se sont manifestées, et en juin 2009, OAuth 1.0a corrigeait des vulnérabilités permettant des usurpations d’identité. Cette révision a clarifié des zones d’ombre du protocole initial et renforcé les protections contre les attaques. L’année suivante, en avril 2010, l’IETF publiait OAuth 1.0 comme RFC 5849, lui conférant un statut de spécification technique officielle.

Le protocole définit trois acteurs : le propriétaire de la ressource (l’utilisateur), le client (l’application qui demande l’accès) et le serveur d’autorisation. L’application obtient d’abord des identifiants temporaires. Elle redirige ensuite l’utilisateur vers une page d’autorisation où celui-ci examine les permissions demandées. Après validation, l’application reçoit un jeton qu’elle utilisera pour ses requêtes futures. À aucun moment elle ne touche aux identifiants de l’utilisateur.

La sécurité s’appuie sur des garde-fous. Chaque requête doit être signée avec une clé secrète. Le protocole intègre des jetons uniques (nonces) et des timestamps pour bloquer toute tentative de réutilisation malveillante. Les concepteurs ont anticipé les attaques par détournement de session, par rejeu, ou par usurpation.

Facebook, Google, Microsoft et Twitter ont adopté OAuth. Cette adhésion massive des géants du web a créé un écosystème d’applications interconnectées. Des bibliothèques sont apparues dans tous les langages de programmation courants, rendant l’intégration plus accessible.

Mais OAuth 1.0 montrait ses limites. La complexité de l’implémentation, notamment pour la signature cryptographique des requêtes, décourageait les développeurs. Les applications mobiles natives, de plus en plus nombreuses, posaient des problèmes non prévus au départ. Ces contraintes ont motivé une refonte complète du protocole avec OAuth 2.0.

Le protocole OAuth a établi le standard de l’autorisation déléguée sur le web. Il a introduit des concepts désormais centraux : le consentement explicite de l’utilisateur, la limitation stricte des privilèges accordés, la séparation nette entre authentification et autorisation.

OAuth a aussi joué un rôle éducatif. Développeurs et utilisateurs ont pris conscience des enjeux autour de la protection des données personnelles. Le protocole a démontré qu’il était possible de créer des services interconnectés sans sacrifier la sécurité. Cette prise de conscience a accompagné l’évolution des réglementations sur la vie privée.

Par ailleurs, les architectures modernes portent la marque d’OAuth. OpenID Connect s’appuie sur ses fondations pour ajouter une couche d’authentification standardisée. Les API REST et les microservices reprennent ses principes architecturaux. Les objets connectés et les systèmes d’identités décentralisées explorent de nouvelles pistes en partant des bases posées par OAuth.

La communauté continue d’adapter le protocole aux nouveaux usages. Les retours d’expérience des déploiements à grande échelle alimentent les réflexions sur ses évolutions futures. OAuth reste un pilier de la sécurité web, près de vingt ans après sa création.

Haut de page

Git

En 2005, Linus Torvalds se retrouve dans une situation embarrassante. BitKeeper, le système de gestion de versions que la communauté Linux utilise depuis des années, n’est plus accessible gratuitement aux développeurs du noyau. L’histoire commence avec Andrew Tridgell, un développeur respecté, qui décide d’étudier le protocole de BitKeeper par rétro-ingénierie. Larry McVoy, le créateur de BitKeeper, considère cette démarche comme une violation des conditions d’utilisation et révoque la licence gratuite accordée aux développeurs Linux.

Torvalds tente une médiation pendant quelques semaines, sans résultat. Face à ce blocage, il doit trouver une alternative. Il examine les systèmes existants mais aucun ne le satisfait. Lui qui considérait les gestionnaires de versions comme l’un des domaines les moins intéressants de l’informatique, juste après les bases de données, se lance dans la création de son propre outil. Son expérience avec BitKeeper lui a au moins appris une chose : les avantages d’un système distribué où chaque développeur possède une copie locale du dépôt.

Torvalds disparaît alors pendant une semaine. Quand il refait surface, il présente la première version de Git. Le développement initial progresse à une vitesse remarquable. En dix jours, Git est capable de gérer son propre code source. Cette rapidité ne vient pas d’une quantité massive de code écrit, mais d’une réflexion approfondie sur l’organisation des données. Torvalds a conçu une architecture qui privilégie la simplicité conceptuelle et la performance.

Le système repose sur plusieurs choix techniques. Chaque développeur dispose d’une copie complète du dépôt, ce qui élimine la dépendance à un serveur central et résout les problèmes d’accès en écriture. Git utilise un hachage cryptographique SHA-1 pour identifier les objets dans le dépôt. Cette approche garantit l’intégrité du code et rend impossible toute modification de l’historique sans que cela soit détecté.

La gestion des branches et des fusions constitue l’une des grandes innovations de Git. Ces opérations, réputées complexes dans les systèmes précédents, sont simples et rapides. Torvalds réalise parfois des dizaines de fusions par jour durant les périodes intenses de développement du noyau Linux. Cette fluidité transforme la manière de travailler des développeurs.

Quelques mois après sa création, Torvalds confie la maintenance de Git à Junio Hamano. Il reconnaît en lui un développeur doté d’un excellent jugement technique. Sous sa direction, Git évolue pour devenir plus accessible tout en conservant ses qualités de rapidité, de fiabilité et de flexibilité.

L’adoption de Git se fait progressivement. Le projet Android de Google le choisit comme système de gestion de versions en 2009, ce qui apporte une validation importante de la part d’une grande entreprise. La création de GitHub en 2008 par Tom Preston-Werner, Chris Wanstrath et P.J. Hyett accélère la démocratisation de l’outil. La plateforme offre une interface web conviviale et des fonctionnalités de réseau social pour les développeurs.

Microsoft, longtemps réticent aux logiciels libres, change progressivement de position. En 2012, l’entreprise commence à contribuer à libgit2, une bibliothèque de développement Git. L’année suivante, elle intègre le support de Git dans Visual Studio et propose l’hébergement via Azure DevOps. En 2017, Microsoft migre le développement de Windows vers Git, créant le plus grand dépôt Git au monde avec 300 Go de code source.

L’acquisition de GitHub par Microsoft en 2018 pour 7,5 milliards de dollars marque un moment symbolique. Cette transaction illustre la transformation de Microsoft et confirme la position dominante de Git dans l’industrie du logiciel. Les statistiques de Stack Overflow en 2018 révèlent que 88,4% des développeurs utilisent Git, loin devant Subversion (16,6%) ou Mercurial (3,7%).

La conception de Git reflète les besoins spécifiques du développement du noyau Linux. La capacité à gérer un grand nombre de contributions simultanées, la rapidité des opérations, la robustesse face aux erreurs : ces caractéristiques, combinées à sa nature distribuée, en font un outil adapté aux projets open source de grande envergure. Les développeurs peuvent travailler de manière autonome sur leurs copies locales, puis synchroniser leurs modifications avec le reste de l’équipe quand ils le souhaitent.

En 2024, Git demeure le standard de fait pour la gestion de versions dans l’industrie du logiciel. Il a transformé la manière dont les développeurs collaborent et partagent leur code. Les principes de son architecture distribuée ont inspiré de nombreux autres outils et pratiques dans le domaine du développement logiciel.

Haut de page

Redis

En 2009, Salvatore Sanfilippo, développeur italien connu sous le pseudonyme « antirez », bute sur un problème irritant. L’analyseur de logs web qu’il développe pour sa startup manque cruellement de réactivité avec MySQL. Plutôt que de bricoler une énième optimisation, il prend le parti de créer sa propre base de données. Ce qui commence comme un prototype en Tcl se transforme en un projet C baptisé Redis, contraction de REmote DIctionary Server.

Quelques semaines après avoir écrit les premières lignes de code, Sanfilippo fait un choix qui scellera l’avenir de son projet : il le publie en open source. La décision s’avère judicieuse. Les développeurs adoptent Redis massivement, attirés par sa vélocité d’exécution et sa simplicité apparente. Le projet rencontre un succès qui dépasse les espérances de son créateur.

Redis rompt avec les conventions des bases de données traditionnelles. Là où la plupart stockent leurs données sur disque, Redis les conserve intégralement en mémoire vive. Cette architecture procure une rapidité d’accès sans commune mesure, mais elle nécessite des mécanismes de persistance pour parer aux arrêts intempestifs du système. Mais Redis ne se contente pas d’être rapide : il manipule nativement des structures de données variées comme les listes, les ensembles, les tables de hachage ou les ensembles triés. Une richesse qui le distingue des simples magasins clé-valeur.

VMware recrute Sanfilippo en 2010 pour qu’il se consacre à plein temps à Redis, tout en préservant la licence BSD du projet. Pieter Noordhuis, contributeur de premier plan, rejoint l’équipe peu après. Cette professionnalisation accélère le développement et Redis s’impose progressivement dans les architectures modernes.

Les géants de la tech ne s’y trompent pas. GitHub et Instagram figurent parmi les premiers adoptants notables. Twitter, Uber, Stripe, Slack et Alibaba suivront le mouvement. Cette adoption massive tient à la polyvalence de l’outil : Redis fonctionne aussi bien comme base de données que comme système de cache ou courtier de messages. Trois rôles pour le prix d’un seul logiciel.

Sanfilippo a pensé Redis comme un jeu de construction. Plutôt qu’un produit monolithique aux fonctionnalités figées, il a conçu des briques élémentaires que les développeurs peuvent assembler selon leurs besoins. Le scripting Lua, le système de publication-souscription ou les flux de données se sont ajoutés progressivement, suivant cette philosophie modulaire. Redis ressemble à un Lego pour programmeurs, où chacun bâtit sa propre solution.

La création de Redis Labs en 2015 (devenue simplement Redis) professionnalise l’écosystème. Cette structure offre des services commerciaux autour du projet tout en maintenant son caractère libre. Après onze ans à piloter Redis, Sanfilippo s’éloigne en 2020 pour se consacrer à l’écriture et à sa famille. Un retrait du quotidien qui n’est pas une rupture.

L’architecture technique de Redis fait des choix audacieux. Son modèle mono-thread évite les casse-têtes liés aux verrous et simplifie la gestion de la concurrence. Pour persister les données, deux mécanismes cohabitent : le snapshot périodique et le journal des opérations (AOF). La réplication maître-esclave distribue la charge et garantit la disponibilité. Des solutions pragmatiques qui ont fait leurs preuves.

Redis introduit une manière singulière de penser les données. Au lieu de se limiter aux paires clé-valeur classiques, il manipule directement des structures complexes via des commandes atomiques. Cette approche réduit la complexité du code applicatif et limite les échanges réseau entre client et serveur. Un gain de temps appréciable quand on travaille à grande échelle.

L’histoire pourrait s’arrêter là, mais Sanfilippo revient en 2024 comme évangéliste de Redis. Son nouveau combat : adapter l’outil à l’ère de l’intelligence artificielle. Outre la nouvelle licence qui n’est plus open source au sens de l’OSI, il travaille sur les vector sets, une extension des ensembles triés taillée pour les embeddings et les modèles de langage. Redis évolue avec son temps.

Haut de page

YouTube

Le 14 février 2005, trois anciens employés de PayPal enregistrent la marque, le logo et le nom de domaine d’un projet qui va changer la manière dont nous consommons la vidéo sur Internet. Chad Hurley, Steve Chen et Jawed Karim ont l’intuition qu’il manque quelque chose sur le web : un moyen simple de partager des vidéos. L’idée germe lors d’un dîner à San Francisco, nourrie par deux événements de 2004 qui ont mis en lumière ce vide technologique. D’abord l’incident vestimentaire de Janet Jackson au Super Bowl, dont les vidéos sont restées introuvables en ligne. Puis le tsunami en Asie, dont les images peinent à circuler sur la toile.

En mai 2005, le site ouvre en version bêta et attire immédiatement 30 000 visiteurs par jour. La première vidéo mise en ligne ne laisse présager en rien le phénomène à venir. Dans cette séquence de 19 secondes intitulée « Me at the Zoo », Jawed Karim filme les éléphants du zoo de San Diego et commente la taille de leurs trompes. Rien de spectaculaire, et pourtant ce fragment banal totalise aujourd’hui plus de 375 millions de vues. Quatre mois plus tard, une publicité Nike avec Ronaldinho franchit le cap du million de vues, révélant le potentiel commercial de la plateforme.

Le lancement officiel a lieu le 15 décembre 2005, rendu possible par un investissement de 3,5 millions de dollars de Sequoia Capital. Cet apport financier est investi dans l’amélioration des serveurs et l’augmentation de la bande passante, car la croissance est vertigineuse. En janvier 2006, le site enregistre 25 millions de vues quotidiennes. Mars voit le nombre de vidéos disponibles dépasser les 25 millions, avec 20 000 nouvelles publications chaque jour. L’été suivant, le cap des 100 millions de vues quotidiennes est franchi.

Cette expansion fulgurante génère des coûts considérables en infrastructure informatique et en connexions Internet. La question des droits d’auteur surgit lorsque de nombreuses entreprises médiatiques découvrent leurs contenus protégés dans les vidéos téléchargées par les utilisateurs. En octobre 2006, Google tranche et acquiert YouTube pour 1,65 milliard de dollars en actions. Plutôt que de fusionner la plateforme avec Google Video, son propre service qui peine à décoller, le géant de Mountain View préfère maintenir YouTube en fonctionnement autonome.

Google négocie alors des accords avec des sociétés de divertissement pour réduire les risques juridiques liés aux droits d’auteur. Ces arrangements autorisent l’utilisation de contenus protégés et permettent aux utilisateurs d’intégrer certaines musiques sous copyright dans leurs vidéos. En 2008, un partenariat avec MGM va plus loin en autorisant la diffusion gratuite de films et séries, financée par la publicité.

Grâce au Programme Partenaire en mai 2007, les créateurs de contenus peuvent désormais monétiser leurs vidéos virales, transformant leurs passions en activités lucratives. Certains utilisateurs génèrent des revenus à six chiffres. L’adoption institutionnelle suit en 2009, quand le Congrès américain et le Vatican ouvrent leurs chaînes officielles.

YouTube Live débarque en avril 2011, diffusant concerts, événements sportifs et mariages royaux en direct. En décembre 2012, le clip « Gangnam Style » est la première vidéo à dépasser le milliard de vues. L’événement force la plateforme à modifier son compteur pour gérer des nombres supérieurs aux limites d’un entier 32 bits.

Le modèle économique se diversifie avec des services payants. Music Key apparaît en 2014, remplacé par YouTube Red en 2015, et YouTube Premium en 2018. Ces offres donnent accès à un visionnage sans publicité et des fonctionnalités supplémentaires. En 2016, YouTube Go cible les marchés émergents avec une application optimisée pour les connexions limitées.

L’intelligence artificielle s’invite dans la plateforme. En 2019, le service Video Reach utilise l’apprentissage automatique pour optimiser les campagnes publicitaires. L’année suivante, YouTube abandonne son système de catégories manuel au profit d’algorithmes de classification plus sophistiqués.

En 2023, la plateforme revendique environ 2,5 milliards d’utilisateurs mensuels actifs, se hissant au rang de second réseau social mondial derrière Facebook. Le format YouTube Shorts, réponse directe aux vidéos courtes popularisées par TikTok, génère plus de 50 milliards de vues quotidiennes. YouTube Premium atteint 125 millions d’abonnés en mars 2025.

En vingt ans, YouTube a bouleversé la consommation de contenus vidéo en ligne. La plateforme a instauré un nouveau modèle de diffusion démocratisé, où chacun peut devenir créateur. Son influence sur la culture numérique, l’éducation, le divertissement et la publicité continue de s’étendre, faisant de ce service un pilier de l’Internet moderne.

Haut de page

Amazon Web Services

En 2003, Amazon était un site de commerce en ligne qui grandissait vite. Les serveurs peinaient à suivre la cadence des commandes, et chaque pic d’activité révélait les limites d’une infrastructure conçue à la va-vite en 1994. Jeff Bezos et ses équipes cherchaient comment tenir la charge sans multiplier indéfiniment les investissements matériels.

L’entreprise avait lancé un service censé permettre à des détaillants comme Marks & Spencer de bâtir leurs propres boutiques sur la plateforme Amazon. Sauf que personne n’avait anticipé la pagaille architecturale qui attendait les développeurs. Le code s’était empilé au fil des ans sans véritable plan d’ensemble. Impossible d’extraire proprement les briques logicielles pour les proposer à des tiers. Il fallait tout reprendre depuis la base.

Amazon se mit donc à découper son infrastructure en services distincts, chacun accessible par des interfaces de programmation bien documentées. Cette réorganisation permit de rendre le service fonctionnel, mais elle eut un effet secondaire inattendu : les équipes internes commencèrent à travailler différemment. Chaque service devenait autonome, réutilisable, standardisé. Une discipline nouvelle s’installait dans le développement logiciel.

Pendant ce temps, Andy Jassy, directeur de cabinet de Bezos, constatait un paradoxe troublant. Amazon recrutait des ingénieurs à tour de bras, pourtant la vitesse de développement stagnait. En creusant, il découvrit que les équipes perdaient trois mois à monter leur environnement technique avant de commencer à coder. Base de données, serveurs de calcul, stockage : chacun reconstruisait les mêmes fondations dans son coin. Un gâchis monumental de temps et d’énergie.

L’été 2003, Bezos réunit ses dirigeants dans sa maison pour une retraite stratégique. Une session anodine sur les compétences d’Amazon s’éternisa bien au-delà des trente minutes prévues. Au-delà du commerce électronique et de la logistique, une évidence émergea : Amazon savait gérer des infrastructures informatiques complexes. La contrainte des marges réduites avait forcé l’entreprise à optimiser ses centres de données jusqu’à l’excellence. Cette expertise valait de l’or.

L’idée germa alors de transformer cette infrastructure en un système d’exploitation pour Internet. Tous les composants existaient déjà chez Amazon, mais personne d’autre n’y avait accès. Les développeurs du monde entier réinventaient les mêmes briques, perdaient les mêmes trois mois, butaient sur les mêmes problèmes. Amazon pouvait leur vendre ces éléments tous faits.

La vision mit du temps à se matérialiser. Amazon Simple Queue Service sortit en 2006, suivi de près par Simple Storage Service et Elastic Compute Cloud. Ces trois services formèrent le socle d’AWS. Les développeurs pouvaient désormais louer de la puissance de calcul, du stockage, des files d’attente, sans acheter un seul serveur. Le tout facturé à l’usage, comme l’eau ou l’électricité.

Le modèle économique bousculait les habitudes. Fini les investissements massifs dans des salles machines qui prenaient la poussière la moitié du temps. Les ressources s’ajustaient à la demande, montaient en charge lors des pics, redescendaient pendant les creux. La complexité technique disparaissait derrière des interfaces simples. Les entreprises pouvaient enfin se concentrer sur leur métier plutôt que sur la gestion de serveurs.

AWS débarqua sur un marché vierge. Étonnamment, les concurrents mirent des années à réagir. Microsoft, IBM, Google regardèrent passer le train avant de se lancer à leur tour. Trop tard : AWS avait posé les standards du cloud computing et raflé plus de 30% du marché en 2016.

Le chiffre d’affaires grimpa jusqu’à 10 milliards de dollars annuels. Des startups aux géants comme Netflix ou Dropbox, tout le monde adoptait les services Amazon. L’obsession de l’efficacité opérationnelle expliquait en partie ce succès. Amazon construisit des centres de données gigantesques dans des zones stratégiques, là où l’électricité et le refroidissement coûtaient peu. Les économies d’échelle lui permirent de baisser régulièrement les prix tout en restant rentable.

AWS marqua le passage d’une informatique de possession à une informatique de consommation. Comme les services publics au moment de la révolution industrielle, le cloud devint une commodité disponible à la demande.

Haut de page

Hadoop

En 2006, Yahoo! se trouve face à un problème de taille. Son infrastructure WebMap, cette technologie qui construit le graphe du web pour alimenter son moteur de recherche, ne suit plus. Le graphe compte plus de 100 milliards de nœuds et 1 000 milliards d’arêtes. L’infrastructure précédente, baptisée Dreadnaught, a atteint sa limite à 800 machines. Il faut repenser l’architecture de fond en comble pour suivre la croissance du web. Yahoo! fait alors le choix d’Apache Hadoop.

L’histoire débute deux ans plus tôt. En 2004, des chercheurs de Google publient deux articles qui vont tout changer. Ils y décrivent leur système de fichiers et l’architecture MapReduce. Ces publications établissent le socle technique : un système de fichiers distribué capable de stocker d’immenses volumes de données, associé à un modèle pour les traiter en parallèle à grande échelle.

La première version de Hadoop naît au sein du projet Apache Nutch, avant de prendre son indépendance en 2006. Quatre ans plus tard, Google obtient un brevet sur l’algorithme MapReduce, mais accorde une licence à la Fondation Apache Software. Cette décision ouvre la voie à une adoption massive dans l’industrie.

L’architecture initiale repose sur deux piliers. HDFS (Hadoop Distributed File System) gère le stockage distribué des données. MapReduce coordonne l’exécution des tâches de traitement. Un service central, le JobTracker, supervise l’ensemble des opérations, tandis que des TaskTrackers exécutent les tâches sur chaque nœud du cluster.

Cette architecture monolithique révèle vite ses faiblesses. Les développeurs tentent de détourner MapReduce pour des usages auxquels il n’est pas destiné. Certains lancent des tâches map uniquement pour exécuter des serveurs web ou des calculs itératifs. Ces contournements, malgré leur ingéniosité, compromettent la stabilité et l’efficacité du système.

La communauté Apache engage une refonte majeure. YARN (Yet Another Resource Negotiator) voit le jour. Cette nouvelle version sépare la gestion des ressources du modèle de programmation. Un ResourceManager central attribue les ressources du cluster aux applications. Chaque application dispose de son propre ApplicationMaster pour coordonner son exécution.

Cette refonte architecturale transforme l’écosystème. De nouveaux frameworks émergent : Apache Tez pour l’exécution de graphes de tâches, Spark pour le traitement en mémoire, Storm pour le temps réel, Giraph pour le calcul sur les graphes. Les utilisateurs ne sont plus enfermés dans les limitations de MapReduce.

L’adoption de Hadoop dans l’industrie prend une ampleur considérable. Yahoo! déploie YARN sur l’ensemble de ses clusters de production. Le système traite quotidiennement environ 500 000 jobs, représentant plus de 230 années de calcul. Sur un cluster de 2 500 machines, le passage à YARN double l’utilisation CPU moyenne. L’entreprise exécute deux fois plus de tâches qu’auparavant.

Les performances progressent. En 2013, l’implémentation MapReduce sur YARN établit des records dans les benchmarks Daytona et Indy GraySort. Le système trie 1,42 téraoctets de données par minute sur un cluster de 2 100 nœuds. Ces résultats démontrent sa capacité à traiter efficacement des volumes massifs.

L’architecture de Hadoop influence la conception des systèmes distribués modernes. Sa capacité à fonctionner sur du matériel standard, sa tolérance aux pannes et son modèle de programmation simple en font une référence. Le concept de localité des données, où le calcul se déplace vers les données plutôt que l’inverse, sera un principe déterminant de l’informatique distribuée.

Le succès de Hadoop inspire le développement de nombreuses plateformes concurrentes. Twitter crée Mesos, Facebook conçoit Corona, Google élabore Omega. Chaque système apporte ses innovations, mais tous partagent l’héritage architectural de Hadoop : la séparation entre la gestion des ressources et les modèles de programmation.

L’évolution de Hadoop reflète la transformation des besoins en traitement de données. D’un outil spécialisé pour l’indexation du web, il se transforme en plateforme générique supportant une multitude d’applications. Cette transformation s’accompagne d’améliorations continues en matière de performances, de flexibilité et de facilité d’utilisation.

En démontrant la viabilité du traitement distribué à grande échelle sur du matériel standard, Hadoop démocratise l’analyse des données massives. Des entreprises de toutes tailles peuvent désormais construire des infrastructures de traitement de données performantes sans investir dans du matériel spécialisé coûteux. La collaboration entre entreprises, développeurs et chercheurs au sein de la Fondation Apache a permis des avancées rapides et une large diffusion des connaissances.

Haut de page

jQuery

En 2005, John Resig était étudiant en informatique au Rochester Institute of Technology. Il passait ses journées à coder des sites web et butait sans cesse sur le même problème : faire fonctionner du JavaScript sur différents navigateurs relevait du parcours du combattant. Chaque navigateur avait ses propres règles, ses propres caprices. Il fallait écrire plusieurs versions du même code, tester, corriger, recommencer. Cette situation épuisait les développeurs et ralentissait tout le monde.

Il décida de créer sa propre solution. L’année suivante, lors d’un événement technologique appelé BarCampNYC, il présenta la première version de jQuery. Son ambition tenait en une phrase : rendre la programmation JavaScript agréable. Il s’était inspiré du travail de Charles Willison, un développeur britannique qui avait créé css_selector.js, une bibliothèque permettant de sélectionner des éléments CSS. Resig reprit cette idée et la poussa beaucoup plus loin.

jQuery proposait une interface simple pour manipuler les pages web. Les développeurs pouvaient sélectionner des éléments HTML avec des expressions complexes, les modifier, les animer. Le moteur de sélection fonctionnait remarquablement bien. Plus tard, ce moteur fut extrait dans une bibliothèque à part, baptisée Sizzle, tant il représentait une avancée technique.

Mais la vraie force de jQuery ne résidait pas que dans son code. Resig avait compris quelque chose que beaucoup d’autres développeurs négligeaient : une bonne documentation valait de l’or. Entre 2006 et 2007, jQuery fut la seule bibliothèque JavaScript open source à proposer une documentation complète et claire. Les autres projets laissaient les développeurs se débrouiller avec le code source. Cette attention aux détails changea tout.

Resig recruta d’abord un responsable communautaire. Pas un développeur supplémentaire, non : quelqu’un dont le travail consistait à répondre aux questions, à accompagner les utilisateurs. Il voyait loin et savait qu’un outil technique ne se diffuse pas tout seul.

Au début, jQuery resta un projet parallèle. Resig travaillait sur d’autres choses. Son embauche chez Mozilla changea la donne. L’entreprise lui permit de consacrer du temps de travail à jQuery. Il put alors bâtir l’infrastructure nécessaire, préparer le projet à durer sans lui. Il quitta ensuite Mozilla pour Khan Academy, mais jQuery était lancé.

La bibliothèque connut un succès foudroyant à la fin des années 2000. Elle rendait accessibles des techniques sophistiquées comme les animations ou les requêtes Ajax. Les développeurs l’adoptèrent massivement. D’après W3Techs, environ 74% des sites web utilisèrent jQuery à son apogée. Un chiffre vertigineux.

Le projet grandit, sa gouvernance aussi. Un jQuery Board vit le jour en 2011, suivi d’une jQuery Foundation en 2012. Puis vint une fusion avec la Dojo Foundation en 2015, créant la JS Foundation. En 2019, nouvelle fusion avec la Node.js Foundation : l’OpenJS Foundation naquit, et jQuery y conserva sa place de projet majeur.

Mais le web évoluait. Les éditeurs de navigateurs—Apple, Google, Microsoft et Mozilla—commencèrent à travailler ensemble au sein du Web Hypertext Application Technology Working Group. Les incompatibilités entre navigateurs diminuèrent. Les navigateurs eux-mêmes intégrèrent des fonctionnalités qui rendaient jQuery moins indispensable. L’API Fetch remplaça les fonctions Ajax. Les méthodes querySelector et querySelectorAll permirent de sélectionner des éléments comme le faisait jQuery. L’interface classList simplifia la manipulation des classes CSS.

Les navigateurs adoptèrent des mises à jour automatiques et continues. Les corrections et nouveautés atteignaient les utilisateurs automatiquement, sans action manuelle. Les développeurs purent exploiter plus vite les nouvelles fonctionnalités du web. Ils eurent moins besoin de solutions de compatibilité.

Internet Explorer mourut progressivement. Microsoft abandonna le support des versions 10 et antérieures en 2016, ne conservant qu’IE 11. Cette disparition libéra les développeurs des contraintes qui avaient justifié jQuery au départ.

De nouveaux frameworks apparurent : React, Angular, Vue. Ils proposaient une approche différente, par composants, facilitant la construction d’interfaces complexes. Ils encourageaient une programmation déclarative où le développeur décrit l’état souhaité plutôt que les étapes pour y parvenir. jQuery, lui, restait impératif.

Certains acteurs majeurs abandonnèrent jQuery. GitHub le retira de son interface. Bootstrap annonça qu’il s’en affranchirait dans sa version 5, jQuery constituant sa principale dépendance JavaScript côté client.

Pourtant, jQuery ne disparut pas. Pour les sites simples nécessitant peu d’interactivité, la bibliothèque reste une solution éprouvée et facile à mettre en œuvre. Son approche impérative demeure plus accessible aux débutants que les paradigmes déclaratifs modernes. Dans certains contextes professionnels où d’anciennes versions d’Internet Explorer tournent encore, jQuery garde son utilité. La bibliothèque continue d’évoluer, maintenue par une communauté fidèle. Beaucoup de développeurs apprécient sa syntaxe concise et l’utilisent par préférence, tandis que des alternatives natives existent. La progression des standards web et l’émergence de nouvelles approches témoignent d’une évolution continue des technologies, un processus auquel jQuery a largement participé en établissant des pratiques qui perdurent.

Haut de page

PowerShell

En 2002, Jeffrey Snover rédige chez Microsoft un document qui va changer l’administration système sous Windows. Le « Manifeste Monad » expose une vision alors peu commune : créer un shell qui manipule des objets plutôt que du texte. Le nom du projet renvoie à Leibniz et son concept d’unités fondamentales capables, par agrégation, de former des systèmes plus élaborés.

L’administration de Windows traversait à l’époque une crise d’identité. D’un côté, des outils graphiques simples pour les opérations basiques. De l’autre, des langages de programmation complexes pour l’automatisation avancée. Entre les deux, un vide. Les administrateurs peinaient à composer des solutions d’automatisation sans basculer dans la programmation lourde. Microsoft avait passé des années à simplifier Windows pour les novices, rendant paradoxalement certaines tâches plus ardues pour les utilisateurs expérimentés qui privilégiaient l’efficacité des lignes de commande.

Snover s’inspire des shells UNIX tout en cherchant à dépasser leurs limites. Dans ces environnements, les commandes produisent du texte non structuré que les commandes suivantes doivent analyser, un processus fragile et source d’erreurs. L’idée novatrice de PowerShell tient dans son approche orientée objet : le shell transmet des objets .NET structurés entre les commandes, éliminant cette fragilité.

Le projet faillit ne jamais voir le jour. Entre 2004 et 2006, plusieurs initiatives majeures basées sur du code managé chez Microsoft connaissent des échecs retentissants, provoquant les retards de Windows Vista. Promouvoir un langage de script reposant sur .NET est risqué. L’équipe Exchange Server, première à adopter PowerShell, développe d’ailleurs une couche d’API intermédiaire qui lui permettrait de basculer vers une autre solution en cas de problème.

PowerShell arrive finalement en 2006. Il introduit les « cmdlets », des commandes légères implémentées comme des classes .NET. Cette architecture garantit une cohérence syntaxique et sémantique rare dans les shells traditionnels, où chaque commande définit ses propres conventions. La version 2.0, livrée avec Windows 7, enrichit l’outil avec l’exécution de scripts à distance et les tâches en arrière-plan.

La standardisation des verbes dans les noms de commandes (Get-, Set-, New-) et l’introduction des providers marquent une rupture. Ces derniers traitent différentes sources de données – système de fichiers, registre Windows, Active Directory – avec une syntaxe uniforme. Les administrateurs n’ont plus à réapprendre un jeu de commandes pour chaque source, ce qui réduit considérablement la courbe d’apprentissage.

L’adoption s’accélère quand Microsoft intègre PowerShell dans ses produits serveur. Exchange Server 2007 rend PowerShell obligatoire pour certaines tâches. Cette décision force les administrateurs à franchir le pas, se rendant vite à l’évidence des avantages en termes d’efficacité et d’automatisation.

L’architecture du shell rompt avec l’approche traditionnelle. Au lieu de créer des exécutables autonomes, les développeurs écrivent des classes .NET héritant d’une classe de base commune. Celle-ci fournit gratuitement l’analyse des paramètres, la validation des données, la journalisation ou la gestion des erreurs. Cette mutualisation du code réduit les coûts de développement et améliore l’expérience utilisateur.

L’environnement de développement intégré (ISE), ajouté plus tard, offre aux administrateurs un outil moderne pour écrire et déboguer des scripts. Coloration syntaxique, auto-complétion et débogueur graphique accompagnent la transition des interfaces graphiques vers l’automatisation par script.

Une communauté active se forme autour de PowerShell. Les administrateurs partagent scripts et bonnes pratiques, tandis que les éditeurs de logiciels adoptent l’outil pour administrer leurs produits. Cette adoption valide la vision initiale de Snover d’une plateforme unifiée d’automatisation.

La sécurité occupe une place centrale dans PowerShell. Le shell intègre des mécanismes de signature de code et de journalisation détaillée des activités. Les organisations peuvent contrôler l’exécution des scripts et tracer leur utilisation, répondant aux exigences de sécurité et de conformité.

L’impact sur l’administration Windows se révèle considérable. PowerShell transforme l’interaction avec le système, remplaçant les actions manuelles répétitives par des solutions automatisées reproductibles. Cette évolution améliore l’efficacité et réduit les erreurs humaines dans les opérations système.

En 2016, Microsoft rend PowerShell open source sous licence MIT et multiplateforme. Cette décision reflète l’évolution de l’entreprise vers plus d’ouverture et reconnaît la réalité des environnements informatiques modernes, où Windows coexiste avec Linux et macOS.

Haut de page

MongoDB

En 2007, trois entrepreneurs américains, Dwight Merriman, Eliot Horowitz et Kevin Ryan, se lancent dans un projet de plateforme en tant que service. Ils constatent que les bases de données relationnelles traditionnelles peinent à répondre aux exigences d’extensibilité et d’agilité de leur infrastructure. Cette contrainte les pousse à imaginer leur propre solution.

Le contexte de l’époque voit s’effriter le mythe de la base de données universelle. Les architectures informatiques se diversifient, chacun cherche des réponses à des problèmes spécifiques. Les bases NoSQL émergent, les bases temporelles aussi. Cette fragmentation du paysage technologique oblige à repenser les choix d’outillage, car chaque type de système répond à des besoins particuliers.

MongoDB se construit autour d’un modèle orienté document qui utilise BSON, une variante binaire de JSON. Cette architecture autorise une représentation souple des données tout en maintenant des performances élevées. Le système gère finement le cache et la localisation des informations, avec une limite fixée à 16 Mo par document pour garantir une utilisation optimale de la mémoire.

L’évolution technique apporte son lot d’innovations. WiredTiger, le moteur de stockage adopté par la suite, introduit la conformité ACID dans les transactions. MongoDB parvient ainsi à marier la souplesse du NoSQL avec la rigueur transactionnelle des systèmes relationnels classiques.

La montée en charge horizontale figure parmi les atouts majeurs de MongoDB. Deux mécanismes de fragmentation coexistent : par plage et par hachage. Cette architecture distribue les données sur plusieurs serveurs, rendant l’extension transparente pour les applications. Le routeur de requêtes exploite cette répartition géographique pour accélérer les traitements, le code écrit pas les développeurs peut donc être identique quelle que soit la distribution physique des données.

La disponibilité atteint 99,99% sans intervention humaine grâce à la réplication automatique et aux capacités d’auto-réparation. Les jeux de réplicas basculent automatiquement lors d’une panne, un nœud secondaire prenant la place du primaire selon un processus d’élection bien rodé.

La sécurité, souvent le talon d’Achille des bases NoSQL, a bénéficié d’améliorations continues. MongoDB intègre désormais le chiffrement au repos via TDE, l’authentification LDAP et Kerberos, le chiffrement TLS/SSL, ainsi que des protections contre les injections SQL. Ces ajouts le placent en bonne position face à ses concurrents NoSQL.

Les cas d’usage se dessinent naturellement. Les applications d’analyse en temps réel sur de gros volumes, comme celles des marchés financiers ou du traitement de flux Twitter, trouvent en MongoDB un allié de choix. Le commerce électronique exploite ses capacités d’analyse comportementale pour affiner l’expérience client. L’Internet des Objets constitue un autre terrain de prédilection, la flexibilité du modèle de données gérant sans difficulté l’hétérogénéité des informations remontées par les capteurs.

La commercialisation se décline en deux versions : entreprise et open source. Cette double approche crée une communauté active de développeurs tout en assurant des revenus réguliers. L’intégration aux plateformes cloud majeures comme Amazon Web Services et Azure renforce sa présence sur le marché des bases de données modernes.

Quelques limites apparaissent néanmoins. MongoDB s’adapte mal aux données fortement relationnelles, aux environnements réclamant une intégrité référentielle stricte, ou aux opérations multipliant les jointures entre documents. L’absence de procédures stockées et de déclencheurs contraint la logique métier hors de la base. Les entrepôts de données et les représentations graphiques complexes ne correspondent pas à ses points forts.

L’influence de MongoDB sur l’écosystème des bases de données reste tangible. Son succès a validé l’approche NoSQL pour les applications d’entreprise et façonné la conception des systèmes modernes de gestion de données. Sa capacité à traiter dans un même environnement des données non structurées, semi-structurées et structurées a redéfini certains standards industriels.

Le développement continu reflète les mutations des besoins en gestion de données. La progression vers les architectures distribuées, l’importance croissante de l’analyse instantanée et l’apparition de nouveaux modèles d’application ont tracé son évolution. Cette adaptation permanente au marché explique sa position actuelle.

Haut de page

Apple iPhone

En janvier 2007, Steve Jobs monte sur la scène du Macworld à San Francisco pour présenter un appareil dont presque personne ne connaissait l’existence. Deux années de secret absolu ont précédé ce moment. Seuls trois dirigeants d’AT&T avaient pu voir l’iPhone avant sa révélation au grand public. Jobs avait négocié directement avec l’opérateur américain un partenariat exclusif qui allait redessiner les rapports de force dans le monde des télécommunications.

Le marché des téléphones en 2007 ressemblait à ce qu’il était quelques années auparavant. BlackBerry dominait avec ses claviers physiques, Palm proposait ses Treo, et les utilisateurs s’accommodaient d’interfaces complexes qui demandaient un vrai temps d’apprentissage. Internet sur mobile restait une expérience frustrante, la messagerie fonctionnait tant bien que mal, et l’idée d’un téléphone vraiment intuitif paraissait hors de portée.

L’iPhone arrive avec son écran tactile de 3,5 pouces et une idée simple : on touche directement ce qu’on veut faire. Pas de stylet, pas de clavier caché sous l’écran. Les doigts suffisent, et la surface réagit à plusieurs points de contact simultanés. Apple a breveté cette technologie multipoint et l’a placée au cœur d’un appareil qui prétend être trois choses à la fois : un téléphone, un iPod, et un moyen de naviguer sur Internet. Cette convergence n’avait jamais vraiment fonctionné auparavant.

Jobs applique à l’iPhone sa maniaquerie habituelle. Il scrute chaque vis, examine les courbes du boîtier sous tous les angles, et va jusqu’à faire refaire l’emballage parce que la bande adhésive ne se trouve pas exactement où elle devrait être. Chez Apple, le déballage du produit compte autant que le produit. Cette obsession du détail traduit une vision particulière de ce que doit être un objet technologique : quelque chose qui fonctionne avant qu’on ait lu le mode d’emploi.

Quand l’iPhone arrive dans les magasins en juin 2007, les files d’attente se forment spontanément. Apple et AT&T vendent deux versions : 499 dollars pour 4 Go, 599 dollars pour 8 Go. Ces prix n’effraient personne. L’entreprise vise modestement 1% du marché mondial pour 2008, soit 10 millions d’unités. Elle dépassera largement cet objectif.

La distribution rompt avec les habitudes du secteur. Pas question de voir l’iPhone chez Best Buy ou RadioShack. Apple impose ses propres magasins et ceux d’AT&T comme seuls points de vente. Cette restriction donne entièrement à Apple le contrôle de la présentation de l’appareil et de l’expérience d’achat. Les revendeurs traditionnels rongeront leur frein pendant des mois.

Techniquement, l’iPhone accumule les trouvailles comme le détecteur de proximité qui éteint l’écran quand on approche le téléphone de l’oreille. Un capteur de luminosité ajuste la brillance selon la lumière ambiante. Un accéléromètre fait pivoter l’affichage quand on tourne l’appareil. Le système d’exploitation dérive d’OS X et gère le multitâche avec une efficacité qui étonne les observateurs. Apple a construit matériel et logiciel en même temps, les faisant dialoguer dès la conception. Ses concurrents séparent ces deux mondes.

Le succès transforme Apple. L’entreprise abandonne le mot « Computer » dans sa raison sociale au profit de Apple Inc., tout simplement. Ce changement reflète la réalité d’une société qui ne vend plus seulement des ordinateurs depuis longtemps. L’iPhone accélère cette mutation et fait basculer le centre de gravité vers les appareils mobiles.

La culture du secret règne dans l’entreprise. Les équipes travaillent sur des fragments de projet sans voir l’ensemble. Seule une poignée de responsables connaît la vision complète. Cette compartimentation frustre certains ingénieurs mais garantit que rien ne fuite avant les annonces officielles. Jobs dirige l’ensemble depuis une structure très centralisée, refusant de créer des divisions autonomes qui pourraient diluer le contrôle.

L’iPhone débarque au Royaume-Uni et en France fin 2007, puis en Asie l’année suivante. Dans chaque pays, Apple reproduit le schéma américain : un seul opérateur, un accord exclusif, une distribution maîtrisée. Ces pratiques soulèvent des questions juridiques en Europe, où la vente liée d’un téléphone à un opérateur unique bute sur certaines réglementations. Apple négocie au cas par cas.

Les concurrents réagissent comme ils peuvent. Nokia lance son N95 avec des capacités multimédia renforcées. D’autres fabricants se précipitent sur les écrans tactiles, souvent sans comprendre que la réussite d’Apple tient autant à l’interface logicielle qu’au matériel. Le marché bascule en quelques mois : ce que l’iPhone propose est la nouvelle référence.

En 2008, Apple ouvre l’App Store et change encore les règles. Les développeurs externes peuvent créer des applications et les vendre directement aux utilisateurs. L’iPhone gagne ainsi des milliers de fonctions que personne n’avait imaginées au départ. Un écosystème économique naît presque instantanément, attirant programmeurs indépendants et grandes entreprises.

L’université Harvard estime la valeur de la publicité gratuite générée par le lancement de l’iPhone à 400 millions de dollars. Apple n’a presque rien dépensé en campagnes traditionnelles. Les médias ont fait le travail gratuitement, relayant chaque annonce, chaque file d’attente, chaque première impression. Cette réussite marketing repose sur une préparation minutieuse et un sens aigu du spectacle.

La valeur boursière d’Apple double dans les douze mois qui suivent. Les analystes comprennent que l’iPhone n’est pas un produit parmi d’autres mais le nouveau pilier de l’entreprise. Jobs avait vu juste : un appareil qui combine téléphone, lecteur multimédia et navigateur Internet dans une interface fluide peut changer les usages. C’est une rupture dans l’histoire de l’informatique mobile et des télécommunications.

Haut de page

Clojure

En 2005, Rich Hickey se lance dans l’aventure Clojure. Il finance cette entreprise avec ses économies de retraite, prenant une année sabbatique pour concevoir un langage qui résoudrait les problèmes qu’il rencontre quotidiennement depuis des années. Son ambition ? Créer un outil aussi acceptable en entreprise que Java ou C#, mais débarrassé des complexités inutiles qui encombrent le développement des systèmes d’information.

Hickey n’est pas un novice. Depuis 1987, il travaille comme architecte logiciel, naviguant entre C++, Java et C#. Cette longue expérience lui a appris une chose : les langages orientés objet traditionnels imposent un prix élevé. La programmation impérative avec état mutable exige des efforts démesurés dès qu’il faut modifier un programme sans rompre la cohérence des données. Ces systèmes rigides résistent au changement malgré l’encapsulation et les abstractions.

Parallèlement à son travail, Hickey explore Common Lisp dans ses projets personnels. Cette pratique lui ouvre les yeux : toute cette complexité qu’il combat au bureau n’est pas une fatalité. Avec la flexibilité de Lisp, on attaque un problème exactement au bon niveau, sans couches superflues. Mais Common Lisp reste cantonné aux expérimentations. Les entreprises refusent de déployer des applications écrites dans ce langage. À deux reprises, Hickey doit réécrire en C++ des systèmes qu’il avait développés en Common Lisp, ou les transformer en procédures stockées SQL pour satisfaire ses clients.

L’idée germe alors de marier la puissance de Lisp avec l’acceptabilité de Java. Hickey choisit la machine virtuelle Java comme fondation. Cette décision tactique élimine d’emblée les obstacles à l’adoption : Clojure est un citoyen de première classe de l’écosystème Java, avec son interopérabilité native et sa capacité à réutiliser les bibliothèques existantes.

Le premier défi technique se posa pour rendre les structures de données immuables suffisamment performantes pour un usage pratique. Durant l’hiver 2006-2007, Hickey implémente une version persistante des tables de hachage à essai mappé avec un facteur de branchement de 32. Les primitives de copie de tableau de Java se révèlent efficaces. Cette percée délivre des performances quasi-constantes pour les opérations courantes, rendant l’immutabilité enfin viable en production.

En octobre 2007, la première version alpha de Clojure apparaît sur la liste de diffusion jFli. Le site clojure.org ouvre ses portes, accompagné d’un groupe Google. La réaction dépasse toutes les prévisions : 30 000 visites en trois jours. Les dix-huit mois qui suivent voient le langage s’étoffer considérablement. La bibliothèque standard quadruple, passant de 100 à plus de 400 fonctions.

Clojure se distingue par sa gestion de l’état. Le langage propose plusieurs types de références selon les besoins : les refs utilisent un système transactionnel inspiré des bases de données, les agents gèrent des mises à jour asynchrones, les atoms offrent des modifications atomiques simples. Cette approche contraste avec le modèle uniforme mais limité des langages impératifs traditionnels.

Mai 2009 marque la sortie de Clojure 1.0, accompagnée du premier ouvrage consacré au langage. La version 1.1 arrive en décembre avec les séquences chunked et les transients, apportant des gains de performance substantiels. La version 1.2 en 2010 introduit protocoles et types définis par l’utilisateur, complétant l’arsenal polymorphique du langage.

L’année 2011 ouvre un nouveau chapitre avec ClojureScript. Cette implémentation s’exécute sur les moteurs JavaScript, étendant Clojure au développement web côté client. Le projet démontre la robustesse des abstractions du langage : elles fonctionnent sur une plateforme radicalement différente de la JVM sans modification conceptuelle.

En 2012, Hickey lance Datomic, une base de données qui transpose les principes de Clojure au stockage : immutabilité, temps explicite, sémantique fonctionnelle. Le format EDN (Extensible Data Notation) formalise la syntaxe de sérialisation utilisée par Clojure, offrant une alternative aux formats traditionnels.

La communauté grandit à son rythme. Les conférences Clojure/conj débutent en 2010. ClojureBridge naît en 2014 pour diversifier l’écosystème à travers des ateliers gratuits. Le langage trouve sa place dans des secteurs variés : finance, climatologie, commerce de détail, analyse de données, édition, santé, publicité, génomique.

Des acteurs majeurs l’adoptent pour des systèmes critiques. Walmart traite les reçus électroniques de ses 5 000 magasins avec Clojure. Netflix analyse 2 000 milliards d’événements quotidiens grâce au langage. Nubank, banque numérique comptant plus de 12 millions de clients, bâtit son infrastructure sur Clojure et Datomic.

Le succès repose sur une programmation fonctionnelle avec structures immuables performantes, une interopérabilité native avec la plateforme hôte, des abstractions puissantes pour la concurrence, et un traitement générique des données. Ces atouts font de Clojure un outil adapté aux systèmes d’information contemporains. En 2025, le développement continue son cours mesuré, améliorant outillage et expérience développeur plutôt que d’accumuler des fonctionnalités.

Haut de page

F#

Microsoft cherche à consolider sa plateforme .NET face à la montée en puissance de Java. Le langage F# naît alors d’une rencontre singulière : celle entre les travaux académiques sur la programmation fonctionnelle et les besoins pragmatiques de l’industrie logicielle.

Les racines de F# plongent dans les années 1970, avec les travaux de Robin Milner sur ML (Meta Language). Ce langage introduisait l’inférence de types et le pattern matching, des concepts pensés initialement pour manipuler des preuves mathématiques. La famille ML, qui compte Standard ML et OCaml, forme le terreau théorique dont F# héritera les principes fondamentaux.

En 1997, Microsoft lance le « Projet 7 », une initiative ambitieuse visant à intégrer quatorze langages, académiques et commerciaux, dans l’écosystème .NET. Don Syme, chercheur chez Microsoft Research à Cambridge, commence en 2002 le développement de F#. Son objectif ? Marier l’élégance des langages fonctionnels avec la richesse de la plateforme .NET.

La première version publique arrive en 2005. F# se distingue par sa capacité à fusionner programmation fonctionnelle et orientée objet. Mais surtout, il offre une interopérabilité naturelle avec les autres langages .NET. Les développeurs peuvent utiliser les bibliothèques existantes sans friction, un atout déterminant pour l’adoption.

Grâce au système de types inféré, hérité de ML, le compilateur déduit automatiquement les types des expressions. Le code gagne en concision sans sacrifier la sûreté. Les « active patterns » facilitent le pattern matching extensible, tandis que les « computation expressions » simplifient l’écriture de code asynchrone. Ces mécanismes transforment la manipulation de données complexes en opérations fluides.

Microsoft intègre F# à sa gamme officielle en 2007. Le langage trouve sa place dans les domaines financier et scientifique, où la rigueur du typage et la concision du code fonctionnel répondent à des exigences critiques. F# 2.0 sort en 2010, première mouture pleinement supportée par Visual Studio.

En 2012 F# 3.0 introduit des « type providers ». Ce mécanisme génère automatiquement des types correspondant aux schémas de données externes, qu’elles proviennent de bases SQL, de services web ou de fichiers structurés. L’intégration de données rendue presque triviale, des institutions comme Credit Suisse et Morgan Stanley adoptent F# pour leurs systèmes d’analyse et de trading, où chaque erreur peut coûter des millions.

En 2010, Microsoft publie le code source de F# sous licence Apache 2.0. Cette ouverture catalyse la formation d’une communauté de contributeurs. La F# Software Foundation voit le jour en 2014, donnant un cadre organisationnel au développement du langage. F# sort progressivement de l’ombre de Microsoft pour devenir un projet communautaire vivant.

Le langage s’adapte aux mutations du paysage informatique. Des projets comme WebSharper et Fable permettent d’écrire des applications web en F#. Le support de .NET Core ouvre la voie au développement multiplateforme. F# n’est plus cantonné à Windows ; il fonctionne sur Linux et macOS, s’inscrivant dans l’ère du cloud computing.

C# emprunte quelques unes des fonctionnalités de F# : le pattern matching, les types non nullables, certaines constructions fonctionnelles. L’approche de la programmation asynchrone via les computation expressions inspire aussi d’autres langages. F# démontre qu’un langage fonctionnel peut cohabiter avec la programmation orientée objet, mais aussi l’enrichir. Il reste un langage de niche, certes, mais une niche où la qualité du code et la sûreté des applications comptent plus que tout.

Haut de page

Groovy

En 2003, Java trônait sur le monde informatique avec sa bibliothèque de composants considérable. Pourtant, son architecture rigide décourageait ceux qui voulaient simplement scripter une tâche, prototyper ou écrire du code minimal. Ruby, Python et Smalltalk paraissaient plus agiles, mais leur syntaxe déroutait les programmeurs habitués à Java. James Strachan créa alors Groovy : un langage qui resterait fidèle à l’esprit Java tout en éliminant ses lourdeurs.

L’idée était simple : garder l’apparence de Java pour ne pas désorienter les développeurs, mais alléger la syntaxe et réduire les contraintes. Strachan voulait un « Python à saveur Java », où Groovy servirait de colle entre les bibliothèques Java existantes. Le langage devait s’intégrer naturellement à l’écosystème de la JVM sans bouleverser les habitudes.

Mars 2004 marqua une étape décisive : Groovy fut soumis comme Java Specification Request (JSR 241) et accepté par vote. Ce processus exigeait une spécification rigoureuse, une implémentation de référence et des tests de compatibilité. La charge de travail s’avéra écrasante. Des tensions émergèrent au sein de la communauté sur les directions à prendre. Strachan finit par se retirer, laissant Guillaume Laforge reprendre le flambeau.

Le JSR ne fut jamais voté dans sa forme finale, mais ce passage obligé força l’équipe à structurer le langage. Sans cette contrainte, les fonctionnalités accumulées pendant le développement initial auraient sans doute formé un ensemble disparate plutôt qu’un tout cohérent.

Janvier 2007 vit naître la version 1.0. Elle apportait les fermetures lexicales, les scripts, les constructeurs, les chaînes interpolées (GStrings) et les paramètres nommés. Le langage intégrait nativement les expressions régulières, la surcharge d’opérateurs et une syntaxe littérale pour les listes et les cartes. Le Groovy Development Kit enrichissait environ 430 classes Java standard avec de nouvelles méthodes.

Deux ans plus tard, Groovy dépassait son rôle initial de langage de script. On l’utilisait désormais pour développer des applications complètes. Ses capacités de métaprogrammation à l’exécution, déjà robustes, furent complétées par des fonctionnalités à la compilation. Cette évolution permit de réduire la complexité du code sans sacrifier les performances.

En 2012, le langage gagnait du terrain sur des projets traditionnellement réservés à Java. Les utilisateurs réclamaient plus de vérifications de types à la compilation et de meilleures performances. L’équipe ajouta une nature statique au langage. Groovy ne renonçait pas à son dynamisme : il offrait simplement le choix entre typage statique et dynamique selon les besoins du projet.

Les transformations AST (Abstract Syntax Tree), introduites avec la version 1.6, changèrent la donne. Elles permettaient d’étendre le langage sans toucher à sa grammaire. Cette approche déclarative, basée sur des annotations, facilitait l’application de motifs de conception Java. L’annotation @Immutable, par exemple, générait automatiquement tout le code nécessaire pour créer une classe immuable conforme aux bonnes pratiques.

La version 2.4 apporta le support d’Android, ce qui entraîna de nombreuses optimisations dans la génération de bytecode. La quantité de code produit diminua, la consommation mémoire des structures internes chuta, et les performances s’améliorèrent. Février 2020 vit arriver la version 3.0 avec son nouveau parseur basé sur Antlr4, offrant une meilleure compatibilité avec la syntaxe Java moderne.

L’histoire organisationnelle de Groovy ressemble à un parcours du combattant. D’abord hébergé sur Codehaus, le projet migra vers la Apache Software Foundation en 2015 après la fermeture de la plateforme. G2One, SpringSource, VMware, Pivotal et OCI sponsorisèrent tour à tour son développement. Malgré ces changements, la communauté open source maintint le cap et assura la progression du langage.

Groovy laissa son empreinte sur d’autres technologies. Kotlin s’inspira de ses fermetures lexicales, de son concept de constructeur, du paramètre par défaut it pour les fermetures, des templates et chaînes interpolées, de l’opérateur Elvis et de la navigation sécurisée. Swift et C# adoptèrent des fonctionnalités similaires comme l’opérateur de navigation sécurisée.

La philosophie de Groovy repose sur l’extensibilité pragmatique. Plutôt que d’intégrer toutes les fonctionnalités possibles dans le cœur du langage, il fournit des mécanismes pour que les utilisateurs enrichissent le langage selon leurs besoins. Les transformations AST, les extensions de vérification de types et la création de langages dédiés (DSL) illustrent cette approche.

Le langage reste vivant et sa communauté continue d’innover tout en préservant la compatibilité avec Java, qui demeure au cœur de sa conception. Groovy tient son équilibre entre productivité accrue pour les développeurs Java et fonctionnalités dynamiques pour des cas d’usage spécifiques.

Haut de page

Android

En 2003, Andy Rubin fonde Android Inc. à Palo Alto, avec l’ambition de créer un système d’exploitation pour appareils mobiles. Ce nom lui va bien : chez Apple puis chez MSN, ses collègues l’avaient surnommé « Android » à cause de sa passion pour la robotique. Quelques années plus tôt, il avait déjà monté Danger Inc., la société qui donna naissance au Danger Hiptop, ce téléphone que T-Mobile commercialisa sous le nom de Sidekick en 2002.

Au départ, l’équipe d’Android Inc. mise sur les appareils photo numériques. Mais ce marché s’effondre tandis que les téléphones mobiles prennent leur essor. Rubin et ses cofondateurs Rich Miner, Nick Sears et Chris White décident alors de pivoter vers un système d’exploitation mobile bâti sur le noyau Linux. L’argent manque terriblement. Steve Perlman, un ami investisseur, doit même apporter 10 000 dollars en liquide pour éviter la faillite.

Google rachète Android Inc. en 2005 pour 50 millions de dollars. Larry Page et Sergey Brin voient loin : ils veulent étendre leur empire au-delà de la recherche sur ordinateur. Le 11 juillet 2005, toute l’équipe d’Android rejoint les bureaux de Mountain View.

À cette époque, le paysage mobile appartient à d’autres. Symbian de Nokia écrase tout avec 63,5% du marché mondial en 2007. Windows Mobile de Microsoft grappille 12%, BlackBerry de RIM se taille 9,6%. Et Apple débarque en janvier 2007 avec l’iPhone, redéfinissant ce qu’est un smartphone. Face à ces géants, Google choisit une voie différente : proposer un système ouvert et gratuit.

L’Open Handset Alliance naît en 2007. Ce consortium rassemble 34 entreprises, des fabricants de téléphones aux opérateurs en passant par diverses sociétés technologiques. Leur mission est de développer des standards ouverts pour les appareils mobiles. Android est le système de référence de cette alliance, distribué en open source sous licence Apache.

La première version publique sort en 2008. L’architecture repose sur le noyau Linux, qui gère le matériel. Au-dessus tourne Dalvik, une machine virtuelle spécialement conçue par Google pour optimiser l’exécution sur mobile. Chaque application fonctionne dans sa propre instance de cette machine virtuelle, plusieurs programmes peuvent donc s’exécuter simultanément.

Les versions se succèdent, baptisées de noms de desserts. Cupcake (1.5) arrive en 2009 avec les widgets et la navigation GPS. Donut (1.6) améliore la recherche et accepte différentes résolutions d’écran. Éclair (2.0-2.1) gère différents comptes e-mail et peaufine l’interface.

Froyo (2.2) en 2010 accélère les performances et renforce la sécurité. Gingerbread (2.3) intègre le NFC et économise mieux la batterie. Honeycomb (3.0) en 2011 adapte Android aux tablettes. Ice Cream Sandwich (4.0) unifie l’expérience entre smartphones et tablettes, avec des nouveautés comme le déverrouillage facial.

Jelly Bean (4.1-4.3) en 2012 rend l’interface plus fluide grâce au « Project Butter ». KitKat (4.4) allège le système pour qu’il tourne sur des machines modestes. Lollipop (5.0) en 2014 introduit le « Material Design », nouvelle esthétique voulue par Google. Marshmallow (6.0) repense les permissions des applications et prolonge l’autonomie.

Le modèle économique tranche avec celui des concurrents. Google offre le système aux fabricants, se rémunérant via la publicité et les services comme le Play Store. Apple garde son écosystème fermé, Microsoft facture des licences : Android prend une troisième voie.

L’adoption explose. En 2010, plus de 100 millions d’appareils tournent sous Android. En 2021, on en compte 3 milliards dans le monde. Cette domination attire l’attention des autorités de la concurrence. La Commission européenne inflige 4,34 milliards d’euros d’amende à Google en 2018 pour abus de position dominante.

Le système déborde vite de son cadre initial. Il équipe des tablettes, des montres connectées, des télévisions, des voitures. Android Wear s’occupe des objets connectés, Android Auto de l’automobile, faisant de ce système une plateforme universelle pour l’informatique mobile.

L’architecture technique évolue avec les besoins. ART remplace progressivement Dalvik pour améliorer les performances et l’efficacité énergétique. Le système intègre reconnaissance faciale, paiement sans contact, réalité augmentée. La sécurité se renforce continuellement : chiffrement des données, isolation des applications dans des sandbox, mises à jour mensuelles. Le modèle de permissions plus transparent donne à l’utilisateur un contrôle accru.

Android a transformé l’industrie mobile. Le système démocratise l’accès aux smartphones en permettant aux constructeurs de proposer des appareils à tous les prix. Il stimule l’innovation grâce à une plateforme ouverte aux développeurs. Son modèle open source inspire d’autres projets et influence l’évolution des systèmes mobiles.

Cette réussite tient à un équilibre : la puissance du noyau Linux, l’efficacité d’une machine virtuelle pensée pour le mobile, une interface intuitive. Android satisfait les constructeurs, les développeurs et les utilisateurs, tout en s’adaptant aux mutations technologiques et aux nouveaux usages.

Haut de page

Google Chrome

En septembre 2008, Google lance la version bêta de Chrome, son propre navigateur web. À cette époque, Internet Explorer domine le marché et Firefox s’est imposé comme l’alternative incontournable. Mais les applications web gagnent en complexité, HTML5 est en préparation et les navigateurs existants montrent leurs limites. Google constate que les navigateurs gèrent mal ces nouvelles applications, provoquant régulièrement des plantages qui affectent toute la navigation.

Chrome arrive avec une architecture multi-processus. Chaque onglet tourne dans son propre processus, isolé des autres. Quand une page plante, seul l’onglet concerné se ferme. Les autres composants du navigateur continuent de fonctionner normalement. Cette rupture avec les navigateurs monolithiques traditionnels transforme l’expérience utilisateur.

La sécurité occupe une place centrale dès la conception. Le sandboxing isole les processus de rendu en limitant drastiquement leurs privilèges et leur accès au système d’exploitation. Un processus compromis ne peut pas infecter le reste du système. Chrome s’appuie sur quatre mécanismes de sécurité Windows pour renforcer cette protection contre les logiciels malveillants.

Le moteur JavaScript V8 marque une avancée technique majeure. Développé par une équipe Google au Danemark, il compile directement en code machine sans passer par un interpréteur. Les classes cachées optimisent le traitement des objets similaires. Le ramasse-miettes est précis tout en demeurant léger, rendant l’exécution de JavaScript bien plus rapide que sur les moteurs concurrents.

L’interface de Chrome frappe par sa simplicité. Les développeurs ont suivi le principe « interface simple, cœur puissant ». Ils ont maximisé l’espace d’affichage des pages en réduisant les éléments d’interface au strict nécessaire. La barre d’adresse et le champ de recherche fusionnent dans l’omnibox. Cette approche minimaliste inspirera ensuite de nombreux autres navigateurs.

Google publie simultanément Chromium, qui est la version open source (et la base) de Chrome. La majorité du code source sort sous licence BSD, permettant aux développeurs de l’utiliser librement. Ce choix stratégique favorise l’adoption des technologies Chrome et stimule l’innovation dans tout l’écosystème des navigateurs.

Les performances restent au cœur des préoccupations. En 2015, Chrome introduit un cache de bytecode JavaScript. Les scripts fréquemment utilisés voient leur code compilé conservé sur le disque. Les pages se chargent plus vite, même après un redémarrage du navigateur. Cette optimisation illustre l’attention constante portée à la vitesse d’exécution.

Chrome intègre WebKit comme moteur de rendu, initialement créé par Apple. Mais Google ne retient que le composant WebCore et développe sa propre couche d’adaptation. Cette personnalisation lui donne un contrôle total sur les performances du navigateur.

Le succès arrive vite. Un an après son lancement, en août 2009, Chrome est le troisième navigateur le plus utilisé au monde, dépassant Safari et Opera. En novembre 2010, il franchit la barre des 10% de parts de marché aux États-Unis. La progression s’accélère d’année en année.

En 2020, Microsoft abandonne EdgeHTML et reconstruit Edge sur la base de Chromium. Brave, Opera et bien d’autres navigateurs s’appuient sur cette technologie. Un écosystème riche se développe autour du projet.

Le Chrome Web Store, lancé en 2010, centralise la distribution des extensions. Cette plateforme structurée facilite la découverte et l’installation d’extensions, un atout dans l’adoption de Chrome, enrichissant les fonctionnalités du navigateur.

Les mises à jour automatiques changent la façon de distribuer un navigateur. Chrome s’actualise silencieusement en arrière-plan, sans intervention de l’utilisateur. Cette approche améliore la sécurité en garantissant que chacun dispose des dernières corrections. Plus besoin d’attendre qu’un utilisateur décide de mettre à jour manuellement son navigateur.

Chrome évolue avec le Web. Le navigateur intègre progressivement des technologies avancées comme le CSS Paint API pour personnaliser le rendu graphique, ou les transformations CSS 3D pour des effets visuels sophistiqués. Ces fonctionnalités répondent aux besoins des applications web modernes qui rivalisent désormais avec les applications natives.

L’architecture de Chrome inspire la conception de systèmes d’exploitation. Chrome OS, lancé en 2011, étend les principes du navigateur à l’échelle d’un OS complet. Google y voit l’avenir de l’informatique, un monde centré sur le web où le navigateur est la plateforme principale d’exécution des applications. Ce qui se vérifie avec l’explosion des solutions SaaS en entreprise.

La recherche de vitesse ne s’arrête jamais. Les optimisations touchent le chargement des pages, l’exécution du JavaScript, le rendu des images. Chrome introduit le préchargement des ressources et la compression des données pour réduire encore les temps de chargement. Chaque milliseconde compte.

En 2023, quinze ans après son lancement, Chrome domine le marché des navigateurs web. Son influence sur l’évolution des standards web et des technologies de navigation est immense. Les innovations techniques de Chrome se sont généralisées. Le web s’est transformé en une véritable plateforme d’applications sophistiquées, et Chrome y a joué un rôle décisif.

Haut de page

HTML5

Au tournant des années 2010, le Web traverse une période où les smartphones se multiplient, les réseaux sociaux explosent, et les développeurs se heurtent à une limitation frustrante : comment écrire du code qui fonctionne partout sans devoir tout réécrire pour chaque plateforme ? HTML5 arrive dans ce contexte, non comme une simple mise à jour technique, mais comme une refonte de l’architecture du Web.

L’histoire commence en 2004, quand Ian Hickson, alors chez Apple, cofonde le WHATWG (Web Hypertext Application Technology Working Group). Ce groupe rassemble des ingénieurs d’Apple, de Mozilla Foundation et d’Opera Software, tous convaincus qu’il faut repenser les fondations du Web. Le W3C finit par intégrer leurs travaux dans une vision plus large d’une plateforme ouverte.

HTML5 ne se résume pas à un nouveau langage de balisage. C’est un ensemble cohérent qui englobe le Document Object Model, les feuilles de style CSS, JavaScript, et toute une série d’interfaces standardisées pour la vidéo, la géolocalisation, le stockage local ou les graphiques. Cette approche globale est une aubaine pour les développeurs.

Matthew McVickar, développeur web chez Ocupop, l’exprime clairement : HTML5 officialise des pratiques que les développeurs utilisaient déjà, mais de manière bricolée. Avec l’interface JavaScript pour la géolocalisation, par exemple, les navigateurs mobiles accèdent au GPS sans passer par des solutions propriétaires. Fini les bidouilles, place aux standards.

CSS3 apporte sa pierre à l’édifice en transformant la gestion de l’apparence des pages. Les développeurs créent maintenant des effets visuels directement dans le navigateur, sans passer par Photoshop ou d’autres outils externes. Le gain de temps est considérable, la flexibilité accrue.

Le stockage local marque une rupture avec les cookies traditionnels. Cette fonction autorise le stockage de volumes importants de données structurées côté client, permettant ainsi aux applications Web de tourner sans connexion internet. Les capacités graphiques s’enrichissent aussi avec le support natif des graphiques vectoriels SVG et l’élément Canvas, qui ouvre la porte aux animations 2D et 3D via JavaScript.

Ian Hickson, passé entre-temps chez Google, insiste sur la rigueur technique apportée par HTML5. Les anciennes versions d’HTML laissaient place à l’interprétation : deux navigateurs pouvaient intégrer différemment les mêmes spécifications tout en prétendant respecter les normes. HTML5 fixe des règles précises qui garantissent une vraie compatibilité.

Mais le déploiement se heurte à des obstacles. La vidéo cristallise les tensions : aucun standard unique pour la compression, le streaming ou la gestion des droits numériques. En 2010, Apple refuse Flash sur l’iPhone et l’iPad, lui préférant sa propre version d’HTML5. Microsoft et Google développent leurs approches, obligeant les développeurs à jongler avec plusieurs versions de leur code.

Hui Zhang, professeur à Carnegie Mellon et cofondateur de Conviva Inc., connaît bien le problème. Pour lui, la vidéo reste l’aspect le plus épineux du contenu en ligne. Faire converger codecs, protocoles de streaming et gestion des droits demande du temps et des compromis entre industriels.

Le W3C prévoit en 2014 de finaliser la spécification HTML5. Philippe Le Hégaret, responsable du domaine interaction, tempère pourtant les attentes : le développement continue. L’organisation reçoit régulièrement des demandes d’ajout de fonctionnalités, comme la conversion voix-texte directement dans le navigateur.

Le WHATWG prend en 2011 un virage radical en abandonnant la numérotation des versions. HTML est un « standard vivant » en développement permanent, une vision qui colle à la réalité d’un Web en évolution constante. Ian Hickson le dit sans détour : le développement d’HTML se poursuivra tant que la technologie sera pertinente.

Cette technologie montre comment la standardisation peut stimuler l’innovation sans sacrifier la compatibilité. Elle illustre aussi l’importance de la collaboration entre acteurs de l’industrie pour faire avancer le Web.

Haut de page

Memcached

En 2003, Brad Fitzpatrick se retrouve face à un casse-tête de taille. LiveJournal, la plateforme de blogs qu’il a créée, explose littéralement : plus de 2,5 millions de comptes et une infrastructure qui commence à montrer ses limites. Quelque 70 machines tournent jour et nuit, mais les bases de données craquent sous la pression des requêtes. Le site affiche une particularité qui complique tout : chaque contenu possède différents niveaux de sécurité et s’insère dans de multiples vues. Impossible de générer des pages statiques quand les éléments qui les composent vivent chacun à leur rythme.

Fitzpatrick observe alors une réalité technique qui va orienter toute sa démarche. Les processeurs gagnent en vitesse, année après année, tandis que les disques durs traînent la patte. Pourquoi ne pas exploiter cette puissance de calcul plutôt que de s’épuiser en accès disques interminables ? L’idée germe d’utiliser la RAM qui sommeille dans les serveurs web, cette mémoire vive qui ne demande qu’à servir.

Un premier prototype voit le jour en Perl. L’essai se révèle décevant : trop lent, trop gourmand en mémoire. Fitzpatrick reprend tout en C et bâtit un démon mono-processus, mono-thread, qui s’appuie sur des entrées-sorties asynchrones. Pour garantir que son système fonctionne partout, il intègre libevent, une bibliothèque qui choisit automatiquement la meilleure stratégie de gestion des descripteurs de fichiers selon l’environnement d’exécution.

Le principe de Memcached tient en quelques mots : transformer la mémoire disponible des serveurs en un vaste réservoir partagé. Une table de hachage distribuée où les données circulent entre les machines grâce à un système de hachage cohérent. Rien de superflu dans l’architecture : le serveur ne bavarde pas avec ses congénères, ne conserve rien sur disque, propose trois opérations basiques – set, get, delete – et c’est tout. Cette austérité voulue procure des performances redoutables, avec des algorithmes en O(1) qui répondent du tac au tac. L’allocateur de mémoire par tranches évite la fragmentation qui pourrissait la vie des premières versions utilisant malloc.

Facebook adopte Memcached en 2007 et développe mcrouter, une variante enrichie de fonctions de sharding. Twitter suit avec twemcache, taillé pour ses besoins propres. Ces géants du web valident l’approche de Fitzpatrick et font de Memcached un standard de fait.

Les chiffres donnent le vertige. Chez Facebook, le système traite des milliards de requêtes par seconde et stocke des milliers de milliards d’objets. Le taux de réussite du cache atteint régulièrement 92% : seule une poignée de requêtes doit vraiment interroger la base de données. La charge s’allège d’autant. Le système introduit les « leases » pour gérer les conflits d’écriture et éviter que des hordes de clients tentent tous en même temps de régénérer une entrée expirée.

L’architecture distribuée autorise une souplesse bienvenue. On ajoute ou retire des serveurs du pool à la volée, le système s’ajuste sans broncher. Cette capacité de montée en charge horizontale devient vite une pratique courante dans la conception des infrastructures web modernes.

La communauté s’empare du projet. Des bibliothèques clientes fleurissent pour PHP, Python, Ruby, Java, C#, et ajoutent sérialisation d’objets et compression transparente, rendant l’outil plus maniable dans des contextes variés. Le code source continue d’évoluer grâce aux contributions d’une communauté active qui ne faiblit pas.

En 2024, Memcached tient toujours son rang dans les infrastructures web. Le projet conserve sa philosophie initiale : rester simple, rapide, fiable. Cette approche minimaliste tranche avec des alternatives plus baroques comme Redis, mais répond parfaitement aux besoins de mise en cache pure. Memcached démontre qu’une solution élégante et dépouillée résout parfois mieux les problèmes complexes qu’une machinerie sophistiquée.

Haut de page

OpenStack

À la fin des années 2000, les ressources matérielles et logicielles basculaient progressivement vers le cloud computing, promettant sécurité accrue et gestion centralisée. En 2009, la NASA cherchait une plateforme pour ses services Web internes. Le marché proposait uniquement des solutions propriétaires, verrouillées par quelques géants du secteur.

Les développeurs de l’agence spatiale américaine pensaient qu’une alternative libre servirait mieux une communauté large : chercheurs universitaires, institutions gouvernementales, entreprises diverses. Rien de tel n’existait. Ils ont donc décidé de créer cette solution eux-mêmes. L’initiative a attiré Rackspace, dont les ingénieurs travaillaient sur un projet similaire pour soutenir leur activité de vente de matériel et de services.

Début 2010, les représentants de Rackspace ont contacté la NASA. Les deux équipes se sont rencontrées dans un restaurant thaïlandais, et cette collaboration modeste a donné naissance à OpenStack. Le lancement officiel a eu lieu en juillet 2010, avec l’ambition d’aider les organisations à déployer des services cloud sur du matériel standard. Quatre mois plus tard, la première version, baptisée Austin, voyait le jour. Elle apportait calcul en cloud et stockage d’objets pour l’Infrastructure as a Service.

Les projets initiaux permettaient de contrôler des pools de ressources : calcul, stockage, réseau, le tout via un tableau de bord centralisé dans les centres de données. Les administrateurs disposaient d’un contrôle fin, tandis que les utilisateurs obtenaient leurs ressources instantanément. La communauté s’est alors engagée sur un rythme de nouvelles versions tous les six mois.

La Fondation OpenStack a vu le jour en 2012. Cette organisation indépendante à but non lucratif avait pour mission de promouvoir le développement et l’adoption du logiciel. La structure garantissait une gestion neutre de la propriété intellectuelle et le partage des ressources, créant des conditions équitables pour tous les participants.

Le modèle de gouvernance reposait sur trois piliers : un conseil d’administration fixait vision et gouvernance, un comité technique gérait versions et besoins inter-projets, un comité d’utilisateurs remontait les retours terrain et défendait leurs intérêts. La communauté fonctionnait selon quatre principes : code source ouvert sous licence Apache 2.0, communauté ouverte produisant un écosystème actif, développement transparent avec revues de code publiques, conception ouverte avec des sommets semestriels accessibles à tous.

Les contributeurs venaient d’horizons variés. Ingénieurs logiciels participant au code, rédacteurs fournissant documentation et traductions, développeurs d’applications créant des solutions sur l’infrastructure, opérateurs et utilisateurs déployant et gérant leurs clouds. Des groupes de travail rassemblaient les exigences de segments particuliers comme les télécommunications ou le monde de l’entreprise. L’écosystème commercial regroupait fournisseurs cloud et prestataires ajoutant leur valeur au logiciel de base.

L’adoption s’est accélérée dans différents secteurs. BMW, Disney et Walmart ont prouvé la viabilité de la solution en production. PayPal l’a adoptée pour l’agilité et la disponibilité qu’exigeaient ses produits phares. Time Warner Cable a misé sur cette flexibilité pour gérer d’importants volumes de données dans ses centres.

La technologie s’est étendue bien au-delà des usages prévus au départ. Le CERN l’a employée pour analyser les données de son Grand collisionneur de hadrons, gérant plus de 115 000 cœurs de calcul. Adobe Digital Marketing s’en est servi pour transformer son environnement de virtualisation en informatique en libre-service. L’université australienne NeCTAR l’a adoptée pour sa recherche collaborative nationale, supportant plus de 6 000 chercheurs.

En 2024, Rackspace a réaffirmé son engagement avec OpenStack Enterprise, solution cloud entièrement gérée pour charges de travail critiques. La société avait contribué plus de 5,6 millions de lignes de code et figurait parmi les plus grands fournisseurs cloud OpenStack mondiaux. Son expertise comprenait plus d’un milliard d’heures-serveur d’expérience en production.

L’impact sur l’industrie informatique a été considérable. La plateforme a permis aux entreprises de toutes tailles de déployer leurs propres infrastructures cloud, échappant ainsi à la domination des services propriétaires. Sa nature libre a favorisé l’innovation collaborative et réduit les coûts d’infrastructure. Les API ouvertes et le support de pratiquement tous les grands fournisseurs informatiques donnaient aux utilisateurs la liberté de déplacer leurs charges de travail entre clouds privés et publics selon leurs besoins.

Les bénéfices incluaient une accélération de la mise sur le marché grâce au portail libre-service, une plateforme basée sur des API pour développer des applications natives du cloud, et des temps de provisionnement drastiquement réduits. L’interopérabilité et la capacité de cloud hybride permettaient aux entreprises de choisir le meilleur environnement pour leurs applications sans dépendre d’un fournisseur unique.

L’évolution s’est poursuivie avec l’intégration de nouvelles technologies comme les conteneurs, les machines virtuelles et les serveurs bare metal. La communauté mondiale compte plus de 56 000 membres individuels dans plus de 180 pays et plus de 600 entreprises. Cette croissance témoigne de la pertinence continue de la plateforme dans un paysage technologique en constante mutation, où la demande de solutions cloud flexibles et ouvertes ne cesse de croître.

Haut de page

Bitcoin

En octobre 2008, alors que la crise financière secoue le monde entier et que la confiance envers les banques s’effondre, un mystérieux document circule sur internet. Son auteur, Satoshi Nakamoto, dont on ne saura jamais s’il s’agit d’une personne seule ou d’un groupe, propose ni plus ni moins qu’une révolution : créer une monnaie numérique qui échappe au contrôle des institutions financières. Le titre du document, « Bitcoin : A Peer-to-Peer Electronic Cash System », annonce clairement l’ambition. Il s’agit de bâtir un système de paiement où les transactions s’effectuent directement entre utilisateurs, sans intermédiaire.

Trois mois plus tard, le 3 janvier 2009, Nakamoto mine le premier bloc de cette chaîne qu’on appellera blockchain. Ce bloc genèse contient un message qui en dit long sur les motivations du projet : « The Times 03/Jan/2009 Chancellor on brink of second bailout for banks ». Cette référence au quotidien britannique n’est pas anodine. Elle rappelle que les banques s’apprêtent à recevoir un énième plan de sauvetage, financé par l’argent public. Le Bitcoin naît donc d’une contestation, d’un refus de ce système bancaire jugé défaillant.

Les débuts restent modestes. Le premier bloc suivant n’apparaît que cinq jours après, le 8 janvier. Ce délai inhabituel intrigue encore aujourd’hui. Certains y voient une période de tests, d’autres une référence biblique aux six jours de la création. Quoi qu’il en soit, le réseau démarre lentement. À l’époque, n’importe qui peut miner des bitcoins avec un ordinateur domestique. La difficulté est fixée au minimum, à 1, un niveau dérisoire comparé aux standards actuels qui nécessitent des installations industrielles.

Actif jusqu’en décembre 2010, Nakamoto disparaît sans laisser de traces. Son départ volontaire laisse la communauté des développeurs poursuivre seule. Cette absence alimente les spéculations sur son identité, mais garantit aussi que personne ne contrôle le projet. Le Bitcoin est véritablement un bien commun, sans chef ni propriétaire.

Des plateformes d’échange voient le jour en 2011, permettant d’acheter et de vendre des bitcoins contre des monnaies classiques. Mt. Gox s’impose et gère bientôt 70% des transactions mondiales. Mais en 2014, le piratage de cette plateforme japonaise fait perdre 850 000 bitcoins. Le choc ébranle l’écosystème et rappelle brutalement les risques liés à ces nouveaux actifs.

Le protocole Bitcoin repose sur des mécanismes ingénieux. La preuve de travail oblige les mineurs à résoudre des calculs complexes pour valider les transactions. En contrepartie, ils reçoivent une récompense en bitcoins. Cette récompense, initialement de 50 unités par bloc, diminue de moitié tous les quatre ans environ. Ce processus, baptisé « halving », limite l’émission totale à 21 millions de bitcoins. Cette rareté programmée rappelle celle de l’or et participe à la valorisation de la cryptomonnaie.

Progressivement, des entreprises acceptent le Bitcoin comme moyen de paiement. En 2012, quelques pionniers se lancent. Des acteurs majeurs comme Microsoft, Dell ou PayPal rejoignent le mouvement. Cette adoption confère une légitimité nouvelle à ce qui n’était au départ qu’une expérimentation cryptographique.

Le cours du Bitcoin traverse des cycles spectaculaires. En 2013, il grimpe de moins de 20 dollars à plus de 1 000 dollars, avant de retomber. En 2017, nouvelle envolée jusqu’à près de 20 000 dollars, suivie d’un effondrement l’année suivante. Ces variations extrêmes trahissent la dimension spéculative de l’actif. Personne ne s’accorde vraiment sur sa valeur réelle, si tant est qu’elle existe.

Le succès du Bitcoin inspire d’autres projets. Des centaines de cryptomonnaies alternatives, les « altcoins », émergent avec des propositions techniques variées. La blockchain trouve des applications insoupçonnées : contrats intelligents, finance décentralisée, traçabilité de produits. Cette technologie, conçue pour une monnaie numérique, s’étend bien au-delà de son usage initial.

Certains États réagissent en interdisant purement et simplement le Bitcoin, d’autres tentant de l’encadrer. Les préoccupations portent sur le blanchiment d’argent, la protection des investisseurs, l’évasion fiscale. L’impact environnemental du minage, gourmand en électricité, soulève aussi des critiques croissantes. Le débat est toujours vif entre les défenseurs d’une liberté financière absolue et ceux qui réclament une régulation stricte.

Plus de quinze ans après sa création, le Bitcoin s’est imposé comme une classe d’actifs à part entière, reconnue par les investisseurs institutionnels. Comme quoi une idée radicale, portée par quelques lignes de code, peut bousculer les certitudes d’un système financier millénaire. La technologie continue d’évoluer : le Lightning Network tente de résoudre les problèmes de lenteur des transactions, tandis que de nouvelles améliorations sont régulièrement proposées.

Cette expérience inédite a ouvert un champ immense dans les domaines de la cryptographie et des systèmes distribués. Le Bitcoin est un objet de fascination, symbole d’une contestation qui refuse les intermédiaires, les autorités centrales, les contrôles. Finalement, qu’est-ce que la monnaie ? Qui doit la contrôler ? Comment organiser la confiance dans un monde numérique ? Ces interrogations continuent d’alimenter les réflexions sur l’avenir de nos sociétés connectées.

Haut de page

CouchDB

En 2005, Damien Katz quitte IBM avec une idée en tête. Ses années passées sur Lotus Notes lui ont appris ce qu’était une base de données documentaire, mais aussi ce qu’elle pourrait devenir. À cette époque, le monde informatique tourne presque exclusivement autour des bases relationnelles. Pourtant, quelque chose cloche. Les applications web modernes et les outils collaboratifs réclament autre chose, une souplesse que SQL ne sait pas vraiment offrir.

Il commence par écrire CouchDB en C++. Les premiers prototypes fonctionnent, mais la gestion de la concurrence le fait buter. Il cherche une solution, parcourt les forums techniques, et tombe sur le blog « Lambda the Ultimate » où quelqu’un parle d’Erlang. Ce langage, conçu à l’origine pour les télécoms chez Ericsson, possède exactement ce dont il a besoin. La tolérance aux pannes, la distribution native, le traitement concurrent : tout y est. Katz prend alors une décision radicale. Il jette son code C++ et recommence tout en Erlang.

Ce choix technique modèle CouchDB. Erlang apporte avec lui une philosophie : les systèmes doivent survivre aux défaillances, les processus peuvent tomber sans faire chuter l’ensemble, les données peuvent être distribuées naturellement. Ces propriétés, pensées pour des centraux téléphoniques devant fonctionner sans interruption, collent parfaitement aux besoins d’une base de données moderne. Le parallèle entre télécoms et stockage de données n’était pas évident au premier regard, mais il s’avère pertinent.

CouchDB rompt avec plusieurs conventions établies. Pas de schéma rigide : les documents JSON peuvent évoluer librement, se transformer au gré des besoins sans nécessiter de migration de base. Cette liberté répond aux réalités du développement web où les structures changent constamment. L’interface parle HTTP, utilise GET pour lire, PUT pour écrire, DELETE pour supprimer. Rien de plus, rien de moins. Un développeur web se retrouve en terrain connu.

JavaScript devient le langage des requêtes. Là où d’autres bases imposent leur propre dialecte, CouchDB mise sur un langage que tout développeur web connaît. Les vues, ces index personnalisés qui permettent d’interroger les données, s’écrivent en JavaScript. Map-reduce aussi.

La réplication bidirectionnelle figure parmi les atouts les plus singuliers de CouchDB. Deux instances peuvent se synchroniser, échanger leurs modifications après avoir fonctionné séparément pendant des jours. Par exemple, un smartphone perd sa connexion, continue de travailler en local, puis synchronise tout une fois reconnecté. Peu de temps après la sortie de l’iPhone par Apple, cette capacité anticipe un monde où les appareils mobiles et les connexions intermittentes seront la norme plutôt que l’exception.

Pour gérer les écritures concurrentes, CouchDB adopte une approche optimiste. Pas de verrous qui bloquent, pas d’attentes forcées. Chaque document possède un numéro de révision, un peu comme Git avec ses commits. Quand deux modifications entrent en conflit, CouchDB garde les deux versions et laisse l’application décider. Cette gestion des conflits, inspirée des systèmes de contrôle de version, donne une souplesse inhabituelle pour une base de données.

L’histoire bifurque en 2011. CouchDB fusionne avec Membase, une technologie de cache distribué aux performances remarquables. De cette union naît Couchbase, qui combine la richesse documentaire de CouchDB avec la vitesse brute de Membase. La créature hybride hérite des deux mondes : persistance et flexibilité d’un côté, vélocité de l’autre.

Techniquement, CouchDB repose sur quelques briques bien pensées. Le moteur de stockage écrit sur disque tout en maintenant des index pour l’accès rapide. Le système de vues transforme les documents en index interrogeables. Le protocole de réplication assure la cohérence entre instances distantes. Ces composants interagissent en s’appuyant sur les forces d’Erlang, qui orchestre le tout avec une certaine élégance.

CouchDB participe à l’émergence du mouvement NoSQL, et prouve qu’on peut penser autrement le stockage des données. Son influence se lit dans l’architecture de nombreuses bases modernes qui reprennent ses idées : documents sans schéma, API web-friendly, réplication intelligente. PouchDB, son dérivé en JavaScript pour navigateurs, étend la synchronisation jusqu’au client web.

Les cas d’usage se multiplient là où la flexibilité compte. Applications mobiles qui doivent fonctionner hors ligne, systèmes collaboratifs où des utilisateurs modifient les mêmes données, outils qui doivent se répliquer entre sites distants. CouchDB excelle dans ces situations où la connexion n’est pas garantie, où les structures évoluent vite, où la distribution des données est une nécessité.

Haut de page

Node.js

En 2009, Ryan Dahl présente Node.js lors d’une conférence européenne sur le JavaScript. Cette technologie allait changer la donne en permettant d’utiliser JavaScript en dehors des navigateurs web. Jusqu’alors, ce langage restait cantonné au front-end, depuis sa création par Brendan Eich en 1995 pour Netscape. À l’origine, JavaScript servait surtout à animer les pages web et manipuler le DOM. Netscape avait bien tenté une version serveur avec Netscape Enterprise Server, mais l’essai s’était soldé par un échec.

Le nom de JavaScript témoigne d’une stratégie marketing : surfer sur la vague de popularité de Java. Pourtant, les deux langages n’ont rien à voir. JavaScript doit bien plus à Scheme et Self qu’à Java, dont il reprend juste quelques éléments de syntaxe. Pendant des années, les programmeurs sérieux regardaient JavaScript de haut, le jugeant trop lent et inadapté aux vraies applications. Cette réputation a volé en éclats avec l’arrivée de moteurs plus puissants, notamment le V8 de Google Chrome. Grâce à la compilation à la volée, l’insertion de code et l’optimisation dynamique, JavaScript a pu rivaliser avec C++ sur certains benchmarks et dépasser Python dans la plupart des cas.

Node.js s’appuie sur le moteur V8 pour bâtir une plateforme serveur robuste. L’architecture tranche avec les approches traditionnelles. Là où Apache crée un nouveau thread ou processus à chaque connexion, Node.js mise sur une boucle événementielle mono-thread. Cette stratégie évite les coûts de création et gestion des threads, qui pèsent lourd quand le serveur croule sous les requêtes.

La gestion des entrées-sorties fait la différence. Au lieu de bloquer l’exécution en attendant qu’une opération se termine, Node.js utilise des callbacks qui traitent les résultats de façon asynchrone. Le serveur peut ainsi jongler avec plusieurs requêtes pendant qu’une opération tourne en arrière-plan. Les ressources sont mieux exploitées, les temps morts disparaissent.

La communauté s’est vite emparée du projet. Dès 2010, Isaac Schlueter lance NPM (Node Package Manager), véritable la pierre angulaire de l’écosystème. Les développeurs peuvent partager et réutiliser du code sans friction, ce qui accélère l’adoption. L’année suivante, une version Windows native voit le jour et élargit considérablement l’audience.

Joyent, société de logiciels et de services basée à San Francisco, pilote le développement pendant quelques années avant que le projet ne rejoigne la Fondation Node.js en 2015. Pendant cette transition vers une gouvernance plus ouverte, sous l’égide d’un comité technique de pilotage, Node.js devient un projet collaboratif de la Linux Foundation. En 2019, la fusion avec la Fondation JS donne naissance à la Fondation OpenJS, qui coordonne mieux l’écosystème JavaScript.

Le registre NPM héberge aujourd’hui plus de deux millions de paquets, ce qui en fait le plus gros référentiel logiciel au monde. On y trouve des frameworks comme Express, des outils de développement comme browserify et gulp, et plus de 8 000 clients de bases de données, de redis à mongoose.

La boucle événementielle mono-thread pourrait sembler un frein sur les processeurs multicœurs modernes. Node.js contourne l’obstacle avec le module cluster, qui crée des processus workers partageant les ports du serveur parent. Un algorithme round-robin sensible à la charge distribue les requêtes entre les cœurs disponibles.

Le succès de Node.js a popularisé la programmation asynchrone basée sur les événements. Cette approche convient bien aux applications gourmandes en concurrence, comme la messagerie instantanée ou les services temps réel. La plateforme a aussi favorisé le JavaScript isomorphe, où le même code tourne côté client et serveur.

Node.js continue d’évoluer. Le support des modules ECMAScript, l’amélioration des performances et le renforcement de la sécurité figurent parmi les priorités actuelles. La plateforme reste pertinente pour les microservices, les applications serverless, les outils de développement et les applications de bureau via Electron. En proposant une autre façon de faire du serveur, Ryan Dahl a redéfini la construction d’applications web performantes et scalables.

Haut de page

Raspberry Pi

En 2006, Eben Upton et ses collègues du laboratoire d’informatique de Cambridge se heurtent à un problème inattendu : les candidats qui postulent dans leur cursus maîtrisent de moins en moins bien l’informatique. Pire, leur nombre diminue d’année en année. Le diagnostic ne tarde pas à s’imposer. Les ordinateurs des années 1980, avec leurs entrailles visibles et leur programmation directe, ont disparu au profit de machines hermétiques, soigneusement dissimulées derrière des coques en plastique et des interfaces léchées. L’ordinateur n’invite plus à bricoler, il se contente d’être utilisé.

Upton rêve d’une machine bon marché qui rendrait aux jeunes ce plaisir de l’expérimentation, celui qu’il a connu à leurs âges. Son prototype initial, baptisé ABC Micro en hommage au BBC Micro, se limite à une carte bricolée autour d’un microcontrôleur Atmel et de quelques puces de mémoire. Les premiers tests auprès d’enfants révèlent toutefois que cette approche minimaliste ne déclenche pas l’étincelle attendue.

Toujours en 2006, Upton rejoint Broadcom. Cette opportunité lui ouvre l’accès à des composants autrement plus puissants, notamment le BCM2835 qui intègre un processeur ARM11. Cette puce concentre sur quelques centimètres carrés tout ce qu’il faut pour faire fonctionner un vrai ordinateur : sortie HDMI, accélération 3D, décodage vidéo, contrôleur USB. L’ajout d’un processeur ARM généraliste change la donne, notamment en y faisant tourner Linux.

La fondation Raspberry Pi voit le jour en 2009. Deux ans plus tard, la carte définitive prend forme. Upton et son équipe imaginent une production confidentielle, quelques centaines d’exemplaires par an tout au plus. Mais l’engouement dépasse leurs prévisions les plus optimistes. La fondation réoriente sa stratégie : elle conserve la conception, la marque et les prototypes, mais délègue la fabrication à RS Components et Premier Farnell.

Début 2012, les 10 000 premiers Raspberry Pi partent en quelques heures. Le nom circule dans les cercles techniques et les communautés maker. La fondation saisit cette dynamique pour relancer l’industrie électronique britannique : après un démarrage en Chine, la production migre progressivement au Pays de Galles jusqu’à atteindre une localisation complète.

Les utilisateurs détournent aussitôt la carte de sa vocation pédagogique initiale. Les 32 broches d’entrée-sortie, qu’Upton avait ajoutées presque par acquit de conscience, sont l’élément le plus prisé. On voit apparaître des drones pilotés par Raspberry Pi, des ballons stratosphériques, des installations domotiques. Un bricoleur transforme son four à micro-ondes en y greffant un écran tactile, des commandes vocales, une interface web et un lecteur de codes-barres connecté à une base de recettes.

Ces réalisations sophistiquées, qui demandent des compétences pointues, renforcent paradoxalement la dimension éducative du projet. Elles montrent aux jeunes ce qu’on peut accomplir quand on sait programmer. Les ateliers en milieu scolaire confirment cette intuition : il suffit parfois de modifier la couleur d’un serpent dans un jeu pour qu’un élève refuse d’arrêter. Cette première sensation de contrôle sur la machine produit un effet comparable à ce qu’Upton avait vécu dans sa jeunesse.

Le Raspberry Pi combine des caractéristiques techniques et économiques qui expliquent son succès. Son processeur ARM1176JZF-S à 700 MHz, couplé à un GPU VideoCore IV, délivre des performances multimédia étonnantes pour un appareil de cette taille. La mémoire SDRAM, passée de 256 Mo sur le modèle A à 512 Mo sur le modèle B, suffit à faire tourner confortablement Linux. L’absence de disque dur, remplacé par une simple carte SD, maintient le prix bas et simplifie le changement de système d’exploitation.

Les mises à jour matérielles se succèdent sans rupture. Le Raspberry Pi 4 embarque un Broadcom BCM2711 quadricœur ARM Cortex-A72 64 bits à 1,5 GHz, jusqu’à 8 Go de mémoire LPDDR4, le Bluetooth 5.0, le Wi-Fi bibande et des ports USB 3.0. Ces évolutions préservent la compatibilité avec les versions antérieures tout en élargissant le champ des possibles.

Le Raspberry Pi a prouvé qu’il existait un marché pour les ordinateurs monocartes accessibles. Avec 19 millions d’unités vendues, il se classe au troisième rang des ordinateurs généralistes. Il a ranimé l’intérêt pour l’apprentissage pratique de l’informatique et inspiré toute une génération d’ingénieurs et de créateurs. Son histoire montre comment une initiative éducative locale peut, en touchant juste, déclencher un mouvement international qui redéfinit notre rapport à la technologie.

Si ce contenu vous a plu, vous pouvez soutenir ce projet en faisant un don ou en commandant l'édition papier sur Lulu ou Amazon. Tout le contenu reste librement accessible sous licence CC BY-SA 4.0.