Application driven system

Pendant des décennies, utiliser un ordinateur exigeait une compréhension, même tacite, de sa mécanique interne: la gestion des fichiers, l'allocation de la mémoire, la hiérarchie du système d'exploitation. L'informatique était une conversation avec la machine. Aujourd'hui, nous assistons à une inversion complète de ce paradigme. Le système d'exploitation, jadis le maître des lieux, n'est plus qu'un hôte silencieux, un majordome presque invisible au service exclusif de l'Application, devenue reine.

Cette transition, progressive mais radicale, a transformé non seulement l'expérience utilisateur, mais aussi le métier de développeur et l'architecture même de nos systèmes. Nous sommes passés d'une ère où l'on construisait sur le système à une ère où l'on assemble dans l'application.

Dans les années 70 et 80, l'informatique était un champ d'exploration. Des environnements comme celui de Smalltalk incarnaient cette philosophie. Les anciens étudiants de l'ESP connaissent le professeur qui faisait les éloges de Smalltalk. Avec ce dernier le système et l'application ne faisaient qu'un. L'utilisateur, souvent un développeur ou un chercheur, pouvait "ouvrir le capot" à tout moment, inspecter un objet, modifier son comportement en direct et voir l'impact sur l'ensemble de l'environnement. L'informatique était un dialogue constant avec un système vivant et malléable.

Aujourd'hui, le postulat a changé. L'objectif n'est plus de comprendre la machine, mais de la faire disparaître.

L'utilisateur ne veut plus "utiliser un système", il veut "réaliser une tâche".

Cette demande a engendré une transition vers des systèmes que l'on peut qualifier d'Application-Driven. Que vous soyez sur iOS, Android, Windows 11 ou macOS, l'objectif est le même: réduire au maximum la friction cognitive et le temps entre l'intention de l'utilisateur ("je veux commander un taxi", "je veux retoucher cette photo") et l'exécution de l'application dédiée. Le système d'exploitation est devenu une plateforme de lancement optimisée, un simple canevas sur lequel les applications peignent leurs expériences.

Cette évolution a créé une couche d'abstraction si épaisse que le matériel (hardware) a quasiment disparu derrière l'interface. Le processeur, la RAM, le stockage ne sont plus des concepts avec lesquels l'utilisateur interagit, mais des ressources gérées de manière opaque pour garantir la fluidité de l'expérience applicative. Le succès se mesure en millisecondes de chargement, pas en mégaoctets de mémoire libérée.

Si cette évolution a indéniablement démocratisé l'informatique, la rendant accessible à des milliards d'individus, elle a un coût caché, particulièrement sensible dans nos métiers techniques: la perte progressive de la culture technique fondamentale. Nous construisons des édifices de plus en plus hauts sur des fondations que nous ne comprenons plus.

L'illusion de la simplicité

Tout semble "magique". On appuie sur un bouton dans une application web, et l'action se produit. En réalité, cette simple interaction déclenche une cascade d'événements vertigineuse: un appel API vers un load balancer, qui le route vers un conteneur dans un cluster Kubernetes, qui exécute un code s'appuyant sur trois microservices, lesquels interrogent une base de données répliquée sur plusieurs continents. Cette complexité, masquée par des abstractions successives, crée une illusion de simplicité qui est aussi une illusion de robustesse. Comme nous l'avons souvent vu dans les revues d'incidents, la défaillance d'un seul maillon invisible peut faire s'écrouler tout le château de cartes.

La dépendance aux outils et aux frameworks

Les nouveaux développeurs apprennent à utiliser des frameworks comme React , Angular ou Flutter sans toujours comprendre comment le navigateur rend le DOM, comment le processeur traite les instructions JavaScript, ou comment la mémoire est gérée par le garbage collector. Ils deviennent des "assembleurs de composants" très efficaces mais se retrouvent démunis lorsque le problème sort du cadre prévu par le framework. Un bug de performance ou une fuite mémoire devient alors une énigme insoluble, car les outils de diagnostic nécessitent une connaissance des couches basses que leur formation n'a pas fournie.

