Chapitre 10
2010

La décennie 2010-2020 a marqué une cassure dans notre relation au numérique. Plus qu’un simple tournant technologique, ces années ont vu naître une société où le digital s’est mêlé au réel jusqu’à en brouiller les frontières. Cette mondialisation a pris un visage concret dans nos vies quotidiennes. Les populations, majoritairement urbaines et mobiles, réclamaient un accès instantané à l’information et aux services en ligne. Cette soif d’immédiateté a façonné les innovations de toute une époque.

Les premiers temps de cette décennie ont révélé la puissance insoupçonnée des réseaux sociaux, avec Facebook et Twitter en fer de lance de véritables révolutions. Le printemps arabe de 2011 a montré comment ces plateformes pouvaient contourner les médias traditionnels contrôlés par les régimes autoritaires. Un simple smartphone suffisait désormais à diffuser des images de manifestations, à coordonner des rassemblements, à faire entendre une voix jusque-là étouffée. Ce bond en avant médiatique a changé notre perception du rôle des technologies dans les mouvements sociaux.

La généralisation des smartphones, couplée au déploiement des réseaux 4G, a transformé chaque citoyen en créateur de contenu. Nous avons commencé à produire et consommer des données en quantités astronomiques. Cette avalanche d’informations a engendré ce phénomène qu’on a nommé « Big Data ». Nos infrastructures traditionnelles craquaient sous le poids de ces flux massifs. Il a fallu imaginer de nouvelles architectures, de nouvelles méthodes d’analyse pour donner du sens à ce déluge informationnel.

Au cœur de cette transformation, quelques entreprises américaines ont bâti des empires d’une envergure inédite. Google, Apple, Facebook, Amazon et Microsoft ont renforcé leur mainmise sur l’écosystème numérique mondial. Leur stratégie repose sur le rachat méthodique de toute startup innovante susceptible de menacer leur domination. Cette concentration du pouvoir numérique a fait naître des inquiétudes légitimes concernant la vie privée des utilisateurs et le contrôle de l’information. Qui détient nos données détient un pouvoir considérable sur nos vies.

Face à cette hégémonie occidentale, la Chine a développé son propre univers numérique. Des acteurs comme Alibaba, Tencent et Baidu ont créé un écosystème parallèle, sous la supervision étroite du gouvernement chinois et du Parti Communiste Chinois. Pékin a mis sur pied une stratégie nationale ambitieuse visant à dominer les technologies d’avenir, notamment l’intelligence artificielle et les réseaux 5G. Cette montée en puissance a transformé l’innovation technologique en véritable enjeu géopolitique. La rivalité sino-américaine s’est déplacée des océans vers les laboratoires et les centres de données.

L’année 2013 a marqué un séisme dans notre rapport à la sécurité numérique. Edward Snowden a dévoilé l’ampleur stupéfiante de la surveillance exercée par les services de renseignement américains. Le monde a découvert que nos communications étaient systématiquement interceptées et analysées. Ce choc a provoqué une prise de conscience globale sur la fragilité de notre vie privée à l’ère numérique. L’Europe a réagi en élaborant le Règlement Général sur la Protection des Données, devenu depuis une référence mondiale. La cybersécurité, jusque-là préoccupation technique marginale, s’est imposée comme priorité stratégique pour les États et les organisations.

Les réseaux sociaux ont progressivement colonisé notre espace informationnel. Leur influence sur la formation de l’opinion publique s’est révélée lors de l’élection présidentielle américaine de 2016 avec le scandale Cambridge Analytica qui a révélé comment Facebook avait permis l’exploitation des données de millions d’utilisateurs à des fins politiques. Ces plateformes ont montré leur vulnérabilité face aux tentatives de manipulation. Plus inquiétant encore, leurs algorithmes de recommandation nous enferment dans des « bulles de filtres », des univers informationnels confortables mais déformés. Cette fragmentation du débat public questionne le fonctionnement de nos démocraties à l’ère numérique.

Le cloud computing a transformé les infrastructures informatiques des entreprises et des particuliers. Pourquoi investir dans des serveurs coûteux et sous-exploités quand on peut louer de la puissance de calcul à la demande ? Cette flexibilité a accéléré la transformation numérique des organisations traditionnelles. Mais cette migration vers le cloud a aussi créé de nouvelles dépendances. La question de la souveraineté numérique s’est à nouveau posée avec acuité, surtout en Europe où la domination des fournisseurs américains suscite des inquiétudes légitimes.

Notre quotidien s’est peuplé d’objets connectés. Montres intelligentes, enceintes à commande vocale, thermostats automatiques, l’Internet des Objets a tissé un maillage invisible mais omniprésent autour de nous. Ces appareils captent en permanence des informations sur nos habitudes, nos déplacements, nos préférences. Ils ont introduit de nouvelles façons d’interagir avec les machines. La voix et le geste remplacent progressivement le clavier et la souris. Cette collecte constante de données personnelles alimente des systèmes d’intelligence artificielle toujours plus sophistiqués.

Bitcoin, né dans l’ombre de la crise financière de 2008, a véritablement émergé durant cette décennie. Cette monnaie numérique, indépendante des banques centrales, a remis en cause nos systèmes financiers. Les technologies financières ont transformé des secteurs entiers : paiements mobiles, prêts entre particuliers, gestion automatisée des investissements. Les institutions traditionnelles ont dû s’adapter face à ces nouveaux concurrents agiles. Les régulateurs, souvent pris de court par l’innovation galopante, ont oscillé entre méfiance et fascination pour ces technologies qui promettaient de démocratiser l’accès aux services financiers.

Les progrès fulgurants de l’intelligence artificielle et de la robotique ont accéléré l’automatisation de nombreuses tâches. Des métiers qu’on croyait réservés aux humains se sont retrouvés menacés par les machines apprenantes. Cette évolution a soulevé des questions sur l’avenir du travail, la préparation des jeunes générations à un monde où les compétences seront obsolètes en peu de temps, et une transition juste pour ceux dont les emplois disparaissent. Ces interrogations ont pris une dimension politique croissante, alors que les inégalités numériques se creusaient entre les différentes catégories de population.

L’économie des plateformes a bouleversé des secteurs entiers. Uber, Airbnb, Deliveroo, ces noms sont devenus emblématiques d’un nouveau modèle économique fondé sur la mise en relation directe entre offre et demande. Cette transformation a créé des formes d’emploi hybrides, ni salariat ni entrepreneuriat classique. Si ces plateformes ont ouvert de nouvelles opportunités et fluidifié les échanges, elles ont aussi généré des tensions sociales considérables. Précarisation du travail, contournement des réglementations, évasion fiscale, les critiques se sont multipliées, forçant les législateurs à repenser des cadres juridiques dépassés par l’innovation.

La conscience de l’impact environnemental du numérique s’est progressivement imposée. L’empreinte carbone des centres de données, la consommation énergétique du minage de Bitcoin, l’obsolescence programmée des appareils électroniques sont des réalités qui ont commencé à influencer les choix technologiques des organisations soucieuses de leur responsabilité écologique. Des initiatives pour un numérique plus sobre ont émergé, cherchant à concilier innovation et durabilité. Cette réflexion sur l’éthique environnementale des technologies numériques deviendra centrale dans les années suivantes.

La fin de la décennie a connu une accélération brutale et inattendue. La pandémie mondiale de 2020 a précipité la transformation numérique de secteurs entiers. Du jour au lendemain, le télétravail s’est généralisé, l’enseignement s’est transporté en ligne, le commerce électronique est devenu vital. Cette crise sanitaire a servi de test grandeur nature pour nos infrastructures numériques, révélant à la fois leur résilience et leurs limites. Elle a aussi mis en lumière l’urgence de réduire la fracture numérique. L’accès à une connexion de qualité et aux compétences digitales est apparu comme une condition essentielle de participation à la vie sociale et économique.

Au terme de ces dix années, le numérique n’apparaît plus comme un secteur distinct mais comme le tissu de notre organisation sociale. Les innovations de cette période ont répondu à notre soif de connexion et d’immédiateté. Mais elles ont aussi engendré de nouveaux problèmes éthiques, sociaux et environnementaux qui continueront de façonner l’évolution de l’informatique. Les années 2010 resteront comme la période où notre monde a basculé définitivement dans l’ère numérique, avec ses promesses éblouissantes et ses zones d’ombre inquiétantes. L’informatique façonne désormais notre perception du monde et nos interactions sociales.

Haut de page

Elasticsearch

L’histoire d’Elasticsearch commence par une histoire d’amour. En 2004, Shay Banon, jeune développeur, déménage à Londres pour accompagner son épouse qui rêve de devenir chef cuisinière. Sans emploi, il décide de mettre ce temps à profit en explorant les technologies émergentes. Son projet : créer une application où sa femme pourrait stocker et retrouver toutes les connaissances culinaires acquises durant sa formation.

Au cœur de cette application, Banon imagine une simple boîte de recherche. Il suffirait d’y saisir un concept, une réflexion ou un ingrédient pour explorer aussitôt les possibilités gastronomiques. Cette vision le conduit vers Apache Lucene, la bibliothèque de référence en matière de recherche pour Java. Son immersion dans Lucene donne naissance à Compass, un projet visant à simplifier l’utilisation de Lucene dans les applications Java conventionnelles. Conceptuellement, Compass se présente comme un « Hibernate pour Lucene », facilitant le mappage du modèle de domaine vers l’index de recherche.

Le projet captive Banon, qui finit par y consacrer plus de temps qu’à l’application culinaire initiale. Quelques mois après sa création, il ouvre le code source de Compass. Le succès est immédiat. Les développeurs apprécient la simplicité avec laquelle ils peuvent désormais indexer leurs modèles de domaine dans Lucene et effectuer des recherches. Cette liberté leur donne accès à des usages inattendus et novateurs.

En 2010, fort de cette expérience et des retours des utilisateurs, Banon lance Elasticsearch. Cette nouvelle création conserve la philosophie de simplicité de Compass tout en répondant aux besoins modernes de distribution et d’évolutivité. Il quitte son poste chez Gigaspaces pour se consacrer entièrement au développement d’Elasticsearch pendant près de deux ans.

La communauté open source s’approprie le projet. Les développeurs enrichissent les fonctionnalités, créent une console d’administration, développent des outils d’analyse graphique. Ces contributions collectives génèrent un élan considérable. En 2012, Elasticsearch attire l’attention des directeurs techniques de nombreuses entreprises qui vantent ses qualités. Avec 200 000 téléchargements mensuels, un chiffre sans précédent pour un logiciel d’entreprise, Elasticsearch s’impose comme une solution incontournable.

L’équipe fondatrice se constitue autour de Banon avec Steven Schuurman, Uri Boness et Simon Willnauer, tous experts reconnus dans le domaine de la recherche. Ensemble, ils créent une entreprise pour soutenir le développement du projet. La société attire les meilleurs talents de la communauté Lucene et devient le lieu de prédilection pour l’open source dans le domaine de la recherche.

L’architecture d’Elasticsearch repose sur une approche novatrice. Le système utilise JSON et une interface RESTful, ce qui le rend accessible depuis n’importe quel langage de programmation. Sa nature distribuée lui donne la capacité de traiter des volumes de données importants en répartissant automatiquement la charge sur plusieurs nœuds. La flexibilité du schéma autorise le stockage de documents complexes sans définition préalable de structure.

Au fil des années, l’écosystème s’enrichit. Logstash vient faciliter l’ingestion des données, tandis que Kibana offre des capacités de visualisation avancées. Ces outils forment la pile ELK (Elasticsearch, Logstash, Kibana), devenue une référence pour l’analyse de logs et la surveillance d’infrastructures. Dans les années 2020, des alternatives plus légères comme Fluentd ou FluentBit remplacent souvent Logstash pour l’ingestion des données.

Les cas d’utilisation d’Elasticsearch se multiplient : recherche sur les sites web, analyse des interactions utilisateurs, détection d’anomalies dans les systèmes de sécurité. Des organisations comme GitHub, Wikimedia, Foursquare et le CERN l’adoptent pour gérer leurs besoins en matière de recherche et d’analyse de données.

En 2018, la société réalise une introduction en bourse, confirmant la maturité du projet. L’année suivante marque un changement significatif. Elastic, l’entreprise derrière Elasticsearch, modifie sa licence. En janvier 2021, elle abandonne la licence Apache 2.0 pour une double licence propriétaire, incluant la Server Side Public License (SSPL). Cette décision provoque une réaction d’Amazon Web Services, qui crée un fork du projet nommé OpenSearch, maintenant la tradition open source sous licence Apache 2.0.

L’impact d’Elasticsearch sur l’industrie du logiciel dépasse son objectif initial de moteur de recherche. La technologie a redéfini la manière dont les organisations gèrent et explorent leurs données. Son architecture distribuée et son approche orientée API ont influencé la conception de nombreux systèmes modernes. La simplicité d’utilisation, associée à des fonctionnalités puissantes, donne aux développeurs la possibilité d’intégrer des capacités de recherche sophistiquées sans expertise approfondie en recherche d’information. L’adoption massive d’Elasticsearch illustre l’importance croissante de l’analyse de données en temps réel dans les systèmes d’information contemporains.

Un projet personnel évolue parfois en une infrastructure majeure, utilisée par des milliers d’organisations à travers le monde.

Haut de page

HEIF

Le format JPEG règne depuis 1992 sur le monde de l’image numérique. Les appareils mobiles, les ordinateurs, les serveurs, tous utilisent ce format qui s’est imposé comme une norme de fait. Mais cette hégémonie cache des faiblesses techniques qui se sont révélées au fil du temps : pas de support pour la haute profondeur de couleur, pas de gestion de la haute gamme dynamique, pas de transparence. Et puis il y a ces artefacts visuels caractéristiques, cette compression qui montre ses limites face aux besoins actuels.

C’est en 2013 que l’équipe technique de Nokia Technologies commence à réfléchir à une alternative. Ils définissent les exigences, identifient les cas d’utilisation. Le développement des spécifications prend un an et demi, jusqu’à l’été 2015. Mais le destin du projet bascule avec le rachat de Nokia par Microsoft. L’entreprise cède ses droits et ses informations à Apple, qui reprend le flambeau.

HEIF (High Efficiency Image File Format) rompt avec la conception traditionnelle des formats d’images. Là où JPEG stocke une seule image, HEIF peut contenir plusieurs images, des séquences entières, leurs métadonnées. La structure repose sur les technologies de codage vidéo HEVC (H.265), dont les techniques avancées de compression sont appliquées aux images fixes. C’est un changement de paradigme.

En 2017, Apple franchit le pas. L’iPhone 7, la sixième génération d’iPad, les Mac sous OS X High Sierra adoptent le format. L’entreprise introduit l’extension .heic pour les images encodées en HEVC, réservant .heif aux fichiers utilisant d’autres codecs. Des millions d’utilisateurs découvrent le format sans vraiment s’en apercevoir.

Les gains sont immédiats : une réduction de 50% de la taille des fichiers par rapport à JPEG, pour une qualité visuelle équivalente voire supérieure. Le format gère la capture en rafale, l’enregistrement simultané de vidéos et d’images fixes, les animations, les images focales et d’exposition dans un seul fichier. Les opérations d’édition sur des images dérivées prédéfinies sont rendues possibles.

L’architecture de HEIF hérite du format de base ISO/IEC 14496-12. Le système de « boîtes » (boxes) donne la possibilité d’imbriquer les données, créant une hiérarchie de relations. La première boîte, nommée « ftyp », contient les métadonnées générales d’encodage. Une boîte « meta » renferme le reste des informations. Le format intègre le tuilage d’image, qui autorise le décodage parallèle ou le chargement partiel des zones d’intérêt dans les images haute résolution.