Quand l'application tombe en panne, le véritable test commence. Le manque de connaissance des couches inférieures rend le débogage exponentiellement plus complexe. Un développeur qui ne comprend pas les appels système (syscalls) aura du mal à utiliser strace ou dtruss pour comprendre pourquoi son application n'arrive pas à ouvrir un fichier. Celui qui ignore les principes du protocole TCP/IP peinera à diagnostiquer une latence réseau inexpliquée. Cela est particulièrement critique face au legacy code, où les abstractions d'hier ne sont plus maintenues et où seule une compréhension profonde du système sous-jacent permet de naviguer dans des strates de code vieilles de plusieurs décennies.

Nous vivons un paradoxe fondamental: plus une interface est simple, plus l'infrastructure qui la soutient est complexe. Cette simplicité en façade est achetée au prix d'une complexité monstrueuse en coulisses. Nous sommes entrés de plain-pied dans le monde des "Leaky Abstractions", un concept brillamment formulé par Joel Spolsky. Une abstraction est "fuyante" lorsqu'elle ne parvient pas à masquer complètement les détails de l'implémentation sous-jacente et ces détails finissent inévitablement par refaire surface, souvent au pire moment.

On nous promet que le "Cloud" est une ressource infinie et élastique mais il repose sur des serveurs physiques bien réels dans des datacenters qui peuvent surchauffer, tomber en panne ou être affectés par une coupure de fibre optique. On nous promet que notre code conteneurisé est universel et portable mais ses performances dépendent intimement de la version du noyau Linux de l'hôte et de la configuration des cgroups. L'abstraction promet la simplicité mais la réalité du système finit toujours par s'imposer.

Cette dichotomie entre la vision applicative et la réalité système est au cœur des défis de l'ingénierie logicielle moderne.

Face à ce constat, il est urgent de rééquilibrer la balance. Nous ne pouvons pas continuer à former des resources qui ne sont que des "utilisateurs avancés" de frameworks. L'innovation future, la robustesse de nos systèmes et notre capacité à maintenir le monde numérique que nous avons construit dépendent d'un retour aux sources. Il ne s'agit pas de rejeter les abstractions, qui sont des outils de productivité extraordinaires, mais de savoir voir à travers elles.

Pour que l'innovation continue, nous devons mettre à jour nos programmes d'éducation et nos pratiques de formation continue pour enseigner:

• Les fondamentaux: il est important de comprendre le binaire, la représentation des nombres, la gestion de la mémoire (la pile vs le tas), le fonctionnement des systèmes de fichiers et les protocoles réseau fondamentaux. Savoir cela n'est pas un exercice académique, c'est ce qui permet de comprendre pourquoi une sérialisation JSON est inefficace ou de déboguer une connexion persistante qui échoue.
• L'histoire: l'informatique n'est pas née avec React. Savoir que des solutions élégantes aux problèmes d'aujourd'hui (concurrence, modularité, gestion d'état) ont été inventées et explorées à l'époque de Smalltalk ou de la philosophie UNIX offre une perspective et une profondeur inestimables. L'histoire nous apprend les compromis et les raisons d'être des technologies actuelles.
• La transparence: nous devons cultiver la curiosité et apprendre à "casser" l'application pour voir le système qui pulse en dessous. Cela signifie maîtriser les profileurs, les débogueurs, les analyseurs de paquets (comme Wireshark) et les outils d'introspection système (comme strace ou perf). Il faut encourager les développeurs à lire le code source de leurs dépendances, pas seulement leur documentation.

Le rôle du développeur, surtout à l'ère de l'IA générative, évolue vers celui d'un architecte et d'un intégrateur système de haut niveau. Pour exceller dans ce rôle, la maîtrise de l'application ne suffit plus. Il faut comprendre la machine sur laquelle elle s'exécute.

L'avenir appartient à ceux qui maîtrisent l'application mais qui comprennent le système aussi.

TakkJokk,