Apple a adapté les spécifications à sa manière. L’entreprise utilise systématiquement des tuiles de 512×512 pixels, générant des entrées « infe » pour chaque tuile. Ces tuiles sont assemblées en une seule image via une image dérivée de type « grid ». Apple exploite des cartes de profondeur auxiliaires, accompagnées de métadonnées XMP.

L’adoption du format s’étend progressivement. Android l’intègre depuis la version 9 (Pie), Samsung le propose sur certains modèles comme le Galaxy S10. Windows 10 l’a introduit dans sa version 1809, mais il faut installer des extensions spécifiques depuis le Microsoft Store. La transition demande des ajustements techniques et pratiques.

Pour la photographie mobile, l’impact est considérable. Les utilisateurs conservent plus de photos sur leurs appareils sans sacrifier la qualité visuelle. L’édition non destructive est plus accessible, la gestion des métadonnées plus flexible. Les développeurs d’applications disposent de nouvelles possibilités.

Du côté de l’analyse numérique légale, généralement pour des enquêtes judiciaires, HEIF complique le travail. Avec la capacité de sa structure à dissimuler des données dans différentes boîtes, de manipuler les relations entre les images, les enquêteurs doivent développer de nouvelles méthodologies, tenir compte des multiples couches de données, des implémentations variables selon les fabricants.

La norme ISO/IEC 23008-12 définit aujourd’hui les spécifications techniques du format. Cette standardisation garantit l’interopérabilité entre les différentes implémentations. Les mises à jour successives ont introduit le support pour le codage prédictif des images, les rafales, l’annotation des régions. Le développement continue.

Le format HEIF s’adapte aux contraintes de performance des appareils modernes. Mais la transition depuis JPEG est progressive. Les questions de compatibilité freinent l’adoption, mais les avantages techniques sont indéniables. Le changement prend du temps, et le match ne semble pas gagné d’avance.

Haut de page

Rust

En 2006, Graydon Hoare travaillait chez Mozilla quand il lança un projet personnel dans la programmation système. Ce projet, baptisé Rust en référence aux champignons de la rouille et au mot anglais robust, resta discret jusqu’en 2010. Cette année-là, Mozilla comprit le potentiel du langage et décida de soutenir son développement.

La première version pré-alpha du compilateur sortit en janvier 2012. Dès le départ, Rust s’attaquait à une contradiction qui empoisonnait les développeurs depuis des décennies : comment obtenir un contrôle fin sur les ressources matérielles tout en garantissant la sécurité mémoire ? Les langages existants forçaient à choisir entre performance et sûreté. Rust refusait ce compromis.

Le système de types de Rust repose sur deux concepts originaux : le ownership (propriété) et le borrowing (emprunt). Le principe est simple : une seule entité peut posséder une ressource à un instant donné. Cette règle, vérifiée à la compilation, élimine d’un coup toute une catégorie de bogues. Les problèmes de concurrence, les fuites mémoire, les accès invalides disparaissent avant l’exécution du programme.

Microsoft a révélé un chiffre édifiant : 70% des failles de sécurité corrigées dans ses produits provenaient d’erreurs de gestion mémoire. Mozilla constatait la même chose avec Firefox. Ces statistiques expliquent pourquoi Rust a trouvé son public. Le langage obtient d’ailleurs le titre de « langage le plus apprécié » dans le sondage Stack Overflow chaque année depuis 2016.

L’écosystème s’est structuré autour de Cargo, le gestionnaire de paquets officiel. Cet outil simplifie radicalement la gestion des dépendances et la construction des projets. La communauté a développé des milliers de bibliothèques, appelées crates, qui couvrent à peu près tous les besoins imaginables. Cette richesse a facilité l’adoption du langage dans l’industrie.

Dropbox fut parmi les premiers à parier sur Rust pour ses infrastructures critiques. Facebook, Amazon et Cloudflare ont suivi. Microsoft explore son usage pour renforcer la sécurité de ses composants système. Mozilla a réécrit certaines parties de Firefox en Rust, démontrant qu’on pouvait intégrer le langage dans des projets monumentaux déjà en production.

La gestion de la concurrence constitue une autre force de Rust. Le compilateur détecte les data races avant la première exécution. Impossible de lancer un programme où plusieurs threads accèdent simultanément à une donnée partagée sans synchronisation appropriée. Cette vérification statique épargne des heures de débogage cauchemardesque.

Le langage évolue avec une discipline remarquable. Les concepteurs introduisent des fonctionnalités avancées sans jamais rompre la compatibilité avec le code existant. Le processus de développement s’appuie sur des groupes de travail spécialisés qui débattent longuement de chaque proposition. Cette gouvernance produit des décisions mûrement réfléchies.

Rust s’est imposé dans des domaines variés. On le trouve dans les systèmes d’exploitation, les navigateurs web, les outils de développement, les applications distribuées. L’Internet des objets adopte le langage pour ses garanties de sécurité et son efficacité sur matériel limité. Les systèmes embarqués critiques bénéficient d’un langage qui combine les performances du C avec des protections absentes des langages bas niveau traditionnels.

Le langage Rust prouve que concilier sécurité et performance se fait sans sacrifier la productivité. D’autres projets de langages s’inspirent de ses innovations. Les pratiques de développement sécurisé évoluent sous son impulsion. Des entreprises proposent formation, conseil et services spécialisés, signalant la maturité commerciale atteinte.

Le système de types sophistiqué de Rust représente une avancée conceptuelle. Il démontre qu’un compilateur peut vérifier des propriétés complexes sur le code et garantir leur respect à l’exécution. Cette approche ouvre des perspectives nouvelles dans la conception des langages. La sécurité n’est plus un objectif contradictoire avec la performance.

De nouvelles fonctionnalités apparaissent régulièrement, toujours dans le respect des principes fondateurs. L’adoption industrielle s’accélère. La communauté reste dynamique et le langage s’inscrit durablement dans le paysage informatique.

Pendant des décennies, les développeurs acceptaient comme inévitables les bugs mémoire et les failles de sécurité associées. Mais Rust a cassé cette fatalité. Il apporte des solutions concrètes à des problèmes anciens, tout en maintenant les performances des langages établis. Cette double victoire technique et communautaire montre qu’on peut repenser les outils de développement pour répondre aux exigences contemporaines de sécurité et de qualité.

Haut de page

ChromeOS

Google lance en 2009 le développement d’un système d’exploitation qui rompt avec les conventions établies : ChromeOS, pensé pour ne fonctionner qu’avec des applications web. Le contexte explique cette audace. Les netbooks, ces petits ordinateurs portables bon marché tournés vers Internet, séduisent de plus en plus d’utilisateurs. L’entreprise choisit une méthode inhabituelle pour comprendre leurs besoins : plutôt que de commander des études classiques, les ingénieurs distribuent 200 machines ChromeOS aux employés de Google. Matthew Papakipos, qui dirige techniquement le projet, installe trois appareils chez lui. Il observe que les sessions sont brèves : une recherche rapide, un court message envoyé, puis l’appareil est refermé.

Le 7 juillet 2009, Google annonce officiellement ChromeOS. En novembre, le code source est accessible sous le nom de Chromium OS. Cette dualité perdure : ChromeOS désigne le produit commercial distribué uniquement sur du matériel spécifique via des partenaires, tandis que Chromium OS reste le projet open source que tout développeur peut compiler et modifier. L’interface épurée s’inspire du navigateur Chrome, reflétant la vocation première du système : accéder au web, vite et simplement.

Le 19 novembre 2009, Sundar Pichai, vice-président de Google supervisant Chrome, présente une version préliminaire lors d’une conférence de presse. La démonstration montre un bureau qui ressemble au navigateur Chrome, enrichi d’onglets d’applications occupant moins de place et pouvant être épinglés pour y accéder plus facilement. Le temps de démarrage atteint alors sept secondes. Les équipes s’attèlent à le réduire encore. Chris Kenyon, vice-président des services OEM chez Canonical, qui édite Ubuntu, annonce une contribution technique sous contrat. Google veut s’appuyer sur les composants existants de la communauté open source plutôt que tout réinventer.

Une interface adaptée aux tablettes tactiles est présentée en janvier 2010. Le design intègre un clavier virtuel et des icônes plus grandes, placées au-dessus des onglets. En mars 2010, Google envisage deux versions : une édition grand public et une version entreprise.

Le prototype Cr-48 est dévoilé en décembre 2010. Cette machine de test, produite à 60 000 exemplaires, introduit une innovation curieuse : la touche « Verrouillage majuscule » disparaît au profit d’une touche de recherche dédiée. Les critiques s’élèvent contre les limitations en mode hors-ligne. Google réagit en démontrant une version d’applications fonctionnant sans connexion, comme Google Docs, et annonce un forfait 3G incluant 100 Mo de données gratuites mensuelles via Verizon.

L’architecture de ChromeOS se déploie sur trois niveaux : le micrologiciel, le navigateur avec son gestionnaire de fenêtres, et les services système. Le micrologiciel accélère le démarrage en évitant la détection de périphériques obsolètes. La sécurité constitue une préoccupation constante, avec une vérification de chaque étape du processus de démarrage et des capacités de restauration intégrées.

La gestion de l’impression illustre l’approche de Google. Le service Google Cloud Print autorise l’impression depuis n’importe quel appareil sur n’importe quelle imprimante, échappant à la complexité habituelle des pilotes d’impression. Le système intègre un lecteur multimédia capable de lire les fichiers MP3 et JPEG hors connexion.

Les premiers utilisateurs du Cr-48 livrent des retours contrastés. Kurt Bakke de Conceivably Tech souligne son adoption rapide comme appareil familial pour les recherches rapides et la consultation des réseaux sociaux. Mais les performances avec Flash déçoivent, et l’absence de fonctionnalités hors-ligne suscite des critiques.

L’intégration matérielle s’effectue via des partenariats avec Acer, Adobe, Asus, Intel, Samsung et Dell. En juillet 2010, Eric Schmidt, PDG de Google, écarte l’idée d’un netbook ChromeOS de marque Google. Il préfère s’appuyer sur l’expérience des constructeurs PC habitués à travailler avec Microsoft.

Le modèle économique de ChromeOS se distingue des systèmes traditionnels. Schmidt reconnaît que la compatibilité logicielle sera plus limitée que Windows, mais la gratuité de la licence autorise les constructeurs à proposer des appareils compétitifs, entre 300 et 400 dollars. Glyn Moody du Linux Journal anticipe même une distribution gratuite du matériel pour développer le modèle publicitaire de Google.

L’adoption de ChromeOS s’accélère à partir de 2015, notamment dans les écoles américaines. IDC rapporte 4,6 millions de Chromebooks vendus en 2014, soit deux fois plus qu’en 2013. Gartner table sur 14,4 millions d’unités en 2017. L’intégration progressive des applications Android et la possibilité d’exécuter des applications Windows via des solutions de virtualisation étendent les capacités du système.

Les performances des Chromebooks basés sur les processeurs Intel démontrent l’importance de l’optimisation matérielle. Les tests comparatifs révèlent des gains de 50% et une autonomie supérieure de 58% par rapport aux solutions ARM concurrentes. Ces résultats témoignent de l’investissement continu des ingénieurs pour améliorer l’efficacité du système.

ChromeOS propose une approche centrée sur le web qui utilise le cloud computing. Sa simplicité, sa sécurité et son modèle de mise à jour automatique influencent aujourd’hui la conception des systèmes d’exploitation modernes. Ce système d’exploitation est loin d’avoir remplacé les systèmes en place, mais il a tracé une voie différente, prouvant qu’une alternative légère et connectée pouvait trouver sa place dans un marché dominé par des géants établis.

Haut de page

NVMe

Les disques SSD commencent à se répandre au début des années 2010, mais se heurtent à un problème inattendu. Ces nouveaux supports dépassent en performances les disques durs mécaniques, pourtant ils restent freinés par les protocoles de communication qui n’ont pas été pensés pour eux. Les interfaces SATA et SAS, conçues pour dialoguer avec des disques à plateaux tournants, imposent leurs contraintes à des mémoires capables de bien mieux faire.

Un groupe de travail regroupant les grands noms de l’industrie décide en 2011 de prendre le problème à bras-le-corps. Plutôt que d’essayer d’adapter l’existant, ces ingénieurs repartent d’une page blanche. Ils publient la première spécification du NVMe (Non-Volatile Memory Express), version 1.0. L’idée directrice est simple : créer une interface native pour les mémoires non volatiles, qui exploite directement le bus PCI Express et dialogue naturellement avec les processeurs modernes.

La proposition bouscule les habitudes. Là où SATA ne gère que 32 commandes dans une file unique, et SAS 256, le NVMe crée jusqu’à 64 000 files d’attente, chacune capable de contenir 64 000 commandes. Cette architecture multi-files s’accorde avec les processeurs multicœurs qui équipent désormais les machines. Chaque application peut disposer de ses propres files, sans interférer avec les autres.

La version 1.1 arrive en octobre 2012 avec son lot d’améliorations. Le protocole intègre la gestion du multi-chemin d’accès et le partage des ressources, des fonctions indispensables dans les environnements professionnels. Les mécanismes de gestion autonome de l’alimentation font aussi leur apparition, anticipant les besoins des ordinateurs portables et des appareils mobiles.

En 2014, la création de NVM Express, Inc. structure la gouvernance du standard. Cette organisation rassemble plus d’une centaine d’entreprises et accélère le développement. La version 1.2 sort en novembre avec des perfectionnements notables : gestion avancée des espaces de nommage, optimisation des tampons mémoire, possibilité de mettre à jour le firmware sans interruption.

Les formats physiques se multiplient pour s’adapter aux usages. Les cartes d’extension PCIe équipent les serveurs et les stations de travail. Les modules M.2 trouvent leur place dans les ordinateurs portables et les machines compactes. Les disques U.2, au format 2,5 pouces, s’installent dans les baies de stockage traditionnelles. Cette diversité facilite l’adoption du NVMe dans tous les segments du marché.

Le protocole intègre des mécanismes de sécurité conformes aux spécifications du Trusted Computing Group. Le chiffrement des données au repos et l’effacement sécurisé répondent aux exigences croissantes en matière de confidentialité. Ces fonctions sont incontournables dans un contexte où la protection des données s’impose comme une priorité.

L’année 2015 apporte la spécification NVMe-MI (Management Interface). Cette extension standardise la gestion hors bande des périphériques, unifiant les commandes de configuration, de surveillance et de maintenance. Les administrateurs système gagnent en simplicité et en cohérence dans la gestion de leurs infrastructures de stockage.

Le tournant de 2016 voit naître NVMe over Fabrics. Cette évolution étend le protocole aux réseaux de stockage, qu’ils utilisent Ethernet, Fibre Channel ou InfiniBand. Le NVMe sort ainsi du cadre des connexions directes pour s’intégrer dans les architectures réseau complexes, sans perdre ses avantages en termes de performances et de latence.

La version 1.3, publiée la même année, enrichit le standard de fonctions destinées aux appareils mobiles. L’optimisation de la gestion de l’énergie et l’intégration de mécanismes adaptés aux systèmes embarqués font du NVMe la première interface de stockage véritablement universelle. Du téléphone au centre de données, un seul protocole couvre désormais tous les besoins.

Les chiffres parlent d’eux-mêmes. Le NVMe divise par deux le nombre d’instructions processeur nécessaires au traitement des entrées-sorties par rapport à SATA ou SAS. Cette efficacité se traduit par une latence réduite et un débit supérieur. Les périphériques NVMe dépassent le million d’opérations par seconde, là où les interfaces précédentes plafonnaient bien en deçà.

Le support logiciel suit. Windows, Linux et MacOS intègrent des pilotes natifs. Les environnements de virtualisation comme VMware ESXi adoptent le protocole, permettant son utilisation dans les infrastructures virtualisées qui constituent le cœur des centres de données modernes.

Le succès du NVMe tient à une approche globale. En repensant entièrement l’interface entre processeurs et mémoires non volatiles, le protocole supprime les goulots d’étranglement hérités des anciennes architectures. Cette refonte exploite pleinement les performances des nouvelles technologies de mémoire, sans compromis lié à des contraintes obsolètes.

En quelques années, le NVMe s’impose comme un standard incontournable, soutenu par un écosystème riche en produits et solutions. Son évolution continue garantit sa pertinence face aux futures technologies de stockage, confirmant sa place centrale dans l’architecture des systèmes informatiques contemporains.

Haut de page

Dart

En octobre 2011, lors de la conférence GOTO à Aarhus au Danemark, Lars Bak et Kaspar Lund présentent au public un nouveau langage de programmation développé chez Google : Dart. L’ambition affichée est claire : offrir une alternative crédible à JavaScript pour le développement web, un langage qui échapperait aux défauts et aux limites que les développeurs reprochent alors au vénérable JavaScript.

Les deux ingénieurs de Google ont conçu Dart avec une idée en tête : unifier le développement logiciel sur différentes plateformes sans sacrifier les performances. La syntaxe du langage emprunte volontairement aux langages établis comme Java, C ou JavaScript, histoire de ne pas trop désorienter les développeurs qui franchiraient le pas. Cette familiarité calculée vise à faciliter l’adoption : pas besoin de tout réapprendre depuis zéro.

Le 14 novembre 2013, Google publie la version 1.0 de Dart. C’est la première mouture stable, celle qui doit convaincre la communauté que Dart peut bel et bien remplacer JavaScript dans les applications web. L’année suivante, en juillet 2014, Ecma International valide le langage lors de sa 107^e Assemblée Générale et crée le standard ECMA-408. Cette reconnaissance officielle confère à Dart une légitimité qu’un simple projet d’entreprise n’aurait pas eue.

Mais les débuts ne sont pas aussi glorieux qu’espéré. Google nourrit l’ambition d’intégrer directement dans Chrome une machine virtuelle Dart pour booster les performances des applications. L’idée fait grincer des dents. Les développeurs web craignent une fragmentation du web, où chaque navigateur imposerait sa propre machine virtuelle. Face à cette résistance, Google fait marche arrière. En 2015, avec la version 1.9, le projet d’intégration native dans les navigateurs est abandonné.

L’histoire de Dart aurait pu s’arrêter là, cantonnée à un énième langage web sans grand relief. Mais 2017, Google lance Flutter, un framework pour créer des interfaces utilisateur qui fonctionnent sur mobile, web et desktop à partir d’un même code source. Et Flutter choisit Dart comme langage principal. Cette alliance redonne un souffle au langage, qui trouve enfin sa vraie raison d’être : servir de socle au développement multiplateforme.

Août 2018 marque une rupture avec l’arrivée de Dart 2.0. Cette version restructure le langage, notamment par l’introduction d’un système de typage bien plus strict. Le code gagne en sécurité et en lisibilité, deux qualités indispensables pour les applications complexes. Le compilateur est également remanié pour produire du code natif performant, les applications Flutter pouvant ainsi atteindre des performances comparables aux solutions développées spécifiquement pour iOS ou Android.

Dart propose deux modes de compilation distincts. La compilation anticipée (Ahead-of-Time ou AOT) transforme le code en JavaScript optimisé pour le web, ou en code machine natif pour les applications mobiles. La compilation à la volée (Just-in-Time ou JIT) facilite un développement plus fluide grâce au rechargement à chaud du code : on modifie le code, et l’application se met à jour instantanément sans redémarrage complet. Cette souplesse accélère considérablement le cycle de développement.

Le langage adopte une approche résolument orientée objet : tout est objet, y compris les nombres et les fonctions. Classes, interfaces, mixins, génériques... Dart reprend les concepts familiers des langages modernes. La gestion automatique de la mémoire libère le développeur des tâches fastidieuses d’allocation et de désallocation manuelle des ressources.

Le succès de Flutter tire Dart vers le haut. La version 2.7 introduit les méthodes d’extension, qui permettent d’ajouter de nouvelles fonctionnalités aux types existants sans modifier leur code source. Cette astuce s’avère précieuse pour enrichir les interfaces utilisateur développées avec Flutter.

L’écosystème s’étoffe progressivement. Le SDK Dart intègre un compilateur dart2js pour générer du JavaScript, un analyseur statique qui détecte les erreurs avant l’exécution, un formateur de code et un gestionnaire de paquets. Ces outils accompagnent le développeur tout au long du processus de création.

L’approche technique de Flutter distingue Dart des autres solutions multiplateformes. Au lieu de compiler vers du code natif iOS ou Android, Flutter dessine directement chaque pixel à l’écran grâce à son propre moteur de rendu. Cette stratégie garantit une expérience utilisateur identique sur toutes les plateformes, sans dépendre des composants graphiques natifs de chaque système.

La machine virtuelle de Dart a été conçue pour tirer le meilleur parti du langage. Le garbage collector gère la mémoire avec efficacité, tandis que le compilateur produit du code optimisé pour chaque plateforme cible, grâce à quoi les applications Dart atteignent des performances élevées tout en conservant une base de code unique.

Des entreprises de toutes tailles utilisent Dart et Flutter pour développer leurs applications. La possibilité de réutiliser le code entre mobile, web et desktop représente un gain de temps et d’argent considérable. On écrit une fois, on déploie partout, avec des performances au rendez-vous.

L’avenir de Dart reste intimement lié à celui de Flutter. Google continue d’investir dans les deux technologies, publiant régulièrement des mises à jour qui enrichissent les fonctionnalités et améliorent les performances. Le langage évolue pour répondre aux besoins du développement moderne, avec un objectif constant : rendre les développeurs plus productifs.

Parti comme une alternative à JavaScript, Dart a finalement trouvé sa voie dans le développement multiplateforme. Son association avec Flutter lui a donné une seconde jeunesse et un véritable terrain de jeu.

Haut de page

Kotlin

En 2010, JetBrains, une entreprise pragoise spécialisée dans les outils de développement, se lance dans la création d’un nouveau langage de programmation. L’objectif est de concevoir une alternative à Java, plus concise et plus sûre, sans pour autant renoncer à la compatibilité avec la machine virtuelle Java. Cette compatibilité n’est pas un détail puisqu’elle garantit que les développeurs pourront adopter progressivement le nouveau langage sans réécrire leur code existant.

Le projet sort de l’ombre en juillet 2011 sous le nom de « Project Kotlin ». Quelques mois plus tard, en février 2012, JetBrains ouvre le code source sous licence Apache 2.0. Ce choix d’ouverture n’est pas anodin : il traduit une volonté d’impliquer la communauté des développeurs dès les premières heures du projet. Quatre ans plus tard, le 15 février 2016, la version 1.0 débarque. Cette première version stable marque le véritable départ de Kotlin, qui commence à séduire par sa syntaxe épurée et son approche pragmatique. Un chiffre frappe d’emblée : Kotlin réduit en moyenne de 40% le nombre de lignes de code nécessaires comparé à Java pour accomplir une même tâche.

L’année 2017 bouleverse la donne. En mai, Google annonce son support officiel pour le développement Android, faisant de Kotlin une alternative crédible à Java. Cette consécration propulse le langage au cœur du développement mobile. Mais Kotlin ne s’arrête pas là. En avril, il franchit un nouveau cap en devenant multiplateforme grâce à Kotlin/Native et au support stabilisé pour JavaScript. Six mois plus tard, la version 1.2 introduit la possibilité de partager du code entre backend, frontend web et applications mobiles Android. Cette capacité répond à un besoin grandissant : réutiliser son code sur différentes plateformes sans tout réécrire.

En octobre 2018, Google et JetBrains créent ensemble la Kotlin Foundation. Cette structure garantit l’indépendance du langage et assure sa gouvernance de façon transparente. Un an plus tard, en 2019, Google va plus loin en déclarant Kotlin comme langage privilégié pour Android. Concrètement, cela signifie que les nouvelles fonctionnalités et API Android arrivent d’abord en Kotlin. Le langage reçoit le prix « Breakout Project of the Year » lors de la convention O’Reilly Open Source Software, reconnaissance de son ascension fulgurante.

Ce qui séduit dans Kotlin, c’est d’abord sa façon de traiter la nullabilité. Le système de types intègre directement cette gestion, réduisant drastiquement les erreurs liées aux références nulles qui empoisonnent la vie des développeurs Java. Les expressions lambda et les fonctions d’extension enrichissent les possibilités de programmation fonctionnelle. Quant aux classes de données, elles simplifient la création d’objets destinés au stockage d’informations.

Le langage évolue vite. La version 1.1 apporte les coroutines qui facilitent la programmation asynchrone. La version 1.3 introduit les contrats et les classes inline, améliorant performances et sécurité du code. Le compilateur transforme le code source en bytecode JVM, rendant son exécution possible sur toutes les plateformes supportant Java.

Les chiffres parlent d’eux-mêmes. En 2020, plus de 4,7 millions de développeurs utilisent Kotlin, dont 65% en production. Pour 56% d’entre eux, c’est devenu leur langage principal. Des géants comme Google, Uber, Atlassian, Pinterest et Square l’ont intégré dans leur code de production. Kotlin est le 13^e langage de programmation le plus populaire, dépassant Scala et Swift. Le rapport GitHub de 2018 le classait déjà comme le langage connaissant la croissance la plus rapide. Stack Overflow le place quatrième dans le classement des langages préférés des développeurs professionnels.

La communauté grossit. En 2020, plus de 100 personnes travaillent sur le langage chez JetBrains, épaulées par plus de 350 contributeurs indépendants qui participent à son évolution. Cette effervescence collective nourrit le développement continu du langage et de son écosystème.

Kotlin réduit le code passe-partout qui alourdit Java, prévient les erreurs courantes et simplifie des tâches complexes. Son approche multiplateforme répond aux attentes actuelles du développement logiciel.

Haut de page

WebRTC

WebRTC est une technologie est née de la rencontre entre les navigateurs web et la communication temps réel. Ses racines plongent dans plusieurs décennies d’évolution des protocoles internet.

Retour en 1996. La publication du Real-time Transport Protocol (RTP) dans le RFC 1889 jette les bases de ce qui deviendra WebRTC. Ron Frederick, l’un des auteurs de ce protocole, avait commencé dès octobre 1992 des expérimentations avec la carte de capture vidéo Sun VideoPix. Son but était de créer un outil de visioconférence réseau basé sur la multidiffusion IP. Le projet s’appelle « nv » (Network Video tool) et s’inspire de « vat », un outil de conférence audio développé par LBL qui utilisait un protocole de session léger pour gérer les participants.

La compression vidéo représentait un enjeu technique considérable. Frederick voulait obtenir un flux acceptable dans une bande passante limitée à 128 kbps, soit la capacité d’une ligne ISDN standard. Cela exigeait un facteur de compression d’environ 20 pour la taille d’image et la fréquence visées. Frederick parvint à développer une technique innovante qui fit l’objet d’un brevet (US5485212A) sur la compression vidéo logicielle pour la téléconférence.

La première version de nv sort en novembre 1992. Elle retransmet certaines sessions de l’IETF dans le monde entier. L’impact est immédiat : environ 200 sous-réseaux dans 15 pays peuvent recevoir cette diffusion, et entre 50 et 100 personnes utilisent nv durant cette période. Le succès se confirme lors de différents ateliers internationaux, notamment l’Australian NetWorkshop et le MultiG workshop sur les réalités virtuelles distribuées en Suède.

Frederick rend le code source public en février 1993. Il introduit ensuite un nouveau système de compression basé sur les ondelettes, et ajoute le support de la vidéo couleur. Le protocole réseau utilisé par nv et d’autres outils de conférence Internet sert de base au protocole RTP que l’IETF normalise. RTP est un standard incontournable, d’abord publié dans les RFC 1889-1890, puis révisé dans les RFC 3550-3551.

L’évolution de nv se poursuit avec des portages sur différentes plateformes matérielles et périphériques de capture vidéo. La NASA choisit cet outil pour diffuser en direct la couverture des missions de la navette spatiale. En 1994, Frederick enrichit nv avec des algorithmes de compression développés par d’autres, incluant des systèmes matériels comme le format CellB de la carte de capture SunVideo.

Cette histoire précoce des communications temps réel sur Internet esquisse WebRTC. Les défis rencontrés par les pionniers comme Frederick ont établi les bases des protocoles modernes. La multidiffusion IP permettait une distribution efficace des données vers de multiples destinataires, une approche différente de l’architecture unicast adoptée plus tard par WebRTC.

Le passage de la multidiffusion à l’unicast s’explique par des raisons pratiques. La complexité de mise en œuvre de la multidiffusion dans les réseaux existants a conduit à privilégier des solutions plus simples à déployer. Cette évolution a nécessité l’introduction de nouvelles architectures, comme les SFU (Selective Forwarding Units), pour gérer la distribution des flux médias entre participants.

L’histoire de WebRTC prend un tournant avec l’arrivée de Serge Lachapelle. Sa passion pour les logiciels de communication remonte aux années 1990, où il développe un projet pour rejoindre des appels vidéo directement depuis un navigateur. Cette expérience le conduit à cofonder Marratech, une entreprise spécialisée dans la visioconférence de groupe. Google acquiert Marratech en 2007 et intègre une expertise précieuse dans son équipe.

Le développement de la messagerie vocale et vidéo de Gmail constitue une étape intermédiaire significative. Cette réalisation implique l’intégration complexe de différents composants : l’audio sous licence GIPs, la vidéo de Vidyo et le réseau via libjingle. Justin Uberti relève le défi technique de faire fonctionner ensemble ces systèmes aux API disparates, ce qui nécessite des connaissances approfondies en réseaux, cryptographie et médias.

Le lancement du projet Chrome chez Google ouvre un nouveau chapitre. L’ambition d’enrichir les capacités du navigateur, combinée à une volonté d’abandonner l’API NPAPI pour des raisons de sécurité, crée un contexte favorable à l’émergence de WebRTC. L’architecture sandbox de Chrome, qui isole les opérations potentiellement dangereuses dans des processus distincts, influence la conception sécurisée de WebRTC.

La naissance de WebRTC répond à trois objectifs principaux. D’abord, simplifier le développement d’expériences de communication temps réel. Ensuite, promouvoir une communication humaine ouverte et non entravée. Enfin, garantir la sécurité par défaut. Pour concrétiser cette vision, Google acquiert et rend open source quelques technologies clés, notamment celles d’On2 pour la vidéo et de Global IP Solutions pour les communications temps réel.

La standardisation de WebRTC représente un effort sans précédent. Elle nécessite la collaboration de deux organismes de normalisation (IETF et W3C) et de centaines d’experts internationaux. Harald Alvestrand, fort de son expérience à l’IETF, initie le processus. Une réunion informelle à Maastricht en 2010 rassemble des développeurs de Google, Cisco, Ericsson, Skype, Mozilla et Linden Labs. Les bases de la spécification sont posées.

WebRTC s’appuie sur l’héritage des technologies existantes. Il évite de réinventer des solutions déjà éprouvées. La décision de ne pas standardiser la signalisation, traitée par SIP et d’autres protocoles, illustre cette approche pragmatique. Cette stratégie concentre les efforts sur l’innovation plutôt que sur la redéfinition de concepts établis.

L’utilisation de WebRTC dans le cloud gaming démontre sa polyvalence. Les avancées en intelligence artificielle améliorent la qualité des communications, notamment par la suppression du bruit de fond. Cette extension des usages témoigne de la robustesse et de la flexibilité de l’architecture WebRTC. La collaboration internationale et l’engagement en faveur de standards ouverts ont créé une plateforme qui continue d’innover et de s’adapter aux nouveaux usages.

Haut de page

WebSocket

Au début des années 2000, les développeurs web se heurtent à un problème récurrent. Les applications qu’ils conçoivent – messageries instantanées, jeux en ligne, tableaux de bord collaboratifs – exigent des échanges constants entre navigateurs et serveurs. Or le Web, tel qu’il existe alors, ne sait pas vraiment gérer ce type de dialogue. HTTP, le protocole qui régit les communications sur Internet, fonctionne selon un modèle rigide : le client demande, le serveur répond. Pas de place pour une conversation fluide dans les deux sens.

Les ingénieurs trouvent des parades. La plus répandue, le « HTTP polling », consiste à bombarder le serveur de requêtes régulières pour vérifier s’il a du nouveau à dire. Une variante, le « long polling », maintient la connexion ouverte jusqu’à ce qu’une information arrive. Ces bidouilles fonctionnent, certes, mais génèrent un trafic réseau considérable. Chaque requête HTTP trimballe des en-têtes volumineux, des centaines d’octets à chaque fois, pour transporter parfois quelques bytes d’information utile.

La RFC 6455, publiée par l’IETF en décembre 2011, vient mettre fin à cette époque d’improvisation. WebSocket propose une approche radicalement différente. Le protocole démarre par une poignée de main HTTP classique, puis bascule vers une connexion permanente. Une fois établi, ce canal envoie des messages dans les deux sens avec un overhead minimal – quelques octets de contrôle au lieu des centaines précédemment nécessaires. Le protocole gère indifféremment du texte ou du binaire, et intègre des mécanismes de surveillance de la connexion via des messages « ping » et « pong ».

Les navigateurs adoptent cette innovation. Chrome, Firefox et Safari déploient des implémentations expérimentales dès 2010. Internet Explorer rejoint le mouvement en 2012. Cette convergence rapide des éditeurs témoigne d’un besoin réel du marché. Les développeurs peuvent enfin créer des applications web réactives sans passer par des contournements complexes et fragiles.

Les chiffres parlent d’eux-mêmes. Sur un site de trading affichant des cours boursiers en temps réel, WebSocket réduit le trafic de 417 octets par mise à jour et par client. Avec 4 835 visiteurs simultanés, l’économie de bande passante grimpe à 16 mégabits par seconde. L’impact se mesure aussi dans les statistiques d’adoption : 1,6% des sites du top million en 2018, 6,3% en 2020. Cette progression témoigne d’une technologie arrivée à maturité.

L’écosystème se structure autour du protocole. Socket.io et SockJS proposent des API de haut niveau qui simplifient son utilisation. Les services de chat, les plateformes collaboratives et les applications financières en font leur cheval de bataille. Les outils d’analyse web l’utilisent pour collecter des données sur le comportement des utilisateurs en temps réel. WebSocket trouve sa place dans l’Internet des objets et les architectures microservices, où sa légèreté et sa bidirectionnalité offrent des avantages tangibles.

La technologie n’échappe pas aux dérives. Certains développeurs négligent les bonnes pratiques de sécurité – vérification des en-têtes Origin, chiffrement TLS systématique. Des acteurs malveillants détournent le protocole pour du pistage ou la diffusion de logiciels indésirables. Ces zones d’ombre rappellent qu’aucune innovation technique n’est neutre.

HTTP/2, standardisé en 2015, introduit la fonctionnalité Server Push. Les serveurs peuvent maintenant envoyer des ressources aux clients sans attendre de requête. Cette capacité ne remplace pourtant pas WebSocket : elle ne crée pas de véritable canal bidirectionnel. Google l’admet implicitement en abandonnant le support de Server Push dans Chrome en 2020, confirmant la position unique de WebSocket dans le paysage web.

Des technologies concurrentes émergent, comme les Server-Sent Events. WebSocket conserve néanmoins sa pertinence. La stabilisation de son taux d’adoption depuis 2019 suggère qu’il a trouvé sa place dans la palette des outils disponibles. Les frameworks modernes l’intègrent par défaut, les développeurs le maîtrisent, les cas d’usage se multiplient.

Le protocole n’a rien révolutionné : il a simplement rendu possible ce qui auparavant nécessitait des acrobaties. Cette simplicité conceptuelle, associée à une efficacité opérationnelle mesurable, explique son succès.

Haut de page

Go

En 2007, chez Google, des ingénieurs se trouvaient face à un problème devenu courant dans l’entreprise. Les langages existants ne répondaient plus aux besoins des applications modernes : réseautage intensif, processeurs multicœurs, environnements distribués. Rob Pike, l’un des concepteurs du futur langage Go, résumait cette impasse technique avec une certaine frustration. L’industrie disposait de nombreux outils, certes, mais aucun ne convenait vraiment.

Le cloud computing sortait tout juste de l’enfance, l’architecture orientée services trouvait ses marques dans les grandes organisations, et l’intégration continue commençait à transformer les pratiques de développement. Le paysage informatique ressemblait déjà à celui d’aujourd’hui. Go n’est pas né dans un laboratoire coupé du monde réel ; il a émergé au cœur des contraintes que rencontraient les équipes de développement.

Un détail frappe dans cette histoire : parmi les créateurs de Go se trouve Ken Thompson, celui qui avait conçu UNIX et le langage C des décennies plus tôt. Cette filiation n’a rien d’anecdotique. Elle trace une ligne directe entre deux époques de l’informatique, Go incarnant une réinterprétation contemporaine des principes qui guidaient la création du C.

Java, apparu en 1991, s’était imposé grâce à sa portabilité. Mais son statut propriétaire jusqu’en 2006 créait des complications : le procès Oracle contre Google en 2012 en témoigne. Quant au C, né en 1972 pour réécrire UNIX, il s’était répandu faute d’alternative ; il était l’un des rares langages rapides et multiplateformes accessibles aux premiers programmeurs. Go, lui, a été pensé dès l’origine pour les besoins actuels.

Le langage se distingue par sa conception réfléchie. Les temps de compilation restent courts, le code machine se génère directement, le typage fort impose une discipline qui rend les programmes lisibles et fiables. La documentation, exhaustive et libre, accompagne le tout. Dans une équipe de développement, souvent nombreuse et aux compétences variées, ces caractéristiques prennent une autre dimension : la collaboration rendue plus fluide, les délais de construction se réduisent, le code existant se déchiffre plus aisément.

Avec la gestion automatique de la mémoire, les développeurs n’ont plus à programmer explicitement l’allocation et la libération mémoire, contrairement au C ou au C++. Cette automatisation améliore la productivité, certes, mais surtout elle renforce la sécurité en diminuant les vulnérabilités liées aux erreurs de manipulation mémoire.

L’intégration native de la concurrence représente sans doute l’innovation la plus significative. Les applications peuvent exécuter plusieurs tâches simultanément plutôt que séquentiellement, exploitant ainsi les processeurs multicœurs. Pour les applications distribuées sur de multiples serveurs ou les architectures en microservices, cette fonctionnalité se révèle précieuse.

Le déploiement des applications Go reste simple. Contrairement à Java qui nécessite des interpréteurs locaux ou des machines virtuelles, les programmes Go se compilent en binaires autonomes. L’outil Get télécharge et installe une application via une commande unique. Cette approche correspond parfaitement aux pratiques DevOps qui privilégient la cohérence des chaînes de développement et la simplicité des mises à jour.

Dans le domaine de la science des données, Go démontre sa polyvalence. Il intègre aisément des algorithmes écrits en Python dans des applications en microservices. Les performances obtenues évitent souvent le recours à l’optimisation en C ou C++, langages bas niveau réputés plus complexes.

La communauté de développeurs autour de Go n’a cessé de croître. En 2016, plus de 700 programmeurs contribuaient à son développement. Le classement TIOBE des langages de programmation illustre cette ascension : Go passe de la 55^e à la 10^e place entre 2016 et 2017.

De nombreuses plateformes open source ont adopté Go. Cloud Foundry l’a choisi pour des composants comme gorouter, qui gère la connectivité des applications en microservices. Docker, qui a transformé le déploiement applicatif, est entièrement écrit dans ce langage. Les développeurs Docker ont opté pour Go en 2013, séduits par sa facilité d’installation, de test et d’adoption. InfluxDB, système de stockage haute performance, tire parti de l’efficacité et de la fiabilité du langage.

Des entreprises technologiques de premier plan ont intégré Go dans leurs infrastructures. Dropbox a migré une partie importante de son infrastructure de Python vers Go pour améliorer son extensibilité. Netflix utilise Go pour créer des microservices nécessitant performance et scalabilité. Uber a développé en Go son service de géolocalisation en temps réel, qui affiche les meilleures performances parmi tous ses services.

Le succès de Go s’explique par son adéquation avec les besoins du développement logiciel moderne. Sa conception prend en compte les environnements cloud, le traitement distribué et les architectures en microservices. La simplicité d’utilisation, associée à des performances élevées et une maintenance facilitée, en fait un choix pertinent pour les entreprises qui modernisent leurs applications.

L’émergence de Go marque l’évolution des langages de programmation vers des solutions adaptées au cloud computing et aux architectures distribuées. Les besoins contemporains en matière de développement logiciel ont conduit à repenser les outils de programmation, créant un langage qui répond aux exigences de l’informatique actuelle tout en conservant une approche élégante et pragmatique.

Haut de page

Julia

Depuis une vingtaine d’années, les chercheurs utilisant du calcul scientifique vivent avec une contrainte qui ralentit leur travail : il faut choisir entre un langage facile à utiliser pour tester des idées et un langage qui tourne vite pour produire des résultats. Quand on veut prototyper, on utilise Python ou MATLAB. Mais dès qu’on veut des calculs sérieux, on reprend tout en C++ ou en Fortran. Cette gymnastique permanente entre deux langages fait perdre du temps et complique les projets sans raison valable.

C’est ce problème que Jeff Bezanson, Alan Edelman, Stefan Karpinski et Viral Shah ont décidé d’attaquer en 2009 au MIT. Ils veulent créer un langage qui réunirait la simplicité des langages dynamiques et la vitesse des langages compilés. Un pari audacieux, car ces deux qualités semblent contradictoires par nature.

La première version de Julia sort en 2013. Dès le début, le langage vise le calcul scientifique avec une architecture pensée pour les opérations sur les tableaux multidimensionnels, à la manière de Fortran. Le moteur repose sur LLVM, qui génère du code machine adapté aux différentes architectures matérielles. Julia compile le code à la volée, au moment où il s’exécute. Cette compilation just-in-time réconcilie deux mondes qu’on croyait séparés : la réactivité d’un langage interprété et la rapidité d’un programme compilé.

L’originalité de Julia tient surtout à son système de dispatch multiple. Contrairement aux langages objets classiques où une méthode dépend du type d’un seul objet, Julia choisit la bonne fonction selon les types de tous les arguments. Ce mécanisme rend le code beaucoup plus flexible et facilite la composition de bibliothèques qui n’ont pas été conçues ensemble. Le langage intègre aussi des macros puissantes, du calcul parallèle natif, et dialogue sans friction avec du code C ou Fortran existant.

La communauté se structure. En 2014 a lieu la première JuliaCon, qui se transforme vite un rendez-vous annuel. Trois ans plus tard, le registre compte déjà plus de 1 000 paquets. Des entreprises de poids commencent à s’y intéresser : Aviva et la Federal Reserve Bank of New York côté finance, Pfizer, Moderna et AstraZeneca dans la pharmacologie, ASML pour les semi-conducteurs.

Les performances surprennent. Des benchmarks montrent que certaines fonctions mathématiques écrites en Julia pur tournent plus vite que leurs équivalents optimisés en C ou Fortran. L’implémentation de la fonction inverse de la fonction d’erreur bat celle de MATLAB d’un facteur 3 ou 4, et celle de SciPy de 2 à 3. Cette vitesse vient des techniques de métaprogrammation et de génération de code que Julia exploite naturellement, là où un langage de bas niveau demanderait des contorsions.

Le nom de l’environnement Jupyter rappelle le lien avec Julia (avec Python et R). Ces notebooks, qui mélangent code, résultats, graphiques et texte, collent bien aux besoins de l’enseignement et de la recherche reproductible. Le MIT et d’autres universités l’utilisent maintenant pour leurs cours de calcul numérique.

Julia fonctionne sur diverses architectures : processeurs ARM et GPU. Le gestionnaire de paquets intégré simplifie la gestion des dépendances et garantit la reproductibilité des environnements. Des outils automatisent la création de passerelles vers les bibliothèques C++, ce qui donne accès à un patrimoine logiciel considérable.

En 2022, Julia s’attaque à des projets scientifiques de grande ampleur. La Climate Modeling Alliance s’en sert pour la modélisation climatique, le projet Celeste pour le traitement d’images astronomiques, des équipes de physique des hautes énergies pour l’analyse de données. Ces applications montrent que le langage tient la distance sur des calculs complexes et massifs, sans sacrifier la lisibilité du code.

Le développement suit une logique open source classique, avec le code sur GitHub. Entre 2009 et 2017, plus de 40 000 commits s’accumulent. Les contributions passent par une revue stricte qui maintient la qualité. La documentation fournie et les tutoriels en ligne aident les nouveaux venus à entrer dans le langage sans trop galérer.

Les choix de départ se révèlent judicieux pour suivre l’évolution du calcul scientifique. L’équipe continue d’améliorer les temps de compilation, d’optimiser automatiquement le code, de supporter les nouvelles architectures. Le fil rouge reste le même : un langage unique qui combine facilité et performance.

Julia montre qu’on peut repenser les langages de programmation pour transformer les pratiques scientifiques. En résolvant élégamment le problème des deux langages, il a changé ce qu’on attend d’un outil de calcul : la productivité sans compromis sur la vitesse.

Haut de page

TypeScript

Lorsque Microsoft lance TypeScript en 2010, le paysage du développement web traverse une période de mutation rapide. JavaScript, jadis relégué aux interactions simples dans les navigateurs, s’impose désormais comme un langage incontournable. Les moteurs d’exécution gagnent en performance, les applications web monopage se multiplient, et Node.js ouvre la voie à JavaScript côté serveur. Cette expansion s’accompagne d’un problème : maintenir de vastes bases de code JavaScript est un véritable casse-tête.

Anders Hejlsberg, l’architecte derrière C#, prend la tête du projet avec une ambition claire. Il ne s’agit pas de remplacer JavaScript, mais de l’enrichir. TypeScript se présente comme un sur-ensemble syntaxique de JavaScript : tout code JavaScript valide reste un code TypeScript valide. L’idée maîtresse consiste à ajouter un système de types statiques facultatifs. Les développeurs peuvent annoter leur code, et ces annotations disparaissent à la compilation. Le JavaScript généré ne garde aucune trace du typage.

Cette décision technique reflète une compréhension fine des besoins réels. Le système de types adopte une approche structurelle plutôt que nominative, ce qui correspond mieux aux habitudes des développeurs JavaScript. Dans cet écosystème, les objets naissent souvent directement, sans passer par des classes formelles. TypeScript épouse cette pratique au lieu de la contrarier.

Un choix de conception mérite qu’on s’y attarde. Les créateurs de TypeScript ont délibérément renoncé à garantir une sûreté totale du typage. Ils ont préféré faciliter l’adoption progressive et maintenir la compatibilité avec les bibliothèques existantes. Cette souplesse autorise les équipes à introduire TypeScript dans leurs projets sans tout réécrire d’un coup.

Steve Ballmer, l’ancien PDG de Microsoft, avait comparé les licences open source à « un cancer qui s’attache à tout ce qu’il touche ». Il dénonçait le manque de responsabilité dans les logiciels libres. Pourtant, l’équipe de TypeScript savait qu’elle ne séduirait jamais la communauté JavaScript sans embrasser l’open source. En 2012, Microsoft publie TypeScript sous licence Apache-2.0, d’abord sur CodePlex, ensuite sur GitHub en 2014.

L’adoption croît progressivement. En 2025, le dépôt GitHub récolte plus de 107 000 étoiles et figure parmi les vingt projets les plus appréciés de la plateforme. Le package NPM enregistre plus de 100 millions de téléchargements hebdomadaires. Plus de 61 000 autres packages en dépendent. Ces chiffres traduisent une confiance établie.

Le langage introduit des concepts structurants : interfaces, classes, modules. Son système d’inférence de type réduit les annotations nécessaires tout en préservant les bénéfices du typage statique. Les outils de développement s’enrichissent d’autocomplétion et de navigation dans le code. Le compilateur, écrit en TypeScript, prouve la capacité du langage à gérer des projets complexes. Il analyse le code source, vérifie les types, et génère du JavaScript standard en préservant la sémantique du programme.

La communauté a bâti un écosystème riche autour de TypeScript. Le référentiel DefinitelyTyped rassemble des milliers de fichiers de définition de types pour les bibliothèques JavaScript traditionnelles. Ces déclarations permettent d’utiliser l’existant avec les avantages du typage statique. Les versions successives apportent des fonctionnalités avancées : types génériques, types conditionnels, types utilitaires. Ces ajouts autorisent l’expression de contraintes complexes et renforcent la sécurité du code. Une nouvelle version sort tous les deux mois, assurant une évolution constante.

TypeScript a instauré des pratiques plus rigoureuses dans l’écosystème JavaScript. Certains concepts ont enrichi JavaScript lui-même, comme le montrent les nouvelles versions d’ECMAScript. Cette réussite témoigne de la transformation de Microsoft vers une approche moins fermée du développement logiciel.

Haut de page

Docker

Il y a une quinzaine d’années, une jeune pousse du nom de dotCloud prenait une décision qui allait chambouler l’industrie informatique. En rendant public le code de son moteur de conteneurisation, l’entreprise offrait au monde Docker. La façon dont on construit, distribue et fait tourner des applications ne serait plus jamais la même. Pourtant, l’histoire des conteneurs ne commence pas avec Docker, loin de là.

Remontons à 1979. UNIX introduisait alors chroot, un mécanisme qui permettait de changer le répertoire racine d’un processus. Une brique élémentaire modeste qui posait les bases d’une idée : isoler le stockage des applications les unes des autres. FreeBSD franchit un cap en 2000 avec ses jails, fournissant une vraie virtualisation au niveau système. Linux-VServer emboîte le pas l’année suivante, suivi d’OpenVZ en 2005. Toutes ces technologies exploraient une piste similaire : partitionner les ressources système pour cloisonner les applications.

Mais aucune ne décollait vraiment. Trop complexes, trop rigides, elles restaient cantonnées à des usages de niche. LXC débarque en 2008 et pour la première fois, on dispose d’un gestionnaire complet de conteneurs qui s’appuie sur le noyau Linux standard, sans bidouilles ni modifications hasardeuses. La virtualisation légère est enfin accessible, du moins en théorie.

dotCloud utilisait LXC pour faire tourner sa plateforme cloud. Ses ingénieurs avaient bricolé un outil maison en Python, baptisé « dc », qui servait à manipuler les conteneurs LXC. Créer, démarrer, arrêter, exposer des ports réseau : les fonctions de base étaient là. Sauf que l’architecture posait problème. Les accès concurrents aux métadonnées des conteneurs créaient des conflits de verrous. Le système tenait debout, mais la fragilité guettait.

En 2013, Solomon Hykes et son équipe font le grand saut : ils libèrent leur moteur sous le nom de Docker. Docker ne se contente pas de rendre les conteneurs utilisables, il les rend simples. Le format d’image standardisé emballe une application avec tout ce dont elle a besoin. Les couches superposées en lecture seule permettent de partager les parties communes entre images. Le registre Docker Hub transforme le partage d’images en un jeu d’enfant.

L’architecture évolue vite. Docker s’émancipe de LXC dès 2014 en développant libcontainer, sa propre bibliothèque pour dialoguer avec le noyau Linux. Plus de dépendance externe, plus de contrôle, plus de stabilité. Les fondations techniques reposent sur les cgroups qui limitent les ressources, les namespaces qui isolent les processus, et des pilotes de stockage comme AUFS ou OverlayFS qui gèrent les couches d’images avec finesse.

La conception modulaire se précise. Le démon dockerd expose l’API et orchestre le tout. containerd prend en charge l’exécution des conteneurs. runc standardise leur création. Cette architecture en briques remplace ce qui ne convient pas, et adapte l’outil à des besoins spécifiques.

Le succès de Docker pose une question : comment garantir l’interopérabilité ? La Linux Foundation lance l’Open Container Initiative en 2015 pour établir des standards ouverts. Docker y contribue en donnant les spécifications de son format d’image et runc comme référence. Cette année naît aussi la Cloud Native Computing Foundation, qui hébergera Kubernetes, Prometheus et containerd. L’écosystème se structure, les standards s’imposent.

En avril 2015, Docker lève 95 millions de dollars lors d’un tour de table Series D mené par Insight Venture Partners. Des noms prestigieux rejoignent l’aventure : Goldman Sachs, Coatue, Northern Trust. Six mois plus tard, 18 millions supplémentaires s’ajoutent. La valorisation dépasse le milliard de dollars. Docker devient une « licorne », tous les poids lourds de la Silicon Valley misent sur cette technologie qui promet de révolutionner le déploiement logiciel. L’entreprise enchaîne les tours de financement jusqu’à atteindre près de 280 millions de dollars levés. En 2017, un nouveau tour rapporte 75 millions de plus, portant la valorisation à 1,3 milliard.

Docker bouleverse les pratiques. Une application mise en conteneur se comporte de la même manière partout : sur la machine du développeur, sur les serveurs de test, en production. Les ressources consommées restent raisonnables, bien loin de la lourdeur des machines virtuelles traditionnelles. La densité sur les serveurs s’améliore mécaniquement.

L’entreprise développe aussi Docker Swarm, son orchestrateur natif. L’idée semble tenir la route : gérer des flottes entières de conteneurs répartis sur plusieurs machines en conservant la simplicité de l’API Docker. Quelques commandes suffisent pour déployer un cluster. Pas de courbe d’apprentissage abrupte, juste une extension naturelle de ce que les développeurs connaissent déjà. En 2016, Docker intègre Swarm directement dans le moteur avec le « Swarm Mode ». C’est dans la boîte, prêt à l’emploi.

Sauf que Google avait libéré Kubernetes en 2014. Fruit d’une décennie d’expérience avec Borg, son système interne d’orchestration, Kubernetes grandit à une vitesse folle. La communauté open source s’enflamme. Les trois grands fournisseurs cloud adoptent Kubernetes : Google bien sûr, mais aussi Amazon avec EKS et Microsoft avec AKS. VMware et Red Hat s’y rallient. En 2017, la bataille est déjà perdue pour Docker Swarm. La direction de Docker l’admet en annonçant que la plateforme prendra en charge Kubernetes. Un aveu d’échec à peine déguisé.

Les tensions montent en interne. Trois directeurs généraux en une seule année. L’entreprise navigue à vue. Elle a deux activités distinctes qui fonctionnent selon des logiques incompatibles : d’un côté Docker Desktop et Docker Hub, prisés des développeurs mais difficiles à monétiser; de l’autre Docker Enterprise, une suite d’outils pour les grandes entreprises avec orchestration intégrée, contrats juteux, mais une complexité croissante.

En novembre 2019, Mirantis, spécialiste du cloud qui cherchait sa voie après l’essoufflement d’OpenStack, rachète toute l’activité entreprise de Docker. La transaction englobe Docker Enterprise Engine, Docker Trusted Registry, Docker Unified Control Plane, le CLI, et 750 clients grands comptes dont un tiers du Fortune 100. Trois cents employés rejoignent Mirantis. Le montant n’est pas divulgué, mais il est dérisoire comparé aux 280 millions levés. Les observateurs parlent d’une vente pour une bouchée de pain.

Le même jour, Docker annonce 35 millions de dollars de financement de la part de Benchmark Capital et Insight Partners. Scott Johnston, directeur des produits depuis 2014, devient le troisième directeur général de l’année. La société se restructure, se recentre sur les développeurs, garde Docker Desktop et Docker Hub. L’équipe passe de plusieurs centaines de personnes à une soixantaine. Beaucoup y voient la fin d’une époque. Les commentateurs déclarent Docker mort.

Docker et Mirantis conviennent de collaborer sur le développement open source. Mirantis s’engage à supporter Docker Swarm au moins deux ans, mais le message est clair : Kubernetes sera l’orchestrateur principal. L’acquisition des actifs Docker Enterprise permet à Mirantis de se positionner face aux géants comme VMware et Red Hat. Deux ans après le rachat, Mirantis annonce un chiffre d’affaires annuel dépassant 100 millions de dollars, dont la moitié provient des actifs rachetés à Docker. La greffe a pris.

De son côté, Docker renaît de ses cendres. Concentré sur son cœur de métier, l’entreprise retrouve une trajectoire de croissance. Le revenu annuel récurrent grimpe de 6 millions en 2020 à 50 millions en 2021, puis à plus de 135 millions en 2023. En mars 2022, Docker lève 105 millions de dollars lors d’un tour Series C mené par Bain Capital Ventures, avec une valorisation de 2,1 milliards. L’effectif double pour atteindre 150 personnes. En 2021, Docker Business voit le jour, une offre pour les grandes entreprises, et les conditions de licence de Docker Desktop changent. Le pari du recentrement paie.

Ce qui frappe dans l’histoire de Docker, c’est moins l’innovation technique pure que la démocratisation d’une idée. Les conteneurs existaient, mais personne ne les utilisait vraiment. Docker les a rendus accessibles, presque évidents. Cette simplification a ouvert la voie aux architectures microservices, accéléré le mouvement DevOps, transformé la façon dont on pense le déploiement logiciel.

Les composants se sont séparés, donnant aux utilisateurs le choix des éléments qui leur conviennent. De nouveaux outils apparaissent sans cesse pour optimiser la construction d’images, renforcer la sécurité, orchestrer les conteneurs. L’héritage de Docker tient dans les standards ouverts qu’il a établis, dans les fondations qu’il a posées pour l’industrie, et dans sa capacité à se réinventer après avoir frôlé la disparition. Docker Inc. existe toujours, plus petit mais viable, tandis que la technologie Docker irrigue l’ensemble de l’écosystème cloud moderne.

Haut de page

SHA-3

Fin des années 1970, les fonctions de hachage cryptographique commencent à prendre forme. Ces algorithmes transforment n’importe quelle donnée en une empreinte numérique de taille fixe, pour vérifier l’intégrité des données et créer des signatures électroniques. En 1976, Diffie et Hellman publient leur article fondateur sur la cryptographie à clé publique ; ils y identifient le besoin d’une fonction de hachage à sens unique pour construire des schémas de signature numérique.

Entre 1978 et 1979, Rabin, Yuval et Merkle posent les bases théoriques. Rabin propose une conception basée sur le chiffrement DES avec une sortie de 64 bits. Yuval démontre qu’on peut trouver des collisions pour une fonction de hachage de n bits en temps 2^n∕2 grâce au paradoxe des anniversaires. Merkle introduit les exigences de résistance aux collisions, aux pré-images et aux secondes pré-images, qui restent les propriétés fondamentales attendues d’une fonction de hachage cryptographique.

Les années 1990 voient l’émergence de MD4 et MD5, conçus par Ron Rivest, qui seront des standards très utilisés. SHA-1, publié par la NSA en 1995, s’impose comme le successeur de MD5 avec une sortie de 160 bits. SHA-2 arrive en 2001 avec des variantes générant des condensats de 224 à 512 bits. Ces algorithmes reposent sur la construction Merkle-Damgård : le message d’entrée est découpé en blocs de taille fixe auxquels on applique itérativement une fonction de compression.

En 2004, l’équipe de Xiaoyun Wang bouleverse le domaine en perfectionnant la cryptanalyse différentielle jusqu’à rendre triviale la recherche de collisions pour MD5. Ces travaux réduisent aussi considérablement la sécurité de SHA-1. En 2008, une équipe parvient à créer un certificat CA malveillant en exploitant les faiblesses de MD5. La communauté cryptographique s’inquiète de la robustesse des fonctions de hachage existantes. SHA-2 utilise des principes de construction similaires à SHA-1, ce qui pose question sur sa résistance future.

Le NIST lance en 2007 un concours public pour sélectionner un nouvel algorithme qui deviendra SHA-3. Le cahier des charges impose que les candidats supportent des sorties de 224, 256, 384 et 512 bits pour assurer la compatibilité avec SHA-2. Les soumissions doivent être libres de droits et utilisables mondialement sans restriction.

64 candidatures arrivent en 2008, dont 51 sont retenues pour le premier tour. À la mi-2009, environ la moitié des algorithmes sont cassés. Cette hécatombe démontre qu’il est difficile de concevoir une fonction de hachage sûre et efficace. En juillet 2009, le NIST sélectionne 14 candidats pour le second tour : Blake, Blue Midnight Wish, CubeHash, ECHO, Fugue, Grøstl, Hamsi, JH, Keccak, Luffa, Shabal, SHAvite-3, SIMD et Skein.

L’algorithme Keccak, développé par Guido Bertoni, Joan Daemen, Michaël Peeters et Gilles Van Assche, se distingue par son architecture novatrice basée sur la construction éponge. Contrairement à la construction Merkle-Damgård, cette approche absorbe le message bloc par bloc avec une partie appelée « taux » de 1 152 bits, tandis que les 448 bits restants servent de paramètre de sécurité. L’état interne forme un cube de 5×5×64 bits totalisant 1 600 bits.

En octobre 2012, le NIST désigne Keccak comme vainqueur du concours SHA-3. La décision s’appuie sur ses excellentes performances matérielles, sa marge de sécurité confortable et son architecture différente des autres SHA. La standardisation aboutit en août 2015 avec la publication du FIPS 202. SHA-3 comprend quatre fonctions de hachage classiques (SHA3-224, SHA3-256, SHA3-384 et SHA3-512) ainsi que deux fonctions à sortie extensible SHAKE128 et SHAKE256.

Les premières mises en œuvre de SHA-3 révèlent des caractéristiques intéressantes. Sur FPGA, l’algorithme nécessite plus de ressources matérielles que SHA-1 mais offre une meilleure résistance cryptographique. Les tests de performance indiquent que SHA-3 est environ 5,5 fois plus lent que SHA-1 du fait de sa complexité accrue. Pour le cassage de mots de passe par force brute, un mot de 6 caractères requiert quelques minutes avec SHA-1 contre plus d’une heure avec SHA-3.

L’introduction de SHA-3 marque une évolution dans l’histoire des fonctions de hachage cryptographique. Sa construction éponge rompt avec l’approche traditionnelle et inspire de nouveaux modes d’utilisation. Les fonctions à sortie extensible SHAKE apportent une innovation : on peut adapter la taille du condensat aux besoins spécifiques des applications. SHA-3 complète la famille SHA-2 en apportant une diversité architecturale qui renforce la résilience globale face aux futures avancées cryptanalytiques.

À ce jour, SHA-3 n’a pas subi d’attaque significative remettant en cause sa sécurité. Les recherches continuent pour explorer les possibilités offertes par la construction éponge, notamment pour la conception de primitives cryptographiques authentifiées. Le succès du concours SHA-3 démontre l’efficacité d’une approche ouverte et collaborative pour développer des standards cryptographiques robustes. Cette méthodologie sert désormais de modèle pour d’autres initiatives de standardisation en cryptographie.

Haut de page

Spark

En 2009, un groupe de chercheurs de l’université de Californie à Berkeley se lance dans le développement de Spark. Leur objectif est de créer un système de calcul distribué capable de dépasser les limites de MapReduce. Le problème était devenu évident : les applications modernes de traitement de données devaient sans cesse réutiliser les mêmes ensembles à travers plusieurs opérations parallèles, que ce soit pour l’apprentissage automatique ou l’analyse interactive.

L’idée centrale du projet tient en une abstraction baptisée RDD, pour Resilient Distributed Datasets. Il s’agit de collections d’objets répartis sur plusieurs machines, accessibles uniquement en lecture, mais capables de se reconstruire si une partition venait à disparaître. Cette approche apporte une tolérance aux pannes sans dupliquer les données, ce qui résout élégamment les questions de fiabilité dans les environnements distribués.

La première version publique arrive en 2010. Spark se démarque par sa capacité à garder les données en mémoire entre les opérations, là où les systèmes traditionnels réécrivaient systématiquement tout sur disque. Pour les algorithmes itératifs, ceux qui traitent les mêmes données encore et encore, le gain de performance est spectaculaire.

Le choix de Scala comme langage de programmation s’avère déterminant. Ce langage statiquement typé, qui s’exécute sur la machine virtuelle Java, offre une expressivité qui simplifie l’écriture d’applications distribuées. Les développeurs manipulent les RDD avec des constructions fonctionnelles, rendant le code plus lisible.

Le projet rejoint l’écosystème de l’Apache Software Foundation en 2013, renforçant ainsi son adoption. Les fonctionnalités se multiplient. SparkSQL voit le jour pour exécuter des requêtes relationnelles sur les données distribuées. Spark Streaming arrive pour traiter les flux en temps réel.

La conception modulaire du système autorise l’ajout progressif de bibliothèques spécialisées. MLlib propose des algorithmes d’apprentissage automatique adaptés aux environnements distribués. GraphX apporte des outils pour traiter les graphes à grande échelle. Ces extensions enrichissent l’écosystème tout en préservant la cohérence de l’interface.

L’architecture intègre un optimiseur nommé Catalyst, introduit en 2014. Ce composant analyse et améliore les requêtes SQL ainsi que les transformations de données. Il exploite les caractéristiques de Scala pour générer du code performant, fusionner les opérations et réduire les transferts entre nœuds du cluster.

L’interface de programmation unifiée constitue une avancée. Les développeurs combinent différents types de traitements dans une même application : SQL, streaming, apprentissage automatique. Plus besoin de jongler entre différents systèmes spécialisés. Cette approche allège la complexité des pipelines de données.

La communauté connaît une croissance exceptionnelle. En 2015, plus de 1 000 contributeurs participent au développement, faisant de Spark l’une des initiatives open source les plus dynamiques dans le traitement de données. Des entreprises comme Databricks, fondée par les créateurs originaux, bâtissent des services commerciaux sur cette technologie.

Les performances impressionnent. Pour les algorithmes itératifs, Spark peut être jusqu’à 100 fois plus rapide que Hadoop MapReduce grâce au maintien des données en mémoire. Dans le domaine des requêtes SQL, il rivalise avec des systèmes spécialisés comme Impala, tout en donnant davantage de flexibilité.

Les banques l’utilisent pour l’analyse de risques, les sites de commerce électronique pour leurs systèmes de recommandation, les centres de recherche pour traiter leurs données expérimentales. Cette diversité d’usages témoigne de la polyvalence du système.

En 2016, Spark devient le projet le plus actif de la fondation Apache. Certaines organisations déploient des clusters de plus de 8 000 nœuds. L’introduction des DataFrames, inspirés de R et Python, simplifie l’utilisation pour les data scientists qui manipulent des données tabulaires.

La conception de Spark influence l’évolution des systèmes distribués. Le modèle de programmation basé sur les transformations fonctionnelles et la gestion efficace de la mémoire inspirent de nombreux projets ultérieurs. Son approche unifiée pour différents types de traitements est une référence dans l’industrie.

Le développement se poursuit en intégrant les avancées en matière d’optimisation et d’accessibilité. Le projet maintient son orientation vers la simplicité d’usage tout en améliorant ses capacités techniques. La documentation abondante et les outils d’apprentissage forment une nouvelle génération de développeurs aux principes du traitement distribué.

En proposant une solution aux limites des approches existantes, tout en gardant un équilibre entre puissance et facilité d’usage, ce projet transforme la manière dont les organisations traitent leurs données à grande échelle. Son évolution continue reflète la nature mouvante du domaine du traitement de données distribuées.

Haut de page

Kubernetes

En 2006, Google se trouvait face à une équation difficile. L’entreprise proposait gratuitement Gmail, YouTube et son moteur de recherche à des millions d’utilisateurs. Comment gérer une infrastructure colossale sans que les coûts s’envolent ? Les ingénieurs ont alors développé Borg, un système interne capable de faire tourner des milliers d’applications sur leur parc de machines. Le nom rendait hommage à une race d’extraterrestres de Star Trek, ces créatures reliées par une conscience collective. L’analogie collait bien au projet. Borg optimisait l’usage des ressources matérielles en orchestrant l’exécution d’applications dans des conteneurs, une technologie qui commençait à peine à émerger. Google garda ce trésor secret pendant des années, conscient de l’avantage technique qu’il représentait.

En 2013, trois ingénieurs de l’entreprise – Craig McLuckie, Joe Beda et Brendan Burns – ont eu une intuition. Docker venait de rendre les conteneurs populaires auprès des développeurs, mais la technologie restait limitée. Elle ne savait gérer des conteneurs que sur une seule machine. L’expérience acquise avec Borg ouvrait la voie à quelque chose de plus ambitieux. Pourquoi ne pas créer un système capable d’orchestrer des conteneurs à l’échelle d’un centre de données entier ?

Ils ont baptisé leur idée « Project Seven », référence au personnage Seven of Nine de Star Trek, une ancienne drone Borg. Ce clin d’œil établissait un lien avec le système originel tout en marquant une rupture vers plus d’ouverture. Car le vrai pari résidait là. Rendre ce projet open source représentait un risque. Urs Hölzle, directeur technique de Google, voyait dans cette expertise en gestion de conteneurs un avantage concurrentiel. Mais l’entreprise a compris qu’une adoption massive nécessitait une communauté active de développeurs externes.

Le projet prit finalement le nom de Kubernetes, du grec ancien kubernētēs qui désigne le pilote ou le timonier d’un navire. Ce choix s’inscrivait dans la continuité maritime de Docker. Le système devait piloter des conteneurs, comme un timonier guide son navire. Le logo arbore sept branches, trace discrète du nom initial « Project Seven ».

Les concepteurs ont bâti Kubernetes en s’appuyant sur les leçons tirées de Borg et de son successeur Omega. L’architecture repose sur des clusters, avec d’un côté des nœuds de travail qui exécutent les applications conteneurisées, de l’autre des nœuds de contrôle qui gèrent l’orchestration. Le système utilise des étiquettes (labels) pour organiser et gérer les conteneurs de manière souple, abandonnant la numérotation séquentielle rigide de Borg.

La version 1.0 fut dévoilée en 2015 lors de la conférence OSCON. Dès le lancement, Microsoft, Red Hat et IBM ont apporté leur soutien. Google a confié le projet à la Cloud Native Computing Foundation (CNCF), une organisation à but non lucratif hébergée par la Linux Foundation. Ce transfert garantissait la neutralité du projet et son développement collaboratif.

Les fonctionnalités techniques de Kubernetes répondent aux exigences des applications modernes. Réplication automatique des conteneurs, équilibrage de charge, découverte de services, surveillance de la santé des applications, réparation automatique en cas de panne. Le système regroupe plusieurs machines pour distribuer efficacement la charge de travail.

L’approche de Kubernetes en matière d’API marque une évolution notable par rapport à Borg. Chaque objet possède trois champs fondamentaux : les métadonnées, la spécification de l’état désiré et le statut actuel. Cette standardisation a simplifié le développement d’outils et d’extensions par la communauté.

La gestion des « pods » apporte une dimension nouvelle. Un pod peut contenir plusieurs conteneurs partageant des ressources. Cette conception aide à décomposer les applications complexes en composants plus petits et mieux isolés, sans perdre la coordination entre eux.

L’ascension de Kubernetes s’inscrit dans une transformation plus vaste du développement logiciel. Le système a accompagné l’essor du cloud computing et des architectures en microservices. Les entreprises peuvent désormais déployer leurs applications de manière cohérente, sur leurs propres serveurs comme sur AWS, Microsoft Azure ou Google Cloud.

L’impact sur l’industrie informatique s’est révélé massif. En 2020, Kubernetes figurait parmi les dix projets open source les plus populaires sur GitHub. Selon la CNCF, il est devenu le deuxième plus grand projet open source après Linux. 71% des entreprises du Fortune 100 l’utilisent.

Cette histoire montre comment une technologie développée pour résoudre des problèmes internes à Google s’est muée en standard industriel grâce à l’open source. Elle souligne le rôle des communautés de développeurs dans l’adoption des technologies à grande échelle. Kubernetes a transformé la manière dont les entreprises développent, déploient et gèrent leurs applications, leur donnant l’agilité nécessaire pour innover vite sans sacrifier la stabilité de leurs services.

Haut de page

Swift

En 2014, le marché des applications mobiles connaît une croissance spectaculaire. Les ventes d’appareils mobiles approchent le milliard d’unités, le double des ordinateurs personnels. Apple saisit ce moment pour annoncer, en juin, la sortie de Swift, un nouveau langage de programmation qui mêle les approches impérative, orientée objet et fonctionnelle.

Depuis 1996, l’entreprise s’appuie sur Objective-C pour développer ses applications. Mais le langage a vieilli. Swift arrive comme une réponse à ce besoin de renouvellement : simplifier le code sans sacrifier la puissance, rendre la programmation plus fluide, plus intuitive. Les concepteurs ont cherché à créer quelque chose d’expressif, où l’interaction avec le code est presque naturelle.

Le succès est immédiat. En moins d’un an et demi, Swift rejoint le club des vingt langages les plus utilisés dans le monde. Cette ascension s’explique d’abord par l’immense base installée d’iOS : plus de 700 millions d’appareils vendus. La domination d’Apple sur son segment et l’annonce du remplacement progressif d’Objective-C ont fait le reste. Les développeurs n’avaient guère le choix, mais le langage s’est avéré suffisamment séduisant pour emporter l’adhésion.

Swift apporte son lot d’innovations. Les types optionnels, par exemple, constituent une vraie avancée. Cette fonctionnalité, habituelle dans les langages fonctionnels mais rare ailleurs, force le développeur à gérer explicitement les valeurs nulles. Moins d’erreurs, plus de clarté. La version 2.0 introduit un nouveau système pour gérer les erreurs avec do-try-catch, abandonnant l’ancienne approche par NSError héritée d’Objective-C.

Les développeurs chevronnés s’adaptent sans trop de peine. Certaines caractéristiques rappellent Objective-C, comme ces paramètres nommés qui rendent le code lisible presque comme une phrase en anglais. Pourtant, une analyse des questions posées sur StackOverflow révèle des zones d’ombre. Près de 17,5% des interrogations portent sur des notions fondamentales : manipulation des types, gestion des tableaux. Le langage n’est pas si simple qu’il n’y paraît.

Les pratiques de développement montrent des usages intéressants. Le chaînage optionnel se popularise. Cette technique élégante évite les erreurs de déréférencement tout en gardant le code compact. Au lieu d’empiler les conditions, on enchaîne les opérations avec un point d’interrogation. Le programme est plus sûr et plus agréable à lire.

Les premières années ne sont pas exemptes de critiques. Le compilateur, en particulier, agace. Il manque de stabilité, ses messages d’erreur restent obscurs. Xcode, l’environnement de développement, connaît des bugs qui ralentissent les équipes. Ces problèmes techniques contrastent avec les promesses d’une expérience de développement améliorée.

L’intégration avec Objective-C est un enjeu majeur. Apple a prévu des mécanismes pour faire cohabiter les deux langages dans une même application. Cette compatibilité est vitale : impossible de tout réécrire d’un coup, et les bibliothèques existantes sont trop nombreuses pour s’en passer. La transition se fait par étapes, projet après projet.

Face aux limites du langage, les développeurs bricolent leurs solutions. Le système de gestion des erreurs, par exemple, ne convient pas toujours au code asynchrone. Certains adoptent alors des énumérations de résultats, contournant les restrictions. Cette créativité témoigne d’une communauté qui s’approprie l’outil, qui le façonne à ses besoins.

L’App Store génère des revenus considérables. En janvier 2015, les développeurs ont gagné 25 milliards de dollars, davantage que sur les autres plateformes. Cette manne financière attire les entreprises comme les indépendants. Swift est un investissement rentable, pas seulement une question de préférence technique.

Le langage évolue au fil des retours d’expérience. Chaque nouvelle version corrige des défauts, optimise des fonctionnalités. La documentation s’étoffe, les tutoriels se multiplient et l’apprentissage est moins ardu pour les nouveaux arrivants. Apple écoute, ajuste, améliore.

Swift représente un virage dans la stratégie d’Apple. L’entreprise ne se contente pas de suivre les tendances ; elle forge un langage moderne qui intègre les meilleures pratiques actuelles. Cette démarche préserve la stabilité de l’écosystème tout en le propulsant vers l’avenir. Pas de rupture brutale, mais une transformation maîtrisée.

Il est délicat d’introduire une nouvelle technologie de programmation. Il faut innover sans perdre les acquis, séduire sans imposer, renouveler sans casser. Swift y est parvenu, s’imposant comme un acteur incontournable du développement mobile. Les années suivantes confirmeront cette position, faisant du langage bien plus qu’un simple remplaçant d’Objective-C.

Haut de page

Kafka

En 2008, chez LinkedIn, Jay Kreps se retrouve face à un défi que personne n’avait vraiment anticipé. Le réseau social professionnel génère des millions de messages chaque jour, et les systèmes traditionnels peinent à suivre le rythme. Les données transactionnelles classiques – profils, relations entre utilisateurs – restent gérables. Mais c’est surtout la masse d’informations comportementales qui pose problème : consultations de profils, recherches par mots-clés, interactions diverses. Ces traces numériques, indispensables pour comprendre les attentes des membres, submergent littéralement l’infrastructure existante.

Kreps décide alors de développer une solution nouvelle. Il s’associe en 2010 avec Neha Narkhede et Jun Rao pour finaliser ce qui deviendra Apache Kafka. Le nom fait référence à l’écrivain Franz Kafka, un clin d’œil à la vocation première du logiciel : gérer efficacement l’écriture de flux de messages. L’équipe conçoit une plateforme distribuée capable de diffuser des événements en temps réel, avec une architecture pensée pour encaisser des volumes considérables.

L’idée qui fait toute la différence tient en une approche contre-intuitive du stockage. Là où les solutions classiques gardent les messages en mémoire vive, Kafka les inscrit directement sur disque dur, de manière séquentielle. Cette méthode tire parti de l’optimisation naturelle des opérations d’entrée-sortie linéaires sur les disques durs, donnant des débits impressionnants sans sacrifier la fiabilité.

LinkedIn publie Kafka en open source en 2011, sous l’égide de la fondation Apache. Les géants de la Silicon Valley s’y intéressent : Twitter, Netflix et Yahoo adoptent la technologie, bientôt suivis par des entreprises plus traditionnelles comme Goldman Sachs, Walmart ou Cerner. Chez LinkedIn, les chiffres donnent le vertige : plus de 800 milliards de messages traités quotidiennement, soit plus de 175 téraoctets de données qui transitent sans faillir.

En 2014, les trois créateurs fondent Confluent. Leur objectif : développer l’écosystème autour de Kafka et proposer des solutions d’entreprise basées sur cette technologie. L’impact est immédiat : le taux d’utilisation est multiplié par sept dans les onze mois qui suivent le lancement de la société.

L’architecture repose sur des concepts simples mais efficaces. Les messages s’organisent en « topics », des catégories qui structurent les flux de données. Chaque topic se divise en partitions, répliquées sur différents serveurs pour garantir disponibilité et tolérance aux pannes. Cette organisation distribue la charge et fait évoluer le système horizontalement, sans limite théorique.

Le développement se poursuit avec des fonctionnalités majeures. Kafka Connect, disponible depuis la version 0.9, simplifie l’intégration avec les autres systèmes grâce à un cadre standardisé pour les connecteurs. Kafka Streams offre une bibliothèque de traitement des flux directement intégrée aux applications, sans infrastructure supplémentaire à déployer.

En 2022 sort KRaft (Kafka Raft), un mécanisme de consensus natif qui remplace la dépendance historique à ZooKeeper. L’architecture se simplifie et se fiabilise. Cette année voit aussi l’introduction du stockage hiérarchisé : une partie des données peut désormais être déportée vers des systèmes de stockage objet comme S3, ce qui réduit sensiblement les coûts d’exploitation.

Kafka a transformé la manière dont les entreprises pensent leurs architectures de traitement de données en temps réel. Le modèle a inspiré de nombreuses alternatives : RedPanda propose une implémentation compatible avec le protocole Kafka, tandis que WarpStream développe une architecture radicalement différente privilégiant le stockage sur S3.

En 2024, Kafka s’est imposé comme une technologie mature. Son adoption continue de croître, portée par l’augmentation constante des besoins en traitement temps réel et l’essor de l’Internet des objets. La communauté qui s’est formée autour du projet contribue régulièrement à son amélioration, assurant une évolution continue.

Le succès tient à une architecture technique solide, une réponse précise à un besoin réel, et à une communauté dynamique soutenue par une entreprise stable. Ce qui n’était au départ qu’un projet interne chez LinkedIn est devenu une pierre angulaire des architectures modernes.

Haut de page

GraphQL

En 2012, les équipes de Facebook butent sur un obstacle technique qui menace les performances de leurs applications mobiles. L’API News Feed, conçue selon les standards REST de l’époque, multiplie les allers-retours entre le client et le serveur. Chaque écran nécessite plusieurs requêtes vers différents points d’accès, et cette fragmentation ralentit l’expérience utilisateur. Sur les réseaux mobiles, où chaque milliseconde compte, la situation est critique. GraphQL naît comme une réponse pragmatique à un problème bien réel.

L’idée de départ tient en une observation simple : pourquoi le client ne pourrait-il pas demander exactement ce dont il a besoin, ni plus ni moins, en une seule fois ? Les architectures REST imposent une structure rigide où chaque endpoint retourne un ensemble prédéfini de données. Le client récupère souvent trop d’informations inutiles, ou pas assez, l’obligeant à enchaîner les appels. L’équipe de Facebook inverse la logique : au lieu que le serveur dicte ce qu’il envoie, c’est le client qui spécifie ce qu’il veut recevoir.

Pendant trois ans, GraphQL reste confiné aux serveurs de Facebook. Les ingénieurs affinent le concept, testent différentes approches, corrigent les erreurs. Le langage prend forme autour d’un schéma qui décrit les relations entre les données comme un graphe. La syntaxe s’inspire de JSON, familière aux développeurs web. En 2015, Facebook décide de publier la spécification et une implémentation de référence. La communauté découvre alors une manière radicalement différente d’interroger les API.

Le schéma constitue la pierre angulaire de GraphQL. Il définit les types d’objets disponibles, leurs champs, et comment ils se connectent entre eux. Avec ce contrat explicite entre le client et le serveur, les développeurs frontend savent exactement quelles données ils peuvent demander, les développeurs backend comprennent ce qu’ils doivent fournir. Le système de types fort attrape les erreurs avant l’exécution des requêtes, un filet de sécurité appréciable en production.

GitHub figure parmi les premiers adoptants majeurs. L’entreprise reconstruit son API publique avec GraphQL, suivie par Pinterest et Coursera. Twitter emprunte un chemin progressif : TweetDeck et Twitter Lite servent de terrain d’expérimentation avant le déploiement sur les applications Android et iOS. Chaque organisation adapte la technologie à ses contraintes, forge ses propres pratiques, contribue de nouveaux outils.

Le cas de Twitter illustre bien les ajustements nécessaires. L’infrastructure repose sur des microservices communiquant via Thrift, un système de sérialisation développé par Facebook. Intégrer GraphQL demande une refonte partielle : une couche frontale intercepte les requêtes GraphQL, les valide, gère l’authentification. Les services backend conservent leur logique métier, mais exposent leurs capacités d’une nouvelle manière. Cette architecture hybride préserve les investissements existants tout en exploitant les avantages de GraphQL.

Coursera rencontre d’autres difficultés. La première tentative de migration échoue face aux problèmes de synchronisation entre le schéma GraphQL et les données réelles. L’équipe trouve une solution astucieuse : un middleware traduit à la volée les API REST existantes en GraphQL. Les clients profitent de la nouvelle interface pendant que le backend évolue progressivement. Cette approche pragmatique démontre qu’il n’existe pas une seule bonne manière d’adopter GraphQL.

Les bénéfices techniques ne tardent pas. Fini le sous-chargement de données qui oblige à multiplier les requêtes. Fini le sur-chargement qui gaspille de la bande passante en transférant des informations superflues. Une seule requête bien formulée récupère exactement ce qui est nécessaire, en impliquant plusieurs ressources liées si nécessaire. Les applications mobiles respirent mieux, les pages web se chargent plus vite.

Le système de types introspection ouvre des possibilités inattendues. Les outils de développement interrogent le schéma pour fournir de l’autocomplétion, de la documentation dynamique, de la validation en temps réel. Les IDE se transforment en assistants efficaces qui guident le développeur au lieu de le laisser naviguer dans une documentation PDF obsolète.

Progressivement, la communauté enrichit le langage. Pour réutiliser des morceaux de requêtes, les fragments émergent comme une solution élégante. Les directives offrent un mécanisme souple pour adapter le comportement sans modifier le schéma. Les abonnements répondent au besoin croissant de mises à jour en temps réel, transformant GraphQL d’un système de requête-réponse en un canal de communication bidirectionnel.

La sécurité représente un défi particulier. La flexibilité des requêtes est une arme à double tranchant : un client malveillant pourrait formuler des demandes extrêmement complexes pour surcharger le serveur. La communauté développe des garde-fous : limitation de la profondeur des requêtes, analyse de la complexité avant exécution, contrôle granulaire des permissions. Ces mécanismes permettent d’exploiter la puissance de GraphQL sans exposer l’infrastructure à des abus.

Gartner prévoit que plus de 60% des entreprises utiliseront GraphQL en production d’ici 2027, contre moins de 30% en 2024. Cette progression témoigne de la maturité atteinte par la technologie. Apollo, Hasura, StepZen et d’autres acteurs proposent des solutions qui simplifient le déploiement et la gestion des serveurs GraphQL. L’écosystème s’étoffe, les bonnes pratiques se cristallisent, les pièges sont mieux identifiés.

Au-delà du simple remplacement de REST, GraphQL modifie la façon de penser les interactions client-serveur. Le client ne subit plus les décisions du backend, il exprime ses besoins. Cette inversion change la dynamique entre les équipes frontend et backend, encourage une meilleure collaboration, clarifie les responsabilités. Le schéma partagé est le langage commun qui aligne les efforts de chacun.

Facebook ne cherchait pas à révolutionner le web, juste à accélérer son application mobile. La solution trouvée s’est révélée applicable bien au-delà du contexte initial. En publiant la spécification et en animant une communauté active, Facebook a transformé une solution interne en un standard de l’industrie. GraphQL rejoint ainsi la liste des technologies nées d’un besoin particulier qui ont fini par redéfinir les pratiques de toute une profession.

Haut de page

TensorFlow

Google met en route le projet Brain en 2011, une initiative destinée à explorer les réseaux de neurones profonds dans un cadre industriel. L’objectif tient en quelques mots : bâtir des systèmes d’intelligence artificielle exploitables, d’abord pour la recherche, puis dans les produits de la société. Ce travail débouche sur DistBelief, un premier système d’apprentissage automatique qui offre aux chercheurs un terrain d’expérimentation pour tester des architectures neuronales complexes.

De 2011 à 2015, DistBelief est le socle d’une multitude d’avancées. L’apprentissage non supervisé, la représentation du langage, la classification d’images, la détection d’objets, la reconnaissance vidéo et vocale : les domaines d’application se multiplient. Plus d’une cinquantaine d’équipes chez Google et dans d’autres filiales d’Alphabet déploient des réseaux neuronaux fondés sur cette technologie. Les services qui en bénéficient couvrent un large spectre : moteur de recherche, publicité en ligne, reconnaissance vocale, Google Photos, Maps, StreetView, Translate, YouTube.

Fort de cet apprentissage, Google conçoit TensorFlow comme héritier de DistBelief. La plateforme sort en novembre 2015 sous licence Apache 2.0 avec une architecture entièrement repensée qui change la donne dans la conception des systèmes d’apprentissage. Sa souplesse autorise l’expression d’algorithmes très variés sous forme de graphes de calcul, le tout avec des performances accrues tant pour l’entraînement que pour le déploiement des modèles.

L’originalité de TensorFlow tient à sa capacité de fonctionner sur des systèmes hétérogènes distribués. Un même modèle s’exécute indifféremment sur un téléphone mobile ou dans un centre de calcul équipé de milliers de processeurs graphiques. Cette adaptabilité simplifie drastiquement l’usage pratique des systèmes d’apprentissage, en supprimant la nécessité de créer des versions spécialisées pour chaque environnement.

TensorFlow repose sur une représentation des calculs en graphes orientés. Les nœuds incarnent des opérations mathématiques, les arêtes transportent des tenseurs, ces tableaux multidimensionnels typés. Cette abstraction convient naturellement aux algorithmes d’apprentissage, qui manipulent matrices et vecteurs en permanence. Le système gère automatiquement la répartition des calculs sur les différentes unités de traitement disponibles.

L’architecture s’articule autour de plusieurs composants. Le cœur du système définit des opérations de base : calculs mathématiques élémentaires, manipulation de tableaux, algèbre linéaire, briques pour réseaux de neurones. Ces opérations bénéficient d’implémentations optimisées selon les types de processeurs. Les variables maintiennent l’état du modèle d’une exécution à l’autre. Des files d’attente assurent synchronisation et transfert efficace des données.

Les développeurs accèdent à TensorFlow via des interfaces Python et C++. Ils construisent leurs modèles en assemblant les opérations de base dans un graphe de calcul. Le système prend alors en charge l’exécution distribuée, la gestion mémoire, les optimisations. Des outils comme TensorBoard aident à comprendre et déboguer les modèles en visualisant leur structure et l’évolution des métriques d’apprentissage.

TensorFlow intègre le calcul symbolique des gradients. Cette fonctionnalité automatise une tâche délicate : le calcul des dérivées qu’exigent les algorithmes d’optimisation tels la descente de gradient stochastique. Le système analyse le graphe de calcul et génère automatiquement les opérations correspondant aux dérivées partielles, en appliquant la règle de dérivation en chaîne.

De nombreuses optimisations améliorent performances et utilisation des ressources. L’élimination des sous-expressions communes supprime les calculs redondants. Le placement judicieux des opérations sur les différents processeurs limite les communications. La compression des données échangées entre machines réduit la bande passante nécessaire. Ces optimisations sont critiques lors de l’entraînement de modèles à grande échelle.

Le déploiement dans les produits Google démontre l’efficacité de TensorFlow. Le système de reconnaissance vocale voit son taux d’erreur chuter de 13,25% à 2,5% en cinq ans. Les performances en classification d’images sur ImageNet passent de 63% à 91% de précision. Ces bonds spectaculaires résultent de la combinaison d’architectures plus élaborées et de la capacité à traiter efficacement d’énormes volumes de données.

Google développe parallèlement une gamme de processeurs spécialisés : les TPU (Tensor Processing Unit). Ces circuits intégrés, taillés pour les opérations d’algèbre linéaire à précision réduite, offrent des gains substantiels en performance et efficacité énergétique face aux CPU et GPU classiques. Les générations successives de TPU forment des systèmes massivement parallèles, atteignant plusieurs exaflops pour l’apprentissage automatique.

La publication en open source crée une communauté active. Chercheurs et développeurs s’emparent de TensorFlow dans des domaines très divers : vision par ordinateur, traitement du langage naturel, robotique, recherche d’information, extraction d’informations géographiques, découverte de médicaments. Les contributeurs enrichissent sans cesse la plateforme.

L’architecture flexible et les performances élevées font de TensorFlow une référence pour la recherche et le déploiement de modèles complexes. La disponibilité d’outils matures et d’une documentation fournie démocratise l’accès aux techniques d’apprentissage profond auprès d’un large public de développeurs.

L’évolution de TensorFlow reflète la progression rapide de l’intelligence artificielle. Des premiers prototypes de recherche aux systèmes de production à grande échelle, la plateforme accompagne le développement d’applications toujours plus sophistiquées. Son architecture distribuée et ses optimisations tirent pleinement parti des ressources de calcul modernes pour entraîner des modèles de plus en plus puissants.

Au fil des années, TensorFlow s’enrichit d’extensions variées. Support de nouveaux types de modèles, amélioration des performances, ajout d’outils de développement et de débogage renforcent progressivement ses capacités. La plateforme continue d’évoluer pour répondre aux exigences croissantes de l’apprentissage automatique et de l’intelligence artificielle.

Haut de page

Accelerated Mobile Pages

En octobre 2015, Google lance Accelerated Mobile Pages, une technologie conçue pour accélérer la navigation sur mobile. Le constat est sans appel : 53% des internautes abandonnent une page qui tarde plus de trois secondes à s’afficher. Face à ce problème, Google cherche une solution radicale.

Le projet naît des discussions entre Google et les éditeurs européens dans le cadre de la Digital News Initiative. L’idée initiale vise les sites d’information, premiers concernés par la frustration des lecteurs sur smartphone. La solution technique repose sur trois piliers : une version épurée du HTML, une bibliothèque JavaScript qui optimise le chargement des ressources, et un système de cache pour stocker les contenus. Mais cette architecture impose des contraintes sévères. Les feuilles de style ne peuvent excéder 50 Ko, le JavaScript personnalisé est interdit, et les images doivent utiliser des balises spécifiques comme <amp-img> ou <amp-video>.

Les premiers résultats dépassent les espérances. Le Washington Post enregistre 23% d’utilisateurs supplémentaires qui reviennent dans la semaine suivant leur première visite. En Europe, la plateforme Plista observe une hausse moyenne de 220% du taux de clics sur les contenus AMP, avec des pics à 600% pour certains éditeurs. Ces chiffres attirent l’attention. Pinterest, Reddit, Bing et eBay adoptent la technologie. Google l’intègre à sa section Actualités en février 2016, puis l’étend à tous les résultats mobiles six mois plus tard. Un petit éclair vient alors signaler les pages AMP dans les résultats de recherche.

Sur le plan technique, les performances sont spectaculaires. Les pages se chargent en moins d’une seconde et consomment dix fois moins de données que leurs équivalents classiques. Le cache AMP vérifie automatiquement la conformité des pages et adapte les images aux écrans mobiles. Cette infrastructure atteint des niveaux de rapidité inaccessibles aux sites web traditionnels.

L’usage d’AMP s’élargit vite au-delà des médias. En 2018, la technologie investit le commerce électronique, les e-mails interactifs et la création de contenus narratifs avec AMP Stories. WordPress, qui fait tourner plus d’un tiers du web, propose une extension officielle pour simplifier son déploiement.

Mais le succès d’AMP s’accompagne de critiques acerbes. Malgré son code ouvert, beaucoup reprochent à Google de contrôler étroitement cette technologie. Le fait que les pages AMP soient servies depuis les serveurs de Google pose question : à qui appartient vraiment le contenu ? La préférence accordée aux pages AMP dans les résultats de recherche alimente les accusations de pratiques anticoncurrentielles. Ces reproches conduisent Google à annoncer, en 2018, la standardisation des principes d’AMP à travers le Web Platform Incubator Community Group. L’objectif consiste à permettre à n’importe quel site d’obtenir un chargement instantané sans passer par AMP, en respectant simplement certains critères de performance avec des standards plus ouverts comme Web Packaging et Feature Policy.

En 2020, Google poursuit le développement d’AMP tout en ouvrant progressivement le format. AMP E-mail apporte l’interactivité aux messages électroniques, tandis qu’AMP Stories crée des contenus visuels immersifs. Le projet compte désormais plus de 600 millions de pages réparties dans 232 pays et 104 langues.

La technologie a indiscutablement accéléré la navigation sur smartphone, mais elle a aussi renforcé la centralisation autour des grandes plateformes. Son évolution vers des standards plus ouverts témoigne de la recherche d’un équilibre entre performance et décentralisation. Au-delà des aspects techniques, avec AMP la vitesse est devenue un critère déterminant de l’expérience mobile.

Haut de page

Natural Language Processing

Depuis les années 1950, les chercheurs tentent d’apprendre aux ordinateurs à comprendre notre langue. Le traitement automatique du langage naturel, qu’on appelle plus volontiers NLP dans les milieux spécialisés, a longtemps buté sur les mêmes obstacles : comment saisir les subtilités, les doubles sens, le contexte changeant d’une conversation ? Les premières machines fonctionnaient avec des dictionnaires figés et des règles grammaticales rigides. Puis sont venues les approches statistiques dans les années 2000, qui ont apporté leur lot d’améliorations sans vraiment résoudre le problème de fond.

L’année 2017 marque un basculement. Sur le campus de Mountain View, Ashish Vaswani et Jakob Uszkoreit discutent de traduction automatique dans un couloir. Une conversation anodine en apparence, qui va déboucher sur quelque chose d’inattendu. Leur équipe compte huit chercheurs de Google, dont Illia Polosukhin, amateur de science-fiction. C’est justement un film, Premier Contact, qui lui donne une idée. Dans cette histoire, les extraterrestres communiquent avec des symboles qui expriment des concepts entiers d’un seul coup, sans suivre notre logique séquentielle habituelle. Pourquoi les machines ne pourraient-elles pas faire pareil avec les phrases ?

Cette réflexion conduit au concept d’auto-attention : au lieu d’analyser les mots les uns après les autres comme on lit un livre, le système embrasse la phrase dans sa globalité. Tous les mots dialoguent entre eux simultanément. Noam Shazeer, qui travaille chez Google depuis 2000 et a créé la fameuse fonction « Vouliez-vous dire ? », entend parler du projet dans les bureaux. Il rejoint l’aventure. Les premiers essais sur des traductions anglais-allemand donnent des résultats encourageants.

L’architecture Transformer qui en résulte est plus rapide et plus précise que les réseaux neuronaux récurrents d’avant, et elle ne se limite pas au texte. Le modèle traite des images, du code informatique, des séquences d’ADN. Cette polyvalence surprend ses créateurs.

L’année suivante, une autre équipe de Google AI publie BERT. L’acronyme cache une idée simple : lire dans les deux sens. Le contexte d’un mot dépend de ce qui vient avant, mais aussi de ce qui suit. BERT performe sur onze tâches différentes de traitement du langage, battant les records précédents.

Curieusement, les huit chercheurs à l’origine des Transformers quittent tous Google dans les années qui suivent. Chacun fonde sa société, exploite la technologie dans sa direction. Aidan Gomez lance Cohere pour les entreprises, Jakob Uszkoreit crée Inceptive et applique les Transformers aux vaccins, Noam Shazeer développe Character.ai où les utilisateurs conçoivent leurs propres agents conversationnels. Vaswani et Parmar montent Essential.ai. On retrouve là un schéma classique : les grandes structures peinent à transformer leurs découvertes en produits commerciaux. Les chercheurs partent créer ailleurs.

Cette base architecturale nourrit depuis tous les modèles de langage modernes. La capacité à traiter d’énormes volumes de données, à tisser des liens complexes entre les éléments d’une séquence, fait des Transformers un outil incontournable. Les applications se multiplient : traduction plus naturelle, génération de texte cohérent, analyse documentaire, systèmes de questions-réponses performants. Les machines s’approchent des nuances du langage humain, comprennent mieux les relations entre les idées.

Du traitement mot à mot des débuts aux systèmes d’attention contemporains, chaque étape a rapproché les ordinateurs de notre complexité linguistique. Les Transformers ne sont pas qu’une prouesse technique. Ils servent de socle à une cascade d’innovations dans des domaines variés : médecine, recherche scientifique, éducation. La communauté scientifique développe sans cesse de nouvelles variantes.

À mesure que ces modèles gagnent en sophistication, ils modifient notre rapport à la technologie. La frontière entre communication humaine et interaction machine est plus floue. Les développements futurs promettent de nouvelles possibilités, tout en soulevant des questions d’éthique et de responsabilité. Jusqu’où ira cette capacité des systèmes à comprendre et produire du langage naturel ? La réponse s’écrit jour après jour, dans les laboratoires comme dans nos usages quotidiens.

Haut de page

WebAssembly

En 1995, JavaScript voyait le jour comme un simple langage de script. Personne n’imaginait alors qu’il deviendrait le moteur d’applications Web sophistiquées. À l’origine, il servait surtout à valider des formulaires ou animer quelques éléments d’une page. Le gros du travail se faisait sur les serveurs, les navigateurs ne gérant que l’affichage et quelques interactions basiques.

Tout a changé avec l’arrivée de moteurs performants comme V8. JavaScript s’est mis à gérer des programmes de plusieurs milliers de lignes, des applications qui auraient été impensables quelques années plus tôt. Le langage se retrouvait utilisé bien au-delà de ce pour quoi on l’avait conçu.

Cette transformation a poussé les acteurs du Web à chercher des voies alternatives. Microsoft a tenté sa chance avec ActiveX, qui reposait sur la signature de binaires x86 – une approche fondée sur la confiance plutôt que sur de vraies garanties techniques. Google a ensuite développé Native Client, qui introduisait le sandboxing pour du code machine sur le Web. Les performances s’approchaient du natif, mais les développeurs devaient suivre des contraintes strictes dans leur code, comme utiliser des masques binaires avant chaque accès mémoire.

Emscripten a ensuite ouvert une nouvelle possibilité : compiler du C ou du C++ vers JavaScript. Le système créait un environnement d’exécution en JavaScript et traduisait le code vers un sous-ensemble spécialisé, qui a donné naissance à asm.js. On pouvait enfin exécuter du code bas niveau dans un navigateur, mais JavaScript restait un intermédiaire contraignant.

C’est en 2015 que l’histoire prend un tournant inattendu. Des ingénieurs de Google Chrome, Mozilla Firefox, Microsoft Edge et Apple Safari se sont mis autour d’une table pour travailler ensemble. Ces concurrents historiques, qui s’étaient livrés à des « guerres des navigateurs » pendant des années, ont décidé de collaborer. Leur but ? Créer un format de bytecode portable qu’ils ont appelé WebAssembly.

Le projet avait des ambitions claires. Il fallait une représentation compacte, une validation rapide, une compilation efficace. Et surtout, une exécution sûre sans pénalité de performance. Les concepteurs ont fait un choix audacieux : formaliser la sémantique dès le départ. WebAssembly devenait ainsi le premier langage industriel conçu avec une sémantique formelle dès sa création.

L’architecture qui en résulte présente quelques particularités. WebAssembly s’appuie sur une machine à pile pour représenter les calculs. Mais grâce à son système de types, les compilateurs peuvent analyser le flux de données entre instructions sans avoir à matérialiser physiquement cette pile. Le contrôle de flux est structuré : pas de goto sauvage, mais des constructions classiques via des blocs imbriqués.

La mémoire fonctionne comme un grand tableau d’octets, séparé du code et de la pile d’exécution. Un programme défaillant ou compromis ne peut corrompre que ses propres données. Cette isolation garantit la sécurité : le code s’exécute dans un bac à sable qui l’empêche d’accéder au système hôte sans autorisation.

Le format binaire a été pensé pour le réseau. Les instructions tiennent sur un octet, les nombres entiers utilisent le format LEB128. Les navigateurs peuvent commencer la compilation dès les premiers octets reçus, sans attendre le téléchargement complet du module.

En 2017, les quatre principaux navigateurs intégraient le support de WebAssembly. Chaque équipe a choisi sa propre stratégie d’implémentation. V8 et SpiderMonkey ont réutilisé leurs compilateurs JIT pour compiler les modules avant leur instanciation. JavaScriptCore a suivi une voie similaire. Chakra a préféré traduire à la volée vers un bytecode interne, puis compiler les fonctions les plus sollicitées.

WebAssembly atteint souvent 80 à 90% des performances du code natif, tout en gardant la portabilité et la sécurité du Web. Le code généré est compact : 62,5% de la taille d’asm.js en moyenne, 85,3% de celle du x86-64 natif.

L’influence de WebAssembly déborde du navigateur. Sa conception le rend utilisable dans d’autres contextes. Des implémentations autonomes existent, qui transforment WebAssembly en format portable pour des applications natives. On retrouve là l’ambition originelle de Java avec son « écrire une fois, exécuter partout ».

Le développement continue. Les exceptions à coût nul sont arrivées, les threads aussi, ainsi que les instructions SIMD. L’intégration des ramasse-miettes des navigateurs est en cours, ce qui facilitera la compilation de langages comme Java, C#, Swift ou OCaml vers WebAssembly.

Au-delà de la technique, WebAssembly témoigne de l’accomplissement de la collaboration dans l’écosystème Web. Le projet montre qu’une approche rigoureuse, presque académique, peut cohabiter avec les réalités du développement industriel. Cette technologie a redéfini ce qu’il est possible de faire tourner dans un navigateur, sans sacrifier la sécurité qui est au cœur du Web.

Haut de page

WebAuthn

Depuis que les premiers systèmes informatiques ont vu le jour, la question de l’authentification des utilisateurs n’a cessé de se poser. Le mot de passe s’est imposé très tôt comme la réponse évidente : une chaîne de caractères connue de l’utilisateur, simple à mettre en place, facile à comprendre. Sauf que cette simplicité cache mal ses faiblesses. On vole les mots de passe, on les devine, on les intercepte. En 2024, plus de 80% des piratages tirent encore parti de mots de passe trop faibles ou volés.

Au fil du temps, d’autres méthodes sont apparues. La vérification en deux étapes, les certificats numériques, la biométrie. Chacune apporte sa pierre à l’édifice, mais elles restent parfois lourdes à déployer, ou manquent d’une vraie uniformité. C’est là que le W3C et l’Alliance FIDO ont décidé de changer la donne avec Web Authentication, qu’on appelle plus simplement WebAuthn.

Google, Mozilla, Microsoft et Yubico ont mis la main à la pâte pour aboutir à cette spécification publiée en 2019. L’idée rompt avec ce qu’on faisait depuis des décennies. Au lieu de partager un secret entre l’utilisateur et le serveur, WebAuthn s’appuie sur la cryptographie asymétrique. Quand vous vous inscrivez sur un service, une paire de clés se crée. La clé privée reste bien au chaud sur votre appareil, tandis que la clé publique part vers le serveur avec un identifiant généré au hasard.

Dans cette architecture, la clé publique stockée côté serveur ne sert à rien pour pirater votre compte. Les attaquants se désintéressent de plus en plus des bases de données. L’authentification est liée au domaine exact du site : une clé créée pour example.com ne marchera jamais sur evil-example.com. Les tentatives d’hameçonnage perdent beaucoup de leur efficacité.

WebAuthn repose sur trois piliers. La robustesse d’abord : l’authentification s’appuie si possible sur un module matériel de sécurité qui garde les clés privées et effectue les calculs cryptographiques. Le périmètre ensuite : chaque paire de clés ne vaut que pour une origine précise, comme les cookies qu’on connaît bien. L’attestation enfin : les authentificateurs peuvent fournir un certificat qui prouve au serveur que la clé publique vient d’une source fiable.

Les navigateurs ont vite adopté cette technologie. Chrome, Firefox, Edge, Safari : tous prennent en charge le standard. Les développeurs ont donc la capacité de l’intégrer de façon homogène. Les systèmes d’exploitation modernes ont suivi avec leurs propres systèmes d’authentification : Windows Hello chez Microsoft, Touch ID chez Apple.

Le processus lui-même se déroule en plusieurs temps. À l’inscription, le serveur transmet des données qui lient l’utilisateur à ses identifiants, avec des informations sur l’organisation et une chaîne aléatoire pour contrer les attaques par rejeu. Le navigateur utilise l’API Web Authentication pour demander la création d’une nouvelle paire de clés.

La réponse contient l’identifiant de l’authentificateur, les données client en JSON, un objet d’attestation. Le serveur vérifie tout ça selon une procédure en 19 points décrite dans la spécification. Une fois validé, il stocke la clé publique et l’identifiant dans sa base.

Pour les connexions suivantes, vous prouvez que vous possédez la clé privée en créant une assertion. Le serveur envoie une nouvelle chaîne aléatoire, l’authentificateur génère une signature numérique que le serveur vérifie avec la clé publique qu’il a gardée. Plus de risque de vol de mot de passe, et l’expérience utilisateur s’en trouve améliorée.

WebAuthn s’inscrit dans FIDO2, un ensemble de technologies qui vise à généraliser l’authentification sans mot de passe. Le besoin se fait sentir : en 2024, seulement 28% des utilisateurs activent la double authentification sur leurs comptes en ligne.

La spécification continue d’évoluer avec de nouvelles fonctionnalités et des implémentations qui s’affinent. Les développeurs trouvent des exemples de code et des bibliothèques dans différents langages, Python et Go notamment, pour intégrer WebAuthn dans leurs applications.

L’histoire de WebAuthn montre comment les méthodes d’authentification sur Internet se transforment. En remplaçant les mots de passe par des clés cryptographiques, cette norme répond aux exigences de sécurité actuelles tout en simplifiant la vie des utilisateurs. Les grands acteurs du web l’adoptent de plus en plus, et l’on peut parier qu’à l’avenir, s’authentifier deviendra à la fois plus sûr et plus pratique.

Cette évolution s’inscrit dans un mouvement plus large où la cryptographie asymétrique remplace peu à peu les secrets partagés d’autrefois. WebAuthn représente une étape importante dans l’histoire de la sécurité informatique, en apportant une solution standardisée à ce problème d’authentification qui nous poursuit depuis les débuts.

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.